[Servercert-wg] Ballot SC31 - Browser Alignment
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Wed Jul 1 21:37:01 MST 2020
On 30/6/2020 9:23 π.μ., Ryan Sleevi wrote:
> Equally, it's unfortunate that you'd wear the Chair Hat while offering
> your own personal, and unfortunately, inaccurate view of audits,
> particularly when they're so clearly dismissive of these concerns.
I tried to separate the "hats" by sending two separate emails. I asked
several CA representatives before adding this issue in my response and
they all confirmed that what is stated in a CP/CPS is audited.
Therefore, I'm not sure what was inaccurate or personal. This is common
On the topics mentioned on a personal capacity, it was really hard to
reply to your points because your responses shifted the discussion to
other areas which were never intended in my initial email. Here is an
attempt to respond to some of your statements.
* The burden of proof for proposed ballots has historically rested
upon the proposer, regardless of the voting category.
* In this SCWG (under the CA/Browser Forum Bylaws), CAs don't "prefer
to dictate the terms on browsers" and neither should the Certificate
Consumers (in the SCWG case, "the Browsers"). Browsers already
"dictate" anything they choose via their Root programs in addition
to the Baseline Requirements.
* Your analogy was not very accurate. A more appropriate analogy would
be "The customer wants 2lt bottles of milk but the State forces
giving them 1lt bottles of milk. The customer is frustrated, asking
for the security reasons why 2-lt bottles are problematic, and the
State is giving reasons that the customer doesn't understand or
feels they are not adequately justified or founded. The customer
will try to get 2-lt bottles but after some time, stores that want
to abide by the State laws will only be selling 1lt bottles of milk
(or risk being put out-of-business). If this customer went to
another State, perhaps there would not be a ban for 2-lt bottles."
* I also believe it's worth pointing out that ballots occasionally do
fail due to the way they are presented rather than the substance of
the changes in them. This is something that should not happen.
HARICA supports the ballot including the 398-day limit, but I fully
understand and respect the position of other CAs which "in principle"
don't support this to be included in the BRs. In practice, Browsers
shouldn't need this to be included in the BRs or rely on audits. With
Certificate Transparency, they can technically detect whether a
certificate has been issued with validity more than 398 days and
discover a possible Root Program policy violation. So, from my
perspective I don't understand why such extreme language is used, for a
topic that Browsers already have full technical control and don't need
to rely on audits or the BRs.
HARICA also has some minor concerns about forcing revocation reasons for
end-entity certificates without good rules and common expectations,
which is what standards are trying to achieve. Rushing this requirement
in will possibly create confusion. We believe a more focused discussion
on the end-entity revocation reasons is necessary to better explain the
expectations, corner cases and find common interpretations on the
existing X.509 descriptions. Things seem to be more "mature" on the
keyCompromise revocation reason and perhaps we could use this as a first
step and prepare rules and expectations for that (e.g. if a Certificate
is marked as keyCompromise, any other non-expired, non-revoked
Certificate that uses the same associated Public Key that the CA has
issued, must also be revoked with the same reason).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Servercert-wg