[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

[Rich Smith]

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Ryan Sleevi
<snip>
> 
> 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.
> 
</snip>


Ryan,
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
advance.

-Rich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130801/b23483fd/attachment-0003.bin>