Subject: [Sidrops] I-D Action: draft-ietf-sidrops-https-tal-01.txt

From: [email-masked]
Date: Fri, 30 Mar 2018 03:45:00 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIDR Operations WG of the IETF.

        Title           : Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
        Authors         : Geoff Huston
                          Samuel Weiler
                          George Michaelson
                          Stephen Kent
                          Tim Bruijnzeels
	Filename        : draft-ietf-sidrops-https-tal-01.txt
	Pages           : 10
	Date            : 2018-03-30

Abstract:
   This document defines a Trust Anchor Locator (TAL) for the Resource
   Public Key Infrastructure (RPKI).  This document obsoletes RFC 7730
   by adding support for HTTPS URIs in a TAL.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sidrops-https-tal-01
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-https-tal-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 30 Mar 2018 12:59:34 +0200

Dear WG,

This -01 version reinstates the RFC7730 authors in the original order, with myself added to the end.

Other than the following remark has been removed from the HTTPS Considerations section:

   REMOVE LATER: The following text is inspired by the equivalent	 		
   section in [RFC8182], but adapted for this case.

As before, please have a look at the HTTPS Considerations section and speak up if you see anything here that you wish to discuss. In a nutshell this text says that it’s good to an RP SHOULD do best effort TLS verification and warn in case of issues, but MUST continue to retrieve data because a retrieved Trust Anchor certificate can still be verified and used even if the channel isn’t trusted. But then of course worded more formally, and including pointers that were added during the IESG review of RFC8182.

If I don’t hear any other remarks and if none of the re-instated authors prefer to be acknowledged instead, then I will ask the co-chairs for last call on this in a week or two from now,

Kind regards

Tim Bruijnzeels

> On 30 Mar 2018, at 12:45, [email-masked] wrote:
> 
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>