Subject: Re: SCVP Draft 17: Summary of changes

From: Peter Sylvester <[email-masked]>
Date: Wed, 16 Feb 2005 19:01:23 +0100 (MET)

Thanks for the fast response. 

I leave the comments for which I don't want to continue, and
other are also finished. ;-)

> >3 -
> >
> >         "The checks item MUST contain a sequence of object identifiers
> >   (OIDs)."  
> >
> >This sentence seems superflous to me, since the syntax already says that.
> >  
> >
> The text is consistent, and reinforces the information that an ASN.1 
> mechanic would glean from the syntax.  There isn't any harm in leaving 
> it, is there?

An additional MUST is something that you have to address explicitely in an
interop test.
 
> >4 - The usage of anyKeyUsage in the keyUsages is not explicitely defined.
> >   (It can be guessed to a certain degree..)
> >  
> >
> The text currently says:
> 
>   The keyUsages item may indicate either the particular key usages that
>   are required by the client or that the client does not require any
>   particular key usage.
> 
> The anyKeyUsage is implicitly described by the "or that the client does 
> not require any particular key usage".  This can be made more explicit 
> if necessary.
> 
> >   in other words, the requiredKeyUsages is defined, but not the anyKeyUsage
> >
> >   What is the difference of having a NULL option and not having coded
> >   the optional field?
> >  
> >
> If the client includes the keyUsages item in the validationPolicy in the 
> request and specifies the anyKeyUsage choice (encoded as NULL), the 
> client is indicating that it does not want validation to fail as a 
> result of the contents of the keyUsage extension in the end certificate 
> (or the absence of the keyUsage extension from the certificate).
> 
> >   Note that if the requiredKeyUsages is used, non existance of the 
> >   key usage in a cert extension is a match.
> >  
> >
> If the client omits the keyUsages item from the the validationPolicy in 
> the request, the client is indicating that validation should be 
> performed using the default value for the validation policy specified in 
> the validationPolRef item.
> 
> For example, a validation policy may, by default, require that the end 
> certificate either not include a keyUsage extension or include a 
> keyUsage extension with the digitalSignature bit set.  If the client 
> specifies the use of this validation policy and omits the keyUsages item 
> from the the validationPolicy in the request, then any end certificate 
> that included a keyUsage extension without the digitalSignature bit set 
> would be rejected.  If the client specifies the use of this validation 
> policy but includes the keyUsages item with the anyKeyUsage choice, then 
> the client is indicating that end certificates should be considered 
> valid if they include keyUsage extensions with digitalSignature set to 0.

Couldn't just NULL be replaced by an empty sequence. 0..MAX but well, this again
enters int ASN1 considerations, but it seem that the entendedkeyusage uses
this approach? 

As later on with one boolean, it seems that there is no way in the policy
definition to indicate that a server prohibits a client to specify a value.
Or, a server needs another configuration parameter to do this. IMO, this 
does not seem to be compatible with the idea of what consitutes a policy.  

> 
> >5- 3.2.4.9  
> >
> >   "If the client wishes to confirm 
> >   the extended key usage, then it can communicate the usage it wants to
> >   validate by the same extension using the same semantics as defined in
> >   [PKIX-1]."
> >   
> >   
> >   shouldn't 
> >
> >      SEQUENCE SIZE (1..MAX) OF KeyPurposeId
> >
> >   then be replaced by 
> >
> >      ExtKeyUsageSyntax
> >
> >   otherwise "same extension" is not well defined. (and even then)
> >   
> >  
> >
> Acutally, in the validationPolicy structure, extendedKeyUsages is now 
> defined as:
> 
>          extendedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL
> 
> Unlike in a certificate, there needed to be the option to include 
> extendedKeyUsages in an SCVP request with an empty sequence.  The effect 
> of including extendedKeyUsages in a request with an empty sequence is 
> similar to the effect of including keyUsages with anyKeyUsage.  That is, 
> the client is explcitly stating that it has no requirements with respect 
> to extended key usages.
> 
> We will re-word the above sentence to more clearly convey this.

Ok.

  Is there a particular reason to have a NULL in the keyusages and not just
  an empty sequence as here?

> 
> >8 - 3.2. 4     
> >
> 
> So, it seems to me that any other information about validation policies, 
> including which default parameter values can be overridden and which can 
> not must be provided through out of band means.  Either that or the 
> client figures it out through trial and error :)

ok, it seems that we agree that the sentence

 "For each parameter, a validation policy may either allow the client to specify a non-
 default value or forbid the use of a non-default value."

cannot be reflected at all in the validation policy data structure. 
  
> >9 - 3.5  requestorName 
> >       
> >   "The optional requestorName item is used by the client to include an 
> >   identifier in the request.  The client MAY include this information 
> >   for the DPV server to copy into the response. 
> >    
> >   SCVP servers MUST be able to process requests that include this
> >   field."
> >
> >   Please add:
> >
> >   A server MAY require this to match with some authenticated identity
> >   depending on a server defined rule.
> >  
> >
> Why do we need to say this explicitly?  It seems out of scope to me.  
> The server may choose to support clients on whatever basis it wishes, 
> including the contents of the requestorName field in the request and 
> some authneticated identity.  We do not need to specify the variety of 
> mechanisms that might be considered...

Well, I can live with that. 

But to prepare soem discussion later down: There is no single
authenticated identity. There may be several possible. 

> 
> >10 - 4.8  
> >
> >   "Alternatively, the SCVP server MAY omit this item."
> >
> >   I don't think that this is not a alternative if the client has set a
> >   requestorName, if if my reading of 3.5  "to copy into the response"
> >   mean that the server MUST copy.
> >  
> >
> RFC 3379 states:
> 
>   When the DPV request is authenticated, the client SHOULD be able to
>   include a client identifier in the request for the DPV server to copy
>   into the response.  Mechanisms for matching this identifier with the
>   authenticated identity depends on local DPV server conditions and/or
>   the validation policy.  The DPV server MAY choose to blindly copy the
>   identifier, omit the identifier, or return an error response.
> 
> The last sentence in this paragraph is very clear that the server may 
> omit the identifier in the response even when the client sends an 
> authenticated request with and asserts an identity in the request.

You are right. I always objected to the text in 3379.

It doesn't give any idea to a client whether it can count on getting
it back. Which may be necessary to have in in a response destined
to a third party. 

It should be at least clear in a server policy, and a server should
always behave in a consistent way, or to say that it is not the case.  

> >   Mildly speaking, after total silence since my last remark concerning
> >   these fields, I was not sure whether anything at all was accepted
> >   by the authors, or not, anyway, the tendancy has continued to 
> >   partially respond, and not say anything to concrete proposal, which
> >   is simply to have a requesterName in both requests and responses
> >   as a GeneralNames (note the s), so taht a relay can add an id etc.
> >  
> >
> For relay, one uses requestorRef.  requestorRef allows for a sequence of 
> identities, there is text in section 7 stating that the sequence needs 
> to list all of the servers involved in processing the request, and there 
> is a requirement that the response MUST copy the value of requestorRef 
> from the request.

There requesterrefs are not identities which can be interpreted.

They are globally unique values that may have defined relation to any 
identity of a server, since one does not know how to interprete the octet string.
 
It may be useful to distunguish some opaque octet string stuff for loop
control, although I stronly believe that remove the requestorRef
octet strings and replacing this by a sequence in the requesterName
is a better solution even for the loop control. 

Note that earlier proposals only had octet strings for all purposes,
and the requeserName was introduced silently after I had asked for
guidance on how to encode an identifier in an octet string.  

> >11 -
> >
> >   "In the case of non-cached responses to signed requests, the SCVP 
> >   server SHOULD return a requestor name."
> >
> >   For what reason a SHOULD? What is the reason for returning anything
> >   for a "signed" requst if the client doesn't need this? And, why
> >   'signed' and not protected?
> >  
> >
> I agree that signed should be replaced with "authenticated".  The change 
> from "signed" to "protected" was made at the last minute and this was 
> overlooked.  The term "protected" would be inappropriate here since 
> "protected" includes unauthenticated requests in which the client used 
> an ephemeral Diffie-Hellman key.
> 
> >12 - 7:
> >       "SCVP 
> >   servers that support relay SHOULD populate this item with the DNS 
> >   name of the server or the distinguished name in the server's 
> >   certificate.  SCVP servers MAY choose other procedures for generating
> >   identifiers that are unique within their community." 
> >
> >   I don't think the SHOULD is appropriate. DNS or distingushed name may 
> >   not exist, and there is no indication who an octet string can be populated.
> >  
> >
> The entire paragraph reads:
> 
>   To prevent false loop detection, servers should use identifiers that
>   are unique within their network of cooperating SCVP servers.  SCVP
>   servers that support relay SHOULD populate this item with the DNS
>   name of the server or the distinguished name in the server's
>   certificate.  SCVP servers MAY choose other procedures for generating
>   identifiers that are unique within their community.
> 
> As you state, a DNS name or DN may not be appropriate in all 
> circumstances, which is why the document says "SHOULD" instead of 
> "MUST".  The most important part is that identifiers be chosen "that are 
> unique within their network of cooperating SCVP servers".  DNS names and 
> DNs are just two types of identifiers that are likely to provide this 
> property.

I am not saying this, I am saying that there is not even a hint to how
create an octet string from such information, thus it is a SHOULD without
specification. 

Choosing something for uniqueness without knowning how it gets mapped into
another space entities from other universes can land, and without knowing
how you are mapped does not guarantee uniqueness.

> Since the only requirement is that the identifiers be "unique within 
> their network of cooperating SCVP servers", there is no need to mandate 
> how the identifiers are encoded within the OCTET STRING.

You have to ensure that the encoding is unique, not the source values.

Although it is somewhat unlikely that two implementations would use different
encodings of a dns name given a false match, or a false match with a DN, or so.  

The historical example is

  cs.some.ac.uk vs  uk.ac.some.cs 
 
> >13 - 7:
> >
> >   It is quite nice to have loop detection for relaying,
> >
> >   but nothing is said how a relay constructs a request from 
> >   a received on, and how a response is created from the 
> >   received response.
> >  
> >   (E.g. what to do with requesterName in the request? )
> >
> >   The SCVP still does not contain a means to include the respons 
> >   of another SCVP server in a response.
> >  
> >
> SCVP should not include a means to include the response of another SCVP 
> server in a response.  An SCVP client sends a request to an SCVP server 

The requirements say, that

  " When the certificate is valid
   according to the validation policy, the server MUST, upon request,
   include that information in the response."

and 

   "Such information may (not necessarily exclusively) consist of ...

    or a DPV response from a DPV server that is
    trusted under the validation policy."

The requirement does not say that the response may only contain the information
of the a relayed DPV response. You would loose some important information,
WHO has told it under what policy, etc. 

> and gets a response from that server.  How the server derives the answer 
> that it provides in the response is a local matter to the server.  The 

Yes, but it has to respond with ALL elements that have been used for
making the decision if the clients request it. The server has no freedom here. 

> server may call upon the services of other SCVP servers in generating 
> the response (i.e., the server may use SCVP relay), but that should be 
> transparent to the reponse.  If the SCVP server were allowed to simply 
> include the reponse from another SCVP server in its response, then this 
> would impose more complexity on the SCVP client, which would need to 
> parse responses that differed based on how the SCVP server derived the 
> response.

I cannot follow at all your conclusion.

It depends largely on what type of server you are talking. in a DPV case, 
the client believes in the response, and may just show it to a user.

Since parsing of a response structure is already one of its capabilities,
I don't see the extra overhead (for the client), I am not talking about
an end user.
 
   "For the client to be able prove to a third party that trusts the same
   DPV server that the certificate validation was handled correctly, the
   DPV response MUST be digitally signed, unless an error is reported.
   The DPV server's certificate MUST authenticate the DPV server."

The third party may only trust the relayed server and not the client's
SCVP server. Assume an client SCVP server which operates as in the equivalent
of the 'locally trusted' OCSP model, which is the normal one, 
and a relay which is associated to a CA or common to some community. 

I am not saying that a CA must have an associated SCVP server. 

> >14 - Since it seems that it has been agreed somehow that a id cannot
> >   necessarily be derived from a security envelope, or, at least for
> >   symmetric reason, a response should have an value identifying
> >   the responder.
> >
> >   Ah well, the previous responder item whihc had context 4 had been
> >   silently dropped (instead of being replaced by a generalnames.)
> >  
> >
> >     CVResponse ::= SEQUENCE { 
> >       cvResponseVersion         INTEGER, 
> >       policyID                  INTEGER, 
> >       producedAt                GeneralizedTime, 
> >       responseStatus            ResponseStatus, 
> >       respValidationPolicy  [0] RespValidationPolicy OPTIONAL, 
> >       requestRef            [1] RequestReference OPTIONAL, 
> >       requestorRef          [2] SEQUENCE SIZE (1..MAX) OF OCTET  
> >                                   STRING OPTIONAL, 
> >       requestorName         [3] GeneralNames OPTIONAL, 
> >           replyObjects          [5] ReplyObjects OPTIONAL, 

I meant to remove 4 blanks here.  

> >       respNonce             [6] OCTET STRING OPTIONAL, 
> >       serverContextInfo     [7] OCTET STRING OPTIONAL, 
> >       cvResponseExtensions  [8] Extensions OPTIONAL } 
> >
> >   please "align" the syntax.
> >  
> >
> 
> A self asserted identity has a value to the client, as established in 
> RFC 3379, when returned in the response.  Since this requirement was 
> agreed upon by the WG and included in RFC 3379, we wanted to be sure the 
> specification supported it.

to start: So seem to agree with Trevor that a from field in email is non existing
and is not used for identification (since I have not seen an answer to
from Trevor). :-)

The value has a meaning to other third parties, what you are saying
is the same as: "The value of 'tsa' in a time stamp token is useless."

   When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response.  Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy.  The DPV server MAY choose to blindly copy the
   identifier, omit the identifier, or return an error response.

To me, 3379 does not say WHY this is a requirement, or

 "A self asserted identity has a value to the client"

is not established in 3379. It has been established by the discussions.

ONE of the possiblities is to declare the identity because a single ONE
cannot be derived from a signing certificate, when you have more than 
one name form. 

This argument also applies to the server. I have not seen any
counterargument for that so far.  And only because I was ensured that 
a protocol may have other required features than those expressed in 3379
I didn't not continue with the discussion. I did not even expect 
that it would take years and versions to even get the requesterName 
aligned with 3379. In all my comments I mentioned the similar 
requirement for a servber identity.

I know the different possibilities to interprete silence
and partial responses. :-)

> Our reading of RFC 3379 does not support inclusion of a self asserted 
> server identity.  

See above. 

>                   Where the client cares about the identity, it can 
> obtain that information from the security envelope.  Where no security 
> envelope is available, the client is performing all security relevant 
> processing locally, and does not need the server's identity.  Unlike the 
> requestorName, this information is not returned in future messages, so 
> it has no value to the server either. 

Thanks for accepting a discussion. The identity has a value to
a third party. (cf tsa field in a time stamp token). 

  " For the client to be able prove to a third party that trusts the same
   DPV server that the certificate validation was handled correctly, the
   DPV response MUST be digitally signed, unless an error is reported. "

I do not only require a SELF ASSERTED identity of the server. I require that
the client may also instruct a server to work under a particular identity.

In TLS one recently found that just connecting to some point is not sufficient
to select the appropriate identity of the endpoint. 

And, in a request, the serverName is a list of names, a local client
should be able to tell his proxy: "Dear server, I know who YOU are, I need
a status request from the PKIX SCVP server concerning the cert from Dave'.
This is useful for proxies. 

> In short, a self asserted server identity has no security value, and we 
> could not come up with other useful semantics  - we tried -  so we 
> deleted it.
> 
> >15 - ReplyWantBack
> >
> >   I have never any explication why the
> >
> >     ReplyWantBack::= SEQUENCE { 
> >       wb                         OBJECT IDENTIFIER, 
> >       value                      OCTET STRING } 
> >
> >   is an encapsulating octet string. Since the client
> >   makes a particular wantback, one could assume that
> >   it knows the syntax? 
> >   
> >     ReplyWantBack::= SEQUENCE { 
> >       wb                         OBJECT IDENTIFIER, 
> >       value                      ANY DEFINED BY wb } 
> >
> >   seems better to me.
> >  
> >
> This is an "elegance" issue again, and we can make similar arguments 
> about the encoding of Extensions, etc.  Changing from "OCTET STRING" to 
> "ANY DEFINED BY wb" would be a stylistic change that would not improve 
> the protocol.

IMHO, this is not elegance, it changes the nature of the parsing code.
You need to explicitely invoke a new parser for the content.  

> >17 - 9
> >
> >   I think all staements of what a client or server MUST do with
> >   certain field should go to the section defining the protocol
> >   element. 
> >
> >   example the first statement in
> >
> >   "Clients MUST check the requestRef item in the response and ensure 
> >   that it matches their original request.  Requests contain a lot of 
> >   information that affects the response and clients need to ensure that
> >   the server response corresponds to the request."
> >
> >  
> >
> We missed this one in the security requirements section.  Since 
> non-cached responses may omit the requestRef item, this cannot be a 
> MUST.  Matching the request message with the contents of requestRef is 
> one option, but there are other ways for the client to verify that the 
> response properly corresponds to the request.  So, we would propose 
> changing the referenced text in the security considerations section. 
> 
>    Clients MUST verify that the response matches their orignal 
> request.   Clients need to ensure that
>    the server has performed the appropriate checks for the correct 
> certificates under the requested
>    validation policy for the specified validation time, and that the 
> response includes the requested want
>    backs and meets the client's freshness requirements.

> 
> It's a mouthful, but I believe this is the correct statement.  As 
> restated, it should stay in the security considerations section.

I don't think that this is a topic for the security considerations,
it is a feature of the protocol, but rather belongs to the description
of the way how each protocol element has to be treated, so you can
void to have too much in your mouth. 

Security considerations may be things like what happens when the
time goes out of sync, or when the server is not available, or ...

But that may be a question of elegance. :-)

> 
> >18 - 9
> >
> >   "Therefore in these situations use 
> >            of a URI many be more attractive."
> >
> >   Is there a comma missing behind the first word? if so, there are other places, too.
> >
> >  
> >
> We'll ask our local tech editor, but I think that the comma is not 
> required.  However, we should change the "many" to "may".

It seems that it depends on whether you want the reader to pause or not. 
one may even say

   Therefore, in these situations, use

   Therefore in these situations, use

as far as I understand some grammar explications. I was pretty (=VERY ***)
schlecht in der Schule. 

> >23 - Paul Hoffman used to be one of the authors. Even when nothing of what
> >   was written by Paul has remained, the contributions section could
> >   still name him, unless ... 
> >
> >   "The lively debate"  may you consider to replace it by 'the lively or almost deadly debate' 
> >
> >Peter
> >
> >  
> >
> This predates my involvement, but you are correct.  Tim tells me we 
> should add Paul to the list of guilty parties.
> 
> As to the debate, how much honesty do we really need?
See *** above.

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 18 Feb 2005 12:53:58 -0500

>An additional MUST is something that you have to address explicitely in an
We removed the word "MUST".

>>not require any particular key usage".  This can be made more explicit 
The text now says: "The keyUsages item may indicate either the 
particular key usages that are required by the client (using 
requiredKeyUsages) or that the client does not require any particular 
key usage (using anyKeyUsage)."

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

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.

>guidance on how to encode an identifier in an octet string.  
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.

>  cs.some.ac.uk vs  uk.ac.some.cs 
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.

>I am not saying that a CA must have an associated SCVP server. 
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.

Dave