<div dir="ltr">And maybe I missed the discussion during one of the calls, I was unable to attend, some of these are really editorial, but not all.<div><br><div>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</div><div><br></div><div>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."<br><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>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.</div></blockquote><div><div><br></div><div>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. </div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>1.3.5 Other participants</div><div>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.</div></blockquote><div><br></div><div>Definition of Applicant - it would read better as "Once the Certificate is issued" instead of "Once the Certificate issues"</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>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."</div></div><div><br></div></blockquote>4.9.5 #4 The example is not relevant for SMIME certificates and should be deleted:<div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>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); <br></div><div><br></div></blockquote>4.12.1  - Should something be said about certificates that contain non-repudiation should NOT be escrowed?</div><div><br></div><div>6.2.1 or 6.2.7 Should place some requirements on the storage of subscriber private keys</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> - </div><div>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.</div><div><br></div><div><div>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<br></div></div><div><br></div><div>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.</div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>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.<br></div><div><br></div></blockquote>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<br><div><div><br></div><div>8.6 #4  - Again – the audit should have been about the CA – not just an audit of a CA certificate</div><div><br></div><div>9.6.1 #2i - Presumably either the subject or an authorized rep requested the cert, not necessarily both in all cases</div><div><br></div><div>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)</div><div><br></div><div>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</div><div><br></div><div>Thanks,<br><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></div></div></div></div></div>