RE: DPD/DPV reqmts

["Michael Myers" <myers@xxxxxxxxxxxxx>]

Denis,

For those of us unable to attend the Minneapolis session, given
the abundance of comments and proposed text may we assume that
the WG will be provided a -03 some time after that session?

Mike



Michael Myers
t: +415.819.1362
e: mailto:mike@xxxxxxxxxxxxxxxxxxxxxx
w: http://www.traceroutesecurity.com

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Denis Pinkas
> Sent: Friday, March 15, 2002 8:09 AM
> To: pkix
> Subject: DPD/DPV reqmts
>
>
>
> To the list,
>
> You will find hereafter additional responses to the
> comments raised during
> the WG last call. In any case for further
> discussions, please indicate first
> the comment number. This was not done by Petra and
> thus does not make the
> task easy. Also do not use separate e-mails.
>
> [About COMMENT 1]
>
> >From Petra Barzin <barzin@xxxxxxxxxx>
>
> I don't see why you differentiate between signed and
> authenticated
> responses.
>
> The same is true for signed responses: either the hash of
> the request or the important elements from the
> request must be present.
> In order to test the response against what has been
> requested the client
> has to keep his request or at least the hash of his request.
>
> The advantage of a hash - instead of copying all
> important elements
> from the request -  is:
>
> (a) that the response will be smaller and
> (b) adding a new important element to the request
> doesn't require a
> change of the response.
>
>   - a hash of the request MUST be included in the response.
>     This may allow the client to check if his request
> was maliciously
>     modified (if the response is signed) and helps to
> associate the
>     response with his request when using
> connectionless protocols.
>
> [Answer 1] The requirements are different whether the
> requester simply
> wants an authenticated response or a signed response.
> For a signed response
> the inclusion of the important elements from the
> request is needed, so that
> a response can be individually tested against what
> has been requested. For
> an authenticated response, the hash of the request is
> sufficient. To
> summarize:
>
>     - for signed responses, the important elements
> from the request
>       must be present.
>
>     - for authenticated responses, either the hash of
> the request or the
>       important elements from the request must be present.
>
> [Additional Answer 1]
>
> Two answers:
>
> 1) Signed answer may be individually re-verified,
> while authenticated
> answers may depend on a context that cannot
> necessarily be reconstructed
> later on. If signed answers are used for
> authenticated responses, then there
> is no more difference, but here we indicate
> requirements, not solutions.
>
> 2) The most important is to be able to use a signed
> response alone. If the
> signed response only contains the hash of the
> request, then the request must
> also be kept to know what the question was. A format
> for concatenating the
> request with the signed response would then be necessary.
>
> So, contradictory to what Peter(Sylvester) said,
> copying the request in the
> response, or just including its hash is not a
> protocol designers
> prerogative.
>
>
> [About COMMENT 2]
>
> yes, indeed. There is a contradiction. My last
> sentence should be:
> The random number doesn't have to be repeated in the response
> *because* the response contains a hash of the request.
>
> I don't understand your last comment. The client does
> not compute
> the hash over all the fields from the response but
> from his request!
>
> > - a random number MAY be included in the request.
> > This allows replay protection when the client has no clock.
> > The random number doesn't have to be repeated in
> the response
> > if the response contains a hash of the request.
> >
> > [Answer 2] Replay protection is so obvious that it
> has been omitted. We
> > could certainly add some text. The nonce
> cryptographically binds a request
> > and a response to prevent replay attacks. However
> when you say: "The random
> > number doesn't have to be repeated in the response
> *if* the response
> > contains a hash of the request". This sentence is
> in contradiction with your
> > first comment where you say: "a hash of the request
> MUST be included in the
> > response". A choice needs to me made.  :-)
> >
> > I believe that the nonce should be in the response
> as well, just because it
> > is easier for the client to compute the hash over
> all the fields from the
> > response instead of saying: "after the item X, I
> need to copy the nonce from
> > the request".
>
> [Additional Answer 2]
>
> At this time we have not agreed to always include the
> hash of the request.
> So if the hash is not there, then the random number
> must be there. See also
> the argumentation about comment 1 above.
>
>
> >From Peter Sylvester
>
> Most of the previous responses have been prepared
> collaboratively by the two
> co-editors: Russ and myself. Therefor, I would kindly
> ask to Peter Sylvester
> to avoid to use "you", in particular with a capital Y
> in words like "You" or
> "Your".
>
> [About COMMENT 5]
>
> > - a method to authenticate a server before sending
> any request
> >    (for example this can be achieved by SSL).
> >    (Another example would be using encryption.)
>
> > [Answer 5]. This is covered under the following
> wording: "In order to be
> > able to be confident that the validation of the
> certificate has correctly
> > been done, the client only requires an
> authenticated response". No change is
> > necessary.
>
> This statement covers authentication of a response, I
> am asking for
> authentication of the service before sending a
> request. Regarding
> your response to the next comment, yes, this can be
> implemented by
> a transport mechanism, but there is still a requirement.
>
> [Additional Answer 5]
>
> Authentication of the service before sending a
> request is not performed in
> similar protocols like OCSP. There is no particular
> reason to do so for this
> protocol.
>
> [About COMMENT 6]
>
> > - a method to ensure confidentiality of the transport.
>
> > [Answer 6] There is nothing here in that protocol
> that mandates
> > confidentiality like protecting the value of a
> private key or a secret key.
> > The transport can provide confidentiality in
> support of environments that do
> > not wish to reveal requests or responses contents,
> e.g. using TLS or S/MIME.
>
> Basically You agree that there is a requirement for
> confidentiality. Whether
> it can be supported by a transport mechanism is a solution.
>
> > No change is necessary.
>
> I Disagree.
>
> [Additional Answer 6]
>
> There is no requirement on the protocol to support
> confidentiality. In the
> same way OCSP does not support confidentiality at the
> level of the protocol,
> but can support it at the transport level.
>
> [About COMMENT 7]
>
> > - a method that client and server provide their identity
> >    in the requests and responses: 'You, the client X, has
> >    asked me, the server Y, the following question, and
> >    I, the server Y, with the help of server Z respond.'
>
> > This allows to be able to determine the
> participating entities
> > without having access to whatever particular authentication
> > method information.
>
> > [Answer 7] Actually, we already include the
> identity of the server in the
> > response. The request could also be optionally
> signed. This allows
> > the server to authenticate the client, and this
> authentication allows the
> > server to only support a selective community if
> desired. An option to be
> > able to sign the request may be added.
>
> > The following requirements may be used for example
> in case of
> > validation of an encryption certificate before usage.
>
> There is a difference between authentication and
> identification.
> The request is that the identification is independant from the
> authentication methods and the transports.
>
> A signing entity (the one identified in a signer info
> or a certificate)
> may or may not be the same as the one declared in the
> request/response.
> you may have separation of roles or other situations.
>
> "The President of the United States declares, ...
> signed by JWB".
>
> Another example is in relaying as follows:
>
> Your company service declares that I can use Your
> encryption cert,
> and the response is signed by my local service.
>
> [Additional Answer 7]
>
> It is unclear what requirement is being addressed and
> what kind of treatment
> would be done with such an identity field.
>
>
> [About COMMENT 8]
>
> > One may resume the relaying requirements into one:
>
> > - The protocol MUST provide a means to allow
> (visible) relaying
> >    of requests and responses.
>
> > - Relaying requirements:
>
> > - depending on policy, a server may just impersonate another
> >    server, i.e., take the responses of another
> server, and create
> >    its own response out of them.
>
> > - a server should be able to include the response
> of a relayed
> >    server into his response.
>
> > - a server should be able to simple add another
> authentication
> >    scheme to a response from another server (for example by
> >    using a second signature or a counter signature.)
>
> > - a server that acts as a relay should be able to
> tell to the
> >    next server that it is acting on behalf of a end
> user, and
> >    the final server should be able to note this in
> the response.
>
> > - For relaying, the protocol MUST provide an efficient means
> >    to detect loops.
>
> > [Answer 8] Clients trust some dedicated servers.
> They don't care how the
> > information that is provided has been established:
> there is a single server
> > that is responsible: the one which provides the
> answer. If the response is
> > signed by the expected private key, then it is
> acceptable, otherwise it is
> > not. There are not requirements for chaining or
> referral services. Relaying
> > between servers is not the topic of this document.
> No change is necessary.
>
> There is already a requirement that a service returns
> all information
> obtained from other services. There may be OCSP
> responses, crls, etc.
> Relaying
> of one request (for example of an encryption
> certificate before its usage)
> to
> another DPV service seems a possible implementation.
>
> If I would follow Your logic, then the DPV server
> never needs to return
> anything else than a authenticable YES/NO/DONTKNOW.
>
> There are requirements for relaying etc.
>
> [Additional Answer 8]
>
> There are no requirement for relying nor referrals.
> We are not going to jump
> into the complexity of protocols like DAP(Directory
> Access Protocol). Note
> also that in addition to the YES/NO/DONTKNOW
> authenticable answer, the path
> elements may be returned.
>
>
> [About COMMENT 9]
>
> > - Requirements for incomplete answers:
>
> > - a server may indicate an incomplete response,
> >    and provide a method to update the response later.
>
> > [Answer 9] This would create the maintenance of
> state information which
> > should be avoided. There has been plenty of
> discussion on the list regarding
> > the number of states.  People clearly want the
> fewest possible number. The
> > client may query again later on. No change is necessary.
>
> You are accepting the requirement as such but You
> propose not to
> include it in the document because of some
> implementation detail.
>
> You always have state in a server (maintaing a TCP
> connection for example.)
>
> The fact that this requirement requires some
> particular feature in
> an implementation does not mean that the requirement
> doesn't exist.
>
> It does neither mean that a particular implementation
> of the protocol
> MUST implement for example given a first online
> response and sending
> a later mail.
>
> [Additional Answer 9]
>
> As already said, there has been plenty of discussion
> on the list regarding
> the number of states.  People clearly want the fewest
> possible number.
>
>
> From: Yuriy Dzambasow" <yuriy@xxxxxxxxxxxx>
>
> Some additional comments.  I have separated them into
> the following
> categories: editorial and technical.
>
> Editorial (at least I am assuming these are editorial):
>
> [COMMENT 19]
>
> 1) Recommend deleting the 2nd paragraph on page 5
> (Section 5) for the
> following reasons:
>         - the first sentence attempts to qualify the
> preceding paragraph,
> and in my
> opinion, adds no additional value
>         - the second sentence contains redundant
> information already defined
> two
> paragraphs above
>
> [Answer 19]
>
> The second paragraph on page 5 (Section 5) is:
>
> Clients MUST be able to specify whether they want, in
> addition to the
> certification path, the revocation information
> associated with the
> path, for the end-entity certificate only, for the CA
> certificates
> only or for both.
>
> This text is not redundant. You are certainly
> pointing to another paragraph.
> Next time, please provide a short extract.
>
> [COMMENT 20]
>
> 2) In section 5, 3rd paragraph it says, "...In that
> case it is acceptable to
> pass the parameters from the path discovery policy
> with each individual
> request, i.e. a set of trust anchors..."  Please
> change the "i.e." to "e.g."
>
> [Answer 20]
>
> OK.
>
> [COMMENT 21]
>
> 3) Section 8, first paragraph: The text states that a
> client can use a
> request/response pair to define to a server a
> "..validation policy and/or a
> path discovery policy..."  Please change "and/or" to "or".
>
> [Answer 21]
>
> OK.
>
> [COMMENT 22]
>
> 4) Change title of 8.1.1 to Certification Path
> Requirements, so that it is
> consistent with the text in section 8.1, item 1.
>
> [Answer 22]
>
> OK.
>
> Technical:
>
> Most of my comments have been addressed (or are being
> addressed on previous
> threads).  I have these three additional comments:
>
> [COMMENT 23]
>
> 1) Why does DPD say that it is OK to pass some policy
> parameters within a
> DPD request if the policy is simple enough (section
> 5), but just the
> opposite is said for DPV (section 4)?  I would think
> that a simple policy
> could be adhered to as well for DPV, and that the
> parameter specification
> could occur within the DPV request.
>
> [Answer 23]
>
> The document does not provide details about what
> means "simple". However the
> idea is the following: when there is a single root,
> with no constraints
> (unless contained in the self-signed certificate
> itself) and when any CRL
> status information is acceptable, then the policy can
> be considered as
> simple. Specific checks on the end-certificate are
> always done locally.
>
> With DPV the policy has to say which CRL information
> is necessary for each
> leg. But the most important is that checks on the
> end-certificate have to be
> done remotely and specifying them is that not simple.
>
> [COMMENT 24]
>
> 2) For DPD responses (page 5), why do the first three
> response types say,
> "...according to the path discovery policy...", while
> the last response type
> says, "...according to the path discovery
> criteria..."?  What is the
> difference between policy and criteria?  If there is
> no difference, then I
> recommend changing "criteria" to "policy".
>
> [Answer 24]
>
> OK.
>
> [COMMENT 25]
>
> 3) Section 8:  I think it would be helpful to break
> out the PDP requirements
> section into two areas:
>
> 1) requirements around the coordination of a
> validation/path discovery
> policy
> between a client and a server to support the
> validation/path discovery for
> a given certificate; and
>
> 2) requirements around defining an authorized policy
> at a server (e.g., used
> by security managers).
>
> This makes it clear that PDP can be used in two distinct ways.
>
> [Answer 25]
>
> PDP only addresses the later. It is unclear what is
> being requested for the
> first area. Please explain.
>
>
> >From Petra Barzin <barzin@xxxxxxxxxx>
>
> [COMMENT 26]
>
> I would propose the following:
>
> - add one more sentence to section 6:
>
> The protocol SHALL allow clients to obtain the identifier and
> definition of a specific, the default or all of the
> policies supported
> by the server by using another additional
> request/response pair.
>
> [Answer 26]
>
> Not all policies have a definition that can be given
> back (e.g. when locally
> defined). However the identifier (e.g. OID) of the
> policy can always be
> given back. So I would propose to change the sentence
> as follows:
>
> "The protocol SHALL allow clients to obtain the
> references for a specific,
> the default or all of the policies supported by the
> server by using an
> additional request/response pair."
>
> [COMMENT 27]
>
> - and add another section after the PDP requirements:
>
> Policy Retrieval Protocol (PRP) requirements
> In order to archive the validation result of a
> certificate, it MAY be
> necessary to combine it with the used validation
> policy. In some
> cases the client MAY want to get an overview of all validation
> policies supported by the server. Both reasons result
> in the following
> requirements for the Policy Retrieval Protocol :
>
> * return a specific validation policy definition
> * return the default validation policy definition
> incl. its identifier
> * return all validation policy definitions incl.
> their identifiers
> * return max. number of validation policy definitions
> incl. their
> identifiers
> * return max. number of validation policy identifiers
>
> The last two requirements are especially useful for
> thin clients with
> small display facilities.
>
> [Answer 27]
>
> What you propose should be restricted to policies
> defined with the PDP
> protocol. I would prefer to retrieve one by one the
> policies. So using first
> the result of the previous responses, mandated by
> section 6, I would
> propose the following text for a new section 9:
>
> Policy Retrieval Protocol (PRP) requirements
>
> This protocol will allow to obtain the details of a
> policy provided that it
> has been previously defined using PDP. Thus by
> providing an identifier, the
> request will include the definition of the policy, as
> originally provided.
>
> Regards,
>
> Denis
>