On 2010-06-17 05:58 PDT, John Dennis wrote: > I'm in the process of adding CSR support to the NSS python binding and > I'm not sure I fully follow how CSR attributes are handled so I'm looking > for some clarification.
Look at how certutil does it. That's best example we have right now. > From reading the relevant RFC's my understanding is that a CSR contains a > sequence of attributes and an attribute has a type (OID) and a set of > values matching that OID type. Yes. > One possible attribute type is a PKCS #9 Extension Request, but their > could be other attribute types as well, right? In theory, there could be. It's extensible. I'm not aware of any formally published attribute types except PKCS#9 however. And to the best of my recollection, in all the years that we've offered this capability, no one has ever requested any attributes other than certificate extensions. > What's confusing me that the NSS API (as well as the implementation) > seems to assume the *only* attribute type in a CSR will be a PKCS #9 > Extension Request (i.e. a set of cert extensions). Yeah, but until some other attribute type comes along and is published in an RFC, and there arises some demand for it, I'd say that the "limitations" of the existing API are academic limitations, at worst. As far as the present API being *THE* (only) NSS API for adding extensions to a cert, it's not really exclusive of others. First, I assume you're writing about functions CERT_StartCertificateRequestAttributes and CERT_FinishCertificateRequestAttributes, and I'll grant that those functions make the assumptions to which you refer. That's largely the result of a number of historic errors (some of which go back 12 years or more) and a decision I made a few years ago to try to make the code work with minimal incision surgery. I would not say that the present API precludes the addition of other types of attributes, but only that it does not facilitate them. Perhaps a new function is needed to add other types of attribute. But no one has asked for such a beast yet, and the NSS team doesn't have resources to invest in unwanted enhancements at this time. > Am I missing something? What about the other possible CSR attributes? Name two that are used by any CA in Mozilla's trusted CA list. > Or in practice are they never used? Or am I being lame and just not > finding the code in NSS which deals with CSR attribute other than cert > extensions? Or do I just not understand the RFC definition of a CSR? If there exist an ample body of well defined other types of ATTRIBUTEs besides PKCS#9 cert extensions, and if there exists anyone who wants them, then this might be viewed as a deficiency in NSS. Otherwise, the lack of support for non-existent and/or unused attribute types can be viewed as simple pragmatism, market economics at work. NSS isn't trying to be a reference implementation for everything ever defined in any paper or standard under the sun. It's trying to be a good implementation of the features that actually bring real security and for which real world demand exists. Real world demand doesn't mean that it's on somebody's personal wish list. The NSS team is not the personal slave to everyone with a whim for some new crypto feature. It's demand that brings with it new or expanded market opportunities. It's demand that creates a reason for a developer to spend the manpower (or part of his lifetime) to develop the feature. But if you personally experience such demand and are willing to develop the enhancements to NSS, NSS is receptive to new contributions. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
