Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile

[Michael Richardson <[e-mail]>]

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.
  * 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".

  - draft-brockhaus-lamps-lightweight-cmp-profile

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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-