Subject: Re: Comments on / suggested changes for RFC3280bis

From: "David A. Cooper" <[email-masked]>
Date: Fri, 10 Jun 2005 14:25:06 -0400

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

---

From: "Dave Engberg" <[email-masked]>
Date: Fri, 10 Jun 2005 15:35:27 -0400

Everyone would agree that a self-signed cert in an LDAP or HTTP server
should not be trusted just because it is discoverable.  True trust anchors
(i.e. a name and a public key) should be securely distributed out of band.

However, I think that the almost-universal convention of publishing
self-signed roots into public servers can be very useful for annotation
purposes.  I.e. I'm not stuck holding an intermediate CA cert with no
pointers to let me know where that cert thinks it came from.  Yes, the
published self-signed cert has no value from an automated-trust-RFC-3280
standpoint.  But it can give me more information about a "foreign" PKI
heirarchy.  I personally have used this feature to (manually) sort out some
funky PKIs on more than one occasion, and would not like to see it banned
for the sake of academic purity.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Friday, June 10, 2005 2:25 PM

...

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.

...

---

From: "David Cross" <[email-masked]>
Date: Wed, 15 Jun 2005 20:19:11 -0700

I agree.

Thanks for clarifying based on the missing context.

David B. Cross 

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Wednesday, June 15, 2005 1:38 PM
To: David Cross
Cc: [email-masked]
Subject: Re: Comments on / suggested changes for RFC3280bis

David,

I think that some of the original context for this issue may have been 
lost.  This discussion began with the following comment:

>because they cannot be trusted,

I agree that a secure directory can be used to securely distribute 
configuration information, including lists of trust anchors, within an 
enterprise.  However, I believe that this should separated from the 
distribution of CA certificate information for path discovery purposes.

So, the original question was only dealing with the inclusion of 
self-signed certificates in a "certs-only" CMS message that is pointed 
to by an authorityInfoAccess extension in a certificate or in the 
cACertificate attribute of a CA's directory entry.  I don't see a 
compelling reason to include self-signed certificates in these 
locations.  If self-signed certificates are included in the directory 
for the purpose that you mention, I believe that should be somewhere 
else in the directory.

Dave

David Cross wrote:

>I think this is an implementation detail.  There are security
considerations
>in trusting a self-signed cert based on a location in a directory, but
it
>CAN be implemented securely and be a valid implementation method for
>distributing trust information.  Enterprises for example cannot
possibly
>have every user install every trusted root on every machine as an OOB
>process.  
>
>
>David B. Cross 
>
>
>
>Behalf Of Dave Engberg
>Sent: Friday, June 10, 2005 12:35 PM
>To: David A. Cooper
>Cc: [email-masked]
>Subject: RE: Comments on / suggested changes for RFC3280bis
>
> 
>
be

---

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 16 Jun 2005 13:37:37 +0100

>locations.  

I see two reasons to allow to include them, in particular when 
the validation policy includes more than one trust anchor :

a) a verifier can know which trust anchor [as defined by the self-signed 
   certificate] should be tried first,

b) if the verifier only knows the hash values of the self-signed certificates, 
    then it can verify whether the self-signed certificates that is included 
    in the message matches one of the hash values [for the self-signed 
   certificates] that are in the validation policy. 

The major benefit in the second case would be to have shorter descriptions 
for validation policies.

As long as we say what to do with a self-signed certificate that would be present, 
then there is no problem.

Denis

> If self-signed certificates are included in the directory 

>David Cross wrote:
>
>>I think this is an implementation detail.  There are security considerations
>>in trusting a self-signed cert based on a location in a directory, but it
>>distributing trust information.  Enterprises for example cannot possibly

Regards,

Denis Pinkas

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 16 Jun 2005 14:40:26 +0100

I must admit that I don't really see the rationale to disallow self
signed certificates in a p7c file.

To me, trust decisions are separate from discovery issues.

P7c file is only specified for http or ftp access so this should not
have anything to do with directory issues.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 16 juni 2005 14:38
> To: David A. Cooper; David Cross
> Cc: [email-masked]
> Subject: Re: Re: Comments on / suggested changes for RFC3280bis
> 
> 
> 
> >David,
> 
> As long as we say what to do with a self-signed certificate that would
be
> present,
possibly
> >>From: [email-masked]
[mailto:[email-masked]]
> On
> >>heirarchy.  I personally have used this feature to (manually) sort
out
> some
> >>From: [email-masked]
[mailto:[email-masked]]
> On
> to

---

From: "Terwilliger, Ann" <[email-masked]>
Date: Thu, 16 Jun 2005 09:05:00 -0700

I would agree with Stefan.  We routinely include the self-signed
certificate (root) in our p7c files with the proviso that the relying
party verify the root in the p7c with the root received from a trusted
source as the last step in the chain validation. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Thursday, June 16, 2005 6:40 AM
To: Denis Pinkas; David A. Cooper; David Cross
Cc: [email-masked]
Subject: RE: Re: Comments on / suggested changes for RFC3280bis

Stefan Santesson

> I see two reasons to allow to include them, in particular when the 
> validation policy includes more than one trust anchor :
> 
be
> > If self-signed certificates are included in the directory for the 
> >purpose that you mention, I believe that should be somewhere else in 
> >the directory.
> 
> >Dave
> 
> >David Cross wrote:
> >

possibly
out