Subject: RE: FW: scvp

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 4 May 2004 10:22:07 -0700

Hi Denis,
There is no mandate in 3379 that a validation policy must be expressed
with a single value. It is not clear that is any value is doing so since
it only raised more ambiguity. This is well trod turf by many groups who
have debated the merits of providing suits vs. "al a carte" combinations
of inputs and the broader consensus is for a "al a carte".
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Tuesday, May 04, 2004 3:15 AM
To: Trevor Freeman
Cc: [email-masked]
Subject: Re: FW: scvp

Trevor,

> Hi Denis,
> 
> 3379 does not require that the validation policy be specified in a
> single value. 

You are playing with words. The text says:
"most clients will simply reference a validation policy"

This means that validation policies can be referenced and thus
parameters do 
not need to be defined through this interface.

A simple and good reference is an OID.

> With SCVP14 a client can accept the default of the SCVP
> server or specify a set of parameters which constitutes its validation
> policy. That is consistent with the requirements of 3379.

The specification of the set of parameters should be done through a 
different interface. This different interface can then return an OID 
Whatever this additional interface can be, it will never be rich enough
to 
pass all the details of the validation policy. Thus OIDs can also be
defined 
not using this additional interface.

Denis

> Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Thursday, April 29, 2004 3:54 AM
> To: Trevor Freeman
> Cc: [email-masked]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> 
>>Hi Denis,
> 
> 
>>Can you please be more specific how you think SCVP 14 does not comply
>>with 3379.
>>
>>I can find no section in 3379 where is there a requirement that a
>>validation policy MUST be represented as an OID. 
> 
> 
> There cannot be a requirement with such a level of detail, but the
text
> states:
> 
>     The protocol MUST allow the client to include
>     these policy dependant parameters in the DPV request; however, 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.
> 
> A simple reference is an OID.
> 
> FYI, I do not expect to use the "default validation policy".
> 
> Denis
> 
> 
> 
>>Given hiding the detail of what a policy is within an OID simply opens
>>the rat hole of what change to the policy constitutes a change to the
>>OID, it is less ambiguous to refer to the primary data. Once you are
> 
> in
> 
>>the business of managing state on a client, then there is negligible
>>cost increase incurred in managing several data points vs. a singe
> 
> data
> 
>>point.
>>
>>Trevor
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[email-masked]] 
>>Sent: Tuesday, April 27, 2004 11:01 AM
>>To: Trevor Freeman
>>Cc: [email-masked]
>>Subject: Re: FW: scvp
>>
>>Trevor,
>>
>>
>>
>>>HI Denis,
>>>In SCVP13, the concept of validation policy was not completely in
>>>alignment  with 3379 definition. 
>>
>>
>>Well, it is different and this is a major problem.
>>
>>
>>
>>>It also blurred the distinction between
>>>validation policy and validation algorithm. 
>>
>>
>>This is also a majo problem.
>>
>>
>>
>>>Therefore I have defined
>>>what each is in SCVP 14 and aligned the structures accordingly.
>>>Section 1.3 has the following.
>>>"In SCVP, the validation policy comprises of an algorithm for
>>>certificate path processing and the input parameters to the
>>
>>algorithm."
>>
>>This does not comply with RFC 3379.
>>
>>
>>
>>>Therefore trust anchors are an input into the algorithm  and
therefore
>>>separate.
>>
>>
>>Therefore I do not follow you.
>>
>> From an interface point of view the simplest validation policy is
>>defined 
>>by an OID where all the parameters necessary to perform the validation
>>check 
>>are "behind" the OID. There is no need to provide any parameter
> 
> through
> 
>>the 
>>interface.
>>
>>When there are some parameters, then they are specific to the
> 
> validation
> 
>>policy. I have no problem to provide specific parameters for what is
>>called 
>>the "default validation policy" which is only a particular validation
>>policy 
>>among many others.
>>
>>Simple clients will be unable to pass any parameter but will know
> 
> which
> 
>>OIDs 
>>(for the validation policy) are appropriate for their applications.
>>
>>Denis
>>
>>
>>
>>>This is in alignment with 3379s definition of validation policy.
>>>
>>>Trevor
>>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[email-masked]] 
>>>Sent: Monday, April 26, 2004 1:09 AM
>>>To: Peter Sylvester
>>>Cc: [email-masked]; Trevor Freeman
>>>Subject: Re: FW: scvp
>>>
>>>Peter and Trevor,
>>>
>>>I have major problems too.
>>>
>>>
>>>
>>>
>>>>in version 13 the syntax for a Query has been changed from
>>>>
>>>> Query ::= SEQUENCE { 
>>>>     queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>>>>     checks                CertChecks, 
>>>>     wantBack              WantBack, 
>>>>     serverContextInfo [0] OCTET STRING OPTIONAL, 
>>>>     valPolicy         [1] ValidationPolicy OPTIONAL, 
>>>>     validityTime      [2] GeneralizedTime OPTIONAL, 
>>>>     trustAnchors      [3] TrustAnchors OPTIONAL, 
>>>>     intermediateCerts [4] CertBundle OPTIONAL, 
>>>>     revInfos          [5] RevocationInfos OPTIONAL, 
>>>>     queryExtensions   [6] Extensions OPTIONAL } 
>>>
>>>
>>>In this structure trustAnchors was more or less an alternative to
>>>valPolicy.
>>>
>>>In fact, IF the valPolicy is the default policy, THEN additional
>>>parameters 
>>>MUST be provided. So the structure below does not fit as well.
>>>
>>>This leads to have the two following elements:
>>>
>>>    valPolicy               ValidationPolicy,
>>>    paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
>>>
>>>where the first one is mandatory and the second one optional.
>>>
>>>
>>>
>>>
>>>>to  
>>>>
>>>>  Query ::= SEQUENCE { 
>>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>
>>>
>>>>    checks                  CertChecks, 
>>>>    wantBack                WantBack, 
>>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>    valAlgorithm            ValidationAlgorithm, 
>>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>    revInfos            [4] RevocationInfos OPTIONAL, 
>>>>    queryExtensions     [5] Extensions OPTIONAL } 
>>>
>>>
>>>I would thus propose to have something like:
>>>
>>>Query ::= SEQUENCE {
>>>        queriedCerts            SEQUENCE SIZE (1..MAX) OF
>>>CertReference,
>>>        checks                  CertChecks,
>>>        wantBack                WantBack,
>>>        requestRefHash          BOOLEAN DEFAULT TRUE,
>>>        serverContextInfo       OCTET STRING OPTIONAL,
>>>        validityTime            GeneralizedTime OPTIONAL,
>>>        includePolResponse      BOOLEAN DEFAULT FALSE,
>>>        valPolicy               ValidationPolicy,
>>>        paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
>>>        intermediateCerts   [1] CertBundle OPTIONAL,
>>>        revInfos            [2] RevocationInfos OPTIONAL,
>>>        queryExtensions     [3] Extensions OPTIONAL }
>>>
>>>and then something like:
>>>
>>>   ParamsDefValPolicy :: = SEQUENCE {
>>>       trustAnchors                  TrustAnchors,
>>>       endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
>>>OPTIONAL,
>>>       inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>>>       caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
>>>OPTIONAL }
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>>I am not sure whether I am the only person unable to construct a
>>>
>>>parser.
>>>
>>>
>>>
>>>>in version 14 an aditional flag has been added which is not
available
>>>
>>>in the
>>>
>>>
>>>
>>>>Chapter 9. Is the isCA flag an orthogonal attribut to other
>>>
> validation
> 
>>>>algorithms, or just to some of them, e.g,. the default name matching
>>>
>>>one? 
>>>
>>>
>>>
>>>>  Query ::= SEQUENCE { 
>>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>
>>>
>>>>    checks                  CertChecks, 
>>>>    wantBack                WantBack, 
>>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>    isCA                    BOOLEAN DEFAULT FALSE, 
>>>>    valAlgorithm            ValidationAlgorithm, 
>>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>    revInfos            [4] RevocationInfos OPTIONAL, 
>>>>    keyUsage            [5] KeyUsage OPTIONAL, 
>>>>    extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>>>>    queryExtensions     [7] Extensions OPTIONAL  
>>>>    producedAt          [8] GeneralizedTime OPTIONAL} 
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 
>

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 6 May 2004 18:35:54 +0800

I don't agree that the broader consensus is for a "al a carte".
(Maybe we should have a straw poll to decide what is the 
broader consensus?)

When designing a DPV protocol, please do not forget that the
two main benefits to establish a DPV server are:

1. it reduces the burden for application implementators to implement
    certification path processing modules by themself;
2. it allows validation against management-defined validation policies
    in a consistent fashion across an application domain (e.g., an
    enterprise).

I believe that application implementors do not want "al a carte"
combinations, they will prefer suits instead. If a DPV server requires
application implementors to use a DPV client API that needs
the implementors to specify a validation policy OID with many initial
mystery parameters, then what is the benefit to use the DPV server?
Why not simply use a certification path processing API such as CML
instead a DPV client API if the burden is the same? At least, you can
save the budget for establishing a DPV server if you choose to use
CML.

Besides, in an application domain where the authority wish
to force all applications to validate certification path against
management-defined validation policies in a consistent fashion,
the applications will not even be allowed to specify any initial
parameters (except the certificate to be validated). If the client
side is allows to specfy its own initial parameters, how can the
validation be guaranteed to proceed in the consistent fashion?
In an application domain with a centralized validation policy, the
server side will decide almost all the initial parameters according
to the validation policy. In such case, the client side need not
(and might not be allowed) to specify any initial parameters
(except the certificate to be validated, of course).

I believe that in most use cases of DPV, the client side will need
not to specify any initial parameters. Therefore, why not simplify the
syntax of the SCVP so that the client side do not to specify any initial
parameters in a basic request. In my opinion, the SCVP is not a
"simple" protocol anymore. Let's simplify it so that it deserve the
name of a "simple" protocol.

That is not to say that the SCVP can not provide a mechanism
for the client side to specify its own validation policy and initial
parameters if the server side allows its clients to do that, but this
can be achieved by using the "Extension" mechanism. In the most
case, there is no need  for the client side to specify its own validation
policy and initial parameters, so please do not let the basic syntax
so complicated.

Personally, I think the draft 12 syntax is better than draft 13/14.
Maybe we should go back to the draft 12 syntax and try to define
some extensions based on that syntax.

Wen-Cheng Wang

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 06 May 2004 16:47:10 +0200

Trevor,

> with a single value. 

"The protocol MUST allow the client to include these policy dependant 
parameters in the DPV request; however, it is expected that most clients 
will simply reference a validation policy."

The "however" mandates that a validation policy must also be expressed
with a single value.

I do not understand your resistance against a single value.
The following strcture could accomodate both approaches:

    ValPolicy  ::=  SEQUENCE  {
         valPolId      OBJECT IDENTIFIER,
         valPolValue   OCTET STRING  OPTIONAL }

The valPolValue would be dependent upon the OID of the valPolId and the 
structure of the valPolValue in the case of the "default policy" would be 
defined in the current document.

Other structures could be defined in other documents.

Denis

 > validation policy.

> It is not clear that is any value is doing so since