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

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

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