scvp

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

The following message was not send to the list a few days ago.



The path validation algorithm is defined for end certificates. 

> [TF] If the path validation algorithm in 3280 cannot validate CA
> certificates I would consider that a defect against 3280. However I
> cannot see ant such defect so if you believe that to be the case you
> need to take that up with the authors.

The text explicitely says that the algorithm is for end entity certs: 

6.1.3 at the end: 

   If i is not equal to n, continue by performing the preparatory steps
   listed in 6.1.4.  If i is equal to n, perform the wrap-up steps
   listed in 6.1.5.

6.1.5  Wrap-up procedure

   To complete the processing of the end entity certificate ...


Take a invalid path  trust ... CA1 --> CA2 
with CA1 having a pathlength constraint 0 in its cert.

path length is n. CA1 is trusted somehow. 
maxpathlength = n
when you arrice at CA1, the maxpathlength will be 2 
path length constraint is 0 ==> set maxpathlength = 0

Then at the last step the 6.1.5 procedure is called
which does not fail. 

Please tell for your scenario who is responsible to detect
the wrong path. 


> [TF] Before we get into the solution, can you provide some examples
> (like I did for isCA) where path length is a useful policy input. In the
> example I cited, use of the isCA Boolean does not require path length as
> a policy input.

Just apply recursion up to the trust anchor. 


> * 
> * We could require that
> * 
> *    when isCA is set,
> *    the DPV client MUST provide the path to the trust anchor,
> *    or MUST provide the chain from the ee to the ca cert to be
> validated,
> *    including the ee cert,
> * 
> * (
> *    or in case of multiple paths that validate a CA, the state of the
> path
> * validation
> *    algorithm for any of the paths MUST be identical. ???
> * )

The previous was a proposition intened to be commnted. 

> * 
> * > We do have a facility to do this via the basic constraints extension
> * > in a CA cert, but we know that this feature is hard to use unless
> one
> * > knows the structure of the PKI pointed to by a cross cert that
> * > incorporates this feature. As a result, I generally suggest not
> * > making use of this optional part of this extension. I've heard
> others
> * > make the same comment, e.g., Sharon Boyen. I realize that 3280 makes
> * > no comment about this feature, so we have not deprecated it, but ...
> * 
> * I think it is not a bad practice to have pathlength = 0 in CA certs
> * that are only used to sign EE certs.
> [TF] That is the only useful instance of path length for a
> infrastructure management perspective but not for a validation
> perspective.

What do you mean by this?