ebxml-tp message

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


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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


The detail is actually far less than the example
might imply simply because the example is intended
to demonstrate multiple ways that a certificate can
be expressed according to the XMLSignature spec. In fact,
I snarfed the example cited right from the spec;-)

The certificate can be expressed as a URI using
the RetrievalMethod form of KeyInfo:

   <RetrievalMethod URI="http://example.com/mycertificate.jsp"/>

The certificate can also be expressed as simply as any of
the following:
<KeyInfo id="ID">


<KeyInfo id="ID">
      <X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM,
                  L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>


<KeyInfo id="ID">
      <X509SubjectName>Subject of Certificate B</X509SubjectName>


<KeyInfo id="ID">

Basically, the KeyInfo can be used in any number of ways
to express a certificate either by value or reference.

My intent here was to leverage something which is close
to a standard and leave it to implementations as to how best
to handle it. We could make a recommendation as to which 
form we prefer (e.g. RetrievalMethod or possibly KeyValue).

I would hope that the security team would suggest specific
recommendations in that vein.

As to whether or not a certificate might be "seen" by
a prospective partner before an agreement is reached, I see
no harm whatsoever in that. I'll defer final judgement on
that to the full security team.


Martin W Sachs wrote:
> 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
org:Sun Microsystems, Inc;XTC Advanced Development
title:Sr. Staff Engineer
fn:Christopher Ferris

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC