Network Working Group S. Josefsson
Internet-Draft SJD AB
Intended status: Standards Track J. Schaad
Expires: February 16, 2017 August Cellars
August 15, 2016
Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and
X448 for use in the Internet X.509 Public Key Infrastructure
draft-ietf-curdle-pkix-01
Abstract
This document specify algorithm identifiers and ASN.1 encoding
formats for Elliptical Curve constructs using the Curve25519 and
Curve448 curves. The signature algorithms covered are Ed25519,
Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered
are X25519 and X448. The Encoding for Public Key, Private Key and
EdDSA digital signature structures is provided.
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 http://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 February 16, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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
Josefsson & Schaad Expires February 16, 2017 [Page 1]
Internet-Draft Safe curves for X.509 August 2016
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3
3. Curve25519 and Curve448 Algorithm Identifiers . . . . . . . . 3
4. Subject Public Key Fields . . . . . . . . . . . . . . . . . . 4
5. Key Usage Bits . . . . . . . . . . . . . . . . . . . . . . . 5
6. EdDSA Signatures . . . . . . . . . . . . . . . . . . . . . . 5
7. Private Key Format . . . . . . . . . . . . . . . . . . . . . 6
8. Human Readable Algorithm Names . . . . . . . . . . . . . . . 7
9. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Example Ed25519 Public Key . . . . . . . . . . . . . . . 10
10.2. Example X25519 Certificate . . . . . . . . . . . . . . . 11
10.3. Example Ed25519 Private Key . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
In [RFC7748], the elliptic curves Curve25519 and Curve448 are
described. They are designed with performance and security in mind.
The curves may be used for Diffie-Hellman and Digital Signature
operations. A convention has developed that when these two curves
are used with the Diffie-Hellman operation, they are referred to as
X25519 and X448.
In [I-D.irtf-cfrg-eddsa] the elliptic curve signature system EdDSA is
described and the recommended choice of curves Ed25519/Ed448 are
chosen. EdDSA has defined two modes, the PureEdDSA mode without pre-
hashing, and the HashEdDSA mode with pre-hashing. Unlike other
digital signature algorithms, the Ed25519ph and Ed448ph algorithm
definitions specify the one-way hash function that is used. Attacks
have been described when the same key is used with and without pre-
hashing for Ed25519, so a single key MUST NOT be used for both modes.
The convention used for identifying the algorithm/curve combinations
are to use the Ed25519 and Ed448 for the PureEdDSA mode and Ed25519ph
and Ed448ph for the HashEdDSA mode.
Josefsson & Schaad Expires February 16, 2017 [Page 2]
Internet-Draft Safe curves for X.509 August 2016
This RFC defines ASN.1 object identifiers for EdDSA for use in the
Internet X.509 PKI [RFC5280], and parameters for Ed25519, Ed25519ph,
Ed448 and Ed448ph. This document serves a similar role as [RFC3279]
does for RSA (and more), [RFC4055] for RSA-OAEP/PSS, and [RFC5758]
for SHA2-based (EC)DSA. This document also specify ASN.1 "named
curve" object identifiers for Curve25519 and Curve448, similar to
what is done in [RFC5639]. This allows the curves to be used and
referenced in PKIX standards and software, in particular enabling re-
use of existing constructs already defined for ECDSA/ECDH but for the
new curves. Similar to [RFC5639], this document does not describe
the cryptographic algorithms to be used with the specified parameters
nor their application in other standards.
2. Requirements 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].
3. Curve25519 and Curve448 Algorithm Identifiers
Certificates conforming to [RFC5280] can convey a public key for any
public key algorithm. The certificate indicates the algorithm
through an algorithm identifier. This algorithm identifier is an OID
and optionally associated parameters.
The AlgorithmIdentifier type, which is included for convenience, is
defined as follows:
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}
The fields in AlgorithmIdentifier have the following meanings:
o algorithm identifies the cryptographic algorithm with an object
identifier. This is one of the OIDs defined below.
o parameters, which are optional, are the associated parameters for
the algorithm identifier in the algorithm field. When the 1997
syntax for AlgorithmIdentifier was initially defined, it omitted
the OPTIONAL key word. The optionality of the parameters field
was later recovered via a defect report, but by then many people
thought that the field was mandatory. For this reason, a small
number of implementations may still require the field to be
present.
Josefsson & Schaad Expires February 16, 2017 [Page 3]
Internet-Draft Safe curves for X.509 August 2016
In this document we defined six new OIDs for identifying the
different curve/algorithm pairs. The curves being Curve25519 and
Curve448. The algorithms being ECDH, EdDSA in pure mode and EdDSA in
pre-hash mode. For all of the OIDs, the parameters MUST be absent.
Implementations SHOULD NOT accept a parameters value of NULL.
The same algorithm identifiers are used for identifying a public key,
identifying a private key and identifying a signature (for the four
EdDSA related OIDs). Additional encoding information is provided
below for each of these locations.
id-X25519 OBJECT IDENTIFIER ::= { 1.3.101.110 }
id-X448 OBJECT IDENTIFIER ::= { 1.3.101.111 }
id-Ed25519 OBJECT IDENTIFIER ::= { 1.3.101.112 }
id-Ed448 OBJECT IDENTIFIER ::= { 1.3.101.113 }
id-Ed25519ph OBJECT IDENTIFIER ::= { 1.3.101.114 }
id-Ed448ph OBJECT IDENTIFIER ::= { 1.3.101.115 }
4. Subject Public Key Fields
In the X.509 certificate, the subjectPublicKeyInfo field has the
SubjectPublicKeyInfo type, which has the following ASN.1 syntax:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
The fields in SubjectPublicKeyInfo have the following meanings:
o algorithm is the algorithm identifier and parameters for the
public key (see above).
o subjectPublicKey contains the byte stream of the public key.
While the encoded public keys for the current algorithms are all
an even number of octets, future curves could change that.
Both [RFC7748] and [I-D.irtf-cfrg-eddsa] define the public key value
as being a byte string. It should be noted that the public key is
computed differently for each of these documents, thus the same
private key will not produce the same public key.
The following is an example of a public key encoded using the textual
encoding defined in [RFC7468].
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZmE=
-----END PUBLIC KEY-----
Josefsson & Schaad Expires February 16, 2017 [Page 4]
Internet-Draft Safe curves for X.509 August 2016
5. Key Usage Bits
The intended application for the key is indicated in the keyUsage
certificate extension.
If the keyUsage extension is present in a certificate that indicates
id-X25119 or id-X448 in SubjectPublicKeyInfo, then the following MUST
be present:
keyAgreement;
one of the following MAY also be present:
encipherOnly; or
decipherOnly.
If the keyUsage extension is present in an end-entity certificate
that indicates id-EdDSA25519, id-EdDSA25519ph, id-EdDSA448 or id-
EdDSA448ph , then the keyUsage extension MUST contain one or both of
the following values:
nonRepudiation; and
digitalSignature.
If the keyUsage extension is present in a certification authority
certificate that indicates id-EdDSA25519 or id-EdDSA448, then the
keyUsage extension MUST contain one or more of the following values:
nonRepudiation;
digitalSignature;
keyCertSign; and
cRLSign.
CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for
the creation of certificates or CRLs. This is implied by the fact
that those algorithms are not listed in the previous paragraph.
Additionally OCSP responders SHOULD NOT use the pre-hash versions of
the EdDSA algorithms when generating OCSP responses. No restriction
is placed on generation of OCSP requests.
AAs MUST NOT use the pre-hash versions of the EdDSA algorithms for
the creation of attribute certificates or attribute CRLs [RFC5755].
6. EdDSA Signatures
Signatures can be placed in a number of different ASN.1 structures.
The top level structure for a certificate is given below as being
Josefsson & Schaad Expires February 16, 2017 [Page 5]
Internet-Draft Safe curves for X.509 August 2016
illustrative of how signatures are frequently encoded with an
algorithm identifier and a location for the signature.
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
The same algorithm identifiers are used for signatures as are used
for public keys. When used to identify signature algorithms, the
parameters MUST be absent.
The data to be signed is prepared for EdDSA. Then, a private key
operation is performed to generate the signature value. This value
is the opaque value ENC(R) || ENC(S) described in section 3.3 of
[I-D.irtf-cfrg-eddsa]. The octet string representing the signature
is encoded directly in the BIT STRING without adding any additional
ASN.1 wrapping. For the Certificate structure, the signature value
is wrapped in the 'signatureValue' BIT STRING field.
When the pre-hash versions of the EdDSA signature algorithms are
used, the hash function used for the pre-hash is defined by the
algorithm. This means that the pre-hash function is implicitly
included in the algorithm identifier rather than being explicit as
done in [RFC3279].
7. Private Key Format
Asymmetric Key Packages [RFC5958] describes how encode a private key
in a structure that both identifies what algorithm the private key is
for, but allows for the public key and additional attributes about
the key to be included as well. For illustration, the ASN.1
structure OneAsymmetricKey is replicated below. The algorithm
specific details of how a private key is encoded is left for the
document describing the algorithm itself.
Josefsson & Schaad Expires February 16, 2017 [Page 6]
Internet-Draft Safe curves for X.509 August 2016
OneAsymmetricKey ::= SEQUENCE {
version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKey PrivateKey,
attributes [0] Attributes OPTIONAL,
...,
[[2: publicKey [1] PublicKey OPTIONAL ]],
...
}
PrivateKey ::= OCTET STRING
PublicKey ::= OCTET STRING
For the keys defined in this document, the private key is always an
opaque byte sequence. The ASN.1 type EdPrivateKey is defined in this
document to hold the byte sequence. Thus when encoding a
OneAsymmetricKey object, the private key is wrapped in an
EdPrivateKey object and then placed in the 'privateKey' field.
EdPrivateKey ::= OCTET STRING
To encode a EdDSA, X25519 or X448 private key, the "privateKey" field
will hold the encoded private key. The "privateKeyAlgorithm" field
uses the AlgorithmIdentifier structure. The structure is encoded as
defined above. If present, the "publicKey" field will hold the
encoded key as defined in [RFC7748] and [I-D.irtf-cfrg-eddsa].
public key.
The following is an example of a private key encoded using the
textual encoding defined in [RFC7468].
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
-----END PRIVATE KEY-----
8. Human Readable Algorithm Names
For the purpose of consistent cross-implementation naming this
section establishes human readable names for the algorithms specified
in this document. Implementations SHOULD use these names when
referring to the algorithms. If there is a strong reason to deviate
from these names -- for example, if the implementation has a
different naming convention and wants to maintain internal
consistency -- it is encouraged to deviate as little as possible from
the names given here.
Josefsson & Schaad Expires February 16, 2017 [Page 7]
Internet-Draft Safe curves for X.509 August 2016
Use the string "ECDH" when referring to a public key of type X25519
or X448 when the curve is not known or relevant.
When the curve is known, use the more specific string of X25519 or
X448.
Use the string "EdDSA" when referring to a signing public key or
signature when the curve is not known or relevant.
When the curve is known, use a more specific string. For the id-
EdDSA25519 value use the string "Ed25519". For the id-EdDSA25519ph
value use the string "Ed25519ph". For id-EdDSA448 use "Ed448". For
id-EdDSA448ph use "Ed448ph".
9. ASN.1 Module
For reference purposes, the ASN.1 syntax is presented as an ASN.1
module here.
-- ASN.1 Module
Safecurves-pkix-0 {1 3 101 120}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
SIGNATURE-ALGORITHM, KEY-AGREE, PUBLIC-KEY, KEY-WRAP,
KeyUsage, AlgorithmIdentifier
FROM AlgorithmInformation-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
mda-sha512
FROM PKIX1-PSS-OAEP-Algorithms-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs-02(54) }
kwa-aes128-wrap, kwa-aes256-wrap
FROM CMSAesRsaesOaep-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-aes-02(38) }
;
id-edwards-curve-algs OBJECT IDENTIFIER ::= { 1 3 101 }
Josefsson & Schaad Expires February 16, 2017 [Page 8]
Internet-Draft Safe curves for X.509 August 2016
id-X25519 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 110 }
id-X448 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 111 }
id-EdDSA25519 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 112 }
id-EdDSA25519-ph OBJECT IDENTIFIER ::= { id-edwards-curve-algs 114 }
id-EdDSA448 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 113 }
id-EdDSA448-ph OBJECT IDENTIFIER ::= { id-edwards-curve-algs 115 }
sa-EdDSA25519 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-EdDSA25519
PARAMS ARE absent
PUBLIC-KEYS {pk-EdDSA25519}
SMIME-CAPS { IDENTIFIED BY id-EdDSA25519 }
}
pk-EdDSA25519 PUBLIC-KEY ::= {
IDENTIFIER id-EdDSA25519
-- KEY no ASN.1 wrapping --
PARAMS ARE absent
CERT-KEY-USAGE {digitalSignature, nonRepudiation,
keyCertSign, cRLSign}
PRIVATE-KEY EdPrivateKey
}
sa-EdDSA25519-ph SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-EdDSA25519-ph
PARAMS ARE absent
HASHES { mda-sha512 }
PUBLIC-KEYS {pk-EdDSA25519-ph}
SMIME-CAPS { IDENTIFIED BY id-EdDSA25519-ph }
}
pk-EdDSA25519-ph PUBLIC-KEY ::= {
IDENTIFIER id-EdDSA25519-ph
-- KEY no ASN.1 wrapping --
PARAMS ARE absent
CERT-KEY-USAGE {digitalSignature, nonRepudiation}
PRIVATE-KEY EdPrivateKey
}
kaa-X25519 KEY-AGREE ::= {
IDENTIFIER id-X25519
PARAMS ARE absent
PUBLIC-KEYS {pk-X25519}
UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent
SMIME-CAPS {
TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}}
IDENTIFIED BY id-X25519 }
Josefsson & Schaad Expires February 16, 2017 [Page 9]
Internet-Draft Safe curves for X.509 August 2016
}
pk-X25519 PUBLIC-KEY ::= {
IDENTIFIER id-X25519
-- KEY no ASN.1 wrapping --
PARAMS ARE absent
CERT-KEY-USAGE { keyAgreement }
PRIVATE-KEY EdPrivateKey
}
KeyWrapAlgorithms KEY-WRAP ::= {
kwa-aes128-wrap | kwa-aes256-wrap,
...
}
kaa-X488 KEY-AGREE ::= {
IDENTIFIER id-X448
PARAMS ARE absent
PUBLIC-KEYS {pk-X448}
UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent
SMIME-CAPS {
TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}}
IDENTIFIED BY id-X448 }
}
pk-X448 PUBLIC-KEY ::= {
IDENTIFIER id-X448
-- KEY no ASN.1 wrapping --
PARAMS ARE absent
CERT-KEY-USAGE { keyAgreement }
PRIVATE-KEY EdPrivateKey
}
EdPrivateKey ::= OCTET STRING
END
10. Examples
This section contains illustrations of EdDSA public keys and
certificates, illustrating parameter choices.
10.1. Example Ed25519 Public Key
An example of a Ed25519 public key:
Josefsson & Schaad Expires February 16, 2017 [Page 10]
Internet-Draft Safe curves for X.509 August 2016
Public Key Information:
Public Key Algorithm: EdDSA25519
Algorithm Security Level: High
Public Key Usage:
Public Key ID: 9b1f5eeded043385e4f7bc623c5975b90bc8bb3b
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZmE=
-----END PUBLIC KEY-----
10.2. Example X25519 Certificate
An example of a PKIX certificate using Ed25519 to sign X25519 would
be:
0 30 300: SEQUENCE {
4 30 223: SEQUENCE {
7 A0 3: [0] {
9 02 1: INTEGER 2
: }
12 02 8: INTEGER
: 56 01 47 4A 2A 8D C3 30
22 30 5: SEQUENCE {
24 06 3: OBJECT IDENTIFIER
: EdDSA 25519 signature algorithm { 1 3 101 112 }
: }
29 30 25: SEQUENCE {
31 31 23: SET {
33 30 21: SEQUENCE {
35 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
40 0C 14: UTF8String (1997) 'IETF Test Demo'
: }
: }
: }
56 30 30: SEQUENCE {
58 17 13: UTCTime '160801121924Z'
73 17 13: UTCTime '401231235959Z'
: }
88 30 25: SEQUENCE {
90 31 23: SET {
92 30 21: SEQUENCE {
94 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
99 0C 14: UTF8String (1997) 'IETF Test Demo'
: }
: }
: }
Josefsson & Schaad Expires February 16, 2017 [Page 11]
Internet-Draft Safe curves for X.509 August 2016
115 30 42: SEQUENCE {
117 30 5: SEQUENCE {
119 06 3: OBJECT IDENTIFIER
: ECDH 25519 key agreement { 1 3 101 110 }
: }
124 03 33: BIT STRING 0 unused bits
: 85 20 F0 09 89 30 A7 54 74 8B 7D DC B4 3E F7 5A
: 0D BF 3A 0D 26 38 1A F4 EB A4 A9 8E AA 9B 4E 6A
: }
159 A3 69: [3] {
161 30 67: SEQUENCE {
163 30 15: SEQUENCE {
165 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
170 01 1: BOOLEAN TRUE
173 04 5: OCTET STRING, encapsulates {
175 30 3: SEQUENCE {
177 01 1: BOOLEAN FALSE
: }
: }
: }
180 30 14: SEQUENCE {
182 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
187 01 1: BOOLEAN FALSE
190 04 4: OCTET STRING, encapsulates {
192 03 2: BIT STRING 7 unused bits
: '1'B
: }
: }
196 30 32: SEQUENCE {
198 06 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
203 01 1: BOOLEAN FALSE
206 04 22: OCTET STRING
: 04 14 9B 1F 5E ED ED 04 33 85 E4 F7 BC 62 3C 59
: 75 B9 0B C8 BB 3B
: }
: }
: }
: }
230 30 5: SEQUENCE {
232 06 3: OBJECT IDENTIFIER
: EdDSA 25519 signature algorithm { 1 3 101 112 }
: }
237 03 65: BIT STRING 0 unused bits
: D1 EE DF 10 15 68 CA C2 4A C2 13 7F 45 C6 B7 6E
: 7C 11 E8 B3 AC D5 67 D3 1A 6E 90 EA 0F 8B F6 50
: 0F 91 66 BB EF BE 10 DE FA 37 7B 61 FC D7 C5 C6
: AB CF 3F 89 01 F9 BD 80 E8 1B 9D 21 DD 32 73 0A
: }
Josefsson & Schaad Expires February 16, 2017 [Page 12]
Internet-Draft Safe curves for X.509 August 2016
-----BEGIN CERTIFICATE-----
MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZXN0IERlbW8wHhcN
MTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQDDA5JRVRGIFRlc3QgRGVtbzAqMAUG
AytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJjga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEA
MA4GA1UdDwEBAAQEAwIHgDAgBgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EA
0e7fEBVoysJKwhN/Rca3bnwR6LOs1WfTGm6Q6g+L9lAPkWa7774Q3vo3e2H818XGq88/iQH5vYDoG50h
3TJzCg==
-----END CERTIFICATE-----
10.3. Example Ed25519 Private Key
An example of an Ed25519 private key:
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
-----END PRIVATE KEY-----
11. Acknowledgements
Text and/or inspiration were drawn from [RFC5280], [RFC3279],
[RFC4055], [RFC5480], and [RFC5639].
The following people discussed the document and provided feedback:
Klaus Hartke, Ilari Liusvaara, Erwann Abalea, Rick Andrews, Rob
Stradling, James Manger, Nikos Mavrogiannopoulos, Russ Housley, and
Alex Wilson.
A big thank you to Symantec for kindly donating the OIDs used in this
draft.
12. IANA Considerations
None.
13. Security Considerations
The security considerations of [RFC5280], [RFC7748], and
[I-D.irtf-cfrg-eddsa] apply accordingly.
A common misconception may be that a Ed25519 public key can be used
to create Ed25519ph signatures, or vice versa. This leads to cross-
key attacks, and is not permitted.
14. References
Josefsson & Schaad Expires February 16, 2017 [Page 13]
Internet-Draft Safe curves for X.509 August 2016
14.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>.
[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>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<http://www.rfc-editor.org/info/rfc5480>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <http://www.rfc-editor.org/info/rfc7748>.
[I-D.irtf-cfrg-eddsa]
Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-06
(work in progress), August 2016.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010,
<http://www.rfc-editor.org/info/rfc5958>.
14.2. Informative References
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
2002, <http://www.rfc-editor.org/info/rfc3279>.
[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>.
Josefsson & Schaad Expires February 16, 2017 [Page 14]
Internet-Draft Safe curves for X.509 August 2016
[RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography
(ECC) Brainpool Standard Curves and Curve Generation",
RFC 5639, DOI 10.17487/RFC5639, March 2010,
<http://www.rfc-editor.org/info/rfc5639>.
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet
Attribute Certificate Profile for Authorization",
RFC 5755, DOI 10.17487/RFC5755, January 2010,
<http://www.rfc-editor.org/info/rfc5755>.
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
Polk, "Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for DSA and ECDSA",
RFC 5758, DOI 10.17487/RFC5758, January 2010,
<http://www.rfc-editor.org/info/rfc5758>.
[RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key
Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010,
<http://www.rfc-editor.org/info/rfc5915>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <http://www.rfc-editor.org/info/rfc7468>.
Authors' Addresses
Simon Josefsson
SJD AB
Email: simon@josefsson.org
Jim Schaad
August Cellars
Email: ietf@augustcellars.com
Josefsson & Schaad Expires February 16, 2017 [Page 15]