There is definitely a great deal of interest in PKCS7 support. Previously we've had to wait while we worked on X509 but now that we have a reasonable implementation of that we can talk more about PKCS7. If you'd like to take a stab at an API proposal to start just file an issue with it and we can start discussing there!
-Paul (reaperhulk) > On Oct 14, 2015, at 8:46 PM, Micah Baker <hacim.re...@gmail.com> wrote: > > Hi Paul, > > I already have the ASN.1 dotted notation values and just need a way to sign > the PKCS7 EnvelopedData with those OIDs. I think you are correct in that what > I need here is a way to build and sign arbitrary PKCS7 structures since SCEP > does some nesting. The diagram on Page 14/15 of the IETF draft for SCEP is a > helpful way to visualize it: > https://tools.ietf.org/html/draft-gutmann-scep-01#page-15 > > Would this be something the community is interested in? > > Thanks, > > Micah > >> On Oct 5, 2015, at 7:32 AM, Paul Kehrer <paul.l.keh...@gmail.com> wrote: >> >> It has been a long time since I looked at SCEP, but it looks like it >> requires PKCS7 SignedData/EnvelopedData structures? Cryptography can't >> generate arbitrary ASN.1 so you'd need to generate it outside of >> cryptography (using something like pyasn1 or >> https://github.com/wbond/asn1crypto) and then sign it using cryptography >> (which may or may not be possible with the currently exposed primitives -- I >> didn't dig into how SCEP does the SignedData). >> >> I suspect what you need here is a PKCS7 implementation in cryptography, >> since that would hypothetically allow you to build/sign arbitrary PKCS7 >> structures, but maybe I'm misunderstanding the problem and it's simpler than >> that. >> >> -Paul >>> On October 4, 2015 at 7:03:53 PM, Micah Baker (hacim.re...@gmail.com) wrote: >>> >>> Hi Paul, >>> >>> SCEP requires a senderNonce and transactionID to be returned to the client >>> requesting the certificate. Those two values are included in the signed >>> message the client sends to the server, and then the server must take the >>> two values and include them in the response to the client or the client is >>> supposed to reject the response. This is not just adding an OID for a >>> capability, it’s also adding a value to the OID which must be included in >>> the signed response. Does x509.ObjectIdentifier allow something to the >>> effect of 1.2.3.4=some random bytes or text? >>> >>> Thanks, >>> >>> Micah >>> >>>> On Oct 4, 2015, at 4:59 PM, Paul Kehrer <paul.l.keh...@gmail.com> wrote: >>>> >>>> Micah, >>>> >>>> You can define any OID you want just by passing a string of the dotted >>>> value of the OID to the constructor of x509.ObjectIdentifier. You won't >>>> get the human readable name, but that's not a big deal. However, that >>>> class is really just a convenience and doesn't have any behavior so I'm >>>> not sure what benefit it would be to you when implementing SCEP. Could you >>>> elaborate a bit on what you're trying to do? >>>> >>>> >>>> -Paul (reaperhulk) >>>> >>>>> On October 4, 2015 at 6:33:57 PM, Micah Baker (hacim.re...@gmail.com) >>>>> wrote: >>>>> >>>>> I’m attempting to build a SCEP server using cryptography and don’t see a >>>>> way to add OIDs not already defined by the module. If it is not possible >>>>> to use other real OIDs, can we add the half-dozen SCEP OIDs to >>>>> cryptography? The OIDs can be found here: >>>>> https://tools.ietf.org/html/draft-gutmann-scep-01#page-17. If someone is >>>>> willing to give me some pointers I could try to write a patch for this, >>>>> assuming it’s just a table of supported OIDs somewhere. >>>>> _______________________________________________ >>>>> Cryptography-dev mailing list >>>>> Cryptography-dev@python.org >>>>> https://mail.python.org/mailman/listinfo/cryptography-dev >
_______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
