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

Lasr RFC dratf comments

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.


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. 


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.

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

IANA (page 15):

What is it? some useful pointers ?.

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

<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>
")"; ).
The version field is not optional here -> <crl> , <delta-crl> <reval>,
why?
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>.


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

Xavier Serret Avila.


-- 
----------------------------------------------------------------
                     Xavier Serret Avila

              Universite Catholique de Louvain
	      Laboratoire de Telecommunications
	      Batiment Stevin
	      2, Place du Levant
	      B-1348 - Louvain La Neuve
                               
mailto:serret@tele.ucl.ac.be          Tel.: +32 - (0)10 - 478072
                                      Fax : +32 - (0)10 - 472089
----------------------------------------------------------------
Follow-Ups: