RE: [ebxml-cppa] Re: Security Details

[Dale Moberg <dmoberg@cyclonecommerce.com>]

1. Multiple CAs may be announced within a SecurityDetails/TrustAnchors

element by each AnchorCertificateRef, by the IDREF pointing

eventually to a KeyInfo.

2. We leave it open whether the chain or just the CA is in the

referenced KeyInfo element, because there is no way for us

to restrict KeyInfo to just one certificate, that I know of. (And if

there is, I think we should just leave it the way XMLDsig defined

it.) This seems harmless. If a chain

is included, then I think it would be OK to verify 

a certificate by chaining up to any element

within that chain. We do not have any parameters

saying what the maximum number of

links can be in the chain to root. If you believe

these restrictions cause interop problems, please elaborate. It

should be obvious which certificate is the CA "root" because

it should be self-signed. I suppose there could be a trust model

in which there is a circle of Co-CA signing going on, but that

is not something currently of interest.

 

-----Original Message-----
From: Himagiri(Hima) Mukkamala [mailto:himagiri@sybase.com]
Sent: Monday, February 04, 2002 3:47 PM
To: Arvola Chan
Cc: Tony Weida; Peter Ogden; CPPA
Subject: Re: [ebxml-cppa] Re: Security Details

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