<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.5 (Ruby 3.0.3) -->
<?rfc docmapping="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-8410-ku-clarifications-01" category="std" consensus="true" updates="8410" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.3 -->
  <front>
    <title abbrev="curve25519, curve448 ECC Clarifications">Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-8410-ku-clarifications-01"/>
    <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="April" day="01"/>
    <area>Security</area>
    <workgroup>LAMPS</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document updates RFC 8410 to clarify existing 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>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-lamps-8410-ku-clarifications/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/lamps-wg/8410-ku-clarifications"/>.</t>
    </note>
  </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 key usage 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="ERRATA"/> has also been submitted
to clarify that keyCertSign is always set in certification authority
certificates. To address these changes, this document replaces Section 5
of <xref target="RFC8410"/> 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 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>
      <artwork><![CDATA[
  keyAgreement;
]]></artwork>
      <t>one of the following <bcp14>MAY</bcp14> also be present:</t>
      <artwork><![CDATA[
  encipherOnly; or
  decipherOnly;
]]></artwork>
      <t>and the following <bcp14>MUST NOT</bcp14> be present:</t>
      <artwork><![CDATA[
  digitalSignature;
  nonRepudiation;
  keyEncipherment;
  dataEncipherment;
  keyCertSign; and
  cRLSign.
]]></artwork>
      <t>If the keyUsage extension is present in an end-entity or CRL issuer
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>
      <artwork><![CDATA[
  nonRepudiation;
  digitalSignature; and
  cRLSign;
]]></artwork>
      <t>and the following <bcp14>MUST NOT</bcp14> be present:</t>
      <artwork><![CDATA[
  keyEncipherment;
  dataEncipherment;
  keyAgreement;
  keyCertSign;
  encipherOnly; and
  decipherOnly.
]]></artwork>
      <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>
      <artwork><![CDATA[
  keyCertSign
]]></artwork>
      <t>and zero or more of the following:</t>
      <artwork><![CDATA[
  nonRepudiation;
  digitalSignature; and
  cRLSign;
]]></artwork>
      <t>and the following <bcp14>MUST NOT</bcp14> be present:</t>
      <artwork><![CDATA[
  keyEncipherment;
  dataEncipherment;
  keyAgreement;
  encipherOnly; and
  decipherOnly.
]]></artwork>
    </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>
        <reference anchor="RFC8410">
          <front>
            <title>Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson">
              <organization/>
            </author>
            <author fullname="J. Schaad" initials="J." surname="Schaad">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves.  The signature algorithms covered are Ed25519 and Ed448.  The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8410"/>
          <seriesInfo name="DOI" value="10.17487/RFC8410"/>
        </reference>
        <reference anchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper">
              <organization/>
            </author>
            <author fullname="S. Santesson" initials="S." surname="Santesson">
              <organization/>
            </author>
            <author fullname="S. Farrell" initials="S." surname="Farrell">
              <organization/>
            </author>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen">
              <organization/>
            </author>
            <author fullname="R. Housley" initials="R." surname="Housley">
              <organization/>
            </author>
            <author fullname="W. Polk" initials="W." surname="Polk">
              <organization/>
            </author>
            <date month="May" year="2008"/>
            <abstract>
              <t>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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="ERRATA" target="https://www.rfc-editor.org/errata/eid5696">
          <front>
            <title>Errata 5696</title>
            <author initials="L." surname="Liao" fullname="Lijun Liao">
              <organization/>
            </author>
            <date year="2019" month="April" day="17"/>
          </front>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We would like to thank Russ Housley, Mike Jenkins, and Corey Bonnell
for the comments.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAFNyRmIAA9VXX1MbNxB/16fYkpe2wxlMIQmm7cQx7oTUQGo702QymYx8
km3FZ+ki6TAXJvks/Sz9ZN2V7uAO6CTtQ2fKC7qVtP9+v92VkyRhXvlM9mCQ
cavmKuVeGe1gbiwMxd7BQfdwGxf7+4+34VX1ybWAVyiBfrYwVvnlGk6E1B6v
S+sYn82svOhBWtgLWV0Ja7oyHAxumWL4X6KesgfOC1bkAr9dDx7vd3cZEybV
fI3+CcvnPlHSz5OMr3OX0H6yKpK0pS3Z7TKV2x54Wzi/t7t7uLvHVrLcGCt6
cKK9tFr65Ji0MW4l78FEonfKlwzPrBbWFHkPRv3TFxN2IXUhewxggUEWsx5E
y5vFzv3GGXMek/OOZ0ajy6V0zK259e8+FCbEpA3LVQ/eeJNugzPWWzl3uCrX
cYHRrnmeK714yxgv/NJYNJ+gBwBKo4JJB6YFRmCDKGZmIrluSo1dcK0+Bpcw
p/oHK4JcrrnKUIDHnwRpJzXr29qfG4eeOKObBtTa6Fs7bSOT58fQf9qyQnee
vK/vdPB8y9RxB07TAUeny4alY9Qps/bOLUsfCkQNgUw7TXMiXHwyU5rbMueW
C3PZQaBbNqcdOPGmYW7KBV+qlbkW37I1HJyfwuC8sw2j6XHLnq9udpQ3nbyY
ZSp9sqCtkFOmjV2jkgskD1N6fvNFKobjcX/aj2uAqvyG1nLP4eDh4cNq4xr+
6i+5XlXhjDowUtw0xDGqkXpf6OYWFVQP9na7h8nuftJ9VFvmdiF9D5be5663
s7PZbDp2niZSYFCWENuRwasdqURwjCVJAnzmvOWpZ2y6VI4oW6yx+KEqXBj/
Mgi1C95ALI8S5KVyHlkdWofLZYpCtlbOkcxhTrF5pLHpYK1C4fhCwkx5B5ul
1PgtBcYMqbQ+VhtWll9yD67Icywj8Ev55XY1zDKVoyEYUDdiA2SKNwvL82UJ
vG5lrhPDXCshMsnYA2oa1ogiJVIwdnX1DUZIAX76VIWiMGpywJXa88sYYysm
2pwUs/cy9fAikIX9imGe1MzA6kIl2Z0YoRXjrfjYF+KDVnzfYuP9rhklQN8B
VopnZk4OOnnj9DYoD0LOlZaEAPqArKbairOBCjCXNuA3y2QdIrvgWYEXor4G
kPLSS+0oypi8g73HmDz04OrqJpVCCWyPnkWz0WqlkOzhVssmVli4go5i65To
gKE2P9Spypd4jhhJR5C+TVkHbcb6Q5NLjrozZ2AmkWSumK2V91KwBnEDAKh3
gKhM1EKDoisbXjrMlm/jRQHGoqVh0sQRm7YBLoSVzlW5TpdcLyRm2reKyMo8
4ynGjEMpKDwgeJp52iB8KKgOYhqJolPKjDaZWZRUljH5NPIcbJ2+nEy3tuN/
ODsP6/Hwt5cn4+ExrSfP+qPR9YJVJybPzl+Ojm9WNzexJ54Oz47jZZRCS8S2
TvuvtyIpt85fTE/Oz/qjLUpUO1DC1FPmcQtncm4lZh64Q/xdatUsFvzTwYs/
/+juV7zZ63YPMQNVBXYf7VM6sD9Ea0ZnZfWJKS4ZzlHJLWnhWQYpz5VHsPEs
Qrc0Gw1ICYnZ+/4NZeZtD36cpXl3/+dKQAG3hHXOWsKQs7uSO5djEu8R3WPm
Opst+a1Mt/3tv25913lvCIklZ3Jzw6tQtde9+upBTajIHwJFC0Ikz7Oa3HUr
I3IhlkqLQG8R0Q3yl1TwTe7fFD+m+mTeOtdoDKgOKeCIGQRYswvGGqyNOaZE
Ejsf1Td9UOvDS1WDjf0V2yt110CF6NzcZJnZ0LwhdBkSrzKII/rz5884E9Gt
/sJKSfw8CjKGz7i6nTXu91/XbeOODln1mnMk4xE6iCIhG6Koluh61yeiwn06
hVoQdan9cF9YeYQybfRY5oVQAZmj6H2z0ZHodvOrjtW97IjKBkXpeESfnejb
V2OkMViR0LPflwTFYDzCI67AV+jfo0eAVXOsgi8MMzzAvoDfPQ6FpKUGhy75
4yGT3Pl7MbvO5d283cluOyv/CrGvx6JBuDY2d7gUvWqS6Z8C9jWj6r+Cq5mq
OuabTH+U1pC9tbH/Vyy/ErwH178+YYBPKyWkrX9Ktl/XqnqEIibagMZO7uqL
aesixlCaECH+9mJzU+jQnxtPiPBiOOmf9b9gkp5HaCuc5GFq1G/jGU9XpKSf
rrTZZFIs6IJjVz1drGc4VsVPW3NskXILx8nv+JgzBT5uM7UKMx8pplcwLvAt
9MwULpPlNpzS3nOpV/jLJo7zAWJfwlOjtcwyVo8efIcGUx32F9x/Yde7EAAA

-->

</rfc>
