Subject: RE: FW: scvp

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 27 Apr 2004 11:57:24 -0700

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. 

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: Denis Pinkas <[email-masked]>
Date: Thu, 29 Apr 2004 12:54:29 +0200

Trevor,

> 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