Re: SCVP Draft 17: Summary of changes

["David A. Cooper" <david.cooper@xxxxxxxx>]

Peter Sylvester wrote:

 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.

You asked me the reason that I encoded keyUsages the way that I did and so I explained.  Just because you don't agree with my reasoning is no reason to be insulting.

Of course, if the working group indicates a preference for a different encoding, I will change it, but I have not heard anyone else suggest that this needs to be changed.

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.
  

As I see it, my responsibility as an editor is to do my best to ensure that the final document is technically correct and represents rough working group consensus.  That means that I should not be making changes to the protocol simply for stylistic reasons just because one person would prefer to see the change made, even if that person is me.

There is nothing in 3379 that requires that you must be able to encode
a hash value.
  

That's probably true, but not the point.  Its not as if I unilaterally changed the protocol to enable the encoding of hash values in requestorRef.  I'm just saying that I would have been in favor of making such a change, but could not because I had reason to believe that some members of the working group would be against such a change, whereas I didn't know of anyone who felt that the change was needed.

I am really confused by your argument that I should have made a unilateral change simply because the option that I would have been removing is not mandated by 3379.  First, as you have said before, just because something is not mandated by 3379 does not mean that it can't be included in SCVP.  Second, YOU are the one who expressed a desire to be able to encode a hash value in requestorRef (http://www.imc.org/ietf-pkix/mail-archive/msg01739.html). 

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.

While it is trivial to convert something that would have been encoded as GeneralName to an OCTET STRING (just place the DER encoding of the name in the octet string), I am not aware of any currently defined method for encoding a hash value in GeneralName.  Certainly one could define an attribute for inclusion in a directoryName or one could define a new name form to go in otherName, but that doesn't seem very practical.

 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.
  

Please specify exactly where in 3379 there is a requirement that the current text does not honor.  I do see the following in section 4.2:

   - Optional parameters in the protocol request and/or response MAY be
     provide support for relaying, re-direction or multicasting.  DPV
     clients that ignore any such optional parameters MUST be able to
     use the DPV service.  DPV servers that ignore any such optional
     parameters MUST still be able to offer the DPV service

To me, this means that any information in the request or response that is specific to relay MUST be auxiliary information in that the recipient must be able to process the message even if this information is ignored.

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.
  

If Trevor agreed to make a change to the document that was not made, I am not aware of it.  If there was a prior agreement to make a change to the document and the change was not made, then I'll work with Trevor to add the necessary text.  I am expressing my own opinions on this matter based on my knowledge of the situation.

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.
  

Support for loop detection is mandated by 3379:

   - When a server supports a relay mechanism, a mechanism to detect
     loops or repetition MUST be provided.

So, it is clear that this must be included in the protocol.  In SCVP, it is included in such a way that it can be ignored by clients and servers that do not support relay.

There no reason for the standard to state how to transform a request from a client  into a request to another server.  The protocol already specifies the rules for generating requests and the rules for generating responses.  These rules apply whether the requester is the end client or a relaying server.  How the server computes the response is a local matter and thus not something that needs to be standardized.  The contents of the response do need to be standardized and they are.  If a server wants to call upon the resources of another SCVP server to help answer a question, it may do that, but the contents of that request message are irrelevant as long as the request conforms to the rules specified in section 3 for SCVP requests.

An SCVP server that receives a DPV request could in turn send either a DPV or DPD request to another server.  The request could ask for revocation status checking if that was required by the client or the server could ask for just the certification path and then perform revocation status checking itself.  As long as it provides the correct response to the client, it does not matter.

So, any information about how to transform a request from a client into a request to another server would be informative not normative, and so it does not need to be included in the base standard.  It is my understanding that Tim Polk has proposed that you write a separate, informative document describing how relay can be used.

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

What information would the client be required to show to a third party that is not provided.  In the case of DPD, the client is performing the validation itself and so would certainly have any evidence needed to show to a third party.  In the case of DPV, the client is indicating that it trusts the server.  If the signed response from the server is not sufficient evidence to show to a third party, then the client needs to request more information from the server (e.g., require the server to include the certification path in the response).   What does relay have to do with this?  What if the server you sent to request to didn't even use relay to compute the response?  Are you saying that a server might be REQUIRED to use relay in order to generate a response, not because the server is unable to compute the response on its own but because some evidence would be created as a result of performing relay that is needed by the client to later show to a third party and that evidence could not be created without relay?  If so, then I do not see anything in 3379 to justify this type of requirement.  If not, then I don't see how it could be in the case that relay was used that the client would be required to have information about the relay to show to a third party.

Dave