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

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Some of these have already been fixed as a result of other feedback or are
straightforward changes which I've applied, I'll coment on what's left...

> . the draft only deals with HTTP, HTTPS may also be useful in some cases and
>should be permitted.

I meant "HTTP" as a generic "HTTP or HTTPS", but I've made it more explicit in
the text.

>. you might want to explicitly state that both the attribute name and value
>are case sensitive

The attribute name isn't case sensitive (unless someone can present a strong
reason for this), but the value is, I've commented on this in the text.

>. the value description says "as it appears in the certificate" even if it
>could also refer to a CRL.

Fixed.

>. "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.

>. Server response in case no certificate/ CRL matches a query is undefined.
>
>. Server error behavior is undefined (invalid request, database temporarily
>unavailable, etc.)
>
>  . server behavior in case of more complex queries should be defined (ignore
>what you don't understand) to allow evolution of the protocol.

This is standard HTTP stuff:

  Responses to unsuccessful queries (for example to indicate a non-match or an
  error conditions) are handled in the standard manner as per [RFC2068].
  Clients should in particular be aware that in some instances servers may
  return HTTP type 3xx redirection requests to redirect queries to another
  server.  Clients receiving this response SHOULD use the returned URI to
  replace their existing one and resubmit the query to the new server.

>. key truncation to 128 bit: if we want to truncate search keys to save space,
>we might as well truncate them to 80 or 96 bits.

See my other reply on this.  I felt that 128 bits is the least I could get away
with without someone somewhere complaining.  The smaller the key, the more
efficient the B-tree indices become, so smaller would definitely be better.
I've added text to say that:

  Although clients MUST submit a fixed 128-bit value, servers are free to
  utilise as many bits of this value as they require, for example a server may
  choose to use only the first 40 or 64 or 80 bits for efficiency in searching
  and maintaining indices.

That should keep everyone happy.

>. I believe the draft should be explicit wrt to attribute certs, even if it is
>only saying that they are not covered by the specification.

All it really needs is another AIA... is there any demand for an attribute-
cert-specific AIA?  If not, I think the boilerplate IANA considerations will
cover it.

>. is a client required to implement full HTTP/1.1 and MIME, i.e. is the server
>allowed to send responses that make use of all the funky features?

I'd prefer to avoid profiling HTTP with anything more than a reference to RFC
2068... it's really up to clients as to how much they want to implement beyond
handling "worked"/"didn't work" responses.

>. the security considerations mention the Cache-Control header, but the main
>document does not say if client and servers MUST/ SHOULD/ MAY send that
>header.

I'd consider it up to the client, the reason I added it in the security
considerations is to let people know the issue exists.  It doesn't affect
interoperability, and I don't know if a MAY would add much.

>. security consideration should state that the server should be considered
>untrusted, e.g. don't use the certificate returned for a email=
>pgut001@xxxxxxxxxxxxxxxxx query to send S/MIME encrypted mail without
>verifiying the contents of the certificate.

Again, I consider that to be a client issue.  It's the same as any cert you get
via any mechanism, you can choose to trust it or not.

Peter.