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