[cabfpub] BR Rekey Rules

Mon Apr 21 18:30:17 UTC 2014

In the interest of expediency and better understanding of this  topic, here
are my preliminary notes from last Thursday's telephone discussion:

5.	Discussion of re-key rules:  Wayne explained that it would be a lot
faster to re-issue certificates based on a re-key needed by customers in
response to the Heartbleed vulnerability. The problem is that section 11.3
of the Baseline Requirements states that the age of data used to validate a
certificate must be less than 39 months, while section 11.13.4 of the
Extended Validation Guidelines provides reissuance under an exception if the
replacement certificate has the same name and expiration date of the
currently valid EV Certificate being replaced.  He said that the EV rule
provides clearer guidance while the BR rule causes problems for legacy
certificates issued with older data, which can't be rekeyed without meeting
all BR requirements.  So, if a vulnerability like Heartbleed happens, and
you have a situation where you just have to re-key, it doesn't make sense to
have to re-perform validation if it is just a re-key.

Kirk agreed that if it is allowed at the EV level, it is strange that it is
not allowed at the OV level.  Gerv said that when we adopted the Baseline
Requirements some rules had sunset periods so that they wouldn't be
applicable immediately, but now, if a CA and customer are changing the
certificate anyway, then it is reasonable to expect that the certificate be
made BR-compliant. 

Ben wondered whether there was any potential ballot wording that could be
proposed or whether the issue will pass too quickly without being able to
address it.  Wayne said that from a practical prospective, it would be
helpful to address, even though it has now been 10 days since Heartbleed was
announced.  Kirk said it appears that the guidelines don't expressly address
this issue (re-key, re-issue, replace), so it is maybe just something to
address with the concerned browsers.

Rich said that in past discussions there has been consensus that a re-key is
allowed after a quick review of the main facts-the certificate issued today
can be based on the details of the past. It will be a new certificate with a
new hash, even though the key is not the same key.   Kirk agreed that
traditionally CAs have done this for customers, and it was not really
considered to be a new certificate.  Eddy said that there is no such thing
as a "re-issued certificate" - it is not the same certificate. 

Rich said that, for the record, he agrees with Wayne, and he would like to
see something done with a ballot as a long-term thing--there should be
something in the Baseline Requirements similar to what we have in the EV
Guidelines about reissues (replacements). In this particular case, in
regards to Heartbleed, do we have an emergency ballot process?  Can we relax
these revalidation requirements just for the instance of Heartbleed? My
personal view is that it is far better to have a re-issued certificate out
there that may not be in full compliance with the BRs. 

Kelvin:  For an emergency ballot for Heartbleed, in terms of this slowing
down customers' ability to re-key, what is the slowdown rate?   How many
customers are waiting in the queue because your staff is dealing with it? 
Rich: I'm seeing at least a 10-fold increase in re-issuance requests. I
thought that by now I would have seen light at the end of the tunnel and for
the next few weeks that seems to be the case, but right now, I'm not sure we
can estimate when this is going to be past us.
Wayne: There's a second take on this. In addition to the customers who have
to wait, in a many cases there are three parties-the
company/website/business owner, the CA, and the hosting provider who we deal
with directly. If we could do it without the business owner-between just the
hosting provider and the CA, that would be better. 
Jeremy:  The Mozilla rules say that you have to re-verify information at
least every 39 months.  Customers cannot get more than a 60-month
certificate. 
Kirk:  The proposal on the table is to reissue with the same expiration
date. 
Rich: The five-year certificate is still permissible under the BRs today.
There are still some certificates out there that were issued with validity
longer than 5 years, which predate the Baseline Requirements. So, if what
you've got left on one of those exceeds 5 years, then you will have to knock
that down to 5 years.   Ben, is there any mechanism within the Bylaws to put
forth an emergency measure? 
Ben:  No, and I don't think we'd even know how to suspend the Bylaws. 
Kelvin:  And that would be a very dangerous thing to do, in terms of
precedent. 
Kirk: Another way we can do this is by asking each of the browsers whether
they prefer the replacement approach to be taken.  Isn't it only Firefox
that has a stated rule?   Has Microsoft ever stated a rule on revalidating
information in case of rekey?  
Rich:  The issue here really is with people who have long-lived certificates
that were issued when the BRs came into existence a few years ago.  
Kirk:  The ballot could address anything that came into place before the
BRs.
Gerv:  How about this? CAs concerned about this issue should send Kathleen
and me an email with the number of re-key requests that they are handling
because of Heartbleed and the percentage of those Heartbleed re-keys that
involve re-validation, and then we can look at it.  That information will
remain confidential. 

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Gervase Markham
Sent: Monday, April 21, 2014 8:06 AM
To: Eddy Nigg; CABFPub
Subject: Re: [cabfpub] BR Rekey Rules

On 18/04/14 16:50, Eddy Nigg wrote:
> Maybe Gerv can clarify this - according to my understanding CAs must 
> validate data of certificates every 3 years if the current life-time 
> of the certificate is longer than that (because permitted for some 
> time according to the BR).

http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
policy/inclusion/

section 6:

"We require that all CAs whose certificates are distributed with our
software products:
...
verify that all of the information that is included in SSL certificates
remains current and correct at time intervals of thirty-nine months or
less;"

My reading of that is that if it ever comes to pass that a certificate
signed by your CA has not had the information within it revalidated in the
last 39 months, and is still valid, then that's in violation of this policy
item.

This is obviously not a problem if you issue certificates whose lifetime is
39 months or less and you get fresh information at the time of cert
issuance; but if you issue certificates which last longer, or you issue
certs based on old information, you need to make sure that the information
is revalidated on or before the date it reaches 39 months old. If this is
not done, I would expect the cert to be revoked.

There is no problem with revalidating the info while the cert is still in
use. And if the info remains the same, there is obviously no requirement to
change the cert or otherwise interrupt service.

Kathleen is away at the moment; but any CA who disputes this reading is
welcome to drop Kathleen and I a line.

Gerv
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140421/3f188d3d/attachment-0001.p7s>