Subject: [Gen-art] Gen-ART review of draft-ietf-pkix-scvp-31.txt

From: Spencer Dawkins <[email-masked]>
Date: Mon, 02 Apr 2007 19:54:31 -0500

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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 Apr 2007 22:21:58 -0400

Russ is an author so he cannot hold a discuss on this document.

I'd appreciate it if the authors/pkix working group could respond to
all of Spencer's comments as last call comments.

I consider the following comments blocking

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".

And the similar versions of that comment.

I do not consider the request to evaluate must/should for server
requirements to be blocking.

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 20 Apr 2007 18:03:15 -0400

Spencer Dawkins wrote:
> 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
>
> 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”.
> 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.
> 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.
> 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”.
> with "MUST support at least one of the standard checks" and "MAY 
Editors' response: How about “MUST support assertion of at least one of 
the standard checks” and “MAY support assertion of multiple checks”?
> 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”.
> 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.
> 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.”
> 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.
> 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.”
> 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.
> 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.
> 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.
> 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.
> Spencer (Nit): s/starting/starting with/?
Editors' response: OK.
> Spencer: same comment on wantBack as above. There are more instances, 
> but I'll stop flagging them.
Editors' response: See above.
> Spencer: this is probably a lower-case (non-2119) "may".
Editors' response: See above.
> 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.
> Spencer (Nit): wantBacks?
Editors' response: See above.
> 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.