[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.
Issues
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
signatures.]
[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
word.]
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
draft?
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 |
+------------------------------------------------------------------+