Subject: RE: FW: scvp

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 26 Apr 2004 11:30:14 -0700

HI Denis,
In SCVP13, the concept of validation policy was not completely in
alignment  with 3379 definition. It also blurred the distinction between
validation policy and validation algorithm. 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."

Therefore trust anchors are an input into the algorithm  and therefore
separate.

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: Tue, 27 Apr 2004 20:01:14 +0200

Trevor,

> 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

This does not comply with RFC 3379.

> Therefore trust anchors are an input into the algorithm  and therefore

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