<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Dimitris:<br class=""><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" cite="mid:AF3E4F13-AECA-42E0-B8B2-E8D92F91D6FE@vigilsec.com" class=""><div class="">
<div class="">
<blockquote type="cite" class="">
<blockquote type="cite" cite="mid:SG2PR03MB314512BC0746B4596852A3E2F0319@SG2PR03MB3145.apcprd03.prod.outlook.com" style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; orphans:
auto; text-align: start; text-indent: 0px; text-transform:
none; white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<div class="WordSection1" style="page: WordSection1;">
<div style="margin: 0in; font-size: 11pt; font-family:
Calibri, sans-serif;" class="">Let me try one other
angle. For TLS certs to be trusted and for them to be
in scope of the BRs, the root programs and browsers
require that the CA have server auth in order to issue
TLS certificates or they won’t be trusted. They are
also outside the scope of the BRs and those CAs do not
need to be audited as TLS CAs. The rule to have EKUs
in the CA is not RFC based, but rather browser/root
program based and these applications check the
hierarchy to be sure that a cert with serverAuth was
issued from a root and CA with those permissions.<o:p class=""></o:p></div>
<div style="margin: 0in; font-size: 11pt; font-family:
Calibri, sans-serif;" class=""><o:p class=""> </o:p></div>
<div style="margin: 0in; font-size: 11pt; font-family:
Calibri, sans-serif;" class="">Not all EKUs are
treated this way, but a few are, and secure mail I
think is one of them. Would an email client reject
the use of a cert issued from a CA with only the
document signing EKU? Is issuance of compliant SMIME
certs limited to those CAs technically capable of
issuing them (those with secure mail EKU in them)? If
so, then perhaps those document signing applications
that need the secure mail EKU but do not need to
actually send secure mail can continue since these are
issued from CAs outside the scope of the SMIME WG
spec.<o:p class=""></o:p></div>
<div style="margin: 0in; font-size: 11pt; font-family:
Calibri, sans-serif;" class=""><o:p class=""> </o:p></div>
<div style="margin: 0in; font-size: 11pt; font-family:
Calibri, sans-serif;" class="">Is this logic also
flawed?</div>
</div>
</blockquote>
<br style="caret-color: rgb(0, 0, 0); font-family:
Helvetica; font-size: 12px; font-style: normal;
font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
text-decoration: none;" class="">
<span style="caret-color: rgb(0, 0, 0); font-family:
Helvetica; font-size: 12px; font-style: normal;
font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
text-decoration: none; float: none; display: inline
!important;" class="">Definitely not flawed, this is a
complicated topic so there is not one right answer. In my
understanding, certificate consumers of S/MIME
Certificates have several choices:</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<ol style="caret-color: rgb(0, 0, 0); font-family:
Helvetica; font-size: 12px; font-style: normal;
font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
text-decoration: none;" class="">
<li class="">Rely on the KU of the end-entity certificate
(usually the digitalSignature bit) alone, no EKU
extension<br class="">
</li>
<li class="">Rely on the KU AND the
keyPurposeId:id-kp-emailProtection in the EKU extension</li>
<li class="">Rely on the KU AND the
keyPurposeId:id-kp-emailProtection in the EKU extension
AND ensure the Issuing CA also includes an EKU extension
which includes the<i class=""><span class="Apple-converted-space"> </span></i><i class="">id-kp-</i><i class="">emailProtection<span class="Apple-converted-space"> </span></i>keyPurposeId</li>
</ol><p style="caret-color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; text-decoration: none;" class="">Option 3 is kind of described in section<span class="Apple-converted-space"> </span><a moz-do-not-send="true" href="https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12" style="color: blue; text-decoration: underline;" class="">4.2.1.12</a><span class="Apple-converted-space"> </span>of
RFC 5280 but as you noticed, it's probably not supported
by all email clients. That doesn't mean the S/MIME Working
Group should not set policy requirements if clients don't
take advantage of them.</p>
</blockquote>
<div class="">I disagree. Section 4.2.1.12 of RFC 5280 says: "In
general, this extension will appear only in end entity
certificates." I think that option 3 should be taken off
the list.</div>
<div class=""><br class="">
</div>
<div class="">I realize that many implementations use the EKU extension
as a path constraint, but it was never intended to be used
that way. <br class="">
</div>
</div>
</div>
</blockquote>
<br class="">
Sorry for the late reply :)<br class="">
<br class="">
If it was never intended to be used that way, the language would not
say "in general,". The option was clearly left open, purposely. The
following paragraph from section 4.2.1.12 makes it very clear that
the option to "restrict" exists.<br class="">
<br class="">
<pre class="newpage"> If a CA includes extended key usages to satisfy such applications,
but does not wish to restrict usages of the key, the CA can include
the special KeyPurposeId anyExtendedKeyUsage in addition to the
particular key purposes required by the applications. </pre>
<br class="">
There is already a precedent of the CA EKU extension being used as a
path constraint for Public Internet services and despite its
problems, it has proved to be quite effective in terms of setting at
least the policy scope. Technical implementations can take it one
step further and protect Relying Parties with additional
restrictions using the EKU extension as a tool to constrain the
path.<br class=""></div></div></blockquote><div><br class=""></div>I think you are misunderstanding the point of that paragraph. The CA includes KeyUsage to limit the cryptographic operations that can be performed with the certified key, and the CA includes ExtendedKeyUsage to limit the applications that the certified public key supports.</div><div><br class=""></div><div>Neither X.509 nor RFC 5280 suggests that ExtendedKeyUsage has any impact on certification path construction or validation. BasicConstraints, NameConstraints, and PolicyConstraints are examples of certificate extension there were intended to do that. As a result, they are all discussed in Section 6 of RFC 5280. KeyUsage does get discussed in Section 6 to ensure the certified key is appropriate for signing certificates and CRLs.</div><div><br class=""></div><div>I do not expect this note to change anyone's mind (or implementation).</div><div><br class=""></div><div>Russ</div><div><br class=""></div></body></html>