Skip to main content

Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-21

Revision differences

Document history

Date Rev. By Action
2024-01-26
21 Gunter Van de Velde Request closed, assignment withdrawn: Carlos Martínez Last Call OPSDIR review
2024-01-26
21 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2023-10-31
21 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2023-09-19
21 (System) RFC Editor state changed to AUTH48
2023-08-08
21 (System) RFC Editor state changed to RFC-EDITOR from REF
2023-08-04
21 (System) RFC Editor state changed to REF from EDIT
2023-05-30
21 (System) RFC Editor state changed to EDIT from MISSREF
2023-03-21
21 Russ Housley Added to session: IETF-116: lamps  Wed-0030
2023-03-02
21 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2023-03-02
21 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2023-03-02
21 (System) IANA Action state changed to In Progress from Waiting on Authors
2023-02-21
21 (System) IANA Action state changed to Waiting on Authors from In Progress
2023-02-20
21 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2023-02-20
21 Tero Kivinen Assignment of request for Last Call review by SECDIR to Nick Sullivan was marked no-response
2023-02-17
21 (System) RFC Editor state changed to MISSREF
2023-02-17
21 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2023-02-17
21 (System) Announcement was received by RFC Editor
2023-02-17
21 (System) IANA Action state changed to In Progress
2023-02-17
21 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2023-02-17
21 Cindy Morgan IESG has approved the document
2023-02-17
21 Cindy Morgan Closed "Approve" ballot
2023-02-17
21 Cindy Morgan Ballot approval text was generated
2023-02-17
21 Roman Danyliw IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2023-02-17
21 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-21.txt
2023-02-17
21 (System) New version approved
2023-02-17
21 (System) Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , Steffen Fries
2023-02-17
21 Hendrik Brockhaus Uploaded new revision
2023-01-12
20 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-20.txt
2023-01-12
20 (System) New version approved
2023-01-12
20 (System) Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , Steffen Fries
2023-01-12
20 Hendrik Brockhaus Uploaded new revision
2023-01-12
19 Sabrina Tanamal
I have reviewed the document for the Well-Known URI Path Segments for this document: https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/. I think there is an issue in section 6.1 …
I have reviewed the document for the Well-Known URI Path Segments for this document: https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/. I think there is an issue in section 6.1 that looks like a copy/paste type of error:

Snippet from table 1 in section 6.1 (page 79):

+----------------------------+--------------------+---------+
| Get CA Certificates | getcacerts | Section |
| | | 4.3.1 |
+----------------------------+--------------------+---------+
| Get Root CA Certificate | getrootupdate | Section |
| Update | | 4.3.2 |
+----------------------------+--------------------+---------+
| Get CA Certificates | getcertreqtemplate | Section |
| | | 4.3.1 |
+----------------------------+--------------------+---------+
| CRL Update Retrieval | getcrls | Section |
| | | 4.3.4 |
+----------------------------+--------------------+---------+

The "Get CA Certificates" PKI Management Operation is listed twice. The second time it refers to the same section 4.3.1. The path Segment says "getcertreqtemplate". I compared it to the CoAP Transfer from table 2 in section 6.2, and section 6.2 seems correct and it contains a PKI Management Operation of "Get Certificate Request Template" which is what I think was meant in section 6.1.

From Table 2 section 6.2 (page 82) - Notice no duplicate and reference to 4.3.3
+---------------------------------------+---------+---------+
| Get CA Certificates | crts | Section |
| | | 4.3.1 |
+---------------------------------------+---------+---------+
| Get Root CA Certificate Update | rcu | Section |
| | | 4.3.2 |
+---------------------------------------+---------+---------+
| Get Certificate Request Template | att | Section |
| | | 4.3.3 |
+---------------------------------------+---------+---------+
| CRL Update Retrieval | crls | Section |
| | | 4.3.4 |
+---------------------------------------+---------+---------+


So I think section 6.1 needs to be updated as follows:

+----------------------------+--------------------+---------+
| Get CA Certificates | getcacerts | Section |
| | | 4.3.1 |
+----------------------------+--------------------+---------+
| Get Root CA Certificate | getrootupdate | Section |
| Update | | 4.3.2 |
+----------------------------+--------------------+---------+
| Get Certificate Request Template | getcertreqtemplate | Section |
| | | 4.3.3 |
+----------------------------+--------------------+---------+
| CRL Update Retrieval | getcrls | Section |
| | | 4.3.4 |
+----------------------------+--------------------+---------+

The rest of it looks correct to me.
2023-01-12
19 Sabrina Tanamal IANA Experts State changed to Issues identified from Reviews assigned
2023-01-11
19 (System) Removed all action holders (IESG state changed)
2023-01-11
19 (System) Sub state has been changed to AD Followup from Revised ID Needed
2023-01-11
19 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-19.txt
2023-01-11
19 (System) New version approved
2023-01-11
19 (System) Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , Steffen Fries
2023-01-11
19 Hendrik Brockhaus Uploaded new revision
2023-01-09
18 Roman Danyliw Proposed text to respond to IESG Review: https://mailarchive.ietf.org/arch/msg/spasm/57bqaUQjRT1u2AjomYU1NC_XzvA/
2023-01-09
18 (System) Changed action holders to Steffen Fries, Hendrik Brockhaus, David von Oheimb (IESG state changed)
2023-01-09
18 Roman Danyliw IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup
2023-01-03
18 Sabrina Tanamal IANA Experts State changed to Reviews assigned from Need IANA Expert(s)
2022-12-15
18 Roman Danyliw Authors reviewing remaining IESG feedback (Murray's ballot): https://mailarchive.ietf.org/arch/msg/spasm/57bqaUQjRT1u2AjomYU1NC_XzvA/
2022-12-15
18 (System) Removed all action holders (IESG state changed)
2022-12-15
18 Roman Danyliw IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation::AD Followup
2022-12-12
18 Murray Kucherawy
[Ballot comment]
Section 1.7 uses a SHOULD NOT before that expression is defined in Section 1.9.

The bulk of the SHOULDs in this document would …
[Ballot comment]
Section 1.7 uses a SHOULD NOT before that expression is defined in Section 1.9.

The bulk of the SHOULDs in this document would benefit from review and possible tuning.  SHOULD presents a choice for the implementer; it would be helpful to include with that choice some guidance about when one might legitimately deviate from what's stated.  If SHOULD is being used as "you really oughta do this, but you don't really have to and things will interoperate just fine", it doesn't deserve SHOULD; if what you mean is "yes you have to do this from now on, but we're retaining backward compatibility here" then it should say that explicitly.  In other cases, I wonder if you don't really mean MUST.

For instance, in 3.1, you have this:

    -- SHOULD contain a name representing the originator of the
    --  message; otherwise, the NULL-DN (a zero-length
    --  SEQUENCE OF RelativeDistinguishedNames) MUST be used

Looks great; I have no wiggle room.  Then you have this:

    -- SHOULD be the subject of the CMP protection certificate, i.e.,
    --  the certificate corresponding to the private key used to
    --  sign the message

Well, what if I don't do that?  Does anything break?  Can I just put whatever in there and everything still works?  If nothing breaks, why isn't this "MAY" or something that doesn't use a BCP 14 keyword?  If something breaks, why isn't this a MUST?

In 3.4:

"Each EE SHOULD know its own identity to fill the sender field."

What happens if I don't?  And what interoperability aspect fails if I don't know my own identity?  Should this be better expressed as "Each EE SHOULD fill the sender field with its own identity?"  Why isn't that a MUST?

The two SHOULDs at the bottom of 3.5 seem suspect too.  Since you're giving me a choice, I'm within specifications to consider the input valid if all of those tests fail.  Is that what's intended?

I'm not going to get into any of them past the bottom of Section 3, but hopefully you can see what I'm getting at.  I would typically DISCUSS this pattern, but since I'm so late to the party, I'll leave it to Roman to decide how much this observation weighs on the strength of the document.
2022-12-12
18 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2022-12-06
18 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-18.txt
2022-12-06
18 Hendrik Brockhaus New version accepted (logged-in submitter: Hendrik Brockhaus)
2022-12-06
18 Hendrik Brockhaus Uploaded new revision
2022-12-01
17 Roman Danyliw
Next steps after the telechat: Thanks for -16 and -17 to address all IESG review feedback to date.  Unfortunately, not enough of the IESG has …
Next steps after the telechat: Thanks for -16 and -17 to address all IESG review feedback to date.  Unfortunately, not enough of the IESG has balloted on this document.  At least more more AD position is required.  A few have volunteered to add a ballot early next week.
2022-12-01
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2022-12-01
17 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-17.txt
2022-12-01
17 Hendrik Brockhaus New version accepted (logged-in submitter: Hendrik Brockhaus)
2022-12-01
17 Hendrik Brockhaus Uploaded new revision
2022-12-01
16 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2022-12-01
16 Paul Wouters
[Ballot comment]
Thanks for this document. It is clear even though it is a tad long :-)
Some minor comments:

  Though CMP is a …
[Ballot comment]
Thanks for this document. It is clear even though it is a tad long :-)
Some minor comments:

  Though CMP is a capable protocol it is so far not used very widely.
  The most important reason appears to be that the protocol offers a
  too large set of features and options.

I would say [citation needed] here...

In section 6:
        HTTP SHOULD be used and CoAP MAY be used
 
        File-based transfer MAY be used in case offline transfer is required.

I find these different levels of usage odd. Clearly devices have no real choice here. If they can support HTTP, there is no need for CoAP.
If they cannot do HTTP and therefor can only do CoAP, there is no choice either. If they are offline, clearly they cannot use anything but
file based transfer. I would set all of these to MAY ?

In section 6.1:

        the recommendations provided in [I-D.ietf-uta-rfc7525bis] SHOULD be considered.

"considered" is already a watered down version of "followed". So either use MUST be considered or "SHOULD be followed" and not "SHOULD be considered"
2022-12-01
16 Paul Wouters [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters
2022-12-01
16 Robert Wilton
[Ballot comment]
Hi,

Thanks for this document.  I just have a couple of comments:

(1) p 7, sec 1.5.  Use of CMP in SZTP and …
[Ballot comment]
Hi,

Thanks for this document.  I just have a couple of comments:

(1) p 7, sec 1.5.  Use of CMP in SZTP and BRSKI Environments

  In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other
  environments using NETCONF/YANG modules, SZTP-CSR
  [I-D.ietf-netconf-sztp-csr] offers a YANG module that includes
  different types of certificate requests to obtain a public-key
  certificate for a locally generated key pair.  One option is using a
  CMP p10cr message.  Such a message is of the form ietf-ztp-types:cmp-
  csr from module ietf-ztp-csr and offers both proof-of-possession and
  proof-of-identity.  To allow PKI management entities to also comply
  with this profile, the p10cr message MUST be formatted by the EE as
  described in Section 4.1.4 of this profile, and it MAY be forwarded
  as specified in Section 5.2.

Given the MUST statement above, should this document "update" ietf-netconf-sztp-csr?


(2) p 7, sec 1.5.  Use of CMP in SZTP and BRSKI Environments

  In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]
  environments, BRSKI-AE: Alternative Enrollment Protocols in BRSKI
  [I-D.ietf-anima-brski-ae] describes a generalization regarding the
  employed enrollment protocols to allow alternatives to EST [RFC7030].
  For the use of CMP, it requires adherence to this profile.

Similar to my comment above, should the "requires adherence" be "MUST adhere", and should this document "update" (BRSKI) [RFC8995]?

Thanks,
Rob
2022-12-01
16 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2022-12-01
16 Francesca Palombini
[Ballot comment]
Thank you for the work on this document, which although long I found quite easy to read.

Many thanks to Robert Sparks for …
[Ballot comment]
Thank you for the work on this document, which although long I found quite easy to read.

Many thanks to Robert Sparks for his ART ART review: https://mailarchive.ietf.org/arch/msg/spasm/msD0CJEIXAeQnqDNawoqS28WPKY/ and to the authors for addressing his comments. I agree with him and haven't found any ART issues. I understand and share his concern about whether the document unintentionally allows behavior that the framework it is profiling would not, but I trust the working group and the responsible AD to have that covered.

Francesca
2022-12-01
16 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2022-12-01
16 Éric Vyncke
[Ballot comment]
Due to time pressure, I am relying completely on the Internet directorate review done by Sheng Jiang: https://datatracker.ietf.org/doc/review-ietf-lamps-lightweight-cmp-profile-15-intdir-telechat-jiang-2022-11-22/

Thank you Sheng for this …
[Ballot comment]
Due to time pressure, I am relying completely on the Internet directorate review done by Sheng Jiang: https://datatracker.ietf.org/doc/review-ietf-lamps-lightweight-cmp-profile-15-intdir-telechat-jiang-2022-11-22/

Thank you Sheng for this review.
2022-12-01
16 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-12-01
16 Andrew Alston [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston
2022-11-30
16 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2022-11-30
16 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2022-11-30
16 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2022-11-30
16 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-16.txt
2022-11-30
16 Hendrik Brockhaus New version accepted (logged-in submitter: Hendrik Brockhaus)
2022-11-30
16 Hendrik Brockhaus Uploaded new revision
2022-11-29
15 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from No Record
2022-11-29
15 Warren Kumari
[Ballot comment]
Firstly, thank you very much to the authors for writing this -- I especially liked Section 1.1 :-)

I have a number of …
[Ballot comment]
Firstly, thank you very much to the authors for writing this -- I especially liked Section 1.1 :-)

I have a number of editorial suggestions to (hopefully) further improve the document


1: Sec 1
"Therefore, this document aims at tailoring the available options and specifying at an adequate detail how" - "at an adequate detail how" seems to be missing "level"?
Actually, I think rewriting it as: "Therefore, this document aims to tailor the available options and specify how to use them in adequate detail to make the implementation of interoperable automated certificate management as straightforward and lightweight as possible." is more readable.

2: Sec 1.3
"are not deployed on-site but in a high protected data center environment" - s/high/highly/

3: Sec 1.6
"This results in violating the general rule that a certificate request transaction must include a certConf message (since moreover, using implicitConfirm is not allowed there, neither)."
You seem to have a bunch of double-negatives here -- I think the last word should be "either" or the "not" should be dropped.

4: Sec 1.7
"To minimize ambiguity and complexity through needless variety, this document specifies exhaustive requirements on generating PKI management messages on the sender side." - "on generating" or "for generating"

5: Sec 1.8
"Section 5 profiles responding to requests, exchange between PKI management entities, ..." -- exchanges

6: Sec 1.9
"The figure above shows an architecture example with at least one LRA" -- architectural... actually, I don't know, but the current seems wrong.

7: Sec 3.6.1
"An EE SHALL NOT send error messages. PKI management entities SHALL NOT send error messages in upstream direction, either." -- the upstream.
2022-11-29
15 Warren Kumari Ballot comment text updated for Warren Kumari
2022-11-27
15 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-lamps-lightweight-cmp-profile-15
CC @ekline

Thanks to Niklas Widell for the IoT-DIR review.

## Nits

### S3.1

* s/signthe/sign the/ …
[Ballot comment]
# Internet AD comments for draft-ietf-lamps-lightweight-cmp-profile-15
CC @ekline

Thanks to Niklas Widell for the IoT-DIR review.

## Nits

### S3.1

* s/signthe/sign the/

### S4.1

* "allows for providing proof-of-possession any method that a key can used for"

  ->

  "allows for providing proof-of-possession using any method that a key can be used for"

  perhaps?

### S4.1.1

* "further requests MUST be sent using separate PKI management operation"

  ->

  "further requests MUST be sent using separate PKI management operations"?

### S4.2

* "requests the revocation of an own certificate" ->
  "requests the revocation of an owned certificate"?

### S4.3.4

* "to identify a CRL for which is available" ->
  "to identify a CRL for which information is available"?
2022-11-27
15 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-11-25
15 Niklas Widell Request for Telechat review by IOTDIR Completed: Ready with Nits. Reviewer: Niklas Widell. Sent review to list.
2022-11-22
15 Sheng Jiang Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Sheng Jiang. Sent review to list.
2022-11-21
15 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2022-11-18
15 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Sheng Jiang
2022-11-18
15 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Sheng Jiang
2022-11-17
15 Jean-Michel Combes Assignment of request for Telechat review by INTDIR to Jean-Michel Combes was rejected
2022-11-15
15 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Jean-Michel Combes
2022-11-15
15 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Jean-Michel Combes
2022-11-14
15 Ines Robles Request for Telechat review by IOTDIR is assigned to Niklas Widell
2022-11-14
15 Ines Robles Request for Telechat review by IOTDIR is assigned to Niklas Widell
2022-11-14
15 Éric Vyncke Requested Telechat review by IOTDIR
2022-11-14
15 Éric Vyncke Requested Telechat review by INTDIR
2022-10-27
15 Roman Danyliw Placed on agenda for telechat - 2022-12-01
2022-10-27
15 Roman Danyliw Ballot has been issued
2022-10-27
15 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2022-10-27
15 Roman Danyliw Created "Approve" ballot
2022-10-27
15 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2022-10-27
15 Roman Danyliw Ballot writeup was changed
2022-10-24
15 (System) Changed action holders to Roman Danyliw (IESG state changed)
2022-10-24
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-10-24
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2022-10-24
15 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-15.txt
2022-10-24
15 Hendrik Brockhaus New version accepted (logged-in submitter: Hendrik Brockhaus)
2022-10-24
15 Hendrik Brockhaus Uploaded new revision
2022-10-24
14 Roman Danyliw Please revise per the ARTART comments and review the GENART feedback.
2022-10-24
14 (System) Changed action holders to Roman Danyliw, Steffen Fries, Hendrik Brockhaus, David von Oheimb (IESG state changed)
2022-10-24
14 Roman Danyliw IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2022-10-24
14 (System) IESG state changed to Waiting for Writeup from In Last Call
2022-10-21
14 Robert Sparks Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Robert Sparks. Sent review to list.
2022-10-20
14 Sabrina Tanamal IANA Experts State changed to Need IANA Expert(s)
2022-10-20
14 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2022-10-20
14 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lamps-lightweight-cmp-profile-14. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lamps-lightweight-cmp-profile-14. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the CMP Well-Known URI Path Segments registry on the Certificate Management Protocol (CMP) registry page located at:

https://www.iana.org/assignments/cmp/

twenty new registrations will be made as follows:

+====================+===============================+===============+
| Path Segment | Description | Reference |
+====================+===============================+===============+
| initialization | Enrolling an End Entity to a | [ RFC-to-be ] |
| | New PKI over HTTP | |
+--------------------+-------------------------------+---------------+
| certification | Enrolling an End Entity to a | [ RFC-to-be ] |
| | Known PKI over HTTP | |
+--------------------+-------------------------------+---------------+
| keyupdate | Updating a Valid Certificate | [ RFC-to-be ] |
| | over HTTP | |
+--------------------+-------------------------------+---------------+
| pkcs10 | Enrolling an End Entity Using | [ RFC-to-be ] |
| | a PKCS#10 Request over HTTP | |
+--------------------+-------------------------------+---------------+
| revocation | Revoking a Certificate over | [ RFC-to-be ] |
| | HTTP | |
+--------------------+-------------------------------+---------------+
| getcacerts | Get CA Certificates over HTTP | [ RFC-to-be ] |
+--------------------+-------------------------------+---------------+
| getrootupdate | Get Root CA Certificate | [ RFC-to-be ] |
| | Update over HTTP | |
+--------------------+-------------------------------+---------------+
| getcertreqtemplate | Get CA Certificates over HTTP | [ RFC-to-be ] |
+--------------------+-------------------------------+---------------+
| getcrls | CRL Update Retrieval over | [ RFC-to-be ] |
| | HTTP | |
+--------------------+-------------------------------+---------------+
| nested | Batching Messages over HTTP | [ RFC-to-be ] |
+--------------------+-------------------------------+---------------+
| ir | Enrolling an End Entity to a | [ RFC-to-be ] |
| | New PKI over CoAP | |
+--------------------+-------------------------------+---------------+
| cr | Enrolling an End Entity to a | [ RFC-to-be ] |
| | Known PKI over CoAP | |
+--------------------+-------------------------------+---------------+
| kur | Updating a Valid Certificate | [ RFC-to-be ] |
| | over CoAP | |
+--------------------+-------------------------------+---------------+
| p10 | Enrolling an End Entity Using | [ RFC-to-be ] |
| | a PKCS#10 Request over CoAP | |
+--------------------+-------------------------------+---------------+
| rr | Revoking a Certificate over | [ RFC-to-be ] |
| | CoAP | |
+--------------------+-------------------------------+---------------+
| crts | Get CA Certificates over CoAP | [ RFC-to-be ] |
+--------------------+-------------------------------+---------------+
| rcu | Get Root CA Certificate | [ RFC-to-be ] |
| | Update over CoAP | |
+--------------------+-------------------------------+---------------+
| att | Get Certificate Request | [ RFC-to-be ] |
| | Template over CoAP | |
+--------------------+-------------------------------+---------------+
| crls | CRL Update Retrieval over | [ RFC-to-be ] |
| | CoAP | |
+--------------------+-------------------------------+---------------+
| nest | Batching Messages over CoAP | [ RFC-to-be ] |
+--------------------+-------------------------------+---------------+

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. We are currently requesting that an expert be designated for this registry. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2022-10-17
14 Barry Leiba Request for Last Call review by ARTART is assigned to Robert Sparks
2022-10-17
14 Barry Leiba Request for Last Call review by ARTART is assigned to Robert Sparks
2022-10-17
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2022-10-17
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2022-10-14
14 Joel Halpern Request for Last Call review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list.
2022-10-13
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Nick Sullivan
2022-10-13
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Nick Sullivan
2022-10-13
14 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2022-10-13
14 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2022-10-12
14 David Blacka Request for Last Call review by DNSDIR Completed: Ready. Reviewer: David Blacka. Sent review to list.
2022-10-10
14 Jim Reid Request for Last Call review by DNSDIR is assigned to David Blacka
2022-10-10
14 Jim Reid Request for Last Call review by DNSDIR is assigned to David Blacka
2022-10-10
14 Cindy Morgan IANA Review state changed to IANA - Review Needed
2022-10-10
14 Cindy Morgan
The following Last Call announcement was sent out (ends 2022-10-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lamps-lightweight-cmp-profile@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org …
The following Last Call announcement was sent out (ends 2022-10-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lamps-lightweight-cmp-profile@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Lightweight Certificate Management Protocol (CMP) Profile) 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: - 'Lightweight
Certificate Management Protocol (CMP) Profile'
  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 2022-10-24. 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 aims at simple, interoperable, and automated PKI
  management operations covering typical use cases of industrial and
  IoT scenarios.  This is achieved by profiling the Certificate
  Management Protocol (CMP), the related Certificate Request Message
  Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct
  but sufficiently detailed and self-contained way.  To make secure
  certificate management for simple scenarios and constrained devices
  as lightweight as possible, only the most crucial types of operations
  and options are specified as mandatory.  More specialized or complex
  use cases are supported with optional features.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/



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




2022-10-10
14 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2022-10-10
14 Roman Danyliw Last call was requested
2022-10-10
14 Roman Danyliw Last call announcement was generated
2022-10-10
14 Roman Danyliw Ballot approval text was generated
2022-10-10
14 Roman Danyliw Ballot writeup was generated
2022-10-10
14 Roman Danyliw IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2022-10-05
14 (System) Changed action holders to Roman Danyliw (IESG state changed)
2022-10-05
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-10-05
14 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-14.txt
2022-10-05
14 Hendrik Brockhaus New version accepted (logged-in submitter: Hendrik Brockhaus)
2022-10-05
14 Hendrik Brockhaus Uploaded new revision
2022-09-16
13 Roman Danyliw AD Review: https://mailarchive.ietf.org/arch/msg/spasm/bEe7AOAGy3JXvozoYu_byIFpUOE/
2022-09-16
13 (System) Changed action holders to Roman Danyliw, Steffen Fries, Hendrik Brockhaus, David von Oheimb (IESG state changed)
2022-09-16
13 Roman Danyliw IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2022-07-13
13 Russ Housley Added to session: IETF-114: lamps  Wed-1000
2022-07-08
13 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-13.txt
2022-07-08
13 (System) New version approved
2022-07-08
13 (System) Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , Steffen Fries
2022-07-08
13 Hendrik Brockhaus Uploaded new revision
2022-05-13
12 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-12.txt
2022-05-13
12 (System) New version approved
2022-05-13
12 (System) Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , Steffen Fries
2022-05-13
12 Hendrik Brockhaus Uploaded new revision
2022-04-15
11 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-11.txt
2022-04-15
11 (System) New version accepted (logged-in submitter: Hendrik Brockhaus)
2022-04-15
11 Hendrik Brockhaus Uploaded new revision
2022-02-01
10 Russ Housley
Shepherd Write-up for draft-ietf-lamps-lightweight-cmp-profile-10


(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-lightweight-cmp-profile-10


(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.


(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 aims at simple, interoperable, and automated PKI
    management operations covering typical use cases of industrial and
    IoT scenarios.  This is achieved by profiling the Certificate
    Management Protocol (CMP), the related Certificate Request Message
    Format (CRMF), and HTTP-based or CoAP-based transfer.  The profile
    is expected to provide certificate management for simple scenarios
    and constrained devices, only the most crucial types of operations
    and options are mandatory to implement.  While special and complex
    use cases are supported as well, these use cases employ recommended
    or optional features.

  Working Group Summary:

    There is consensus for this document in the LAMPS WG.

  Document Quality:

    Vendors with CMP implementations have indicated that they intend to
    support the lightweight CMP profile.
   
  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 resolved.


(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.

  The PKIX WG developed RFC 4210 (CMP) and RFC 4211 (CRMF).  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.

  One place: s/MUST not/MUST NOT/

  There is 1 instance of lines with non-ascii characters in the document.


(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.


(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?

  There is a normative dependency on draft-ietf-lamps-cmp-updates,
  which has already been sent to the IESG for publication. 

  There are four related Internet-Drafts that are coming to the IESG
  at roughly the same time.  Please publish all four at the same
  time with consecutive RFC numbers.  The documents are:
 
    1.  draft-ietf-lamps-cmp-updates
  2.  draft-ietf-lamps-cmp-algorithms
    3.  draft-ietf-lamps-lightweight-cmp-profile
    4.  draft-ietf-ace-cmpv2-coap-transport


(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.

  None.


(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 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.
2022-02-01
10 Russ Housley Responsible AD changed to Roman Danyliw
2022-02-01
10 Russ Housley IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2022-02-01
10 Russ Housley IESG state changed to Publication Requested from I-D Exists
2022-02-01
10 Russ Housley IESG process started in state Publication Requested
2022-02-01
10 Russ Housley
Shepherd Write-up for draft-ietf-lamps-lightweight-cmp-profile-10


(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-lightweight-cmp-profile-10


(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.


(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 aims at simple, interoperable, and automated PKI
    management operations covering typical use cases of industrial and
    IoT scenarios.  This is achieved by profiling the Certificate
    Management Protocol (CMP), the related Certificate Request Message
    Format (CRMF), and HTTP-based or CoAP-based transfer.  The profile
    is expected to provide certificate management for simple scenarios
    and constrained devices, only the most crucial types of operations
    and options are mandatory to implement.  While special and complex
    use cases are supported as well, these use cases employ recommended
    or optional features.

  Working Group Summary:

    There is consensus for this document in the LAMPS WG.

  Document Quality:

    Vendors with CMP implementations have indicated that they intend to
    support the lightweight CMP profile.
   
  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 resolved.


(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.

  The PKIX WG developed RFC 4210 (CMP) and RFC 4211 (CRMF).  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.

  One place: s/MUST not/MUST NOT/

  There is 1 instance of lines with non-ascii characters in the document.


(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.


(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?

  There is a normative dependency on draft-ietf-lamps-cmp-updates,
  which has already been sent to the IESG for publication. 

  There are four related Internet-Drafts that are coming to the IESG
  at roughly the same time.  Please publish all four at the same
  time with consecutive RFC numbers.  The documents are:
 
    1.  draft-ietf-lamps-cmp-updates
  2.  draft-ietf-lamps-cmp-algorithms
    3.  draft-ietf-lamps-lightweight-cmp-profile
    4.  draft-ietf-ace-cmpv2-coap-transport


(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.

  None.


(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 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.
2022-02-01
10 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-10.txt
2022-02-01
10 (System) New version approved
2022-02-01
10 (System) Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , Steffen Fries
2022-02-01
10 Hendrik Brockhaus Uploaded new revision
2021-12-22
09 Russ Housley Notification list changed to housley@vigilsec.com because the document shepherd was set
2021-12-22
09 Russ Housley Document shepherd changed to Russ Housley
2021-12-22
09 Russ Housley IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-12-22
09 Russ Housley Changed consensus to Yes from Unknown
2021-12-22
09 Russ Housley Intended Status changed to Proposed Standard from None
2021-12-17
09 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-09.txt
2021-12-17
09 (System) New version approved
2021-12-17
09 (System) Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , Steffen Fries
2021-12-17
09 Hendrik Brockhaus Uploaded new revision
2021-11-19
08 Russ Housley IETF WG state changed to In WG Last Call from WG Document
2021-11-19
08 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-08.txt
2021-11-19
08 (System) New version approved
2021-11-19
08 (System) Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , Steffen Fries
2021-11-19
08 Hendrik Brockhaus Uploaded new revision
2021-10-25
07 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-07.txt
2021-10-25
07 (System) New version approved
2021-10-25
07 (System) Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , Steffen Fries
2021-10-25
07 Hendrik Brockhaus Uploaded new revision
2021-07-09
06 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-06.txt
2021-07-09
06 (System) New version approved
2021-07-09
06 (System) Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , Steffen Fries
2021-07-09
06 Hendrik Brockhaus Uploaded new revision
2021-07-06
05 Russ Housley Added to session: IETF-111: lamps  Mon-1430
2021-07-06
05 Russ Housley Removed from session: IETF-111: lamps  Thu-1500
2021-07-06
05 Russ Housley Added to session: IETF-111: lamps  Thu-1500
2021-02-22
05 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-05.txt
2021-02-22
05 (System) New version approved
2021-02-22
05 (System) Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , Steffen Fries
2021-02-22
05 Hendrik Brockhaus Uploaded new revision
2020-11-10
04 Russ Housley Added to session: IETF-109: lamps  Tue-1600
2020-11-02
04 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-04.txt
2020-11-02
04 (System) New version approved
2020-11-02
04 (System) Request for posting confirmation emailed to previous authors: Hendrik Brockhaus , David von Oheimb , Steffen Fries
2020-11-02
04 Hendrik Brockhaus Uploaded new revision
2020-10-02
03 (System) New version available: draft-ietf-lamps-lightweight-cmp-profile-03.txt
2020-10-02
03 (System) Posted submission manually
2020-10-02
03 (System) Request for posting confirmation emailed to previous authors: Hendrik Brockhaus , David von Oheimb , Steffen Fries
2020-10-02
03 Hendrik Brockhaus Uploaded new revision
2020-07-11
02 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-02.txt
2020-07-11
02 (System) New version approved
2020-07-11
02 (System) Request for posting confirmation emailed to previous authors: Hendrik Brockhaus , David von Oheimb , Steffen Fries
2020-07-11
02 Hendrik Brockhaus Uploaded new revision
2020-03-26
01 Russ Housley Added to session: interim-2020-lamps-01
2020-03-04
01 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-01.txt
2020-03-04
01 (System) New version approved
2020-03-04
01 (System) Request for posting confirmation emailed to previous authors: David von Oheimb , Hendrik Brockhaus , Steffen Fries
2020-03-04
01 Hendrik Brockhaus Uploaded new revision
2020-02-17
00 Russ Housley This document now replaces draft-brockhaus-lamps-lightweight-cmp-profile instead of None
2020-02-17
00 Hendrik Brockhaus New version available: draft-ietf-lamps-lightweight-cmp-profile-00.txt
2020-02-17
00 (System) WG -00 approved
2020-02-14
00 Hendrik Brockhaus Set submitter to "Hendrik Brockhaus ", replaces to draft-brockhaus-lamps-lightweight-cmp-profile and sent approval email to group chairs: lamps-chairs@ietf.org
2020-02-14
00 Hendrik Brockhaus Uploaded new revision