[cabfpub] BR Rekey Rules

[Jeremy Rowley]

We do revalidate in that situation (after 39 months) and think it should be
required under the BRs.

Jeremy

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Wayne Thayer
Sent: Thursday, April 17, 2014 9:38 AM
To: Jeremy Rowley; kirk_hall at trendmicro.com; 'Gervase Markham'; 'CABFPub'
Subject: Re: [cabfpub] BR Rekey Rules

That assumes the cert was not renewed using previously verified info.

-----Original Message-----
From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
Sent: Thursday, April 17, 2014 8:00 AM
To: kirk_hall at trendmicro.com; 'Gervase Markham'; Wayne Thayer; 'CABFPub'
Subject: RE: [cabfpub] BR Rekey Rules

You already can reissue 1-3 year certs under the BRs as you can reuse
verification data for up to 39 months under Section 11.3.

Jeremy

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of kirk_hall at trendmicro.com
Sent: Thursday, April 17, 2014 8:44 AM
To: Gervase Markham; Wayne Thayer; CABFPub
Subject: Re: [cabfpub] BR Rekey Rules

Just to clarify -- Trend Micro has never issued 5 year OV certs, and we only
issue 1 and 2 year OV certs.  We take no position as to legacy 5 year certs,
but it does seem sensible to us to allow reissue (to the original cert
expiration date) for a 1, 2, or 3 year OV cert that was properly
authenticated and issued originally without requiring revetting of customer
identity information.  For that reason, it makes sense to extend EVGL
11.13.4 to OV certs as well.

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Thursday, April 17, 2014 10:30 AM
To: Kirk Hall (RD-US); 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

<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>
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public