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:
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:
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).