OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-tp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: comments on cppml,v0.1.dtd

Chris, seems like a good idea. I agree that ebXML should not define its own
cert structure.
KeyInfo contains the KeyValue, so I don't see why not use it, but would
like to hear from
the Security team.

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

Christopher Ferris <chris.ferris@east.sun.com>@east.sun.com on 12/12/2000
11:53:19 AM

Sent by:  Chris.Ferris@east.sun.com

To:   "ebxml-tp@lists.ebxml.org" <ebxml-tp@lists.ebxml.org>,
Subject:  comments on cppml,v0.1.dtd


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

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?


  <X509Data> <!-- two pointers to certificate-A -->
      <X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM,
                  L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
  <X509Data> <!-- single pointer to certificate-B -->
      <X509SubjectName>Subject of Certificate B</X509SubjectName>
  <X509Data><!-- certificate chain -->
              <!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial
    <!-- Intermediate cert subject CN=arbolCA,OU=FVTO=IBM,C=US
                   issuer,CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
    <!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->

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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC