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