RE: Questions/Comments for the current draft.

> -----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 Tuesday, 11 July 2000 12:04:35 UTC