Subject: SCVP remarks.

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Aug 2004 13:27:04 +0200 (MEST)

I'll repeat The purpose is not only relaying.

Using an opaque blob for the server is not conformant with the text
and spirit of 3379. I had asked for those fields during the
discussions of 3379, and the intention was by no means to have
opaque blob but 'potentially global identifiers'. 

3379 clearly indicates that a server may possesses some logic to 
match these identiiers with the ones used for authentication. 

An opaque blob does not allow IMO to implement any useful interoperable 
interpretation by the server which serves to identify the participating
entities. 

> [TF] Since you had not linked our discussion on the requestor field to
> this section of 3379 before we have been at cross purposes. As Dennis
> pointed out this field is intended for SCVP relay so the current text is
> accurate for that purpose. It's a opaque blob to the server so
> definition of any standard structures in this case was and is a
> pointless exercise.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Aug 2004 13:34:12 +0200 (MEST)

Sorry for the bad subject in the previous mail.

> * 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).
> 
> [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 or a DPV response from another SCVP
> server as an input, however if such as algorithm were to be defined,
> then the extension mechanisms within SCVP would permit TSA responses or
> DPV responses to be also returned. 
> 

If you read the text above the XXX above I am not talking about TSAs.
There has been a lengthy discussion about this requirement years ago
with at least some understaning that a DPV server can operate in a similar
way as an OCSP server, thus returning DPV server responses have the
similar functionality. 

I suggest to return a CMS contenttype as one of the possible return values.

> Also which discussing the client requesting the validation information
> by value in section 3.2.5 states
> 
> "include by value in the CVResponse  every aspect of the validation
> policy"
> 
>

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 11 Aug 2004 09:33:29 -0700

Hi Peter,
Let me repeat my previous posting which was after this mail.

It is also not appropriate to reuse the requestor field because of the
case of authenticated relay. Since the client signed the request with a
certificate in this case, the request complies with 3379. We just need
to add a GeneralName field in the response for this purpose. Though
remember that with cached responses this will not be possible.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 4:27 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: SCVP remarks.
* 
* 
* 
* I'll repeat The purpose is not only relaying.
* 
* Using an opaque blob for the server is not conformant with the text
* and spirit of 3379. I had asked for those fields during the
* discussions of 3379, and the intention was by no means to have
* opaque blob but 'potentially global identifiers'.
* 
* 3379 clearly indicates that a server may possesses some logic to
* match these identiiers with the ones used for authentication.
* 
* An opaque blob does not allow IMO to implement any useful
interoperable
* interpretation by the server which serves to identify the
participating
* entities.
* 
* > [TF] Since you had not linked our discussion on the requestor field
to
* > this section of 3379 before we have been at cross purposes. As
Dennis
* > pointed out this field is intended for SCVP relay so the current
text is
* > accurate for that purpose. It's a opaque blob to the server so
* > definition of any standard structures in this case was and is a
* > pointless exercise.