Re: Leaking private keys through web servers

[Jakob Bohm via dev-security-policy]

On 14/07/2017 21:04, Ryan Sleevi wrote:

On Fri, Jul 14, 2017 at 2:07 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


That's my point.  The current situation is distinct from weak keys, and
we shouldn't sacrifice the weak keys BR to make room for a compromised
keys BR.



But a weak key is always suspected of having suffered a Key Compromise - is
it not?




That is, changing to from "weak keys" to "suspected or known to have
suffered Key Compromise" in 6.1.1.3 would fully include weak keys (which
are already in scope) as well as include those excluded (compromised,
strong). This applies in addition to the requirements already present in
6.1.5/6.1.6 regarding key sizes and strengths (which already counter your
hypothetical), and 4.9.1.1/4.9.1.2 address the situation if a strong key,
post issuance, becomes either weak or compromised.



I would say a key whose strength against attack is significantly below
that of normally accepted keys (say 256 times less work factor with the
best known attack) would be a weak key, even though that might still
require a year or more on the best known hardware at fort Meade.

A suspected key compromise is a higher degree of badness (say > 0.01%
chance that attackers will have the key now or in the next 72 hours).

Heartbleed, Debian weak keys or leaving the private key in a public
place would be suspected or actual key compromise, because attackers may
have already gotten the private key using a known attack and almost
trivial effort, and there is no way to tell.

A 2048 bit RSA key which somehow has only the cryptographic strength
normally associated with a 1536 bit RSA key would be a weak key, but
still unlikely to be cracked within a few weeks of revealing the public
key.  And since an actual 1536 bit RSA key would be too weak to allow
issuance under BR 6.1.5, issuing a new certificate issued to such a
"special form" 2048 bit RSA key would be reasonably considered against
6.1.1.3 .

Now we obviously don't know the nature of yet-to-be-published 
cryptanalytical attacks, but if a new attack applies to only some keys, 
and those keys can be identified from the public keys, similar to how 
there is currently a formula for detecting "weak SHA-1" hashes, then CAs 
should apply that formula in a pre-issuance test under 6.1.1.3, but 
would not require instant revocation of all such keys under 4.9.1.2 #3, 
though CA subscribers would be encouraged to voluntarily reissue and 
revoke such keys as they are spotted by e.g. Qualsys SSL checks or 
database scans by the CA.


P.S.

The classical example of "weak keys" is of cause the special forms of
DES symmetric keys that were known 30 years ago, at a time when cracking
regular full DES keys was still beyond most attackers.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Ryan Sleevi via dev-security-policy]

On Fri, Jul 14, 2017 at 2:07 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> That's my point.  The current situation is distinct from weak keys, and
> we shouldn't sacrifice the weak keys BR to make room for a compromised
> keys BR.


But a weak key is always suspected of having suffered a Key Compromise - is
it not?

That is, changing to from "weak keys" to "suspected or known to have
suffered Key Compromise" in 6.1.1.3 would fully include weak keys (which
are already in scope) as well as include those excluded (compromised,
strong). This applies in addition to the requirements already present in
6.1.5/6.1.6 regarding key sizes and strengths (which already counter your
hypothetical), and 4.9.1.1/4.9.1.2 address the situation if a strong key,
post issuance, becomes either weak or compromised.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Jakob Bohm via dev-security-policy]

On 14/07/2017 18:19, Ryan Sleevi wrote:

On Fri, Jul 14, 2017 at 11:11 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 14/07/2017 15:53, Ryan Sleevi wrote:


On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:



But that doesn't clearly include keys that are weak for other reasons,
such as a 512 bit RSA key with an exponent of 4 (as an extreme example).



Yes. Because that's clearly not necessary - because it's already covered
by
4.9.1.1 #3 and 6.1.5/6.1.6. So I don't think this serves as a valid
criticism to the proposed update.



That's why I called it an "extreme example".  Point was that the current
wording requires CAs to reject public keys that fail any reasonable test
for weakness not just the explicit cases listed in the BRs (such as too
short RSA keys or small composite public exponents).

For example if it is published that the RSA requirements in 6.1.6 are
insufficient (for example that moduli with more than 80% 1-bits are
weak), then the current wording of 6.1.1.3 would require CAs to
instigate such a test without waiting for a BR update.



Sure, but that's unrelated to the discussion at hand, at least from what
you've described. However, if I've misunderstood you, it might help if you
rephrase the argument from what was originally being discussed - which is
CAs issuing certificates for compromised keys - which are arguably distinct
from weak keys (which was the point I was making).



That's my point.  The current situation is distinct from weak keys, and
we shouldn't sacrifice the weak keys BR to make room for a compromised
keys BR.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Ryan Sleevi via dev-security-policy]

On Fri, Jul 14, 2017 at 11:11 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 14/07/2017 15:53, Ryan Sleevi wrote:
>
>> On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> But that doesn't clearly include keys that are weak for other reasons,
>>> such as a 512 bit RSA key with an exponent of 4 (as an extreme example).
>>>
>>>
>> Yes. Because that's clearly not necessary - because it's already covered
>> by
>> 4.9.1.1 #3 and 6.1.5/6.1.6. So I don't think this serves as a valid
>> criticism to the proposed update.
>>
>>
> That's why I called it an "extreme example".  Point was that the current
> wording requires CAs to reject public keys that fail any reasonable test
> for weakness not just the explicit cases listed in the BRs (such as too
> short RSA keys or small composite public exponents).
>
> For example if it is published that the RSA requirements in 6.1.6 are
> insufficient (for example that moduli with more than 80% 1-bits are
> weak), then the current wording of 6.1.1.3 would require CAs to
> instigate such a test without waiting for a BR update.
>

Sure, but that's unrelated to the discussion at hand, at least from what
you've described. However, if I've misunderstood you, it might help if you
rephrase the argument from what was originally being discussed - which is
CAs issuing certificates for compromised keys - which are arguably distinct
from weak keys (which was the point I was making).

It sounds like you're saying "No, they're weak" - but I both acknowledged
and refuted that interpretation in my message, so perhaps I simply do not
understand the relation of what you're discussing above to the general
issue Hanno raised.


> Maybe it would be better stylistically to add this to one of the other
>>> BR clauses.
>>>
>>>
>> Considering that the goal is to make it clearer, I'm not sure this
>> suggestion furthers that goal.
>>
>>
> It could be in a new clause 6.1.1.3.1 (not applicable to SubCAs) or a
> new clause 6.1.1.4 (applicable to all public keys, not just subscribers)
> or a new clause 6.1.6.1 (ditto), or it could be added as an additional
> textual paragraph in 6.1.1.3 or 6.1.6 .
>

I'm afraid at this point, I'm completely lost as to the point you're trying
to make.

But at least 4.9.1.1 #3 requires them to revoke without waiting for a
> new report.


No, "it depends". And that was the point I was trying to make.


> And it would be obviously and patently bad faith to revoke
> the same key every 24 hours and claim all is well (once or twice may be
> an understandable oversight, since this is not such a common scenario,
> but after that they should start automating the rejection/revocation).


I don't think you can or should ascribe bad faith here; my entire point was
to highlight the possible interpretation issues - but to further highlight
why the thing you call "patently bad faith" is itself fraught with peril,
and thus it's reasonable to argue that it's not bad faith.

If this is not desirable, we should strive to make it clearer - but that
means acknowledging the edge cases, determining what is appropriate, and
providing sufficient guidance so that, in the future, it might be more
successfully argued as bad faith.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Jakob Bohm via dev-security-policy]

On 14/07/2017 16:07, Alex Gaynor wrote:

On Fri, Jul 14, 2017 at 10:03 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

...

>> ...

Ultimately I'm inclined to say that there really shouldn't be any good
reason at all to ever reuse a key. (Except... HPKP)



I see. I think I'd strongly disagree with that assertion. There are lots of
good reasons to reuse keys. The most obvious example being for
shorter-lived certificates (e.g. 90 days), which allow you to rotate the
key in case of compromise, but otherwise don't require you to do so.
Considering revocation information is no longer required to be provided
once a certificate expires, it _also_ means that in the CA Foo case, with
Key X compromised, the subscriber could get another cert for it once the
original cert has expired (and thus revocation information no longer able
to be provided)



What you described is a case where it's not harmful to reuse a key, not a
case in which it's a good reason to. Indeed defaulting to rotating your key
on every new certificate is probably the safest choice, as it ensures that
"key compromise" is no different from any other rotation, and keeps that
hinge well oiled.



His scenario did include "Key X compromised" .


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Jakob Bohm via dev-security-policy]

On 14/07/2017 15:53, Ryan Sleevi wrote:

On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


But that doesn't clearly include keys that are weak for other reasons,
such as a 512 bit RSA key with an exponent of 4 (as an extreme example).



Yes. Because that's clearly not necessary - because it's already covered by
4.9.1.1 #3 and 6.1.5/6.1.6. So I don't think this serves as a valid
criticism to the proposed update.



That's why I called it an "extreme example".  Point was that the current
wording requires CAs to reject public keys that fail any reasonable test
for weakness not just the explicit cases listed in the BRs (such as too
short RSA keys or small composite public exponents).

For example if it is published that the RSA requirements in 6.1.6 are
insufficient (for example that moduli with more than 80% 1-bits are
weak), then the current wording of 6.1.1.3 would require CAs to
instigate such a test without waiting for a BR update.




Maybe it would be better stylistically to add this to one of the other
BR clauses.



Considering that the goal is to make it clearer, I'm not sure this
suggestion furthers that goal.



It could be in a new clause 6.1.1.3.1 (not applicable to SubCAs) or a
new clause 6.1.1.4 (applicable to all public keys, not just subscribers)
or a new clause 6.1.6.1 (ditto), or it could be added as an additional
textual paragraph in 6.1.1.3 or 6.1.6 .




Anyway, I think this is covered by BR 4.9.1.1 #3, although it might not
be obvious to the CA that they should have set up checks for this, since
most key compromise reports come from the subscriber, who would be a lot
less likely to make this mistake after revoking the key themselves,
except when the revocation was mistaken (this happens, and in that case,
reusing the key is not a big problem).



I'm afraid you may have misunderstood the point. Certainly, 4.9.1.1 #3
covers revocation. However, my suggestion was about preventing issuance,
which is why I was talking about 6.1.1.3. That is, unquestionably, if a CA
revokes a certificate for key compromise, then issues a new one for that
same key, they're obligated under 4.9.1.1 #3 to revoke within 24 hours. My
point was responding to Hanno's suggestion of preventing them from issuing
the second certificate at all.



But at least 4.9.1.1 #3 requires them to revoke without waiting for a
new report.  And it would be obviously and patently bad faith to revoke
the same key every 24 hours and claim all is well (once or twice may be
an understandable oversight, since this is not such a common scenario,
but after that they should start automating the rejection/revocation).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Alex Gaynor via dev-security-policy]

On Fri, Jul 14, 2017 at 10:03 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > So there are several questions and possible situations here.
> >
> > I think it's relatively clear that a CA could prevent reissuance of
> > certs if they know about a key compromise.
> >
>
> I actually don't think it's clear, that's why I was trying to highlight the
> challenges.
>
> That is, I think we can all agree that for situations where you reported
> directly to the CA, it was clear that the CA had knowledge that the
> associated private key was compromised. Presumably, a requirement to
> prevent issuance would mean that the CA maintains a blacklist of
> 'compromised keys' and refuses to issue certificates for them.
>
> However, if we say that the CA shall not prevent for situations of
> compromise, the following interpretations exist, and we should try to
> figure out first what we want (from an ecosystem) and then how to specify
> that.
> - Are we expecting the CA to maintain a database of compromised private
> keys (I believe the implied answer is 'yes' - but today, they only need
> maintain the database of revoked certificates, which is different)
> - Is the CA obligated to check other sources of compromise information
> prior to issuing the certificate.
>   - Example: Should they check other CAs' CRLs? The CRLs themselves don't
> provide information about the key, so one would presumably _also_ need to
> check sources like Certificate Transparency.
>   - Tortured example: What happens if a (different CA's) cert is not logged
> in CT, revoked in the CRL (for keyCompromise), and then subsequently
> disclosed to first CA. Are they obligated to revoke (under 4.9.1.1 #3)? Are
> they obligated to not issue (under the proposed change)?
>
> The reason I highlight this is that preventing CA "Foo" from issuing a
> second cert for (compromised) key X doesn't prevent CA "Bar" from doing the
> same. Because of this, it's a reasonable question about what security value
> we're obtaining, if the party with Key X can simply go to another CA to get
> the cert.
>
> From a CA perspective, requiring that Foo reject a request that Bar can
> accept would be unappealing to Foo - it's effectively giving business to
> Bar (whether or not this is actually the case, and however illogical it is,
> there are plenty of CAs who think this way)
>
> From a security perspective, requiring that Foo not issue for key X doesn't
> ensure that a cert for key X will not be introduced, not unless we make the
> requirement of all CAs.
>
> So that's why I'm not sure how much value we'd get from such a requirement
> - and wanted to highlight the challenges in finding a way to establish it
> for all CAs, and why it's important (for CAs and relying parties) for a
> consistent requirement.
>
>
> > Ultimately I'm inclined to say that there really shouldn't be any good
> > reason at all to ever reuse a key. (Except... HPKP)
>
>
> I see. I think I'd strongly disagree with that assertion. There are lots of
> good reasons to reuse keys. The most obvious example being for
> shorter-lived certificates (e.g. 90 days), which allow you to rotate the
> key in case of compromise, but otherwise don't require you to do so.
> Considering revocation information is no longer required to be provided
> once a certificate expires, it _also_ means that in the CA Foo case, with
> Key X compromised, the subscriber could get another cert for it once the
> original cert has expired (and thus revocation information no longer able
> to be provided)
>

What you described is a case where it's not harmful to reuse a key, not a
case in which it's a good reason to. Indeed defaulting to rotating your key
on every new certificate is probably the safest choice, as it ensures that
"key compromise" is no different from any other rotation, and keeps that
hinge well oiled.

Alex


> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Ryan Sleevi via dev-security-policy]

On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> So there are several questions and possible situations here.
>
> I think it's relatively clear that a CA could prevent reissuance of
> certs if they know about a key compromise.
>

I actually don't think it's clear, that's why I was trying to highlight the
challenges.

That is, I think we can all agree that for situations where you reported
directly to the CA, it was clear that the CA had knowledge that the
associated private key was compromised. Presumably, a requirement to
prevent issuance would mean that the CA maintains a blacklist of
'compromised keys' and refuses to issue certificates for them.

However, if we say that the CA shall not prevent for situations of
compromise, the following interpretations exist, and we should try to
figure out first what we want (from an ecosystem) and then how to specify
that.
- Are we expecting the CA to maintain a database of compromised private
keys (I believe the implied answer is 'yes' - but today, they only need
maintain the database of revoked certificates, which is different)
- Is the CA obligated to check other sources of compromise information
prior to issuing the certificate.
  - Example: Should they check other CAs' CRLs? The CRLs themselves don't
provide information about the key, so one would presumably _also_ need to
check sources like Certificate Transparency.
  - Tortured example: What happens if a (different CA's) cert is not logged
in CT, revoked in the CRL (for keyCompromise), and then subsequently
disclosed to first CA. Are they obligated to revoke (under 4.9.1.1 #3)? Are
they obligated to not issue (under the proposed change)?

The reason I highlight this is that preventing CA "Foo" from issuing a
second cert for (compromised) key X doesn't prevent CA "Bar" from doing the
same. Because of this, it's a reasonable question about what security value
we're obtaining, if the party with Key X can simply go to another CA to get
the cert.

From a CA perspective, requiring that Foo reject a request that Bar can
accept would be unappealing to Foo - it's effectively giving business to
Bar (whether or not this is actually the case, and however illogical it is,
there are plenty of CAs who think this way)

From a security perspective, requiring that Foo not issue for key X doesn't
ensure that a cert for key X will not be introduced, not unless we make the
requirement of all CAs.

So that's why I'm not sure how much value we'd get from such a requirement
- and wanted to highlight the challenges in finding a way to establish it
for all CAs, and why it's important (for CAs and relying parties) for a
consistent requirement.


> Ultimately I'm inclined to say that there really shouldn't be any good
> reason at all to ever reuse a key. (Except... HPKP)


I see. I think I'd strongly disagree with that assertion. There are lots of
good reasons to reuse keys. The most obvious example being for
shorter-lived certificates (e.g. 90 days), which allow you to rotate the
key in case of compromise, but otherwise don't require you to do so.
Considering revocation information is no longer required to be provided
once a certificate expires, it _also_ means that in the CA Foo case, with
Key X compromised, the subscriber could get another cert for it once the
original cert has expired (and thus revocation information no longer able
to be provided)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Ryan Sleevi via dev-security-policy]

On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> But that doesn't clearly include keys that are weak for other reasons,
> such as a 512 bit RSA key with an exponent of 4 (as an extreme example).
>

Yes. Because that's clearly not necessary - because it's already covered by
4.9.1.1 #3 and 6.1.5/6.1.6. So I don't think this serves as a valid
criticism to the proposed update.


> Maybe it would be better stylistically to add this to one of the other
> BR clauses.
>

Considering that the goal is to make it clearer, I'm not sure this
suggestion furthers that goal.


> Anyway, I think this is covered by BR 4.9.1.1 #3, although it might not
> be obvious to the CA that they should have set up checks for this, since
> most key compromise reports come from the subscriber, who would be a lot
> less likely to make this mistake after revoking the key themselves,
> except when the revocation was mistaken (this happens, and in that case,
> reusing the key is not a big problem).
>

I'm afraid you may have misunderstood the point. Certainly, 4.9.1.1 #3
covers revocation. However, my suggestion was about preventing issuance,
which is why I was talking about 6.1.1.3. That is, unquestionably, if a CA
revokes a certificate for key compromise, then issues a new one for that
same key, they're obligated under 4.9.1.1 #3 to revoke within 24 hours. My
point was responding to Hanno's suggestion of preventing them from issuing
the second certificate at all.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Hanno Böck via dev-security-policy]

On Wed, 12 Jul 2017 10:47:51 -0400
Ryan Sleevi  wrote:

> One challenge to consider is how this is quantified. Obviously, if you
> reported to Comodo the issue with the key, and then they issued
> another certificate with that key, arguably that's something Comodo
> should have caught. However, if you reported the compromise to, say,
> ACME CA, and then Comodo issued an equivalent cert, that's
> questionable. I'm loathe to make CAs rely on eachothers'
> keyCompromise revocation reasons, simply because we have no normative
> guidance in the BRs (yet) that require CAs be honest or competent
> with their revocation reasons (... yet). Further, we explicitly don't
> want to have a registry (of compromised keys, untrustworthy orgs,
> etc), for various non-technical reasons.
> 
> I'm curious if you have thoughts there - particularly, how you
> reported the private key was compromised (did you provide evidence -
> for example, a signed message, or simply a link to "Here's the URL,
> go see for yourself"?)
> - and how you see it working cross-CA boundaries.

To answer this question: As the private keys were available on webpages
I simply reported the URLs and corresponding certs to the CAs.
(This was also with the intention that in case the CA has a contact to
their customer they could inform them about the key on their server,
though I'm not sure if any CA informed them.)

So there are several questions and possible situations here.

I think it's relatively clear that a CA could prevent reissuance of
certs if they know about a key compromise.

Another question is if there has been a revocation that wasn't clearly
tied to a key compromise. On the other hand I hardly see any reason why
anyone would revoke a cert if there isn't any indication of a
compromise.

The next question would be if there should be a cross-CA blacklisting
of compromised keys. I think that would be valuable, but of course it
raises a lot of questions on how this information should be shared
(share the private keys? public keys? spki hashes? share it in public
or only between CAs?).

Ultimately I'm inclined to say that there really shouldn't be any good
reason at all to ever reuse a key. (Except... HPKP)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Jakob Bohm via dev-security-policy]

On 12/07/2017 16:47, Ryan Sleevi wrote:

On Wed, Jul 12, 2017 at 10:19 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


* Comodo re-issued certs with the same key. I wonder if there should be
   a rule that once a key compromise event is known to the CA it must
   make sure this key is blacklisted. (Or maybe one of the existing
   rules already apply, I don't know.)



BRs 1.4.5 6.1.1.3 only requires the CA to reject a certificate if it
doesn't mean 6.1.5/6.1.6 or is known weak private key.

While the example is given (e.g. Debian weak keys), one could argue that
'weak' includes 'disclosed'. Of course, given that the specific term "Key
Compromise" is also provided in the BRs, that seems a stretch.

One could also argue 6.1.2 is applicable - that is, revocation was
immediately obligated because of the awareness - but that also seems
tortured.

Probably the easiest thing to do is update the BRs in 6.1.1.3 to replace
"known weak private key" to just say "If the private key is suspected or
known to have suffered Key Compromise" - which includes known weak private
keys, as well as the broader sense.



But that doesn't clearly include keys that are weak for other reasons,
such as a 512 bit RSA key with an exponent of 4 (as an extreme example).


One challenge to consider is how this is quantified. Obviously, if you
reported to Comodo the issue with the key, and then they issued another
certificate with that key, arguably that's something Comodo should have
caught. However, if you reported the compromise to, say, ACME CA, and then
Comodo issued an equivalent cert, that's questionable. I'm loathe to make
CAs rely on eachothers' keyCompromise revocation reasons, simply because we
have no normative guidance in the BRs (yet) that require CAs be honest or
competent with their revocation reasons (... yet). Further, we explicitly
don't want to have a registry (of compromised keys, untrustworthy orgs,
etc), for various non-technical reasons.

I'm curious if you have thoughts there - particularly, how you reported the
private key was compromised (did you provide evidence - for example, a
signed message, or simply a link to "Here's the URL, go see for yourself"?)
- and how you see it working cross-CA boundaries.



Maybe it would be better stylistically to add this to one of the other
BR clauses.

Anyway, I think this is covered by BR 4.9.1.1 #3, although it might not
be obvious to the CA that they should have set up checks for this, since
most key compromise reports come from the subscriber, who would be a lot
less likely to make this mistake after revoking the key themselves,
except when the revocation was mistaken (this happens, and in that case,
reusing the key is not a big problem).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 13, 2017 at 7:07 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 12/07/17 15:47, Ryan Sleevi wrote:
> > One challenge to consider is how this is quantified. Obviously, if you
> > reported to Comodo the issue with the key, and then they issued another
> > certificate with that key, arguably that's something Comodo should have
> > caught.
>
> I'd say so.
>
> > However, if you reported the compromise to, say, ACME CA, and then
> > Comodo issued an equivalent cert, that's questionable.
>
> Sure. This would be a provision to deter accidental stupidity, not
> wilful stupidity. The common case is a clueless person just resubmits
> the same keypair to their current CA.
>

Right. My point in that was that it's easy to rathole into a definition of
"known Key Compromise" that  implies an obligation to check others
revocation lists to see if a certificate with the same public key has been
revoked due to keyCompromise, which is further undesirable given that CAs
can't be trusted with the revocation reasons in the first place.

My goal was to try to capture that, to some extent, the burden of knowledge
can only be on the CA's own direct knowledge - which means it only prevents
the subscriber from getting a cert (from the same CA), and not from another
CA. This is both a limitation of the mitigation - it doesn't prevent
another CA from issuing - and a potential concern from CAs - others can
issue what they cannot.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Leaking private keys through web servers

[Gervase Markham via dev-security-policy]

On 12/07/17 15:47, Ryan Sleevi wrote:
> One challenge to consider is how this is quantified. Obviously, if you
> reported to Comodo the issue with the key, and then they issued another
> certificate with that key, arguably that's something Comodo should have
> caught. 

I'd say so.

> However, if you reported the compromise to, say, ACME CA, and then
> Comodo issued an equivalent cert, that's questionable. 

Sure. This would be a provision to deter accidental stupidity, not
wilful stupidity. The common case is a clueless person just resubmits
the same keypair to their current CA.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Leaking private keys through web servers

[Hanno Böck via dev-security-policy]

Hello,

I recently did an investigation where I tried to simply download private
keys from web servers with common filenames. I collected these
filenames simply from common tutorials on the web (server.key,
privatekey.key, myserver.key, key.pem and [hostname].key with and
without www).
In several cases I was able to download private keys belonging to
currently valid certificates.

I wrote about this today for the German news site Golem.de (with an
english translation available):
https://www.golem.de/news/https-private-keys-on-web-servers-1707-128862.html


In the course of this I also learned quite a bit about the revocation
process. According to the baseline requirements a CA shall revoke keys
within 24 hours in case of a key compromise.

Some notes about my experiences:
* All certificates I reported are revoked now.
* In several cases the deadline wasn't hit and CAs took longer. Some
  took over 4 days. In one case (Gandi) I learned that it's a branded
  CA from Comodo. Comodo immediately revoked the cert after they
  learned about it, but this raises interesting questions about the
  responsibilities of branded CAs.
* The reporting process is wildly different. Some CAs provide email
  addresses, others online forms, Symantec has forms with captchas. In
  the April CA communications [1] mozilla announced that it wants to
  compile a list of contact methods and has asked CAs for them. I would
  encourage streamlining that process. I also think revocation should
  be automatable (at least on the side of the reporter) and wonder
  whether things like forms with captchas should be outruled.
  Particularly interesting is Let's Encrypt that provides an API via
  ACME to revoke if you posess the private key. IMHO that's ideal.
* Comodo re-issued certs with the same key. I wonder if there should be
  a rule that once a key compromise event is known to the CA it must
  make sure this key is blacklisted. (Or maybe one of the existing
  rules already apply, I don't know.)

I had opened a private bug in mozillas bugtracker which contains some
more info and lists of the specific certificates. It's up to mozilla
when they'll open it, but from my side I think this can go public.


[1] https://wiki.mozilla.org/CA/Communications#April_2017_Responses
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1378074
-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy