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

From: [email-masked] (Peter Gutmann)
Date: Tue, 8 Jan 2002 20:42:55 +1300 (NZDT)

Russel F Weiser <[email-masked]> writes:

>1. Within the section 2.2 examples the difference from the fetch of the CA
>certificate and the fetch of the CRL is only the URI base. You might want to
>note this difference in the examples just to clarify.

OK.

>2. The latest son of 2459 specifies a SubjectInfoAccess SIA which would be
>another approperiate certificate extension for also encoding the Certificate
>retrieval URI as discussed in 2.2 . I believe that going forward this should
>be the primarily used to access the certificats.

Good idea, I'll mention it in the next draft.

>3. I don't understand why the CRLDP extension could not be leveraged to
>support URI based queries you discribe in your draft? To me this seems like
>the logical location to place the CRL query uri.

It won't work, the rationale in 3.4 explains why.

Peter.

---

From: "Piers Chivers" <[email-masked]>
Date: Tue, 8 Jan 2002 21:41:44 -0000

Peter,
This may be off-topic but have you considered a SOAP version of this
protocol.  SOAP messages can be transported over http, hence meeting this
requirement, but can also be transported over SMTP etc.  This seems to me to
be a more general approach than the one described here.
 
Section 2.
email       "Email address contained in the certificate..." 
What does this mean? I think you should be more explicit. Will the search be
against an email attribute in the subject DN, or an attribute in the subject
alternative name...
 
Section 2.1
"The one exception to this process is the subjectKeyIdentifier..." 
I hate exceptions to rules;)  Why bother with this proviso?  OK, it stops
one needless hash but it introduces additional coding at both the client and
server.  Why not just hash the hash?
 
Section 2.2
Although earlier text indicates why, the examples for retrieving a CA cert
and a CRL are identical in this section.  I think this should be clarified
(by indicating a query URI appropriately)
 
Section 2.2 Rational
Typo - should be Section 2.3
I appreciate your rationale but, as a client implementer, I don't want to
care what technology the CA is using to store the certs (RDBMS, LDAP,
whatever). But, as an LDAP zealot, I think there is a requirement to support
cert lookup by a textual representation of the subject DN.  Maybe the LDAP
server vendors can comment?
 
Regards,
Piers

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Public-Key Infrastructure
(X.509) Working Group of the IETF.
 
      Title       : Internet X.509 Public Key Infrastructure Operational  
                          Protocols: Certificate Store Access via HTTP
      Author(s)   : P. Gutmann
      Filename    : draft-ietf-pkix-certstore-http-01.txt
      Pages       : 
      Date        : 04-Jan-02

 
Piers Chivers
Product Architect
Protek Network Security
+44 (0)1270 507800
www.protek.com <http://www.protek.com> 

--------------------------------------------------------------------------------
This message is for the named person's use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient.  PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all email communications through its network.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 11 Jan 2002 18:33:24 +1300 (NZDT)

This has since been sorted out in private mail, Michael has suggested a whole
range of useful things which you can do with pre-constructed URIs which I've
added to the draft:

  Note that a single server can handle both CRLDP and AIA/SIA queries provided
  the CRLDP form uses an HTTP URI.  Since CRLDP points to a single static
  location for a CRL, a query can be pre-constructed and stored in the CRLDP
  extension.  Software which uses the CRLDP will retrieve the single CRL which
  applies to the certificate from the server, and software which uses the
  AIA/SIA can retrieve any CRL from the server.  Similar pre-constructed URIs
  may also be useful in other circumstances, for example for links on web
  pages, to place in appropriate locations like the issuerAltName, or even for
  tech support staff to email to users who can't find the certificate
  themselves.

Peter.

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 11 Jan 2002 10:16:25 -0500

Peter Gutmann:

I would prefer to maintain alignment with RFC 2585.  The use of SEQUENCE OF 
would be fewer bit on the wire, but it would also require the specification 
of another MIME type for the transfer of certificates.

Russ

> >. "If more than one certificate matches a query, it MUST be returned as a
> >multipart response." I assume you mean multipart/mixed? I would
definitely
> >prefer a SEQUENCE of certificates.
>
>Does anyone else have any thoughts on this?  The comments in the draft on
>SEQUENCE OF are:
>
>   This has the advantage that it takes a lot less code to parse, OTOH it 
> may be
>   harder to produce if what you're using is a web-enabled database, which
is
>   what most of them are.

============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 11 Jan 2002 18:27:17 +0100 (MET)

> of another MIME type for the transfer of certificates.

And what about using a cert-only cms message?

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 12 Jan 2002 17:39:45 +1300 (NZDT)

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

>Hmm, I think the cert store implementation itself should deal with these kind
>of index optimization issues. I vote for just submitting search values as is
>and let the certificate store backend do the bit reducing at the server-side
>if necessary at all. That makes client implementations simpler and leaves up
>decisions about how to deal with possible collisions to the server-side cert
>store implementation.

Fair enough, if no-one has any objections to the full 160 bits I'll leave it at
that.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 12 Jan 2002 19:39:09 +1300 (NZDT)

I wrote:

>That's probably the best argument for choosing MIME multipart/RFC 2585 rather
>than a SEQUENCE OF, the server shouldn't need to do anything more specialised
>than "fetch value based on key, via HTTP".  Any special-case processing can be
>done by the client.

There's another reason which I just realised while I was adding the IANA
considerations: Requiring a DER-encoded response is rather ugly if you're
processing something which isn't a DER-encoded certificate.  While I shall
reserve my opinion on the value of (say) XML certificates, I wouldn't want to
implicitly exclude them through a particular data-encoding requirement.

Peter.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 14 Jan 2002 20:30:06 +0100 (MET)

> >>This is acceptable, but I prefer one that is more straightforward to implement
> >>with web server tools.
> > 
> I don't agree. Complexity should be put in the server, not the client. 

Another argument may be that using a 'simple' standard developement kit
for a server to create unnecessary overhead for a client (and useless
data) instead of having a small and fast logic may result in
having all kinds of possible and undesirable errors and protocol messages 
above HTTP/MIME to escape at some point.