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

issues from RLR



I've added the following numbered issues to my copy of the I-D:


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

    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?

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

    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.

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

    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
        signatures.]

    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?





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