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

From: [email-masked] (Peter Gutmann)
Date: Thu, 22 Nov 2001 03:16:34 +1300 (NZDT)

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

>1. Are the URIs meant to be of the encoding type application/x-www-form-
>urlencoded? This would make sense because that's what is generated by HTML
>forms. But it also requires that use of URL quoting is mandated. E.g.
>
>GET /search-cgi?email=[email-masked] HTTP/1.0
>should be
>GET /search-cgi?email=foo%40bar.com HTTP/1.0
>
>Otherwise it would be similar unclear like URL quoting of LDAP URLs. :-(

Hmm, I hadn't considered that.  Thanks, I've added some text referring people
to RFC 1866 for encoding details.

>2. I'd prefer that the encodings are described more clearly. Especially how
>hashs are generated for sHash, iHash and iAndSHash. (Order of RDN components,
>same problem/solution like in OCSP?)

I've changed it to:

[Refers to section 2.1 for how to handle binary search keys]

  iHash         Search key derived from the certificate's issuer DN as it
                appears in the certificate.
  [etc]

2.1 Convering Binary Blobs into Search Keys

Some of the fields which are used in queries are of arbitrary length and
contain binary data.  Both of these properties make them unsuited for direct
used in HTTP queries.  In order to make them usable, they are first hashed down
to a fixed-length 128-bit value and then base64-encoded:

  Step 1: Hash the key value using SHA-1 to produce a 160-bit value

  Step 2: Encode the first 128 bits of the hash value using base64-encoding to
		  produce a 22-byte text-only value

The one exception to this process is the subjectKeyIdentifier, which is already
a hashed value.  In this case it isn't hashed again, but only base64-encoded as
per step 2.

2.2 Examples

To convert the subject DN C=NZ, O=... CN=John Smith into a search key:

  Hash the DN, in the DER-encoded form it appears in the certificate, to
  obtain:

    96 4C 70 C4 1E C9 08 E5 CA 45 25 10 D6 C8 28 3A 1A C1 DF E2

  base-64 encode the first 128 bits:

    96 4C 70 C4 1E C9 08 E5 CA 45 25 10 D6 C8 28 3A

  to obtain:

    lkxwxB7JCOXKRSUQ1sgoOh

This is the search key to use in the query URI.

[...]

2.2 Rationale

[...]

The binary search key sizes are limited to 128 bits to save space in search
indexes, and because there's no advantage to be gained from using the full 160
bits

[...]

>3. Thanks for featuring web2ldap. But it's not a technology just a web-based
>LDAP client software. Just leave it out.

OK.

Peter.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 21 Nov 2001 22:01:17 +0100

Peter Gutmann wrote:
> 
> Michael Ströder <[email-masked]> writes:
> 
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
Hmm, is that sufficient? I remember me stumbling over the right
"order" of SET in RDN components and calculating the issuerNameHash
in OCSP.

From RFC 2459:

   RelativeDistinguishedName ::=
     SET OF AttributeTypeAndValue

IMHO an application is not allowed to assume an order for SET.

Same problem in RFC 2560. AFAIK one has to sort the
AttributeTypeAndValue elements according to their DER encoding.
(OCSP experts, please correct me if I'm wrong).

I'd prefer that the exactly same definition is used like in OCSP.

Ciao, Michael.