Title: Re: Proposal for an X.509-based XRI Trust Profile
If it wasn’t clear, the goal is to turn this into a spec *very* quickly and submit as a CD. It is already in pretty good shape for a first draft.
EHL
On 1/20/10 2:52 PM, "Breno de Medeiros" <> wrote:
XRD Signature - Basic X.509 Trust Profile
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.
Inputs
The validation function takes three inputs:
1. XRD Document - the signed XRD document being validated. The XRD
document MUST be signed as defined by [XRD 1.0] section 5.
2. Authority Name - the absolute URI of the resource described by the
XRD, or its URI host component as defined by [RFC 3986].
3. Root Certificates -the set of self-signed certificates that are
trusted by the application 'a priori'. For instance, a set of commonly
known Certificate Authority certificates, used to validate other
certificates.
Process
The validation process includes three steps:
1. The XRD <Subject> or <Alias> is matched against the Authority Name input.
2. The Authority Name input is matched against the common name or
alternative names of the XRD Document's signature certificate.
3. 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.
String Comparisons
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.
1. XRD Subject Matching
1.1 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):
i. Compare the Authority Name with the value of the XRD Document's
<Subject> element if present.
ii. Compare the Authority Name with the values of the XRD Document's
<Alias> elements in document order if present.
1.2 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):
i. 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.
ii. 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.
iii. 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.
2. Certificate Subject Matching
The client MUST perform the following steps in order (validation fails
if any of these steps fail):
i. The XRD Document MUST contain a <ds:KeyInfo> element per [XRD 1.0]
section 5.5 and [XML DSig 2] section 4.4.
ii. The <ds:KeyInfo element> MUST contain one or more <X509Data>
elements, as specified in [XML DSig 2].
iii. 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.
iv. 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, and the certificate
SubjectAltName extension is marked as critical, then the host MUST
match against at least one SubjectAltNames present.
3. Signature and Certificate Validation
The client MUST perform the following steps in order (validation fails
if any of these steps fail):
i. 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.
ii. 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
[TLSECC].
iii. The <Signature> element MUST be verified against the signer's
certificate, following [XML DSig 2].
References
[RFC 3986] URI Generic Syntax, RFC 3986.
[XRD 1.0] Extensible Resource Descriptor (XRD) Version 1.0
[XML DSig 2] W3C XML Signature Syntax and Processing (Second Edition).
[TLS 1.2] The Transport Layer Security (TLS) Protocol Version 1.2 (RFC 5246).
[TLSECC] Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
Layer Security (TLS), RFC 4492.
