Re: Certifcate element..RE: comments on cppml,v0.1.dtd

[christopher ferris <chris.ferris@east.sun.com>]

Krishna,

Good points.

Krishna Sankar wrote:
<snip/>
> 
>         Does the above picture change if we use PGP ?

I don't believe so. XMLDSig supports PGP. Keep in mind that
the choice of use of KeyInfo from XMLDSIG is merely for
some means to identify (or store) certificate info.

I believe that S/MIME and PGP/MIME could still leverage 
this info from the CPP/CPA.

Cheers,

Chris

> 
>         cheers
> 
> > -----Original Message-----
> > From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com]
> > Sent: Thursday, December 14, 2000 3:33 PM
> > To: christopher ferris; Krishna Sankar
> > Cc: ebxml-tp@lists.ebxml.org; ebxml-ta-security@lists.ebxml.org
> > Subject: RE: Certifcate element..RE: comments on cppml,v0.1.dtd
> >
> >
> > Generally, I like the idea of inclusion of certificate
> > data using XMLDSig KeyInfo, particualrly for signing
> > XML documents. For signing the whole ebXML message
> > envlope, it is better to use the PKCS7 format for S/MIME.
> >
> > However, is it possible to support both approaches:
> >       - the XML DSIg retrieval mechanism;
> >       - physical inclusion of cert chain
> >
> > I'm concerned about accessing certs from remotes
> > site (during a ebXML transaction/message validation)
> > since links can go stale or become outdated . Hence,
> > invariably, if given the option, I would end up
> > incluiding the cert chain in a message. This is pretty
> > much like S/MIME. The value of pointer-based access
> > to certs is good for trusted roots, CRLs, etc.
> >
> > ----Zahid
> >
> >
> >
> > > -----Original Message-----
> > > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > > Sent: Thursday, December 14, 2000 2:58 PM
> > > To: Krishna Sankar
> > > Cc: ebxml-tp@lists.ebxml.org; ebxml-ta-security@lists.ebxml.org
> > > Subject: Re: Certifcate element..RE: comments on cppml,v0.1.dtd
> > >
> > >
> > > Krishna,
> > >
> > > I am not interested in cert management either, but
> > > there seems to me to be a need to enable negotiated
> > > (possibly dynamic) CPP->CPA that the identification
> > > (if nothing else) of the certificates to be used
> > > is required in the CPP and that for a CPA, that
> > > the certificates will at the very least need to be
> > > identified if not "in-band" in the CPA.
> > >
> > > This *does* raise an interesting point with which
> > > I have been struggling. Storage of the user/password
> > > information in a (possibly) public document such as
> > > the CPA is probably a bad idea;-) tpaML1.0.6 had
> > > a means of storing this information in the
> > > TPA, but I'm thinking that it should be removed.
> > >
> > > The same problem does not exist for certificates
> > > because they don't expose the private bits, just
> > > the public key needed to either encrypt or verify
> > > a signature.
> > >
> > > So, we *could* follow Krishna's suggestion and omit
> > > the actual certs from the CPP/CPA, but I'd like
> > > to have others on the ta-security list comment on
> > > removal of the cert identification info, which I actually
> > > feel would be quite useful.
> > >
> > > Comments??
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > > Krishna Sankar wrote:
> > > >
> > > > Chris/Dale,
> > > >
> > > > > > > > We are in effect inventing yet another means
> > > > > > > > of certificate distribution by obtaining
> > > > > > > > certs from a CPA to store in a cert/crl cache.
> > > > > > > >
> > > >
> > > >         This is what I am worried about - reinventing
> > > another PKI ! Do we really
> > > > need the certinfo in the CPP ? For the first version can we say
> > > > "out-of-band" certificate management and then take up this
> > > issue during next
> > > > phase ? Also how are SMEs going to manage this ?
> > > >
> > > > cheers
> > >
> >
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard