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

From: "Aram Perez" <[email-masked]>
Date: Mon, 28 Jun 1999 20:07:37 -0700

Hi Paul,

Thanks for your response. Below are my comments.

> At 06:24 PM 6/28/1999 -0700, Aram Perez wrote:
>>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?
>
> It has the public key of the server built-in without a cert. Remember, you
> don't need certs for root keys.

This is fine but implies a limited number of SCVP servers.

>>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 ;-)
>
> 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.

Believe me, I agree with specifying just one algorithm for simplicity (and
interoperability) sake. It's just that I wanted someone else to get beat up
like I was ;-)

>>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.
>
> It didn't seem completely necessary, just Very Good, thus SHOULD instead of
> MUST. We're open to either.

I vote for SHOULD.

>>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..."
>
> That wording is equivalent to what we have, I think. I prefer SHOULD to
> "MUST with exceptions" as a stylistic choice.

I don't think that it is equivalent. With the original wording I can send an
unsigned request over an unauthenticated channel and be compliant but with
my wording I can't be compliant.

[snip]
>>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?
>
> 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
>>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
>>     }
>
> 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.

In my cursory reading I missed this point. I would recommend you highlight
this point to make it very clear and make sure all understand it.

Regards,
Aram Perez

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 28 Jun 1999 20:16:57 -0700

>This is fine but implies a limited number of SCVP servers.

A limited number that the client trusts. Absolutely. You aren't going to 
trust just anyone. Our expectation is that a typical client might trust one 
or two servers at a time. Of course, there's nothing in the protocol that 
limits the client to this.

>interoperability) sake. It's just that I wanted someone else to get beat up

We're open to such beating, and changing if necessary.

>my wording I can't be compliant.

If you want to be insecure, you can. Again, our expectation is that 
companies relying on SCVP will have their own SCVP servers. They might want 
to risk running the requests and responses over their corporate networks. 
Dumb, yes (given the small overhead of signing), but it should be 
acceptable if they really want to do it even after the warnings.

>this point to make it very clear and make sure all understand it.

Will do.

--Paul Hoffman, Director
--Internet Mail Consortium