< draft-ietf-curdle-pkix-05.txt   draft-ietf-curdle-pkix-06.txt >
Network Working Group S. Josefsson Network Working Group S. Josefsson
Internet-Draft SJD AB Internet-Draft SJD AB
Intended status: Standards Track J. Schaad Intended status: Standards Track J. Schaad
Expires: January 4, 2018 August Cellars Expires: March 16, 2018 August Cellars
July 3, 2017 September 12, 2017
Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure
draft-ietf-curdle-pkix-05 draft-ietf-curdle-pkix-06
Abstract Abstract
This document specifies algorithm identifiers and ASN.1 encoding This document specifies algorithm identifiers and ASN.1 encoding
formats for Elliptic Curve constructs using the curve25519 and formats for Elliptic Curve constructs using the curve25519 and
curve448 curves. The signature algorithms covered are Ed25519 and curve448 curves. The signature algorithms covered are Ed25519 and
Ed448. The key agreement algorithm covered are X25519 and X448. The Ed448. The key agreement algorithm covered are X25519 and X448. The
encoding for Public Key, Private Key and EdDSA digital signature encoding for Public Key, Private Key and EdDSA digital signature
structures is provided. structures is provided.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on March 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 8, line 8 skipping to change at page 8, line 8
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
Z9w7lshQhqowtrbLDFw4rXAxZuE= Z9w7lshQhqowtrbLDFw4rXAxZuE=
-----END PRIVATE KEY------ -----END PRIVATE KEY------
NOTE: There exist some private key import functions that have not NOTE: There exist some private key import functions that have not
picked up the new ASN.1 structure OneAsymmetricKey that is defined in picked up the new ASN.1 structure OneAsymmetricKey that is defined in
[RFC7748]. This means that they will not accept a private key [RFC7748]. This means that they will not accept a private key
structure which contains the public key field. This means a structure which contains the public key field. This means a
balancing act needs to be done between being able to do a consitency balancing act needs to be done between being able to do a consistency
check on the key pair and widest ability to import the key. check on the key pair and widest ability to import the key.
8. Human Readable Algorithm Names 8. Human Readable Algorithm Names
For the purpose of consistent cross-implementation naming this For the purpose of consistent cross-implementation naming this
section establishes human readable names for the algorithms specified section establishes human readable names for the algorithms specified
in this document. Implementations SHOULD use these names when in this document. Implementations SHOULD use these names when
referring to the algorithms. If there is a strong reason to deviate referring to the algorithms. If there is a strong reason to deviate
from these names -- for example, if the implementation has a from these names -- for example, if the implementation has a
different naming convention and wants to maintain internal different naming convention and wants to maintain internal
skipping to change at page 14, line 37 skipping to change at page 14, line 37
: } : }
11. Acknowledgements 11. Acknowledgements
Text and/or inspiration were drawn from [RFC5280], [RFC3279], Text and/or inspiration were drawn from [RFC5280], [RFC3279],
[RFC4055], [RFC5480], and [RFC5639]. [RFC4055], [RFC5480], and [RFC5639].
The following people discussed the document and provided feedback: The following people discussed the document and provided feedback:
Klaus Hartke, Ilari Liusvaara, Erwann Abalea, Rick Andrews, Rob Klaus Hartke, Ilari Liusvaara, Erwann Abalea, Rick Andrews, Rob
Stradling, James Manger, Nikos Mavrogiannopoulos, Russ Housley, David Stradling, James Manger, Nikos Mavrogiannopoulos, Russ Housley, David
Benjamin, and Alex Wilson. Benjamin, Brian Smith, and Alex Wilson.
A big thank you to Symantec for kindly donating the OIDs used in this A big thank you to Symantec for kindly donating the OIDs used in this
draft. draft.
12. IANA Considerations 12. IANA Considerations
IANA is requested to assign a module OID from the "SMI for PKIX IANA is requested to assign a module OID from the "SMI for PKIX
Module Identifier" registry for the ASN.1 module in Section 9. Module Identifier" registry for the ASN.1 module in Section 9.
13. Security Considerations 13. Security Considerations
The security considerations of [RFC5280], [RFC7748], and [RFC8032] The security considerations of [RFC5280], [RFC7748], and [RFC8032]
apply accordingly. apply accordingly.
The procedures for going from a private key to a public key is The procedures for going from a private key to a public key are
different for when used with Diffie-Hellman and when used with different for when used with Diffie-Hellman and when used with
Edwards Signatures. This means that the same public key cannot be Edwards Signatures. This means that the same public key cannot be
used for both ECDH and EdDSA. used for both ECDH and EdDSA.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key "Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<http://www.rfc-editor.org/info/rfc5480>. <https://www.rfc-editor.org/info/rfc5480>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010, DOI 10.17487/RFC5958, August 2010,
<http://www.rfc-editor.org/info/rfc5958>. <https://www.rfc-editor.org/info/rfc5958>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <http://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<http://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
14.2. Informative References 14.2. Informative References
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
2002, <http://www.rfc-editor.org/info/rfc3279>. 2002, <https://www.rfc-editor.org/info/rfc3279>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055, and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005, DOI 10.17487/RFC4055, June 2005,
<http://www.rfc-editor.org/info/rfc4055>. <https://www.rfc-editor.org/info/rfc4055>.
[RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography [RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography
(ECC) Brainpool Standard Curves and Curve Generation", (ECC) Brainpool Standard Curves and Curve Generation",
RFC 5639, DOI 10.17487/RFC5639, March 2010, RFC 5639, DOI 10.17487/RFC5639, March 2010,
<http://www.rfc-editor.org/info/rfc5639>. <https://www.rfc-editor.org/info/rfc5639>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <http://www.rfc-editor.org/info/rfc7468>. April 2015, <https://www.rfc-editor.org/info/rfc7468>.
Appendix A. Invalid Encodings Appendix A. Invalid Encodings
There are a number of things that need to be dealt with when a new There are a number of things that need to be dealt with when a new
key part is decoded and imported into the system. A partial list of key part is decoded and imported into the system. A partial list of
these includes: these includes:
o ASN.1 encoding errors: Two items are highlighted here. First, the o ASN.1 encoding errors: Two items are highlighted here. First, the
use of an OCTET STRING rather than a BIT STRING for the public use of an OCTET STRING rather than a BIT STRING for the public
key. This was an incorrect copy of the structure from [RFC5958] key. This was an incorrect copy of the structure from [RFC5958]
skipping to change at page 16, line 46 skipping to change at page 16, line 46
o Key encoding errors: Both [RFC7748] and [RFC8032] have formatting o Key encoding errors: Both [RFC7748] and [RFC8032] have formatting
requirements for keys that need to be enforced. In some cases the requirements for keys that need to be enforced. In some cases the
enforcement is done at the time of importing, for example doing enforcement is done at the time of importing, for example doing
masking or a mod p operation. In other cases the enforcement is masking or a mod p operation. In other cases the enforcement is
done by rejecting the keys and having an import failure. done by rejecting the keys and having an import failure.
o Key mismatch errors: If a public key is provided, it may not agree o Key mismatch errors: If a public key is provided, it may not agree
with the private key either because it is wrong or the wrong with the private key either because it is wrong or the wrong
algorithm was used. algorithm was used.
What follows here is a brief sampling of some incorrect keys. Some systems are also going to be stricter on what they accept. As
stated in [RFC5958], BER decoding of OneAsymmetricKey objects is a
The following is not an invalid encoding, but it may not be accepted requirement for compliance. Despite this requirement, some acceptors
by many systems as it is BER encoded. will only decode DER formats. The following is a BER encoding of a
private key, as such is is valid, but it may not be accepted by many
systems.
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MIACAQAwgAYDK2VwAAAEIgQg1O5y2/kTWErVttjx92n4rTr+fCjL8dT74Jeoj0R1W MIACAQAwgAYDK2VwAAAEIgQg1O5y2/kTWErVttjx92n4rTr+fCjL8dT74Jeoj0R1W
EIAAA== EIAAA==
-----END PRIVATE KEY----- -----END PRIVATE KEY-----
What follows here is a brief sampling of some incorrect keys.
In the following example, the private key does not match the masking In the following example, the private key does not match the masking
requirements for X25519. For this example the top top bits are set requirements for X25519. For this example the top bits are set to
to zero and the low three bits are set to 001. zero and the bottom three bits are set to 001.
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MFMCAQEwBQYDK2VuBCIEIPj///////////////////////////////////////8/oS MFMCAQEwBQYDK2VuBCIEIPj///////////////////////////////////////8/oS
MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg== MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg==
-----END PRIVATE KEY----- -----END PRIVATE KEY-----
In the following examples, the key is the wrong length because an all In the following examples, the key is the wrong length because an all
zero byte has been removed. zero byte has been removed. In one case the first byte has been
removed, in the other case the last byte has been removed.
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MFICAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoS MFICAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoS
IDIADBfk2Lv/J8H7YYwj/OmIcDx++jzVkKrKwS0/HjyQyM IDIADBfk2Lv/J8H7YYwj/OmIcDx++jzVkKrKwS0/HjyQyM
-----END PRIVATE KEY----- -----END PRIVATE KEY-----
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MFICAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS MFICAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS
IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk
-----END PRIVATE KEY----- -----END PRIVATE KEY-----
 End of changes. 22 change blocks. 
26 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/