Subject: RE: Comments on SCVP15

From: Peter Sylvester <[email-masked]>
Date: Mon, 2 Aug 2004 15:06:10 +0200 (MEST)

> Hi Denis,
> The concern you express here is touching.
> See answers below.
> Trevor
> 

I am not sure to whom Trevor is talking in the following. 
Since the original message was from me, and Trevor did not
answer, Denis, would be be so glad to comment again
or/and to remind him that he is trying to respond to
my message. 

Note again, that Trevor answers Denis, not to my comments, 
I may be on his black list. 

> * 
> * Now awaiting SCVP-16 ... or much better, before issuing it, a response
> to
> * the many technical comments raised on this mailing list on SCVP-15.
> 
> [TF] A reply to you last posting has been made. What is of concern is
> the fact that you requested changes in your posting on SCVP15 to
> sections of SCVP which have been stable for the past 15 versions. I will
> only post draft 16 when I have a definitive and final set of issues from
> you and there will only be editorial changes from then on. This point is
> not negotiable. Anything else will have to wait. 

Trevor, are you assuming that people haven't archived
the previous 15 versions? configID, policyID had changed
and this was a little bit more than a textual change IMO.
Furthermore, the resulting texts were sometimes uncomprehensible
since the asn1 syntaxes were inconsistent or unimplementable. 

Since last call, many changes had been added without any discussion, 
i.e. all the extensions stuff, these are clearly new features, and 
not just editorial or bug corrections. 

I think that all extensions which are features and not
completions should be properly discussed and developed
or removed.

Peter

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 02 Aug 2004 15:36:11 +0200

Trevor,

Would you please also respond to Peter ?
Peter is correct when saying that major changes have been made.

>>The concern you express here is touching.

I have some difficulties to understand the meaning of this sentence.

I certainly missed some or all of the e-mails you sent explaining the 
differences between the successive versions of SCVP, or/and the section at 
the very end of the document that would be there to keep track of the 
changes until the document is published. :-(

Going back to technical concerns, we still have a major disagreement about 
the concept and the use of a validation policy.

RFC 3379 states:

    it is expected that most clients will simply reference a validation
    policy for a given application or accept the DPV server's default
    validation policy.

Referencing a validation policy does not require to define any parameter, 
hence why all validation policy parameters should be removed from the "first 
level" of the parameters from the SCVP request" and be placed under the OID 
of a "parametrable" validation policy. This is not stylistic.

RFC 3379 states:

    A validation policy is a set of rules against which the validation of
    the certificate is performed.

    A validation policy MAY include several trust anchors.  A trust
    anchor is defined as one public key, a CA name, and a validity time
    interval; a trust anchor optionally includes additional constraints.
    The use of a self-signed certificate is one way to specify the public
    key to be used, the issuer name, and the validity period of the
    public key.

    Additional constraints for each trust anchor MAY be defined.  These
    constraints might include a set of certification policy constraints
    or a set of naming constraints.  These constraints MAY also be
    included in self-signed certificates.

    Additional conditions that apply to the certificates in the path MAY
    also be specified in the validation policy.  For example, specific
    values could be provided for the inputs to the certification path
    validation algorithm in [PKIX-1], such as user-initial-policy-set,
    initial-policy-mapping-inhibit, initial-explicit-policy, or initial-
    any-policy-inhibit.

    Additional conditions that apply to the end-entity certificate MAY
    also be specified in the validation policy.  For example, a specific
    name form might be required.

I believe that our disagrement comes from the fact that you restict a 
validation policy to be only a certification path check done according to 
RFC 3280 section 6, while it may be much more than that: see above.

Denis

PS. I have no time available today to respond to your detailed response to 
my comments. I will try to do it later.

---

From: [email-masked]
Date: Mon, 2 Aug 2004 15:51:18 -0400

Peter,

In your last email you stated:

> completions should be properly discussed and developed

Please note that a "design team" was formed at my request to bring the whole 
unsigned DPD issue to resolution.  I was hoping that the design team would be 
more efficient in finding a soilution than the on-list discussion.  So, if the 
changes you refer to involve unsigned DPD, it is *entirely* appropriate for 
these features to be included in the new draft.  

To quote RFC 2418:

> 6.5. Design teams

>    It is often useful, and perhaps inevitable, for a sub-group of a
>    working group to develop a proposal to solve a particular problem.
>    Such a sub-group is called a design team.  In order for a design team
>    to remain small and agile, it is acceptable to have closed membership
>    and private meetings.  Design teams may range from an informal chat
>    between people in a hallway to a formal set of expert volunteers that
>    the WG chair or AD appoints to attack a controversial problem.  The
>    output of a design team is always subject to approval, rejection or
>    modification by the WG as a whole.

Please note the final sentence: the WG still gets the final say, not the 
design team!

Thanks,

Tim Polk

---

From: [email-masked]
Date: Mon, 2 Aug 2004 16:37:13 -0400

Peter,

> I may be on his black list. 

It is far more likely that Trevor did not read your message because the 
subject line indicated it was a comment on the PKIX agenda.

As Trevor is on vacation, and will not be in San Diego, comments on the agenda 
probably seem immaterial.

I have forwarded the message to Trevor with a more concise subject line...

Tim