identity 1.0 documentation

SAML V2.0 Holder-of-Key Assertion Profile Version 1.0

«  Shibboleth   ::   Contents   ::   SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0  »

SAML V2.0 Holder-of-Key Assertion Profile Version 1.0

Committee Specification 02 23 January 2010

1 Introduction

The SAML V2.0 Holder-of-Key Assertion Profile describes the issuing and processing of a holder-of-key SAML assertion, that is, an assertion containing a <saml:SubjectConfirmation> element whose Method attribute is set to urn:oasis:names:tc:SAML:2.0:cm:holder-of-key.

Specifically, we describe the structural characteristics of a <ds:KeyInfo> element with bound X.509 data and show how a relying party confirms that such a <ds:KeyInfo> element matches given X.509 data. The binding material used by the SAML issuer and the matching data used by the relying party are obtained from an X.509 certificate.

This profile involves a SAML issuer and a SAML relying party, each with an X.509 certificate in its possession. The SAML issuer uses its certificate to produce a holder-of-key SAML assertion. The relying party consumes the assertion, confirming the attesting entity by comparing the X.509 data in the assertion with the X.509 data in its possession.

1.1 Notation

This specification uses normative text. The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this specification are to be interpreted as described in [RFC2119]:

…they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)…

These keywords are thus capitalized when used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.

Listings of XML schemas appear like this.
Example code listings appear like this.

Conventional XML namespace prefixes are used throughout the listings in this specification to stand for their respective namespaces as follows, whether or not a namespace declaration is present in the example:

Prefix XML Namespace Comments
saml: urn:oasis:names:tc:SAML:2.0:assertion This is the SAML V2.0 assertion namespace defined in the SAML V2.0 core specification [SAML2Core].
ds: http://www.w3.org/2000/09/xmldsig# This is the XML Signature namespace [XMLSig].
xs: http://www.w3.org/2001/XMLSchema This is the XML Schema namespace [Schema1].
xsi: http://www.w3.org/2001/XMLSchema-instance This is the XML Schema namespace for schema-related markup that appears in XML instances [Schema1].

1.2 Terminology

In this specification, a SAML issuer is a producer of holder-of-key assertions. Similarly, a relying party is a consumer of holder-of-key assertions.

A presenter transmits a holder-of-key assertion to the relying party. An attesting entity is a presenter who is able to satisfy the subject confirmation requirements of the holder-of-key assertion.

Usually the attesting entity is the subject of the assertion (hence the terms “subject confirmation” and “confirming the subject”). In general, however, the attesting entity may not be the subject, in which case the previous phrases are misnomers. Thus the terms “attestation” and “confirming the attesting entity” are more technically correct than “subject confirmation” and “confirming the subject,” respectively. We will use the term “attesting entity” exclusively in this document.

SAML issuer
a producer of holder-of-key assertions.
relying party
a consumer of holder-of-key assertions.
presenter
A presenter transmits a holder-of-key assertion to the relying party.
attesting entity

a presenter who is able to satisfy the subject confirmation requirements of the holder-of-key assertion.

Usually the attesting entity is the subject of the assertion (hence the terms “subject confirmation” and “confirming the subject”).

In general, however, the attesting entity may not be the subject, in which case the previous phrases are misnomers.

Thus the terms “attestation” and “confirming the attesting entity” are more technically correct than “subject confirmation” and “confirming the subject,” respectively.

1.3 Normative References

RFC2119
  1. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt
RFC4514
  1. Zeilenga. Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names. IETF RFC 4514, June 2006. http://www.ietf.org/rfc/rfc4514.txt
RFC5280
  1. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF RFC 5280, May 2008. http://www.ietf.org/rfc/rfc5280.txt
SAML2Core
OASIS Standard, Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. March 2005. http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
SAML2Prof
OASIS Standard, Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0. March 2005. http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
Schema1
    1. Thompson et al. XML Schema Part 1: Structures. World Wide Web Consortium Recommendation, May 2001. See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
XMLSig
  1. Eastlake, J. Reagle, D. Solo, F. Hirsch, T. Roessler. XML Signature Syntax and Processing (Second Edition). World Wide Web Consortium Recommendation, 10 June 2008. http://www.w3.org/TR/xmldsig-core/

1.4 Non-normative References

RFC3820
  1. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile. IETF RFC 3820, June 2004. http://www.ietf.org/rfc/rfc3820.txt
RFC4346
  1. Dierks, E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.1. IETF RFC 4346, April 2006. http://www.ietf.org/rfc/rfc4346.txt
SAML2ConDel
  1. Cantor. SAML V2.0 Condition for Delegation Restriction. OASIS SSTC Committee Draft 01, 10 March 2009. http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-delegation-cd-01.pdf

2 SAML V2.0 Holder-of-Key Assertion Profile

2.1 Required Information

Identification:
urn:oasis:names:tc:SAML:2.0:profiles:holder-of-key
Contact information:
security-services-comment@lists.oasis-open.org
SAML Confirmation Method Identifiers:
The SAML V2.0 holder-of-key confirmation method identifier (urn:oasis:names:tc:SAML:2.0:cm:holder-of-key) is associated with every <saml:SubjectConfirmation> element issued under this profile.
Description:
Given below.
Updates:
Supplements the holder-of-key confirmation method described in section 3.1 of [SAML2Prof].

2.2 Profile Description

holder-of-key assertion

A SAML assertion which contains <saml:SubjectConfirmation> XML element, where

<saml:SubjectConfirmation
    'Method'='urn:oasis:names:tc:SAML:2.0:cm:holder-of-key'
>
holder-of-key SAML assertion
holder-of-key assertion

This specification profiles a type of assertion called a holder-of-key assertion. By definition, a holder-of-key SAML assertion contains a <saml:SubjectConfirmation> element whose Method attribute is set to urn:oasis:names:tc:SAML:2.0:cm:holder-of-key.

This specification describes how the SAML issuer binds selected X.509 data from an X.509 certificate to the <saml:SubjectConfirmation> element of a holder-of-key assertion. The complementary process involves a relying party who confirms that the X.509 data bound to the assertion matches the data in a given X.509 certificate.

Suppose a SAML response issued by a SAML issuer contains one or more holder-of-key assertions (otherwise this specification is not applicable).

At the time the assertion is issued, the issuer possesses an X.509 certificate known to be associated with the attesting entity (who may or may not be present when the assertion is issued). The SAML issuer binds some (or all) of the X.509 data in the certificate to the holder-of-key assertion.

Subsequently, the attesting entity presents the holder-of-key assertion and an X.509 certificate to the relying party. The attesting entity proves possession of the private key corresponding to the public key bound to the certificate, the details of which are out of scope with respect to this profile. The relying party compares the X.509 data in the certificate to the X.509 data bound to the assertion, thereby confirming the attesting entity.

Precisely how the issuer comes to possess a certificate known to be associated with attesting entity and how the assertion and the certificate are presented to the relying party are all out of scope with respect to this profile.

On the other hand, the issuing of the holder-of-key assertion itself and the ultimate confirmation of the attesting entity are in scope.

We assume that the relying party trusts the SAML issuer to issue holder-of-key assertions. The SAML issuer, on the other hand, may not even know the intended relying party, so there is no underlying assumption that the SAML issuer trusts the relying party.

2.3 X.509 Certificate Usage

There are no explicit requirements with respect to the X.509 certificate (s) possessed by the SAML issuer and the relying party. If, however, a certificate contains a Subject Key Identifier (SKI) extension, then the certificate MUST be an X.509 v3 certificate [RFC5280]. Other than that, the specific characteristics of these certificates are wholly out of scope with respect to this specification.

In particular, there is no expectation that either the SAML issuer or the relying party trusts the issuer of the certificate, and therefore all portions of the certificate, apart from the X.509 data specified in the following sections, are unspecified.

The only exception to the above rule is the case where the <ds:X509Data> element specified in section 2.4.1 contains a <ds:X509SubjectName> element or a <ds:X509SerialIssuer> element.

In these two cases, the relying party MUST trust the X.509 issuer in order to confirm the attesting entity. This is discussed more fully in section 2.5 below.

2.4 Issuing Holder-of-Key Assertions

Every assertion containing a holder-of-key <saml:SubjectConfirmation> element MUST conform to [SAML2Core] (see section 2.4.1 of Core, especially section 2.4.1.3) and section 3.1 of [SAML2Prof].

Where this specification conflicts with the SAML V2.0 specification, the former takes precedence. Suppose a SAML issuer wishes to issue a response containing one or more holder-of-key assertions. As a prerequisite, the SAML issuer MUST possess an X.509 certificate known to be associated with the attesting entity.

The SAML issuer binds some or all of the X.509 data in the certificate to the <saml:SubjectConfirmation> element of a SAML assertion.

Briefly, the SAML issuer binds a <ds:KeyInfo> element to the <saml:SubjectConfirmationData> element of a holder-of-key assertion. The <ds:KeyInfo> element contains one or more of the following elements: <ds:X509Certificate>, <ds:X509SKI>, <ds:X509SubjectName>, or <ds:X509IssuerSerial>.

A <ds:X509Certificate> element contains a base64 encoding of the certificate possessed by the SAML issuer

Note

SAML issuer ? Atesting entity’s certificate.....

A <ds:X509SKI> element contains the base64 encoding of the Subject Key Identifier (SKI) extension (if there is one) bound to the certificate.

A <ds:X509SubjectName> element contains the subject distinguished name (DN) bound to the certificate.

A <ds:X509IssuerSerial> element contains the issuer DN and the issuer serial number bound to the certificate.

In each case, the content of the <ds:KeyInfo> element conforms to the XML Signature specification [XMLSig]. These requirements are spelled out more clearly in the next section.

If the SAML issuer has reason to believe that the relying party trusts the certificate issuer, the SAML issuer MAY include NotBefore or NotOnOrAfter XML attributes on the <saml:SubjectConfirmationData> element. If so, the values bound to the assertion MUST be consistent with the values in the certificate. In particular, the value of the NotBefore attribute (resp., the NotOnOrAfter attribute) MUST be greater than or equal to (resp., less than or equal to) the NotBefore field (resp., the NotOnOrAfter field) of the certificate.

The <saml:SubjectConfirmation> element MAY contain a <saml:NameID> element. If it does, the latter identifies an attesting entity different from the subject of the assertion. If the <saml:SubjectConfirmation> element does not contain a <saml:NameID> element, then the attesting entity and the subject are one and the same.

If the <saml:SubjectConfirmation> element contains a <saml:NameID> element, the attesting entity is presumably acting on behalf of the subject.

To more strongly signal such a delegation scenario, a <saml:Condition> element MAY be used (cf. [SAML2ConDel]).

2.4.1 KeyInfo Usage

X.509 data
A <ds:X509Data> XML element which is contained in <ds:KeyInfo> XML element of XML Signature.

According to the SAML V2.0 specification, a holder-of-key assertion MUST contain at least one <ds:KeyInfo> element within the <saml:SubjectConfirmationData> element and that the <ds:KeyInfo> element MUST conform to the XML Signature specification.

This SAML V2.0 Holder-of-Key Assertion Profile requires that the <ds:KeyInfo> element MUST conform to the Second Edition of the XML Signature specification [XMLSig] and further constrains the content of each <ds:KeyInfo> element to contain exactly one <ds:X509Data> element. The <ds:X509Data> element MUST NOT contain a <ds:X509CRL> element. Instead, the following content options are specified, at least one of which MUST be satisfied:

The <ds:X509Data> element MAY contain a <ds:X509Certificate> element. If it does, the <ds:X509Certificate> element MUST contain a base64 encoding of the X.509 certificate possessed by the SAML issuer.

<ds:X509Data>
    <ds:X509Certificate>
    --------
    -- base 64 encoded X.509 certificate
    --------
    </ds:X509Certificate>
</ds:X509Data>

The <ds:X509Data> element MAY contain a <ds:X509SKI> element. If it does, the <ds:X509SKI> element MUST contain the base64 encoding of the plain (i.e., not DER-encoded) value of the Subject Key Identifier (SKI) extension (as specified in [XMLSig]) of the X.509 certificate possessed by the SAML issuer. If the certificate does not contain an SKI extension, the <ds:X509Data> element MUST NOT contain a <ds:X509SKI> element.

<ds:X509Data>
    <ds:X509SKI>
    plan value fo SKI extension
    </ds:X509SKI>
</ds:X509Data>

The <ds:X509Data> element MAY contain a <ds:X509SubjectName> element. If it does, the <ds:X509SubjectName> element MUST contain the subject distinguished name (DN) bound to the X.509 certificate possessed by the SAML issuer.

<ds:X509Data>
    <ds:X509SubjectName>
    subject distingushied name(DN)
    </ds:X509SubjectName>
</ds:X509Data>

The <ds:X509Data> element MAY contain a <ds:X509IssuerSerial> element. If it does, the <ds:X509IssuerSerial> element MUST contain the issuer DN and the issuer serial number (as specified in [XMLSig]) bound to the X.509 certificate possessed by the SAML issuer. (This is the most ristrictive way)

<ds:X509Data>
    <ds:X509IssuerSerial>
    issuer serial number
    </ds:X509IssuerSerial>
</ds:X509Data>

Use of the <ds:X509Certificate> element or the <ds:X509IssuerSerial> element is most restrictive since each implies that the exact same certificate is used by both the SAML issuer and the relying party. Use of the <ds:X509SKI> element or the <ds:X509SubjectName> element is less restrictive since each permits a different certificate to be used by the relying party provided the certificate contains the same key or DN (resp.) as in the certificate used by the SAML issuer.

Use of the <ds:X509SubjectName> element or the <ds:X509IssuerSerial> element is warranted in those situations where the relying party trusts theissuer of the X.509 certificate. The SAML issuer SHOULD NOT bind either of these elements to the <ds:X509Data> element unless it knows that such a trust relationship exists.

Note that the format of the DN contained in the <ds:X509SubjectName> element or the <ds:X509IssuerSerial> element is specified in [XMLSig]. In accordance with that specification, it is RECOMMENDED that the DN conform to [RFC4514] in all cases.

Since the <ds:KeyInfo> element is extensible [XMLSig], other fields or extensions from the X.509 certificate may be bound to the holder-of-key assertion. These are provided as a convenience to the relying party, so that the relying party need not have to decode and parse the certificate. All such extensions are out of scope with respect to this profile, however.

2.4.2 Example

Here is an example of a holder-of-key <saml:SubjectConfirmation> element illustrating three of the content options specified in section 2.4:

<saml:SubjectConfirmation
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
<saml:SubjectConfirmationData
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="saml:KeyInfoConfirmationDataType">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>

<!-- a base64 encoding of an X.509 certificate -->
<ds:X509Certificate>
MIIDuDCCAqACCQCJZK8wF0xVXjANBgkqhkiG9w0BAQQFADCBnTELMAkGA1UEBhMCQlIxEzARBgNV
BAgTClNvbWUtU3RhdGUxEjAQBgNVBAcTCVNvbWUtQ2l0eTESMBAGA1UEChMJR1NvQyAyMDA4MRIw
EAYDVQQLEwlHU29DIDIwMDgxFzAVBgNVBAMTDkpvYW5hIFRyaW5kYWRlMSQwIgYJKoZIhvcNAQkB
FhVzb21lLWFkZHJlc3NAaG9zdC5vcmcwHhcNMDgwNjE2MTcyMTQzWhcNMDkwNjE2MTcyMTQzWjCB
nTELMAkGA1UEBhMCQlIxEzARBgNVBAgTClNvbWUtU3RhdGUxEjAQBgNVBAcTCVNvbWUtQ2l0eTES
MBAGA1UEChMJR1NvQyAyMDA4MRIwEAYDVQQLEwlHU29DIDIwMDgxFzAVBgNVBAMTDkpvYW5hIFRy
aW5kYWRlMSQwIgYJKoZIhvcNAQkBFhVzb21lLWFkZHJlc3NAaG9zdC5vcmcwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDIDVKdO2CCVYA0TspOPmcSNnivjQq7jCacrgRPawKi3/pTuvnW
3c2XCpyT2s6Sks3Eg5T4HIXta5E+lOpN8VbTunVdSrac54r2uK8x+8AqX7M0wQw+98iGw9E2an5q
xRZfqqE1T5jWL/a/G1/e2TGlmp521W3k1nNtf8rYH39JpwBSZMeW7uHOSZOkT/pVvqPTgG7vUQT6
BiRh7PfwsLrLOMubbeQ6Z2m3Vnsv20E1FbPzwswzh4X1gXj9bnyI2UsuoisW9Y4p4byjL3GJ/hxp
mjRjXs+aIpzi0V3MH+jVJ98eomhlUFLaE83xycC8lns+FcCSQZ8RsbnaLZrtC8r7AgMBAAEwDQYJ
KoZIhvcNAQEEBQADggEBACwnWSEpwq5aE7QBdDNNXyok34RIonYi9690yw7i+JU7R/QdE42GERJS
DVKBN959ELLJf5d0vybGv08QWbZVQ7eBGn9xaZ7MhSnblYNDXs9vuv1V2Dy32q1J5nCSzqpJDyln
lVFWe9UQMCJOO6ibUtWLhiDQ49kmMabgyYfX28qB6oRdVL+mDI/XTt+mkCgk4Rs78n4kbX6qnRlj
dE/YnibP1A7iMh8pQkv49J6sP9SeUmQ2zxKCt3tSRzzypWc8JjOZGuBYGQHl9Xm7WEs4CXS7iZJW
E32frMAtavMcTM/gnDtCc8tZAxl2PSLOF1954vapfMjBhg3VTI6QRW//wPE=
</ds:X509Certificate>

<!-- the above X.509 certificate does not contain a
Subject Key Identifier extension so the SAML issuer
must not include a <ds:X509SKI> element -->
<!-- the subject DN (in RFC 5414 format) bound to the
above X.509 certificate -->
<ds:X509SubjectName>emailAddress=some-address@host.org,CN=Joana Trindade,OU=GSoC 2008,O=GSoC 2008,L=Some-City,ST=Some-State,C=BR</ds:X509SubjectName>
<!-- the issuer DN (in RFC 5414 format) and the issuer serial
number (in decimal) bound to the above X.509 certificate -->
<ds:X509IssuerSerial>
<ds:X509IssuerName>emailAddress=some-address@host.org,CN=Joana Trindade,OU=GSoC 2008,O=GSoC 2008,L=Some-City,ST=Some-State,C=BR</ds:X509IssuerName>
<ds:X509SerialNumber>9900230501951362398</ds:X509SerialNumber>
</ds:X509IssuerSerial>

</ds:X509Data>
</ds:KeyInfo>
</saml:SubjectConfirmationData>
</saml:SubjectConfirmation>

A relying party can confirm the attesting entity by the matching the available X.509 data to any of the above child elements of the <ds:X509Data> element.

2.5 Processing Holder-of-Key Assertions

The attesting entity presents a holder-of-key assertion and an X.509 certificate to the relying party. The attesting entity MUST prove possession of the private key corresponding to the public key bound to the certificate, the details of which are out of scope with respect to this profile.

The relying party confirms the attesting entity by comparing the X.509 data in the certificate to the X.509 data bound to the assertion. If the X.509 data in the certificate matches the X.509 data bound to the assertion, the attesting entity is said to be confirmed.

Regardless of the protocol used, any assertions relied upon MUST be valid according to the processing rules specified in [SAML2Core]. In particular, the relying party MUST verify the signature (if any) on each assertion containing a holder-of-key <saml:SubjectConfirmation> element. Any assertion that is not valid, or whose subject confirmation requirements cannot be met, SHOULD be discarded and SHOULD NOT be used to establish a security context for the subject.

If the <ds:X509Data> element contains multiple child elements, the relying party may choose to confirm the attesting entity based on any one of them. Specifically, the relying party MUST confirm that the certificate matches the content of the <ds:X509Data> element as follows:

If the <ds:X509Data> element contains a <ds:X509Certificate> element, and the relying party chooses to confirm the attesting entity based on this element, the relying party MUST ensure that the certificate bound to the assertion matches the X.509 certificate in its possession. Matching is done by comparing the base64-decoded certificates, or the hash values of the base64-decoded certificates, byte-for-byte.

If the <ds:X509Data> element contains a <ds:X509SKI> element, and the relying party chooses to confirm the attesting entity based on this element, the relying party MUST ensure that the value bound to the assertion matches the Subject Key Identifier (SKI) extension bound to the X.509 certificate. Matching is done by comparing the base64-decoded SKI values byte-for-byte. If the X.509 certificate does not contain an SKI extension, the attesting entity is not confirmed and the relying party SHOULD disregard the assertion.

If the <ds:X509Data> element contains a <ds:X509SubjectName> element, and the relying party chooses to confirm the attesting entity based on this element, the relying party MUST ensure that the subject distinguished name (DN) bound to the assertion matches the DN bound to the X.509 certificate. If, however, the relying party does not trust the certificate issuer to issue such a DN, the attesting entity is not confirmed and the relying party SHOULD disregard the assertion.

If the <ds:X509Data> element contains a <ds:X509IssuerSerial> element, and the relying party chooses to confirm the attesting entity based on this element, the relying party MUST ensure that the issuer DN and issuer serial number bound to the assertion match the issuer DN and the issuer serial number (resp.) bound to the X.509 certificate. If the relying party does not trust the certificate issuer to issue X.509 certificates, however, the attesting entity is not confirmed and the relying party SHOULD disregard the assertion.

In the case of a <ds:X509Certificate> element or a <ds:X509SKI> element, the matching process is relatively straightforward. If the <ds:X509Data> element contains a <ds:X509SubjectName> element or a <ds:X509IssuerSerial> element, however, and the relying party chooses to confirm the attesting entity based on one of these elements, the relying party MUST trust the issuer of the X.509 certificate before the attesting entity can be considered confirmed. If such a trust relationship between the relying party and the certificate issuer does not exist, the relying party SHOULD disregard the assertion.

If the <saml:SubjectConfirmationData> element includes NotBefore or NotOnOrAfter attributes, and the relying party trusts the issuer of the X.509 certificate, the relying party MUST confirm that the current time is greater than or equal to (resp., less than or equal to) the value of the NotBefore (resp., the NotOnOrAfter) attribute. If this requirement is not met, the attesting entity is not confirmed and the relying party SHOULD disregard the assertion.

2.6 Security and Privacy Considerations

This profile assumes that both the SAML issuer and the relying party have access to an X.509 certificate. For those deployments that wish to avoid or do not require an X.509-based public key infrastructure (PKI), this may seem unnecessarily restrictive.

In fact, the use of X.509 certificates is typical and provides a number of advantages. First, observe that the SSL/TLS protocol [RFC4346] requires the use of X.509 certificates. Second, and most importantly, since there is no presumption of an underlying trust model for X.509 certificates, the full range of possible content for the <ds:KeyInfo> element is avoided. Those deployments that are in fact based on such a trust model, or wish to avoid X.509 certificates altogether, may choose to profile additional child elements such as <ds:KeyName> or <ds:KeyValue>.

Deployments that rely on holder-of-key SAML assertions will no doubt impose their own requirements on the X.509 certificates used to obtain those assertions.

For example, some deployments will require the certificate to be an X.509 end-entity certificate [RFC5280] issued by a trusted X.509 certification authority (CA) or a certificate based on a trusted X.509 end-entity certificate (such as an X.509 proxy certificate [RFC3820]). This specification imposes no such restrictions, however.

2.6.1 ASN.1 Encoding

For compatibility with the XML Signature specification [XMLSig], this profile intentionally avoids any discussion of the ASN.1 encoding of the X.509 certificate possessed by the SAML issuer and the relying party.

Indeed, in the case of the <ds:X509Certificate> element, the ASN.1 encoding of the certificate doesn’t matter. In this case, the SAML issuer simply base64-encodes the ASN.1-encoded certificate in its possession and binds it to the <ds:X509Certificate> element. Later the relying party base64-decodes the content of the <ds:X509Certificate> element and compares the resulting certificate (byte-for-byte) with the ASN.1-encoded certificate in its possession.

In the case of the <ds:X509SKI>, <ds:X509SubjectName>, or <ds:X509IssuerSerial> elements, however, the ASN.1 encoding of the certificates does matter.

To produce these elements, the SAML issuer must ASN.1-decode the certificate in its possession and parse the ASN.1 to obtain the X.509 data to be bound to the assertion. Likewise the relying party must ASN.1-decode the certificate in its possession, parsing the ASN.1 to obtain the required X.509 data, which it compares to the X.509 data bound to the assertion.

The basic problem is that the ASN.1 encoding of an X.509 certificate is not guaranteed. While it is true that an X.509 certificate is often DER-encoded, a robust implementation must be prepared to handle other ASN.1 encodings besides DER, mainly BER and CER.

Consequently it is anticipated that deployments will prefer the <ds:X509Certificate> element for maximum interoperability. In fact, this preference is reflected in the conformance requirements of this profile (section 3 ).

2.6.2 X.509 Serial Number

Note that some CAs use large random numbers as serial numbers to prevent sequence guessing.

However, not all XML libraries are capable of dealing with large integers in the <ds:X509IssuerSerial> element. The problem is that the <ds:X509SerialNumber> child element of the <ds:X509IssuerSerial> element is typed as an arbitrary integer in [XMLSig] yet conforming implementations are required to support only 18 decimal digits. Thus the <ds:X509IssuerSerial> element should be used with care.

3 Conformance

3.0.1 SAML V2.0 Holder-of-Key Assertion Profile

Both the SAML issuer and the relying party MUST conform to section 2.3.

A SAML issuer MUST follow the issuing rules in section 2.4. In particular, a SAML issuer MUST produce <ds:KeyInfo> elements that conform to section 2.4.1.

Likewise, a relying party MUST follow the processing rules in section 2.5.

To claim conformance to this specification, a SAML issuer implementation MUST support the <ds:X509Certificate> element specified in section 2.4.1.

Support for the remaining child elements specified in section 2.4.1 is OPTIONAL for SAML issuers.

Likewise a conforming relying party implementation MUST support the <ds:X509Certificate> element specified in section 2.5. Support for the remaining child elements specified in section 2.5 is OPTIONAL for relying parties.

«  Shibboleth   ::   Contents   ::   SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0  »