draft-ietf-pkix-scvp-12.txt

["Frank Balluffi" <frank.balluffi@xxxxxx>]

I reviewed draft-ietf-pkix-scvp-12.txt and have the following comments, many of which are typos related to earlier draft changes. The following numbering scheme is used:

section[/paragraph[/sentence]]

general comment: scope of extensions

CVRequest's reqExtensions and CVResponse's respExtensions pertain to the entire request and response.

A CVRequest has one Query containing queryExtensions. So queryExtensions really pertain to the entire request (not to an individual queriedCerts item), yet a CVResponse may have many certReplyExtensions elements (not certReplyExtensions items), each of which pertains to a CertReply (not the entire response). [Take deep breath.] One might describe this as an impedance mismatch. BTW, this characteristic goes back to early drafts.

One possible "solution" would be to add a type named something like CertRequest and move queryExtensions from Query to CertRequest. For example:

Query ::= SEQUENCE {
    queriedCerts        SEQUENCE SIZE (1..MAX) OF CertRequest, -- Was CertReference.
    ...
    revInfos        [5] RevocationInfos OPTIONAL
    -- queryExtensions was moved to CertRequest.
}

CertRequest ::= SEQUENCE {
    certReference             CertReference,
    certRequestExtensions [1] Extensions OPTIONAL -- Was Query's queryExtensions.
}

I think I got that right.

1.3/2/3 nit: I would insert "are" before "likely".

3/1 "SCVPRequest" should be "CVRequest".

3/3/1 I think I understand the use of certValRequest, but because it is not defined, it might confuse some readers.

For me, the following ContentInfo adds confusion, not clarity:

ContentInfo {
    contentType id-ct-scvp-certValRequest, -- (1.2.840.113549.1.9.16.1.10)
    content     CVRequest }

As page 6 shows ContentInfo containing SignedData (or AuthenticatedData) containing EncapsulatedContentInfo containing OCTET STRING containing CVRequest, which is very clear, but a little different. For reference, RFC 2630 says:

ContentInfo ::= SEQUENCE {
    contentType          ContentType,
    content [0] EXPLICIT ANY DEFINED BY contentType
}

EncapsulatedContentInfo ::= SEQUENCE {
    eContentType          ContentType,
    eContent [0] EXPLICIT OCTET STRING OPTIONAL
}

This comment also applies to section 4.

3.2/2 nit: CertChecks and WantBack defintions (unnecessary level of indirection)

Because CertChecks and WantBack only appear one time in the ASN.1 module, why not just put SEQUENCE ... OF ... in Query. This is how Query's queriedCerts is defined.

3.2/2: The body of the document shows Query's valPolicy element as mandatory, yet the ASN.1 module (section 8) shows the element as OPTIONAL.

3.2.1 nit: lots of CHOICEs

CertReference's use of three CHOICEs is a lot of work. How about:

CertReference ::= CHOICE {
    cert     [1] Certificate,
    pkcRef   [2] ESSCertID,
    attrCert [3] AttributeCertificate,
    acRef    [4] ESSCertID
}

RevocationInfo uses this technique for two types of CLRs.

3.2.2/2 clarity

I do not understand "Revocation status checking inherently includes ..." Does this mean path validation includes path building, and revocation status checking includes path building and path validation? I believe that revocation status checking is a superset of path validation is a superset of path building. This needs to be "spelled out" very clearly.

3.2.3/1 clarity

If I understand this correctly, you might want to add that each wantBack item applies to all queriedCerts items.

3.2.5.1/1/2 typo: "use to" should be "to" or "to use to".

3.2.5.1/2 typo: KeyPurposeID should be KeyPurposeId (note case).

3.2.5.1/3/1: typo: "sting" should be "string".

3.2.5.2/2/1: typo: "Name mismatch" should be "NameMismatch".

3.2.5.2/4: typo: "KeyPurposeID" should be KeyPurposeId".

3.2.5.2/5: typo: "and empty" should be "an empty".

3.2.6/1/3: typo: "the using" should be "the checks using".

3.2.6/2: nit: "expressed Greenwich" should be "expressed in Greenwich".

This comment also applies to section 4.2.

3.2.7/3 inclusion of trust anchor in response

I am surprised that the certifiation path MUST NOT include the trust anchor. I recognize the efficiency of this, but am concerned about the ability to audit a system using this technique.

If a client sends more than one trust anchor in its request, how easy is it for an auditor to determine which trust anchor was used? I would expect the server to send the client a path which includes the trust anchor and for the client to log the "complete" path. Am I missing something?

3.2.10/1/5 typo: "and each of extension" should read "and each extension".

4.3 What is the difference between badSignature and invalidSignature?

Status code 12 is not described. The description of status code 23 includes the no-longer-used type RequestSignature.

4.4 The heading "requestReference" should be "requestRef".

4.4.1

Why define HashValue when lots of developers already have implementations of PKCS #1 DigestInfo?

4.4.2/2 typo: "PSRequest" should be "CVRequest".

4.5 typo: The heading "Requestor" should be "requestor".

4.7/2/1 nit: "for each queriedCerts item" might be clearer than "for each Query item".

4.7.5 The heading "replyWantBack" should be "replyWantBacks". This also occurs in the first paragraph.

4.7.6 confusion

If a server uses the default validation policy, how can it comply with the following:

"The valPolicy value MUST NOT be id-svp-defaultValPolicy."

CertReply's valPolicy is mandatory.

4.7.8/1/2 typo: "singleReplyExtensions" should be "certReplyExtensions".

8 The ASN.1 module needs to import CertificateList and OCSPResponse -- I validated it using a compiler.

Appendix B nit: Does not include descriptions for validation policies request and response.

Frank


--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.