Subject: RE: 3280bis redefines HTTP

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 28 Sep 2006 10:18:55 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Anders Rundgren
	Sent: Wednesday, September 27, 2006 2:50 PM
	To: [email-masked]
	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 <mailto:[email-masked]>  
	To: Anders Rundgren <mailto:[email-masked]>  
	Cc: Sharon Boeyen <mailto:[email-masked]>  ; 'Stefan Santesson' <mailto:[email-masked]>  ; [email-masked] 
	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 <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

---

From: Alan Sill <[email-masked]>
Date: Thu, 28 Sep 2006 14:03:14 -0500

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:

> 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: [email-masked] [mailto:owner-ietf- 
> [email-masked]] On Behalf Of Anders Rundgren
> Talking about standards, the following extract from 3280bis  
> contains an interpretation of HTTP which is quite unique:
>
>
> 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
>
>
> From: Stephen Kent
> To: Anders Rundgren
> Cc: Sharon Boeyen ; 'Stefan Santesson' ; [email-masked]
>> 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
> 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: [email-masked]   ph. 806-742-4350  fax 806-742-4358  :
====================================================================