[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG Last Call: SCVP
Please see below.
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.
[Trevor Freeman] I have added a refernce to 3379 to define validation
policy.
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.
[Trevor Freeman] I have removed the word private.
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.
[Trevor Freeman] This is not a requirment in 3379.
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."
[Trevor Freeman]I disagree since the validation policy alone is not
enough. 3379 does not require that the validation policy and the
parameter used with that policy are represented by a single OID.
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,
[Trevor Freeman] This is covered by a certificate status request.
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)
[Trevor Freeman] This is coved by two requests, one for certificate
status and one DPD.
Note : certificate values or associated revocation status information as
a
signed parameter are not needed when using the two alternatives above.
[Trevor Freeman] This is not a requirement in 3379. The client is at
liberty to ignore the signature.
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.
[Trevor Freeman] This reduces the footprint of a simple client.
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".
[Trevor Freeman] I have removed the second sentence and the word
"private" from the third sentence.
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.
[Trevor Freeman] the default policy has no parameters - it is a set of
rules as per 3379.
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.
[Trevor Freeman] This is not a requirement for 3379. The trust anchors
are specified in the request. You requirements are accommodated by two
requests, one for the end cert, and one for the CA cert.
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.
[Trevor Freeman] This was asked for at IETF 56 as an example for another
validation policy
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.
[Trevor Freeman] agreed
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.
[Trevor Freeman] This is not a requirement in 3379. The client can
ignore the signature.
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
[Trevor Freeman] Agreed typo
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."
[Trevor Freeman] agreed
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.
[Trevor Freeman] agreed. There is now a RequestRefHash value in the
query.
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."
[Trevor Freeman] disagree
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."
[Trevor Freeman] disagree
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."
[Trevor Freeman] agree
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.
[Trevor Freeman] This is a requirement of 3379.
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."
[Trevor Freeman] agree
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".
[Trevor Freeman] agree
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.
[Trevor Freeman] disagree
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."
[Trevor Freeman] Disagree. If the client wants all the parameters used
with the validation policy, then they can ask for the request to be
included in the response.
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.
[Trevor Freeman] Disagree.
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.
[Trevor Freeman] agreed
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
}
[Trevor Freeman] Disagree. This is not a requirement in 3379.
Denis