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

[Michael Ströder <[e-mail]>]

[e-mail] wrote:
> 
> 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.