[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

Wed Aug 7 19:05:02 MST 2013

Ryan, I think you are putting up a straw man argument when you imply that CAs could cheat on all the BR rules by pretending they are simply reissuing a pre-BR cert, so they don't have to comply with anything.  To my knowledge, no one has done that or proposed that.  The only controversy here is validity period for the reissued pre-BR 10 year certs (which to our minds are in fact BR complaint, by their terms).

I believe that many CAs have always allowed a free reissue of an outstanding cert in their subscriber agreements (for the remaining certificate validity period only - not for any extended period) if necessary due to a technical problem such as loss of private key.  So the reissued (re-keyed) cert for the remaining validity period presents no greater danger to the internet community than the previously issued, pre-BR 10 year cert.  Does it?

I can't fully understand why some are acting as if there is a grave danger from reissue/rekeying for the remaining validity period - if pre-BR 10 year certs (which are expiring by their own terms) are so dangerous, why wouldn't you demand they all be revoked right now?  (Or that they all be revoked when they reach 60 months?)

This feels to us like a "gotcha" moment, when people are seizing on what, to us, is an overly-technical interpretation of what "issue" means in order to say to CAs and their customers "too bad you have a technical need for reissue of a pre-BR 10 year cert for the remaining 6 years of validity period (or whatever) - you can't do it.  But you can continue to use the other 10 year pre-BR cert you have until it expires."  Why is this useful or necessary?  It's certainly disruptive.

At the end of the day, I guess the browsers can impose whatever interpretation they want, but from a CA viewpoint, we don't agree with this interpretation.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Wednesday, August 07, 2013 2:29 PM
To: Kirk Hall (RD-US)
Cc: public at cabforum.org >> public at cabforum.org
Subject: Re: [cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

On Tue, Aug 6, 2013 at 10:50 PM, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com<mailto: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> [mailto: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<mailto:public at cabforum.org> >> public at cabforum.org<mailto: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:<mailto: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<mailto: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<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
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.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130808/9168e86b/attachment-0001.html 