On Thu, 2016-09-08 at 13:44 +0000, Salz, Rich wrote: > I would suggest the LAMPS WG (https://datatracker.ietf.org/wg/lamps/c > harter/), which is the closest thing to PKIX these days, and perhaps > cross-post to the SAAG mailing list the general catch-all for > security area https://trac.tools.ietf.org/area/sec/trac/wiki.
I sent this to both lists; thanks again. It doesn't seem to have made it to either list yet, but hopefully it will shortly. -- dwmw2
--- Begin Message ---(I hope the cross-post is acceptable; apologies if not.) Various applications will optionally make use of X.509 certificates for client authentication. Those certificates, and the associated private keys, may be found in files on the file system, in PKCS#11 tokens, or in another OS-specific form of certificate database. In my opinion, it would be nice to have some consistency between applications. If a user has a certificate in a certain form, it would be nice for that to Just Work™ across all well-behaved applications. In practice, nothing could be further from the truth. Applications *all* suck, and various certificates will spuriously fail to work in one application but not another. Or work if the application is build against crypto library $A but not when built against crypto library $B. Or for objects in PKCS#11 each application might require a *different* identifier string to locate the same object. If they support PKCS#11 at all. I'd like to fix that. I would like to achieve a consensus that a "well- behaved application" SHOULD accept certificates and keys in various (TBD) file formats and also accept PKCS#11 URIs according to RFC7512. I have slowly been working on this. I have encouraged the Fedora distribution of Linux to amend their packaging guidelines to state that software packaged for Fedora SHOULD accept a PKCS#11 URI wherever it would accept a filename. And that software SHOULD load the PKCS#11 tokens which are indicated by the system configuration. We have already fixed various applications to comply with these requirements, and I even mentored a Google Summer of Code project which added RFC7512 support to NSS². I believe the Fedora packaging guidelines have been a success, and I would like to expand the scope. There's no *reason* this should be Fedora-specific, or even specific to Linux or POSIX operating systems. So I'm looking for a forum in which to reach a consensus on what should be accepted, and to publish those guidelines. I'd be very interested in hearing suggestions. Simultaneously, I'm also looking at expanding the technical scope. For my own project, the OpenConnect VPN client, I have started to collect a torture test suite³ of RSA, DSA and EC keys in various PKCS#1, PKCS#8 and PKCS#12 forms — both unencrypted, and encrypted with various algorithms. I have yet to embark of the joy of files with non- ASCII passphrases, especially in non-UTF8 locales — but I have a bottle of vodka ready to help me do so. My test suite also includes PKCS#11 tests including private keys where the token doesn't expose the public component (which made OpenSSL crash until yesterday, yay!) and certificates with the CKA_PRIVATE attribute set, so some software will fail to *find* them. I am thinking of splitting my torture test out from OpenConnect itself, and making it available as a project in its own right. I can, of course, lobby to expand the Fedora guidelines to state that all software packaged for Fedora SHOULD pass the torture test suite, but I think it makes sense to aim for a wider consensus than that. Opinions welcome... does it make sense to attempt to publish an informational RFC outlining such "expectations"? Or should it take some other form? Or should I just not bother, and continue to push it from the Fedora angle, since it's getting into a lot of upstream software already? I also expect some heckling at my specific test cases — do we *really* expect everyone to support DSA keys still? And PEM files encrypted the old OpenSSL way? And PKCS#12 files encrypted with MD5-DES? (I can accept 'no' answers to the latter two only if expressed in a form which lets me file bugs against ancient "enterprise" software to stop *creating* them that way...) -- dwmw2 ¹ https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling ² https://bugzil.la/1162897 ³ http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
