[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Pairwise merging of certificates


Carl --

In my last note, I said that we had the following issue:

4. [Longer issuers and cert chain collapsing]
    It would be desirable to define cert chain collapsing pairwise, so that
    the description of how to collapse a cert chain proceeds by induction
    from the base case of collapsing two certs.  At the moment, we can't
    do this, since the result cert may have an issuer with the form
    (ref K1 N1 N2 .. Nk)  where k>1.  Thus, Butler and I feel that it would
    be good to allow such expanded issuers in certs.  This is an issue that
    we addressed before, and decided not to allow such issuers because they
    may seem a bit more complicated to the user.  

Here is a more detailed explanation:

Suppose we have 

Cert 1:	Issuer 1 = K1 A
	Subject 1 = K2 B X

Cert 2: Issuer 2 = K2 B Y
	Subject 2 = K3 C

where A, B, C, X, and Y stand for sequences (possibly empty) of names,
and B is the longest prefix of names in common from Subject 1 and
Issuer 2.  (In the current version of SPKI/SDSI, A and B Y must be at
most a singleton name.)  If Cert 2 follows Cert 1 in the chain, then
for collapsing to be legal, we must have that at least one of X and Y
must be null, so that one of Subject 1 and Issuer 2 is a prefix of the
other (or that Subject 1 = Issuer 2).

The result of collapsing these certs is

Cert 3: Issuer 3 = K1 A Y
        Subject 3 = K3 C X

(which can be checked by considering the cases X = null and Y = null
separately.)

Thus, we see that even in the current version we get a result certificate
with an issuer that has length > 2 if A and Y are both non-null names. E.g.

Cert 1: Issuer 1  = K1 microsoft
        Subject 1 = K2

Cert 2: Issuer 2  = K2 gates
        Subject 2 = K3 bill

==>

Cert 3: Issuer 3  = K1 microsoft gates
        Subject 3 = K3 bill


Thus, I think that we should restore the possibility of having issuers
with > 1 name, to support pair-wise cert collapsing.  

The user interface may, of course, reasonably discourage the user from
issuing such certs.

	Cheers,
	Ron Rivest
Follow-Ups: