[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements
sleevi at google.com
Thu Aug 1 18:50:37 UTC 2013
On Thu, Aug 1, 2013 at 11:46 AM, Rich Smith <richard.smith at comodo.com> wrote:
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
>> On Behalf Of Ryan Sleevi
>> I would suggest that there are several reasons for the date policies,
>> beyond key lifecycle:
>> 1) Ensuring that the information presented in the certificate is
>> accurate and regularly vetted.
>> 2) Ensuring that even in the absence of hard-fail revocation checking
>> (a point that things like mustStaple are arguably helping to actually
>> get to the point of actually being practical on the Internet), that
>> certificates cannot live on 'in perpetuity'
>> 3) Ensuring that the certificates themselves reflect the best security
>> practices at the time of issuance (eg: minimally, the BRs), but that
>> they also recognize that the threat landscape changes, and thus are
>> periodically reviewed and adjusted to reflect best current practice.
> I have no problem with any of the above. I can't speak to any other CAs
> practices around something like this, but as for Comodo, if a replacement is
> done on any certificate regardless of the term of validity, we re-verify
> domain control as per the BR. We have done this even before the BR became
> effective. We also require that the reissuance/re-key be based upon a CSR
> meeting current key size requirements (2048 on our system at this point)
> regardless of what was allowed when the cert was originally issued. That
> being the case, IMO, if I re-issue a cert that was originally issued for a
> 10 year term, 4 years ago, I think that new cert is now MORE secure today
> than the one I issued 4 years ago, even if it is for a now-non-BR-compliant
> 6 year term (in keeping with the time left of the original 10). Having
> re-checked domain control today, and most likely increased the key size from
> 1024 to 2048 bit, that cert is now in better shape than had we just left the
> original in place until expiration.
> So, like I said, I don't really have enough certs out there to put up strong
> resistance to your reasoning and conclusion, but the fact is that if even
> one of these gets re-issued, the customer is going to scream bloody murder
> when I cut time off it and I'm going to have to talk them down and jump
> through hoops on our system to either get a partial refund issued or somehow
> tack another free cert on at the end of the BR allowed term (5 years from
> now). Both of those things are a bloody pain in the neck for what I see as
> zero added benefit to anyone, so I'd really rather not have to deal with it.
> That being said, pending the outcome of this discussion (and with 3 browsers
> now having weighed in, it seems to be going your way) I'll do what I have to
> do. I just think that had this reasoning been made more clear from the
> outset, those of us effected would have either tried to carve out a
> reasonable exception for existing cert replacements from the beginning, or,
> barring that, we would at least have had a complete understanding of the
> expectation and been able to prepare ourselves and our customers for it in
In case it wasn't clear, I'm not actually opposed to, if necessary,
proposing a ballot that whitelists based on date, according to the
policies and practices you outlined - which I think are eminently
reasonable and to be expected.
That is, if we are going to allow re-issuance to deviate from whatever
the current BCP is, I'd much rather see it as a whitelist (eg:
acceptable to deviate on fields X, Y or Z, provided they were
compliant with the BRs at original issuance) rather than a blacklist
of preventing certain things.
I just want to make sure we're all on the same page in terms of
issuance practices - both for 'new' certs, for re-key, and for
re-issuance - so that we don't find ourselves scrambling to respond to
security incident that arose from a misinterpretation.
More information about the Public