Zahid Ahmed writes:
" I'm concerned Transport Security Policy is including informatioon
about
Trusted CA issuers (as part of TrustedAnchors) and not TrustedClients,
which means that transport security information is incomplete w.r.t.
capturing of relevant authentication policy
information.
" In the specific example of SSL mutual authentication (for which
the CPA/CPP spec has included relevant TransportClientSecurity and
TransportServerSecurity components) between 2 colloborating
parties' MSHs if we will exploit fromthe CPA/CPP's
TrustAnchor, i.e., Trusted CA Roots information,
then we should also be able to
maintain TrustedClient or
TrustedDomains information."
The CPA itself binds the two parties into a relationship, and trust
(supported by PKI sub agreements) is part of the overall documented
agreement. In other words, when client side SSL authentication is
agreed to, the certificate used by the client is referenced in
the CPA. The TrustAnchors are also listed, and in a workable
agreement, the client SSL certificate must validate with respect
to the anchors (for economy, the TrustAnchor in a CPA may be only
the one(s) relevant to certificate validity of the correlative
certificate. It seems to me that the proposed
"TrustedClient" element may already be covered/handled by the element
with type CertificateReference.type. This certificate is the
specific one to be used in the PKI operation agreed to in
the CPA. So this cert. is one of the trusted client ones.
(At any rate, the requirement for Transport security was
that there should be ways to indicate a Server cert,
a client cert, the TAs for the server cert, and/or the TAs
for the client cert. The path for the CertificateRef.type
element should be a sibling to the SecurityDetailsRef.
Remember, though, that in the CPA, the TAs "go with" the CertificateRef
on the other PartyInfo's corresponding element. I believe, or
more accurately, I hope that the explanatory text explains this.)
Let me know if you have something completely different in mind.
The notation is hopefully no more complex than what is being
represented.
I certainly agree that we have a lot of tacit and inexplicit
items connected with security, authentication, and authorization.
The exact checking procedure(s) to be used and the access permissions
(ACLs) associated with these SSL client checks are not yet
documented and so are implementation dependent. In a way,
that is even true when we come to digital signatures (ebMS XMLDsig
signatures). That is, ebXML specifications do not explicitly
mention what ACLs get tickled when the message signature checks out
(nor even all the checks involved); presumably enough rights are
granted to get the payload to the application destination somehow.
It might be worth mentioning all the checks that "might" be made: there
might be a check that the certificate used in the ebMS signature is
one approved for the service, action, cpaid, and "from" values.
Otherwise, a signature could be valid, the cert chain valid, the
certificate one that is _a_ "TrustedClient" cert, but still a renegade
approved user could be trying to spoof a request by pretending
to be another user in the "from", cpaid and other fields.
(or trying to make a request for a response
that was not yet agreed to). I am not certain how risky this threat
is, and it would be pretty easy to track down a plausible suspect once
the problem gets detected!