Re: RevocationCodeIdentifier

Yes. This is how we implemented.

Yunhao

----- Original Message ----- 
From: "Tommy Lindberg" <tommy.lindberg@gmail.com>
To: "Shivaram Mysore" <shivarammysore@yahoo.com>
Cc: "XKMS WG" <www-xkms@w3.org>
Sent: Wednesday, November 03, 2004 2:27 PM
Subject: 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 Thursday, 4 November 2004 00:25:25 UTC