Looking at the BRs, specifically BR 4.9.1, the reasons that can lead
to fast revocation fall into a few categories / groups:
(I will reference the numbered items with 24 hour limit as A#, the numbered
items with 120 hour limit as B# and the numbered items in 4.9.1.2 as C#).
(Some of the
On Fri, Dec 28, 2018 at 03:19:19AM +, Jeremy Rowley via dev-security-policy
wrote:
> > I'm not sure I'd call it "leniency", but I think you're definitely asking
> > for "special treatment" -- pre-judgment on a potential incident so you can
> > decide whether or not it's worth it (to
>> I think Matt provided a pretty clear moral hazard here - of customers
>> suggesting their CAs didn't do enough (e.g. should have tried harder to
>> intentionally violated by not revoking). One significant way to mitigating
>> that risk is to take meaningful steps to ensure that "We couldn't
On Thu, Dec 27, 2018 at 10:00 PM Jeremy Rowley
wrote:
> The risk Matt identified is too nebulous of an issue to address, tbh. How
> do you address a moral issue? The only way I can think of to address the
> moral issue is to say “we promise to be good”. But the weight that carries
> depends on
> I don't think there's *any* result from all this that everyone would
> consider desirable -- otherwise we wouldn't need to have this conversation.
+ 1 to that.
> I'm not sure I'd call it "leniency", but I think you're definitely asking
> for "special treatment" -- pre-judgment on a potential
The risk Matt identified is too nebulous of an issue to address, tbh. How do
you address a moral issue? The only way I can think of to address the moral
issue is to say “we promise to be good”. But the weight that carries depends on
how much you trust the actor. If you trust the actor, then
On Thu, Dec 27, 2018 at 11:56:41PM +, Jeremy Rowley via dev-security-policy
wrote:
> The risk is primarily outages of major sites across the web, including
> certs used in Google wallet. We’re thinking that is a less than desirable
> result, but we weren’t sure how the Mozilla community
On Thu, Dec 27, 2018 at 6:56 PM Jeremy Rowley
wrote:
> The risk is primarily outages of major sites across the web, including
> certs used in Google wallet. We’re thinking that is a less than desirable
> result, but we weren’t sure how the Mozilla community would feel/react.
>
I don’t think
Treading carefully…
Mozilla is the only browser related to the discussion. Probably sufficient to
say that the revocation/no-revoke decision is entirely dependent on the results
of this thread.
From: James Burton
Sent: Thursday, December 27, 2018 6:07 PM
To: Jeremy Rowley
Cc: Matt
I disagree that we won't get that. I think we could see a "it's okay to wait
until April 30 for large pharmacy" or "Waiting until April 30 is too long
but March 1 is okay". I don't think Mozilla wants outages either. But... if
Mozilla did say that we should revoke now, that would be great as well.
The 7 required items under the Mozilla template are:
1. Timeline of events
2. Timeline of actions taken
3. Whether the CA has stopping issuing
4. Summary of problematic certs
5. Cert data
6. How mistakes were made
7. Remediation plan
The info we’re working
On Thu, Dec 27, 2018 at 9:04 AM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, 27 Dec 2018 15:30:01 +0100
> Jakob Bohm via dev-security-policy
> wrote:
>
> > The problem here is that the prohibition lies in a complex legal
> > reading of multiple
On Fri, Dec 28, 2018 at 12:12:03AM +, Jeremy Rowley via dev-security-policy
wrote:
> This is very helpful. If I had those two options, we'd just revoke all the
> certs, screw outages. Unfortunately, the options are much broader than that.
> If I could know what the risk v. benefit is, then
It clearly wasn't understood by everyone. That's why we had two ballots on it,
one of them failing to address the issue. You can just look through the long
discussions on the topic to see people didn't agree.
-Original Message-
From: dev-security-policy On
Behalf Of Jakob Bohm via
This is very helpful. If I had those two options, we'd just revoke all the
certs, screw outages. Unfortunately, the options are much broader than that.
If I could know what the risk v. benefit is, then you can make a better
decision? DigiCert distrusted - all revoked. DigiCert gets some mar on its
This is accurate. We have the technical capability and policy ability to
revoke the certificates. What we were hoping was a discussion based on
impact of the revocation so we could hear what we should do. Blind obedience
isn't my favorite answer, but it's an option. The guidance so far is file an
The risk is primarily outages of major sites across the web, including certs
used in Google wallet. We’re thinking that is a less than desirable result, but
we weren’t sure how the Mozilla community would feel/react. We’re still
considering revoking all of the certs on Jan 15th based on these
On Thu, Dec 27, 2018 at 01:19:26PM -0800, Peter Bowen via dev-security-policy
wrote:
> I don't see how this follows. DigiCert has made it clear they are able to
> technically revoke these certificates and presumably are contractually able
> to revoke them as well. What is being said is that
On 27/12/2018 18:03, Nick Lamb wrote:
> On Thu, 27 Dec 2018 15:30:01 +0100
> Jakob Bohm via dev-security-policy
> wrote:
>
>> The problem here is that the prohibition lies in a complex legal
>> reading of multiple documents, similar to a situation where a court
>> rules that a set of laws has an
On Thu, Dec 27, 2018 at 9:00 PM Ryan Sleevi wrote:
> I'm not really sure I understand this response at all. I'm hoping you can
> clarify.
>
> On Thu, Dec 27, 2018 at 3:45 PM James Burton wrote:
>
>> For a CA to intentionally state that they are going to violate the BR
>> requirements means that
On Thu, Dec 27, 2018 at 12:53 PM thomas.gh.horn--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> As to why these certificates have to be revoked, you should see this the
> other way round: as a very generous service of the community to you and
> your customers!
>
>
On Thu, Dec 27, 2018 at 12:12 PM Wayne Thayer wrote:
> On Wed, Dec 26, 2018 at 2:42 PM Peter Bowen via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> In the discussion of how to handle certain certificates that no longer
>> meet
>> CA/Browser Forum baseline
I'm not really sure I understand this response at all. I'm hoping you can
clarify.
On Thu, Dec 27, 2018 at 3:45 PM James Burton wrote:
> For a CA to intentionally state that they are going to violate the BR
> requirements means that that CA is under immense pressure to comply with
> demands or
As to why these certificates have to be revoked, you should see this the other
way round: as a very generous service of the community to you and your
customers!
Certificates with (pseudo-)hostnames in them are clearly invalid, so a
conforming implementation should not accept them for
For a CA to intentionally state that they are going to violate the BR
requirements means that that CA is under immense pressure to comply with
demands or face retribution. The severity inflicted on a CA by
intentionally violating the BR requirements can be severe. Rolling a dice
of chance. Why
I'm not trying to throw you under the bus here, but I think it's helpful if
you could highlight what new information you see being required, versus
that which is already required.
I think, yes, you're right that it's not well received if you go violate
the BRs and then, after the fact, say "Hey,
On Thu, Dec 27, 2018 at 8:34 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Thu, Dec 27, 2018 at 11:12 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Yes, you are consistently mischaracterizing everything
On 27/12/2018 17:28, Ryan Sleevi wrote:
On Thu, Dec 27, 2018 at 11:12 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Yes, you are consistently mischaracterizing everything I post.
My question was a refinement of the original question to the one case
On Wed, Dec 26, 2018 at 1:03 PM Jeremy Rowley
wrote:
> Much better to treat this question as “We know X is going to happen.
> What’s the best way to mitigate the concerns of the community?” Exception
> was the wrong word in my original post. I should have used “What would you
> like us to do to
On Thu, 27 Dec 2018 15:30:01 +0100
Jakob Bohm via dev-security-policy
wrote:
> The problem here is that the prohibition lies in a complex legal
> reading of multiple documents, similar to a situation where a court
> rules that a set of laws has an (unexpected to many) legal
> consequence.
I
On Thu, Dec 27, 2018 at 11:12 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Yes, you are consistently mischaracterizing everything I post.
>
> My question was a refinement of the original question to the one case
> where the alternative in the original
The main reason that publicly trusted certificates are used by
organizations for all infrastructure (internal and external) is that it's
far cheaper than building and maintaining an internal PKI.
On Thu, Dec 27, 2018 at 4:14 PM Jakob Bohm via dev-security-policy <
On 27/12/2018 17:13, Jakob Bohm wrote:
On 27/12/2018 17:02, Rob Stradling wrote:
On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote:
For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp-
browserWwwServerAuth" . WWW is mentioned only in a comment under the
OID
On 27/12/2018 17:02, Rob Stradling wrote:
On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote:
For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp-
browserWwwServerAuth" . WWW is mentioned only in a comment under the
OID definition.
Hi Jakob.
Are you suggesting
On 27/12/2018 16:55, Ryan Sleevi wrote:
On Thu, Dec 27, 2018 at 10:41 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
He described three combined conditions to be met. You've described a
situation "What if you meet two, but not three". I believe that was
On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote:
> For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp-
> browserWwwServerAuth" . WWW is mentioned only in a comment under the
> OID definition.
Hi Jakob.
Are you suggesting that comments in ASN.1 specifications are
On Thu, Dec 27, 2018 at 10:41 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > He described three combined conditions to be met. You've described a
> > situation "What if you meet two, but not three". I believe that was
> > originally captured in his
On Thu, Dec 27, 2018 at 10:38 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> PKIX clearly uses definitions that make it clear that the same PKI
> should be used for most/all TLS implementations for the public Internet,
> and this is indeed the common
On 27/12/2018 16:24, Ryan Sleevi wrote:
> On Thu, Dec 27, 2018 at 9:34 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 26/12/2018 22:42, Peter Bowen wrote:
>>> In the discussion of how to handle certain certificates that no longer
>> meet
>>>
On 27/12/2018 16:16, Ryan Sleevi wrote:
On Thu, Dec 27, 2018 at 9:30 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Also it isn't the "Web PKI". It is the "Public TLS PKI", which is not
confined to Web Browsers surfing online shops and social networks,
On Thu, Dec 27, 2018 at 9:34 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 26/12/2018 22:42, Peter Bowen wrote:
> > In the discussion of how to handle certain certificates that no longer
> meet
> > CA/Browser Forum baseline requirements, Wayne asked
On Thu, Dec 27, 2018 at 9:30 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Also it isn't the "Web PKI". It is the "Public TLS PKI", which is not
> confined to Web Browsers surfing online shops and social networks, and
> hasn't
> been since at least the
On 26/12/2018 22:42, Peter Bowen wrote:
> In the discussion of how to handle certain certificates that no longer meet
> CA/Browser Forum baseline requirements, Wayne asked for the "Reason that
> publicly-trusted certificates are in use" by the customers. This seems to
> imply that Mozilla has an
On 27/12/2018 13:39, Nick Lamb wrote:
> As a relying party I read this in the context of the fact that we're
> talking about names that are anyway prohibited.
>
The problem here is that the prohibition lies in a complex legal reading
of multiple documents, similar to a situation where a court
As a relying party I read this in the context of the fact that we're talking about names that are anyway prohibited.Why would you need a publicly trusted certificate that specifies a name that is publicly prohibited?I guess the answer is "But it works on Windows". And Windows is welcome to
On 27/12/2018 10:35, Matt Palmer via dev-security-policy wrote:
> Hmm, Rob's reply never made it to my inbox. I'll reply to that separately
> now I know it's a thing.
Hi Matt. I'm consistently receiving "Undelivered Mail Returned to
Sender" messages from your mailserver, which is presumably
> On Tue, Dec 18, 2018 at 8:19 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > On 10/12/2018 18:09, Ryan Sleevi wrote:
> > > On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via
> > > dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
>
On Wed, 19 Dec 2018 05:09:11 -0600, Rob Stradling wrote:
> How do you handle malformed SPKIs? (e.g., the algorithm parameters
> field for an RSA public key is missing, whereas it should be present and
> should contain an ASN.1 NULL).
>
> Presumably your server/database only deals with
Hmm, Rob's reply never made it to my inbox. I'll reply to that separately
now I know it's a thing.
On Thu, Dec 27, 2018 at 05:56:08PM +0900, Hector Martin 'marcan' via
dev-security-policy wrote:
> On 19/12/2018 20:09, Rob Stradling via dev-security-policy wrote:
> > I'm wondering how I might
On 19/12/2018 20:09, Rob Stradling via dev-security-policy wrote:
I'm wondering how I might add a pwnedkeys check to crt.sh. I think I'd
prefer to have a table of SHA-256(SPKI) stored locally on the crt.sh DB.
Yes, I think the right approach for an upstream source is to provide a
big list of
50 matches
Mail list logo
