idnits 2.17.1 draft-pala-composite-crypto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 5, 2019) is 1878 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC5958' is mentioned on line 149, but not defined == Missing Reference: 'RFC4648' is mentioned on line 171, but not defined == Missing Reference: 'RFC1421' is mentioned on line 183, but not defined == Missing Reference: 'RFC3279' is mentioned on line 259, but not defined == Missing Reference: 'RFC8410' is mentioned on line 259, but not defined == Missing Reference: 'RFC8411' is mentioned on line 262, but not defined Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Pala 3 Internet-Draft CableLabs 4 Intended status: Experimental February 5, 2019 5 Expires: August 9, 2019 7 Composite Public Keys and Signatures 8 draft-pala-composite-crypto-00 10 Abstract 12 PKIs are used to provide scalability and ease key management. One 13 type of PKIs that is predominant for securing communications and data 14 is based on the X.509 standard. Since the security of PKIs, 15 ultimately, depends on the security of the cryptographic building 16 blocks that are used for authentication and encryption, the standards 17 community made algorithm agility a priority. Algorithm agility, in 18 particular, enables upgrading to newly available algorithms when 19 needed. 21 The CompositeCrypto (i.e., CompositeKey and CompositeSignature 22 structures) described in this document provides an additional tool 23 that enables the use of multiple algorithms to authenticate data 24 without the need to use multiple certificates and more complex data 25 structures. 27 This document provide the description of the definition and encoding 28 rules for CompositeKey and CompositeSignature. A description of how 29 to use these structures in main PKIX objects (e.g., X.509 30 certificates, CRLs, OCSP responses, etc.) is also provided. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 9, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 67 2. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3 68 3. Composite Cryptography . . . . . . . . . . . . . . . . . . . 3 69 3.1. Composite Public Keys . . . . . . . . . . . . . . . . . . 3 70 3.2. Composite Private Keys . . . . . . . . . . . . . . . . . 4 71 3.2.1. Encoding Rules . . . . . . . . . . . . . . . . . . . 4 72 3.2.2. Encrypted and Un-encrypted Local Storage . . . . . . 4 73 3.2.3. Asymmetric Key Packages . . . . . . . . . . . . . . . 5 74 3.3. Composite Signatures . . . . . . . . . . . . . . . . . . 5 75 4. Use of Composite Crypto in PKIX structures . . . . . . . . . 5 76 4.1. Use in X.509 Certificates . . . . . . . . . . . . . . . . 5 77 4.2. Use in X.509 CRLs . . . . . . . . . . . . . . . . . . . . 5 78 4.3. Use in X.509 OCSP Messages . . . . . . . . . . . . . . . 5 79 4.4. Use in PKCS#7 Structures . . . . . . . . . . . . . . . . 5 80 4.5. Use in CMS Structures . . . . . . . . . . . . . . . . . . 5 81 4.6. Use in PKCS#1 Structures . . . . . . . . . . . . . . . . 5 82 4.7. Use in PKCS#8 Structures . . . . . . . . . . . . . . . . 5 83 4.8. Use in PKCS#12 Structures . . . . . . . . . . . . . . . . 5 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 85 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 86 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 87 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 90 1. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Introduction and Scope 98 With the definition of new algorithms (e.g. more efficient factoring 99 techniques) and technologies (e.g., quantum-based computing devices) 100 that might be available in the near future, the need to provide an 101 easy-to-deploy and efficient solution capable of providing multi- 102 algorithms authentication is paramount. 104 Today there are no complete or general solutions that allow the use 105 of multiple public-key algorithms to authenticate PKIX data without 106 using multiple X.509 certificates or complex data structures. For 107 example, CRLs or OCSP responses can not be protected via multiple 108 algorithms without wrapping the OCSP responses' data via CMS or other 109 signed containers. 111 This document defines two new building blocks that can be applied to 112 many environments where Public Key authentication is used - i.e., 113 from the generation of certificates that are authenticated with 114 multiple signatures (i.e., using multiple keys that may or may not 115 use different cryptographic schemes or different number of security 116 bits), to the possibility of specifying a composite key that combines 117 multiple public keys (instead of one) in a single certificate. This 118 solution can also be The two new building blocks are Composite 119 Signatures and Composite Keys. 121 This document describes the encoding of the new building blocks and 122 their application to different X.509 core data structures that are 123 used in PKIs. In particular, this document focuses only on the 124 definition of the composite keys and composite signatures definitions 125 for X.509 based PKIs (PKIX) by providing the encoding rules and their 126 usage in existing X.509 (PKIX) data structures. 128 3. Composite Cryptography 130 id-pk-compositeCrypto OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) dod(6) 131 internet(1) private(4) enterprise(1) OpenCA(18227) 10 } 133 3.1. Composite Public Keys 135 This document defines a new Object Identifier (or OID) to identify 136 the Composite Keys algorithm (e.g., similar to to the 'rsaEncryption' 137 OID when using RSA public keys). 139 id-pk-compositeKeys OBJECT IDENTIFIER ::= { id-kp-compositeCrypto 1 } 141 3.2. Composite Private Keys 143 This section specifies a syntax and semantics for Composite Keys 144 private key information. Composite private key information includes 145 a sequence of private keys and parameters. Additionally, it may 146 include the corresponding public keys. The structure defined in this 147 document allows for the distribution of the composite keys (public 148 and private) and the associated domain parameters by using a sequence 149 of OneAsymmetricKey as defined in [RFC5958]. The Algorithm 150 Identifier and data structure associated with composite private keys 151 is defined as follows: 153 id-kp-compositePrivateKeys OBJECT IDENTIFIER ::= { id-kp-compositeCrypto 2 } 155 compositePrivateKeys ::= SEQUENCE (1..MAX) OF OneAsymmetricKey 157 3.2.1. Encoding Rules 159 When encoding Composite Private Keys, generators SHOULD use 160 Distinguished Encoding Rules (DER) [X.690] and receivers SHOULD be 161 prepared to handle Basic Encoding Rules (BER) [X.690] and DER 162 [X.690]. 164 3.2.2. Encrypted and Un-encrypted Local Storage 166 The compositePrivateKeys format as defined in the previous subsection 167 can also be used for local storage of an unencrypted 168 compositePrivateKeys binary object. The compositePrivateKeys can 169 also be formatted in PEM format that uses the (".pem") file extension 170 and which is encoded as the the Base64 encoding (see Section 4 of 171 [RFC4648]), of the DER-encoded compositePrivateKeys object with the 172 following armour: 174 -----BEGIN COMPOSITE PRIVATE KEY----- 175 -----END COMPOSITE PRIVATE KEY----- 177 Local storage of an encrypted CompositePrivateKeys object is out of 178 scope of this document. However, CompositePrivateKeys should be the 179 format for the plaintext key being encrypted. DER [X.690] encoding 180 the CompositePrivateKeys will promote interoperability if the key is 181 encrypted for transport to another party. PEM encoding the DER- 182 encoded CompositePrivateKeys is common; "Proc-Type:" and "DEK-INFO:" 183 fields [RFC1421] followed by the DER-encoded CompositePrivateKeys. 184 The following armour used in this case is as follows: 186 -----BEGIN COMPOSITE PRIVATE KEY----- 187 -----END COMPOSITE PRIVATE KEY----- 189 3.2.3. Asymmetric Key Packages 191 The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can 192 be used to digitally sign, digest, authenticate, or encrypt the 193 asymmetric key format content type. When encoding Composite Private 194 Keys, the privateKeyAlgorithm in the OneAsymmetricKey SHALL be set to 195 id-kp-compositePrivateKeys. The parameters of the 196 privateKeyAlgorithm SHALL be a sequence of AlgorithmIdentifier 197 objects, each of which are encoded according to the rules defined for 198 each of the different keys in the Composite Private Key. The value 199 of the privateKey field in the OneAsymmetricKey SHALL be set to the 200 DER encoding of the SEQUENCE of private key values that make up the 201 composite key. The number and order of elements in the sequence 202 SHALL be the same as identified in the sequence of parameters in the 203 privateKeyAlgorithm. The value of the the publicKey (if present) 204 SHALL be set to the DER encoding of the SEQUENCE of publicKey values. 205 If this field is present, the number and order of elements SHALL be 206 the same as identified in the sequence of parameters in the 207 privateKeyAlgorithm. The value of the attributes is encoded as 208 usual. 210 3.3. Composite Signatures 212 compositeSignatures OBJECT IDENTIFIER ::= { compositeCrypto 3 } 214 4. Use of Composite Crypto in PKIX structures 216 4.1. Use in X.509 Certificates 218 4.2. Use in X.509 CRLs 220 4.3. Use in X.509 OCSP Messages 222 4.4. Use in PKCS#7 Structures 224 4.5. Use in CMS Structures 226 4.6. Use in PKCS#1 Structures 228 4.7. Use in PKCS#8 Structures 230 4.8. Use in PKCS#12 Structures 232 5. Security Considerations 234 This structures described in this document do not protect the private 235 keys information in any way unless combined with a security protocol 236 or encryption properties of the objects (if any) where the 237 CompositePrivateKey is used (see next Section). Protection of the 238 private key information is vital to public key cryptography. The 239 consequences of disclosure depend on the purpose of the private key. 240 If a private key is used for signature, then the disclosure allows 241 unauthorized signing. If a private key is used for key management, 242 then disclosure allows unauthorized parties to access the managed 243 keying material. The encryption algorithm used in the encryption 244 process must be as 'strong' as the key it is protecting. 246 6. IANA considerations 248 This document makes use of object identifiers to identify an content 249 type and the ASN.1 module found in Appendix A (still missing). The 250 CMS content type OID is registered in a DoD arc. The ASN.1 module 251 OID is TBD. The CompositeCrypto, CompositeKey, and 252 CompositeSignature OIDs are to be assigned by IANA. The authors 253 suggest to use the id-pkix arc for this usage. 255 7. Acknowledgments 257 The authors would like to thank everybody who provided insightful 258 comments and helped in any form. This document uses a lot of text 259 from similar documents ([RFC3279] and [RFC8410]) as well as [I- 260 D.ietf-lamps-cms-hash-sig]. Thanks go to the authors of those 261 documents. "Copying always makes things easier and less error prone" 262 - [RFC8411]. 264 8. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, 268 DOI 10.17487/RFC2119, March 1997, 269 . 271 Author's Address 273 Massimiliano Pala 274 CableLabs 275 858 Coal Creek Cir 276 Louisville, CO 80027 277 USA 279 Email: director@openca.org 280 URI: http://www.linkedin.com/in/mpala