[precis] Mapping Cryptographic Passwords in PKCS #8

Sean Leonard <dev+ietf@seantek.com> Sat, 21 November 2015 16:25 UTC

Return-Path: <dev+ietf@seantek.com>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D7A1ACE42 for <precis@ietfa.amsl.com>; Sat, 21 Nov 2015 08:25:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKJjn_v68hOP for <precis@ietfa.amsl.com>; Sat, 21 Nov 2015 08:25:24 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12091ACE41 for <precis@ietf.org>; Sat, 21 Nov 2015 08:25:24 -0800 (PST)
Received: from [192.168.123.105] (unknown [75.83.2.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 58D8A509BD for <precis@ietf.org>; Sat, 21 Nov 2015 11:25:22 -0500 (EST)
From: Sean Leonard <dev+ietf@seantek.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <38EC381E-C707-480E-A203-EEA403764B8A@seantek.com>
Date: Sat, 21 Nov 2015 08:25:21 -0800
To: precis@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/precis/8-MC95txvMsYT7mgWcfggWzti0s>
Subject: [precis] Mapping Cryptographic Passwords in PKCS #8
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Nov 2015 16:25:26 -0000

Hello PRECIS:

Recently I proposed the application/pkcs8-encrypted media type registration. I thought I would ping this list (now) as well as the Unicode mailing list (eventually) to weigh in on some parameters that could use PRECIS. What are your thoughts?

In <http://mailarchive.ietf.org/arch/msg/media-types/h9EGzrtrcxXSgD16uQPGPQag8G8>, application/pkcs8-encrypted is proposed for the PKCS #8 EncryptedPrivateKeyInfo type. For purposes of our discussion, the format takes as input an opaque octet string (any octet in the range 00h-FFh, of any length), and executes various specified algorithms; the result is a decrypted private key. The most common algorithm is PBKDF2, but any algorithm can be used (including, for example, a raw symmetric encryption algorithm such as AES-256).

PKCS #8 uses PKCS #5. PKCS #8 and PKCS #5 are embedded in a variety of other protocols and formats, including PKCS #12.

PKCS #8 punts on the issue of character encoding. It says that ASCII or UTF-8 could be used, but doesn’t enforce anything in particular. PKCS #12 specifies UTF-16LE with a terminating NULL character (00h 00h).

In the application/pkcs8-encrypted registration, I thought it might be wise to allow senders and receivers to specify how input (whether user input or otherwise) gets mapped to the octet string, since it’s not part of the format. However my concern at that time was to reflect IANA character sets, rather than profiles of Unicode.

Currently, I am thinking that the parameter “charset” should be renamed to “mapping” (or “pw-mapping”), and “mapping” (or “pw-mapping”) can include the following special values:
*pkcs12          for PKCS #12
*precis          for RFC 7613 Section 4 (Passwords)

Thank you,

Sean

The relevant part of the template (proposed 2015-11-04) is:

Optional parameters:
charset: When the private key encryption algorithm incorporates a “password" that is an octet string, a mapping between user input and the octet string is desirable. PKCS #5 [RFC2898] Section 3 recommends "that applications follow some common text encoding rules"; it then suggests, but does not recommend, ASCII and UTF-8. This parameter specifies the charset that a recipient SHOULD attempt first when mapping user input to the octet string. It has the same semantics as the charset parameter from text/plain, except that it only applies to the user’s input of the password. There is no default value.

ualg: When the charset is a Unicode-based encoding, this parameter is a space-delimited list of Unicode algorithms that a recipient SHOULD first attempt to apply to the Unicode user input in succession, in order to derive the octet string. The list of algorithm keywords is defined by [UNICODE]. “Tailored operations” are operations that are sensitive to language, which must be provided as an input parameter. If a tailored operation is called for, the exclamation mark followed by the [BCP47] language tag specifies the language. For example, "toNFD toNFKC_Casefold!tr" first applies Normalization Form D, followed by Normalization Form KC with Case Folding in the Turkish language, according to [UNICODE] and [UAX31]. The default value of this parameter is empty, and leaves the matter of whether to normalize, case fold, or apply other transformations unspecified.