[openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

[David Benjamin]

On Wed, Jun 6, 2018 at 1:26 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

>
>
> > On Jun 6, 2018, at 12:52 PM, David Benjamin <davidben at google.com> wrote:
> >
> > Oh, I didn't realize that document existed. Although it doesn't say that
> it is overriding the BMPString restrictions. It says it "does not add any
> further restrictions to the input passwords of these methods, however it is
> RECOMMENDED to use (big-endian) UTF-16 NFC form". That reads to me as
> saying you should use UTF-16 NFC form, but only the subset that still
> satisfies the existing BMPString restrictions. It even recommends that
> "applications which restricted the MacData password to BMPString set" fail
> in some cases.
> >
> > If the intent was otherwise, probably worth some rewording.
>
> The point is that instead of failing we should use UTF-16 for non-BMP code
> points.
> Worst case we'll still fail.  We can document a warning that passwords
> outside
> the BMP are non-portable.  The responsibility for ensuring NFC form will
> be placed
> on the application feeding us the UTF-8 data.  We should just convert from
> UTF-8 to
> UTF-16.
>
> I don't read the draft as forbidding non-BMP UTF-16.  The two agree on the
> UCS-2
> subset of UTF-16 (i.e. the BMP code points).  If the intent is to forbind
> non-BMP
> passwords, we should ask the authors to change that, with a portability
> warning.
> Such passwords might not work everywhere, but forbidding them is unwise.
>

Whether or not it is the intent, the status quo (X.680 +  RFC 7292)
unambiguously forbids non-BMP passwords by way of the definition of
BMPString. Not saying anything in the new document implies carrying over
that restriction.

I think extending UCS-2 to UTF-16 in the context of PKCS#12 passwords is a
fine idea. Likewise with other BMPStrings in PKCS#12 like the friendlyName
attribute. (Though, there, changing BMPString to CHOICE { BMPString,
UTF8String} may be better as it keeps things working with a standard ASN.1
implementation. I'm fine with either.) But this should be explicitly
specified somewhere, rather than implementations making up behavior. See
also https://tools.ietf.org/html/draft-thomson-postel-was-wrong-03.

As there appears to already be a draft in progress to update things, this
should be pretty straightforward to do. Have it say something like:

"The definition of BMPString in X.680 restricts the input to code points in
the BMP, encoded in big-endian UCS-2. This document generalizes it for
these fields to carry any code point, encoded in big-endian UTF-16. This is
backwards-compatible with existing PKCS#12 decoders, but note that new
files using code points outside the BMP may not interoperate with older
decoders."

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180607/da789eca/attachment.html>