On 14/02/2017 18:14, Nick Lamb wrote:
On Tuesday, 14 February 2017 13:47:51 UTC, Steve Medin wrote:
- PKCS#7 chains are indeed not a requirement, but see point 1. It’s
probably no coincidence that IIS supports it given awareness of the demands
placed on enterprise IT admins.
I don't see how PKCS#7 offers any advantage at all.
I end up helping lots of ordinary people with certificate installation (on
things which are more or less web servers, and other things), which today
mostly means Let's Encrypt because even though Let's Encrypt focuses on
automation that $0 price point is very attractive without the automation when
you've got no idea what you're doing.
Not once have I thought "This would be easier with PKCS#7". Literally I've
never even had to walk a user through how to make a PKCS#7 file, because it never comes
up. In addition to PEM they've needed JKS and PKCS#12 and ZIP files but never PKCS#7.
When it comes to installation, the main problem is usually the awful UX in the GUI they're trying to use.
Invalid inputs are often swallowed with no visible commentary or result, let alone helpful error messages;
the system may expect them to wait for a lengthy restart or reboot before their changes take effect; and
nomenclature is arbitrary, one program's "CA Cert" is another's "Chain File" and yet
another's "Intermediate Certificates".
I would pressure server vendors to clean this up, except that really in most
cases what they actually need to do is embrace at least one of the automation
options and bake that into their software instead. We didn't make the safety
elevator easier to use by affixing a great many wordy instruction panels about
the correct means of closing the doors and sequence of operation for the
motors, we just made the machine smarter so that all the humans do is press a
floor button and try to avoid eye-contact with strangers. As a result even an
illiterate child can confidently operate such an elevator once they can reach
the buttons. Nobody would purchase an old-style manual elevator today even if
it were available a little cheaper from a major manufacturer, it's just not
worth the hassle.
Unfortunately, for these not-quite-web-server things (printers, routers
etc.), automating use of the current ACME Let's encrypt protocol with
or without hardcoding the Let's Encrypt URL is a non-starter for anyone
using these things in a more secure network and/or beyond the firmware
renewal availability from the vendor.
On a simple network where public certs are acceptable, such devices
will often need to get renewed certificates long past the availability
of upstream firmware updates to adapt to ecosystem changes (such as
Let's Encrypt switching to an incompatible ACME version in the year
2026 or WoSign free certs becoming a thing of the past in 2016).
On a secure network, existence and address of each such device should
not be revealed to an outside entity (such as Let's encrypt admins),
let alone anyone who knows how to read CT logs. For such devices I
generally use an in-house CA which is trusted only in-house and uses
the validation procedure "The subject is known personally to the CA
admin and the transport of the CSR and cert have been secured by
out-of-band means"
Thus the ability to install certificates and keys in a standard format
such as PKCS#12 or PEM is much more important than the ability to talk
to a public service such as Let's Encrypt/ACME or WoSign.
Similarly, it would be useful to have an easily findable tool/script
for doing ACME in a semi-offline way that doesn't presume that the ACME
client has any kind of direct control over the servers that will be
configured with the certificates. Such a tool could be installed once
by a site and then used to generate certs for the various "web-managed"
devices that need them.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
