X.509 related features CPPA3

[Pim van der Eijk <pvde@sonnenglanz.net>]

Dear all,

For CPPA3, one of the last outstanding issues is to improve/finish its 
support for X.509 certificates, PKI, chaining, key selection and 
discovery. The following is notes on work in progress and a summary of 
some offline discussions with Dale, for your review and comment.

Right now for CPPA3 we kept the basic ideas of CPPA2: a party can define 
lists of certificates and of sets of trust anchors and can associate a 
certificate or a trust anchor reference to a channel for a particular 
purpose. E.g. a signingCertificateRef can be specified for the sender's 
channel and a signingCertificateTrustAnchorRef for the receiver's 
matching channel. In CPA formation, this information is used to check 
that the specified referenced signing leaf certificate chains to a trust 
anchor (if the receiver specifies a trust anchor).

A first generalization suggested by Dale is to allow parties to express 
constraints on certificate policies. A Certification Authority that 
issues certificates can implement a particular policy, or different 
policies for different classes of certificates. A policy can be 
identified using a OID, registered with by IANA. An issued certificate 
can indicate under which policy (or policies) it was issued, using the 
"certificatePolicies" X.509 extension. What we could do in CPPA3 is to 
add extensions to allow a party to specify lists of policy OIDs and 
policy list references. The semantics of the list would be to express a 
requirement that any Policy CAs and the issuing CA implement a 
referenced policy. This list of policy OIDs could be used instead of, or 
in addition to, a list of trusted root CA certificates.

The matching of certificates to trust anchors in CPA formation is like a 
"compile time" check, the produced CPA can include the presented leaf 
certificate, if it passes the checks. Some run time checks would 
obviously still be needed at run time, e.g. the certificate could be 
revoked after the agreement is formed. But otherwise, at run time, there 
is no difference with a situation where the sender used a (perhaps even 
self-signed) certificate that was explicitly pre-agreed with the 
receiver. There is no need to keep the trust anchor reference in the 
CPA, it served its purpose in CPA formation.

For more flexibility, in the CPPA3 schema we already added an option to 
allow the sender to provide an XKMS locate request query instead of a 
specific certificate. This decouples the use of the certificate from the 
specification of a specific certificate. The CPP would not specify a 
specific certificate, but a query to select one. Right now the spec does 
not specify where and when (CPA formation time or CPA use time) the 
query is expected to be executed. It leaves this functionality to 
implementations. So whether the query is done at CPA formation time or 
at runtime is unspecified. The use of the XKMS syntax does not require 
there to actually be any use of XKMS services. XKMS is in the draft 
schema as its LocateRequest is a standard XML syntax to specify a key 
selection.  Suggestions for other options are welcome.

If the party does not specify a signing certificate, or uses the XKMS 
Locate Request, but the receiver does specify the trust anchor ref, then 
we could keep the trust anchor reference in the CPA. The certificate and 
checks on it would then need to be done at run time. This may be 
possible in some situations, but there are many situations where users 
still expect to pre-configure leaf certificates, even if they use a 
specific PKI. Also, many B2B products assume leaf certificates to be 
configured and do not support processing messages with not previously 
presented certificates. So an idea (not yet in the draft schema) is to 
add a new Boolean element that indicates whether or not the party is 
actually capable of doing such run time lookups and PKI certificate 
checks or not. This would avoid unspecified or application specific 
behavior.

Comments to the list are welcome.  Also, some of us are meeting in Oslo 
next week for an informal meeting, I'll update the list with any 
feedback from there.

Pim