[NCAP-Discuss] Defining CI/CE

[rubensk at nic.br]

- If the TLD is currently held by one specific party and can't be assigned to others, this qualifies to get a wildcard certificate from current CA/B Forum guidelines. So instead of a certificate for deadend.icann.org, a certificate for *.TLD could be served. This certificate only needs to be time-constrained so it doesn't interfere with regular TLD usage afterwards. The 90-day Let's Encrypt default sounds like a good start, and happens to be the length of 2012-round CI.
- If a valid certificate can be served, then an HSTS header with a limit similar to the certificate validity could be set. This will prevent further HTTP communication by the top browsers.
- In order to set HSTS, the first HTTP redirect will need to be done to an in-domain site. Like to hsts.nic.TLD or something like that, and after setting HSTS, then redirecting to https://icann.org/namecollisions. HTTPS can already set HSTS and serve a redirect in the same request.


Rubens
PS: I am still doubtful that ECI will ever see the light of the day. But if it does, it needs to have the least harmful operating specs.


Rubens





> On 25 Feb 2022, at 21:28, Jeff Schmidt via NCAP-Discuss <ncap-discuss at icann.org> wrote:
> 
> Sorry, I was too imprecise in my SSL certificate language in the last one. Please replace with this one.
> 
> Thx,
> Jeff
> 
> 
> On 2/25/22, 6:20 PM, "NCAP-Discuss on behalf of Jeff Schmidt via NCAP-Discuss" <ncap-discuss-bounces at icann.org <mailto:ncap-discuss-bounces at icann.org>on behalf of ncap-discuss at icann.org <mailto:ncap-discuss at icann.org>> wrote:
> 
>    All:
> 
>    I think a very important point has come out of this discussion - one of the reasons for the circular arguments is that we have never carefully defined CE and therefore we're operating under a number of assumptions which have vastly different implementation outcomes. Credit to Matt L and Danny for pointing this out.
> 
>    Attached is my shot at a careful technical definition of the Controlled Interruption and Controlled Exfiltration options. We need to come to consensus on this before we can further discuss/recommend. The attached is the most conservative technical approach I can think of. This is just a strawman to start the conversation. I'm happy to be wrong on any/all of this. But no more glossing over the details - let's be super specific.
> 
>    I would suggest the Chair(s) "force the issue" and call for consensus on this as quickly as discussion allows. Our lack of fundamental agreement here is blocking progress on this important item.
> 
>    Thx,
>    Jeff
> 
> 
> 
> <NCAP Implementation Spec2.pptx>_______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
> 
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220226/06b9d196/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220226/06b9d196/signature.asc>