Re: Digicert issued certificate with let's encrypts public key
Thanks, Corey. I've added this as a matter to consider in a future version of the Root Store Policy. https://github.com/mozilla/pkipolicy/issues/215 On Thu, May 21, 2020 at 7:23 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > While I realize the current topic is concerning TLS, I find it rather > surprising that Mozilla Policy does not mandate PoP for S/MIME certificate > issuance. Lack of checking for S/MIME would present more concrete security > concerns, so perhaps this should be addressed in a future update to the > Policy. > > Thanks, > Corey > ___ > 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
While I realize the current topic is concerning TLS, I find it rather surprising that Mozilla Policy does not mandate PoP for S/MIME certificate issuance. Lack of checking for S/MIME would present more concrete security concerns, so perhaps this should be addressed in a future update to the Policy. Thanks, Corey ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Digicert issued certificate with let's encrypts public key
Matthew Hardeman via dev-security-policy writes: >The standard use of the most common way of communicating the public key and >the purported proof-of-possession of the private key to the CA, the CSR, does >not provide replay protection and yet is frequently NOT treated as a security >impacting element should it be disclosed post-issuance. As such, one must >question if an arbitrary CSR which contains a valid signature produced using >the private key which corresponds to the subject public key in same said CSR >is really qualified to be considered proof-of-possession (or proof of control) >of said private key. I submit that it is not. All of the cert management protocols I referenced earlier, CMP, CMC, and SCEP but not ACME which I haven't implemented so I'm not sure about, have liveness constraints. In other words you can't replay an old CSR to get a new cert. Even if there is a bare-CSR way to get a cert, the only thing you could do with it is get the same cert issued with a more recent expiry date. Since everyone clicks past expired certs anyway and when they're used for things like code signing they're countersigned by a TSA to give them an indefinite lifetime, I'm not sure that it gets an attacker much. Having said that, it's another one of the many PKI things that just get done a certain way without anyone ever presenting a threat model that justifies it, so it could be a threat in some manner. 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
On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton wrote: > 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. > I don't mean to beat a dead horse, and without addressing the merits of trying to consider a leaf certificate issued over a particular public key as proof-of-possession/control of the corresponding private key, I add one further practical problem: The standard use of the most common way of communicating the public key and the purported proof-of-possession of the private key to the CA, the CSR, does not provide replay protection and yet is frequently NOT treated as a security impacting element should it be disclosed post-issuance. As such, one must question if an arbitrary CSR which contains a valid signature produced using the private key which corresponds to the subject public key in same said CSR is really qualified to be considered proof-of-possession (or proof of control) of said private key. I submit that it is not. ___ 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 6:55 PM Kyle Hamilton wrote: > 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. > How, precisely? Today, the vast majority of certificates lack any end-entity identifying factors other than some number of SAN dnsName entries. In modern CDNs (example: CloudFlare), a single certificate might represent a plurality of entirely unrelated websites run by entirely unrelated entities who happen to share a service provider in common. In as far as that these sites are already sharing a TLS concentrator -- while it is not the practice of anyone I know of -- such a service provider could have quite a number of TLS concentrator elements sharing (access to) a public/private key pair and might choose to provision quite a number of unrelated certificates with the same key. Two certificates issued at two different times containing the same public key is not proof one way or the other. It does not prove two entities are definitely related. It does not prove that they are not. But the fact that proof of possession isn't required increases the plausibility that it does not prove a relationship. I wonder if the attendant ambiguity has saved anyone's head from rolling. On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton wrote: > 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
Re: Digicert issued certificate with let's encrypts public key
On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton 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.) > Could you explain how this is different from other stretches of fitness for purpose? For example, I can use Lipton's tea leaves as guidance dictates - for making a beverage purportedly fit for human consumption. I can also try to diving events of the future by finding meaning in the patterns of the tiny dregs of tea leaf left in the bottom of my mug. But I should expect to get laughed at by Lipton customer service if I ask for assistance with this or appear to be taking these predictions seriously. On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton wrote: > 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 Tue, May 19, 2020 at 12:35 AM Kyle Hamilton wrote: > > > 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.) > This is a strawman argument based on fundamental misunderstanding, not the logical end. You’ve directly conflated public and private key, and confused the ability to create a signature with attribution. In short: this is utter nonsense. I’m disappointed to even need to point out how unsound the statement of “another entity was certified as being able to make signatures which could be technically attributed to the Let's Encrypt CA” is. This doesn’t hold water at all. The Issuing CA is not certifying a proof of possession of a private key, so naturally you can’t (and shouldn’t) conclude it is a proof of possession of a private key. This is basic. > 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. > This is, continuing, nonsense. This is entirely unnecessarily precisely because it *isn’t* a proof of possession of private key. > (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). > Again, you’re trying to call it both ways. You’re right to point out the logical absurdity of having your cake and eating it to, but you’re missing that you’re the one making that claim. The concerns you raise are there only if you believe it is a PoP. As I’ve said, repeatedly, it is not, nor should it be. These concerns entirely disappear. A TLS Certificate is an expression of authorization, by the domain holder, to allow a public key to be used for their domain. The domain holder is permitted to express whatever public key(s) they want, with all the attendant risk, and the certificate is an expression that the CA has verified that assertion and expression by the domain holder. Similarly, in the case of OV/EV, it’s similarly an expression tha
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
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
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
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
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
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 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
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 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 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: 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
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
I thought I posted on this a while ago, but I can't seem to find the post. It may have been CAB Forum (where the archives are nearly useless). The conclusion from that is the CSR isn't required as part of the issuance process because there isn't a risk without having actual control over the private key. The worst someone can do isdemonstrate the existence of a cert with a bad public key? 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. -Original Message- From: dev-security-policy On Behalf Of Matt Palmer via dev-security-policy Sent: Sunday, May 17, 2020 10:37 PM To: Mozilla Subject: Re: Digicert issued certificate with let's encrypts public key On Mon, May 18, 2020 at 03:46:46AM +, Peter Gutmann via dev-security-policy wrote: > I assume this is ACME that allows a key to be certified without any > proof that the entity requesting the certificate controls it? ACME requires a CSR to be submitted in order to get the certificate issued. A quick scan doesn't show anything like "the signature on the CSR MUST be validated against the key", but it does talk about policy considerations around weak signatures on CSRs and such, suggesting that it was at least the general intention of ACME to require signatures on CSRs to be validated. In any event, given that the certs involved were issued by Digicert, not Let's Encrypt, and Digicert's ACME issuance pipeline is somewhat of a niche thing at present, I think it's more likely the problem lies elsewhere. - Matt ___ 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 03:46:46AM +, Peter Gutmann via dev-security-policy wrote: > I assume this is ACME that allows a key to be certified without any proof that > the entity requesting the certificate controls it? ACME requires a CSR to be submitted in order to get the certificate issued. A quick scan doesn't show anything like "the signature on the CSR MUST be validated against the key", but it does talk about policy considerations around weak signatures on CSRs and such, suggesting that it was at least the general intention of ACME to require signatures on CSRs to be validated. In any event, given that the certs involved were issued by Digicert, not Let's Encrypt, and Digicert's ACME issuance pipeline is somewhat of a niche thing at present, I think it's more likely the problem lies elsewhere. - Matt ___ 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 Sun, May 17, 2020 at 10:47 PM Peter Gutmann via dev-security-policy wrote: > I assume this is ACME that allows a key to be certified without any proof that > the entity requesting the certificate controls it? I don't know that any of > the PKIX protocols allow it. I do not see anywhere in ACME that specifies how an ACME server or the CA are to treat the CSR's signature field. Based on that, there is nothing specific in ACME allowing this behavior. (The only place I see talking about the private key associated with the cert's public key is to sign messages for revocation.) -carl mehner ___ 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
Matthew Hardeman writes: >What gap, exactly? There’s not a risk here. There are attacks possible, but this stuff was covered more than twenty years ago by PKIX and I can't remember the specifics. It was around various ways of fooling a victim that you'd signed something that you hadn't based on the two different certs. >I don’t think it’s been codified that private key possession or control has >to be demonstrated. All the PKIX cert-enrolment protocols (CMP, CMC, and plain PKCS #10) as well as the non-PKIX SCEP require proof-of-possession in order to deal with these problems. Unfortunately in the PKIX tradition the spec just says "In order to prevent certain attacks" without ever saying what they are. I assume this is ACME that allows a key to be certified without any proof that the entity requesting the certificate controls it? I don't know that any of the PKIX protocols allow it. 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
> 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
Re: Digicert issued certificate with let's encrypts public key
Corey Bonnell writes: >Certificate renewal that uses the existing certificate as input, rather than >a CSR. The (presumably expiring) certificate supplies the domains, >organization info, and the public key for the renewal certificate request. In >this case there is no proof of key possession absent some out-of-band process >(TLS handshake with the web server, etc). But if it's a renewal based on an existing cert, meaning that someone already had a cert for a key they don't control, that means that at some point in the past the CA turned a CSR for a key the requester doesn't control into a cert. 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. 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
Peter Bowen writes: >There is no requirement to submit a PKCS#10 CSR. Hmm, so what sort of issue process allows you to obtain a certificate for a key you don't control? 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
On Sat, May 16, 2020 at 8:18 PM Peter Gutmann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Kurt Roeckx via dev-security-policy > writes: > > >Browsing crt.sh, I found this: https://crt.sh/?id=1902422627 > > > >It's a certificate for api.pillowz.kz with the public key of Let's > Encrypt > >Authority X1 and X3 CAs. > > How could that have been issued? Since a (PKCS #10) request has to be > self- > signed There is no requirement to submit a PKCS#10 CSR. > ___ 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
Kurt Roeckx via dev-security-policy writes: >Browsing crt.sh, I found this: https://crt.sh/?id=1902422627 > >It's a certificate for api.pillowz.kz with the public key of Let's Encrypt >Authority X1 and X3 CAs. How could that have been issued? Since a (PKCS #10) request has to be self- signed, does this mean Digicert aren't validating signatures on requests? 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
On Sat, May 16, 2020 at 10:11 AM Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Sat, May 16, 2020 at 10:04:24AM -0400, Andrew Ayer via > dev-security-policy wrote: > > On Sat, 16 May 2020 14:02:42 +0200 > > Kurt Roeckx via dev-security-policy > > wrote: > > > > > https://crt.sh/?id=1902422627 > > > > > > It's a certificate for api.pillowz.kz with the public key of Let's > > > Encrypt Authority X1 and X3 CAs. > > > > > > It's revoked since 2020-01-31, but I couldn't find any incident > > > report related to it. > > > > Hi Kurt, > > > > It's not obvious what's non-compliant about this certificate - could you > > explain? Note that there is no requirement or security need for CAs to > > validate proof of possession of a private key. > > I was under the impression that there was. But looking at the BRs, > 3.2.1 is just empty. Yeah, that’s intentional, at least with regards to server certificates, as it is not necessary for such certificates. As Andrew mentioned, there are no requirements here and it’s not a violation of any expectation, in the Baseline Requirements or in any Root Programs’ policies. > ___ 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 Sat, May 16, 2020 at 10:04:24AM -0400, Andrew Ayer via dev-security-policy wrote: > On Sat, 16 May 2020 14:02:42 +0200 > Kurt Roeckx via dev-security-policy > wrote: > > > https://crt.sh/?id=1902422627 > > > > It's a certificate for api.pillowz.kz with the public key of Let's > > Encrypt Authority X1 and X3 CAs. > > > > It's revoked since 2020-01-31, but I couldn't find any incident > > report related to it. > > Hi Kurt, > > It's not obvious what's non-compliant about this certificate - could you > explain? Note that there is no requirement or security need for CAs to > validate proof of possession of a private key. I was under the impression that there was. But looking at the BRs, 3.2.1 is just empty. Kurt ___ 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 Sat, 16 May 2020 14:02:42 +0200 Kurt Roeckx via dev-security-policy wrote: > https://crt.sh/?id=1902422627 > > It's a certificate for api.pillowz.kz with the public key of Let's > Encrypt Authority X1 and X3 CAs. > > It's revoked since 2020-01-31, but I couldn't find any incident > report related to it. Hi Kurt, It's not obvious what's non-compliant about this certificate - could you explain? Note that there is no requirement or security need for CAs to validate proof of possession of a private key. Therefore, it's entirely acceptable for a subscriber to request a certificate for someone else's public key, although the certificate would be useless to them. Regards, Andrew ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy