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