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

New Issue: <issuer> definition

Ron Rivest and I have been having a discussion about issuer names offline
and he asked me to forward his comments to the list.

He is raising a concern with the inclusion of <fq_name> as one possibility 
for an Issuer.  [This was one of the open questions listed in the December 
meeting which I said I would work into the I-D and open up for comments on 
the list and in the next meeting.]

Currently, we have:

<issuer>:: <principal> ;
<principal>:: <key> | <hash-of-key> | <fq-name> ;
<subj-obj>:: <principal> | <relative-name> | <hash> | <secret-sig-key> ;
<fq-name>:: "(" <T_fq_name> <principal> <names> ")" ;
<names>:: token | <names> token ;

Ron is proposing that we switch back to

<principal>:: <key> | <hash-of-key> ;
<subj-obj>:: <principal> | <fq-name> | <relative-name> | <hash> | 
<secret-sig-key> ;
and have one of two options for <issuer> --

1) <issuer>:: <principal> ;


2) <issuer>:: <principal> | <fq-group-name> ;
<fq-group-name>:: "(" "GN:" <principal> token ")" ;

Discussion so far:

Current I-D:

As defined in the I-D, a principal is anything which can be resolved to a 
key -- perhaps at a later date.  One side effect of this is that the same 
certificate body could be signed by two different issuer keys at the same 
time.  The benefit of this, IMHO, is that the issuer's signature on a cert 
can be fault tolerant.  That is, one person can use two different issuer 
keys, sign the same cert with both, and then when one of the keys becomes 
compromised, the cert is left with a valid signature.

The alternative way to achieve fault tolerance is to have the two issuer 
keys and generate two different but equivalent certs, one for each key, and 
sign both.  So, the I-D's definition of <issuer> (really of <principal>) 
saves one cert body but gains no new functionality, at the expense 
of complication through generality of <principal>.  [The other uses of 
<principal> are not affected by this option, since they are forced to 
resolve to a key to make sense.]

Option 1:
Ron's argument against the I-D method is as follows.

He wrote:
>In general, I am uncomfortable with situations where
>it is not clear, just from the certificate, which signing key has the authority
>to issue the certificate. In case (*) above, the key bound to K's bob
>(or to K's bob's alice) has the authority, but you can't tell what that is
>unless you have additional certificates.  I believe this could even end
>up with circular ambiguities...

and later:
>    Now I argue that you must store K2 with the certificate after signature
>    validation.  What, for example, happens if there is more than one valid
>    certificate for K's A?  If K3 is also a valid definition of K's A, then
>    this ambiguity is not represented in just the certificate.  If something
>    later goes wrong (this certificate is part of a chain that allows a bad
>    guy in), then your audit trail needs to be clear on this point.
>    Furthermore, there may even be a whole chain of certificates involved,
>    if K's A can be defined symbolically as K4's D's E's F and and so on.
>    Thus, with the interpretation of what the issuer means as sketched above,
>    determining who (i.e. what key) is really the issuer may involve
>    ambiguity and many other certificates.  

Option 2:
Ron actually recommended this option, and I am attracted to the elegance, 
but it might be on shaky ground.  After all, the I-D definition of <issuer> 
was even more elegant.  [This partial elegance reminds me a little of the C 
language (of which I'm not fond).]

The argument is that if you allow an <issuer> to be a group name (one token 
from a given <principal>'s name space), then the syntax of the SDSI-style 
MEMBER certificate is simiplified -- and becomes identical with the 
SPKI-style MEMBER certificate -- namely, an <auth> field of <Moi:>.
I haven't looked for other benefits from this option.


So, I'm adding an issue to the end of my copy of the I-D:

    18) Should we restrict the <issuer> definition to preclude the
        possibility of the same cert body being signed by multiple keys
        as Issuer (which can happen when the <issuer> is a general SDSI
        name resolving to a key)?  If so, should we permit an <issuer>
        to be a group name, thus allowing the (Moi:) <auth> to define
        SDSI group membership?
   18a) <principal>:: <pub-key> | <hash-of-key> ;
        <subj-obj>:: <principal> | <fq-name> | <relative-name> | <hash>
        | <secret-sig-key> ;
        <issuer>:: <principal> ;
   18b) <principal>:: <pub-key> | <hash-of-key> ;
        <subj-obj>:: <principal> | <fq-name> | <relative-name> | <hash>
        | <secret-sig-key> ;
        <issuer>:: <principal> | <fq-group-name> ;
        <fq-group-name>:: "(" "GN:" <principal> token ")" ;

|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |