[Servercert-wg] Ballot SC31 - Browser Alignment

[Dimitris Zacharopoulos (HARICA)]

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 
knowledge.

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).


Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200702/e6f9a3bc/attachment.html>