...@lists.mozilla.org
Subject: RE: Certificates with metadata-only subject fields
On this particular issue, it's questionable whether these are a violation of
a strict reading of the BRs. Section 7.1.4.2.2(i) defines the OU field.
Section 7.1.4.2.2(j) defines "Any other subject".
Section 7
, 2017 12:24 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields
Can you provide an example of what you believe is a bigger issue that has been
masked? Otherwise, it sounds like you're
metadata.
From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Thursday, August 10, 2017 12:24 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields
Can you provide an example of wh
to:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, August 10, 2017 7:20 AM
To: Ryan Sleevi <r...@sleevi.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=
> digicert.com@lists.mozilla
> .org] On Behalf Of David E. Ross via dev-security-policy
> Sent: Wednesday, August 9, 2017 4:35 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: R
Of David E. Ross via dev-security-policy
Sent: Wednesday, August 9, 2017 4:35 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields
On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>
>> On Aug 9, 2017, at 17:50, Peter Bowen <pzbo.
As a friend of mine sagely points out, fundamentally the current incentives
for a CA are, "Issuing certs gets us money, not issuing certs does not get
us anything". That's an incentive structure that badly needs correction --
CAs should be accountable for what they issue.
Without speaking to
> On Aug 9, 2017, at 18:34, David E. Ross via dev-security-policy
> wrote:
>
> On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>>
>>> On Aug 9, 2017, at 17:50, Peter Bowen wrote:
>>>
>>> The point of certlint was to help identify
On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>
>> On Aug 9, 2017, at 17:50, Peter Bowen wrote:
>>
>> The point of certlint was to help identify issues. While I appreciate
>> it getting broad usage, I don't think pushing for revocation of every
>> certificate that trips any
> On Aug 9, 2017, at 17:50, Peter Bowen wrote:
>
> The point of certlint was to help identify issues. While I appreciate
> it getting broad usage, I don't think pushing for revocation of every
> certificate that trips any of the Error level checks is productive.
I agree,
The point of certlint was to help identify issues. While I appreciate
it getting broad usage, I don't think pushing for revocation of every
certificate that trips any of the Error level checks is productive.
This reminds of me of people trawling a database of known
vulnerabilities then reporting
And this is exactly why we need separate tiers of revocation. Here, there is
zero risk to the end user. I do think it should be fixed and remediated, but
revoking all these certs within 24 hours seems unnecessarily harsh. I think
there was a post about this a while ago, but I haven't been
12 matches
Mail list logo