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

From: "Deacon, Alex" <[email-masked]>
Date: Mon, 11 Feb 2002 14:56:15 -0800

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, February 10, 2002 11:16 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
> 
> 
> 
> 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: Michael Ströder <[email-masked]>
Date: Wed, 13 Feb 2002 16:19:58 +0100

"Deacon, Alex" wrote:
> However, why should

Hmm, although I voted for MIME multipart I would happily prefer
having to implement SEQUENCE OF Certificate just to have one way xor
the other.

IMHO we should avoid blowing up this simple draft to another famous
PKIX collection of keywords like MAY, OPTIONAL and doing the same
thing in three different ways.

Ciao, Michael.