X509Data
Element Type="http://www.w3.org/2000/09/xmldsig#X509Data
"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:
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 X509SubjectName
element, which contains an X.509
subject distinguished name that SHOULD be represented as a
string that complies with section 3 of X509SKI
element, which contains the base64 encoded
plain (i.e. non-DER-encoded) value of a X509 V.3 SubjectKeyIdentifier
extension. X509Certificate
element, which contains a
base64-encoded [X509v3] certificate, and
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:
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 permitX509Data
to be empty; this is precluded by the text inKeyInfo
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. -->