OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ebxml-cppa] How to allow/disallow self-signed certificates?

Good clarification - yes - people should realize that out-of-band verification is needed for these self-signed certificates.
Suggest we note that - and that telephone, email or other out-of-band communication is noted as needed to confirm the details of the certificates.
Is there something we could add possibly to CPA?  Optional element in header?
 <out-of-band-confirmation  date="yyyy/mm/dd" confirmationID="my-initials" certificateID="12345" method="telephone| email | mail"/>
maybe draw specific attention to this aspect.  I think this is something we're going to see much more use of.
Thanks, DW

"The way to be is to do" - Confucius (551-472 B.C.)

-------- Original Message --------
Subject: RE: [ebxml-cppa] How to allow/disallow self-signed
From: "Dale Moberg" <dmoberg@us.axway.com>
Date: Mon, February 19, 2007 7:42 pm
To: "Sacha Schlegel" <sacha_oasis@schlegel.li>, "ebxml-cppa"

I can add this issue to the agenda this week for discussion if you can
attend Friday. Here are some general remarks.

Self-signed certificate usage does not fit smoothly into the CPP to CPA
flow. In general, some modifications to the public announced CPP
information  needs to occur when using self-signed certificates.

With a self-signed certificate, the certificate gets trusted by some
process of direct trust. There is no CA really, but the situation can be
viewed as involving a trust anchor, which is the certificate itself.
There is little point in putting your certificate in your trust anchor
lists in your CPP, of course. What needs to happen (assuming that both
parties are using self-signed certificates for both signing and
encryption (key exchange)), is that the corresponding party's
certificate gets added to the trust anchors of each party. No
verification of the certificate by the signer is done because there is
no signing chain to verify (or, you can view it as a minimal length
chain of one node and just check that the signature in the certificate
matches the certificate's hash). In practice, what may happen is that a
phone call is made so that the other party's certificate fingerprint can
be checked before the certificate is added to some trusted certificate
store. Or some such "out of band" process occurs to check on the
certificate being trusted.

In the CPA case, both sides will be able to check that their certificate
is the one the other side is to use, and they can optionally sign this
agreement. The CPA then serves to indicate the mutual trust. I believe
that there was or at least could be language stating that each party
adds the other party's certificate to the appropriate trust anchor
lists. This is a kind of formality because the "real" trust occurred
outside the normal processes of CA based certificate verification when
the certificates are self-signed.

-----Original Message-----
From: Sacha Schlegel [mailto:sacha_oasis@schlegel.li]
Sent: Sunday, February 18, 2007 3:32 AM
To: ebxml-cppa
Subject: [ebxml-cppa] How to allow/disallow self-signed certificates?

Hi ebXML CPPA team

I wanted to note an observation I made. Often self-sigend certificate
are great to setup a test environment where certificates are used.
Whether to allow self-signed certificates in a production system is
another discussion and some argue against it.

OK to enable self-signed certificates in the CPA we must add the "other
parties" certificate to our SecurityDetails element because we only
trust certificates that have been signed by one of the certificates
listed in the appropriate SecurityDetails and a self-signed certificate
(as the name indicates) is signed by itself.

* Party A:

certificate A-1
certificate A-2

trust A-trust
 * certificate B-1

transport A-t
 use ssl version 3.0
 when receiving use certificate A-1 as server SSL cert
 when receiving only trust a client SSL cert that has been signed by
one of the certs listed in trust A-trust

* Party B:

certificate B-1
certificate B-2

trust B-trust
 * certificate A-1

transport B-t
 use ssl version 3.0
 when sending use certificate B-1 as client SSL cert
 when sending only trust the server cert that was sigend by one of
trust B-trust


Actually two interesting observations

a) If B sends an ebXML message to A it can determine the SSL server
certificate that A will be using (must look at the appropriate place in
the other PartyInfo). So there will be two checks required: 1. The SSL
Server certificate of A must match the one in the CPA AND 2. the SSL
Server certificate must be signed by one of trust B-trust.

-> clearly check number 2 can be done at CPA import time and a system
can reject to import the CPA if the server certificate is not signed by
one of the trust certificates. But I think this check must still be done
at run time.

b) in case of allowed self-signed certificates the cpa formation process
does need to update the trust elements (the SecurityDetails element in
the real CPA) and must add the "others" SSL Server, SSL Client
certificate to the trust (SecurityDetails/TrustAnchor) element.

More thoughs:

Question: How to express to accept self-signed certificates in the CPP.

Answer: I think the optional SecurityPolicy element could be used for
this, to allow self-signed cert (for a test setup useful) or not.
Unfortunately the SecurityPolicy element is an empty sequence.

Suggestion: A new element could be added to the SecurityPolicy element.
Eg an optional element such as "AllowSelfSignedCertificates"? The
absence of this element could mean to NOT trust self-signed


Sacha Schlegel

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]