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

*To*: carl@theory.lcs.mit.edu*Subject*: Pairwise merging of certificates*From*: rivest@theory.lcs.mit.edu (Ron Rivest)*Date*: Fri, 27 Jun 97 09:28:21 EDT*Cc*: butler@theory.lcs.mit.edu, tatu@theory.lcs.mit.edu, angelos@theory.lcs.mit.edu, rivest-only@theory.lcs.mit.edu, martin@theory.lcs.mit.edu, spki@c2.net*Sender*: owner-spki@c2.net

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

**Re: Pairwise merging of certificates***From*: Carl Ellison <cme@cybercash.com>**Re: Pairwise merging of certificates***From*: Carl Ellison <cme@cybercash.com>

- Prev by Date:
**Top SDSI issues** - Next by Date:
**Re: Pairwise merging of certificates** - Prev by thread:
**Re: Top SDSI issues** - Next by thread:
**Re: Pairwise merging of certificates** - Index(es):