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.