Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....
As a practical exercise in logic, pick any CA that issues EV Certificates and is CAB BR compliant. Look at the CA Certificate Policy Statement and Relying Party Agreement. It's irrelevant to cite the UX of the "normal" user without first look at the agreements and policy. For the most part it will say they are not concerned with content. There is no uniqueness assumed unless one uses a logically consistent Directory (X.500) which does not allow duplicate names. This is why people register multiple sound alike domain names. The CA is only responsible to get you to the domain in the certificate and to verify (to some degree) additional identity or business attributes. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
c=US policy layer in development
https://groups.google.com/forum/#!forum/cus-policy-layer ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
ACES Sunset
https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/gsa-aces-sunset-guide.pdf ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On the value of EV
@Ryan “Since improving it as a technical means is an effective non-starter (e.g. introducing a new origin for only EV certs), the only fallback is to the cognitive means” EV is a convenient signal. I like it. The problem is the infrastructure that pits the Internet and it’s protocols with inadequate protection for the end user against active adversaries. Whether the false “claim” of security is being made contrary to what most security experts would consider a fact (or an I wrong?) is a problem not specific to UI, but to one of OWASP threats. Perhaps a moral question of fooling Internet users via a higher level of security knowledge. In general the IETF and IAB have already reached consensus that internet users and use cases should have the same rights to protection that other organizations have. Mozilla acknowledges this by not locating the GooglePlex in Boca Raton, Fl. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: On the value of EV
@Jakob I was referring to the classical namespaces which have evolved since the 1980s. The NSF pilot project was based on a now obsolete version of X.500, Quipu, that world rooted with participating county directories. While I managed that part of the capital D Directory it was in the context of c=US. It was at that point we modified the EDB of the pilot project to include certificates so that the nuclear labs could use low cost Internet mail to collabrate with other organizations to decrease the number of weapons under the negotiated treaties. During that time the labs went through the process of also proposing and adopting the domain component approach. Still it was possible as an internet user to download a certificate from a part of c=US that was part of that directory tree. Since the certificate is a viable stand alone ASN1 object then it actually does not entirely matter where one obtains the certificate, (but with some caveats as to the original design) which relates to semiotics and the general nature of what is considered authoritative or even useful in the post dot com world. For example, when those of us in the US represent ourselves to people that are not in the US. I can look at the certificate that is pushed to a user (and of course no longer trusted) and say, hmm based on my knowledge of Google, and geography, and business, they are not located in Boca Raton. I find the EV helpful as a user, but I know it is masking a deeper problem. And I don’t see any of the CA who acknowledge this problem privately as doing the right thing based on a tacit realpolitik that ultimately disadvantages the Internet user with less than optimal security. It’s not that the state chancery errors would replicate into an X.500 environment, on the contrary that is name confusion engineered into DNS to profit from user name confusion. The classic example is whitehouse.com Registrars offer similar names at a discount bundle price for this reason, it is a business model. At the same time they sell certificates. They blind the ownership in WHOISbecause frankly one gets horribly spammed when one uses WHOIS the way it was intended in the original DDN-NIC version of the 1980s. So the Internet needs to have a viable trust framework and one already exists under c=US, using X.500. which feeds the various trust frameworks that don’t entirely trust the Internet. CT is one of those technologies that benefits the Internet directly, but the business model is based on these separate organizations which the CA interact with, the selling proposition to them is that the BR are BS. You need my dear customer a trust framework that uniquely represents you as a member of the Carpenters Union so your unique woodworking skills are fairly representated. As opposed to anyone who can set up shop as Stripe Carpenters with a business registration. That allows for the enterprise certificates and directories as a market, the government and military who to some extent use the commercial CA, but also do not, and thus gain the advantages of cross certification using X.500 at the Federal Bridge between these major siloed trust frameworks. The DN is inherently unique. The Internet enterprise OID is something else. If geography has anything to do with this, then it’s possible to extend c=US to have semantic meaning. According to the last extant analysis done. The US government can’t solely be c=US, that’s a common namespace confusion. They are at an Organization level. However there are two OID paths in that regard. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
On the value of EV
I think this is fundamentally an issue of the history of the DNS and X.500 architecture. Combined with social factors since 1996 when the original NSF Directory and DNS grant money ran out, and domains (which had been free) became this wild west name space, which has reached some predictable level of insecurity. Inevitably the classic solutions are brought out and rejected. I think the rapid growth of the Internet has been achieved in terms of IP over everything, but security is always going to be a work in progress. People who understand X.509 versions understand that the original version was highly integrated with the Directory, which provides its own level of assurance. It was also stifling. However we are seeing a renewed interest in directory variants around the issue of lowering US healthcare processing overhead. Using the Internet has been on the agenda since 2004. There’s a long thread here dating back to the 1980’s regarding naming, resulting in the fields that are eventually defined in RFC 5280. The ANSI registration component is permanent and perpetual. Like most elements of the Internet that remain insecure, it’s a matter of ubiquitous access (domains are cheap, it costs more money to validate a business or organization, so the less secure solution is adopted) or other solutions like pinning are tried. I would be open to partnering with Mozilla and doing this using X.500, but the ANSI name and OID fee is high. Which is the case also with NIST LOA 3 certificates. I’m certainly open to any ideas to make this work. Right now there is a governance gap of a organization equivalent to ICANN that is addressed by various industry organizations that do well known certificate cross certification at the Federal Bridge and European trust anchors. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Francisco Partners acquires Comodo certificate authority business
On Tuesday, October 31, 2017 at 9:22:09 AM UTC-4, Kyle Hamilton wrote: > http://www.eweek.com/security/francisco-partners-acquires-comodo-s-certificate-authority-business I did a little spot check. So yes they hired a person who was involved with Entrust, so that is a plus. The website says it is an IP carve out. OK. Does this translate into knowledge so a consumer can make a rational trust decision? I looked at their most recent CPS while shopping for a client email certificate. 3.2.7.1. Personal Secure Email Certificate The only identifying information in the subject DN is the email address of t he Subscriber. Comodo validates the right for the Applicant to use the submitted email address. This is achieved through the delivery via a challenge and response made to the email address submitted during the Certificate application. Comodo validates that the Applicant holds the private key corresponding with a public key to be included in the Certificate by utilizing an online enrollment process whereby Comodo facilitates the Subscriber generating its key pair using a specially crafted web page. The key pair is generated in the Subscriber’s computer. The private key is not exported or transferred from the Subscriber’s computer as part of the application process. This was previously "Free" and now is billed at $12, but no matter. I clicked on the chat window and spoke to a technical support rep. I asked what NIST Level of Assurance was the S/MIME certificate, after about 10 minutes I got the answer, which was LOA 3. So as a consumer I was just told I could get a NIST LOA 3 S/MIME client and signing certificate for $12, that according to the website also would be trusted by Mozilla, etc. Of course I know that's not possible, and we can't always expect random support people to give the right answer. So what is the value add here from Francisco Partners, other than the previously "Free" certificate is now $12 and claimed to be at LOA 3? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response L
I probably need some additional information to see if my partners can effectively share PHI at LOA 3 and I don't want to burden the list on whether the healthcare use cases defined by the Federal Health Architecture is covered by ACES 2017 Jan policy. It's very important that the community agreed on LOA 3 for healthcare providers and LOA 2 for patients. It's not an issue about validating to domain names. That's what I meant about separating Internet from USperson citizen use cases. This goes back to 2004 when enabling legislation was created to apply the Internet to Healthcare and create secure services to exchange information. Eventually, years later the FHA set down with Direct Project certificate requirements, however the two models are different in that one is based on a end user STA, and a different model that uses a MITM intentionally that requires a different trust layer under HIPAA called a business associate agreement. The LOA3 Direct STA to STA does not require an additional trust framework beyond the Federal Bridge. Typically the bridge only deals with cross certification of CAs. So to meet the requirements the individual user certificate needs to use a root that can chain through the bridge and have a separate signing and encryption certificate. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response L
That very useful visualization can seen in Chrome and validates against the Identrust ACES 2 root. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response L
The 2017 ACES CP excluding anything other than citizen to E-gov breaks certain use cases that are outside the scope of Mozilla, but not from the standpoint of a fully functional commercial c=US structure which I have developed since 1996 since I reached an agreement with GSA on how to proceed after managing the c=US pilot and implementing X.509 for the National Labs in the Directory. Specifically it blocks the development of a functional national patient and provider Directory structure in which relying parties require fully valid cross certified trust chains that was already developed with HHS. Invalid patient identity is at the heart of one of the leading causes of mortality in the US. Not reaching consensus on equipping end users with low cost affordable PKI in addition to browser security policy puts profit over human rights. The only rational reason I can see for such a policy is to MITM at will medical records under the 702 Authorities, since end user implementation of PKI based tecnology in an end to end manner precludes business level meddling and trust, replaced by the original Diffie concept. As we know this is already the policy of the IETF and IAB to encrypt everything. But the policy mapping between these different use cases is perhaps overly complex and certainly not user friendly. Also the Blue Button MU2 used ACES in their trust bundle at one point and I checked yesterday for medical providers that already attested to MU2 SMTP/SMIME compliance and received Federal money under the recovery stimulus package and that's not limited to just the VA but the VA has used this very effectively. Browsers of course don't typically implement bi-directional TLS authenticating the client which is very useful in use cases related to maintaining data integrity in disaster situations for logging. i checked the Identrust site and their ACES CP had poor user documentation with CP dated 2015. That's when I subsequently found your information which was up to date and very useful. I see that the only remaining bug issue was to drop the cross certificate so that Mozilla users could not incorrectly validate, ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response L
Since we use ACES certificates for sending healthcare information in a way that mimimizes MITM, I was surprised to read the following. "The Federal PKI has cross-certified other agencies and commercial CAs, which means their certificates will be trusted by clients that trust the Federal PKI. However, none of these roots are publicly trusted. Even when a publicly trusted commercial CA is cross-certified with the Federal PKI, they maintain complete separation between their publicly trusted certificates and their Federal PKI cross-certified certificates. As a result, there is not currently a viable way to obtain an individual certificate for use in TLS/HTTPS that is issued or trusted by the Federal PKI, and also trusted by the general public." Source CIO Council The new ACES CP dated Jan 17 2017 does not assure public use of the ACES root. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
