Clarify /crts text

[malishav]

Based on @EskoDijk 's review in https://mailarchive.ietf.org/arch/msg/ace/I70MHcCzSfPIy28lDqxEOcllgJw/:

4.2.1 /crts

… which is subsequently installed in the Explicit TA. “TA” here should be “TA database”. And it could be clarified that the “installed in” 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: “could be just the CA public key … or … without the signature” -> in this case the Content-Format would be a different one, I presume – 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’s 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.

[malishav]

OLD: EST-oscore follows much of the EST-coaps and EST design.

NEW: EST-oscore follows much of the EST-coaps and EST design. This includes the need to authenticate the EST-server before performing any request on the different EST endpoints specified in this document.

OLD:

EST-coaps provides the /crts operation. A successful request from the client to this resource will be answered with a bag of certificates which is subsequently installed in the Explicit TA.

NEW:

EST-coaps provides the /crts operation. A successful request from the client to this resource will be answered with a bag of certificates which is subsequently installed in the TA database, resulting in Explicit TAs.

OLD:

A trust anchor is commonly a self-signed certificate of the CA public key. In order to reduce transport overhead, the trust anchor could be just the CA public key and associated data (see {{terminology}}), e.g., the SubjectPublicKeyInfo, or a public key certificate without the signature. In either case they can be compactly encoded, e.g. using CBOR encoding {{I-D.ietf-cose-cbor-encoded-cert}}.

NEW:

A trust anchor is commonly a self-signed certificate of the CA public key, of the format indicated by the CoAP Accept option present in the request. In order to reduce transport overhead, the trust anchor could be a CBOR encoding of an X.509 certificate {{I-D.ietf-cose-cbor-encoded-cert}}, or a CWT Claims Set (CCS) {{RFC8392}}, containing the CA public key and associated data without a signature.