<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-turner-5480-ku-clarifications-00" category="std" updates="5480">

  <front>
    <title abbrev="Clarifications for ECC SPKI">Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information</title>

    <author initials="T." surname="Ito" fullname="Tadahiko Ito">
      <organization>SECOM CO., LTD.</organization>
      <address>
        <email>tadahiko.ito.public@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Turner" fullname="Sean Turner">
      <organization>sn3rd</organization>
      <address>
        <email>sean@sn3rd.com</email>
      </address>
    </author>

    <date />

    <area>Security</area>
    <workgroup>TBD</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document updates RFC 5480 to specify semantics for the keyEncipherment
and dataEncipherment key usage bits when used in certificates that support Elliptic
Curve Cryptography.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t><xref target="RFC5480"/> specifies the syntax and semantics for the Subject Public Key
Information field in certificates that support Elliptic Curve Cryptography.  As part
of these semantics, it defines what combinations are permissible for the values
of the key usage extensions <xref target="RFC5280"/>.  <xref target="RFC5480"/> specifies  7 of the 9
values; it makes no mention of keyEncipherment and dataEncipherment key
usage bits.  This document corrects this omission, but updating Section 3 of
<xref target="RFC5480"/> to include semantics for these two key usages.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in
all capitals, as shown here.</t>

</section>
<section anchor="updates-to-section-3" title="Updates to Section 3">

<t>If the keyUsage extension is present in a certificate that indicates id-ecPublicKey as algorithm of AlgorithmIdentifier <xref target="RFC2986"/> in SubjectPublicKeyInfo, then following values MUST NOT be present:</t>

<figure><artwork><![CDATA[
  keyEncipherment; and
  dataEncipherment.
]]></artwork></figure>

<t>If the keyUsage extension is present in a certificate that indicates id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following values also MUST NOT be present:</t>

<figure><artwork><![CDATA[
  keyEncipherment; and
  dataEncipherment.
]]></artwork></figure>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This document introduces no new security considerations beyond those found in
<xref target="RFC5480"/>.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document makes no request of IANA.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC5480" target='https://www.rfc-editor.org/info/rfc5480'>
<front>
<title>Elliptic Curve Cryptography Subject Public Key Information</title>
<author initials='S.' surname='Turner' fullname='S. Turner'><organization /></author>
<author initials='D.' surname='Brown' fullname='D. Brown'><organization /></author>
<author initials='K.' surname='Yiu' fullname='K. Yiu'><organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<author initials='T.' surname='Polk' fullname='T. Polk'><organization /></author>
<date year='2009' month='March' />
<abstract><t>This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography.  This document updates Sections 2.3.5 and 5, and the ASN.1 module of &quot;Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile&quot;, RFC 3279.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5480'/>
<seriesInfo name='DOI' value='10.17487/RFC5480'/>
</reference>



<reference  anchor="RFC5280" target='https://www.rfc-editor.org/info/rfc5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author>
<date year='2008' month='May' />
<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" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<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>



<reference  anchor="RFC2986" target='https://www.rfc-editor.org/info/rfc2986'>
<front>
<title>PKCS #10: Certification Request Syntax Specification Version 1.7</title>
<author initials='M.' surname='Nystrom' fullname='M. Nystrom'><organization /></author>
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'><organization /></author>
<date year='2000' month='November' />
<abstract><t>This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process.  The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2986'/>
<seriesInfo name='DOI' value='10.17487/RFC2986'/>
</reference>




    </references>




  </back>

<!-- ##markdown-source:
H4sIAGkUIV0AA61VXW/bNhR956+4y3NkOGm2JioK1LU91GgSp7FSYBiGgZKu
bc4yqZFUXC1IfvsOJcWxkwzdQ/1ikuL9OufcyyiKhFe+4JhoWEir5iqTXhnt
aG4sjYtClV5lNKzsLdPQ1qU3Cy/LZU2zKv2LM09XVVrgxmeuaaJhtG7shUxT
y7fxq16HQ5pdfZ6I3GRarhE7t3LuI19ZzTb6+eS0H62qKNuzjPp9kUuPy3ej
QTK+FzjnhbF1TM7noirDRxdTsBZClTYmbyvnj/v9s/6xkJZlTDPOKqt8LTbG
rhbWVGVMyceRWHGNkzxGBZ6RhI9GISMhnJc6/1MWRiNwzU6UKqbfvckOyRnr
Lc8dVvU6LP4QQlZ+aWwsKBKEn9JIKOnRxJtm3xabyFwu1cpsj41dSK3+aepE
juPh9IKG094hnSejXnOD11IVKKiz7ClvemWD+4dF+NTLzHov6KxHSYPmTtwZ
S717uh/W6Tc23w3mcP1Dc9p4F7ql9pZjwPtIdLOLoohk6ryVGSBLlsoRmK3W
rD11vND1r8OGGvKGXMmZmteIsJYa6mpV4ZdM4GGsM1Uu2QZrAfAJ9nL3MFyi
yskFU6q8o82SNfaco3LK2PpWM4jpl9KTq8oSTG2lLPakbIOUe20Ja5XnBQsB
DViTV1kj4/dC3N39hOxD8vf3Xe6q8c5gXnv5jUKaL4t52SBip0EITor/mTO9
kjPRwFEprRdmHsI5fkrhkJSnnOdKc8AHHsFgqnTXg+gFKgGmck6lBW8TvpVF
BYm3/nZg5m+etWtMOyyOAxZI4e7uNWToLXU+zkTr811IaC1X+KgNBRYDArj0
jHD6L8LFE+EIuy+xzFgLnAN2ODZNWUYfUlp18lN6ETq/ifkGUcVu2tCj0llR
5fySQmDqN+YJCQelJAE4bQqzqIM4kg6pMD4cHVzczJKDw/afLqfN+nr85WZy
PR6F9ezT4Px8u2hvCGymN+fd97B6ssQouBhfjlpjnNKzo4vBb/gDauJgepVM
ppeD84OgKb+HUCAcdaaMT5hvpWWPdpG4wS6zKm16R3wcXtHRSUfx8dHRGdBp
N6dHb0+wCZ3WBCOji7rbAqaaZFmytMGJLArKZKm8LCBDhHBLs9EEKhng3XTT
AMlsCQkoTraSu9lXHKEMpOtCFShL7jZL2ytK513rqDzirG228BghtizwQCi/
XAepDR43kzzoD0q1j7Wenf6C8uC/a9mtk9CvTYloV1MUZhOk1EqaHikOsHYp
YhY+PDxgiD6T9buGIXqh7F64/vAjyx99wlhvlxdfvn6npBDzRVngzfyw2oR4
fHFpiPGhcrbtDGpbZ1ejqpu67YjQvEE7dqbZnilyqg00iJfWhfwr3ah3p6ch
tMngcvDdkNuBZPlvlO6DSoJh9x6kMluJfwGOyfFjIQkAAA==

-->

</rfc>

