[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3280bis redefines HTTP
These may be valid operational issues but as such they have no valid place in a standard designed to serve for several decades.
If we prohibit signature generation for performance reasons this suggests that there might be a problem with verification as well. (It is not necessarily the case that verification is faster).
Regardless the restriction is unverifiable and hence unenforceable. The syntactic form of a URL says nothing about the resource it refers to.
I doubt that many engineers would read the spec and insert a check to reject a URI that was not formed exactly as specified:
If (not-what-I-expect) then
throw (hissy-fit)
> -----Original Message-----
> From: Alan Sill [mailto:Alan.Sill@xxxxxxx]
> Sent: Thursday, September 28, 2006 3:03 PM
> To: Hallam-Baker, Phillip
> Cc: Alan Sill; Anders Rundgren; ietf-pkix@xxxxxxx
> Subject: Re: 3280bis redefines HTTP
>
> The purpose of this is to prevent CRL's from being logical
> URIs, but instead actually to be physical entities on a disk.
> I do not know the origin of this restriction, which has
> cause a certain amount of questioning in my community
> (grids), but I can say that one does NOT want to implement
> CRLs via time-consuming mechanisms in general, and in
> particular tomcat servlets (although I am a fan of Tomcat in other
> circumstances) would be a very bad way to implement a CRL.
>
> In any substantial deployment, as hinted here, it is crucial
> to have a CRL responder that is very fast indeed. Most CRL
> servers used in academic grids already run at several hundred
> hits per second, and the rate is going up. This is driving
> research on credential validation methods that do not use
> CRLs as intensively. For now, you should NOT read the RFC as
> a mistake, but as a requirement. At minimum, to meet this
> requirement, your CRL identifier must be fully specified, i.e.,
>
> http://mycrlserver.domain.tld/crlname.ext
>
> and not
>
> http://mycrlserver.domain.tld/crlname/
>
> (Didn't invent it, not my fault, that's the spec.)
>
> Alan
>
> On Sep 28, 2006, at 12:18 PM, Hallam-Baker, Phillip wrote:
>
> > 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
> >
>
> Alan Sill
> TIGRE Senior Scientist
> High Performance Computing Center
> TTU
>
> ====================================================================
> : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 :
> : e-mail: Alan.Sill@xxxxxxx ph. 806-742-4350 fax 806-742-4358 :
> ====================================================================
>
>
>