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

current issues list

Here is my copy of the issues list, with answers from the past week's 
discussion, as I have it at this moment.


     1) Should we require that all certificates be signed by both Issuer
        and Subject, when the Subject reduces to a key?  [When the
        Subject is a non-key object, it can't sign.]

             [Answer: no.  Signing by the Subject can not be prevented
             so it can be used if a need arises, but at present no
             security enhancement is seen to come from Subject signing.
             This seems to address the concerns of lawyers only.]

     2) Can the Signature object support blind signatures with
        algorithms other than RSA?

     3) Should we eliminate the final ":" in field names?  These are
        always the first names in a list and the ":" seems to be a
        carry-over from RFC822 without a real purpose.

             [Answer: yes.]

     4) Should we continue to lump public key algorithm, hash algorithm
        and padding algorithm together in one pub-key-name?  This could
        lead to an explosion of names.  Of course, on the other hand
        this might reduce the number of competing algorithm/hash/pad
        mixes and simplify code.

             [Answer: no.  There are a number of proposals for
             expressing the components of a signature verification
             algorithm and one should settle out by the week after the
             April IETF meeting.]

     5) Should the delegation parameter be integer or boolean?

             [Answer: boolean is all people want, except for the third
             value "stop-at-key" proposed by Ron Rivest.  We will assume
             a three-value parameter.]

     6) Are object names (e.g., "Issuer") case sensitive?

             [Answer: yes.  All other strings are, so these byte strings
             should be also.  However, we decided to use all lower-case
             for object names that we define.]

     7) Should we allow multiple <auth>s in one cert?  It saves space
        and time, maybe, but could constitute a privacy threat and may
        complicate the cert reading code.

             [Answer: yes.  The (* set ...) mechanism makes it easy to
             specify without constituting a serious complication to the
             5-tuple reduction process.]

     8) How much can we specify the <online-test>?  Are there only a
        handful possible/desirable tests, that we can fully spell out,
        or do we need to leave that open for invention?

     9) How many pre-defined <auth>s should we bother defining?

    10) If the Subject is a hash of a Bundle of hashes of keys, does
        this mean that the cert applies to all keys in the bundle?

    11) If the Subject is a hash of a file and the file contains hashes
        of other things, does the cert apply to the other things?

             [Answer: no, according to general opinion.  This is a more
             general issue which the community needs to consider.
             Perhaps W3C DSig will be the first to encounter examples of
             this in practice.]

    12) Do we want to include validity fields for private key dates, as
        was done with X.509v3?

             [Answer: not at this time and not in these certificates.
             An SPKI/SDSI certificate doesn't define a public key.  The
             public key is a primitive.  There remains open the question
             of whether we want keys to expire and, if so, what kind of
             a data structure we want to support key validity dates.
             The subject-info field can point to or yield such a
             structure, should we define one.]

    13) How do we want to name algorithms?  One possibility is to define
        a few common ones (ones we want to encourage everyone to use for
        interoperability reasons) and allow others to be defined as URIs
        pointing to the definition of the algorithm.

    14) Should we restore the explanation of [ECR] and define a <valid>
        field option for it?  This was removed from this draft in the
        interest of simplification.

    15) Should we allow Object as an optional element of the Signature
        expression, or force that block to give the Object's hash?

    16) Should we define an RSA signature algorithm with no hash and no
        padding, to hold verbatim objects being signed (assuming they
        are small enough)?

    17) What is the difference between the Member and Name <auth>?  Can
        they be combined into one?

             [Answer: these are now one, according to the SDSI authors.]

    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> byte-string ")" ;

             [Answer: current thinking restricts the (issuer ...) to be
             a principal or a name under that principal, in which the
             principal signs the certificate.  That is, a simple name as
             issuer is a syntactic form for the original SPKI (name foo)
             and (member bla) forms.]

    19) [RLR] Should we replace the display info syntax [xxx] "yyy" with
        ( display-type xxx "yyy" ) ?

             [Answer: no.]

    20) [RLR] Should we have only one spelling of each object type?  If
        so, should it be the long or the short form?  Can we make such
        spellings short enough that they don't force line continuations
        while keeping them descriptive?

             [Answer: one spelling, preferrably one English word (so
             that a user can look it up in a dictionary).]

    21) [RLR] Let's add a section to the I-D showing how each of the
        original SDSI constructs is handled in SPKI.  [[CME] We could
        also add a section for PICS labels, X.509 certs, PGP signed
        keys, ....]

    22) [CME] Are object types reserved words over the entire
        certificate body or are they to be non-conflicting only within
        their enclosing object?  [In the latter case, the ( Auth XXX
        .... ) object is to be considered to be of type "Auth XXX".]
        That is, when we go into an object, do we acquire a new
        dictionary of object types relevant to the interior of that
        object or do we use a single global such dictionary?  [I believe
        we have to use local dictionaries, in order to allow distributed
        <auth> definition.]

             [Answer: object names have scope only within an object
             which defines them.]

    23) [RLR] Should we allow the Subject to optionally be the hash of
        some non-key object?  This could be seen as encroaching on the
        territory of signed PICS labels.

             [Answer: yes.]

    24) [RLR] Should we define another, non-cert object, ( assert ... ),
        to cover signed statements about non-keys?

             [Answer: no.]

    25) [RLR] Should we make a clear statement that the keys used in
        these certs are signature keys?  [[CME] I think that's
        understood from the fact that the only crypto we use is for

             [Answer: yes -- this should be clear in the document.]

    26) [RLR] Should we continue to use different object types for fq-
        name, rel-name and grp-name, or use "Ref" as the type and let
        the parameters determine which is intended?

             [Answer: no -- use "ref", although that is not an English

    27) [RLR] Should we define (keyholder <principal>) to mean the human
        or computer etc. who/which holds a private key, to be used in
        Subject lines?

             [Answer: yes.]

    28) [RLR] There are different cert-like entities, in that they all
        reduce to 5-tuples, but they may have different object names and
        slightly different BNF definitions:
        a) certificate -- subject is a <principal>
        b) assertion -- subject is a cyberspace object
        c) request -- (a kind of assertion)
        d) ACL entry -- issuer is missing
        e) auto-cert -- subject is (keyholder [of] <principal>)

             [Answer: call them all certificates.]

    29) [RLR, CME] As written now, it is inconsistent to have a name as
        a Subject in a cert with (delegate false).  RLR proposes that
        (delegate to-key) mean that propagation occurs through
        certificate sub-chains which have non-key subjects and stop when
        the subject is a key.

             [Answer: use to-key as an argument to delegate, but rename
             delegate to propagate.]

    30) Should we start another draft to cover operation of a
        certificate server (as in SDSI 1.0) including protocols for
        communicating with it or should that discussion be in this

    31) Should we start another draft to cover fully worked out examples
        of tags for real operations (e.g., FTP, HTTP) or let those be
        part of this draft?

 - Carl

|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        |