doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc2792.txt b/doc/rfc/rfc2792.txt
new file mode 100644
index 0000000..0b805c9
--- /dev/null
+++ b/doc/rfc/rfc2792.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                           M. Blaze
+Request for Comments: 2792                                  J. Ioannidis
+Category: Informational                             AT&T Labs - Research
+                                                            A. Keromytis
+                                                      U. of Pennsylvania
+                                                              March 2000
+
+
+             DSA and RSA Key and Signature Encoding for the
+                    KeyNote Trust Management System
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This memo describes RSA and DSA key and signature encoding, and
+   binary key encoding for version 2 of the KeyNote trust-management
+   system.
+
+1.  Introduction
+
+   KeyNote is a simple and flexible trust-management system designed to
+   work well for a variety of large- and small-scale Internet-based
+   applications.  It provides a single, unified language for both local
+   policies and credentials.  KeyNote policies and credentials, called
+   `assertions', contain predicates that describe the trusted actions
+   permitted by the holders of specific public keys.  KeyNote assertions
+   are essentially small, highly-structured programs.  A signed
+   assertion, which can be sent over an untrusted network, is also
+   called a `credential assertion'.  Credential assertions, which also
+   serve the role of certificates, have the same syntax as policy
+   assertions but are also signed by the principal delegating the trust.
+   For more details on KeyNote, see [BFIK99].  This document assumes
+   reader familiarity with the KeyNote system.
+
+   Cryptographic keys may be used in KeyNote to identify principals.  To
+   facilitate interoperation between different implementations and to
+   allow for maximal flexibility, keys must be converted to a normalized
+   canonical form (depended on the public key algorithm used) for the
+   purposes of any internal comparisons between keys.  For example, an
+
+
+
+Blaze, et al.                Informational                      [Page 1]
+
+RFC 2792         Key and Signature Encoding for KeyNote       March 2000
+
+
+   RSA [RSA78] key may be encoded in base64 ASCII in one credential, and
+   in hexadecimal ASCII in another.  A KeyNote implementation must
+   internally convert the two encodings to a normalized form that allows
+   for comparison between them.  Furthermore, the internal structure of
+   an encoded key must be known for an implementation to correctly
+   decode it.
+
+   In some applications, other types of values, such as a passphrase or
+   a random nonce, may be used as principal identifiers.  When these
+   identifiers contain characters that may not appear in a string (as
+   defined in [BFIK99]), a simple ASCII encoding is necessary to allow
+   their use inside KeyNote assertions.  Note that if the identifier
+   only contains characters that can appear in a string, it may be used
+   as-is.  Naturally, such identifiers may not be used to sign an
+   assertion, and thus no related signature encoding is defined.
+
+   This document specifies RSA and DSA [DSA94] key and signature
+   encodings, and binary key encodings for use in KeyNote.
+
+2.  Key Normalized Forms
+
+2.1  DSA Key Normalized Form
+
+   DSA keys in KeyNote are identified by four values:
+
+   - the public value, y
+   - the p parameter
+   - the q parameter
+   - the g parameter
+
+   Where the y, p, q, and g are the DSA parameters corresponding to the
+   notation of [Sch96]. These four values together make up the DSA key
+   normalized form used in KeyNote.  All DSA key comparisons in KeyNote
+   occur between normalized forms.
+
+2.2  RSA Key Normalized Form
+
+   RSA keys in KeyNote are identified by two values:
+
+   - the public exponent
+   - the modulus
+
+   These two values together make up the RSA key normalized form used in
+   KeyNote.  All RSA key comparisons in KeyNote occur between normalized
+   forms.
+
+
+
+
+
+
+Blaze, et al.                Informational                      [Page 2]
+
+RFC 2792         Key and Signature Encoding for KeyNote       March 2000
+
+
+2.3  Binary Identifier Normalized Form
+
+   The normalized form of a Binary Identifier is the binary identifier's
+   data.  Thus, Binary Identifier comparisons are essentially binary-
+   string comparisons of the Identifier values.
+
+3.  Key Encoding
+
+3.1  DSA Key Encoding
+
+   DSA keys in KeyNote are encoded as an ASN1 SEQUENCE of four ASN1
+   INTEGER objects.  The four INTEGER objects are the public value and
+   the p, q, and g parameters of the DSA key, in that order.
+
+   For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-
+   encoded (e.g., as a string of hex digits or base64 characters).
+
+   DSA keys encoded in this way in KeyNote must be identified by the
+   "dsa-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" or
+   "base64").  Other ASCII encoding schemes may be defined in the
+   future.
+
+3.2  RSA Key Encoding
+
+   RSA keys in KeyNote are encoded as an ASN1 SEQUENCE of two ASN1
+   INTEGER objects.  The two INTEGER objects are the public exponent and
+   the modulus of the DSA key, in that order.
+
+   For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-
+   encoded (e.g., as a string of hex digits or base64 characters).
+
+   RSA keys encoded in this way in KeyNote must be identified by the
+   "rsa-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" or
+   "base64").  Other ASCII encoding schemes may be defined in the
+   future.
+
+3.3  Binary Identifier Encoding
+
+   Binary Identifiers in KeyNote are assumed to have no internal
+   encoding, and are treated as a sequence of binary digits.  The Binary
+   Identifiers are ASCII-encoded, similarly to RSA or DSA keys.
+
+   Binary Identifiers encoded in this way in KeyNote must be identified
+   by the "binary-XXX:" algorithm name, where XXX is an ASCII encoding
+   ("hex" or "base64").  Other ASCII encoding schemes may be defined in
+   the future.
+
+
+
+
+
+Blaze, et al.                Informational                      [Page 3]
+
+RFC 2792         Key and Signature Encoding for KeyNote       March 2000
+
+
+4.  Signature Computation and Encoding
+
+4.1  DSA Signature Computation and Encoding
+
+   DSA signatures in KeyNote are computed over the assertion body
+   (starting from the beginning of the first keyword, up to and
+   including the newline character immediately before the "Signature:"
+   keyword) and the signature algorithm name (including the trailing
+   colon character, e.g., "sig-dsa-sha1-base64:")
+
+   DSA signatures are then encoded as an ASN1 SEQUENCE of two ASN1
+   INTEGER objects.  The two INTEGER objects are the r and s values of a
+   DSA signature [Sch96], in that order.
+
+   For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-
+   encoded (as a string of hex digits or base64 characters).
+
+   DSA signatures encoded in this way in KeyNote must be identified by
+   the "sig-dsa-XXX-YYY:" algorithm name, where XXX is a hash function
+   name ("sha1", for the SHA1 [SHA1-95] hash function is currently the
+   only hash function that may be used with DSA) and YYY is an ASCII
+   encoding ("hex" or "base64").
+
+4.2  RSA Signature Computation and Encoding
+
+   RSA signatures in KeyNote are computed over the assertion body
+   (starting from the beginning of the first keyword, up to and
+   including the newline character immediately before the "Signature:"
+   keyword) and the signature algorithm name (including the trailing
+   colon character, e.g., "sig-rsa-sha1-base64:")
+
+   RSA signatures are then encoded as an ASN1 OCTET STRING object,
+   containing the signature value.
+
+   For use in KeyNote credentials, the ASN1 OCTET STRING is then ASCII-
+   encoded (as a string of hex digits or base64 characters).
+
+   RSA signatures encoded in this way in KeyNote must be identified by
+   the "sig-rsa-XXX-YYY:" algorithm name, where XXX is a hash function
+   name ("md5" or "sha1", for the MD5 [Riv92] and SHA1 [SHA1-95] hash
+   algorithms respectively, may be used with RSA) and YYY is an ASCII
+   encoding ("hex" or "base64").
+
+4.3  Binary Signature Computation and Encoding
+
+   Binary Identifiers are unstructured sequences of binary digits, and
+   are not associated with any cryptographic algorithm.  Thus, they may
+   not be used to validate an assertion.
+
+
+
+Blaze, et al.                Informational                      [Page 4]
+
+RFC 2792         Key and Signature Encoding for KeyNote       March 2000
+
+
+5.  Security Considerations
+
+   This document discusses the format of RSA and DSA keys and signatures
+   and of Binary principal identifiers as used in KeyNote.  The security
+   of KeyNote credentials utilizing such keys and credentials is
+   directly dependent on the strength of the related public key
+   algorithms.  On the security of KeyNote itself, see [BFIK99].
+
+6.  IANA Considerations
+
+   Per [BFIK99], IANA should provide a registry of reserved algorithm
+   identifiers.  The following identifiers are reserved by this document
+   as public key and binary identifier encodings:
+
+   - "rsa-hex"
+   - "rsa-base64"
+   - "dsa-hex"
+   - "dsa-base64"
+   - "binary-hex"
+   - "binary-base64"
+
+   The following identifiers are reserved by this document as signature
+   encodings:
+
+   - "sig-rsa-md5-hex"
+   - "sig-rsa-md5-base64"
+   - "sig-rsa-sha1-hex"
+   - "sig-rsa-sha1-base64"
+   - "sig-dsa-sha1-hex"
+   - "sig-dsa-sha1-base64"
+
+   Note that the double quotes are not part of the algorithm
+   identifiers.
+
+7.  Acknowledgments
+
+   This work was sponsored by the DARPA Information Assurance and
+   Survivability (IA&S) program, under BAA 98-34.
+
+References
+
+   [Sch96]   Bruce Schneier, Applied Cryptography 2nd Edition, John
+             Wiley & Sons, New York, NY, 1996.
+
+   [BFIK99]  Blaze, M., Feigenbaum, J., Ioannidis, J. and A. Keromytis,
+             "The KeyNote Trust-Management System Version 2", RFC 2704,
+             September 1999.
+
+
+
+
+Blaze, et al.                Informational                      [Page 5]
+
+RFC 2792         Key and Signature Encoding for KeyNote       March 2000
+
+
+   [DSA94]   NIST, FIPS PUB 186, "Digital Signature Standard", May 1994.
+
+   [Riv92]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+             April 1992.
+
+   [RSA78]   R. L. Rivest, A. Shamir, L. M. Adleman, "A Method for
+             Obtaining Digital Signatures and Public-Key Cryptosystems",
+             Communications of the ACM, v21n2. pp 120-126, February
+             1978.
+
+   [SHA1-95] NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.
+             http://csrc.nist.gov/fips/fip180-1.txt (ascii)
+             http://csrc.nist.gov/fips/fip180-1.ps  (postscript)
+
+Contacts
+
+   Comments about this document should be discussed on the
+   keynote-users@nsa.research.att.com mailing list.
+
+   Questions about this document can also be directed to the authors as
+   a group at the keynote@research.att.com alias, or to the individual
+   authors at:
+
+   Matt Blaze
+   AT&T Labs - Research
+   180 Park Avenue
+   Florham Park, New Jersey 07932-0000
+
+   EMail: mab@research.att.com
+
+
+   John Ioannidis
+   AT&T Labs - Research
+   180 Park Avenue
+   Florham Park, New Jersey 07932-0000
+
+   EMail: ji@research.att.com
+
+
+   Angelos D. Keromytis
+   Distributed Systems Lab
+   CIS Department, University of Pennsylvania
+   200 S. 33rd Street
+   Philadelphia, Pennsylvania  19104-6389
+
+   EMail: angelos@cis.upenn.edu
+
+
+
+
+
+Blaze, et al.                Informational                      [Page 6]
+
+RFC 2792         Key and Signature Encoding for KeyNote       March 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blaze, et al.                Informational                      [Page 7]
+