Subject: comments on draft-ietf-pkix-scvp-23

From: thomas fossati <[email-masked]>
Date: Wed, 8 Mar 2006 10:24:05 +0100

Paragraph 4.9.4 draft-ietf-pkix-scvp-23.txt uses the values "id-stc n".

I think it should not use these values but rather 
"id-stc-build-pkc-path" instead of "id-stc 1"

But what is exactly the difference between id-stc-build-pkc-path and 
id-pkc-valid-pkc-path ?

The definition of id-stc-build-pkc-path refers to a prospective path 
defined in 3280.  In my understanding the corresponding section defines 
a prospective path as something that is validated according to the path 
validation algorithm.
6.1 defines the chaining as one of the tests made by the validation 
algorithm, but a prospective path is one that has passed all the other 
tests of the validation algorithm, too.

It remains the following possible difference between 
id-stc-build-pkc-path and id-stc-valid-pkc-path:  in case of 
id-stc-valid-pkc-path only one path is selected by the server, whilst 
in id-stc-build-pkc-path the server can propose several, each of them 
validated according to the validation algorithm.
Stated in other words, if there is only one path available, the 
definitions are identical.

t.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 16 Mar 2006 09:57:38 -0500

thomas fossati wrote:

> defined in 3280.  In my understanding the corresponding section 
> defines a prospective path as something that is validated according to 
> the path validation algorithm.

SCVP was designed to operated in two modes:  delegated path discovery 
(DPD) and delegated path validation (DPV).  In DPD mode, the server 
returns a prospective certification path that the client may use to 
validate the target certificate.  In DPV mode, the server performs the 
validation and returns an indication of whether the target certificate 
is valid.

For DPD mode, the client specifies the id-stc-build-pkc-path check and 
specifies in the wantBack item that it wants the certification path 
returned.  The server is supposed to return a prospective certification 
path, which is defined in RFC 3280 as follows:

      ... a prospective certification path (a sequence of n
      certificates) satisfies the following conditions:

         (a)  for all x in {1, ..., n-1}, the subject of certificate x is
         the issuer of certificate x+1;

         (b)  certificate 1 is issued by the trust anchor;

         (c)  certificate n is the certificate to be validated; and

         (d)  for all x in {1, ..., n}, the certificate was valid at the
         time in question.

While some of the terms in this description are somewhat vague, it is 
clear that a prospective certification path is not guaranteed to pass 
certification path validation.  There may be path length constraint, 
name constraint, or policy violations.  Also, the definition of 
prospective certification path does not take into account any of the 
inputs defined in section 6.1.1, which may affect the outcome of path 
validation.  So, it is possible that even if there is only one 
prospective certification path for a target certificate, this path may 
be invalid (or at least may not validate under the validation policy 
specified by the client) but may still be returned by a server in 
response to a query with a id-stc-build-pkc-path check.  It is the 
client's responsibility to validate the certification path.

For DPV mode, the client specifies the id-stc-valid-pkc-path check.  In 
this case, the server can only reply with a status of "Valid" in the 
corresponding ReplyCheck if it finds a certification path that is valid 
according to the validation policy specified by the client.

Of course, one may choose to implement a server so that it only replies 
with a status of "Built a path" in response to a query with a 
id-stc-build-pkc-path check if it is able to build a certification path 
that validates according to the validation specified by the client, but 
that is not a requirement of the protocol.

Dave

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 16 Mar 2006 19:01:55 +0100

> returned.  The server is supposed to return a prospective 
> certification path, which is defined in RFC 3280 as follows:
>
I don't think that it is correct to cite the phrase in this way.
It is like  removing "I don't think that"

The full sentence is "To meet this goal, the path validation process 
verifies , among other things, that a prospective path (a sequence of n 
certificates) satifies: ..." 

If my understanding of English is correct,  the definition of 
prospective path is just what is inside the brackets.

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

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 16 Mar 2006 12:21:46 -0800

I've been reviewing -23 in advance of Dallas and was pleased to see the
formulation cited below.  Whoever wrote this has studied and written
induction proofs.

Mike

---

From: thomas fossati <[email-masked]>
Date: Thu, 16 Mar 2006 21:48:11 +0100

Hi David,

>         (d)  for all x in {1, ..., n}, the certificate was valid at the

3280 says that a set of certificates which satisfies (a-d) is a set of 
certs which has reached "the primary goal of path validation ..." i.e. 
"[...] to verify the binding between a subject distinguished name or a 
subject alternative name and subject public key, as represented in the 
end entity certificate, based on the public key of the trust anchor."

A prospective certification path seems to be just "(a sequence of n 
certificates)" independent from the fact that properties (a-d) are met 
or not.

If it's 3280 to be wrong let's rephrase it in son-of-3280.

ciao, t.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 20 Mar 2006 17:47:15 +0100

David:

- In draft 18 the text was "build a certification path to a trust 
anchor", this
  was changed to "build a prospective certification path to a trust 
anchor (as defined
  in section 6.1 of PKIX-1)", this IMO was an error. I understand the 
intent but:

- The corresponding definition for id-stc-build-aa-path has not been 
changed.

- Judging form your incomplete and unaccaptable citation it may be that
  you didn't correctly read 6.1.

- SCVP indicates that  a server  can return a validation error of 
expired/not yet valid
  in DPV processing but on the other hand this validation is already 
part of the 4 point
  below?
  Why should a DPD server perform this test? It depends on information 
about a date
  that may not be available for the the server.

regards
Peter

David A. Cooper wrote:
>> defines a prospective path as something that is validated according 
>> to the path validation algorithm.
>> algorithm, but a prospective path is one that has passed all the 
>> other tests of the validation algorithm, too.
>>
> For DPV mode, the client specifies the id-stc-valid-pkc-path check.  
> In this case, the server can only reply with a status of "Valid" in 
> the corresponding ReplyCheck if it finds a certification path that is 
> valid according to the validation policy specified by the client.
>
> Of course, one may choose to implement a server so that it only 
> replies with a status of "Built a path" in response to a query with a 
> id-stc-build-pkc-path check if it is able to build a certification 
> path that validates according to the validation specified by the 
> client, but that is not a requirement of the protocol.
>
> Dave
>
>
>

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 20 Mar 2006 15:28:28 -0500

Peter,

Your initial response to my message was correct.  I simply read RFC 3280 too
quickly when responding to Thomas's message and quoted the wrong text for the
definition of prospective certification path.  RFC 3280 does define a
prospective certification path as a sequence of n certificates and indicates
that path validation involves (among other things) verifying the items listed in
a) - d).

I agree that the description of id-stc-build-aa-path should be change to be
consistent with the description for id-stc-build-pkc-path.  By design, it should
be possible to operate a DPD server as an untrusted system, which means that the
client cannot necessarily rely on any of the information returned by the server.
 The client must perform all of the steps of path validation and cannot assume
that the path returned by the server satisfies certain conditions.  Of course,
it would be preferable from the client's point of view for the server not to
send it invalid certification paths, so I would encourage DPD servers to perform
at least some checks on the certification paths that they return to clients,
even if this is not a requirement of the protocol.

Dave

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 22 Mar 2006 18:08:38 +0100

> even if this is not a requirement of the protocol.
Your message is unclear to me. Are you saying that the current SCVP is 
correct concerning
the  DPD mode to "build"  a prospective path, i.e. a DPD server should 
be explicitely
allowed to throw any set of certs to a client?