Subject: RE: Comments on SCVP15

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 2 Aug 2004 00:01:10 -0700

Hi Denis,
The concern you express here is touching.
See answers below.
Trevor

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Denis Pinkas
* Sent: Thursday, July 29, 2004 12:06 AM
* To: Peter Sylvester
* Cc: [email-masked]
* Subject: Comments on SCVP15
* 
* 
* Peter,
* 
* I am in general agreement with the *technical* comments you sent.
* 
* The current version of SCVP is still not compliant with RFC 3379.
* A large amount of work still needs to be done on this draft.
* 
* It is also a pitty that the new draft (15) has only be officially
* distributed on July 20.
* 
* On May 17, Trevor said: "I will be posting SCVP 15 shortly so you can
* review
* the latest draft." I replied: "An extract of the proposal sent to the
* mailing list and targeted to this problem would probably save another
* round."
* 
* Should I undertstand that, for Trevor, "shortly" practically means
"more
* than 2 months" ?

[TF] I will pass on you comments to my management when we are next
discussing my work schedule. I am sure they value such input.

* 
* Now awaiting SCVP-16 ... or much better, before issuing it, a response
to
* the many technical comments raised on this mailing list on SCVP-15.

[TF] A reply to you last posting has been made. What is of concern is
the fact that you requested changes in your posting on SCVP15 to
sections of SCVP which have been stable for the past 15 versions. I will
only post draft 16 when I have a definitive and final set of issues from
you and there will only be editorial changes from then on. This point is
not negotiable. Anything else will have to wait.

* 
* Denis
* 
* (as "someone participating in this list who agrees with something or
* considers it as useful").
* 
* 
* > it seems to me that some of the results of discussions between
* > the editor and me have been forgotten or so.
* >
* >
* > I still think that the scvp is not conformant to RFC 3379
* > and/or the editors has not done something as announced.
* >
* > 1) RFC 3379 says:
* >    The DPV request MUST allow the client to request that the server
* >    include in its response additional information which will allow
* >    relying parties not trusting the DPV server to be confident that
the
* >    certificate validation has correctly been performed.  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
* >                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

[TF] Given that SCVP requires the server ensure that the validation
policy has been complied with and permits all the parameters for the
currently defined validation algorithms to be returned ( full
certificate path, CRLs, OCSP responses) then I consider SCVP to be fully
compliant with 3379. There are no currently defined validation
algorithms which have a TSA response as an input, however is such as
algorithm were to be defined, then the extension mechanisms within SCVP
would permit TSA responses to be also returned. It is also conceivable
that a validation algorithm where a DPV response from another SCVP
server was also an input, and the same extension mechanisms would permit
these responses to be likewise returned.

* >
* >    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.
* >
* >    ==> no provision (as far as I see).
* >
* >
* > 2) RFC 3379 says:
* >    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.

[TF]Peter had not linked our discussion on the requestor field to this
section of 3379 before. As you pointed out this field is intended for
SCVP relay so the current text is accurate for that purpose. Given that
this is a SHOULD clause you cannot claim that SCVP is non-conformant to
3379 if it does not support this feature. 

* >
* > The current text is SCVP says:
* >
* >   The OPTIONAL requestor item is used to identify the requestor.
The
* >   value is only of local significance to the requestor.  If the SCVP
* >   client includes a requestor value in the request, then the SCVP
* >   server MUST return the same value if the server is generating a
* >   specific response.
* >
* >
* > tf also said:
* >
* >
* >>Given there are plenty of ways a client can generate a "unique" as
well
* >>as other behaviors like it can encode a DN in the octet sting if it
* >>likes I don't see a problem. Its down to the client to do what it
thinks
* >>fit. The value is simply replayed by the server so it is treated a
* >>binary blob.
* >
* >
* > There is nothing else possible for the server except copying, or,
* > no mechanisms to match this with the some authenticated entity
* > can be safely developped if it is solely 'up to the client to encode
* whatever'.
* >
* > I had proposed two changes to the logic of 0 terminated octet
strings
* by:
* >
* > - a sequence of octet strings allowing a real opaque string.
* > - a choice of generalname
* >
* > I.e.
* >
* >    Identifiers ::= SEQUENCE OF {
* >           CHOICE {
* >                opaqueId OCTET STRING,
* >                nameId GeneralName
* >           }
* >
* > No comment to this proposition as far as I remember.
* >
* > 3) In May 204 trevor wrote:
* >
* >
* >>I think we can use the Cert sign bit in key usage so the is CA bit
can
* >>be removed from SCVP15
* >
* >
* > which was not done.

[TF] Yes I reconsidered that position. Since the 3280 path validation
algorithm uses the basic constrains extension as it's test for CA
certificates (3280, 6.1.4 k) and that algorithm is a mandatory feature
for every SCVP validation algorithm, I concluded it was safer to use the
same test rather than risk another based on key usage.

* >
* > 4) Somewhat related to this, and to the provisions to search in DPD
or
* validate
* >    in DPV several types of extensions, I had proposed to opetionally
* search
* >    for the pathlength basicconstraint. if for example a client has a
* >    cert and a CA cert then one could use it to search only for CAs
that
* >    have at least a pathlength of 1.
* >
* >
* > I seem to understand that the rule in this WG is:
* >
* > - editor, chairmen, iesg says something ==> accepted if no response
* > - others ==> rejected if no response from anyone.
* >
* > all totally independant of the content of the comment.
* >
* > At least point 3 doesn't fit into this rule.
* >
* > I'd like to to see whether there is someone participating
* > in this list who agrees with something or considers it as useful ...
* >
* > Thanks for consideration
* > Peter
* >
* >
* >
* >
*