Subject: Re: SCVP: Certificate value & ESSCertID (minor)

From: Peter Sylvester <[email-masked]>
Date: Wed, 01 Mar 2006 14:37:49 +0100

Tim Polk wrote:
> Peter, Sam, and Denis,
>
> I believe that we want to ensure that SCVP servers can parse requests, 
> even if they include certificate types that aren't support (e.g., 
> attribute types), or certificates are referenced using an unsupported 
> mechanism (e.g., certificate hash). I agree the current text is 
> unclear and also think that attribute certificates are not covered 
> comprehensively.
If that is what you want then your proposed text does not fit.
In the following you don't require unconditional parsing.

"Conforming SCVP server MUST be able to parse all choices of 
PKCReference and ACReference."

Or at least you can add

"Conforming SCVP server MUST be able to return unsupported choices of 
PKCReference and ACReference in a CVResponse."

This doesn't imply complete parsing.

>
> To be really clear, I think we need to replace the sentence in the 
> last paragraph of section 3.2.1:
>
>     "Conforming SCVP Server implementations MUST be able to parse
>     CertReferences with certificates referenced by both inclusion and
>     CertID."
>
> with the following two sentences:
>
>     "Conforming SCVP Server implementations MUST be able to parse both
>     the cert and pkcRef choices in PKCReference. Conforming SCVP
>     Server implementations that process attribute certificates MUST be
>     able to parse both the attrCert and acRef choices in ACReference."
>
> Would that work for everyone?
>
> Tim
>
> At 01:56 PM 2/27/2006 +0100, Peter Sylvester wrote:
>
>> Denis version could be interpreted as if all occurrences msut be of the
>> same type.
>>
>> what about something like:
>>
>> Conforming implementations MUST support both the 'cert' a and 'pkcRef'
>> choice of PKCReference.
>>
>>
>> Sam Hartman wrote:
>>>>>>>> "Tim" == Tim Polk <[email-masked]> writes:
>>>
>>>
>>> Tim> [Tim] We *meant* to require servers to parse requests where some
>>> Tim> certificates were referenced by inclusion and others were 
>>> referenced
>>> Tim> by CertID.
>>>
>>> >> Change the sentence with :
>>> >> >> Conforming SCVP Server
>>> >> implementations MUST be able to parse CertReferences with
>>> >> certificates referenced by either inclusion or CertID.
>>>
>>> Tim> How about the following sentence instead?
>>>
>>> Tim> Conforming SCVP Server implementations MUST be able to
>>> Tim> parse CertReferences where some certificates are referenced
>>> Tim> by inclusion and others are referenced using CertID.
>>>
>>> Denis's sentence seems to better handle the case where a request only
>>> handles one cert.
>>>
>>> I don't think this matters much, but his proposal does seem slightly
>>> more clear.
>>>
>>>
>>>
>>
>>
>> -- 
>> To verify the signature, see http://edelpki.edelweb.fr/ Cela vous 
>> permet de charger le certificat de l'autorite'; die Liste mit 
>> zuru"ckgerufenen Zertifikaten finden Sie da auch.
>>
>>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 01 Mar 2006 10:50:38 -0500

Peter,

We agree that a conforming SCVP server should be able to parse a 
CVRequest whether the request includes public key certificates or 
attribute certificates and whether the certificates are included in the 
request or are specified by reference.  Here is the full paragraph of 
the relevant text, with the revision that Tim has proposed:

   Conforming SCVP Server implementations MUST be able to process
   CertReferences with multiple certificates.  Conforming SCVP Server
   implementations MUST be able to parse CertReferences that contain
   either public key or attribute certificates.  Conforming SCVP Server
   implementations MUST be able to parse both the cert and pkcRef
   choices in PKCReference.  Conforming SCVP Server implementations
   that process attribute certificates MUST be able to parse both the
   attrCert and acRef choices in ACReference.

So, it states that SCVP servers must be able to parse requests that 
include attribute certificates.  However, a conforming SCVP server may 
simply return an error message in response to any request that includes 
attribute certificates.  The checks item in a request that includes 
attribute certificates would need to include at least one check 
associated with attribute certificates and section 3.2.2 states that 
SCVP server implementation are not required to support the attribute 
certificate checks.  So, a conforming SCVP server that does not support 
attribute certificates could simply return an error message with a 
response status of "unsupported checks" in response to any request that 
includes attribute certificates.  While the server would need to parse 
requests that include attribute certificates to do this, it would not 
need to parse the contents of the acRefs choice of CertReferences in 
order to generate the response.  That is why the text states that only 
servers that can process attribute certificates are required to be able 
to parse the attrCert and acRef choices in ACReference.

Since conforming SCVP server implementations are required to support 
some of the checks items associated with public key certificates, all 
conforming SCVP server implementations must be prepared to return 
responses where the response status is "okay" and thus the replyObjects 
item of the response includes responses for each certificate in the 
request.  Where the certificate is included by reference in the request, 
the server must at the very least be able to copy the reference from the 
queriedCerts item in the request to the cert item in the response.  SCVP 
servers that do not process certificates that are included by reference 
in the request would simply copy the reference into the response and 
return a "referenceCertHashFail" error for that certificate indicating 
that the server could not locate the referenced certificate.

Dave

Peter Sylvester wrote:

> Tim Polk wrote:
>
>> Peter, Sam, and Denis,
>>
>> I believe that we want to ensure that SCVP servers can parse 
>> requests, even if they include certificate types that aren't support 
>> (e.g., attribute types), or certificates are referenced using an 
>> unsupported mechanism (e.g., certificate hash). I agree the current 
>> text is unclear and also think that attribute certificates are not 
>> covered comprehensively.
>