Subject: FW: FW: scvp

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 7 May 2004 01:24:49 +0200

Oh.Oh. I am getting old. Pressed the wrong button and wondered why the
message does not show up on the list. It is old but it fits :)

-----Original Message-----
From: Florian Oelmaier [mailto:[email-masked]] 
Sent: Wednesday, May 05, 2004 12:11 AM
To: 'Trevor Freeman'
Subject: RE: FW: scvp

Hello Trevor, Denis,

I personally agree with Denis - it seems to be better to reference a
policy. All the validation parameter settings can be agreed upon out of
band. Delivering the parameters within SCVP will a) be a never ending
task as people will always want another parameter for their special
use-case, b) will make the protocol even more complex in wording and
implementation and c) will make it less interoperable, as client will
expect a certain behaviour of the server when delivering certain
parameters.

So may be I am not in line with the "many groups" but I think that the
idea of a validation-policy OID is better.

Just my 0.02cp,

Florian Oelmaier
SyTrust

> 
> 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} 
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> > 
> > 
> > 
> 
> 
> 
>