From nobody Wed Nov 4 21:59:41 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BF11B3A3E for ; Wed, 4 Nov 2015 21:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wXd4GfIKzLh6 for ; Wed, 4 Nov 2015 21:59:38 -0800 (PST) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DEA1B3A18 for ; Wed, 4 Nov 2015 21:59:38 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora4.lax.icann.org (8.13.8/8.13.8) with ESMTP id tA55xHHY000466 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 5 Nov 2015 05:59:37 GMT Received: from dhcp-29-53.meeting.ietf94.jp (unknown [133.93.29.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5423C509BB for ; Thu, 5 Nov 2015 00:59:15 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_DE4E5CC1-94EF-46F3-9C00-2AC70F012D71"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Date: Thu, 5 Nov 2015 14:57:28 +0900 To: "media-types@iana.org" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Greylist: Delayed for 259:25:49 by milter-greylist-4.0 (pechora4.lax.icann.org [192.0.33.74]); Thu, 05 Nov 2015 05:59:37 +0000 (UTC) Archived-At: Subject: [media-types] Internet media type application/pkcs8-encrypted rev 2 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 05:59:40 -0000 --Apple-Mail=_DE4E5CC1-94EF-46F3-9C00-2AC70F012D71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello: To keep this moving, trying a different thing. Please review. Sean ***** Type name: application Subtype name: pkcs8-encrypted Required parameters: N/A Optional parameters: charset: When the private key encryption algorithm incorporates a = =93password" 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=92s = 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]. =93Tailored operations=94 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. Encoding considerations: binary Security considerations: Carries a cryptographic private key. See Section 6 of RFC 5958. EncryptedPrivateKeyInfo PKCS #8 data contains exactly one private key. = Poor password choices, weak algorithms, or improper parameter selections = (e.g., insufficient salting rounds) will make the confidential payloads = much easier to compromise. Interoperability considerations: PKCS #8 is a widely recognized format for private key information on all = modern cryptographic stacks. The encrypted variation in this = registration, EncryptedPrivateKeyInfo (Section 3, Encrypted Private Key = Info, of RFC 5958, and Section 6 of PKCS #8), is less widely used for = exchange than PKCS #12, but it is much simpler to implement. The = contents are exactly one private key (with optional attributes), so the = possibility for hidden "easter eggs" in the payload such as unexpected = certificates or miscellaneous secrets is drastically reduced. Published specification: PKCS #8 v1.2, November 1993 (republished as RFC 5208, May 2008); RFC = 5958, August 2010 Applications that use this media type: Machines, applications, browsers, Internet kiosks, and so on, that = support this standard allow a user to import, export, and exercise a = single private key. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): None. File extension(s): .p8e Macintosh file type code(s): N/A Person & email address to contact for further information: Sean Leonard Intended usage: COMMON Restrictions on usage: None. Author: RSA, EMC, IETF Change controller: The IETF Provisional registration? (standards tree only): No --Apple-Mail=_DE4E5CC1-94EF-46F3-9C00-2AC70F012D71 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTA1MDU1OTE1WjAjBgkqhkiG9w0BCQQxFgQUK7B1lILQLZMkNhShYoDk7am+1aYwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAAOBbhJDkLcG5YBZwUjhQtmePLSxA5hBFQx30TbSDPF9zaNxusypHkrSIRIkCV7KmpwB uSc7e4zpg65IUXX1TIXZ6CHtxwM/U1eiQkS9DepyG5dGg7Av8ozrxSki3etZzUYd9Q1Bj1zyFmCr 5MO1foycinqS/MLadJWE14rQkpwzLKmrbeTMraMEGcBImzrtQQ4NzYMxrGDS+xx+bQgDuiT8+t8f a/b8ZYmLc96c80L83c/RPaW7ZDolehl5velm8jlevCJX5GJE5x6uUydyJ9QEkXk5FRbAt2WZz27W ZzRPvwc7UEy2T8x7Cocv5Y0Kz2CUKAOEtTs0zmno/hSbthoAAAAAAAA= --Apple-Mail=_DE4E5CC1-94EF-46F3-9C00-2AC70F012D71-- From nobody Tue Nov 10 06:22:29 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD331B2B2B for ; Tue, 10 Nov 2015 06:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.765 X-Spam-Level: * X-Spam-Status: No, score=1.765 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=no 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 cG7mw8jQl4cy for ; Tue, 10 Nov 2015 06:22:26 -0800 (PST) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26C61B2B28 for ; Tue, 10 Nov 2015 06:22:26 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0101.outbound.protection.outlook.com [104.47.126.101]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id tAAEM4k3023509 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 Nov 2015 14:22:25 GMT Received: from TY1PR01MB0143.jpnprd01.prod.outlook.com (10.161.134.147) by TY1PR01MB0271.jpnprd01.prod.outlook.com (10.161.136.12) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 10 Nov 2015 09:45:37 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0143.jpnprd01.prod.outlook.com (10.161.134.147) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 10 Nov 2015 09:45:35 +0000 To: Sean Leonard , "media-types@iana.org" References: From: "=?UTF-8?Q?Martin_J._D=c3=bcrst?=" Organization: Aoyama Gakuin University Message-ID: <5641BCB5.4060409@it.aoyama.ac.jp> Date: Tue, 10 Nov 2015 18:45:25 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: HKXPR03CA0053.apcprd03.prod.outlook.com (10.141.129.43) To TY1PR01MB0143.jpnprd01.prod.outlook.com (25.161.134.147) X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0143; 2:Z3TunNdxgLQS7FD+kr5JaYFmsYoFoL3x9mU4Oeb0/hFqdgoqFAcnVzgUM1FEVCiICaa9wnZ/GiFRaDP0aMGzWYCe0Q74G89FRZLcJERGK29YBmRe/AxNEPTwhWNFRceHWPZhtGk9pE9GuZyoAA4zTnWE1Iwphdv7KCofOZAdAHk=; 3:UXno8opfxCtIGA2wuStCcVM+u459Jmnekikpzgsa+M5oUpfnIboLIxz5OwL7odvGYIo49JPlmR3zXwRgg4FZ6t1IQPNk/6ZKa0BhKEFLZhINEaXjva1vnEA3jlxPgOubmkqT0ThlD5g3qJzHmJRykQ==; 25:FpGkvWzx9Kdth6zYJBN+W0fGGIPvLOQexh8hT9jzRqYsiQCNc/wq+IT53g5yl/67VKFqbLLhArVIhu3DSSmM6mCafk3x5X3eQe5oOQ0Z4TkakiGNAQOb4DVYfPiUmloRC/ag5S1EA0160wM4pAdkURCSTJJ0KjOAetHaCqHVGIPZkSojC686HTg2u6nyqdGoHtyxldDBtdw9hOALDLtN84ruIDLIubxMxdTlJdUsfGZN+FUO9/+xg63aQ16y7NFSbUzU+yLnOuL00ajNAsPHZw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0143; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:TY1PR01MB0143; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0143; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0143; 4:4l1koGHBVh/K8W8m2kt+BqSehtWq2SjgESR5X4veSk4Uh3NfNi8hwHlsU99GIOqfnM7lK4re6p3FnK8GKtkLBcG2g7wyO0lvj962+EiDZcciiODCdnRhSYZqOoK3ownyEZ5IEd/5BW8DAsbenHBVZT5zT/sly+9742GQy1VkvEfa2RhlK9hVMvb11T7Td7WEhDjz2aobZ6TgSYldR+gzTvGijyuUa+32nrb++GzkCsN7RbRnLqXcved8KvJmO7FnuQkBx3wtEbAvIIn3iRIzAucBt4gOjexo10FhnFv89+x7lUiYiTHDVLZHu1xVNCWgBDjJz27vrWvaPZ1aR/vxC3qqe2P3uoDp7fc934SFmWH+cVqB4EpLcCV5Jhc8IS/w X-Forefront-PRVS: 07562C22DA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(189002)(24454002)(479174004)(199003)(2950100001)(50466002)(122386002)(33656002)(2501003)(64126003)(87976001)(189998001)(101416001)(86362001)(59896002)(5007970100001)(83506001)(92566002)(77096005)(15975445007)(23676002)(5001920100001)(81156007)(4001350100001)(5001770100001)(19580395003)(19580405001)(47776003)(106356001)(65806001)(5004730100002)(76176999)(65956001)(42186005)(66066001)(74482002)(105586002)(107886002)(50986999)(5001960100002)(551544002)(5008740100001)(54356999)(65816999)(80316001)(87266999)(40100003)(97736004)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0143; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwMTQzOzIzOnlGeFArVzJ0SU14ZVhWQzh6OStSMFdtbGho?= =?utf-8?B?YmI1Yk5PNXlvNHlzMG54ZWdOcy9CSzVFbkRZdnRoTFdRUkh3S2lkQkVFVU9L?= =?utf-8?B?eUZES1lEeVlVdTNlVjJKbEtOYnhtUW9ZUVhSdURNeFlhTnZna1p1N2tnSzdL?= =?utf-8?B?OUhqcERLdjFZTTllZXF3bEN3MnczYm9zU0lUaTFZT0paY2RjOVd4Mzg3VlZs?= =?utf-8?B?UDduUy9tSEpnOGZEbnJUMUVsYTBxcUx5U2t1WW16bzZ4Q20rdnkzeTU4OVIr?= =?utf-8?B?enl2WURGMXF2V3hFNVRiWnNLR2lkd045MFhYM2phVlhtY2FQSHh1Zk5GUkZs?= =?utf-8?B?anZwdzY1aVJDb0wxUmlFbDNjMnhCZVNzMTFHWExpMEFGNHhQVXUyV1ZpVVhZ?= =?utf-8?B?VW4vRUpseGtQdzQzdmpNWUt2SVgxTjdGQWhtaWlsak41OVRYQ3hRaTNYTXhT?= =?utf-8?B?Tm5DNklFOUlITVgwWGR0NDhtd2hnZXB0NzhSZnh3RHM1T3J3N1NpajFXWU9F?= =?utf-8?B?M1hnRGhUcXpaZjNBSDI5R3JQck5saWc0NEw4b1hUbDcyWXJ3SXpFMFl6dVNv?= =?utf-8?B?MEdHcDRLTS9zdERLNUlRSkphMFhkYm1aYTloQnQrN0p3S0VqUHdIT3VXTmRw?= =?utf-8?B?Ym1MMEpGRFZMcGhONUdBNnlYeXYxK04yY2ROekRlK1RldEp5Y2pkekxtUk5h?= =?utf-8?B?UnR6UGF3dStWUEE3RzZDMUgyUDJrWUorVkE5bkYzTExLZDJpQldnUlFneVg5?= =?utf-8?B?T0tOMlhCemptNFE4ejlFUlhyMTMvRWF0TGlMZGZBaHNmWkpGZ3RNVk9HN2tC?= =?utf-8?B?d2szb2tkaFNURDFpRVRsaEFFZFhYNHZWYkxDeExUaDI3NFpaL3cwWmVIU1A3?= =?utf-8?B?ak1vbWxKa3NtcnpQVEoxdVNITDNtVlFiMGw2b255ZjBPeFJjWWlQTmE4WlJz?= =?utf-8?B?RCtqQzRVek1MRDBCYVQvR2FCTzF1WWc0Y2ZzaWZEdlBsblhXVitybFhyL1Rq?= =?utf-8?B?SUlrWGRUU3VDR28yWnVrZjcwOEVEL1RGc3JiRjVlNlJmdDB1K2JaQjk4UUN2?= =?utf-8?B?Sms3N0RRbFVmRXhaQTh3V01DTnBHTDBGbjFXSzRrVUJBZkM1RWh2YTFtK21O?= =?utf-8?B?WGVHYTRzaUlDTnZQcmJDOEdUZmsrTVgvdzk1RG96QTgyaDl0SHE1THhObUtY?= =?utf-8?B?ZlBydEgwcXJqV3pLQmlvWEVTVnhxTEVxVWI4bG93VUcyc3ErUXF2aEhIK3Va?= =?utf-8?B?UmIxK1lUcXlLRzVrbG1TUXlxVkY5bnBIUVNjL2JUK3c4engramM1SElUUVoz?= =?utf-8?B?VjVLd1J4K0JRUE4xckd5TkpPYmFTM1BjRGVnV3k0dnlxem0rckZJZlJjVER3?= =?utf-8?B?eTkyMzk2RWtlQXJhMU9DdElYSUVwd1lRaXlEaXR5bmZvRjl0UHN5WE52SFc1?= =?utf-8?B?MkszeFdYdXNaVFRrcFJLT2JNRStSanBaMlc4MWJsVjZtVTV4R0d0VGRBeFAr?= =?utf-8?B?ZjcvclFnVGpkNW1wd2dNRHllTlZ1cEFIcUhpaUI5VkdERFgyTUtZekxWdE9j?= =?utf-8?B?NFFlQkFPbkxDNm81dWoyWVAwV2F3S2NkOWo2a2wrckR3dGNBdVZ5YjhZeXdX?= =?utf-8?B?eW1jZmR2U0hBMmt6MmY4QzEvNjY2Q0toODd2YjFEUTE5Ukd5SEN0STRpbEEw?= =?utf-8?B?cGVXWEcrdVE0cWZoeTFneUlOMXRzWHoxSUFQNWRTNVczSS9vazNMbXhkR2tV?= =?utf-8?B?NXN1SFpIR1EyMWErOUhuM1pXRmh5YmpJa1MzdFRQeWFweFdGNFNBN2xJWkVr?= =?utf-8?B?TlBFamlUOElFWTZFWFpWNGpYOFlpdUorL0NFaDRqZ0NnOGc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0143; 5:ZwmVkuIY7RPqr7aEKocgWekyYkglb2mTVIHZhoNCZWe9FZoOzd7Ba/YZtAY+fowrl9Z4/xLUHVC9XFvOUTRrKGbp6F2RhK8syv/xua6rCU+zlIXFUsZn3B7uRJPlTJZNxfU+JzL7uWPKOxb3VeC8Rg==; 24:KinTRePqXeL3pleuzTW10A7SFP2gA9L62iqV6hGyuy54K7G8WNxncgomXZZC0O1p+7cSdj2waeoHt+XVqLGtOmx+iuSkCBrFMlBkpIoaUvk=; 20:y+g441aYCIfWuSOe/m69s63bla8ZvknchGV2E3wr5YnjAppRr/5jLoWPb3pUlAwoiZFv8T0aTBztIhW/wJ0ewg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2015 09:45:35.7942 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0143 X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0271; 2:rNqTUbqHWl5xpgGkJOb8UA7B3Oz9NHypv1ttLct732RCvhc7oCgtdZsGZlEyteLkpV7G6tGPYJe7BwF0vD9bxZZ9etADggnRiP8G/F9RR0DfUGPp9FVRH0EjzJ1DSglYkUeyw7xBM5JGhs3N7kQp4PNPB5vJy2g4YWGuShNouLA=; 23:rXOiTDTI2yMIL2Q+veXfiplOpgUXNpL4Ojo3xEUORJ3ZmZK+6kpOfFbVLVxtvV0Mvhm2/QrVynNNTGHrFL7Wldfqn5a58editoSEYMuLFKdtULfwPGXpOp3r6qF0p66mdp1lPXM9Fw6647bh1O/ltsyP2ghZpSRuhb1MlN7Cju9xwUP9Cv83jXN59wK2H1zd X-OriginatorOrg: it.aoyama.ac.jp X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Tue, 10 Nov 2015 14:22:26 +0000 (UTC) Archived-At: Subject: Re: [media-types] Internet media type application/pkcs8-encrypted rev 2 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 14:22:28 -0000 Hello Sean, I have a few questions re. your registration below. On 2015/11/05 14:57, Sean Leonard wrote: > Hello: > > To keep this moving, trying a different thing. Please review. > > Sean > > ***** > > Type name: application > > Subtype name: pkcs8-encrypted > > Required parameters: N/A > > 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. Why does it say "This parameter specifies the charset that a recipient SHOULD attempt *first*" here? Can't that encoding just be specified as such? At least for future, similar efforts, it would be extremely desirable to not leave character encoding open like this, but just to nail it down to UTF-8. > 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. "When the charset is": Is this the charset parameter, or the actual encoding of the password? What is a "Unicode algorithm"? And where in [UNICODE] are these defined (I know Unicode pretty well, but this is the first time I see the term "Unicode algorithm"). Reading on and looking at the examples, the intent becomes clearer, at least to somebody who has seen things such toNFD and toNFKC and Casefold, but I hope we can avoid "specification by example" here. Also, if there is indeed a list of algorithm identifiers in [UNICODE], then it would be good to give a Section number. Is the intent that each and every algorithm named somewhere in [UNICODE] is implemented? My rough guess would be that the average password input implementation implements only the identity transform. [I would of course be positively surprised if I were wrong.] Also, references for [UNICODE], [BCP47], and [UAX31] should be give so that this registration is self-containing. Regards, Martin. > Encoding considerations: binary > > Security considerations: > Carries a cryptographic private key. See Section 6 of RFC 5958. > EncryptedPrivateKeyInfo PKCS #8 data contains exactly one private key. Poor password choices, weak algorithms, or improper parameter selections (e.g., insufficient salting rounds) will make the confidential payloads much easier to compromise. > > Interoperability considerations: > PKCS #8 is a widely recognized format for private key information on all modern cryptographic stacks. The encrypted variation in this registration, EncryptedPrivateKeyInfo (Section 3, Encrypted Private Key Info, of RFC 5958, and Section 6 of PKCS #8), is less widely used for exchange than PKCS #12, but it is much simpler to implement. The contents are exactly one private key (with optional attributes), so the possibility for hidden "easter eggs" in the payload such as unexpected certificates or miscellaneous secrets is drastically reduced. > > Published specification: > PKCS #8 v1.2, November 1993 (republished as RFC 5208, May 2008); RFC 5958, August 2010 > > Applications that use this media type: > Machines, applications, browsers, Internet kiosks, and so on, that support this standard allow a user to import, export, and exercise a single private key. > > Fragment identifier considerations: N/A > > Additional information: > > Deprecated alias names for this type: N/A > Magic number(s): None. > File extension(s): .p8e > Macintosh file type code(s): N/A > > Person & email address to contact for further information: > Sean Leonard > > Intended usage: COMMON > > Restrictions on usage: None. > > Author: > RSA, EMC, IETF > > Change controller: The IETF > > Provisional registration? (standards tree only): No > > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > From nobody Tue Nov 10 12:14:35 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341CE1B3E63 for ; Tue, 10 Nov 2015 12:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.008 X-Spam-Level: X-Spam-Status: No, score=-0.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, MIME_8BIT_HEADER=0.3] autolearn=no 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 faNxpqTVxIVR for ; Tue, 10 Nov 2015 12:14:32 -0800 (PST) Received: from pechora1.lax.icann.org (pechora1.icann.org [IPv6:2620:0:2d0:201::1:71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782E31B3E58 for ; Tue, 10 Nov 2015 12:14:31 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id tAAKEAoN010182 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 10 Nov 2015 20:14:31 GMT 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 3D724509BB; Tue, 10 Nov 2015 15:14:08 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_84B9F0DC-98EE-45CE-80AF-1E0FBC60EF5E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <5641BCB5.4060409@it.aoyama.ac.jp> Date: Tue, 10 Nov 2015 07:25:59 -0800 Message-Id: References: <5641BCB5.4060409@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1878.6) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Tue, 10 Nov 2015 20:14:31 +0000 (UTC) Archived-At: Cc: "media-types@iana.org" Subject: Re: [media-types] Internet media type application/pkcs8-encrypted rev 2 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 20:14:34 -0000 --Apple-Mail=_84B9F0DC-98EE-45CE-80AF-1E0FBC60EF5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Martin, On Nov 10, 2015, at 1:45 AM, Martin J. D=C3=BCrst = wrote: > Hello Sean, >=20 > I have a few questions re. your registration below. >=20 > On 2015/11/05 14:57, Sean Leonard wrote: >> Hello: >>=20 >> To keep this moving, trying a different thing. Please review. >>=20 >> Sean >>=20 >> ***** >>=20 >> Type name: application >>=20 >> Subtype name: pkcs8-encrypted >>=20 >> Required parameters: N/A >>=20 >> Optional parameters: >> charset: When the private key encryption algorithm incorporates a = =E2=80=9Cpassword" 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=E2=80=99s input of the password. There is no default value. >=20 > Why does it say "This parameter specifies the charset that a recipient = SHOULD attempt *first*" here? Can't that encoding just be specified as = such? >=20 > At least for future, similar efforts, it would be extremely desirable = to not leave character encoding open like this, but just to nail it down = to UTF-8. There seems to be something of a =E2=80=9Ccultural disconnect=E2=80=9D = between the security people and the I18N/UI/UX people. The I18N/UI/UX people want well-defined interfaces that work with users = =E2=80=9Cin their own language=E2=80=9D, whether that language is = visual, aural, tactile, symbolic, pictorial, etc. Invariably this = involves Unicode and a large character repertoire such as =F0=9F=92=A9 = and =E5=A4=A7=E4=BE=BF=E6=89=80. In contrast, the security people find open-ended things like Unicode to = be anathema and would much rather restrict the range of inputs to a = small and preferably uniformly distributed set of values. And there are = good reasons for that, because when you introduce bias into = cryptographic protocols, it turns out that it is a lot easier to = cryptanalyze the results. The common security protocols that I have seen that take passwords, = hand-wave about character sets and encodings and define the password to = be an octet string. This is great for universality but bad for human = input. PBKDF2 (PKCS #5, on which this PKCS #8 EncryptedPrivateKeyInfo = registration is based) is a leading example of the =E2=80=9Coctet = string=E2=80=9D approach. Ultimately, the algorithms don=E2=80=99t care = what encoding it=E2=80=99s in, as long as they get a blob of bits = (octets). My knowledge of implementations of PKCS #5/#8/#12 suggests that there = are many applications out there that give zero thought to the encoding = issue, which means that they will take user input =E2=80=9CAs-Is=E2=80=9D,= i.e., in the current code page. Note that PKCS #12 defines the input to this structure as a UTF-16LE = encoded character string, *with* a terminating U+0000 NULL character = (i.e., the octets 00 00). This is really =E2=80=9Cweird=E2=80=9D except = of course for the fact that Microsoft invented it and then shipped it = without too much thought, in which case, all weirdness can be explained. It is a design criteria that if you extract such an = EncryptedPrivateKeyInfo blob from a PKCS #12 file, that you should be = able to process it. If you specify UTF-8 as the one, single, true = encoding of the password for application/pkcs8-encrypted, that can=E2=80=99= t happen. Furthermore, UTF-8 is not uniformly distributed across the octet range. = If your users are in US-English they are highly likely to have octets in = 20-7E. Octets in 00-1F will be pretty rare. And if you choose scalar = values randomly in Unicode (regardless of assignment), you will see a = *lot* of F0-F4 but virtually none in 00-7F. And in spite of all this, = octets F5-FF will *never* appear in UTF-8. It turns out that we have a pretty good source of uniformity and = universality: characters in the US-ASCII range 20-7E. Many password = input boxes will only accept US-ASCII and so user=E2=80=99s = non-US-English keyboards will switch to US-ASCII mode for the purpose of = providing input to such boxes. What matters is not so much the specific = characters, so much as a reasonable selection of arbitrary buttons that = a user can push *across a wide range of devices*. This ends up giving = you 5-6 bits of entropy per user input. So the need for UTF-8 or any = particular encoding is actually not as great as some people perceive. Overall I think that a standard such as IEEE 802.11 strikes a reasonable = balance. (See 802.11-2012 Annex M.4, which is informative, but is pretty = much the worldwide de-facto standard practice.) In 802.11, the input to = PBKDF2 is between 8-63 ASCII-encoded characters in the range 20-7E, or = 64 hexadecimal characters that convert directly to 32 octets. *** To answer your questions directly:=20 > Why does it say "This parameter specifies the charset that a recipient = SHOULD attempt *first*" here? > Can't that encoding just be specified as such? The parameter is not cryptographically protected so it is subject to = tampering or substitution. Furthermore, a good-faith but na=C3=AFve = sender may put some encoding (e.g., UTF-8) but not have the means to = verify that the encoding actually works, because the user did not supply = the password. Basically it=E2=80=99s a good-faith first effort, but this = parameter can=E2=80=99t meaningfully restrict what the sender or = receiver attempt to do. Also, I am not sure how to specify the NULL suffix in the PKCS = #12-extracted case. I suppose it could just be =E2=80=9C+0=E2=80=9D or = something. >=20 >> 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]. =E2=80=9CTailored operations=E2=80=9D 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. >=20 > "When the charset is": Is this the charset parameter, or the actual = encoding of the password? Admittedly this was vague. First draft. I am not sure what it should be. = Per PKCS #5, the "Actual Encoding" is just an octet string of arbitrary = length. I would limit this to cases when the charset parameter is present and = defined. Makes it easier. >=20 > What is a "Unicode algorithm=E2=80=9D? Conformance Clause D17. > And where in [UNICODE] are these defined (I know Unicode pretty well, = but this is the first time I see the term "Unicode algorithm=E2=80=9D). It=E2=80=99s actually a defined term of art (see D17). > Reading on and looking at the examples, the intent becomes clearer, at = least to somebody who has seen things such toNFD and toNFKC and = Casefold, but I hope we can avoid "specification by example" here. In fairness, =E2=80=9CtoNFD=E2=80=9D and =E2=80=9CtoNFKC=E2=80=9D are = not defined terms. However, NFD (D118) and NFKC (D121) are. I would rather not create Yet Another Registry of things. The terms are = in fact defined in [UNICODE] in the conformance clauses. My usability perception is that if people really want to use Unicode in = their passwords, canonicalization is a very useful property to preserve. = Case folding/case mapping are not so useful, as most systems like to = have case-sensitive passwords for greater entropy, but =E2=80=9Cmost = systems=E2=80=9D is not =E2=80=9Call systems=E2=80=9D so we shouldn=E2=80=99= t preclude the use of case algorithms. As for other algorithms such as = line breaking, character segmentation, Hangul syllable name generation, = etc., the short answer is =E2=80=9CI don=E2=80=99t know=E2=80=9D. (These = are all reasons why people stick with ASCII passwords, by the way.) >=20 > Also, if there is indeed a list of algorithm identifiers in [UNICODE], = then it would be good to give a Section number. Is the intent that each = and every algorithm named somewhere in [UNICODE] is implemented? My = rough guess would be that the average password input implementation = implements only the identity transform. [I would of course be positively = surprised if I were wrong.] See above; main thing that worries me is Normalization Forms. >=20 > Also, references for [UNICODE], [BCP47], and [UAX31] should be give so = that this registration is self-containing. Ok. Another possibility is that this registration goes back to =E2=80=9Crev = 1=E2=80=9D, i.e., no optional parameters about the character encoding at = all. I think that is perfectly defensible. But it is not particularly = i18n-friendly. Regards, Sean >=20 > Regards, Martin. >=20 >> Encoding considerations: binary >>=20 >> Security considerations: >> Carries a cryptographic private key. See Section 6 of RFC 5958. >> EncryptedPrivateKeyInfo PKCS #8 data contains exactly one private = key. Poor password choices, weak algorithms, or improper parameter = selections (e.g., insufficient salting rounds) will make the = confidential payloads much easier to compromise. >>=20 >> Interoperability considerations: >> PKCS #8 is a widely recognized format for private key information on = all modern cryptographic stacks. The encrypted variation in this = registration, EncryptedPrivateKeyInfo (Section 3, Encrypted Private Key = Info, of RFC 5958, and Section 6 of PKCS #8), is less widely used for = exchange than PKCS #12, but it is much simpler to implement. The = contents are exactly one private key (with optional attributes), so the = possibility for hidden "easter eggs" in the payload such as unexpected = certificates or miscellaneous secrets is drastically reduced. >>=20 >> Published specification: >> PKCS #8 v1.2, November 1993 (republished as RFC 5208, May 2008); RFC = 5958, August 2010 >>=20 >> Applications that use this media type: >> Machines, applications, browsers, Internet kiosks, and so on, that = support this standard allow a user to import, export, and exercise a = single private key. >>=20 >> Fragment identifier considerations: N/A >>=20 >> Additional information: >>=20 >> Deprecated alias names for this type: N/A >> Magic number(s): None. >> File extension(s): .p8e >> Macintosh file type code(s): N/A >>=20 >> Person & email address to contact for further information: >> Sean Leonard >>=20 >> Intended usage: COMMON >>=20 >> Restrictions on usage: None. >>=20 >> Author: >> RSA, EMC, IETF >>=20 >> Change controller: The IETF >>=20 >> Provisional registration? (standards tree only): No >>=20 >>=20 >>=20 >> _______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types >>=20 --Apple-Mail=_84B9F0DC-98EE-45CE-80AF-1E0FBC60EF5E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTEwMTUyNzA4WjAjBgkqhkiG9w0BCQQxFgQUnLBXcy5vNfQhWthVWt7sf96x4tIwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBABYVEYJMgqrwS901Tpkg4PHtFj3M96oblSXiez5tlLGWBEcmSq0Lf3TIT1+3zRspd6TB INlMdBwzrmZayvxgdOx2LC4ct10n9cATut40ZeSQVTJiXSq3NBFnWsKjKHFBhLW0RMdj2GVNc62A JwrMbvT4iqOzB1MhfLwdYJ1rUiuRmi95a1DDaRLA7XjAQM2uh2IS27jp7Kz4DYmWHBcTBJY86gtA F+T61ezIyP0b6u524B6HZZGxiCU9ODaNlkMs5KGUqfmfPIH57Eq/G8ZFICoksf5GEIJf+nyw7mEF kH6M23jhrYvdsR0M9Nn3ejpzpmYBkqupAb3D7wLjulUuXt0AAAAAAAA= --Apple-Mail=_84B9F0DC-98EE-45CE-80AF-1E0FBC60EF5E-- From nobody Tue Nov 24 01:57:12 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0122C1B2ED9 for ; Tue, 24 Nov 2015 01:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no 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 KL_dSHXtq0FL for ; Tue, 24 Nov 2015 01:57:07 -0800 (PST) Received: from pechora7.dc.icann.org (pechora7.icann.org [IPv6:2620:0:2830:201::1:73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0F01B2ED3 for ; Tue, 24 Nov 2015 01:57:06 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by pechora7.dc.icann.org (8.13.8/8.13.8) with ESMTP id tAO9uiF0012326 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 24 Nov 2015 09:57:05 GMT Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 600FA509BB; Tue, 24 Nov 2015 04:56:43 -0500 (EST) To: "=?UTF-8?Q?Martin_J._D=c3=bcrst?=" References: <5641BCB5.4060409@it.aoyama.ac.jp> <5653BDDB.9020203@it.aoyama.ac.jp> From: Sean Leonard Message-ID: <565433DF.50304@seantek.com> Date: Tue, 24 Nov 2015 01:54:39 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5653BDDB.9020203@it.aoyama.ac.jp> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030004020303030104030100" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora7.dc.icann.org [192.0.46.73]); Tue, 24 Nov 2015 09:57:05 +0000 (UTC) Archived-At: Cc: "media-types@iana.org" , "precis@ietf.org" Subject: Re: [media-types] Internet media type application/pkcs8-encrypted rev 2 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 09:57:11 -0000 This is a cryptographically signed message in MIME format. --------------ms030004020303030104030100 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/23/2015 5:31 PM, Martin J. D=C3=BCrst wrote: > Hello Sean, > > I have cc'ed the precis mailing list because some of what I'll write=20 > below is relevant for the discussion you have started there. This is=20 > also the reason why I'm keeping most the previous context. > > On 2015/11/11 00:25, Sean Leonard wrote: >> Hello Martin, >> >> On Nov 10, 2015, at 1:45 AM, Martin J. D=C3=BCrst =20 >> wrote: >> >>> Hello Sean, >>> >>> I have a few questions re. your registration below. >>> >>> On 2015/11/05 14:57, Sean Leonard wrote: >>>> Hello: >>>> >>>> To keep this moving, trying a different thing. Please review. >>>> >>>> Sean >>>> >>>> ***** >>>> >>>> Type name: application >>>> >>>> Subtype name: pkcs8-encrypted >>>> >>>> Required parameters: N/A >>>> >>>> Optional parameters: >>>> charset: When the private key encryption algorithm incorporates a=20 >>>> =E2=80=9Cpassword" that is an octet string, a mapping between user i= nput=20 >>>> and the octet string is desirable. PKCS #5 [RFC2898] Section 3=20 >>>> recommends "that applications follow some common text encoding=20 >>>> rules"; it then suggests, but does not recommend, ASCII and UTF-8.=20 >>>> This parameter specifies the charset that a recipient SHOULD=20 >>>> attempt first when mapping user input to the octet string. It has=20 >>>> the same semantics as the charset parameter from text/plain, except = >>>> that it only applies to the user=E2=80=99s input of the password. Th= ere is=20 >>>> no default value. >>> >>> Why does it say "This parameter specifies the charset that a=20 >>> recipient SHOULD attempt *first*" here? Can't that encoding just be=20 >>> specified as such? >>> >>> At least for future, similar efforts, it would be extremely=20 >>> desirable to not leave character encoding open like this, but just=20 >>> to nail it down to UTF-8. >> >> There seems to be something of a =E2=80=9Ccultural disconnect=E2=80=9D= between the=20 >> security people and the I18N/UI/UX people. >> >> The I18N/UI/UX people want well-defined interfaces that work with=20 >> users =E2=80=9Cin their own language=E2=80=9D, whether that language i= s visual,=20 >> aural, tactile, symbolic, pictorial, etc. Invariably this involves=20 >> Unicode and a large character repertoire such as =F0=9F=92=A9 and =E5=A4= =A7=E4=BE=BF=E6=89=80. >> >> In contrast, the security people find open-ended things like Unicode=20 >> to be anathema and would much rather restrict the range of inputs to=20 >> a small and preferably uniformly distributed set of values. And there = >> are good reasons for that, because when you introduce bias into=20 >> cryptographic protocols, it turns out that it is a lot easier to=20 >> cryptanalyze the results. >> >> The common security protocols that I have seen that take passwords,=20 >> hand-wave about character sets and encodings and define the password=20 >> to be an octet string. This is great for universality but bad for=20 >> human input. PBKDF2 (PKCS #5, on which this PKCS #8=20 >> EncryptedPrivateKeyInfo registration is based) is a leading example=20 >> of the =E2=80=9Coctet string=E2=80=9D approach. Ultimately, the algori= thms don=E2=80=99t care=20 >> what encoding it=E2=80=99s in, as long as they get a blob of bits (oct= ets). >> >> My knowledge of implementations of PKCS #5/#8/#12 suggests that there = >> are many applications out there that give zero thought to the=20 >> encoding issue, which means that they will take user input =E2=80=9CAs= -Is=E2=80=9D,=20 >> i.e., in the current code page. >> >> Note that PKCS #12 defines the input to this structure as a UTF-16LE=20 >> encoded character string, *with* a terminating U+0000 NULL character=20 >> (i.e., the octets 00 00). This is really =E2=80=9Cweird=E2=80=9D excep= t of course for=20 >> the fact that Microsoft invented it and then shipped it without too=20 >> much thought, in which case, all weirdness can be explained. >> >> It is a design criteria that if you extract such an=20 >> EncryptedPrivateKeyInfo blob from a PKCS #12 file, that you should be = >> able to process it. If you specify UTF-8 as the one, single, true=20 >> encoding of the password for application/pkcs8-encrypted, that can=E2=80= =99t=20 >> happen. > > That's just fine, in this specific case. I have explicitly prefaced my = > remark above with "At least in the future". > > But if we know that the password is encoded in UTF-16LE, then why=20 > doesn't your registration just say "This parameter specifies the=20 > charset" rather than the handwavy "This parameter specifies the=20 > charset that a recipient SHOULD attempt *first*". See below... > > >> Furthermore, UTF-8 is not uniformly distributed across the octet=20 >> range. If your users are in US-English they are highly likely to have = >> octets in 20-7E. Octets in 00-1F will be pretty rare. And if you=20 >> choose scalar values randomly in Unicode (regardless of assignment),=20 >> you will see a *lot* of F0-F4 but virtually none in 00-7F. And in=20 >> spite of all this, octets F5-FF will *never* appear in UTF-8. >> >> It turns out that we have a pretty good source of uniformity and=20 >> universality: characters in the US-ASCII range 20-7E. Many password=20 >> input boxes will only accept US-ASCII and so user=E2=80=99s non-US-Eng= lish=20 >> keyboards will switch to US-ASCII mode for the purpose of providing=20 >> input to such boxes. What matters is not so much the specific=20 >> characters, so much as a reasonable selection of arbitrary buttons=20 >> that a user can push *across a wide range of devices*. This ends up=20 >> giving you 5-6 bits of entropy per user input. So the need for UTF-8=20 >> or any particular encoding is actually not as great as some people=20 >> perceive. > > My comment was specifically trying to say: If you use something more=20 > than US-ASCII, make it UTF-8. I think that's also the general policy=20 > of the IETF. As for entropy, the entropy needs to be measured over the = > whole string. It's clear that in UTF-8 bytes, a password in the ASCII=20 > range is shorter than a similar-length (in terms of charaters)=20 > password in a non-Latin script. The entropy of each byte will be=20 > lower, but the entropy of the overall password should be about the same= =2E > > Something that's very important for passwords is how easy they are to=20 > remember for actual people. It should be obvious that it's easier for=20 > somebody to remember a password in the language/script they use every=20 > day than in some foreign gibberish. Actually, the most important criteria for passwords is that they are=20 inputtable: capable of being input into a computing system. The=20 passphrase "=C3=A9clairs sont si d=C3=A9licieuX" is nice and memorable, b= ut if you=20 cannot put in "=C3=A9" (or "X") in the computer systems where you're goin= g to=20 use the thing, you're screwed. Viewed through this lens, many cryptographic systems are so-defined to=20 accept secret input as octet strings, where neither the mathematical=20 algorithms nor the protocols inherently restrict the range of the=20 octets. Whether "=C3=A9" maps to E9, C3 A9, E9 00, or 82 [code page 437] = is=20 relevant because if the user tries to input =C3=A9 but the math part does= n't=20 get the original octets on the input, it won't work. Scenarios where PKCS #8 blobs might be accessed at device boot-time are=20 possible. In those scenarios, the character set/encoding of the system=20 may well be something other than UTF-8. Regardless of the encoding, the=20 boot-time input methods may be severely restricted. (There is a recent=20 thread on the Unicode mailing list, related to passwords, that raises=20 this issue.) PKCS #8/PKCS #5 mention ASCII and UTF-8 as complementary=20 possibilities--this registration does not attempt to disturb that. The handwavy text, "This parameter specifies the charset that a=20 recipient SHOULD attempt *first*", recognizes the mathematical reality.=20 Suppose an Evildoer (pick your preferred one) encodes all of its private = keys with the parameter charset=3Dus-ascii. But the actual input has some= =20 character =C3=B1 that is clearly outside the range. When the Good Guys=E2= =84=A2 try=20 to break the encryption, if they only attempt characters in us-ascii=20 range, they are never going to decrypt the thing. Ditto for UTF-8=20 encoding if the correct input (meaning the input that actually results=20 successfully decrypting the private key payload) contains FFh somehow,=20 or some overlong encoding. If this parameter were baked into the PKCS #8 format, perhaps a stronger = claim could be made in the specification text. (Compare with PKCS #12.)=20 But as it stands, the parameter is just a "hint"...and for a long time,=20 implementations will probably not bother to put this parameter in. > >> Overall I think that a standard such as IEEE 802.11 strikes a=20 >> reasonable balance. (See 802.11-2012 Annex M.4, which is informative, = >> but is pretty much the worldwide de-facto standard practice.) In=20 >> 802.11, the input to PBKDF2 is between 8-63 ASCII-encoded characters=20 >> in the range 20-7E, or 64 hexadecimal characters that convert=20 >> directly to 32 octets. > > So it's up to 63 ASCII characters but only up to 32 octets that may=20 > e.g. be used for UTF-8? That doesn't strike me as a reasonable=20 > balance; it puts a much stronger length limitation on some scripts=20 > outside ASCII. Take a look at 802.11-2012 Annex M.4. Here is a direct link:=20 . When the input is 64 hexadecimal characters, PBKDF2 is bypassed: the=20 resulting 32 octets are used directly as the RSNA pre-shared key (PSK).=20 The advantage of defining the protocol that way is that a user interface = (aka, password prompt) for Wi-Fi devices only needs to have one text box = field: the implementation then auto-detects which path to use based on=20 the length. Otherwise, all Wi-Fi devices on the planet would have to=20 have user interfaces designed with additional dropdowns, checkboxes,=20 radio buttons, etc. to pick between the (ASCII) password and direct=20 input of the PSK. (It stands to reason that every password input for=20 every SSID has a corresponding valid 64-hexacdecimal-character PSK.) 802.11-2012 does not define an algorithm for cases when the passphrase=20 has characters that encode outside of the range of 32 to 126. I do not=20 know what other implementations do worldwide if non-ASCII characters are = entered. As some have observed (on the Unicode mailing list), some=20 operating systems, e.g., iOS, always enforce Latin script for password=20 box entry. > >> *** >> To answer your questions directly: >>> Why does it say "This parameter specifies the charset that a=20 >>> recipient SHOULD attempt *first*" here? >>> Can't that encoding just be specified as such? >> >> >> The parameter is not cryptographically protected so it is subject to=20 >> tampering or substitution. Furthermore, a good-faith but na=C3=AFve se= nder=20 >> may put some encoding (e.g., UTF-8) but not have the means to verify=20 >> that the encoding actually works, because the user did not supply the = >> password. Basically it=E2=80=99s a good-faith first effort, but this=20 >> parameter can=E2=80=99t meaningfully restrict what the sender or recei= ver=20 >> attempt to do. > > That essentially applies to any single parameter in any single media=20 > type registration, and in much more of what the IETF does. Yet this is = > virtually never called out, because otherwise, IETF documents would be = > full of such stuff and very hard to read. Perhaps. First of all such warnings about "not being cryptographically=20 protected" tend to show up in many Security Considerations sections, of=20 which I have seen many in the IETF. Second of all, the content inside=20 PKCS #8 EncryptedPrivateKeyInfo *is* cryptographically protected (to a=20 certain extent, depends on the algorithms being used), but an=20 implementation really needs to be vigilant not to treat the stuff=20 outside, i.e., the media type parameters, as the same as on the inside. > >> Also, I am not sure how to specify the NULL suffix in the PKCS=20 >> #12-extracted case. > > That may suggest that you are going down the wrong path here. > >> I suppose it could just be =E2=80=9C+0=E2=80=9D or something. >> >>> >>>> ualg: When the charset is a Unicode-based encoding, this parameter=20 >>>> is a space-delimited list of Unicode algorithms that a recipient=20 >>>> SHOULD first attempt to apply to the Unicode user input in=20 >>>> succession, in order to derive the octet string. The list of=20 >>>> algorithm keywords is defined by [UNICODE]. =E2=80=9CTailored operat= ions=E2=80=9D=20 >>>> are operations that are sensitive to language, which must be=20 >>>> provided as an input parameter. If a tailored operation is called=20 >>>> for, the exclamation mark followed by the [BCP47] language tag=20 >>>> specifies the language. For example, "toNFD toNFKC_Casefold!tr"=20 >>>> first applies Normalization Form D, followed by Normalization Form=20 >>>> KC with Case Folding in the Turkish language, according to=20 >>>> [UNICODE] and [UAX31]. The default value of this parameter is=20 >>>> empty, and leaves the matter of whether to normalize, case fold, or = >>>> apply other transformations unspecified. >>> >>> "When the charset is": Is this the charset parameter, or the actual=20 >>> encoding of the password? >> >> Admittedly this was vague. First draft. I am not sure what it should=20 >> be. Per PKCS #5, the "Actual Encoding" is just an octet string of=20 >> arbitrary length. >> >> I would limit this to cases when the charset parameter is present and = >> defined. Makes it easier. >> >>> >>> What is a "Unicode algorithm=E2=80=9D? >> >> Conformance Clause D17. > > Well, this, via the term "Named Unicode Algorithm" points to table 3.1 = > (page 93 in Unicode V 8.0). > > >>> Reading on and looking at the examples, the intent becomes clearer,=20 >>> at least to somebody who has seen things such toNFD and toNFKC and=20 >>> Casefold, but I hope we can avoid "specification by example" here. >> >> In fairness, =E2=80=9CtoNFD=E2=80=9D and =E2=80=9CtoNFKC=E2=80=9D are = not defined terms. However, NFD=20 >> (D118) and NFKC (D121) are. > > Yes, but not as (Named) Unicode Algorithms. > >> I would rather not create Yet Another Registry of things. > > I'd agree in principle. > >> The terms are in fact defined in [UNICODE] in the conformance clauses.= > > Yes, but there are many other things defined there, too. Yes... If you meant to refer to [UNICODE] Table 3.1 (page 93, Unicode V8.0) as=20 a canonical list of names...I do not find that satisfactory because the=20 only entries for normalization are "Normalization" and "Identifier=20 Normalization", but the most important kind of transformation is to pick = which Normalization Form you want: NFC, NFD, NFKC, or NFKD. (I am under=20 the impression that NFKC is the "Best" for passwords, but the PRECIS=20 profile for passwords uses NFC. Not sure exactly why but I will leave=20 that one alone.) Really, algorithms to do character transformations, prohibitions,=20 substitutions, etc. in the Internet context, would seem to fall under=20 PRECIS. Therefore maybe the proper pre-existing "registry" of things is=20 just PRECIS profiles. Developing from my last PRECIS e-mail on the topic, I am leaning towards = a single parameter: pw-mapping with special values: *pkcs12 =3D UTF-16LE with U+0000 NULL terminator *precis =3D PRECIS password profile, i.e., OpaqueString from Section 4= =20 for RFC 7613 (always UTF-8) *precis-XXX =3D PRECIS profile named by XXX *hex =3D hexadecimal input: as with 802.11, the input is mapped to= =20 0-9, A-F, and then converted directly to octets. If there are an odd=20 number of hex digits, the final digit 0 is appended, or an error=20 condition may be raised. *dtmf =3D The characters "0"-"9", "A"-"D", "*", and "#", which map t= o=20 their corresponding ASCII codes. (This is to support restricted-input=20 devices, i.e., telephones and telephone-like equipment.) Otherwise, pw-mapping is a charset. The parameter previously called "ualg" is interesting but maybe it's a=20 bit over-specified. If *precis-XXX can do the job, I am fine with=20 specifying "pw-mapping" only, and removing "ualg". Personally I don't see why PRECIS prohibits control characters like HT=20 in passwords. It seems to me that those sorts of characters are legit=20 for password purposes. But that is just my personal view and I don't=20 care enough about HT, BEL, ENQ, or similar in this context to fight=20 about it. :) > >> My usability perception is that if people really want to use Unicode=20 >> in their passwords, canonicalization is a very useful property to=20 >> preserve. Case folding/case mapping are not so useful, as most=20 >> systems like to have case-sensitive passwords for greater entropy,=20 >> but =E2=80=9Cmost systems=E2=80=9D is not =E2=80=9Call systems=E2=80=9D= so we shouldn=E2=80=99t preclude the=20 >> use of case algorithms. As for other algorithms such as line=20 >> breaking, character segmentation, Hangul syllable name generation,=20 >> etc., the short answer is =E2=80=9CI don=E2=80=99t know=E2=80=9D. (The= se are all reasons why=20 >> people stick with ASCII passwords, by the way.) > > Line breaking, character segmentation, Hangul syllable name=20 > generation,... are completely irrelevant for passwords and passphrases.= > > Also, many algorithms come with options or parameters. > > >>> Also, if there is indeed a list of algorithm identifiers in=20 >>> [UNICODE], then it would be good to give a Section number. Is the=20 >>> intent that each and every algorithm named somewhere in [UNICODE] is = >>> implemented? My rough guess would be that the average password input = >>> implementation implements only the identity transform. [I would of=20 >>> course be positively surprised if I were wrong.] >> >> See above; main thing that worries me is Normalization Forms. >> >>> >>> Also, references for [UNICODE], [BCP47], and [UAX31] should be give=20 >>> so that this registration is self-containing. >> >> Ok. >> >> Another possibility is that this registration goes back to =E2=80=9Cre= v 1=E2=80=9D,=20 >> i.e., no optional parameters about the character encoding at all. I=20 >> think that is perfectly defensible. But it is not particularly=20 >> i18n-friendly. > > I'm not sufficiently familiar with the format and the actual use=20 > cases, but my suggestion would be to check what's actually out there=20 > in the field (such as the Microsoft UTF-16LE including final NULL),=20 > and select or create a list of parameters/algorithms (with a registry=20 > if it turns out to be needed). To that, add a way to reference PRECIS, = > even if it's not currently used, because that includes the=20 > expertise/recommendations of experts. > > The current proposal just essentially saying: Unicode may define some=20 > of the pieces you may want to use here, and may have labels for them,=20 > so just give it a try. I'm not at all sure this will help=20 > interoperability, except by similar accidents like the Microsoft one=20 > that you described above. Right. Well, maybe PRECIS to the rescue? David Wheeler's aphorism is=20 that all problems in computer science can be solved by another level of=20 indirection. If PRECIS can handle this stuff, that's good enough for me. Sean > > Regards, Martin. > >> Regards, >> >> Sean >> >>> >>> Regards, Martin. >>> >>>> Encoding considerations: binary >>>> >>>> Security considerations: >>>> Carries a cryptographic private key. See Section 6 of RFC 5958. >>>> EncryptedPrivateKeyInfo PKCS #8 data contains exactly one private=20 >>>> key. Poor password choices, weak algorithms, or improper parameter=20 >>>> selections (e.g., insufficient salting rounds) will make the=20 >>>> confidential payloads much easier to compromise. >>>> >>>> Interoperability considerations: >>>> PKCS #8 is a widely recognized format for private key information=20 >>>> on all modern cryptographic stacks. The encrypted variation in this = >>>> registration, EncryptedPrivateKeyInfo (Section 3, Encrypted Private = >>>> Key Info, of RFC 5958, and Section 6 of PKCS #8), is less widely=20 >>>> used for exchange than PKCS #12, but it is much simpler to=20 >>>> implement. The contents are exactly one private key (with optional=20 >>>> attributes), so the possibility for hidden "easter eggs" in the=20 >>>> payload such as unexpected certificates or miscellaneous secrets is = >>>> drastically reduced. >>>> >>>> Published specification: >>>> PKCS #8 v1.2, November 1993 (republished as RFC 5208, May 2008);=20 >>>> RFC 5958, August 2010 >>>> >>>> Applications that use this media type: >>>> Machines, applications, browsers, Internet kiosks, and so on, that=20 >>>> support this standard allow a user to import, export, and exercise=20 >>>> a single private key. >>>> >>>> Fragment identifier considerations: N/A >>>> >>>> Additional information: >>>> >>>> Deprecated alias names for this type: N/A >>>> Magic number(s): None. >>>> File extension(s): .p8e >>>> Macintosh file type code(s): N/A >>>> >>>> Person & email address to contact for further information: >>>> Sean Leonard >>>> >>>> Intended usage: COMMON >>>> >>>> Restrictions on usage: None. >>>> >>>> Author: >>>> RSA, EMC, IETF >>>> >>>> Change controller: The IETF >>>> >>>> Provisional registration? (standards tree only): No >>>> >>>> >>>> >>>> _______________________________________________ >>>> media-types mailing list >>>> media-types@ietf.org >>>> https://www.ietf.org/mailman/listinfo/media-types >>>> >> --------------ms030004020303030104030100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MjQwOTU0MzlaMC8GCSqGSIb3DQEJBDEiBCDg/OSWtiZwTMa+a3T+hu0dlmq9MJ1TZhVOjxF1 Q8DONzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQCiq17o1yxyIrVaZ1ix KMBjFilLvHi4q6ORHL7pf0/z2LyPLKhcLa2gTEfC5dSSLC71o0qodzjqfku1lCM7Z0w+K+5V NMGqQnqeC8gmHJBMDIk9XEecSs/PduenpGi7gZXJdB+mywvoOpz/8q1OoNillZ66gFgbGFDV BF2Yrv3lCLbgz2AS9LAxdOL3btKz/yi15GKM6xlGNc9+lB9DJ+rIq4rQQw/sNR7Pgc5GF5Zs Is0Fogh0xu9ArHTaSl7Fr1VnfQODyTA7l+SOBLoCqi0muXrV0nXeu6ZHnQazkh0Czt6bKNcV RfLcXDq/4+3h1eZXvPoDtnLQUprEHFmLjug6AAAAAAAA --------------ms030004020303030104030100-- From nobody Tue Nov 24 02:18:15 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E931B2F1E for ; Tue, 24 Nov 2015 02:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.964 X-Spam-Level: X-Spam-Status: No, score=0.964 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=no 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 v2wxgxpDrj2c for ; Tue, 24 Nov 2015 02:18:05 -0800 (PST) Received: from pechora8.dc.icann.org (pechora8.icann.org [IPv6:2620:0:2830:201::1:74]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9861B2F22 for ; Tue, 24 Nov 2015 02:18:04 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0091.outbound.protection.outlook.com [104.47.126.91]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id tAOAHf5i013570 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Nov 2015 10:18:03 GMT Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS1PR01MB0134.jpnprd01.prod.outlook.com (10.161.228.15) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 24 Nov 2015 01:31:13 +0000 To: Sean Leonard References: <5641BCB5.4060409@it.aoyama.ac.jp> From: "=?UTF-8?Q?Martin_J._D=c3=bcrst?=" Organization: Aoyama Gakuin University Message-ID: <5653BDDB.9020203@it.aoyama.ac.jp> Date: Tue, 24 Nov 2015 10:31:07 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR0201CA0005.apcprd02.prod.outlook.com (25.164.90.143) To OS1PR01MB0134.jpnprd01.prod.outlook.com (25.161.228.15) X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0134; 2:W2NvGTHtSc+yEXu7AKKwZcYaKX+IOPDe8x/4NmsC0B31wF988MUOHoIAxw3KG1Q+IIG/PUsxvilc6LdpsS/WuBOuyrB/mDDkvZaZqGHe0FRMI1w95Kyeh6NSaa4uClC1quTE9VLfGMbguvm6y9ceKg==; 3:7rLu3gLygXN6iF6V5mfqRJbi/w76tn3YykdkTyRhEqE90sSkowjUn1wm6Xs3ePFK6q24BDb0F9sYUu99F4/pW1BFLlBJ0+gS/y1My0rJwQsVTb1Js9Vxtwoja8zJgZjY; 25:QIWO7K8/6t7nYQf9hvZHxwOw6cHYegHbweqd61e15ZDkAPaUGASP+vUW8coU4C91x+cOxC/ZBOO4sQ4tGqj3XheRbUFcdMJWQ+TIIDv2Xo/japNgt5IQKvft2KoWXIR0QfZ/6+dHS/NzoiXqAkB9ZjaSDdzuWE/KR3z4nuz/9L10lXDYSezvO3U2Ox55uJfdTqiyBVi7UXv/aHOgNKTvVgmwmAfYlitgMwiZwkvhg8Y943ruP1kfz90uMQydHiUVWJ+/Qche67n8GoMbGECYSg==; 4:9dQzNy5gaSsIXTNCy60ApZHekKg/3fBOWCgN2BvHuJBJE2IrisAPGl0yU7B+jmW36vMmi0QWTgcU65uFAaMvXfAeyA7w+Nm3vsnU3UBKHePv7Ks/+pBLrEBBcJILf4pQ/5o9uZqX/O6ZHDaBPu/rc1uWGz8yT0KokmNetbTIc3ailLUJG1uAi8ad+ZBj5QY82SXIWVIUUnYZf6411q4IxPxxS81+Q5oUpHdt/EF6Y4o24E8YaEswSEbaf4sHfgXO5T2lYQg0Jg2+EAm1JrWCVxIVHmFH8vB81RYAlq1AVLEg4lUQagKWjZFF7wzSrqYPSitv8gj2P9KvmWPtkTlKBEwsgZA8ckfP7wk+Q1aw6Civprb1ylUFOMDgqh9Oeh8B X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0134; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:OS1PR01MB0134; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0134; X-Forefront-PRVS: 0770F75EA9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(24454002)(189002)(52034003)(377454003)(479174004)(15594002)(199003)(51444003)(87976001)(87266999)(40100003)(59896002)(15975445007)(5007970100001)(5004730100002)(50466002)(106356001)(74482002)(561944003)(54356999)(77096005)(189998001)(83506001)(110136002)(2950100001)(5001960100002)(122386002)(4001350100001)(86362001)(23676002)(92566002)(19580395003)(19580405001)(33656002)(81156007)(80316001)(101416001)(65816999)(3846002)(105586002)(551544002)(50986999)(5008740100001)(66066001)(65956001)(97736004)(76176999)(42186005)(64126003)(586003)(6116002)(65806001)(47776003)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0134; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzFQUjAxTUIwMTM0OzIzOmhOanNoVHpHZUgwZTdvaDlscEE2WDB0ZVNP?= =?utf-8?B?ZXhMSXdaVnBEaGxTQlJEN3dXRy9RTzdyNk1lcm12eGVaMWRhL2drVFoyZktD?= =?utf-8?B?dXNQRjdUNlJSMjNURC9TUVlYaEc0a29uaGxPVTFkREgwMHVXUHNaMXFWVzh4?= =?utf-8?B?bU40eVBXSm5vRVVJeWRRd3ZGblJLRDFlbzFLcGhuQk1SV2IveXB4TWNvWGlr?= =?utf-8?B?bkluNXNxcmZESHZMcUI4bU1IUTBpSklWOXlGNmVXMVcyRzhxRFEvdHV6VXRZ?= =?utf-8?B?eTRtcVJFUlB3dE9ucjFUQWhHSEg2OEdrV0FnRWZ5SXJXenEyZ1k3NjlTY01y?= =?utf-8?B?K2NJdHA3WXd4cVhpUjg5a1k3OGI4a1ZuQUtjb21lS3ZoTXlkSklZbGpMdWJi?= =?utf-8?B?bitiR0g5bW1SaGdhSHpSVW9FUUFERWhUV3dKZDVDRG9IK0h6UU5VL1ZBL3ZY?= =?utf-8?B?UmRTQTM0cm1WMWNWdGhnb2NXLzJCbFVnczk3WlJPb1lucXFqbUZpb1VLZGVR?= =?utf-8?B?YUJxeUZ2M0M3VHJPZ21TMXVjTHFxYXBSYlBpQjZyZzhyMjBMa3pXM1oyUytW?= =?utf-8?B?MmpXYW5LbVhoUVIrRTRDQzVTWTdjejZISVU0Zk4wR0J2ei90bXg5dHg1Tkt6?= =?utf-8?B?dTV2K2luK0gzYnIyRmNXYmszd3pEdkpKMzFzQ3VhdDMyM3p4MG1IVTZCYnJE?= =?utf-8?B?VHJScDZEcmhJNVZISzdqQVRYTmlkV3hHc2FRaEFRNmtYTTRvNDRwYk9WMUIy?= =?utf-8?B?MEtzVll5ayszVmw5R3hzbUI0YUt3eG41SmdqOEt3dmVrWTBReTh0QW5lUEQ1?= =?utf-8?B?a0Nzek4zV25SRE81blJvMnRtczVzcEcyWG9Oc2RLV3VGZ1NkaUVVRnN4REdP?= =?utf-8?B?eFB4c1N4K2ljTG9IT1l2WUY0Z2F4VEVQWGdKaWV0WmFkRk1SZkU2K0MrSEFC?= =?utf-8?B?c3dvTVpNc2lQNHY0LzlUUys3SnpoVndhRFl2V3VtM0s2aUpLdHBDZjFUV3ZU?= =?utf-8?B?SDBHOGo1bGpVb2tDVnVOUGFzVTdCd2FQemp4cDVtVVpjbVQ3STc5SGtCREp5?= =?utf-8?B?Y0tTVmM1SGJSeXZmMEFkVlFWb0NXNXh1Zk1TRUtHQkdpakhyaVZ2WUk3emJ0?= =?utf-8?B?TnpNMEFOT1l4aWNOVmhtM2w1bHJjdko5TDJBSTk3ajF3dlp6L2I3NWdjY3I4?= =?utf-8?B?TkNqZUZyRHFGM3A3Yi9wbEVZejYyUzlyVE5IelkzV0FQYjVBOGlvUGVOV25m?= =?utf-8?B?c0JUc2VLZ3NZdnVHNjM2WlRzdHM0aDZTU0doMHNRQ0lwR3VSb0ZQWStWREJV?= =?utf-8?B?NGpsM3JIaXlPMlYzYkpKbDJ3bXVkczlGajVqaFVXWXFFRHNLT1N6Z0R3aGdy?= =?utf-8?B?VEt0blNhR1UzNnphWm9KYTBLbENMV0kxMTNwcXdoZFZHNitYWi9neFdzdGUx?= =?utf-8?B?ZmNWQkpNcDd5LzhBMjZxOHlCMGdubkVSemJqRUI1Z2taekNsaEtnc2g4WE5z?= =?utf-8?B?UDVDU1VBZE8vbDVhSlVrU25nVFFMeG5rMm5xQUhsNkNCN0hxOHJDUWR5a3Fs?= =?utf-8?B?dmREOTc1MksrVzJsTXBUd2g1anpFZTdyV1c0YzQxb3FlcmFsR0VWbldQM1lW?= =?utf-8?B?VzBrNVVjbDBSRWdhNEZ5TlhoTGMvWkdSVU5MMk5EeWtRYUhTSE85ejNZQzJx?= =?utf-8?B?WTFxeVEzSGZwUFgxNG9FVTlGZnhkMHFKS0ZMbVIyU0FRSTdZYVAvY2FyMGk3?= =?utf-8?B?NnFiTXlWR2xFanE4dURrVjZMQ0xIUndMcTk3anZ5V3NsSDVobDlHTEdRVUxx?= =?utf-8?B?NXYwaTRTcytadWZrdExyQUZTQkdldkpMVkJneFBGVTdBVFNEa2Q4V3ZOT3Bw?= =?utf-8?B?SklCQjlnenFuZWJYSzBxRWsrYnpNZ0xuSVFjUlpPOXZBblAxMnJ2SWh5cGtB?= =?utf-8?Q?gizTzW/QJIEhQcqgujnuWUsO7apRYI=3D?= X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0134; 5:e4hc9g+H/SDK3OMD8LnYArH8GeUqHGKt7gl0clQGv0Iu7WgsRvqNN7ec2dtP2rPGC3zRnnZBBoxKyOpVnnMpR2eP6fE7CNDhWPmKftk8frZLVXlFfTtCUaPaNfJmzicXENEExF5SeGm4G0JUi7eHGg==; 24:rRXzIDi3uW4mA4SxnQxXmKq6fAXwFQxMjVagvfDCNa4FjcXJIN5hmwioWGWU1TLgipolp0Tysrb4OMMYG8XLbvJKGK4VjWuTEJV6kUs4AuQ=; 23:AOIv86OanXoQ9aW4T7Xna7ymvp7+yJjO/vRhnwod1OUE45e1NpQpnqVyCM6TfETXSvViZ84BQ5XPPA/uhpZXrjfMbFi4c2WYD1O9/Iag04s/xnriZ+ZpdOrQjHiNjHm0AXMTyQ2DSuYSqxvHnqk+gWGLYpFQQzMKk1dXm4N3P7r/WtFoRjAlMocNwzXk/eDM SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2015 01:31:13.1686 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0134 X-OriginatorOrg: it.aoyama.ac.jp X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Tue, 24 Nov 2015 10:18:04 +0000 (UTC) Archived-At: Cc: "media-types@iana.org" , "precis@ietf.org" Subject: Re: [media-types] Internet media type application/pkcs8-encrypted rev 2 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 10:18:14 -0000 Hello Sean, I have cc'ed the precis mailing list because some of what I'll write below is relevant for the discussion you have started there. This is also the reason why I'm keeping most the previous context. On 2015/11/11 00:25, Sean Leonard wrote: > Hello Martin, > > On Nov 10, 2015, at 1:45 AM, Martin J. Dürst wrote: > >> Hello Sean, >> >> I have a few questions re. your registration below. >> >> On 2015/11/05 14:57, Sean Leonard wrote: >>> Hello: >>> >>> To keep this moving, trying a different thing. Please review. >>> >>> Sean >>> >>> ***** >>> >>> Type name: application >>> >>> Subtype name: pkcs8-encrypted >>> >>> Required parameters: N/A >>> >>> 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. >> >> Why does it say "This parameter specifies the charset that a recipient SHOULD attempt *first*" here? Can't that encoding just be specified as such? >> >> At least for future, similar efforts, it would be extremely desirable to not leave character encoding open like this, but just to nail it down to UTF-8. > > There seems to be something of a “cultural disconnect” between the security people and the I18N/UI/UX people. > > The I18N/UI/UX people want well-defined interfaces that work with users “in their own language”, whether that language is visual, aural, tactile, symbolic, pictorial, etc. Invariably this involves Unicode and a large character repertoire such as 💩 and 大便所. > > In contrast, the security people find open-ended things like Unicode to be anathema and would much rather restrict the range of inputs to a small and preferably uniformly distributed set of values. And there are good reasons for that, because when you introduce bias into cryptographic protocols, it turns out that it is a lot easier to cryptanalyze the results. > > The common security protocols that I have seen that take passwords, hand-wave about character sets and encodings and define the password to be an octet string. This is great for universality but bad for human input. PBKDF2 (PKCS #5, on which this PKCS #8 EncryptedPrivateKeyInfo registration is based) is a leading example of the “octet string” approach. Ultimately, the algorithms don’t care what encoding it’s in, as long as they get a blob of bits (octets). > > My knowledge of implementations of PKCS #5/#8/#12 suggests that there are many applications out there that give zero thought to the encoding issue, which means that they will take user input “As-Is”, i.e., in the current code page. > > Note that PKCS #12 defines the input to this structure as a UTF-16LE encoded character string, *with* a terminating U+0000 NULL character (i.e., the octets 00 00). This is really “weird” except of course for the fact that Microsoft invented it and then shipped it without too much thought, in which case, all weirdness can be explained. > > It is a design criteria that if you extract such an EncryptedPrivateKeyInfo blob from a PKCS #12 file, that you should be able to process it. If you specify UTF-8 as the one, single, true encoding of the password for application/pkcs8-encrypted, that can’t happen. That's just fine, in this specific case. I have explicitly prefaced my remark above with "At least in the future". But if we know that the password is encoded in UTF-16LE, then why doesn't your registration just say "This parameter specifies the charset" rather than the handwavy "This parameter specifies the charset that a recipient SHOULD attempt *first*". > Furthermore, UTF-8 is not uniformly distributed across the octet range. If your users are in US-English they are highly likely to have octets in 20-7E. Octets in 00-1F will be pretty rare. And if you choose scalar values randomly in Unicode (regardless of assignment), you will see a *lot* of F0-F4 but virtually none in 00-7F. And in spite of all this, octets F5-FF will *never* appear in UTF-8. > > It turns out that we have a pretty good source of uniformity and universality: characters in the US-ASCII range 20-7E. Many password input boxes will only accept US-ASCII and so user’s non-US-English keyboards will switch to US-ASCII mode for the purpose of providing input to such boxes. What matters is not so much the specific characters, so much as a reasonable selection of arbitrary buttons that a user can push *across a wide range of devices*. This ends up giving you 5-6 bits of entropy per user input. So the need for UTF-8 or any particular encoding is actually not as great as some people perceive. My comment was specifically trying to say: If you use something more than US-ASCII, make it UTF-8. I think that's also the general policy of the IETF. As for entropy, the entropy needs to be measured over the whole string. It's clear that in UTF-8 bytes, a password in the ASCII range is shorter than a similar-length (in terms of charaters) password in a non-Latin script. The entropy of each byte will be lower, but the entropy of the overall password should be about the same. Something that's very important for passwords is how easy they are to remember for actual people. It should be obvious that it's easier for somebody to remember a password in the language/script they use every day than in some foreign gibberish. > Overall I think that a standard such as IEEE 802.11 strikes a reasonable balance. (See 802.11-2012 Annex M.4, which is informative, but is pretty much the worldwide de-facto standard practice.) In 802.11, the input to PBKDF2 is between 8-63 ASCII-encoded characters in the range 20-7E, or 64 hexadecimal characters that convert directly to 32 octets. So it's up to 63 ASCII characters but only up to 32 octets that may e.g. be used for UTF-8? That doesn't strike me as a reasonable balance; it puts a much stronger length limitation on some scripts outside ASCII. > *** > To answer your questions directly: >> Why does it say "This parameter specifies the charset that a recipient SHOULD attempt *first*" here? >> Can't that encoding just be specified as such? > > > The parameter is not cryptographically protected so it is subject to tampering or substitution. Furthermore, a good-faith but naïve sender may put some encoding (e.g., UTF-8) but not have the means to verify that the encoding actually works, because the user did not supply the password. Basically it’s a good-faith first effort, but this parameter can’t meaningfully restrict what the sender or receiver attempt to do. That essentially applies to any single parameter in any single media type registration, and in much more of what the IETF does. Yet this is virtually never called out, because otherwise, IETF documents would be full of such stuff and very hard to read. > Also, I am not sure how to specify the NULL suffix in the PKCS #12-extracted case. That may suggest that you are going down the wrong path here. > I suppose it could just be “+0” or something. > >> >>> 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. >> >> "When the charset is": Is this the charset parameter, or the actual encoding of the password? > > Admittedly this was vague. First draft. I am not sure what it should be. Per PKCS #5, the "Actual Encoding" is just an octet string of arbitrary length. > > I would limit this to cases when the charset parameter is present and defined. Makes it easier. > >> >> What is a "Unicode algorithm”? > > Conformance Clause D17. Well, this, via the term "Named Unicode Algorithm" points to table 3.1 (page 93 in Unicode V 8.0). >> Reading on and looking at the examples, the intent becomes clearer, at least to somebody who has seen things such toNFD and toNFKC and Casefold, but I hope we can avoid "specification by example" here. > > In fairness, “toNFD” and “toNFKC” are not defined terms. However, NFD (D118) and NFKC (D121) are. Yes, but not as (Named) Unicode Algorithms. > I would rather not create Yet Another Registry of things. I'd agree in principle. > The terms are in fact defined in [UNICODE] in the conformance clauses. Yes, but there are many other things defined there, too. > My usability perception is that if people really want to use Unicode in their passwords, canonicalization is a very useful property to preserve. Case folding/case mapping are not so useful, as most systems like to have case-sensitive passwords for greater entropy, but “most systems” is not “all systems” so we shouldn’t preclude the use of case algorithms. As for other algorithms such as line breaking, character segmentation, Hangul syllable name generation, etc., the short answer is “I don’t know”. (These are all reasons why people stick with ASCII passwords, by the way.) Line breaking, character segmentation, Hangul syllable name generation,... are completely irrelevant for passwords and passphrases. Also, many algorithms come with options or parameters. >> Also, if there is indeed a list of algorithm identifiers in [UNICODE], then it would be good to give a Section number. Is the intent that each and every algorithm named somewhere in [UNICODE] is implemented? My rough guess would be that the average password input implementation implements only the identity transform. [I would of course be positively surprised if I were wrong.] > > See above; main thing that worries me is Normalization Forms. > >> >> Also, references for [UNICODE], [BCP47], and [UAX31] should be give so that this registration is self-containing. > > Ok. > > Another possibility is that this registration goes back to “rev 1”, i.e., no optional parameters about the character encoding at all. I think that is perfectly defensible. But it is not particularly i18n-friendly. I'm not sufficiently familiar with the format and the actual use cases, but my suggestion would be to check what's actually out there in the field (such as the Microsoft UTF-16LE including final NULL), and select or create a list of parameters/algorithms (with a registry if it turns out to be needed). To that, add a way to reference PRECIS, even if it's not currently used, because that includes the expertise/recommendations of experts. The current proposal just essentially saying: Unicode may define some of the pieces you may want to use here, and may have labels for them, so just give it a try. I'm not at all sure this will help interoperability, except by similar accidents like the Microsoft one that you described above. Regards, Martin. > Regards, > > Sean > >> >> Regards, Martin. >> >>> Encoding considerations: binary >>> >>> Security considerations: >>> Carries a cryptographic private key. See Section 6 of RFC 5958. >>> EncryptedPrivateKeyInfo PKCS #8 data contains exactly one private key. Poor password choices, weak algorithms, or improper parameter selections (e.g., insufficient salting rounds) will make the confidential payloads much easier to compromise. >>> >>> Interoperability considerations: >>> PKCS #8 is a widely recognized format for private key information on all modern cryptographic stacks. The encrypted variation in this registration, EncryptedPrivateKeyInfo (Section 3, Encrypted Private Key Info, of RFC 5958, and Section 6 of PKCS #8), is less widely used for exchange than PKCS #12, but it is much simpler to implement. The contents are exactly one private key (with optional attributes), so the possibility for hidden "easter eggs" in the payload such as unexpected certificates or miscellaneous secrets is drastically reduced. >>> >>> Published specification: >>> PKCS #8 v1.2, November 1993 (republished as RFC 5208, May 2008); RFC 5958, August 2010 >>> >>> Applications that use this media type: >>> Machines, applications, browsers, Internet kiosks, and so on, that support this standard allow a user to import, export, and exercise a single private key. >>> >>> Fragment identifier considerations: N/A >>> >>> Additional information: >>> >>> Deprecated alias names for this type: N/A >>> Magic number(s): None. >>> File extension(s): .p8e >>> Macintosh file type code(s): N/A >>> >>> Person & email address to contact for further information: >>> Sean Leonard >>> >>> Intended usage: COMMON >>> >>> Restrictions on usage: None. >>> >>> Author: >>> RSA, EMC, IETF >>> >>> Change controller: The IETF >>> >>> Provisional registration? (standards tree only): No >>> >>> >>> >>> _______________________________________________ >>> media-types mailing list >>> media-types@ietf.org >>> https://www.ietf.org/mailman/listinfo/media-types >>> >