Stephen Kent wrote:
Please send me a message with any requested corrections before 11/28: Steve ----- PKIX WG Meeting 11/7/05 Edited by Steve Kent SCVP rev 21- David Cooper (NIST)Text was added to clarify conformance requirements. WantBack items were made optional. New, optional items were added to allow an SCVP server to relay responses from other SCVP servers, and to label responses with an identity specified by a requestor, if the server has multiple identities. The reference to validation policies was tightened, so that only OIDs, not URIs, are accepted. Policy parameters, in addition to validation algorithm parameters, are now supported, but the optional validation policy attributes were removed, since no examples have been provided and the need for this facility was not well established.
The authors have spend three months to get out an editors after the Paris meeting and after Denis and me spend an hour to explain Tim Polk our issues. During the following months that was no interaction, and just a week before the submission deadline, there was a editors draft shown to us to comment it within three days. This draft showed that the notes taken by Tim Polk do not reflect the issues, and, not surprisong, they were either
ignored or only partially interpreted.The mentioned 'server has multiple identities' has never been stated as such, and the requested implementation (something which I have been asking for since years) is continuously misunderstood,
either refused, then partially implement, and then withdrawn. Point 1:What I have been requesting is that the CVrequest, and the CVResponse carry two sequences
of identifiers for the requestors and the responders.For the CVRequest, the requestorName sequence indicates who is acting as client or for whom the client is acting. A server may use the list to determine whether one of the authentication
methods matches with one of the entities.For the CVRequest, the responderName sequence indicates who the client believs should participate in the response. (this seems to be close to the current text). But the indication should be a list, in order to allow for proxies chaining or other. it is up to the server to determine what to do with the field, and how to respond with an appropriate authentication method.
For the CVResponse, the the requestorName sequence is essentially a copy of the last CVrequest (e.g. if chaining was used). The server may add an identification, if the initial client has not provide one, and if it can be derived from a networking identification or an authentication method, all this controlled by a policy where a client can be allowed to stay anonymous through a proxy.
For the CVResponse, the the responderName sequence (a responder field had been introduced in the past and then removed again), indicates the identities of parties that have participated in the creation of the response. This allows a client to show them immediately without the need of interpreting the details of the result which is difficult if not impossible in case of muiltiple
identities of servers.The various drafts cover all this partially, but each time only a part, a different one.
Or, in
CVRequest ::= SEQUENCE {
cvRequestVersion INTEGER DEFAULT 1,
query Query,
requestorRef [0] GeneralNames OPTIONAL,
requestNonce [1] OCTET STRING OPTIONAL,
requestorName [2] GeneralName OPTIONAL,
responderName [3] GeneralName OPTIONAL,
requestExtensions [4] Extensions OPTIONAL }
CVResponse ::= SEQUENCE {
cvResponseVersion INTEGER,
serverConfigurationID INTEGER,
producedAt GeneralizedTime,
responseStatus ResponseStatus,
respValidationPolicy [0] RespValidationPolicy OPTIONAL,
requestRef [1] RequestReference OPTIONAL,
requestorRef [2] GeneralNames OPTIONAL,
requestorName [3] GeneralNames OPTIONAL,
replyObjects [4] ReplyObjects OPTIONAL,
respNonce [5] OCTET STRING OPTIONAL,
serverContextInfo [6] OCTET STRING OPTIONAL,
cvResponseExtensions [7] Extensions OPTIONAL }
there should be
requestorName [x] GeneralNames OPTIONAL,
responderName [y] GeneralNames OPTIONAL,
(There was once a responder in the response structure.)
Point 2:
I have asked to explain the need for the MUST concerning
If the default values for all of the flags are used, then the
response flags item MUST NOT be included in the request.
responseFlags ResponseFlags OPTIONAL,
you can have the same effect using
responseFlags ResponseFlags DEFAULT {} ,
(modulo syntax errors introduced by my limited knowledge).
i.e. a MUST important for interop test is replaced by a standard feature
of ASN.1
My suggestion of 'elegance', i.e. the one that I made a strawman in Paris
was to change the definition of
ResponseFlags ::= SEQUENCE {
fullRequestInResponse [0] BOOLEAN DEFAULT FALSE,
responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE,
protectResponse [2] BOOLEAN DEFAULT TRUE,
cachedResponse [3] BOOLEAN DEFAULT TRUE }
to a bitstring with named values, and thus avoiding nested DEFAULT specs.
I can live with that, just write the DEFAULT as indicated above, and you
have one
test les for interop. On the other hand, there are compilers that may have
problems with nested defaults. so
ResponseFlags ::= BIT STRING {
fullRequestInResponse(0), responseValidationPolByRef(1)
protectResponse(2)
cachedResponse (3) }
and an appropriate DEFAULT
(responseValidationPolByRef,protectResponse,cachedResponse)
or DEFAULT '0111'BI repeat, the original point is the MUST about the empty sequence implying an
unncessary addition explicit test for conformance which you can handle by a
spec of DEFAULT { }.
point 3;
After 2 years or so, none of the authors ever answered why there is:
ReplyWantBacks ::= SEQUENCE OF ReplyWantBack
ReplyWantBack::= SEQUENCE {
wb OBJECT IDENTIFIER,
value OCTET STRING }
where some of the octet strings contain certificat lists and crls for
example.
What is the security risk or advantage to force client to invoke a parser
individually each time.
I simply propose:
ReplyWantBack::= SEQUENCE {
wbType OBJECT IDENTIFIER,
wbValue ANY DEFINED BY wbType }
(or in fact the correct corresponding current ASN.1 which may be a
bit difficult to understand for some people.)
There are minimal changes in the text that follows this definition, i.e.
instead of saying the octet string contains you says the type used is ...
Compare this with a similar construct in the request.
RevocationInfo ::= CHOICE {
crl [0] CertificateList,
delta-crl [1] CertificateList,
ocsp [2] OCSPResponse,
other [3] OtherRevInfo }
OtherRevInfo ::= SEQUENCE {
riType OBJECT IDENTIFIER,
riValue ANY DEFINED BY riType }
Point 4:
Use current ASN1. Free tools to validate the syntax exist.
Point 5:
Policy issues: I leave this mainly to Denis, but IMO the policy definitions
are intended to be usable for a client to determine *ALL* the required
or possible
parameters. By no way it is acceptable that a client try be required to
make
a trial to detrmline whether a something is necessary or required. Otherwise the whole point of having a protocol for policy discovery is useless. Point 6: Since this is ther from the very beginning, some error codes are represented as integer, although one would rather use an enumeration. Integers arefor values that be be used for counting. But well, I won't die because of that.
The one remaining problem here is how to make this protocol agile with regard to the hash algorithm employed for certificate references. Today SHA-1 is hardwired. Updating the spec to specify another hash function does not satisfy the new algorithm agility requirement. Steve Kent suggested that the hash function can be an aspect of the server's validation policy, to satisfy the agility requirement. Russ Housley suggested that the OID of the hash employed be explicitly returned, in case the server's policy changes over time (but the policy OID does not). A straw poll was conducted to get a sense of the room for the two alternatives described in the last slide in this presentation. The first alternative received 12 votes, vs. 0 for the second. (Slides)
Why are these alternatives?A client should be able to detect CURRENT hash algorithm in a policy lookup.
A server response and request are self containing entities. No additional information should be required to interprete the content, in particular, it an octet string containing a hash always needs to be accompanied by an algorithm identifier (unless the the protocol
or version specific default is used. Peter --To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature