Subject: RE: FW: scvp

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 29 Apr 2004 09:57:28 -0700

Hi Denis,

3379 does not require that the validation policy be specified in a
single value. 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.
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} 
>>>
>>>
>>
>>
>>
>>
> 
> 
>