Re: ACTION-502: Propose new model for RetrievalMethod in 2.0

+1 to different element name

to be sure I understand this, a KeyInfoReference with URI #foo could  
refer to a ds:KeyInfo element in the same document with ID="foo" and  
if containing a child X509Data, for example,  the application would  
need to know to parse the content of the KeyInfo element and process  
it appropriately....

regards, Frederick

Frederick Hirsch
Nokia



On Feb 2, 2010, at 2:30 PM, ext Scott Cantor wrote:

> Prateek went ahead and copied in the original 1.1 text for this into  
> the 2.0
> draft:
>
> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/Overview.src.html#sec-R
> etrievalMethod
>
> In addition to the known issue around IDs, there's also the fact  
> that the
> existing definition depends on the full Reference Processing model,  
> so not
> just Transforms but also the special syntax for xpointers.
>
> I think the right thing to do is deprecate RetrievalMethod and  
> replace it
> with a new ds2:RetrievalMethod, or perhaps to avoid confusion we could
> rename it? Maybe ds:KeyInfoReference or ds:KeyInfoRef?
>
> Anyway, the idea would be to emulate the intended function of the old
> element but with a processing model that lives within the  
> limitations of the
> schema. A strawman is below. The suggestion there is to limit the  
> possible
> URI space to absolute URIs or "#foo" references, and point at the  
> parent
> KeyInfo rather than the actual child element you want. The prose  
> makes it a
> requirement for the referenced KeyInfo to actually include at least  
> one
> instance of the appropriate child. If there's more than one, it  
> shouldn't
> matter, since KeyInfo requires that all of its children be talking  
> about the
> same key.
>
> If we wanted to be simpler and skip the ability to identify the  
> actual child
> type, we could probably have only the options of "a KeyInfo element"  
> or
> "rawX509Certificate". Or we can drop the "raw" option, leave that for
> RetrievalMethod to handle, and get rid of Type altogether.
>
> -- Scott
>
> The KeyInfoReference Element
>
> A KeyInfoReference element within KeyInfo is used to convey a  
> reference to
> KeyInfo information that is stored at another location. For example,  
> several
> signatures in a document might use a key verified by an X.509v3  
> certificate
> chain appearing once in the document or remotely outside the  
> document; each
> signature's KeyInfo can reference this chain using a single  
> KeyInfoReference
> element instead of including the entire chain with a sequence of
> X509Certificate elements.
>
> KeyInfoReference uses the same syntax and dereferencing behavior as
> Reference's URI in "Compatibility Mode" (section 6.4.3.2) and the
> "Compatibility Mode" Reference Processing Model (section 6.4.3.3)  
> except
> that there are no child elements, the presence of the URI attribute is
> mandatory, and URI values MUST be either an absolute URI or a same- 
> document
> reference consisting of a hash sign ('#') followed by a fragment.  
> Neither an
> empty URI nor the "shortname XPointer" syntax are permitted.
>
> Type is an optional identifier for the type of data referenced. The  
> result
> of dereferencing a KeyInfoReference for all KeyInfo types defined by  
> this
> specification with a corresponding XML structure is a KeyInfo  
> element or a
> document with a KeyInfo element as the root. The element MUST  
> contain at
> least one child element of the corresponding type (possibly  
> contained within
> additional substructure as the relevant syntax dictates). The
> rawX509Certificate Type (for which there is no XML structure)  
> indicates a
> binary X509 certificate.
>
> Schema Definition
>
>  <element name="KeyInfoReference" type="ds2:KeyInfoReferenceType"/>
>  <complexType name="KeyInfoReferenceType">
>    <attribute name="URI" type="anyURI" use="required"/>
>    <attribute name="Type" type="anyURI"/>
>  </complexType>
>
>
>
>

Received on Monday, 8 February 2010 22:59:44 UTC