[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Pairwise merging of certificates
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
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.