LAMPS M. Ounsworth Internet-Draft Entrust Updates: {"RFC5280"=>nil} (if approved) M. Saarinen Intended status: Standards Track PQShield Expires: September 22, 2021 March 21, 2021 External Keys And Signatures For Use In Internet PKI draft-ounsworth-pq-external-pubkeys-00 Abstract Many of the post quantum cryptographic algorithms have either large public keys or signatures. In the interest of reducing bandwidth of transitting X.509 certificates, this document defines new public key and signature algorithms for referencing external public key and signature data by hash, URL, etc. This mechanism is designed to mimic the behaviour of an Authority Information Access extension. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 22, 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Ounsworth & Saarinen Expires September 22, 2021 [Page 1] Internet-Draft External keys and sigs March 2021 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. External Value . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. External Public Key . . . . . . . . . . . . . . . . . . . 3 2.2. External Signature . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 4.1. CSRs and CT logs . . . . . . . . . . . . . . . . . . . . 3 5. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Intellectual Property Considerations . . . . . . . . . . 4 6. Contributors and Acknowledgements . . . . . . . . . . . . . . 4 6.1. Making contributions . . . . . . . . . . . . . . . . . . 4 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction 2. External Value The id-external-value algorithm identifier is used for identifying a public key or signature which is provided as a reference to external data. id-external-value ::= < OID > The corresponding subjectPublicKey is the DER encoding of the following structure: ExternalValue ::= SEQUENCE { location GeneralName, hashAlg AlgorithmIdentifier, hashVal BIT STRING } Upon retrieval of the referenced data, the hash of the OCTET STRING of the retrieved data (removing base64 encoding as per [RFC4648] if necessary) MUST be verified using hashAlg to match the ExternalPublicKey.hash value. Ounsworth & Saarinen Expires September 22, 2021 [Page 2] Internet-Draft External keys and sigs March 2021 2.1. External Public Key When used with a public key, algorithm parameters for id-external- value are absent. When ExternalValue is placed into a SubjectPublicKeyInfo.subjectPublicKey, the ExternalValue.location MUST refer to a DER-encoded SubjectPublicKeyInfo, which MAY be base64 encoded as per [RFC4648] for easier transport over text protocols. 2.2. External Signature When used with a signatureAlgorithm, algorithm parameters are to contain the AlgorithmIdentifier of the signature that is being externalized. When ExternalValue is placed into a signatureValue, the location MUST refer to the BIT STRING of a signatureValue, which MAY be base64 encoded as per [RFC4648] for easier transport over text protocols. 3. IANA Considerations The ASN.1 module OID is TBD. The id-alg-composite OID is to be assigned by IANA. 4. Security Considerations 4.1. CSRs and CT logs In practice, situations will arise where the ExternalPublicKey.location refers to a location which is not publicly available either because it is in a local keystore, on a private network, or no longer being hosted. Not having the public key in a certificate signing request (CSR) could make it substantially harder for CAs to perform vetting of the key, for example for cryptographic strength or checking for prior revocation due to key compromise. A certificate requester MUST make the full public key available to the CA at the time of certificate request either by ensuring that the link in the ExternalPublicKey.location is visible to the CA, or by supplying the full public key to the CA out of band. Not having the public key in Certificate Transparency (CT) logs could make it substantially harder for researchers to perform auditing tasks on CT logs. This may require additional CT mechanisms. Ounsworth & Saarinen Expires September 22, 2021 [Page 3] Internet-Draft External keys and sigs March 2021 5. Appendices 5.1. ASN.1 Module 5.2. Intellectual Property Considerations The following IPR Disclosure relates to this draft: https://datatracker.ietf.org/ipr/3588/ 6. Contributors and Acknowledgements This document incorporates contributions and comments from a large group of experts. The Editors would especially like to acknowledge the expertise and tireless dedication of the following people, who attended many long meetings and generated millions of bytes of electronic mail and VOIP traffic over the past year in pursuit of this document: John Gray (Entrust), Serge Mister (Entrust), Scott Fluhrer (Cisco Systems), Panos Kampanakis (Cisco Systems), Daniel Van Geest (ISARA), and Tim Hollebeek (Digicert). We are grateful to all, including any contributors who may have been inadvertently omitted from this list. This document borrows text from similar documents, including those referenced below. Thanks go to the authors of those documents. "Copying always makes things easier and less error prone" - [RFC8411]. 6.1. Making contributions Additional contributions to this draft are weclome. Please see the working copy of this draft at, as well as open issues at: https://github.com/EntrustCorporation/draft-ounsworth-pq-external- keys 7. Normative References [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . Ounsworth & Saarinen Expires September 22, 2021 [Page 4] Internet-Draft External keys and sigs March 2021 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the Cryptographic Algorithm Object Identifier Range", RFC 8411, DOI 10.17487/RFC8411, August 2018, . Authors' Addresses Mike Ounsworth Entrust Limited 1000 Innovation Drive Ottawa, Ontario K2K 1E3 Canada Email: mike.ounsworth@entrust.com Markku-Juhani O. Saarinen PQShield Email: mjos@pqshield.com Ounsworth & Saarinen Expires September 22, 2021 [Page 5]