[P1363:] AMP proposal of Dec. 2005
- To: STDS-P1363-DISCUSS@xxxxxxxxxxxxxxxxx
- Subject: [P1363:] AMP proposal of Dec. 2005
- From: D Jablon <jablon1363@xxxxxxxxx>
- Date: Thu, 8 Dec 2005 12:45:49 -0800
- DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Hj7I8rQ5qNStw3sh+05Soraz8DJVP7nTQgV24+KNuYCD6WJ1VlnJQa1/foSyxO40tF1NyCfhwQP+y4kn0l0/ZtusJ6j8eg2Vb8Lngqc5mP/NpDsjcEPuHVUqOhz7BSANDSomfR4YAg79Jf9i9CahZ6PzetjyKHoqDWWfHK/35/c= ;
- Reply-To: D Jablon <jablon1363@xxxxxxxxx>
Dear working group,
In yesterday's teleconference we discussed
the 11/29/2005 draft of a proposal to fix
APKAS-AMP [AMP-11-29], and how it could
be further refined to increase Client
performance. I think we agree to:
(1) Remove the Hash_w2 multiplier value,
effectively replacing it with 1.
(2) Restore the Server's step to abort if it
derives a small-order z_g.
(3) Add tighter requirements for domain
parameters regarding small subgroups.
Ignoring issue (3) for the moment, what we're
now discussing is really a variant of AMP2,
rather than AMP+. Taekyoung Kwon's June 8
proposal [Kw05] was really two different
proposals (*), to either:
(a) replace APKAS-AMP with the two-hash
AMP+, as in [AMP-11-29], or
(b) replace APKAS-AMP with the one-hash
AMP2, as in [AMP-12-08].
As discussed, it's probably not a good
idea to merge these two proposals, with
something like an optional second hash.
And since a suitably amended AMP2 needs less
computation for the client, with no apparent
downside vs. a suitably amended AMP+,
I think it's a good idea to focus our
efforts here. AMP2 is also closer to
what we have in draft D22.
I just posted draft text for this proposal
with related Notes and Annex discusion,
plus a brief history of AMPs, to the
P1363 website at [AMP-12-08].
I hope this one is suitable for voting
on this proposal, so please let me know
immediately if it's not.
As for (3), I don't really see how tighter
mandatory constraints on domain parameters
helps, unless it's merely to simplify the
discussion of what to think about when one
doesn't follow the recommendations.
These recommendations are now in Note 3 of
APKAS-AMP, as well as Annex D, in
[AMP-12-08]. Please let me know
immediately if you think this issue
needs further resolution before voting.
-- David
References
----------
[Kw05] T. Kwon, "Revision of AMP in IEEE
P1363.2 and ISO/IEC 11770-4", June 8, 2005.
http://grouper.ieee.org/groups/1363/passwdPK/
contributions.html#Kwon05
[AMP-11-29] AMP Proposal, November 11, 2005,
http://grouper.ieee.org/groups/1363/WorkingGroup/
presentations/0512.html#P1363_2
[AMP-12-08] AMP Proposal, December 8, 2005,
http://grouper.ieee.org/groups/1363/WorkingGroup/
presentations/0512.html#FollowUp
(*) Footnote:
I corrected the abstract for [Kw05] on the P1363.2
contributions page to list AMP2 as well as AMP+,
since both were in this proposal.
__________________________________________________
David Jablon, Editor IEEE P1363.2
www.jablon.org
http://grouper.ieee.org/groups/1363/
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
______________________________________________________________________
To unsubscribe, mail LISTSERV@LISTSERV.IEEE.ORG with
the body of the message containing: SIGNOFF STDS-P1363-DISCUSS
Send any concerns to STDS-P1363-DISCUSS-request@LISTSERV.IEEE.ORG,
or manage subscriptions at http://listserv.ieee.org/cgi-bin/wa
Visit IEEE P1363 on the web at: http://grouper.ieee.org/groups/1363
______________________________________________________________________