Subject: Re: PKIX WG Agenda for 60th IETF (second try!)

From: Peter Sylvester <[email-masked]>
Date: Wed, 28 Jul 2004 14:33:02 +0200 (MEST)

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

   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.

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. 

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

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 29 Jul 2004 09:05:43 +0200

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" ?

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.

Denis

(as "someone participating in this list who agrees with something or 
considers it as useful").