W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

Re: XMLDSIG Interop in connection with 48th IETF

From: merlin <merlin@baltimore.ie>
Date: Wed, 19 Jul 2000 19:44:01 +0100
Message-Id: <200007191844.TAA08771@bobcat.baltimore.ie>
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>


>Making some of this stuff optional seems reasonable but I would think
>that a lot of implementations would just pass off the uri to some
>retrieval mechanism without looking inside it and still want a
>separate indication of type and encoding.


I agree. I just don't grasp the reason for the current
structure of the element.

It seems to me that a minimal specification would be [1]:

  <RetrievalMethod Location="http://..."
   Type="foo#x509-certificate" Encoding="bar#base64" />

A more pedantic specification would be [2]:

  <RetrievalMethod Type="foo#x509-certificate>
    <Encoding Algorithm="bar#base64" />

Type could be expanded into an element, if desired.

However, I can't see how Type would be more than a URI,
nor do I see the impact of Encoding on Type, as captured
in the current spec:

    <Method><x:From-ASN1-To-Key-Info-Foo /></Method>
    <Type Encoding="bar#base64"><x:Its-A-X509-Certificate-Foo /></Type>

As I say, I just don't fully understand what would be a default
implementation of the current element specification.



<element name='RetrievalMethod'>
  <complexType content='mixed'>
    <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
  <attribute name='Location' type='uriReference' use='required'>
  <attribute name='Type' type='uriReference' use='optional'/>
  <attribute name='Encoding' type='uriReference' use='optional'>


<element name='RetrievalMethod'>
  <complexType content='elementOnly'>
    <sequence minOccurs='1' maxOccurs='1'>
      <element name='Location' type='uriReference' minOccurs='1' maxOccurs='1'/>
      <element ref='ds:Encoding' minOccurs='0' maxOccurs='unbounded'/>
    <attribute name='Type' type='uriReference' use='optional'/> 

<element name='Encoding'>
  <complexType content='mixed'>
    <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
    <attribute name='Algorithm' type='uriReference' use='required'/>

>From:  merlin <merlin@baltimore.ie>
>Message-Id:  <200007182220.XAA10671@bobcat.baltimore.ie>
>To:  "Joseph M. Reagle Jr." <reagle@w3.org>
>Cc:  "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
>In-reply-to:  <> 
>Date:  Tue, 18 Jul 2000 23:20:57 +0100
>>>At 19:30 7/18/00 +0100, Merlin Hughes wrote:
>>> >The Schema has mandatory content for the Type element. This
>>> >seems wrong because it can't then be implemented interoperably
>>> >without further specification.
>>>Are you suggestion it be change to optional?
>>>   <element name='Type'>
>>>     <complexType content='mixed'>
>>>       <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
>>>        ...
>>Something of that nature. RetrievalMethod simply seems
>>underspecified given that it "SHOULD" be implemented.
>>By making some of those parts optional, it could be
>>read as minimally and sufficiently specified.
>>For example, it seems reasonable to present a RetrievalMethod
>>with the Location:
>>  ldap://ldap.baltimore.ie/CN=merlin?userCertificate;binary
>>What, in this case, do I specify as the Method and Type,
>>both of which are currently mandatory?
>>By making Method and Type optional I can, at the very least,
>>assume that the recipient will determine the type of key
>>information from the URI.
Received on Wednesday, 19 July 2000 14:44:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:34 UTC