Re: comments on cppml,v0.1.dtd

[Christopher Ferris <chris.ferris@east.sun.com>]

Marty,

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:

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

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

or:

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

or:

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

or:

<KeyInfo id="ID">
  <KeyValue>
	<RSAKeyValue>publickeyvaluebase64encoded</RSAKeyValue>
  </KeyValue>
</KeyInfo>

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.

Cheers,

Chris
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
begin:vcard 
n:Ferris;Christopher
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard