This document was briefly discussed on the SAAG list where it met no
opposition. Some additions were suggested, but the author preferred to keep the
scope as was.
Reviews were received from Russ Housley and Stephen Farrell (see below) and an
updated revision was produced.
The author originally considered this document an update to 5208 and 5958, but
on discussion this was only because he wanted to flag the connection between
the documents. Sadly we have no metadata for that so he is reduced to
describing the connection in the Abstract and Introduction. It is clear that
the process he describes is an implementation option.
At the request of the IESG (at the time of their conflict review), this
document was also taken to SecDispatch. A mail to the WG mailing list attracted
no attention over a four week period. A lengthy discussion at the WG meeting at
IETF-102 concluded that the meeting strongly supported publication via the
Independent Submissions stream.
Late edits wee made to clarify that this is not a standard.
===Russ's review===
The ISE asked me to review this Internet-Draft.
Document: draft-mavrogiannopoulos-pkcs8-validated-parameters-00
Reviewer: Russ Housley
Review Date: 2017-12-20
Summary: Accept and publish after the comments are addressed
Major Concerns:
RFC 5958, "Asymmetric Key Packages", obsoletes RFC 5208. So this
Internet-Draft should point to RFC 5958 instead of RFC 5208. Please
note that RFC 5958 is a Standard Track RFC, but RFC 5208 was an
Informational RFC. One significant change in RFC 5958 will have
an impact on this document: the name "PrivateKeyInfo" was changed
to "OneAsymmetricKey". That said, for backward compatibility the
ASN.1 module in RFC 5958 includes:
PrivateKeyInfo ::= OneAsymmetricKey
Section 3 includes this structure:
ValidationParams ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
seed OCTET STRING }
Please replace "algorithm" with "hashAlg" to make it clear that
this is a hash algorithm. Also, please replace "OBJECT IDENTIFIER"
with "AlgorithmIdentifier" so that parameters can be provided if a
future hash algorithm needs them.
To aid implementers, please include a full ASN.1 module in an
appendix. Please see below for a suggested ASN.1 module. If an
object identifier is assigned for the module, it compiles properly.
Minor Concerns:
The document seems to mix "validation parameters" and "validated
parameters". I think the document should use "validation parameters"
throughout. (Note: In the ASN.1 module that I offer, I took the
liberty of using "validation" in many places. In addition, I used
the AlgorithmIdentifier{} definition from RFC 5912 require the use
of a hash algorithm (a.k.a. a digest algorithm).
Editorial Comments:
Some lines exceed the 72 character limit.
Suggested Appendix:
This appendix provides the normative ASN.1 definitions for the
structures described in this specification using ASN.1 as defined in
[X.680], [X.681], [X.682], and [X.683].
PrivateKeyValidationAttrV1
{ TBD }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL
IMPORTS
AlgorithmIdentifier{}, DIGEST-ALGORITHM
FROM AlgorithmInformation-2009 -- [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
ATTRIBUTE
FROM PKIX-CommonTypes-2009 -- [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ;
-- OneAsymmetricKeyAttributes is defined in [RFC5958].
-- This definition adds the validation parameters attribute
-- to the set of allowed attributes.
OneAsymmetricKeyAttributes ATTRIBUTE ::= {
at-validation-parameters, ... }
at-validation-parameters ATTRIBUTE ::= {
TYPE ValidationParams
IDENTIFIED BY id-attr-validation-parameters }
id-attr-validation-parameters OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 2312 18 8 1 }
ValidationParams ::= SEQUENCE {
hashAlg AlgorithmIdentifier { DIGEST-ALGORITHM, {...}},
seed OCTET STRING }
END
Suggested Additional Normative References:
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
June 2010.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
August 2010.
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.
Information Technology - Abstract Syntax Notation One.
[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002.
Information Technology - Abstract Syntax Notation One:
Information Object Specification.
[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002.
Information Technology - Abstract Syntax Notation One:
Constraint Specification.
[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002.
Information Technology - Abstract Syntax Notation One:
Parameterization of ASN.1 Specifications.
===Stephen's review===
It looks like it could be reasonable. I don't have
code to check it against though, so I can't say if
it's correct really. (Esp given that it's most just
a "here's a thing you can do" spec.)
I'd say best would be to send a mail to the saag
list to ask if anyone has done this and if so if
the spec looks right.
If not already suggested, I'd say asking Russ, Jim S.,
Tero and Yoav for comments might be useful.
I'm not sure a more detailed review from me would
be that useful as I'd likely not have time to check
if the text matches real code or not, which is really
the main thing for this I'd say. (If it does, then
an RFC is useful. If not, such an RFC would be the
opposite;-)
I'm not sure I'd bother with the "updates 5208"
tag for this - if that is warranted, then I think
the text should have an argument that pkcs#8 code
ought generally support this, but I'm not clear
that that's generally the case if this is really
just a FIPS186 related thing. (I'm not in the set
of folks who think abiding by FIPS things is that
generally useful unless one is forced to pay
attention to that.;-)