Re: [netconf] Éric Vyncke's No Objection on draft-ietf-netconf-trust-anchors-23: (with COMMENT)

[Kent Watsen <[e-mail]>]

Hi Eric,


> On Jan 31, 2024, at 4:43 AM, Eric Vyncke (evyncke) <[e-mail]> wrote:
> 
> Hello Kent and thank you for your prompt reply.
> 
> As my corporate mail agent is quite broken, please see below for EVY>

Responses below!

K.


> Regards
> 
> -éric
> 
> 
> On 29/01/2024, 15:35, "Kent Watsen" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
> 
> 
> Hi Éric,
> 
> 
> 
> 
>> On Jan 29, 2024, at 5:31 AM, Éric Vyncke via Datatracker <[e-mail] <mailto:[e-mail]><mailto:[e-mail]>> wrote:
>> 
>> Éric Vyncke has entered the following ballot position for
>> draft-ietf-netconf-trust-anchors-23: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> 
>> for more information about how to handle DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/<https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/>
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Thanks for the work done for this document.
>> 
>> Suggest to refresh some dates used in examples (2018 is a long time ago).
> 
> 
> I updated the date in the example to 2024.
> This update is only in my local copy for now...
> 
> 
> EVY> thank you
> 
>> Should there also be a 'not valid before' date for certificates ?
> 
> 
> Is this comment connected to the previous comment regarding the "certificate-expiration” notification?
> Assuming “yes”, I do not think there is a need for a *notification* for 'not valid before’ - agreed?
> 
> EVY> my only issue with the above statement is that the store is then limited to sending notification and not on how to select the right certificate. 
> EVY> selecting the right certificate is important when doing cert rollover (i.e., the sender has 2 certs with a small time overlap).

Hmmm, now my understanding is that you’re NOT asking for a *notification”, but rather possibly a couple “config false" nodes to propagate said validity period values from the certificate itself.  

Whilst this could be done, I wonder to what end?  How many more X.509 fields would folks want to surface?
  - On the flip side, clients can examine the cert themselves for such details - too much effort?

If too much effort, then what about clients that care mangle info they care about into the “name” field?  For example this:

      <certificate>
        <name>My certificate (notBefore: AAA, notAfter BBB)</name>
        <cert-data>BASE64VALUE=</cert-data>
      </certificate>

Please advise.


>> How can a node know where to send the certificate expiration notifications ? Is
>> it also a pub/sub model ? (I should probably know the answer…)
> 
> 
> How YANG notifications are delivered is topic outside the scope of this draft but, since you asked…
> - delivery varies by protocol: e.g. NETCONF and RESTCONF have their own delivery mechanisms
> - delivery can also be via UDP or HTTP (see the udp-notif and http-notif drafts - WG documents)
> 
> EVY> I will have to (re)-read the udp/http notifications then ;-)

Yes, orthogonal to this document.


Thanks again,
Kent