Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

2018-04-20 Thread sleevi--- via dev-security-policy
On Friday, April 20, 2018 at 9:31:32 AM UTC-4, Tim Shirley wrote: > First of all, it's important to distinguish between the BR requirement, which > is defined in terms of certificate *issuance* dates, and the value in the > "Not Before" field. I'm guessing the "Not Before" value in this

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

2018-04-20 Thread Rob Stradling via dev-security-policy
On 20/04/18 14:30, Tim Shirley via dev-security-policy wrote: First of all, it's important to distinguish between the BR requirement, which is defined in terms of certificate *issuance* dates, and the value in the "Not Before" field. I'm guessing the "Not Before" value in this certificate is

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

2018-04-20 Thread Wayne Thayer via dev-security-policy
On Thu, Apr 19, 2018 at 8:40 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/04/2018 20:24, Wayne Thayer wrote: > >> This proposal is to require intermediate certificates to be dedicated to >> specific purposes by EKU. Beginning at some future date,

Re: Policy 2.6 Proposal: Require CAs to support problem reports via email

2018-04-20 Thread Wayne Thayer via dev-security-policy
At this point we have a few choices: 1. Do nothing about requiring email as a problem reporting mechanism. Instead, take on the related issues of disclosure of the reporting mechanism and receipt confirmation in Mozilla policy, via the CAB Forum, or both. 2. Go ahead with the proposal to require

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-04-20 Thread Wayne Thayer via dev-security-policy
On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I believe the wording "insecure electronic channels" leaves a lot of space > for interpretation. In corporate PKIs for email encryption it is quite > common to transfer

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

2018-04-20 Thread Matt Palmer via dev-security-policy
On Fri, Apr 20, 2018 at 01:30:49PM +, Tim Shirley via dev-security-policy wrote: > This is why I'm not a fan of such precise enforcements of date-related > compliance. There are a lot of different ways to interpret dates/times, > but none of the readings materially change the net effect of

Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st

2018-04-20 Thread Tim Shirley via dev-security-policy
First of all, it's important to distinguish between the BR requirement, which is defined in terms of certificate *issuance* dates, and the value in the "Not Before" field. I'm guessing the "Not Before" value in this certificate is not the actual issuance timestamp, since it's unlikely it was