Network Working Group J. Hildebrand
Internet-Draft Cisco
Intended status: Standards Track S. Turner
Expires: April 22, 2010 IECA, Inc.
October 19, 2009
Domain Name Assertions
draft-hildebrand-dna-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
An application-level approach to asserting and proving the delegated
ownership of a domain name for XMPP.
Hildebrand & Turner Expires April 22, 2010 [Page 1]
Internet-Draft DNA October 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Generic Use Cases . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Requesting proof with a challenge . . . . . . . . . . . . 6
4.5. No proof possible . . . . . . . . . . . . . . . . . . . . 6
4.6. Proving a challenge . . . . . . . . . . . . . . . . . . . 7
5. Attribute Certificate Proof . . . . . . . . . . . . . . . . . 7
5.1. Attribute Certificate Issuer Profile . . . . . . . . . . . 7
5.2. Attribute Certificate Profile . . . . . . . . . . . . . . 8
5.3. Access Identity Values . . . . . . . . . . . . . . . . . . 8
5.3.1. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Attribute Certificate Signature Algorithms . . . . . . . . 9
5.5. Proof Encoding . . . . . . . . . . . . . . . . . . . . . . 9
6. DNA for XMPP Federation . . . . . . . . . . . . . . . . . . . 9
6.1. DNS SRV lookups . . . . . . . . . . . . . . . . . . . . . 10
6.2. Certificates during Start-TLS . . . . . . . . . . . . . . 10
6.3. Discovering Support . . . . . . . . . . . . . . . . . . . 11
6.4. Turning on DNA . . . . . . . . . . . . . . . . . . . . . . 11
6.5. Asserting new domains . . . . . . . . . . . . . . . . . . 12
6.6. Proactive challenges . . . . . . . . . . . . . . . . . . . 12
6.7. Proactive validation . . . . . . . . . . . . . . . . . . . 12
6.8. Reusing streams . . . . . . . . . . . . . . . . . . . . . 13
6.9. Implementation notes . . . . . . . . . . . . . . . . . . . 13
7. DNA for XMPP client connections . . . . . . . . . . . . . . . 13
7.1. Announcing Support . . . . . . . . . . . . . . . . . . . . 14
7.2. Client challenges for proof . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. XML Namespace Name for DNA . . . . . . . . . . . . . . . . 14
8.2. URN space for standard DNA Proof Types . . . . . . . . . . 14
8.3. DNA Proof Registry . . . . . . . . . . . . . . . . . . . . 15
8.4. Object Identifiers . . . . . . . . . . . . . . . . . . . . 15
9. Internationalization Considerations . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. RELAX NG XML Schema . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Hildebrand & Turner Expires April 22, 2010 [Page 2]
Internet-Draft DNA October 2009
1. Introduction
As large hosting providers begin providing XMPP services for multiple
domains, several issues with previous mechanisms for server-to-server
federation have become apparent.
A large number of sockets are currently required between hosting
providers. Although servers may attempt to piggyback whenever
possible, the possibility exists that 2*N*M sockets will be created
(where N is the number of domains on one hosting provider, and M is
the number of domains on another hosting provider). The goal would
be that the number of sockets was dependent on load or deployment
considerations.
In order to enable or require encryption, the hosting provider must
create a separate socket for each hostname pair and have access to a
X.509 certificate that is signed by a widely-trusted CA and includes
both the public and private keys. Customers of hosting providers
might be uncomfortable with the level of trust this requires.
This document lays out an approach known as Domain Name Assertions
(DNA) that allows providers to effectively host XMPP services on
behalf of other companies, and might be expanded later to support
other protocols.
2. Glossary
Hosted domain An XMPP domain whose network services are delegated to
a third party.
Hosting provider A business entity that provides services for one or
more domains that it does not directly and fully control.
Self-hosted domain A domain whose owner acts as its hosting
provider.
Delegation A ceremony that acts as proof of the intent of the owner
of a hosted domain to cede control to a hosting provider for a
given protocol.
Widely-trusted CA For open communities, a Certificate Authority
whose certificate that is trusted by multiple web browsers by
default. For closed communities, a Certificate Authority that is
trusted by all members of that community.
Sender Domain The domain associated with the 'from' address on a
stanza to be sent across a federation boundary.
Target Domain The domain associated with the 'to' address on a
stanza to be sent across a federation boundary.
Hildebrand & Turner Expires April 22, 2010 [Page 3]
Internet-Draft DNA October 2009
Originating Server The machine that wants to send a message from an
entity at the Sender Domain to an entity at the Target Domain and
thus is attempting to establish a connection between the two
servers.
Receiving Server The machine to which the Originating Server has
opened a connection for the purpose of sending a message from the
Sender Domain to the Target Domain.
Asserting Entity A system element (such as a server) asserting a
given domain name as an identity.
Validating Entity A system element (such as a client or server) that
checks a given identity asserted by an asserting entity.
Asserted Domain A domain name asserted by either side of a
conversation. validating entities may require assertions to be
backed up with proof.
Proof A secure mechanism through which a validating entity can
ascertain that an asserting entity has authority for the asserted
domain, either directly or indirectly (by delegation).
3. Requirements
1. A hosting provider MUST be able to service domains for which it
cannot obtain certificates signed by a widely-trusted CA.
2. All network traffic (except for initial handshakes) MUST be
encrypted in a manner not subject to man-in-the-middle attacks.
3. The number of socket connections between hosting providers MUST
NOT be a function of the number of domains hosted by either
provider.
4. Connections MUST be usable in either direction, if allowed by
policy and deployment considerations.
5. The owners of the hosted domain MUST NOT be required to give out
private keying material associated with any certificate they own
that has been signed by a widely-trusted CA.
6. The owners of the hosted domain MUST be allowed to choose the
frequency with which they wish to perform the delegation
ceremony.
7. The owners of the hosted domain MUST be allowed to revoke their
delegation at any time.
8. Multiple mechanisms for proving delegation MUST be possible.
9. It MUST be possible for new assertions to be added to a stream at
any point after the stream is fully established, but before the
stream is closed
4. Generic Use Cases
The DNA mechanism can be used for multiple different protocols. In
particular, client-to-server XMPP and server-to-server XMPP are
Hildebrand & Turner Expires April 22, 2010 [Page 4]
Internet-Draft DNA October 2009
discussed herein, but the general approach could be used for non-XMPP
protocols such as SMTP or IMAP. As such, the protocol syntax offered
here is normative for XMPP, but merely illustrative for other
protocols, which will need their own protocol bindings.
The following domain names are used in the examples in this section:
asserted.tld The domain name being asserted.
4.1. Assertions
The asserting entity asserts a domain name through the use of an
"assert" element. Assertions MUST contain a "from" attribute naming
the domain name that is being asserted.
4.2. Validation
When the validating entity has been satisified that the asserting
entity is authoritative for the domain name asserted, it MUST send a
"valid" element. At this point, the asserting entity MAY send
stanzas to the validating entity containing from addresses in the
asserted and validated domain.
Validating entities SHOULD respond to a domain name assertion without
asking for further proof when the domain name asserted is represented
in the certificate offered by the asserting entity according to the
rules set out in [rfc3920bis].
Validating entities MAY respond to a domain name assertion without
asking for further proof when the domain name asserted is known to be
associated with the asserting entity through some other secure means
such as DNSSEC, caching, or local knowledge. In the DNSSEC case, the
server hostname in the SRV record used to connect SHOULD be looked
for in the certificate offered by the asserting entity, according to
the rules set out in [rfc3920bis].
4.3. Invalidation
When the validating entity does not accept proof offered by the
asserting entity, or it no longer trusts the proof (for example due
to the proof timing out or being revoked), it sends the asserting
entity an "invalid" element. The asserting entity MUST NOT send any
stanzas to the validating entity containing from addresses in the
invalidated domain without performing another validation.
Invalid responses MAY be given in direct response to an assertion if
the validating entity has reason to believe that no proof is
Hildebrand & Turner Expires April 22, 2010 [Page 5]
Internet-Draft DNA October 2009
possible. Examples that would cause this response include a blocking
list or a negative cache.
4.4. Requesting proof with a challenge
If an assertion cannot be validated immediately, the validating
entity may ask for further proof. Inside the "challenge" element, at
least one form of proof that will be acceptable MUST be given to the
asserting entity. If an acceptable proof format is not available for
the asserted domain, the validating entity MUST return an invalid
response proactively.
A "proof" element designates a type of proof that would be acceptable
to the verifying entity. The "type" attribute of the "proof" element
MUST be a valid URI. A registry of proof types will be created with
the IANA (see Section 8). Standard proof types will begin with
"urn:ietf:params:dna:proof:". Custom proofs should be signaled with
a "type" attribute value containing a full URI under the control of
the defining party. Proof types MUST be compared for equality using
the rules for comparing URIs.
Some proof types MAY require information or nonces from the
validating entity. If so, the specification for that proof type MUST
specify extensions to the "proof" element in a new namespace.
In some protocols, a challenge MAY be sent without an assertion, if
the validating entity has reason to believe that the entity with
which it is talking is authoritative for a given domain.
< type='http://example.com/proof/custom'/>
4.5. No proof possible
If the validating entity requires proof, but will not accept proof by
a means that the asserting entity has available for the asserted
domain, the asserting entity MUST respond with an "impossible"
element. The validating entity MUST NOT send a "valid" or "invalid"
element in response, and MUST NOT accept stanzas from the asserted
domain on this connection unless some other assertion works in the
future.
The "impossible" element MAY be sent after full validation, if the
asserting entity would like to retract the assertion.
Hildebrand & Turner Expires April 22, 2010 [Page 6]
Internet-Draft DNA October 2009
4.6. Proving a challenge
If an asserting entity thinks it can prove a given assertion when
challenged, it sends that proof in a "proof" element. The REQUIRED
"type" attribute specifies the chosen proof type, and the REQUIRED
"from" attribute specifies the domain being proved. Each proof type
MUST specify the format of the contents of the "proof" element.
Suggestions for formats include Base64-encoded binary as character
data or structured XML in a new namespace.
(Base64-encoded attribute certificate)
5. Attribute Certificate Proof
When an asserting entity has been delegated responsibility for
hosting a given domain, an Attribute Certificate MUST be used to
prove the delegation. The proof type URI associated with attribute
certificates SHALL be 'urn:ietf:params:dna:proof:attribute-cert'
(EDITOR'S NOTE: We will work with IANA to come up with a good URN.
This is just a placeholder.)
The certificate that signed the attribute certificate MUST have been
acceptable as proof of ownership of a given domain for the protocol
in question, according to the rules in [rfc3920bis]. Validating
entities SHOULD try prepending the asserted domain with "www." and
re-checking for name matches before rejecting the signing
certificate, in order to allow for easier deployments using existing
web certificates as proof.
Each protocol that is delegated will be assigned its own OID to
identify a service and whether the entity can act as a server or
client. These values will be included in the Access Identifier
attribute, from [I-D.ietf-pkix-3281update]. This document defines
the OIDs for XMPP. Other documents may specify additional OIDs.
The remaining paragraphs in this section profile the attribute
certificate issuers public key certificate and the attribute
certificate.
5.1. Attribute Certificate Issuer Profile
The following is a profile of the attribute certificate issuer's
public key certificate, which is as per [I-D.ietf-pkix-3281update]:
Hildebrand & Turner Expires April 22, 2010 [Page 7]
Internet-Draft DNA October 2009
o The issuer's certificate MUST conform to [RFC5280].
o The issuer's certificate MUST have a keyUsage extension with the
digitalSignature bit set.
o The issuer's certificate MUST NOT have a basicConstraints
extension with the cA BOOLEAN set to TRUE.
In addition to the [I-D.ietf-pkix-3281update] requirements, the
subject name MUST be non-NULL in the attribute certificate issuer's
public key certificate.
5.2. Attribute Certificate Profile
The attribute certificate issued MUST conform to
[I-D.ietf-pkix-3281update]. There are options in that profile and
the following profiles those options:
o The holder field MUST be the baseCertificateID.
o The attributes field MUST include the Access Identity attribute,
as specified in Section 4.4.2 of [I-D.ietf-pkix-3281update]. Both
the service and ident fields' GeneralName choice MUST be
registeredID. The service and ident fields MUST be as defined in
Section 5.3. Other attributes MAY be included.
o The extensions field MUST include the non-critical noRevAvail
extension, as defined in Section 4.3.6 of
[I-D.ietf-pkix-3281update], to indicate that no revocation
information is available from the attribute certificate issuer.
o The extensions field MAY include:
* The authorityKeyIdentifier extension if the issuer has more
than one key pair.
* The issuerAltName extension if the issuer's certificate
includes the subjectAltName extension. If included
issuerAltName MUST be marked non-critical.
5.3. Access Identity Values
The following paragraphs define the service and ident values for the
delegated protocols. Currently, only values for XMPP are defined. A
later version of this document or another document may specify
additional values for other protocols.
5.3.1. XMPP
When XMPP is delegated the following procedures MUST be followed.
The service field MUST be id-xmpp. The following object identifier
identifies that the AC holder supports XMPP:
id-xmpp OBJECT IDENTIFIER ::= { TBD }
The ident field MUST be either id-xmpp-client or id-xmpp-server.
Hildebrand & Turner Expires April 22, 2010 [Page 8]
Internet-Draft DNA October 2009
Both id-xmpp-client and id-xmpp-server MAY appear in the same
attribute certificate. Note that the Access Identity attribute will
be multi-valued when both id-xmpp-client and id-xmpp-server are
present.
The following object identifier identifies the AC holder as the XMPP
client:
id-xmpp-client OBJECT IDENTIFIER ::= { id-xmpp 0 }
The following object identifier identifies the AC holder as the XMPP
server:
id-xmpp-server OBJECT IDENTIFIER ::= { id-xmpp 1 }
5.4. Attribute Certificate Signature Algorithms
The issuer MUST support signing attribute certificate with the PKCS
#1 version 1.5 signature algorithm with SHA-256, as specified in
[RFC4055].
5.5. Proof Encoding
The attribute certificate, the issuer's certificate, and all of the
CA certificates in the trust chain of the signing certificate back to
the trust anchor are encoded as a "certs-only" SMIME message, as per
[I-D.ietf-smime-3851bis] (i.e, a degenerate SignedData with no
content just certificates). The resulting message is then Base64
encoded, as per Section 6.8 of [RFC2045]. The end result is then
transmitted as the character data of a "proof" element.
6. DNA for XMPP Federation
Two XMPP servers, each of which hosts multiple domains that they do
not directly control, desire to connect in order to exchange traffic
for at least two of those domains (one on either side).
The following domain names are used in the examples:
target.tld The domain portion of the JID in the to address of the
stanza that caused this connection to be initiated.
othertarget.tld The domain portion of the JID in the to address of a
stanza being sent across a stream that was originally started to
talk to target.tld.
targetprovider.tld The hosting provider for target.tld.
server.targetprovider.tld A server with XMPP federation services at
the target's hosting provider.
Hildebrand & Turner Expires April 22, 2010 [Page 9]
Internet-Draft DNA October 2009
originator.tld The domain portion of the JID in the from address of
the stanza that caused this connection to be initiated.
originatingprovider.tld The hosting provider for target.tld.
server.originatingprovider.tld A server with XMPP federation
services at the originator's hosting provider.
6.1. DNS SRV lookups
In a delegated hosting scenario, DNS SRV records are REQUIRED, since
otherwise the hosting provider will never be contacted for the target
domain. As specified by [rfc3920bis] the originating server looks up
the target domain to find a list of receiving servers. If the
originating server already has a connection to the IP address
represented by one of these servers (perhaps because it is
communicating with another domain hosted by this provider), it MAY
reuse that stream (see Stream Reuse). If the originating server does
not have a connection it wants to reuse, it performs the SRV
algorithm to select an SRV record and makes a TCP connection to the
server and port specified by the selected SRV record.
Unless assured by a mechanism such as DNSSEC, the originating server
MUST NOT trust the information received from the DNS SRV as proof
that the target domain has been delegated to the receiving server.
% dig +short -t SRV _xmpp-server._tcp.target.tld
0 1 5269 server.targetprovider.tld
6.2. Certificates during Start-TLS
The first step during stream negotiation MUST be Start-TLS. The
receiving server MUST offer a certificate signed by a widely-trusted
CA. The receiving server MUST require a client certificate. The
certificate offered by the originating server MUST be signed be a
widely-trusted CA. Both sides MUST check the certificate offered to
it for validity (e.g. time period, signatures, and trust anchor), but
MUST NOT disconnect when the certificate received does not contain a
name matching its expectations.
The names on these certificates SHOULD be associated with the
relevant hosting provider, and need not be related to the domains
being hosted. If the certificates have the name of the server
offered in the SRV record, it MAY be possible to use DNSSEC for proof
in the future.
CN=server.targetprovider.tld
CN=server.originatingprovider.tld
Hildebrand & Turner Expires April 22, 2010 [Page 10]
Internet-Draft DNA October 2009
6.3. Discovering Support
To and from addresses are REQUIRED in the stream:stream tag. These
represent the first domain pair associated with this stream, and are
the domain names from the stanza that caused this connection to be
established.
To announce its support for DNA, the receiving server asserts its
identity in the stream features following TLS negotiation.
6.4. Turning on DNA
If the originating server supports DNA, it looks for an assertion in
the stream features. If it finds none, it MAY fall back on another
means of verifying the identiy of the target server, if allowed by
local policy.
Originating servers that support DNA talking to target servers that
declare support for DNA MUST NOT send protocol other than DNA
negotations until they are able to validate the assertion offered by
the target server in the stream features. The first validation
proves to the originating server that it is talking to a server
authoritative for the target domain, so that it is safe to use this
domain in "to" addresses on this stream.
Once an originating server completes this first validation it signals
that it is willing and able to participate in bi-directional XMPP
federation traffic, as long as all of the domains required have been
asserted and validated at least once on this stream.
If the originating server does not require more proof (due to a
certificate match or DNSSEC-verified delegation), it may send a
"valid" element without requesting proof first, as in all DNA
interactions.
(Base64-encoded attribute certificate)
Hildebrand & Turner Expires April 22, 2010 [Page 11]
Internet-Draft DNA October 2009
6.5. Asserting new domains
Before either side sends stanzas on a given stream, it MUST ensure
that the other side will accept those stanzas by asserting the domain
in the "from" attribute of those stanzas, and waiting for a "valid"
response before sending the stanzas in question.
The originating server MUST therefore send its own assertion after
accepting the target domain's assertion.
6.6. Proactive challenges
Before either side sends stanzas on a given stream, it MUST ensure
that the other side is authoriative for the domain in the "to"
attribute on those stanzas. If the sender has already accepted an
assertion on this stream, and that assertion has not been revoked
with an "impossible" element, no action is required. Otherwise, the
sender can proactively request proof for that domain by sending a
challenge even though the other side has not sent an assertion for
that domain yet.
6.7. Proactive validation
When two hosting providers connect, they may have previous knowledge
(perhaps from a cache) of which domains they will trust on the new
connection. If so, either side MAY send as many "valid" elements as
desired, even though the other side has not sent assertions for those
domain.
The server receiving these proactive validations MUST NOT change its
self-image (which domains it thinks it is authoritative for), but
SHOULD NOT send assertions for these domains on this stream. If the
server receiving a proactive validation is no long authoritative for
a given domain, it MUST send an "impossible" element, at which point
the sender MUST remove the receiver from any cache and not send any
stanzas on this stream to the given domain.
Any cache of DNA information SHOULD be associated with the
certificate offerred by the relevant server, and SHOULD be checked
for revocation if possible, according to local policy.
Hildebrand & Turner Expires April 22, 2010 [Page 12]
Internet-Draft DNA October 2009
6.8. Reusing streams
DNA streams are bi-directional, and may have an aribtrary number of
domains validated in either direction, at any point in the lifetime
of the stream. Before sending a stanza on a given stream, the sender
MUST ensure that "valid" elements have been exchanged according to
the above rules for both the "to" and "from" address, and that no
"invalid" or "impossible" element has revoked an assertion.
An "impossible" or "invalid" element SHOULD NOT cause the rest of the
stream to become invalidated in either directions. When these
elements are seen, they SHOULD merely change the list of domains that
are valid on that stream. If no domains are valid on the stream, the
stream MAY be closed immediately, or MAY be left open if desired. If
left open, the stream MUST NOT be used for stanza traffic until
domains are asserted as needed for the desired domains.
Domains that are marked as "invalid" or "impossible" SHOULD NOT be
retried on the same stream unless new information has become
available, in order to prevent assertion storms.
6.9. Implementation notes
If the first server-to-server validation exchange fails, the parties
MAY keep the connection open (perhaps for a shorter than is usual) in
case another domain pair would need a connection between these
servers.
Ensure that only one challenge is outstanding on a given connection
for a given domain. Ensure that only one assertion or one proof is
outstanding on a given connection for a given domain.
7. DNA for XMPP client connections
Hosting providers have a similar problem for client to server
connections. Clients need to ensure that they are talking to an
authoritative server for the domain they intend to log in to.
Typically, this is done by examining the certificate offered by the
server during TLS negotiation, according to the rules in
[rfc3920bis]. However, hosting providers will typically not have
access to a valid certificate for the target domain and its
associated private key. DNA can be used for the hosting provider to
prove that hosting services have been delegated to it.
Hildebrand & Turner Expires April 22, 2010 [Page 13]
Internet-Draft DNA October 2009
7.1. Announcing Support
To announce its support for DNA, the server asserts its identity in
the stream features following TLS negotiation. The server MUST offer
the identity of the domain specified in the client's stream header
"to" attribute.
7.2. Client challenges for proof
To utilize the server's DNA assertion, the client performs Start-TLS
per [rfc3920bis], however, if the client does not find a name match
on the offered certificate, it does not disconnect immediately.
Instead, if the server offers an assertion, it can use the name from
that assertion to ask the server for proof of delegation.
Subsequent protocol follows the generic use cases above, with the
exception that alternate or additional domain names MUST NOT be
asserted. If the server returns an "impossible" element, the server
MUST terminate the stream. If the client sends an "invalid" element,
the client MUST terminate the stream.
8. IANA Considerations
8.1. XML Namespace Name for DNA
A URN sub-namespace for Domain Name Assertion (DNA) negotiation data
in the Extensible Messaging and Presence Protocol (XMPP) is defined
as follows. (This namespace name adheres to the format defined in .)
URI: urn:ietf:params:xml:ns:dna
Specification: XXXX
Description: This is the XML namespace name for Domain Name
Assertion (DNA) negotiation data in the Extensible Messaging and
Presence Protocol (XMPP) as defined by XXXX.
Registrant Contact: IETF, XMPP Working Group,
8.2. URN space for standard DNA Proof Types
A URN sub-namespace for DNA is defined as follows. (This namespace
name adheres to the format defined in .)
Hildebrand & Turner Expires April 22, 2010 [Page 14]
Internet-Draft DNA October 2009
URI: urn:ietf:params:dna:proof
Specification: XXXX
Description: This is the sub-namespace for standardized Domain Name
Assertion (DNA) proof types as defined by XXXX.
Registrant Contact: IETF, XMPP Working Group,
8.3. DNA Proof Registry
The URNs inside urn:ietf:params:dna:proof
8.4. Object Identifiers
The following OIDs are defined in Section 5.3 of this document:
o id-xmpp
o id-xmpp-client
o id-xmpp-server
9. Internationalization Considerations
The domains offered MUST conform to all of the rules for "Domain
Identitifiers", as specified in &rfc3920bis;, including (but not
limited to) the rules for syntax, cannonicalization and comparison.
10. Security Considerations
TBD.
11. Normative References
[rfc3920bis]
Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-02 (work
in progress), September 2009.
[I-D.ietf-pkix-3281update]
Housley, R., Farrell, S., and S. Turner, "An Internet
Attribute Certificate Profile for Authorization",
draft-ietf-pkix-3281update-05 (work in progress),
April 2009.
[I-D.ietf-smime-3851bis]
Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", draft-ietf-smime-3851bis-11 (work in
progress), May 2009.
Hildebrand & Turner Expires April 22, 2010 [Page 15]
Internet-Draft DNA October 2009
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
Appendix A. RELAX NG XML Schema
default namespace = "urn:ietf:params:xml:ns:dna"
# Intent: Internationalized Domain Name (simplisitic view)
domain = xsd:string { pattern = "(\p{L}|\p{N})(\p{L}|\p{N}|\p{M}|-)*"
"(\.(\p{L}|\p{N})(\p{L}|\p{N}|\p{M}|-)*)*"}
assert = element assert {
attribute from { domain }
}
valid = element valid {
attribute to { domain }
}
invalid = element valid {
attribute to { domain }
}
proof = element proof {
attribute type { xsd:anyURI },
attribute from { domain }?,
text?
}
challenge = element challenge {
proof+
}
start = assert | valid | invalid | proof | challenge
Hildebrand & Turner Expires April 22, 2010 [Page 16]
Internet-Draft DNA October 2009
Authors' Addresses
Joe Hildebrand
Cisco
Email: jhildebr@cisco.com
Sean Turner
IECA, Inc.
Email: turners@ieca.com
Hildebrand & Turner Expires April 22, 2010 [Page 17]