Re: (long) RE: [ebxml-cppa] Purpose of CertificateRef inCollaborationRole

[Arvola Chan <arvola@tibco.com>]

Marty:

Thanks for the reminder. I will try to point this out in the spec updates I
am going to send to Tony.

-Arvola

-----Original Message-----
From: Martin W Sachs <mwsachs@us.ibm.com>
To: Arvola Chan <arvola@tibco.com>
Cc: Dale Moberg <dmoberg@cyclonecommerce.com>; ebXML-CPPA (E-mail)
<ebxml-cppa@lists.oasis-open.org>; Peter Ogden <pogden@cyclonecommerce.com>
Date: Tuesday, December 18, 2001 11:54 AM
Subject: Re: (long) RE: [ebxml-cppa] Purpose of CertificateRef in
CollaborationRole



...and we must make it very clear that in spite of the fact that the
specification says that a delivery channel contains receive properties, the
certificates referenced by the delivery channel are used for signing and
encrypting outgoing messages and are therefore send properties.

Regards,
Marty

****************************************************************************
*********

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
****************************************************************************
*********



Arvola Chan <arvola@tibco.com> on 12/18/2001 02:10:55 PM

To:    Dale Moberg <dmoberg@cyclonecommerce.com>, "ebXML-CPPA (E-mail)"
       <ebxml-cppa@lists.oasis-open.org>
cc:    Peter Ogden <pogden@cyclonecommerce.com>
Subject:    Re: (long) RE: [ebxml-cppa] Purpose of CertificateRef in
       CollaborationRole




Dale:

I was assuming that if certificate references are missing from  the
NonRepudiation element, then perhaps the certificate reference included in
the CollaborationRole element may be used as the default. I agree that this
is a  confusing optimization and that we should do away with the
defaultSigningCertificateRef attribute.

I think many implementations will want the MSH to sign on  behalf of the
applications. Therefore, the certificate references in the  NonRepudiation
element should be usable by the MSH for signing purposes.  Otherwise, where
are we recording the signing certificate that the MSH will be  using?

In the 1.0 spec, section 7.6.5 NonRepudiation element, it is  stated:

"If the NonRepudiation element is omitted, the Messages are  not digitally
signed."

The NonRepudiation and DigitalEnvelope elements under  DocExchange may be
referenced by a DeliveryChannel that is used synchronously.  Therefore,
each of NonRepudation and DigitalEnvelope should contain two  certificate
references, one is required for the normal case, the other is  optionally
used for signing or encrypting responses that must be returned
synchronously.

-Arvola

-----Original Message-----
From:  Dale Moberg <dmoberg@cyclonecommerce.com>
To:  ebXML-CPPA (E-mail) <ebxml-cppa@lists.oasis-open.org>
Cc:  Peter Ogden <pogden@cyclonecommerce.com>;  Arvola Chan <
arvola@tibco.com>
Date: Tuesday,  December 18, 2001 10:15 AM
Subject: (long) RE: [ebxml-cppa] Purpose of  CertificateRef in
CollaborationRole




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"?