[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: (long) RE: [ebxml-cppa] Purpose of CertificateRef inCollaborationRole
Marty,
We needed this to distinguish Client
from Server side certificates
under TransportSecurity. There was
no way to tell in that situation,
unless we hung some under SendingProtocol,
which was not popular
So we had to do this change to
correct the missing client SSL agreement.
The other changes
were made for consistency
and to help the security implementer remember
which element to set or get.
Very few implementations are yet
deployed in real production.
The changes are really either
clarificatory or to fix a shortcoming, IMO.
We decided by consensus
to adopt Arvola's approach (rather than a
similar attribute based approach
that I proposed) some time ago.
They seem OK to me, though it does add
a lot of new elements; I did
point this out, but no one besides
me seemed to think it a weighty point!
Let me know if you want the issue to
be on the agenda for early January.
Dale
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, December 18, 2001 1:29 PM
To: Peter Ogden
Cc: Arvola Chan; Dale Moberg; ebXML-CPPA (E-mail)
Subject: RE: (long) RE: [ebxml-cppa] Purpose of CertificateRef in
CollaborationRole
Do we really need to rename all the certificateRef elements to
use-specific
names? The use of the certificate should be implied by the element that
it
is a child of. Aren't these element name changes unnecessary changes
for a
maintenance release? The will cause additional grief to existing
implementations.
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
************************************************************************
*************
Peter Ogden <pogden@cyclonecommerce.com> on 12/18/2001 03:13:59 PM
To: Arvola Chan <arvola@tibco.com>, Dale Moberg
<dmoberg@cyclonecommerce.com>, "ebXML-CPPA (E-mail)"
<ebxml-cppa@lists.oasis-open.org>
cc:
Subject: RE: (long) RE: [ebxml-cppa] Purpose of CertificateRef in
CollaborationRole
Hi Arvola,
Rather than doing away with the DefaultSigningCertificateRef in
CollaborationRole, why don't we rename it something like
"ApplicationCertificateRef", or "BusinessProcessCertificateRef" - that
way, it is available to negotiated and agreed upon (even though it won't
be
used by the MSH, which my comments in the text will reflect).
Regarding the cert refs in DocExchange: the 04 draft schema has a
single
EncryptionCertificateRef under DigitalEnvelope. Are planning to add
another, much like you did for NonRepudiation?
Also, I gather from your last paragraph below that you intend for the
initiatorCertifcateRef to be used for signing requests and asynchronous
responses, and that the responderCertificateRef would be used for
signing
synchronous responses. Would it work just as well to suggest that the
initiatorCertificateRef be used for requests and
the responderCertificateRef be used for all responses (both synch and
asynch)? It just seems more logical to tie the use of the cert to
its role
in the message exchange rather than to the "synchronicity" of the
protocol.
Finally (and this is a nit), would you mind initial-casing the NR
certifcate ref names (InitiatorCertificateRef and
ResponderCertificateRef)? Just to be consistent with the others ...
Respectfully,
Peter
-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Tuesday, December 18, 2001 12:11 PM
To: Dale Moberg; ebXML-CPPA (E-mail)
Cc: Peter Ogden
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"?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC