RE: comments on cppml,v0.1.dtd

[Krishna Sankar <ksankar@cisco.com>]

Chris et al,

	Let me take you up on this issue as a representative of the security team.
But I am not yet ready to suggest any ideas ;-) I am doing some
research/reading/thinking on this. We need a simple and elegant way but
still leveraging the standards ! Tall order ;-0

	cheers

-----Original Message-----
From: Chris.Ferris@east.sun.com [mailto:Chris.Ferris@east.sun.com]
Sent: Tuesday, December 12, 2000 12:52 PM
To: ebxml-tp@lists.ebxml.org
Cc: ebxml-ta-security@lists.ebxml.org
Subject: Re: comments on cppml,v0.1.dtd


Scott,

I fully agree with your assessment;-) Anyone on the
security team have an opinion on this?

Chris

Scott Hinkelman wrote:
>
> One thing to consider is that if we continue to "just point to a URL" for
> the cert
> that puts the onus on all of the URL owners to provide the structure when
> obtaining it,
> and authorization mechanisms with error messages etc. Yes it can all be
> there at a URL,
> but I think it is beneficial to think to accommodate a common structure
for
> this.
>
> Spec:
> "KeyInfo may contain keys, names, certificates and other public key
> management information, such as in-band
> key distribution or key agreement data."
>
> Seems the CPP would be a good place to advertise a public key data, and
> beyond that
> it seems the issue is mostly on process as to what should appear where
> when; Something
> important but secondary to having a consistent structure. The structure
> does seem flexible
> enough to use in CPP and CPA. regardless of what appears when.
>
> 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/12/2000 02:00:32 PM
>
> To:   Christopher Ferris <chris.ferris@east.sun.com>
> cc:   "ebxml-tp@lists.ebxml.org" <ebxml-tp@lists.ebxml.org>,
>       "ebxml-ta-security@lists.ebxml.org"
>       <ebxml-ta-security@lists.ebxml.org>
> Subject:  Re: comments on cppml,v0.1.dtd
>
> Is the amount of detail in the certificate proposal below actually needed
> in the CPA or CPP?  The 0.0 draft merely contains the URL of the
> certificate.  Could the information shown below be obtained by actually
> going to the certificate via the URL?  Is the intent that the actual
> certificate not be seen by another party before there is an agreement or
> note be seen at all?
>
> 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
>
****************************************************************************
*********
>
> Christopher Ferris <chris.ferris@east.sun.com>@east.sun.com on 12/12/2000
> 12:53:19 PM
>
> Sent by:  Chris.Ferris@east.sun.com
>
> To:   "ebxml-tp@lists.ebxml.org" <ebxml-tp@lists.ebxml.org>,
>       "ebxml-ta-security@lists.ebxml.org"
>       <ebxml-ta-security@lists.ebxml.org>
> cc:
> Subject:  comments on cppml,v0.1.dtd
>
> All,
>
> I would like to hear some opinions on the following comment
> I have regarding the initial draft DTD for our CPP/CPA.
>
> The original tpaML,v1.0.6 offered a Certificate
> element which was composed of (basically) the same
> elements as have been defined thus far for our CPP.
> I only reorganized things such that a set of Certificates
> could be organized/collected within a Party element (formerly
> Participants/Member).
>
> The issue/comment that I have is that the certificate
> contains no means which I can determine to actually
> identify the certificate itself. Would we be better
> served to leverage the work of the (now CR) XMLDSig WG
> and use the KeyInfo element they have defined?
>
> http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/#sec-KeyInfo
>
> e.g.
> <KeyInfo>
>   <X509Data> <!-- two pointers to certificate-A -->
>     <X509IssuerSerial>
>       <X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM,
>                   L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
>       <X509SerialNumber>12345678</X509SerialNumber>
>     </X509IssuerSerial>
>     <X509SKI>31d97bd7</X509SKI>
>   </X509Data>
>   <X509Data> <!-- single pointer to certificate-B -->
>       <X509SubjectName>Subject of Certificate B</X509SubjectName>
>   </X509Data>
>   <X509Data><!-- certificate chain -->
>               <!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial
> 4-->
>     <X509Certificate>MIICXTCCA..</X509Certificate>
>     <!-- Intermediate cert subject CN=arbolCA,OU=FVTO=IBM,C=US
>                    issuer,CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
>     <X509Certificate>MIICPzCCA...</X509Certificate>
>     <!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
>     <X509Certificate>MIICSTCCA...</X509Certificate>
>   </X509Data>
> </KeyInfo>
>
> It would seem to me that this would be a logical choice
> for us as it would (potentially) ease implementation
> use of this particular feature, especially once XMLDSig becomes
> more commonly used.
>
> I see no real benefit at this stage for ebXML to define
> its own XML vocabulary for describing a certificate.
>
> Comments?
>
> Thanks!
>
> Chris