[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