<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
I kind of agree with Wendy, however if a requirement is clear from
the TLS BRs and applicable to the S/MIME BRs, it would be best to
copy it over. If it's not clear we should improve. It it's not
applicable, we should definitely update or remove :-)<br>
<br>
Dimitris.<br>
<br>
<div class="moz-cite-prefix">On 31/8/2022 2:37 μ.μ., Wendy Brown -
QT3LB-C via Smcwg-public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:01000182f3b12411-097498a7-196e-4e1f-886c-8c6167efec75-000000@email.amazonses.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Stephen -
<div>This document is about SMIME certificates not TLS.</div>
<div>Just because there is language in the TLS BRs that was
initially copied into the document as a start is no reason
that it has to remain in tis document if it is clearly about
TLS certificates and not related to SMIME certificates, or if
it is unclear. I thought the idea was to create baseline
requirements related to SMIME certificates.</div>
<div><br>
</div>
<div>Thanks,<br clear="all">
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<p class="MsoNormal"><span
style="font-family:"Segoe
Script",sans-serif">Wendy</span></p>
<p class="MsoNormal"><br>
</p>
<p class="MsoNormal">Wendy Brown</p>
<p class="MsoNormal">Supporting GSA</p>
<p class="MsoNormal">FPKIMA Technical Liaison</p>
<p class="MsoNormal">Protiviti Government
Services</p>
<span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">703-965-2990
(cell)</span><br>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Aug 30, 2022 at 4:22
PM Stephen Davidson <<a
href="mailto:Stephen.Davidson@digicert.com"
moz-do-not-send="true" class="moz-txt-link-freetext">Stephen.Davidson@digicert.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-msg-637178470846013499">
<div style="overflow-wrap: break-word;" lang="EN-US">
<div class="gmail-m_-637178470846013499WordSection1">
<p class="MsoNormal">Hello Wendy –</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thanks for your input. Responses
inline below.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Regards, Stephen</p>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><b> </b></p>
<p class="MsoNormal">1.3.2 #4 - It seems
to me that a Delegated Party must
comply with the CA’s CP regardless of
whether or not they have a separate
document to follow since trust stores
will be evaluating CAs based on the
CA's CP/CPS and may not have
visibility into all Delegated Parties’
Practice statements.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> Standard
language from TLS BR</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"
style="margin-bottom:12pt">1.3.2.1#2
- If the CA is doing the mailbox
validation, then the Enterprise RA is
not involved, and this sentence is
misplaced. "If the Certificate Request
is for a Mailbox-validated profile,
the CA SHALL confirm that the mailbox
holder has control of the requested
Mailbox Address(es) in accordance with
Section 3.2.2.2."</p>
<p class="MsoNormal">On the other hand
if the Enterprise RA is doing the
validation of the mailbox, maybe
because they have assigned the mailbox
to the individual, the CA only needs
to ensure that the Enterprise has
control of the email domain.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"
style="margin-bottom:12pt">>>
Sentence was previously requested to
clarify that Mailbox-validation may
only be done by CA, not Enterprise RA.</p>
<p class="MsoNormal">Normally 1.3.5
would be about other participants
assisting in the operation of a CA
rather than just writing the document
- however if this context is
appropriate for the BRs, I'm OK - but
why are only specific Associate
Members called out here - that makes
it read as though all other
non-voting participants do endorse
& approve of the final product and
that may not necessarily be the case. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">1.3.5 Other
participants</p>
<p class="MsoNormal">Other groups that
have participated in the development
of these Requirements include the CPA
Canada WebTrust for Certification
Authorities task force and the
Accredited Conformity Assessment
Bodies’ Council (ACAB’C).
Participation by these groups does not
imply their endorsement,
recommendation, or approval of the
final product.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> Based on
standard language from TLS BR</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Definition of
Applicant - it would read better as
"Once the Certificate is issued"
instead of "Once the Certificate
issues"</p>
<p class="MsoNormal">And the example is
out of place in a document about SMIME
certificates - "For Certificates
issued to devices, the Applicant is
the entity that controls or operates
the device named in the Certificate,
even if the device is sending the
actual Certificate Request."</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> Standard
language from TLS BR. Language does
apply to email gateways.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">4.9.5 #4 The
example is not relevant for SMIME
certificates and should be deleted:</p>
<p class="MsoNormal">The entity making
the complaint (for example, a
complaint from a law enforcement
official that a Web site is engaged in
illegal activities should carry more
weight than a complaint from a
consumer alleging that they didn't
receive the goods they ordered); </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> Standard
language from TLS BR</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">4.12.1 - Should
something be said about certificates
that contain non-repudiation should
NOT be escrowed?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> We did
discuss this in early versions – and
it was agreed to stick to a baseline
here and that enhancements to the key
escrow section would likely be a
subject for future ballots.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">6.2.1 or 6.2.7
Should place some requirements on the
storage of subscriber private keys</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> Future
discussion.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">6.3.2 - Why is 825
Days still listed? I thought Apple
relaxed their requirement why are we
maintaining it here as there seemed to
be a lot of disagreement with the
shorter validity period for
certificates where the private key is
held in hardware and can’t easily
support automated renewal.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> This was
discussed at length with Certificate
Consumers indicating a preference to
move to shorter validity periods.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">7.1 - Please
explain the requirement for
"non-sequential Certificate serial
numbers greater than zero (0) and less
than 2^159 containing at least 64 bits
of output from a CSPRNG" – I
understood its purpose with SHA-1 –
but not SHA-2 or beyond. There is no
reason to retain this just because it
is in the serverAuth BRs unless there
is a good security reason for it.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> comes from
Mozilla. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">7.1.2 There has
been so much discussion in the
serverauth group of whether the BRs
should be read as default deny or not,
that I think it needs to be made
clear that if an extension is not
mentioned it may still be included –
for example SIA should be allowed on
Root CA certificates and Subordinate
CA certificates so that PKIs may make
use of monitoring tools that may build
from the top down. As long as these
extension are not critical, it should
not impact consumers.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> see
7.1.2.4</p>
<p class="MsoNormal"> - </p>
<p class="MsoNormal">7.1.4.2.5 - user id
and dnQualifier should be listed as
MAY at least for the legacy as I
believe they are used today in order
to distinguish subjectDN within an
organization.<br>
Trying to get organizations to
standardize on the serialNumber in the
future might be OK but don’t break
current implementations with the
Legacy profile.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> In Legacy
generation other attributes are
allowed (bottom line of table)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">8.4 the Delegated
3rd Party practices may be optional
but even if optional if they exist,
they still need to comply with the
CA’s CP/CPS</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> see 1.3.2,
text has also been improved.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">8.4 I think the
following should be deleted, unless
the 3 year cycle is actually required
by existing CAs. I believe it
originally came into the BRs due to an
old FPKI practice of allowing a
triennial audit that is no longer
allowed.</p>
<p class="MsoNormal">However, if the CA
or Delegated Party is under the
operation, control, or supervision of
a Government Entity and the audit
scheme is completed over multiple
years, then the annual audit SHALL
cover at least the core controls that
are required to be audited annually by
such scheme plus that portion of all
non-core controls that are allowed to
be conducted less frequently, but any
non-core control SHALL NOT be audited
less often than once every three
years.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> Thank you
for highlighting this; have removed
and suggested changes at the TLS BR at
<a
href="https://github.com/cabforum/servercert/issues/387"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/cabforum/servercert/issues/387</a>
</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">8.6 #3 - The audit
should be about CAs & their
operations not just the CA
certificate.<br>
It is equally, if not more important,
to actually list the CA Name</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> Based on
standard language from TLS BR</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">8.6 #4 - Again –
the audit should have been about the
CA – not just an audit of a CA
certificate</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> Based on
standard language from TLS BR</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">9.6.1 #2i
- Presumably either the subject or an
authorized rep requested the cert, not
necessarily both in all cases</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> correct</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">9.6.3 #4 I believe
this is too strict – maybe only with
Mailboxes list in the Certificate or
under the control of the subject
identified in the cert. At least 1
current large email system allows the
use of unrelated certificates – a
capability that many may rely on (I
know I do)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> The intent
is to restrict the use of certs to the
associated mailboxes.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">9.6.3#6 - may be
too strict – what about the case of
encryption certs the corresponding
private key can still be used to
decrypt previously received emails</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> Based on
standard language from TLS BR updated
for context – and the sense is to
prevent future use of
known-compromised keys.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Smcwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Smcwg-public@cabforum.org">Smcwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/smcwg-public">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a>
</pre>
</blockquote>
<br>
</body>
</html>