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.
AbstractThis memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system. 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
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. 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.
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"). Riv92] and SHA1 [SHA1-95] hash algorithms respectively, may be used with RSA) and YYY is an ASCII encoding ("hex" or "base64").
BFIK99]. 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. [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.
[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)
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.