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