[cabfpub] BR Rekey Rules

[Rich Smith]

Gerv,
I'm not unsympathetic to your points, but I agree with Wayne and Kirk on
this.  But I think anything we do here should be crafted as a temporary, and
hopefully quickly passed measure specifically crafted to address Heartbleed
and not to be carried out in perpetuity.  We can discuss and debate any
longer term measures on a future ballot.

I propose the following:
Be it resolved by the Forum, for the specific purpose of supplying existing
subscribers with a re-key of any certificate which may have been compromised
by the OpenSSL Heartbleed bug, the issuing CA MAY supply the subscriber with
a re-key of their existing certificate, not to exceed the original
expiration date, OR current max validity period specified by the Baseline
Requirements (BRs), whichever is less, without re-verification of
organizational details, BR organizational document aging and verification
requirements notwithstanding. The CA MUST still adhere to current BR domain
verification requirements.

If we can generally agree on the above, I think we should try get this
through as an emergency measure, accelerating the standard ballot review and
voting timeframes, but I don't know that we have a mechanism in place w/in
the bylaws for doing so.

-Rich 

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Gervase Markham
> Sent: Thursday, April 17, 2014 10:30 AM
> To: kirk_hall at trendmicro.com; Wayne Thayer; CABFPub
> Subject: Re: [cabfpub] BR Rekey Rules
> 
> On 17/04/14 15:11, kirk_hall at trendmicro.com wrote:
> > Gerv -- I think Wayne is asking for a reissue rule for all certs
> > (including 2 year and 3 year certs) that allows reissue to the
> > original expiration date without having to re-vet the applicant.  For
> > example, a customer might have been vetted on 1/1/2010 (good for 39
> > months) and receive a 3 year OV cert on 10/1/2012 that expires
> > 9/30/2015.
> 
> I was not aware that it was permissible for CAs to vet on date X, and
> then issue a max-length cert (5 years?) for that customer without
> revetting on date X + 38 months, i.e a cert that lasts 5 years is based
> on info which is already over 3 years old. That seems wrong to me. But
> then, I've never set much store by the OV vetting process ;-)
> 
> > The customer wants to revoke and reissue with a new cert that also
> > expires on 9/30/2015.  The CA wants to do this, but the last vetting
> > was more than 39 months ago.
> 
> The aim of the 39-month rule was, AIUI, to not have certs created with
> really old info in. It seems that it doesn't fully achieve that, if my
> scenario above is accurate. However, I'm not sure that means we should
> drive a second coach-and-horses through this hole after the first one
> has passed.
> 
> Still, having understood the situation better: given that Firefox does
> not use OV information in its primary UI, we would consider abstaining
> on a ballot on this question.
> 
> 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/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140417/5b73314d/attachment-0003.bin>