idnits 2.17.1 draft-ounsworth-pq-external-pubkeys-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 90: '... necessary) MUST be verified using h...' RFC 2119 keyword, line 100: '... MUST refer to a DER-encoded Subject...' RFC 2119 keyword, line 109: '...to a signatureValue, the location MUST...' RFC 2119 keyword, line 110: '... a signatureValue, which MAY be base64...' RFC 2119 keyword, line 130: '...se. A certificate requester MUST make...' == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2021) is 1124 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) == Unused Reference: 'RFC5280' is defined on line 185, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 8411 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS M. Ounsworth 3 Internet-Draft Entrust 4 Updates: {"RFC5280"=>nil} (if approved) M. Saarinen 5 Intended status: Standards Track PQShield 6 Expires: September 22, 2021 March 21, 2021 8 External Keys And Signatures For Use In Internet PKI 9 draft-ounsworth-pq-external-pubkeys-00 11 Abstract 13 Many of the post quantum cryptographic algorithms have either large 14 public keys or signatures. In the interest of reducing bandwidth of 15 transitting X.509 certificates, this document defines new public key 16 and signature algorithms for referencing external public key and 17 signature data by hash, URL, etc. This mechanism is designed to 18 mimic the behaviour of an Authority Information Access extension. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 22, 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. External Value . . . . . . . . . . . . . . . . . . . . . . . 2 56 2.1. External Public Key . . . . . . . . . . . . . . . . . . . 3 57 2.2. External Signature . . . . . . . . . . . . . . . . . . . 3 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 60 4.1. CSRs and CT logs . . . . . . . . . . . . . . . . . . . . 3 61 5. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 4 63 5.2. Intellectual Property Considerations . . . . . . . . . . 4 64 6. Contributors and Acknowledgements . . . . . . . . . . . . . . 4 65 6.1. Making contributions . . . . . . . . . . . . . . . . . . 4 66 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 2. External Value 73 The id-external-value algorithm identifier is used for identifying a 74 public key or signature which is provided as a reference to external 75 data. 77 id-external-value ::= < OID > 79 The corresponding subjectPublicKey is the DER encoding of the 80 following structure: 82 ExternalValue ::= SEQUENCE { 83 location GeneralName, 84 hashAlg AlgorithmIdentifier, 85 hashVal BIT STRING 86 } 88 Upon retrieval of the referenced data, the hash of the OCTET STRING 89 of the retrieved data (removing base64 encoding as per [RFC4648] if 90 necessary) MUST be verified using hashAlg to match the 91 ExternalPublicKey.hash value. 93 2.1. External Public Key 95 When used with a public key, algorithm parameters for id-external- 96 value are absent. 98 When ExternalValue is placed into a 99 SubjectPublicKeyInfo.subjectPublicKey, the ExternalValue.location 100 MUST refer to a DER-encoded SubjectPublicKeyInfo, which MAY be base64 101 encoded as per [RFC4648] for easier transport over text protocols. 103 2.2. External Signature 105 When used with a signatureAlgorithm, algorithm parameters are to 106 contain the AlgorithmIdentifier of the signature that is being 107 externalized. 109 When ExternalValue is placed into a signatureValue, the location MUST 110 refer to the BIT STRING of a signatureValue, which MAY be base64 111 encoded as per [RFC4648] for easier transport over text protocols. 113 3. IANA Considerations 115 The ASN.1 module OID is TBD. The id-alg-composite OID is to be 116 assigned by IANA. 118 4. Security Considerations 120 4.1. CSRs and CT logs 122 In practice, situations will arise where the 123 ExternalPublicKey.location refers to a location which is not publicly 124 available either because it is in a local keystore, on a private 125 network, or no longer being hosted. 127 Not having the public key in a certificate signing request (CSR) 128 could make it substantially harder for CAs to perform vetting of the 129 key, for example for cryptographic strength or checking for prior 130 revocation due to key compromise. A certificate requester MUST make 131 the full public key available to the CA at the time of certificate 132 request either by ensuring that the link in the 133 ExternalPublicKey.location is visible to the CA, or by supplying the 134 full public key to the CA out of band. 136 Not having the public key in Certificate Transparency (CT) logs could 137 make it substantially harder for researchers to perform auditing 138 tasks on CT logs. This may require additional CT mechanisms. 140 5. Appendices 142 5.1. ASN.1 Module 144 5.2. Intellectual Property Considerations 146 The following IPR Disclosure relates to this draft: 148 https://datatracker.ietf.org/ipr/3588/ 150 6. Contributors and Acknowledgements 152 This document incorporates contributions and comments from a large 153 group of experts. The Editors would especially like to acknowledge 154 the expertise and tireless dedication of the following people, who 155 attended many long meetings and generated millions of bytes of 156 electronic mail and VOIP traffic over the past year in pursuit of 157 this document: 159 John Gray (Entrust), Serge Mister (Entrust), Scott Fluhrer (Cisco 160 Systems), Panos Kampanakis (Cisco Systems), Daniel Van Geest (ISARA), 161 and Tim Hollebeek (Digicert). 163 We are grateful to all, including any contributors who may have been 164 inadvertently omitted from this list. 166 This document borrows text from similar documents, including those 167 referenced below. Thanks go to the authors of those documents. 168 "Copying always makes things easier and less error prone" - 169 [RFC8411]. 171 6.1. Making contributions 173 Additional contributions to this draft are weclome. Please see the 174 working copy of this draft at, as well as open issues at: 176 https://github.com/EntrustCorporation/draft-ounsworth-pq-external- 177 keys 179 7. Normative References 181 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 182 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 183 . 185 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 186 Housley, R., and W. Polk, "Internet X.509 Public Key 187 Infrastructure Certificate and Certificate Revocation List 188 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 189 . 191 [RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the 192 Cryptographic Algorithm Object Identifier Range", 193 RFC 8411, DOI 10.17487/RFC8411, August 2018, 194 . 196 Authors' Addresses 198 Mike Ounsworth 199 Entrust Limited 200 1000 Innovation Drive 201 Ottawa, Ontario K2K 1E3 202 Canada 204 Email: mike.ounsworth@entrust.com 206 Markku-Juhani O. Saarinen 207 PQShield 209 Email: mjos@pqshield.com