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

Re: Lasr RFC dratf comments

-----BEGIN PGP SIGNED MESSAGE-----

Thank you for these comments.  I will work on the next draft with these in 
mind.

 - Carl

(see comments interspersed below)

At 11:35 AM 11/25/97 +0100, serret wrote:
>Hello all!
>
>After trying to study the last RFC's draft
>(draft-ietf-spki-cert-structure-02 & theory & examples) we found several
>problems or inconsistencies ( commented over
>draft-ietf-spki-cert-structure-02 document).
>
>Principal confusion:
>
>In the whole document the notion of Principal is used. The major problem
>is that is never clearly specified that in the general case of a public
>key cryptosystem, the Principal is the private key, but its (unique)
>identifier (what we will find writen in the certificates) is its public
>key or the hash of its public key. If the hash of the private key is
>used to identify a principal on a certificate, then it is clear that we
>will never be able to check a signature, because there is no way to go
>from hash(PrivateKey) to PublicKey. This means that we use the private
>key in the same way as a secret key.

I will make this clearer.

The private key is that which speaks and is the machinery of the principal.

The public key is 1:1 with the private key and is both a way of verifying a 
signature and a name for the public key.

The hash of the public key is a name for the public key.

So, we use either the public key or its hash as the principal -- precisely, 
as a name for the private key.

>
>BNF lack:
>
>BNF is used to specify the structures, but unfortunately BNF is only
>poorly introduced in page 12, (for example the operator "|" is not
>explained) and there is no bibliographic pointer. 

I assumed everyone knew these, but you're right.  If I define * and ?, I 
should define |.


>SDSI confusion:
>
>The examples based on SDSI are almost confusing. The reader must guest
>the meaning of all the fields, and then try to check if the example
>"works" or have any sense. Pages 8(better) & 31(worst). Reading the
>proposed online documentation does not help.
>
>In page 8 I would change the text where it says :
>By NAME (formally "SDSI Name") we mean a string of the form (K1 N1 N2
>   ... Nk) where 1 <= k.  Every name is a name in some namespace.
>To :
>By NAME (formally "SDSI Name") we mean a string of the form (K1 N1 N2
>   ... Nk) where 1 <= k.  Every name is a name in some namespace
>designed by the previous name in the string, being K1 the owner of the
>initial namespace.

I will look carefully at that text and find a way to rework it.
Thanks for the catch.

>ACL : 
>
>The meaning of the term ACL for SPKI is well defined, but the term
>itself is valid only for historical reasons, and Access Control List
>does not mean " unsigned certificate issued by me". Maybe somebody can
>propose a better name ?.

We might call it an assertion.  It really is an ACL, of course.  That is, an 
ACL is a list of assignments of authorizations to subjects, not signed.  I 
like "ACL" for its brevity, but will gladly listen to discussion on the term.


>IANA (page 15):
>
>What is it? some useful pointers ?.

I'll track down defining RFCs (if any).

><public-key>: 
>
>Why the pub-sig-alg-id includes the hasing algorithm ? I think is much
>better to leave a public key alone and identify the hash-alg-name in the
><hash> structures. Keeping in that way a key is forced to use always the
>same hash algorithm, and what happens if a key will never be used to
>sign ? ( yes is possible).

A key not used to sign would have a different name.  It could have the same 
values, but a different algorithm name.

We went back and forth on naming of public keys.  The separation of parts of 
the process led us down the path of expressing a public key as a little 
(LISP) program to do the signature validation -- but that got out of hand.  
I can argue both directions.  I like the idea of naming algorithms with 
little programs everyone can execute.  However, that's a complexity for many 
people.  E.g., those with BSAFE don't have that choice.  They have a list of 
combined algorithm names like the ones we're using.

><reval> & <reval>, <crl> <delta-crl> <sequence> :
>
>The s-expression <reval> is defined two times : one in page 32
>(<reval>:: "(" "reval" <version> <subj-hash> <valid-basic> ")";) and
>other in 33 (<reval>:: "(" "reval" <version> <subj-hash> <one-valid>
>")"; ).

There are two kinds of reval -- one-time and persistent.  I will look at the 
text to see how to make that clear.


>The version field is not optional here -> <crl> , <delta-crl> <reval>,
>why?

The version should be optional in all these cases.  It's sloppiness on my 
part when it isn't.

>Finally and must important, a big incoherence :
>To be valid the <cert> <reval> & <crl> objects must be signed, for that
>reason <cert> is packed in the <sequence> object, who to have any sense
>must contain almost a <cert> and a <signature> over that <cert>.
>Strangely <reval> and <crl> are top level objects, who can stand alone
>with any signature over them !. I suggest to add <reval> and <crl> items
>to the <seq-entry>.

<reval>, <crl> are not part of a normal sequence.  They are responses to 
on-line tests and arrive alone.  However, you are correct that the response 
itself will probably need to be a sequence.  I will modify the BNF and the 
text to note that.

>
>Finally I would like to apologize for being more destructive that I
>would desire to.

I really appreciate your help and your thorough reading of the draft.

 - Carl


-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQCVAwUBNH0lyRN3Wx8QwqUtAQHfXQP/Yg9v4zqOs5gFhSapnmneR/ozfepxXUkE
M6SIlqJIa+VbE+Hp0BSn9uxiZdx6lJzmzWnVaLiXzIhQDvdcIdq76Gep+REcjlup
KCi1iQ6dD8cfxHVDJdPdKxcUQZfRhH59Km9unPv54jFIajo+2UkiM5kYNPz30c/J
5VivfGbYs9o=
=7QLF
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+
Follow-Ups: References: