On 2020-11-14 5:01 π.μ., Ryan Sleevi wrote:
I believe it's possible to do, with the original language, but this
requires the CA to proactively take steps to address that in their
CP/CPS. That is, I think it'd be reasonable for an auditor to conclude
that, if a CA stated "We do X, Y, Z" in our CP/CPS, then doing "A, B,
or C" without it being listed in their CP/CPS first would be an issue.
I believe that is the concern you're raising, if I understood you
correctly.
Exactly, and the first proposed language by Ben, doesn't seem to allow
the CA to include language to support "and any other method". This is
not like the Domain or IP Address Validation methods where "any other
method" was considered a bad thing. This is a case where we should
welcome additional acceptable methods for third-parties to demonstrate
their control of compromised keys.
The way to address that, and what I think is a good goal, is to get it
to be "We do X, Y, Z, and any other method", ideally, when CAs make
the update in response to the new policy. As situations come up on a
case by case basis, the CA can deal with the issue without any update
required first. If any CA updates their CP/CPS without also adding
"and any other method" in response to the new policy, we can then
clarify whether they're intentionally stating they'll reject anything,
or whether it was an oversight, and like you, they want extra
flexibility because they want to go "above and beyond" as needed.
However, I also want to make sure that any formally accepted method of
proof is documented in the CP/CPS. So if the CA formalizes A and B as
routine operations, they will update their CP/CPS to state "We do X,
Y, Z, A, B, and any other method". This makes it clear which are the
guaranteed methods they promise to accept, as well as that exceptions
are recognized as necessary, and they will be accepted and dealt with.
I think we're in agreement here, and I already stated that in a previous
reply.
"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."
We could make the language even stricter so that if a CA accepts new
methods to demonstrate key compromise not mentioned in their CPS, they
should include the details of these new methods in an upcoming CPS
update (although I consider this redundant because this is IMO the
normal way of doing things). Since CAs are required to perform this
update task at least once a year, this information will eventually end
up in their CPS.
I will reply to Peter's post separately why I think invoking that
particular revocation reason is IMO not such a good idea.
Dimitris.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
