[OpenID] My 2 Cents to the OpenID foundation

John Bradley john.bradley at wingaa.com
Wed Apr 8 06:45:01 UTC 2009

Yes that might be possible once we have AX 2.0 but at the moment there  
is only one signature for the message optionally including the AX  

One possible thing an OP could do if it really wanted to prevent  
tampering, is return the assertion with a private association handle  
signed by a HMAC-SHA256 or better MAC.  The RP would then use a direct  
request to the OP to verify the signature(Secd 11.4.2)

That way for sensitive information you could sign the entire assertion  
with a more tamper resistant signature.

That is one way it could be done without the RP having to support HMAC- 
SHA256 itself.

I honestly think we need to worry more about MTM attacks sniffing  
attributes because they are unencrypted.

I do think that eventually someone will come up with a way to exploit  
the fact that you can add almost unlimited payload to a response to  
generate a signature collision with HMAC-SHA1.  Fortunately they will  
probably go after far more lucrative targets than openID giving   
people time to upgrade to HMAC-SHA256 signatures.  But I could be  
wrong about that:)

Perhaps RPs using HMAC-SHA1 should test for suspicious payloads like  
the CAs are now doing with Certificate Signing Requests after the MD5  
issue?  No HMAC-SHA256 is probably easier:)

John B.

On 7-Apr-09, at 11:05 PM, general-request at openid.net wrote:

> Date: Tue, 7 Apr 2009 22:49:11 -0700 (PDT)
> From: Santosh Rajan <santrajan at gmail.com>
> Subject: Re: [OpenID] My 2 Cents to the OpenID foundation
> To: general at openid.net
> Message-ID: <22943636.post at talk.nabble.com>
> Content-Type: text/plain; charset=us-ascii
> Thanks John. Now its clearer. I was only wondering that maybe we  
> should stick
> to SHA1 only in that case to verify signature since we are only  
> transporting
> basic profile information. So that it does not cause incompatilities  
> like
> the myspace case.
> John Bradley-7 wrote:
>> Santrajan,
>> The symmetric encryption is key SHA1 or SHA256 is set per RP/OP
>> association.
>> It would take some real bending of the protocol for the RP to have  
>> two
>> associations and choose the one to use based on what the OP might  
>> send
>> back.
>> It is also unlikely that PCI rules are going to allow any OP to store
>> credit cards numbers and make them available via AX.
>> There is going to have to be something other than AX as it is now for
>> authenticating financial transactions.
>> We also need to remember this signature is only intended to prevent
>> tampering and is not used for encryption.
>> For AX including the attributes in the signed portion of the message
>> is optional in any event.
>> Yes the OP may send back attributes that could be modified by the  
>> user
>> without the RP knowing.
>> The AX 1.0 spec allows OP's and RPs to negotiate any sort of signing
>> and/or encryption they like for attributes.
>> However there is no standard for that,  so at the moment the most OPs
>> can do is include the AX attributes in the signed part of the  
>> response.
>> We have talked for a while about the need for AX 2.0 to address some
>> of the ambiguities and add things like encryption and structured
>> attributes.
>> I am hopping work on that can get started soon!
>> John Bradley

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2486 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090407/aef7e709/attachment-0002.bin>

More information about the general mailing list