Sacha,
Good analysis. Also I think there are two use cases here -
a) use of other independent means to verify partner certificate -
e.g. email, postal, write-once media, other authority intermediary
b) standalone verification
I've mostly seen a) where setup includes exchange of certificates by
other means, or verification by trusted third party service. Clearly you are viewing b) where the ebMS itself is able to self-authenticate and configure.
I think b) is something most operational environments are not attempting
yet - which is why most people have not encountered issues? So - for b) - I think we need to decide what use cases we are looking to allow.
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: Sacha Schlegel <>
Date: Sun, February 18, 2007 10:46 am
To: "David RR Webber (XML)" <>
Cc: ebxml-cppa <>
Hi David,
BTW this "how to enable self-signed certificates" is not exclusive
for
SSL but is also the case for encryption and digital signatures
configuration.
I think one aspect is how you interpret the CPA.
A)
For example if I have a list of trusted root certificates I could
argue
that no matter what certificate my partner uses, as long as it is
signed
bye one of those trusted certificates I am fine.
-> I think this is not true for the CPA because we also agreed
which
exact certificate the server MUST use and strict interpretation
would
invalidate the CPA.
B)
BUT I can also argue that in the CPA we have a) the list of trusted
certificates BUT b) also the explicitly selected certificate for
the
server (in an SSL example). So if my tool is strict I will not allow
the
other server to present just about any certificate that is signed by
one
of my trusted root certificates but it also requires the other server
to
present the exact one certificate he (the partner) listed in the
CPA.
>From the CPA XML schema:
o the "ServerCertificateRef" (server SSL certificate) element is
for
example mandatory. Party A side
o there can be 0 TrustAnchors in a SecurityDetails element. Party
B
side.
So in one case there could be no TrustAnchors but the required
ServerCertificateRef.
What does the absence of TrustAnchors mean?
o anything goes, anything is fine? or
o I do not trust you at all, no matter what certificate you have. ->
an
empty TrustAnchor would then seem useless in a CPA.
Clearly to allow self-signed certificates the partners certificate
must
be listed in the list of trusted certficiates as a self-signed
certificate is signed by itself.
I think one good use case of the trusted certificates is the one in
a
CPA formation process, eg prior the ebXML CPA is created. Then it
is
important whether a tool shall allow to add another partners
self-signed
certificate to the trusted certificates or not ... a security
person
probably would say no "simply" because it makes the whole thing
easier
to setup with self-signed certs is no argument to change security
policy. So when creating a CPA we can have a rule that my partners
certificate must valid in respect to my TrustAnchors and the same for
my
certificate that it must respect my partners TrustAnchors. Otherwise
such a CPA formation tool should not create the CPA because it
is
invalid regarding these considerations.
Too bad there is no real ebXML CPPA interop done. Such an interop
would
look at how an ebXML Messaging System that has CPA support deals
with
different CPA's. Soon I will some time to check Korbits CPA interop
support to see how far they have gone.
Two things I will take home from this:
o to list my a parties own certificates in one of its TrustAnchor
seems
useless. Maybe I used to put them because the TrustAnchor element
cannot
be empty but I missed that the TrustAnchor element itself is
optional.
o to enable self-signed certificates I will stick the other parties
certificate into my TrustAnchor and vice versa.
Sacha
Am Sonntag, den 18.02.2007, 07:58 -0700 schrieb David RR Webber
(XML):
> Sacha,
>
> Note that in production environments using firewall tools like
"Big
> IP" and SSL connection - this is a moot question - because the
partner
> must send a copy of the certificate to be loaded on the Big IP
device
> for verification purposes anyway - if they are not using one of
the
> trusted certificate authorities.
>
> So perhaps the CPP should indicate "PreRegistrationRequired"
for
> individual certificates? And then in the CPA - this would be
set to
> "Pending/Confirmed" depending on the state of that process?
>
> 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: Sacha Schlegel <>
> Date: Sun, February 18, 2007 6:00
am
> To: ebxml-cppa <>
>
> Hi ebXML CPPA team.
>
> The ebXML CPPA spec actually suggests
('may be added' -> I do
> not know
> how to do it otherwise though except
some new SecurityPolicy
> setting) to
> add the "other parties self-signed"
certificates to this
> parties
> appropriate TrustAnchors.
>
> Appendix 5 section "E.5.2.3 DocExchange
Checks for
> BusinessTransactionCharacteristics" in
paragraph starting at
> line 7162.
>
> So that confirms me to add them to the
appropriate
> TrustAchnors element.
>
> The question how we can specify in a
CPP to allow self-signed
> certificates is still open. Clearly an
option is to not
> express it in
> the CPP and let it be negotiated
(manually or electronically)
> in the CPA
> formation process. A clear directive
such as
> "AllowSelfSignedCertificates" could
help the CPA formation
> process.
>
> Sacha
>
> Am Sonntag, den 18.02.2007, 11:31 +0100
schrieb Sacha
> Schlegel:
> > 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
> >
> >
