RE: 3280bis redefines HTTP

There is a minor problem here and a significant error.

The minor problem is the use of the term 'file' in place of 'resource'. Since a file is merely an abstraction for a bag of bits this does not worry me very much. Some people assume that file must mean a resource stored on disk. It worried some people in the context of http and they started using the term resource.

The more troubling issue is the use of the file extension rather than the mime content type. This is likely to cause problems in quite a few deployments. It is clearly an error, it might be a mistake.

On the wording for logotypes I would be happier with stating that there SHOULD be an HTTP uri and that FTP and LDAP SHOULD NOT be used. Mandating HTTP is likely to be a problem down the road when we have something better. Its not a major concern unless someone thought it was OK to write code that would actually break if it saw a non HTTP URI.

Prohibiting LDAP and FTP does make good sense, they are both less efficient than HTTP. FTP is much less efficient and less reliable through NAT.

From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Anders Rundgren
Sent: Wednesday, September 27, 2006 2:50 PM
To: ietf-pkix@xxxxxxx
Subject: 3280bis redefines HTTP

Talking 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' ; ietf-pkix@xxxxxxx

Sent: Wednesday, September 27, 2006 00:04

Subject: Re: 3280bis AIA RFC2585 and RFC2797 deviations

At 9:39 PM +0200 9/26/06, Anders Rundgren wrote:

Sharon & 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.

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

"AIA extensions include both LDAP and HTTP URIs for id-ad-caIssuers access method"

That is, this is already a standard.

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