I’ve used free certificates for Open Source projects from both CAcert and StartCom. I’ve also gotten them commercially from some of the expected players.
Will Let’s Encrypt honor reasonable bits in the CSR for Free/Open Source projects? And will it refrain from adding extraneous bits to the end entity certificate (or make some of them optional)?
I understand that some of this is governed by CPS’es, so I guess what I am asking/hoping is the CPS flexible enough to meet reasonable requests from free and open source projects. Below is an example using the real life problems I have experienced in the past. I hope the CPS and Issuing Policies are flexible enough to handle it.
Imagine Example Project is a free and open source project, hosted at example.com, looking for a low cost/no cost certificate. It has one box hosting multiple services, including a web server, SVN or Git server, FTP server and wiki.
The project makes downloads available. Secrecy is not required, but authenticity/integrity is required because the project does not sign its release with a PGP-like key. Hashes of the downloads are published in independent channels, which avoids nearly all the key management problems for the signer, many of the verification problems for those verifying signatures, and the PGP-like key distribution problems.
The project does no utilize email addresses per se, like john.doe@example.com or jane.doe@example.com. Rather, emails to well known addresses webmaster@, hostmaster@ and security@ pass through a spam filter/smart host and are sent to the project contributors in a distribution-list like fashion. This allows emails to be received for things like domain validation and security notices.
Domain validation should occur through a well known address, like those published in RFC 2142, MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS, http://www.ietf.org/rfc/rfc2142.txt. Well known names include POSTMASTER@, HOSTMASTER@, WEBMASTER@, NOC@ and SECURITY@.
Optionally, it might be helpful to allow domain control to be validated through the administrative and technical contacts in the WHOIS database. The administrative and technical contacts are appealing because its a contractual requirement that’s been around since the 1990s.
Browsers appear to have an aversion to DNS, but there’s no getting around DNS since the email used in domain validation is based upon it.
As a matter of policy, maybe the email trail should include a CC to NOC@ and SECURITY@ since the notification of a PKIX or CA/B issued certificate is the sort of thing they exist for.
The CN should be a friendly name, like “Example Project”. It should be a friendly name because (1) its usually displayed to the user, and (2) use of a domain name or DNS names in the CN is deprecated by both the IETF and CA/B Forums. Domain name and DNS names go in the SAN.
The SAN should include the following five DNS names:
- example.com
- www.example.com
- ftp.example.com
- wiki.example.com
- {svn|git}.example.com
Deprecation of domain names and DNS names in the CN (and presence in the SAN) is codified by both the IETF and the CA/B Forums. The IETF deprecated the practice in RFC 6125, Section 6.4.4. The CA/Browser Forum deprecated the practice in Baseline Requirements (BR) Section 9.2.2 Subject Common Name Field.
When I see a certificate with a domain name or DNS name in the CN, then I consider it a defective certificate. As far as I am concerned, it does not meet the industry’s own standards. That folks have accepted the broken certificates for so long speaks to how the industry suffered a Race to the Bottom (http://en.wikipedia.org/wiki/Race_to_the_bottom) in services and created a Market for Lemons (http://en.wikipedia.org/wiki/The_Market_for_Lemons) among buyers.
Please ensure Let’s Encrypt issuing policies have room for the industry’s own standards.
The Example Project only exists in cyberspace; and it does not have a brick and mortar street address. Some entities or organizations may have a street address, but not all of them do.
Please ensure Let’s Encrypt issuing policies for domain validated end entity certificates have room for cyberspace-only entities that don’t exist in the real world.
Let’s Encrypt should accept an EC key over a well known curve, like NIST’s P-256, P-384 or P-521. As soon as OIDs are available for Bernstein’s gear, ed25519 (and friends) support would be greatly appreciated, too.
In the past, its been difficult to find CAs who even accepted an EC key and issued an EC-based certificate.
Example Project is a free software project, and the only thing it really protects are the free downloads it offers (both source code and ZIP/TAR files). The certificate provides authenticity and inhibits tampering in transit.
The Key Usage (KU) must include Digital Signature and should include Key Encipherment, if requested. Key Encipherment should be optional, and Key Agreement should not be present. The project can use Key Encipherment because it does not need forward secrecy. There’s no need for key Agreement because there are no Diffie-Hellman parameters.
Let those who want Key Encipherment opt-in, or those who don’t want it opt-out. In the past, I even had a CA add Key Agreement even though we provided a RSA key!
This is basic security engineering and existing practices violate Secure Design principals. The seminal paper is Saltzer and Schroeder’s “The Protection of Information in Computer Systems” (http://web.mit.edu/Saltzer/www/publications/protection/). Its been around 40 years or so…
Its also another example of the Lemon Market the industry has created.
Example Project’s server does not authenticate itself as a client. The certificate is for server authentication only.
id-kp-serverAuth is OK, but please don’t automatically add id-kp-clientAuth or other unneeded or un-requested bits. If desired, make it optional so I can opt-out of it. Better, make folks who want it opt-in.
This is basic security engineering and existing practices violate Secure Design principals. The seminal paper is Saltzer and Schroeder’s “The Protection of Information in Computer Systems” (http://web.mit.edu/Saltzer/www/publications/protection/). Its been around 40 years or so…
Its also another example of the Lemon Market the industry has created.
I recently saw a certificate where both Microsoft Server Gated Crypto and Netscape Server Gated Crypto were added. Please don’t add Server Gated Crypto bits.
In our case, we would rather fail the connection based on principal rather than promulgating that cursed crypto.
Others may want it or need it due to local restrictions, so maybe it should be an opt-in feature.
In general, its also another example of the Lemon Market the industry has created.
The Example Project provides a PKCS7 email attribute in its CSR. Please don’t remove it or place it in the CN. Removing it means we are not being good netizens, and those who have a legitimate need to contact the administrative or technical party responsible cannot easily do so. Its also worth noting we handle spam with other technical controls, and not by hiding email addresses.
The CN is for friendly names that are displayed to the user by the user’s software, so it should not be polluted with a CA’s arbitrary mashup. like random numbers concatenated to emails addresses.
Its also another example of the Lemon Market the industry has created.
This probably applies more to the IdenTrust [intermediate] CA used for cross-signing (Frequently Asked Questions (FAQ)). Please don’t lump Domain Validated and Organizational Validated certificates under the same intermediate CA because there’s no way for relying parties to tell them apart. That is, as a user, I can’t tell when the CSR was vetted by an independent 3rd party auditor (the customary RA), or if its one of those OV’s where the independent 3rd party auditor was eschewed/abandoned and the person or organization making the request is the same one vetting and approving the request (no effective RA, and the requestor becomes the issuer).
So it would be nice (and even good planning) if Let’s Encrypt ensured a pristine intermediate CA from IdenTrust is present in the path building exercise. Its good planning because we’ve already seen this failures in practice. I believe the most recent was the MSC Holdings and CNNIC.
On the downside, its not always clear what actions browsers and other user agents will take in response to an incident. For example, CNICC got punished for its subordinate, while Trustwave got off scot-free. A transgression by IdenTrust may result in no action, or it may result in the eventual disgorging of IdenTrust from trust stores. If its the latter, then a pristine intermediate may provide the necessary stopgap needed during an emergency migration.
This is also another example of the Lemon Market the industry has created. But its not readily apparent to most, and the backside risks are often over looked.
Don’t tailor to browsers too much. They only make up a percentage of user agents, and their security model has gaps so large at times that it makes me wonder how/why users and organizations accept the risks.
There are security models worse than the one used by browsers, like Opportunistic Encryption used in SMTP by MTAs. They may be using Let’s Encrypt certificates, too.
There are some security models better than that used by browsers, and those particular applications may be using Let’s Encrypt certificates, too.
