Subject: Re: SCVP Draft 17: Summary of changes

From: "David A. Cooper" <[email-masked]>
Date: Fri, 04 Mar 2005 14:08:27 -0500

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

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 8 Mar 2005 14:57:12 +0100 (MET)

> so I explained.  Just because you don't agree with my reasoning is no 

Insulting?  I do not intend to insult anyone here, but 
I forgot to mention that I cited from Morris Hirsch's book of 
differential topology.  

> that this needs to be changed.

Tim and you have explicitly asked not to propose changes in ASN.1.
 
Did I ask to change it? I only made another explanation of a different
way to specify the same thing with a shorter encoding, but since the
semantics is equivalent ...

see also (*1*) below

> would prefer to see the change made, even if that person is me.

'stylistic' is the important word here?

> didn't know of anyone who felt that the change was needed.

The change from a octet string containing a sequence of zero terminated
octet string into a sequence of octet string was made by Trevor.

The message referenced below accnoledged that this was a first step,
BUT that the explanatary text contain useless restriction left
over from the previous version. The desire to code a hash is an example
to illustrate the error, not more.

The real point is that several times in the past I had asked exactly
what you had thought about, i.e. to use a construct that at
least allow GeneralName to represent participating entities.

> (http://www.imc.org/ietf-pkix/mail-archive/msg01739.html). 

This was  a reference to the restrictions about the content,
i.e. no zeros. I could have said as well that any encoded value
needs an extra escaping rule to protect for hex 0. 

I had sugggested also at some time ago a 
sequence of choice { octet string , generalname }
as a compromise in order to avoid a potential problem with the
content of an octet string that might be required by someone.

- without any success
- but then a change to a sequence to octet strings, 
- then the introduction of one requestername
- then requesternames. 

If I am considered to be the only one who wants to
encode a hash value, I can do this without the need of
an octet string, so you can safely replace requesterRef by
a GeneralName.

> name form to go in otherName, but that doesn't seem very practical.

Since it is a hash with an algo, one can use the well known
messageDigest which is roughly speaking close to an attribute which
you could formally put into a RDN.

> must be able to process the message even if this information is ignored.

The "third" "other" relying party is NOT a dpv client. The requester of
the dpv response is a client. It can process the result because all
what it does is to authenticate the result and see whether it is good.

> based on my knowledge of the situation.

I include an excerpt from a message from 10th of december 2004, after
draft 16. And there is also a corresponding comment from Denis.

* > * > * Chapter 7: Denis is right that the spec does not describe how
* > relaying
* > * > is
* > * > * performed, i.e. how a response is created from a response
received
* > * > from
* > * > * another
* > * > * server by a 'proxy'.
* > * > [TF] What specifically are you looking for?
* > *
* > * A working specification that includes:
* > *
* > * - how a request received is transformed into a new request by a
relay,
* > *   which fields are copied, or not, or may.
* > * - how the response is transformed into a response to the original
* > request
* > *   there are SEVERAL options, in particulat the one that addresses
* > *   the requirement of allowing a response as part of another one.
* > [TF] OK. I will add that.
* good.
* 
* Would it be possible to send a draft to the list before it get graved
into
* electronic marble.

> from a client  into a request to another server.  The protocol already 

The text for loop control is a demonstration that the contrary is true.
The transformation may be simple, but still you have:

- A relaying server prepares a request by taking all parameters from
  the received request, and:
  - modifies the loop control parms
  - modifies the requesterName (sets itself, or not?)

> response to the client, it does not matter.

Dependingh on a paricular policy, the only correct answer can be one that
includes all the information provided by external sources that have contributed
to make the DPV response.  

> it does not need to be included in the base standard.  

- An optional feature does not mean that it is not normative when used.

- Currently there is no way for a server to include a response from
  another server ASIS, including its signature. 
  The remote server acts as a civil law notary type, the third
  party is a judge that only validates whether the notary has
  validated the certificate, and does not perform any validation.

- If a DPV server validates a certificate, it may only provide
  a yes and no answer, and a statement from the remote server
  also with a yes and no answer. No path, no revocation info. 
   
                                                        It is my 
> informative document describing how relay can be used.

???

> that is not provided.  In the case of DPD, the client is performing the 

A way to authenticate the response, the third party is not required
to trust the client's local server but only a response from let's say
'public notary service'.

> include the certification path in the response).   What does relay have 
The local server may not be in the trust space of the third party. 

> justify this type of requirement.  If not, then I don't see how it could 

The requirement's text says clearly: 

   Such
   information may (not necessarily exclusively) consist of a
   certification path, revocation status information from authorized CRL
   issuers or authorized OCSP responders, revocation status information
   from CRL issuers or OCSP responders trusted under the validation
   policy, time-stamp tokens from TSAs responders trusted under the
   validation policy, or a DPV response from a DPV server that is
                         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   trusted under the validation policy.  When the certificate is valid
   according to the validation policy, the server MUST, upon request,
   include that information in the response.  However, the server MAY
   omit that information when the certificate is invalid or when it
   cannot determine the validity.

This means that it is possible for a server to use another one for
whatever purpose, and, if so (and why and how is a local matter), but
it is not a local matter to have the possibility to include the answer,
and this is not the case today.  

> have information about the relay to show to a third party.

The signature of the remote server's DPV response is not shown, i.e.
there is no way for the third party to authenticate the information. 

- You have still not responded to my question why it is necessary to
  have returned information encapsulated in octet strings requiring
  another invocation of a parser for the octet strings. 

  I had said this long ago: *1*

  - There are octet strings that carry undefined global information
  without encoding guidance.

  - There are ANY defined by structures

  - There are octet string containing other asn1 structures

  - there is the EXTENSION logic (=previous + critical)

  Three different techniques are used for similar purposes, where
  is any justification or logic for these differences?

- Given that a server can now return more than one requesterName,
  I ask for a change that allow a sequence also in a request,
  so that one has at least some change to note more than one
  client identity. This allow to note participating entities
  in a relaying environment. 

- It seems that you have not seem that in my recent message about
  asn1 styles there was a remark to make a policyId optional in
  case of a fatal server error.

Peter