]> Entrust Limited

1000 Innovation Drive Ottawa, Ontario K2K 1E3 Canada mike.ounsworth@entrust.com

PQShield

mjos@pqshield.com

Entrust

john.gray@entrust.com

KeyFactor

david.hook@keyfactor.com

LAMPS Internet-Draft 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction

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. EDNOTE: for prototyping purposes, id-external-value ::= 1.3.6.1.4.1.22554.4.2 The corresponding subjectPublicKey is the DER encoding of the following structure: Upon retrieval of the referenced data, the hash of the OCTET STRING of the retrieved data (removing base64 encoding as per if necessary) MUST be verified using hashAlg to match the ExternalPublicKey.hash value.

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 for easier transport over text protocols.

IANA Considerations ## Object Identifier Allocations

Module Registration - SMI Security for PKIX Module Identifier

• Decimal: IANA Assigned - Replace TBDMOD
• Description: EXTERNAL-PUBKEY-2023 - id-mod-external-pubkey
• References: This Document

Object Identifier Registrations - SMI Security for PKIX Algorithms

• Attest Statement
  • Decimal: IANA Assigned - Replace TBDOID
  • Description: id-external-value
  • References: This Document

Security Considerations There are no security implications to externalizing a public key from a certificate as described in this draft. It is of course possible for a malicious actor to replace or tamper with the public key data at the referenced location, but since the hash of the public key data is included in the signed certificate, any such tampering will be detected and the certificate verification will fail.

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.

Appendices

ASN.1 Module

Samples Here is a sample of a Kyber1024 end entity certificate with an external public key. A trust anchor certificate using the algorithm ecdsaWithSHA256 is provided so that the Kyber1024 End Entity certificate can be verified. This is a modest example demonstrating a 550 byte Kyber1024 certificate and a 2.2 kb external Kyber1024 public key. This "compression" effect will be even more pronounced with algorithms such as Classic McEliece which have public keys in the hundreds of kilobytes; with the external public key mechanism, the size of the certificate remains constant regardless of how large the externalized subject public key is. End entity Kyber1024 Certificate with ExternalValue public key: For illustrative purposes, the SubjectPublicKeyInfo within the end entity certificate decodes as: The external public key object referenced by the end entity certificate is: For illustrative purposes, the key data, which is itself a SubjectPublicKeyInfo, decodes as: The following trust anchor certificate can be used to validate the above end entity certificate.

Intellectual Property Considerations None.

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: Serge Mister (Entrust). 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" - .

Making contributions Additional contributions to this draft are welcome. Please see the working copy of this draft at, as well as open issues at: https://github.com/EntrustCorporation/draft-ounsworth-pq-external-keys

Normative References This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.