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

Mike Helm helm at fionn.es.net
Thu Nov 2 09:50:19 CST 2006


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.)



More information about the caops-wg mailing list