[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?
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 <sacha@schlegel.li>
> Date: Sun, February 18, 2007 6:00 am
> To: ebxml-cppa <ebxml-cppa@lists.oasis-open.org>
>
> 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
> >
> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]