[cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy

[Eneli Kirme]

That said, if there's concern about timing, arguably it's useful to know concretely what the timing is.

We have asked our developer and we don’t have a problem with extending the requirement from 20 to 64 bits.

That said, we are still happy to see that discussion about how to audit the quality of RNG has started.


Best regards,

Eneli Kirme


On 28 Apr 2016, at 19:07, Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>> wrote:



On Thu, Apr 28, 2016 at 5:16 AM, Eneli Kirme <Eneli.Kirme at sk.ee<mailto:Eneli.Kirme at sk.ee>> wrote:
Hi,

The current requirement was part of root program conditions already before first version of BR-s were published and could be taken as a requirement while developing or purchasing the CA software.

Actually, at the time the BRs were published, the requirement was 64 bits. The BRs were looser (to 20 bits) than what Microsoft was requiring.

As the vendor claimed compliance, we believe to be compliant.
Changing to 64 bits may or may not make a difference - we have to check with the vendor. Adding some other restrictions on the types of acceptable RNGs is another change in requirements that may or may not make a difference.
We also have to check with the auditors about what evidence they would like to see to believe that long enough seemingly random number comes from an acceptable source.

But the question is more general - to which level you expect a CA to have control over the software it is using and to which level auditors should have access to it?

The expectation is that all CAs will be following the latest-published BRs, per Section 2.2 of the BRs, specifically:

[Name of CA] conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates published at http://www.cabforum.org<http://www.cabforum.org/>. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.

To the extent a given CA has concerns about the BRs, such as the timing of the deployment of updated software, that's useful information to bring forward during the discussion of the proposed changes, and may inform the voting on the ballot. But once a ballot has passed, the expectation is that the CA will adopt it operationally "immediately", even if the audit criteria for it is developed, and the audit expectation of compliance is not enforced until the audit criteria are adopted.

This was discussed during the Scottsdale F2F as understanding when ballots come into effect - when the consensus about the understanding that the above clause represents an expectation to adopt immediately. That naturally follows that CAs should be prepared to adopt the Ballots as they're published, or their effective date, or to understand what challenges might exist to prevent that.

That said, if there's concern about timing, arguably it's useful to know concretely what the timing is.
_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160429/ec8f81b2/attachment-0003.html>