wdiff rfc9295.original.xml rfc9295.xml

<?xml version='1.0' encoding='utf-8'?> 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;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

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

<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="Internet-Draft" value="draft-ietf-lamps-8410-ku-clarifications-02"/> 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="June" day="30"/>
    <area>Security</area>
    <workgroup>LAMPS</workgroup>
    <keyword>Internet-Draft</keyword> 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 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 keyUsage extension <xref target="RFC5280"/>.  <xref target="RFC8410"/> did not
define what values are not permissible permissible, nor did it refer to
keyEncipherment or dataEncipherment. <xref target="ERRATA"/> target="Err5696"/> 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"/> 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 14 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>
      <artwork><![CDATA[
  keyAgreement;
]]></artwork>
      <t>one
      <sourcecode name="" type=""><![CDATA[
  keyAgreement
]]></sourcecode>
      <t>One of the following <bcp14>MAY</bcp14> also be present:</t>
      <artwork><![CDATA[
  encipherOnly; or
  decipherOnly;
]]></artwork>
      <sourcecode name="" type=""><![CDATA[
  encipherOnly
  decipherOnly
]]></sourcecode>
      <t>and any of the following <bcp14>MUST NOT</bcp14> be present:</t>
      <artwork><![CDATA[
  digitalSignature;
  nonRepudiation;
  keyEncipherment;
  dataEncipherment;
  keyCertSign; and
  cRLSign.
]]></artwork>
      <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>
      <artwork><![CDATA[
  nonRepudiation;
  digitalSignature; and
  cRLSign;
]]></artwork>
      <sourcecode name="" type=""><![CDATA[
  nonRepudiation
  digitalSignature
  cRLSign
]]></sourcecode>
      <t>and any of the following <bcp14>MUST NOT</bcp14> be present:</t>
      <artwork><![CDATA[
  keyEncipherment;
  dataEncipherment;
  keyAgreement;
  keyCertSign;
  encipherOnly; and
  decipherOnly.
]]></artwork>
      <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>
      <t>~~
  cRLSign;
~~</t>
      <sourcecode name="" type=""><![CDATA[
  cRLSign
]]></sourcecode>
      <t>and zero or more of the following:</t>
      <t>~~
  nonRepudiation; and
  digitalSignature;
~~</t>
      <sourcecode name="" type=""><![CDATA[
  nonRepudiation
  digitalSignature
]]></sourcecode>
      <t>and any of the following <bcp14>MUST NOT</bcp14> be present:</t>
      <t>~~
  keyEncipherment;
  dataEncipherment;
  keyAgreement;
  encipherOnly; and
  decipherOnly;
~~</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>
      <t>~~
  keyCertSign.
~~</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>
      <artwork><![CDATA[
      <sourcecode name="" type=""><![CDATA[
  keyCertSign
]]></artwork>
]]></sourcecode>
      <t>and zero or more of the following:</t>
      <artwork><![CDATA[
  nonRepudiation;
  digitalSignature; and
  cRLSign;
]]></artwork>
      <sourcecode name="" type=""><![CDATA[
  nonRepudiation
  digitalSignature
  cRLSign
]]></sourcecode>
      <t>and any of the following <bcp14>MUST NOT</bcp14> be present:</t>
      <artwork><![CDATA[
  keyEncipherment;
  dataEncipherment;
  keyAgreement;
  encipherOnly; and
  decipherOnly.
]]></artwork>
      <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>
        <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>

<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="ERRATA" target="https://www.rfc-editor.org/errata/eid5696"> anchor="Err5696" target="https://www.rfc-editor.org/errata/eid5696" quote-title="false">
          <front>
            <title>Errata
            <title>Erratum ID 5696</title>
            <author initials="L." surname="Liao" fullname="Lijun Liao">
              <organization/>
            <author>
              <organization>RFC Errata</organization>
            </author>
            <date year="2019" month="April" day="17"/>
            <date/>
          </front>
         <refcontent>RFC 8410</refcontent>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We would like to thank Russ Housley, <contact fullname="Russ Housley"/>, <contact fullname="
Mike Jenkins, Jenkins"/>, and Corey Bonnell <contact fullname="Corey Bonnell"/>
for the their comments.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81YbXPbNhL+jl+x53y565i05dptLN/dRJHViXOynUrKtJlO
pwMRkISIAlgAtKJ6mt9yv+V+2e0CpEVK7tjph5vzF5OLl919nmcXoJIkYV75
XHahn3OrZirjXhntYGYsDMTJ2Vnn/BAfTk9fHsKP1SvXAn5EC/TyubHKL1Zw
JaT2uFxax/h0auVdF7LS3slqSXimJYN+f8cVw/8S99l0wXnBykLgu+vCy9PO
MWPCZJqvMD5h+cwnSvpZkvNV4RIaT5ZlkrV2S45PmCpsF7wtnT85Pj5Hw1Ju
1saKLlxpL62WPrmk3Ri3kndhLDE65TcM5yzn1pRFF4a963djdid1KbsMYI5J
ltMuRM/r+dHjzhlzHsH5hedGY8gb6Zhbcet/+bU0ISdtWKG68JM32SE4Y72V
M4dPm1V8wGxXvCiUnv/MGC/9wlh0n2AEAErjBuMUJiVmYIMpIjOWXDetxs65
Vr+FkBBT/bUVwS5XXOVowOmvgjXNzGp397fGYSTO6KYDtTJ6Z6TtZPz2Enqv
W15ozauP9ZoU57dcXaZwnfU5Br1peLrEPWXeHtnx9GuJrCGRWdp0J8LCV1Ol
ud0U3HJhPqVIdMvnJIUrbxruJlzwhVqaB/OOr0H/9hr6t+khDCeXLX++Wpkq
b9KinOYqezWnoYAp08aucJM7FA9TerZ9oy0Go1Fv0ovPAFX5DazlnsPZN+ff
VAMP9Fd/ycNTlc4whaHipmGOWQ3Vx1I3h6igunBy3DlPjk+Tzre1Z27n0ndh
4X3hukdH6/U6tbMskQKTssTYkQxRHUklQmAsSRLgU+ctzzxjk4VyJNlyhcUP
VeHC6Lt+qF3wBmJ5bEB+Us6jqkPrcIXM0MhWyjmyOcQUm0cWmw7WKpSOzyVM
lXewXkiN71JgzpBJ62O1YWX5BffgyqLAMgK/kE+3q0GeqwIdQZ+6EeujUryZ
W14sNsDrVubSmOZKCZFLxl5Q07BGlBmJgrH7+79ghpTg779XqSjMmgJwG+35
p5hjKycaHJfTjzLz8C6Ihf0L07yqlYHVhZvkezlCK8ed/NgT+UErv79i4/1b
M0uAngOsFM/MjAJ0chv0ISgPQs6UlsQAxoCqptqKZwMVYCFt4G+ayzpFdsfz
EhfE/RpEyk9eakdZRvDOTl4ieBjB/f0WSqEEtkfPotvotdqQ/OFQyydWWFiC
gWLrlBiAoTY/0JkqFjiPFElTUL5NW4o+Y/2hywXHvXNnYCpRZK6crpT3UrCG
cAMBuG8fWRmruQZFS9Z84xAt3+aLEoxFS4dJk0ds2ga4EFY6V2GdLbieS0Ta
t4rIyiLnGeaMh1LY8IzoaeK0RvrQUE1EGEmiE0JGm9zMN1SWEXw68hwcXL8f
Tw4O43+4uQ3Po8H3769Gg0t6Hr/pDYcPD6yaMX5z+354uX3arsSeeD24uYyL
0QotEzu47n04iKI8uH03ubq96Q0PCKh2osSpJ+RxCM/kwkpEHrhD/l1m1TQW
/Ov+u//8u3Na6eak0zlHBKoK7Hx7SnBgf4jejM431StCvGF4jkpuaRee55Dx
QnkkG+cidQuz1oCSkIjeVz8RMj934e/TrOic/rMyUMItY41Zyxgw27fsLY4g
PmJ6xM0Dmi37DtLteHsfWu817g0jqeRGrre6ClX70KvvX9SCivohUrQgRooi
r8VdtzISF3KptAjyFpHdYH9PBd/U/rb4EeqrWWteozHgdigBR8ogwppdMNZg
7cwxJZLY+ai+6YVaHy6qGmzsr9heqbsGKcTgZibPzZrOG2KXofAqh3hEf/78
Gc9EDKs3t1KSPi+CjeE1rm5njfW9D3Xb2NtDVr3mFsV4gQGiSciGKW5Lct2P
iaTw2J5CzUm61H64L628QJs2eiSLUqjAzEWMvtnoyLTb/KppdS+7oLJBUzYa
0msaY3s2RxqTFQld+9vdbocvoqg6uSrCwvGFE9gTjD0SQoApM3jMUgQecsmd
f5SlB/T2kdrDs43Dn+Lo+eg3JNZmY089MaqmfL6UIuiPhmhzJZ6PuwyxZzD0
RE2xJxgK6LSBjbj+Jq0hVytj/4C5feJqOPaK4cvI+vNcPUXONhIVM2qAr6qL
Bv+j68IzQA0b7CDb0E/Kvkwaz7i3/K8quVlFdTrbInxaLP/3Zf7Mun7x8FME
9PGerYS09e8K7U8tVX2RICfagMZj3dULs9ZCzGFjQob4Ic5mptThsG7cJ8P1
8ap303vCJd2V0VeYycMVov5QmvJsSZv0sqU261yKOS1w7L6ry9UU71jiHwcz
FK88wLvFD3izNyV+6eRqGS6AKDG9hFGJF+M3pnS5xFK4prG3Ui/xMzfe7frI
/QZeG61lnrP6HoIfJcFVyv4LJXV01cgSAAA=

-->
</rfc>