Re: [lamps] WG Last Call for draft-ietf-lamps-pkcs12-pbmac1-02

[Hubert Kario <[e-mail]>]

My explicit goal for draft-ietf-lamps-pkcs12-pbmac1 is to NOT
influence how PBES1 or PBES2 is done. However the password is
handled by the library, it should just continue to do the same
thing, but instead of passing it to the legacy mac calculation,
pass it to PBMAC1 and then to PBKDF2 or something else.

So, no, I will not be adding additional test vectors as those
are unnecessary to ensure that.

If you want to standardise how passwords outside 7-bit ASCII range
are to be handled, I'm willing to contribute to that draft,
but I consider it completely out of scope and a distraction for
the purpose of introducing PBMAC1.

Unless Chairs state otherwise, I consider this discussion finished.

On Tuesday, 7 November 2023 07:50:43 CET, David Woodhouse wrote:
> On Mon, 2023-11-06 at 21:42 +0100, Hubert Kario wrote:
>> 
>> That's the issue: NFC isn't the correct normalisation because it will
>> leave ligatures intact. And with people copying passwords from pdf
>> files there's non-zero chance of it including ligatures.
>
> Honestly, if you put a password into a PDF and allow it to use
> ligatures and expect users to cut and paste… that isn't a problem we're
> trying to solve today. And 'f' and 'i' are in ASCII anyway. Does that
> mean you'd be disinclined to use a test password of 'fish' too?
>
>> So there's two of us and we already are disagreeing about the correct
>> normalisation form for passwords: precisely the reason why I don't
>> want to touch it.
>
> I agree that it's out of scope. As is the input method. And the means
> (PDF or otherwise) by which it's communicated to the user, if such
> occurs.
>
> But once we get to PKCS#12 with a password character sequence of U+2460
> U+00B2 U+00B3 U+FF14, *however* we got that, from then *on* it's
> perfectly defined and can be tested.
>
> The lack of normalization of our normalization doesn't have to stop us
> exercising the basic character encoding. Which *sorely* needs testing.
>
>

-- 
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic