Re: SCVP Draft 17: Summary of changes

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

subject should be version 18. 

> >  Is there a particular reason to have a NULL in the keyusages and not just
> >  an empty sequence as here?
> >
> Yes.  extendedKeyUsages is defined as a sequence in which the end 
> certificate must satisfy ALL of the elements of the sequence.  If the 
> sequence if empty, then the end certificate trivially satisfies this.
> 
> keyUsages is defined as a sequence in which the end certificate must 
> satisfy AT LEAST ONE of the elements of the sequence.  If the sequence 
> were empty, it would not be possible for the certificate to satisfy at 
> least one element from the sequence.

Not only in mathematics a red herring may neither be red nor a herring. An empty
set trivially full fills any condition. 

> So, using "SEQUENCE OF KeyUsage" would not have worked for keyUsages.  
> We could have used a structure similar to the KeyUsages for extended key 
> usages, but the current structure is simpler and works just as well.

   SEQUENCE OF KeyUsage SIZE(0..MAX)

is certainly smaller text than KeyUsages.

I am saying the coding an empty sequence is technically equivalent to
coidng the null choice. Anyway, not too important since the size of the
encoding is the same, just the tag would be different, i.e.

   0500 instead of 3000

But, since the CHOICE forces the tag to be explicit, there are always two
additional 2 octets.

In fact what is happening here is typical for many texts in PKIX where
one interpretes and encoding instead of defining abstract indications
and then the encodings.definition and the interpretation of an encoding.

As an example, the text could go like this:

A client has three ways to indicate to the server what processing it
like to be performed concerning keyUsage. 

- Accept policy default processing for keyUsage
  The client informs the server that the default processsing defined
  in the server policy can be used with no additional parameters.

  To encode this, the client does not code the field XXX.

- Accept any keyusage
  The client informs the server that no checks concerning keyUsage
  should be performed.
  The client indicates this by coding an empty sequence of field XXX.

- Required keyusage pattern
  The client indicates to the server a set of bitstrings structures
  in the same way as keyusages, and requires at least one of the
  elements to match with the keyusage in the certificate, where
  match means that for any bit set to 1 in the indication element
  the corresponding bit in the certificate's keyusage is also set to 1.

  The client codes this by setting a non empty SEQUENCE. The order
  of elements in the sequence has no meaning.

Note that the abstract indication three was a SET, so if I follow
you argumentation the ASN1 should have a SET. 


> I had actually been tempted to change requestorRef to be a sequence of 
> GeneralName since GeneralName seemed to be more appropriate than OCTET 
> STRING for something that was supposed to hold an identifier.  A side 
> effect of this change is that it would have specified the encodings for 
> the identifiers as well.  However, there was a comment submitted for 
> draft 16 indicating a need to be able to use a hash value as an 
> identifier in requestorRef, an option that would have been effectively 
> precluded if OCTET STRING had been changed to GeneralName.  Since I 
> could not justify preventing use of a hash value and one can easily 
> encode any GeneralName value in an OCTET STRING, I left the syntax for 
> requestorRef unchanged.

Since you could not justify it, well then, yes, that's important ... :) 
And, you didn't even feel that this would have been worth to be
discussed a little bit.

There is nothing in 3379 that requires that you must be able to encode
a hash value. 
   
> I think this is more of a theoretical concern than a practical concern.  
> The odds that two servers that are part of the same SCVP relay network 
> would select different identifiers for use in requestorRef, but that as 
> a result of using different encoding techniques the encoded versions of 
> their names are the same are extremely small.

There are also various ways to encode a hash value into a GeneralName,
so it is wrong that this has been effectively precluded. Waht IS actually
precluded is that these identifiers can have a structure following any
global name space and you have no collisions using encoding. 

...

> I believe that SCVP already includes all of the basic fields needed to 
> support relay.  I don't believe that the base document needs to say any 
> more.  When a server implements relay, it sends out an CVRequest and 
> gets back a CVResponse just as a normal client would.  Guidance on what 
> queries a server should send and what it should do with the response is 
> just that.  Guidance on how to use a particular feature does not need to 
> be in the base standard, it can be in a separate informational 
> document.  If there is a desire for SCVP servers that implement relay to 
> exchange auxiliary information, that information can always be included 
> in non-critical response extensions.  So, I can not see any reason to 
> hold up the base standard.  There are too many people who need this 
> standard to be completed and who can use it even without guidance on how 
> to implement relay.

There is no exchange of AUXILIARY information. The requirements say
clearly that the client can request that the server returns ALL
information. The base text allows for relaying.

The current text does not honor this requierement of 3379. 

what you are suggesting, is to totally ignore relaying in the base
document which is contrary to what had been announced by Trevor, i.e. 
to specify how a relay would act, nothing had been changed. 
After having discussed that this is needed several months ago, 
and with agreement from Trevor, it is really surprising that
you haven't made your observation earlier.

Thus, as you admit, the text does not at all contain information about how 

- a relay should take a request from a client and transform it into
  a request to another server;
  At least it is already said one modification is to add the loop
  control.

- the result of the request could be returned as is with just the
  security envelope changed. But then the client does not have
  the important information required to show to a third party.
  
  one could just make a second signature in this case, 
  a counter-signature, or, when the client can authenticate the
  response from the relay, the response can be returned as is,
  i.e. with the signature from the second server.
  THIS is not possible with the current text because it is
  restrictive regarding the various authentication modes.

- Not having the ability to include a DPV response in a request/response
  similar to any other revocation information can easily be
  changed by one other type.

It is not ME who is holding the text, you, the authors are not
doing what you promised. And, if you have changed your mind,
you could have said this earlier.

peter

PS: I don't think that with a few additions the text can go
but if they are not made, fixing it might get very clumsy. 
Otherwise we would have OCSPv2 since years.