On Tue, Mar 12, 2019 at 11:18 PM bif via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> FWIW, the easiest would've been to remove "positive" aspect of serials.
> Who really cares? A random number is a random number.
>
RFC 5280 cares, as it's been a long-standing source of
Overall I think it's a neat scheme.
It does impose some trade-offs beyond the mechanism that I proposed:
1. It leaves the implementing CA with no space within the serial number
field to include a CA significant sequence number, timestamp, or other
value. That may not be a bad thing, but it's
On Saturday, March 9, 2019 at 3:44:12 AM UTC+1, Matthew Hardeman wrote:
> I know this isn't the place to bring a BR ballot, but I'm not presently a
> participant there.
>
> I present alternative language along with notes and rationale which, I put
> forth, would have resulted in a far better
Rob Stradling via dev-security-policy
writes:
>I've been working on an alternative proposal for a serial number generation
>scheme, for which I intend to write an I-D and propose to the LAMPS WG.
This seems really, really complicated. In all of the endless debate over
this, the one thing that
From 2018-10-17 to 2019-03-06, DFN-PKI issued 40 certificates with
wrong ST-Field. 35 server certificates, 5 user certificates.
Details can be found here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1534580
Thanks,
Jürgen
___
On 12/03/2019 07:54, Ryan Sleevi via dev-security-policy wrote:
On Mon, Mar 11, 2019 at 5:35 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Since choice 1 is a logical consequence of "containing 64 bits of random
data", I was always under the
Hi all. I've been working on an alternative proposal for a serial
number generation scheme, for which I intend to write an I-D and propose
to the LAMPS WG. However, since other folks' proposals are already
flowing, I will share the gist of mine here. Comments welcome!
- Serial Number
Daymion,
You linked to a thread in m.d.s.p and cited it as confirming a specific
interpretation of 7.1 - as that's a long thread (with some possible
questionable information), could you possibly share what criteria you used to
determine what certificates were impacted by this issue and which
Good day,
I want to share what is happening right now with the insistance of a certificat
for my domain.
I have setup my CAA record and request a certificat form a new CA, but forgot
to correct my CAA record.
The certificat insurance fail, all good.
I detect the issue but in the mean time
As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit certificate
Serial Number issue. Due to a m.d.s.p.[1] discussion validating an
interpretation of BR 7.1 our revised count is approximately 12,152 live
certificates not meeting the 64bit serial number requirement. Additionally, we
On Tue, Mar 12, 2019 at 12:07 PM Mike Kushner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Unless you're going under the presumption that the MSB doesn't count as a
> part of the serial number (and I've never seen an RFC or requirement
> pointing to that being the
On Tue, Mar 12, 2019 at 12:08 PM Thomas-Louis Laforest via
dev-security-policy wrote:
> Good day,
>
> I want to share what is happening right now with the insistance of a
> certificat for my domain.
>
> I have setup my CAA record and request a certificat form a new CA, but
> forgot to correct my
Apple just submitted an updated report:
Incident Report
How your CA first became aware of the problem (e.g. via a problem report
submitted to your Problem Reporting Mechanism, a discussion in
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the
time and date.
Apple
On March 11, 2019; Apple submitted a followup Incident Report.
https://bugzilla.mozilla.org/show_bug.cgi?id=1533655.
Incident Report
How your CA first became aware of the problem (e.g. via a problem report
submitted to your Problem Reporting Mechanism, a discussion in
> I think when it comes to specifications with cryptographic relevance (as
> unpredictable serials are), less is more; the more inflexible and
> unambiguous the spec is, the less likely it will be "creatively
> interpreted" in a manner that bypasses the whole point. To someone with
> crypto
On Tue, Mar 12, 2019 at 7:14 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 5. As a special exception, systems that require signing certificates
>with the same serial-number more than once (such as CT and CA
>validity adjustments) are not required
On 09/03/2019 03:43, Matthew Hardeman wrote:
> I know this isn't the place to bring a BR ballot, but I'm not presently a
> participant there.
>
> I present alternative language along with notes and rationale which, I put
> forth, would have resulted in a far better outcome for the ecosystem than
On Tuesday, March 12, 2019 at 9:54:56 AM UTC-7, ad...@adamcaudill.com wrote:
> Daymion,
>
> You linked to a thread in m.d.s.p and cited it as confirming a specific
> interpretation of 7.1 - as that's a long thread (with some possible
> questionable information), could you possibly share what
On 12/03/2019 21.10, Mike Kushner via dev-security-policy wrote:
>>> There are no, and has never been any, 63 bit serial numbers created by
>>> EJBCA.
>>
>> ... lead me to significantly reduce my trust in those making them, and
>> their ability to correctly interpret security-critical standards
On Tue, Mar 12, 2019 at 2:22 PM Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> The crux of the difference is in the DER format interpretation. The fact
> prefix (0)s do count for entropy, provided none of the bits are fixed and
> you have a minimum of 8
On Tue, Mar 12, 2019 at 2:49 PM Hector Martin 'marcan' via
dev-security-policy wrote:
> What I'm saying is that merely sticking to the most convenient
> interpretation for you and deflecting all responsibility for how we
> ended up here is not productive, and does not scream trustworthiness.
>
One item that I think could bear a useful discussion from these incident
reports is how the community can get more involved in discussing and helping
with incident reports. For example, the 63 bit serial number issue is leading
to a lot of certs potentially being revoked with little benefit to
On Tue, Mar 12, 2019 at 4:17 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> A new flow that includes the community more fully could be:
> 1) Post to Mozilla, the post must include an initial proposed plan of
> action
> 2) Create an incident report (to
Not looking for blanket approval – I stated it’d still be part of the audit
report. We also aren’t directly impacted by this particular incident (which is
why I brought it up here). The actual evaluation of the CA would remain up to
Mozilla of course, but the really good discussion about 63
On Tue, Mar 12, 2019 at 4:23 PM Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tuesday, March 12, 2019 at 11:32:38 AM UTC-7, Ryan Sleevi wrote:
> > On Tue, Mar 12, 2019 at 2:22 PM Daymion Reynolds via dev-security-policy
> <
> >
On Tue, Mar 12, 2019 at 4:38 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I think the primary change I’m proposing is that the initial report
> shouldn’t be an incident report. Instead, the initial report can be short
> blurb posted to Mozilla along
On Tuesday, March 12, 2019 at 11:32:38 AM UTC-7, Ryan Sleevi wrote:
> On Tue, Mar 12, 2019 at 2:22 PM Daymion Reynolds via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > The crux of the difference is in the DER format interpretation. The fact
> > prefix (0)s do count
On 13/03/2019 05.38, Ryan Sleevi via dev-security-policy wrote:
> Note that even 7 bytes or less may still be valid - for example, if the
> randomly generated integer was 4 [1], you might only have a one-byte serial
> in encoded form ( '04'H ), and that would still be compliant. The general
>
On Tue, Mar 12, 2019 at 4:57 PM Hector Martin 'marcan'
wrote:
> On 13/03/2019 05.38, Ryan Sleevi via dev-security-policy wrote:
> > Note that even 7 bytes or less may still be valid - for example, if the
> > randomly generated integer was 4 [1], you might only have a one-byte
> serial
> > in
On Wed, Mar 13, 2019 at 05:56:55AM +0900, Hector Martin 'marcan' via
dev-security-policy wrote:
> On 13/03/2019 05.38, Ryan Sleevi via dev-security-policy wrote:
> > Note that even 7 bytes or less may still be valid - for example, if the
> > randomly generated integer was 4 [1], you might only
30 matches
Mail list logo
