Storing validation parameters in PKCS#8
draft-mavrogiannopoulos-pkcs8-validated-parameters-02

Abstract

This memo describes a method of storing parameters needed for private key validation in the Private-Key Information Syntax Specification as defined in RFC5208 (PKCS#8) format. It is equally applicable the alternative implementation of the Private-Key Information Syntax Specification as defined in RFC 5958.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 30, 2018.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

RSA or DSA private keys generated using the Shawe-Taylor prime generation algorithm describled in [FIPS186-4] allow for parameter validation, i.e., verify whether the primes are actually prime, and were correctly generated. That is done by generating the parameters from a known seed and a selected hash algorithm.

Storing these parameters in a private key format such as the RSA Private Key Syntax from PKCS#1 [RFC8017], or common representations for DSA private keys, does not allow attaching information on the parameters needed for validation. The purpose of the document is to describe such a method using the Private-Key Information Syntax Specification as defined in [RFC5208], as well as on the alternative specification on [RFC5958].

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.

3. ValidationParams attribute

The information related to the validation parameters is stored as an attribute in the PrivateKeyInfo structure. The attribute is identified by the id-attr-validation-parameters object identifier and contains as AttributeValue a single ValidationParams structure.

  id-attr-validation-parameters OBJECT IDENTIFIER ::=
                                           {1 3 6 1 4 1 2312 18 8 1}

  ValidationParams ::= SEQUENCE {
      hashAlgo OBJECT IDENTIFIER,
      seed OCTET STRING
  }

The algorithm identifier in the ValidationParams should be a hash algorithm identifier for the [FIPS186-4] methods. The ValidationParams sequence must be DER encoded [CCITT.X690.2002].

4. Example Structure

The following structure contains an RSA key generated using the [FIPS186-4] section B.3.3 algorithm with SHA2-384 hash. The seed used is '8af4328c87bebcec31e303b8f5537effcb6a91d947084d99a369823b36f01462' (hex encoded).

5. Compatibility notes

For compatibility it is RECOMMENDED that implementations following this document, support generation and validation using the SHA2-384 hash algorithm.

The extension defined in this document is applicable both to the Private-Key Information Syntax Specification defined in [RFC5958] and PKCS#8 [RFC5208].

6. Security Considerations

All the considerations in [RFC5208] and [RFC5958] apply.

7. IANA Considerations

None.

8. References

8.1. Normative References

[CCITT.X680.2002]	International International Telephone and Telegraph Consultative Committee, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", CCITT Recommendation X.680, July 2002.
[CCITT.X690.2002]	International International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002.
[FIPS186-4]	Kerry, C. and P. Gallagher, "FIPS PUB 186-4: Digital Signature Standard (DSS)", FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION , July 2013.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5208]	Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2", RFC 5208, DOI 10.17487/RFC5208, May 2008.
[RFC5958]	Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010.
[RFC8174]	Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

8.2. Informative References

[RFC5912]	Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010.
[RFC8017]	Moriarty, K., Kaliski, B., Jonsson, J. and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016.

Appendix A. Acknowledgements

The author would like to thank Russ Housley for his comments and for the ASN.1 module appendix.

Appendix B. ASN.1 module

This appendix provides non-normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [CCITT.X680.2002] and [RFC5912].

   PrivateKeyValidationAttrV1
     { iso(1) identified-organization(3) dod(6) internet(1)
       private(4) enterprise(1) 2312 18 1 1 }

   DEFINITIONS IMPLICIT TAGS ::=

   BEGIN

   -- EXPORTS ALL

   IMPORTS

   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) } ;

   -- PrivateKeyInfo is defined in [RFC5208].
   -- This definition adds the validation parameters attribute
   -- to the set of allowed attributes.

   PrivateKeyInfo 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 OBJECT IDENTIFIER,
     seed OCTET STRING }

   END

Author's Address

Nikos Mavrogiannopoulos Red Hat, Inc. Brno, Czech Republic EMail: nmav@redhat.com

1. Introduction
2. Terminology
3. ValidationParams attribute
4. Example Structure
5. Compatibility notes
6. Security Considerations
7. IANA Considerations
8. References

8.1. Normative References
8.2. Informative References

Appendix A. Acknowledgements
Appendix B. ASN.1 module
Author's Address