diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-00.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-00.txt
new file mode 100644
index 0000000000..e8fb4665a4
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-00.txt
@@ -0,0 +1,336 @@
+
+
+DNS Extentions                                                O. Kolkman
+Internet-Draft                                                  RIPE NCC
+Expires: March 4, 2003                                 September 3, 2002
+
+
+                      KEY RR Key Signing (KS) Flag
+            draft-ietf-dnsext-keyrr-key-signing-flag-00.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   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 March 4, 2003.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   The Introduction of the DS [1] record has introduced the concept of
+   KEY signing and zone signing keys.  In general, KEY signing keys are
+   the keys that are pointed to by DS records and are the secure entry
+   points to a zone.  The key signing keys only sign the KEY RRset at
+   the apex of a zone, zone signing keys sign all data in a zone.  We
+   propose a flag to distinguish the KEY signing key from other keys in
+   the KEY RR set during DNSSEC operations.
+
+   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
+   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
+   interpreted as described in RFC2119.
+
+
+
+
+Kolkman                  Expires March 4, 2003                  [Page 1]
+
+Internet-Draft        KEY RR Key Signing (KS) Flag        September 2002
+
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2. The Key Signing flag . . . . . . . . . . . . . . . . . . . . . . 3
+   3. DNSSEC Protocol changes  . . . . . . . . . . . . . . . . . . . . 3
+   4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 4
+   5. Security considerations  . . . . . . . . . . . . . . . . . . . . 4
+   6. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 4
+      References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
+      Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman                  Expires March 4, 2003                  [Page 2]
+
+Internet-Draft        KEY RR Key Signing (KS) Flag        September 2002
+
+
+1. Introduction
+
+   The Introduction of the DS record has introduced the concept of KEY
+   signing keys.  In general these are the keys that are pointed to by
+   DS records and are the secure entry points to a zone.  These key
+   signing keys may also be configured in resolver systems that use
+   zones as a root for a secure island.
+
+   Early deployment tests have shown that during DNSSEC parent-child
+   interactions it is useful to indicate which keys are to be used as
+   the secure entry point to a zone.  We introduce the Key Signing Key
+   flag to indicate this special 'administrative' status of the key.
+
+   During DNSSEC parent-child interactions it is useful to indicate
+   which keys are to be used as the secure entry point to a zone.
+   During key rollovers the KS-flag can be used by the parent to
+   determine from which key the DS RR is to be generated from.
+
+2. The Key Signing flag
+
+
+                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              flags          |K|   protocol    |   algorithm   |
+      |                             |S|               |               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               /
+      /                        public key                             /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                                KEY RR Format
+
+
+
+   The bit 15th bit (TBD) in the flags field is assigned to be the key
+   signing flag.  If set the key is intended to be used as key signing
+   key.  If the bit is not set then no special meaning should be
+   assigned.  The 15th bit is currently reserved [2].
+
+3. DNSSEC Protocol changes
+
+   The use of the KS flag does NOT change the DNS resolution and
+   resolution protocol.  The KS flag is only used to provide a hint
+   about the different administrative properties and MUST NOT be used
+   during the resolving process.
+
+
+
+
+Kolkman                  Expires March 4, 2003                  [Page 3]
+
+Internet-Draft        KEY RR Key Signing (KS) Flag        September 2002
+
+
+4. Operational Guidelines
+
+   By setting the KS-flag on a particular key, zone administrators
+   indicate that that key should be used as the secure entry point for
+   their zone.  Therefore zone administrators SHOULD set the bit only
+   for zone keys that are used to sign the KEY RRset and are intended to
+   act as the top of the chain of trust for their zone.
+
+   Parent zone administrators and resolver administrators MAY choose to
+   ignore the flag.
+
+   Even with the KS-flag there is no mechanism to distinguish between
+   keys that should be used by the parent to point DS records to or keys
+   to be used by resolver administrators as statically configured keys.
+
+   If the bit is modified during the lifetime of the key then this would
+   have impact on the keytag and on the hash data in the DS RRs
+   intending to point to this key.  The bit SHOULD NOT be modified once
+   the key has been put into use.
+
+5. Security considerations
+
+   The flag MUST NOT be used in the resolution protocol or to determine
+   the security status of a key.  The flag is to be used for
+   administrative purposes only.
+
+   If the flag is used to determine which key is to be used as the
+   secure entry point then the trust in the key should be inferred from
+   an existing DNS chain of trust or by an out of band key exchange.
+
+6. Acknowledgments
+
+   The ideas documented in this draft are inspired by communications we
+   had with numerous people and ideas published by other folk, Jakob
+   Schlyter and Olafur Gudmundsson and Dan Massey have been most
+   substantial in providing ideas and feedback.
+
+   This document saw the light during a workshop on DNSSEC operations
+   hosted by USC/ISI.
+
+   "Animal Farm; a Fairy Story" was first published by George Orwell in
+   1945, The version illustrated by Ralph Steadman is one we recommend (
+   ISBN: 0151002177 ).
+
+References
+
+   [1]   Gudmundsson, "Delegation Signer Resource Record", work in
+        progress draft-ietf-dnsext-delegation-signer-08.txt, June 2002.
+
+
+
+Kolkman                  Expires March 4, 2003                  [Page 4]
+
+Internet-Draft        KEY RR Key Signing (KS) Flag        September 2002
+
+
+   [2]  Massey and Rose, "Limiting the Scope of the KEY Resource
+        Record", work in progress draft-ietf-dnsext-restrict-key-for-
+        dnssec-03, June 28 2002.
+
+
+Author's Address
+
+   Olaf M. Kolkman
+   RIPE NCC
+   Singel 256
+   Amsterdam  1016 AB
+   NL
+
+   Phone: +31 20 535 4444
+   EMail: olaf@ripe.net
+   URI:   http://www.ripe.net/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman                  Expires March 4, 2003                  [Page 5]
+
+Internet-Draft        KEY RR Key Signing (KS) Flag        September 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman                  Expires March 4, 2003                  [Page 6]
+