> On 14 Dec 2017, at 12:38, Paul Kehrer <paul.l.keh...@gmail.com> wrote: > > We discussed this in the past > (https://github.com/pyca/cryptography/issues/1506 > <https://github.com/pyca/cryptography/issues/1506>) but now that we're > dropping explicit backends the proposed solutions in that issue don't really > apply. > > Probably the easiest path is just to sign your certificate with a dummy key > and then call `tbs_certificate_bytes` on the resulting certificate. Those > bytes can then be signed by your real key to construct the certificate and > then you can construct/load the resulting bytes as a cryptography object. > This avoids any private API calls, but is not particularly elegant. > > If you want to create your own backend then you should be able to get the > bytes you need via i2d_re_X509_tbs rather than needing ASN1_item_i2d directly > bound. Be aware that since we're deprecating this backend concept (at least > as a thing that users pass as an argument) this might be a bit tricky to > maintain in the long term.
Many thanks! I’ll play around some with both of those, and see if I can make something fly. > We've been discussing whether it makes sense to build a hazmat x509 layer (to > allow construction of a variety of various ASN.1 structures that violate RFCs > but are nonetheless seen in the wild) -- maybe giving access to the > tbs_certificate_bytes prior to signing makes sense there. In that case the > hazmat cert builder would provide tbs bytes that can be signed via <other > method> and then maybe we'd also include a hazmat method for constructing the > final cert from tbs + signature? Sounds like a fairly clean solution to me. It’d probably require more work, but an (arguably more pythonic) way could perhaps be to support various protocols, so you could pass in “something” that implemented an RSA signing protocol, and then have create_x509_certificate and similar just call that for the signature step. It’s tempting in one way, but at the same time, it might require quite a bit more work, not being able to do that with the OpenSSL helpers that are currently available. As for constructing things that violate RFCs, at least to me, that’s one of the major reasons why tools like these are interesting. Being able to directly make whatever it is you need, makes it so much more easy to go about testing or verifying things, running quick trials for proof of concepts, and so on. As a use case example, it’s been said that Apple doesn’t support NameConstraints. If you were to test that, making a constrained CA sign two certs (one “legal”, and the other violating the name constraint) would be pretty easy to throw together using pyca/cryptography, while a more proper CA platform should preferably prohibit you from doing that at all. Same applies to cloning mistakes that are happening in the wild to test your own systems against that particular weirdness, and so on. Many thanks again! Terje
_______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
