Subject: WG Last Call: SCVP

From: [email-masked]
Date: Tue, 8 Jul 2003 07:58:39 -0400

This message initiates working group Last Call for the Simple Certificate
Validation Protocol.

Last Call will run for (at least) two weeks. That is, Last Call will not 
close before July 22.

The URL for this Internet-Draft is:
  http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-12.txt 
 
The -12 draft includes minor enhancements to bring the specification into
full compliance with RFC 3379.
 
Thanks,

Tim Polk

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 15 Jul 2003 13:10:12 +0200

> full compliance with RFC 3379.

Comments on draft-ietf-pkix-scvp-12.txt
Simple Certificate Validation Protocol (SCVP)

As an answer to the last call, please find 24 comments on this document.

1. Section 1.3 Validation Policies

In this section the wording "validation policy" is used but is left 
undefined: "A validation policy can be used to specify the SCVP 
configuration." Please define it.

2. Section 1.3 Validation Policies. The text says: " The validation policy 
is determined by private agreement between the client and the server, ...". 
While this may be one case this is not the single case. Please delete and 
simply say: "The validation policy MUST be represented as an OBJECT 
IDENTIFIER and optionally some additional parameters.

3. In section 3, SignedData is defined with unsignedAttrs being not used. As 
it will be explained later on, unsignedAttrs should be used to carry 
unsigned certificate values, as well as unsigned revocation information 
(CRLs in particular) while the references (much shorter) will be signed. 
This has the major advantage of keeping the size of archived signed 
responses short.

4. Section 3.2. The text currently says on page 9: " The OPTIONAL valPolicy, 
trustAnchors, intermediateCerts, and revInfos items provide context for the 
client request."

This sentence should be replaced by the following:

"Either the valPolicy item or the trustAnchors item SHALL be used. The 
intermediateCerts and revInfos items provide certificates or revocation 
status information which MAY be useful to build the response."

5. Section 3.2.3  wantBack

More options should be allowed to return:

1)  only the references of both the certificates and the associated 
revocation status information for the path as a signed parameter,

2) both the references of both the certificates and the associated 
revocation status information for the path as signed parameter, and the 
certificate values together with the associated revocation status 
information as an unsigned attribute (see comment 3)

Note : certificate values or associated revocation status information as a 
signed parameter are not needed when using the two alternatives above.

It is unclear why *only* the "Public key from the certificate" should be 
returned. Either suppress this option, explain why it is sufficient or 
return the full certificate.

6. Section 3.2.5  valPolicy . The text says:

"  The valPolicy item, defines the validation policy to be used by the
    SCVP server during certificate validation.  The client can use this
    instead of specifying other SCVP configuration items such as
    trustAnchors.  The value of this item can be determined by private
    agreement between the client and the server, but it MUST be
    represented as an object identifier.  The server might want to
    assign identifiers that indicate that some settings are used in
    addition to others given in the request.  In this way, the
    validation policy object identifier can be a shorthand for some SCVP
    options, but not others".

Replace the whole with:

"  The valPolicy item, defines the validation policy to be used by the
    SCVP server during certificate validation.  The client MUST either
    use it or use trustAnchors which allows to define relatively simple
    validation policies".

7. Section 3.2.5  valPolicy . The text says: "All SCVP servers MUST support 
the default policy". This is fine. However, it is important that the client 
may know the parameters of the default policy when the default policy has 
been used by the server. So the default policy SHALL define its parameters.

In order to be able to use this protocol with Qualified Certificates (as per 
the European Directive on Electronic Signatures) certPolicies should further 
be subdivided in two categories: certPolicy for the end-entity certificate 
and certPolicies for CA certificates (currently CA certificates do not have 
certPolicies mandated as per the European Directive on Electronic Signatures).

It is thus propose to defined three parameters for the default policy:

  - trustAnchors,
  - certPolicy for the end-entity certificate,
  - certPolicies for CA certificates.

As mentioned in the text, revocation conditions include any source of 
revocation available.

8. Section 3.2.5.1 The need and the rational for this section could not be 
understood: an OID unambiguously identity a validation policy, a "name 
Validation Policy" or "Validation Policy name" (?) would not add anything.
Please explain or delete.

9. Section 3.3 Requestor. the text states: "The OPTIONAL requestor item is 
used to identify the requestor." Since there is no identification involved, 
change into: "The OPTIONAL requestor item is a reference local to the requestor.

10. Section 4 Validation Response. The text states: " An unsigned response 
MUST only be generated for an error status". This is contradictory with the 
preamble where it is said:

"SCVP can be used by clients that do much of the certificate processing 
themselves but simply want an untrusted server to collect information for them."

When simply collecting certification paths, responses do not need to be 
signed. Thus clients should have a way to indicate whether they want signed 
responses or not.

11. Section 4. there is an ASN.1 syntax error. Change

        signerInfos        SET OF SignerInfos } -- Only 1 in SCVP

into:

        signerInfos        SET OF SignerInfo } -- Only 1 in SCVP

12. Section 4, page 20, states: "The inclusion of policies in the 
SigningCertificate attribute is also OPTIONAL."

    SigningCertificate ::=  SEQUENCE {
        certs        SEQUENCE OF ESSCertID,
        policies     SEQUENCE OF PolicyInformation OPTIONAL

RFC 2634 states:

    The sequence of policy information terms identifies those certificate
    policies that the signer asserts apply to the certificate, and under
    which the certificate should be relied upon.

The added value of policies is doubtful. Replace with :
"The policies item in the SigningCertificate attribute SHALL not be present."

13. Section 4.4 requestReference, page 22. The requestRef allows the SCVP 
server to identify the request that corresponds to this response, but the 
client has now way to specify in his request whether he wants a hash of the 
request or the full CVRequest. This decision should not be at the discretion 
of the server, but chosen by the client. Please add a parameter to allow the 
client to make the choice.

14. Section 4.4 requestReference, page 22. The text states:"However, the 
requestNonce provides a better mechanism for matching requests and 
responses". This is incorrect. Change into:

"While requestRef allows to detect that the request was modified, the 
requestNonce parameter provides replay protection."

15. Section 4.4.1  requestHash, page 23. The text states: "However, the 
requestNonce provides a better mechanism for matching requests and responses."

This is incorrect. Change into:

"While requestHash allows to detect that the request was modified, the 
requestNonce parameter provides replay protection."

16. Section 4.5 Requestor, page 23. The text states: "The OPTIONAL requestor 
item is used to identify the requestor." This is incorrect. Change into:

"The OPTIONAL requestor item is a reference local to the requestor."

17. Section 4.6 responder, page 23. The text states: "The OPTIONAL responder 
item is used to identify the server." The rational for this parameter is not 
clear. In PKIX, the subject item from a certificate allows to identify a 
server. Since it is unrelated, it is very doubtful to have a value chosen by 
the client which has only local significance to the SCVP server. Please 
explain or delete.

18. Section 4.7.3 replyValTime, page 26. The text states: "The replyValTime 
item tells the time at which the information in the CertReply was correct."

This is incorrect. Change into:

"The replyValTime item tells the time at which the server processed the 
request."

19. Section 4.7.4 replyChecks, page 26. The text states: "The replyChecks 
item repeats the object identifier (OID) from the query and an integer". It 
would be more precise to say:

"The replyChecks item repeats the object identifier (OID) from the checks 
from the query and an integer".

20. Section 4.7.5 page 28. The text states:

   "The octet string value for the AC issuer certification path used to
    verify the certificate in the request, { id-swb 5 }, contains the
    CertBundle type.  The syntax and semantics of the CertBundle type
    are described in section 3.2.7."

As already mentioned, since

    CertBundle ::= SEQUENCE SIZE (1..MAX) OF PKCReference

and

      PKCReference ::= CHOICE {
        cert              [1] Certificate,
        pkcRef            [2] ESSCertID }

The client should be able to say in his request whether he wants back cert 
or pkcRef. If within the signed response he gets pkcRef, then he should be 
able to say that he wants CertBundle with the option cert as an unsigned 
attribute. The integrity of this unsigned parameter can easily be checked 
using the signed pkcRef.

21. Section 4.7.6 valPolicy, page 29. The text states: "The valPolicy value 
MUST NOT be id-svp-defaultValPolicy".

If the default policy has been used, then the client MUST be able to know 
which one it was: the default policy may vary with the time.

Change into:

"When the valPolicy value is id-svp-defaultValPolicy, then all the 
parameters from that policy MUST be returned."

22. Section 6 Validation Policies Response. The text states: "The response 
is not signed by the server". It would be nice to include a variant that 
would allow the response to be signed.

23. Section 9. Security Considerations. This section should import more text 
from RFC 3379 in particular:

    When no policy reference is present in the DPV request, the DPV
    client ought to verify that the policy selected by the DPV server is
    appropriate.

    The revocation status information is obtained for the validation
    time.  In case of a digital signature, it is not necessarily
    identical to the time when the private key was used.  The validation
    time ought to be adjusted by the DPV client to compensate for:

    1) time for the end-entity to realize that its private key has been
       or could possibly be compromised, and/or

    2) time for the end-entity to report the key compromise, and/or

    3) time for the revocation authority to process the revocation
       request from the end-entity, and/or

    4) time for the revocation authority to update and distribute the
       revocation status information.

24. Addition. At present, PKCReference is defined as:

       PKCReference ::= CHOICE {
        cert              [1] Certificate,
        pkcRef            [2] ESSCertID }

In OCSPv2 a third alternative, i.e. certIdWithSignature has been introduced. 
It would be interesting to be able to support it. It allows an OCSP server 
(and thus an SCVP server) to answer when it does not have access to the 
value of the certificate (in particular when it *only* uses CRLs in the 
background), whereas ESSCertID would be useless.

certIdWithSignature is a compact way to specify unambiguously a
certificate and to allow to verify a certification path.

    CertIdWithSignature ::= SEQUENCE {
         issuerandSerialNumber     IssuerandSerialNumber,
         tbsCertificateHash        BIT STRING,
         certSignature             CertSignature
    }

IssuerandSerialNumber is defined in [RFC3369] section 10.2.4.

tbsCertificateHash contains a hash value computed over the ASN.1 DER
encoded tbsCertificate field from the certificate using the hash
function identified in the signature algorithm from the signature.

certSignature contains the signature fields from the certificate.

    CertSignature ::= SEQUENCE {
         signatureAlgorithm        AlgorithmIdentifier,
         signatureValue            BIT STRING
    }

Denis