Subject: [Sidrops] draft-kwvanhove-sidrops-rpki-tree-hints-01

From: "Koen van Hove" <[email-masked]>
Date: Mon, 13 Dec 2021 16:36:55 +0100

Dear all,

Based on your feedback I hereby present the second version of the tree hints
draft [1]. 

Russ Housley rightly pointed out to me that whilst additional fields cannot
be added to the PKIX certificate profile, non-critical extensions can be
added. I believe adding the hints to the certificate directly, rather than
using a separate object, reduces operational complexity, might simplify some
issues with "what if the limits change" (as that now only happens when the
certificates change). I hope it also makes the political problem less
troubling. Additionally, I reduced the limits to the two main ones, although
others can be added in a similar fashion. Apart from that, the main concept
was left unchanged.

Koen van Hove

[1]
<https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/>
https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/

---

From: Ties de Kock <[email-masked]>
Date: Mon, 13 Dec 2021 17:00:35 +0100

Hi Koen,

> On 13 Dec 2021, at 16:36, Koen van Hove <[email-masked]> wrote:
> 
> Dear all,
>  
> Based on your feedback I hereby present the second version of the tree hints draft [1]. 
>  
> Russ Housley rightly pointed out to me that whilst additional fields cannot be added to the PKIX certificate profile, non-critical extensions can be added. I believe adding the hints to the certificate directly, rather than using a separate object, reduces operational complexity, might simplify some issues with “what if the limits change” (as that now only happens when the certificates change). I hope it also makes the political problem less troubling. Additionally, I reduced the limits to the two main ones, although others can be added in a similar fashion. Apart from that, the main concept was left unchanged.

That is a significant realisation. I think this will need some testing to see
what implementations are intolerant to additional extensions, but that should be
quick --- but if this works, this is much easier to implement, both for RPs and
CAs.

This also specifies the exceptions much more naturally :).

Kind regards,
Ties

---
>  
> Koen van Hove
>  
> [1] https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/ <https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/>_______________________________________________
> Sidrops mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>