[Ace] AD review of draft-ietf-ace-coap-est-12

[Benjamin Kaduk <[e-mail]>]

Hi all,

A good number of comments here, though many are just nits.  We may need
some more in-depth discussion about only using certificates for client
authentication (immediately below) and how we discuss server-keygen.

Thanks,

Ben

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Section 2

   This document also profiles the use of EST to only support
   certificate-based client authentication.  HTTP Basic or Digest
   authentication (as described in Section 3.2.3 of [RFC7030]) are not
   supported.

Is the intent just to exclude HTTP-layer authentication, or to
specifically prefer client certificate authentication?  7030 does allow
for non-certificate TLS-layer authentication (e.g., TLS-SRP), which
would be compatible with DTLS just fine.  There's also recurrent talk of
getting modern PAKE(s) integrated with TLS, which might also be an
option in the constrained space.
[There are subsequent parts of the document that continue to assume
only-certificates, so I'm mostly assuming that the intent is
specifically to prefer client certificates, and have not made specific
notes at those other places in the document.]

Section 4

   As per sections 3.3 and 4.4 of [RFC7925], the mandatory cipher suite

nit: I do see RFC 7925 in the subject heading, but the lead-in here is
still a bit jarring.  Without some statement in this document to that
effect, RFC 7925 is not binding on the protocol specified in this
document, so I think it's better to say something like "In accordance
with", or even to flat out state that "this document conforms to the
DTLS 1.2 profile specified in RFC 7925".

   DTLS 1.2 implementations must use the Supported Elliptic Curves and
   Supported Point Formats Extensions in [RFC8422].  Uncompressed point
   format must also be supported.  DTLS 1.3 [I-D.ietf-tls-dtls13]
   implementations differ from DTLS 1.2 because they do not support
   point format negotiation in favor of a single point format for each
   curve.  Thus, support for DTLS 1.3 does not mandate point format
   extensions and negotiation.

DTLS 1.3 uses the "supported_groups" extension in contrast to Supported
Elliptic Curves for 1.2; we should mention that disparity as well.

   o  a previously issued client certificate (e.g., an existing
      certificate issued by the EST CA); this could be a common case for
      simple re-enrollment of clients.

Is "re-enrollment" intended to cover renewal operations?

   o  a previously installed certificate (e.g., manufacturer IDevID
      [ieee802.1ar] or a certificate issued by some other party); the
      server is expected to trust that certificate.  IDevID's are

"trust" can cover a lot of things, many of which we don't really need
here; would "expected to be able to validate" suffice?

   As described in Section 2.1 of [RFC5272] proof-of-identity refers to
   a value that can be used to prove that the private key corresponding
   to the public key is in the possession of and can be used by an end-
   entity or client.  Additionally, channel-binding information can link

nit: "the certified public key", I think, since the certificate is what
binds the identity to the public key.
Also, this sentence is a bit awkward, though I don't have any concrete
rewording suggestions at present.

   When proof-of-possession is desired, a set of actions are required
   regarding the use of tls-unique, described in Section 3.5 in
   [RFC7030].  The tls-unique information consists of the contents of

I see the note in the shepherd writeup about converting EST to use TLS
exporters rather than tls-unique in a separate update document.  Where
is that work happening?  The discussion in Section 10.1 is helpful (and
we could do well to reference it from here) but does not inspire great
confidence in the reader that such work will come to fruition.
I think we also need to at least mandate extended-master-secret to be
used on the underlying DTLS connection.  (That
is, assuming that we don't want to lock down to specific,
non-vulnerable, ciphersuites -- RFC 7925 only has
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as MTI, not MTU.)

   Given that after a successful enrollment, it is more likely that a
   new EST transaction will take place after a significant amount of
   time, the DTLS connections SHOULD only be kept alive for EST messages
   that are relatively close to each other.  In some cases, like NAT
   rebinding, keeping the state of a connection is not possible when
   devices sleep for extended periods of time.  In such occasions,
   [I-D.ietf-tls-dtls-connection-id] negotiates a connection ID that can
   eliminate the need for new handshake and its additional cost.

Do we also want to mention DTLS 1.3 session resumption here as less
expensive than a full handshake?  It's not as cheap as "just keep using
the same connection ID", of course, but has somewhat different other
properties.

Section 5

   o  Simple enroll and re-enroll for a CA to sign public client
      identity key.

nit(?): is this "public client identity key" or "client identity public
key" or something else?

   o  Certificate Signing Request (CSR) attribute messages that inform
      the client of the fields to include in a CSR.

nit: "informs"

   o  Server-side key generation messages to provide a private client
      identity key when the client choses so.

(similar nit(?) as above)

Section 5.1

With the current text, I expect us to get several IESG questions about
"why do you have both discovery and well-known URIs?".  I think we need
to treat this more prominently in the first few paragraphs of the
section, perhaps just after we discuss the short-est strings, so we
could tie into the constrained nature of things and how some devices may
need to hardcode assumptions about the endpoint location.

   Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations and
   corresponding paths which are supported by EST.  Table 1 provides the
   mapping from the EST URI path to the shorter EST-coaps URI path.

Our table has the entries in a different order than 7030's table.
We also don't say anything about the (lack of the) fullcmc endpoint.
The serverkeygen endpoints could perhaps have some notation to indicate
that the private key is always returned, in addition to the PKCS#7 vs.
pkix-cert question that distinguishes skg and skc.

   The /skg message is the EST /serverkeygen equivalent where the client
   requests for a certificate in PKCS#7 format and a private key.  If

nit: s/requests for a/requests a/

   Clients and servers MUST support the short resource EST-coaps URIs.

Are they expected to also support the long EST URIs over CoAP?

   In the context of CoAP, the presence and location of (path to) the
   EST resources are discovered by sending a GET request to "/.well-
   known/core" including a resource type (RT) parameter with the value
   "ace.est*" [RFC6690].  The example below shows the discovery over

Is that a literal asterisk, for ace dot est star?
(1) Why?
(2) It probably merits a mention in the text to confirm it for the
reader.


It's a little unfortunate that we can only indicate ct=62 for the last
two, and there's no way to indicate what content types we expect within
that container.

   The first three lines of the discovery response above MUST be
   returned if the server supports resource discovery.  The last three

It may be worth listing out ace.est.crts, ace.est.sen, and ace.est.sren
explicitly for clarity (especially since line breaks are "only for
readability")

   lines are only included if the corresponding EST functions are
   implemented.  The Content-Formats in the response allow the client to
   request one that is supported by the server.  These are the values
   that would be sent in the client request with an Accept option.

It seems that these specific values (or a subset thereof) are mandatory;
a forward reference might be in order.

Section 5.2

Did we consider merging this table with Table 1?

Section 5.2

   While [RFC7030] permits a number of these functions to be used
   without authentication, this specification requires that the client
   MUST be authenticated for all functions.

Perhaps this divergence from 7030 should be noted more prominently,
perhaps in the section title or a dedicated "Differences from RFC 7030"
section?

Section 5.3

   EST-coaps is designed for low-resource devices and hence does not
   need to send Base64-encoded data.  Simple binary is more efficient
   (30% smaller payload) and well supported by CoAP.  Thus, the payload
   for a given Media-Type follows the ASN.1 structure of the Media-Type
   and is transported in binary format.

This last sentence is only true when scoped to this document, for which
all the content we're handling is specified using ASN.1.  I don't know
whether we want to tweak the wording to reflect that or not, though.
Also, we probably should say DER-encoded ASN.1 structure (or BER?  I'd
have to check what the requirements are) since ASN.1 is just the
abstract syntax and not the encoding rules.

   When the client makes an /skc request the certificate returned with
   the private key is a single X.509 certificate (not a PKCS#7
   container) with Content-Format identifier TBD287 (0x011F) instead of
   281.  In cases where the private key is encrypted with CMS (as
   explained in Section 5.8) the Content-Format identifier is 280
   (0x0118) instead of 284.  The key and certificate representations are
   ASN.1 encoded in binary format.  An example is shown in Appendix A.3.

I think these relationships might be more clear in tabular form; I
dind't really understand the scheme at this point in the document, and
needed to get a ways further in before it really "clicked".

Section 5.4

   o  EST-coaps servers sometimes need to provide delayed responses
      which are conveyed with an empty ACK or an ACK containing response
      code 5.03 as explained in Section 5.7.  Thus, it is RECOMMENDED

nit: the response itself (delayed or not) is not in the ACK, so maybe
"the need for which is conveyed".

Section 5.6

   layer.  In addition, invokers residing on a 6LoWPAN over IEEE
   802.15.4 [ieee802.15.4] network should attempt to size CoAP messages
   such that each DTLS record will fit within one or two IEEE 802.15.4
   frames.

Is this intended to be a normative SHOULD?  If not, it feels like we
need a reference or justification.

Section 5.7

   certificate to the client after a short delay.  If the certificate
   response is large, the server will need more than one Block2 blocks
   to transfer it.

nit: "Block2 block" singular

POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} -->
   <-- (ACK) (1:0/1/256) (2.31 Continue)

Where is this notation documented?  (Is Appendix B.1 of this document the
first place it's introduced?)  We need some kind of reference on first
usage.

   If the server is very slow (i.e. minutes) in providing the response
   (i.e. when a manual intervention is needed), he SHOULD respond with

nit: RFC style puts commas after (and before) "i.e." and "e.g.".

   the identical CSR to the server.  As long as the server responds with
   response code 5.03 (Service Unavailable) with a Max-Age Option, the
   client SHOULD keep resending the enrollment request until the server
   responds with the certificate or the client abandons for other
   reasons.

nit: the transitive verb "abandons" has no direct object

   response.  Note that the server asks for a decrease in the block size
   when acknowledging the first Block2.

nit: From the trace, it looks like the server is the first one to use
a 128-byte block size, and it does happen in an ack message, but that
ack is not acking a block2 (though it contains one).  (That ack message
also happens to contain part of the response.)

POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# 1)}-->
  <-- (ACK) (1:0/1/256) (2.31 Continue)
POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)}  -->
  <-- (ACK) (1:1/1/256) (2.31 Continue)

The first line doesn't seem to match up -- doesn't the "N1" mean
"fragment N1+1" but the descriptive text at the end say "frag# 1"?
Or is this supposed to be 1:0/1/256?

Also, it surprised me somewhat that the client has to re-send the whole
request (i.e., all fragments thereof) after the Max-Age interval when
the server says it's ready, since that feels wasteful of bandwidth, but
I assume that's just how CoAP works and not relevant for this document.

Section 5.8

   In scenarios where it is desirable that the server generates the
   private key, server-side key generation should be used.  Such

nit: suggest s/should be used/is available/ to avoid the appearance of
tautology.

   scenarios could be when it is considered more secure to generate at
   the server the long-lived random private key that identifies the
   client, or when the resources spent to generate a random private key
   at the client are considered scarce, or when the security policy
   requires that the certificate public and corresponding private keys
   are centrally generated and controlled.  Of course, that does not

I can (grudgingly) accept that people are going to do server-side key
generation, so I do not propose to remove it from the document.  The
policy case is a clear example of why the feature needs to be available,
but I'm not 100% sure that I believe that server-keygen could be "more
secure" given that the client needs to be able to produce secure random
numbers for DTLS (though I do accept that some people will believe it to
be so!).  It seems likely to only be possible in some intermediate situation
where the client-generated random numbers could be attacked but at
substantial expense, such that paying that expense for a single
handshake is "too much" for the attacker to bear, but doing it for the
key generation that would give the attacker all transactions would make
the expense worthwhile; this intermediate situation seems to also be
transitory, since attacks only get better/cheaper.
For the other case, if we were doing RSA keygen, then going from random
numbers to prime generation could be enough incremental expense that
offloading to the server would make sense, but I didn't think the
elliptic curve stuff had the same kind of issues, so I'd like to hear
more about the resource-consumption aspect as well.

   When requesting server-side key generation, the client asks for the
   server or proxy to generate the private key and the certificate which
   are transferred back to the client in the server-side key generation
   response.  In all respects, the server SHOULD treat the CSR as it
   would treat any enroll or re-enroll CSR; the only distinction here is
   that the server MUST ignore the public key values and signature in
   the CSR.  These are included in the request only to allow re-use of
   existing codebases for generating and parsing such requests.

We need to reword this; the SHOULD is in conflict with the MUST.

   certificate and a private key.  The private key Content-Format
   requested by the client is depicted in the PKCS#10 CSR request.  If

nit: I suggest s/depicted/indicated/

   (Section 5.3) .  The two representations (each consisting of two CBOR
   array items) do not have to be in a particular order since each

[side note: core-multipart-ct is looking to land on "multipart/mixed"
semantics to resolve my outstanding Discuss point; RFC 2046 is pretty
clear about the component parts "need[ing] to be in a particular order",
which this is in conflict with]

   representation is preceded by its Content-Format ID.  The private key
   can be in unprotected PKCS#8 [RFC5958] format (Content-Format 284) or
   protected inside of CMS SignedData (Content-Format 280).  The

Phrasing it like this makes it soun like the server can just
spontaneously decide that it wants to sign the key content, as opposed
to having it be dependant on the CSR's contents.  Also...

   SignedData is signed by the party that generated the private key,
   which may be the EST server or the EST CA.  The SignedData is further
   protected by placing it inside of a CMS EnvelopedData as explained in
   Section 4.4.2 of [RFC7030].  In summary, the symmetrically encrypted

... if the SignedData is not the outermost container, then we don't care
what the relevant Content-Format for it is; we only care about the
Content-Format for the EnvelopedData.

Also, did we explicitly consider and reject AuthEnvelopedData?

   key is included in the encryptedKey attribute in a KEKRecipientInfo
   structure.  In the case where the asymmetric encryption key is
   suitable for transport key operations the generated private key is
   encrypted with a symmetric key which is encrypted by the client
   defined (in the CSR) asymmetric public key and is carried in an

nit: hyphenate "client-defined"

   encryptedKey attribute in a KeyTransRecipientInfo structure.
   Finally, if the asymmetric encryption key is suitable for key
   agreement, the generated private key is encrypted with a symmetric
   key which is encrypted by the client defined (in the CSR) asymmetric

In the key-agreement case, the symmetric key-encryption key is the
result of the key-agreement operation, no?  In which case it is not
itself encrypted, but rather the server's ephemeral public value is
sent.

   public key and is carried in an recipientEncryptedKeys attribute in a
   KeyAgreeRecipientInfo.

   [RFC7030] recommends the use of additional encryption of the returned
   private key.  For the context of this specification, clients and
   servers that choose to support server-side key generation MUST
   support unprotected (PKCS#8) private keys (Content-Format 284).
   Symmetric or asymmetric encryption of the private key (CMS
   EnvelopedData, Content-Format 280) SHOULD be supported for
   deployments where end-to-end encryption needs to be provided between
   the client and a server.  Such cases could include architectures
   where an entity between the client and the CA terminates the DTLS
   connection (Registrar in Figure 4).

This carefully says nothing about recommendations for use, only for
software support.  Are we letting 7030's recommendation for use of
encryption stand?  It's probably worth being explicit, either way.

Section 6

   The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream
   and initiate EST connections over TLS upstream.  The Registrar MUST
   authenticate and OPTIONALLY authorize the clients and it MUST be

Why OPTIONAL?  (Also, nit: OPTIONALLY isn't a 2119 keyword; only OPTIONAL.)

   client.  For example, it could be configured to accept POP linking
   information that does not match the current TLS session because the
   authenticated EST client Registrar has verified this information when
   acting as an EST server.

This is close enough to a literal quote that we might think about
actually quoting and using quotation marks.
nit: s/POP/PoP/ if we don't do the literal quote.

   For some use cases, clients that leverage server-side key generation
   might prefer for the enrolled keys to be generated by the Registrar
   if the CA does not support server-side key generation.  Such
   Registrar is responsible for generating a new CSR signed by a new key
   which will be returned to the client along with the certificate from

nit: "Such a Registrar"

   the CA.  In these cases, the Registrar MUST support random number
   generation using proper entropy.

Not just support -- use!

   Additionally, a conversion from CBOR major type 2 to Base64 encoding
   MUST take place at the Registrar when server-side key generation is
   supported.  [...]

Not always?

   key, the encrypted CMS EnvelopedData blob MUST be converted to binary
   in CBOR type 2 downstream to the client.

I think we should reword this -- my first reading of "downstream to the
client" is "after the client in the processing path", which doesn't
actually help the client.  Presumably we mean at the registrar, in the
downstream direction, towards the client.

   The EST-coaps-to-HTTP Registrar MUST support resource discovery
   according to the rules in Section 5.1.  Section 5.1.

Do we need to say anything about translation of discovered URIs?

Section 7

   This section addresses transmission parameters described in sections
   4.7 and 4.8 of [RFC7252].  EST does not impose any unique values on
   the CoAP parameters in [RFC7252], but the EST parameter values need
   to be tuned to the CoAP parameter values.

I don't understand what "but the EST parameter values need to be tuned
to the CoAP parameter values" means.

   It is recommended, based on experiments, to follow the default CoAP
   configuration parameters ([RFC7252]).  However, depending on the
   implementation scenario, retransmissions and timeouts can also occur
   on other networking layers, governed by other configuration
   parameters.  A change in a server parameter MUST ensure the adjusted
   value is also available to all the endpoints with which these
   adjusted values are to be used to communicate.

I don't understand who this is a normative requirement upon.  Is it the
network operator's, to propagate configuration changes?  Or is there
supposed to be some automated protocol that makes adjusted values
available?

   o  NSTART: A parameter that controls the number of simultaneous
      outstanding interactions that a client maintains to a given
      server.  An EST-coaps client is not expected to interact with more
      than one servers at the same time, which is the default NSTART
      value defined in [RFC7252].

nit: there's a mismatch between "to a given server" and "more than one
servers at the same time".  (Also, s/one servers/one server/.)

   o  PROBING_RATE: A parameter which specifies the rate of re-sending
      non-confirmable messages.  The EST messages are defined to be sent
      as CoAP confirmable messages, hence this setting is not
      applicable.

Section 5.4 only has it as RECOMMENDED to send requests in CON messages,
so we should still say something here.

Section 9.1

I think we probably need this document as a reference for all the
allocations; as the document effectuating the registration, we are still
of interest even if most details of content encoding lie elsewhere.

Section 9.2

The grammar for these entries is a bit stilted, though the existing
registrations are not so far off.

nit: should ace.est.att include the word "get" like ace.est.crts does?

Section 10.1

   The security considerations of Section 6 of [RFC7030] are only
   partially valid for the purposes of this document.  As HTTP Basic
   Authentication is not supported, the considerations expressed for
   using passwords do not apply.

It may be worth explicitly stating that "the other portions of the
security considerations of RFC 7030 continue to apply".

   Modern security protocols require random numbers to be available
   during the protocol run, for example for nonces, ephemeral (EC)
   Diffie-Hellman key generation.  This capability to generate random

nit: the comma expects a 3+ element list but we only have two elements.
Just "and" suffices?

   Analysis SHOULD be done to establish whether server-side key
   generation increases or decreases the probability of digital identity
   theft.

In the abstract sense, this seems like a non-normative "should".  But if
we make it apply specifically to those deploying server-side key
generation then it is appropriately normative.

   It is important to note that sources contributing to the randomness
   pool used to generate random numbers on laptops or desktop PCs are
   not available on many constrained devices, such as mouse movement,
   timing of keystrokes, air turbulence on the movement of hard drive
   heads, as pointed out in [PsQs].  Other sources have to be used or

nit: need an "and" (or "or") to close the list.

   It is also RECOMMENDED that the Implicit Trust Anchor database used
   for EST server authentication is carefully managed to reduce the
   chance of a third-party CA with poor certification practices
   jeopardizing authentication.  Disabling the Implicit Trust Anchor

We may want to call out that since the implicit database is used for the
initial /crts request, that single jeporadized exchange could cause all
subsequent exchanges from that client to be compromised as well.

   database after successfully receiving the Distribution of CA
   certificates response (Section 4.1.3 of [RFC7030]) limits any risk to
   the first DTLS exchange.  Alternatively, in a case where a /sen
   request immediately follows a /crts, a client MAY choose to keep the
   connection authenticated by the Implicit TA open for efficiency
   reasons (Section 4).  A client that pipelines EST-coaps /crts request

nit: is "pipelines" the right word here, given that HTTP pipelining is a
thing and CoAP pipelining (probably?) isn't, and the former isn't what
we're doing anyway?

   with other requests in the same DTLS connection SHOULD revalidate the
   server certificate chain against the updated Explicit TA from the
   /crts response before proceeding with the subsequent requests.  If
   the server certificate chain does not authenticate against the
   database, the client SHOULD close the connection without completing
   the rest of the requests.  The updated Explicit TA MUST continue to
   be used in new DTLS connections.

I'm not going to say you shouldn't do this check, but it seems pretty
easy for an attacker that knows it's servicing a /crts request to supply
a response that includes a (potentially bogus) trust anchor that can
certify the certificate it used for the current connection.  So it's not
clear how much protection this really provides.

   As described in CMC, Section 6.7 of [RFC5272], "For keys that can be
   used as signature keys, signing the certification request with the
   private key serves as a POP on that key pair".  The inclusion of tls-
   unique in the certificate request links the proof-of-possession to
   the TLS proof-of-identity.  This implies but does not prove that only
   the authenticated client currently has access to the private key.

Do we want to further clarify that this means the PoP is weaker than it
could be?  ("no" is a fine answer, as always.)

   What's more, POP linking uses tls-unique as it is defined in
   [RFC5929].  The 3SHAKE attack [tripleshake] poses a risk by allowing

nit: "such POP linking" or "the CMC POP linking"

   a man-in-the-middle to leverage session resumption and renegotiation
   to inject himself between a client and server even when channel
   binding is in use.  The attack was possible because of certain (D)TLS
   implementation imperfections.  In the context of this specification,

I don't think we can solely blame the attacks on implementation
imperfections (though they were certainly compounding factors).  Does
this sentence really add any value to the current document?

   binding mechanism.  Such a mechanism could include an updated tls-
   unique value generation like the tls-unique-prf defined in
   [I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS
   1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]).  Such
   mechanism has not been standardized yet.  Adopting a channel binding

We probably should be explicit about "using a TLS Exporter value in
place of the tls-unique value in the CSR", just from a writing clarity
perspective.

It might be worth splitting the triple-handshake bits (including open
question) into a separate subsection so that we can make a forward
reference to it from earlier in the document.

   value generated from an exporter would break backwards compatibility.
   Thus, in this specification we still depend on the tls-unique
   mechanism defined in [RFC5929], especially since a 3SHAKE attack does
   not expose messages exchanged with EST-coaps.

I suppose that new endpoint names would be one way to work through the
backwards-compatibility break, though it's not entirely clear that we
need to say so in this document.  We probably do want to say that even
though EST-coaps looks like a new protocol that could get away with
changing the default, we want to preserve the ability for the RA to
proxy through to a "classic" EST HTTPS server, so we are in fact
constrained to use the compatible choice.

   Regarding the Certificate Signing Request (CSR), an EST-coaps server
   is expected to be able to recover from improper CSR requests.

What does "recover" mean?  Is it just "not crash" or is it expected to
somehow still be able to issue a certificate?  (If the former, that
might be implicit in an RFC 3552 threat model, though saying it
explicitly probably doesn't hurt.)

Section 10.2

   The Registrar proposed in Section 6 must be deployed with care, and
   only when the recommended connections are impossible.  When POP

Do we actually explicitly say that the direct connection is recommended
anywhere?  If not, we should.

   linking is used the Registrar terminating the TLS connection
   establishes a new one with the upstream CA.  Thus, it is impossible

I think technically it terminates DTLS and esablishes a new TLS
connection.

   for POP linking to be enforced end-to-end for the EST transaction.
   The EST server could be configured to accept POP linking information
   that does not match the current TLS session because the authenticated
   EST Registrar client has verified this information when acting as an
   EST server.

I think we need to say that the EST server "assumes" or "trusts" that
the registrar has verified this information -- it is to some extent a
leap of faith.

   The introduction of an EST-coaps-to-HTTP Registrar assumes the client
   can trust the registrar using its implicit or explicit TA database.

I'm not entirely sold on "trust" as the best word here (vs., e.g.,
validate), but don't object to it.

   It also assumes the Registrar has a trust relationship with the
   upstream EST server in order to act on behalf of the clients.  When a
   client uses the Implicit TA database for certificate validation, she
   SHOULD confirm if the server is acting as an RA by the presence of
   the id-kp-cmcRA EKU [RFC6402] in the server certificate.

Why is this only a SHOULD?

   generating the key.  In such cases, the existence of a Registrar
   requires the client to put its trust on the registrar doing the right
   thing if it is generating the private key.

This is true, though it (probably correctly, for our purposes) does not
give any indication of what "the right thing" is intended to be :)

Section 11.2

I think draft-ietf-lamps-rfc5751-bis, RFC 5958, RFC 8075, and RFC 8422
should be normative references.

If we're going to say that this spec requires conformance to RFC 7925's
DTLS profile (which we currently don't, but I suggest above that we do),
it will need to be a normative reference as well.

I don't understand why RFC 7231 is in the 'reference' column for
application/csrattrs in Table 4; its presence there would normally
suggest that it should be a normative reference. 

RFC 5929 is interesting, as it is of course a normative reference for
RFC 7030, which we use normatively, but we may not need to cite it
directly as a normative reference from this document.

It may be worth citing RFC 7525 as BCP 195 where it appears.

Appendix A

   transported in hex, but in binary.  The payloads are shown
   unencrypted.  In practice the message content would be transferred
   over an encrypted DTLS tunnel.

I expect a tsvart reviewer to complain about the use of the word
"tunnel" here, and suggest "channel" as an alternative.

   The certificate responses included in the examples contain Content-
   Format 281 (application/pkcs7).  If the client had requested Content-
   Format TBD287 (application/pkix-cert) by querying /est/skc, the
   server would respond with a single DER binary certificate.

Just to check my own understanding: this will always appear within a
multipart-core container, right?

Appendix A.1

     Option (Uri-Port)
        Option Delta = 0x4  (option# 3+4=7)
        Option Length = 0x4
        Option Value = 9085
      Option (Uri-Path)
        Option Delta = 0x4   (option# 7+4=11)
        Option Length = 0x5
        Option Value = "est"

This is more for my own edification than the document's sake, so thank
you for your time, but what accounts for the "extra" length here?  The
"est" is three bytes, and what makes up for the other two?  Also, I
assume that the port value of 9805 is the decimal value, which gets
CBOR encoded into two bytes  of integer encoding plus the byte with
additional information 25 to indicate the two-byte integer, and another
byte that I need help accounting for.

Appendix A.2

Do we want to say anything about the IDevID in the CSR/cert?
I note that the breakdown in Appendix C.2 (looks like openssl output)
does not decode the otherName (though asn1parse can be convinced to do
so).

Appendix A.3

I'm having trouble validating the private key in the PKCS#8 component:
asn1parse says:

$ unhex|openssl asn1parse -inform der
   308187020100301306072a8648ce3d020106082a8648ce3d030107046d30
   6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7
   45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82
   0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78
   cd33f3c1846e304f1717f8123f1a284cc99f
    0:d=0  hl=3 l= 135 cons: SEQUENCE          
    3:d=1  hl=2 l=   1 prim: INTEGER           :00
    6:d=1  hl=2 l=  19 cons: SEQUENCE          
    8:d=2  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   17:d=2  hl=2 l=   8 prim: OBJECT            :prime256v1
   27:d=1  hl=2 l= 109 prim: OCTET STRING      [HEX DUMP]:306B02010104200B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6A144034200041BB8C1117896F98E4506C03D70EFBE820D8E38EA97E9D65D52C8460C5852C51DD89A61370A2843760FC859799D78CD33F3C1846E304F1717F8123F1A284CC99F

which doesn't look like an RFC5208 PrivateKeyInfo:

      PrivateKeyInfo ::= SEQUENCE {
        version                   Version,
        privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
        privateKey                PrivateKey,
        attributes           [0]  IMPLICIT Attributes OPTIONAL }

      Version ::= INTEGER

      PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier

      PrivateKey ::= OCTET STRING

      Attributes ::= SET OF Attribute

due to the lack of OID for privateKeyAlgorithm, etc.
(`openssl pkcs8` also chokes on it, but I don't have a working example and
can't rule out user error there.)

Even that giant OCTET STRING 27 bytes in doesn't seem to match a
PrivateKeyInfo:

$ unhex|openssl asn1parse -inform der -strparse 27
   308187020100301306072a8648ce3d020106082a8648ce3d030107046d30
   6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7
   45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82
   0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78
   cd33f3c1846e304f1717f8123f1a284cc99f
    0:d=0  hl=2 l= 107 cons: SEQUENCE          
    2:d=1  hl=2 l=   1 prim: INTEGER           :01
    5:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:0B9A67785B65E07360B6D28CFC1D3F3925C0755799DEECA745372B01697BD8A6
   39:d=1  hl=2 l=  68 cons: cont [ 1 ]        
   41:d=2  hl=2 l=  66 prim: BIT STRING        

though the OCTET STRING does have the private key and the BIT STRING has
the public key's contents as depicted in C.3 (details of that too boring
to show).

So I have to wonder if I'm messing something up, somewhere.

Section A.4

I'm not sure how useful repeating the RFC 7030 csrattrs is: do we expect
(e.g.) brainpoolP384r1 to be relevant for our readers?

Appendix B.1

   and BLOCK option Block2.  The minimum PMTU is 1280 bytes, which is
   the example value assumed for the DTLS datagram size.  The example

I'm not seeing how this relates to the rest of the section.

                                  The CoAP message adds around 10 bytes,
   the DTLS record 29 bytes.  To avoid IP fragmentation, the CoAP Block

The DTLS overhead can also vary based on cipher suite, padding, etc., so
a bit more qualification ("we assume", "around", etc.) might be in
order.

   tenth packet of 63 bytes.  The client sends an IPv6 packet containing
   the UDP datagram with the DTLS record that encapsulates the CoAP
   request 10 times.  The server returns an IPv6 packet containing the
   UDP datagram with the DTLS record that encapsulates the CoAP
   response.  The CoAP request-response exchange with block option is

The definite vs. indefinite articles here don't seem quite right, and
each of the 10 datagrams do not encapsulate the entire CoAP request.

   with exponent (2**(SZX+4)) separated by slashes.  The Length 64 is
   used with SZX=2 to avoid IP fragmentation.  The CoAP Request is sent

We just said "to avoid IP fragmentation" ten lines ago.


Should we be using the same Token value in two different exchanges in
this document?

Appendix B.2

   In this example, the requested Block2 size of 256 bytes, required by
   the client, is transferred to the server in the very first request
   message.  The block size 256=(2**(SZX+4)) which gives SZX=4.  The

I don't see a Block2 size in the first request message, just Block1:

   POST [2001:db8::2:321]:61616/est/sen (CON)(1:0/1/256) {CSR req} -->
          <-- (ACK) (1:0/1/256) (2.31 Continue)


Also, we seem to have stopped using the "{CSR req frag#2}" notation that
we had in the main body text.

Appendix C.2

[I mentioned otherName's non-decoding earlier]

Appendix C.3

I find it kind of amusing that we have a "Netscape Comment" in the
generated cert :)