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

Wed Aug 31 14:54:10 UTC 2022

Here is a relevant discussion from the past:

https://github.com/mozilla/pkipolicy/issues/13

I'll continue to look for others.

Ben

On Wed, Aug 31, 2022 at 5:42 AM Wendy Brown - QT3LB-C <wendy.brown at gsa.gov>
wrote:

> 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/9e1ffe41/attachment-0001.html>