[Smcwg-public] a few remaining comments on the SMIME BRs that I still have not seen addressed

Tue Aug 30 13:56:00 UTC 2022

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.

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

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."

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.

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.

1.3.5 Other participants
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.

Definition of Applicant - it would read better as "Once the Certificate is
issued" instead of "Once the Certificate issues"

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."

4.9.5 #4 The example is not relevant for SMIME certificates and should be
deleted:

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);

4.12.1  - Should something be said about certificates that contain
non-repudiation should NOT be escrowed?

6.2.1 or 6.2.7 Should place some requirements on the storage of subscriber
private keys

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.

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.

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.
 -
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.
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.

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

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.

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.

8.6 #3 - The audit should be about CAs & their operations not just the CA
certificate.
It is equally, if not more important, to actually list the CA Name

8.6 #4  - Again – the audit should have been about the CA – not just an
audit of a CA certificate

9.6.1 #2i - Presumably either the subject or an authorized rep requested
the cert, not necessarily both in all cases

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)

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

Thanks,

Wendy

Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220830/21eeccc1/attachment.html>