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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


Subject: [ebxml-msg] Note on current restricted scope of [ebxml-cppa]authentication policies/model in CPA/MSH


 
Zahid Admed writes:
 " I am reviewing the latest draft of tye CPA/CPP spec and I'm pleased to see that we have
broken down the TransportSecurity into its corresponding TransportClientSecurity and
TransportServerSecurity components.
 
 " However, I'm concerned about the current definition of SecurityDetailsRef. While the
TrustAnchor element will be used to specify all the Trusted CA Roots that an end-point
may be able to use to validate a SSL certificate chain is signed by a trusted issuer,
an important authentication policy that we need to be able to satsify is that only
mutually trusted parties should be to connect via their target MSH's. " 
 
 " To give a concrete example, I'm not sure if usage of trusted anchors is sufficient to satisfy
the above requirement of ensuring that trust-worthy ebXML sending party (or sending MSH) can
only communicate over the required transport (e.g., HTTPS) with receiving party (or receiving
MSH) if and only if sending party's client certifcate is issued by a trusted CA.  "
 
Thanks for raising some questions. I am responding to the first part of your message here.
I hope to respond to the remainder of your proposals soon. I will take your concern
with "only mutually trusted parties should be able to connect" to be a concern with
authentication/authorization and not a literal concern with preventing abuse of
connecting (DOS type concerns).
 
The TrustAnchors and the correlative certificates provide a means to reach agreements
for interoperable PKI operations (such as signing, key exchange, and transport authentication)
where certificate validity/trust is typically checked. At present, we are attempting to meet the
explicit suggestions of the ebXML Security group, and are not delving into larger areas
of PKI trust management (like CRL checking policies). So we are attempting to allow an
agreement to be made where both parties can tell that the certificate-checking side
can validate the certificate of the certificate using side ( the signer's cert for signatures,
the key exchange cert of the receiver for digital envelopes, etc.). That is about all we
aspire to at this point in introducing the SecurityDetails. So we would agree, the details
are surely not detailed enough to express all nuances subject to agreement involving
PKI management policies. We do think that we can promote PKI interoperability
by being able to configure systems so that certificates can be chained to root
during validity checks. (We will allow agreements to use self signed certificates,
and this will be done by augmenting TrustAnchors during CPA formation to include
the self-signed certificate ...)
 
You are also right in noting that specifying trust anchors does not in itself constitute a complete
authentication policy-- it is at best a component of the authentication policy.
Explicit checks on the DN, issuer serial number, etc might be used to check identity.
And identity might be variably mapped (ACLs) to resources depending on service,
action, role, and other parameters. Those more elaborate authorization issues are not things
treated in the current maintenance version. We are waiting to review specs
of other groups before taking on authentication or authorization.
Agreements on credentials for username/password tokens will need to use
encryption,  for example, so we are waiting on xml encryption being available.
The SAML and XACML groups may eventually produce specs usable for
some security policy expressions. So we are in a way avoiding getting into too much
detail here while some other supporting specs get finished.
 
I will try to respond to your constructive suggestion in a separate message.


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


Powered by eList eXpress LLC