[openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Fri, 2016-11-25 at 08:54 +0100, Nikos Mavrogiannopoulos wrote:
> On Thu, Nov 24, 2016 at 4:33 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> > On Thu, 2016-11-24 at 14:26 +0100, Nikos Mavrogiannopoulos wrote:
> > > On Wed, Nov 23, 2016 at 10:10 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> > > > > Locales is not the only thing you have to worry about. UTF-8 and UTF-16
> > > > > can express the same string in various (different) ways, so they cannot
> > > > > be directly used as passwords. I have recently added RFC7613
> > > > > "normalization" to gnutls, to address the differences.
> > > > > 
> > > > > https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008240.html
> > > > 
> > > > Right. You normalise to NFC, yes? That's what my draft recommends. It's a
> > > > shame that PKCS#12 doesn't *mandate* that... but hey, at least it does
> > > > better than PKCS#8 :)
> > > 
> > > NFC normalization is one step of RFC7613. I think recommending RFC7613
> > > is better than making any recommendation.
> > 
> > Hmmm.... I'd be happier if RFC7613 had any mention of using its
> > profiles for key derivation. (And even happier if the PKCS#12 and
> > PKCS#8 standards mandated its use!)
> 
> They predate it by several years. At the time they were published very
> few could conceive how UTF-8/unicode would look like.

The original PKCS documents predated the publication of Unicode by a
few months in 1991. Sure, *NOBODY* could have predicted in early 1991
that some kind of coherent approach to character sets would be a good
idea ☺

And yes, UTF-8 came later (1992, I believe¹) but isn't necessary. Even
the original RSA PKCS#12 uses Unicode, and specifies the use of
BMPString for key derivation. Although it neglected to specify any
normalisation. (Did normalisation exist, at that point?)

Even by the time PKCS#5 was brought into the IETF fold in 2000
(RFC2898) it was fairly clear that you kind of had to agree on the
mapping of password characters to numbers, and it was "recommended that
applications follow some common text encoding rules. ASCII and UTF-8
[27] are two possibilities."

I know, it's useless to look back and, with the benefit of hindsight,
criticise the original standards. I'm mostly just reacting to your
"excuse". And standards *do* evolve. PKCS#8 was updated again in
RFC5958 and even then it could have been mandated that UTF-8/NFC be
used for key derivation.

> > This is really something that should be required of the software which
> > *creates* the key file. I've tried to limit my draft to the *use* of
> > existing files — but on the plus side, that means I can say things like
> > "try X and if that doesn't work try Y", at least for the file
> > decryption, if not for hardware.
> > So sure, if there is existing software which is *creating* key files
> > and using the rules in RFC7613 when it does so, then it makes sense for
> > me to suggest that.
> 
> gnutls after 3.5.7 will be using RFC7613 for all types of passwords.

Including *rejecting* passwords such as '<my cat is a &#x9;by>' as
shown in example 17 in §4.3? Or do we end up in a situation where
applications which are *loading* key files should attempt such a
password anyway, even though it *shouldn't* work?

And how about PKCS#12? RFC7613 mandates UTF-8 but we just ignore that
bit and do UTF-16 instead for PKCS#12, with the rest of the RFC7613
rules?

-- 
dwmw2

¹ https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161125/d9cd2721/attachment.bin>