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. _______________________________________________ precis mailing list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis
