Shepherd writeup
rfc8479-04

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.;-)
Back