Internet DRAFT - draft-laurie-dnssec-key-distribution
draft-laurie-dnssec-key-distribution
Network Working Group B. Laurie
Internet-Draft Nominet
Expires: December 16, 2006 June 14, 2006
Distributing Keys for DNSSEC
draft-laurie-dnssec-key-distribution-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 December 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Until DNSSEC is fully deployed, so-called "islands of trust" will
exist. This will lead to a large number of keys with no method
within DNSSEC to manage the keys. This proposal seeks to address
that issue using existing mechanisms to allow cross-signing of root
(i.e. roots of islands) keys. This cross-signing of keys creates a
non-hierarchical web of trust which permits the efficient gathering
and validation of trust anchors.
Laurie Expires December 16, 2006 [Page 1]
Internet-Draft key-distribution June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Island CAs . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Key Signing . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Publication of Certificates . . . . . . . . . . . . . . . . . . 4
5. Location of Island Publication URL . . . . . . . . . . . . . . 4
6. Use of Certificates . . . . . . . . . . . . . . . . . . . . . . 4
7. Verification of Certificates . . . . . . . . . . . . . . . . . 5
8. Variations . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. Security Non-issues . . . . . . . . . . . . . . . . . . . . . . 5
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
11. Requirements notation . . . . . . . . . . . . . . . . . . . . . 6
12. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
13.1. Normative References . . . . . . . . . . . . . . . . . . . 6
13.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Laurie Expires December 16, 2006 [Page 2]
Internet-Draft key-distribution June 2006
1. Introduction
When DNSSEC signatures are validated the validators will follow a
chain of authority from a pre-configured trust anchor to the data
that is to be validated. The DNSSEC protocol (RFC 4033 [RFC4033],
RFC 4034 [RFC4034] and RFC 4035 [RFC4035]) clearly describes how
these chains of trust are to be established but does not address the
issue of the distribution of the trust anchors.
This document describes how an X.509 based public key infrastructure
can be used to bootstrap the configuratation of a set of trust
anchors. SEP keys are stored in certificates that are signed by the
registries' Certificate Authorities. The system allows registries to
indicate levels of trust which allows for prudent cross-signing.
The Certificate Authority and the certificates are discussed in
Section 2 and Section 3. Section 4 and Section 5 describe how the
certificates are published. Section 6 describes how the certificates
are used to establish the trust-anchors.
In this document the term secure entry point (SEP) key is used to
describe the (sub)set of public key(s) that is intended as a secure
entry point into the zone [RFC3757]. The term Island of security, or
island for short, is used for a zone for which one of the SEP keys
are used as a trust-anchor and which is therefore the start of a
chain of authority.
2. Island CAs
The root of each island will publish an X.509 CA certificate. This
will be a long-term, self-signed certificate, known as the Island
Root CA (IRCA). This CA will then be used to create two subsidiary
CAs, each with a shorter expiry, known as the High Assurance Island
CA and the Low Assurance Island CA. The High and Low Assurance CA
certificates will each contain an X.509v3 extension indicating their
role.
Each island will have a set of requirements for cross-signing, one
for low assurance and one for high assurance. The reason for having
two is to allow cross-signing of keys that the island's operators do
not have high confidence in without exposing them to accusations of
insufficient prudence.
3. Key Signing
Each island will issue a certificate signed by the Island Root CA for
Laurie Expires December 16, 2006 [Page 3]
Internet-Draft key-distribution June 2006
each of its own SEPs. The public key in the certificate will be the
same public key as used by the SEP.
For each other island that meets the island's requirements for cross-
signing, the island will issue a certificate for their IRCA signed by
either the Low or High Assurance Island CA, as appropriate. That is,
the certificate will have the same subject name and public key as the
IRCA being signed, but the issuer will be one of this island's
subsidiary CAs. This could be done using the cross-certification
protocol from RFC 2510 [RFC2510]
Each certificate issued will contain an X.509v3 extension with the
name of the domain associated with the signed public key.
4. Publication of Certificates
Each island will maintain a URL (known as the Island Publication URL
or IPU) where all current certificates issued by any of its CAs are
available. This URL may also have a collection of certificates
issued by other island CAs and also the CA certificates themselves of
other islands. Note, however, that the presence of a certificate
does not indicate any kind of trust in it - that is done purely by
the certificate signatures.
5. Location of Island Publication URL
The location of each IPU will be held in the IRCA using an X.509v3
certificate extension registered for the purpose.
6. Use of Certificates
A resolver wishing to bootstrap its collection of trust anchors need
only choose a small set of IRCAs to trust (or, with luck, a single
one). Once it has done so, it can extract the IPU from the CA
certificate, use HTTP to retrieve the certificate collection
available there, check their (chained) signatures, extract the public
keys from the certificates and use these as the initial set of SEPs
for the domains named in the certificates.
Once the initial set of certificates has been retrieved, this process
can be followed recursively for other IRCAs retrieved. Also, the set
of trusted IRCAs could be expanded to include some or all of the
retrieved IRCAs.
After the set of trusted trust anchors have been established, in-band
Laurie Expires December 16, 2006 [Page 4]
Internet-Draft key-distribution June 2006
mechanisms can be used to keep them up to date. If for some reason
the set of trust anchors becomes too stale to update (for example,
because the device has been offline for an extended period), then the
process can be repeated from the start.
7. Verification of Certificates
Once the collection of certificates is complete, the resolver uses
the trusted IRCAs to verify the certificate of each SEP. Because of
the use of cross-certification, the X.509 verification must be
capable of trying multiple paths to verification, as specified in RFC
3280 [RFC3280].
Users may choose to restrict the verification path, for example by
requiring certificate chains to be below some length, or not
permitting verification through Low Assurance CAs.
Once the set of verified SEPs has been established, then the public
keys are extracted from each one and associated as trust anchors for
DNSSEC with the corresponding domain.
8. Variations
Instead of a URL, the certificate could contain a domain name and
socket number.
Certificates could be published in the DNS [I-D.ietf-dnsext-
rfc2538bis].
Rather than using X.509 for signing, OpenPGP [RFC2440] could be used
instead.
9. Security Non-issues
Note that DNSSEC is not required to secure the domain names used for
certificate retrieval, since the signature of the selected IRCA(s)
will be sufficient to validate the retrieved certificates.
10. Acknowledgements
Thanks to Olaf Kolkman for comments on early drafts and Russ Housley
for explaining how to use X.509 the way I wanted to.
Laurie Expires December 16, 2006 [Page 5]
Internet-Draft key-distribution June 2006
11. Requirements notation
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 [RFC2119].
12. Security Considerations
13. References
13.1. Normative References
[I-D.ietf-dnsext-rfc2538bis]
Josefsson, S., "Storing Certificates in the Domain Name
System (DNS)", draft-ietf-dnsext-rfc2538bis-09 (work in
progress), October 2005.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key
Infrastructure Certificate Management Protocols",
RFC 2510, March 1999.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
13.2. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
Laurie Expires December 16, 2006 [Page 6]
Internet-Draft key-distribution June 2006
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
Laurie Expires December 16, 2006 [Page 7]
Internet-Draft key-distribution June 2006
Author's Address
Ben Laurie
Nominet
17 Perryn Road
London W3 7LR
England
Phone: +44 (20) 8735 0686
Email: ben@algroup.co.uk
Laurie Expires December 16, 2006 [Page 8]
Internet-Draft key-distribution June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Laurie Expires December 16, 2006 [Page 9]
