The RFC Archive
 The RFC Archive   RFC 2792   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 2792

DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System

Last modified on Wednesday, March 8th, 2000

Permanent link to RFC 2792
Search GitHub Wiki for RFC 2792
Show other RFCs mentioning RFC 2792







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 © 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 top


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 top

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 top

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 top

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 top

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 top

RFC 2792 Key and Signature Encoding for KeyNote March 2000 Full Copyright Statement Copyright © 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 top

DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System RFC TOTAL SIZE: 13461 bytes PUBLICATION DATE: Wednesday, March 8th, 2000 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 2792: The IETF Trust, Wednesday, March 8th, 2000
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement