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

[Hubert Kario <[e-mail]>]

On Monday, 6 November 2023 18:44:19 CET, David Woodhouse wrote:
> On Mon, 2023-11-06 at 16:50 +0100, Hubert Kario wrote:
>> On Monday, 6 November 2023 15:55:07 CET, David Woodhouse wrote:
>>> On Wed, 2023-11-01 at 19:48 +0100, Hubert Kario wrote: ...
>> 
>> I have no problem with requiring BMPString. That's exactly what I want to
>> happen and what must happen for interoperability.
>> 
>> Please propose a phrasing for that section that you find sufficient
>> for that.
>
> Happy to do so! I had thought we were arguing about the necessity of
> doing just that :)
>
>     <section title="Password encoding">
>         <t>As documented in <xref target="RFC7292">Appendix B.1 of RFC
>         7292</xref> handling of password encoding in the 
> underlying standards
>         is underspecified. However, just as with PBES1 and 
> PBES2 when used in
>         the context of PKCS#12 objects, all passwords used with PBMAC1 MUST
>         be created from BMPStrings with a NULL terminator.
>         </t>
>     </section>
>
> https://github.com/tomato42/id-pkcs12-pbmac1/pull/5
>
>
> I didn't manage to slip in the part about recommending that the *same*
> password be used for all encrypted PDUs and the overall MAC. That would
> want to be in a separate section rather than 'Password encoding', I
> think?

It's just a recommendation, and already established general practice anyway
(I know of only openssl being able to create files with different
passwords, and just few implementations can handle them anyway),
so I'm fine with it being omitted.

> If we are indeed agreeing that the password encoding MUST be a
> BMPString, can I have another try at persuading you that the test
> password you use should be more adventurous? I thought you were
> previously saying that a more interesting test password would overstep
> the mark of what's actually being specified... but I don't think it
> does?
>
> My preferred test suite password is just two characters:
>
>    U+0102 LATIN CAPITAL LETTER A WITH BREVE
>    U+017B LATIN CAPITAL LETTER Z WITH DOT ABOVE
>
> That would give 0x01 0x02 0x01 0x7b 0x00 0x00 for the BMPString
> encoding.
>
> And that's completely specified and required by the wording above,
> which I hope reflects what you agreed? So could we use something like
> that instead of just "1234"? 

First let me be cheeky: but that file is encrypted with a Unicode password 
of
'①²³４', it just uses the correct Unicode NFKC normalisation!
That is:
U+2460    CIRCLED DIGIT ONE
U+00B2    SUPERSCRIPT TWO
U+00B3    SUPERSCRIPT THREE
U+FF14 	FULLWIDTH DIGIT FOUR

Secondly, more serious answer:
While users do expect that password entered using different input methods
ends up deriving the same encryption keys, the way to do that isn't exactly
straight-forward.

Because while having "ó" (U+00F3 LATIN SMALL LETTER O WITH ACUTE)
and the "ó" (U+006F LATIN SMALL LETTER O, U+0301 COMBINING ACUTE ACCENT)
producing the same password is expected and even, I'd say, wanted, 
having symbols like "²" (SUPERSCRIPT TWO) being converted to ASCII "2" 
isn't.
Ligatures are an area where we do want the "ffi" (LATIN SMALL LIGATURE FFI)
to be converted to "ffi".

So, what kind of normalisation should be used is the first issue.

The other issue is how you achieve that: the library to handle that
normalisation is anything but small. We'd be asking people to link their
cryptographic libraries with libraries two to four times the size of the
crypto lib.

Lastly, how do you handle legacy files, from before when "²" were converted
to "2"? What if the file was created with a Unicode library version that
didn't recognise the new emoji with "1" in it as a digit and convert it
to arabic numeral 1 under NFKD?

All of that would have to be agreed on and specified. We would end up with
a document longer than the existing one.

So, I'm against including it not because I don't think it's important,
but because I'm well aware of the scope of work to do it right.
-- 
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