Renewal is indeed important for EST-obtained certificates, and knowing
when to renew also.
In draft-ietf-anima-constrained-voucher (cBRSKI) we call it
"re-enrollment" (this includes both plain renewal as well as a potential
change of domain TA). Do we have this term correct?
If renewal happens frequently enough, we might have a good use case for
using Uri-Path-Abbrev. But, this is only in the following case:
1. Device knows, or somehow discovers, address/port of the EST Registrar
and contacts it using a /.well-known/est/... resource.
There's also other cases enabled by RFC 9148: (Section 4.1)
2. Device knows, or somehow discovers, address/port of the EST
Registrar, makes DTLS connection, and uses CoAPS-secured discovery to
get resource names. (Shorter Link Format document - example 1 in 4.1.
Still more verbose than really needed...)
3. Device uses unsecured CoAP discovery to find address/port/resources
of EST Registrar, then makes DTLS connection and uses the discovered
resource names. (Very long Link Format document - example 2 in 4.1.)
In case 2/3, Uri-Path-Abbrev won't be used. Not a problem, just wanted
to point this out.
Esko
On 27-9-2025 19:32, Michael Richardson wrote:
Christian Amsüss<[email protected]> wrote:
> I think this is as compact as it gets, with all the options of
> repetition deferred to future development (sketched in an appendix for
> the benefit of future documents), it's really just a simple number.
Agreed.
Rifaat,MikeO and I have just posted
draft-yusef-lamps-rfc7030-renewal-recommendation.
It replicates RFC9773 (an ACME thing) into EST/RFC7030.
It (renewal-info) probably should also update RFC9148 to add a new renewal-info
for
EST-coaps. So this would fit into the path-abbrev 30x space!
I think it will be fine for renewal-info to block on publication of abbrev.
Probably renewal-info should return CBOR for 9148 use, so we'll need to do CDDL.
So I'll include IANA Considerations in that document.
----
I think that renewal-info will have to resurrect the well-known/EST registry
that RFC8995 created as I-D, then walked back to make well-known/BRSKI
instead near the last minute...
--
Michael Richardson<[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
core mailing list [email protected]
To unsubscribe send an email [email protected]
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
_______________________________________________
Ace mailing list -- [email protected]
To unsubscribe send an email to [email protected]
