[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Certs draft
-----BEGIN PGP SIGNED MESSAGE-----
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
N2).
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
reading...
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
it.
Whew! Tomorrow, I'll try to get to the other two drafts...
Marc
+------------------------------------------------------------------------+
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
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNIS6elrdFXNdDxPlAQEB3QL/fA5E0PGPRz2KKGt9LTItJvfcRow44F03
RmTxmsoqT/Z0ouxxLLlwONZOXmCXeH5su4X6U9js0kVjdIrKvnWjAgQQS/PLKarQ
8nnLYm0pqzILimaLPrjnokp6BFjt4SpC
=2CVC
-----END PGP SIGNATURE-----