On Tue, 2016-03-01 at 17:09 +0000, David Woodhouse wrote: > I have a promising GSoC candidate who is interested in working on bug > 1162897 (RFC7512 URI support¹), and potentially also on bug 248722 > (honour the system-wide configuration for PKCs#11 modules, when it > exists²). > > I am more than happy to co-mentor, but I think it *really* needs a > proper NSS developer to be the primary mentor. Could I interest > anyone in helping out, please?
Thanks Bob for volunteering! PROJECT PROPOSAL ================ So... first we need to add it to the wiki at https://wiki.mozilla.org/index.php?title=Community:SummerOfCode16:Brainstorming I went through the process of applying for a wiki account a few days ago, but haven't seen anything yet. If someone could add it, that'd be much appreciated. Here's a draft of what it would look like, even: | Implement RFC7512 PKCS#11 URI support and system integration | [https://tools.ietf.org/html/rfc7512 RFC7512] defines a URI standard for identifying PKCs#11 tokens and the objects therein. We need to implement a PK11_FindCertByURI() or similar function, and also make it possible to obtain/generate the URI for a given CERT and other objects which have been found/selected by other means. See [https://bugzilla.mozilla.org/show_bug.cgi?id=1162897 bug 1162897] for details. Also, NSS does not obey the system configuration for which PKCS#11 tokens to load, as described in [https://bugzilla.mozilla.org/show_bug. cgi?id=248722 bug 248722]. We should fix this too. | C coding, familiarity with PKCS#11 preferable | dwmw2 | rrelyea,dwmw2 CANDIDATE PREPARATION ===================== GSoC candidates are supposed to get familiar with the code and submit a bug fix during the application period, so I have (filed and) suggested https://bugzilla.mozilla.org/show_bug.cgi?id=1253211 — it should be a relatively simple job to fix NSSTrustDomain_TraverseCertificates() *not* to take O(n²) time by using a hash table or something similar, and seems ideal as a way to get familiar with precisely the code that needs to be worked on. (Fixing it so that it applies filters (such as matching the email address) *before* building up the list of results and spending time de-duplicating them, might involve API changes and might be best left for a later date.) PROJECT BACKGROUND ================== For the project itself, I've been working with Varun on IRC to get him up to speed. I figured it was worth doing that in email for posterity, to allow others to "play along", and to solicit constructive feedback. I started by referring to some online documentation to understand the expectation of how things "should work". Which is basically expressed in the Fedora packaging guidelines as three points: • Packages which use SSL certificates/keys from a file or elsewhere SHOULD also support using certs/keys from PKCS#11 tokens. • Where PKCS#11 objects are specified in a textual form which is visible to the user (e.g. on the command line or in a config file), objects SHOULD be specified in the form of a PKCS#11 URI as as described in RFC7512. • Packages which can use PKCS#11 tokens SHOULD automatically use the tokens which are present in the system's p11-kit configuration, rather than needing to have a PKCS#11 provider explicitly specified. (From https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling ) Fedora also has some documentation for packagers to help them establish whether their package conforms to these guidelines: https://fedoraproject.org/wiki/PackageMaintainers/PKCS11 Obviously this isn't at all a Fedora-specific thing. The RFC7512 URI format is applicable everywhere, and p11-kit provides a "system configuration" for which PKCS#11 modules to load on fairly much *all* Linux systems, and many non-Linux systems. But Fedora has documentation and sets clear expectations for packagers. There's also http://www.infradead.org/openconnect/pkcs11.html which is targeted at users who just want to find the URI of the token/cert they need to use, and then use it. PROJECT PLAN ============ Here's where I'm transitioning from the overview of the system integration, to the specifics of how to implement it in NSS, and would really appreciate feedback. I've suggested that a reasonable target for completion would probably be to fix the cURL bug filed at https://bugzilla.redhat.com/1219544 (although again, this is *not* Fedora or Red Hat specific). As we're looking at two independent bugs, I suggested to work around the first (#248722) purely by adding p11-kit-proxy.so to the NSS database in ~/.pki/nssdb to start with: $ modutil -dbdir sql:`pwd` -add p11-kit-proxy -libfile /usr/lib64/p11-kit-proxy.so Now we can focus on URI support. I'd start by adding new functions like PK11_FindCertsFromUri(), PK11_FindSlotByUri(), and the various other parallel functions for other objects. This basically resolves the system integration and behaviour problem, as long as applications are updated to use the new APIs. However, a *complete* implementation in NSS also needs to give applications a way to obtain the URI of a given object. Which would mean adding new methods such as CERT_GetPkcs11Uri(), perhaps adding a new field containing the URI to the PK11SlotInfo structure, etc. Once that's all done, then I'd suggest we look at the system integration (loading the right modules) as a second stage. As noted, using p11-kit-proxy.so is a cheap trick which kind of makes that work. But *ideally* we'd actually coordinate the NSS-loaded modules properly with the p11-kit-loaded modules — one of the explicit goals of p11-kit is to handle the coordination when the same PKCS#11 token is loaded from *multiple* places within an application (e.g. different crypto libraries in different loadable plugins). So we should probably do better. And it's already been suggested in bug 1162897] that we should link directly to libp11-kit for its URI support, rather than reinventing the wheel... Anyway, the details of that part can come later, I suspect. There's enough here for Varun to be digesting... -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
