idnits 2.17.1 draft-keromytis-keynote-x509-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a Notice of Compliance with BCP 78 and BCP 79 according to IETF Trust Provisions of 28 Dec 2009, Section 6.a or Provisions of 12 Sep 2009, Section 6.a. ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 277 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC3280], [KEYNOTE], [RFC2792]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Intended Status: Proposed March 25, 2009', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (March 25, 2009) is 5504 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) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft A.D. Keromytis 2 Expires: October 20, 2009 Columbia University 3 Intended Status: Proposed March 25, 2009 4 Filename: draft-keromytis-keynote-x509-02.txt 6 X.509 Key and Signature Encoding for the 7 KeyNote Trust Management System 9 Status of this Memo 11 This Internet-Draft is submitted to the IETF in full conformance 12 with the provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright and License Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents in effect on the date of 38 publication of this document (http://trustee.ietf.org/licenseinfo). 39 Please review these documents carefully, as they describe your 40 rights and restrictions with respect to this document. 42 Abstract 44 This memo describes X.509 key identifiers and signature encoding 45 for version 2 of the KeyNote trust-management system [KEYNOTE]. 46 X.509 certificates [RFC3280] can be directly used in the Authorizer 47 or Licensees field (or in both fields) in a KeyNote assertion, 48 allowing for easy integration with protocols that already use X.509 49 certificates for authentication. 51 In addition, the document defines additional signature types that 52 use other hash functions (beyond the MD5 and SHA1 hash functions 53 that are defined in [RFC2792]). 55 1. Introduction 57 KeyNote is a simple and flexible trust-management system designed to 58 work well for a variety of large- and small-scale Internet-based 59 applications. It provides a single, unified language for both local 60 policies and credentials. KeyNote policies and credentials, called 61 `assertions', contain predicates that describe the trusted actions 62 permitted by the holders of specific public keys. KeyNote 63 assertions are essentially small, highly-structured programs. A 64 signed assertion, which can be sent over an untrusted network, is 65 also called a `credential assertion'. Credential assertions, which 66 also serve the role of certificates, have the same syntax as policy 67 assertions but are also signed by the principal delegating the trust. 68 Note that only one principal may sign a credential assertion, but 69 trust may be delegated to multiple principals. The credential 70 assertion may delegate trust to each of these principals separately, 71 or to groups of principals required to act together. For more 72 details on KeyNote, see [KEYNOTE]. This document assumes reader 73 familiarity with the KeyNote system. 75 Cryptographic keys may be used in KeyNote to identify principals. To 76 facilitate interoperation between different implementations and to 77 allow for maximal flexibility, keys must be converted to a normalized 78 canonical form (depended on the public key algorithm used) for the 79 purposes of any internal comparisons between keys. For example, an 80 RSA key may be encoded in base64 ASCII in one credential, and 81 in hexadecimal ASCII in another. A KeyNote implementation must 82 internally convert the two encodings to a normalized form that allows 83 for comparison between them. Furthermore, the internal structure of 84 an encoded key must be known for an implementation to correctly 85 decode it. RFC 2792 [RFC2792] describes the RSA and DSA key 86 identifier and signature encodings for use in KeyNote assertions. 87 This document specifies a new key identifier, allowing X.509 88 certificates [RFC3280] to be used as a key substitute wherever an 89 RSA or DSA key may be used in KeyNote. Specifically, KeyNote will 90 use the key associated with the Subject of an X.509 certificate. In 91 addition, this document defines a corresponding signature encoding, 92 to be used in conjunction with X.509 key identifiers. Finally, this 93 document defines new signature encodings that use new hash functions 94 beyond the MD5 and SHA1 functions defined in RFC 2792, and which in 95 recent years have been found to be vulnerable to attack. 97 1.1. Conventions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 2. X.509 Key Identifier Encoding 105 X.509 key identifiers in KeyNote are encoded as an ASN1 DER encoding 106 of the whole X.509 certificate, as defined in Section 4 of RFC 3280 107 [RFC3280]. 109 For use in KeyNote credentials, the ASN1 DER-encoded object is then 110 ASCII- encoded (e.g., as a string of hex digits or base64 111 characters). 113 X.509 keys encoded in this way in KeyNote must be identified by the 114 "x509-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" or 115 "base64"). Other ASCII encoding schemes may be defined in the 116 future. 118 3. X.509 Key Identifier Normalized Forms 120 For comparison purposes, X.509 certificates are parsed, the Subject 121 public key is extracted and decomposed according to the rules 122 described in Section 2 of [RFC2792]. The resulting RSA or DSA key 123 is then used for comparing, per [RFC2792]. All X.509 key comparisons 124 in KeyNote occur between normalized forms. Note that this allows for 125 comparison between a directly encoded RSA or DSA key (as specified in 126 RFC 2792) and the same key when contained in an X.509 certificate. 128 4. X.509 Signature Computation and Encoding 130 X.509 key identifier signatures are defined for historical reasons. 131 Implementers are encouraged to use the RSA or DSA-based signature 132 encodings instead. 134 X.509 key identifier signatures in KeyNote are identical to RSA- or 135 DSA-based signatures [RFC2792]. The only difference is that the 136 public key corresponding to the private key that generated the 137 signatures is encoded in an X.509 certificate in the ``Authorizer'' 138 field of the signed credential assertion. However, an RSA- or 139 DSA-based signature encoding (depending on the Subject key contained 140 in the X.509 certificate itself) may be used instead. 142 X.509 key identifier signatures in KeyNote are computed over the 143 assertion body (starting from the beginning of the first keyword, 144 up to and including the newline character immediately before the 145 "Signature:" keyword) and the signature algorithm name (including 146 the trailing colon character, e.g., "sig-x509-sha512-base64:") 148 X.509 key identifier signatures are encoded as an ASN1 OCTET 149 STRING object, containing the signature value. 151 For use in KeyNote credentials, the ASN1 OCTET STRING is then ASCII- 152 encoded (as a string of hex digits or base64 characters). 154 X.509 key identifier signatures encoded in this way in KeyNote must 155 be identified by the "sig-x509-XXX-YYY:" algorithm name, where XXX 156 is a hash function name (see Section 5 and Section 7 of this 157 document) and YYY is an ASCII encoding ("hex" or "base64"). 159 5. Hash Functions For RSA, DSA, and X.509 Key Identifier Signatures 161 For historical reasons (backward compatibility), X.509 key 162 identifier signatures SHOULD support SHA1 as the hash function, 163 using the "sha1" keyword. In addition, SHA256, SHA512 and 164 RIPEMD160 [SHA256+] [SHA2-2] [RIPEMD-160] signatures MUST be 165 supported for use with X509 key identifier signatures, by using 166 the "sha256", "sha512" and "ripemd160" keywords respectively 167 (see Section 7). 169 In addition, SHA256, SHA512 and RIPEMD160 signature identifiers are 170 defined for RSA signatures, using the "sha256", "sha512" and 171 "ripemd160" keywords respectively (see Section 7). 173 6. Security Considerations 175 This document discusses the format of X.509 keys and signatures 176 as used in KeyNote. The security of KeyNote credentials utilizing 177 such keys and credentials is directly dependent on the strength of 178 the related public key algorithms. On the security of KeyNote 179 itself, see [KEYNOTE]. Furthermore, it is the responsibility of the 180 application developer to ensure that X.509 certificates are valid 181 (signed by a trusted authority, not expired, and not revoked). 183 The use of SHA1 as part of signatures and key identifiers is 184 discouraged, because of the various weaknesses in the algorithm 185 that have been identified in recent years. 187 7. IANA Considerations 189 Per [KEYNOTE], IANA should provide a registry of reserved algorithm 190 identifiers. The following identifiers are reserved by this document 191 as public key identifier encodings: 193 - "x509-hex" 194 - "x509-base64" 196 The following identifiers are reserved by this document as signature 197 encodings: 199 - "sig-x509-sha1-hex" 200 - "sig-x509-sha1-base64" 201 - "sig-x509-sha256-hex" 202 - "sig-x509-sha256-base64" 203 - "sig-x509-sha512-hex" 204 - "sig-x509-sha512-base64" 205 - "sig-x509-ripemd160-hex" 206 - "sig-x509-ripemd160-base64" 207 - "sig-rsa-sha256-hex" 208 - "sig-rsa-sha256-base64" 209 - "sig-rsa-sha512-hex" 210 - "sig-rsa-sha512-base64" 211 - "sig-rsa-ripemd160-hex" 212 - "sig-rsa-ripemd160-base64" 214 Note that the double quotes are not part of the algorithm 215 identifiers. 217 8. Normative References 219 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 220 X.509 Public Key Infrastructure Certificate and 221 Certificate Revocation List (CRL) Profile", RFC 3280, 222 April 2002. 224 [SHA256+] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 225 (SHA and HMAC-SHA)", RFC 4634, July 2006. 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 9. Informative References 232 [KEYNOTE] Blaze, M., Feigenbaum, J., Ioannidis, J., and 233 A. Keromytis, "The KeyNote Trust-Management System, 234 Version 2", RFC 2704, September 1999. 236 [RIPEMD-160] 3.ISO/IEC 10118-3:1998, "Information technology - 237 Security techniques - Hash-functions - Part 3: 238 Dedicated hash-functions," International Organization 239 for Standardization, Geneva, Switzerland, 1998. 241 [RFC2792] Blaze, M., Ioannidis, J., and A. Keromytis, "DSA and RSA 242 Key and Signature Encoding for the KeyNote Trust 243 Management System", RFC 2792, March 2000. 245 [SHA2-2] NIST, "Descriptions of SHA-256, SHA-384, and SHA-512", 246 May 2001, 247 . 249 10. Acknowledgements 251 The author would like to thank Jim Schaad for his review and comments 252 on earlier versions of this document. 254 Authors' Addresses 256 Angelos D. Keromytis 257 Department of Computer Science 258 Columbia University 259 Mail Code 0401 260 1214 Amsterdam Avenue 261 New York, New York 1007 262 USA 263 angelos cs columbia edu