Re: Certificates with invalidly long serial numbers

licy Sent: Thursday, August 10, 2017 3:40 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificates with invalidly long serial numbers But that would require the issuer of the replacement cert (which might not be a fast-issue DV cert) to complete validation in something like

Re: Certificates with invalidly long serial numbers

ay, August 10, 2017 3:40 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Certificates with invalidly long serial numbers > > But that would require the issuer of the replacement cert (which might not > be a fast-issue DV cert) to complete validation in something like 36 hours, >

Re: Certificates with invalidly long serial numbers

y-policy-bounces+jeremy.rowley=digicert. com@lists.mozilla .org] On Behalf Of Paul Kehrer via dev-security-policy Sent: Wednesday, August 9, 2017 4:57 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificates with invalidly long serial numbers On Wednesday, August 9, 2017 at 9:20:02

RE: Certificates with invalidly long serial numbers

Of Ryan Sleevi via dev-security-policy Sent: Thursday, August 10, 2017 4:13 PM To: Jakob Bohm <jb-mozi...@wisemo.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Certificates with invalidly long serial numbers Could you explain how it bene

RE: Certificates with invalidly long serial numbers

@lists.mozilla .org] On Behalf Of Jakob Bohm via dev-security-policy Sent: Thursday, August 10, 2017 3:40 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificates with invalidly long serial numbers But that would require the issuer of the replacement cert (which might not be a fast

Re: Certificates with invalidly long serial numbers

lto:dev-security-policy-bounces+jeremy.rowley=digicert. >> com@lists.mozilla >> .org] On Behalf Of Paul Kehrer via dev-security-policy >> Sent: Wednesday, August 9, 2017 4:57 PM >> To: mozilla-dev-security-pol...@lists.mozilla.org >> Subject: Re: Certificates with invalid

Re: Certificates with invalidly long serial numbers

, 2017 4:57 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificates with invalidly long serial numbers On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote: All CAS are required to maintain the capability to process and receive revocation requests 24x7 under

Re: Certificates with invalidly long serial numbers

The answers from CAs we typically see in this group are more along the lines of not thinking it necessary to revoke at all than needing more time, I'd say. So I don't really see what this idea that 24 hours would be too short is based on. I think relaxing the revocation time limit may in fact

Re: Certificates with invalidly long serial numbers

On Wed, Aug 09, 2017 at 04:21:19PM +0200, Jakob Bohm via dev-security-policy wrote: > On 08/08/2017 20:46, Alex Gaynor wrote: > > It's from the BRs 4.9.1.1: > > > > The CA SHALL revoke a Certificate within 24 hours if one or more of > > the following occurs: > > > > It's also not a

RE: Certificates with invalidly long serial numbers

-policy Sent: Wednesday, August 9, 2017 4:57 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificates with invalidly long serial numbers On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote: > All CAS are required to maintain the capability to process and rece

Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote: > All CAS are required to maintain the capability to process and receive > revocation requests 24x7 under the baseline requirements. The headache is not > with the CA. Rather, it's notifying the customer that their

Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 12:05:32 AM UTC-4, Peter Gutmann wrote: > Matthew Hardeman via dev-security-policy > writes: > > >I merely raise the point that IF the framers of the 20 bytes rule did, in > >fact, simultaneously intend that arbitrary SHA-1

Re: Certificates with invalidly long serial numbers

(Note: Top posting because Alex did so) FYI: Last night, I posted a proposed very very rough draft overall graduation of revocation periods for various kinds of issues in mailman.1730.1502216764.14894.dev-security-pol...@lists.mozilla.org (Part of this thread). This only received a meaningless

Re: Certificates with invalidly long serial numbers

Totally agree Alex. The tiers I'm proposing are 1) subscriber requests revocation, cert was issued to the wrong entity, or the key was compromised and 2) everything else On Aug 9, 2017, at 8:22 AM, Alex Gaynor > wrote: I'm not really sure I

Re: Certificates with invalidly long serial numbers

On 08/08/2017 21:24, Jeremy Rowley wrote: I agree that the 24 hours seems excessive for some of these. Ive proposed at the cab forum we bifuracte the revocation periods to key compromise vs non key compromise. I'd love support there on the proposal. However, I think that until the rules

Re: Certificates with invalidly long serial numbers

I'm not really sure I agree that there should be multiple tiers of revocation, but just to go along with the thought experiment.. If there were, "key compromise" is definitely not the only case I'd want on the more aggressive schedule, I'd also want to include cases where there was a failure in

Re: Certificates with invalidly long serial numbers

On 08/08/2017 20:46, Alex Gaynor wrote: It's from the BRs 4.9.1.1: The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: It's also not a penalty on the CA, it's a remediation step for them to undertake. It is a disruption and penalty to the 3rd

Re: Certificates with invalidly long serial numbers

All CAS are required to maintain the capability to process and receive revocation requests 24x7 under the baseline requirements. The headache is not with the CA. Rather, it's notifying the customer that their certificate will be revoked before the start of the next business day. Having a one to

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote: > 24 hours is super short when it's a Saturday morning at 4 am and it’s a > European government entity. I agree that is what the policy says now, but, > for lower risk items, the policy should change, preferably to at least one

Re: Certificates with invalidly long serial numbers

Matthew Hardeman via dev-security-policy writes: >I merely raise the point that IF the framers of the 20 bytes rule did, in >fact, simultaneously intend that arbitrary SHA-1 hash results should be able >to be stuffed into the serial number field AND

RE: Certificates with invalidly long serial numbers

[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Alex Gaynor via dev-security-policy Sent: Tuesday, August 8, 2017 12:46 PM To: Jakob Bohm <jb-mozi...@wisemo.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificates with inv

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 11:26:11 AM UTC-7, Jakob Bohm wrote: > On 08/08/2017 18:43, Ryan Sleevi wrote: > > On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote: > >> I was not advocating "letting everyone decide". I was advocating that > >> Mozilla show some restraint,

Re: Certificates with invalidly long serial numbers

It's from the BRs 4.9.1.1: The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: It's also not a penalty on the CA, it's a remediation step for them to undertake. Alex On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy <

Re: Certificates with invalidly long serial numbers

Some people seemed to require 24-hour revocation of these, which I also find possibly excessive. On 08/08/2017 20:28, Alex Gaynor wrote: I think you're largely objecting to a strawman, no one is proposing revoking trust in any of these threads. The only CAs that have ever had _any_ penalty

Re: Certificates with invalidly long serial numbers

It seems this thread has diverged a bit from its stated purpose, the determination of the question of mis-issuance of a set of certificates which have (possibly) longer than allowed serial numbers. I raised a question as to the history of the selection of the 20 bytes limit for serial numbers

Re: Certificates with invalidly long serial numbers

I think you're largely objecting to a strawman, no one is proposing revoking trust in any of these threads. The only CAs that have ever had _any_ penalty applied to them have been for grotesque abuse of the trust vested in them. Alex On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via

Re: Certificates with invalidly long serial numbers

On 08/08/2017 18:43, Ryan Sleevi wrote: On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote: I was not advocating "letting everyone decide". I was advocating that Mozilla show some restraint, intelligence and common sense in wielding the new weapons that certlint and crt.sh have

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote: > I was not advocating "letting everyone decide". I was advocating that > Mozilla show some restraint, intelligence and common sense in wielding > the new weapons that certlint and crt.sh have given us. > > This shouldn't be race

Re: Certificates with invalidly long serial numbers

I was not advocating "letting everyone decide". I was advocating that Mozilla show some restraint, intelligence and common sense in wielding the new weapons that certlint and crt.sh have given us. This shouldn't be race as to who wields the weapon first, forgiving CAs only if they happen to

Re: Certificates with invalidly long serial numbers

This methodology of "letting everyone decide which parts of the spec/BRs aren't important" doesn't make sense. If there's something wrong with the spec, let's fix it! (Perhaps X.509 validation needs its own equivalent of the "fetch" specification). Giving each CA unilateral authority to ignore

Re: Certificates with invalidly long serial numbers

Ryan Sleevi via dev-security-policy writes: >>Pragmatically, does anything known break on the extra byte there? > >Yes. NSS does. Because NSS properly implements 5280. I would say that's probably more a flaw in NSS then. Does anyone's implementation

Re: Certificates with invalidly long serial numbers

Matthew Hardeman via dev-security-policy writes: >One question: the choice of 20 bytes of serial number is an unusual length >for an integer type. It's not a nice clean power of 2. It doesn't align to >any native integer data type length on any platform

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 12:51:40 AM UTC+9, Matthew Hardeman wrote: > It is what it is, I'm sure, but that definition in RFC5280 is rather tortured > and leads to ambiguity as to whether or not the leading 0x00 is. In fact, I > would say that it is not part of the integer value but rather

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 5:27:13 AM UTC+9, Jakob Bohm wrote: > On 07/08/2017 22:12, Alex Gaynor wrote: > > You seem to be suggesting that the thoroughness of testing is somehow > > related to how long it takes. > > > > I'd expect any serious (or even not particularly serious...) to have a >

Re: Certificates with invalidly long serial numbers

On Monday, August 7, 2017 at 5:20:13 PM UTC-5, Ryan Sleevi wrote: > This is entirely unnecessary and would present serious stability issues due > to backwards compatibility. > > It may not be appropriate for this thread - discussing specific misissuances > - but there is zero benefit from

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 5:18:21 AM UTC+9, Jakob Bohm wrote: > On 07/08/2017 16:54, Peter Bowen wrote: > > On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy > > wrote: > >> Hello > >> > >> I checked only one but I think they are all

Re: Certificates with invalidly long serial numbers

On 07/08/2017 22:12, Alex Gaynor wrote: You seem to be suggesting that the thoroughness of testing is somehow related to how long it takes. I'd expect any serious (or even not particularly serious...) to have a comprehensive automated test suite that can verify that the software is regression

Re: Certificates with invalidly long serial numbers

On 07/08/2017 16:54, Peter Bowen wrote: On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy wrote: Hello I checked only one but I think they are all the same. The integer value of the serial number is 20 octets, but when encoded into

Re: Certificates with invalidly long serial numbers

You seem to be suggesting that the thoroughness of testing is somehow related to how long it takes. I'd expect any serious (or even not particularly serious...) to have a comprehensive automated test suite that can verify that the software is regression free and correct in minutes or hours. If

Re: Certificates with invalidly long serial numbers

On 07/08/2017 18:07, Hanno Böck wrote: On Mon, 7 Aug 2017 15:59:07 + Ben Wilson via dev-security-policy wrote: FWIW - In the case of Telecom Italia, they have a commercial CA product has a bug in it that occasionally causes this issue. They may need

Re: Certificates with invalidly long serial numbers

On Mon, 7 Aug 2017 15:59:07 + Ben Wilson via dev-security-policy wrote: > FWIW - In the case of Telecom Italia, they have a commercial CA > product has a bug in it that occasionally causes this issue. They > may need some time for the software to be

RE: Certificates with invalidly long serial numbers

@lists.mozilla.org] On Behalf Of Matthew Hardeman via dev-security-policy Sent: Monday, August 7, 2017 9:52 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificates with invalidly long serial numbers It is what it is, I'm sure, but that definition in RFC5280 is rather tortured

Re: Certificates with invalidly long serial numbers

It is what it is, I'm sure, but that definition in RFC5280 is rather tortured and leads to ambiguity as to whether or not the leading 0x00 is. In fact, I would say that it is not part of the integer value but rather an explicit sign flag required by the encoding mechanism. Wouldn't it have

Re: Certificates with invalidly long serial numbers

(inserted missed word; off to get coffee now) On Mon, Aug 7, 2017 at 7:54 AM, Peter Bowen wrote: > On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy > wrote: >> Hello >> >> I checked only one but I think they are all

Re: Certificates with invalidly long serial numbers

On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy wrote: > Hello > > I checked only one but I think they are all the same. > > The integer value of the serial number is 20 octets, but when encoded into > DER a starting 00 may be

Re: Certificates with invalidly long serial numbers

Hello I checked only one but I think they are all the same. The integer value of the serial number is 20 octets, but when encoded into DER a starting 00 may be necessary to mark the integer as a positive value : 0 1606: SEQUENCE { 4 1070: SEQUENCE { 83: [0] { 101: