Verifying certificate chains with different policies

[Dean Povey <povey@xxxxxxxxxxx>]

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: povey@dstc.edu.au     | 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/