Re: [FORGED] Re: How Certificates are Verified by Firefox
This is trivially detectable, and doesn't need to be addressed via any CA/B Forum work. This particular threat model is already part of other browser certificate uses (e.g. HTTP Signed Exchanges) and already something (some) browsers monitor. As Peter Bowen mentions, OCSP and CRLs are just as equal there. On Wed, Dec 4, 2019 at 6:52 PM Matthew Hardeman wrote: > Not that anyone is presently doing or would do such a thing, but... > > Imagine a CA that wanted to offer up a user/browser tracking service to > their subscriber customer. > > Is there any rule that prevents an issuing CA from having a "custom" > (hiding an identifier for the end-entity certificate) AIA URL? Such that > when the browser AIA chases, it's disclosing the fact of the AIA chase as > well as a user's IP address (and possibly some browser details) to the CA? > One could easily do it with wildcard DNS and a per-end-entity cert host > label for the AIA distribution point. > > > On Wed, Dec 4, 2019 at 4:13 PM Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Yes, I am one of the ones who actively disputes the notion that AIA >> considered harmful. >> >> I'm (plesantly) surprised that any CA would be opposed to AIA (i.e. >> supportive of "considered harmful", since it's inherently what gives them >> the flexibility to make their many design mistakes in their PKI and still >> have certificates work. The only way "considered harmful" would work is if >> we actively remove the flexibility afforded CAs in this realm, which I'm >> highly supportive of, but which definitely encourages more distinctive >> PKIs >> (i.e. more explicitly reducing the use of Web PKI in non-Web cases) >> >> Of course, AIA is also valuable in helping browsers push the web forward, >> so I can see why "considered harmful" is useful, especially in that it >> helps further the notion that root certificates are a thing of value (and >> whose value should increase with age). AIA is one of the key tools to >> helping prevent that, which we know is key to ensuring a more flexible, >> and >> agile, ecosystem. >> >> The flaw, of course, in a "considered harmful", is the notion that there's >> One Chain or One Right Chain. That's not the world we have, nor have we >> ever. The notion that there's One Right Chain for a TLS server to send >> presumes there's One Right Set of CA Trust Anchors. And while that's >> definitely a world we could pursue, I think we know from the past history >> of CA incidents, there's incredible benefit to users to being able to >> respond to CA security incidents differently, to remove trust in >> deprecated/insecure things differently, and to set policies differently. >> And so we can't expect servers to know the Right Chain because there isn't >> One Right Chain, and AIA (or intermediate preloading with rapid updates) >> can help address that. >> >> On Wed, Dec 4, 2019 at 5:02 PM Tim Hollebeek via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> > Someone really should write up "AIA chasing considered harmful". It was >> > disputed at the TLS session at IETF 105, which shows that the reasoning >> > behind it is not as widely understood as it needs to be, even among TLS >> > experts. >> > >> > I'm very appreciative of Firefox's efforts in this area. Leveraging the >> > knowledge of all the publicly disclosed ICAs to improve chain-building >> is >> > an >> > idea whose time has come. >> > >> > -Tim >> > >> > > -Original Message- >> > > From: dev-security-policy < >> dev-security-policy-boun...@lists.mozilla.org >> > > >> > On >> > > Behalf Of Wayne Thayer via dev-security-policy >> > > Sent: Monday, December 2, 2019 3:29 PM >> > > To: Ben Laurie >> > > Cc: mozilla-dev-security-policy >> > ; >> > > Peter Gutmann >> > > Subject: Re: [FORGED] Re: How Certificates are Verified by Firefox >> > > >> > > Why not "AIA chasing considered harmful"? The current state of >> affairs is >> > that >> > > most browsers [other than Firefox] will go and fetch the intermediate >> if >> > it's not >> > > cached. This manifests itself as sites not working in Firefox, and >> users >> > switching >> > > to other browsers. >> > > >> > > You may be further dismayed to learn that Firefox will soon implement >> > > intermediate preloading [1] as a privacy-preserving alternative to AIA >> > chasing. >> > > >> > > - Wayne >> > > >> > > [1] >> > > >> > >> https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading >> > > #Intermediate_CA_Preloading >> > > >> > > On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie wrote: >> > > >> > > > >> > > > >> > > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann >> > > > >> > > > wrote: >> > > > >> > > >> Ben Laurie via dev-security-policy >> > > >> >> > > >> writes: >> > > >> >> > > >> >In short: caching considered harmful. >> > > >> >> > > >> Or "cacheing considered necessary to make things work"? >> > > > >> > > > >> > > > If you happen to visit a bazil
Re: How Certificates are Verified by Firefox
I had thought that the OCSP privacy concerns were among the reasons for the general decline in OCSP queries issued by browsers. In addition, part of the rationale for development and encouragement of deployment of OCSP stapling. On Wed, Dec 4, 2019 at 6:12 PM Peter Bowen wrote: > Why not use OCSP? > > On Wed, Dec 4, 2019 at 3:52 PM Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Not that anyone is presently doing or would do such a thing, but... >> >> Imagine a CA that wanted to offer up a user/browser tracking service to >> their subscriber customer. >> >> Is there any rule that prevents an issuing CA from having a "custom" >> (hiding an identifier for the end-entity certificate) AIA URL? Such that >> when the browser AIA chases, it's disclosing the fact of the AIA chase as >> well as a user's IP address (and possibly some browser details) to the CA? >> One could easily do it with wildcard DNS and a per-end-entity cert host >> label for the AIA distribution point. >> >> >> On Wed, Dec 4, 2019 at 4:13 PM Ryan Sleevi via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> > Yes, I am one of the ones who actively disputes the notion that AIA >> > considered harmful. >> > >> > I'm (plesantly) surprised that any CA would be opposed to AIA (i.e. >> > supportive of "considered harmful", since it's inherently what gives >> them >> > the flexibility to make their many design mistakes in their PKI and >> still >> > have certificates work. The only way "considered harmful" would work is >> if >> > we actively remove the flexibility afforded CAs in this realm, which I'm >> > highly supportive of, but which definitely encourages more distinctive >> PKIs >> > (i.e. more explicitly reducing the use of Web PKI in non-Web cases) >> > >> > Of course, AIA is also valuable in helping browsers push the web >> forward, >> > so I can see why "considered harmful" is useful, especially in that it >> > helps further the notion that root certificates are a thing of value >> (and >> > whose value should increase with age). AIA is one of the key tools to >> > helping prevent that, which we know is key to ensuring a more flexible, >> and >> > agile, ecosystem. >> > >> > The flaw, of course, in a "considered harmful", is the notion that >> there's >> > One Chain or One Right Chain. That's not the world we have, nor have we >> > ever. The notion that there's One Right Chain for a TLS server to send >> > presumes there's One Right Set of CA Trust Anchors. And while that's >> > definitely a world we could pursue, I think we know from the past >> history >> > of CA incidents, there's incredible benefit to users to being able to >> > respond to CA security incidents differently, to remove trust in >> > deprecated/insecure things differently, and to set policies differently. >> > And so we can't expect servers to know the Right Chain because there >> isn't >> > One Right Chain, and AIA (or intermediate preloading with rapid updates) >> > can help address that. >> > >> > On Wed, Dec 4, 2019 at 5:02 PM Tim Hollebeek via dev-security-policy < >> > dev-security-policy@lists.mozilla.org> wrote: >> > >> > > Someone really should write up "AIA chasing considered harmful". It >> was >> > > disputed at the TLS session at IETF 105, which shows that the >> reasoning >> > > behind it is not as widely understood as it needs to be, even among >> TLS >> > > experts. >> > > >> > > I'm very appreciative of Firefox's efforts in this area. Leveraging >> the >> > > knowledge of all the publicly disclosed ICAs to improve >> chain-building is >> > > an >> > > idea whose time has come. >> > > >> > > -Tim >> > > >> > > > -Original Message- >> > > > From: dev-security-policy < >> > dev-security-policy-boun...@lists.mozilla.org >> > > > >> > > On >> > > > Behalf Of Wayne Thayer via dev-security-policy >> > > > Sent: Monday, December 2, 2019 3:29 PM >> > > > To: Ben Laurie >> > > > Cc: mozilla-dev-security-policy >> > > ; >> > > > Peter Gutmann >> > > > Subject: Re: [FORGED] Re: How Certificates are Verified by Firefox >> > > > >> > > > Why not "AIA chasing considered harmful"? The current state of >> affairs >> > is >> > > that >> > > > most browsers [other than Firefox] will go and fetch the >> intermediate >> > if >> > > it's not >> > > > cached. This manifests itself as sites not working in Firefox, and >> > users >> > > switching >> > > > to other browsers. >> > > > >> > > > You may be further dismayed to learn that Firefox will soon >> implement >> > > > intermediate preloading [1] as a privacy-preserving alternative to >> AIA >> > > chasing. >> > > > >> > > > - Wayne >> > > > >> > > > [1] >> > > > >> > > >> > >> https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading >> > > > #Intermediate_CA_Preloading >> > > > >> > > > On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie wrote: >> > > > >> > > > > >> > > > > >> > > > > On Thu, 28 Nov 2019 at 20:22, Peter Gutma
Re: How Certificates are Verified by Firefox
Why not use OCSP? On Wed, Dec 4, 2019 at 3:52 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Not that anyone is presently doing or would do such a thing, but... > > Imagine a CA that wanted to offer up a user/browser tracking service to > their subscriber customer. > > Is there any rule that prevents an issuing CA from having a "custom" > (hiding an identifier for the end-entity certificate) AIA URL? Such that > when the browser AIA chases, it's disclosing the fact of the AIA chase as > well as a user's IP address (and possibly some browser details) to the CA? > One could easily do it with wildcard DNS and a per-end-entity cert host > label for the AIA distribution point. > > > On Wed, Dec 4, 2019 at 4:13 PM Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Yes, I am one of the ones who actively disputes the notion that AIA > > considered harmful. > > > > I'm (plesantly) surprised that any CA would be opposed to AIA (i.e. > > supportive of "considered harmful", since it's inherently what gives them > > the flexibility to make their many design mistakes in their PKI and still > > have certificates work. The only way "considered harmful" would work is > if > > we actively remove the flexibility afforded CAs in this realm, which I'm > > highly supportive of, but which definitely encourages more distinctive > PKIs > > (i.e. more explicitly reducing the use of Web PKI in non-Web cases) > > > > Of course, AIA is also valuable in helping browsers push the web forward, > > so I can see why "considered harmful" is useful, especially in that it > > helps further the notion that root certificates are a thing of value (and > > whose value should increase with age). AIA is one of the key tools to > > helping prevent that, which we know is key to ensuring a more flexible, > and > > agile, ecosystem. > > > > The flaw, of course, in a "considered harmful", is the notion that > there's > > One Chain or One Right Chain. That's not the world we have, nor have we > > ever. The notion that there's One Right Chain for a TLS server to send > > presumes there's One Right Set of CA Trust Anchors. And while that's > > definitely a world we could pursue, I think we know from the past history > > of CA incidents, there's incredible benefit to users to being able to > > respond to CA security incidents differently, to remove trust in > > deprecated/insecure things differently, and to set policies differently. > > And so we can't expect servers to know the Right Chain because there > isn't > > One Right Chain, and AIA (or intermediate preloading with rapid updates) > > can help address that. > > > > On Wed, Dec 4, 2019 at 5:02 PM Tim Hollebeek via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > Someone really should write up "AIA chasing considered harmful". It > was > > > disputed at the TLS session at IETF 105, which shows that the reasoning > > > behind it is not as widely understood as it needs to be, even among TLS > > > experts. > > > > > > I'm very appreciative of Firefox's efforts in this area. Leveraging > the > > > knowledge of all the publicly disclosed ICAs to improve chain-building > is > > > an > > > idea whose time has come. > > > > > > -Tim > > > > > > > -Original Message- > > > > From: dev-security-policy < > > dev-security-policy-boun...@lists.mozilla.org > > > > > > > On > > > > Behalf Of Wayne Thayer via dev-security-policy > > > > Sent: Monday, December 2, 2019 3:29 PM > > > > To: Ben Laurie > > > > Cc: mozilla-dev-security-policy > > > ; > > > > Peter Gutmann > > > > Subject: Re: [FORGED] Re: How Certificates are Verified by Firefox > > > > > > > > Why not "AIA chasing considered harmful"? The current state of > affairs > > is > > > that > > > > most browsers [other than Firefox] will go and fetch the intermediate > > if > > > it's not > > > > cached. This manifests itself as sites not working in Firefox, and > > users > > > switching > > > > to other browsers. > > > > > > > > You may be further dismayed to learn that Firefox will soon implement > > > > intermediate preloading [1] as a privacy-preserving alternative to > AIA > > > chasing. > > > > > > > > - Wayne > > > > > > > > [1] > > > > > > > > > > https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading > > > > #Intermediate_CA_Preloading > > > > > > > > On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie wrote: > > > > > > > > > > > > > > > > > > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann > > > > > > > > > > wrote: > > > > > > > > > >> Ben Laurie via dev-security-policy > > > > >> > > > > >> writes: > > > > >> > > > > >> >In short: caching considered harmful. > > > > >> > > > > >> Or "cacheing considered necessary to make things work"? > > > > > > > > > > > > > > > If you happen to visit a bazillion sites a day. > > > > > > > > > > > > > > >> In particular: > > > > >> > > > > >> >caching them and filling in
Re: [FORGED] Re: How Certificates are Verified by Firefox
Not that anyone is presently doing or would do such a thing, but... Imagine a CA that wanted to offer up a user/browser tracking service to their subscriber customer. Is there any rule that prevents an issuing CA from having a "custom" (hiding an identifier for the end-entity certificate) AIA URL? Such that when the browser AIA chases, it's disclosing the fact of the AIA chase as well as a user's IP address (and possibly some browser details) to the CA? One could easily do it with wildcard DNS and a per-end-entity cert host label for the AIA distribution point. On Wed, Dec 4, 2019 at 4:13 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Yes, I am one of the ones who actively disputes the notion that AIA > considered harmful. > > I'm (plesantly) surprised that any CA would be opposed to AIA (i.e. > supportive of "considered harmful", since it's inherently what gives them > the flexibility to make their many design mistakes in their PKI and still > have certificates work. The only way "considered harmful" would work is if > we actively remove the flexibility afforded CAs in this realm, which I'm > highly supportive of, but which definitely encourages more distinctive PKIs > (i.e. more explicitly reducing the use of Web PKI in non-Web cases) > > Of course, AIA is also valuable in helping browsers push the web forward, > so I can see why "considered harmful" is useful, especially in that it > helps further the notion that root certificates are a thing of value (and > whose value should increase with age). AIA is one of the key tools to > helping prevent that, which we know is key to ensuring a more flexible, and > agile, ecosystem. > > The flaw, of course, in a "considered harmful", is the notion that there's > One Chain or One Right Chain. That's not the world we have, nor have we > ever. The notion that there's One Right Chain for a TLS server to send > presumes there's One Right Set of CA Trust Anchors. And while that's > definitely a world we could pursue, I think we know from the past history > of CA incidents, there's incredible benefit to users to being able to > respond to CA security incidents differently, to remove trust in > deprecated/insecure things differently, and to set policies differently. > And so we can't expect servers to know the Right Chain because there isn't > One Right Chain, and AIA (or intermediate preloading with rapid updates) > can help address that. > > On Wed, Dec 4, 2019 at 5:02 PM Tim Hollebeek via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Someone really should write up "AIA chasing considered harmful". It was > > disputed at the TLS session at IETF 105, which shows that the reasoning > > behind it is not as widely understood as it needs to be, even among TLS > > experts. > > > > I'm very appreciative of Firefox's efforts in this area. Leveraging the > > knowledge of all the publicly disclosed ICAs to improve chain-building is > > an > > idea whose time has come. > > > > -Tim > > > > > -Original Message- > > > From: dev-security-policy < > dev-security-policy-boun...@lists.mozilla.org > > > > > On > > > Behalf Of Wayne Thayer via dev-security-policy > > > Sent: Monday, December 2, 2019 3:29 PM > > > To: Ben Laurie > > > Cc: mozilla-dev-security-policy > > ; > > > Peter Gutmann > > > Subject: Re: [FORGED] Re: How Certificates are Verified by Firefox > > > > > > Why not "AIA chasing considered harmful"? The current state of affairs > is > > that > > > most browsers [other than Firefox] will go and fetch the intermediate > if > > it's not > > > cached. This manifests itself as sites not working in Firefox, and > users > > switching > > > to other browsers. > > > > > > You may be further dismayed to learn that Firefox will soon implement > > > intermediate preloading [1] as a privacy-preserving alternative to AIA > > chasing. > > > > > > - Wayne > > > > > > [1] > > > > > > https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading > > > #Intermediate_CA_Preloading > > > > > > On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie wrote: > > > > > > > > > > > > > > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann > > > > > > > > wrote: > > > > > > > >> Ben Laurie via dev-security-policy > > > >> > > > >> writes: > > > >> > > > >> >In short: caching considered harmful. > > > >> > > > >> Or "cacheing considered necessary to make things work"? > > > > > > > > > > > > If you happen to visit a bazillion sites a day. > > > > > > > > > > > >> In particular: > > > >> > > > >> >caching them and filling in missing ones means that failure to > > > >> >present correct cert chains is common behaviour. > > > >> > > > >> Which came first? Was cacheing a response to broken chains or > broken > > > >> chains a response to cacheing? > > > >> > > > >> Just trying to sort out cause and effect. > > > >> > > > > > > > > Pretty sure if broken chains caused browsers to not show pages, then > > > > there woul
Re: [FORGED] Re: How Certificates are Verified by Firefox
Yes, I am one of the ones who actively disputes the notion that AIA considered harmful. I'm (plesantly) surprised that any CA would be opposed to AIA (i.e. supportive of "considered harmful", since it's inherently what gives them the flexibility to make their many design mistakes in their PKI and still have certificates work. The only way "considered harmful" would work is if we actively remove the flexibility afforded CAs in this realm, which I'm highly supportive of, but which definitely encourages more distinctive PKIs (i.e. more explicitly reducing the use of Web PKI in non-Web cases) Of course, AIA is also valuable in helping browsers push the web forward, so I can see why "considered harmful" is useful, especially in that it helps further the notion that root certificates are a thing of value (and whose value should increase with age). AIA is one of the key tools to helping prevent that, which we know is key to ensuring a more flexible, and agile, ecosystem. The flaw, of course, in a "considered harmful", is the notion that there's One Chain or One Right Chain. That's not the world we have, nor have we ever. The notion that there's One Right Chain for a TLS server to send presumes there's One Right Set of CA Trust Anchors. And while that's definitely a world we could pursue, I think we know from the past history of CA incidents, there's incredible benefit to users to being able to respond to CA security incidents differently, to remove trust in deprecated/insecure things differently, and to set policies differently. And so we can't expect servers to know the Right Chain because there isn't One Right Chain, and AIA (or intermediate preloading with rapid updates) can help address that. On Wed, Dec 4, 2019 at 5:02 PM Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Someone really should write up "AIA chasing considered harmful". It was > disputed at the TLS session at IETF 105, which shows that the reasoning > behind it is not as widely understood as it needs to be, even among TLS > experts. > > I'm very appreciative of Firefox's efforts in this area. Leveraging the > knowledge of all the publicly disclosed ICAs to improve chain-building is > an > idea whose time has come. > > -Tim > > > -Original Message- > > From: dev-security-policy > > On > > Behalf Of Wayne Thayer via dev-security-policy > > Sent: Monday, December 2, 2019 3:29 PM > > To: Ben Laurie > > Cc: mozilla-dev-security-policy > ; > > Peter Gutmann > > Subject: Re: [FORGED] Re: How Certificates are Verified by Firefox > > > > Why not "AIA chasing considered harmful"? The current state of affairs is > that > > most browsers [other than Firefox] will go and fetch the intermediate if > it's not > > cached. This manifests itself as sites not working in Firefox, and users > switching > > to other browsers. > > > > You may be further dismayed to learn that Firefox will soon implement > > intermediate preloading [1] as a privacy-preserving alternative to AIA > chasing. > > > > - Wayne > > > > [1] > > > https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading > > #Intermediate_CA_Preloading > > > > On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie wrote: > > > > > > > > > > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann > > > > > > wrote: > > > > > >> Ben Laurie via dev-security-policy > > >> > > >> writes: > > >> > > >> >In short: caching considered harmful. > > >> > > >> Or "cacheing considered necessary to make things work"? > > > > > > > > > If you happen to visit a bazillion sites a day. > > > > > > > > >> In particular: > > >> > > >> >caching them and filling in missing ones means that failure to > > >> >present correct cert chains is common behaviour. > > >> > > >> Which came first? Was cacheing a response to broken chains or broken > > >> chains a response to cacheing? > > >> > > >> Just trying to sort out cause and effect. > > >> > > > > > > Pretty sure if broken chains caused browsers to not show pages, then > > > there wouldn't be broken chains. > > > > > > -- > > > I am hiring! Formal methods, UX, SWE ... verified s/w and h/w. > > > #VerifyAllTheThings. > > > > > > https://g.co/u58vjr https://g.co/adjusu *(Google internal)* > > > > > ___ > > 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: [FORGED] Re: How Certificates are Verified by Firefox
Someone really should write up "AIA chasing considered harmful". It was disputed at the TLS session at IETF 105, which shows that the reasoning behind it is not as widely understood as it needs to be, even among TLS experts. I'm very appreciative of Firefox's efforts in this area. Leveraging the knowledge of all the publicly disclosed ICAs to improve chain-building is an idea whose time has come. -Tim > -Original Message- > From: dev-security-policy On > Behalf Of Wayne Thayer via dev-security-policy > Sent: Monday, December 2, 2019 3:29 PM > To: Ben Laurie > Cc: mozilla-dev-security-policy ; > Peter Gutmann > Subject: Re: [FORGED] Re: How Certificates are Verified by Firefox > > Why not "AIA chasing considered harmful"? The current state of affairs is that > most browsers [other than Firefox] will go and fetch the intermediate if it's not > cached. This manifests itself as sites not working in Firefox, and users switching > to other browsers. > > You may be further dismayed to learn that Firefox will soon implement > intermediate preloading [1] as a privacy-preserving alternative to AIA chasing. > > - Wayne > > [1] > https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading > #Intermediate_CA_Preloading > > On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie wrote: > > > > > > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann > > > > wrote: > > > >> Ben Laurie via dev-security-policy > >> > >> writes: > >> > >> >In short: caching considered harmful. > >> > >> Or "cacheing considered necessary to make things work"? > > > > > > If you happen to visit a bazillion sites a day. > > > > > >> In particular: > >> > >> >caching them and filling in missing ones means that failure to > >> >present correct cert chains is common behaviour. > >> > >> Which came first? Was cacheing a response to broken chains or broken > >> chains a response to cacheing? > >> > >> Just trying to sort out cause and effect. > >> > > > > Pretty sure if broken chains caused browsers to not show pages, then > > there wouldn't be broken chains. > > > > -- > > I am hiring! Formal methods, UX, SWE ... verified s/w and h/w. > > #VerifyAllTheThings. > > > > https://g.co/u58vjr https://g.co/adjusu *(Google internal)* > > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Add section 5.1 to the Common CCADB Policy
All, Section 5.1 has been added to the CCADB Policy. https://www.ccadb.org/policy#51-audit-statement-content Please let me know if you see any problems with the addition. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
