title: Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers abbrev: curve25519, curve448 ECC Clarifications category: std updates: 8410
docname: draft-ietf-lamps-8410-ku-clarifications-latest ipr: trust200902 keyword: Internet-Draft area: Security workgroup: LAMPS venue: github: lamps-wg/8410-ku-clarifications
stand_alone: yes smart_quotes: no pi: [toc, sortrefs, symrefs, docmapping]
ins: S. Turner
name: Sean Turner
organization: sn3rd
email: [email protected]
- ins: S. Josefsson name: Simon Josefsson organization: SJD AB email: [email protected]
- ins: D. McCarney name: Daniel McCarney organization: Square Inc. email: [email protected]
- ins: T. Ito name: Tadahiko Ito organization: SECOM CO., LTD. email: [email protected]
normative:
informative: ERRATA: title: Errata 5696 author: - ins: L. Liao name: Lijun Liao date: 2019-04-17 target: https://www.rfc-editor.org/errata/eid5696
--- abstract
This document updates RFC 8410 to clarify existing and specify missing semantics for key usage bits when used in certificates that support the Ed25519, Ed448, X25519, and X448 Elliptic Curve Cryptography algorithms.
--- middle
{{!RFC8410}} specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Ed25519, Ed448, X25519, and X448 Elliptic Curve Cryptography (ECC) algorithms. As part of these semantics, it defines what combinations are permissible for the values of the key usage extension {{!RFC5280}}. {{RFC8410}} did not define what values are not permissible nor did it refer to keyEncipherment or dataEncipherment. {{ERRATA}} has also been submitted to clarify that keyCertSign is always set in certification authority certificates. To address these changes, this document replaces Section 5 of {{RFC8410}} with {{replace}}.
{::boilerplate bcp14-tagged}
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-X25519 or id-X448 in SubjectPublicKeyInfo, then the following MUST be present:
keyAgreement;
one of the following MAY also be present:
encipherOnly; or
decipherOnly;
and the following MUST NOT be present:
digitalSignature;
nonRepudiation;
keyEncipherment;
dataEncipherment;
keyCertSign; and
cRLSign.
If the keyUsage extension is present in an end-entity certificate that indicates id-Ed25519 or id-Ed448 in SubjectPublicKeyInfo, then the keyUsage extension MUST contain at least one of the following:
nonRepudiation;
digitalSignature; and
cRLSign;
and the following MUST NOT be present:
keyEncipherment;
dataEncipherment;
keyAgreement;
keyCertSign;
encipherOnly; and
decipherOnly.
If the keyUsage extension is present in a CRL issuer certificate that indicates id-Ed25519 or id-Ed448 in SubjectPublicKeyInfo, then the keyUsage extension MUST contain:
~~ cRLSign; ~~
and zero or more of the following:
~~ nonRepudiation; and digitalSignature; ~~
and the following MUST NOT be present:
~~ keyEncipherment; dataEncipherment; keyAgreement; encipherOnly; and decipherOnly; ~~
and if the CRL issuer is also a certification authority, then the keyUsage extension MUST also contain:
~~ keyCertSign. ~~
If the keyUsage extension is present in a certification authority certificate that indicates id-Ed25519 or id-Ed448 in SubjectPublicKeyInfo, then the keyUsage extension MUST contain:
keyCertSign
and zero or more of the following:
nonRepudiation;
digitalSignature; and
cRLSign;
and the following MUST NOT be present:
keyEncipherment;
dataEncipherment;
keyAgreement;
encipherOnly; and
decipherOnly.
This document introduces no new security considerations beyond those found in {{RFC8410}}.
This document has no IANA actions.
--- back
{:numbered="false"}
We would like to thank Russ Housley, Mike Jenkins, and Corey Bonnell for the comments.