Re: [precis] [media-types] Internet media type application/pkcs8-encrypted rev 2

Martin J. Dürst <duerst@it.aoyama.ac.jp> Tue, 24 November 2015 01:31 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9C01B2B53 for <precis@ietfa.amsl.com>; Mon, 23 Nov 2015 17:31:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.098
X-Spam-Level: *
X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 5O_Pu-UAgy87 for <precis@ietfa.amsl.com>; Mon, 23 Nov 2015 17:31:19 -0800 (PST)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0111.outbound.protection.outlook.com [104.47.126.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7781D1B2B51 for <precis@ietf.org>; Mon, 23 Nov 2015 17:31:18 -0800 (PST)
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 <dev+ietf@seantek.com>
References: <F2EFBAE2-DD4E-4E33-A8FB-B4402ABBF086@seantek.com> <5641BCB5.4060409@it.aoyama.ac.jp> <F0194F3F-46B7-401F-A2E8-118EFBE1C39C@seantek.com>
From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
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: <F0194F3F-46B7-401F-A2E8-118EFBE1C39C@seantek.com>
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: <OS1PR01MB01345C54D086E177E61F99A6CA060@OS1PR01MB0134.jpnprd01.prod.outlook.com>
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: 1;OS1PR01MB0134;23:hNjshTzGeH0e7oh9lpA6X0teSOexLIwZVpDhlSBRD7wWG/QO7r6MermvxeZ1da/gkTZ2fKCusPF7T6RR23TD/SQYXhG4konhlOU1dDH00uWPsZ1qVW8xmN4yPWJnoEUIydQwvFnRKD1eo1KphnBMRWb/ypxMcoXiknIn5sqrfDHvLqB8mMHQ0iJIV9yF6eW1W2G8qDQ/tuzUtYy4mqRERPwtOnr1TAhGHH68GkWAgEfyIrWzq2gY769ScMr+cItp7YwxqXiR89kY78b8kVnAKcomeKvhMydJIYljLubbn+bGH9mmRhgaHzRUoEQADEhTWwJd5CDoH+HzQNU/VA/vXRdSA34rmV1cVthgocW/2BlUgs97ZROoYnqqjmFioUKdeQaBqyFv3C7TrOgmS1ucLqqapRbPiB6rg8r20LkzW3Z2S+V2jWanKmXhQR+E4CC5SY7cz6HIU4fN0GBvz/tmx9tx5NKzu5v+in+H3br2FcWbk3wzDvJJ31sCuat323zx0mHU6BbrDTrRp6DrhI5VHK7jATXNidWxGsaQhAQ6kXM4o44pbOV1B20KsVYyk+3Vl9GxsmB4aKwxn5Jgj8KwvekY0Qy8tAnePD5kCszN3WnRDO5nRo2tms5spG2XoNsdKWuFgSdiEUFsxDGOxPxsSx+icLoHOYvYF4gaxTEPXgJietZadFMRfE6+C+HABswoMZMsiP4v4/9TS+7JzhVwaDYvWum3K6iJKtpCf1TWvTH0G8j5ljUokCVuNPasU7BwaPzjxp5mUZcmT7I79HkBDJycKSVc5HbRyvf0AdVQVoCW5xufMSEKGBGijHriVvYI7zbtNzM0ANOYxicNVhm3l5lrcvJ9L2AI97j1wvZz/b75gccr8NCjeFrDqF3p7b/plEYz62S9rTNHzY3WAPb5A8ioPeNWnfsBTseKgsYvuG636ZTsts4h6SSGh0sQCIpGuRoFPY+VDBU4jl3rHiyO2V3bJJl2wmuds9Fj5jhUWYqEDsKOSzgDwhgrTKtnSaGU36zaZoJa0KlCLWI113pqwhdVG6+XZ/gxWste1fcVBJMp7y/8A26q8yB0gnnERzbjEB5gkZzClhKgsh8XNsP5CSUAdO/l5aJUkSngTQLxnk2nqAHl6CB7Hq8rCQdykqlvdD9752K+W2lMpTwh5jzEe7rWW4c41oqeralGEVnWP3YVW0k5Ucl0REga4FyNXhLc/ZGRUNL2NDykQaHSHO9z3YC2qY1qyQ3HfpPX14oEU9Ffxd0qJKFLmR2SAQI7YaP/car0i76qbMyVGlEjq8uDkV6LCLHRwLq97jvyWslH5hl9GLGQULq5v0i4Ss+ZufktLrAFSBGevJLVBgxPFU7ATSDkd8WvNOppJIBB9gzqnebXK0qEk+bzMgLnIQcRZO9vAnP12rvIhypkAgizTzW/QJIEhQcqgujnuWUsO7apRYI=
X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0134; 5:e4hc9g+H/SDK3OMD8LnYArH8GeUqHGKt7gl0clQGv0Iu7WgsRvqNN7ec2dtP2rPGC3zRnnZBBoxKyOpVnnMpR2eP6fE7CNDhWPmKftk8frZLVXlFfTtCUaPaNfJmzicXENEExF5SeGm4G0JUi7eHGg==; 24:rRXzIDi3uW4mA4SxnQxXmKq6fAXwFQxMjVagvfDCNa4FjcXJIN5hmwioWGWU1TLgipolp0Tysrb4OMMYG8XLbvJKGK4VjWuTEJV6kUs4AuQ=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: it.aoyama.ac.jp
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
Archived-At: <http://mailarchive.ietf.org/arch/msg/precis/RRcypti-7XFKkY4zwOHYlo_w5_0>
Cc: "media-types@iana.org" <media-types@iana.org>, "precis@ietf.org" <precis@ietf.org>
Subject: Re: [precis] [media-types] Internet media type application/pkcs8-encrypted rev 2
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Nov 2015 01:31:23 -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 <duerst@it.aoyama.ac.jp> 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 <dev+ietf&seantek.com>
>>>
>>> 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
>>>
>