Change:
changes are followings We accepeted your comment We accepeted your comment we stop using term "trust program" and changed as following "KeyPurposeIds are used in a PKI governed by the vendor or a set of specific group of vendors." "Unless certificates are governed by a vendor(s) specific PKI, certificates that indicate usage for document signing.." We accepeted your comment >(e.g. - When the end user encounters... >Editorially, please split this large "(e.g.," text block into distinct sentences. we divided the sentence, and clarified the relationship between KeyPurposeIds owning vendor and another vendor. We accepeted your comment We accepeted your comment prescribed behavior for RFC8358. We accepeted your comment We accepeted your comment as follows We removed secound MAY, and numbering. We further clarified the " outside of scope" case where it is up to software. We clarified order of "Excluded KeyPurposeId procedure" and Permitted KeyPurposeId procedure. we accept your change and changed as follow. "TLS (id-kp-clientAuth) or S/MIME (id-kp-emailProtection) etc."

Discussion:
RFC5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates.  In addition, several <del> KeyPurposeIds have been added RFC7299 under the IANA repository "SMI Security for PKIX Extended Key Purpose".  While usage of the </del> <ins> KeyPurposeIds have been added under the IANA repository "SMI Security for PKIX Extended Key Purpose" RFC7299.  While usage of the </ins> "anyExtendedKeyUsage" KeyPurposeId is bad practice for publicly trusted certificates, there is no public and general KeyPurposeId explicitly assigned for Document Signing.  The current practice is to

KeyPurposeId for general document signing purposes. In circumstances where code signing and S/MIME certificates are also <del> 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. </del> <ins> used for document signing, technical or policy changes made to the code signing and S/MIME ecosystem may cause unexpected behaviors or have an adverse impact such as decreased cryptographic agility on the document signing ecosystem and vice versa. </ins> There is no issue if the vendor-defined KeyPurposeIds are used in a <del> PKI (or a trust program) governed by the vendor.  However, if the KeyPurposeId is used outside of vendor governance, the usage can easily become out of control (e.g. - When the end user encounters vendor-defined KeyPurposeIds, 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 KeyPurposeId owner, there is no way for the KeyPurposeId owner to know what the impact will be if any change is made to the KeyPurposeId in question, and it would restrict vendor's choice of OID management.  etc.). </del> <ins> PKI governed by the vendor or a set of specific group of vendors. However, if the KeyPurposeId is used outside of vendor governance, the usage can easily become out of control.  For instance, when the end user encounters certificates with vendor-defined KeyPurposeIds, they might want to ask that vendor about use of the certificate. However, if those certificates were not governed by the KeyPurposeIds owner but by another vendor, the vender who own the KeyPurposeIds may not able to control use, or even do not know about the use. - If the issuance of the cert is not under the control of the KeyPurposeIds owner, it is hard to estimate the impact of change to made on the KeyPurposeId.  Changes related to KeyPurposeIds possibly make negative impacts that some group of people do not tolerate, and it could become a migration agility issue. </ins> Therefore, it is not favorable to use a vendor-defined KeyPurposeId for signing a document that is not governed by the vendor. <del> This document defines a extended key purpose identifier for Document </del> <ins> This document defines an extended key purpose identifier for Document </ins> Signing. 2.

This specification defines the KeyPurposeId id-kp-documentSigning. <del> As described in RFC5280, If the Extended Key Usage extension is </del> <ins> As described in RFC5280, "[i]f the [Extended Key Usage] extension is </ins> present, then the certificate MUST only be used for one of the <del> purposes indicated.  RFC5280 also describes that If multiple key purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. </del> <ins> purposes indicated."  RFC5280 also describes that "[i]f multiple [key] purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present." </ins> Document Signing applications MAY require that the Extended Key Usage extension be present and that the id-kp-documentSigning be indicated

4. <del> RFC8358 specifies the conventions for digital signatures on Internet- Drafts.  This is one of the intended use cases for the general document signing key purpose described in this document.  RFC8358 uses CMS to digitally sign a wide array of files such as ASCII, PDF, EPUB, HTML etc.  Currently, there are no specification regarding key purposes for certificates signing those files except those which are defined by the software vendor. </del> The signed contents of Internet-Drafts are primarily intended to be consumed by people.  To be more precise, contents are intended to be shown to a person in a printable or displayable form by means of

consumed by people, implementations MAY perform the steps below during certificate validation: <del> The implementation MAY examine the KeyPurposeId(s) included in the Extended Key Usage extension as follows: A Restriction on Extended Key Usage is derived and implemented from (or configured with) the policy to which the implementation conforms. </del> <ins> The following procedure is used to examine the KeyPurposeId(s) included in the Extended Key Usage extension.  Restrictions on Extended Key Usage is derived and implemented from (or configured with) the policy to which the implementation conforms. </ins> If there are no restrictions set for the relying party and the relying party software, the certificate is acceptable.

party software, then process the KeyPurposeId(s) as described below. <del> Each restriction on "Excluded KeyPurposeId" or "Permitted KeyPurposeId" is handled as described below. </del> This procedure is intended to permit or prohibit presence of a certain KeyPurposeId or complete absence of KeyPurposeIds.  It is outside the scope of this document, but the relying party can <del> permit or prohibit combinations of KeyPurposeIds.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document. </del> <ins> permit or prohibit combinations of KeyPurposeIds, instead of single KeyPurposeId.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document.  If both "Excluded KeyPurposeId" and "Permitted KeyPurposeId" exists, the relying party or the relying party software proresses each restriction on "Excluded KeyPurposeId" first, and then processes each restriction on "Permitted KeyPurposeId". </ins> "Excluded KeyPurposeId" is a KeyPurposeId which the relying party or the relying party software prohibits.  Examples of

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 <del> governed by a vendor specific PKI (or trust program), certificates that indicate usage for document signing MAY include the id-kp- documentSigning KeyPurposeId.  The inclusion of the id-kp- documentSigning KeyPurposeId does not preclude the inclusion of other KeyPurposeIds. </del> <ins> governed by a vendor(s) specific PKI, certificates that indicate usage for document signing MAY include the id-kp-documentSigning KeyPurposeId.  The inclusion of the id-kp-documentSigning KeyPurposeId does not preclude the inclusion of other KeyPurposeIds. </ins> 6.

binary code.  This extended key purpose does not introduce new security risks but instead reduces existing security risks by providing means to separate other extended key purposes used for <del> communication protocols namely, TLS or S/MIME etc. in order to minimize the risk of cross-protocol attacks. </del> <ins> communication protocols namely, TLS (id-kp-clientAuth) or S/MIME (id- kp-emailProtection) etc.  in order to minimize the risk of cross- protocol attacks. </ins> To reduce the risk of specific cross-protocol attacks, the relying party or relying party software may additionally prohibit use of