RFC 7935

The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure

πŸ“… published August 2016, from ietf

RFC 7935 πŸ’– is titled The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure ✨ It's a Standards Track doc from August 2016 (ISSN 2070-1721) πŸŽ€ Written by G. Huston and G. Michaelson, Ed. from APNIC πŸ¦‹ It obsoletes RFC 6485 🫢 and doesn't update anything else.

Abstract 🌈

okay so this doc is the rulebook for the crypto stuff in the Resource Public Key Infrastructure (RPKI) πŸ” It covers the algorithms, their parameters, key formats, key size, and signature format for the RPKI subscribers who sign certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects, and certification requests πŸ’… It also covers the relying parties (RPs) who check those signatures, so everyone's on the same page πŸ‘‘

Status of This Memo πŸ“œ

this is an Internet Standards Track document πŸ”₯

it's a product of the Internet Engineering Task Force (IETF) πŸ’œ It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ For more on Internet Standards, check Section 2 of RFC 7841 🧚

for info on the current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7935 πŸ“

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved πŸ¦‹

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication πŸ’… please read those carefully because they spell out your rights and restrictions πŸ™ˆ Code Components pulled out of this document need to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🫢

Table of Contents πŸ—‚οΈ

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Algorithms  . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Asymmetric Key Pair Formats . . . . . . . . . . . . . . . . .   4
  3.1.  Public Key Format . . . . . . . . . . . . . . . . . . . .   5
  3.2.  Private Key Format  . . . . . . . . . . . . . . . . . . .   5
4.  Signature Format  . . . . . . . . . . . . . . . . . . . . . .   5
5.  Additional Requirements . . . . . . . . . . . . . . . . . . .   5
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
7.  Changes Applied to RFC 6485 . . . . . . . . . . . . . . . . .   6
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction 🌸

this doc specifies four things πŸ‘‘

  • the digital signature algorithm and its parameters;
  • the hash algorithm and its parameters;
  • the public and private key formats; and,
  • the signature format

RPKI [RFC6480] subscribers use all of that when they sign certificates and Certificate Revocation Lists (CRLs) [RFC5280], Cryptographic Message Syntax (CMS) signed objects [RFC5652] (like Route Origin Authorizations (ROAs) [RFC6482] and manifests [RFC6486]), and certification requests [RFC2986] [RFC4211] πŸ¦‹ Relying parties (RPs) use the same algorithms to verify those signatures [RFC6480] πŸ’…

the other RPKI profiles and specs that point at RFC 6485 now point here instead 🫢 That includes the RPKI Certificate Policy (CP) [RFC6484], the RPKI Certificate Profile [RFC6487], the RPKI Architecture [RFC6480], and the Signed Object Template for the RPKI [RFC6488] 🧠 Familiarity with those is assumed, so go read them if you haven't ✨

1.1. Terminology πŸŽ€

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] πŸ™ˆ

2. Algorithms πŸ’…

two cryptographic algorithms are used in the RPKI, and they're the stars of the show πŸ”₯

  • the signature algorithm for certificates, CRLs, CMS signed objects, and certification requests is RSA Public-Key Cryptography Standards (PKCS) #1 Version 1.5 (sometimes called "RSASSA-PKCS1-v1_5") from Section 8.2 of [RFC3447] πŸ”‘
  • the hashing algorithm for certificates, CRLs, CMS signed objects, and certification requests is SHA-256 [SHS] (see the note below) 🌈

NOTE: the exception is SHA-1 [SHS], which CAs use when they generate authority and subject key identifiers [RFC6487] 🧚

in certificates, CRLs, and certification requests, the hashing and signature algorithms get named together, like "RSA PKCS #1 v1.5 with SHA-256" or just "RSA with SHA-256" ✨ The Object Identifier (OID) sha256WithRSAEncryption from [RFC4055] MUST be used in these products πŸ‘‘

where the OID shows up:

  • in the certificate, it appears in the signature and signatureAlgorithm fields [RFC4055] πŸŽ€
  • in the CRL, it appears in the signatureAlgorithm field [RFC4055] πŸ¦‹
  • in a certification request, it appears in the PKCS #10 signatureAlgorithm field [RFC2986], or in the Certificate Request Message Format (CRMF) POPOSigningKey algorithmIdentifier field [RFC4211] πŸ’œ

in CMS SignedData, the hashing (message digest) and signature algorithms are identified separately πŸ’… The object identifier and parameters for SHA-256 (as defined in [RFC5754]) MUST be used for the SignedData digestAlgorithms field and the SignerInfo digestAlgorithm field πŸ”₯ The object identifier and parameters for rsaEncryption [RFC3370] MUST be used for the SignerInfo signatureAlgorithm field when you generate CMS SignedData objects 🫢 RPKI implementations MUST accept either rsaEncryption or sha256WithRSAEncryption in the SignerInfo signatureAlgorithm field when they verify CMS SignedData objects, for compatibility with objects made by implementations that follow [RFC6485] 🌸

3. Asymmetric Key Pair Formats πŸ”‘

the RSA key pairs used to compute the signatures MUST have a 2048-bit modulus and a public exponent (e) of 65,537 πŸ’–

3.1. Public Key Format 🧚

the subject's public key goes in subjectPublicKeyInfo [RFC5280] ✨ It has two sub-fields, algorithm and subjectPublicKey, and here's what goes in each πŸŽ€

  • algorithm (which is an AlgorithmIdentifier type): the object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be used in the algorithm field, as specified in Section 5 of [RFC4055] πŸ¦‹ The value for the associated parameters from that clause MUST also be used for the parameters field πŸ’…
  • subjectPublicKey: RSAPublicKey MUST be used to encode the certificate's subjectPublicKey field, as specified in [RFC4055] 🫢

3.2. Private Key Format 🌈

local policy decides the private key format πŸ”

that's the whole section, so nothing more is required here. Part 2 picks up with Section 4.

8. References ✨

8.1. Normative References πŸ’–

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <http://www.rfc-editor.org/info/rfc2986>.

[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, <http://www.rfc-editor.org/info/rfc3370>.

[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.

[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, <http://www.rfc-editor.org/info/rfc4055>.

[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, <http://www.rfc-editor.org/info/rfc4211>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.

[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, <http://www.rfc-editor.org/info/rfc5754>.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <http://www.rfc-editor.org/info/rfc6480>.

[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 2012, <http://www.rfc-editor.org/info/rfc6484>.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <http://www.rfc-editor.org/info/rfc6487>.

[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, <http://www.rfc-editor.org/info/rfc6488>.

[SHS] National Institute of Standards and Technology (NIST), "FIPS Publication 180-3: Secure Hash Standard", FIPS Publication 180-3, October 2008.

8.2. Informative References 🌸

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <http://www.rfc-editor.org/info/rfc6482>.

[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, DOI 10.17487/RFC6485, February 2012, <http://www.rfc-editor.org/info/rfc6485>.

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, <http://www.rfc-editor.org/info/rfc6486>.

[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <http://www.rfc-editor.org/info/rfc6916>.

Acknowledgments 🫢

The authors acknowledge the reuse in this document of material originally contained in working drafts of the RPKI Certificate Policy [RFC6484] and resource certificate profile [RFC6487] documents. The coauthors of these two documents -- namely, Stephen Kent, Derrick Kong, Karen Seo, Ronald Watro, George Michaelson, and Robert Loomans -- are acknowledged, with thanks. The constraint on key size noted in this profile is the outcome of comments from Stephen Kent and review comments from David Cooper. Sean Turner has provided additional review input to this document.

Andrew Chi and David Mandelberg discovered the issue addressed in this replacement of [RFC6485], and the changes in this updated specification reflect the outcome of a discussion between Rob Austein and Matt Lepinski on the SIDR Working group mailing list. Richard Hansen contributed a significant number of suggestions that have been incorporated into this document.

Authors' Addresses πŸ’œ

Geoff Huston APNIC

Email: gih@apnic.net

George Michaelson (editor) APNIC

Email: ggm@apnic.net

πŸ“¦ where this page comes from