< draft-ietf-curdle-pkix-02.txt   draft-ietf-curdle-pkix-03.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: May 4, 2017 August Cellars Expires: May 27, 2017 August Cellars
October 31, 2016 November 23, 2016
Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and
X448 for use in the Internet X.509 Public Key Infrastructure X448 for use in the Internet X.509 Public Key Infrastructure
draft-ietf-curdle-pkix-02 draft-ietf-curdle-pkix-03
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, Curve448 curves. The signature algorithms covered are Ed25519,
Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered
are X25519 and X448. The Encoding for Public Key, Private Key and are X25519 and X448. The encoding for Public Key, Private Key and
EdDSA digital signature structures is provided. EdDSA digital signature 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 http://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 May 4, 2017. This Internet-Draft will expire on May 27, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
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
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3
3. Curve25519 and Curve448 Algorithm Identifiers . . . . . . . . 3 3. Curve25519 and Curve448 Algorithm Identifiers . . . . . . . . 3
4. Subject Public Key Fields . . . . . . . . . . . . . . . . . . 4 4. Subject Public Key Fields . . . . . . . . . . . . . . . . . . 4
5. Key Usage Bits . . . . . . . . . . . . . . . . . . . . . . . 4 5. Key Usage Bits . . . . . . . . . . . . . . . . . . . . . . . 5
6. EdDSA Signatures . . . . . . . . . . . . . . . . . . . . . . 5 6. EdDSA Signatures . . . . . . . . . . . . . . . . . . . . . . 6
7. Private Key Format . . . . . . . . . . . . . . . . . . . . . 6 7. Private Key Format . . . . . . . . . . . . . . . . . . . . . 7
8. Human Readable Algorithm Names . . . . . . . . . . . . . . . 7 8. Human Readable Algorithm Names . . . . . . . . . . . . . . . 8
9. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 8 9. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Example Ed25519 Public Key . . . . . . . . . . . . . . . 10 10.1. Example Ed25519 Public Key . . . . . . . . . . . . . . . 11
10.2. Example X25519 Certificate . . . . . . . . . . . . . . . 11 10.2. Example X25519 Certificate . . . . . . . . . . . . . . . 11
10.3. Example Ed25519 Private Key . . . . . . . . . . . . . . 13 10.3. Example Ed25519 Private Key . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
In [RFC7748], the elliptic curves Curve25519 and Curve448 are In [RFC7748], the elliptic curves Curve25519 and Curve448 are
described. They are designed with performance and security in mind. described. They are designed with performance and security in mind.
The curves may be used for Diffie-Hellman and Digital Signature The curves may be used for Diffie-Hellman and Digital Signature
skipping to change at page 3, line 8 skipping to change at page 3, line 8
curve Digital Signature Algorithm (EdDSA) is described along with a curve Digital Signature Algorithm (EdDSA) is described along with a
recommendation for the use of the Curve25519 and Curve448. EdDSA has recommendation for the use of the Curve25519 and Curve448. EdDSA has
defined two modes, the PureEdDSA mode without pre-hashing, and the defined two modes, the PureEdDSA mode without pre-hashing, and the
HashEdDSA mode with pre-hashing. The Ed25519ph and Ed448ph algorithm HashEdDSA mode with pre-hashing. The Ed25519ph and Ed448ph algorithm
definitions specify the one-way hash function that is used for pre- definitions specify the one-way hash function that is used for pre-
hashing. The convention used for identifying the algorithm/curve hashing. The convention used for identifying the algorithm/curve
combinations are to use the Ed25519 and Ed448 for the PureEdDSA mode, combinations are to use the Ed25519 and Ed448 for the PureEdDSA mode,
with Ed25519ph and Ed448ph for the HashEdDSA mode. The use of the with Ed25519ph and Ed448ph for the HashEdDSA mode. The use of the
OIDs is described for public keys, private keys and signatures. OIDs is described for public keys, private keys and signatures.
[I-D.irtf-cfrg-eddsa] additionally defined the concept of a context.
Contexts can be used to differentiate signatures generated for
different purposes with the same key. The use of contexts is not
defined in this document for the following reasons:
o The current implementations of Ed25519 do not support the use of
contexts, thus if specified it will potentially delay the use of
these algorithms further.
o The EdDSA algorithms are the only IETF algorithms that currently
support the use of contexts, however there is a possibility that
there will be confusion between which algorithms need have
separate keys and which do not. This may result in a decrease of
security for those other algorithms.
o There are still on going discussions among the cryptographic
community about how effective the use of contexts is for
preventing attacks.
o There needs to be discussions about the correct way to identify
when context strings are to be used. It is not clear if different
OIDs should be used for different contexts, or the OID should
merely not that a context string needs to be provided.
2. Requirements Terminology 2. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Curve25519 and Curve448 Algorithm Identifiers 3. Curve25519 and Curve448 Algorithm Identifiers
Certificates conforming to [RFC5280] can convey a public key for any Certificates conforming to [RFC5280] can convey a public key for any
public key algorithm. The certificate indicates the algorithm public key algorithm. The certificate indicates the algorithm
skipping to change at page 3, line 28 skipping to change at page 4, line 4
through an algorithm identifier. This algorithm identifier is an OID through an algorithm identifier. This algorithm identifier is an OID
and optionally associated parameters. and optionally associated parameters.
The AlgorithmIdentifier type, which is included for convenience, is The AlgorithmIdentifier type, which is included for convenience, is
defined as follows: defined as follows:
AlgorithmIdentifier ::= SEQUENCE { AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER, algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL parameters ANY DEFINED BY algorithm OPTIONAL
} }
The fields in AlgorithmIdentifier have the following meanings: The fields in AlgorithmIdentifier have the following meanings:
o algorithm identifies the cryptographic algorithm with an object o algorithm identifies the cryptographic algorithm with an object
identifier. This is one of the OIDs defined below. identifier. This is one of the OIDs defined below.
o parameters, which are optional, are the associated parameters for o parameters, which are optional, are the associated parameters for
the algorithm identifier in the algorithm field. When the 1997 the algorithm identifier in the algorithm field. When the 1997
syntax for AlgorithmIdentifier was initially defined, it omitted syntax for AlgorithmIdentifier was initially defined, it omitted
the OPTIONAL key word. The optionality of the parameters field the OPTIONAL key word. The optionality of the parameters field
was later recovered via a defect report, but by then many people was later recovered via a defect report, but by then many people
thought that the field was mandatory. For this reason, a small thought that the field was mandatory. For this reason, a small
number of implementations may still require the field to be number of implementations may still require the field to be
present. present.
In this document we defined six new OIDs for identifying the In this document we defined six new OIDs for identifying the
different curve/algorithm pairs. The curves being Curve25519 and different curve/algorithm pairs. The curves being Curve25519 and
Curve448. The algorithms being ECDH, EdDSA in pure mode and EdDSA in 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. pre-hash mode. For all of the OIDs, the parameters MUST be absent.
Implementations SHOULD NOT accept a parameters value of NULL. Regardless of the defect in the original 1997 syntax, implementations
MUST NOT accept a parameters value of NULL.
The same algorithm identifiers are used for identifying a public key, The same algorithm identifiers are used for identifying a public key,
identifying a private key and identifying a signature (for the four identifying a private key and identifying a signature (for the four
EdDSA related OIDs). Additional encoding information is provided EdDSA related OIDs). Additional encoding information is provided
below for each of these locations. below for each of these locations.
id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }
id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 } id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 }
id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 } id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 }
id-Ed448 OBJECT IDENTIFIER ::= { 1 3 101 113 } id-Ed448 OBJECT IDENTIFIER ::= { 1 3 101 113 }
skipping to change at page 5, line 43 skipping to change at page 6, line 15
CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for 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 the creation of certificates or CRLs. This is implied by the fact
that those algorithms are not listed in the previous paragraph. that those algorithms are not listed in the previous paragraph.
Additionally OCSP responders SHOULD NOT use the pre-hash versions of Additionally OCSP responders SHOULD NOT use the pre-hash versions of
the EdDSA algorithms when generating OCSP responses. No restriction the EdDSA algorithms when generating OCSP responses. No restriction
is placed on generation of OCSP requests. is placed on generation of OCSP requests.
AAs MUST NOT use the pre-hash versions of the EdDSA algorithms for AAs MUST NOT use the pre-hash versions of the EdDSA algorithms for
the creation of attribute certificates or attribute CRLs [RFC5755]. the creation of attribute certificates or attribute CRLs [RFC5755].
The decision to require the use of pure mode balances the higher
security of having a single failure point againist the possibility
that constrained devices, such as Hardware Security Modules (HSMs),
may be unable to check signatures on CRLs due to the amount of memory
required to hold the entire CRL in memory at one time. This concern
can be addressed by CAs using CRL distribution points, combined with
segmenting the certificates issued so that the length of any
segmented CRL is not "too long" evenif a large percentage of the
certificates are revoked. The defintion of "too long" is going to be
highly dependent on what constrained device is being used, it can be
on the order of single or low double digit kilobytes.
6. EdDSA Signatures 6. EdDSA Signatures
Signatures can be placed in a number of different ASN.1 structures. Signatures can be placed in a number of different ASN.1 structures.
The top level structure for a certificate is given below as being The top level structure for a certificate is given below as being
illustrative of how signatures are frequently encoded with an illustrative of how signatures are frequently encoded with an
algorithm identifier and a location for the signature. algorithm identifier and a location for the signature.
Certificate ::= SEQUENCE { Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate, tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier, signatureAlgorithm AlgorithmIdentifier,
skipping to change at page 6, line 28 skipping to change at page 7, line 8
is encoded directly in the BIT STRING without adding any additional is encoded directly in the BIT STRING without adding any additional
ASN.1 wrapping. For the Certificate structure, the signature value ASN.1 wrapping. For the Certificate structure, the signature value
is wrapped in the 'signatureValue' BIT STRING field. is wrapped in the 'signatureValue' BIT STRING field.
When the pre-hash versions of the EdDSA signature algorithms are When the pre-hash versions of the EdDSA signature algorithms are
used, the hash function used for the pre-hash is defined by the used, the hash function used for the pre-hash is defined by the
algorithm. This means that the pre-hash function is implicitly algorithm. This means that the pre-hash function is implicitly
included in the algorithm identifier rather than being explicit as included in the algorithm identifier rather than being explicit as
done in [RFC3279]. done in [RFC3279].
In [I-D.irtf-cfrg-eddsa], a parameter was defined for a context
value, specific to an application, to be provided to the signing
operation. This value is used to force different signatures to be
generated for different applications. Along with the defintion of
the context comes a recommendation that contexts only be used if all
of the signature algorithms used for an application have the ability
to accept a context string. For this reason, applications MUST NOT
define the use a context value with the signatures created for these
OIDs. New OIDs would be defined in the event that context values
appear to provide additional value.
7. Private Key Format 7. Private Key Format
Asymmetric Key Packages [RFC5958] describes how encode a private key Asymmetric Key Packages [RFC5958] describes how encode a private key
in a structure that both identifies what algorithm the private key is in a structure that both identifies what algorithm the private key is
for, but allows for the public key and additional attributes about for, but allows for the public key and additional attributes about
the key to be included as well. For illustration, the ASN.1 the key to be included as well. For illustration, the ASN.1
structure OneAsymmetricKey is replicated below. The algorithm structure OneAsymmetricKey is replicated below. The algorithm
specific details of how a private key is encoded is left for the specific details of how a private key is encoded is left for the
document describing the algorithm itself. document describing the algorithm itself.
skipping to change at page 14, line 7 skipping to change at page 14, line 21
The security considerations of [RFC5280], [RFC7748], and The security considerations of [RFC5280], [RFC7748], and
[I-D.irtf-cfrg-eddsa] apply accordingly. [I-D.irtf-cfrg-eddsa] 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 is
different for when used with Diffie-Helman and when used with Edwards different for when used with Diffie-Helman and when used with Edwards
Signatures. This means that the same public key cannot be used for Signatures. This means that the same public key cannot be used for
both ECDH and EdDSA. both ECDH and EdDSA.
In the original design of Ed25519 signatures, there was a known In the original design of Ed25519 signatures, there was a known
attack between the pure and the pre-hash version of the signatures. attack between the pure and the pre-hash version of the signatures.
This has sense been corrected in the final version of the design. This has since been corrected in the final version of the design.
The initial problem meant that there was a known attack, and The initial problem meant that there was a known attack, and
therefore a known reason to forbid the use of Ed25519 keys with the therefore a known reason to forbid the use of Ed25519 keys with the
Ed25519ph signature scheme and visa versa. With the change in the Ed25519ph signature scheme and visa versa. With the change in the
design this attack has been prevented. This does not mean that the design this attack has been prevented. This does not mean that the
same Ed25519 key should be used with both schemes, there still may be same Ed25519 key should be used with both schemes, there still may be
attacks where collisions can be found. For this reason, the same attacks where collisions can be found. For this reason, the same
keys are not to be used for the pure and pre-hash versions of the keys are not to be used for the pure and pre-hash versions of the
scheme. This applies to both curve 25519 and curve 448. scheme. This applies to both curve 25519 and curve 448.
14. References 14. References
 End of changes. 13 change blocks. 
27 lines changed or deleted 52 lines changed or added

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