Re: Digicert issued certificate with let's encrypts public key
Jeremy Rowley via dev-security-policy writes: >For those interested, the short of what happened is that we had an old >service where you could replace existing certificates by having DigiCert >connect to a site and replace the certificate with a key taken from the site >after a TLS connection. No requirement for a CSR since we obtained proof of >key control through a TLS connection with the website. Turned out the >handshake didn't actually take the key, but allowed the customer to submit a >different public key without a CSR. We took down the service a while ago - >back in November I think. I plan to put it back up when we work out the kink >with it not forcing the key to match the key used in the handshake. Thanks, that was the info I was after: was this a general problem that we need to check other systems for as well, or a situation-specific issue that affected just one site/system but no others. Looks like other systems are unaffected. Peter. ___ 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
It was just the one system and situation-specific. -Original Message- From: dev-security-policy On Behalf Of Peter Gutmann via dev-security-policy Sent: Monday, May 18, 2020 6:31 AM To: Matt Palmer ; Mozilla ; Jeremy Rowley Subject: Re: Digicert issued certificate with let's encrypts public key Jeremy Rowley via dev-security-policy writes: >For those interested, the short of what happened is that we had an old >service where you could replace existing certificates by having >DigiCert connect to a site and replace the certificate with a key taken >from the site after a TLS connection. No requirement for a CSR since we >obtained proof of key control through a TLS connection with the >website. Turned out the handshake didn't actually take the key, but >allowed the customer to submit a different public key without a CSR. We >took down the service a while ago - back in November I think. I plan to >put it back up when we work out the kink with it not forcing the key to match >the key used in the handshake. Thanks, that was the info I was after: was this a general problem that we need to check other systems for as well, or a situation-specific issue that affected just one site/system but no others. Looks like other systems are unaffected. 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
I certainly recall descriptions of other issuing systems in history in which it was (at least based on the description) possible to get a certificate issued without proof of control of the private key. A scary example, I know, but StartCom's original system was once described as taking the public key data (and they emphasized _only_ the public key data) from the CSR. Everything else was populated out-of-band of any PKI protocols via the website. Frankly, I don't see how anyone permitting signature over a third party public key without proof of control of the matching private key creates a risk. I think if there are relying-party systems where this creates a problem, the error is in those relying-party systems and their respective validation logic. On Mon, May 18, 2020 at 10:05 AM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > It was just the one system and situation-specific. > > -Original Message- > From: dev-security-policy > On Behalf Of Peter Gutmann via dev-security-policy > Sent: Monday, May 18, 2020 6:31 AM > To: Matt Palmer ; Mozilla < > mozilla-dev-security-pol...@lists.mozilla.org>; Jeremy Rowley < > jeremy.row...@digicert.com> > Subject: Re: Digicert issued certificate with let's encrypts public key > > Jeremy Rowley via dev-security-policy < > dev-security-policy@lists.mozilla.org> writes: > > >For those interested, the short of what happened is that we had an old > >service where you could replace existing certificates by having > >DigiCert connect to a site and replace the certificate with a key taken > >from the site after a TLS connection. No requirement for a CSR since we > >obtained proof of key control through a TLS connection with the > >website. Turned out the handshake didn't actually take the key, but > >allowed the customer to submit a different public key without a CSR. We > >took down the service a while ago - back in November I think. I plan to > >put it back up when we work out the kink with it not forcing the key to > match the key used in the handshake. > > Thanks, that was the info I was after: was this a general problem that we > need to check other systems for as well, or a situation-specific issue that > affected just one site/system but no others. Looks like other systems are > unaffected. > > 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 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Microsec: Issuance of 2 IVCP precertificates without givenName, surName, localityName fields
I give you a brief status report on CA software development. Microsec has already completed the development of CA software and introduced additional automatic checks for the proper configuration of the SN fields in case of different certificate types. A number of internal tests have already been performed on the test system, but the new release is still awaiting final acceptance tests. The new release of the CA software has not been activated in the live system yet, the scheduled activation date is 2020-05-20. IVCP profiles are still inactive, Microsec does not issue IVCP certificates. As Microsec informed the community in its first comment (2020-03-13), there was no deadline for CA software development due to the COVID-19 emergency situation. This information was confirmed in comment 2020-03-19, and the date 2020-04-15 was given as a plan only and not as a strict deadline. Microsec will immediately notify the community in case of any further change in this thread. ___ 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
On Mon, May 18, 2020 at 11:40 AM Matthew Hardeman via dev-security-policy wrote: > A scary example, I know, but StartCom's original system was once described > as taking the public key data (and they emphasized _only_ the public key > data) from the CSR. Everything else was populated out-of-band of any PKI > protocols via the website. > > Frankly, I don't see how anyone permitting signature over a third party > public key without proof of control of the matching private key creates a > risk. I think if there are relying-party systems where this creates a > problem, the error is in those relying-party systems and their respective > validation logic. Why would StartCom's system be "A scary example" when you acknowledge that you don't see how it creates a risk? The scenario you ascribe to StartCom is exactly what is recommended, of CAs, in numerous CA incident bugs where the failure to apply that restrictive model has lead to misissuance. ___ 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
I did not state the point well. "Scary example" as I used it above was merely because it was a reference to StartCom at all (given the history, etc.) -- not particularly in the context of this practice. I concur that I see no risk in leaf certificates issued with signatures over public keys for which neither ownership or control of the corresponding private key have been established. I merely wished to add an example case to the discussion in which it was presumably possible to have leaf certificates issued over a public key for which the control of private key had not been proven. On Mon, May 18, 2020 at 12:44 PM Ryan Sleevi wrote: > On Mon, May 18, 2020 at 11:40 AM Matthew Hardeman via > dev-security-policy wrote: > > A scary example, I know, but StartCom's original system was once > described > > as taking the public key data (and they emphasized _only_ the public key > > data) from the CSR. Everything else was populated out-of-band of any PKI > > protocols via the website. > > > > Frankly, I don't see how anyone permitting signature over a third party > > public key without proof of control of the matching private key creates a > > risk. I think if there are relying-party systems where this creates a > > problem, the error is in those relying-party systems and their respective > > validation logic. > > Why would StartCom's system be "A scary example" when you acknowledge > that you don't see how it creates a risk? The scenario you ascribe to > StartCom is exactly what is recommended, of CAs, in numerous CA > incident bugs where the failure to apply that restrictive model has > lead to misissuance. > ___ 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
On Mon, May 18, 2020 at 12:44 PM Ryan Sleevi wrote: > The scenario you ascribe to > StartCom is exactly what is recommended, of CAs, in numerous CA > incident bugs where the failure to apply that restrictive model has > lead to misissuance. > Separate to the matter in discussion in this thread, my understanding of CSR processing best practice mirrored what you say here -- take the minimum that you require from the structure and discard the rest. I was surprised in reading the ACME specs that various factors for issuance rely upon data in the rather flexible but (relatively) complex data structure that is the CSR, like requested DNS names, whether or not OCSP must-staple is desired, etc. I am curious what the authors' intent was there. Was it possibly a desire to adhere to the original functional intent of the CSR as elsewhere specified, irrespective of the known risks which had been previously demonstrated in bad CA implementations? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Status of the bugzilla bug list
All, I have looked at the list of open bugs in the CA compliance dashboard [0], and I was unpleasantly suprised. There's a total of 75 open issues at the moment of writing, of which 31 have not seen an update in 4 weeks, and of which again 23 [1] are not waiting for a planned future CA or Mozilla action; 30% of the open issues, spread over 14 CAs. (These 23 include issues that end with actions like "A: We will do this" and "B: We will do that at 'date-long-gone'" when there is no indication the action has been taken, and no update since.) Of those 23, 17 have not seen interactions for over 2 months. (!) The MRSP (v2.7) requires regular updates for incident reports until the bug is marked as resolved. This means that a CA MUST actively keep track of the issue, even though this is not always understood by CAs [2]. I can understand that it is not always clear what information is still needed to close a bug, but please ask for this information on the issue when this is not known, so that there are no 'zombie' tickets. To remedy the issue of 'many long-standing open CA-Compliance issues with unclear state', I would like - as a concerned individual and end user of the root store - to ask the relevant CAs and Mozilla to check their issues in the ca-compliance board [0], check whether the issues are 'solved' or what information they need, and update the relevant issues with the updated information or ask for said missing information, so that there is a clear understanding which issues are resolved and which issues need more information / actions by some party in the issue. As stated before, this process is not always clear to all CAs [2], and in my experience explicit communication helps a lot in checking what is needed to solve an issue. Kind regards, Matthias van de Meent [0] https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificate%20Compliance&bug_status=__open__ [1] https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificate%20Compliance&bug_id=1593776%2C1605804%2C1623356%2C1550645%2C1625767%2C1502957%2C1620561%2C1575022%2C1590810%2C1578505%2C1463975%2C1496616%2C1614448%2C1559765%2C1606380%2C1532559%2C1599916%2C1551372%2C1610767%2C1575530%2C1597950%2C1597947%2C1597948&bug_id_type=anyexact&list_id=15253621&query_format=advanced [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1613409 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Status of the bugzilla bug list
I think your list of 23 is wrong. For example, bug 1550645 is just waiting for Mozilla closure. It looks like 1605804 is in the same boat. -Original Message- From: dev-security-policy On Behalf Of Matthias van de Meent via dev-security-policy Sent: Monday, May 18, 2020 1:04 PM To: MDSP Subject: Status of the bugzilla bug list All, I have looked at the list of open bugs in the CA compliance dashboard [0], and I was unpleasantly suprised. There's a total of 75 open issues at the moment of writing, of which 31 have not seen an update in 4 weeks, and of which again 23 [1] are not waiting for a planned future CA or Mozilla action; 30% of the open issues, spread over 14 CAs. (These 23 include issues that end with actions like "A: We will do this" and "B: We will do that at 'date-long-gone'" when there is no indication the action has been taken, and no update since.) Of those 23, 17 have not seen interactions for over 2 months. (!) The MRSP (v2.7) requires regular updates for incident reports until the bug is marked as resolved. This means that a CA MUST actively keep track of the issue, even though this is not always understood by CAs [2]. I can understand that it is not always clear what information is still needed to close a bug, but please ask for this information on the issue when this is not known, so that there are no 'zombie' tickets. To remedy the issue of 'many long-standing open CA-Compliance issues with unclear state', I would like - as a concerned individual and end user of the root store - to ask the relevant CAs and Mozilla to check their issues in the ca-compliance board [0], check whether the issues are 'solved' or what information they need, and update the relevant issues with the updated information or ask for said missing information, so that there is a clear understanding which issues are resolved and which issues need more information / actions by some party in the issue. As stated before, this process is not always clear to all CAs [2], and in my experience explicit communication helps a lot in checking what is needed to solve an issue. Kind regards, Matthias van de Meent [0] https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificate%20Compliance&bug_status=__open__ [1] https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificate%20Compliance&bug_id=1593776%2C1605804%2C1623356%2C1550645%2C1625767%2C1502957%2C1620561%2C1575022%2C1590810%2C1578505%2C1463975%2C1496616%2C1614448%2C1559765%2C1606380%2C1532559%2C1599916%2C1551372%2C1610767%2C1575530%2C1597950%2C1597947%2C1597948&bug_id_type=anyexact&list_id=15253621&query_format=advanced [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1613409 ___ 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: Status of the bugzilla bug list
There are others in this same group of pending Mozilla closure: https://bugzilla.mozilla.org/show_bug.cgi?id=1496616 https://bugzilla.mozilla.org/show_bug.cgi?id=1463975 https://bugzilla.mozilla.org/show_bug.cgi?id=1532559 https://bugzilla.mozilla.org/show_bug.cgi?id=1502957 (Waiting on Wayne) -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Monday, May 18, 2020 1:52 PM To: Mozilla Subject: RE: Status of the bugzilla bug list I think your list of 23 is wrong. For example, bug 1550645 is just waiting for Mozilla closure. It looks like 1605804 is in the same boat. -Original Message- From: dev-security-policy On Behalf Of Matthias van de Meent via dev-security-policy Sent: Monday, May 18, 2020 1:04 PM To: MDSP Subject: Status of the bugzilla bug list All, I have looked at the list of open bugs in the CA compliance dashboard [0], and I was unpleasantly suprised. There's a total of 75 open issues at the moment of writing, of which 31 have not seen an update in 4 weeks, and of which again 23 [1] are not waiting for a planned future CA or Mozilla action; 30% of the open issues, spread over 14 CAs. (These 23 include issues that end with actions like "A: We will do this" and "B: We will do that at 'date-long-gone'" when there is no indication the action has been taken, and no update since.) Of those 23, 17 have not seen interactions for over 2 months. (!) The MRSP (v2.7) requires regular updates for incident reports until the bug is marked as resolved. This means that a CA MUST actively keep track of the issue, even though this is not always understood by CAs [2]. I can understand that it is not always clear what information is still needed to close a bug, but please ask for this information on the issue when this is not known, so that there are no 'zombie' tickets. To remedy the issue of 'many long-standing open CA-Compliance issues with unclear state', I would like - as a concerned individual and end user of the root store - to ask the relevant CAs and Mozilla to check their issues in the ca-compliance board [0], check whether the issues are 'solved' or what information they need, and update the relevant issues with the updated information or ask for said missing information, so that there is a clear understanding which issues are resolved and which issues need more information / actions by some party in the issue. As stated before, this process is not always clear to all CAs [2], and in my experience explicit communication helps a lot in checking what is needed to solve an issue. Kind regards, Matthias van de Meent [0] https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificate%20Compliance&bug_status=__open__ [1] https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificate%20Compliance&bug_id=1593776%2C1605804%2C1623356%2C1550645%2C1625767%2C1502957%2C1620561%2C1575022%2C1590810%2C1578505%2C1463975%2C1496616%2C1614448%2C1559765%2C1606380%2C1532559%2C1599916%2C1551372%2C1610767%2C1575530%2C1597950%2C1597947%2C1597948&bug_id_type=anyexact&list_id=15253621&query_format=advanced [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1613409 ___ 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Status of the bugzilla bug list
Hi Jeremy, Thanks for responding, On Mon, 18 May 2020 at 21:58, Jeremy Rowley via dev-security-policy wrote: > > There are others in this same group of pending Mozilla closure: > https://bugzilla.mozilla.org/show_bug.cgi?id=1496616 > https://bugzilla.mozilla.org/show_bug.cgi?id=1463975 > https://bugzilla.mozilla.org/show_bug.cgi?id=1532559 > https://bugzilla.mozilla.org/show_bug.cgi?id=1502957 (Waiting on Wayne) > > -Original Message- > From: dev-security-policy On > Behalf Of Jeremy Rowley via dev-security-policy > Sent: Monday, May 18, 2020 1:52 PM > To: Mozilla > Subject: RE: Status of the bugzilla bug list > > I think your list of 23 is wrong. For example, bug 1550645 is just waiting > for Mozilla closure. It looks like 1605804 is in the same boat. I believe my list is correct. As I said, the specific list contains issues that ( " have not been touched for >4 weeks" AND ( "of which it is unclear why they're still open" OR "of which it is unclear what they're waiting for" ) ). The list is provided as a guidance, not an authorative list (that should be the base dashboard). CAs should of course decide for themselves which issues should be updated & checked. Further, a comment requesting the closure of the issue is in my opinion not enough to remove it from this list; When an issue can be closed, it should have been closed already (there's been >4 weeks for that without action on Mozilla's part). If an issue is still after those 4 weeks, then either Mozilla was lax in its closing of issues, or there is an uncommunicated need for missing information from Mozilla. This is why they are also included in the list. This is also why I explicitly called for Mozilla to also check the issues - a part of the set is "closable" according to the CA, but no action taken by Mozilla. With regards, Matthias ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Status of the bugzilla bug list
Hi Matthias, We're aware of this. Could you explain what issue or issues this presents to you? Understanding that different projects can and do use different workflows to address their needs, it's not immediately clear to me what impact, if any, this might have for you, and it's unclear why the distinction between an open bug and a closed bug should be something you're concerned about. Understanding what problem(s) you're trying to solve seems more productive/useful way to get them addressed. What difference does the distinction make for you? ___ 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
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
On Mon, May 18, 2020 at 7:55 PM Kyle Hamilton via dev-security-policy wrote: > 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.) The problem with this attack is that it has no relevance to TLS and server certificates. Which is important to understand, especially why the omission is, as I stated, intentional. I appreciate the appeal to theoretical purity of consistency among PKIs, but comparing the needs of one PKI with the needs of another is not a reasonable comparison to make. That same logical leap would have all keys in HSMs in safes, or forbid keys from being in safes, both of which we know are appropriate or inappropriate - depending on the use case. > 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. ___ 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
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
Re: Digicert issued certificate with let's encrypts public key
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
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
Re: Digicert issued certificate with let's encrypts public key
On May 18, 2020, at 23:58, Peter Gutmann via dev-security-policy wrote: > > > > 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? They are really only certifying that the requester can control the dns for the domain name mentioned in the certificate anyway. The same function DNSSEC provides without middle men :) Paul ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
