Subject: SCVP: Certificate value & ESSCertID (minor)

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 24 Feb 2006 14:41:02 +0100

The text states :

   PKCReference ::= CHOICE {
       cert              [0] Certificate,
       pkcRef            [1] CertID }

   Conforming SCVP Server
   implementations MUST be able to parse CertReferences with
   certificates referenced by both inclusion and CertID.

[Denis] Since there is a CHOICE, it is impossible to parse CertReferences 
With certificates referenced by both inclusion and ESSCertID.

Change the sentence with : 

   Conforming SCVP Server
   implementations MUST be able to parse CertReferences with
   certificates referenced by either inclusion or CertID.

---

From: Tim Polk <[email-masked]>
Date: Fri, 24 Feb 2006 17:26:17 -0500

Denis,

>With certificates referenced by both inclusion and ESSCertID.

[Tim] We *meant* to require servers to parse requests where some 
certificates were referenced by inclusion and others were referenced by CertID.

>    certificates referenced by either inclusion or CertID.

How about the following sentence instead?

         Conforming SCVP Server implementations MUST be able to
         parse CertReferences where some certificates are referenced
         by inclusion and others are referenced using CertID.

Tim Polk

---

From: Sam Hartman <[email-masked]>
Date: Fri, 24 Feb 2006 21:26:09 -0500

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

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

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 27 Feb 2006 13:56:51 +0100

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.

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

---

From: Tim Polk <[email-masked]>
Date: Mon, 27 Feb 2006 17:04:41 -0500

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.

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.

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.

>>     >> Conforming
SCVP Server

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Feb 2006 19:03:42 -0500

Works for me.