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 <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 > <mailto: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 > <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 > <mailto: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 >>> <mailto: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 >>> <mailto: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 >>>> <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 <mailto:Cryptography-dev@python.org> >>>> https://mail.python.org/mailman/listinfo/cryptography-dev >>>> <https://mail.python.org/mailman/listinfo/cryptography-dev>
_______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
