On 12/11/2020 10:51 μ.μ., Ryan Sleevi via dev-security-policy wrote:
On Thu, Nov 12, 2020 at 1:39 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:
I believe this information should be the "minimum" accepted methods of
proving that a Private Key is compromised. We should allow CAs to accept
other methods without the need to first update their CP/CPS. Do people
think that the currently proposed language would forbid a CA from
accepting methods that are not explicitly documented in the CP/CPS?
I also think that "parties" is a bit ambiguous, so I would suggest
modifying that to follow the language of the BRs section 4.9.2
"Subscribers, Relying Parties, Application Software Suppliers, and other
third parties". Here is my proposed change:
"Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods (at a
minimum) that Subscribers, Relying Parties, Application Software
Suppliers, and other third parties may use to demonstrate private key
compromise."
Dimitris,
Instead, what about something like, "Section 4.9.12 of a CA's CP/CPS MUST
clearly specify its accepted methods that Subscribers, Relying Parties,
Application Software Suppliers, and other third parties may use to
demonstrate private key compromise. A CA MAY allow additional, alternative
methods that do not appear in section 4.9.12 of its CP/CPS." ?
I understand and appreciate Dimitris' concern, but I think your original
language works better for Mozilla users in practice, and sadly, moves us
back in a direction that the trend has been to (carefully) move away from.
I would say the first goal is transparency, and I think that both proposals
try to accomplish that baseline level of providing some transparency. Where
I think it's different is that the concern Dimitris raised about
"minimums", and the proposed language here, is that it discourages
transparency. "We accept X or Y", and a secret document suggesting "We also
accept Z", makes it difficult to evaluate a CA on principle.
There is transparency that the CA has evaluated some reporting
mechanisms and these will be documented in the CPS. However, on an issue
like compromised key reporting, there is no single recipe that covers
all possible and secure ways for a third-part to report a key
compromise. This has already been demonstrated in the various
discussions on this Forum. In such time-sensitive issues, where
certificates must be revoked within 24 hours, CAs should have the
liberty to accept a key compromise being reported by a method that might
be considered acceptable but which the CA's engineers didn't think about
when drafting the CPS. We can't expect a CA to update a CPS within 24
hours to allow additional reporting methods before accepting them.
For CAs that want to do the right thing with this flexibility, the
original language Ben proposed seems to be problematic, which is why I
highlighted it in the discussion. The updated language keeps all the
"good" things from the original language, and allows the CA to accept a
reporting method that they may have not considered. Obviously, the
logical thing is that once this new method is accepted, the CPS should
be updated to include that additional method but that might take place
later, after the report was accepted and certificates revoked.
I can't think of a bad scenario with this added language.
The second goal is auditability: whether or not the CP/CPS represents a
binding commitment to the community. This is why they exist, and they're
supposed to help relying parties not only understand how the CA operates,
but how it is audited. If a CA has a secret document Foo that discloses
secret method Z, is the failure to actually support secret method Z worth
noting within the audit? I would argue yes, but this approach would
(effectively) argue no.
This makes no sense to me. We're not discussing secrets here. Say a
third party reports a key compromise by sending a signed plaintext
message, and the CA has only indicated as accepting a CSR with a
specific string in the CN field. The updated proposal would allow the CA
to evaluate this "undocumented" (in the CPS) reporting method, check for
its credibility/accuracy and proceed with accepting it or not.
The original proposal seems to forbid this and forces the CA instructing
the reporter to create a CSR with a specific string because that's the
only thing allowed in the CPS.
I hope this makes it clearer.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
