<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe Script \,sans-serif";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=en-SE link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'>Regarding 4.9.5 specifically I’d say part of the example itself is still relevant, but not all of it. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><br>Maybe we just replace <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><br>“</span><span style='font-family:"Calibri",sans-serif'>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); and</span><span lang=EN-US style='font-family:"Calibri",sans-serif'>”<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri",sans-serif'>with<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri",sans-serif'><br>“</span><span style='font-family:"Calibri",sans-serif'>The entity making the complaint (for example, a complaint from a law enforcement official should carry more weight than a complaint from a consumer); and</span><span lang=EN-US style='font-family:"Calibri",sans-serif'>”<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=en-SE style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Smcwg-public <smcwg-public-bounces@cabforum.org> <b>On Behalf Of </b>Dimitris Zacharopoulos (HARICA) via Smcwg-public<br><b>Sent:</b> Wednesday, 31 August 2022 13:57<br><b>To:</b> Wendy Brown - QT3LB-C <wendy.brown@gsa.gov>; SMIME Certificate Working Group <smcwg-public@cabforum.org>; Stephen Davidson <Stephen.Davidson@digicert.com><br><b>Subject:</b> Re: [Smcwg-public] a few remaining comments on the SMIME BRs that I still have not seen addressed<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div style='border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt'><p class=MsoNormal style='line-height:12.0pt;background:#FAFA03'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:black'>CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'>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.<o:p></o:p></p><div><p class=MsoNormal>On 31/8/2022 2:37 μ.μ., Wendy Brown - QT3LB-C via Smcwg-public wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>Stephen - <o:p></o:p></p><div><p class=MsoNormal>This document is about SMIME certificates not TLS.<o:p></o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks,<br clear=all><o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"Segoe Script ,sans-serif",serif'>Wendy</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><o:p> </o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Wendy Brown<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Supporting GSA<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>FPKIMA Technical Liaison<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Protiviti Government Services<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>703-965-2990 (cell)</span><o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Tue, Aug 30, 2022 at 4:22 PM Stephen Davidson <<a href="mailto:Stephen.Davidson@digicert.com">Stephen.Davidson@digicert.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>Hello Wendy –<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>Thanks for your input. Responses inline below.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>Regards, Stephen<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><div><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=EN-US> </span></b><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> Standard language from TLS BR<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><span lang=EN-US>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."<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><span lang=EN-US>>> Sentence was previously requested to clarify that Mailbox-validation may only be done by CA, not Enterprise RA.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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. <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>1.3.5 Other participants<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> Based on standard language from TLS BR<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>Definition of Applicant - it would read better as "Once the Certificate is issued" instead of "Once the Certificate issues"<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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."<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> Standard language from TLS BR. Language does apply to email gateways.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>4.9.5 #4 The example is not relevant for SMIME certificates and should be deleted:<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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); <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> Standard language from TLS BR<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>4.12.1 - Should something be said about certificates that contain non-repudiation should NOT be escrowed?<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> 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.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>6.2.1 or 6.2.7 Should place some requirements on the storage of subscriber private keys<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> Future discussion.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> This was discussed at length with Certificate Consumers indicating a preference to move to shorter validity periods.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> comes from Mozilla. <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> see 7.1.2.4<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> - <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> In Legacy generation other attributes are allowed (bottom line of table)<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> see 1.3.2, text has also been improved.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> Thank you for highlighting this; have removed and suggested changes at the TLS BR at <a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fissues%2F387&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cf12fb2e856254c8088b608da8b47e475%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637975438154027636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Bp7V5vaHsesVT9%2FYlPsD%2Bbwo51%2BHmqkJDSsge2WdEAQ%3D&reserved=0" target="_blank">https://github.com/cabforum/servercert/issues/387</a> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> Based on standard language from TLS BR<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>8.6 #4 - Again – the audit should have been about the CA – not just an audit of a CA certificate<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> Based on standard language from TLS BR<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>9.6.1 #2i - Presumably either the subject or an authorized rep requested the cert, not necessarily both in all cases<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> correct<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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)<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> The intent is to restrict the use of certs to the associated mailboxes.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>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<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US>>> Based on standard language from TLS BR updated for context – and the sense is to prevent future use of known-compromised keys.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US> <o:p></o:p></span></p></div></div></div></div></div></div></div></div></div></div></div></blockquote></div><p class=MsoNormal><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Smcwg-public mailing list<o:p></o:p></pre><pre><a href="mailto:Smcwg-public@cabforum.org">Smcwg-public@cabforum.org</a><o:p></o:p></pre><pre><a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fsmcwg-public&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cf12fb2e856254c8088b608da8b47e475%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637975438154027636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4Pvr81r0r0if2LMUcZZL9vN4lohW8A%2FouZMbHvyr2aI%3D&reserved=0">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><o:p></o:p></pre></blockquote><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>