[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG Last Call: SCVP
See below.
-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
Sent: Friday, July 18, 2003 6:02 AM
To: Trevor Freeman
Cc: wpolk@xxxxxxxx; ietf-pkix@xxxxxxx
Subject: Re: WG Last Call: SCVP
Comments on draft-ietf-pkix-scvp-12.txt
Simple Certificate Validation Protocol (SCVP)
The following 8 issues have been suppressed since there are agreed:
9, 11, 12, 13, 16, 18, 19 and 23.
There remains 16 issues to be discussed. The original numbering has been
kept.
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 reference to 3379 to define validation
policy.
[Denis] Are you going to add a reference to section 7 from RFC 3379 ?
[Trevor Freeman] Actually, I now realise that a simple reference is not
going to work since the current use of validation policies in SCVP does
not cleanly map onto 3379 use of the term. I will redraft SCVP to clean
this up.
This text is copied below.
A validation policy is a set of rules against which the validation
of
the certificate is performed.
A validation policy MAY include several trust anchors. A trust
anchor is defined as one public key, a CA name, and a validity time
interval; a trust anchor optionally includes additional constraints.
The use of a self-signed certificate is one way to specify the
public
key to be used, the issuer name, and the validity period of the
public key.
Additional constraints for each trust anchor MAY be defined. These
constraints might include a set of certification policy constraints
or a set of naming constraints. These constraints MAY also be
included in self-signed certificates.
Additional conditions that apply to the certificates in the path MAY
also be specified in the validation policy. For example, specific
values could be provided for the inputs to the certification path
validation algorithm in [PKIX-1], such as user-initial-policy-set,
initial-policy-mapping-inhibit, initial-explicit-policy, or initial-
any-policy-inhibit.
Additional conditions that apply to the end-entity certificate MAY
also be specified in the validation policy. For example, a specific
name form might be required.
In order to succeed, one valid certification path (none of the
certificates in the path are expired or revoked) MUST be found
between an end-entity certificate and a trust anchor and all
constraints that apply to the certification path MUST be verified.
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.
[Denis] This does not solve my concern. A validation policy may also be
determined by a policy issuer, while means that there is no agreement
between the client and the server. The client wants to use a given
validation policy defined by a policy issuer. If the server supports it,
then it is fine. If the server does not support it, then the client
looks
for another server supporting it.
[Trevor Freeman]I will redraft this section and repost.
For the first of the sentence I would thus propose:
"The validation policy may be determined by the server, or any third
party."
For the second part of the sentence, we currently have:
", but it MUST be represented as an OBJECT IDENTIFIER."
I have proposed:
"The validation policy MUST be represented as an OBJECT
IDENTIFIER and optionally some additional parameters."
So the issue is whether we have or not "and optionally some additional
parameters"
This seems to be the reason of a disagreement on many of the other
points.
The validation policy does not only include the processing algorithms
but
also the values used by the processing algorithms to validate a
certificate.
The two possibilities, as I see them, are :
- the OID of the validation policy tells everything (i.e. both the
processing algorithms and all the values to be used by these processing
algorithms),
- the OID validation policy provides the processing algorithms and some
of
the values to be used, but some other values may be defined as
additional
parameters.
Please, reconsider my proposal.
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 requirement in 3379. Correct. However,
this
is a big advantage in the following case:
The RP wants to keep an archive of "YES" answers. If the values are all
signed, then the size of the archives will get pretty big since the same
CA
certificates and CRLs will be duplicated many times in every "YES"
answer.
If only the references are signed, then the values may be stored
elsewhere
and only once: the same values will be usable for thousands of
validations.
[Trevor Freeman] This is not a requirement 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.
[Denis] I do not think that you disagree on the second sentence:
" The intermediateCerts and revInfos items provide certificates or
revocation status information which MAY be useful to build the
response."
[Trevor Freeman] Wait for the redrafted version
You probably disagree on the first sentence. It is in fact incorrect.
I would thus propose the following:
"Either the valPolicy item alone or both the valPolicy and the
trustAnchors
items SHALL be used.
The rational is explained in issue 2.
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 covered by two requests, one for certificate
status and one DPD.
[Denis] This is not optimum, since this could be done by one request.
If this is done in two requests, this may be complicated because there
is no
assurance that the first DPD request will return the path used by the
DPV
request. So the client will have to test if the path that is returned is
the
right one and re-issue a PVD request until it the right one is returned.
If
you maintain two requests, these additional explanations would be
useful.
[Trevor Freeman] We are past optimisations. I am only considering
critical issues.
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.
[Denis] This relates to issue 2.
[Trevor Freeman] Wait for the redrafted version.
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.
[Denis] Maybe. If we keep it, then add the full certificate as another
possibility.
[Trevor Freeman] Please clarify. We already support returning the
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".
[Trevor Freeman] I have removed the second sentence and the word
"private" from the third sentence.
[Denis] This does not solve my concern. See issue 2.
[Trevor Freeman] I am redrafting this.
I would propose the following rephrasing:
" 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 it in combination with trustAnchors. The second
option
allows to define relatively simple validation policies".
[Trevor Freeman] agreed
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.
[Denis] As explained in issue 2, a validation policy must at least
define
one root key, so it is not true to say that it has no parameter.
[Trevor Freeman] Not true. Both the default policy and the Name
comparison policy do not define a trust root. The trust root must be
supplied in the request or the server chooses.
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 or the sever choose. You requirements are
accommodated by two requests, one for the end cert, and one for the CA
cert or define another algorithm.
[Denis] No. This would not solve my concern. The EESSI standards built
upon
the EU Directive ask for a given CP to be present in the end-entity
certificate, but place no such constraint on the CP from the CA
certificates. It would however be nice to be able to use the default
validation policy in such a case.
[Trevor Freeman] My previous answer still stands. Two requests using the
default policy meets your request.
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.
[Denis] Adding an explanation in the document like "This was asked for
at
IETF 56" would not be sufficient.
[Trevor Freeman] disagree. Its documented on the list along with
countless other issues not in RFCs.
:-)
I still do not understand. Please provide additional explanations in the
main body of the document (or delete).
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.
[Denis] I disagree. This is a DPD requirement. RFC 3379 states:
For the client to be confident that all of the elements from the
response originate from the expected DPD server, an authenticated
response MAY be required.
Signing takes time and resources. Please do not mandate the signing
operation.
[Trevor Freeman] We are conformant with 3379. The server decides and may
return a signed or unsigned response.
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
[Denis] You disagree but you do not provide a rational for it. Please
explain your position.
[Trevor Freeman] I don't think you assertion that the current text is
incorrect - is correct.
15. Section 4.4.1 requestHash, page 23. The text states: "However, the
requestNonce provides a better mechanism for matching requests
andresponses."
This is incorrect. Change into:
"While requestHash allows to detect that the request was modified, the
requestNonce parameter provides replay protection."
[Trevor Freeman] disagree
[Denis] You disagree but you do not provide a rational for it. Please
explain your position.
[Trevor Freeman] I don't think you assertion that the current text is
incorrect - is correct.
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.
[Denis] Maybe, but where from ? I would guess that this item is only
needed
to detect a loop when chaining is being used. If this is the case,
please
add such explanations and what the client SHALL do with it. If this is
not
the case, please add the appropriate explanations.
[Trevor Freeman] Since you are an author of 3379, I would expect you to
be better placed to answer why this is in 3379.
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
[Denis] See item 3.
[Trevor Freeman] See my response to item 3.
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.
[Denis] Fine. However, it would be nice to include this explanation in
the
document.
[Trevor Freeman] Agreed.
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.
[Denis] You disagree but you do not provide a rational for it. Please
explain your position.
[Trevor Freeman] Actually I have reconsidered this and have changed my
position and now will mandate that this will be signed.
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
OCSPserver
(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] Yes, this is not in RFC 3379 but this comes from an observation
made
after RFC 3379 was done and when the OCSPv2 draft was written. Please
take a
closer look at this issue.
[Trevor Freeman] disagree. The SCVP server MUST have the certificate to
build a response. This is a MUST in 3379.
Denis