From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2792.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc2792.txt (limited to 'doc/rfc/rfc2792.txt') 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] + -- cgit v1.2.3