Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)

2017-01-19 Thread Gervase Markham via Public
On 16/01/17 21:02, Doug Beattie wrote: >> I don't think that's what I mean, because that's language of >> intent, not capability. I can change it to "the issuing >> intermediate or root" and then change the "pathlen=0" thing to be >> "(intermediates only)". > > I'm not sure why pathlen=0 is

Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)

2017-01-13 Thread Richard Barnes via Public
[unicast] Just tuning in here, may be missing context, but this seems like something that should be on m.d.s.p? On Jan 12, 2017 12:52 PM, "Gervase Markham via Public" wrote: > Here's v4. I've decided to leave the email situation unchanged for now, > in the name of getting

Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)

2017-01-13 Thread Doug Beattie via Public
> On 12/01/17 19:06, Doug Beattie wrote: > > Is there a provision for signing SHA-1 OCSP signing certificates? > > Perhaps this is covered in #1, but specifically allowing SHA-1 OCSP > > Signing certificates (under SHA-1 CAs which have active SHA-1 TLS > > certificates) would be a good idea for

Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)

2017-01-13 Thread Gervase Markham via Public
On 12/01/17 19:34, Tim Shirley wrote: > Besides EKU, I presume this should also list adding the pathlen:0 > constraint if it was previously absent. Yes. > It would probably be good to > include serial number as well, so no one could interpret this as a > requirement to duplicate a serial

Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)

2017-01-12 Thread Jeremy Rowley via Public
:51 AM To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public Discussion List <public@cabforum.org> Subject: Re: [cabfpub] Mozilla SHA-1 further restrictions (v4) On 12/01/17 18:17, Jeremy Rowley wrote: > Hey Gerv - when dos this policy take effect? Or is this

Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)

2017-01-12 Thread Tim Shirley via Public
>CAs may only sign SHA-1 hashes over issuing intermediates which chain >up to roots in Mozilla's program if the certificate to be signed is a >duplicate of an existing SHA-1 intermediate certificate with the only >change being the addition of an EKU to meet the requirements

Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)

2017-01-12 Thread Doug Beattie via Public
lic@cabforum.org> Cc: Gervase Markham <g...@mozilla.org> Subject: Re: [cabfpub] Mozilla SHA-1 further restrictions (v4) Here's v4. I've decided to leave the email situation unchanged for now, in the name of getting the SSL situation put to bed. We can address it in a different

Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)

2017-01-12 Thread Gervase Markham via Public
On 12/01/17 18:17, Jeremy Rowley wrote: > Hey Gerv - when dos this policy take effect? Or is this being proposed for > the next Mozilla policy update. I am trying to nail the text down; we'd then decide a timeline, probably initially promulgate it via a CA Communication, and add it to our policy.

Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)

2017-01-12 Thread Jeremy Rowley via Public
lic@cabforum.org> Cc: Gervase Markham <g...@mozilla.org> Subject: Re: [cabfpub] Mozilla SHA-1 further restrictions (v4) Here's v4. I've decided to leave the email situation unchanged for now, in the name of getting the SSL situation put to bed. We can address it in a different discussion. This is th