Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours

[Piotr Kucharski via dev-security-policy]

For 0% of impact the FPs do not matter that much, so agreed!

Of course for now reality is not that... yet!
https://github.com/certbot/certbot/issues/1028 seems so appropriate :)

PS  I was definitely not advocating for 5% false negative, no; we must
strive for 0% false negatives as well; all I was saying was exercising
caution for the perhaps-not-so-clear-cut 5% cases. (Probably closer to 1%)

On Tue, 10 Mar 2020 at 23:08, Ryan Sleevi  wrote:

>
>
> On Tue, Mar 10, 2020 at 5:56 PM Piotr Kucharski  wrote:
>
>> I'm sympathetic to CAs wanting to filter out the noise of shoddy reports
>>> and shenanigans, but I'm also highly suspicious of CAs that put too
>>> unreasonable an onus on reporters. It seems, in the key compromise case,
>>> the benefit of the doubt should largely deal with the reporter. If we saw
>>> some quantifiable increase in hijinks and misrevocations, there are a
>>> myriad of ways to deal with that. The most effective of these reasons seems
>>> to be facilitating rapid replacement of certificates, rather than
>>> preferring ossification.
>>>
>>
>> I am totally against putting unreasonable onus on reporters! But
>> hopefully you agree that CAs should strive for zero false positives in
>> revocations.
>>
>
> I'd happily take a 95% false positive of revocations if there were 0%
> impact in the revocation (e.g. due to easy replacement). I'm mainly
> hesitant to setting up a system of 0% false positives but which has a 5%
> false negative.
>
> That's why I'm less excited for standard systems of signaling revocation
> (not that there isn't some value!), and more keen on systems that make
> revocation easier, quicker, and less-impactful. That's obviously Hard Work,
> but that's the exciting part of working in PKI. Everything is Hard Work
> these days :D
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours

[Piotr Kucharski via dev-security-policy]

On Tue, 10 Mar 2020 at 22:19, Ryan Sleevi  wrote:

>
>
> On Tue, Mar 10, 2020 at 4:25 PM bif via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Matt,
>>
>> Voluntarily providing CSR is not an ideal way to prove key compromise,
>> because you could've simply found this CSR somewhere (I know, I know, super
>> unlikely with your Subject... but still could happen.)
>>
>
> That seems to be making the perfect the enemy of the good.
>

Most likely :) Take it as more general musings for having generally
accepted recipes for providing proof of key possession, using which would
not allow CAs to wiggle out of responsibility of revocation.


> This seems like a perfectly reasonable thing to allow and accept. If we're
> concerned about someone "might" having done something as a reason to reject
> it, it seems like we'd need another pass through the BRs validation methods
> - e.g. to remove the non-IANA-reserved mail addresses.
>

Sure, as long as CN is long enough, and CSR is clean, ie. no
extensions allowing to fit, say, collision attacks.


>
> I don't disagree that this is a possibility, but the probability of this
> possibility seems incredibly low, and the risk of a CA deciding to revoke
> on this basis seems immeasurably better than the risk of deciding to not
> revoke.
>

As a CA I would most likely accept this proof, considering the incredibly
low false positive possibility. :)
All I'm saying is that proof of key possession is not clearly defined in
the absence of said key being shared with a CA.


>
>
>> And while "compromised" is way too short (one can sign up to 32 bytes
>> using it as a nonce in regular TLS session) to prove the key compromise, in
>> the absence of the actual compromised private key, about the only way to
>> ensure the possession is to get the reporter to sign some data chosen by
>> the CA. It very well may be a random CN in the CSR, or plain old openssl
>> dgst.
>>
>
> I'm concerned about CAs disproportionately adding burdens to reporters of
> compromise. For example, your 'compromised' case doesn't really make sense.
> The string 'compromised', or even the hash of the string 'compromised',
> would not in and of itself be a sufficient TLS transcript. I agree with you
> that one can't simply /look/ for the string 'compromised' in the unsigned
> data, where that signed data is a TLS transcript, but that's not what you
> really described, and that distinction seems important.
>
> I also disgree with, and have concerns with, the CA being able to direct
> the signing of the data. I think the ecosystem learned a lot from the
> Heartbleed scenario, of "We're not affected, we're not affected... oh crap,
> we're affected".
>

> I'm sympathetic to CAs wanting to filter out the noise of shoddy reports
> and shenanigans, but I'm also highly suspicious of CAs that put too
> unreasonable an onus on reporters. It seems, in the key compromise case,
> the benefit of the doubt should largely deal with the reporter. If we saw
> some quantifiable increase in hijinks and misrevocations, there are a
> myriad of ways to deal with that. The most effective of these reasons seems
> to be facilitating rapid replacement of certificates, rather than
> preferring ossification.
>

I am totally against putting unreasonable onus on reporters! But hopefully
you agree that CAs should strive for zero false positives in revocations.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: A modest proposal for a better BR 7.1

[Piotr Kucharski via dev-security-policy]

On Wed, Mar 13, 2019 at 5:52 AM Ryan Sleevi  wrote:

>
>
> On Tue, Mar 12, 2019 at 11:18 PM bif via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> FWIW, the easiest would've been to remove "positive" aspect of serials.
>> Who really cares? A random number is a random number.
>>
>
> RFC 5280 cares, as it's been a long-standing source of compat issues,
> which is why RFC 5280 itself made the 'positive' requirement.
>
> https://tools.ietf.org/html/rfc5280#section-4.1.2.2
>

Oh, I know RFC is the source of this requirement (and even in that, it says
"should handle").
All I was saying, a number is a number, and making this exception only
solidified wrong implementations (said compat issues), instead of healing
the ecosystem (forcing wrong implementations to be fixed).

But I understand that's not the battle to be won or even fought here. :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla’s Plan for Symantec Roots

[Piotr Kucharski via dev-security-policy]

On Mon, Feb 12, 2018 at 5:36 PM, Kai Engert  wrote:

> > For example, if you note, there are two Google certificates, but they
> > share the same SPKI and Subject Name - which is why the Chromium
> > whitelist only has one certificate listed, as it extracts the SPKI from
> > that resource as part of the whitelist.
>
> Are you referring to these two subCAs?
>   https://crt.sh/?id=23635000
>   https://crt.sh/?id=142951186
>
> It seems the first one has already expired, and it might no longer be
> necessary to worry about it?
>

While nothing is certain, it is likely that Google might have another subCA
certificate issued with the same SPKI and Subject.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy