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

[Krishna Sankar <ksankar@cisco.com>]

ZA,

	You are right. It is better to include the cert chain for the DSig. And
hopefully this is part of the ebXML security recommendation.

	But the deeper question is, should we keep the cert chain as a part of the
CPP ? (I have been agonizing on this for the last couple of days).

Chris,

	Thanks for the reply. It made me think more and possibly reverse my earlier
position !

	May be it is a good idea to keep the cert chain in the CPP - makes it
easier for SMEs ! No need for a PKI et al. On one of the systems I had
developed, we did keep the certs in a pseudo registry and used it for
authentication et al.

	But we need to make some provision for expired certs (including expired
certs somewhere in the chain); may be say "Handle expired certs thru
out-of-band schemes". We also need to handle CRLs, especially because the
CPPs are long lived documents. I assume we could invalidate a CPP if and
when we encounter a revoked or expired certificate. At the implementation
level, the registry also could run some daemons to check the validity of the
certs.

	If we go this route (i.e. store certs as a part of CPP), it would
definitely help the regrep, as we can then require a CPP with certificates
*before* content submission. Then hopefully processing authentication and
authorization is much easier - will have to think this thru.

	And if we do store certs, we might as well use the way DSig does it so that
there is some leverage by using existing standards.

	Of course, any username/PW schemes would need to be done out-of-band, as
this information is too sensitive to store with the CPP. Another point in
this regard, is the existence of URLs (login/Request/Response) in a public
document, making them susceptible to denial of service et al.

	Does the above picture change if we use PGP ?

	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
> >
>