On Saturday, 9 March 2019 03:44:12 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 outcome
Dimitris Zacharopoulos via dev-security-policy
writes:
>If we have to count every CA that had this interpretation, then I suppose all
>CAs that were using EJBCA with the default configuration have the same
>interpretation.
There's also an unknown number of CAs not using EJBCA that may have
Adding to this discussion, and to support that there were -in fact-
different interpretations (all in good faith) please check the issue I
had created in Dec 2017 https://github.com/awslabs/certlint/issues/56.
My simple interpretation of the updated requirement in 7.1 at the time
was that "no
On Fri, Mar 8, 2019 at 7:55 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Fri, Mar 8, 2019 at 9:49 PM Ryan Sleevi wrote:
>
> > I consider that only a single CA has represented any ambiguity as being
> > their explanation as to why the
On Fri, Mar 8, 2019 at 10:54 PM Matthew Hardeman
wrote:
>
>
> On Fri, Mar 8, 2019 at 9:49 PM Ryan Sleevi wrote:
>
>> I consider that only a single CA has represented any ambiguity as being
>> their explanation as to why the non-compliance existed, and even then,
>> clarifications to resolve
On Fri, Mar 8, 2019 at 9:49 PM Ryan Sleevi wrote:
> I consider that only a single CA has represented any ambiguity as being
> their explanation as to why the non-compliance existed, and even then,
> clarifications to resolve that ambiguity already existed, had they simply
> been sought.
>
On Fri, Mar 8, 2019 at 10:29 PM Matthew Hardeman
wrote:
> I would appreciate your thoughts on it.
>
I consider the matter more than settled, based on the clear historic
evidence, so I see no value in engaging further. The amount of time and
energy necessary to evaluate and reason about it seems
On Fri, Mar 8, 2019 at 8:52 PM Ryan Sleevi wrote:
I appreciate the attention to detail, but I find it difficult to feel that
> it is a good faith effort that is designed to produce results consistent
> with the goals that many of this community have and share, and thus don't
> think it would be
On Fri, Mar 8, 2019 at 8:57 PM Peter Gutmann
wrote:
> Matthew Hardeman via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
>
> >shall be 0x75
>
> Not 0x71?
>
:-) In truth, I think any particular chosen single value for the first
byte which has the high order bit set to 0
Matthew Hardeman via dev-security-policy
writes:
>shall be 0x75
Not 0x71?
>If anyone thinks any of this has merit, by all means run with it.
Sounds good, and saves me having to come up with something (the
bitsort(CSPRNG64()) nonsense took enough time to type up). The only thing I
somewhat
On Fri, Mar 8, 2019 at 7:22 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Pursuant to the plain language of 7.1 as written, that circumstance --
> regardless of how it would occur -- would appear to be a misissuance.
>
I've already addressed this
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
the issues which have arisen from the present BR 7.1
On Fri, Mar 8, 2019 at 9:27 PM Peter Gutmann
wrote:
> Ryan Sleevi writes:
>
> >I'm not sure this will be a very productive or valuable line of
> discussion.
>
> What I'm pointing out is that beating up CAs over an interpretation of the
> requirements that didn't exist until about a week ago
Ryan Sleevi writes:
>I'm not sure this will be a very productive or valuable line of discussion.
What I'm pointing out is that beating up CAs over an interpretation of the
requirements that didn't exist until about a week ago when it was pointed out
in relation to DarkMatter is unfair on the
On Fri, Mar 8, 2019 at 8:26 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Daymion Reynolds via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
>
> >Our goal is to reissue all the certificates within the next 30 days.
>
> Before
I wrote:
>So the immediate application of this observation is to make any 64-bit value
>comply with the ASN.1 encoding rules: If the first bit is 1 (so the sign bit
>is set), swap it with any convenient zero bit elsewhere in the value.
>Similarly, if the first 9 bits are zero, swap one of them
On Fri, Mar 8, 2019 at 8:11 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I didn't post this as part of yesterday's message because I didn't want to
> muddy the waters even further, but let's look at the exact wording of BR
> 7.1:
>
> All fully
On Fri, Mar 08, 2019 at 09:35:21PM +, Jeremy Rowley via
> dev-security-policy wrote: If they need some help with large scale
> replacement, I know some people who did that recently. Joking of
> course, but really - with Godaddy, Google, and Apple reporting a large
> number of certs that have
(Sending from the right e-mail this time)
Thanks for the responses! I think this is a great thing to bring here,
because there are some interplays with policy and implications that can
affect the design, as I discuss below. I'm trying to be mindful of
proffering solutions outside of the TLS-WG,
Daymion Reynolds via dev-security-policy
writes:
>Our goal is to reissue all the certificates within the next 30 days.
Before everyone goes into an orgy of mass revocation, see the message I just
posted "Why BR 7.1 allows any serial number except 0". As long as your serial
number isn't zero,
I didn't post this as part of yesterday's message because I didn't want to
muddy the waters even further, but let's look at the exact wording of BR 7.1:
CAs SHALL generate non-sequential Certificate serial numbers greater than
zero (0) containing at least 64 bits of output from a CSPRNG
Note
On Friday, March 8, 2019 at 6:05:05 PM UTC-6, Ryan Sleevi wrote:
> You're absolutely correct that two certificates, placed next to eachother,
> could appear sequential. Someone might then make a claim that the CA has
> violated the requirements. The CA can then respond by discussing how they
>
Our goal is to reissue all the certificates within the next 30 days. We have
started the revocation process. We have a significant number of customers that
use manual methods for managing their certificates, so being agile for them is
difficult. We want to keep our customers using https through
On Fri, Mar 8, 2019 at 6:50 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I am well aware of the reason for the entropy in the certificate serial
> number. What I'm having trouble with is that there can be no dispute that
> two certificates with
On Fri, Mar 8, 2019 at 3:10 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Having sequential serial numbers is not problematic. Having *predictable*
> serial numbers is problematic.
My problem with this is that, if we parse the english language
### Problem description
SSL.com has issued a limited number of ECDSA certificates with
curve-hash pairs that are no longer allowed by the Mozilla Root Store
Policy.
In particular, section 5.1 states that:
> Root certificates in our root program, and any certificate which
chains up to them, MUST
On Fri, Mar 8, 2019 at 4:03 PM Jeremy Rowley
wrote:
> Apologies, I realize that Mozilla’s policy is that revocation is up to the
> CA and there is no such thing as an exception. A more careful way to state
> what I meant is that I’m surprised that there is not more discussion around
> the
Apologies, I realize that Mozilla’s policy is that revocation is up to the CA
and there is no such thing as an exception. A more careful way to state what I
meant is that I’m surprised that there is not more discussion around the
revocation of all of these certificates and the impact to the
Ryan beat me to the punch. so I'll reinforce his message with my own:
The overall potential impact from revocations in the current scenario feels
quite similar to the potential for disruption from revoking certificates
containing underscores a few months ago. Mozilla's guidance for revocation
[1]
On Fri, Mar 8, 2019 at 4:35 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> does Mozilla want to require a complete revocation and replacement? Seems
> like a lot of effort and disruption for little value to the Mozilla
> community.
I'm surprised,
On Fri, Mar 8, 2019 at 4:35 PM watson--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> We are interested in CAs signing x509 certificates that can be used with
> delegated credentials for TLS,
> https://tools.ietf.org/html/draft-ietf-tls-subcerts-03. The certificates
>
We are interested in CAs signing x509 certificates that can be used with
delegated credentials for TLS,
https://tools.ietf.org/html/draft-ietf-tls-subcerts-03. The certificates to be
signed by the CA are x509 certificates that contain a special extension that
identifies them as being able to
If they need some help with large scale replacement, I know some people who did
that recently . Joking of course, but really - with Godaddy, Google, and Apple
reporting a large number of certs that have what seems to be a minor compliance
issue in light of the certs all being SHA2, does
My apologies to the list for having unintentionally posted two
rather different versions of the same post, one long, and one
short.
I had initially tried to post using the Google Groups web interface,
but there was, apparently, a dramatic lag time in that post actually
being relayed to the list
Yesterday, Apple submitted this preliminary incident report:
https://bugzilla.mozilla.org/show_bug.cgi?id=1533655, which is reposted below.
On 2019-03-06 we determined that we were issuing certificates with
non-compliant serial numbers because of the EJBCA issue [1]. We fixed the
problem
Later this month, I would like to begin discussing a number of proposed
changes to the Mozilla Root Store policy [1]. I have reviewed the list of
issues on GitHub and labeled the ones that I recommend discussing:
https://github.com/mozilla/pkipolicy/labels/2.7 They are:
173 - Strengthen
On Friday, 8 March 2019 17:07:57 UTC+1, Wayne Thayer wrote:
> I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1533774 to track
> this issue.
>
> Apple has also submitted the following bug for this issue listing a large
> number of impacted certificates:
>
I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1533774 to track
this issue.
Apple has also submitted the following bug for this issue listing a large
number of impacted certificates:
https://bugzilla.mozilla.org/show_bug.cgi?id=1533655
- Wayne
On Thu, Mar 7, 2019 at 7:14 PM Matthew
Hi Jakob,
On Thursday, March 7, 2019 at 7:30:03 PM UTC+1, Jakob Bohm wrote:
> In the cause of the other discussion it was revealed that EJBCA by PrimeKey
> has apparently:
>
> 1. Made serial numbers with 63 bits of entropy the default. Which is
> not in compliance with the BRs for globally
Wow!
I read this whole thread from top to bottom this afternoon/evening, and all I
got was a splitting headache and this lousy t-shirt: https://bit.ly/2UpZxIz
But seriously folks, just a couple of simple questions.
Firstly, is this a private discussion or may any member of the Great Unwashed
On Thursday, March 7, 2019 at 11:14:46 AM UTC-5, Matthew Hardeman wrote:
> On Thu, Mar 7, 2019 at 10:10 AM Ken Myers (personal capacity) via
> dev-security-policy wrote:
>
> > Is the issue that a Dark Matter business unit may influence the Dark
> > Matter Trust Services (a separate unit, but
On Thursday, March 7, 2019 at 6:35:13 PM UTC-5, Matt Palmer wrote:
> On Thu, Mar 07, 2019 at 10:20:34AM -0600, Matthew Hardeman wrote:
> > Let's Encrypt does not quite provide certificates to everyone around the
> > world. They do prevent issuance to and revoke prior certificates for those
> > on
On Fri, Mar 8, 2019 at 7:31 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Many (not me) in the recent discussion of a certain CA have called
> for this to be changed one way or another. This is the only thing
> that is new.
>
I do not believe this is an
I've read what I believe to be all of the messages in this thread to
date, but it appears that I may have missed something.
The word "transparency" and/or derivatives thereof has come up several
times in this thread. Also, that same word, or derivatives thereof,
was/were included no fewer than
On 08/03/2019 06:27, Peter Bowen wrote:
...
Mozilla has specifically chosen to not distinguish between "government
CAs", "national CAs", "commercial CAs", "global CAs", etc. The same rules
apply to every CA in the program. Therefore, the "national or other
affiliation" is not something that
On Thu, Mar 07, 2019 at 08:47:46PM -0600, Matthew Hardeman via
dev-security-policy wrote:
> On Thu, Mar 7, 2019 at 8:29 PM Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > Past analysis and discussion have shown the interpretation is hardly
> > specific to
On Friday, 8 March 2019 04:28:17 UTC+1, Matt Palmer wrote:
> On Thu, Mar 07, 2019 at 09:03:22PM -0600, Matthew Hardeman via
> dev-security-policy wrote:
> > On Thu, Mar 7, 2019 at 8:54 PM bif via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> > > But BRs are not to be
47 matches
Mail list logo
