13.6 The X509Data Element | Secure XML: The New Syntax for Signatures and Encryption

Like all other children of KeyInfo, an X509Data element contains information to help the recipient figure out which key to use, including information to link that key to an authenticating entity. It has the richest structure, in terms of alternate and parallel allowed element content, of any KeyInfo child element specified in the XML Security standards. For its identifier, see Table 13-1.

The X509Data element consists of one or more X509 key identifiers, X509 certificates, certificate identifiers, or revocation lists. (See [ISO 9594] and Chapter 2 for a discussion of X509 certificates and related identifiers.) Implementation of X509Data is optional.

The content of X509Data must include at least one element, from the following set of element types:

The X509IssuerSerial element, which contains an X.509 issuer distinguished name/serial number pair that should comply with [RFC 2253], except for the representation of strings in names (as specified in Section 13.6.1)
The X509SubjectName element, which contains an X.509 subject distinguished name that should comply with [RFC 2253], except for the representation of strings in names (as specified in Section 13.6.1)
The X509SKI element, which contains the base-64 encoded plain (i.e., not DER-encoded) value of a X509 V.3 SubjectKeyIdentifier extension
The X509Certificate element, which contains a base-64 encoded X509 V.3 certificate
The X509CRL element, which contains a base-64 encoded certificate revocation list (CRL) [ISO 9594]
Elements from an external namespace that accompanies, complements, or replaces any of the preceding elements, including the PKCS7signedData element found in the "http://www.w3.org/2001/04/xmldsig-more" namespace

Any X509IssuerSerial, X509SKI, and X509SubjectName elements that appear must refer to the certificate or certificates containing the validation key. All such elements that refer to a particular individual certificate must be grouped inside a single X509Data element; if the certificate to which they refer appears, it must also reside in that X509Data element.

Also, any X509IssuerSerial, X509SKI, and X509SubjectName elements that relate to the same key but different certificates may occur in multiple X509Data elements. They must occur within the same KeyInfo, but this requirement is not surprising because only one KeyInfo is allowed under any SignedInfo, EncryptedData, or EncryptedKey.

All certificates appearing in an X509Data element must relate to the validation key by either containing it or being part of a certification chain that terminates in a certificate containing the validation key.

These constraints are not intended to imply any ordering between X509Data or X509Data and other elements in a KeyInfo, or ordering between X509Data child elements within an X509Data.

The following is an example of an X509Data:

 <KeyInfo>   <X509Data> <!-- two pointers to certificate-A -->     <X509IssuerSerial>       <X509IssuerName>CN=TAMURA Kent, OU=TRL,           O=IBM, L=Yamato-shi, ST=Kanagawa,           C=JP</X509IssuerName>       <X509SerialNumber>12345678</X509SerialNumber>     </X509IssuerSerial>     <X509SKI>31d97bd7</X509SKI>   </X509Data>   <X509Data><!-- single pointer to certificate-B -->     <X509SubjectName>Subject of Certificate B</X509SubjectName>   </X509Data>   <X509Data> <!-- certificate chain -->     <!--Signer cert,         issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4-->     <X509Certificate>MIICXTCCA..</X509Certificate>     <!-- Intermediate cert subject CN=arbolCA,OU=FVT,O=IBM,C=US          issuer CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->     <X509Certificate>MIICPzCCA...</X509Certificate>     <!-- Root cert,          subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->     <X509Certificate>MIICSTCCA...</X509Certificate>   </X509Data> </KeyInfo>

The XMLDSIG standard does not make any direct provision for a PKCS#7 encoded "bag" of certificates or CRLs. However, a set of certificates or CRLs can occur within an X509Data element, and multiple X509Data elements can occur in a KeyInfo. Whenever multiple certificates appear in an X509Data element, at least one such certificate must contain the public key that verifies the signature. In addition, the PKCS7signedData element is defined outside the XML Security standards in a separate, in-progress draft.

13.6.1 Distinguished Name Encoding

X509 distinguished names can appear as content of the X509IssuerName, X509SubjectName, and KeyName elements. They should be encoded as follows:

Consider the string as consisting of Unicode characters.
Escape occurrences of the following special characters by prefixing each with the "\ " character:
- A "#" character occurring at the beginning of the string
- One of the following characters: comma (","), plus sign ("+"), double quote ("""), back slash ("\ "), less than ("<"), greater than (">"), or semicolon (";")
Escape all occurrences of ASCII control characters (Unicode range 0x00 0x1F) by replacing them with "\" followed by a two-digit hexa decimal number showing its Unicode number.
Because an XML document logically consists of characters, not oc tets, the resulting Unicode string is encoded according to the character encod ing used for producing the physical representation of the XML document.

13.6.2 X509Data Syntax

The X509Data element syntax follows:

 <!-- X509Data DTD --> <!ELEMENT X509Data ( (X509IssuerSerial |                       X509SKI |                       X509SubjectName |                       X509Certificate)+ |                       X509CRL %X509.ANY;) > <!ELEMENT X509IssuerSerial (X509IssuerName,                             X509SerialNumber) > <!ELEMENT X509IssuerName (#PCDATA) > <!ELEMENT X509SerialNumber (#PCDATA) > <!ELEMENT X509SKI (#PCDATA) > <!ELEMENT X509SubjectName (#PCDATA) > <!ELEMENT X509Certificate (#PCDATA) > <!ELEMENT X509CRL (#PCDATA) > <!--Note: This DTD and schema permit X509Data to be empty;      this use is precluded by the standard stating that at      least one element from the dsig namespace should be present      in the PGP, SPKI, and X509 structures. This is easily      expressed for the other key types, but not for X509Data      because of its rich structure. -->

In schema notation, it has the following form:

 <!-- X509Data schema --> <element name="X509Data" type="ds:X509DataType"/> <complexType name="X509DataType">   <sequence maxOccurs="unbounded">     <choice>       <element name="X509IssuerSerial"                type="ds:X509IssuerSerialType"/>       <element name="X509SKI" type="base64Binary"/>       <element name="X509SubjectName" type="string"/>       <element name="X509Certificate"                type="base64Binary"/>       <element name="X509CRL" type="base64Binary"/>       <any namespace="##other" processContents="lax"/>     </choice>   </sequence> </complexType> <complexType name="X509IssuerSerialType">   <sequence>     <element name="X509IssuerName" type="string"/>     <element name="X509SerialNumber" type="integer"/>   </sequence> </complexType>

13.6.3 PKCS7signedData Element

A PKCS #7 [RFC 2315] "signedData" structure can be used as a bag of certificates, CRLs, or a mixture of the two. The PKCS7signedData element is specified to accommodate this structure within KeyInfo. The binary PKCS #7 structure is encoded in base-64 [RFC 2045]. Any signer information present is ignored. The following example elides the base-64 data:

 <dsm:PKCS7signedData  xmlns:dsm="http://www.w3.org/2001/04/xmldsig-more">     ... </dsm:PKCS7signedData>

Implementation of PKCS7signedData is optional. Its syntax follows:

 <!-- PKCS7signedData DTD --> <!ELEMENT PKCS7signedData (#PCDATA) >

In schema notation, it has the following form:

 <!-- PKCS7signedData Schema --> <element name="PKCS7signedData" type="base64Binary"/>

13.6.4 OCSP Tokens

Retrieving and examining all the CRLs for the certificates in a chain can take a lot of time and effort. To avoid this problem, some systems use an online server to obtain the status of certificates. Such servers return a secure token indicating the certificate status. It would be reasonable to use such a token as a child of X509Data in place of an X509CRL. No syntax for On-line Certificate Status Protocol (OCSP) tokens has been specified for XML Security as yet, but one is likely to be defined in connection with XKMS (see Chapter 14).