<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jun 6, 2018 at 1:26 PM Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Jun 6, 2018, at 12:52 PM, David Benjamin <<a href="mailto:davidben@google.com" target="_blank">davidben@google.com</a>> wrote:<br>
> <br>
> 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.<br>
> <br>
> If the intent was otherwise, probably worth some rewording.<br>
<br>
The point is that instead of failing we should use UTF-16 for non-BMP code points.<br>
Worst case we'll still fail.  We can document a warning that passwords outside<br>
the BMP are non-portable.  The responsibility for ensuring NFC form will be placed<br>
on the application feeding us the UTF-8 data.  We should just convert from UTF-8 to<br>
UTF-16.<br>
<br>
I don't read the draft as forbidding non-BMP UTF-16.  The two agree on the UCS-2<br>
subset of UTF-16 (i.e. the BMP code points).  If the intent is to forbind non-BMP<br>
passwords, we should ask the authors to change that, with a portability warning.<br>
Such passwords might not work everywhere, but forbidding them is unwise.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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 <a href="https://tools.ietf.org/html/draft-thomson-postel-was-wrong-03">https://tools.ietf.org/html/draft-thomson-postel-was-wrong-03</a>.</div><div><br></div><div>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:</div><div><br></div><div>"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."</div><div><br></div><div>David</div></div></div>