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

Certs draft


Finally found some time to read the latest drafts.  Here are some
thoughts/comments on Simple Public Key Certificates.

2.3 Name:  In the paragraph
   Letting "->" stand for a name definition, if we have (K1 N1) -> K2
   and (K1 N1) -> K3, then (K1 N1 N2) -> (K2 N2) and (K1 N1 N2) -> (K3
I think the numbering of the K's and N's should be different, but I'm not
sure how.  Either that, or I really don't understand the example and could
use some explanation...

2.4 Certificate:  It might be a bit clearer to modify the definition of
the ISSUER field to mention how name certs work:
   The ISSUER generates and signs the certificate.  Name certificates
   employ a special kind of issuer.

2.10 Validity conditions, One-time revalidation: It's not clear that it's
the verifier's responsibility to discard one-time revaldiation replies
once their used.  This is pretty important, so we should make it clear.
Something like:
   The verifier MUST discard one-time revalidation replies after using
   them in the current trust evaluation.  One-time revalidation replies
   MUST NOT be cached nor persist once the trust evaluation is completed.

3.2 <byte-string>: The definition of <display-type> means that the
length:bytes notation applies to types too, such as [10:text/plain]
(rather than the usual [text/plain] normally seen in MIME types).  Some
examples that include a display-type would make this clearer.

3.8.[123] :  What is the <uri> parameter for?

3.8.4 <signature>:  <principal> isn't formally defined until 4.3, and
<sig-val> isn't until 8.2 (the BNF appendix).  Makes for confusing

3.8.5 <acl>:  We should define an <acl> <signature> sequence to allow for
self-signed ACLs, providing the "protected memory" the draft refers to.
This lets everyone know just what we mean by such protected memory.

4. Authorization Certificate:  Are optional fields are included in the
signature of the cert?  If so, what is to prevent a processing engine from
omitting or adding an optional part when it parses and reassmebles a cert?

4.1 <version>:  Why (version V0)?  Why not just (version 0), which is a
bit easier to verify computationally and ensures that we don't have v0/V0
problems?  Also, as the objects evolve they will all need to include a
<version>, since the default is 0.  This means that <version> will become
an implied required field, so why not make it required for everything
right away?  Conversely, note that <version> is required for <crl>,
<delta-crl> and <reval> but is optional for everything else.

4.3 <issuer>: <hash-of-key> is only defined in the BNF appendix.

4.5.1 <name>:  "... recursing until the subject reduces to a key."
Shouldn't this be "... recursing until the subject reduces to a principal
or group of principals."?  Well, maybe not "group of principals" but "key"
is too restrictive -- what about <hash-of-key>?  Besides, it seems to be
different than what is said in 5.2 (Name reduction).

4.5.2 <obj-hash>:  Given the hash of an object, how does the verifier know
which object it's referring to?  Say it's a program.  Is the prover
(presumably the program itself) supposed to send the verifier a hash of
its own code?  Somehow I don't think that this is what <obj-hash> is
supposed to be used for, but its purpose isn't made clear in the draft.

4.5.4 <keyholder>:  I think it'd be useful to allow a keyholder to be
specified by a <name> as well as a <principal>.  This would allow certs
that apply to flesh-or-silicon things to also take advantage of delayed
binding, etc.

4.5.5 <subj-thresh>:  The discussion here about branching at the Subject
states that "a cert is signed by a single Issuer."  This seems to
contradict 3.8.4 which says "there may be cases when the same cert body
needs to be signed by multiple keys."  Multiple keys = multiple
principals = multiple issuers, no?  This gets back to the definition of
<issuer>, which only allows for a single principal.  But then, what's the
point of having a cert body signed by multiple keys?

5.1 Name cert syntax: <valid> and <comment> are not optional.

5.2 Name reduction:  The -> operation is confusingly different than what
it was in 2.3.

7.7 CRCs:  Something that reduced to the form (Self,X,D,A,V), where V is
"now" (i.e. the result of a one-time revalidation), should never be made
into a CRC and should never be passed back to the caller.  It would be
interesting, though, to preserve one-time revalidation parameters as they
are reduced.  That is, we would end up with a V that included a validity
range and a number of one-time revalidation tests, and "now" would never
actually be encountered in the reduction process.  Instead, the one-time
revalidation tests would be performed after reduction.  This would require
a slightly different syntax for <valid> -- something like <online-test>*
instead of <online-test>? -- and some tweaking of the reduction algorithm,
but I don't think it's infeasible.  This would allow us to avoid doing
full-chain reduction every time something had a one-time revalidation in

Whew!  Tomorrow, I'll try to get to the other two drafts...


 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 marcnarc@xcert.com        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Version: 2.6.2