ebcore — archive

[Pim van der Eijk]

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