Skip to main content

Clarifications for Elliptic Curve Cryptography Subject Public Key Information
draft-ietf-lamps-5480-ku-clarifications-03

Revision differences

Document history

Date Rev. By Action
2020-08-07
03 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-08-03
03 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-05-26
03 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-05-01
03 (System) IANA Action state changed to No IANA Actions from In Progress
2020-04-28
03 (System) RFC Editor state changed to EDIT
2020-04-28
03 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-04-28
03 (System) Announcement was received by RFC Editor
2020-04-28
03 (System) IANA Action state changed to In Progress
2020-04-28
03 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-04-28
03 Amy Vezza IESG has approved the document
2020-04-28
03 Amy Vezza Closed "Approve" ballot
2020-04-28
03 Amy Vezza Ballot approval text was generated
2020-04-28
03 Roman Danyliw IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2020-04-24
03 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from Approved-announcement to be sent::Point Raised - writeup needed
2020-03-31
03 Sean Turner New version available: draft-ietf-lamps-5480-ku-clarifications-03.txt
2020-03-31
03 (System) New version accepted (logged-in submitter: Sean Turner)
2020-03-31
03 Sean Turner Uploaded new revision
2020-03-26
02 Russ Housley Added to session: interim-2020-lamps-01
2020-03-07
02 Klaas Wierenga Request for Last Call review by SECDIR Completed: Ready. Reviewer: Klaas Wierenga. Sent review to list.
2020-03-05
02 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2020-03-05
02 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-03-04
02 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-03-04
02 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-03-04
02 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2020-03-04
02 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-03-03
02 Alissa Cooper [Ballot comment]
If further clarifications can be made based on the latest email from the Gen-ART reviewer, that would be good.
2020-03-03
02 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-03-03
02 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-03-03
02 Warren Kumari [Ballot comment]
Thanks to Tim for the OpsDir review, and Sean for addressing it.
2020-03-03
02 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-03-02
02 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2020-03-02
02 Benjamin Kaduk
[Ballot comment]
I'm somewhat amenable to the genart reviewer's concerns that we are
implicitly asserting restrictions in RFC 5480 usage by describing the
algorithms defined …
[Ballot comment]
I'm somewhat amenable to the genart reviewer's concerns that we are
implicitly asserting restrictions in RFC 5480 usage by describing the
algorithms defined by 5480 as "key agreement algorithms"; RFC 5480 does
not seem to use that terminology to refer to id-ecPublicKey.

Section 1

  Cryptography.  As part of these semantics, it defines what
  combinations are permissible for the values of the key usage
  extensions [RFC5280].  [RFC5480] specifies 7 of the 9 values; it

nit: IMO, "key usage extensions" would mean both keyUsage and
extendedKeyUsage, but this document considers only the identified bits
in the original keyUsage extension, and thus the singular "extension"
would be more appropriate.

Section 4

What are the considerations that apply to implementations that follow
RFC 5480 but not this document, e.g., existing implementations that
allow keyEncipherment and/or dataEncipherment?  Specifically, if we are
forbidding their usage, is it because there are vulnerabilities to doing
so?  It seems like we should mention them here.
2020-03-02
02 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-02-28
02 Sean Turner New version available: draft-ietf-lamps-5480-ku-clarifications-02.txt
2020-02-28
02 (System) New version accepted (logged-in submitter: Sean Turner)
2020-02-28
02 Sean Turner Uploaded new revision
2020-02-27
01 Tim Chown Request for Last Call review by OPSDIR Completed: Not Ready. Reviewer: Tim Chown. Sent review to list.
2020-02-26
01 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2020-02-25
01 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-02-25
01 Sean Turner New version available: draft-ietf-lamps-5480-ku-clarifications-01.txt
2020-02-25
01 (System) New version accepted (logged-in submitter: Sean Turner)
2020-02-25
01 Sean Turner Uploaded new revision
2020-02-25
01 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-02-25
00 Barry Leiba
[Ballot comment]
Thanks for a nice, super-short and to-the-point document.  I hate to pick on anything here, but:

  then the following
  values also …
[Ballot comment]
Thanks for a nice, super-short and to-the-point document.  I hate to pick on anything here, but:

  then the following
  values also MUST NOT be present:

Do you mean "MUST NOT also be present"?  The "also" seems misplaced where it is, and it made me wonder if I misunderstood.  An alternative fix would be to simply remove "also".
2020-02-25
00 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-02-25
00 Éric Vyncke
[Ballot comment]
Ultra short document :-)

Anyway, a minor comment: what is the location of the text updating the section 3 of RFC 5480? …
[Ballot comment]
Ultra short document :-)

Anyway, a minor comment: what is the location of the text updating the section 3 of RFC 5480? Should it go at the end of the existing section 3 (my guess)? Or at the beginning ? or somewhere in the middle ? Should it replace completely or partially the existing section 3?

-éric

PS: I know that my comment is mostly larger than the update itself ;-)
2020-02-25
00 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-02-25
00 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2020-02-24
00 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for Writeup
2020-02-24
00 Amy Vezza Placed on agenda for telechat - 2020-03-05
2020-02-24
00 Roman Danyliw Ballot has been issued
2020-02-24
00 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2020-02-24
00 Roman Danyliw Created "Approve" ballot
2020-02-24
00 Roman Danyliw Ballot writeup was changed
2020-02-21
00 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2020-02-21
00 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-lamps-5480-ku-clarifications-00, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-lamps-5480-ku-clarifications-00, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-02-21
00 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-02-18
00 Dale Worley Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dale Worley. Sent review to list.
2020-02-13
00 Jean Mahoney Request for Last Call review by GENART is assigned to Dale Worley
2020-02-13
00 Jean Mahoney Request for Last Call review by GENART is assigned to Dale Worley
2020-02-13
00 Tero Kivinen Request for Last Call review by SECDIR is assigned to Klaas Wierenga
2020-02-13
00 Tero Kivinen Request for Last Call review by SECDIR is assigned to Klaas Wierenga
2020-02-10
00 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2020-02-10
00 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2020-02-07
00 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-02-07
00 Amy Vezza
The following Last Call announcement was sent out (ends 2020-02-21):

From: The IESG
To: IETF-Announce
CC: rdd@cert.org, lamps-chairs@ietf.org, Russ Housley , housley@vigilsec.com, …
The following Last Call announcement was sent out (ends 2020-02-21):

From: The IESG
To: IETF-Announce
CC: rdd@cert.org, lamps-chairs@ietf.org, Russ Housley , housley@vigilsec.com, spasm@ietf.org, draft-ietf-lamps-5480-ku-clarifications@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information) to Proposed Standard


The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: -
'Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key
  Information'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-02-21. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document updates RFC 5480 to specify semantics for the
  keyEncipherment and dataEncipherment key usage bits when used in
  certificates that support Elliptic Curve Cryptography.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ballot/


No IPR declarations have been submitted directly on this I-D.




2020-02-07
00 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-02-07
00 Roman Danyliw Last call was requested
2020-02-07
00 Roman Danyliw Last call announcement was generated
2020-02-07
00 Roman Danyliw Ballot approval text was generated
2020-02-07
00 Roman Danyliw Ballot writeup was generated
2020-02-07
00 Roman Danyliw IESG state changed to Last Call Requested from Publication Requested
2020-02-07
00 Roman Danyliw AD review: https://mailarchive.ietf.org/arch/msg/spasm/4gWhR64UmS09yFYIsVmrnfOoxBk
2020-02-01
00 Russ Housley
Shepherd Write-up for draft-ietf-lamps-5480-ku-clarifications-00


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the …
Shepherd Write-up for draft-ietf-lamps-5480-ku-clarifications-00


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for Standards Track.
 
  This new RFC will update RFC 5480, which is a Proposed Standard.
 

(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

    This document updates RFC 5480 to specify semantics for the
    keyEncipherment and dataEncipherment key usage bits when used
    in certificates that support Elliptic Curve Cryptography.

  Working Group Summary:

    There is consensus for this document in the LAMPS WG.

  Document Quality:

    The information in this mail list posting shows that this
    guidance is needed:

    https://mailarchive.ietf.org/arch/msg/spasm/mSDS2rOYWoX6jb-d9TmXug3OgPo
   
  Personnel:

    Russ Housley is the document shepherd.
    Roman Danyliw is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document during
  WG Last Call.  All issues were raised and resolved prior to the
  LAMPS WG adopting the document.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  Several people that were involved in the PKIX WG were part of the
  review that took place during LAMPS WG Last Call.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any
  additional IP that was introduced in the updates to the document.

  The authors have explicitly stated that they do not hold any IPR
  related to the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the LAMPS WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  This document, once it is approved, will update RFC 5480.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes, all of them are normative.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are downward normative reference to Informational RFC 2986,
  but it is already in the downref registry, so no special action is
  needed.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  This new RFC will update RFC 5480, which is clearly stated on the
  title page and the Abstract.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None are needed.
2020-02-01
00 Russ Housley Responsible AD changed to Roman Danyliw
2020-02-01
00 Russ Housley IETF WG state changed to Submitted to IESG for Publication from WG Document
2020-02-01
00 Russ Housley IESG state changed to Publication Requested from I-D Exists
2020-02-01
00 Russ Housley IESG process started in state Publication Requested
2020-02-01
00 Russ Housley
Shepherd Write-up for draft-ietf-lamps-5480-ku-clarifications-00


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the …
Shepherd Write-up for draft-ietf-lamps-5480-ku-clarifications-00


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for Standards Track.
 
  This new RFC will update RFC 5480, which is a Proposed Standard.
 

(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

    This document updates RFC 5480 to specify semantics for the
    keyEncipherment and dataEncipherment key usage bits when used
    in certificates that support Elliptic Curve Cryptography.

  Working Group Summary:

    There is consensus for this document in the LAMPS WG.

  Document Quality:

    The information in this mail list posting shows that this
    guidance is needed:

    https://mailarchive.ietf.org/arch/msg/spasm/mSDS2rOYWoX6jb-d9TmXug3OgPo
   
  Personnel:

    Russ Housley is the document shepherd.
    Roman Danyliw is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document during
  WG Last Call.  All issues were raised and resolved prior to the
  LAMPS WG adopting the document.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  Several people that were involved in the PKIX WG were part of the
  review that took place during LAMPS WG Last Call.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any
  additional IP that was introduced in the updates to the document.

  The authors have explicitly stated that they do not hold any IPR
  related to the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the LAMPS WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  This document, once it is approved, will update RFC 5480.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes, all of them are normative.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are downward normative reference to Informational RFC 2986,
  but it is already in the downref registry, so no special action is
  needed.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  This new RFC will update RFC 5480, which is clearly stated on the
  title page and the Abstract.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None are needed.
2020-02-01
00 Russ Housley Changed consensus to Yes from Unknown
2020-02-01
00 Russ Housley Intended Status changed to Proposed Standard from None
2020-02-01
00 Russ Housley Notification list changed to Russ Housley <housley@vigilsec.com>
2020-02-01
00 Russ Housley Document shepherd changed to Russ Housley
2020-01-08
00 Jenny Bui This document now replaces draft-turner-5480-ku-clarifications instead of None
2020-01-08
00 Sean Turner New version available: draft-ietf-lamps-5480-ku-clarifications-00.txt
2020-01-08
00 (System) New version accepted (logged-in submitter: Sean Turner)
2020-01-08
00 Sean Turner Uploaded new revision