Working Draft 01
21 January 2010
- Specification URIs:
- This Version:
- http://docs.oasis-open.org/xri/xrd-trust-basic-x509/v1.0/wd01/xrd-trust-basic-x509-wd01.xml
(Authoritative)
http://docs.oasis-open.org/xri/xrd-trust-basic-x509/v1.0/wd01/xrd-trust-basic-x509-wd01.html
http://docs.oasis-open.org/xri/xrd-trust-basic-x509/v1.0/wd01/xrd-trust-basic-x509-wd01.pdf
- Previous Version:
- http://docs.oasis-open.org/xri/xrd-trust-basic-x509/v1.0/wd11/xrd-trust-basic-x509-1.0-wd11.xml
(Authoritative)
http://docs.oasis-open.org/xri/xrd-trust-basic-x509/v1.0/wd11/xrd-trust-basic-x509-1.0-wd11.html
http://docs.oasis-open.org/xri/xrd-trust-basic-x509/v1.0/wd11/xrd-trust-basic-x509-1.0-wd11.pdf
- Technical Committee:
- OASIS Extensible Resource Identifier (XRI) TC
- Chairs:
- Peter Davis, NeuStar Inc.
Drummond Reed, XDI.org
- Abstract:
This document defines a basic, X.509-based trust profile used to validate an XRD document signed according to [XRD 1.0], section 5. The document's validity is determined by matching the document's subject to a provided resource host and a set of root certificates.
- Status:
This document was last revised or approved by the XRI Technical Committee on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.
Technical Committee members should send comments on this specification to the Technical Committee's email list. Others should send comments to the Technical Committee by using the "Send A Comment" button on the Technical Committee's web page at http://www.oasis-open.org/committees/xri.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/xri/ipr.php).
The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/xri.
- Notices:
Copyright © OASIS Open 2009. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Final Deliverable, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this deliverable.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this OASIS Final Deliverable by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this OASIS Final Deliverable. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
Table of Contents
- 1. Introduction
- 2. XRD Suject Matching
- 3. Certificate Subject Matching
- 4. Signature and Certificate Validation
Appendixes
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC 2119].
[RFC 2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF, 1997.
[RFC 3986] T. Berners-Lee, R. Fielding L. Masinter. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. IETF, 2005.
[TLS 1.2] T. Dierks, E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. IETF, 2008.
[TLS ECC] S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller. Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS). IETF, 2006.
[XRD 1.0] E. Hammer-Lahav, W. Norris. Extensible Resource Descriptor (XRD) Version 1.0. OASIS, 2009.
[XML Signature] D. Eastlake, J. Reagle, D. Solo, F. Hirsch, T. Roessler. XML Signature Syntax and Processing (Second Edition). W3 Recommendation, 2008.
The validation function takes three inputs:
- XRD Document
The signed XRD document being validated. The XRD document MUST be signed as defined by [XRD 1.0] section 5.
- Authority Name
The absolute URI of the resource described by the XRD, or its URI host component as defined by [RFC 3986].
- Root Certificates
The set of certificates that are trusted by the application 'a priori'. For instance, a set of commonly known Certificate Authority certificates, used to validate other certificates.
The validation process includes three steps:
The XRD
<Subject>or<Alias>is matched against the Authority Name input.The Authority Name input is matched against the common name or alternative names of the XRD Document's signature certificate.
The XRD Document's signature is verified using the document certificate, and the certificate is verified using the Root Certificates input.
All three steps MUST match for the validation to pass successfully.
When comparing host names, the strings MUST be compared in a case insensitive
manner. When comparing absolute URIs, the URIs MUST be first normalized
according to their URI scheme, then compared as defined by [RFC 3986] section 6. For example,
the following two URIs are equivalent: http://example.com:80/resource and
http://EXAMPLE.COM/resource.
If the Authority Name is an absolute URI, perform the following comparisons in order until the first successful match (if none of the comparisons match successfully, validation fails):
Compare the Authority Name with the value of the XRD Document's
<Subject>element if present.Compare the Authority Name with the values of the XRD Document's
<Alias>elements in document order if present.
If the Authority Name is a host name, perform the following comparisons in order until the first successful match (if none of the comparisons match successfully, validation fails):
Compare the Authority Name with the host name component of the XRD Document's
<Subject>element if present and has an authority component per [RFC 3986]. If a<Subject>is present but does not contain a host component per [RFC 3986] but a host can be derived from the URI (such as in mailto, xmpp, or acct URIs), use the scheme-specific rules to extract the host from the<Subject>URI value and compare.For each of the XRD Document's
<Alias>elements in document order if present, compare the Authority Name with the<Alias>URI host name component if present per [RFC 3986]. If an<Alias>does not contain a host component per [RFC 3986] but a host can be derived from the URI (such as in mailto, xmpp, or acct URIs), use the scheme-specific rules to extract the host from the<Alias>URI value and compare.If the document contains a subject using an application-specific element (such as
<hm:Host>in host-meta), extract the host name from it and compare to the Authority Name.
The client MUSTperform the following steps in order (validation fails if any of these steps fail):
The XRD Document's
<ds:Signature>element MUST contain a<ds:KeyInfo>element per [XRD 1.0] section 5.5 and [XML Signature] section 4.4.The
<ds:KeyInfo>MUST contain one or more<X509Data>elements, as specified in [XML Signature].At least one of the
<X509Data>elements MUST contain one or more<X509Certificate>elements. The order in which the certificates appear is significant. The sequence of certificates MUST follow [TLS 1.2] section 7.4.2. In particular, the first certificate must be the signer's certificate, and any subsequent certificate MUST certify the preceding certificate.If the Authority Name is an absolute URI, its host name is extracted per the scheme-specific rules. The Authority Name host must match the subject CN in the certificate. Wildcards in the subject CN are allowed. If the subject CN does not match, then the Authority Name or the host extracted from the Authority Name MUST match against at least one SubjectAltNames present.
The client MUST perform the following steps in order (validation fails if any of these steps fail):
The last
<X509Certificate>element in the<X509Data>element MUST be in the set of Root Certificates input or MUST be certified by a certificate in the set of Root Certificates.The client MUST validate the sequence of certificates as described in [TLS 1.2], section 7.4.2 (i.e., as a Server Certificate). In particular, the signer's certificate MUST allow the key to be used for signing (the digital signature bit MUST be set if the key usage extension is present) with the signature scheme and hash algorithm used in the signature. If the certificate is for an ECDSA public key, the public key MUST use a curve and point format as described in [TLS ECC].
The
<Signature>element MUST be verified against the signer's certificate, following [XML Signature].