Hi Mike, Kaspar, all, Thanks for the comments, I've built v0.16 out of them. [new versions on GridForge again v0.16: https://forge.gridforum.org/sf/go/doc13741 (pdf) https://forge.gridforum.org/sf/go/doc13742 (doc)] Mike Helm wrote:
I haven't had time to read the new draft but a couple comments at 2nd hand ...
Kaspar Brand writes:
recommendation. It used to be necessary to set pathlen=0 in the
I said the wrong thing here - pathlen has to be undefined, or whatever "unlimited" is in asn.1. "0" probably has to be forbidden for Grid CAs; it disables old-style Grid proxy certs (we did this ca 2002).
That sounds gine -- and I now can happily undo most of the wording in both section 2.4.1 (on CA certs) and just add a cautionary word in 3.3.1 that the pathLenConstraint MUST NOT be present, with a footnote explaining that if you do it anyway, it MUST allow for an unlimited pathlen.
that pathLenConstraint MUST be absent or set to 0. I did the same for end-entity certs, comments welcome on that!
Setting pathlen to 0 in end-entity certs actually goes explicitly against both RFC 3280 and the latest 3280bis I-D:
CAs MUST NOT include the pathLenConstraint field unless the cA boolean is asserted and the key usage extension asserts the keyCertSign bit.
In its current wording, 3.3.1 still gives the option of not including pathlen at all (which is fine), but if we really want to allow the other option (setting it to 0 for EE certs), then we should state that this contradicts a mandatory requirement of RFC 3280 (similar to 3.2.1).
Why would we want to set it for EE certs?
The IETF PKIX profile for how path length is evaluated is in 4.2.1.10 (about p 36)
This is now obsolete and removed from v0.16...
Second, two comments about authority and subject key identifiers - section 2.4.6 currently states:
2.4.6 Authority and Subject Key Identifier: A subjectKeyIdentifier extension MAY be included in CA certificates to aid in validation path construction. An authorityKeyIdentifier MAY be included in all CA certificates, except for selfsigned root certificates.
The statement about the authorityKeyIdentifier is basically fine, but the "except for selfsigned root certificate" poses a problem for a large number of existing CA certs - when looking at the IGTF distribution
Sure, ours does too. I don't understand this restriction - see the discussion in RFC 3280 4.2.1.1 - it's simply useless in the case of most self-signed CAs. RFC 3280 says "where ... [the CA has a] "self-signed" certificate, the authority key identifier MAY be omitted ....
It's useless (I think) because disambiguation is not defined at the point in the chain of certs where you have a self-signed cert.
The subject key & authority key ids should be identical in this case. (It might be useful to say, that if a self-signed CA cert presents an authority key id, it must be identical to the subject key id.)
Added text to that effect. From Kaspar's mail:
If either of these extensions is included, it SHOULD
include only the keyid attribute and no other attributes.
"keyid" should be replaced by "keyIdentifier", that's the official RFC 3280 term ("keyid" is OpenSSL specific).
Done.
Comment H12/H14: subjectKeyIdentifier and certificatePolicies MUST?? not be critical
I’ve seen no harm come from a sKI, but does all software actually parse it? I’m not sure that by making it critical we will not break things.
For the subjectKeyIdentifier, I would change this (back) to MUST NOT, RFC 3280 states "Conforming CAs MUST mark this extension non-critical".
Changed back to be compliant to RFC3280 again. Thanks! DavidG. -- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **