Subject: Technical comments on SCVP Draft 15

From: "David A. Cooper" <[email-masked]>
Date: Fri, 13 Aug 2004 16:38:48 -0400

All,

Tim Polk asked me to review SCVP draft 15 in the hope of obtaining the
perspective of someone who has not read RFC 3379 nor any of the
preceding SCVP drafts.  So, I read through draft 15 and prepared a set
of technical and editorial comments.  The technical comments are
below.  I will send the editorial comments directly to the editors.

Dave

Technical comments on
draft-ietf-pkix-scvp-15.txt:

General Comment: The document needs to clarify
the differences/relationships between validationAlg (3.2.12) and
validationPolRef (3.2.21) in the request and valPolResponse (4.11) and
validationPolRef (4.? - no section).

Assuming that the
ValidationPolRef can be a single reference specifying all the
contents of ValidationPolicy, then it is a superset of validationAlg.
Why is validationAlgorithm mandatory in the request? If you specify
a ValidationPolRef you wouldn't seem to need it.

When are valPolResponse
and validationPolRef included in a response? Could both appear?

If the server includes
valPolResponse, the validationAlgorithm is a mandatory field. If the
server includes certReply, valAlg is a mandatory field for every
cert. What if they conflict?

Section 3: In the ASN.1, there are comments
indicating that SignedAttributes and AuthAttributes are required in the
SignerInfo and AuthenticatedData structures, respectively. What
attributes are required?

The new syntax for CertReference (below) makes it
difficult to distinguish between a public key certificate and an
attribute certificate. When the ESSCertID method is chosen, it will not
be possible to determine whether a public key or attribute certificate
has been referenced until the certificate has been obtained and parsed.
Even if the certificate is included, it will have to be at least
partially parsed before it can be determined what type of certificate
it is. Why were the tags in ACReference changed from [3] and [4] to [1]
and [2]?

CertReference
::= CHOICE {

pkc PKCReference,

ac ACReference }

PKCReference
::= CHOICE {

cert [1] Certificate,

pkcRef [2] ESSCertID }

ACReference
::= CHOICE {

attrCert [1]
AttributeCertificate,

acRef [2] ESSCertID }

Sections 3.2.1, 3.2.2, and 3.2.3: Can the
queriedCerts item in a single request include both public key and
attribute certificates? There is nothing in section 3.2.1 that suggests
otherwise. However, in sections 3.2.2 and 3.2.2, each of the checks and
want backs defined is specific to either a public key certificate or an
attribute certificate. If the server must respond to each check and
want back for each certificate in the queriedCerts item, this would
suggest that a single query can not include both types of certificates.
An alternative would be for the server's response for each certificate
to only include responses to those checks and want backs that are
relevant to for the given type of certificate, however the
specification does not indicate that this is acceptable.

Section 3.2.9 states “If the client does not care
it MUST omit the Boolean.” However, the isCA flag is not OPTIONAL. isCA
may be either TRUE or FALSE, but may not be omitted.

Sections 3.2.6 through 3.2.8: Should
inhibitPolMap, requireExplicitPol, ignoreAnyPol also be OPTIONAL?
Otherwise, how can we indicate that we use the server’s default or
specify these values using the validationAlg or validationPolRef?

Section 3.2.9:

What is the purpose of the isCA flag?

Under what circumstances would the client
need to know whether the referenced certificate is a CA? Isn't it
sufficient to check that the certificate has the appropriate key usage,
extended key usage, policy, etc.? (NOTE: The cA field of the
basicConstraints extension indicates “if the certified public key may
be used to verify certificate signatures.” So, if the cA flag is TRUE,
then the certificate subject is a CA. However, a cA flag set to FALSE
or an absent basicConstraints extension does not mean that the
certificate subject is not a CA. It merely indicates that the subject
public key in this certificate may not be used to verify
certificate signatures.)

How should the isCA flag be set (and/or
interpreted) if the referenced certificate is an attribute certificate?

Section 3.2.12.2:

This section is not clear. If the name
validation algorithm is specified, is the server expected to validate
the certificate according to the rules specified for the default
validation algorithm in addition to comparing the names?

Why is name comparison a considered to be a
validation algorithm? Why isn't this treated the same way are keyUsage
or extendedKeyUsage?

What is the reason for the KeyPurposeID?
Aren't the name matching rules for DNs, email addresses, DNS names,
etc. the same no matter what protocol is being used?

If an email address is supplied, is the
server required to look in both the subjectAltName extension for the
subject field (in an emailAddress attribute) for the email address.

Where the text states “all names MUST be ...
valid according to the name matching rules requested.” Does this mean
that all of the names must appear in the certificate (i.e., that each
name in the request must match a name in the certificate, when the
specified name comparison rules are used).

Section 3.2.14 states:

The
OPTIONAL certPolicies item specifies a list of policy identifiers
that the SCVP server MUST use when forming and validating a
certification path that terminates at the associated trust anchor. If
certPolicies is not specified, then any-policy MUST be used.

Is there an implicit
assumption here that requireExplicitPol will be set to TRUE if
certPolicies is included?

Section 3.2.15: The intermediateCerts is of type
CertBundle. Shouldn’t CertBundle be defined as SEQUENCE SIZE (1..MAX) OF Certificate
instead SEQUENCE SIZE (1..MAX) OF
PKCReference? If a server rec’d the ESSCertID choice of
PKCReference for the intermediateCerts, this implies the server would
already have the certificates. In this case, we didn’t need this field!

Section 3.2.17: Note we assume this applies only
to the end certificate. Even with this clarification, this section
needs to provide more information on how the match is performed.
Specifically:

If more than one bit is set by the client, do
all of these bits need to be set in the key usage extension in the
certificate?

What if there is no key usage extension in
the certificate? Does this constitute an automatic match?

Section 3.2.18: Basically the same questions and
assumptions as for key usage:

If the request includes more than one OID,
must all OIDs be present in the certificate?

What if there is no extended key usage
extension in the certificate? Does this constitute an automatic match?

If the extended key usage extension is
present and includes the anyExtendedKeyUsage OID, does this constitute
an automatic match or do the OIDs in the request need to be explicitly
asserted in the extension?

Section 3.2.21:

Why is there a mandate to do a binary
comparison between policy references? If two URIs match according to
the standard matching rules for that type of URI (e.g., case
insensitive match), why wouldn't that be acceptable?

Does the URI represent a human
readable definition of the policy or does it point to a human
readable definition?

Section 4: Don't these two sentences contradict
each other?

The
inclusion of policies in the SigningCertificate attribute is also
OPTIONAL. The policies item in the SigningCertificate attribute SHALL
not be present.

Section 4: I don't understand what the sentence
below means. More explanation is needed.

The
value of the message-digest attribute in the signedAttrs within
SignerInfo MAY be used as an identifier of the response generated by
the SCVP server.

Section 4: The statement below contradicts
section 3.4.

The
requestNonce item MUST be included if the request included a
requestNonce item.

Section 4.1 needs more explanation.

Is the svcpVersion
number in the response required to match the scvpVersion number in the request
(if the server can process that version of SCVP)?

If the svcpVersion
number in the request is higher than the highest version number that
the server can process, is the server required to send an error
response? Should the svcpVersion
number in the response be the highest version number that the server
can process?

Section 4.4: This sentence needs to be re-written
since there is no requirement to sign DPD responses if the SignResponse flag in the request
is FALSE.

Status
codes 0-9 are reserved for codes where the request was processed by
the server and therefore MUST be sent in a signed response.

Section 4.7: What is the reason for the responder
item? How is it used? It is included in the response but of only of
local significance? Perhaps this for retrospective audit trail lookups?

Section 4.8.1: Does the contents of the cert item in the response need to
match the contents of the corresponding certificate from the queriedCerts item in the request?
This is, if the request includes a Certificate,
does the response also need to include a Certificate rather than an ESSCertID? If the request
includes an ESSCertID, does
the response need to include an ESSCertID
rather than a Certificate?

The
cert item contains either the public key certificate or the attribute
certificate or a reference to the certificate about which the client
is requesting information.

Section 4.8.2: Why aren't the errors below responseStatus errors? Since each
of these applies to every certificate, making it a replyStatus means repeating the
same error for every certificate in the query rather than just
specifiying the error once.

5 Failure: the
certificate policy OID is not recognized

6 Failure: the validation
policy
algorithm OID is not recognized

7 Failure: the extension
OID is not recognized

Section 4.8.2: The conditions that would lead to
one of the error values below should really result in a ReplyStatus of success (0) since “a definitive
answer follows”. The definitive answer that follows will be that no
valid path could be constructed (e.g., in ReplyChecks and/or replyWantBacks).

10
Failure: no certification path could be constructed

11
Failure: the constructed certification path is invalid

12
Failure: the constructed certification path is invalid, but a
query at a later time may be successful

Section 4.8.4: In responses to {id-stc 3}, {id-stc 6}, and {id-stc 7}, what is the
difference between Unknown (2) and Unavailable (3)?

Section 4.8.4 and 4.8.5: The reply check {id-stc
1} (simple validation processing with no status checking) or {id-stc 2}
(but with the Revoked, Unknown, and Unavailable responses being
condensed down to FALSE) would seem to correspond to the wantback for
public key certificate status, { id-swb 3 }.

We should eliminate
the
wantback (or clarify the difference!)

Section 4.8.5: Same question as above. How does
wantback { id-swb 8 } differ from the corresponding check item { id-stc
7 }? Why is it needed?

Section 4.8.6: Is valAlg required to match the
validationAlg specified in the request or can the server choose a
different validation algorithm?

Section 4.8.7: Should the nextUpdate item be included if
the validation time is not the current time?

Section 4.11: More information needs to be
provided about what information can be implicitly specified by a ValidationPolRef. This section
seems to indicate that things such as the value for inhibitPolMap can be part part of
the definition of a policy reference. However, section 3.2.21 states
that a server must return an error if there a a discrepency between the
policy reference and the contents of the request and inhibitPolMap is not an optional
item in the request. So, if the value for inhibitPolMap is specified in the
policy referrence, the client will be forced to specify the same value
for this boolean in its request in order to avoid an error response,
making its inclusion as part of the definition of the policy reference
useless. Is a ValidationPolRef
limited to defining values for the parameters specified in ValPolicy in section 4.11?

Section 4.13.1: paragraph 1 sentences 2 through 4
are confusing.

It
is an implementation decision how
the keys are stored. This can be accomplished by cryptographic hashes
of public keys used to sign signedData responses. It could also be
shared symmetric keys used to HMAC authenticatedData responses.

Could
we replace these three sentences with:   Mechanisms for storage
of server keys or identifiers is a local matter. For example, a
client could store cryptographic hashes of public keys used to verify
signedData responses. Alternatively, a client could store shared
symmetric keys used to HMAC authenticatedData responses.

Section 5: What is the meaning of the svcpVersion in the request? Is it
the highest version number that the client supports?

Section 6.1: Does the svcpVersion number in the
response need to match the svcpVersion
number in the request? If the highest version that the server can
process is lower than the version specified by the client, should it
specify the highest version number that it can process? If the version
specified by the client is lower than the highest version number that
the server can process, is the server required to respond with a
version number equal to that in the request?

Section 6:

Is validationPolicies
the set of ValidationPolRef
that the server supports, whereas defaultValPol
is the validation policy used if none is specified? The validationPolices item is not
defined in this section.

What is authDataCert?
It is not defined.

Section 9: Section 6 states that the policies
response MUST be signed. This conflicts with the seventh paragraph in
the Security Considerations:

The
request and response for which policies are supported on the server
are unsigned. These could lead to a denial of service attack where a
man-in-the-middle indicates that a server supports a different set of
validation policies than it actually does. This could result in the
client requesting validation based on a policy the server does not
support or lead the client using a less desirable policy.

Perhaps
we can delete this text from security considerations?