Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9295.¶

Copyright Notice

Copyright (c) 2022 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 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.¶

Table of Contents

1.Introduction

[RFC8410] specifies the syntax and semantics for the Subject PublicKey Information field in certificates that support Ed25519, Ed448,X25519, and X448 Elliptic Curve Cryptography (ECC) algorithms. As partof these semantics, it defines what combinations are permissible for thevalues of the keyUsage extension[RFC5280].[RFC8410] did notdefine what values are not permissible, nor did it refer tokeyEncipherment or dataEncipherment.[Err5696] has also been submittedto clarify that keyCertSign is always set in certification authoritycertificates. To address these changes, this document replacesSection 5 of [RFC8410] withSection 3.¶

2.Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3.New Section 5 for RFC 8410

The intended application for the key is indicated in the keyUsagecertificate extension.¶

If the keyUsage extension is present in a certificate that indicatesid-X25519 or id-X448 in SubjectPublicKeyInfo, then the followingMUSTbe present:¶

  keyAgreement

One of the followingMAY also be present:¶

  encipherOnly  decipherOnly

and any of the followingMUST NOT be present:¶

  digitalSignature  nonRepudiation  keyEncipherment  dataEncipherment  keyCertSign  cRLSign

If the keyUsage extension is present in an end-entitycertificate that indicates id-Ed25519 or id-Ed448 inSubjectPublicKeyInfo, then the keyUsage extensionMUST contain at leastone of the following:¶

  nonRepudiation  digitalSignature  cRLSign

and any of the followingMUST NOT be present:¶

  keyEncipherment  dataEncipherment  keyAgreement  keyCertSign  encipherOnly  decipherOnly

If the keyUsage extension is present in a CRL issuer certificate thatindicates id-Ed25519 or id-Ed448 in SubjectPublicKeyInfo, then thekeyUsage extensionMUST contain:¶

  cRLSign

and zero or more of the following:¶

  nonRepudiation  digitalSignature

and any of the followingMUST NOT be present:¶

  keyEncipherment  dataEncipherment  keyAgreement  encipherOnly  decipherOnly

and if the CRL issuer is also a certification authority, then thekeyUsage extensionMUST also contain:¶

  keyCertSign

If the keyUsage extension is present in a certification authoritycertificate that indicates id-Ed25519 or id-Ed448 inSubjectPublicKeyInfo, then the keyUsage extensionMUST contain:¶

  keyCertSign

and zero or more of the following:¶

  nonRepudiation  digitalSignature  cRLSign

and any of the followingMUST NOT be present:¶

  keyEncipherment  dataEncipherment  keyAgreement  encipherOnly  decipherOnly

4.Security Considerations

This document introduces no new security considerations beyond thosefound in[RFC8410].¶

5.IANA Considerations

This document has no IANA actions.¶

Acknowledgments

We would like to thankRuss Housley,Mike Jenkins, andCorey Bonnellfor their comments.¶

Authors' Addresses