Subject: Re: [saag] encrypted files with UTF-8/16 passwords

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 8 Aug 2017 10:23:24 +0200

On Wed, May 3, 2017 at 7:01 PM, Russ Housley <[email-masked]> wrote:
> I do not understand two things in your Internet-Draft.
>
> In Section 3, I do not know what you mean by:
>
>    As an exception to the OpaqueString profile, empty (zero-length)
>    passwords MAY be used, when they are not they result of the [RFC7613]
>    processing.
>
> Can you please state as: If a zero-length string is provided as a password, then …

Thank you Russ for the comments. Sorry it took quite long to get back to it.
I've rephrase it as:
Note that the OpaqueString profile does not allow empty passwords. Since these
passwords are often used in practice, applications conforming to this document
MAY allow empty (zero-length) passwords, when they are not they result of
the <xref target="RFC7613"/> processing.
That is, an empty string generated from any non-empty internationalized
input MUST NOT be used.

> In Section 5.2, I do not know how an implementation is impacted by the MUST statement:
>
>    … This is the correct
>    version which any application supporting the use of files for
>    certificates and keys MUST support.
>
> I think you are trying to say that PKCS#12 implementations MUST encode the password in UTF-16 big-endian form.  However, Appendix B.1 of RFC 7292 already says that, and more.

Note that this section is not intended to be a normative description
of RFC7292, but rather document bugs in password processing of
existing software. The intention of this description is to provide
context on why openssl's conversion on the next paragraphs was
incorrect.

>
>    In this specification, however, all passwords are created from
>    BMPStrings with a NULL terminator.  This means that each character in
>    the original BMPString is encoded in 2 bytes in big-endian format
>    (most-significant byte first).  There are no Unicode byte order
>    marks.  The 2 bytes produced from the last character in the BMPString
>    are followed by 2 additional bytes with the value 0x00.
>
> Further, your example omits the UTF-16 null character (0x00 0x00) from the resulting password string.

Added and posted an updated version at:
https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-01

regards,
Nikos