[Cryptography-dev] SCEP OID support

[Paul Kehrer]

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.rekab at 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.kehrer at 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.rekab at 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.kehrer at 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.rekab at 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 at python.org 
>>>>> https://mail.python.org/mailman/listinfo/cryptography-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20151014/9def0160/attachment.html>