External Keys For Use In Internet X.509 Certificates

Internet-Draft	External X.509 Keys	October 2023
Ounsworth, et al.	Expires 5 April 2024	[Page]

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 5 April 2024.¶

Copyright Notice

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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

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 OBJECT IDENTIFIER  ::=  { iso(1)
            identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) algorithms(6)
            TBDOID }

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:¶

ExternalValue ::= SEQUENCE {
  location     GeneralNames,
  hashAlg      AlgorithmIdentifier,
  hashVal      OCTET 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.¶

GeneralNames is defined in [!RFC5280] as¶

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

which we use instead of GeneralName so that certificate issuers can specify multiple backup key servers for high availability or specify key identifiers in multiple formats if the corresponding public keys will be distributed in multiple keystore formats. When multiple key locations are specified, they MUST represent alternative locations for retrieval of the same key and MUST NOT be used as a mechanism to place multiple subject keys into a single certificate. Thus, when multiple key locations are specified, the client MAY try them in any order and stop when it successfully retrieves a public key whose hash matches hashVal.¶

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.¶

3. IANA Considerations

## Object Identifier Allocations¶

3.1. Module Registration - SMI Security for PKIX Module Identifier

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

3.1.1. Object Identifier Registrations - SMI Security for PKIX Algorithms

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

4. 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. For this reason, external public key data MAY be served over an insecure channel such as HTTP.¶

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.¶

5. Appendices

5.1. ASN.1 Module

EXTERNAL-PUBKEY-2023
           {iso(1) identified-organization(3) dod(6) internet(1) security(5)
       mechanisms(5) pkix(7) id-mod(0) id-mod-external-pubkey(TBDMOD)}

DEFINITIONS IMPLICIT TAGS ::= BEGIN

EXPORTS ALL;

IMPORTS

  GeneralNames
  FROM PKIX1Implicit-2009
      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}

  AlgorithmIdentifier{}
  FROM AlgorithmInformation-2009
      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) id-mod(0)
      id-mod-algorithmInformation-02(58)}

;

id-external-value OBJECT IDENTIFIER  ::=  { iso(1)
            identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) algorithms(6)
            TBDOID }

ExternalValue ::= SEQUENCE {
  location     GeneralNames,
  hashAlg      AlgorithmIdentifier,
  hashVal      OCTET STRING
}

END

5.2. 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:¶

subjectPublicKeyInfo SubjectPublicKeyInfo SEQUENCE (2 elem)
      algorithm AlgorithmIdentifier SEQUENCE (1 elem)
        algorithm OBJECT IDENTIFIER 1.3.6.1.4.1.22554.4.2 ExternalValue
      subjectPublicKey BIT STRING (704 bit)
        SEQUENCE (3 elem)
          SEQUENCE (1 elem)
            [6] (35 byte) file://local_keyserver/surveyors.db
          SEQUENCE (1 elem)
            OBJECT IDENTIFIER 2.16.840.1.101.3.4.2.1 sha-256
          OCTET STRING (32 byte) D0AD4FE39E9690C08E4...

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:¶

SEQUENCE (2 elem)
  SEQUENCE (1 elem)
    OBJECT IDENTIFIER 1.3.6.1.4.1.22554.5.6.3 Kyber1024
  BIT STRING (12544 bit) 001111000100000101000

The following trust anchor certificate can be used to validate the above end entity certificate.¶

5.3. Intellectual Property Considerations

None.¶

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:¶

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" - [RFC8411].¶

6.1. 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¶

7. Normative References

[RFC4648]: Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.
[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, <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC8411]: Schaad, J. and R. Andrews, "IANA Registration for the Cryptographic Algorithm Object Identifier Range", RFC 8411, DOI 10.17487/RFC8411, August 2018, <https://www.rfc-editor.org/rfc/rfc8411>.

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

J. Gray

Entrust

Email: john.gray@entrust.com

D. Hook

KeyFactor

Email: david.hook@keyfactor.com