<div dir="ltr">I finally made it through the pre SMIME BR and have the following comments<div><br></div><div>Definitions:<br><ul><li>Application Software Supplier - in the context of SMIME - I think we should drop the "Internet browser software or other relying-party application software such as"</li></ul></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>and at least start with mail user agents (web-based or application based) and email service providers that process S/MIME Certificates - because that is the correct context for this document</div></blockquote><div><ul><li>Audit Report - should state A letter from a Qualified Auditor stating the Qualified Auditor's opinion on whether an entity's processes and controls comply with the appropriate CP and CPS and the mandatory provisions of these Requirements</li></ul><ul><li>Sponsor-validated - I do not think it should be limited to Individual (Natural Person) should be equally applicable to role or group - email validated certificates issued by an Enterprise RA associated with the organizationName or org/OU</li></ul><ul><li>Subject Identity Information - why is the Mailbox Address excluded?</li></ul><br>3.1.1 Types of Names<br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>I disagree with - Names in the subject:commonName MUST be identical to the names as they appear in the identifying documentation or Enterprise RA records.</div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>Often an Enterprise has a naming convention such as first.last which is not identical to id documents - they should be allowed to use that in the CN field</div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>the statement also contradicts the following paragraph about being able to choose one or several given names in any sequence</div></blockquote></blockquote><div><br>3.2.2 what does this mean in terms of enterprise RA?<br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>The CA SHALL NOT delegate the verification of mailbox authorization or control.</div></blockquote><div><br>3.2.2.1 - needs a version # for TLS BRs<br><br>3.2.2.2 - I thought we agreed to a longer period than 24 hours for the random value in mailbox validation<br><br>3.2.3.1 - B - not all businesses necessarily have a physical address - what is the definition of business presence at a physical address?</div><div><br>3.2.3.4.1 - why do all businesses have to have a physical address in this day and age? Many only do business using a PO Box. There are still places in the US where even some residences use a PO box rather than a physical address for all US mail.<br><br>3.2.3.6.2 1 - why does a company have to be in business for 3 years before they can get an SMIME cert?<br><br>3.2.4.1 <br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>2. - why should digital identity need to follow ICAO 9303 part 10 - this does not allow for PIV or PIV-I authentication</div><div>3. - not entirely sure what these mean - the Kantara identity assurance framework at level 2, NIST SP 800-63 at level 2, or the FBCA CP at Basic or higher assurance</div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>What's the definition of "distant past"?</div></blockquote><div><br>3.2.8.4 - 3 A - why can't the phone be the person's personal phone? Due to COVID many are using cell phones for business purposes & in the case of my own very large company that means our personal cell phones, which are also listed within the company internal directory<br><br>4.1.2 - in the case of sponsored emails - does the CA really need a signed subscriber agreement from each individual - or is it sufficient that the agreement is between the individual & the Org?<br><br>4.2.1 2. - extra in (Validation of authority in in ...)<br><br>4.9.5 - references to Web Site are inappropriate for SMIME certs<br><br>4.9.10 - 4. - this doesn't seem to make sense in all cases - if the validity period is 16 hours updating no more than 4 days after the thisUpdate is way too late<br>For OCSP responses with validity intervals greater than or equal to sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.<br><br>4.9.10 - unclear if OCSP required for subordinate CA certificate status?<br><br>4.9.14-16 - if suspension is not allowed in 4.9.13 - no stip in the following sections about suspension is not correct - they should probably be Not Applicable<br><br>6.3.2 - still disagree with the 825 max - should be a minimum of 3 years & the idea of needing to measure in seconds is ridiculous<br><br>7.1 - I would still like someone to explain the need for 64 bits of randomness in the serial number - just because it was added to the serverAuth BRs in response to the SHA-1 weakness is no reason to add it to the SMIME cert profiles that already disallow SHA-1<br><br>7.1.2.1 - no mention of SIA - so it should be optional, same for SKI<br>7.1.2.2 - footnote on nameConstraints - don't we consider nameConstraints to be widely supported at this point - so do we still want the optional criticality?<br>no mention of SKI - so optional?<br>7.1.2.3 - j - why should subjectDirectoryAttributes be prohibited?<br>again - no mention of SKI<br><br>7.1.4.2.2 seems to contradict cert profiles further down<br>k, - locality should just be optional<br>l - state or province should just be optional<br><br>7.1.4.2.3 & 4 - I thought we had deicded organizationIdentifier did not need to be present in the cert - just validated<br>7.1.4.2.4 & 5 - should be able to use common name rather than given, surname or pseudonym<br><br>7.1.4.3.1 - not sure what this means when/if a CA is going to be managed/operated by a PKI on behalf of an organization - i.e. when the org operating the CA is not the same as the org named in the CA<br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>This field MUST be present and the contents MUST contain either the Subject CA's name or DBA as verified under Section 3.2.3.3 The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name".</div></blockquote><div><br><br>7.1.5 - not sure why the first paragraph is included - this header is about nameConstraints - not Technically constrained CAs<br><br>7.1.6 & 7.1.6.2 - cert policies are not allowed in the Root CA certs - so unclear why Root CA is included here<br>suggest either not including Root here or making it 7.1.6.1 with a single sentence Root CA certificates do not contain certificate Policies<br><br>7.1.6.3 - why allow/require anyPolicy?<br>7.1.9 - since we state certificate policies must be non-critical no stip here is not appropriate - instead it should say something about there the expectation that all RPs will support processing cert policies regardless of criticality - after all we are relying on the ability of the RP to recognize the various cert policies defined in this doc<br><br>7.2.1 - don't we expect all CRLs to be V2?<br><br>7.3.2 - why prohibit reasoncode in OCSP extensions?<br><br>8.1 Certificates do not issue certificates - new or old. Certificates can be used to validate certificates - but the certificates themselves are issued by CAs</div><div><br>8.3 - don't we want the auditor to be independent of the PKI being audited?<br><br>8.4 - Should state the Audit should assess that the CA's operations are in compliance with their documented CPS and CP in addition to the requirements in these BRs. In addition to being conducted in accordance with one of the following schemes.<br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>also - I believe we should be able to delete the following line</div><div>However, if the CA or Delegated Third 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 MUST 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.</div></blockquote><div><br>8.5 - don't we want to state that a CA needs to correct or mitigate any deficiencies noted by an audit? To me this would be more important than the audit can't go over a year - I would rather see an audit cover a 13 month period than a 12 month audit with deficiencies that are not addressed. Personally, I think the priorities written into section 8 are misplaced.<br><br>8.6 - rather (or at a minimum in addition) to the SHA-256 fingerprint of certificates it would be better to include SKI of the CA's key. After all the audit should be about the operations of the CA not just CA certificates.<br> 10 - what is a surveillance audit? first & only time that term is used in this doc<br> 11 - wouldn't we want the same req for listing the BR for webtrust or any other audit as well - not just ETSI?<br><br>8.8 might be better worded as:<br>The CA SHALL ensure the practices and procedures of each Delegated Third Party, Enterprise RA, and Technically Constrained Subordinate CA are in compliance with these Requirements and the relevant CP and/or CPS. The CA shall document the obligations of Delegated Third Parties, Enterprise RAs, and Technically Constrained Subordinate CAs and perform internal audits of their adherence with those obligations on an annual basis. This requirement can be met by Delegated Third Parties, Enterprise RAs, and Technically Constrained Subordinate CAs undergoing an annual audit that meets the criteria specified in Section 8.4.<br><br>9.1.2 - if these certificates are really supposed to be publicly trusted I would think we would want something like this instead of no stip<br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>CA certificates must be publicly available. CAs operating in accordance with these requirements must not charge additional fees for access to this information.</div></blockquote><div><br>9.1.3 - again if the certificates are to be publicly trusted<br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>CAs operating in accordance with these requirements must not charge additional fees for revoking certificates or access to CRLs and OCSP status information.</div></blockquote><div><br>9.4 with all the new privacy laws and security risks of identity theft etc. I really think it is inappropriate to have No Stip in section 9.4 - at a minimum they should say something about needing to operate in accordance to the jurisdiction in which the CA operates to protect any personal information that was gathered in support of identity proofing an applicant, as well as providing notice & consent before collecting the information.<br><br>9.6.3 4 - rather than the following statement - because sometimes it is a legitimate use of an SMIME certificate issued to one email of a given user to use it with a different email owned by the same individual & at least currently some email software legitimately allows this use<br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>Use of Certificate: An obligation and warranty to use the Certificate only on email mailboxes listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use;</div></blockquote><div>instead</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>Use of Certificate: An obligation and warranty to use the Certificate only on email mailboxes listed in the Certificate, or under the legitimate control of the subscriber, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use;</div></blockquote><div><br><br></div><div>thanks,<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><p><span style="font-family:"Segoe Script",sans-serif">Wendy</span></p>
<p><span style="font-size:12.8px">Wendy Brown<br></span><span style="font-size:12.8px">Supporting GSA FPKI<br></span><span style="font-size:12.8px">Protiviti Government
Services</span></p>
<p> 703-965-2990 (cell)</p>
<p><a href="mailto:wendy.brown@gsa.gov" style="font-size:12.8px" target="_blank">wendy.brown@gsa.gov</a><br><a href="mailto:wendy.brown@protiviti.com" style="font-family:Calibri,sans-serif" target="_blank">wendy.brown@protiviti.com</a></p></div></div></div></div></div></div></div></div></div></div></div></div></div>