[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-pkix-certpathbuild-00.txt
Comments on certpathbuild-00.txt
The title of the document was promising, but the content is not exactly what
would have been expected.
The topic should be how to allow interoperability to find out the elements
(i.e. both the certificates and the associated revocation status
information) needed for to build a certification path either walking
downwards or upwards the certification tree.
The document should explain how inserting some of the extensions defined in
RFC 3280 will allow to build the certification path, irrespective of local
conditions (e.g. the user does not have a XX-xxxxxxDirectory where
everything needed is stored. :-) )
Some interesting elements are provided starting page 54, in sections 6.2 and
6.3. but this is far from sufficient.
There are two solutions to this problem, either walking downwards or upwards
the certification tree.
A. Walking downwards the certification tree.
Each trust point SHOULD include in the self-signed certificate the way to
find out where the CA has placed the CA certificates that it issues. This
SHALL be done using the Subject Information Access extension defined in
section 4.2.2.2 from RFC 3280.
The id-ad-caRepository OID SHALL be used to indicate in which repository the
CA publishes its certificates and CRLs (if issued).
Each CA certificate SHOULD also include the Subject Information Access
extension defined in section 4.2.2.2. from RFC 3280.
This is the preferred method, since anyway trust points MUST be known.
B. Walking upwards the certification tree.
Each end-entity certificate and each CA certificate SHOULD include the way
to find out where the CA is placing the other certificates. This SHALL be
done using the Authority Information Access extension defined in section
4.2.2.1 from RFC 3280 :
The id-ad-caIssuers OID SHALL be used to list where the CA that has issued
the certificate lists CA certificates issued to the CA.
This extension SHOULD be included in end-entity certificates and CA
certificates.
This can only be a complement to the previous method, since anyway trust
points MUST be known. When the downwards approach does not succeed (explain
in which cases, it may not succeed), then a combination of both methods may
succeed.
Note: The location of CRLs is not specified in this extension. That
information is provided by the cRLDistributionPoints extension.
C. Revocation checking
For revocation checking each end-entity and CA certificate SHALL either
include :
a) a cRLDistributionPoints extension, or
b) Subject Information access extension that includes the id-ad-ocsp OID
to indicate the location of servers using the Online Certificate
Status Protocol (OCSP) [RFC 2560].
Other comments.
1. The difference between a CA-certificate and a cross-certificate is still
very hazy since what means a "realm" is either left undefined or is said to
be "dependant upon local policy". It is thus impossible to have standard
rules with such an approach.
Introducing naming constraints between subject and issuer names might be
more appropriate; however, the real question is the following:
Is it really important to make the difference if both:
- the pointers to CA repositories are present, and
- these repositories entries are correctly filled-in ?
2. There is, as usual, some confusion between cross certification (which is,
by definition, unilateral) and mutual cross certification (see section
13.2). Figure 3 does not make sense unless the trust points are indicated.
3. The case of validating a certificate in the past after a CA key rollover
(using the new root key) should be addressed.
4. An interesting case to discuss would be the encoding of the issuer name
before and after December 31, 2003 since all certificates issued after
December 31, 2003 MUST use the UTF8String encoding of DirectoryString
(except as noted). The case of "name rollover" certificates to support an
orderly migration to UTF8String encoding should be explained .
5. The document is far too long.
Denis