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

[David Benjamin]

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.

On Wed, Jun 6, 2018 at 11:36 AM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

>
> https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-4
>
> https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs5-passwords-02#section-5.2
>
> > On Jun 6, 2018, at 11:23 AM, David Benjamin <davidben at google.com> wrote:
> >
> > Is there a spec citation for this, or some documented experiments
> against other implementations' behavior? (What do Microsoft and NSS do
> here?) I was pondering something similar recently, but things do seem to
> point at UCS-2 right now. UCS-2 is indeed an unfortunate historical wart,
> but X.680 says:
> >
> > > BMPString is a subtype of UniversalString that has its own unique tag
> and contains only the characters in the Basic Multilingual Plane (those
> corresponding to the first 64K-2 cells, less cells whose encoding is used
> to address characters outside the Basic Multilingual Plane) of ISO/IEC
> 10646.
> >
> > RFC 7292 just says to use a BMPString. That doesn't suggest anyone has
> actually updated it for UTF-16. This is fine for X.509 where BMPString is
> one of many possible string types and folks can use UTF8String for this
> anyway. For PKCS#12, yeah, this introduces limitations that may be worth
> resolving, UTF-16 being the obvious fix. But if it's not in a spec, we
> should get it into one and also be clear on if this is OpenSSL inventing a
> behavior or following de facto behavior established elsewhere.
>
> --
>         Viktor.
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180606/23879e6a/attachment.html>