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 that
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 endorsed
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 t
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
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 k
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 engi
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 the
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
proto
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 o
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 matc
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
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 non-revo
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 4:27 AM, Ryan Sleevi
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 nece
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
>> >> misissua
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 wrote:
> >> Yes, my concern is
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 TBSCertificate. For example, if I
could sign
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 sign an ASN.1 sequence which had the fol
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 encourage that improper application of the
>> > protocols
>>
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 constitut
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:
>> > Perhaps some reference to technologically inco
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 3.2.2.4
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 us
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 t
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
> ent
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, content)
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?
>
>
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 incompetence).
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
29 matches
Mail list logo