Subject: RE: 3280bis AIA RFC2585 and RFC2797 deviations

From: Sharon Boeyen <[email-masked]>
Date: Tue, 26 Sep 2006 09:46:37 -0400

I agree with Stefan - use of AIA and use of any specific type of access
locator should be optional.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, September 26, 2006 6:38 AM
To: Anders Rundgren; [email-masked]
Subject: RE: 3280bis AIA RFC2585 and RFC2797 deviations

BM__MailEndComposeAnders,

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.

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
<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: "Anders Rundgren" <[email-masked]>
Date: Tue, 26 Sep 2006 21:39:01 +0200

MessageSharon & Stefan,
I did not write that AIA -aIssuers should be mandatory, or even be recommended.

I simply asked you to lower the bar for clients in order to improve interoperability.
Since the CA defines this property unilaterally, it is kind of critical that it is usable.

I noted that in the Logotypes RFC, HTTP is a MUST.  In what aspect are certificates files different from image files with respect to access?  IMO, not at all. 

Regarding "alien" file-extensions and MIME-types: I believe it is prudent documenting established practices rather than hoping that nobody will notice the glitches that will result by ignoring them.

Since a CA is usually server you can put higher requirements on a CA than on clients, there seems to be a reasonable compromise:
HTTP and LDAP could be RECOMMENDED for AIA-caIssuers-using CAs.  There isn't a "certificate-user" (it is a program) that can't handle at least one of these.  Often both.

http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf
"AIA extensions include both LDAP and HTTP URIs for id-ad-caIssuers access method"

That is, this is already a standard.

Anders

----- Original Message ----- 
From: Sharon Boeyen 
To: 'Stefan Santesson' ; Anders Rundgren ; [email-masked] 
Sent: Tuesday, September 26, 2006 15:46
Subject: RE: 3280bis AIA RFC2585 and RFC2797 deviations

I agree with Stefan - use of AIA and use of any specific type of access locator should be optional.  
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
  Sent: Tuesday, September 26, 2006 6:38 AM
  To: Anders Rundgren; [email-masked]
  Subject: RE: 3280bis AIA RFC2585 and RFC2797 deviations

  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

  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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 26 Sep 2006 18:04:44 -0400

At 9:39 PM +0200 9/26/06, Anders Rundgren wrote:
>Sharon & Stefan,
>I noted that in the Logotypes RFC, HTTP is a MUST.  In what aspect 
>are certificates files different from image files with respect to 
>access?  IMO, not at all. 

certs are nominally available via a wide range of ways, which are 
under the control of CAs and others who choose to operate 
repositories. The AIA and SIA extensions allow specification of 
various access methods to accommodate such diversity. The logotypes 
extension defined a new data item and Stefan, as the author, chose a 
particular method of making them accessible. Nobody argued for other 
access methods at the time this was proposed, so ...

>  Regarding "alien" file-extensions and MIME-types: I believe it is 
>prudent documenting established practices rather than hoping that 
>nobody will notice the glitches that will result by ignoring them.

An established practice that is not the product of an IETF WG can be 
documented via an informational RFC written by the folks who 
established the practice. Including comments about such practices in 
a standards track RFC obscures the distinction.

>  Since a CA is usually server you can put higher requirements on a 
>CA than on clients, there seems to be a reasonable compromise:

CAs are not servers acting as repositories. While a CA may choose to 
operate a repository for the certs and CRLs is issues, prudent 
security practice often calls for a machine signing certs to not be 
directly accessible in the same fashion as a repository.  So maybe 
what you meant to say above was that IF a CA operates a repository 
for such data, then it is likely to be a highly available machine.

>HTTP and LDAP could be RECOMMENDED for AIA-caIssuers-using CAs. 
>There isn't a "certificate-user" (it is a program) that can't handle 
>at least one of these.  Often both.
>
><http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf>http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf

This is a U.S. Government PKI profile, but that does not make it a 
global standard of the sort we develop in the IETF.

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 27 Sep 2006 20:49:30 +0200

Re: 3280bis AIA RFC2585 and RFC2797 deviationsTalking about standards, the following extract from 3280bis contains an interpretation of HTTP which is quite unique:

   Where the information is available via HTTP or FTP, accessLocation  
   MUST be a uniformResourceIdentifier and the URI MUST point to a certificate file. 
   The certificate file MUST contain either a single
   DER encoded certificate (indicated by the .cer file extension) or a
   collection of certificates (indicated by the .p7c file extension):

Outside of 3280bis, HTTP UIRs like

http://example.com/index.html
http://example.com/index.asp
http://example.com/home
http://example.com/library?id=2

work flawlessly in spite of either using a real file extension (.html), a file extension which as no meaning for a client (.asp), or  having no extensions at all.  If the underlaying object is a "file" or not is totally ireelvant.  In fact, the depencdy on file extension for HTTP URIs complicates deployment if you want to use a Servlet or similar rather than a file.  The Apache web-server requires a change in the MIME master table in order to do this.  But such a change affects static contents and is therefore highly impopular.  MIME-types represent the established way of associating HTTP objects with consuming applications.

Putting this in a typical CA context it is probably a good idea publishing certficates in an LDAP directory.  If you want to provide HTTP access as well, a trivial way would be to wrap a suitable LDAP call in a JSP page or .NET appication. Such applications do normally not use file extensions except ..jsp and aspx.  http://example.com/respository/certs.aspx?id=455 works just  fine.

Using FTP, you indeed need to bother about file-names, but FTP is another protocol, not to be confused with HTTP.  Since LDAP got its own wording, you might do the same with HTTP.

Anders

----- Original Message ----- 
From: Stephen Kent 
To: Anders Rundgren 
Cc: Sharon Boeyen ; 'Stefan Santesson' ; [email-masked] 
Sent: Wednesday, September 27, 2006 00:04
Subject: Re: 3280bis AIA RFC2585 and RFC2797 deviations

certs are nominally available via a wide range of ways, which are under the control of CAs and others who choose to operate repositories. The AIA and SIA extensions allow specification of various access methods to accommodate such diversity. The logotypes extension defined a new data item and Stefan, as the author, chose a particular method of making them accessible. Nobody argued for other access methods at the time this was proposed, so ...

An established practice that is not the product of an IETF WG can be documented via an informational RFC written by the folks who established the practice. Including comments about such practices in a standards track RFC obscures the distinction.

CAs are not servers acting as repositories. While a CA may choose to operate a repository for the certs and CRLs is issues, prudent security practice often calls for a machine signing certs to not be directly accessible in the same fashion as a repository.  So maybe what you meant to say above was that IF a CA operates a repository for such data, then it is likely to be a highly available machine.

This is a U.S. Government PKI profile, but that does not make it a global standard of the sort we develop in the IETF.

Steve