About

This page provides functional definitions of the two proposed XRD 1.0 trust elements for two purposes:

  1. Clarifying the definitional text to put in the Trust section of the spec.
  2. Deciding on the element names.

Element #1: Value of or Reference to <ds:KeyInfo> Element of Signing Authority for Linked XRD (WAS <TargetAuthority>)

Functional Definition

  1. Child element of <XRD:Link>.

  2. Same data type as <ds:KeyInfo>.

  3. Specifies the <ds:KeyInfo> of the signing authority for the XRD that is the target of an <XRD:Link> element in one of two ways:

    1. If the element contains ONLY the child element <ds:KeyName>, it specifies the required value of the <XRD:Subject> element of the XRD that is authoritative for the <ds:KeyInfo> block.

    2. If the element contains any other child element, it specifies the actual <ds:KeyInfo> block.

Trust Verification Function

This element enables the author of an XRD to delegate signing authority for a linked XRD, either by supplying the key material directly or by supplying a reference to the key material in another XRD.

Note that in order for this protection to work, XRD signature processors MUST use <ds:KeyInfo> when it is present in an XRD:Link (either by value or by reference), and MUST fail if the linked XRD signature does not verify using this <ds:KeyInfo>.

Behavior If This Element Is NOT Present in an <XRD:Link>

If not present, the signing authority for the linked XRD is unspecified, and an XRD processor must rely on its own policy for determining trust.

Proposed Element Names

The following element names have been proposed:

The Case for <ds:KeyInfo>

Writing up this functional definition makes it clear that in order for the element to have the same semantics as XML dSig, we must reuse the element name in the XML dSig namespace, i.e., <ds:KeyInfo>.

This means we do not need our own name for this element. Instead, <ds:KeyInfo> can be used at two levels within an XRD:

  1. At the XRD level, in which case it defines the key material for the authority described by the XRD.
  2. At the XRD:Link level, in which case it contains the key material (or a reference to the key material) for the authority for the linked XRD.

Element #2: Reference to <XRD:Subject> Element of Linked XRD (WAS <TargetSubject>)

Functional Definition

Trust Verification Function

This element can prevent "XRD substitution attacks", i.e., where DNS poisoning or other URI resolution attacks are employed to substitute a malicious XRD as the target of an <XRD:Link> in place of an authentic XRD.

In order for this protection to work, an XRD processor MUST perform the following verification test: if the value of the <XRD:Subject> element of the signed XRD is NOT within the authority of the XRD signer (as defined by the <ds:KeyName> child of <ds:KeyInfo>), the processor:

  1. MUST perform XRD discovery on the value of the <XRD:Subject> element.

  2. MUST verify that an <XRD:Link> element exists that delegates authority to the signed XRD. This <XRD:Link> element SHOULD contain an <XRD:Link:{element-name-here}> child element whose value matches the value of the <XRD:Subject> element in the signed XRD.

Behavior If This Element Is NOT Present in an <XRD:Link>

If this element is not present in an <XRD:Link>, the value of the <XRD:Subject> element of the linked XRD is unspecified, and an XRD processor must rely on its own policy for determining trust.

Proposed Element Names

The Case for <XRD:Link:Subject>

Reusing the Subject element at the XRD:Link layer has three advantages:

  1. It eliminates the need for a new element name altogether.
  2. It eliminates the need for an XRD trust namespace completely.
  3. It mirrors the same pattern of using <ds:KeyInfo> at both the XRD and XRD:Link levels, for the same reasons.

XrdOne/TrustElements (last edited 2009-08-12 18:07:17 by localhost)