[Ace] Re: [core] Re: I-D Action: draft-ietf-core-uri-path-abbrev-01.txt and renewal-info

[Esko Dijk <[e-mail]>]

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<[e-mail]> 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<[e-mail]>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>
> _______________________________________________
> core mailing list [e-mail]
> To unsubscribe send an email [e-mail]

-- 
*IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
2385 8339