[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Réf. : Re: I-D ACTION:draft-ietf-pkix-certstore-http -01 .txt
>. 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.
<comment>
In this case why not send the whole 160 bits hash in the client query and
let the server use some part of it (64, 80, 96, 128 or 160 bits) ?
This would simplify both the client (albeit not much) and the current
specification (which, from my implementer point of view, are both good
things). Then the specification could include an "implementation comment"
saying that "servers MAY use only part of hash supplied by the client query
to retrieve a certificate or CRL".
</comment>
--------------------------------------------------------------
Sébastien Pouliot
Architecte Sécurité / Security Architect
Motus Technologies
tel: 418 521 2100 ext 307
courriel / email: spouliot@xxxxxxxxx
pgut001@xxxxxxxxxx
d.ac.nz (Peter Pour : Andreas.Sterbenz@xxxxxxx, ietf-pkix@xxxxxxx
Gutmann) cc : pgut001@xxxxxxxxxxxxxxxxx
Envoyé par : Objet : Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
owner-ietf-pkix@xx
il.imc.org
11/01/02 13:20
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.