[Servercert-wg] Aligning the BRs with existing Browser Requirements

[Ryan Sleevi]

Another example of divergence was highlighted, where browsers place more
restrictive requirements, prohibiting things that the Baseline Requirements
allow.

The requirements on Signature Algorithms and Keys are updated to align with
the requirements placed by Microsoft and Mozilla:

   - The BRs allow for the use of DSA (or, more specifically, DSA2).
   - Microsoft prohibits the use of DSA (
   https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#b-key-requirements
    )
   - Mozilla prohibits the use of DSA (
   https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms
    )



   - The BRs allow for arbitrary key sizes beyond 2048 bits.
   - Mozilla Policy requires that the modulus size be divisible by 8 (
   https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms
    )



   - The BRs allow for the use of P-521
   - Mozilla Policy prohibits the use of P-521 (
   https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms
    ).
   - Microsoft Policy **allows** the use of P-521 (
   https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#b-key-requirements
    )
   - Google clients do not support P-521
   - Thus, this is a change in which two Root Programs are **more
   restrictive** than another.



   - The BRs allow for combining arbitrary hash functions when using the
   ECDSA signature algorithm (e.g. the use of ecdsa-with-SHA512 for a P-256
   key).
   - As described in FIPS 186-4, the use of a hash function whose output
   length is greater than the bit length of the key simply results in the
   truncation of the hash, and thus does not provide additional security
   strength. Further, it notes that the use of a stronger hash function should
   not be done, absent an a priori mutual agreement between the sender and
   receiver.
   - Mozilla Policy prohibits the use of hash algorithms that are not equal
   in output to the key size, by requiring that P-256 keys MUST sign data
   using ecdsa-with-SHA256 and that P-384 keys MUST sign data using
   ecdsa-with-SHA384 (
   https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms
    )
      - Mozilla Policy 2.7 (Draft) significantly rewords and expands this
      section (
      https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md#51-algorithms
)
      to be explicit about the allowed AlgorithmIdentifiers and their specific
      encoding. This may be a model to provide further clarity and
expectations,
      and avoid issues with encoding that have resulted from misinterpretations.

You can see this change in isolation at
https://github.com/cabforum/documents/commit/ea6ec5d2ea708542bed6f271e320ba96c1c7e092
,  or
the overall set of changes continue to be available at
https://github.com/cabforum/documents/compare/master...sleevi:2019-10-Browser_Alignment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191012/a4d96b4d/attachment.html>