Subject: RE: DVD & DVP requirements

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Jan 2001 12:33:52 -0500

Bob,

>Steve, you said in part:
>  >
>  >I'd like to better understand what parameters the client will change
>  >between invocations of a DPD server, in a controlled fashion, to make
>  >multiple invocations for the same target certificate provide
>  >distinct, useful, answers. Do you have some examples that could
>  >clarify this scenario?
>  >
>  >Steve
>
>Let me give you a possible "existence proof " of such a scenario.
>
>There's an old joke about a Vermonter, who when asked, "How's
>your wife?" replied "Compared to what?"
>
>When we have said in this context, "Is this certificate chain valid?",
>we should really be asking "Can I trust this certificate chain?"
>and the only reasonable answer to that question is to say
>"compared to what?" or more precisely, "Trust it for what purpose?"

A DPV client specifies a set of parameters for controlling an 
objective, deterministic process that we call certificate validation. 
I think the word "trust" has no place in this process.  At best, 
since the client selects the parameters relative to an intended use 
for the key in the cert, you might choose to say that the client 
chooses these parameters based on its perception of what it needs to 
trust the key for, but those would be your words, not mine.

>In other words, trust, like integrity, is not some binary value that is
>independent of any predicate.  Instead, something, either a process
>or the data that was produced as a result of some process, is "trusted"
>if and only if the process conforms to a specified set of rules or
>expectations.  It is clearly not possible for a process to be tested
>against all possible rules in the universe, so without qualifying the
>trust to a particular set of rules, the question is meaningless.

Validation is trinary here: yes, no, don't know.

>Now, the reason why a client or relying party might ask the server t
>hat question is obviously a function of the client's current context, i.e.,
>the type of transaction or whatever that is being evaluated.

Which is why it makes sense to keep this aspect of the decision to 
use a cert for a given application a local matter, outside the scope 
of this standard.

>And clearly, that context may vary, depending on the perceived value
>of the transaction, the history of that transaction and previous
>transactions with that signer, etc.

see comment immediately above.

>If the client is trying to decide whether to honor a purchase order
>for a single quart of 10-40 motor oil, the risk analysis for such a
>transaction would probably suggest that the probability of default
>is low, and that continued customer good will is worth more than
>that risk. In that case, maybe it isn't even worth the bother of
>consulting the server, except perhaps for auditing or logging
>purposes.
>
>On the other hand, if that very same client is evaluating a purchase
>order for one hundred million barrels of crude oil, to be delivered
>via multiple oil tankers FOB Saudi Arabia, then the risk analysis
>would suggest that the buyer's credentials had better be
>gilt-edged indeed.
>
>As to how the parameters would be conveyed, a very simple,
>existence-proof mechanism would be to simply encode the value
>of the transaction in dollars, and let the server try do its thing.
>maybe it has some artificial intelligence program that parses the
>Certificate Practice Statement and does a risk assessment.
>Or maybe it simply looks up the net worth of the buyer and the
>CA in Dun and Bradstreet and decides accordingly.

Since not all transactions are best characterized by monetary value, 
this is not my idea of a good example. It also shifts the burden to 
the server in a fashion that makes it impossible to test if a server 
is operating properly. So, no, this is not a good idea.

>Of course, since I have a hammer and this looks like a nail,
>I would suggest that a better mechanism would be to use
>the Novell Security Attributes (cf. 
>http://developer/novell.com/repository/attributes/certattrs_v10.htm),
>and to have the client either encode a minimum set of those
>attributes for this particular transaction.  Or more likely,
>the client would be preconfigured with a set of attributes
>labeled platinum, gold, silver, bronze, green and brown,
>and would select one of those for certain kinds of transactions,

Bob, we frown on advertisements on this list. You know better.

><snip>
>
>In either case, the client can ask the question, "Is this certificate
>chain trustworthy with respect to my "Platinum" criteria?" and get one
>answer, and later ask the same question with respect to exactly the
>same certificate chain, but specifying the "Green" criteria, and perhaps
>get a different answer.

We support this via reference to different policies configured on the 
server, but only to the extent that the policies make use of standard 
cert attribute validation parameters. To do what you propose would 
require adding support for private extensions at the server and 
perhaps in client requests.  This could be done if the WG wants, but 
it would be a supplement to the mandatory, 2459bis validation 
criteria.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 24 Jan 2001 10:30:23 +0100

Steve,

I picked up one of your sentences in your response to Bob.

[Bob]

> >same certificate chain, but specifying the "Green" criteria, and perhaps

[Steve]
 
> server, 

Not necessarilly configured, but also accessible by the server using a
reference.

> but only to the extent that the policies make use of standard
> cert attribute validation parameters. 

Validation policies may include more controls than specified in RFC 2459bis.
If these validation policies are defined using external references, then it
is easy to point to them and thus avoids to describe them at the interface
level.

> To do what you propose would

Describing parameters additional to the traditional validation algorithm
described in RFC2459, is indeed not that easy. For simplicity, these
addtional parameters should be limited to indicate conditions on the leaf
certificates.

As a summary:

1) Using validation policy references allows a simple interface and hides
the details (and complexity) of the validation policy.

2) Using an explicit validation policy by describing all the parameters at
the interface level is more complex and in any case will have some
limitations when compared to referenced validation policies. I agree with
Steve, that it would be a supplement to the mandatory 2459bis validation
criteria.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Jan 2001 12:34:06 -0500

Denis,

>Not necessarilly configured, but also accessible by the server using a

My spec requires that the server be able to be configured with these 
policies. That will ensure that we have a definition of a minimum 
parameter set well defined for all servers.  If we allow for external 
references, then we have to define a reference format (do you already 
have one in mind?), select a protocol and format for transport of the 
parameters, etc. So, while it may be OK to have external references, 
I really want to keep the local config requirement as a base, and I 
think the addition of external references adds complexity.

>is easy to point to them and thus avoids to describe them at the interface

Yes, and that leads to potential ambiguities and potentially 
undefined server operation.

>addtional parameters should be limited to indicate conditions on the leaf

I'm not comfortable with pushing the problem under the rug in this 
fashion. We all love the power of indirection, but the reason I 
called for server config of parameters was to ensure that we had a 
well-defined list and that a compliant server implementation could be 
managed based on that list, without reference to some vendor-specific 
mechanisms.

>the details (and complexity) of the validation policy.

Are you suggesting that we not have a facility for the client to pass 
in validation parameters, but only have references to policies, or 
are you proposing external references in addition to explicit 
parameters in the request? I'm not sure I want to hide details of the 
policy. I think references to a policy are attractive as a means of 
centralizing management.

>Steve, that it would be a supplement to the mandatory 2459bis validation

Not sure I know how to parse this last sentence, although I think I 
sense an overall disparagement of support for explicit parameters, 
which I still think is necessary.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 25 Jan 2001 19:06:23 +0100

Steve,

> parameter set well defined for all servers.  

There are two approaches to define a policy, either by passing all the
parameters in the request using ASN.1 or by referencing a policy which has
been defined using e.g. English text. It is much faster to say in English :
the leaf certificate must have either this field present or that other field
present with the value X or Y, rather than saying the same thing using
ASN.1.

> If we allow for external references, then we have to define a reference format 

For external references we do not NEED to define such a reference format,
plain English is sufficient, unless you prefer plain French. :-)

> (do you already have one in mind?), select a protocol and format for transport of the parameters, etc. 

I do have in mind such a format which has been defined ASN.1. It could be
used for describing the format as a parameter.

You could derive it from a subset of the Electronic Signature Policies
<draft-ietf-smime-espolicies-00.txt> 

Here is a copy of sections which could be useful to define some (not all !)
conditions:

3.6	Certificate and Revocation Requirement

The SigningCertTrustCondition, TimestampTrustCondition and 
AttributeTrustCondition (defined in subsequent sub-clauses) make use of 
two ASN1 structures which are defined below: CertificateTrustTrees and 
CertRevReq.

3.6.1	Certificate Requirements

The certificateTrustTrees identifies a set of self signed certificates 
for the trust points used to start (or end) certificate path processing 
and the initial conditions for certificate path validation as defined 
RFC 2459 [7] section 4. This ASN1 structure is used to define policy 
for validating the signing certificate, the TSA's certificate and 
attribute certificates.

CertificateTrustTrees ::=   SEQUENCE OF CertificateTrustPoint

CertificateTrustPoint ::= SEQUENCE {
	trustpoint				Certificate,
                               -- self-signed certificate
	pathLenConstraint	[0] PathLenConstraint   OPTIONAL,
	acceptablePolicySet	[1] AcceptablePolicySet OPTIONAL,
                                -- If not present "any policy"
	nameConstraints		[2] NameConstraints     OPTIONAL, 
	policyConstraints	[3] PolicyConstraints   OPTIONAL }

The trustPoint field gives the self signed certificate for the CA that 
is used as the trust point for the start of certificate path 
processing.

The pathLenConstraint field gives the maximum number of CA certificates 
that may be in a certification path following the trustpoint. A value 
of zero indicates that only the given trustpoint certificate and an 
end-entity certificate may be used. If present, the pathLenConstraint 
field must be greater than or equal to zero. Where pathLenConstraint 
is not present, there is no limit to the allowed length of the 
certification path.

PathLenConstraint    ::=   INTEGER (0..MAX) 

The acceptablePolicySet field identifies the initial set of certificate 
policies, any of which are acceptable under the signature policy.
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId

CertPolicyId ::= OBJECT IDENTIFIER

The nameConstraints field indicates a name space within which all 
subject names in subsequent certificates in a certification path must 
be located. Restrictions may apply to the subject distinguished name or 
subject alternative names. Restrictions apply only when the specified 
name form is present. If no name of the type is in the certificate, the 
certificate is acceptable.

Restrictions are defined in terms of permitted or excluded name 
subtrees. Any name matching a restriction in the excludedSubtrees field 
is invalid regardless of information appearing in the ermittedSubtrees.

 NameConstraints ::= SEQUENCE {
           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

      GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

      GeneralSubtree ::= SEQUENCE {
           base                    GeneralName,
           minimum         [0]     BaseDistance DEFAULT 0,
           maximum         [1]     BaseDistance OPTIONAL }

      BaseDistance ::= INTEGER (0..MAX)

The policyConstraints extension constrains path processing in two ways. 
It can be used to prohibit policy mapping or require that each 
certificate in a path contain an acceptable policy identifier.

The policyConstraints field, if present specifies requirement for 
explicit indication of the certificate policy and/or the constraints on 
policy mapping.

PolicyConstraints ::= SEQUENCE {
        requireExplicitPolicy           [0] SkipCerts OPTIONAL,
        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

If the inhibitPolicyMapping field is present, the value indicates the 
number of additional certificates that may appear in the path 
(including the trustpoint's self certificate) before policy mapping is 
no longer permitted. For example, a value of one indicates that policy 
mapping may be processed in certificates issued by the subject of this 
certificate, but not in additional certificates in the path.

If the requireExplicitPolicy field is present, subsequent certificates 
must include an acceptable policy identifier. The value of 
requireExplicitPolicy indicates the number of additional certificates 
that may appear in the path (including the trustpoint's self 
certificate) before an explicit policy is required. An acceptable 
policy identifier is the identifier of a policy required by the user of 
the certification path or the identifier of a policy which has been 
declared equivalent through policy mapping.

3.6.2	Revocation Requirements

The RevocRequirements field specifies minimum requirements for 
revocation information, obtained through CRLs and/or OCSP responses, to 
be used in checking the revocation status of certificates. This ASN1 
structure is used to define policy for validating the signing 
certificate, the TSA's certificate and attribute certificates. 

CertRevReq ::= SEQUENCE {
	endCertRevReq	RevReq,
	caCerts	    [0] RevReq
                                            }

Certificate revocation requirements are specified in terms of checks 
required on:
     * endCertRevReq: end certificates (i.e. the signers certificate,
     the attribute certificate or the timestamping authority 
     certificate).

     * caCerts: CA certificates.

        RevReq ::= SEQUENCE  { 
         enuRevReq  EnuRevReq,
         exRevReq    SignPolExtensions OPTIONAL}

An authority certificate is certificate issued to an authority (e.g. 
either to a certification authority or to an attribute authority (AA)).

A TimeStamping Authority (TSA) is a trusted third party that creates 
time stamp tokens in order to indicate that a datum existed at a 
particular point in time. See [TSP]

EnuRevReq  ::= ENUMERATED {
	clrCheck	(0), 
                   --Checks must be made against current CRLs
		   -- (or authority revocation lists (ARL))
	ocspCheck	(1), -- The revocation status must be checked
                  -- using the Online Certificate Status Protocol 
                  -- (OCSP),RFC 2450.
	bothCheck	(2),	
                  -- Both CRL and OCSP checks must be carried out
	eitherCheck	(3),	
                  -- At least one of CRL or OCSP checks must be
                  -- carried out
	noCheck		(4),	
                  -- no check is mandated
	other		(5)		
                  -- Other mechanism as defined by signature policy 
                  -- extension
	  }

Revocation requirements are specified in terms of: 
     * clrCheck: Checks must be made against current CRLs (or
       authority revocation lists);
     * ocspCheck: The revocation status must be checked using the
       Online Certificate Status Protocol (RFC 2450);
     * bothCheck: Both OCSP and CRL checks must be carried out;
     * eitherCheck: Either OCSP or CRL checks must be carried out;
     * noCheck: No check is mandated.

> So, while it may be OK to have external references,

Fine. On that point we both agree.

> I really want to keep the local config requirement as a base, and 

I am confused with the term that you use :"local configuration requirement".
If the parameters, passed at the time of the request, define the validation
policy then there is no such local configuration.

Do you have in mind a protocol where you could define with one call the
validation policy and then in another call ask for the validation using a
refrence to that policy ? If so, I agree.

In that case, I would understand what a local configuration is, and then
both calls would look the same.

The case where the validation policy is referenced would have one call,
while the case where the validation policy is locally defined would have two
calls.

> I think the addition of external references adds complexity.

Validation policies passed as a parameter add complexity.

> undefined server operation.

Not exactly. See above.
 
> managed based on that list, without reference to some vendor-specific

There is nothing such as "endor-specific mechanisms", but more "specific
validation policies".

> which I still think is necessary.

Explicit validation policies passed as a parameter are more complex. Now
this is not a reason of not supporting them.

So I am advocating the support of both cases: 

a) explicit validation policies AND 
b) referenced validation policies, 

Denis