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

Tue Aug 30 20:30:56 UTC 2022

WRT:

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.

>> comes from Mozilla.

Do we want to raise this issue on mdsp and see whether there is a desire to
remove this requirement for post-SHA1 certificates?

Ben

On Tue, Aug 30, 2022 at 2:22 PM Stephen Davidson via Smcwg-public <
smcwg-public at cabforum.org> wrote:

> Hello Wendy –
>
>
>
> Thanks for your input. Responses inline below.
>
>
>
> Regards, Stephen
>
>
>
>
>
> 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.
>
>
>
> >> Standard language from TLS BR
>
>
>
> 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.
>
>
>
> >> Sentence was previously requested to clarify that Mailbox-validation
> may only be done by CA, not Enterprise RA.
>
> 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.
>
>
>
> >> Based on standard language from TLS BR
>
>
>
> 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."
>
>
>
> >> Standard language from TLS BR.  Language does apply to email gateways.
>
>
>
> 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);
>
>
>
> >> Standard language from TLS BR
>
>
>
> 4.12.1  - Should something be said about certificates that contain
> non-repudiation should NOT be escrowed?
>
>
>
> >> 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.
>
>
>
> 6.2.1 or 6.2.7 Should place some requirements on the storage of subscriber
> private keys
>
>
>
> >> Future discussion.
>
>
>
> 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.
>
>
>
> >> This was discussed at length with Certificate Consumers indicating a
> preference to move to shorter validity periods.
>
>
>
> 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.
>
>
>
> >> comes from Mozilla.
>
>
>
> 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.
>
>
>
> >> see 7.1.2.4
>
>  -
>
> 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.
>
>
>
> >> In Legacy generation other attributes are allowed (bottom line of table)
>
>
>
> 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
>
>
>
> >> see 1.3.2, text has also been improved.
>
>
>
> 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.
>
>
>
> >> Thank you for highlighting this; have removed and suggested changes at
> the TLS BR at https://github.com/cabforum/servercert/issues/387
>
>
>
> 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
>
>
>
> >> Based on standard language from TLS BR
>
>
>
> 8.6 #4  - Again – the audit should have been about the CA – not just an
> audit of a CA certificate
>
>
>
> >> Based on standard language from TLS BR
>
>
>
> 9.6.1 #2i - Presumably either the subject or an authorized rep requested
> the cert, not necessarily both in all cases
>
>
>
> >> correct
>
>
>
> 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)
>
>
>
> >> The intent is to restrict the use of certs to the associated mailboxes.
>
>
>
> 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
>
>
>
> >> Based on standard language from TLS BR updated for context – and the
> sense is to prevent future use of known-compromised keys.
>
>
>
>
> _______________________________________________
> Smcwg-public mailing list
> Smcwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220830/567a5c7b/attachment.html>