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-issue DV cert) to complete validatio
t; 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 lik
ity-policy
[mailto: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 invalidly long serial numbers
On Wednesd
ehalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, August 10, 2017 4:13 PM
To: Jakob Bohm
Cc: mozilla-dev-security-policy
Subject: Re: Certificates with invalidly long serial numbers
Could you explain how it benefits Mozilla users to optimize for OV or EV, given
that it does not provid
t.com@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
-security-policy
>> [mailto: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:
ust 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 receive
revocation requests 24x7
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 be
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 penalty
-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
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 certificate
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 hash results should be able
> >to be stu
(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 r
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
mailto:agay...@mozilla.com>> wrote:
I'm not really sure I agree that there should be
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 change
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 DV
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 party
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
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
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 SIMULTANEOUSLY that the DER
>encoded integer f
olicy
[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
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers
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 change formally, CAs should be required to meet th
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, intellige
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 <
dev-security-poli
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 appl
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 a
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 dev-security-po
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 g
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
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 repo
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
what
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 seriously expect things to work, and by exte
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 I'm aware of.
It exactly matches the SH
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 a
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
> >
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 exten
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 the same.
> >>
> >> The integer value of
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 fr
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 DER
a starting 00 may be necessary to ma
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 you
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 some time for the software to be fixed/
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 fixed/replaced.
I'm more worried by this
@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
tor
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 bee
(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 the same.
>>
>> The integer value of the serial number is 2
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 necessary to mark the integer as a positive valu
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:
47 matches
Mail list logo
