Re: PKIX Part 2 - Revised Draft

[Peter Williams <peter@xxxxxxxxxxxx>]

Sharon,

In regard to the edits made to section 3:

"3. Hypertext Transfer Protocol and File Transfer Protocol

Some CAs mandate the use of on-line validation services, while
others distribute CRLs to allow certificate users to perform
certificate validation themselves.  In general, CAs make CRLs
available to certificate users by posting them in the Directory.
The Directory is also the normal distribution mechanism for
certificates.  However, Directory Services are not available in
many parts of the Internet today. The Hypertext Transfer Protocol
(HTTP) defined in RFC 2068 and the File Transfer Protocol (FTP)
defined in RFC 959,  offer alternate methods for certificate and
CRL distribution.

Within certificate extensions and CRL extensions, URI form of
GeneralName is used to specify the location where issuer
certificates and CRL may be obtained.  For instance, a URI
identifying the subject of a certificate may be carried in
subjectAltName certificate extension. An IA5String describes the
use of anonymous, or authenticated HTTP or FTP to fetch certificate
or CRL information.
For example:

   http://www.netcom.com/sp/spyrus/housley.cer
   http://www.your.org/pki/id48.cer
   http://www.your.org/pki/id48.no42.crl
   ftp://ftp.netcom.com/sp/spyrus/housley.cer
   ftp://ftp.your.org/pki/id48.cer
   ftp://ftp.your.org/pki/id48.no42.crl

Internet users may publish the URI reference to a file that
contains their certificate on their business card.  This practice
is useful when there is no Directory entry for that user. HTTP and
FTP are widely deployed, and anonymous HTTP and FTP are
accommodated by many firewalls.  Thus, HTTP and FTP are attractive


alternatives to Directory access protocols for certificate and CRL
distribution.

In the case of FTP, for convenience, the names of files that
contain certificates should have a suffix of ".cer".  Each .cer
file contains exactly one certificate, encoded in DER format.
Likewise, the names of files that contain CRLs should have a suffix
of ".crl". Each .crl file contains exactly one CRL, encoded in DER
format.

**(Note - still outstanding for the HTTP case is the definition of
specific content type label (mime type) with content in specific
syntax.)"

I would like to comment on the last paragraph. I suggest the
following language:-

"In the case of HTTP, for convenience, the HTTP-response should
provide a MIME application/octet-string header when serving
file resources. The MIME type descriptor shall be accompanied
by a mandatory "name" parameter whose value is the name of the
retrieved file, with ".cer" or ".crl" suffix.

Should the HTTP URI refer to a non file resource which is
conventionally denoted by a particular MIME type (e.g. a PKCS7
certs-only
object used in popular SSL-capable browsers is
often denoted by "application/x-pkcs7-user-cert") then
the customary MIME headers for that resource shall be returned in
the HTTP-response in place of  application/octet-string. (see
Appendix A for  examples)"

Id like to suggest this is a short, minimalist  summary of existing
submissions
made by others to the list. One can tweak my language at will, of
course.

The specification is compatible with ftp URIs, where required, enables
current
practice for S/MIME and SSL browsers/servers, and is flexible to allow
new
MIME types to be defined if needed to extend the http mechanism for
new varieties of simple URI-based lookup over time, without need
for PKIX-2 change..

(http://digitalid.verisign.com/query.htm is an example provision of the
basic validity of this http approach for a variety
of commercial download formats, including the CRL file-centric approach,
if
we are in doubt of its implementability. Downgrading this
*interactive-query*
service to the URI *lookup* model intended by section 3 for use
in address books or vcard attachements is, of course, a simple task)

I think given the evidence, such a flexible http service will be highly
valued
by many products using the simpler, but wholly functional, end of the
PKIX
infrastructure.

Peter.