Re: [caops-wg] [igtf-general] Re: Certificate Profile document updated (to v0.14)
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 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)
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.)
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 **
I haven't had time to get back to this for more review, but 2 things: (1) name constraints. We need to say something about this. My understanding is that most grid middleware and many if not all applications will not be able to deal with name constraints (it's a critical extension, and most software doesn't know how to interpret it, and there are continuing problems with the PKIX interpretation rules). I was also told recently both that openssl had name constraint capability now, and that it didn't work. I think what we need to say is that this extension cannot (must not) be used currently in Grid middleware. Perhaps that could be should not, since a "private" grid might be able to pick & control x.509 software that can cope with name constraints. (It's also useless, except in networks of CA's, but we probably don't need to get into that.) (2) A subscriber asks about key usage settings for client & server (this is the NS cert type extension, not the other possibility). We set both for people - in the old days in Grids, people set up one off servers with personal certs, and so it was a "requirement". We are currently recommending not to use NS types at all; does this need refining? Thanks, ==mwh
Pinging the CA-Ops group on both of the issues raised by Mike below. (Similar message on item 2 already sent to the IGTF list just now separately.) Alan On Nov 10, 2006, at 2:08 PM, Mike Helm wrote:
I haven't had time to get back to this for more review, but 2 things: (1) name constraints. We need to say something about this. My understanding is that most grid middleware and many if not all applications will not be able to deal with name constraints (it's a critical extension, and most software doesn't know how to interpret it, and there are continuing problems with the PKIX interpretation rules).
I was also told recently both that openssl had name constraint capability now, and that it didn't work.
I think what we need to say is that this extension cannot (must not) be used currently in Grid middleware. Perhaps that could be should not, since a "private" grid might be able to pick & control x.509 software that can cope with name constraints.
(It's also useless, except in networks of CA's, but we probably don't need to get into that.)
(2) A subscriber asks about key usage settings for client & server (this is the NS cert type extension, not the other possibility). We set both for people - in the old days in Grids, people set up one off servers with personal certs, and so it was a "requirement". We are currently recommending not to use NS types at all; does this need refining?
Thanks, ==mwh
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ==================================================================== Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
participants (3)
-
Alan Sill -
David Groep -
Mike Helm