Re: Criticism of Google Re: Google Trust Services roots
* Peter Kurrasch via dev-security-policy: > By "not new", are you referring to Google being the second(?) instance > where a company has purchased an individual root cert from another > company? It's fair enough to say that Google isn't the first but I'm > not aware of any commentary or airing of opposing viewpoints as to the > suitability of this practice going forward. I think most of the DNs in the Mozilla root store still do not reflect reality. The restrictions on certificate naming do not apply to the CAs themselves. This is due to the way PKIX validation works. Correcting the DNs would break the certificate chains. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys
* Nick Lamb via dev-security-policy: > In order for Symantec to reveal anybody's private keys they'd first > need to have those keys, which is already, IIRC forbidden in the > BRs. I think this requirement was dropped because it makes it unnecessarily difficult to report key compromises. There used to be a time when CAs demanded zero-knowledge proofs of key compromise (which can be surprisingly hard to do with existing tools). Fortunately, these times are over, and CAs no longer categorically reject the submission of compromised subscriber keys (although my sample is really small due to my limited factorization capabilities). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites
* mono riot: >> I've been wondering if CT is a good tool for things like safe >> browsing to monitor possible phishing sites and possibly detect >> them faster. > > Are there general proposals yet on how to distinguish phishing vs > legitimate when it comes to domains? (like apple.com vs app1e.com vs > mom'n'pop farmer's myapple.com) If there was a general rule, people would game the system, making the rule useless. In general, recognizing malicious web content requires looking at said content. It is not possible to go by the domain name alone. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft Email - Non-Disclosed SubCAs
* Kathleen Wilson: > The following was stated in Mozilla’s March 2016 CA Communication > (https://wiki.mozilla.org/CA:Communications#March_2016): > Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any > certificate which directly or transitively chains to the root > certificates you currently have included in Mozilla's CA Certificate > Program, which are capable of being used to issue new certificates, > and which are not technically constrained as described in Section 9 of > Mozilla's CA Certificate Inclusion Policy, you are required to provide > public-facing documentation about the certificate verification > requirements and annual public attestation of conformance to said > requirements. This includes certificates owned by, operated by, or > issued by third parties, whether or not those issuing certificates are > already part of Mozilla's CA Certificate Program, if they have been > cross-signed by a certificate that directly or transitively chains to > your root certificate. Does this requirement apply transitively sub-CAs of sub-CAs? It may make sense to stress explicitly that the “technically constrained” refers to properties visible in the certificates themselves, not technical measures in the certificate issuance process (which I would consider organizational constraints, but opinions probably differ). What about sub-CAs with outdated published policies which do not meet Mozilla's requirements, but where the CA actually issues certificates according to an unpublished policy which is likely conforming to Mozilla's requirements? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign and StartCom: next steps
* Hanno Böck: > Minor sidenote: there have been some concerns about TLS security > vulnerabilities of the qihoo 360 browser [1] [2]. While this is not > directly related to the operation of a CA, it surely would increase the > community's trust of qihoo 360 if these issues get resolved quickly. > > > [1] https://cabforum.org/pipermail/public/2015-April/005441.html > [2] https://twitter.com/ryancdotorg/status/780470538686697472 It is certainly possible to implement access to servers using untrusted X.509 certificates in such a way that security is compromised only after further user action (e.g. supplying login credentials, despite the browser warning). A reasonable approximation of such a secure implementation is to visit the site with a fresh Firefox profile, and override the certificate warning. More care is needed to check the origin of the cookie which, according to Tom Ritter's post, the browser transmitted without further user interaction. It might be the case that the cookie is not marked as secure (restricting it to HTTPS), or it may have been created as a secure cookie over an untrusted HTTPS connection. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
* Patrick Figel: > On 17/09/16 16:38, Florian Weimer wrote: >> * Peter Bowen: >> >>> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei >>> wrote: >>>> So when I delegated the DNS service to Cloudflare, Cloudflare >>>> have the privilege to issue the certificate by default? Can I >>>> understand like that? >>> >>> I would guess that they have a clause in their terms of service or >>> customer agreement that says they can update records in the DNS >>> zone and/or calls out that the subscriber consents to them getting >>> a certificate for any domain name hosted on CloudFlare DNS. >> >> I find it difficult to believe that the policies permit Cloudflare's >> behavior, but are expected to prevent the issue of interception >> certificates. Aren't they rather similar, structurally? > > I don't see how they're similar. Interception certificates are issued > without the knowledge and permission of the domain owner. Someone > signing up for CloudFlare willingly chooses to trust a CDN provider with > all their web traffic and DNS (in order to enable CloudFlare for a > domain, the NS record for that domain needs to point to CloudFlare.) > > I could understand this argument if they'd somehow pretend to be a > DNS-only provider and then abuse that to issue certificates. However, > nothing about their site (or their marketing approach in general) gives > me that impression - it's made quite clear that they're primarily a CDN > with SSL support. Well, there is <https://www.cloudflare.com/dns/>. My concern goes like this: If I move my infrastructure to Cloudflare, I give them implied permission, based on their terms of service, to obtain a X.509 certificate for my domain names hosted there, so that they can intercept traffic. On the other hand, if I move my infrastructure to Germany, I give the German authorities implied permission, based on applicable German law, to ask my service provide to obtain an X.509 certificate for my domain names hosted there, so that they can intercept traffic in the clear (in accordance with German law). In both cases, we have implied consent, but the alleged certificate subscriber never has control over the private key, and how it is used. I don't think neither setup is intended to exist per the Mozilla CA guidelines. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incidents involving the CA WoSign
* Richard Wang: >> Thus, do you believe it was faithful and accurate for Management to >> warrant that the CA was operated in compliance with the BRs, given >> that Management was aware of incidents of non-compliance? > > This is my fault that I think it is not serious enough to state in > the assertion letter, now I know and every related employee know how > to do this in the future. Richard, do you think more precise communication from auditors could have helped to avoid the incorrect representation? Thanks, Florian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
* Peter Bowen: > On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei wrote: >> So when I delegated the DNS service to Cloudflare, Cloudflare have >> the privilege to issue the certificate by default? Can I understand >> like that? > > I would guess that they have a clause in their terms of service or > customer agreement that says they can update records in the DNS zone > and/or calls out that the subscriber consents to them getting a > certificate for any domain name hosted on CloudFlare DNS. I find it difficult to believe that the policies permit Cloudflare's behavior, but are expected to prevent the issue of interception certificates. Aren't they rather similar, structurally? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
* Ben Laurie: > On 10 September 2016 at 15:43, Erwann Abalea wrote: >> Ironically, since you're not the Subscriber, you cannot request for >> the revocation of this certificate, at least not directly to the >> CA. If you want this certificate to be revoked, you need to ask >> Cloudflare. > > Surely not? The BRs say (4.9.2): > > "The Subscriber, RA, or Issuing CA can initiate revocation. > Additionally, Subscribers, Relying Parties, Application Software > Suppliers, and other third parties may submit Certificate Problem > Reports informing the issuing CA of reasonable cause to revoke the > certificate." This is fairly new. Third-party revocation requests are very tricky to process promptly. For many (most?) interesting certificates, the guaranteed damage from an immediate revocation outweighs the risk from a potential man-in-the-middle attack enabled by the compromised certificate. Back in 2008, most CAs flat out refused to revoke certificates even though there was proof that the private key has been compromised. A very small-scale repeat exercise showed that this is no longer the case. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign Issue L and port 8080
* Nick Lamb: > On Sunday, 11 September 2016 21:05:12 UTC+1, Lee wrote: >> does dns hijacking or dns cache poisoning count as mitm? > > A careful CA validator does DNS only by making authoritative queries, > so they're not subject to cache poisoning since they don't look at > cached answers. I'm not sure if you can resolve all domains without some sort of DNS cache, in the sense that you never use data from one answer to satisfy more than one query (which can be internally generated). More reasonable would be to require that the resolver starts with a cold cache (possibly preloaded with a copy of the root zone) and performs DNSSEC validation starting with the IANA keys. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Nation State MITM CA's ?
* Jakob Bohm: > Could they, hypothetically, simply claim to use the real certificate on > the connection from their MiTM machines to the real server to do > practical control validation? They would have to claim, also, that > they are holding the private key of the MiTM certificate "in trust" on > behalf of the site owners "on whose behalf" the issued the certifiate? > (Just playing devils advocate). I think it's similar to what certain CDNs do: They hold the key material (both long term and session) on behalf of the server operator. A TLS interception facility holds the session keys on behalf of the client. Both parties claim to increase Internet security. Both are probably right in some ways, and wrong in others. Florian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Gervase Markham: > On 25/03/15 10:27, Florian Weimer wrote: >> * The CNNIC CPS is incorrect, and they no longer run an >> Entrust-sponsored sub-CA. > > I believe this is the correct answer. Quoting Bruce Morton in this thread: > > "Please note that the intermediate certificate which Entrust issued to > CNNIC expired in 2012 and was not extended. Also note that the Basic > Constraints had a path length of 0; as such the trust would not have > extended to intermediates issued by CNNIC." Yes, I saw this message only after I had posted the above. This leads to the question why Ernst & Young, CNNIC's auditors, have not caught this discrepancy between the CPS and actual business practice. The most recent audit <https://cert.webtrust.org/SealFile?seal=1731&file=pdf> already covers the time period when CNNIC ceased to be an Entrust sub-CA. (I think to clean up this mess, we should focus on formal mistakes by auditors, not things that can be downplayed as operational glitches.) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Daniel Micay: > In other words, if you want the responsible choice to be made in these > cases then you should be contacting news publications to shame Mozilla > into doing the right thing - not a Mozilla mailing list. Ugh, surely there has to be a better way. I sometimes get carried away and post acerbic comments about things like the dynamics of maintaining a market share (sorry about that), but what you propose is totally over the top. The present can of worms is not just about an unwillingness to do the right thing (whatever that is), but there are one or two unsolved engineering problems involved. You simply can't make those go away by media pressure. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Bruce: > On Tuesday, March 24, 2015 at 3:41:50 PM UTC-4, Florian Weimer wrote: >> * Kai Engert: >> >> > The discovery of any unconstrained and unrevoked intermediate CA >> > certificate that isn't controlled by the root CA organization results in >> > the immediate removal of the root CA from the Mozilla CA list. >> >> In this case, wouldn't this require the removal of the Entrust root, >> not just the CNNIC root? Or wasn't the CNNIC SSL sub-CA certificate >> extended beyond 2012? >> >> Clearly, the removal of an actually relevant root CA from the trust >> store is not going to happen because the user impact and subsequent >> reduction in browser market share. > > Please note that the intermediate certificate which Entrust issued > to CNNIC expired in 2012 and was not extended. Also note that the > Basic Constraints had a path length of 0; as such the trust would > not have extended to intermediates issued by CNNIC. Sorry, Bruce, I saw your message just now, it was not properly threaded. It is good to know that the certificate was not extended. But as I wrote in my other message, the CNNIC CPS from 2013 onwards claims that the Entrust signature is still valid. :-( ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Florian Weimer: > * Kai Engert: > >> The discovery of any unconstrained and unrevoked intermediate CA >> certificate that isn't controlled by the root CA organization results in >> the immediate removal of the root CA from the Mozilla CA list. > > In this case, wouldn't this require the removal of the Entrust root, > not just the CNNIC root? Or wasn't the CNNIC SSL sub-CA certificate > extended beyond 2012? According to the CNNIC CPS, the sub-CA certificate still exists: “According to the agreement of CNNIC and Entrust, CNNIC intermediate root CNNIC SSL is trusted by Entrust root certificate also. The domain certificates issued by CNNIC Trusted Network Service Center may be generated through different route either by CNNIC root or by Entrust root.” Certificate Practice Statement of the Trusted Network Service Center of the China Internet Network Information Center (CNNIC) Version No.: 3.03 Validity from July 1st, 2013 <http://www1.cnnic.cn/IS/fwqzs/CNNICfwqzsywgz/201208/W020130929345948738150.pdf> However, Entrust does not list the sub-CA certificate here: <http://www.entrust.net/about/third-party-sub-ca.htm> As far as I can see, there are several explanations for that: * It was omitted by accident. * The CNNIC root was signed (although only signatures on the intermediate CNNIC SSL CA certificate have been documented so far, I think). * Entrust assumes that once an organization has a root in the Mozilla program, any sub-CAs controlled by that organization is exempted from disclosure. * The CNNIC CPS is incorrect, and they no longer run an Entrust-sponsored sub-CA. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Rob Stradling: > On 24/03/15 19:58, Florian Weimer wrote: > >> There's also an ongoing effort to defang CT and make the data much >> less useful, so CT could turn meaningless fairly soon. > > Huh? The work on name redaction worries me. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Daniel Micay: > These rules would be a lot more meaningful if any new additions to the > trust store were required to have Certificate Transparency implemented > for the sake of auditing, along with a deadline for other CAs to put it > in place. CT would have meant this was trivially caught *much* earlier > by security researchers. That depends on how many legitimate gmail.com certificates are out there. Organizations struggle to keep track of their own certificates. It's difficult to see how relative outsiders (and most “security researchers” are) can cope with that, except by raising an alarm about everything they see (which is not generally helpful). There's also an ongoing effort to defang CT and make the data much less useful, so CT could turn meaningless fairly soon. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
* Kai Engert: > The discovery of any unconstrained and unrevoked intermediate CA > certificate that isn't controlled by the root CA organization results in > the immediate removal of the root CA from the Mozilla CA list. In this case, wouldn't this require the removal of the Entrust root, not just the CNNIC root? Or wasn't the CNNIC SSL sub-CA certificate extended beyond 2012? Clearly, the removal of an actually relevant root CA from the trust store is not going to happen because the user impact and subsequent reduction in browser market share. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Consequences of mis-issuance under CNNIC
* Kurt Roeckx: > I understand that the name constraint applies to the > SubjectAltName. Under the Baseline Requirements the SAN must be > present. If there is a CommonName it should match one of the SANs. If the CAs abided by the baseline requirements, we wouldn't have to consider name constraints. :-( > We know that not everybody does add the SANs. But I think that if > there is a name constraint and there is no SAN we should just either > reject the certificate for being invalid or for not matching. This has to be integrated with certificate path processing somehow. Maybe it is feasible to ignore the Subject DN if there is a name constraint anywhere on the path? That would be fairly straightforward to implement with other PKIX validators (which generally lack the NSS hack for Common Name verification). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Consequences of mis-issuance under CNNIC
* Gervase Markham: > On 24/03/15 09:35, Florian Weimer wrote: >> Sadly, name constraints do not work because they do not constrain the >> Common Name field. The IETF PKIX WG explicitly rejected an erratum >> which corrected this oversight. >> >> NSS used to be different (before the mozilla::pkix rewrite), but it's >> not PKIX-compliant. > > My understanding is that we continue to constrain the CN field using > name constraints, even after adopting mozilla::pkix; do you know > differently? I simply have not investigated, my comment was poorly phrased in this regard. > Anyway, the BRs require that the value in the CN field be repeated in > the SAN field. So, at some point in the future, for publicly-trusted > certs anyway, we can start ignoring the CN field. > >>From BRs draft 30b: > > "If present, this field MUST contain a single Fully-Qualified > Domain Name that is one of the values contained in the > Certificate's subjectAltName extension (see Section 9.2.1)." > > The BRs were adopted in 2011 and had an effective date of 1st July 2012. > At the time, they permitted 5 year issuance. So on 1st July 2017, we > should be able to start ignoring CN if we want. This is an interesting idea. It would be a nice simplification. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Consequences of mis-issuance under CNNIC
* Gervase Markham: > On 24/03/15 09:38, Florian Weimer wrote: >> The intermediate certificate which prompted this discussion had C=EG, >> which does not align well with a limitation to the Chinese market. > > I'm not entirely sure what you are saying here. Are you saying you are > suprised not to see ".eg" in that list? Or a more diverse choice of (cc)TLDs, yes. > CNNIC could issue a cert to an Egyptian Company called Cairo Corporation > for cairocorp.com, and the issuer would be C=EG, O=Cairo Corporation, > but the CN would be www.cairocorp.com. In this type of case, .eg would > not show up in the list. Technically, this is true. I just find it odd that the offending certificate suggests a relationship with a non-Chinese market, while at the same time, Richard's data only shows the top gTLDs and various China-related TLDs. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Consequences of mis-issuance under CNNIC
* Gervase Markham: > On 24/03/15 00:59, Peter Kurrasch wrote: >> Is the proposal to limit CNNIC roots to only .cn domains or would >> others be allowed? > > That's a matter for discussion. We do have some data (thanks, Richard) > from CT and other places on the prevalence of CNNIC certificates in > those scans, broken down by TLD: > > cn: 481 > com: 203 > net: 10 > xn--fiqs8s: 8 (This is 中国, .china in Simplified characters) > xn--55qx5d: 4 (This is 公司, basically .com) > xn--io0a7i: 2 (This is 网络, basically .net) > wang: 2 (This is the Pinyin (romanization) for 网, which you can see >in the .net equivalent above. Chinese internet cafes have >this character on their signs. http://icannwiki.com/.wang) > xn--fiqz9s: 1 (This is 中國, .china in Traditional characters) > > This is useful in assessing the impact of any particular proposed set of > changes. The intermediate certificate which prompted this discussion had C=EG, which does not align well with a limitation to the Chinese market. How reliable are the data quoted above? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Consequences of mis-issuance under CNNIC
* Kurt Roeckx: > So it's my understanding that they were only supposed to issue > certificates for their own domain(s). Why wasn't this enforced by > using a name constraint? Sadly, name constraints do not work because they do not constrain the Common Name field. The IETF PKIX WG explicitly rejected an erratum which corrected this oversight. NSS used to be different (before the mozilla::pkix rewrite), but it's not PKIX-compliant. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Name Constraints
* Richard Barnes: > I've been doing some research on the potential benefits of adding name > constraints into the Mozilla root program. I've drafted an initial > proposal and put it on a wiki page: > > https://wiki.mozilla.org/CA:NameConstraints > > Questions and comments are very welcome. A PKIX-compliant implementation of Name Constraints is not effective in the browser PKI because these constraints are not applied to the Common Name. NSS used to be non-compliant (and deliberately so), so the constraints do work there, but I don't know if that's still the case. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about disclosing subCA certs
* Kurt Roeckx: >> RFC 5280 is pretty clear that implementations must support end-entity >> certificates without the subjectAltName extension under under a CA >> which has name constraints. > > But the CA/B baseline requirements does require a SAN, so there is > no reason for us not to require it. RFC 5280 is clearly buggy as far as HTTPS is concerned, so the NSS behavior is fine. It's just that this behavior is pretty much specific to NSS, but the Mozilla-approved root certificates are used in a wider context. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about disclosing subCA certs
* Kurt Roeckx: > On Sun, May 25, 2014 at 12:17:11PM +0200, Florian Weimer wrote: >> * Kathleen Wilson: >> >> > Unless it is technically constrained as described in section 9 of the >> > policy. >> >> Unfortunately, a conforming implementation of PKIX validation makes >> name constraints useless as a security feature (see bug 394919 for >> details). > > I'm not sure I understand what you're saying. I'm expecting this > behaviour: > - When the CA is constrained, not having a SAN should result in > a validation error. There really is no excuse for this. RFC 5280 is pretty clear that implementations must support end-entity certificates without the subjectAltName extension under under a CA which has name constraints. > - When the SAN is present and there is a CN, the CN should be one > of the SANs, so can just be ignored. You could go and check that According to RFC 5280, CNs do not contain domain names, so there is no need to check them against dnsName constraints. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about disclosing subCA certs
* Kathleen Wilson: > Unless it is technically constrained as described in section 9 of the > policy. Unfortunately, a conforming implementation of PKIX validation makes name constraints useless as a security feature (see bug 394919 for details). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about disclosing subCA certs
* Jeremy Rowley: > She's clarified in the discussion thread that it is all SubCAs chained to > the a CAs root certificate that must be disclosed, regardless of who > controls the private key. In any case, control over the private key is only one aspect. It's also important who runs the Registration Authority and who enforces the validity of the bits in the certificate that are automatically processed. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cloudflare heartbleed challenge, Re: Revocation Policy
* Peter Eckersley: > Florian, there's something that about legal rules that is often quite > unintuitive to those of us with technical backgrounds: lawyers don't > necessarily expect them to be followed exhaustively all of the time. And they tend to withhold compassion (or technical judgments). > At least in common law countries (.us, .uk, .ca, .au, .il, and many > more), legal rules exist most profoundly to resolve disputes between > people who cannot resolve their dispute by less formal means. Exactly, once lawyers are involved, formalities matter, and the rules are quite different compared to what we would use otherwise. > As a legal instrument, the Baseline Requirements should be > understood in the same tradition. They exist as operational > guidelines, and as a fallback mechanism if there is an unresolved > dispute with a CA. The Cloudflare Challenge is a pretty unusual > case that probably wasn't anticipated by whoever drafted the BRs and > the Comodo CPS. But if there's nobody who has a security problem > because of the Cloudflare Challenge, why on earth would the cert be > revoked? I totally disagree with that, for two reasons. The first one is that we are not merely dealing with a dispute between two contracting parties. If subscribers and CAs were free to negotiate alternative terms, the current frameworks of policy reviews and audits would be completely pointless. The second reason is the following: What you are proposing is a value judgement. But these have no place in the browser PKI. For example, a properly contained sub-CA which issues interception certificates for internal company use arguably increases security for the covered users because content passing in and out can be reviewed independently from the end points. Furthermore, many people will agree that interception certificates for targeting terrorists and other criminals would result in a net benefit as well. I think it is extremely difficult to draw the line between "good" CA policy violations and "bad" ones, so it's better not to start. Requesting certificates with the intent of leaking the private key is against the rules, so just don't do it. It is debatable whether the rules makes sense (especially the CA-initiated revocations on key compromise, as mandated by Mozilla's rules, seem problematic to me), but then the rules need changing. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cloudflare heartbleed challenge, Re: Revocation Policy
* Jürgen Brauckmann: > Cloudflare set up a challenge with nginx on Ubuntu. Seems some > people succeeded in extracting the servers private key: > > https://www.cloudflarechallenge.com/heartbleed FWIW, I've asked Comodo to revoke the Cloudflare certificate due to this compromise. The challenge itself is probably against the subscriber agreement, but that is an internal matter between Cloudflare and Comodo. On the other hand, I do think that a rule that requires CAs to revoke keys against the subscriber's will can be problematic. But nevertheless, it's a rule, and we'll see if all those costly audits are good at ensuring that CAs follow it. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Stop using SHA1 in certificates
* Kurt Roeckx: > But it's unclear if this is really a policy or just what some > people think should happen. If we do this, it should not just apply to end-entity certificates, but also to intermediate certificates (but not the self-signature of root certificates). Obviously, that's rather unlikely to happen because of the number of long-term intermediate certificates which cannot be re-issued under current policies. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Second discussion of Atos Root Inclusion Request
* martin: > The subjects's name is not the domain name, it is the legal entity's name. > Point one means: The subject's name in the certificate must match the name of > the domain owner. (checked f.e. via www.denic.de, with www.iana.com) > Point two means: The subject's name must match the name of the requester. > Point three mwans: The existence of the subject's name is evident from an > excerpt from the commercial register. I thought those described the checks you implement to fulfill the Cabforum requirements on domain control validation. I couldn't find anything else in the CPS that is relevant to this question. And could you add specific document versions to your references, please? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Second discussion of Atos Root Inclusion Request
* Kathleen Wilson: >> The primary document is the CPS which is provided in English. >> https://pki.atos.net/EJPKI-WebFrontend/Public/TrustedRoot/Download?File=AtosTrustedCA_CPS_v1.6.pdf Clause 77 is both overly restrictive (domain name must match registered company name) and permissive (domain ownership not required). Is this intentional? | […] | • The device or system possesses an Internet Domain name, and a | registration as Top Level Domain (which can be found for Germany | with www.denic.de or international with www.iana.com) inclusive | verification for homographic IDNs, where the registered full name of | the legal entity is registered and this matches the subject’s full | name. | | • The legal’s entity full name matches the subject’s name in the | certificate. | […] ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
