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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Dave Engberg Sent: Friday, June 10, 2005 12:35 PM To: David A. Cooper Cc: ietf-pkix@xxxxxxx 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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] 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. ...
Attachment:
smime.p7s
Description: S/MIME cryptographic signature