Re: RevocationCodeIdentifier

While on the subject, the only minor(?) dislike I have for
RevocationCode{Identifier} is that the hash algorithm is not
parameterizable in the instance document - it defaults to SHA-1.

An AlgorithmIdentifier attribute would in my opinion be more elegant
than having to rely on an out of band mechanism proposed by paragraph
[285].  This would also be in line with the approach taken in the
specs that the XKMS spec builds upon (dsig & xenc). Perhaps (optional)
ds:DigestMethod could have been used for this purpose.

Regards
Tommy

On Wed, 3 Nov 2004 16:38:23 -0800 (PST), Shivaram Mysore
<shivarammysore@yahoo.com> wrote:
> 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 09:59:57 UTC