Subject: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt

From: [email-masked]
Date: Mon, 07 Jan 2002 09:08:07 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Operational  
                          Protocols: Certificate Store Access via HTTP
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-pkix-certstore-http-01.txt
	Pages		: 
	Date		: 04-Jan-02
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories (although RFC 2585 covers fetching certificates via HTTP, this merely mentions that certificates may be fetched from a static URL, which doesn't provide a general-purpose interface to a certificate store). Additional mechanisms addressing PKIX operational requirements are specified in separate documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-certstore-http-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-certstore-http-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Russel F Weiser <[email-masked]>
Date: Mon, 07 Jan 2002 12:16:33 -0700

Peter, 
Several comments regarding your new draft. 

1. Within the section 2.2 examples the difference from the fetch of the
CA certificate 
and the fetch of the CRL is only the URI base. You might want to note
this difference
in the examples just to clarify. 

2. The latest son of 2459 specifies a SubjectInfoAccess SIA which would 
be another approperiate certificate extension for also encoding the
Certificate 
retrieval URI as discussed in 2.2 . I believe that going forward this
should be
the primarily used to access the certificats. 

3. I don't understand why the CRLDP extension could not be leveraged to
support
URI based queries you discribe in your draft? To me this seems like the
logical location 
to place the CRL query uri.  

It would seem that use the AIA Extension to get the Authority
certificate, SIA 
extension to get the subject extension and then use CRLDP to get the
CRLS would be the
best overall approach. 

If the certificate doesn't populate the SIA then the Client should
utilize the AIA extension to 
query for the Subjects certificate. I still believe the CRLDP should be
used for CRL retrieval. 
Unless you are also thinking of additionally supporting the concept of
allowing queries for a CRL form a particular CA with an added parameter
of asofDATE/TIME which could be a useful way of 
obtaining archived CRLs for use in attempting to valid signed data etc..

cheers
RFW

---

From: Michael Ströder <[email-masked]>
Date: Tue, 08 Jan 2002 13:19:29 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-01.txt

I have some problems with section 2.1:

Maybe it's me (I'm not a native english speaker) but I read it like
all search values have to be hashed and base64-encoded except
subjectKeyIdentifier. How about e.g. search attribute email? To
avoid misinterpretation I'd prefer having a table which states
exactly how to treat each search attribute on the client side if
necessary before submitting the query. Or at least starting section
2.1 with "The fields [complete binary attribute list]...are of"
instead of "Some of the fields...are of".

IMHO for a low-tech use-case with wide-spread acceptance ;-) it
should be possible to create a simple HTML form with the <form>'s
attribute action= pointing to the URL of the "HTTP Certificate Store
Interface". For this simple scenario pre-processing (hashing) of
search values at the client side is unfeasible (except when using
Javascript or similar beasty things).

I'd also suggest that it should be possible to pass a subject DN in
RFC2253 string representation as (x-www-form-urlencoded) search
value. Maybe your could provide a separate search attribute
rfc2253Name? Even though the length is theoretically unlimited the
usual string length of DNs shouldn't be an issue with today's web
servers. E.g. for security reasons I'm limiting string repr. of DNs
to 1024 bytes in web2ldap and - guess what - never hit the limit. As
long as you don't impose a hard limit in the draft there shouldn't
be a problem with it.

Now off course the really interesting part is "3. Locating HTTP
Certificate Stores":

IMHO locating a cert store in the Internet falls into two different
steps:
1. Locating a server name or IP address *and* port of a cert store
2. Some well-defined addressing rules once the IP address is known

One should not mix these two levels.

The rules in section 3.2 for forming the URIs more or less
sufficiently addresses 2. by defining the well-known PATH_INFO
/search.cgi but fall short for 1.

Your example already shows the problem:
--------------- snip ---------------
  certificates.<domain_name>/search.cgi
  crls.<domain_name>/search.cgi

Service providers SHOULD use these URIs in preference to other
alternatives.
For example if a CA with the domain kiwisign.com were to make its
certificates
available via an HTTP certificate store interface, the "well-known"
query URIs
for certificates and CRLs would be:

  certificates.kiwisign.com/search.cgi
  crls.kiwisign.com/search.cgi"
--------------- snip ---------------

Now what's our use-case here? Most times a user has an e-mail
address of a recipient and wants to obtain the matching certificate
for the recipient's e-mail address. The sender does not know the
issuer of the certificate in advance => the <domain_name> in the
example above is unknown.

Or maybe I misunderstood something? Maybe it's not clear enough what
the term "service provider" means in this context. And that's
exactly the same case where LDAP-based cert stores fall short today.

My suggestion would be to run certificate stores holding e-mail
certs associated to e-mail domains. Like there are DNS MX RRs for
each e-mail domain there could be DNS SRV RRs for the e-mail domains
pointing to the certificate stores' DNS A or CNAME RR and port
number. In this case "service provider" would be the domain name
hoster for the recipient's e-mail address. IMHO
draft-ietf-pkix-pkixrep-00 went in that direction but expired
silently. :-(

I cannot really comment on UPNP and determining net_loc but is
net_loc really solely an IP address or a DNS name as you described
or a host:port location?

I think URI generation for both cases should be unified.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 08 Jan 2002 13:42:56 +0100

Russel F Weiser wrote:
> support URI based queries you discribe in your draft? To me this seems
> like the logical location to place the CRL query uri.

While I understand the rationale in section 3.4 that AIA and CRLDP
extensions are different in semantics I think the CRL could be
retrieved via CRLDistributionPoint as long as the HTTP certificate
store interface behaves as expected for CRLDistributionPoint. IMHO
this mainly depends on what search attributes/values are used for
forming the URI.

An additional note could state that the issuer MAY use the URI of
the issuer's HTTP certificate store interface for generating a URI
for extension CRLDistributionPoint.distributionPoint.fullName but is
certainly responsible for generating a URI which works as expected
for semantics of CRLDistributionPoint.

But I don't understand this sentence in section 3.4:
"In addition CRLDP associates other attribute information with a
query which is
incompatible with the simple query mechanisms presented in this
document."

> I still believe the CRLDP should be used for CRL retrieval.

Me too. ;-)

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 08 Jan 2002 16:19:49 +0100

> 2. Some well-defined addressing rules once the IP address is known

BTW: Although not necessary for security a service provider running
a HTTP cert store might want to provide this service with SSL for
privacy reasons. Therefore the URL scheme is part of the 1. step.
=> Section 3.2 has to define rules for deriving URL scheme,
   host name/IP address and port number.

Ciao, Michael.

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 08 Jan 2002 12:43:06 -0500

CRLDP is, IMHO, fundamentally flawed because it combines two
unrelated functions:

1. cryptographically binding a certificate to the specific
partitioned CRL that applies to that certificate, and

2. facilitating retrieval of the CRL from a repository.

PKIX Part 1 Section 6.3.3: CRL Processing gives the algorithm
for determining if a certificate is revoked.  Step 1 is:

  "(1) locate the corresponding CRL in CRL cache, and ..."

The "corresponding CRL" is determined by comparing the CRLDP
extension in the certificate with the IDP extension in the
cached CRLs, using an algorithm that is not completely
specified.  For example, if CRLDP and IDP each contain a
DistributionPointName:fullName with two GeneralName's:
a directoryName that matches and a URI that does not match,
does the CRL correspond to the certificate or not?

I believe that the CRL partitioning algorithm should say
that URI forms of DistributionPointName are *not* compared
when determining if a CRL applies to a particular certificate,
and that other forms of DPN *are* compared.

But since that would be a butt-ugly special-case hack of a
rule, I agree with Peter that AIA should be used to hold
retrieval information, and CRLDP/IDP should be used to hold
only partitioning information.

The next-to-last sentence of Section 6.3.3 is:

  "The verifier must repeat the process above with the
   additional CRLs not specified in a distribution point."

How are those additional CRLs retrieved?  AIA.

Regards,
Dave

---

From: Andreas Sterbenz <[email-masked]>
Date: Thu, 10 Jan 2002 15:57:20 +0000

Peter,

some comments, partially overlapping with other people's feedback.

  . the draft only deals with HTTP, HTTPS may also be useful in some 
cases and should be permitted.

  . "Arbitrary-length binary values are converted into a search key by 
the process described in section 2.1." This seems a bit to vague, please 
clarify. In particular, the certHash is not an arbitrary length binary 
value, does that imply the full 160 bits are used or is it still 
truncated to 128?

  . you might want to explicitly state that both the attribute name and 
value are case sensitive

  . the value description says "as it appears in the certificate" even 
if it could also refer to a CRL.

  . "If more than one certificate matches a query, it MUST be returned 
as a multipart response." I assume you mean multipart/mixed? I would 
definitely prefer a SEQUENCE of certificates.

  . Server response in case no certificate/ CRL matches a query is 
undefined.

  . Server error behavior is undefined (invalid request, database 
temporarily unavailable, etc.)

  . key truncation to 128 bit: if we want to truncate search keys to 
save space, we might as well truncate them to 80 or 96 bits.

  . I believe the draft should be explicit wrt to attribute certs, even 
if it is only saying that they are not covered by the specification.

  . is a client required to implement full HTTP/1.1 and MIME, i.e. is 
the server allowed to send responses that make use of all the funky 
features?

  . the security considerations mention the Cache-Control header, but 
the main document does not say if client and servers MUST/ SHOULD/ MAY 
send that header.

  . security consideration should state that the server should be 
considered untrusted, e.g. don't use the certificate returned for a 
email=[email-masked] query to send S/MIME encrypted mail 
without verifiying the contents of the certificate.

  . some examples with full requests and responses may be helpful.

  . server behavior in case of more complex queries should be defined 
(ignore what you don't understand) to allow evolution of the protocol.

Andreas.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 10 Jan 2002 19:47:16 +0100

> value, does that imply the full 160 bits are used or is it still

I also agree that all sort of hashes should be taken as-is because
they are most times already calculated before the HTTP cert store is
queried.

> temporarily unavailable, etc.)

I'd suggest to explore the possibility to just use HTTP response
error code as defined RFC2616, section 6.1.1. Otherwise a message
format for queries and response would have to be defined.

Ciao, Michael.