Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E7DC15152F for ; Thu, 29 Aug 2024 09:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inria.fr Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cgvsb3Dil5l6 for ; Thu, 29 Aug 2024 09:19:00 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A417C14CE42 for ; Thu, 29 Aug 2024 09:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ti/eaw6X6o+rhNTOQoyo4A79sFBX7bk20x7CTK+oSb8=; b=qCTKabG+Q0USb61i/UdO9NCp01rIW9zw1HmYtsQgb8ReyJUn59f3OMsS ab8EyLdPuOuC9xcOm2+o5hSbbR3o5Ow3xGJJi0W8tV22KxZnE9hUym7qD xuUbo4Oj4RWA/o1IjrMaFQcKLMNRsa4AG3AmxX+Sy8xs2/0cmrc2jwxd4 I=; Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=malisa.vucinic@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="6.10,186,1719871200"; d="scan'208,217";a="180624538" Received: from wifi-pro-83-108.paris.inria.fr (HELO smtpclient.apple) ([128.93.83.108]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Aug 2024 18:18:57 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: <0CDB2FE3-A913-4FC3-86B1-7876137E950B@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_BBDE418C-26A6-457C-B2EB-08E2AC74E3FF" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\)) Date: Thu, 29 Aug 2024 18:18:47 +0200 In-Reply-To: To: Esko Dijk References: X-Mailer: Apple Mail (2.3731.700.6.1.1) Message-ID-Hash: 5ZVDXTYZ36ZILQTWUVPYWJTUZ2SQXKUG X-Message-ID-Hash: 5ZVDXTYZ36ZILQTWUVPYWJTUZ2SQXKUG X-MailFrom: malisa.vucinic@inria.fr X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ace.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "ace@ietf.org" , =?utf-8?Q?G=C3=B6ran_Selander?= X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BAce=5D_Re=3A_Review_of_draft-ietf-ace-coap-est-oscore-05?= List-Id: "Authentication and Authorization for Constrained Environments (ace)" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_BBDE418C-26A6-457C-B2EB-08E2AC74E3FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Esko, Many thanks for sending this review! I am responding with some delay due = to the vacation period. I have converted your points below into github = issues and plan on handling and discussing them on github. I tagged you = so you should have received a bunch of notifications related to it. For = reference, here is a list of issues I created: https://github.com/ace-wg/est-oscore/issues/55 https://github.com/ace-wg/est-oscore/issues/56 https://github.com/ace-wg/est-oscore/issues/57 https://github.com/ace-wg/est-oscore/issues/58 https://github.com/ace-wg/est-oscore/issues/59 https://github.com/ace-wg/est-oscore/issues/60 https://github.com/ace-wg/est-oscore/issues/61 https://github.com/ace-wg/est-oscore/issues/62 https://github.com/ace-wg/est-oscore/issues/63 https://github.com/ace-wg/est-oscore/issues/64 https://github.com/ace-wg/est-oscore/issues/65 https://github.com/ace-wg/est-oscore/issues/66 https://github.com/ace-wg/est-oscore/issues/67 https://github.com/ace-wg/est-oscore/issues/68 https://github.com/ace-wg/est-oscore/issues/69 https://github.com/ace-wg/est-oscore/issues/70 https://github.com/ace-wg/est-oscore/issues/71 https://github.com/ace-wg/est-oscore/issues/72 https://github.com/ace-wg/est-oscore/issues/73 https://github.com/ace-wg/est-oscore/issues/74 https://github.com/ace-wg/est-oscore/issues/75 https://github.com/ace-wg/est-oscore/issues/76 https://github.com/ace-wg/est-oscore/issues/77 https://github.com/ace-wg/est-oscore/issues/78 https://github.com/ace-wg/est-oscore/issues/79 https://github.com/ace-wg/est-oscore/issues/80 Again, many thanks for doing this review! Mali=C5=A1a > On Aug 10, 2024, at 16:21, Esko Dijk = wrote: >=20 > Hi all, authors (cc), > =20 > Here=E2=80=99s a first review of the document = draft-ietf-ace-coap-est-oscore-05. This is mostly based on my first read = of the document; I didn=E2=80=99t look yet into all the details or = possible implementations of this technology. > Overall it looks like a useful addition to the constrained-networks = toolbox, where IoT devices already using OSCORE / EDHOC can benefit from = EST without needing additional security protocols/code. > =20 > Detailed comments per section below: > =20 > General (entire document) > =20 > - There could be one line of whitespace between table content and = table caption. This would be visually more clear. > - Spelling =E2=80=9Cenrolment=E2=80=9D vs =E2=80=9Cenrollment=E2=80=9D = - unify > =20 > Abstract > =20 > >> =E2=80=A6 is a certificate provisioning protocol over HTTPS. > It=E2=80=99s currently defined over HTTPS or CoAPS, not just HTTPS. = (RFC 7030 / 9148 respectively.) Best to mention both these transports = already here in the 1stsentence. > =20 > >> =E2=80=A6 also leverages the certificate structures defined in = [I-D.ietf-cose-cbor-encoded-cert]. > Sentence could be clarified to say that the CBOR encoded certs are = optionally used! Now it=E2=80=99s not clear at high level if CBOR = replaces X509 certificates always or that it=E2=80=99s optionally used. > =20 > 1. Introduction > =20 > Paragraph 3 explains that EST can be carried over HTTP protected with = OSCORE. This part could still be clarified: I initially thought the = intention was to enable HTTP transport without needing CoAP at all i.e. = in none of the communication legs. This interpretation then conflicts = with many following parts of the document that only mention CoAP and not = HTTP used by the client. For example, paragraph 5 mentions =E2=80=9C=E2=80= =A6 context, the CoAP exchange carrying =E2=80=A6 =E2=80=9C which then = triggers the question whether this is really a CoAP exchange, or whether = it can also be a HTTP exchange? > Maybe the intention was to support only CoAP for the client side; = which might be carried as HTTP for a particular network segment? (e.g. = from proxy to EST server). > Not sure how to resolve this; it depends on the intention of how HTTP = is supposed to be used and this is not yet fully clear to me. > =20 > >> =E2=80=A6 translating between between=20 > (remove double word) > =20 > >> * Compact representations f X.509 =E2=80=A6 > Compact CBOR representations of X.509 =E2=80=A6 > =20 > Operational Differences with EST-coaps > =20 > >> =E2=80=A6 the following respects: > the following aspects: > =20 > There is some repetition in the text. E.g. paragraph 1 overlaps with = bullet 1 content. And bullet 2 subbullet 3 overlaps with bullet 2 of = Section 1. I think that Section 1 and 1.1 could be easily joined = together and compressed. > (Or maybe I misunderstood the purpose of 1.1.) > =20 > Bullet 2, subbullet 1: =E2=80=9Cis complemented with=E2=80=9D -> = unclear exactly what =E2=80=9Ccomplemented=E2=80=9D means here. Is using = raw public keys an optional thing the client can invoke? Or does it need = to do both? > Similar questions for subbullet 2 and 3. > =20 > 2. Terminology > =20 > Section may expand acronym =E2=80=9CDH=E2=80=9D when used first time. > =20 > >> Apart from enrolling signature keys, =E2=80=A6 > This is unclear to me! The purpose of EST was explained to be = =E2=80=9Ccertificate provisioning=E2=80=9D or =E2=80=9Ccertificate = enrollment=E2=80=9D (assumed to be synonyms). Now it=E2=80=99s signature = key enrollment ? Doesn=E2=80=99t sound familiar and may need some more = details. Maybe it points to the fact that an identity (consisting of a = device=E2=80=99s public key and associated private key) gets enrolled = into a domain, at the same time that a certificate is provisioned into = the device? Could we say =E2=80=9Capart from enrollment based on = signature keys, =E2=80=A6 =E2=80=9C ? > =20 > >> recipients public DH key > recipient=E2=80=99s public DH key > =20 > >> Therefore this document =E2=80=A6 procedures defined. > Last sentence is complex and could be improved (grammar-wise). What = does =E2=80=9Cits=E2=80=9D refer to? =E2=80=9Cdefined=E2=80=9D refers to = something defined where? > =20 > 3. Authentication > =20 > >> During initial enrollment =E2=80=A6 payloads. > Is EDHOC only run during the initial / first enrollment =E2=80=93 and = then never again? Or does it in some cases need to be =E2=80=9Crefreshed=E2= =80=9D before doing a re-enrollment? > =20 > >> =E2=80=A6 conveying EST payloads. > =E2=80=9Ccarrying EST payloads=E2=80=9D is maybe more clear? > =20 > >> =E2=80=A6 to the CA for decision about =E2=80=A6 > =E2=80=9Cto the CA to support its decision about=E2=80=9D ? Or =E2=80=9C= to the CA for the decisions about=E2=80=9D ? > =20 > 3.1 EDHOC > >> certificates/raw public keys > Maybe better to clarify =E2=80=9Ccertificates or raw public keys=E2=80=9D= ? > =20 > >> =E2=80=A6 URI to the credential =E2=80=A6 > =E2=80=9CURI of the credential=E2=80=9D is perhaps more accurate? = Since the I stands for Identifier. It identifies the credential. > =20 > 3.2 Certificate-based Authentication > =20 > >> =E2=80=A6 client SHOULD populate its Explicit TA database =E2=80=A6 > There=E2=80=99s a requirement on the client here, but what should the = client do concretely? Are there some details needed on how to do this? = And with whom are the =E2=80=9Csubsequent authentications=E2=80=9D made, = only with EST servers or with any servers/peers in the domain? (If it = concerns EST server then it=E2=80=99s in scope of this spec.) > And what are the exception cases of the SHOULD ? It=E2=80=99s also = not so clear here how this requirement differs from RFC 9148 = requirements on Explicit and Implicit TA database. > =20 > >> =E2=80=A6 EST client certificate SHOULD conform to [RFC7925] =E2=80=A6= > That holds also for the server certificate, I think? If the server=E2=80= =99s cert is not lightweight, then just optimizing the client=E2=80=99s = cert helps only for 50%. RFC 7925 defines the profile for both client = and server. > =20 > >> =E2=80=A6 EST server certificate MAY be a (natively signed) CBOR = certificate =E2=80=A6 > This MAY would imply that all clients MUST support the CBOR = certificate =E2=80=93 was that intended? It would be better if the = client could select either option and the EST server would support both = and adapt to the client=E2=80=99s choice. > If that=E2=80=99s not possible then having a defined =E2=80=9Cprofile=E2= =80=9D can be useful =E2=80=93 e.g. a system implementation would need = to pick either the X509 cert profile or the CBOR cert profile and then = all devices in the system including the EST server support that choice = according to the profile. > =20 > 3.4 Optimizations > =20 > There should be some introductory text before the bullets. E.g. = explain there will follow some optional behaviours that a client can be = configured / programmed to use, in order to reduce one of message size / = round-trips / =E2=80=A6 . > Perhaps split into optimizations that a client can decide to use, and = optimizations that a server can decide to use? > =20 > Difference between bullet 3 and 4 is not very clear yet. Bullet 3 = mentions =E2=80=9Cenrolled client certificate=E2=80=9D =E2=80=93 is this = the domain certificate that=E2=80=99s created due to the enrollment = process? I suppose the client can=E2=80=99t use this optimization when = it=E2=80=99s not yet enrolled? > In bullet 4=20 > =E2=80=93 is the advantage here that the client never has to actually = access/download its own domain certificate? E.g. it keeps using a = reference to it, instead of the actual certificate? Does this mean = that all future/potential servers and peers will have to support this = =E2=80=9Ccert reference=E2=80=9D instead of the real cert? > - when would the EST server return the reference rather than the full = certificate? It seems the client is also obliged to support the cert = references then, adding to its codebase. > =20 > All of the =E2=80=9Ccertificate reference=E2=80=9D optimizations seem = to complicate matters in terms of interoperability. If device 1 MAY send = a reference, this forces device 2 to support (MUST) a method to get the = certificate using this reference to e.g. check it. (Is this correct?) > There should also be more detail about what from RFC 9360 is used for = this =E2=80=93 e.g. specify the x5u header as the default option for = this? (Now it=E2=80=99s just mentioned as example.) > =20 > 4. Protocol Design and Layering > =20 > >> Block-Wise > -> =E2=80=9CBlock-Wise transfer=E2=80=9D > =20 > Figure 1 caption: best to mention the term =E2=80=9Cstack diagram=E2=80=9D= in the caption. > =20 > 4.1 Discovery and URI > =20 > The server uses the =E2=80=9Cosc=E2=80=9D attributes to signal OSCORE = support. This is fine, however, the re-use of the existing resource type = name =E2=80=9Cace.est.sen=E2=80=9D also means it would support the = original EST-coaps protocol. > This gives a clash in resource definitions when the EST server wants = to provide EST-with-OSCORE-over-DTLS which is stated as one of the = options of this protocol. > In this case, a regular EST-coaps client will see a resource of type = =E2=80=9Cace.est.sen=E2=80=9D which it recognizes and which is hosted at = a URL that has a coaps:// protocol, which it recognizes, and so it would = assume this EST server would support EST-coaps. (It would ignore the = =E2=80=9Cosc=E2=80=9D attribute, not knowing it.) So this gives a = conflict in resource type name use, because the EST server maybe = doesn=E2=80=99t intend to support EST-coaps classic and only intends to = support EST-OSCORE. But now it=E2=80=99s impossible to express this = using link format. (Or do we intend to make EST-coaps support mandatory = for such case?) > =20 > 4.2.1 /crts > =20 > >> =E2=80=A6 which is subsequently installed in the Explicit TA. > =E2=80=9CTA=E2=80=9D here should be =E2=80=9CTA database=E2=80=9D. And = it could be clarified that the =E2=80=9Cinstalled in=E2=80=9D part only = happens of course if the server has been properly authenticated. I think = the original EST protocol in Section 4.1.1 allows a client to request = /cacerts without having yet authenticated the EST server. > =20 > Second paragraph: =E2=80=9Ccould be just the CA public key =E2=80=A6 = or =E2=80=A6 without the signature=E2=80=9D -> in this case the = Content-Format would be a different one, I presume =E2=80=93 a format = that can encode this reduced information instead of the regular = Content-formats defined by EST-coaps. Now it reads as if the server can = just leave away information but that=E2=80=99s not correct I think. The = client might request a specific Content-Format for the /crts resource, = one with all bells and whistles included, and the server needs to oblige = to this request. > =20 > 4.3.2 CBOR-encoded Objects > =20 > >> In the case of CBOR-encoded request =E2=80=A6 also CBOR encoded. > There=E2=80=99s also the client=E2=80=99s Accept option that comes = into play. There could be a future content-format that the client would = specify in the Accept option; in which case the response could be = another format than 62. > But agree that when no Accept option is specified, then 62 is returned = with CBOR-encoded contents. > =20 > 4.4 Message Bindings > =20 > >> endpoints support delayed responses > Text here could refer to Section 4.7 of RFC 9148.=20 > =20 > Final bullet: =E2=80=9CEST URLs based on https:// are=E2=80=9D -> this = seems incorrect, it would probably need to be =E2=80=9CEST-coaps URLs = based on coaps:// are translated to coap:// , but with =E2=80=A6 =E2=80=9C= > =20 > 4.6 Message fragmentation > (Use caps =E2=80=98F=E2=80=99 here) > =20 > >> =E2=80=A6 to prevent IP fragmentation =E2=80=A6 > to prevent 6LoWPAN fragmentation > =20 > Last paragraphs Block1/Block2 requirements: these are repeats of = section 4.4 requirements. Should try to avoid duplicate normative = requirements. > If needed, refer back to the requirements made elsewhere. > =20 > 4.8 Enrollment of Static DH Keys > =20 > >> =E2=80=A6 how the EST client enrolls a static DH key > See earlier comment about enrolling keys vs enrolling devices or = certificates. Terminology is a bit unclear to me. > =20 > Paragraph 2: there are 2 SHOULD requirements here =E2=80=93 it seems = it=E2=80=99s in fact only 1 requirement? Reduce to one SHOULD, if = possible. Also if the SHOULD is not followed, what are the alternatives? > =20 > >> In some cases, it may be beneficial =E2=80=A6 > Which cases? Maybe this is further detailed in the SP- references = given later on? > =20 > 5. HTTP-CoAP Proxy > =20 > >> =E2=80=A6 use of TLS and DTLS is optional =E2=80=A6 > Use of TLS or DTLS is optional > =20 > It=E2=80=99s optional for the client to use: it determines which = protocol is initiated. Is it mandatory for the Proxy to support all of = the options NoSec, OSCORE, TLS and DTLS for the first leg from the = client ? Or do we assume =E2=80=9Cprofiles=E2=80=9D where the deployer = of the Proxy knows what all the EST clients will support/use? > In case of CoAP-over-TLS, what scheme would be used? (would we have to = mention in that case that discovery would yield e.g. =E2=80=9Ccoap+tls=E2=80= =9D scheme in the links? That seems to add more complexity / options to = this specification. ) > =20 > 6.1 Server-generated Private Keys > =20 > >> =E2=80=A6 it has been shown that many available hardware modules = =E2=80=A6 > Is there some reference for this claim? Maybe not needed in this doc = if it=E2=80=99s generally known. But I didn=E2=80=99t know it. > =20 > 6.2 Considerations on Channel Binding > =20 > >> =E2=80=A6 PKCS#10 requests OPTIONAL > Is this OPTIONAL for the client? Does the server need to support this = channel binding always? > =20 > 7.1 EDHOC Exporter Label Registry > It=E2=80=99s not clear to me what this is and how/when TBD4 is used. = It=E2=80=99s not mentioned anywhere else in the draft. > =20 > 8.2 Informative References > =20 > It looks like some references need to be normative. There=E2=80=99s = some IETF guidance for this case that any optionally implemented = function requires the spec for that function to be Normatively = referenced. Because the one implementing this option needs to follow = that specification and normatively implement it. =E2=80=9CInformative=E2=80= =9D is purely background info that an implementer would not have to = implement even with all options enabled. See = e.g.https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normati= ve-and-informative-references-20060419/ > =20 > [I-D.ietf-core-oscore-edhoc] > =20 > [I-D.ietf-cose-cbor-encoded-cert]=20 > -> normative, because using these CBOR encoded certs is an option in = the implementation. > =20 > [RFC8446] > -> normative, because it looks like the client could use TLS, and for = sure the EST server could use TLS. > =20 > [RFC7627] > -> Normative, in case using TLS is OPTIONAL for an implementation. = (E.g. so far in the draft it looks like an EST client could use TLS, or = the leg between Proxy and EST server could use TLS.) > =20 > [RFC9147] > -> normative since DTLS can be optionally used as extra transport = security? > =20 > [RFC9360] > -> normative since it looks like a client or server can optionally use = a certificate by reference. Assuming we want x5u to be the default = option for this. > =20 > Some references are not used it seems: > =20 > [RFC2985] -> not used? > [RFC2986] -> not used? > [RFC5280] -> not used? > [RFC5869] -> not used? > [RFC5914] -> not used? > [RFC7627] -> not used? > =20 > =20 > Best regards, > Esko > =20 > IoTconsultancy.nl | Email/Teams: = esko.dijk@iotconsultancy.nl --Apple-Mail=_BBDE418C-26A6-457C-B2EB-08E2AC74E3FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Esko,

Many thanks for sending this review! I am = responding with some delay due to the vacation period. I have converted = your points below into github issues and plan on handling and discussing = them on github. I tagged you so you should have received a bunch of = notifications related to it. For reference, here is a list of issues I = created:


Again, many = thanks for doing this = review!

Mali=C5=A1a


On Aug 10, 2024, at 16:21, Esko = Dijk <esko.dijk@iotconsultancy.nl> wrote:

Hi all, authors = (cc),
 
Here=E2=80=99s a first review of the document = draft-ietf-ace-coap-est-oscore-05. This is mostly based on my first read = of the document; I didn=E2=80=99t look yet into all the details or = possible implementations of this technology.
Overall it looks like a useful addition to the = constrained-networks toolbox, where IoT devices already using OSCORE / = EDHOC can benefit from EST without needing additional security = protocols/code.
 
Detailed comments per section below:
 
General (entire = document)
 
- There could be one line of whitespace between table = content and table caption. This would be visually more = clear.
- Spelling =E2=80=9Cenrolment=E2=80=9D = vs =E2=80=9Cenrollment=E2=80=9D - unify
 
Abstract
 
>> =E2=80=A6 is = a certificate provisioning protocol over HTTPS.
It=E2=80=99s currently defined over HTTPS or CoAPS, not = just HTTPS. (RFC 7030 / 9148 respectively.)  Best to mention both = these transports already here in the = 1stsentence.
 
>> =E2=80=A6 = also leverages the certificate structures defined in = [I-D.ietf-cose-cbor-encoded-cert].
Sentence could be = clarified to say that the CBOR encoded certs are optionally used! Now = it=E2=80=99s not clear at high level if CBOR replaces X509 certificates = always or that it=E2=80=99s optionally used.
 
1. = Introduction
 
Paragraph 3 explains that EST can be carried over HTTP = protected with OSCORE. This part could still be clarified: I initially = thought the intention was to enable HTTP transport without needing CoAP = at all i.e. in none of the communication legs.  This interpretation = then conflicts with many following parts of the document that only = mention CoAP and not HTTP used by the client. For example, paragraph 5 = mentions =E2=80=9C=E2=80=A6 context, the CoAP exchange carrying =E2=80=A6 = =E2=80=9C which  then triggers the question whether this is really = a CoAP exchange, or whether it can also be a HTTP = exchange?
Maybe the intention was to support only = CoAP for the client side; which might be carried as HTTP for a = particular network segment? (e.g. from proxy to EST = server).
Not sure how to resolve this; it = depends on the intention of how HTTP is supposed to be used and this is = not yet fully clear to me.
 
>> =E2=80=A6 = translating between between 
(remove double word)
 
>> * Compact = representations f X.509 =E2=80=A6
Compact CBOR = representations of X.509 =E2=80=A6
 
    1. Operational = Differences with EST-coaps
 
>> =E2=80=A6 the = following respects:
the following = aspects:
 
There is some repetition in the text. E.g. paragraph 1 = overlaps with bullet 1 content. And bullet 2 subbullet 3 overlaps with = bullet 2 of Section 1. I think that Section 1 and 1.1 could be easily = joined together and compressed.
(Or maybe I = misunderstood the purpose of 1.1.)
 
Bullet 2, subbullet 1: = =E2=80=9Cis complemented with=E2=80=9D -> unclear exactly what = =E2=80=9Ccomplemented=E2=80=9D means here. Is using raw public keys an = optional thing the client can invoke? Or does it need to do = both?
Similar questions for subbullet 2 and = 3.
 
2. Terminology
 
Section may expand = acronym =E2=80=9CDH=E2=80=9D when used first time.
 
>> Apart from = enrolling signature keys, =E2=80=A6
This is unclear = to me! The purpose of EST was explained to be =E2=80=9Ccertificate = provisioning=E2=80=9D or =E2=80=9Ccertificate enrollment=E2=80=9D = (assumed to be synonyms). Now it=E2=80=99s signature key enrollment ? = Doesn=E2=80=99t sound familiar and may need some more details. Maybe it = points to the fact that an identity (consisting of a device=E2=80=99s = public key and associated private key) gets enrolled into a domain, at = the same time that a certificate is provisioned into the device? Could = we say =E2=80=9Capart from enrollment based on signature keys, =E2=80=A6 = =E2=80=9C ?
 
>> recipients public DH key
recipient=E2=80=99s public DH key
 
>> Therefore = this document =E2=80=A6 procedures defined.
Last sentence is complex and could be improved = (grammar-wise). What does =E2=80=9Cits=E2=80=9D refer to? =E2=80=9Cdefined= =E2=80=9D refers to something defined where?
 
3. = Authentication
 
>> During initial enrollment =E2=80=A6 = payloads.
Is EDHOC only run during the initial / = first enrollment =E2=80=93 and then never again? Or does it in some = cases need to be =E2=80=9Crefreshed=E2=80=9D before doing a = re-enrollment?
 
>> =E2=80=A6 conveying EST = payloads.
=E2=80=9Ccarrying EST payloads=E2=80=9D&n= bsp; is maybe more clear?
 
>> =E2=80=A6 to = the CA for decision about =E2=80=A6
=E2=80=9Cto the = CA to support its decision about=E2=80=9D ?  Or =E2=80=9Cto the CA = for the decisions about=E2=80=9D ?
 
3.1 = EDHOC
>> certificates/raw public = keys
Maybe better to clarify =E2=80=9Ccertific= ates or raw public keys=E2=80=9D ?
 
>> =E2=80=A6 URI = to the credential =E2=80=A6
=E2=80=9CURI of the = credential=E2=80=9D is perhaps more accurate? Since the I stands for = Identifier. It identifies the credential.
 
3.2 Certificate-based = Authentication
 
>> =E2=80=A6 client SHOULD populate its Explicit TA = database =E2=80=A6
There=E2=80=99s  a = requirement on the client here, but what should the client do = concretely? Are there some details needed on how to do this? And with = whom are the =E2=80=9Csubsequent authentications=E2=80=9D made, only = with EST servers or with any servers/peers in the domain? (If it = concerns EST server then it=E2=80=99s in scope of this = spec.)
And what are the exception cases of the = SHOULD ?  It=E2=80=99s also not so clear here how this requirement = differs from RFC 9148 requirements on Explicit and Implicit TA = database.
 
>> =E2=80=A6 EST client certificate SHOULD conform to = [RFC7925] =E2=80=A6
That holds also for = the server certificate, I think? If the server=E2=80=99s cert is not = lightweight, then just optimizing the client=E2=80=99s cert helps only = for 50%. RFC 7925 defines the profile for both client and = server.
 
>> =E2=80=A6 EST server certificate MAY be a = (natively signed) CBOR certificate =E2=80=A6
This MAY would imply that all clients MUST support the CBOR = certificate =E2=80=93 was that intended?  It would be better if the = client could select either option and the EST server would support both = and adapt to the client=E2=80=99s choice.
If that=E2=80=99s not possible then having a defined = =E2=80=9Cprofile=E2=80=9D can be useful =E2=80=93 e.g. a system = implementation would need to pick either the X509 cert profile or the = CBOR cert profile and then all devices in the system including the EST = server support that choice according to the = profile.
 
3.4 Optimizations
 
There should be some = introductory text before the bullets. E.g. explain there will follow = some optional behaviours that a client can be configured / programmed to = use, in order to reduce one of message size / round-trips / =E2=80=A6 = .
Perhaps split into optimizations that a = client can decide to use, and optimizations that a server can decide to = use?
 
Difference between bullet 3 and 4 is not very clear yet. = Bullet 3 mentions =E2=80=9Cenrolled client certificate=E2=80=9D =E2=80=93 = is this the domain certificate that=E2=80=99s created due to the = enrollment process? I suppose the client can=E2=80=99t use this = optimization when it=E2=80=99s not yet enrolled?
In bullet 4 
=E2=80=93 is the advantage here that the client never has = to actually access/download its own domain certificate? E.g. it keeps = using a reference to it, instead of the actual certificate?   = Does this mean that all future/potential servers and peers will have to = support this =E2=80=9Ccert reference=E2=80=9D instead of the real = cert?
- when would the EST server return the = reference rather than the full certificate?  It seems the client is = also obliged to support the cert references then, adding to its = codebase.
 
All of the =E2=80=9Ccertificate reference=E2=80=9D = optimizations seem to complicate matters in terms of interoperability. = If device 1 MAY send a reference, this forces device 2 to support (MUST) = a method to get the certificate using this reference to e.g. check it. = (Is this correct?)
There should also be more detail = about what from RFC 9360 is used for this =E2=80=93 e.g. specify the x5u = header as the default option for this? (Now it=E2=80=99s just mentioned = as example.)
 
4. Protocol Design and Layering
 
>> = Block-Wise
-> =E2=80=9CBlock-Wise = transfer=E2=80=9D
 
Figure 1 caption: best to mention the term =E2=80=9Cstack = diagram=E2=80=9D in the caption.
 
4.1 Discovery and = URI
 
The server uses the =E2=80=9Cosc=E2=80=9D attributes to = signal OSCORE support. This is fine, however, the re-use of the existing = resource type name =E2=80=9Cace.est.sen=E2=80=9D also means it would = support the original EST-coaps protocol.
This gives a clash in resource definitions when the EST = server wants to provide EST-with-OSCORE-over-DTLS which is stated as one = of the options of this protocol.
In this case, a = regular EST-coaps client will see a resource of type =E2=80=9Cace.est.sen=E2= =80=9D which it recognizes and which is hosted at a URL that has a = coaps:// protocol, which it recognizes, and so it would assume this EST = server would support EST-coaps. (It would ignore the =E2=80=9Cosc=E2=80=9D= attribute, not knowing it.) So this gives a conflict in resource type = name use, because the EST server maybe doesn=E2=80=99t intend to support = EST-coaps classic and only intends to support EST-OSCORE. But now it=E2=80= =99s impossible to express this using link format.  (Or do we = intend to make EST-coaps support mandatory for such = case?)
 
4.2.1 /crts
 
>> =E2=80=A6 = which is subsequently installed in the Explicit TA.
=E2=80=9CTA=E2=80=9D here should be =E2=80=9CTA = database=E2=80=9D. And it could be clarified that the =E2=80=9Cinstalled = in=E2=80=9D part only happens of course if the server has been properly = authenticated. I think the original EST protocol in Section 4.1.1 allows = a client to request /cacerts without having yet authenticated the EST = server.
 
Second paragraph: =E2=80=9Ccould be just the CA public key = =E2=80=A6 or =E2=80=A6 without the signature=E2=80=9D -> in this case = the Content-Format would be a different one, I presume =E2=80=93 a = format that can encode this reduced information instead of the regular = Content-formats defined by EST-coaps. Now it reads as if the server can = just leave away information but that=E2=80=99s not correct I = think.  The client might request a specific Content-Format for the = /crts resource, one with all bells and whistles included, and the server = needs to oblige to this request.
 
4.3.2 CBOR-encoded = Objects
 
>> In the case of CBOR-encoded request =E2=80=A6 also = CBOR encoded.
There=E2=80=99s also the = client=E2=80=99s Accept option that comes into play. There could be a = future content-format that the client would specify in the Accept = option; in which case the response could be another format than = 62.
But agree that when no Accept option is = specified, then 62 is returned with CBOR-encoded = contents.
 
4.4 Message Bindings
 
>> endpoints = support delayed responses
Text here could refer = to Section 4.7 of RFC 9148. 
 
Final bullet: =E2=80=9CE= ST URLs based on https:// are=E2=80=9D -> this seems incorrect, it = would probably need to be =E2=80=9CEST-coaps URLs based on coaps:// are = translated to coap:// , but with =E2=80=A6 =E2=80=9C
 
4.6 Message = fragmentation
(Use caps =E2=80=98F=E2=80=99 = here)
 
>> =E2=80=A6 to prevent IP fragmentation = =E2=80=A6
to prevent 6LoWPAN = fragmentation
 
Last paragraphs Block1/Block2 requirements: these are = repeats of section 4.4 requirements. Should try to avoid duplicate = normative requirements.
If needed, refer back = to the requirements made elsewhere.
 
4.8 Enrollment of = Static DH Keys
 
>> =E2=80=A6 how the EST client enrolls a static DH = key
See earlier comment about enrolling = keys vs enrolling devices or certificates. Terminology is a bit unclear = to me.
 
Paragraph 2: there are 2 SHOULD requirements here =E2=80=93 = it seems it=E2=80=99s in fact only 1 requirement? Reduce to one SHOULD, = if possible. Also if the SHOULD is not followed, what are the = alternatives?
 
>> In some cases, it may be beneficial = =E2=80=A6
Which cases? Maybe this is further = detailed in the SP- references given later on?
 
5. HTTP-CoAP = Proxy
 
>> =E2=80=A6 use of TLS and DTLS is optional = =E2=80=A6
Use of TLS or DTLS is = optional
 
It=E2=80=99s optional for the client to use: it determines = which protocol is initiated.  Is it mandatory for the Proxy to = support all of the options NoSec, OSCORE, TLS and DTLS  for the = first leg from the client ? Or do we assume =E2=80=9Cprofiles=E2=80=9D = where the deployer of the Proxy knows what all the EST clients will = support/use?
In case of CoAP-over-TLS, what scheme = would be used? (would we have to mention in that case that discovery = would yield e.g. =E2=80=9Ccoap+tls=E2=80=9D scheme in the links? That = seems to add more complexity / options to this specification. = )
 
6.1 Server-generated Private Keys
 
>> =E2=80=A6 it = has been shown that many available hardware modules = =E2=80=A6
Is there some reference for this claim? = Maybe not needed in this doc if it=E2=80=99s generally known.  But = I didn=E2=80=99t know it.
 
6.2 Considerations on = Channel Binding
 
>> =E2=80=A6 PKCS#10 requests = OPTIONAL
Is this OPTIONAL for the client? Does = the server need to support this channel binding = always?
 
7.1 EDHOC Exporter Label Registry
It=E2=80=99s not clear to me what this is and how/when TBD4 = is used. It=E2=80=99s not mentioned anywhere else in the = draft.
 
8.2  Informative References
 
It looks like some = references need to be normative. There=E2=80=99s some IETF guidance for = this case that any optionally implemented function requires the spec for = that function to be Normatively referenced. Because the one implementing = this option needs to follow that specification and normatively implement = it.  =E2=80=9CInformative=E2=80=9D is purely background info that = an implementer would not have to implement even with all options = enabled.  See e.g.https://datatracker.ietf.org/doc/statement-iesg-iesg-statement= -normative-and-informative-references-20060419/
 
[I-D.ietf-core-oscore-edhoc]
 
[I-D.ietf-cose-cbor-encoded-cert] 
-> normative, because using these CBOR encoded certs is = an option in the implementation.
 
[RFC8446]
-> normative, = because it looks like the client could use TLS, and for sure the EST = server could use TLS.
 
[RFC7627]
-> Normative, in = case using TLS is OPTIONAL for an implementation. (E.g. so far in the = draft it looks like an EST client could use TLS, or the leg between = Proxy and EST server could use TLS.)
 
[RFC9147]
-> normative since = DTLS can be optionally used as extra transport = security?
 
[RFC9360]
-> normative since = it looks like a client or server can optionally use a certificate by = reference. Assuming we want x5u to be the default option for = this.
 
Some references are not used it seems:
 
[RFC2985] -> not = used?
[RFC2986] -> not = used?
[RFC5280] -> not = used?
[RFC5869] -> not = used?
[RFC5914] -> not = used?
[RFC7627] -> not = used?
 
 
Best = regards,
Esko
 

= --Apple-Mail=_BBDE418C-26A6-457C-B2EB-08E2AC74E3FF--