[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WG Last Call: SCVP




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

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