Re: Comments to SCVP ID 17

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> >We set a DEFAULT value wherever we could do so without adding any
> >more explicit tagging.  So, DEFAULT version numbers were set in
> >CVRequest and ValPolRequest, but not CVResponse or ValPolResponse.

... Which can be easily achieved also by switching the order, for
example 

     CVResponse ::= SEQUENCE { 
       cvResponseVersion         INTEGER DEFAULT v1(1) , 
       producedAt                GeneralizedTime, 
       policyID                  INTEGER, 

'explicit' is not the right term here. 

And furthermore there are other places where universal tags
can still be used at the place of context specific tags,

> I still believe that it is better to group "name checking", "key usage checking"
> and "extended key usage checking" into the category of "end/target certificate
> requirements". This is not a simply a stylistic change. It is a matter of logicalness
> of the protocol design. However, if we are really running out of time, I can live
> with "the basic validation algorithm with name validation".

We were running out of time 2 years ago. Everything was already settled in draft 12
as far as I remember the Vienna meeting. :) I just remind that the
text was totally un-implmentable at that time. 
 

... some text removed, I mostly share Wen-Cheng Wang's views. 

>  
> The point is a validation policy can imply a validation algorithm, and therefore
> the notion of validation algorithm can be removed from SCVP.

The "small" problem is that you need to specify the parameters even for 
example the name validation algorithm. 

The validation algo OID is used to define the syntax for these parameters. 
Denis gave another way

> 
> The current SCVP syntax and semantics only support validating certificates against
> a retrospective moment. Please not that it is not the same to say "a certificate is
> valid at time t1" as to say "a certificate is valid before time t1", because the validity of
> the certificate could be suspended and then resumed before time t1. It is certainly
> different with "a certificate is valid from time t2 to time t1".

Suspended doesn't mean revoked, if a suspended cert gets resumed, then I don't
think that someone really requires "You may still use it now, but anything
you have done within the time it was suspended (and which has still not
been tested!!), will be considered as invalid." 

The time intervals in question are also not really long.