Subject: SCVP Question regarding Trust Anchors

From: "Julien Stern" <[email-masked]>
Date: Mon, 23 Apr 2007 17:44:46 +0200

Folks,

sorry to ask this fairly late in the process, but it did not catch
my eye before:

The ValidationPolicy structure defines
- userPolicySet
- inhibitPolicyMapping
- requireExplicitPolicy
- inhibitAnyPolicy

globally and not on a per trust-anchor basis.

Wouldn't it be more logical and less limiting to define it for each
trust anchor (like in RFC3125)... ?

Regards,

--
Julien

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Apr 2007 15:44:28 -0400

You are right, in my personal opinion, that would be a better 
structure.  Can you propose text?

Russ

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 23 Apr 2007 17:52:05 -0400

Russ, Julien,

This was discussed on the list in early 2005 and the consensus was 
against making this change.  It was simply a trade off between 
flexibility and complexity.  In almost every case, the same set of 
inputs (e.g., userPolicySet, inhibitPolicyMapping, 
requireExplicitPolicy, etc.) are appropriate for each trust anchor.  
Allowing different values to be specified for each trust anchor would 
complicate things for all clients (and servers) for the benefit of the 
few that would need this level of granularity in specifying validation 
requirements and we already have enough complaints that SCVP is too 
complicated.  The few clients that need this degree of flexibility can 
simply send multiple requests, with each request specifying a different 
set of trust anchors along with the appropriate input values for that 
set of trust anchors.

(Note that in theory a validation policy could be defined in which 
values for userPolicySet, inhibitPolicyMapping, requireExplicitPolicy, 
etc. were different for each trust anchor.  The easiest way to do this 
would be to only allow the client to specify the validation policy by 
OID and to only include the validation policy by reference in the 
response.  That way the request would simply say "validate certificate X 
under policy Y" and the response would say "the result of validating 
certificate X under policy Y was ...".  Since neither the request nor 
the response would include any explicit information about the meaning of 
policy Y, there would be no limitations on the complexity of the 
definition of policy Y.  Not that I would recommend defining overly 
complicated validation policies, but I think it can be done with certain 
limitations on what can be included in the request and in the response.)

Dave

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Apr 2007 15:44:28 -0400

Russ

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 23 Apr 2007 17:52:05 -0400

Russ, Julien,

Dave

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 23 Apr 2007 15:14:08 -0800

Russ, Julien:

To what benefit?

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
Sent: Monday, April 23, 2007 11:44 AM
To: Julien Stern; [email-masked]
Subject: Re: SCVP Question regarding Trust Anchors

Russ

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 24 Apr 2007 10:28:39 +0200

David,

I agree that I can define my validation policy as I want
and live with the ability to do this by only specifying an OID.

Still, I believe the trade off has _really_ gone towards
simplicity and not flexibility. Even the inhibitPolicyMapping, the
requireExplicitPolicy and the inhibitAnyPolicy are booleans instead of
integers.

Also, I disagree that one can send multiple requests. The trust anchor
for an OCSP response may not be the same as the one for the main
certificate and may have conflicting parameters.

Would it be complicated to leverage on RFC3125 which defines
a Trust Anchor as:

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

possibly replacing the Certificate by a PKCReference.

--
Julien

---

From: Russ Housley <[email-masked]>
Date: Tue, 24 Apr 2007 10:59:58 -0400

Mike:

If a validation policy includes several trust anchors, then it is 
desirable for the path validation algorithm inputs for each of these 
might be different.  I can live with the current structure, but it 
imposes the restriction that all of the trust anchors associated with 
the validation policy must be used with the same path validation 
algorithm inputs.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 24 Apr 2007 17:28:09 -0800

Russ,

Your explanation suggests "equivalency".
I fear for in-band negotiation of that
state absent a use-case requirement.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
Sent: Tuesday, April 24, 2007 7:00 AM
To: Michael Myers
Cc: [email-masked]
Subject: RE: SCVP Question regarding Trust Anchors

Mike:

Russ

---

From: "Julien Stern" <[email-masked]>
Date: Wed, 25 Apr 2007 10:52:17 +0200

Mike,

just check RFC3125 (part of PKIX).
It defines a validation policy where several trust anchors
are associated with different inputs.
The benefit would be to be able to validate such a policy with SCVP.

--
Julien

---

From: "Julien Stern" <[email-masked]>
Date: Wed, 25 Apr 2007 15:05:26 +0200

> The benefit would be to be able to validate such a policy with SCVP.

A few people let me know that
1) RFC3125 is part of S/MIME (not PKIX)
2) It is "Experimental"

However, it is related to the ETSI technical reports 102038 and 102272,
which define a broader notion of Trust Anchor than SCVP.

Well, that's for the benefit: being in sync with these TRs and the
Experimental RFC. That being said, as Russ, I can live
with the current situation. It is always possible to define a local
policy that has more complex Trust Anchors...

--
Julien

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 26 Apr 2007 14:55:26 -0700

A certificate can contain information that tells a relying party where to find information to verify the status of information provided by the issuer.

The purpose of SCVP is to provide information on the trustworthyness of the information provided by the issuer. It does not make any sense for the issuer to be involved in supplying trust chain validation information and providing trust chain discovery information makes only limited sense. 

A more appropriate mechanism for this requirement would be to advertise the location of the SCVP server for a domain by means of a DNS SRV record. In practice two records are needed, one for path discovery (which may be asserted by the issuer) and the second for validation (which the relying party needs to choose).

My machine knows that it is part of the verisign.com network. So why not deploy DNSSEC and then advertise the location of the local trust chain discovery and validation service via a DNSSEC secured SRV record? That server knows the trust criteria for the domain and can make a useful interrogation of the relying party path discovery server.

Alternatively use the DNS to discover your XKMS servers for the same purposes.

DNSSEC signed SRV is the way to cut through the Gordian knot of PKI deployment.

> [mailto:[email-masked]] On Behalf Of Julien Stern
> Sent: Wednesday, April 25, 2007 9:05 AM
> To: Michael Myers; Russ Housley; [email-masked]
> > It defines a validation policy where several trust anchors are 
> > associated with different inputs.
> However, it is related to the ETSI technical reports 102038 
> and 102272, which define a broader notion of Trust Anchor than SCVP.
> 
> Well, that's for the benefit: being in sync with these TRs 
> and the Experimental RFC. That being said, as Russ, I can 
> live with the current situation. It is always possible to 
> define a local policy that has more complex Trust Anchors...
> 
> --
> Julien
> 
> > --
> > Julien
> > 
> > > I fear for in-band negotiation of that state absent a use-case 
> > > requirement.
> > > 
> > > Mike
> > > 
> > > imposes the restriction that all of the trust anchors associated 
> > > with the validation policy must be used with the same path 
> > > validation algorithm inputs.
> > > 
> > > Russ
> > >