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

From: Andreas Sterbenz <[email-masked]>
Date: Fri, 08 Feb 2002 14:59:05 +0000

> 2. HTTP Certificate Store Interface

 > If more than one certificate matches a query, it MUST be returned as a
 > multipart/mixed response.

 > 2.4 Rationale

 > Multiple response are returned as multipart/mixed rather than an ASN.1
 > SEQUENCE OF Certificate or PKCS #7/CMS certificate chain because this
 > is more straightforward to implement with standard web-enabled tools.
 > An additional advantage is that it doesn't restrict this access
 > mechanism to DER-based data, allowing it to be extended to other
 > certificate types such as XML, PGP, and SPKI.

I continue to disagree with the decision to use multipart MIME for the 
reasons previously stated by me and others.

The XML/PGP argument does not seem to carry much weight either, because 
the spec is only targeted at X.509. It also seems questionable that MIME 
would be a suitable choice for XML/PGP any more than it is for X.509.

[I speak for myself, not for Sun]

Andreas.

---

From: Phil Griffin <[email-masked]>
Date: Fri, 08 Feb 2002 11:40:11 -0500

> [I speak for myself, not for Sun]

Agree. It seems to me that if you are capable of
handling a certificate, then handling a sequence
of certificates is not too much to ask. Common
industry practice. Reasonably expected capability.

And a bag of certificates is no more difficult for
an application not ASN.1-aware to hand off than a 
single certificate. It's a blob after all.

As to XML markup, that's just another ASN.1
encoding format too now. From the Study Group
17 Secretariat to the public asn1 list at ITU-T:

   "X.680, X.681, X.682, X.683, X.690, X.691 are being
   revised by Question 12 of ITU-T Study Group 17. As
   part of the ITU-T ASN.1 Project, an FTP server was
   set up with the aim of increasing interaction with
   all parties interested in the development of ASN.1
   related standards.

   I am pleased to inform you that the draft revision
   of the set of above mentioned Recommendations has
   been made available on an FTP server for a limited
   period of time (pdf format), and you are invited to
   review these texts to provide any comments that 
   could help to improve the most valuable base texts
   for your future reference.

   In addition, the draft of a new ASN.1-series 
   Recommendation, X.692, on Encoding Control Notation
   (ECN) is also made available on the FTP server. 
 
   Please note that the next scheduled meeting to discuss
   this issue is 27 February - 8 March 2002 (Geneva). If
   you wish to comment, could you please do so prior to
   15 February 2002 by using this e-mail mailing list 
   ([email-masked]) or by direct contact with the Rapporteur
   concerned ([email-masked]). 

   Many thanks in advance for your interest,

   NOTE: 
   asn1 FTP HOST NAME: ties.itu.int, 
   ID asn1, 
   PWD notation1"

Phil Griffin

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 08 Feb 2002 16:50:22 -0500

Hi Phil.

>It seems to me that if you are capable of
>of certificates is not too much to ask.

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.

Russ

---

From: Phil Griffin <[email-masked]>
Date: Fri, 08 Feb 2002 19:45:05 -0500

Completely understand. Opinion unchanged.

Phil

---

From: Andreas Sterbenz <[email-masked]>
Date: Mon, 11 Feb 2002 13:51:39 +0000

Housley, Russ wrote:
> 
> 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.

I was not arguing for a new MIME type, I was arguing for using the 
existing PKCS7/CMS format and MIME type. I would claim that this is much 
better supported by certificate handling applications than multipart.

Andreas.

---

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.