Subject: SCVP 16 comments 1-16

From: Denis Pinkas <[email-masked]>
Date: Tue, 15 Feb 2005 16:15:26 +0100

Tim,

You said: "I am looking forward to your comments on our disposition of your 
comments".

You already got this one below which was not responded.

Denis

==========================================================================
Denis,

The editors have been working feverishly to meet the deadlines.  In some 
cases, the disposition of comments are currently chicken scratch on paper. 
They will be submitted to the list as soon as we can document things.

However, you should understand that some comments may not be resolved to 
your satisfaction.  We are looking for *rough consensus* here.  That means 
the WG as a group needs to be satisfied on each issue, but some individuals 
will inevitably be unhappy with the resolution of some particular issues. 
That is just life.

IMHO, issues related to consistency with RFC 3379 are show stoppers - SCVP 
must be responsive to our requirements document!  Issuers related to 
elegance and personal preference are not show stoppers, and should not be 
allowed to prevent this document from moving forward.

Anyway, we will get the disposition of your comments (and others) documented 
and onto the list today or tomorrow.  I'm looking forward to your comments 
on our disposition of your comments.

Thanks,

Tim

-------- Original Message --------
Subject: Re: SCVP 16 comments deadline
Date: Wed, 08 Dec 2004 17:00:33 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: [email-masked]
References: 
<[email-masked]>

Trevor,

 > Hi Denis,
 > Below are responses to 1-16. Others will follow later.

I am pleased that you accepted comments 13, 14, 15 and 16.
Among this list, I have a further remark on comment 4.

 > * 4. Page 13. Typo. Section 3.1.2 "checks"
 > * The two following lines are in fact one line:
 > *
 > * Change:
 > *
 > *      - Build a validated certification path to a trust anchor; and
 > *
 > *      - Do revocation status checks on the certification path.
 > *
 > * into:
 > *
 > *      - Build a validated certification path to a trust anchor and
 > *        do revocation status checks on the certification path.
 > *
 > [TF] Since this paragraph is listing the possible checks and building a
 > path is a separate check to revocation checking, I think the current
 > text is more accurate.

I agree that "building a path is a separate check to revocation checking",
but revocation checking without building a validated path does not make sense.

The full text currently is:

      - Build a certification path to a trust anchor;

      - Build a validated certification path to a trust anchor; and

      - Do revocation status checks on the certification path.

The full text should be:

      - Build a certification path to a trust anchor;

      - Build a validated certification path to a trust anchor; and
        do revocation status checks on the certification path.

Denis

---

From: Tim Polk <[email-masked]>
Date: Tue, 15 Feb 2005 10:41:52 -0500

Denis,

Comment 4 was addressed in the new draft.  Your comment that "revocation 
checking without building a validated path does not make sense" was 
accepted, and the client now asserts a single check to request a validated 
path with revocation checking, as in your proposal.

Our resolution was slightly different from your proposal.  You proposed to 
resolve this issue by reducing the set of checks from three to two.  We 
retained three different checks because we wanted to allow for the case 
where a path is built and validated without considering status 
information.  This is explicitly permitted in both RFC 2459 and 3280, and 
should be covered by SCVP as well.

Our text follows:

Excerpt form draft -17, section 3.2.2 Checks
>
>    For public key certificates, the following checks are defined:
>
>     - id-stc-build-pkc-path: Build a certification path to a trust
>        anchor;
>
>     - id-stc-build-valid-pkc-path: Build a validated certification path
>        to a trust anchor (revocation checking not required);
>
>     - id-stc-build-status-checked-pkc-path: Build a validated
>        certification path to a trust anchor and perform revocation
>        status checks on the certification path.
>
>    Conforming SCVP server implementations MUST support the id-stc-build-
>    pkc-path check.  Conforming SCVP server implementations that support
>    delegated path validation (DPV) as defined in [RQMTS] MUST support
>    the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-
>    path checks.
>

Your thoughts?

Tim

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 15 Feb 2005 16:53:41 +0100

Tim,

> accepted, and the client now asserts a single check to request a 
> validated path with revocation checking, as in your proposal.

> Our resolution was slightly different from your proposal.  You proposed 
> to resolve this issue by reducing the set of checks from three to two.  
> We retained three different checks because we wanted to allow for the 
> case where a path is built and validated without considering status 
> information.  This is explicitly permitted in both RFC 2459 and 3280, 
> and should be covered by SCVP as well.

>>        status checks on the certification path.

Humm !! humm !!

You say above "reducing the set of checks from three to two.".

If I count correctly I see three choices above.

Would you explain ?

Denis

---

From: Tim Polk <[email-masked]>
Date: Tue, 15 Feb 2005 11:21:49 -0500

Please reread my message.  I said *you* suggested reducing the set from 
three to two, but we retained all three.  The rationalization is clearly 
stated in the message.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 15 Feb 2005 17:45:17 +0100

Tim,

> three to two, but we retained all three.  

OK.

> The rationalization is clearly stated in the message.

1) Would you explain the difference between:

  - Build a certification path to a trust anchor
    (i.e. id-stc-build-pkc-path)

   and

  - Build a validated certification path to a trust anchor
    (id-stc-build-valid-pkc-path) ?

2) I would then presume that a conforming SCVP server implementations
    MUST support the id-stc-build-status-checked-pkc-path check
    instead of the id-stc-build-pkc-path check
    (but the answer to the first question might possibly solve this one).

Denis

 >>>>        to a trust anchor (revocation checking not required);

id-stc-build-pkc-path: Build a certification path to a trust

>>> Comment 4 was addressed in the new draft.  Your comment that 
>>> "revocation checking without building a validated path does not make 
>>> sense" was accepted, and the client now asserts a single check to 
>>> request a validated path with revocation checking, as in your proposal.
>>
>>
>>> Our resolution was slightly different from your proposal.  You 
>>> proposed to resolve this issue by reducing the set of checks from 
>>> three to two.

---

From: Tim Polk <[email-masked]>
Date: Tue, 15 Feb 2005 14:31:09 -0500

>    (i.e. id-stc-build-pkc-path)

id-stc-build-pkc-path is asserted to indicate that a client wants the 
server to construct a certification path but is not asking the server to 
guarantee it is valid, or provide status information.

This functionality is the minimum required to support DPD.  The DPD client 
will perform path validation itself, so the server need not perform this step.

>    (id-stc-build-valid-pkc-path) ?

id-stc-build-pkc-path is asserted to indicate that a client wants the 
server to construct and validate a certification path but is not asking the 
server to check status information.  This functionality is the minimum 
required to support DPV.

>>>>>    the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-

SCVP servers that perform DPV MUST support all three checks.  Most 
importantly, DPV server need to support 
id-stc-build-status-checked-pkc-path, where the server constructs and 
validates a path including checking status information.  Supporting all 
three checks is not burden, since a path that satisfies this check 
satisfies the other checks as well.

However, SCVP servers that only support DPD need only support 
id-stc-build-pkc-path.  It would be very burdensome to require DPD servers 
to support id-stc-build-status-checked-pkc-path when that functionality is 
not required by its clients.

Does that clarify things?

Thanks,

Tim