Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Kyle Hamilton]

As far as I know, GeoTrust is not at fault here.  They just signed this
(domain validated) certificate, and I don't know if they've been
notified of it before.  That said, I don't have GeoTrust's contact info,
and I'm presuming that someone here does.

Information here comes from
http://blog.sec-consult.com/2016/09/house-of-keys-9-months-later-40-worse.html
.  The private key for this certificate was published by SEC Consult (a
Singaporean company) in a public github repo that documents static TLS
keys in embedded device firmware, located at
https://github.com/sec-consult/houseofkeys/ .

Aruba is the OEM for various Alcatel-Lucent OmniAccess firmware.  They
embedded a certificate (trusted by GeoTrust) and its private key into
the firmware for more than 10 different models of OmniAccess.  This
certificate is in CT logs, and is currently valid until August 11, 2017. 
Issuer is OU "C=US, O=GeoTrust Inc., OU=Domain Validated SSL,
CN=GeoTrust DV SSL CA".
Subject is "serialNumber=lLUge2fRPkWcJe7boLSVdsKOFK8wv3MF, C=US,
O=securelogin.arubanetworks.com, OU=GT28470348, OU=See
www.geotrust.com/resources/cps (c)11, OU=Domain Control Validated -
QuickSSL(R) Premium, CN=securelogin.arubanetworks.com".
Serial number is 121426.

The certificate (and the usual information about it) can be found at
https://censys.io/certificates/47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534
.

The private key for the certificate can be found at
https://github.com/sec-consult/houseofkeys/blob/master/certificates/47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534.key
or by pulling the aforementioned github repo.

Aruba chose not to notify GeoTrust that it needed to be revoked due to
compromised private  key.  I am notifying because I believe it violates
the Basic Requirements for someone other than the identified subject to
possess the private key for a publicly-trusted certificate.

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

Re: Reuse of serial numbers

[Kyle Hamilton]

On 9/6/2016 04:59, Ben Laurie wrote:
> On 1 September 2016 at 11:29, Peter Gutmann  wrote:
>> Rob Stradling  writes:
>>
 I guess it makes them easy to revoke, if a single revocation can kill 313
 certs at once.
>>> That's true.
>> Hey, WoSign has solved the CRL scalability problem!
>>
>>> It'd be impossible to revoke (via CRL and/or OCSP) a subset of those 313
>>> certs though.
>> I also get the feeling that a lot of PKI software won't handle the revocation
>> properly, because they're expecting to revoke *the* certificate, not the
>> certificate, and the other certificate, and that other one there too, and 
>> that
>> one in the corner, and ... .  In other words I'm assuming most code will 
>> treat
>> serial numbers as unique and assume the revocation acted on when the first
>> cert has been marked as invalid.
> That seems unlikely to me (in that browsers don't really keep a server
> cert database).

Has that changed?  I talked with Dan Veditz (at Mozilla) around 5 years
ago regarding the fact that NSS had told me of duplicate serial numbers
being issued by a single issuer, and that as a result Firefox had
refused to permit me to connect to a site and also refused to allow me
to examine the certificate or identify it issuer for myself.  I had to
use OpenSSL to get it.  His action item at the time was to increase
reportability of those issues to Mozilla, because (paraphrased from his
words) "a CA issuing duplicate serial numbers is a violation of all of
the specifications and we need to know about it, to figure out what else
they're doing wrong".

(That was during a conversation where I told him I'd come up with a
means of putting multiple end-entity certs into the TLS Certificate
message, in a way that proved possession of all of them but which would
break strict PKIX formatting of that message's content.)

-Kyle H

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

Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Kyle Hamilton]

On 9/12/2016 20:20, Jakob Bohm wrote:
> On 13/09/2016 03:03, Kyle Hamilton wrote:
>> I would prefer not to see a securelogin-.arubanetworks.com
>> name, because such makes it look like Aruba Networks is operating the
>> captive portal.  If (for whatever reason) the system is compromised, or
>> the login process is altered, or there's a need to enter credit card
>> information [I do not know if these devices can be configured to require
>> payment, but since this group typically discusses policy in general I
>> think it's appropriate to address during this discussion] but there are
>> then unauthorized charges caused by the device being compromised, then
>> Aruba Networks is going to be the one who's called to answer for it.
>> Because Aruba sells the devices and plays no part in their ongoing
>> operation, they'll quite rightly shut any claim down.  This leads the
>> user to have no recourse.  I think it would be better if there were a
>> mandate that all of these devices obtain ACME (i.e., Let's Encrypt)
>> certificates when they first start up.
>>
>> Provisioning a self-signed certificate for the administrator to
>> configure the device with prior to obtaining an ACME certificate would
>> in my mind be legitimate, as a warning that "hey, the device isn't
>> completely configured yet".  However, since I'm not a User Experience
>> guy, I may be incorrect here.
>>
>> I also suggest that the now-revoked certificate should be put in the
>> OneCRL, because of its widespread
>> captive-DNS/captive-network/no-CRL-or-OCSP-retrieval environment and
>> compromised private key.
>>
>> -Kyle H
>>
> Just to clarify, I never said that the use was for a "captive portal"
> or other such 3rd party hit address.  My presumption was that
> https://securelogin.arubanetworks.com would be a manually entered URL
> printed in the user manual or on the device itself.  However you may
> have other sources for it being a captive portal.

http://community.arubanetworks.com/t5/Wireless-Access/Certificate-securelogin-arubanetworks-com-and-trial-SSL-certs/td-p/28158
is an Aruba Networks customer request to alter the name that the users
are directed to with a "guest wifi pass".  This, and other things,
indicate that the name in the now-revoked certifcate is used for captive
portal authentication (to prevent users from having their credentials
sniffed over an unencrypted wifi connection).

> The securelogin-.arubanetworks.com domain name was my
> hypothetical/suggested name for a cert not associated with a
> shared/compromised key, but with a per-device certificate and key
> generated on a secure production line before the device was put in a
> cardboard box and shipped on a slow boat from China.

Understood.

> The point of having a real trusted cert rather than a self-signed cert
> for the first-time login would be to protect the user against a WiFi
> spoofed MiTM, a protection which is gone for the revoked cert due to
> the publicly compromised key.

I understand.  In this instance, I don't think it's quite as much a
problem as you're concerned about.  The configuration of such a
(managed, non-consumer-level) device would generally be performed over
the hardware network -- either in the configuration lab of the network
provider who purchased and is installing it, or on-site via the
hardwired network connection that it's bridging access to.  That
interface is guaranteed not to have guests connecting directly to it,
and so is really the only appropriate interface for secure things like
configuration to be done over.  (That said, there's a lot of
security-unconscious manufacturers out there -- but if they're
security-unconscious, they probably won't listen to this bit of security
advice, either.)

For actual instances of configuration interfaces exposed over WiFi, this
approach is probably infeasible without a reworking of the architecture
of such devices (perhaps akin to the changes required by FCC for
consumer wifi routers in US to prevent installers of DD-WRT from setting
their region to Japan and using unauthorized 2.4GHz spectrum above
802.11a/b/g channel 11), as updated device firmware would need to be
distributed without the keys and certificates (which would need to stay
in secure memory, approximately like the firmware wifi chip driver
configurations now used to meet FCC's mandate).  I understand that this
is what you suggested.

However, the firmware of those devices would need to prevent the
proposed key and certificate from being used for anything other than the
administration interface, in order to prevent a misattribution attack
against the user and hardware manufacturer.  It would be difficult to
achieve this with any platform that had an open platform

Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Kyle Hamilton]

I would prefer not to see a securelogin-.arubanetworks.com
name, because such makes it look like Aruba Networks is operating the
captive portal.  If (for whatever reason) the system is compromised, or
the login process is altered, or there's a need to enter credit card
information [I do not know if these devices can be configured to require
payment, but since this group typically discusses policy in general I
think it's appropriate to address during this discussion] but there are
then unauthorized charges caused by the device being compromised, then
Aruba Networks is going to be the one who's called to answer for it. 
Because Aruba sells the devices and plays no part in their ongoing
operation, they'll quite rightly shut any claim down.  This leads the
user to have no recourse.  I think it would be better if there were a
mandate that all of these devices obtain ACME (i.e., Let's Encrypt)
certificates when they first start up.

Provisioning a self-signed certificate for the administrator to
configure the device with prior to obtaining an ACME certificate would
in my mind be legitimate, as a warning that "hey, the device isn't
completely configured yet".  However, since I'm not a User Experience
guy, I may be incorrect here.

I also suggest that the now-revoked certificate should be put in the
OneCRL, because of its widespread
captive-DNS/captive-network/no-CRL-or-OCSP-retrieval environment and
compromised private key.

-Kyle H

On 9/7/2016 00:41, Jakob Bohm wrote:
> Given the specific name in those certificates, and the place where the
> private key was seen, I would guess the actual use case is this:
>
> Each router (presumably a SOHO router) contains a DNS server that
> responds with its own internal RFC1918 IP address for the name
> securelogin.arubanetworks.com and then the routers internal user
> interface shows a https page with the router configuration user
> interface.  The printed 1 page manual that accompanies those routers
> probably says to plug in the router then open your browser and type in
> that name with https in front.  No actual legitimate public server
> would use that DNS name or certificate, and arubanetworks.com
> presumably ensures this (that is certainly the current status of the
> public DNS).
>
> If that is indeed the use case, users are not going to replace that
> certificate by any "real" certificate and will probably either generate
> a per device self-signed certificate and then add a browser exception
> OR they will just add a browser exception for the certificate that is
> now going to be revoked.  Depending on the actual router firmware
> available at github (and any older versions incorporating the same
> certificate), the user may not even have the ability to replace the
> certificate with a self-signed one.  Now sharing a single private key
> among thousands of router user interfaces is obviously bad security,
> but the common alternative (used by most other routers) is to use
> unencrypted http, perhaps over an (initially) unencrypted WiFi link.
>
> The correct, but more expensive, option would be for each router to get
> a unique certificate for securelogin-.arubanetworks.com
> (where  is the MAC address of the router) with an
> intercepting redirect from securelogin.arubanetworks.com or something
> similar.  However the process to securely generate and install a
> different private key and certificate for each router on the
> assembly line, and preserve those across routine firmware upgrades
> would probably be costly in a cost-competitive market, even if the
> router manufacturer ran a trusted sub-ca or could otherwise get the
> certificates for free.  I guess that is why this router manufacturer
> (presumably) chose to get a single low cost certificate and embed the
> private key in the firmware images.
>
> On 07/09/2016 01:26, Steve Medin wrote:
>> Agree, regardless of 4.9.5's investigation gap, in this case 4.9.1.1(3)
>> clearly applies as well as other clauses. At this point, revocation
>> is less
>> harm than the key compromise. It may be an effective way to get the
>> message
>> to the affected device operators who have not replaced the default
>> certificate with a purchased one.
>>
>> Kind regards,
>> Steven Medin
>> PKI Policy Manager, Symantec Corporation
>>
>> -----Original Message-
>> From: Jeremy Rowley [mailto:jeremy.row...@digicert.com]
>> Sent: Tuesday, September 06, 2016 7:06 PM
>> To: Steve Medin <steve_me...@symantec.com>
>> Cc: Gervase Markham <g...@mozilla.org>; Kyle Hamilton
>> <aerow...@gmail.com>;
>> mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: Compromised certificate that the owner didn't wish to
>>

Re: Incidents involving the CA WoSign

[Kyle Hamilton]

I do have to ask this, though:  WoSign has at least one EV issuer.  I do
not know if there is an issuer with EV permissions in NSS, but WoSign
does have an EV code signing issuer in the Microsoft root program.  Has
this issuer been checked to ensure that it could not have misissued
certificates?  (Yes, it's probably out of scope for mozilla's process. 
However, it's still something I'm curious about.)

Also, on #2: Will this audit apply to all WoSign issuers included in
NSS, or just a single one?  I count at least 4.

And finally, where does this leave StartCom?  Is there a need for
inquiries regarding StartCom's operations?

-Kyle H

On 9/7/2016 03:06, Richard Wang wrote:
> Hi Gerv, Kathleen and Richard,
>
> This discuss has been lasting two weeks, I think it is time to end it, it 
> doesn’t worth to waste everybody’s precious time.
> I make my confession that our system and management do have some problems 
> which lead to the misissuance of some certificates. And I am very sorry that 
> WoSign don’t notify all browsers after the incident happened and even after 
> the problem fixed.
>
> I’d like to give my suggestion action for Mozilla as below:
> 1. Mozilla will trust those SSL certificates only:
> (1) The certificate notBefore date is before Jan. 1st 2015;
> (2) The certificate notBefore date is from Jan. 1st 2015 to July 4th 2016 
> that listed in the Google CT log server;
> (3) The certificate notBefore date is from July 5th 2016 to Sept xx 2016 
> that embedded SCT data in the certificate;
> (4) The certificate notBefore date is from Sept xx 2016 that embedded SCT 
> data in the certificate and must have the “C=CN” in the certificate subject.
>
> 2. Mozilla can assign a WebTrust auditor to WoSign office to check and 
> inspect every incident, check every relevant issued certificate, and record a 
> report with:  what happened, why this happened and what is being done to 
> prevent this in the future etc., WoSign will pay the audit cost.
>
> I’d like to make some supplements about 1. (4) above, this term means WoSign 
> will only issue SSL certificates to China subscribers. 
> WoSign issued about 120K SSL certificates for websites in China including 
> many central government websites like MIIT and many other local province 
> government websites, many university websites, many online banking websites, 
> 6 of the Top 10 ecommerce websites, big supermarket online store like 
> Walmart, 4 of the Top 5 cloud service in China, and many big companies that 
> listed in NYSE and Nasdaq, and many subsidiaries of foreign countries big 
> companies. 
> Those customers like to use WoSign certificate especially our support of 
> Chinese, local support and customer service. And some of them paid up to 
> 10-year certificate fee in advance, we need to renew their certificate for 
> free once it is about to expire at every three years for OV SSL.
>
> I wish Mozilla could accept my suggestion, and I am sure WoSign will do it 
> better after getting this so big lesson. 
> Thank you.
>
>
> Best Regards,
>
> Richard Wang
> CEO
> WoSign CA Limited
>
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Richard Wang
> Sent: Sunday, September 4, 2016 5:49 PM
> To: Gervase Markham ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Incidents involving the CA WoSign
>
> Hi all,
>
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
>
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
>
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
>
>
> Best Regards,
>
> Richard Wang
> CEO
> WoSign CA Limited
>
>
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Richard Wang 
> Subject: Incidents involving the CA WoSign
>
> Dear m.d.s.policy,
>
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
>
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> clear to us, and appears to be clear to other CAs based on their actions, 
> that misissuances where domain control checks have failed fall into the 
> category of "serious security concern".
>
> Incident 0
> --
>
> On or around April 23rd, 2015, WoSign's certificate issuance system for 

Re: Reuse of serial numbers by StartCom

[Kyle Hamilton]

On 9/4/2016 02:04, Eddy Nigg wrote:
> On 09/02/2016 07:02 PM, Nick Lamb wrote:
>> On Friday, 2 September 2016 08:50:02 UTC+1, Eddy Nigg  wrote:
>>> Lets speak about relying parties - how does this bug affect you?
>> As a relying party I am entitled to assume that there is no more than
>> one certificate signed by a particular issuer with a certain serial
>> number. If I have seen this certificate and verified by whatever
>> means I choose that it's OK, then I can safely assume that any time I
>> see a certificate in the future signed by that issuer with that same
>> serial number it's the same one, and skip the verification process.
>
> Well, according to the CA policies and relying party terms, you should
> always check with the CRL or OCSP responders if a certificate is
> considered valid or not. So the verification process shouldn't be
> skipped beyond the advertised refresh time (in CRLs/OCSP).
>
> Of course if you do some sort of certificate pinning based on serial
> and issuer, than this wouldn't work. But I'm not aware of any common
> software that doesn't use the certificate's public key for pinning and
> relies just on a serial numbers.
>

1: NSS does in fact pin on serial numbers.  It has actually stopped me
from utilizing a site in Firefox specifically because a CA had issued
multiple certificates with the same serial number.  As a relying party,
my first and foremost requirement is that my verification software can
and will actually let me rely on your assertions of identity, even
though it enforces the technical mandates of the specifications involved.

(A duplicate certificate serial number explicitly violates the
definition in section 3.5.13 of X.509.  Since PKIX is a profile of
X.509, PKIX inherits all assumptions and definitions of X.509. 
Furthermore, 4.1.2.2 of RFC 5280 specifies that it MUST be unique for
each certificate issued by a given CA.)

There is no mandate that a public key not be certified multiple times
(thus permitting renewals without rekeying), but there is a mandate that
multiple certificates with different information not be given the same
serial number.

2: If I were to get into a legal dispute with the subject of a
certificate you issued and needed to obtain the documentation you had
that was related to your issuance of that particular certificate, I
would probably request the documents from you based on the certificate
serial number.  You would then be able to pull the documents related to
that serial number and copy them appropriately.  With multiple
certificates having the same serial number it would be easier for the
following errors to show up:

a) provision of documents that related to a certificate that wasn't the
one in question (thus muddying the waters as to exactly who had been
identified by the certificate in question), and
b) failure to provision documents that did relate to the certificate in
question (thus throwing your due diligence and my reliance on it into
question), by being improperly identified by StartCom as not relevant to
the certificate in question.

In either case, your errors and omissions insurance would probably be
paying out because I wouldn't be able to prove the validity of my
reliance to pin whatever dispute on the entity I was suing.

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

Francisco Partners acquires Comodo certificate authority business

[Kyle Hamilton via dev-security-policy]

http://www.eweek.com/security/francisco-partners-acquires-comodo-s-certificate-authority-business


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

Re: Francisco Partners acquires Comodo certificate authority business

[Kyle Hamilton via dev-security-policy]

Another article about this is 
http://www.securityweek.com/francisco-partners-acquires-comodo-ca .


Notably, I'm not seeing anything in the official news announcements 
pages for either Francisco Partners or Comodo.  Is this an attempt at 
another StartCom (silent ownership transfer), or is it a case of "rumor 
mill reported as fact"?


-Kyle H


On 2017-10-31 06:21, Kyle Hamilton wrote:
http://www.eweek.com/security/francisco-partners-acquires-comodo-s-certificate-authority-business 






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

Re: Digicert issued certificate with let's encrypts public key

[Kyle Hamilton via dev-security-policy]

CABForum's current Basic Requirements, section 3.2.1, is titled "Method to
prove possession of private key".

It is currently blank.

A potential attack without Proof of Possession which PKIX glosses over
could involve someone believing that a signature on a document combined
with the non-possession-proved certificate constitutes proof of possession,
and combined with external action which corroborates the contents of the
document could heuristically evidence the authority to issue the document.
(Yes, this would be a con job. But it would be prevented if CAs actually
had the applicant prove possession of the private key.)

Regardless of that potential con, though, there is one very important thing
which Proof of Possession is good for, regardless of whether any credible
attacks are "enabled" by its lack: it enables identification of a situation
where multiple people independently generate and possess the same keypair
(such as what happened in the Debian weak-key fiasco). Regardless of how
often it might be seen in the wild, the fact is that on every key
generation there is a chance (small, but non-zero) that the same key will
be generated again, probably by someone different than the person who
originally generated it. (With bad implementations the chance gets much
larger.)

With proof of possession, these situations can be detected and raised as
being not-just-theoretical, and the CAs (or whoever wants to search the CT
logs) can notify the entities involved that they probably want to change
their keys. In the case of CA keys potentially being duplicated, this is an
incredibly important capacity.  In the case of EV certificate keys being
duplicated, it can be a reportable event for the certified entities (such
as banks) if copies of their private key are found to be in the possession
of anyone else.

Non-zero probability of duplication is not zero probability of duplication,
and relying on it being "close enough to zero" is eventually going to bite
us all.  It's up to those who work for CAs to put in mitigations for when
that day ultimately arrives, or else risk the viability of not only their
businesses but every other CA business they compete with.

So, I request and encourage that CABForum members consider populating
clause 3.2.1 of the Basic Requirements, so that Proof-of-Possession be
mandated.

-Kyle H

On Sun, May 17, 2020, 22:23 Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > In particular, there must have been some authorisation carried out at
> some
> > point, or perhaps that wasn't carried out, that indicates who requested
> the
> > cert.  What I'm trying to discover is where the gap was, and what's
> > required
> > to fix it in the future.
> >
>
> What gap, exactly?  There’s not a risk here.
>
> I don’t think it’s been codified that private key possession or control has
> to be demonstrated.
>
> I think it would be plausible for a CA to allow submission of a public key
> in lieu of a CSR and that nothing would be wrong about it.
> ___
> 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: Digicert issued certificate with let's encrypts public key

[Kyle Hamilton via dev-security-policy]

That is my reading of the situation, that they're not doing an actual
certification of an enrollment without verifying the actual key-identity
binding.

In addition, I'm wondering if the concept of "third-party attestation" (of
identity) is even a thing anymore, given that most CAs issue certificates
for their own websites.

-Kyle H

On Mon, May 18, 2020, 22:58 Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> A bit of philosophical question here: Certificates are pretty much
> universally
> described in PKI texts and the like as a cryptographic binding between an
> identity and a key, in other words an assertion by the CA that the key in
> the
> cert is associated with the identity in the cert.
>
> If there's no requirement to verify that this is the case by CAs issuing
> certificates, doesn't this make what they're producing a non-certificate?
>
> This isn't snark, it's a genuine question: If the CA isn't checking that
> the
> entity they're certifying controls the key they're certifying, aren't they
> then not acting as CAs any more?
>
> Peter.
> ___
> 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: Digicert issued certificate with let's encrypts public key

[Kyle Hamilton via dev-security-policy]

On Mon, May 18, 2020, 19:46 Ryan Sleevi  wrote:

> On Mon, May 18, 2020 at 7:55 PM Kyle Hamilton via dev-security-policy
>  wrote:
>
> > Regardless of that potential con, though, there is one very important
> thing
> > which Proof of Possession is good for, regardless of whether any credible
> > attacks are "enabled" by its lack: it enables identification of a
> situation
> > where multiple people independently generate and possess the same keypair
> > (such as what happened in the Debian weak-key fiasco). Regardless of how
> > often it might be seen in the wild, the fact is that on every key
> > generation there is a chance (small, but non-zero) that the same key will
> > be generated again, probably by someone different than the person who
> > originally generated it. (With bad implementations the chance gets much
> > larger.)
>
> This argument doesn't hold water. This is an argument not about proof
> of possession about private key, but about the public key itself.
> Multiple parties possessing the same key pair are revealed by the
> public key. Proof of possession provides zero value.
>

So... taking this argument to its logical end, Let's Encrypt should have
immediately revoked its public key when it was found to have been issued to
another entity by another member of CABF, which is supposed to operate
within the constraints of identification embedded in the Basic
Requirements.  (i.e., another entity was certified as being able to make
signatures which could be technically attributed to the Let's Encrypt CA,
which qualifies as "loss of control of the CA private key".  A private key
is not a device, or an authorized or unauthorized copy of a PKCS#8 or
PKCS#12 structure.  A private key is a sequence of bits which encodes a
value which, when operated upon in accordance with the rules of the
algorithm it was generated under, will generate a value which can be
verified (and possibly decrypted, in the case of RSA) with its
corresponding public key value.  Random generation means that the
independent generation of a keypair is always a potential risk.  The reason
we have a uniform and large key space and generation process is to minimize
the risk that this will happen, but a non-zero risk is not a zero risk.)

In this case, it becomes even more important for CAs to prove that the
private key is held by every person who claims it as being their public key
-- again, to change it from a theoretical/potential/too-expensive-to-act-on
threat to an actual key compromise scenario that mandates pushing the big
red button and holding a new key generation ceremony and regenerating the
PKI infrastructure and getting the new root key installed in browsers and
operating systems as soon as possible.

(or, if it's an intermediate, generating a new intermediate, contacting all
legitimate recipients and having them change their certificate chains, and
revoking the one that had its key independently discovered.)

Unfortunately, you can't have it both ways.  What's more important, correct
certificate issuance (the issuance is by the entity trusted to issue the
certificate), or lack of disruption?  The CA has always been expected to
err on the side of correct issuance (which is why, for example, the
Netherlands PKIOverheid intermediate was distrusted).

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