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.
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?
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).
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/?
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".
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.
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
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
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...
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...
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?
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.
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.
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.
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/?
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.
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".
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"? :-)
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?
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
