ISE write-up for: draft-seantek-pkcs8-encrypted-03
Abstract:
"This document registers the application/pkcs8-encrypted media type
for the EncryptedPrivateKeyInfo type of PKCS #8. An instance of this
media type carries a single encrypted private key, BER-encoded as a
single EncryptedPrivateKeyInfo value."
This draft documents a request to register Media Type,
application/pkcs8-encrypted.
That request was Discussed on the media-types list; Ned Freed (the
designated Expert Reviewer for this) discussed it in August-September
2016. IANA reported that the media type was approved (by Ned), and
are now waiting for this draft to be published as an RFC.
The draft was reviewed for me by Barry Leiba, and Pete Resnick took
part if further discussions with its author (Sean Leonard) over it's
internationalisation aspects.
It's author has worked with the reviewers to address all the issues
they raised.
- - - - - - -
Barry Leiba's review
Especially given that there's no Introduction, it might be good to say
something clearer than "for use with". Do you mean that this media
type carries an EncryptedPrivateKeyInfo unit? Can it carry anything
else as well, or instead? If the entire content of an instance of
this media type is a single EncryptedPrivateKeyInfo unit, and nothing
else, you should clearly say that. If that's not it, then you should
be clear about what, exactly, it is.
Section 1:
The key word "SHOULD" in this document is to be interpreted as
described in [RFC2119].
You use "SHOULD NOT" and "RECOMMENDED" as well.
Section 2 (the first one):
When the encryption algorithm incorporates a
"password" that is an octet string, a mapping between user input
and the octet string is desirable.
I have a few problems with this sentence. First, what does << the
encryption algorithm incorporates a "password" that is an octet string
>> mean? Does it mean that the algorithm uses a password as part of
the operation of the algorithm? Can you say this more clearly? This
leads one to believe that the password is actually carried in the
media type; it would be good to be clearer about where the password
comes in.
Second, could there be a password that is *not* an octet string?
Maybe you mean << the encryption algorithm uses an externally supplied
octet string (a "password") >> ?
Third, I don't know what you're getting at when you say << a mapping
between user input and the octet string is desirable >>. There
clearly has been a mapping, or we wouldn't have an octet string.
Maybe you mean that it's desirable to *specify here* the mapping that
was/should be used? Can you say this more clearly also?
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.
I'm not sure what you're recommending here. You're telling us what
PKCS#5 says, but you're not telling us what, if anything, we should do
with that information, nor why PKCS#5 is relevant here. (In any case,
I certainly don't think 2898 should be a normative reference here;
it's at most an informative reference, and might stand to be removed
entirely.)
Otherwise, the value of this parameter is a charset, from the IANA
Character Sets Registry [RFC2978].
Pointing to 2978 isn't right here. If you want a reference that
explains what a "charset" is, you can find better ones; 2978 is
primarily telling you how to register new charsets. If you want a
reference to the registry, use the registry's URI
<http://www.iana.org/assignments/character-sets>
If you do retain the 2978 reference, make it informative.
To be sure to avoid confusion, it might be good to point out that the
special values all begin with "*", perhaps as << The following special
values, which all begin with "*" to distinguish them from registered
charsets, are defined: >>.
Published specification:
PKCS #8 v1.2, November 1993 (republished as RFC 5208, May 2008); RFC
5958, August 2010
Why is 5208 still relevant, as 5958 made it obsolete?
Section 2 (the second one):
This and subsequent sections are mis-numbered.
A note to Nevil: RFC 6838 says, about media-type registrations in the
Standards Tree:
Registrations published in non-IETF RFC streams are also allowed and
require IESG approval.
In other words, apart from the normal conflict review, this requires a
management item for the IESG to approve the registration explicitly.
I would think that Alexey would ask the media-types experts for their
input on that, even if it isn't strictly required.
Section 4:
As noted above, I think this about the references:
2898 should probably be removed, and should be informative if it remains.
2978 should probably be removed, and should be informative if it remains.
5208 should be removed, as it's obsolete. It certainly shouldn't be
normative; the normative reference is now 5958.
- - - - - - -
Pete Resnick's comment(s) on internationalisation
It's not clear that the password-mapping parameter does what the
author thinks it does. What you would really want out of a
password-mapping parameter is the answer to, "What input method was
used to type in this password and what character encoding does the
output of that method represent?" But you're not getting that. While
the precis profile names let you know that the string conforms to
Unicode Normalization Form C (NFC), and therefore the input method
doesn't really matter, neither the pkcs12 nor any of the CHARREG
character sets provide you with enough information to determine what
you're dealing with: You could have an NFC string, or an NFKC string,
or an NFD string. If you're not getting that information from the
parameter, then it's not clear why this is at all useful to register,
as it's really not much better that guessing.
- - - - - - -