Subject: RE: Comments on / suggested changes for RFC3280bis

From: "David Cross" <[email-masked]>
Date: Sat, 11 Jun 2005 13:27:04 -0700

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 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
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

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 A. Cooper" <[email-masked]>
Date: Wed, 15 Jun 2005 16:38:18 -0400

David,

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

Peter Hesse wrote:

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