OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[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