<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hello Wendy –<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for your input. Responses inline below.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards, Stephen<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><b><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> Standard language from TLS BR<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">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></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">>> Sentence was previously requested to clarify that Mailbox-validation may only be done by CA, not Enterprise RA.<o:p></o:p></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. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1.3.5 Other participants<o:p></o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> Based on standard language from TLS BR<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Definition of Applicant - it would read better as "Once the Certificate is issued" instead of "Once the Certificate issues"<o:p></o:p></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."<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> Standard language from TLS BR. Language does apply to email gateways.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">4.9.5 #4 The example is not relevant for SMIME certificates and should be deleted:<o:p></o:p></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); <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> Standard language from TLS BR<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">4.12.1 - Should something be said about certificates that contain non-repudiation should NOT be escrowed?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">6.2.1 or 6.2.7 Should place some requirements on the storage of subscriber private keys<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> Future discussion.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> This was discussed at length with Certificate Consumers indicating a preference to move to shorter validity periods.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> comes from Mozilla. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> see 7.1.2.4<o:p></o:p></p>
<p class="MsoNormal"> - <o:p></o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> In Legacy generation other attributes are allowed (bottom line of table)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> see 1.3.2, text has also been improved.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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">https://github.com/cabforum/servercert/issues/387</a>
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> Based on standard language from TLS BR<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">8.6 #4 - Again – the audit should have been about the CA – not just an audit of a CA certificate<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> Based on standard language from TLS BR<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> correct<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> The intent is to restrict the use of certs to the associated mailboxes.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>