Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt

From: "Aram Perez" <[email-masked]>
Date: Mon, 28 Jun 1999 18:24:24 -0700

A few minor comments after a very cursory read:

1) I like the idea of SCVP but if the SCVP response is signed, how does the
client verify the signature if it can't handle certs?

2) Section 3.20 states "The CertID item has an identifier for the type of
certificate and the SHA-1 [SHA-1] hash of the octets of the certificate
itself." While I agree with specifying SHA-1 to *identify the certs*, I
recently got beat up on this mailing list because IETF is always supposed to
allow algorithm independence ;-)

3) Section 3.17 RequestNonce. Why is this field optional if requiring it
would prevent a well known attack? Ditto for changing the nonce with every
request.

4) Section 3.19 RequestSignature, 2nd paragraph. I would suggest rewording
it as "Requests MUST include a RequestSignature item unless the request is
done over an authenticated channel, such as..."

5) Section 3.23 KeyId. See comment 2.

6) Section 4.13 ResponseSignature. See comment 4.

7) Section 5 Tiny Syntax. More definition is needed specially for items that
are octets. For example, Version. Does 0x00 correspond to version 1 or
should the octet be 0x01? Another example, ExtensionCritical. Are only 0x00
and 0x01 allowed? Or does 0x00 mean FALSE and non-zero mean TRUE? Ditto for
TypesOfCheck and WantBack.

8) I think it would be helpful to add ASN.1 comments (Phil Griffin help).
For examples:
    FullRequest ::= SEQUENCE {
      version             Version,
        .
        .
      requestSignature    [3] Signature OPTIONAL
                                   -- Required on unauthenticated channels
    }

    CertID ::= CHOICE {
      pkixCert    [0] OCTET STRING, -- SHA-1 of X.509 certificate
      pgpCert     [1] OCTET STRING  -- SHA-1 of PGP certificate
    }

That's it for now,
Aram Perez

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working
> Group of the IETF.
>
>  Title  : Simple Certificate Validation Protocol (SCVP)
>  Author(s) :  A. Malpani, P. Hoffman
>  Filename : draft-ietf-pkix-scvp-00.txt
>  Pages  :
>  Date  : 25-Jun-99
>  
> The SCVP protocol allows a client to offload certificate handling to a
> server. The server can give a variety of valuable information about the
> certificate, such as whether or not it is valid, what the public key
> and subject of the certificate is, and so on.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-00.txt
[snip]

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 28 Jun 1999 18:49:23 -0700

>client verify the signature if it can't handle certs?

It has the public key of the server built-in without a cert. Remember, you 
don't need certs for root keys.

>allow algorithm independence ;-)

Not always. There is a tradeoff of multiple algorithms for safety (in case 
SHA-1 gets broken) versus complexity (having to include another identifier 
and having clients understand it). What do others think here? I hard-coded 
SHA-1 for simplicity.

>would prevent a well known attack? Ditto for changing the nonce with every

It didn't seem completely necessary, just Very Good, thus SHOULD instead of 
MUST. We're open to either.

>done over an authenticated channel, such as..."

That wording is equivalent to what we have, I think. I prefer SHOULD to 
"MUST with exceptions" as a stylistic choice.

>5) Section 3.23 KeyId. See comment 2.

Ditto.

>6) Section 4.13 ResponseSignature. See comment 4.

Ditto.

>should the octet be 0x01?

The latter. In the semantics section, we gave the decimal values for the 
items. Version has a decimal value of 1, so the hex value would be x01.

>  Another example, ExtensionCritical. Are only 0x00
>and 0x01 allowed?

Correct. See the list of values in the semantics section for the legal 
values, then apply that to the appropriate syntax section.

>  Or does 0x00 mean FALSE and non-zero mean TRUE? Ditto for

We very explicitly did the opposite. *All* of the semantics are in sections 
2, 3, and 4; *only* the syntax is in sections 5 and 6. The reason for this 
is to reduce confusion between the two syntaxes.

--Paul Hoffman, Director
--Internet Mail Consortium