Re: RevocationCodeIdentifier

Hi Shivaram -

Section 7.1.2 makes good sense to me.  I believe at least three
interop parties have independently implemented this in a way that
interoperates.  The implementation is according to section 8.1.

The "two MAC" protocol allows the key holder to demonstrate knowledge
of the same secret he used during registration without revealing
neither the secret nor the first MAC.

During registration the second MAC is sent to the service where it is
stored for future revocation requests.  An eavesdropper won't be able
to use this MAC for (possibly harmless but exceedingly annoying)
revocation.

During revocation the first MAC is sent to the service. The service
MAC's this first MAC and compares the result to MAC received during
registration.

Regards
Tommy
On Wed, 3 Nov 2004 10:34:57 -0800 (PST), Shivaram Mysore
<shivarammysore@yahoo.com> wrote:
> 
> Tommy, 
>   
> Para [282] 
>  <RevocationCodeIdentifier> [Optional] Specifies a value to be used to
> validate a RevocationCode value in a subsequent Revocation request   
> 
> 
> Section 7.1.2 
> 
> [286]On initial registration the <RevocationCodeIdentifier> value is
> obtained by first performing the MAC calculation on the pass phrase value,
> then performing a second MAC calculation on the result. 
> 
> [287]To prove knowledge of the pass phrase in a subsequent revocation
> request the <RevocationCode> value is obtained by performing the MAC
> calculation on the pass phrase value. 
> 
> [288]The double MAC calculation ensures that the <RevocationCode> value may
> be sent as plaintext without the risk of disclosing a value which might have
> been used by the end-user as a password in another context. A second
> advantage of employing the double MAC calculation is that it ensures XKMS
> service does not place arbitrary constraints on the length of or character
> set in which the pass phrase is encoded. 
> 
> But, as per [288], we don't specify double MACing in [287].  I believe this
> is an error.  And if there is double MACing, then the values for
> RevocationCode and RevocationCodeIdentifier must be the same. 
> 
> Can you throw some light on how current implementation is done? 
> 
> Thanks 
> 
> /Shivaram
> 
>  
> 
> 
> Tommy Lindberg <tommy.lindberg@gmail.com> wrote: 
> 
> 
> 
> Hi Shivaram -
> 
> The RevocationCodeIdentifier is the second hash of some client chosen
> quantity whereas the RevocationCode is the first hash of the same
> quantity - this is done according to the Limited Use Shared Secret
> algorithm.
> 
> So, yes they should in that sense match. However, they will not be
> identical.
> 
> They might be incorrectly calculated ofcourse. Let me know if you
> think that is the case.
> 
> Regards
> Tommy
> 
> 
> On Wed, 3 Nov 2004 09:47:05 -0800 (PST), Shivaram Mysore
> wrote:
> > 
> > Hi, 
> > 
> > Should n't the RevocationCodeIdentifier in para [243] (example) 
> > 
> > 5AEAai06hFJEkuqyDyqNh8k/u3M=
> > 
> > 
> > be matched with the same in example para[261] ? 
> > PHx8li2SUhrJv2e1DyeWbGbD6rs=
> 
> 
> > 
> > Spec:
> > http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html
> > 
> > /Shivaram
> > 
> > 
> > http://www.geocities.com/shivarammysore/
> > 
> > ________________________________
> > Do you Yahoo!?
> > Check out the new Yahoo! Front Page. www.yahoo.com> 
> >
> 
> 
> 
> 
> 
> 
> http://www.geocities.com/shivarammysore/
> 
>  ________________________________
> Do you Yahoo!?
>  Check out the new Yahoo! Front Page. www.yahoo.com</a 
> 
>

Received on Wednesday, 3 November 2004 19:27:52 UTC