[Openid-specs-ab] Fwd: ab

John Bradley jbradley at mac.com
Wed Apr 28 14:06:02 UTC 2010


Nat,


For signatures we need RSA (2048 or 3072) with a SHA256 hash and (PKCS #1 v1.5 or PSS) padding.

The older signatures are deprecated by NIST as of 12/31/2010. That applies to keysizes < 2048 and the SHA1 hash Algorithm.

PSS padding is preferred but not required.

There is a requirement that the RSA exponent be greater then 65,537.   That however is part of the certificate being used so I think we can leave that to profiles to specify.


For symmetric  encryption Triple DES - CBC is supported but AES-128 CBC is preferred.


My preference is to just make AES-128 CBC the mandatory to implement algorithm and default.
http://www.w3.org/2001/04/xmlenc#aes128-cbc

There are pure PHP and other implementations
http://www.phpaes.com/

So I think we can keep it simple:)

All signing is RSA SHA256 with PKCS #1 v1.5 padding (RSA-SHA256)
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256


The default encryption is AES-128 CBC with RSA Key Transport

http://www.w3.org/2001/04/xmlenc#aes128-cbc
http://www.w3.org/2001/04/xmlenc#rsa-1_5

The reality is that most implementations will not use this, and the ones that will are going to require meeting NIST standards.
So supporting the older algorithms just adds complexity.

There may be jurisdictional requirements by jurisdiction eg France
http://www.opengroup.org/security/meetings/apr98/french-regulation.pdf

I think we are probably OK for authentication but if they consider this for confidentiality then we need to support a weaker encryption for French RP.

I am personally OK with not doing that, and letting the French Gov try and stop the RP from using the default.

In 7.4 we could add a 
openid.enc_alg Value: (optional) The RP's preferred symmetric encryption algorithm.  The value is a URL from http://www.w3.org/2001/04/xmlenc


That way if a RP and OP wanted to use AES-256 for some top secret thing they could.
Or we could just list the three AES URI in the spec directly.


The other thing we should consider is leveraging the IETF CMS support already in openSSL.

One command could take a openID response and sign/encrypt and base64encode the message.

With the reverse on the other end.

S/Mime is based on CMS 
http://www.openssl.org/docs/apps/cms.html

http://www.faqs.org/rfcs/rfc3852.html

CMS is way more sophisticated than we need but it allready exists.

The less people need to think about the crypto the happier they will be.

John B.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20100428/42d22b9d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20100428/42d22b9d/attachment.bin>


More information about the Openid-specs-ab mailing list