W3C home > Mailing lists > Public > public-xmlsec@w3.org > February 2010

ACTION-502: Propose new model for RetrievalMethod in 2.0

From: Scott Cantor <cantor.2@osu.edu>
Date: Tue, 2 Feb 2010 14:30:57 -0500
To: "'XMLSec WG Public List'" <public-xmlsec@w3.org>
Message-ID: <026201caa43e$3e70ade0$bb5209a0$@2@osu.edu>
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 Tuesday, 2 February 2010 19:31:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 February 2010 19:31:31 GMT