Subject: Verifying certificate chains with different policies

From: Dean Povey <[email-masked]>
Date: Mon, 18 Jan 1999 16:50:38 +1000 (EST)

Hi all,

I am involved in the Standards Australia Working group IT/12/4/1 which
is looking at the deployment of a Public Key authentication framework
in Australia.  We are currently having a problem with how to handle
"policy chains" using the X.509 and PKIX certificate path processing
techniques, so I thought I might throw this question at PKIX'ers to
see if someone can come up with an appropriate solution.

(NB: the term "certify" is somewhat confusing when mixing X.509 and
ISO9000 jargon.  In X.509 it usually means to assure the binding
between a private/public key and one or more attributes (usually an
identity).  In the ISO9000 sense it means to audit ones compliance
with stated procedures and practices.  In the discussion below the
X.509 sense is meant unless otherwise indicated).

Our problem is this: one of the architechtures that we wish to support
is a hierarchy of CAs within an accreditation framework (similar to
ISO9000).  The way this would work would be to have a root authority
(RA) which acts as an accreditation body.  The RA then accredits
intermediate CAs (or ICAs), who in turn certify (in both the X.509 and
the ISO9000 sense) organisational CAs (OCAs).  Part of the role of the
ICA then in addition to POP and verifying the OCAs identity, is to
audit the OCA against the policy and practices they claim to
implement.  An OCA can then issue certificates to end entities or to
other OCAs depending on what policy they support.

Now the problem is this, there are several different policies at work
here: (In the notation below X -> Y means the certificate where X
certifies Y.)

RA -> RA : Policy indicating that the RA is an accreditation body

RA -> ICA : Policy indicating that the ICA can act as a certifying (in
	    the ISO9000 sense) body.  This policy may or may not
            specify the types of OCA that the ICA can specify.

ICA -> OCA : Policy indicating how the OCA will issue certificates.
             This also indicates that the ICA has been certified (in
             the ISO9000 sense) the OCA as implementing this policy or
             its CPS correctly

OCA -> EE : Policy indicating how the EE was identified.

Each of these policies has different semantics and so should be
interpreted differently.  While the ICA->OCA and the OCA->EE might be
able to be issued under the same policy if that policy differentiates
between certs issued to CAs and certs issued to End entities.  The
RA->RA and RA->ICA certififcates are obviously very different from the
ICA->OCA policy.  This is because the ICA should be able to issue
certificates to OCAs under any policy it wants whereas the RA->RA and
RA->ICA certs will be a specific policy saying that the ICA has been
accredited to act as a certifying (in the ISO9000 sense) body.

However when processing Certificate paths, you simply input a list of
acceptable policies and each certificate in the path must support one
of those policies (or an equivalent policy).

The problem I guess, is that here we want to enforce a particular
ordering of policies (or a "policy chain").  We want our certificate
paths to start with an accreditation body, which is followed by an
ICA, a certified (in the ISO9000 sense) OCA and then an EE.  There
seems to be no way to do this and enforce those semantics using the
existing path processing and policy extensions.

Is the problem clear?  Does anyone have a suggestion for how we might
work around this problem?

--
Dean Povey,         | e-m: [email-masked]     | Cryptozilla:
Research Scientist  | ph:  +61 7 3864 5120       |  www.cryptozilla.org/
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 18 Jan 1999 17:04:20 +0100

Dean,

> of those policies (or an equivalent policy).

Another parameter has to be taken into consideration: the naming constraints
as well. They may be even more important than the policies.

Regards,

Denis

---

From: "Dwight Arthur" <[email-masked]>
Date: Wed, 20 Jan 1999 08:34:07 -0500

Dean, you may benefit from reading the document at
http://internetcouncil.nacha.org/CARAT/CARAT921.pdf

In the approach advocated by CARAT, your RA the Policy Authority. The Policy
that it adopts covers the obligations and responsibilities of all of the
other parties. Specific contracts may be derived from the policy for
specific types of parties but all are tied to the policy by contract.

Using this approach, instead of multiple policies you have a single policy,
but a need bind each party to one of the various roles within the policy.
Specifying roles within an X.509v3 PKI is not altogether straightforward but
it's closer to the mainstream than trying to enforce a defined hierarchy of
policies.
------------------------------------------------
p:(212) 412-8687                   Dwight Arthur
f:(212) 908-2345      Managing Director: Systems
b:(917) 646-6682    National Securities Clearing
[email-masked]              55 Water Street
http://www.nscc.com      New York, NY 10041-0082

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Jan 1999 14:28:30 -0500

Dean,

I think that one should keep the notion of accrediation of CAs (relative to
some criteria) very separate from PKI topology for validation of
certificate paths.  CAs can express the policies that they follow via
appropriate extensions, and the accrediation authorities can then attest to
the fact that the CAs in question do follow these policies.  The
attestation can take many forms, including attribute certificates, online
queries, etc.

Steve

---

From: Dean Povey <[email-masked]>
Date: Thu, 21 Jan 1999 09:22:26 +1000

>attestation can take many forms, including attribute certificates, online

I agree completely.  However I was trying to point out that the system we are 
proposing requires you to enforce different policies and enforce an ordering 
of those policies in a certificate path.  What I was indicating is that it is 
not possible to enforce ordering of policies using the given X.509 framework.  
This would seem to be a useful goal irrespective of whether there is an 
underlying accreditation framework.  X.509 uses the idea that a certificate 
path should contain certificates that are issued under the same (or deemed 
equivalent) policies.  However, I think there are many cases where this is not
appropriate (particularly as the length of the path increases).

BTW: The most pragmatic way of doing this I have seen so far is to specify 
all the policies in the initial policy set and rely on individual CAs in the 
path to enforce the ordering.  I still think that it would be nice if the 
path validation process could prove this assertion for you (but then I guess
there are a lot of things that it would be nice to have).

Cheers.