Re: [saag] [Spasm] Best practices for applications using X.509 client certificates

[Sean Leonard <[e-mail]>]

On 9/26/2016 1:25 PM, David Woodhouse wrote:
> On Mon, 2016-09-26 at 12:55 -0700, Sean Leonard wrote:
>> On 9/26/2016 12:48 PM, David Woodhouse wrote:
>>>> For interoperable private key formats, I favor PKCS #8 PrivateKeyInfo
>>>> (as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are
>>>> standardized, widely-supported, and algorithm-agile.
>>> They are also non-portable, because even when RFC5958 was published in
>>> 2010, FFS, it didn't mandate the conversion of the password to UTF-8
>>> (let alone any mention of Unicode normalisation) for the purpose of the
>>> key derivation.
>>>
>>> PKCS#12 at least gets *part* of that right, by mandating UTF16BE (BMP).
>> draft-seantek-pkcs8-encrypted-01
> OK... so now we have can say
>
> Content-Type: application/pkcs8-encrypted; password-mapping=UTF-8
>
> (Did you intend '*pkcs12' to mean UTF16-BE which is BMP, not UTF-16LE?)
Yes, I meant UTF-16BE. That was a typo.

By the way, I've actually done quite a lot of tests on several crypto 
stacks, and none of them enforce that the Unicode code point has to be 
in the BMP. You can use surrogate pairs (which are in the BMP anyway) 
just fine.

>
> But I've *never* seen an application make use of certs/files from any
> container where that Content-Type: header might be present. It's not
> even permitted to put it in PEM files, is it? So does this really buy
> me anything in practice?

As with any "new thing", people have to write code for the "new thing" 
to use the "new thing". If you build it, they will come...

The alternative would be to shoehorn the password mapping into some 
attribute in ASN.1. But there's no practical place for that in PKCS #8 
EncryptedPrivateKeyInfo, which is just:

EncryptedPrivateKeyInfo ::= SEQUENCE {
     encryptionAlgorithm AlgorithmIdentifier {{KeyEncryptionAlgorithms}},
     encryptedData EncryptedData
}


I mean, you *could* put it in the PBKDF2-params, with a new algorithm 
identifier. But that will require writing new code to deal with the "new 
thing". No way around it, sorry.

>
> And it still doesn't cover Unicode normalisation. :)

Actually it does. PRECIS says NFC for password/OpaqueString. See Section 
6.2 of RFC 7613.

There were much earlier draft registrations (see the media-types mailing 
list, it's been kicking around for many months now; see also PRECIS 
mailing list) that went into some detail about NFC and stuff like that. 
The rough consensus was that it's best to let PRECIS handle that stuff: 
doing it in the security space (aka PKCS #8 or similar container) is not 
where the expertise lies.

The other point is that there is only one party that cares about the 
encoding: "you". You = the private key holder. Private keys aren't meant 
to be shared. Frankly, who cares what the octets are, as long as you can 
input the same ones into the decryption process. If you are creating the 
private key and using it on the same computing device, the encoding 
doesn't actually matter. You could record mouse clicks or voice samples 
or raw key scan codes from the kernel, and it wouldn't affect the result.

Annex M.4 of IEEE 802.11-2012 has similar insights (which is why I cited 
it).

Adding the encoding parameter actually facilitates attacks, because it 
tells an eavesdropper what bit patterns will *not* appear. Well-formed 
UTF-8 can never have octets C0, C1, or F5-FF, for example; well-formed 
UTF-8 will also bias the input to make certain bit patterns far more 
likely than others. (The KDF is designed to mitigate against biased 
input anyway, though.) The encoding parameter can also thwart attacks, 
by intentionally mislabeling the encoding. It's not cryptographically 
protected so it is subject to undetectable tampering.

Best regards,

Sean