Skip to main content

Limiting the Scope of the KEY Resource Record (RR)
RFC 3445

Revision differences

Document history

Date Rev. By Action
2020-01-21
04 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
04 (System) Notify list changed from <ogud@ogud.com>, <okolkman@ripe.net> to <okolkman@ripe.net>
2003-01-06
04 (System) Ballot writeup text was added
2003-01-06
04 (System) Last call text was added
2003-01-06
04 (System) Ballot approval text was added
2003-01-06
04 Thomas Narten RFC 3445 appears
2003-01-06
04 Thomas Narten State Changes to RFC Published from RFC Ed Queue by Narten, Thomas
2002-12-18
04 (System) RFC published
2002-09-18
04 Stephen Coya responsible has been changed to RFC Editor from Working Group
2002-09-18
04 Stephen Coya State Changes to Approved - Info sent from Approved by scoya
2002-09-18
04 Stephen Coya Due date has been changed to 2002-09-12 from 2002-08-22<br>by scoya
2002-09-18
04 Stephen Coya State Changes to Approved from Evaluation: Discuss by scoya
2002-09-12
04 (System) IESG has approved the document
2002-09-11
04 (System) New version available: draft-ietf-dnsext-restrict-key-for-dnssec-04.txt
2002-09-05
04 Erik Nordmark
Sent comments to WG:<br><br><br>This document was discussed by the IESG today.<br>Here are the comments:<br><br><br>Section 2.1 describes some of the differences between Application Keys<br>and DNSSEC Keys. …
Sent comments to WG:<br><br><br>This document was discussed by the IESG today.<br>Here are the comments:<br><br><br>Section 2.1 describes some of the differences between Application Keys<br>and DNSSEC Keys. However, some of the text (e.g., reasons 3 and<br>onward) use upper case MUST/SHOULD language in a confusing way. I<br>suspect the intent is to describe what the existing RFCs require from<br>these Keys, but it would be better to not use that terminology at all<br>here (since Application keys are being deprecated, it seems odd for<br>this document to be saying what one SHOULD do when processing them)<br>and just describe what the differences are in a more reader-friendly<br>way. For example:<br><br> 3. DNSSEC zone keys are used to authenticate application keys, but<br> application keys MUST NOT be used to authenticate DNS zone keys. A<br> DNS zone key is either configured as trusted key or authenticated by<br> constructing a chain of trust in the DNS hierarchy. To participate<br> in the chain of trust, a DNS zone needs to exchange zone key<br> information with its parent zone [2]. Application keys are not<br> configured as trusted keys in the DNS and are never part of any DNS<br> chain of trust. Application key data SHOULD not be exchanged with<br> the parent zone. A resolver considers an application key<br> authenticated if it has a valid signature from the local DNS zone<br> keys, but applications could impose additional requirements before<br> the application key is accepted as authentic.<br><br>might be better as:<br><br> 3. DNSSEC zone keys are used to authenticate application keys, but<br> by definition application keys are not allowed to authenticate DNS<br> zone keys. A DNS zone key is either configured as a trusted key or<br> authenticated by constructing a chain of trust in the DNS<br> hierarchy. To participate in the chain of trust, a DNS zone needs<br> to exchange zone key information with its parent zone [2]. In<br> contrast, Application keys are not configured as trusted keys in<br> the DNS and are never part of any DNS chain of trust. Application<br> key data is not generally exchanged with the parent zone. A<br> resolver considers an Application key authenticated if it has a<br> valid signature from the local DNS zone keys. However, applications<br> will likely impose additional requirements (outside the scope of<br> DNSSEC checks) before accepting the application key as authentic.<br><br>Sections 4-6 would benefit from similar changes.<br><br>Nits:<br><br>The document sometimes capitalizes "Application key" and<br>sometimes doesn't. Be consistent? (And shouldn't it then be<br>"Application Key".)<br><br>uses "isi.edu" rather than "example.com". I don't have a big problem<br>with this, but should they switch?<br><br>> with a response that contain the www.isi.edu A record and SIG record.<br>s/contain/contains/<br><br>> the SIG and authenticate the www.isi.edu A record. It is typical not<br><br>s/typical/typically/<br><br> record. Note that by placing application keys in the KEY record, a<br> resolver will need the IPSEC, email, TLS, and other key associated<br> with isi.edu if the resolver intends to authenticate the isi.edu zone<br> key (since signatures only apply to the entire KEY RR set).<br><br>s/will/would/? I.e., this document is deprecated application keys, so<br>this should not be "will" it seems.<br><br> Erik<br><br>
2002-09-05
04 Erik Nordmark responsible has been changed to Working Group from Area Directors
2002-08-27
04 Stephen Coya Due date has been changed to 2002-08-22 from 2002-07-30<br>by scoya
2002-08-27
04 Stephen Coya State Changes to Evaluation: Discuss from Ready for Telechat by scoya
2002-08-08
04 Stephen Coya
State Changes to Ready for Telechat                                from Wait for Writeup  …
State Changes to Ready for Telechat                                from Wait for Writeup                                  by scoya
2002-07-30
04 Stephen Coya
State Changes to Wait for Writeup                                  from Last Call …
State Changes to Wait for Writeup                                  from Last Call Issued                                  by scoya
2002-07-02
04 Jacqueline Hargest responsible has been changed to Area Directors from IETF Secretary
2002-07-02
04 Jacqueline Hargest
State Changes to Last Call Issued                                  from Last Call …
State Changes to Last Call Issued                                  from Last Call Requested                              by jhargest
2002-07-02
04 Erik Nordmark responsible has been changed to IETF Secretary from Working Group
2002-07-02
04 Erik Nordmark
State Changes to Last Call Requested                              from AD Evaluation      …
State Changes to Last Call Requested                              from AD Evaluation                                    by nordmark
2002-07-02
04 (System) Last call sent
2002-07-01
03 (System) New version available: draft-ietf-dnsext-restrict-key-for-dnssec-03.txt
2002-06-05
04 Erik Nordmark Pinged WG about an updated I-D with the issue about "ignore non-DNSsec keys" clarified.
2002-06-05
04 Erik Nordmark A new comment added<br>by nordmark
2002-05-07
04 Erik Nordmark Sent AD review comments to mailing list.<br>
2002-05-07
04 Erik Nordmark responsible has been changed to Working Group from IESG member
2002-05-06
04 Erik Nordmark responsible has been changed to IESG member from Area Directors
2002-05-06
04 Erik Nordmark Intended Status has been changed to Proposed Standard from Request
2002-03-28
04 Erik Nordmark Draft Added by Erik Nordmark
2002-03-27
02 (System) New version available: draft-ietf-dnsext-restrict-key-for-dnssec-02.txt
2002-01-23
01 (System) New version available: draft-ietf-dnsext-restrict-key-for-dnssec-01.txt
2001-11-06
00 (System) New version available: draft-ietf-dnsext-restrict-key-for-dnssec-00.txt