Subject: Re: [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify

From: Russ Housley <[email-masked]>
Date: Fri, 3 Jan 2020 12:54:39 -0500

A few people have spoken in support of adopting this document without GRASP discovery.  No one has spoken against adoption.

So, the LAMPS WG has adopted it.

Michael, please revise the document to remove GRASP discovery, and then post draft-ietf-lamps-rfc7030est-clarify-00.

Russ

> On Dec 22, 2019, at 9:46 PM, Russ Housley <[email-masked]> wrote:
> 
> Please indicate whether you support adoption of draft-richardson-lamps-rfc7030est-clarify by the LAMPS WG by January 3rd.
> 
> I previously sent a message with this correct subject, but the body contained the wrong draft name.  This restarts the call with a new date.
> 
> Russ
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Jan 2020 19:05:19 +0000

Hi Russ,

On 03/01/2020 17:54, Russ Housley wrote:
> A few people have spoken in support of adopting this document without
> GRASP discovery.  No one has spoken against adoption.
> 

I looked back and it seems that two of the three people who
support adoption are co-authors.

FWIW, while I'm not against adoption (I had a quick read
and am neutral) I'm not convinced that's sufficient, nor
wise - given this is modifying an existing spec. and I'm
not sure all EST implementers are on this list, I'd say
it'd be a better plan to ask e.g. on saag to see if there
are any real objections (or not).

I'm not formally appealing or anything though, mostly
just bemoaning yet another aspect of the reincarnation of
pkix;-)

S.

> 
> Michael, please revise the document to remove GRASP discovery, and
> then post draft-ietf-lamps-rfc7030est-clarify-00.
> 
> Russ
> 
> 
>> Please indicate whether you support adoption of
>> draft-richardson-lamps-rfc7030est-clarify by the LAMPS WG by
>> January 3rd.
>> 
>> I previously sent a message with this correct subject, but the body
>> contained the wrong draft name.  This restarts the call with a new
>> date.
>> 
>> Russ
>> 
> 
> _______________________________________________ Spasm mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Jan 2020 17:51:16 -0500

> are any real objections (or not).

I actually went out to surveyed a few EST implementors back in April/May last
year, hoping that we could kill the base64 by signaling it with
Content-Transfer-Encoding:, but we can't, because EST implementors out there
do not include or pay attention to the header.

Do you want the mailarchive links?

    > just bemoaning yet another aspect of the reincarnation of

My opinion is that anything that makes it easier to automate provisioning of
certificates can make it easier to replace the format without causing a flag day.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Russ Housley <[email-masked]>
Date: Tue, 7 Jan 2020 10:00:45 -0500

There are two CMP-related documents:
  - draft-brockhaus-lamps-cmp-updates
  - draft-brockhaus-lamps-lightweight-cmp-profile

Please indicate whether you support adoption of zero, one, or both of these documents by the LAMPS WG.  Please respond before January 22nd.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Jan 2020 16:51:20 +0000

I support adoption of both of these.

As a side-note, Hendrik and David are active in contributing CMP support to OpenSSL for the next major release.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jan 2020 15:35:37 -0500

I support adopting

with the following (non-blocking) comments:
  * I find that section 3 lacks motivation for why it is making these changes.
  * why is "The following updates were made since RFC 4210:" in the past tense?
  *
     Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and
     a CMC RA.  As the functionality of a CA and RA is not specific to
     whether use CMC or CMP as certificate management protocol, the same
     OIDs SHALL be used for a cmpCA and a cmpRA.

I believe that I might need a little bit of convincing here on reusing cmpRA.
I want to think about this a bit.... the last two paragraphs of 3.2 hint at
my not well formed concerns.
As such this document would seem to update RFC6402 as well.

I do wonder if 4210bis might be better a better idea rather than
replacing/updated so much "EncryptedValue -> EncryptedKey".

This is the document I'm more interested in.
At 64 pages, I wonder about "lightweight" ;-)
I believe that a two paragraph summary of Appendix D and E would be worthwhile.
How much of 4210 could we just throw out in a 4210bis?
s/IPSec/IPsec/         {it's the brown M&M of rfc4301}

section 2.6 says:
   "Chapter 2", so I think the references are all dangling.
   XML2rfc deals with tis for you, so I'm guessing you aren't using <xref> here?

I find this statement:
   HTTP transfer is RESOMMENDED to use for all PKI entities, but there
   is no transport specified as mandatory to be flexible for devices
   with special constrained to choose whatever transport is suitable.

(aside from the typo), difficult to take in a profile.
RECOMMENDED is a synonym for SHOULD, and usually needs to have some
explanation of when another answer is appropriate.
If you want to be open to COAP, then let's just say that.
I'm glad that section 7.1 makes the URL clear.
I think that lower case 'cmp' would be more consistent with other .well-known uses.

7.2 should say TLS 1.2 or greater/newer, rather than saying 1.2 or 1.3.

Both the HTTP and HTTPS usage might need to be clear if support for
HTTP/2 and/or QUIC is expected to be supported.  Constrained environments
want to know what they can skip.

7.5.  CoAP transport
   ...
   Such specification is out of scope of this document and would need to
   be specifies in a separate document.

I think that it's not that hard to specify this.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 8 Jan 2020 11:49:20 +0100

I support the adoption of both drafts for further work in the WG.

My comments on the draft right now:

1. I oppose the usage of .well-known URLs in this context. I don't
consider CMP end points being in the line of the definition of
.well-known as specified in RFC5785. A CMP end point is not meta-data.
If anything .well-known shold be used for discovering the active CMP end
point urls (see point 2).

2. A single CMP end point url path does not work when servicing multiple
CAs and use cases. Since real CMP end points are not "serve all
everything they ask for", multiple configurations, access rights and
profiles are needed. Today this is commonly implemented by different CMP
url paths. It is not technically possible, within the scope of RFC4210,
to merge all uses cases into a single url path. Any CMP profile should
support multiple url-paths.

3. The multiple url paths defined in 7.1 for different operations is
redundant for CMP, as this information is already in the CMP messages.
CMP works very well with a single url path for all messages and
establishing a new scheme will break interoperability, not foster imho.

Regards,
Tomas

On 2020-01-07 16:00, Russ Housley wrote:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 8 Jan 2020 11:22:27 +0000

I support the adoption of both these documents with the preference of 
finishing draft-brockhaus-lamps-cmp-updates before dealing with the 
lightweight profile.

--Mohit

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 15 Jan 2020 14:25:16 +0000

Michael,

Thank you for you detailed feedback and comments. Below you find my feedback to your comments. (Sorry for my late response...)

> Von: Spasm <[email-masked]> Im Auftrag von Michael Richardson
> 
> I support adopting
[Bro] Thank you for your support!

>   * I find that section 3 lacks motivation for why it is making these changes.
[Bro] The idea is that New Section 1.1 provides the motivation for the changes. The other sections should only contain the technical changes. Does New Section 1.1 is not descriptive enough?

>   * why is "The following updates were made since RFC 4210:" in the past
[Bro] Actually I took Jim Schaad's RFC 6402 'Updates CMC' as of blueprint. He put it a bit different like "The following updates were made by RFC 6402.". I am not a native speaker, so I am not sure about the correct tense to use here. Should I say "The following updates are made in draft-brockhaus-lamps-cmp-updates:" and replace the draft-... with the RFC number after the release? But I am happy for any concrete suggestions on how to put it best.

> I believe that I might need a little bit of convincing here on reusing cmpRA.
[Bro] My first approach was to specify new OIDs for cmpCA and cmpRA, but during the discussion at IETF106 Sean Turner suggested to reuse the OIDs already specified for CMC here. As the EKU OIDs specify for which purpose the public key may be used, I see no much differences between the usage of a public key for CMC and for CMP from a key usage perspective. Therefore, I took Sean's suggestion and tried to express the idea in this Note.
 
> I want to think about this a bit.... the last two paragraphs of 3.2 hint at my not
> well formed concerns.
[Bro] You are right, the issue with undefined validation dates is an issue for all certificates used for PKI management entities. So you may be right, that this is also relevant for CMC or EST. I personally see it as a matter of course to use limited validity for those certificates used on PKI management entities. Therefore it is only a Note her. 

> replacing/updated so much "EncryptedValue -> EncryptedKey".
[Bro] The idea was not to write a 4210bis but to have only very limited updates to CMP together with a concrete profiling. Reworking the complete 4210 RFC would be much more effort and would need much more community support. 

> At 64 pages, I wonder about "lightweight" ;-)
[Bro] You are right, 64 pages does not look lightweight. Lightweight refers more to the very limited number of mandatory use cases as specified in section 3.3.1.
This is on the EE only the initialization and update and on the RA the forwarding with and without changing the original message. 

> I believe that a two paragraph
> summary of Appendix D and E would be worthwhile.
[Bro] I thought the very brief summary in section 2.3 is sufficient and for more details one would anyhow look into RFC4210. But I can add a detailed summary to section 2.3, if you think it is helpful.

> How much of 4210 could we just throw out in a 4210bis?
[Bro] For the use in automated certificate management in a machine-to-machine communication environment we do not need many feature specified in CMP and CRMF. That is why I wrote the profile to specify what to use and what not. 
I also see the value of a 4210bis and throw away all what is not needed, but I can not say what features of CMP are needed for other use case. Therefore Profiling is an approach we can do focusing on our uses cases and 4210bis is the bigger approach where we have to take all existing uses cases into account. This is something a bigger group of people would have to contribute.

>    XML2rfc deals with tis for you, so I'm guessing you aren't using <xref> here?
[Bro] You are right, I will change this to <xref> and Section x. 
BTW: Should I always use Section instead of Chapter in this document? 
In later sections I referred to the top-level structure as Chapters and subsections as Section.

> If you want to be open to COAP, then let's just say that.
[Bro] You are right, I see HTTP transfer as the most important transport option as it is already specified in RFC6712. But I also see devices and uses cases where HTTP transfer will not be possible. In offline scenarios we would need some file based transport, in constrained environments CoAP is used instead of HTTP, and in any other environment for example the last mile to the EE is bridged with some wireless protocol like NFC or what so ever. The advantage of CMP is to have no requirements regarding transport but reliability.

There is also some explanation at the beginning of section 7 on this. 
   The CMP messages are designed to be self-contained, such that in
   principle any transport can be used.  HTTP SHOULD be used for online
   transport while file-based transport MAY be used in case offline
   transport is required.  In case HTTP transport is not desired or
   possible, CMP messages MAY also be piggybacked on any other reliable
   transport protocol, e.g., CoAP [RFC7252].

Is this more what you were looking for?
Should I also add some more description in section 3.4?.

> I think that lower case 'cmp' would be more consistent with other .well-known
[Bro] Good to hear that you like it. There was further feedback from Tomas Gustavsson regarding the URIs and I see his concern regarding endpoints for different CAs and different types of certificates to be request as valid. As it is seems to be easy to spot the message type from the header of the CMP message (except for central key generation and general messages, there you need to look into the type field in the body too), there is no real technical need for the second half of the URL. On the other hand an 'arbitraryLable' as also specified in EST section 3.2.2 could be used to specify the CA or CA profile to be used. 
Actually, I am not finally sure on what the best solution would be and I appreciate all thoughts on this. Let us continue this discussion in response to the email from Tomas to have the discussion regarding this topic in one thread.

> want to know what they can skip.
[Bro] Thank you for this hint. I will talk to Steffen Fries, he is more expert in this.
 
> I think that it's not that hard to specify this.
[Bro] In the first version of this document I also had CoAP in scope. But after synchronization with Jim Schaad and the ACE WG, we decided to have this out of scope of this draft to have a more clear focus on LAMPS and to circumvent overlaps with ACE.
We have more practical experiences with HTTP and only some experiences with CoAP transfer (see https://github.com/siemens/embeddedCMP). I am open to take CoAP transfer back into scope, but I would need someone with more CoAP experiences to properly write this section.

Hendrik Brockhaus
Siemens AG
Corporate Technology
Research in Digitalization and Automation
Security Architecture
CT RDA CST SEA-DE
Otto-Hahn-Ring 6
81739 Muenchen, Germany 
Tel.: +49 89 636-633672
Mobile: +49 174 1517765
mailto:[email-masked]

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 15 Jan 2020 14:25:25 +0000

Tomas

Many thanks for your feedback and support.
My comments are inline below.

> Von: Spasm <[email-masked]> Im Auftrag von Tomas Gustavsson
> 
[Bro] Thanks, and many thanks for your review and discussion we had already.

> 1. I oppose the usage of .well-known URLs in this context. I don't consider CMP
> end points being in the line of the definition of ..well-known as specified in
> RFC5785. A CMP end point is not meta-data.
> If anything .well-known shold be used for discovering the active CMP end point
> urls (see point 2).
[Bro] Currently I saw the concept of .well-known URIs in EST and BRSKI. As far as I understand your concerns, the concept of .well-known URIs should only be used to offer meta-data on the services provided by, e.g., an RA. Such meta-data could than be the list of supported use cases according Schüppler the lightweight CMP profile and the list of supported CAs or certificate profiles. The format for such meta-data must be specified then too, I guess. Is this what you meant?
Michael Richardson also gave feedback to the .well-known URIs I specified in section 7.1.
@Michael, may be you can also bring in your opinion in this tread.

Are there further opinions on this?
Does anyone has expertise on the requested meta-data approach?

> 
> 2. A single CMP end point url path does not work when servicing multiple CAs
> and use cases. Since real CMP end points are not "serve all everything they ask
> for", multiple configurations, access rights and profiles are needed. Today this
> is commonly implemented by different CMP url paths. It is not technically
> possible, within the scope of RFC4210, to merge all uses cases into a single url
> path. Any CMP profile should support multiple url-paths.
[Bro] I found section 3.2.2 in RFC7030.
" 3.2.2.  HTTP URIs for Control

[...]

   An EST server MAY provide service for multiple CAs as indicated by an
   OPTIONAL additional path segment between the registered application
   name and the operation path.  To avoid conflict, the CA label MUST
   NOT be the same as any defined operation path segment.  The EST
   server MUST provide services regardless of whether the additional
   path segment is present.  The following are three example valid URIs:

   1.  https://www.example.com/.well-known/est/cacerts

   2.  https://www.example.com/.well-known/est/arbitraryLabel1/cacerts

   3.  https://www.example.com/.well-known/est/arbitraryLabel2/cacerts

   In this specification, the distinction between enroll and renew/rekey
   is explicitly indicated by the HTTP URI.  When requesting /fullcmc
   operations, CMC [RFC5272] uses the same messages for certificate
   renewal and certificate rekey.

   An EST server can provide additional services using other URIs."

What do you think of this approach using an "arbitraryLable" to identify the CA or certificate profile that is to be addressed? Would that solve your problem?

> 
> 3. The multiple url paths defined in 7.1 for different operations is redundant for
> CMP, as this information is already in the CMP messages.
> CMP works very well with a single url path for all messages and establishing a
> new scheme will break interoperability, not foster imho.
[Bro] Yes, CMP messages types can be easily identified from the body type. Together with the transactionId of the message headers, the client and server can easily identify the intended uses case.
As an example, the paths specified in section 7.1 not directly map with one specific CMP body type. For example /initialization is a sequence of ir (EE->RA) and ip (RA->EE) and optionally certConf (EE->RA) and pkiconf (RA->EE). In case of an error the error message is sent to terminate the transaction. All messages are bundled in a transaction identified by the transactionId in the message header. So ir and certConf will both be sent to .well-known/cmp/initialization.
But there is some overlap with /serverkeygen, that uses the same body types. To spot that this is different, one has to dig quite deep into the certificate request to figure out that there is no public key in it. 
Also the different use cases using support messages cannot be differentiated purely by evaluating the body type. Also the infoType field of the genm message body must be taken into account.

Actually, I am not decided whether to only specify a .well-known/cmp URI and identify the rest from the body type and the transactionId, etc., or a .well-known/cmp/optionalArbitraryLable/path where 'path' clearly identifies the use case from the Lightweight CMP Profile and the optional lable directly identifies the addressed CA or certificate profile.

@Tomas, Michael, what do you think?
Are there further opinions on this?

> > Please indicate whether you support adoption of zero, one, or both of these
> documents by the LAMPS WG.  Please respond before January 22nd.
> >
> > Russ
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.bro
> ck
> >
> haus%40siemens.com%7Cb6b051019f8247ba2b1908d79428757f%7C38ae3bcd9
> 5794f
> >
> d4addab42e1495d55a%7C1%7C0%7C637140773796808073&amp;sdata=p7nIO
> 8qmA5aH
> > ibPuzzxT0ZU7%2BtEum8xK984W87WisLI%3D&amp;reserved=0
> >
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.
> org%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.brockha
> us%40siemens.com%7Cb6b051019f8247ba2b1908d79428757f%7C38ae3bcd957
> 94fd4addab42e1495d55a%7C1%7C0%7C637140773796808073&amp;sdata=p7
> nIO8qmA5aHibPuzzxT0ZU7%2BtEum8xK984W87WisLI%3D&amp;reserved=0

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Jan 2020 13:40:42 -0500

Brockhaus, Hendrik <[email-masked]> wrote:
    >> I support adopting - draft-brockhaus-lamps-cmp-updates

    >>
    >> with the following (non-blocking) comments: * I find that section 3
    >> lacks motivation for why it is making these changes.

    > [Bro] The idea is that New Section 1.1 provides the motivation for the
    > changes. The other sections should only contain the technical
    > changes. Does New Section 1.1 is not descriptive enough?

lamps-cmp-updates hasn't got a section 1.1
lamps-industrial-cmp-profile-00 has a 1.1, but I didn't read that.
lamps-leightweight-cmp-profile hasn't got a 1.1, but a 2.1.
I think that your numbering of sections is not what you think it is :-)

    > the correct tense to use here. Should I say "The following updates are
    > made in draft-brockhaus-lamps-cmp-updates:" and replace the

I think so.

    >> section 2.6 says: "Chapter 2", so I think the references are all
    >> dangling.  XML2rfc deals with tis for you, so I'm guessing you aren't
    >> using <xref> here?
    > [Bro] You are right, I will change this to <xref> and Section x.  BTW:
    > Should I always use Section instead of Chapter in this document?  In
    > later sections I referred to the top-level structure as Chapters and
    > subsections as Section.

The xref will usually expand as Section x.y.z.

    > Is this more what you were looking for?  Should I also add some more
    > description in section 3.4?.

Works for me.

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 16 Jan 2020 11:23:59 +0100

> [Bro] Currently I saw the concept of .well-known URIs in EST and BRSKI. As far as I understand your concerns, the concept of .well-known URIs should only be used to offer meta-data on the services…

Yes. I admit to have limited experience of good usage of .well-known
though.

> What do you think of this approach using an "arbitraryLable" to identify the CA or certificate profile that is to be addressed? Would that solve your problem?

Yes the arbitraryLabel is the approach we use currently, both for EST
and for CMP in fact. I think that works well.

> @Tomas, Michael, what do you think?

Thanks. It was not clear (to me) the full meaning of the label paths
described. Do you mean that multiple messages could be bundled? Or just
that each path would enforce a specific work-flow? I.e. server key gen
is not allowed in /initialization for example?

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 17 Jan 2020 07:29:19 +0000

> I think that your numbering of sections is not what you think it is :-)
[Bro] Sorry for the confusion!
What I was referring to was draft-brockhaus-lamps-cmp-updates-02 section 3.1 with the title " New Section 1.1. - Changes since RFC 4210".
>     > made in draft-brockhaus-lamps-cmp-updates:" and replace the
[Bro] Thanks, I will change it accordingly.
> The xref will usually expand as Section x.y.z.
[Bro] So I will always use the term 'section' and not 'chapter'.
> 
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-

Hendrik Brockhaus
Siemens AG
Corporate Technology

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 17 Jan 2020 10:40:47 +0000

> Von: Tomas Gustavsson <[email-masked]>
> 
> >> ..well-known as specified in RFC5785. A CMP end point is not meta-data.
> >> If anything .well-known shold be used for discovering the active CMP
> >> end point urls (see point 2).
> > [Bro] Currently I saw the concept of .well-known URIs in EST and BRSKI. As far
> as I understand your concerns, the concept of .well-known URIs should only be
> used to offer meta-data on the services provided by, e.g., an RA. Such meta-
> data could than be the list of supported use cases according Schüppler the
> lightweight CMP profile and the list of supported CAs or certificate profiles. The
> format for such meta-data must be specified then too, I guess. Is this what you
> meant?
> 
> Yes. I admit to have limited experience of good usage of .well-known though.
[Bro] @Michael, can you jump in?

> >> 2. A single CMP end point url path does not work when servicing
> >> multiple CAs and use cases. Since real CMP end points are not "serve
> >> all everything they ask for", multiple configurations, access rights
> >> and profiles are needed. Today this is commonly implemented by
> >> different CMP url paths. It is not technically possible, within the
> >> scope of RFC4210, to merge all uses cases into a single url path. Any CMP
> profile should support multiple url-paths.

[Bro] Sorry about the reformatting of the URLS. My office mail client is doing such things for security reasons....
I deleted the enumeration from this email.

> > What do you think of this approach using an "arbitraryLable" to identify the
> CA or certificate profile that is to be addressed? Would that solve your
> problem?
> 
> Yes the arbitraryLabel is the approach we use currently, both for EST and for
> CMP in fact. I think that works well.
[Bro] OK, that is great. I will update the draft accordingly.

> > [Bro] Yes, CMP messages types can be easily identified from the body type.
> Together with the transactionId of the message headers, the client and server
> can easily identify the intended uses case.
> > As an example, the paths specified in section 7.1 not directly map with one
> specific CMP body type. For example /initialization is a sequence of ir (EE->RA)
> and ip (RA->EE) and optionally certConf (EE->RA) and pkiconf (RA->EE). In case
> of an error the error message is sent to terminate the transaction. All
> messages are bundled in a transaction identified by the transactionId in the
> message header. So ir and certConf will both be sent to .well-
> known/cmp/initialization.
> > But there is some overlap with /serverkeygen, that uses the same body types.
> To spot that this is different, one has to dig quite deep into the certificate
> request to figure out that there is no public key in it.
> > Also the different use cases using support messages cannot be differentiated
> purely by evaluating the body type. Also the infoType field of the genm
> message body must be taken into account.
> >
> > Actually, I am not decided whether to only specify a .well-known/cmp URI and
> identify the rest from the body type and the transactionId, etc., or a .well-
> known/cmp/optionalArbitraryLable/path where 'path' clearly identifies the use
> case from the Lightweight CMP Profile and the optional lable directly identifies
> the addressed CA or certificate profile.
> >
> Thanks. It was not clear (to me) the full meaning of the label paths described.
> Do you mean that multiple messages could be bundled? Or just that each path
> would enforce a specific work-flow? I.e. server key gen is not allowed in
> /initialization for example?
[Bro] Yes, the last part of the path should indicate one specific work-flow.

Hendrik Brockhaus
Siemens AG
Corporate Technology

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jan 2020 10:36:59 -0500

> [Bro] @Michael, can you jump in?

{Your non-Usenet non-quoting style makes it very difficult to deal with your
thread.  Please consider getting a standard MUA}

.well-known URIs are not just for meta-data about where the service is.
RFC7030, for instance, puts all of it's end points there.

---

From: Russ Housley <[email-masked]>
Date: Wed, 29 Jan 2020 12:08:51 -0500

Both of these documents are adopted.  I am very pleased to see the discussion of the content has started.

As a matter of priority, the LAMPS WG will complete the cmp-updates document first, but both documents will be worked in parallel.

Russ

> On Jan 7, 2020, at 10:00 AM, Russ Housley <[email-masked]> wrote:
>