[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

Ryan Sleevi sleevi at google.com
Wed Aug 7 21:29:21 UTC 2013


On Tue, Aug 6, 2013 at 10:50 PM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:

>  Just because you (and others) may have had an **undisclosed**
> expectation about something, and I (and others) had an opposite **
> undisclosed** expectation about the same thing relating to initial
> adoption of the BRs doesn’t make any of us liars.****
>
> ** **
>
> In the future, if anyone thinks some new CA/Browser Forum requirement is
> meant to be retroactive (i.e., will apply to certificates already issued or
> to agreements made before the effective date of the new requirement) –
> please speak up, as that’s a big expectation to have, and many may oppose
> it.
>

I think we need to be clear on this:

I can certainly understand and appreciate that when the BRs were adopted,
there was NOT an assumption that all pre-BR certs would have to be revoked.
There was no giant flag day.

However, there has unquestionably been the expectation - from the root
stores, from the audit guidelines, and from the BRs itself - that all
certificates issued from the effective date must comply. This is, after
all, why the effective dates are so typically set further in the future -
to give CAs time to adequately prepare to implement the required measures.

The fundamental disagreement seems to be about which has higher priority:
existing agreements or the audit compliance. If a CA has an existing
agreement that says "We (the CA) agree not to conform to the BRs for
Customer Foo", then you cannot simultaneously argue that the CA is in
compliance with either the letter or the spirit of the BRs or of the root
program requirements.

If this was an acceptable interpretation, it seems like it incentivizes
every CA to put into their contracts language that runs counter to the BRs,
as it provides a "get out of jail free" card for any non-compliant
certificates. This would, in effect, make the BRs meaningless - a symbolic
hollow gesture.

If we want to talk about undisclosed expectations, I would simply highlight
that the BRs, unlike the EV guidelines, say nothing about re-key beyond
15.2.2.a. Absent any clarifications, and given the prevalence of terms like
"issuance", which itself has a defined meaning, it seems unreasonable to
think that rekey was or is exempt from this. If "rekey" was not an instance
of "issuance", then surely it would mean that no CA was obligated to keep
audit logs for any certificates they "rekeyed" - or if any (other)
attributes were changed on the certificate. Naturally, I hope you can see
why this interpretation is so fundamentally alarming, even if the current
example certificates are less troubling.


****
>
> ** **
>
> I can say that the only explicit requirement included in the initial BRs
> about maximum validity period for certs is BR 9.4 – and by its terms, it
> clearly does not apply to certs issued or agreements made before the
> effective date of the BRs.
>

I would hardly agree this point is clear, as stated above and previously.
After all, this thread would hardly be as active it if was so clear and
unambiguous.

Further, in your reply, you've now added an extra clause "or agreements",
which itself is not present in the BRs. This indicates another fundamental
disagreement here, and I hope to understand how you've reached this
conclusion, so that we can make sure that the BRs (and the CA/B Forum
Membership) are clear and in agreement on this.


> ****
>
> ** **
>
> I can also say that in the future, Trend Micro is likely to oppose any new
> requirements that are explicitly intended to be retroactive and would
> require a CA to revoke outstanding certs and/or breach existing agreements
> with customers, unless there is an extraordinary, proven, and immediate
> security threat – and the issue currently under current discussion doesn’t
> meet that test.
>

I would think that any CA that is not considering and incorporating, as
part of their agreements, the implications that the Baseline Requirements
will have on current and future certificate issuances may be acting in bad
faith with respect to making forward progress here.

Suggesting that no improvements can be made that disrupt the status quo
would be truly unfortunate.


> ****
>
> ** **
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *Eddy Nigg (StartCom Ltd.)
> *Sent:* Tuesday, August 06, 2013 2:51 PM
> *To:* public at cabforum.org >> public at cabforum.org
>
> *Subject:* Re: [cabfpub] Concerns regarding Mozilla Root Program/Baseline
> Requirements****
>
>  ** **
>
>
> On 08/07/2013 12:43 AM, From kirk_hall at trendmicro.com: ****
>
> Ryan and Eddy – if it was anyone’s intention to put CAs in the position of
> breach of contract with their existing customers for long-term certificates
> they had issued pre-BR (by effectively prohibiting them under the BRs from
> reissuing an existing long term cert for the balance of the cert validity
> period, as the CAs had agreed to do with their customers by contract), that
> was never made clear by anyone.****
>
>
> Well, as I mentioned earlier, if you are in this situation then fire your
> lawyers and whoever is responsible for setting up the policies and
> agreements. But there are other possible solutions to make a customer happy
> and still stay in compliance with the BR, I don't have to mention those
> here.
>
>
> ****
>
> If it had been made clear, I doubt many CAs would have supported that
> position.  We don’t think that’s a common-sense interpretation of the
> current BRs.****
>
>
> In my opinion it's the only logical interpretation and not only that, but
> we've discussed this extensively and the current BR was created by
> consensus being fully aware of the implications. Claiming otherwise would
> be a lie.
>
> ****
>
> Regards ****
>
>  ****
>
> Signer: ****
>
> Eddy Nigg, COO/CTO****
>
>  ****
>
> StartCom Ltd. <http://www.startcom.org>****
>
> XMPP: ****
>
> startcom at startcom.org****
>
> Blog: ****
>
> Join the Revolution! <http://blog.startcom.org>****
>
> Twitter: ****
>
> Follow Me <http://twitter.com/eddy_nigg>****
>
>  ****
>
> ** **
>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail or
> telephone and delete the original message from your mail system.
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130807/b7d39de1/attachment-0003.html>


More information about the Public mailing list