idnits 2.17.1 draft-angelos-keynote-dsa-rsa-encoding-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 287 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 238 has weird spacing: '...att.com ji@r...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2000) is 8867 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'AC2' ** Downref: Normative reference to an Informational RFC: RFC 2704 (ref. 'BFIK') -- Possible downref: Non-RFC (?) normative reference: ref. 'DSA94' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA78' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Matt Blaze 2 Internet Draft John Ioannidis 3 Expires in six months AT&T Labs - Research 4 Angelos D. Keromytis 5 U. of Pennsylvania 6 January 2000 8 DSA and RSA Key and Signature Encoding for the 9 KeyNote Trust Management System 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Please direct comments to one of the authors (for the authors contact 18 information, see the end of this document), and/or to the 19 trustmgt@east.isi.edu mailing list. 21 Internet Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working Groups. Note that 23 other groups may also distribute working documents as Internet 24 Drafts. 26 Internet-Drafts draft documents are valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress". 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Distribution of this memo is unlimited. 39 Abstract 41 This memo describes RSA and DSA key and signature encoding for 42 version 2 of the KeyNote trust-management system. 44 1. Introduction 46 KeyNote is a simple and flexible trust-management system designed 47 to work well for a variety of large- and small- scale 48 Internet-based applications. It provides a single, unified 49 language for both local policies and credentials. KeyNote policies 50 and credentials, called `assertions,' contain predicates that 51 describe the trusted actions permitted by the holders of specific 52 public keys. KeyNote assertions are essentially small, 53 highly-structured programs. A signed assertion, which can be sent 54 over an untrusted network, is also called a `credential assertion.' 55 Credential assertions, which also serve the role of certificates, 56 have the same syntax as policy assertions but are also signed by 57 the principal delegating the trust. For more details on KeyNote, 58 see [BFIK]. This document assumes reader familiarity with the 59 KeyNote system. 61 Cryptographic keys in KeyNote are used to identify principals. To 62 facilitate interoperation between different implementations and to 63 allow for maximal flexibility, keys must be converted to a 64 normalized canonical form (depended on the public key algorithm 65 used) for the purposes of any internal comparisons between keys. 66 For example, an RSA [RSA78] key may be encoded in base64 ASCII in 67 one credential, and in hexadecimal ASCII in another. A KeyNote 68 implementation must internally convert the two encodings to a 69 normalized form that allows for comparison between them. 70 Furthermore, the internal structure of an encoded key must be known 71 for an implementation to correctly decode it. 73 This document specifies RSA and DSA [DSA94] key and signature 74 encodings for use in KeyNote. 76 2. Key Normalized Forms 78 2.1 DSA Key Normalized Form 80 DSA keys in KeyNote are identified by four values: 81 - the public value 82 - the p parameter 83 - the q parameter 84 - the g parameter 86 For an explanation of the various parameters, see [AC2]. These 87 four values together make up the DSA key normalized form used in 88 KeyNote. All DSA key comparisons in KeyNote occur between 89 normalized forms. 91 2.2 RSA Key Normalized Form 93 RSA keys in KeyNote are identified by two values: 94 - the public exponent 95 - the modulus 97 These two values together make up the RSA key normalized form used 98 in KeyNote. All RSA key comparisons in KeyNote occur between 99 normalized forms. 101 3. Key Encoding 103 3.1 DSA Key Encoding 105 DSA keys in KeyNote are encoded as an ASN1 SEQUENCE of four ASN1 106 INTEGER objects. The four INTEGER objects are the public value 107 and the p, q, and g parameters of the DSA key, in that order. 109 For use in KeyNote credentials, the ASN1 SEQUENCE is then 110 ASCII-encoded (e.g., as a string of hex digits or base64 111 characters). 113 DSA keys encoded in this way in KeyNote must be identified by the 114 "dsa-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" 115 or "base64"). Other ASCII encoding schemes may be defined in the 116 future. 118 3.2 RSA Key Encoding 120 RSA keys in KeyNote are encoded as an ASN1 SEQUENCE of two ASN1 121 INTEGER objects. The two INTEGER objects are the public exponent 122 and the modulus of the DSA key, in that order. 124 For use in KeyNote credentials, the ASN1 SEQUENCE is then 125 ASCII-encoded (e.g., as a string of hex digits or base64 126 characters). 128 RSA keys encoded in this way in KeyNote must be identified by the 129 "rsa-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" 130 or "base64"). Other ASCII encoding schemes may be defined in the 131 future. 133 4. Signature Computation and Encoding 135 4.1 DSA Signature Computation and Encoding 137 DSA signatures in KeyNote are computed over the assertion body 138 (starting from the begining of the first keyword, up to and 139 including the newline character immediately before the 140 "Signature:" keyword) and the signature algorithm name (including 141 the trailing colon character, e.g., "sig-dsa-sha1-base64:") 143 DSA signatures are then encoded as an ASN1 SEQUENCE of two ASN1 144 INTEGER objects. The two INTEGER objects are the r and s 145 values of a DSA signature [AC2]. 147 For use in KeyNote credentials, the ASN1 SEQUENCE is then 148 ASCII-encoded (as a string of hex digits or base64 characters). 150 DSA signatures encoded in this way in KeyNote must be identified 151 by the "sig-dsa-XXX-YYY:" algorithm name, where XXX is a hash 152 function name ("sha1", for the SHA1 [SHA1] hash function is 153 currently the only hash function that may be used with DSA) and 154 YYY is an ASCII encoding ("hex" or "base64"). 156 4.2 RSA Signature Computation and Encoding 158 RSA signatures in KeyNote are computed over the assertion body 159 (starting from the begining of the first keyword, up to and 160 including the newline character immediately before the 161 "Signature:" keyword) and the signature algorithm name (including 162 the trailing colon character, e.g., "sig-rsa-sha1-base64:") 164 RSA signatures are then encoded as an ASN1 OCTET STRING object, 165 containing the signature value. 167 For use in KeyNote credentials, the ASN1 OCTET STRING is then 168 ASCII-encoded (as a string of hex digits or base64 characters). 170 RSA signatures encoded in this way in KeyNote must be identified 171 by the "sig-rsa-XXX-YYY:" algorithm name, where XXX is a hash 172 function name ("md5" or "sha1", for the MD5 [MD5] and SHA1 [SHA1] 173 hash algorithms respectively, may be used with RSA) and YYY is an 174 ASCII encoding ("hex" or "base64"). 176 5. Security Considerations 178 This document discusses the format of RSA and DSA keys and 179 signatures as used in KeyNote. The security of KeyNote credentials 180 utilizing such keys and credentials is directly dependent on the 181 strength of the related public key algorithms. On the security 182 of KeyNote itself, see [BFIK]. 184 6. IANA Considerations 186 Per [BFIK], IANA should provide a registry of reserved algorithm 187 identifiers. The following identifiers are reserved by this 188 document as public key encodings: 190 - "rsa-hex" 191 - "rsa-base64" 192 - "dsa-hex" 193 - "dsa-base64" 195 The following identifiers are reserved by this document as 196 signature encodings: 198 - "sig-rsa-md5-hex" 199 - "sig-rsa-md5-base64" 200 - "sig-rsa-sha1-hex" 201 - "sig-rsa-sha1-base64" 202 - "sig-dsa-sha1-hex" 203 - "sig-dsa-sha1-base64" 205 References 207 [AC2] Bruce Schneier, Applied Cryptography 2nd Edition, John Wiley 208 & Sons, New York, NY, 1996. 210 [BFIK] M. Blaze, J. Feigenbaum, J. Ioannidis, A D. Keromytis, "The 211 KeyNote Trust-Management System Version 2", RFC 2704, 212 September 1999. 214 [DSA94] NIST, FIPS PUB 186, "Digital Signature Standard", May 1994. 216 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 217 MIT and RSA Data Security, Inc., April 1992. 219 [RSA78] R. L. Rivest, A. Shamir, L. M. Adleman, "A Method for 220 Obtaining Digital Signatures and Public-Key Cryptosystems", 221 Communications of the ACM, v21n2. pp 120-126, February 222 1978. 224 [SHA1] NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995. 225 http://csrc.nist.gov/fips/fip180-1.txt (ascii) 226 http://csrc.nist.gov/fips/fip180-1.ps (postscript) 228 Contacts 230 Comments about this document should be discussed on the 231 keynote-users@nsa.research.att.com mailing list. 233 Questions about this document can also be directed to the authors as 234 a group at the keynote@research.att.com alias, or to the individual 235 authors at: 237 Matt Blaze John Ioannidis 238 mab@research.att.com ji@research.att.com 240 AT&T Labs - Research 241 180 Park Avenue 242 Florham Park, New Jersey 07932-0000 244 Angelos D. Keromytis 245 angelos@dsl.cis.upenn.edu 247 Distributed Systems Lab 248 CIS Department, University of Pennsylvania 249 200 S. 33rd Street 250 Philadelphia, Pennsylvania 19104-6389 252 Full Copyright Statement 254 Copyright (C) The Internet Society (1999). All Rights Reserved. 256 This document and translations of it may be copied and furnished to 257 others, and derivative works that comment on or otherwise explain it 258 or assist in its implementation may be prepared, copied, published 259 and distributed, in whole or in part, without restriction of any 260 kind, provided that the above copyright notice and this paragraph are 261 included on all such copies and derivative works. However, this 262 document itself may not be modified in any way, such as by removing 263 the copyright notice or references to the Internet Society or other 264 Internet organizations, except as needed for the purpose of 265 developing Internet standards in which case the procedures for 266 copyrights defined in the Internet Standards process must be 267 followed, or as required to translate it into languages other than 268 English. 270 The limited permissions granted above are perpetual and will not be 271 revoked by the Internet Society or its successors or assigns. 273 This document and the information contained herein is provided on an 274 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 275 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 276 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 277 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 278 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.