[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] Re: Certificate Element under PartyInfo
People have raised security concerns about including actual certificates in the CPP or CPA. I included an item on referencing, rather than embedding, certificates in the open work items list. The prospect of having to deal with long chains of certificates further strengthens the argument that they should be referenced rather than embedded. I don't know much about PKI but it seems to me that referencing certificates may have another advantage. If a particular certificate has been invalidated, referencing the certificate ought to raise some kind of alarm whereas using an embedded copy of a certificate probably would not, at least not until much later. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* "Dale Moberg" <dmoberg@cyclonecommerce.com> on 10/19/2001 11:58:24 AM To: <ebxml-cppa@lists.oasis-open.org> cc: Maryann Hondo/Austin/IBM@IBMUS, Martin W Sachs/Watson/IBM@IBMUS, "Peter Ogden" <pogden@cyclonecommerce.com>, "Paul Bussey" <pbussey@cyclonecommerce.com>, <suresh_damodaran@stercomm.com> Subject: Certificate Element under PartyInfo With the emergence of Certificates that form the set of TrustAnchors (or trusted roots) in the SecurityDetails, the possibility arises that the same Certificates may be used in distinct PartyInfos in the CPA. So an opportunity for reuse (much like that of Packaging) arises. It may not be worth it. However, ds:KeyInfos can be large items (base 64 encodings of entire certificate chains, maybe 2 to 6 K range), it may be worth raising the Certificate element sequence up to just under the root elements-- /CollaborationProtocolProfile or /CollaborationProtocolAgreement. While thinking about how large these items are, should we also generalize Certificate to be either a ds:KeyInfo or a URI for retrieval? If so, what forms of URI should be allowed? Should any exotic URIs for PKIX protocols be included? Should we avoid requiring or promoting any Cert access method and just leave it as anyURI? I think it is worthwhile thinking about just what implementations would be expected to support for these URIs in terms of access (ftp, http, ldap, etc etc). Thanks, Dale (Working on 1.1 Security updates)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC