On 2020-11-13 7:17 μ.μ., Ryan Sleevi wrote:
On Fri, Nov 13, 2020 at 2:55 AM Dimitris Zacharopoulos
<ji...@it.auth.gr <mailto:ji...@it.auth.gr>> wrote:
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.
Sure, and the original proposed language doesn't restrict this.
The CA can still disclose "Email us, and we'll work it out with you",
and that's still better than the status quo today, and doesn't require
the CP/CPS update you speculate about.
I understand the proposal to describe a different thing. Your proposal
to accept an email, is a different requirement, which is "how to
communicate". I think the policy change proposal is to describe the
details about what is expected from third-parties to submit in order to
report a key compromise. Whether via email, web form or other means, I
think this policy update covers *what* is expected to be submitted (e.g.
via CSR, signed plain text, the actual private key).
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.
As above
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.
I addressed this in my reply to Nick, but for your benefit, the "bad"
thing here is a CA that lists, in their CP/CPS, "We will only accept
using our convoluted API that requires you to submit on the lunar
equinox", and then states "Well, that's just the minimum, we have this
doc over here saying we'll also consider X, Y, Z".
The modified language fully allows that. The original language would
see methods X, Y, Z also added to the CP/CPS.
I think one of us has misunderstood the policy update proposal. I
believe that what you describe is already covered by the existing policy
which states that the CA must disclose *how* they accept requests (via
email, API, web form, etc), disclosed in CPS section 1.5.2.
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 also allows this, by saying exactly what you
stated here, but within the CP/CPS.
The modified proposal, however, keeps secret whether or not the CA has
a policy to unconditionally reject such messages.
You seem to be thinking the original proposal prevents any discretion;
it doesn't. I'm trying to argue that such discretion should be
explicitly documented, rather than kept secret by the CA, or allowing
the CA to give conflicting answers to different relying parties on
whether or not they'll accept such messages.
If people consider that the original language is unambiguous and will
prevent an auditor to interpret this as "you have stated specific
technical method(s) for a third-party to demonstrate a key compromise,
therefore these are the only methods you must accept otherwise you are
violating your CP/CPS", then I'm fine.
Dimitris.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
