The ECDH public value in RFC 5480 is an OCTET STRING, which means that the
value is exactly 32 bytes. When this gets carried as a subject public key in a
certificate, there is an extra byte only because the type is a BIT STRING.
My conclusion is that the current draft is correct:
* For P-256, the length of this value is 32 bytes, encoded in
binary as specified in [FIPS186-4].
Russ
> On Jun 24, 2020, at 1:10 AM, Mohit Sethi M
> <[email protected]> wrote:
>
> Hi all,
>
> I am not a crypto expert and my knowledge of public key encodings is
> based on my work with Rene Struik for a different draft.
>
> The current text in draft-ietf-emu-aka-pfs-04 says "For P-256, the
> length of this value is 32 bytes, encoded in binary". Shouldn't this be
> 33 bytes? And wouldn't it make sense to explicitly say that this is an
> octet string in the compressed format while referencing "SEC 1: Elliptic
> Curve Cryptography, Version 2.0" for the point to octet string
> conversion rules?
>
> --Mohit
>
> On 5/26/20 9:57 AM, [email protected] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the EAP Method Update WG of the IETF.
>>
>> Title : Perfect-Forward Secrecy for the Extensible
>> Authentication Protocol Method for Authentication and Key Agreement
>> (EAP-AKA' PFS)
>> Authors : Jari Arkko
>> Karl Norrman
>> Vesa Torvinen
>> Filename : draft-ietf-emu-aka-pfs-04.txt
>> Pages : 26
>> Date : 2020-05-25
>>
>> Abstract:
>> Many different attacks have been reported as part of revelations
>> associated with pervasive surveillance. Some of the reported attacks
>> involved compromising smart cards, such as attacking SIM card
>> manufacturers and operators in an effort to compromise shared secrets
>> stored on these cards. Since the publication of those reports,
>> manufacturing and provisioning processes have gained much scrutiny
>> and have improved. However, the danger of resourceful attackers for
>> these systems is still a concern.
>>
>> This specification is an optional extension to the EAP-AKA'
>> authentication method which was defined in [I-D.ietf-emu-rfc5448bis].
>> The extension, when negotiated, provides Perfect Forward Secrecy for
>> the session key generated as a part of the authentication run in EAP-
>> AKA'. This prevents an attacker who has gained access to the long-
>> term pre-shared secret in a SIM card from being able to decrypt any
>> past communications. In addition, if the attacker stays merely a
>> passive eavesdropper, the extension prevents attacks against future
>> sessions. This forces attackers to use active attacks instead.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-emu-aka-pfs-04
>> https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-04
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-aka-pfs-04
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> Emu mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/emu
> _______________________________________________
> Emu mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
