Re: RevocationCodeIdentifier

Thanks.  I understand.  I was trying to update the
spec looking at some very old open issues[1] and some
of the items led me to all of this confusion.  

BTW, all the items in this have now been fixed or not
applicable as appropriate.  I will recheck and send
out an other email regarding the same.

[1]
http://lists.w3.org/Archives/Public/www-xkms/2004Jul/0037.html

Thanks

/Shivaram

--- Yunhao Zhang <yzhang@sqldata.com> wrote:

> 
> 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
> > >
> > >
> >
> >
> 
> 
> 
> 


=====
http://www.geocities.com/shivarammysore/



		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

Received on Thursday, 4 November 2004 00:38:54 UTC