Change:
Addressing Lars' .
Debating adding more context than just "document". Thanks to Dale Worley for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/1T23l8-kN8pEMqnQvh1ir3MsGVw). Did you mean "documents" here instead of "Internet-Drafts"? All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. File types are normally capitalized. A period is needed after the abbreviation "etc.".

Discussion:
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 <del> owner but by another vendor, the vender who own the KeyPurposeIds may </del> <ins> owner but by another vendor, the vendor who own the KeyPurposeIds may </ins> 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

4. <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 services or software, rather than processed by machines.  The digital signature on the contents is to indicate to the recipient of the contents that the content has not changed since it was signed by the identity indicated as the subject of the certificate.  To validate the digital signature which is signed on contents intended to be consumed by people, implementations MAY perform the steps below during certificate validation: </del> <ins> Our intended use case is people consuming the contents of signed documents.  To be more precise, contents are intended to be shown to a person in a printable or displayable form by means of services or software, rather than processed by machines.  The digital signature on the contents is to indicate to the recipient of the contents that the content has not changed since it was signed by the identity indicated as the subject of the certificate.  To validate the digital signature which is signed on contents intended to be consumed by people, implementations MAY perform the steps below during certificate validation: </ins> The following procedure is used to examine the KeyPurposeId(s) included in the Extended Key Usage extension.  Restrictions on

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 <del> party software proresses each restriction on "Excluded </del> <ins> party software processes each restriction on "Excluded </ins> KeyPurposeId" first, and then processes each restriction on "Permitted KeyPurposeId".

When a single application has the capability to process various data formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling <del> (e.g.  text, pdf, etc). </del> <ins> (e.g., TEXT, PDF). </ins> 5.