<?xml version="1.0" encoding="UTF-8"?>

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.11 (Ruby 3.1.2) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-8410-ku-clarifications-02" number="9295" submissionType="IETF" category="std" consensus="true" updates="8410" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.12.10 -->
  <front>
    <title abbrev="curve25519, curve448 ECC Clarifications">Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers</title>
    <seriesInfo name="RFC" value="9295"/>
    <author initials="S." surname="Turner" fullname="Sean Turner">
      <organization>sn3rd</organization>
      <address>
        <email>sean@sn3rd.com</email>
      </address>
    </author>
    <author initials="S." surname="Josefsson" fullname="Simon Josefsson">
      <organization>SJD AB</organization>
      <address>
        <email>simon@josefsson.org</email>
      </address>
    </author>
    <author initials="D." surname="McCarney" fullname="Daniel McCarney">
      <organization>Square Inc.</organization>
      <address>
        <email>daniel@binaryparadox.net</email>
      </address>
    </author>
    <author initials="T." surname="Ito" fullname="Tadahiko Ito">
      <organization>SECOM CO., LTD.</organization>
      <address>
        <email>tadahiko.ito.public@gmail.com</email>
      </address>
    </author>
    <date year="2022" month="September"/>
    <area>sec</area>
    <workgroup>lamps</workgroup>

<keyword>PKIX</keyword>
<keyword>X.509</keyword>
<keyword>keyUsage</keyword>
<keyword>Elliptic Curve Cryptography</keyword>

    <abstract>
      <t>This document updates RFC 8410 to clarify existing semantics, and specify
missing semantics, for key usage bits when used in certificates
that support the Ed25519, Ed448, X25519, and X448 Elliptic Curve
Cryptography algorithms.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="RFC8410"/> specifies the syntax and semantics for the Subject Public
Key Information field in certificates that support Ed25519, Ed448,
X25519, and X448 Elliptic Curve Cryptography (ECC) algorithms.  As part
of these semantics, it defines what combinations are permissible for the
values of the keyUsage extension <xref target="RFC5280"/>.  <xref target="RFC8410"/> did not
define what values are not permissible, nor did it refer to
keyEncipherment or dataEncipherment. <xref target="Err5696"/> has also been submitted
to clarify that keyCertSign is always set in certification authority
certificates. To address these changes, this document replaces 
<xref target="RFC8410" section="5"/> with <xref target="replace"/>.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
       <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="replace">
      <name>New Section 5 for RFC 8410</name>
      <t>The intended application for the key is indicated in the keyUsage
certificate extension.</t>
      <t>If the keyUsage extension is present in a certificate that indicates
id-X25519 or id-X448 in SubjectPublicKeyInfo, then the following <bcp14>MUST</bcp14>
be present:</t>
      <sourcecode name="" type=""><![CDATA[
  keyAgreement
]]></sourcecode>
      <t>One of the following <bcp14>MAY</bcp14> also be present:</t>
      <sourcecode name="" type=""><![CDATA[
  encipherOnly
  decipherOnly
]]></sourcecode>
      <t>and any of the following <bcp14>MUST NOT</bcp14> be present:</t>
      <sourcecode name="" type=""><![CDATA[
  digitalSignature
  nonRepudiation
  keyEncipherment
  dataEncipherment
  keyCertSign
  cRLSign
]]></sourcecode>
      <t>If the keyUsage extension is present in an end-entity
certificate that indicates id-Ed25519 or id-Ed448 in
SubjectPublicKeyInfo, then the keyUsage extension <bcp14>MUST</bcp14> contain at least
one of the following:</t>
      <sourcecode name="" type=""><![CDATA[
  nonRepudiation
  digitalSignature
  cRLSign
]]></sourcecode>
      <t>and any of the following <bcp14>MUST NOT</bcp14> be present:</t>
      <sourcecode name="" type=""><![CDATA[
  keyEncipherment
  dataEncipherment
  keyAgreement
  keyCertSign
  encipherOnly
  decipherOnly
]]></sourcecode>
      <t>If the keyUsage extension is present in a CRL issuer certificate that
indicates id-Ed25519 or id-Ed448 in SubjectPublicKeyInfo, then the
keyUsage extension <bcp14>MUST</bcp14> contain:</t>
      <sourcecode name="" type=""><![CDATA[
  cRLSign
]]></sourcecode>
      <t>and zero or more of the following:</t>
      <sourcecode name="" type=""><![CDATA[
  nonRepudiation
  digitalSignature
]]></sourcecode>
      <t>and any of the following <bcp14>MUST NOT</bcp14> be present:</t>
      <sourcecode name="" type=""><![CDATA[
  keyEncipherment
  dataEncipherment
  keyAgreement
  encipherOnly
  decipherOnly
]]></sourcecode>
      <t>and if the CRL issuer is also a certification authority, then the
keyUsage extension <bcp14>MUST</bcp14> also contain:</t>
      <sourcecode name="" type=""><![CDATA[
  keyCertSign
]]></sourcecode>
      <t>If the keyUsage extension is present in a certification authority
certificate that indicates id-Ed25519 or id-Ed448 in
SubjectPublicKeyInfo, then the keyUsage extension <bcp14>MUST</bcp14> contain:</t>
      <sourcecode name="" type=""><![CDATA[
  keyCertSign
]]></sourcecode>
      <t>and zero or more of the following:</t>
      <sourcecode name="" type=""><![CDATA[
  nonRepudiation
  digitalSignature
  cRLSign
]]></sourcecode>
      <t>and any of the following <bcp14>MUST NOT</bcp14> be present:</t>
      <sourcecode name="" type=""><![CDATA[
  keyEncipherment
  dataEncipherment
  keyAgreement
  encipherOnly
  decipherOnly
]]></sourcecode>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document introduces no new security considerations beyond those
found in <xref target="RFC8410"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8410.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="Err5696" target="https://www.rfc-editor.org/errata/eid5696" quote-title="false">
          <front>
            <title>Erratum ID 5696</title>
            <author>
              <organization>RFC Errata</organization>
            </author>
            <date/>
          </front>
         <refcontent>RFC 8410</refcontent>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We would like to thank <contact fullname="Russ Housley"/>, <contact fullname="
Mike Jenkins"/>, and <contact fullname="Corey Bonnell"/>
for their comments.</t>
    </section>
  </back>
</rfc>
