4.4.4 The X509Data Element

Identifier

Type="http://www.w3.org/2000/09/xmldsig#X509Data "
(this can be used within a RetrievalMethod or Reference element to identify the referent's type)

An X509Data element within KeyInfo contains one or more identifiers of keys or X509 certificates (or certificates' identifiers or a revocation list). The content of X509Data is:

1. At least one element, from the following set of element types; any of these may appear together or more than once iff (if and only if) each instance describes or is related to the same certificate:
2. • The X509IssuerSerial element, which contains an X.509 issuer distinguished name/serial number pair. The distinguished name SHOULD be represented as a string that complies with section 3 of that SHOULD be compliant with RFC2253 [LDAP-DN],
   • The X509SubjectName element, which contains an X.509 subject distinguished name that SHOULD be represented as a string that complies with section 3 of compliant with RFC2253 [LDAP-DN],
   • The X509SKI element, which contains the base64 encoded plain (i.e. non-DER-encoded) value of a X509 V.3 SubjectKeyIdentifier extension.
   • The X509Certificate element, which contains a base64-encoded [X509v3] certificate, and
   • Elements from an external namespace which accompanies/complements any of the elements above.
   • The X509CRL element, which contains a base64-encoded certificate revocation list (CRL) [X509v3].

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 and if the certificate to which they refer appears, it MUST also be in that X509Data element.

Any X509IssuerSerial, X509SKI, and X509SubjectName elements that relate to the same key but different certificates MUST be grouped within a single KeyInfo but MAY occur in multiple X509Data elements.

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.

No ordering is implied by the above constraints. The comments in the following instance demonstrate these constraints:

   <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>

Note, there is no direct provision for a PKCS#7 encoded "bag" of certificates or CRLs. However, a set of certificates and CRLs can occur within an X509Data element and multiple X509Data elements can occur in a KeyInfo. Whenever multiple certificates occur in an X509Data element, at least one such certificate must contain the public key which verifies the signature.

Also, strings in DNamesTo encode a distinguished name (X509IssuerSerial,X509SubjectName, and KeyName if approriate), the encoding rules in section 2 of RFC 2253 [LDAP-DN] SHOULD be applied, except that the string encoding rules in section 2.4 of RFC 2253 [LDAP-DN] shouldMAY be encoded augmented as follows:

• Consider the string as consisting of Unicode characters.
• Escape occurrences of the following special characters by prefixing it with the "\" character:
  • a "#" character occurring at the beginning of the string
  • one of the characters ",", "+", """, "\", "<", ">" or ";"
• Escape all occurrences of ASCII control characters (Unicode range \x00 - \x1f) by replacing them with "\" followed by a two digit hex number showing its Unicode number.
• Escape any a trailing white space character (Unicode \x20) by replacing "\ " with "\20", instead of using the escape sequence "\ ".
• Since a XML document logically consists of characters, not octets, the resulting Unicode string is finally encoded according to the character encoding used for producing the physical representation of the XML document. implying that character references could be intruduced. Due to immediate expansion these are transparent in a canonicalized XML content or on an application layer. Note that implementations MAY just as well rely on escaping such characters as allowed in section 2.4 of RFC 2253 [LDAP-DN].
  
  @@@Konrad to Thomas: if DNAMES are usewd in content that is not canonicalized before signed, this is useful and also implementations may also decide to escape all characters beyond ASCII @@@
  @@@Konrad to Thomas: Some word smithing from your side may be required here. @@@
  @@@Question to all: Is it possible that characters are introduced via immediate expansion that cannot be represented in UTF-8 and if so would these be . @@@

   Schema Definition

   <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>

   DTD

   <!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName |
                        X509Certificate | X509CRL)+ %X509.ANY;)>
   <!ELEMENT X509IssuerSerial (X509IssuerName, X509SerialNumber) >
   <!ELEMENT X509IssuerName (#PCDATA) >
   <!ELEMENT X509SubjectName (#PCDATA) >
   <!ELEMENT X509SerialNumber (#PCDATA) >
   <!ELEMENT X509SKI (#PCDATA) >
   <!ELEMENT X509Certificate (#PCDATA) >
   <!ELEMENT X509CRL (#PCDATA) >

   <!-- Note, this DTD and schema permit X509Data to be empty; this is 
   precluded by the text in KeyInfo Element (section 4.4) which states 
   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. -->