553N/ANetwork Working Group M. StJohns
0N/ARequest for Comments: 5011 Independent
553N/ACategory: Standards Track September 2007
0N/A Automated Updates of DNS Security (DNSSEC) Trust Anchors
0N/A This document specifies an Internet standards track protocol for the
0N/A Internet community, and requests discussion and suggestions for
0N/A improvements. Please refer to the current edition of the "Internet
0N/A Official Protocol Standards" (STD 1) for the standardization state
0N/A and status of this protocol. Distribution of this memo is unlimited.
0N/A This document describes a means for automated, authenticated, and
0N/A authorized updating of DNSSEC "trust anchors". The method provides
0N/A protection against N-1 key compromises of N keys in the trust point
0N/A key set. Based on the trust established by the presence of a current
196N/A anchor, other anchors may be added at the same place in the
196N/A hierarchy, and, ultimately, supplant the existing anchor(s).
196N/A This mechanism will require changes to resolver management behavior
196N/A (but not resolver resolution behavior), and the addition of a single
196N/A flag bit to the DNSKEY record.
0N/AStJohns Standards Track [Page 1]
0N/ARFC 5011 Trust Anchor Update September 2007
196N/A 1. Introduction ....................................................2
196N/A 1.1. Compliance Nomenclature ....................................3
0N/A 2. Theory of Operation .............................................3
0N/A 2.1. Revocation .................................................4
0N/A 2.2. Add Hold-Down ..............................................4
0N/A 2.3. Active Refresh .............................................5
0N/A 2.4. Resolver Parameters ........................................6
0N/A 2.4.1. Add Hold-Down Time ..................................6
0N/A 2.4.2. Remove Hold-Down Time ...............................6
0N/A 2.4.3. Minimum Trust Anchors per Trust Point ...............6
0N/A 3. Changes to DNSKEY RDATA Wire Format .............................6
0N/A 4. State Table .....................................................6
0N/A 4.1. Events .....................................................7
0N/A 4.2. States .....................................................7
0N/A 5. Trust Point Deletion ............................................8
0N/A 6. Scenarios - Informative .........................................9
0N/A 6.1. Adding a Trust Anchor ......................................9
0N/A 6.2. Deleting a Trust Anchor ....................................9
0N/A 6.3. Key Roll-Over .............................................10
0N/A 6.4. Active Key Compromised ....................................10
0N/A 6.5. Stand-by Key Compromised ..................................10
0N/A 6.6. Trust Point Deletion ......................................10
0N/A 7. IANA Considerations ............................................11
0N/A 8. Security Considerations ........................................11
0N/A 8.1. Key Ownership vs. Acceptance Policy .......................11
0N/A 8.2. Multiple Key Compromise ...................................12
0N/A 8.3. Dynamic Updates ...........................................12
0N/A 9. Normative References ...........................................12
0N/A 10. Informative References ........................................12
0N/A As part of the reality of fielding DNSSEC (Domain Name System
0N/A Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
0N/A come to the realization that there will not be one signed name space,
0N/A but rather islands of signed name spaces each originating from
0N/A specific points (
i.e., 'trust points') in the DNS tree. Each of
0N/A those islands will be identified by the trust point name, and
0N/A validated by at least one associated public key. For the purpose of
0N/A this document, we'll call the association of that name and a
0N/A particular key a 'trust anchor'. A particular trust point can have
0N/A more than one key designated as a trust anchor.
0N/A For a DNSSEC-aware resolver to validate information in a DNSSEC
0N/A protected branch of the hierarchy, it must have knowledge of a trust
0N/A anchor applicable to that branch. It may also have more than one
0N/AStJohns Standards Track [Page 2]
0N/ARFC 5011 Trust Anchor Update September 2007
0N/A trust anchor for any given trust point. Under current rules, a chain
0N/A of trust for DNSSEC-protected data that chains its way back to ANY
0N/A known trust anchor is considered 'secure'.
0N/A Because of the probable balkanization of the DNSSEC tree due to
0N/A signing voids at key locations, a resolver may need to know literally
0N/A thousands of trust anchors to perform its duties (
e.g., consider an
0N/A unsigned ".COM"). Requiring the owner of the resolver to manually
0N/A manage these many relationships is problematic. It's even more
0N/A problematic when considering the eventual requirement for key
0N/A herein won't help with the initial configuration of the trust anchors
0N/A in the resolvers, but should make trust point key
0N/A As mentioned above, this document describes a mechanism whereby a
0N/A resolver can update the trust anchors for a given trust point, mainly
0N/A without human intervention at the resolver. There are some corner
0N/A cases discussed (
e.g., multiple key compromise) that may require
0N/A manual intervention, but they should be few and far between. This
0N/A document DOES NOT discuss the general problem of the initial
0N/A configuration of trust anchors for the resolver.
0N/A1.1. Compliance Nomenclature
0N/A The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
0N/A "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
0N/A document are to be interpreted as described in BCP 14, [RFC2119].
0N/A2. Theory of Operation
0N/A The general concept of this mechanism is that existing trust anchors
0N/A can be used to authenticate new trust anchors at the same point in
0N/A the DNS hierarchy. When a zone operator adds a new SEP key (
i.e., a
0N/A DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section
0N/A 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
0N/A validated by an existing trust anchor, then the resolver can add the
0N/A new key to its set of valid trust anchors for that trust point.
909N/A There are some issues with this approach that need to be mitigated.
0N/A For example, a compromise of one of the existing keys could allow an
0N/A attacker to add their own 'valid' data. This implies a need for a
0N/A method to revoke an existing key regardless of whether or not that
0N/A key is compromised. As another example, assuming a single key
0N/A compromise, we need to prevent an attacker from adding a new key and
0N/A revoking all the other old keys.
0N/AStJohns Standards Track [Page 3]
0N/ARFC 5011 Trust Anchor Update September 2007
0N/A Assume two trust anchor keys A and B. Assume that B has been
0N/A compromised. Without a specific revocation bit, B could invalidate A
0N/A simply by sending out a signed trust point key set that didn't
0N/A contain A. To fix this, we add a mechanism that requires knowledge
0N/A of the private key of a DNSKEY to revoke that DNSKEY.
0N/A A key is considered revoked when the resolver sees the key in a
0N/A self-signed RRSet and the key has the REVOKE bit (see Section 7
0N/A below) set to '1'. Once the resolver sees the REVOKE bit, it MUST
0N/A NOT use this key as a trust anchor or for any other purpose except to
909N/A validate the RRSIG it signed over the DNSKEY RRSet specifically for
0N/A the purpose of validating the revocation. Unlike the 'Add' operation
0N/A below, revocation is immediate and permanent upon receipt of a valid
0N/A revocation at the resolver.
0N/A A self-signed RRSet is a DNSKEY RRSet that contains the specific
0N/A DNSKEY and for which there is a corresponding validated RRSIG record.
0N/A It's not a special DNSKEY RRSet, just a way of describing the
909N/A validation requirements for that RRSet.
0N/A N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint
0N/A than one without the bit set. This affects the matching of a DNSKEY
0N/A to DS records in the parent [RFC3755], or the fingerprint stored at a
0N/A resolver used to configure a trust point.
0N/A In the given example, the attacker could revoke B because it has
0N/A knowledge of B's private key, but could not revoke A.
0N/A Assume two trust point keys A and B. Assume that B has been
0N/A compromised. An attacker could generate and add a new trust anchor
0N/A key C (by adding C to the DNSKEY RRSet and signing it with B), and
0N/A then invalidate the compromised key. This would result in both the
909N/A attacker and owner being able to sign data in the zone and have it
0N/A accepted as valid by resolvers.
0N/A To mitigate but not completely solve this problem, we add a hold-down
0N/A time to the addition of the trust anchor. When the resolver sees a
0N/A new SEP key in a validated trust point DNSKEY RRSet, the resolver
0N/A starts an acceptance timer, and remembers all the keys that validated
0N/A the RRSet. If the resolver ever sees the DNSKEY RRSet without the
0N/A new key but validly signed, it stops the acceptance process for that
0N/A key and resets the acceptance timer. If all of the keys that were
0N/AStJohns Standards Track [Page 4]
0N/ARFC 5011 Trust Anchor Update September 2007
0N/A originally used to validate this key are revoked prior to the timer
0N/A expiring, the resolver stops the acceptance process and resets the
0N/A Once the timer expires, the new key will be added as a trust anchor
0N/A the next time the validated RRSet with the new key is seen at the
0N/A resolver. The resolver MUST NOT treat the new key as a trust anchor
0N/A until the hold-down time expires AND it has retrieved and validated a
0N/A DNSKEY RRSet after the hold-down time that contains the new key.
0N/A N.B.: Once the resolver has accepted a key as a trust anchor, the key
0N/A MUST be considered a valid trust anchor by that resolver until
0N/A explicitly revoked as described above.
0N/A In the given example, the zone owner can recover from a compromise by
0N/A revoking B and adding a new key D and signing the DNSKEY RRSet with
0N/A The reason this does not completely solve the problem has to do with
0N/A the distributed nature of DNS. The resolver only knows what it sees.
0N/A A determined attacker who holds one compromised key could keep a
0N/A single resolver from realizing that the key had been compromised by
0N/A intercepting 'real' data from the originating zone and substituting
0N/A their own (
e.g., using the example, signed only by B). This is no
0N/A worse than the current situation assuming a compromised key.
0N/A A resolver that has been configured for an automatic update of keys
0N/A from a particular trust point MUST query that trust point (
e.g., do a
0N/A lookup for the DNSKEY RRSet and related RRSIG records) no less often
0N/A than the lesser of 15 days, half the original TTL for the DNSKEY
0N/A RRSet, or half the RRSIG expiration interval and no more often than
0N/A once per hour. The expiration interval is the amount of time from
0N/A when the RRSIG was last retrieved until the expiration time in the
0N/A RRSIG. That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
0N/A 1/2*RRSigExpirationInterval))
0N/A If the query fails, the resolver MUST repeat the query until
0N/A satisfied no more often than once an hour and no less often than the
0N/A lesser of 1 day, 10% of the original TTL, or 10% of the original
0N/A expiration interval. That is, retryTime = MAX (1 hour, MIN (1 day,
0N/A .1 * origTTL, .1 * expireInterval)).
0N/AStJohns Standards Track [Page 5]
0N/ARFC 5011 Trust Anchor Update September 2007
196N/A2.4. Resolver Parameters
196N/A2.4.1. Add Hold-Down Time
196N/A The add hold-down time is 30 days or the expiration time of the
196N/A original TTL of the first trust point DNSKEY RRSet that contained the
196N/A new key, whichever is greater. This ensures that at least two
196N/A validated DNSKEY RRSets that contain the new key MUST be seen by the
196N/A resolver prior to the key's acceptance.
196N/A2.4.2. Remove Hold-Down Time
196N/A The remove hold-down time is 30 days. This parameter is solely a key
196N/A management database bookeeping parameter. Failure to remove
196N/A information about the state of defunct keys from the database will
196N/A not adversely impact the security of this protocol, but may end up
196N/A with a database cluttered with obsolete key information.
196N/A2.4.3. Minimum Trust Anchors per Trust Point
196N/A A compliant resolver MUST be able to manage at least five SEP keys
196N/A3. Changes to DNSKEY RDATA Wire Format
196N/A Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag.
196N/A If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY)
196N/A signed by the associated key, then the resolver MUST consider this
196N/A key permanently invalid for all purposes except for validating the
196N/A The most important thing to understand is the resolver's view of any
0N/A key at a trust point. The following state table describes this view
0N/A at various points in the key's lifetime. The table is a normative
0N/A part of this specification. The initial state of the key is 'Start'.
0N/A The resolver's view of the state of the key changes as various events
0N/A This is the state of a trust-point key as seen from the resolver.
0N/A The column on the left indicates the current state. The header at
0N/A the top shows the next state. The intersection of the two shows the
0N/A event that will cause the state to transition from the current state
0N/AStJohns Standards Track [Page 6]
0N/ARFC 5011 Trust Anchor Update September 2007
0N/A --------------------------------------------------
0N/A FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
0N/A ----------------------------------------------------------
0N/A Start | |NewKey | | | | |
0N/A ----------------------------------------------------------
0N/A AddPend |KeyRem | |AddTime| | | |
0N/A ----------------------------------------------------------
0N/A Valid | | | |KeyRem |Revbit | |
0N/A ----------------------------------------------------------
0N/A Missing | | |KeyPres| |Revbit | |
0N/A ----------------------------------------------------------
0N/A Revoked | | | | | |RemTime|
0N/A ----------------------------------------------------------
0N/A Removed | | | | | | |
0N/A ----------------------------------------------------------
0N/A NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
0N/A That key will become a new trust anchor for the named trust
0N/A point after it's been present in the RRSet for at least 'add
0N/A KeyPres The key has returned to the valid DNSKEY RRSet.
0N/A KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
0N/A AddTime The key has been in every valid DNSKEY RRSet seen for at
0N/A least the 'add time'.
0N/A RemTime A revoked key has been missing from the trust-point DNSKEY
0N/A RRSet for sufficient time to be removed from the trust set.
0N/A RevBit The key has appeared in the trust anchor DNSKEY RRSet with
0N/A its "REVOKED" bit set, and there is an RRSig over the DNSKEY
0N/A RRSet signed by this key.
0N/A Start The key doesn't yet exist as a trust anchor at the resolver.
0N/A It may or may not exist at the zone server, but either
0N/A hasn't yet been seen at the resolver or was seen but was
0N/A absent from the last DNSKEY RRSet (
e.g., KeyRem event).
0N/AStJohns Standards Track [Page 7]
0N/ARFC 5011 Trust Anchor Update September 2007
0N/A AddPend The key has been seen at the resolver, has its 'SEP' bit
0N/A set, and has been included in a validated DNSKEY RRSet.
0N/A There is a hold-down time for the key before it can be used
0N/A Valid The key has been seen at the resolver and has been included
0N/A in all validated DNSKEY RRSets from the time it was first
0N/A seen through the hold-down time. It is now valid for
0N/A verifying RRSets that arrive after the hold-down time.
0N/A Clarification: The DNSKEY RRSet does not need to be
0N/A continuously present at the resolver (
e.g., its TTL might
0N/A expire). If the RRSet is seen and is validated (
i.e.,
909N/A verifies against an existing trust anchor), this key MUST be
0N/A in the RRSet, otherwise a 'KeyRem' event is triggered.
0N/A Missing This is an abnormal state. The key remains a valid trust-
0N/A point key, but was not seen at the resolver in the last
0N/A validated DNSKEY RRSet. This is an abnormal state because
0N/A the zone operator should be using the REVOKE bit prior to
0N/A Revoked This is the state a key moves to once the resolver sees an
0N/A RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet
0N/A contains this key with its REVOKE bit set to '1'. Once in
0N/A this state, this key MUST permanently be considered invalid
0N/A Removed After a fairly long hold-down time, information about this
0N/A key may be purged from the resolver. A key in the removed
0N/A state MUST NOT be considered a valid trust anchor. (Note:
0N/A this state is more or less equivalent to the "Start" state,
0N/A except that it's bad practice to re-introduce previously
0N/A used keys -- think of this as the holding state for all the
0N/A old keys for which the resolver no longer needs to track
0N/A5. Trust Point Deletion
0N/A A trust point that has all of its trust anchors revoked is considered
0N/A deleted and is treated as if the trust point was never configured.
0N/A If there are no superior configured trust points, data at and below
0N/A the deleted trust point are considered insecure by the resolver. If
0N/A there ARE superior configured trust points, data at and below the
0N/A deleted trust point are evaluated with respect to the superior trust
0N/A Alternately, a trust point that is subordinate to another configured
0N/A trust point MAY be deleted by a resolver after 180 days, where such a
0N/AStJohns Standards Track [Page 8]
0N/ARFC 5011 Trust Anchor Update September 2007
0N/A subordinate trust point validly chains to a superior trust point.
0N/A The decision to delete the subordinate trust anchor is a local
0N/A configuration decision. Once the subordinate trust point is deleted,
0N/A validation of the subordinate zone is dependent on validating the
909N/A chain of trust to the superior trust point.
0N/A6. Scenarios - Informative
0N/A The suggested model for operation is to have one active key and one
909N/A stand-by key at each trust point. The active key will be used to
0N/A sign the DNSKEY RRSet. The stand-by key will not normally sign this
0N/A RRSet, but the resolver will accept it as a trust anchor
if/when it
0N/A sees the signature on the trust point DNSKEY RRSet.
0N/A Since the stand-by key is not in active signing use, the associated
0N/A private key may (and should) be provided with additional protections
0N/A not normally available to a key that must be used frequently (
e.g.,
0N/A locked in a safe, split among many parties, etc). Notionally, the
0N/A stand-by key should be less subject to compromise than an active key,
0N/A but that will be dependent on operational concerns not addressed
0N/A6.1. Adding a Trust Anchor
0N/A Assume an existing trust anchor key 'A'.
0N/A 1. Generate a new key pair.
0N/A 2. Create a DNSKEY record from the key pair and set the SEP and Zone
0N/A 3. Add the DNSKEY to the RRSet.
0N/A 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
0N/A 5. Wait for various resolvers' timers to go off and for them to
0N/A retrieve the new DNSKEY RRSet and signatures.
0N/A 6. The new trust anchor will be populated at the resolvers on the
0N/A schedule described by the state table and update algorithm -- see
0N/A Sections 2 and 4 above.
0N/A6.2. Deleting a Trust Anchor
0N/A Assume existing trust anchors 'A' and 'B' and that you want to revoke
0N/AStJohns Standards Track [Page 9]
0N/ARFC 5011 Trust Anchor Update September 2007
0N/A 1. Set the revocation bit on key 'A'.
0N/A 2. Sign the DNSKEY RRSet with both 'A' and 'B'. 'A' is now revoked.
0N/A The operator should include the revoked 'A' in the RRSet for at
0N/A least the remove hold-down time, but then may remove it from the
0N/A Assume existing keys A and B. 'A' is actively in use (
i.e. has been
0N/A signing the DNSKEY RRSet). 'B' was the stand-by key. (
i.e. has been
0N/A in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
0N/A used to sign the RRSet).
0N/A 1. Generate a new key pair 'C'.
0N/A 2. Add 'C' to the DNSKEY RRSet.
0N/A 3. Set the revocation bit on key 'A'.
0N/A 4. Sign the RRSet with 'A' and 'B'.
0N/A 'A' is now revoked, 'B' is now the active key, and 'C' will be the
0N/A stand-by key once the hold-down expires. The operator should include
0N/A the revoked 'A' in the RRSet for at least the remove hold-down time,
0N/A but may then remove it from the DNSKEY RRSet.
0N/A6.4. Active Key Compromised
0N/A This is the same as the mechanism for Key Roll-Over (Section 6.3)
0N/A above, assuming 'A' is the active key.
0N/A6.5. Stand-by Key Compromised
0N/A Using the same assumptions and naming conventions as Key Roll-Over
0N/A (Section 6.3) above:
0N/A 1. Generate a new key pair 'C'.
0N/A 2. Add 'C' to the DNSKEY RRSet.
0N/A 3. Set the revocation bit on key 'B'.
0N/A 4. Sign the RRSet with 'A' and 'B'.
0N/A 'B' is now revoked, 'A' remains the active key, and 'C' will be the
0N/A stand-by key once the hold-down expires. 'B' should continue to be
0N/A included in the RRSet for the remove hold-down time.
0N/A6.6. Trust Point Deletion
0N/A To delete a trust point that is subordinate to another configured
0N/A data. The specific process is:
0N/AStJohns Standards Track [Page 10]
0N/ARFC 5011 Trust Anchor Update September 2007
0N/A 1. Generate a new DNSKEY and DS record and provide the DS record to
0N/A the parent along with DS records for the old keys.
0N/A 2. Once the parent has published the DSs, add the new DNSKEY to the
0N/A RRSet and revoke ALL of the old keys at the same time, while
0N/A signing the DNSKEY RRSet with all of the old and new keys.
0N/A 3. After 30 days, stop publishing the old, revoked keys and remove
0N/A any corresponding DS records in the parent.
0N/A Revoking the old trust-point keys at the same time as adding new keys
0N/A that chain to a superior trust prevents the resolver from adding the
0N/A new keys as trust anchors. Adding DS records for the old keys avoids
0N/A a race condition where either the subordinate zone becomes unsecure
0N/A (because the trust point was deleted) or becomes bogus (because it
0N/A didn't chain to the superior zone).
0N/A7. IANA Considerations
0N/A The IANA has assigned a bit in the DNSKEY flags field (see Section 7
0N/A of [RFC4034]) for the REVOKE bit (8).
112N/A8. Security Considerations
0N/A In addition to the following sections, see also Theory of Operation
0N/A above (Section 2) and especially Section 2.2 for related discussions.
0N/A Security considerations for trust anchor rollover not specific to
0N/A this protocol are discussed in [RFC4986].
0N/A8.1. Key Ownership vs. Acceptance Policy
0N/A The reader should note that, while the zone owner is responsible for
0N/A creating and distributing keys, it's wholly the decision of the
0N/A resolver owner as to whether to accept such keys for the
0N/A authentication of the zone information. This implies the decision to
0N/A update trust-anchor keys based on trusting a current trust-anchor key
0N/A is also the resolver owner's decision.
0N/A The resolver owner (and resolver implementers) MAY choose to permit
0N/A or prevent key status updates based on this mechanism for specific
0N/A trust points. If they choose to prevent the automated updates, they
0N/A will need to establish a mechanism for manual or other out-of-band
0N/A updates, which are outside the scope of this document.
0N/AStJohns Standards Track [Page 11]
0N/ARFC 5011 Trust Anchor Update September 2007
0N/A8.2. Multiple Key Compromise
0N/A This scheme permits recovery as long as at least one valid trust-
0N/A anchor key remains uncompromised,
e.g., if there are three keys, you
0N/A can recover if two of them are compromised. The zone owner should
0N/A determine their own level of comfort with respect to the number of
0N/A active, valid trust anchors in a zone and should be prepared to
0N/A implement recovery procedures once they detect a compromise. A
0N/A manual or other out-of-band update of all resolvers will be required
0N/A if all trust-anchor keys at a trust point are compromised.
0N/A Allowing a resolver to update its trust anchor set based on in-band
0N/A key information is potentially less secure than a manual process.
0N/A However, given the nature of the DNS, the number of resolvers that
0N/A would require update if a trust anchor key were compromised, and the
0N/A lack of a standard management framework for DNS, this approach is no
0N/A worse than the existing situation.
0N/A9. Normative References
0N/A [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
0N/A Requirement Levels", BCP 14, RFC 2119, March 1997.
0N/A [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
0N/A Signer (DS)", RFC 3755, May 2004.
0N/A [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
0N/A Rose, "DNS Security Introduction and Requirements", RFC
0N/A [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
0N/A Rose, "Resource Records for the DNS Security Extensions",
0N/A RFC 4034, March 2005.
0N/A [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
0N/A Rose, "Protocol Modifications for the DNS Security
0N/A Extensions", RFC 4035, March 2005.
0N/A10. Informative References
0N/A [RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy,
0N/A "Requirements Related to DNS Security (DNSSEC) Trust
0N/A Anchor Rollover", RFC 4986, August 2007.
0N/AStJohns Standards Track [Page 12]
0N/ARFC 5011 Trust Anchor Update September 2007
0N/A EMail: mstjohns@comcast.net
0N/AStJohns Standards Track [Page 13]
0N/ARFC 5011 Trust Anchor Update September 2007
0N/AFull Copyright Statement
0N/A Copyright (C) The IETF Trust (2007).
0N/A This document is subject to the rights, licenses and restrictions
0N/A contained in BCP 78, and except as set forth therein, the authors
0N/A retain all their rights.
0N/A This document and the information contained herein are provided on an
0N/A "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS
0N/A OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
0N/A THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1045N/A OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1045N/A THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1045N/A WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1045N/A The IETF takes no position regarding the validity or scope of any
1045N/A Intellectual Property Rights or other rights that might be claimed to
0N/A pertain to the implementation or use of the technology described in
1045N/A this document or the extent to which any license under such rights
0N/A might or might not be available; nor does it represent that it has
0N/A made any independent effort to identify any such rights. Information
0N/A on the procedures with respect to rights in RFC documents can be
0N/A found in BCP 78 and BCP 79.
0N/A Copies of IPR disclosures made to the IETF Secretariat and any
0N/A assurances of licenses to be made available, or the result of an
0N/A attempt made to obtain a general license or permission for the use of
0N/A such proprietary rights by implementers or users of this
0N/A specification can be obtained from the IETF on-line IPR repository at
0N/A The IETF invites any interested party to bring to its attention any
0N/A copyrights, patents or patent applications, or other proprietary
0N/A rights that may cover technology that may be required to implement
0N/A this standard. Please address the information to the IETF at
0N/AStJohns Standards Track [Page 14]