draft-ietf-dnsext-dnssec-rsasha256-02.txt | draft-ietf-dnsext-dnssec-rsasha256-03.txt | |||
---|---|---|---|---|

DNS Extensions working group J. Jansen | DNS Extensions working group J. Jansen | |||

Internet-Draft NLnet Labs | Internet-Draft NLnet Labs | |||

Expires: June 13, 2008 December 11, 2007 | Expires: August 19, 2008 February 16, 2008 | |||

Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records | Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records | |||

for DNSSEC | for DNSSEC | |||

draft-ietf-dnsext-dnssec-rsasha256-02 | draft-ietf-dnsext-dnssec-rsasha256-03 | |||

Status of this Memo | Status of this Memo | |||

By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||

applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||

Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||

Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||

skipping to change at page 1, line 34 | skipping to change at page 1, line 34 | |||

and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||

time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||

material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||

The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||

http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||

The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||

http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||

This Internet-Draft will expire on June 13, 2008. | This Internet-Draft will expire on August 19, 2008. | |||

Copyright Notice | Copyright Notice | |||

Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2008). | |||

Abstract | Abstract | |||

This document describes how to produce RSA/SHA-256 and RSA/SHA-512 | This document describes how to produce RSA/SHA-256 and RSA/SHA-512 | |||

DNSKEY and RRSIG resource records for use in the Domain Name System | DNSKEY and RRSIG resource records for use in the Domain Name System | |||

Security Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035). | Security Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035). | |||

Table of Contents | Table of Contents | |||

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||

2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 | 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 | |||

2.1. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . 3 | 2.1. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . 3 | |||

2.2. RSA/SHA-512 DNSKEY Resource Records . . . . . . . . . . . . 3 | 2.2. RSA/SHA-512 DNSKEY Resource Records . . . . . . . . . . . . 3 | |||

3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 | 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 | |||

3.1. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . 4 | 3.1. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . 4 | |||

3.2. RSA/SHA-512 RRSIG Resource Records . . . . . . . . . . . . 4 | 3.2. RSA/SHA-512 RRSIG Resource Records . . . . . . . . . . . . 4 | |||

4. Implementation Considerations . . . . . . . . . . . . . . . . . 5 | 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 | |||

5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 | 4.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||

6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 | 4.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5 | |||

6.1. SHA-1 versus SHA-2 Considerations for RRSIG resource | 5. Implementation Considerations . . . . . . . . . . . . . . . . . 5 | |||

records . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 | |||

6.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 6 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 | |||

7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 | 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource | |||

8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||

8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 | 7.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 6 | |||

8.2. Informative References . . . . . . . . . . . . . . . . . . 7 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||

Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||

Intellectual Property and Copyright Statements . . . . . . . . . . 8 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 | |||

9.2. Informative References . . . . . . . . . . . . . . . . . . 7 | ||||

Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 | ||||

Intellectual Property and Copyright Statements . . . . . . . . . . 9 | ||||

1. Introduction | 1. Introduction | |||

The Domain Name System (DNS) is the global hierarchical distributed | The Domain Name System (DNS) is the global hierarchical distributed | |||

database for Internet Addressing. The DNS has been extended to use | database for Internet Addressing. The DNS has been extended to use | |||

cryptographic keys and digital signatures for the verification of the | cryptographic keys and digital signatures for the verification of the | |||

integrity of its data. RFC4033 [1], RFC4034 [2], and RFC4035 [3] | integrity of its data. RFC4033 [1], RFC4034 [2], and RFC4035 [3] | |||

describe these DNS Security Extensions, called DNSSEC. | describe these DNS Security Extensions, called DNSSEC. | |||

RFC4034 describes how to store DNSKEY and RRSIG resource records, and | RFC 4034 describes how to store DNSKEY and RRSIG resource records, | |||

specifies a list of cryptographic algorithms to use. This document | and specifies a list of cryptographic algorithms to use. This | |||

extends that list with the algorithm RSA/SHA-256 and RSA/SHA-512, and | document extends that list with the algorithms RSA/SHA-256 and RSA/ | |||

specifies how to store DNSKEY data and how to produce RRSIG resource | SHA-512, and specifies how to store DNSKEY data and how to produce | |||

records with these hash algorithms. | RRSIG resource records with these hash algorithms. | |||

Familiarity with DNSSEC, RSA [7] and the SHA-2 [5] family of | Familiarity with DNSSEC, RSA [7] and the SHA-2 [5] family of | |||

algorithms is assumed in this document. | algorithms is assumed in this document. | |||

To refer to both SHA-256 and SHA-512, this document will use the name | To refer to both SHA-256 and SHA-512, this document will use the name | |||

SHA-2. This is done to improve readability. When a part of text is | SHA-2. This is done to improve readability. When a part of text is | |||

specific for either SHA-256 or SHA-512, their specific names are | specific for either SHA-256 or SHA-512, their specific names are | |||

used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be | used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be | |||

grouped using the name RSA/SHA-2. | grouped using the name RSA/SHA-2. | |||

2. DNSKEY Resource Records | 2. DNSKEY Resource Records | |||

The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110 | The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110 | |||

[6]. | [6]. | |||

2.1. RSA/SHA-256 DNSKEY Resource Records | 2.1. RSA/SHA-256 DNSKEY Resource Records | |||

RSA public keys for use with RSA/SHA-256 are stored in DNSKEY | RSA public keys for use with RSA/SHA-256 are stored in DNSKEY | |||

resource records (RRs) with the algorithm number [TBA]. | resource records (RRs) with the algorithm number {TBA1}. | |||

For use with NSEC3, the algorithm number of RSA/SHA-256 will be | For use with NSEC3, the algorithm number of RSA/SHA-256 will be | |||

[TBA]. | {TBA2}. | |||

The key size for RSA/SHA-256 keys MUST NOT be less than 512 bits, and | ||||

MUST NOT be more than 4096 bits. | ||||

2.2. RSA/SHA-512 DNSKEY Resource Records | 2.2. RSA/SHA-512 DNSKEY Resource Records | |||

RSA public keys for use with RSA/SHA-512 are stored in DNSKEY | RSA public keys for use with RSA/SHA-512 are stored in DNSKEY | |||

resource records (RRs) with the algorithm number [TBA]. | resource records (RRs) with the algorithm number {TBA3}. | |||

For use with NSEC3, the algorithm number of RSA/SHA-512 will be | For use with NSEC3, the algorithm number of RSA/SHA-512 will be | |||

[TBA]. | {TBA4}. | |||

The key size for RSA/SHA-512 keys MUST NOT be less than 1024 bits, | ||||

and MUST NOT be more than 4096 bits. | ||||

3. RRSIG Resource Records | 3. RRSIG Resource Records | |||

The value of the signature field in the RRSIG RR is calculated as | The value of the signature field in the RRSIG RR follow the RSASSA- | |||

follows. The values for the fields that precede the signature data | PKCS1-v1_5 signature scheme, and is calculated as follows. The | |||

are specified in RFC4034 [2]. | values for the RDATA fields that precede the signature data are | |||

specified in RFC 4034 [2]. | ||||

hash = SHA-XXX(data) | hash = SHA-XXX(data) | |||

Where XXX is either 256 or 512, depending on the algorithm used. | Where XXX is either 256 or 512, depending on the algorithm used. | |||

signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) | signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) | |||

Where SHA-XXX is the message digest algorithm as specified in FIPS | Where SHA-XXX is the message digest algorithm as specified in FIPS | |||

180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of | PUB 180-2 [5], "|" is concatenation, "00", "01", "FF" and "00" are | |||

corresponding hexadecimal value, "e" is the private exponent of the | fixed octets of corresponding hexadecimal value, "e" is the private | |||

signing RSA key, and "n" is the public modulus of the signing key. | exponent of the signing RSA key, and "n" is the public modulus of the | |||

The FF octet MUST be repeated the maximum number of times so that the | signing key. The FF octet MUST be repeated the maximum number of | |||

total length of the signature equals the length of the modulus of the | times so that the total length of the signature equals the length of | |||

signer's public key ("n"). "data" is the data of the resource record | the modulus of the signer's public key ("n"). "data" is the data of | |||

set that is signed, as specified in RFC4034 [2]. | the resource record set that is signed, as specified in RFC 4034 [2]. | |||

The prefix should make the use of standard cryptographic libraries | The "prefix" is intended to make the use of standard cryptographic | |||

easier. These specifications are taken directly from PKCS #1 v2.1 | libraries easier. These specifications are taken directly from the | |||

section 9.2 [4]. The prefixes for the different algorithms are | specification of EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2 | |||

specified below. | [4]. The prefixes for the different algorithms are specified below. | |||

3.1. RSA/SHA-256 RRSIG Resource Records | 3.1. RSA/SHA-256 RRSIG Resource Records | |||

RSA/SHA-256 signatures are stored in the DNS using RRSIG resource | RSA/SHA-256 signatures are stored in the DNS using RRSIG resource | |||

records (RRs) with algorithm number [TBA]. | records (RRs) with algorithm number {TBA1} for use with NSEC, or | |||

{TBA2} for use with NSEC3. | ||||

The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as | The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as | |||

specified in PKCS 2.1 [4]: | specified in PKCS #1 v2.1 [4]: | |||

hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 | hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 | |||

3.2. RSA/SHA-512 RRSIG Resource Records | 3.2. RSA/SHA-512 RRSIG Resource Records | |||

RSA/SHA-512 signatures are stored in the DNS using RRSIG resource | RSA/SHA-512 signatures are stored in the DNS using RRSIG resource | |||

records (RRs) with algorithm number [TBA]. | records (RRs) with algorithm number {TBA3} for use with NSEC, or | |||

{TBA4} for use with NSEC3. | ||||

The prefix is the ASN.1 BER SHA-512 algorithm designator prefix as | The prefix is the ASN.1 BER SHA-512 algorithm designator prefix as | |||

specified in PKCS 2.1 [4]: | specified in PKCS #1 v2.1 [4]: | |||

hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 | hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 | |||

4. Implementation Considerations | 4. Deployment Considerations | |||

4.1. Key Sizes | ||||

Apart from prohibiting RSA/SHA-512 signatures smaller than 1024 | ||||

bytes, this document will not specify what size of keys to use. That | ||||

is more an operational issue and depends largely on the environment | ||||

and intended use. Some good starting points might be DNSSEC | ||||

Operational Practises [9], section 3.5, and NIST SP 800-57 Part 1 | ||||

[10] and Part 3 [11]. | ||||

4.2. Signature Sizes | ||||

In this family of signing algorithms, the size of signatures is | ||||

related to the size of the key, and not the hashing algorithm used in | ||||

the signing process. Therefore, RRSIG resource records produced with | ||||

RSA/SHA256 or RSA/SHA512 shall have the same size as those produced | ||||

with RSA/SHA1, if the keys have the same length. | ||||

5. Implementation Considerations | ||||

DNSSEC aware implementations SHOULD be able to support RRSIG resource | DNSSEC aware implementations SHOULD be able to support RRSIG resource | |||

records with the RSA/SHA-2 algorithms. | records with the RSA/SHA-2 algorithms. | |||

If both RSA/SHA-2 and RSA/SHA-1 RRSIG resource records are available | If both RSA/SHA-2 and RSA/SHA-1 RRSIG resource records are available | |||

for a certain rrset, with a secure path to their keys, the validator | for a certain RRset, with a secure path to their keys, the validator | |||

SHOULD ignore the SHA-1 signature. If the RSA/SHA-2 signature does | SHOULD ignore the SHA-1 signature. If the RSA/SHA-2 signature does | |||

not verify the data, and the RSA/SHA-1 signature does, the validator | not verify the data, and the RSA/SHA-1 signature does, the validator | |||

SHOULD mark the data with the security status from the RSA/SHA-2 | SHOULD mark the data with the security status from the RSA/SHA-2 | |||

signature. | signature. | |||

5. IANA Considerations | 6. IANA Considerations | |||

IANA has not yet assigned an algorithm number for RSA/SHA-256 and | IANA has not yet assigned an algorithm number for RSA/SHA-256 and | |||

RSA/SHA-512. | RSA/SHA-512. | |||

The algorithm list from RFC4034 Appendix A.1 [2] is extended with the | The algorithm list from RFC 4034 Appendix A.1 [2] is extended with | |||

following entries: | the following entries: | |||

Zone | Zone | |||

Value Algorithm [Mnemonic] Signing References Status | Value Algorithm [Mnemonic] Signing References Status | |||

----- ----------- ----------- ------- ---------- -------- | ----- ----------- ----------- ------- ----------- -------- | |||

[TBA] RSA/SHA-256 [RSASHA256] y [TBA] OPTIONAL | {TBA1} RSA/SHA-256 RSASHA256 y {this memo} OPTIONAL | |||

[TBA] RSA/SHA-256-NSEC3 [RSASHA256NSEC3] y [TBA] OPTIONAL | {TBA2} RSA/SHA-256-NSEC3 RSASHA256NSEC3 y {this memo} OPTIONAL | |||

[TBA] RSA/SHA-512 [RSASHA512] y [TBA] OPTIONAL | {TBA3} RSA/SHA-512 RSASHA512 y {this memo} OPTIONAL | |||

[TBA] RSA/SHA-512-NSEC3 [RSASHA512NSEC3] y [TBA] OPTIONAL | {TBA4} RSA/SHA-512-NSEC3 RSASHA512NSEC3 y {this memo} OPTIONAL | |||

6. Security Considerations | 7. Security Considerations | |||

6.1. SHA-1 versus SHA-2 Considerations for RRSIG resource records | 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records | |||

Users of DNSSEC are encouraged to deploy SHA-2 as soon as software | Users of DNSSEC are encouraged to deploy SHA-2 as soon as software | |||

implementations allow for it. SHA-2 is widely believed to be more | implementations allow for it. SHA-2 is widely believed to be more | |||

resilient to attack than SHA-1, and confidence in SHA-1's strength is | resilient to attack than SHA-1, and confidence in SHA-1's strength is | |||

being eroded by recently-announced attacks. Regardless of whether or | being eroded by recently-announced attacks. Regardless of whether or | |||

not the attacks on SHA-1 will affect DNSSEC, it is believed (at the | not the attacks on SHA-1 will affect DNSSEC, it is believed (at the | |||

time of this writing) that SHA-2 is the better choice for use in | time of this writing) that SHA-2 is the better choice for use in | |||

DNSSEC records. | DNSSEC records. | |||

SHA-2 is considered sufficiently strong for the immediate future, but | SHA-2 is considered sufficiently strong for the immediate future, but | |||

predictions about future development in cryptography and | predictions about future development in cryptography and | |||

cryptanalysis are beyond the scope of this document. | cryptanalysis are beyond the scope of this document. | |||

6.2. Signature Type Downgrade Attacks | The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one | |||

used for RSA/SHA-1 signatures. This should ease implementation of | ||||

the new hashing algorithms in DNSSEC software. | ||||

7.2. Signature Type Downgrade Attacks | ||||

Since each RRset MUST be signed with each algorithm present in the | Since each RRset MUST be signed with each algorithm present in the | |||

DNSKEY RRset at the zone apex (see [3] Section 2.2), a malicious | DNSKEY RRset at the zone apex (see [3] Section 2.2), a malicious | |||

party cannot filter out the RSA/SHA-2 RRSIG, and force the validator | party cannot filter out the RSA/SHA-2 RRSIG, and force the validator | |||

to use the RSA/SHA-1 signature if both are present in the zone. | to use the RSA/SHA-1 signature if both are present in the zone. | |||

Together with the implementation considerations from Section 4 of | Together with the implementation considerations from Section 5 of | |||

this document, this provides resilience against algorithm downgrade | this document, this provides resilience against algorithm downgrade | |||

attacks, if the validator supports RSA/SHA-2. | attacks, if the validator supports RSA/SHA-2. | |||

7. Acknowledgments | 8. Acknowledgments | |||

This document is a minor extension to RFC4034 [2]. Also, we try to | This document is a minor extension to RFC4034 [2]. Also, we try to | |||

follow the documents RFC3110 [6] and RFC4509 [8] for consistency. | follow the documents RFC3110 [6] and RFC4509 [8] for consistency. | |||

The authors of and contributors to these documents are gratefully | The authors of and contributors to these documents are gratefully | |||

acknowledged for their hard work. | acknowledged for their hard work. | |||

The following people provided additional feedback and text: Jaap | The following people provided additional feedback and text: Jaap | |||

Akkerhuis, Rob Austein, Miek Gieben, Scott Rose and Wouter | Akkerhuis, Roy Arends, Rob Austein, Miek Gieben, Alfred Hoenes, | |||

Wijngaards. | Michael St. Johns, Scott Rose and Wouter Wijngaards. | |||

8. References | 9. References | |||

8.1. Normative References | 9.1. Normative References | |||

[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | |||

"DNS Security Introduction and Requirements", RFC 4033, | "DNS Security Introduction and Requirements", RFC 4033, | |||

March 2005. | March 2005. | |||

[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | |||

"Resource Records for the DNS Security Extensions", RFC 4034, | "Resource Records for the DNS Security Extensions", RFC 4034, | |||

March 2005. | March 2005. | |||

[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | |||

skipping to change at page 7, line 5 | skipping to change at page 7, line 33 | |||

[4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards | [4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards | |||

(PKCS) #1: RSA Cryptography Specifications Version 2.1", | (PKCS) #1: RSA Cryptography Specifications Version 2.1", | |||

RFC 3447, February 2003. | RFC 3447, February 2003. | |||

[5] National Institute of Standards and Technology, "Secure Hash | [5] National Institute of Standards and Technology, "Secure Hash | |||

Standard", FIPS PUB 180-2, August 2002. | Standard", FIPS PUB 180-2, August 2002. | |||

[6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name | [6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name | |||

System (DNS)", RFC 3110, May 2001. | System (DNS)", RFC 3110, May 2001. | |||

8.2. Informative References | 9.2. Informative References | |||

[7] Schneier, B., "Applied Cryptography Second Edition: protocols, | [7] Schneier, B., "Applied Cryptography Second Edition: protocols, | |||

algorithms, and source code in C", Wiley and Sons , ISBN 0-471- | algorithms, and source code in C", Wiley and Sons , ISBN 0-471- | |||

11709-9, 1996. | 11709-9, 1996. | |||

[8] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) | [8] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) | |||

Resource Records (RRs)", RFC 4509, May 2006. | Resource Records (RRs)", RFC 4509, May 2006. | |||

[9] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", | ||||

RFC 4641, September 2006. | ||||

[10] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, | ||||

"Recommendations for Key Management Part 1: General", NIST | ||||

SP 800-57 Part 1, March 2007. | ||||

[11] Barker, E., Barker, W., Burr, W., Jones, A., Polk, W., Smid, | ||||

M., and S. Rose, "Recommendations for Key Management Part 3: | ||||

Application-Specific Key Guidance", NIST SP 800-57 Part 3, | ||||

March 2007. | ||||

Author's Address | Author's Address | |||

Jelte Jansen | Jelte Jansen | |||

NLnet Labs | NLnet Labs | |||

Kruislaan 419 | Kruislaan 419 | |||

Amsterdam 1098VA | Amsterdam 1098VA | |||

NL | NL | |||

Email: jelte@NLnetLabs.nl | Email: jelte@NLnetLabs.nl | |||

URI: http://www.nlnetlabs.nl/ | URI: http://www.nlnetlabs.nl/ | |||

Full Copyright Statement | Full Copyright Statement | |||

Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2008). | |||

This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||

contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||

retain all their rights. | retain all their rights. | |||

This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||

"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||

OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | |||

THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | |||

OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |||

End of changes. 33 change blocks. | ||||

64 lines changed or deleted | | 112 lines changed or added | ||

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |