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

From: [email-masked] (Peter Gutmann)
Date: Wed, 9 Jan 2002 17:59:39 +1300 (NZDT)

Michael StrM-vder <[email-masked]> writes:

>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".

Done.

>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).

The human-usable forms are all text-only.  I doubt a user will ever want to
construct an issuerAndSerialNumber from a hex dump of a cert just to fetch it
from a directory.  In fact users aren't meant to use the interface at this
level at all.  This interface really isn't meant for use by humans, it's a
universal interface to a cert store which happens to use HTTP to achieve
universality.

>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. 

Web-to-LDAP interface issues are already covered in various RFCs, I didn't want
to wander into other people's territory.  It's also a pretty LDAP-specific
mechanism, you can't just grab a binary string from a cert, hash it, and do a
lookup, you have to follow fairly complex LDAP name-representation rules.  I'd
rather leave this to other RFCs which seem to cover it adequately.

>My suggestion would be to run certificate stores holding e-mail certs
>associated to e-mail domains. 

That's pretty much how it's meant to work.  If I know your email address is
@hotmail.com, I'd go to certificates.hotmail.com and ask for your cert.  If you
work for a certain government agency, I'd ask at ...agencysite.gov.  That's
also why the draft specifically mentions support for redirects, if you're
outsourcing the cert-storage task you can point to where the certs really are
(at worst you need to add a single static page pointing to the real server) -
did I mention in a previous message that there's a bit of practical experience
in using this? :-).  It's not perfect, but it's good enough, and pretty
transparent.

(I've added another paragraph to the rationale to cover this).

>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?

It's an IP address or DNS name.  Port is always 80.

Peter.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 09 Jan 2002 16:58:25 +0100

Peter Gutmann wrote:
> 
> Michael Ströder <[email-masked]> writes:
> 
> from a directory.

Agreed.

>  In fact users aren't meant to use the interface at this

I already understood that you don't have usage by end-users through
web forms in mind. But the specification is pretty close to enable
it. So why prevent us from querying the cert store with a simple web
form for searching certificates associated to an e-mail address?

> [..] It's also a pretty LDAP-specific

We had this discussion about RFC2253 string representation here. It
was not LDAP-specific at all. AFAIR it was triggered by XML-DSIG
specs. Remember?

E.g. OpenSSL already implements getting a RFC2253-compliant
representation of subject and issued DNs. Properly implementing the
DN string matching is a matter of the cert store's implementation
not your specification.

I know that you personally don't like LDAP. But this shouldn't hold
you back from relying on usable parts of the LDAP standard.

> @hotmail.com, I'd go to certificates.hotmail.com and ask for your cert.

Ok, understood. You should specify the term "service provider" a
little bit more in detail.

> That's

Well, I don't object against HTTP redirects but IMHO setting DNS
CNAME RRs are a more practical and efficient solution for
out-sourced installations.

> in using this? :-).

I know. That's why I'm reading and commenting the draft. Did I
mention that I have also some practical experience using those kind
of things? ;-)

> It's not perfect, but it's good enough, and pretty transparent.

I don't impose that such a thing has to be "perfect" since I don't
know what "perfect" might be.

Unfortunately you did not comment on my inquiry to run such a
service with URL scheme https and port number!=80. From my practical
experience it's sometimes crucial to be flexible in this regard.

Ciao, Michael.

---

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 10 Jan 2002 13:56:19 +0100

How much space is saved by only using 128 bits from the SHA1 hash?
I expect many databases already contain certificates indexed by a full SHA1 hash, and only using the first 128 bits requires an almost duplicate field (alt. using SQL 'like' things).
Is the added chance of collision insignificant when truncating the hash?

Regards,
Tomas