Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 04/06/17 03:03, Matt Palmer wrote: > For whatever it is worth, I am a fan of this way of defining "misissuance". This is an "enumerating badness" vs. "enumerating goodness" question. My original draft attempted to (without limitation) enumerate some badness, and you and Ryan are suggesting

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 07/06/2017 17:41, Ryan Sleevi wrote: On Wed, Jun 7, 2017 at 11:25 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Note that I also had a second, related, point: The possibility that such a new piece of infrastructure was, for other reasons, not

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Wed, Jun 7, 2017 at 11:25 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Note that I also had a second, related, point: The possibility that such > a new piece of infrastructure was, for other reasons, not endorsed by > Mozilla, but of great interest

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 07/06/2017 16:43, Nick Lamb wrote: On Tuesday, 6 June 2017 21:08:54 UTC+1, Ryan Sleevi wrote: Standards defining organization. More usually a Standards _Development_ Organization. I wouldn't usually feel the need to offer this correction but in this context we care a good deal about the

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 07/06/2017 12:55, Rob Stradling wrote: On 06/06/17 22:26, Jakob Bohm wrote: On 06/06/2017 22:08, Ryan Sleevi wrote: Signing data is heavily reliant on CA competency, and that's in unfortunately short supply, as the economics of the CA market make it easy to fire all the engineers, while

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Tuesday, 6 June 2017 21:08:54 UTC+1, Ryan Sleevi wrote: > Standards defining organization. More usually a Standards _Development_ Organization. I wouldn't usually feel the need to offer this correction but in this context we care a good deal about the fact that SDOs are where the actual

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 06/06/17 22:26, Jakob Bohm wrote: On 06/06/2017 22:08, Ryan Sleevi wrote: Signing data is heavily reliant on CA competency, and that's in unfortunately short supply, as the economics of the CA market make it easy to fire all the engineers, while keeping the sales team, and outsourcing

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 06/06/2017 22:08, Ryan Sleevi wrote: On Tue, Jun 6, 2017 at 2:28 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I am saying that setting an administrative policy for inclusion in a root program is not the place to do technical reviews of security

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Tue, Jun 6, 2017 at 2:28 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I am saying that setting an administrative policy for inclusion in a > root program is not the place to do technical reviews of security > protocols. Of course it is. It is the

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 06/06/2017 07:45, Ryan Sleevi wrote: On Mon, Jun 5, 2017 at 6:21 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: If you read the paper, it contains a proposal for the CAs to countersign the computed super-crl to confirm that all entries for that CA

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 04/06/17 03:03, Matt Palmer wrote: > For whatever it is worth, I am a fan of this way of defining "misissuance". So you think we should use the word "misissuance" for all forms of imperfect issuance, and then have a gradated reaction depending on the type and circumstances, rather than use the

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Mon, Jun 5, 2017 at 6:21 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > If you read the paper, it contains a proposal for the CAs to countersign > the computed super-crl to confirm that all entries for that CA match the > actual revocations and

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 02/06/2017 17:12, Ryan Sleevi wrote: On Fri, Jun 2, 2017 at 10:09 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 02/06/2017 15:54, Ryan Sleevi wrote: On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote: On Fri, Jun 2, 2017 at

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Fri, Jun 02, 2017 at 09:54:55AM -0400, Ryan Sleevi via dev-security-policy wrote: > The general principle I was trying to capture was one of "Only sign these > defined structures, and only do so in a manner conforming to their > appropriate encoding, and only do so after validating all the

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Fri, Jun 2, 2017 at 8:12 AM, Ryan Sleevi wrote: > On Fri, Jun 2, 2017 at 10:09 AM Jakob Bohm wrote: > >> On 02/06/2017 15:54, Ryan Sleevi wrote: >> > On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote: >> > >> >> Yes, my concern is that this could make SIGNED{ToBeSigned} considered >> >>

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Fri, Jun 2, 2017 at 10:09 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 02/06/2017 15:54, Ryan Sleevi wrote: > > On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote: > > > >> On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 02/06/2017 15:54, Ryan Sleevi wrote: On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote: On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi wrote: Yes, my concern is that this could make SIGNED{ToBeSigned} considered misissuance if ToBeSigned is not a

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote: > On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi wrote: > Yes, my concern is that this could make SIGNED{ToBeSigned} considered > misissuance if ToBeSigned is not a TBSCertificate. For example, if I > could

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi wrote: > > > On Thu, Jun 1, 2017 at 10:19 PM, Peter Bowen via dev-security-policy > wrote: >> >> On Thu, Jun 1, 2017 at 5:49 AM, Ryan Sleevi via dev-security-policy >> > So I would definitely

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Thu, Jun 1, 2017 at 10:19 PM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Jun 1, 2017 at 5:49 AM, Ryan Sleevi via dev-security-policy > > So I would definitely encourage that improper application of the > protocols > > and data formats

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Thu, Jun 1, 2017 at 5:49 AM, Ryan Sleevi via dev-security-policy wrote: > On Thu, Jun 1, 2017 at 4:35 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 31/05/17 18:02, Matthew Hardeman wrote: >> >

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 31/05/2017 18:04, Gervase Markham wrote: It has been suggested we need a formal definition of what we consider mis-issuance. The closest we have is currently a couple of sentence in section 7.3: "A certificate that includes domain names that have not been verified according to section

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

So how about this:A proper certificate is one that...- contains the data as provided by the requester that the requester intended to use;- contains the data as provided by the issuer that the issuer intended to

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

I think a broad definition is appropriate here. Mozilla is not obliged to do anything at all, much less anything drastic if it is discovered that mis-issuance has occurred. At most we might think it time to re-evaluate this policy. Fools are endlessly inventive so a too narrow definition runs

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Thursday, June 1, 2017 at 8:03:33 AM UTC-5, Gervase Markham wrote: > > My point is not that we are entirely indifferent to such problems, but > that perhaps the category of "mis-issuance" is the wrong one for such > errors. I guess it depends what we mean by "mis-issuance" - which is the >

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 01/06/17 13:49, Ryan Sleevi wrote: > I would encourage you to reconsider this, or perhaps I've misunderstood > your position. To the extent that Mozilla's mission includes "The > effectiveness of the Internet as a public resource depends upon > interoperability (protocols, data formats,

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Thu, Jun 1, 2017 at 4:35 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 31/05/17 18:02, Matthew Hardeman wrote: > > Perhaps some reference to technologically incorrect syntax (i.e. an > incorrectly encoded certificate) being a mis-issuance? > >

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On 31/05/17 18:02, Matthew Hardeman wrote: > Perhaps some reference to technologically incorrect syntax (i.e. an > incorrectly encoded certificate) being a mis-issuance? Well, if it's so badly encoded Firefox doesn't recognise it, we don't care too much (apart from how it speaks to

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

On Wednesday, May 31, 2017 at 11:04:53 AM UTC-5, Gervase Markham wrote: > > If you have suggestions on how to improve this definition, let's keep > brevity in mind :-) Perhaps some reference to technologically incorrect syntax (i.e. an incorrectly encoded certificate) being a mis-issuance? How