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

Wed Aug 31 11:42:03 UTC 2022

Ben -
I would certainly appreciate Mozilla at least providing the rationale for
the requirement, as I do not understand if there is actually any security
benefit from it.  I have been told by others that they do not see the
benefit. And especially what is so special about exactly 64 bits of
randomness?

thanks,

Wendy

Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)

On Tue, Aug 30, 2022 at 4:31 PM Ben Wilson <bwilson at mozilla.com> wrote:

> 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/20220831/f2d7d01b/attachment-0001.html>