RE: Questions/Comments for the current draft.

Yes, you're right.
My correct suggestion is 

<element name='X509Data'>
 <complexType content='elementOnly'>
  <sequence minOccurs='1' maxOccurs='1'>
   <choice minOccurs='1' maxOccurs='1'>
    <sequence minOccurs='1' maxOccurs='1'>
     <element ref='ds:X509IssuerSerial'
                                 minOccurs='0' maxOccurs='1'/>
     <element name='X509SKI' type='CryptoBinary'/
                                 minOccurs='0' maxOccurs='1'/>
     <element name='X509SubjectName' type='string'/
                                 minOccurs='0' maxOccurs='1'/>
    </sequence>
   <element name='X509Certificate' type='ds:CryptoBinary'
                                 minOccurs='1' maxOccurs='1'/>
   </choice>
  <element name='X509CRL' type='ds:CryptoBinary' minOccurs='0'
                                                            ^
                                 maxOccurs='1'/>
  </sequence>
 </complexType>
</element>

-- Yoshiaki Kawatsura Hitachi, Ltd.

>>>>> Tue, 11 Jul 2000 09:03:42 -0700,
	Brian LaMacchia <bal@microsoft.com> said:

> 
> > -----Original Message-----
> > From: Yoshiaki KAWATSURA [mailto:kawatura@bisd.hitachi.co.jp]
> > Sent: Monday, June 26, 2000 2:20 AM
> > To: w3c-ietf-xmldsig@w3.org
> > Cc: kawatura@bisd.hitachi.co.jp
> > Subject: Questions/Comments for the current draft.
> > 
> > Hello,
> > I have some questions/comments for the current draft.
> > 
> > (2-2) The structure of X509Data element
> > I think that the combination of X509IssuerSerial,X509SKI and/or 
> > X509SubjectName should be used as the identifier for the certificate
> > if it has been already stored in the verifier's local storage.
> 
> Individual applications are free to store and locate certificates however
> they choose, so I don't see a reason for the standard to mandate any
> particular means of indexing/identifying particular certificates that
> already exist in local storage.  (As a concrete example, the
> CertFindCertificateInStore routine within MS CryptoAPI provides no fewer
> than 21 different types of search criteria for filtering a collection of
> certificates...) Additionally, I can certainly envision scenarios in which
> peering applications would use some private shorthand for refering to
> particular certificates (say some sort of internal index/reference) that is
> completely independent of the content of the stored certificate.  
> 
> > Additionally, X509CRL may be separated or may be included with
> > certificate (or certificate identifiers) in X509Data if multiple
> > certificates is allowed by using multiple X509Data because X509CRL is
> > independent. Therefore I suggest the following structure of X509Data:
> > 
> > <element name='X509Data'>
> >  <complexType content='elementOnly'>
> >   <sequence minOccurs='1' maxOccurs='1'>
> >    <choice minOccurs='1' maxOccurs='1'>
> >     <sequence minOccurs='1' maxOccurs='1'>
> >      <element ref='ds:X509IssuerSerial'
> >                                  minOccurs='0' maxOccurs='1'/>
> >      <element name='X509SKI' type='CryptoBinary'/
> >                                  minOccurs='0' maxOccurs='1'/>
> >      <element name='X509SubjectName' type='string'/
> >                                  minOccurs='0' maxOccurs='1'/>
> >     </sequence>
> >    <element name='X509Certificate' type='ds:CryptoBinary'
> >                                  minOccurs='1' maxOccurs='1'/>
> >    </choice>
> >   <element name='X509CRL' type='ds:CryptoBinary' minOccurs='1'
> >                                  maxOccurs='1'/>
> >   </sequence>
> >  </complexType>
> > </element>
> 
> I'm not sure I understand your complaint about the way X509CRL is currently
> handled within X509Data.  Currently, each X509CRL must appear within its own
> X509Data element (but, of course, there can be multiple X509Data elements
> within a single KeyInfo).  The schema you proposed above would REQUIRE an
> X509CRL element to be present in every X509Data element (it is in the outer
> sequence and must occur exactly once since minOccurs=1, maxOccurs=1).  Did
> you really intend this?  Perhaps you intended for X509CRL to be optionally
> included in each element, with minOccurs=0 and maxOccurs=1.
> 
> Can you explain why you feel the current X509Data syntax is insufficient in
> its handling of X509CRL?  Thanks,
> 
> 					--bal 
>  
> > Thanks,
> > ----
> > Yoshiaki Kawatsura : E-mail kawatura@bisd.hitachi.co.jp
> >  Business Solution Systems Development Division, Hitachi,Ltd.
> > Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721
> > 
> > 
> > 
> > 
> > 
> 
>

Received on Wednesday, 12 July 2000 05:00:04 UTC