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

From: [email-masked] (Peter Gutmann)
Date: Mon, 11 Feb 2002 20:15:58 +1300 (NZDT)

So far there seems to be a pretty even split on this.  Initially when I
suggested SEQUENCE OF there was a clamour for MIME multipart, with MIME
multipart people are saying they want SEQUENCE OF.  Russ Housley commented
that:

>On the client side of the HTTP Cert Store, I agree.  However, it is not clear
>that the server side of the HTTP Cert Store needs to do anything with the
>certificate at all.  It is just a blob that needs to be returned to the client.
>
>The MIME wrapper is already needed.  We are discussing whether a new MIME type
>should be defined to carry the SEQUENCE OF Certificate or we should use the
>existing MIME type define in RFC 2585 with a multipart.  All of the
>specifications and implementation tools are already in place to do the latter.

To try and sort this out I asked one or two of the people who have implemented
this (that is, not strictly what's in the draft since it didn't exist when they
did it, but something pretty similar).  All they did was (on the server side)
allow web queries of SQL Server via the SQL ISAPI extension, and (on the client
side) use WinInet (which is either an API name or an ActiveX control) to grab
the results, the interface is something like connect, send-request, get-result
(I don't use this stuff myself so I'm just repeating what I was told).  These
are standard tools which (presumably) a majority of users will end up using.
Since this seems to be the way which implementations will go, and without any
strong argument to push the balance one way or the other, I'll leave it at MIME
multipart for now.  Following the PKIX tradition this will probably remain a
draft for ages :-), so there'll be plenty of time to change it if an
overwhelming reason for SEQUENCE OF appears later.

Peter.

---

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: "Deacon, Alex" <[email-masked]>
Date: Tue, 12 Feb 2002 07:59:01 -0800

I don't see these as problems at all.  Moving processing complexity to the
server and away from the client is a good thing in my opinion.  

Alex

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 12, 2002 5:20 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
> 
> 
> "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.
>