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

From: Peter Sylvester <[email-masked]>
Date: Tue, 12 Feb 2002 13:08:50 +0100 (MET)

> 
> I would prefer we use the existing PKCS7/CMS formats.  However, why should
> we force the client/user to choose one way or the other?  Can't we add an
> optional "response attribute" to enable the client to tell the server what
> format it wants to deal with?  
> 
> <query URI> '?' <attribute> '=' <value> ['&' 'response' '=' <value>]
> 
> I don't see this complicating the server side implementation very much.  
> 
> Alex
> 

The HTTP request could simply have an Accept: application/pkcs7 or
Accept: multipart/* header.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 8 Feb 2002 17:52:19 +0100 (MET)

> Andreas Sterbenz <[email-masked]> writes:
> 
> Most respondents were in favour of multipart, because they didn't want to build
> an ASN.1 encoder into their database.

It seems to me that implementing an encoder for a sequence like

30 80 cert1 cert2 ... 00 00

isn't really a big task, 
and even surrounding this with some fixed magic octets
representing a p7c message, thus allowing to reuse an 
already existing content-type.

Or, I seem to share Andreas' disagreement.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 13 Feb 2002 02:20:08 +1300 (NZDT)

"Deacon, Alex" <[email-masked]> writes:

>I would prefer we use the existing PKCS7/CMS formats.  However, why should we
>force the client/user to choose one way or the other?  Can't we add an

There are two problems with this:

- It adds unnecessary complexity to the query processing (it's not just a
  simple <attribute>=<value> any more).

- It makes it even worse than before, because now instead of having to support
  one of the two (right or wrong, depending on personal opinion) you have to
  support both.

Peter.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 13 Feb 2002 16:29:41 +0100

[email-masked] wrote:
> 
>         Title           : Internet X.509 Public Key Infrastructure Operational
>                           Protocols: Certificate Store Access via HTTP

I still see no reason why hash values (marked as binary) have to be
hashed again to generate the search value. IMHO base64-encoding them
would be sufficient. Well, personally I'm far less concerned about
limited length of URL query strings than Peter is anyway.

Ciao, Michael.