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

[Scott Hinkelman <srh@us.ibm.com>]

We are all in agreement on this.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Duane Nickull <duane@xmlglobal.com> on 12/15/2000 04:41:51 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   Scott Hinkelman/Austin/IBM@IBMUS, christopher ferris
      <chris.ferris@east.sun.com>, Krishna Sankar <ksankar@cisco.com>,
      ebxml-tp@lists.ebxml.org, ebxml-ta-security@lists.ebxml.org
Subject:  Re: Certifcate element..RE: comments on cppml,v0.1.dtd



Marty:

Well said.  PW and UN in a CPP would never fly around here.

Duane

Martin W Sachs wrote:
>
> As I said in another reply, I agree to removing the values of the ID and
> password from the TPA.  (More than agree, I insist.) I do not agree to
> including them in the CPP.  Password values should never be stored in a
> place where anyone except the two parties to an agreement can see them.
> The value of a starting password should be exchanged out-band after the
> agreement to do business is completed.
>
> 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
>
*************************************************************************************

>
> Scott Hinkelman
> 12/15/2000 01:33 PM
>
> To:   christopher ferris <chris.ferris@east.sun.com>, Krishna Sankar
>       <ksankar@cisco.com>, ebxml-tp@lists.ebxml.org,
>       ebxml-ta-security@lists.ebxml.org, Martin W Sachs/Watson/IBM@IBMUS
> cc:
> From: Scott Hinkelman/Austin/IBM@IBMUS
> Subject:  Re: Certifcate element..RE: comments on cppml,v0.1.dtd
(Document
>       link: Martin W. Sachs)
>
> I agree with Chris to remove the id/pw from the CPA/CPP as in tpaML.  I
am
> under the impression that
> there is no current default/standard directory on the public Internet
that
> business make
> available public keys (UDDI is a potential for this). I see it more
> appropriate for this to
> be in the CPP space than CPA. Holding/referencing in the CPA is a
> thin/thick CPA question.
>
> Scott Hinkelman, Senior Software Engineer
> XML Industry Enablement
> IBM e-business Standards Strategy
> 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
> srh@us.ibm.com, Fax: 512-838-1074
>
> Martin W Sachs/Watson/IBM@IBMUS on 12/15/2000 12:14:27 PM
>
> To:   christopher ferris <chris.ferris@east.sun.com>
> cc:   Krishna Sankar <ksankar@cisco.com>, ebxml-tp@lists.ebxml.org,
>       ebxml-ta-security@lists.ebxml.org
> Subject:  Re: Certifcate element..RE: comments on cppml,v0.1.dtd
>
> Storing userid and password information in the CPA is definitely a Bad
> Idea.  It is in tpaML 1.0.6 because some people on the IBM Res team
> understood that it would be necessary for some existing B2B systems.
> However the text in tpaML 1.0.6 strongly advises against using this
option.
>
> While it may be safe to keep certificates in the CPA, it is not obvious
to
> me why we would want to do so rather than just including a pointer to the
> certificate. Keeping certificates in the CPA would require renegotiating
> the CPA if a certificate has to be replaced. (I understand that for
signing
> of the CPA, those certificates would have to be in the CPA, but that's
> another matter.)  As to the certificate identification information, we
need
> to understand just how much information is really needed in the CPA.  We
> will need explanatory text to go in the specification.
>
> Regarrds,
> 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
>
*************************************************************************************

>
> christopher ferris <chris.ferris@east.sun.com> on 12/14/2000 05:58:28 PM
>
> To:   Krishna Sankar <ksankar@cisco.com>
> 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