idnits 2.17.1 draft-pala-composite-crypto-03.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 4 instances of too long lines in the document, the longest one being 5 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 (March 25, 2019) is 1859 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) == Missing Reference: 'RFC5958' is mentioned on line 168, but not defined == Missing Reference: 'RFC4648' is mentioned on line 191, but not defined == Missing Reference: 'RFC1421' is mentioned on line 203, but not defined == Missing Reference: 'RFC3279' is mentioned on line 315, but not defined == Missing Reference: 'RFC8410' is mentioned on line 315, but not defined == Missing Reference: 'RFC8411' is mentioned on line 318, but not defined == Missing Reference: 'CMSASN1' is mentioned on line 337, but not defined Summary: 1 error (**), 0 flaws (~~), 8 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: Standards Track March 25, 2019 5 Expires: September 26, 2019 7 Composite Public Keys and Signatures 8 draft-pala-composite-crypto-03 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 September 26, 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 . . . . . . . . . . . . . . . . . . 4 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 3.4. Generating Composite Signatures . . . . . . . . . . . . . 6 76 3.5. Verifying Composite Signatures . . . . . . . . . . . . . 6 77 4. Use of Composite Crypto in PKIX structures . . . . . . . . . 6 78 4.1. Use in X.509 Certificates . . . . . . . . . . . . . . . . 6 79 4.2. Use in X.509 CRLs . . . . . . . . . . . . . . . . . . . . 6 80 4.3. Use in X.509 OCSP Messages . . . . . . . . . . . . . . . 6 81 4.4. Use in PKCS#7 . . . . . . . . . . . . . . . . . . . . . . 6 82 4.5. Use in PKCS#8 . . . . . . . . . . . . . . . . . . . . . . 6 83 4.6. Use in PKCS#12 . . . . . . . . . . . . . . . . . . . . . 7 84 4.7. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . 7 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 86 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 88 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 89 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 7 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 92 1. Requirements notation 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Introduction and Scope 100 With the definition of new algorithms (e.g. more efficient factoring 101 techniques) and technologies (e.g., quantum-based computing devices) 102 that might be available in the near future, the need to provide an 103 easy-to-deploy and efficient solution capable of providing multi- 104 algorithms authentication is paramount. 106 Today there are no complete or general solutions that allow the use 107 of multiple public-key algorithms to authenticate PKIX data without 108 using multiple X.509 certificates or complex data structures. For 109 example, CRLs or OCSP responses can not be protected via multiple 110 algorithms without wrapping the OCSP responses' data via CMS or other 111 signed containers. 113 We define two new building blocks, i.e. compositeKey and 114 compositeSignature, that can be used in many environments where 115 Public Key authentication is used - i.e., from the generation of 116 certificates that are authenticated with multiple signatures (i.e., 117 using multiple keys that may or may not use different cryptographic 118 schemes or different number of security bits), to the possibility of 119 specifying a composite key that combines multiple public keys 120 together (instead of one) in a single certificate. 122 This document describes the encoding of the new building blocks and 123 their application to different X.509 core data structures that are 124 used in PKIs. In particular, this document focuses only on the 125 definition of the composite keys and composite signatures definitions 126 for X.509 based PKIs (PKIX) by providing the encoding rules and their 127 usage in existing X.509 (PKIX) data structures. 129 3. Composite Cryptography 131 Composite Cryptography is defined as the possibility to combine 132 different public keys and signatures in PKIX objects. The following 133 OID is defined to identfy the algorithm class: 135 id-pk-compositeCrypto OBJECT IDENTIFIER ::= { iso(1) 136 identified-organization(3) dod(6) internet(1) private(4) 137 enterprise(1) OpenCA(18227) Algorithms(2) 1 } 139 Composite Cryptography provides three distinct building blocks: the 140 compositePublicKey, the compositePrivateKey and the 141 compositeSignature. The compositePublicKey is meant to carry all the 142 public keys associated with an identity. The compositePrivateKey is 143 meant to carry all the private keys associated with an identity. The 144 compositeSignature, instead, carries a sequence of signatures that 145 are generated by using the different individual keys from a 146 compositePrivateKey. 148 3.1. Composite Public Keys 150 This document defines a new Object Identifier and data strcuture for 151 composite public keys as follows: 153 id-pk-compositePublicKey OBJECT IDENTIFIER ::= { id-kp-compositeCrypto 1 } 155 CompositePublicKey ::= SEQUENCE (1..MAX) OF SubjectPublicKeyInfo 157 3.2. Composite Private Keys 159 This section specifies a syntax and semantics for Composite Keys 160 private key information. Composite private key information is built 161 as a SEQUENCE of BIT STRINGs each of which contains the single 162 private keys and parameters. Additionally, it may include the 163 corresponding public keys. 165 The structure defined in this document allows for the distribution of 166 the composite keys (public and private) and the associated domain 167 parameters by using a sequence of OneAsymmetricKey as defined in 168 [RFC5958]. 170 The Algorithm Identifier and data structure associated for Composite 171 Private Keys is defined as follows: 173 id-pk-compositePrivateKey OBJECT IDENTIFIER ::= { id-kp-compositeCrypto 2 } 175 CompositePrivateKey ::= SEQUENCE (1..MAX) OF OneAsymmetricKey 177 3.2.1. Encoding Rules 179 When encoding Composite Private Keys, generators SHOULD use 180 Distinguished Encoding Rules (DER) [X.690] and receivers SHOULD be 181 prepared to handle Basic Encoding Rules (BER) [X.690] and DER 182 [X.690]. 184 3.2.2. Encrypted and Un-encrypted Local Storage 186 The compositePrivateKeys format as defined in the previous subsection 187 can also be used for local storage of an unencrypted 188 compositePrivateKeys binary object. The compositePrivateKeys can 189 also be formatted in PEM format that uses the (".pem") file extension 190 and which is encoded as the the Base64 encoding (see Section 4 of 191 [RFC4648]), of the DER-encoded compositePrivateKeys object with the 192 following armour: 194 -----BEGIN COMPOSITE PRIVATE KEY----- 195 -----END COMPOSITE PRIVATE KEY----- 197 Local storage of an encrypted CompositePrivateKeys object is out of 198 scope of this document. However, CompositePrivateKeys should be the 199 format for the plaintext key being encrypted. DER [X.690] encoding 200 the CompositePrivateKeys will promote interoperability if the key is 201 encrypted for transport to another party. PEM encoding the DER- 202 encoded CompositePrivateKeys is common; "Proc-Type:" and "DEK-INFO:" 203 fields [RFC1421] followed by the DER-encoded CompositePrivateKeys. 204 The following armour used in this case is as follows: 206 -----BEGIN COMPOSITE PRIVATE KEY----- 207 -----END COMPOSITE PRIVATE KEY----- 209 3.2.3. Asymmetric Key Packages 211 The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can 212 be used to digitally sign, digest, authenticate, or encrypt the 213 asymmetric key format content type. 215 When encoding Composite Private Keys, the privateKeyAlgorithm in the 216 OneAsymmetricKey SHALL be set to id-kp-compositePrivateKey. 218 The parameters of the privateKeyAlgorithm SHALL be a sequence of 219 AlgorithmIdentifier objects, each of which are encoded according to 220 the rules defined for each of the different keys in the Composite 221 Private Key. 223 The value of the privateKey field in the OneAsymmetricKey SHALL be 224 set to the DER encoding of the SEQUENCE of private key values that 225 make up the composite key. The number and order of elements in the 226 sequence SHALL be the same as identified in the sequence of 227 parameters in the privateKeyAlgorithm. 229 The value of the the publicKey (if present) SHALL be set to the DER 230 encoding of the SEQUENCE of publicKey values. If this field is 231 present, the number and order of elements SHALL be the same as 232 identified in the sequence of parameters in the privateKeyAlgorithm. 234 The value of the attributes is encoded as usual. 236 3.3. Composite Signatures 238 The use of composite signatures allows for the use of multiple 239 algorithms for authentication. 241 id-pk-compositeSignature OBJECT IDENTIFIER ::= { compositeCrypto 3 } 243 CompositeSignature OBJECT IDENTIFIER ::= SEQUENCE (1..MAX) OF BITSTRING 245 3.4. Generating Composite Signatures 247 When generating a CompositeSignature, the signing entity MUST 248 generate one signature per key that is in the corresponding 249 compositePrivateKey set. 251 The value of the compositeSignature is the DER encoding of the 252 SEQUENCE of BIT STRING where each BIT STRING is the DER 253 representation of the signature generated with one of the private key 254 in the compositePrivateKey set. 256 When signing, the order of the signature MUST respect the order of 257 keys in the compositePrivateKey and compositePublicKey sets. 259 3.5. Verifying Composite Signatures 261 When validating a compositeSignature, the relying party MUST verify 262 at least one of the signatures in the compositeSignature structure 263 and SHOULD verify all of them. 265 The process of validating composite signatures starts with going 266 through the sequence of the signatures and if the inner signature 267 algorithm is supported, the relying party MUST verify the signature 268 with the corresponding public key in the compositePrivateKey. 270 The order of the signatures MUST respect the order of keys in the 271 compositePrivateKey and compositePublicKey sets. 273 4. Use of Composite Crypto in PKIX structures 275 4.1. Use in X.509 Certificates 277 4.2. Use in X.509 CRLs 279 4.3. Use in X.509 OCSP Messages 281 4.4. Use in PKCS#7 283 4.5. Use in PKCS#8 284 4.6. Use in PKCS#12 286 4.7. Use in CMS 288 5. Security Considerations 290 This structures described in this document do not protect the private 291 keys information in any way unless combined with a security protocol 292 or encryption properties of the objects (if any) where the 293 CompositePrivateKey is used (see next Section). 295 Protection of the private key information is vital to public key 296 cryptography. The consequences of disclosure depend on the purpose 297 of the private key. If a private key is used for signature, then the 298 disclosure allows unauthorized signing. If a private key is used for 299 key management, then disclosure allows unauthorized parties to access 300 the managed keying material. The encryption algorithm used in the 301 encryption process must be as 'strong' as the key it is protecting. 303 6. IANA considerations 305 The CMS content type OID is registered in a DoD arc. The ASN.1 306 module OID is TBD. The id-pk-compositeCrypto, id-pk- 307 compositePrivateKey, id-pk-compositePublicKey, and id-pk- 308 compositeSignature OIDs are to be assigned by IANA. The authors 309 suggest to use the id-pkix arc for this usage. 311 7. Acknowledgments 313 The authors would like to thank everybody who provided insightful 314 comments and helped in any form. This document uses a lot of text 315 from similar documents ([RFC3279] and [RFC8410]) as well as [I- 316 D.ietf-lamps-cms-hash-sig]. Thanks go to the authors of those 317 documents. "Copying always makes things easier and less error prone" 318 - [RFC8411]. 320 8. Normative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, 324 DOI 10.17487/RFC2119, March 1997, 325 . 327 Appendix A. ASN.1 Module 328 CompositeCrypto-2009 { iso(1) identified-organization(3) dod(6) internet(1) 329 security(5) mechanisms(5) pkix(7) id-mod(0) TBD } 331 DEFINITIONS IMPLICIT TAGS ::= BEGIN 333 EXPORTS ALL; 335 IMPORTS 336 PUBLIC-KEY, SIGNATURE-ALGORITHM 337 FROM AlgorithmInformation-2009 -- RFC 5911 [CMSASN1] 338 { iso(1) identified-organization(3) dod(6) internet(1) 339 security(5) mechanisms(5) pkix(7) id-mod(0) 340 id-mod-algorithmInformation-02(58) } 342 -- 343 -- Object Identifiers 344 -- 346 id-pk-compositeCrypto OBJECT IDENTIFIER ::= { iso(1) 347 identified-organization(3) dod(6) internet(1) private(4) 348 enterprise(1) OpenCA(18227) Algorithms(2) 1 } 350 id-pk-compositePublicKey OBJECT IDENTIFIER ::= { 351 id-kp-compositeCrypto 1 } 353 id-pk-compositePrivateKey OBJECT IDENTIFIER ::= { 354 id-kp-compositeCrypto 2 } 356 id-pk-compositeSignature OBJECT IDENTIFIER ::= { 357 id-kp-compositeCrypto 3 } 359 END 361 Author's Address 363 Massimiliano Pala 364 CableLabs 365 858 Coal Creek Cir 366 Louisville, CO 80027 367 USA 369 Email: director@openca.org 370 URI: http://www.linkedin.com/in/mpala