I guess what I was trying to point out was, if
the intent is to show that each of the Certificates
pointed by references in TrustAnchors element
was a Certificate for TrustAnchor, then it cannot
be a chain. Each of them should point to a single
Certificate which should be the Certificate for a root CA.
What I was also saying is that, we should provide a
list of CA Certificate Refs(intermediate) for path validation.
We cannot restrict KeyInfo to include just one Certificate,
but do we've to state that by naming it TrustAnchors, they
should have the Certficate for Root CA only and not a chain.
-hima
Dale Moberg wrote:
1.
Multiple CAs may be announced within a SecurityDetails/TrustAnchorselement
by each AnchorCertificateRef, by the IDREF pointingeventually
to a KeyInfo.2.
We leave it open whether the chain or just the CA is in thereferenced
KeyInfo element, because there is no way for usto
restrict KeyInfo to just one certificate, that I know of. (And ifthere
is, I think we should just leave it the way XMLDsig definedit.)
This seems harmless. If a chainis
included, then I think it would be OK to verify a
certificate by chaining up to any elementwithin
that chain. We do not have any parameterssaying
what the maximum number oflinks
can be in the chain to root. If you believethese
restrictions cause interop problems, please elaborate. Itshould
be obvious which certificate is the CA "root" becauseit
should be self-signed. I suppose there could be a trust modelin
which there is a circle of Co-CA signing going on, but thatis
not something currently of interest.
But by definition "TrustAnchor" refers to the Certificate of CA
at the root of the certificate chain.
I guess, my question would be, are we trying to convey the certificate
path or the TrustAnchor.
IF we want to convey just the TrustAnchor, each TrustAnchor element
should be a reference to a single CA Certificate. But that's not going
to convey the certificates in the chain that may be employed to validate
the certificate!
IF we want to convey a set of CA certificates, i.e. intermediate CAs
we should employ a list of certificates but name the
the element something else, which could include TrustAnchors
for a child element.
THis way implementors could use a CertPath Building tools based on
these intermediate CAs and the root TrustAnchor CA to validate a certificate
-hima
Arvola Chan wrote:
Tony: I
think it is intended that TrustAnchors may occur any number of times. Each
TrustAnchors element represents a certificate chain rooted from one trusted
Certificate Authority. The other party's certificate must be signed by
one of the certificates in any of the certificate chains in order to be
valid. -Arvola
-----Original
Message-----
From: Tony Weida <rweida@hotmail.com>
To: Arvola Chan <arvola@tibco.com>;
Peter Ogden <pogden@cyclonecommerce.com>
Cc: CPPA <ebxml-cppa@lists.oasis-open.org>
Date: Monday, February 04,
2002 1:08 PM
Subject: Security Details
Arvola and Peter,
Under SecurityDetails, the XSD specifies maxOccurs="unbounded"
for both TrustAnchors and SecurityPolicy.Since
the TrustAnchors element contains one or more AnchorCertificateRef elements,
shouldn't there be at most one TrustAnchors element?Since
SecurityPolicy has unconstrained contents, and considering (if nothing
else) the aesthetic appeal of a "unified" security policy, shouldn't there
be at most one SecurityPolicy element?Thanks,Tony
|