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

Dale,

 

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
certificates?
From: "Dale Moberg" <>
Date: Mon, February 19, 2007 7:42 pm
To: "Sacha Schlegel" <>, "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:] 
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.

-------------------------------------example----------------------------
-
* 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

-------------------------------------example----------------------------
-

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
certificates.

Thoughts?

Sacha Schlegel