Spencer Dawkins wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-pkix-scvp-31.txt
Reviewer: Spencer Dawkins
Review Date: 02 April 2007
IESG Telechat date: 05 April 2007
Summary: Basically ready for publication, with some questions about
2119 language and a couple of places where the text wasn't clear to
me, but should be fixable with an RFC Editor note for anything that
Russ agrees with.
Comments:
1.2 SCVP overview
Untrusted SCVP servers can provide clients the certification paths.
They can also provide clients the revocation information, such as
CRLs and OCSP responses, that the clients need to validate the
certification paths constructed by the SCVP server. These services
can be valuable to clients that do not include the protocols needed
Spencer (nit): I'm somewhat confused by "do not include" - is this
saying clients "do not implement the protocols needed ..."? For some
reason, this isn't as confusing in the first bullet below... perhaps
because one is talking about protocols and the other is talking about
software.
Editors' response: “do no include” could be changed to “do not implement”.
to find and download intermediate certificates, CRLs, and OCSP
responses.
Trusted SCVP servers can perform certification path construction and
validation for the client. For a client that uses these services,
the client inherently trusts the SCVP server as much as it would its
own certification path validation software (if it contained such
software). There are two main reasons that a client may want to
trust such an SCVP server:
1. The client does not want to incur the overhead of including
certification path validation software and running it for each
certificate it receives.
2. The client is in an organization or community that wants to
centralize management of validation policies. These policies
might dictate that particular trust anchors are to be used and
the types of policy checking that are to be performed during
certification path validation.
1.3 SCVP Requirements
SCVP meets the mandatory requirements documented in [RQMTS] for DPV
and DPD. When SCVP is used to support DPD, the same response is
Spencer: I'm somewhat confused by "the same response" - the same
response as what, exactly?
Editors' response: When SCVP is used to support DPD, the server returns
the constructed path in a response message with all of the requested
revocation information or an error. If some or all of the requested
information was unavailable, the server returns the same DPD error
response. That is, the error message does not differentiate between “no
status information was available”, or “missing one out of 12 CRLs”. The
PKIX DPD/DPV requirements document (RFC 3379) seemed to impose such a
requirement, but there was working group consensus that SCVP met the
WG's intent and that further differentiation for the error message was
not required.
That said, the editors' agree that the second sentence is unclear, and
propose deleting the offending sentence. Given the remaining text in
that section, the concept seems to be adequately addressed.
returned when a path is constructed, but some or all of the
revocation information is unavailable.
3.1 cvRequestVersion
The cvRequestVersion item defines the version of the SCVP CVRequest
used in a request. The subsequent response MUST use the same version
number. The value of the cvRequestVersion item MUST be one (1) for a
client implementing this specification. Future updates to this
specification must specify other values if there are any changes to
syntax or semantics. However, new extensions may be defined without
changing the version number.
SCVP clients MUST support asserting this value and SCVP servers must
be capable of processing this value.
Spencer: Hmmm. In most cases, this document has similar server
language as MUST (2119).
Editors' response: Agree that the “must” after “SCVP servers” should be
capitalized.
3.2 query
The query item specifies one or more certificates that are the
subject of the request; the certificates can be either public key
certificates [PKIX-1] or attribute certificates [PKIX-AC]. A query
MUST contain a queriedCerts item as well as one checks, and one
Spencer (Nit): correct as written but confusing - s/as one checks/as
one checks item/?
Editors' response: Agree to add the word “item” after “checks”.
validationPolicy item; a query MAY also contain wantBack,
responseFlags, serverContextInfo, validationTime, intermediateCerts,
revInfos, producedAt, and queryExtensions items.
3.2.2 checks
Conforming client implementations MUST be able to assert at least one
of the standard checks. Conforming clients MAY be able to assert
multiple checks. Conforming clients need not support all of the
checks defined in this section.
Spencer: I'm somewhat confused by "MUST/MAY be able to assert" - is
"be able to" really a 2119 requirement? I would be more comfortable
with "MUST support at least one of the standard checks" and "MAY
assert multiple checks".
Editors' response: How about “MUST support assertion of at least one of
the standard checks” and “MAY support assertion of multiple checks”?
3.2.3 wantBack
Conforming client implementations that support delegated path
validation (DPV) as defined in [RQMTS] SHOULD be able to assert at
least one wantBack. Conforming client implementations that support
delegated path discovery (DPD) as defined in [RQMTS] MUST be able to
assert at least one wantBack. Conforming clients MAY be able to
assert multiple wantBacks. Conforming clients need not support all
of the wantBacks defined in this section.
Spencer: same concerns about 2119 requirements to "be able to" do
something as expressed previously.
Editors' response: As above, how about “SHOULD support assertion of at
least one wantBack”, “MUST support assertion of at least one wantBack”,
and “MAY support assertion of multiple wantBacks”.
3.2.4 validationPolicy
Conforming SCVP servers MUST be able to process a ValidationPolicy
Spencer: "MUST be able to"... please see previous note on 2119
language like this
Editors' response: “MUST support processing of a ValidationPolicy that
contains any or all of the optional items.
that contains any or all of the optional items.
The validationAlg item specifies the validation algorithm. The
userPolicySet item provides an acceptable set of certificate
policies. The inhibitPolicyMapping item inhibits certificate policy
mapping during certification path validation. The
requireExplicitPolicy item requires at least one valid certificate
policy in the certificate policies extension. The inhibitAnyPolicy
item indicates whether the anyPolicy certificate policy OID is
processed or ignored when evaluating certificate policy. The
trustAnchors item indicates the trust anchors that are acceptable to
the client. The keyUsages item indicates the technical usage of the
public key that is to be confirmed by the server as acceptable. The
extendedKeyUsages item indicates the application-specific usage of
the public key that is to be confirmed by the server as acceptable.
The syntax and semantics of each of these items is discussed in the
following sections.
3.2.4.1 validationPolRef
Conforming SCVP client implementations MUST be able to specify a
Spencer: "MUST be able to"... please see previous note on 2119
language like this
Editors' response: How about “Conforming SCVP client implementations
MUST support specification of a validation policy.”
validation policy. Conforming SCVP client implementations MAY be
able to specify parameters for a validation policy. Conforming SCVP
server implementations MUST be able to process valPolId and MAY be
able to process valPolParams.
3.2.4.4 inhibitPolicyMapping
SCVP clients MAY support inhibiting policy mapping. SCVP servers
SHOULD support inhibiting policy mapping.
Spencer: Is there a reason why SCVP servers would not support
inhibiting policy mapping ("Why is this SHOULD not a MUST")? I have
this question for several of the SCVP server requirements, but won't
flag each one...
Editors' response: In order to be able to support inhibiting policy
mapping, a server must also support processing the policy mappings
extension. RFC 3280 says that conforming applications SHOULD be able to
process the policy mappings extension. Furthermore, 3280bis
(draft-ietf-pkix-rfc3280bis-08.txt) states that conforming
implementations SHOULD support inhibiting policy mapping. So, specifying
“SHOULD” instead of “MUST” aligns SCVP with RFC 3280 and 3280bis.
3.2.5.2 responseValidationPolByRef
SCVP clients and servers MUST support the default behavior. SCVP
Spencer (Nit): just for clarity, could you say "the default behavior
(X)"? I think "X" is "returning the validation policy by reference",
but I can identify at least a couple of flavors of this...
Editors' response: This sentence can be changed to read: “SCVP clients
MUST support requesting and processing the validation policy by
reference and SCVP servers MUST support returning the validation policy
by reference.”
clients MAY support requesting and processing the validation policy
by values. SVCP server SHOULD support returning the validation
policy by values.
3.2.9 revInfos
Clients SHOULD be courteous to the SCVP server by separating CRLs and
delta CRLs. However, since the two share a common syntax, SCVP
servers SHOULD accept delta CRLs even if they are identified as
regular CRLs by the SCVP client.
Spencer: why isn't the server SHOULD a MUST?
Editors' response: SCVP servers are permitted to ignore information
provided by the client in revInfos. In most cases, the server will
maintain its own cache of status information; requiring processing of
client supplied status information would be wasteful. Since processing
is optional, requiring support for mis-identified delta CRLs should also
be optional.
3.6 responderName
The optional responderName item is used by the client to indicate the
identity of the SCVP server that the client expects to sign the SCVP
response if the response is digitally signed. The responderName item
SHOULD only be included if:
Spencer: this doesn't seem like a 2119 SHOULD.
Editors' response: If the responderName is asserted, this indicates the
client will only accept responses from that server. If a client
indicates it will accept unprotected responses, it is indicating that
the identity of the SCVP server is not important. When both conditions
are true, this would seem to be a conflict.
This SHOULD statement ensures that the client's security expectations
are consistent and unambiguous. There is a potential for negative impact
on interoperability where this SHOULD is ignored: for example, an
authenticated request specifies the responder in the protection
mechanisms (e.g., in the CMS encapsulation), so the responderName is
redundant but potentially conflicting information.
The editors would prefer to preserve this as a 2119 SHOULD.
1. the request is either unprotected or digitally signed (i.e., is
not protected using a MAC); and
2. the responseFlags item is either absent or present with the
protectResponse set to TRUE.
4.9.3 replyValTime
The information in the CertReply item MUST be formatted as if the
server created this portion of the response at the time indicated in
the validationTime item of the query. However, if the server does
not have appropriate historical information, the server MAY either
return an error or return information for a later time.
Spencer: do you guys have deployed servers that exhibit both of these
behaviors? If you could pick one, or even recommend "return
information for a later time if available, or an error if no
information is available", it would give client a better understanding
of what's going on - the current specification allows you to return an
error even if a later time is available, for instance.
Editors' response: Servers will often exhibit both behaviors. A server
may satisfy a request for historical validation for an unexpired
certificate using the most current status information. For expired
certificates, the Server may not be able to determine the status beyond
“expired”, which is not useful to the client, so the server needs to
return an error.
4.9.5 replyWantBacks
The octet string value for the proof of revocation status, { id-swb 2
}, contains the RevInfoWantBack type. The RevInfoWantBack type is a
SEQUENCE of the RevocationInfos type and an optional CertBundle. The
syntax and semantics of the RevocationInfos type are described in
section 3.2.9. The CertBundle MUST be included if any certificates
required to validate the revocation information were not returned in
the id-swb-pkc-best-cert-path or id-swb-pkc-all- cert-paths want
back. The CertBundle MUST include all such certificates but there
Spencer: Mumble. isn't "want back" wantBack? I'm very confused by the
trailing blank in the id name and am not entirely sure what the
sentence actually says ... probably easily fixable by someone who
understands the technology, just not by me.
Editors' response: All instances of “want back” can be replaced with
“wantBack” if this will improve readability.
are no ordering requirements.
The octet string value for returning all paths, { id-swb 12 },
contains an ASN.1 type CertBundles, as defined below. The syntax and
semantics of the CertBundle type are described in section 3.2.8.
Each CertBundle includes all the certificates in one path, starting
Spencer (Nit): s/starting/starting with/?
Editors' response: OK.
the end certificate and ending with the certificate issued by the
trust anchor.
The octet string value for the proof of revocation status of the
path's target certificate, { id-swb-13 }, contains the
RevInfoWantBack type. The RevInfoWantBack type is a SEQUENCE of the
RevocationInfos type and an optional CertBundle. The syntax and
semantics of the RevocationInfos type are described in section 3.2.9.
The CertBundle MUST be included if any certificates required to
validate the revocation information were not returned in the id- swb-
pkc-best-cert-path or id-swb-pkc-all-cert-paths want back. The
Spencer: same comment on wantBack as above. There are more instances,
but I'll stop flagging them.
Editors' response: See above.
CertBundle MUST include all such certificates but there are no
ordering requirements.
6 Validation Policy Response
In response to a ValPolRequest, the SCVP server provides a
ValPolResponse. The ValPolResponse MAY not be unique to any
Spencer: this is probably a lower-case (non-2119) "may".
Editors' response: See above.
ValPolRequest, so may be reused by the server in response to multiple
ValPolRequests. The ValPolResponse also has an indication of how
frequently the ValPolResponse may be reissued. The server MUST sign
the response using its digital signature certificate. When a
ValPolResponse is encapsulated in a MIME body part, it MUST be
carried in an application/scvp-vp-response MIME body part.
6.12 responseTypes
responseTypes allows the server to publish the range of response
types it supports. Cached only means the server will only return
cached responses to requests. Non-cached only means the server will
return a specific response to the request, i.e., containing the
requestor's nonce. Both means the server will return either,
depending on the request.
Spencer (Nit): "both" means "either"? Perhaps the value could be
called "either"? :-)
Editors' response: A responseType of “both” means that the server
supports both cached and non-cached response types and will return
either a cached or non-cached response depending on the request. We can
reword the final sentence to say that.
9 Security Considerations
Clients MUST verify that the response matches their original request.
Clients need to ensure that the server has performed the appropriate
checks for the correct certificates under the requested validation
policy for the specified validation time, and that the response
includes the requested want backs and meets the client's freshness
Spencer (Nit): wantBacks?
Editors' response: See above.
requirements.
SCVP does not include any confidentiality mechanisms. If
confidentiality is needed, it can be achieved with a lower-layer
security protocol.
Spencer: any recommendation here? If you could call out TLS, that
might be helpful, for instance.
Editors' response: We can add "such as TLS" to the send of the second
sentence.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
