Subject: 3280bis AIA RFC2585 and RFC2797 deviations

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 25 Sep 2006 20:53:02 +0200

Apparently 3280bis is in last call.  That is a little bit sad given the following by accident found facts:

3280bis says that AIA caIssuers SHOULD use the mime-type application/pkix-cert for HTTP.

A quick check reveals that .cer is currently mapped to application/x-x509-ca-cert in Microsoft and Apache Tomcat web-servers. 

The file extension .p7c is at least not defined in Apache Tomcat's web.xml while p7b is.
Export in Internet Explorer also mentions p7b.

Tomcat defines p7b as application/x-pkcs7-certificates rather than 3280bis' application/pkcs7-mime

Conclusion: 3280bis has limited compliance to the current and since long time established conventions for file-extensions and mime-types for certificates.

That http://www.ietf.org/rfc/rfc2459.txt said nothing about these things is some kind of historic explanation.  That 2585 and 2797 were sort of "forgotten" is due to the fact the current reference system does not support retroactive changes.  I think that the work recently done for character encodings may go the same way unless we come up with a better way of linking new things back to older stuff.

To not screw up things more than necessary I propose the inclusion of the existing and since 2459 established practices.  This may be described as "legacy" if that feels better :-)

And now back to the access method discussion again...
PKI is (should be at least), a part of the IT landscape.  The last 6-7 years, the rest of the IT world ceased requiring that everything should be supported by every Internet protocol there is.
Subsequently there are no FTP, LDAP, or SMTP bindings for Web Services, only HTTP.

That does not mean that I think you should remove the other protocols but you could indeed specify a SHOULD or MUST for at least one HTTP AIA caIssuers, for PKIs that target the Internet and rely on COTS software (if AIA caIssues is used at all).  For the PKIs that only target a "community" and where all software is designed from scratch, it seems perfectly OK to use DAP.  To my knowledge none of the common PKI-using client software packages has any problems with http while the support for other protocols is more uncertain.  There are hardly any quality issues here, it is only about interoperability.

Sincerely
Anders Rundgren

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 26 Sep 2006 11:37:38 +0100

Anders,

On the p7c / p7b issue.

.p7c  is defined by the S/MIME message specification RFC 3851 and is the
standard file extension. P7b is a Microsoft invented file extension for
local storage.

The only reason why p7b was created was to enable p7b and p7c files to
be associated with different applications. If you open a p7c file, the
management console MMC is launched, while if you open a p7b file the
certificate viewer is launched. Both files contain the same information.

For files referenced through AIA p7c is the only standardized
alternative and hence p7c should be used. We had this discussion early
in the process of RFC 3280bis

Secondly, AIA is an optional resource for certificate discovery, the
different types of access locators reflects the CA's infrastructure. To
demand http is the same as demanding an infrastructure that provides
http access. I'm not comfortable with making such infrastructure
requirements since AIA to begin with is completely optional.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anders Rundgren
Sent: den 25 september 2006 20:53
To: [email-masked]
Subject: 3280bis AIA RFC2585 and RFC2797 deviations

Apparently 3280bis is in last call.  That is a little bit sad given the
following by accident found facts:

3280bis says that AIA caIssuers SHOULD use the mime-type
application/pkix-cert for HTTP.

A quick check reveals that .cer is currently mapped to
application/x-x509-ca-cert in Microsoft and Apache Tomcat web-servers. 

The file extension .p7c is at least not defined in Apache Tomcat's
web.xml while p7b is.

Tomcat defines p7b as application/x-pkcs7-certificates rather than
3280bis' application/pkcs7-mime

Conclusion: 3280bis has limited compliance to the current and since long
time established conventions for file-extensions and mime-types for
certificates.

That http://www.ietf.org/rfc/rfc2459.txt said nothing about these things
is some kind of historic explanation.  That 2585 and 2797 were sort of
"forgotten" is due to the fact the current reference system does not
support retroactive changes.  I think that the work recently done for
character encodings may go the same way unless we come up with a better
way of linking new things back to older stuff.

To not screw up things more than necessary I propose the inclusion of
the existing and since 2459 established practices.  This may be
described as "legacy" if that feels better :-)

PKI is (should be at least), a part of the IT landscape.  The last 6-7
years, the rest of the IT world ceased requiring that everything should
be supported by every Internet protocol there is.

Subsequently there are no FTP, LDAP, or SMTP bindings for Web Services,
only HTTP.

That does not mean that I think you should remove the other protocols
but you could indeed specify a SHOULD or MUST for at least one HTTP AIA
caIssuers, for PKIs that target the Internet and rely on COTS software
(if AIA caIssues is used at all).  For the PKIs that only target a
"community" and where all software is designed from scratch, it seems
perfectly OK to use DAP.  To my knowledge none of the common PKI-using
client software packages has any problems with http while the support
for other protocols is more uncertain.  There are hardly any quality
issues here, it is only about interoperability.

Sincerely

Anders Rundgren