[caops-wg] [igtf-general] Re: Certificate Profile document updated (to v0.14)

[David Groep]

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 **