|
Dear list,
The following are my comments to SCVP
17.
Wen-Cheng Wang
1. Typo in the last sentence of the last
second
paragraph of page 67: "Therefore in
these situations use of a URI
many be more attractive." -> "Therefore, in these situations use of a URI may be more attractive." ("many be" -> "may
be")
2. I suggest to let the version filed of request and response messages default to v1(1). That is:
cvRequestVersion
INTEGER,
-> cvRequestVersion INTEGER DEFAULT v1(1),
cvRsponseVersion
INTEGER
-> cvRsponseVersion INTEGER DEFAULT v1(1),
vpRequestVersion
INTEGER,
-> vpRequestVersion INTEGER DEFAULT v1(1), vpRsponseVersion INTEGER -> vpRsponseVersion INTEGER DEFAULT v1(1), By doing this, the DER code of
every request and
response message will save 3 bytes. I believe that the SCVP version will stay at v1 for a long time, asigning default value will allow clients and servers do not bother to send the version number in their requests and responses. Note that when a field become
a field with DEFAULT
value, it might need change to a tagged field. 3. The tagging rule for ASN.1 syntax is
odd. I list
the following as oddness: (1) In the
"ValidationPolicy" data type, the
tag
numbers skip from [4] to [6]. (There is no tag [5].) (2) In the "CVResponse" data type, the tag numbers skip from [3] to [5]. (There is no tag [4].) I know that the editors of
SCVP ID do not like to
discuss ASN.1 stylistic change, but the fix is simple. 4. I notice that SCVP 17 newly invented the
term
"end certificate". Personally, I understand what you mean by "end certificate" because I have been tracking this ID for a long time. However, I am worrying that using the term "end certificate" might cause confusion because it might have different interpretation for different direction of path construction (forward or reverse). As a technical spec, SCVP should be more precise in adopting technical term. Therefore, I suggest to use the term "target certificate" instead, not only for eliminating possible confucion but also for keeping alignment with RFC 3379. In addition, to make a more
strong connection between
the term "target certificate" and the field of the query message, I further suggest to change the field name "queriedCerts" in the "Query" data type into "targetCerts". Of course, related statements that explain or refer to that field shoul also be modified in response to the changing of the filed name. 5. After reading SCVP 17, I finally
understand the
purpose of name validation algorithm. Before SCVP 17, I always thought it is used to specify the name matching rule (binary matching or X.500 name matching) during certificate chaining. Now I understand that it is use to specify the request for checking subject name of the "target certificate". If it is so, I think it is unreasonalbe to say: "The name
validation is a refinement of the basic
validation algorithm" The basic validation algorithm
is an algorithm
specifying conditions and rules for validating the whole certification path. In terms of RFC 3379, the basic validation algorithm specifies "certification path requirements". On th contrary, the name validation algorithm only specifies the request for checking subject name of the "target certificate". In terms of RFC 3379, the so-called name validation algorithm is simply one of the "end-entity certificate specific requirements". (Now I prefer to call them "target certificate specific requirements".) It is much like "keyUsages" and "extendedKeyUsages" checks, which are also "target certificate specific requirements". To make the protocol more resonable and aligned with RFC 3379, I suggest to take "name validation algorithm" out of section 3.2.4.2 and group it with "keyUsages" and "extendedKeyUsages", because they all belong to the category of "target certificate specific requirements". 6. The current text of SCVP 17 tries to
define a
"global" default validation policy and tries to enforce all implementation to support that default validation policy. This notion of "default validation policy" does not align with the general understanding of "default validation policy". The default validation policy defined in SCVP 17 is actually simply a "basic" validation policy which adopts the basic path validation algorithm defined in RFC 3280, it is odd to specify it as the "global" default validation policy. The general understanding of "default validation policy" is the default one among the organizational validation policies. I suggest to change term "default validation policy" to "basic validation policy" to avoid confussion. With this distinction of the notion of "default validation policy" and the notion of the predefined "basic validation policy, we can clearly say that The SCVP server
can define multiple vlidation
policies and nominate one as its default policy. If the client does not select a validation policy in its request, the server will use the default validation policy. The SCVP server
MAY list the "basic validation
policy" defined in this specification as one of its supported validation policies. The SCVP server MAY select the "basic validation policy" as its default policy. Please note that I also
suggest that the
"validationPolicy" field in the "Query" data type should be changed to be an optional field. This allow the client to ommit the selection of the validation policy in its request and simply let the server use its default policy. 7. The title of section 1.3 is "validation
Policies", but
in the middle of that section it mentions: "The inputs to the
basic certification path processing
algorithm used by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise: Certificate to be validated (by value or by reference); Validation time; Set of Trust Anchors (by value or by reference); The initial policy set; Initial inhibit policy mapping setting; Initial inhibit anyPolicy setting; and Initial require explicit policy setting." Isn't it be odd to define
inputs to "validation
algorithm" in a section titled "validation policies"? It reveals that even the
authors of SCVP have no
good distinction between the notion of "validation policy" and the notion of "validation algorithm", no to say an implementator who try to implement SCVP. Even several reviewers (for
example Denis and I)
clearly express that the notion of "validation algorithm" is redundant to the notion of "validation policy" and can be removed, how strange it is that the authors always to reject the suggestions. Now, even with SCVP 17 which
authors says "the text
for validation policies, validation algoriothms and name validation algorithms has all been revised for clarity, the distinction still vague. I sugest to remove the notion
of "validation
algorithm" from SCVP, and change the text to: "The certification
path specific parameters to the
basic validation policy defined by this specification are defined by [PKIX-1] in its section 6.1.1 and comprise: Certificate to be validated (by value or by reference); Validation time; Set of Trust Anchors (by value or by reference); The initial policy set; Initial inhibit policy mapping setting; Initial inhibit anyPolicy setting; and Initial require explicit policy setting." 8. In th end of section 1.3, it
says:
"The basic certification path
processing algorithm
also supports the following parameters, which are defined in [PKIX-1] section 4: The usage of the key contained in the certificate (e.g., key encipherment, key agreement, signature); and Other application-specific purposes for which the certified public key may be used." Since "the basic certification
path processing algorithm"
is the algorithm defined in section 6 of RFC 3280, it is not proper to say that "the certification path processing algorithm" supports parameters related to checking key usages and extended key usage. Wee all know that the lgorithm defined in section 6 of RFC 3280 does not support these two kinds of parameters. I think the text will be more
proper if it is changed to:
"The basic validation policy
defined by this specification
also supports target certificate specific parameters for specifying the following checks: The key usages specified in the target certificate (e.g., key encipherment, key agreement, signature) are acceptable; The extended key usages specified in the target certificate are acceptable; and The subject name
or the subject alternative name
specified in the certificate meet the application-specific requirement." (Note that I move the name
validation requirement here.)
Again, this is a sign that the
distinction between
the notion of "validation policy" and the notion of "validation algorithm" in SCVP 17 is still vague. 9. I give the following comment before but
get no response,
so here I raise it again. There are situations where the
certificate-using
applications need to check whether a certificate was valid during a period of time, not only validate it with respect to a specific moment. For example, an application verifying an archived long-term signature might need to check whether a certificate was valid during a period of time in which the signature was generated. Therefore, I suggest to extend the structure of the "validationTime" field of the "Query" data type to support this. A CHOICE between a moment and a period of time is sufficient. To summarize the above comments, the "Query" needs to be changed to the following: (Of course, the related text in the ID
should also be
changed. However, at this moment, I simply use the following syntax to demonstrate my idea to editors and the list. If my proposal is accepted, then I will be happy to help revising the related text.) Query ::= SEQUENCE {
targetCerts CertReferences, checks CertChecks, wantBack WantBack, validationPolicy [2] ValidationPolicy OPTIONAL, responseFlags [3] ResponseFlags OPTIONAL, serverContextInfo [4] OCTET STRING OPTIONAL, validationTime ValidationTime OPTIONAL, intermediateCerts [7] CertBundle OPTIONAL, revInfos [8] RevocationInfos OPTIONAL, producedAt [9] GeneralizedTime OPTIONAL, queryExtensions [10] Extensions OPTIONAL } ValidationTime ::= CHOICE
{
moment [5] GeneralizedTime, period [6] ValidationPeriod} ValidationPeriod ::= SEQUENCE
{
start GeneralizedTime, end GeneralizedTime} ValidationPolicy ::= SEQUENCE {
validationPolRef ValidationPolRef, pathSpecificParams [1] PathSpecificParams OPTIONAL, targetCertSpecificParams [2] TargetCertSpecificParams OPTIONAL} PathSpecificParams ::= SEQUENCE
{
userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL, inhibitPolicyMapping [2] BOOLEAN OPTIONAL, requireExplicitPolicy [3] BOOLEAN OPTIONAL, inhibitAnyPolicy [4] BOOLEAN OPTIONAL, trustAnchors [6] TrustAnchors OPTIONAL} targetCertSpecificParams ::= SEQUENCE
{
keyUsages [1] KeyUsages OPTIONAL, extendedKeyUsages [2] SEQUENCE OF KeyPurposeId OPTIONAL, nameValidation [3] NameValidationAlgParms OPTIONAL} NameValidationAlgParams ::= SEQUENCE {
nameCompAlgId OBJECT IDENTIFIER, validationNames GeneralNames } -- SCVP Validation Policy and Algorithm
Identifiers
id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } -- SCVP Basic Validation Policy
Identifier
id-svp-basicValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } -- SCVP Basic Validation Policy Errors id-bvpe OBJECT IDENTIFIER ::= id-svp-basicValPolicy id-bvpe-expired OBJECT IDENTIFIER ::= { id-bvae 1 } id-bvpe-not-yet-valid OBJECT IDENTIFIER ::= { id-bvae 2 } id-bvpe-wrong-anchor OBJECT IDENTIFIER ::= { id-bvae 3 } id-bvpe-invalid-key-usage OBJECT IDENTIFIER ::= { id-bvae 10 } id-bvpe-invalid-purpose OBJECT IDENTIFIER ::= { id-bvae 11 } id-bvpe-revoked OBJECT IDENTIFIER ::= { id-bvae 16 } -- SCVP Name Validation Algorithm Identifier -- SCVP Name Validation Algorithm DN
comparison algorithm
id-nva-dnCompAlg OBJECT IDENTIFIER ::= { id-svp 4 } -- SCVP Name Validation Algorithm Errors id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg id-nvae-name-mismatch OBJECT IDENTIFIER ::= { id-nvae 1 } id-nvae-no-name OBJECT IDENTIFIER ::= { id-nvae 2 } id-nvae-unknown-alg OBJECT IDENTIFIER ::= { id-nvae 3 } id-nvae-bad-name OBJECT IDENTIFIER ::= { id-nvae 4 } id-nvae-bad-name-type OBJECT IDENTIFIER ::= { id-nvae 5 } id-nvae-mixed-names OBJECT IDENTIFIER ::= { id-nvae 6 } |