(long) RE: [ebxml-cppa] Purpose of CertificateRef in CollaborationRole

[Dale Moberg <dmoberg@cyclonecommerce.com>]

 

 PeterOgden> Can anyone provide any thoughts or historical perspective on the intended use of the CertificateRef that exists in the CollaborationRole element?  

 

D ale tries>> 

  

I think there may be at present 8  possibly distinct

PartyId certificates that pertain to the CPP or CPA!!

(Yikes, and this does not even count the certificates

that will be referenced in the TrustAnchor element)

 

1. The signing certificates used to sign the CPP or CPA

(I think this will normally be found within a KeyInfo element in the relevant signatures.

Not further discussed.)

2. The certificate for the PartyInfo application layer certificate,

    used by the party for certificate-dependent security operations.

3. The certificate used by a SSL server to authenticate itself.

4. The certificate used by  a SSL client to authenticate itself.

5. The certificate to be used in the KeyExchange function for digital envelopes

6. The certificate to be used in NonRepudiationofOrigin signatures

7. The certificate to be used in NonRepudiationofReceipt signatures

8. The certificate to be used in ebXML Messaging signing of a message

 

Unfortunately, it is not likely that the same certificate

will be used, if all these

capabilities are specified or in CPP (or CPA template)

or subject to an agreement in a CPA.

It is also not likely that distinct certificates will be used

for each of these functions!

 

I believe that in Tokyo representatives of financial groups introduced the

requirement that payloads be signable or enveloped

by "applications," and that it could not be assumed that

a MSH could carry out that signing on behalf of the application

(that is, access to the private key might not be available to the MSH).

[Maryann Hondo at IBM would probably remember the details here.]

So payloads could be submitted to a MSH that already were signed

or enveloped. A MSH would follow packaging formats to send that payload

within an ebXML message. I think that is why a certificateref occurs

under the CollaborationRole-- to allow the agreement to be made on

certificates pertaining to application applied security properties.

 

One defect even in this approach is that some PKI installations want

distinct signing and enveloping certificates-- for example,  when there is

escrow for the enveloping certificate. To make this work, the

KeyInfo element would have to contain both a signing and

an enveloping certificate. While this is possible, the CPP and CPA

do not explicitly indicate what kind of certificates are in

the KeyInfo element. Even with the new  element flavors

(of CertificateRef.type) , I don't think we indicate what certificates

are present. I think the presumption is that the MSH does

not explicitly use these certificates, so it has not been a priority

to mark all these distinctions.

 

So given that we do have a certificate for a CollaborationRole, for

situations where MSH security operations only have one

keypair, the same certificate could be used for digital enveloping,

signing, or (less likely) the transport server  or client side

authentication. I think that is where the "default" interpretation

is coming from; I am not certain where it originated. Possibly

this interpretation should be eliminated.

 As an "optimization" it may be creating

more confusion than it is worth.

 

After all, if the same certificate

is used throughout, we would at most only be repeating the use

of a reference to its ID value-- not the whole certificate!

 

 I think I would support the

idea of restricting the CollaborationRole certificateref to

having the unique function of pointing to certificates used

by layers above the MSH. If so, it should be an optional

(0 or 1) element.

 

 

 PeterOgden" Arvola recently renamed it "DefaultSigningCertificateRef",  

 which would indicate that it can be used whenever a signing cert is needed.  \"

 

Dale>OK, maybe we should rethink this.

 

  

PeterOgden> "But the list archive has several threads which indicate that CertificateRef(s)  

 under DocExchange/../NonRepudiation are to be used for this purpose. 

  Furthermore, section 7.5.3.3 of the v1.0 CPPA spec, which pertains to the  

 CertificateRef in the CollaborationRole, contains the following note:

Note: This certId attribute relates to the authorizing role in the  

 Process Specification while the certificates identified in the  

 delivery-channel description relate to Message exchanges. " 

---

 " This seems to imply that the CertRef in the CollaborationRole element  

 is to be used by some business process, not by a messaging service.  

 Is this still a valid comment? "

 

Yes, I think it is valid. I think the default certificate concept may be one we need

to give up on, even though it might have been simpler. I think using the flavored

approach to CertificateRef that Arvola has introduced means we should probably

just drop the default interpretation.

 

Arvola, do you think we should retain the DefaultSigningCertificateRef idea or

rename it to something like "ApplicationLayerCertificateRef"?