Subject: Comments on the DPV-DPD req doc

From: Ambarish Malpani <[email-masked]>
Date: Wed, 27 Feb 2002 16:15:00 -0800

Hi Denis, Russ,
    Here are a set of comments on the DPV-DPD requirements doc.
Denis, some of these are repeats of comments I had sent you
earlier (off the list):

1. Section 4 2nd paragraph
    If a client is asking a server to validate a certificate at
a particular time, that means "was the certificate valid at that
time" (based on information available at that time or information
obtained later). I don't think we should allow it to mean multiple
things

2. Section 4 3rd paragraph
    The requirements document should not forbid specification
of the policy with a request. If the protocol writers find that
specifying the policy (or a subset of the policy) with the
request is too burdensome, let them make that decision. Allowing
a client to specify a frequently changing part of the policy
with every request wouldn't be a bad decision

3. Section 4 6th paragraph
    You say that if the client doesn't provide the full certificate,
the server MUST use the unambiguous reference provided by the client
to get that certificate.
    Again, this is not a requirement. If the server could devine
that certificate by sticking its thumb in the air, that should be
fine - as long as the server verifies that it is the certificate
the client specified

4. Section 4 8th paragraph
    You say that a client MUST verify the policy used by the server
is appropriate
    Would you allow for the case where a client doesn't understand
much about policies and is willing accept that the server chose the
right policy for it? Kind of like a NULL verification?

5. Section 4 return states
    I agree with Mike - it is unclear why 3 and 4 are different. I
believe you are planning to change this already

6. Section 4 2nd last paragraph
    You say "All the parameters needed to prove that the response
conforms to a request SHALL be copied from the request into the
response, so that a response is self-sufficient proof."
    This is not an appropriate requirement. At the most all you
should require in this document is that there be a way to show
that a response corresponds to a particular request. Whether this
is done by copying the request in the response, or just including
its hash is the protocol designers prerogative.

7. Section 7.1 7th para onwards
    I thought the group had recommended against the "cautionary
period". Are you planning to get rid of these paragraphs?

8. Section 8.1.4
    More cautionary period stuff

9. Section 9
    Any need to talk about DSV in this document? You aren't really
saying much about it - why mention it?

Sorry for the long mail.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 28 Feb 2002 18:07:41 +0100

Ambarish,

Just before leaving on holidays for 10 days, my last response for the day.

> Denis, some of these are repeats of comments I had sent you

[COMMENT 10]

things.

[Answer 10]

The question is what means the sentence: "Is the certificate valid 
at a time T ? ".  Does it mean:

1) valid when compared to the revocation status information that is
   available at that time T (which may not be up to date) ? , or

2) valid for the time T, where the key was used ? 

These two times are not always identical and thus the response is 
dependant upon the meaning of that time which is left to the policy. 

[COMMENT 11]

[Answer 11]

Validation policies are usually not defined by end-users but by
administrators. So why a separate protocol should be used, the policy is not
locally defined. Clients should not define policies. As we know, policy
parameters are quite complex.

[COMMENT 12]

[Answer 12]

No. "The text says" that if the client doesn't provide the full certificate,
the server MUST use the unambiguous reference provided by the client
to get that certificate.

Since "MUST" is used, this is indeed a requirement.

In order for a server to verify that it is the certificate the client
specified, the reference which is provided must be ambiguous. As soon as a
client wants a signed response, it may wish to prove to some one that he got
a right answer. The unambiguous reference is there as a protection in case
of a CA key compromise where a certificate with the same serial number but a
different content would be created. 

[COMMENT 13]

3. Section 4 8th paragraph

[Answer 13]

There has been plenty of discussions on this topic already these past days,
please refer to that thread.

[COMMENT 14]

I agree with Mike - it is unclear why 3 and 4 are different. 
I believe you are planning to change this already

[Answer 14]

It can be changed to three states or even two sates: Yes, No.
The summary provided by Mike is fair. The text will be changed.

[COMMENT 15]

4. Section 4 2nd last paragraph

[Answer 15]

See the response to the [COMMENT 1] posted today.

[COMMENT 16]

 
[Answer 16]

This section is related to your first comment. This is what makes the
difference between the time T1, where the key was used and the time T2 where
the revocation information is available. I would guess that the next IETF
meeting will be the right place to discuss this issue, ... in corridors
first. 

[COMMENT 17]

8. Section 8.1.4

[Answer 17]

Same.

[COMMENT 18]

9. Section 9

[Answer 18]

When the text was saying more, some people have been asking to say less.
Since now the text is saying less, you are suggesting more text ? :-)

Denis