<?xml version='1.0' encoding='ascii'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.24 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-ito-documentsigning-eku-00" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en">

  <front>
    <title abbrev="EKU for Document Signing">General Purpose Extended Key Usage (EKU) for Document Signing X.509 Certificates</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="T." surname="Okubo" fullname="Tomofumi Okubo">
      <organization>DigiCert, Inc.</organization>
      <address>
        <email>tomofumi.okubo+ietf@gmail.com</email>
      </address>
    </author>

    <date year="2021" month="April" day="01"/>

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

    <abstract>


<t><xref target="RFC5280" pageno="false" format="default"/> specifies several extended key usages for X.509 certificates. This document defines a general purpose document signing extended key usage for X.509 public key certificates which restricts the usage of the certificates for document signing.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction" numbered="true" toc="default">

<t><xref target="RFC5280" pageno="false" format="default"/> specifies several extended key usages for X.509 certificates. In addition, 
several extended key usage had been added<xref target="RFC7299" pageno="false" format="default"/> as public OID under the IANA repository.
While usage of any extended key usage is bad practice for publicly trusted certificates, 
there are no public and general extended key usage explicitly assigned for Document Signing certificates. 
The current practice is to use id-kp-emailProtection, id-kp-codeSigning or vendor defined Object ID 
for general document signing purposes.</t>

<t>In circumstances where code signing and S/MIME certificates are also widely used for document signing, 
the technical or policy changes that are made to code signing and S/MIME certificates may cause 
unexpected behaviors or have an adverse impact such as 
decreased cryptographic agility on the document signing ecosystem and vice versa.</t>

<t>There is no issue if the vendor defined OIDs are used in a PKI (or a trust program) governed by the vendor.
However, if the OID is used outside of the vendor governance, the usage can easily become out of control
(e.g. - When the end user encounters vendor defined OIDs, they might want to ask that vendor about use of the certificate, however, the vendor may not know about the particular use. - If the issuance of the cert is not under the control of the OID owner, there is no way for the OID owner to know what the impact will be if any change is made to the OID in question, and it would restrict vendor's choice of OID management. etc.).
<!--&#20309;&#12364;&#21839;&#38988;&#12363;&#12434;&#12289;&#19978;&#12395;&#26360;&#12356;&#12383;&#12290;--></t>

<t>Therefore, it is not favorable to use a vendor defined EKU for signing a document that is not governed by the vendor.</t>

<t>This document defines a general Document Signing extended key usage.</t>

</section>
<section anchor="conventions-and-definitions" title="Conventions and Definitions" numbered="true" toc="default">

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

</section>
<section anchor="extended-key-usage-for-documentsigning" title="Extended Key usage for DocumentSigning" numbered="true" toc="default">
<t>This specification defines the KeyPurposeId id-kp-documentSigning.
Inclusion of this KeyPurposeId in a certificate indicates that the
use of any Subject names in the certificate is restricted to use by a document signing.</t>

<t>Term of "Document Sign" in this paper is digitaly signing human readable data or data that is intended to be human readable by means of services and software.</t>

<section anchor="extended-key-usage-values-for-document-signing" title="Extended Key Usage Values for Document Signing" numbered="true" toc="default">
<t><xref target="RFC5280" pageno="false" format="default"/> specifies the EKU X.509 certificate extension for use in the Internet.  The extension indicates one or more purposes for which the certified public key is valid.  The EKU extension can be used in conjunction with the key usage extension, which indicates how the public key in the certificate is used, in a more basic cryptographic way.</t>

<t>The EKU extension syntax is repeated here for convenience:</t>

<figure title="" suppress-title="false" align="left" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
    ExtKeyUsageSyntax  ::=  SEQUENCE SIZE (1..MAX) OF KeyPurposeId
    KeyPurposeId  ::=  OBJECT IDENTIFIER
</artwork></figure>

<t>This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the use of any Subject names in the certificate is restricted to use by a document signing service or a software (along with any usages allowed by other EKU values).</t>

<!-- the use of any Subject names in the certificate is restricted to use by a document signing service or a software. &#12371;&#12428;&#12399;&#12381;&#12398;&#12414;&#12414;&#12391;&#12356;&#12356;&#12392;&#24605;&#12358;&#65311;-->

<figure title="" suppress-title="false" align="left" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
    id-kp  OBJECT IDENTIFIER  ::=
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) 3 }
    id-kp-documentSigning  OBJECT IDENTIFIER  ::=  { id-kp XX }
</artwork></figure>

</section>
</section>
<section anchor="implications-for-a-certification-authority" title="Implications for a Certification Authority" numbered="true" toc="default">
<t>The procedures and practices employed by a certification authority MUST ensure that the correct values for the EKU extension are inserted in each certificate that is issued.
Unless certificates are governed by a vendor specific PKI (or trust program), certificates that indicate usage for document signing MAY include the id-kp-documentSigning EKU extension. This does not encompass the mandatory usage of the id-kp-documentSigning EKU in conjunction with the vendor specific EKU. However, this does not restrict the CA from including multiple EKUs related to document signing.</t>

</section>
<section anchor="security-considerations" title="Security Considerations" numbered="true" toc="default">
<t>The Use of id-kp-documentSigning EKU can prevents the usage of id-kp-emailProtection for none-email purposes and  id-kp-codeSigning for signing objects other than binary codes. An id-kp-documentSigning EKU value does not introduce any new security or privacy concerns.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations" numbered="true" toc="default">

<t>The id-kp-documentSigning purpose requires an object identifier (OID).  The objects are defined in an arc delegated by IANA to Limited Additional Mechanisms for PKIX and SMIME (lamps).  No further action is necessary by IANA.</t>

</section>


  </middle>

  <back>

    <references title="Normative References">





<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quote-title="true">
<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="RFC7299" target="https://www.rfc-editor.org/info/rfc7299" quote-title="true">
<front>
<title>Object Identifier Registry for the PKIX Working Group</title>
<author initials="R." surname="Housley" fullname="R. Housley"><organization/></author>
<date year="2014" month="July"/>
<abstract><t>When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was allocated by IANA for use by that working group.  This document describes the object identifiers that were assigned in that arc, returns control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.</t></abstract>
</front>
<seriesInfo name="RFC" value="7299"/>
<seriesInfo name="DOI" value="10.17487/RFC7299"/>
</reference>



<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quote-title="true">
<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" quote-title="true">
<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>




    </references>



<!--
# Acknowledgments
{:numbered="false"}

TODO acknowledge.
-->

<!--
# Apendix

~~~
id-ce-extKeyUsage OBJECT IDENTIFIER ::=  {joint-iso-itu-t(2) ds(5) certificateExtension(29) extKeyUsage(37)}
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER

DEFINITIONS IMPLICIT TAGS ::=
BEGIN
    OID Arcs
        id-kp  OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 }
    Extended Key Usage Values
        id-kp-docSigning  OBJECT IDENTIFIER  ::=  { id-kp XX }
END
~~~
-->



  </back>

<!-- ##markdown-source:
H4sIAKUtZmAAA71YTY8bSRm+96+onRywhd3MTDZkY7EIZ8ZJTGbGsxkPG0Bo
Ve4u25Xp7upUdY9jookyEeIAKyGB9oTQihNISHDdA/BnvKzEib/A81Z1t9sf
A7uwu9FIaXfX+/28X9Vut71MZpHosJ2HIhGaR+w016kygvVeZCIJRcgeizk7
N3wiWKP3+LzJxkqzQxXksUgydiYniUwm7Kl/Z/ceOxA6k2MZ8EyYHY+PRlpc
gjXItlLteKEKEh5DfKj5OGvLTLXD4pBxZ9riIm/v7nrEc6L0vMNkMlaeJ1Pd
YZnOTba/u3tvd9/jWvAOOxNBrmU292ZKX0y0ytMO6yehvJRhDuO8CzHHl5Be
ZkInImsfkmTPMxlPwg94pBJoMxfGMzHX2QfPcwVbOixRXio77MeZClrMKJ1p
MTZ4msf08BPP43k2VbrjsbbH8E8mIBr6rJ8p+9tZOeQhn8oLVb1WesIT+VOe
SZVA+d7B4JgdDPwWOxoe+vaEiLmMYGlB6cNFfpqPIhl8b0Kf/EDF60IHF/lo
RayK1TiPZe3DquBDOZEUuxbcEqzKLUh9RaTflCIb1+R6XrvdZnxkMs0DOPHl
y7eePDi4s//O7tUVM6kIAAZhmBGXFlqihBSiwHKClLG4cOAJauDx2XAqDSux
wEIxlglOczYpYJoWMK2OFHjZIqQmw3nOfqqLY7OpDKZMCxgig8ywbCoKWjW2
P1ZOE791uT5zzohlGEbC824RwrQK84Bc/KW6pp8wHoaS+LaYdzMHNuUhGwlh
j4vQaXB3/949aMBN6YtB/5DlINTWzn73pAs/wLUAmp773vtTGdV8wZP5NkmI
1QjCUoKBDJzHHf9o7rIUx+tWQHGI04IhbZFcpTLIwSrCW8SIFylOoWDNYQA5
Hl+3lqNVh3lDimCuNR2pdITOmQJjPIXti7RtEX+qke+Bc617HahQlGwh6hI6
UfgtIEM2GD3DcQYfeqRIqfsGKgu4Gt/zEL5AanynkhNY8JEjSE51nPxw9q3j
/nFvFXnkLR4ZxWYyFBG5pfDAukDnXwZbpgloI1I9VXAegD/lCcErm/LMMow5
JMMVn0uDmIMDJ695eYJ4wHpBKJvyS6m0ITl4hJaEOiCT3BuncDkzOVIMuPNC
EaBWk+aBnqeZmmieTin4ExmhdDOVWChuZnagzBxIiq1ylxRDEsDh06F1ISIK
KEljcjy7vF0PV//QOdE6TkJHdvq4zxo4wh1OgQ9SKG6yibqkDgHj5jVWvvdI
zSjlWqUISiBIthxVjr4VVlWjkO44UbBbtcoSwEVwg0QYRzAtFkRNlIGiyhF5
DeGjrLTZ+1PhPAJuJEbjIVA5NTCzzUArZI5KNJlmbMbhQQSXmwsX8YKAj0ga
xXGzwrXYtLSxZgVFPlEZu0jUrCCnrynapAzyiGviRvr2HUOKA9lcF+BClNUK
TmFseYicqWZJIbqK6QyyCeYrR8gsq8yM7LIiHdJmMorgUwoQ1SsHeOJUIr0K
W8Ke5yj6Nt0JVBLEKo/CqhUUxn/DgIuSzhiijHmCGBI8fSaywG/63nfearc/
/dtHi+sP//HRr/75+w8X179cvPn14vX1p5/8YnH9p89++8ni+meL648Xr9+0
298tMAuj4G5ZOWbML5Xmo0iUtYmvR7gcpqpEXSaKjW/B6Cb0ev+tsW7U0s06
7FN7O1AJeJLrjHXdIXGyTclY2+xxmrUM2zk+PxvutNz/7GRgn5/03jvvP+kd
0vPZo+7RUfVQnjh7NDg/wneveFpSYkw67p0cOmK8ZWuvjrs/3HEB3RmcDvuD
k+7RDgU7g+1eZTvVAXiZgEK5lGpBpQwVKhQm0HLkKsT9g1O29zZz3XN/b4+6
p/vxzt7dt6+uPJTvAj0qQS67nzYDeZoKpAWVGQAy4KnMULxbJMIgwxJGCIAz
4c2VaXs5tZTBKGLhgldMD4Ed3qoIUpBBXIzv/bBoX+EqBx/tJ4hyQ5Q25cBv
lYpqYq0W4EVYlP6sSDOvqBqUW2e5a4A0aBrnYrFKbqpcgnUFqIFJvjlBATZC
x8R5ZwWEVehQa1KkPeEXAyt8Oa+yYJojIyEJYzIlT8gzTq3I/l+mBUXZ+tgF
fY0EOsWCA8yQjxpL7cUB26hxNuM2ULdubVuLfsCjvBjX1pMHY9+2qY+cRHm8
Md25ZLPRIXZ2OHE+LfcVnzFKruW5ZXywupDNMUpKNW9YNm66rUUG6tcmYbjm
kkcyLFiTYkv21KVGy36Jcv0sT+yAhDKbOa71Aa2gaxVCl9oB8K5f1ARvhQuJ
ajkcWlNG6JHB2qiAfuC6/pq2Zp5k/IUDHXKPIGe7CHkhsAVLoneKjue9evXK
7jmIJyJpA3nmiFmn8y7DLvbeee/koMfO+j/qscae7x93nzbZ4MFKulgWK/nj
qAf3v987GGIs7J0M+w/6vSdW3peQvuz/T1/21aRvmTTMzlJl0rAGrdQThxWS
WOw2KIgYMWx3UtTobRwvbSKhldpe+rXr6rPF9W8Wb9C4/7K4/t3i+s+L67/b
vz/Yxo2/P372Gu9//q+/fmw7eIkhG6otQbdgsCfo30soqBp7TRynvklZ2K6v
4Y3bTSgaNr7ddP0IyY7TFTmD0u5uo3GniVJFU400saFf6YV80bjbZLfZ1VKh
dezcpKDVzFrw9CnoLVCxvca0anHX38fWT8vbHYJf11540FULpSGm5kCEuS5q
ZrlkGSbAR81dpOvIJBa8ZMHsYIAczqkllzgNFDY2GsGW9TXbyHjCmEwQz8wV
KMFRdeqoqKo/rQWh750nkTBmc62qD0zV0FXmarUlrO4IrVU2TlSRcLUuvgE/
zCc4h0SmcXQqbojXiqHVjYhw8x2tAJh2jasc6GRodVjYV28tbuZ7Uylftxtn
ffZouQ3UVahmZCI86LKxVnFhFomJ8yiTaWQDRpkZ8SIttzT+W9XFHc2VtELp
AnoWXeeuCtxsDnUpzG80kK5d3mzd7W1UEvRL92HZLQm7W/b++rytbBUyRdlC
yNEfZcLheqIwPusm/0FRi+WlC2VxRyRshUvErEpyu7BreclpY1foWToxblS0
VzSrXnKtcLvU8qJMi+e5dPlZ2LAsRJo1sNQ0iwGgtJCyotw6qK9QsgV4E4mJ
DSUSxeqCkB7JWNKrbnEvhT3iuKpQ1n1IoKfuUsHeKTQiHqeGJJ4oNs61dSZ3
waENRqB2GHJqIcR3t2sjHly47gBHdAPa/iIRTux9sfeyk+TxCO0+fHdnjEFb
7FzBMYPDARiXJzHF2dJdskiBd/nClXL4LwAilgPBloLp6uUzhcC1Uc7bMsvb
WWMfldsW4lo56JWZ29i/12Q1ro3bd5tX3ubcQaw/59Sx0vKJbnPe8A57D/on
fVp+zlj/+PSof9AfsmH34ZltSvd7D/sntlfQNtvVgakazY3djAT9b03sC7Su
G+frVf0I5l+sr2E5tFGm8P8bjjHL9PgYAAA=

-->

</rfc>
