[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on / suggested changes for RFC3280bis


Peter,
Thanks for the comments. Below are some responses to your comments. I've skipped over most of the editorial comments for the moment, but I will make any appropriate changes in the document. 

Peter Hesse wrote:


A real-world example of the unclear language related to behavior causing a
problem: RFC3280 specified that the inhibitAnyPolicy extension be marked
critical.  At least one version of the Sun Java CertPath implementation
rejects any certification paths containing inhibitAnyPolicy extensions which
are not marked critical.  The wording in RFC3280 was not clear that this was
a requirement for issuers and not for implementations.  (This issue has been
fixed the current RFC3280bis draft, but remains in other places for other
extensions.)
This is definitely something that will need to be addressed in 3280bis. At first I thought it would be sufficient to change statements of the form "this extension MUST be marked critical" to "conforming CAs MUST mark this extension as critical". But Sam Roberts suggested that 3280bis needs a more explicit statement that relying parties should not be checking certificates to verify that they were issued in conformance with 3280bis. As Peter Guttman noted in a recent message (http://www.imc.org/ietf-pkix/mail-archive/msg02333.html), even statements of the form "conforming CAs MUST" can sometimes be interpreted as imposing a requirement on relying parties. 


Location: 4.2.1.11, 4th para, last sentence
Original Text: "If the policyConstraints extension is marked critical and
the inhibitPolicyMapping field is present, applications that do not
implement support for the inhibitPolicyMapping field MUST reject the
certificate."
Comment: This seems to be encouraging different behavior depending on the
criticality of the field, which goes against the spirit of extension
processing.
I don't understand the concern here. This statement is entirely consistent with the general rule for processing the criticality bit (from section 4.2): 

A certificate using system MUST reject the certificate if it encounters
a critical extension it does not recognize or a critical extension
that contains information that it can not process.

It was only stated here explicitly since section 4.2.1.11 also says:

Conforming applications MUST be able to process the
requireExplicitPolicy field and SHOULD be able to process the
inhibitPolicyMapping field.
We wanted it to be clear that even though the ability to process the inhibitPolicyMapping field was not required, the general rule that one must still reject a certificate with a critical extension containing information that the application cannot process still applies. 


Location: 4.2.1.13, 5th para, last sentence
Original Text: "DistributionPointName SHOULD include at least one LDAP or
HTTP URI."
Recommendation: Add the following sentence. "If both HTTP and LDAP
DistributionPointName URI values are specified, the HTTP
DistributionPointName SHOULD appear first."
Reason: Firewalls are more likely to allow HTTP through, and HTTP typically
results in faster access.  Applications typically try distribution points in
the order in which they appear.
The design team thought that it specifying an ordering was too prescriptive. In general it is probably a good idea to list the distribution points in order of preference, but it may not always be possible to control the order in which the distribution points are encoded. Even if 3280bis did say something about ordering, I think it should only note that they should be listed in order of preference without declaring an opinion that one protocol is inherently better than another. 


Location: 4.2.2.1, 13th para, 2nd sentence
Original Text: "...and MAY specify a host name (e.g.,
ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?cACertificate;bina
ry,crossCertificatePair;binary).
Recommendation: remove ",crossCertificatePair;binary" from the example
Reason: Attributes containing cross-certificate pairs should not be
recommended.  There is no way for the client to know whether or not they
will be encountering cross-certificate pairs as opposed to certificates,
without attempting to decode them and failing.  Retrieving only
cACertificate attribute should be sufficient if LDAPv3 schema is being
followed.
First, I don't understand why you say that "[t]here is no way for the client to know whether or not they will be encountering cross-certificate pairs as opposed to certificates, without attempting to decode them and failing." If its stored in the cACertificate or userCertificate attribute, it is a certificate. If its stored in the crossCertificatePair attribute its a cross-certificate pair (it may be that either the forward or reverse element is absent, but it is still encoded as a certificate pair).
I am also not aware of any schema that would make the contents of the crossCertificatePair attribute unnecessary. The current text in X.509 states: 

Clause 11.2.2:
The cACertificate attribute of a CA's directory entry shall be used to store
self-issued certificates (if any) and certificates issued to this CA by CAs in the same realm as this CA. In the case of v3 certificates, these certificates 
shall include a basicConstraints extension with the cA value set to TRUE.
The definition of realm is purely a matter of local policy.

Clause 11.2.3:
The issuedToThisCA elements of the crossCertificatePair attribute of a CA's
directory entry shall be used to store all, except self-issued certificates issued to this CA. Optionally, the issuedByThisCA elements of the crossCertificatePair attribute, of a CA's directory entry may contain a subset of certificates issued 
by this CA to other CAs. If a CA issues a certificate to another CA, and the
subject CA is not a subordinate to the issuer CA in a hierarchy, then the issuer 
CA shall place that certificate in the issuedByThisCA element of the
crossCertificatePair attribute of its own directory entry.
The requirements for cACertificate are the same as in RFC 2587. draft-zeilenga-ldap-x509-01.txt simply refers to clause 11.2.2 in X.509. All of these documents state the same thing: certificates issued to this CA by CAs in a different "realm" do not need to be included in the cACertificate attribute, but must be included in the crossCertificatePair attribute. I am not aware of any schemas that require all certificates issued to the CA to be included in the cACertificate attribute. 


Location: 4.2.2.1, 16th para
Original Text: " .p7c   A DER encoded "certs-only" CMS message as specified
in [RFC 2797]."
Recommendation: " .p7c   A DER encoded "certs-only" CMS message as specified
in [RFC 2797] which MUST NOT contain self-signed certificates."
Reason: Self-signed certificates retrieved externally should not be included
because they cannot be trusted,
I agree that self-signed certificates should not be included in the directory. Self-signed certificates should only be used as a source of trust anchor information and should be obtained by secure, out-of-band means for this purpose. Including unnecessary certificates in the directory only complicates matters. I think they should be excluded from the cACertificate attribute of the directory as well the Web server. It is, however, very common practice to include self-signed certificates in the directory.
I would be in favor of stating that self-signed certificates SHOULD NOT be included in the directory or in the information pointed to by the AIA extension, but given that this is such common practice, I would need sufficient evidence of working group consensus before making any changes to the current text. 


Location: 4.2.2.1, 18th para
Original Text: "The semantics of other id-ad-caIssuers accessLocation name
forms are not defined."
Recommendation: Add a new paragraph before this one: "If both HTTP and LDAP
accessLocations are specified, the HTTP accessLocation SHOULD appear first."
Reason: Same as above (4.2.1.13, 5th para, last sentence).
I am actually aware of some implementations that can process an LDAP URI in the AIA extension but not an HTTP URI (and vice versa), which I think is yet another reason that 3280bis should not declare that one protocol is inherently superior to another. 


Location: 4.2.2.2, 9th para, 2nd sentence
Original Text: "...and MAY specify a host name (e.g.,
ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?cACertificate;bina
ry,crossCertificatePair;binary).
Recommendation: remove ",crossCertificatePair;binary" from the example
Reason: Same as above (4.2.2.1, 13th para, 2nd sentence).
See text from clauses 11.2.2 and 11.2.3 from X.509 above. The cACertificate attribute only includes the self-issued certificates issued by the CA. Only the crossCertificatePair attribute contains the cross-certificates issued by the CA. So, the crossCertificatePair attribute is even more important in the SIA extension than in the AIA extension. 


Dave