From nobody Mon Jan 22 01:56:13 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634E4126C3D for ; Mon, 22 Jan 2018 01:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7KfQy7oWqif for ; Mon, 22 Jan 2018 01:56:09 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39871243F6 for ; Mon, 22 Jan 2018 01:56:09 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1edYpg-0000zL-V9 for sidrops@ietf.org; Mon, 22 Jan 2018 10:56:08 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-180.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1edYpg-0002Gh-PM; Mon, 22 Jan 2018 10:56:04 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tim Bruijnzeels In-Reply-To: Date: Mon, 22 Jan 2018 10:56:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D0B8FA9-2CBD-41D6-91EC-40AAEDB42DFA@ripe.net> References: <151064401825.5985.7789265592065530099@ietfa.amsl.com> <20171116103441.GB7247@tomh-laptop> To: sidrops@ietf.org X-Mailer: Apple Mail (2.3445.5.20) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071937824f0d910aacfc2ddb27f8db722d59 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 09:56:12 -0000 Dear WG, Allow me to kick this thread again. The London IETF is happening soon, = and if possible I would like to have some discussion before then, so = that we may be able to update the document before then. TL;DR on the below: - I agree with Tom about a double encoding issue - I am thinking out loud whether to have: - An explicit XML based structure for the content, rather than a = simple TAL, as it will allow for some additional information that is = useful here - A mechanism for unplanned rolls: a stand-by key can can revoke the = current key if it would be lost - And if adopted, use the same mechanism for planned rolls (keep = things consistent). I would like to hear your thoughts on this. If it is desired I am happy = to present on this in London and/or discuss in person. Tim > On 6 Dec 2017, at 14:59, Tim Bruijnzeels wrote: >=20 > Hi Tom, >=20 > Thank you for your reply. I have been side-tracked for a bit, but let = me comment :) >=20 >> On 16 Nov 2017, at 11:34, Tom Harrison wrote: >>=20 >> On Mon, Nov 13, 2017 at 11:20:18PM -0800, internet-drafts@ietf.org = wrote: >>> 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. >>>=20 >>> Title : RPKI signed object for TAL >>> Authors : Tim Bruijnzeels >>> Carlos Martinez >>> Filename : draft-ietf-sidrops-signed-tal-00.txt >>> Pages : 10 >>> Date : 2017-11-13 >>=20 >> We've done a fairly basic proof-of-concept implementation of this as >> an extension to our RPKI system. The core of it looks good and >> functions as expected. Some questions and minor suggestions (all >> IMHO): >>=20 >> Having explicit structure in the SignedTalContent definition would >> make implementation a little easier. It would also remove any >> possible confusion about whether the public key need be = base64-encoded >> again (the current text appears to require that). >=20 > I agree that the double encoding is probably not needed. I hoped to = avoid any chance of having character in the =E2=80=98eContent=E2=80=99 = part that could cause issue. But.. just shooting for encoding again for = good measure was a bit of lazy thinking here.. we don=E2=80=99t need = this for the XML messages in RFC6492 (provisioning) and RFC8181 = (publication) either, so I think we should be safe. >=20 > There is no structure at the moment because we wanted to use the TAL = format as-is. >=20 > That said, I think that there may be merit in an explicit json, or XML = (to be consistent with 6492 and 8181) format, e.g.: >=20 > > > https://rpki.example.org/rpki/hedgehog/root.cer > rsync://rpki.example.org/rpki/hedgehog/root.cer > > > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx > GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 > Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 > nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa > BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG > ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 > aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB > > >=20 > A structure like this will make it easier to add tags or attributes to = communicate other things. See below. >=20 >> Section 3.3 has "[i]f the above procedure indicates that the manifest >> is invalid". It looks like it should be "...that the Signed TAL is >> invalid". >>=20 >> Section 4 has "[t]his EE certificate MUST have a "notBefore" time = that >> is before the moment that the Signed TAL will be published". Why is >> this a MUST? I can imagine somebody prepublishing the new TAL, but >> not wanting RPs to switch over until the notBefore time had been >> reached, though I guess that would also lead to validation errors for >> RPs in the interim due to the object not being in-date. >=20 > It=E2=80=99s a MUST because otherwise the object is invalid. >=20 > If we need an explicit staging time, rather than require this = implicitly by publishing it, then I think we are better off with a valid = object and an XML structure like above with an additional tag like: >=20 > 2019-01-01T00:00:00.000Z >=20 >> Regarding signed TAL EE certificate validity periods generally, I >> think it would be good to add some text about how the new TAL becomes >> 'effective' as soon as it is published, and that neither revocation >> nor expiry of the associated EE certificate has any implications in >> that respect (even though this is implicit from the document as a >> whole). >=20 > True. Whether it=E2=80=99s done implicitly by publishing the signed = TAL (as the document says now), or some explicit tag is = introduced: there is a point of no return by which RPs will have moved = over. >=20 > And thinking about this a bit more I believe that there should also be = text that forbids a Trust Anchor from pointing RPs back to a previous = key. We should only roll forward. >=20 >> Section 6.3 has "[t]he TA SHOULD preserve a Signed TAL for the old = key >> after the staging period as a hint for RPs that missed the key roll". >> Although (I think) the only sensible way to read this is that the >> signed TAL to which this is referring is that pointing to the new TA, >> "for the old key" might make people think the signed TAL should be = for >> the deprecated key instead. Something like "[t]he TA SHOULD preserve >> the Signed TAL pointing to the new TA after the staging period..." >> could work. >=20 > So, here there is a lot of implicit stuff again. >=20 > We could also think of this differently.. maybe extending the = structure to something like this could help: >=20 > > > MIIBIjANBgk=E2=80=A6 > MIIBIjdfkhjfd=E2=80=A6 > > > > > https://rpki.example.org/rpki/hedgehog/root.cer > rsync://rpki.example.org/rpki/hedgehog/root.cer > > > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx > GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 > Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 > nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa > BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG > ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 > aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB > > > > >=20 > This way we can communicate explicitly which previous keys have been = expired. And what the current key is at the time of publishing this. >=20 > If this is published by old keys in the form of long-lived objects and = CRLs, then RPs could still find their way to the current key. An = argument can also be made that RPs should not care about staleness of = MFT/CRL or expired MFT/TAL EE certificates in this case. >=20 >> I think 24 hours for the staging period is too short, mainly because >> people who don't update their validators to support this may not take >> action on the new validation error (something like "unknown type of >> object: {name}.tal") within that short a time period. >=20 > Okay, it=E2=80=99s not clear to me that this is related to the staging = period. >=20 > But, before any of this could be deployed we do need to be sure that = RP software can be upgraded to support it, or at least not choke on it. = If people do not upgrade their RP software they can still find out that = a new TAL should be used through other means (e.g. mailing lists). And = let me be devil=E2=80=99s advocate here.. if people never, ever upgrade = their RP software, then breaking it and forcing them to upgrade could be = considered a feature by some. Of course, after a reasonable time.. >=20 >> There are also >> other instances like this where manual action might be required, e.g. >> where operations staff insist that the validator not have write = access >> to its configuration and that all updates happen manually. A week or >> a month as a mandatory period would be better. >=20 > I believe that we should insist that key rolls like this are fully = automated and not done manually. I also believe that it would be prudent = that if && when we agree on a mechanism for this, it is done regularly - = at least in some environments to ensure that this works. In short: I = think a planned key roll, signed by a trusted TA, should be a normal = thing. If we leave this as paperware then there will be no guarantee = that it works when we need it. >=20 >=20 > One more thing I wanted to bring up is unplanned key rolls. There may = be merit in having a tag in the structure, like this: >=20 > > > MIIBIjANBgk=E2=80=A6 > MIIBIjdfkhjfd=E2=80=A6 > > =E2=80=A6 this key.. >=20 > > standby > > > https://rpki.example.org/rpki/hedgehog/root.cer > rsync://rpki.example.org/rpki/hedgehog/root.cer > > > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAovWQL2lh6knDx > GUG5hbtCXvvh4AOzjhDkSHlj22gn/1oiM9IeDATIwP44vhQ6L/xvuk7W6 > Kfa5ygmqQ+xOZOwTWPcrUbqaQyPNxokuivzyvqVZVDecOEqs78q58mSp9 > nbtxmLRW7B67SJCBSzfa5XpVyXYEgYAjkk3fpmefU+AcxtxvvHB5OVPIa > BfPcs80ICMgHQX+fphvute9XLxjfJKJWkhZqZ0v7pZm2uhkcPx1PMGcrG > ee0WSDC3fr3erLueagpiLsFjwwpX6F+Ms8vqz45H+DKmYKvPSstZjCCq9 > aJ0qANT9OtnfSDOS+aLRPjZryCNyvvBHxZXqj5YCGKtwIDAQAB > > > >=20 > >=20 > This could alert RPs that a new key exists. It in turn can publish the = same signed TAL structure - confirming that this staging key is not in = use yet. If and when the old key needs to be replaced and the TA = operator lost access to its key, then the staging key can publish a = structure where the old key appears in the list instead.. in = other words it=E2=80=99s empowered to revoke the =E2=80=9Ccurrent=E2=80=9D= key. If access to the =E2=80=9Cstaging" key is lost, then the = =E2=80=9Ccurrent=E2=80=9D key can just remove the section, or = replace it with another staging key. >=20 > The risk here is that if the new key goes rogue it can revoke the = current key. I don=E2=80=99t think that this is a bigger risk than the = current key going rogue. The advantage is that there is a back-up key = and in a TA can recover if they lose access to either the current, or = the staging key. If Hardware Security Modules (HSMs) are used, the risk = of key theft can be mitigated to a very large degree - typically keys = are protected by an N out of M card set where a quorum of people are = needed to use the key, or migrate it into new hardware. But, losing = keys, broken cards, and sadly loosing people, are real threats that can = lead to situations where a TA no longer has a quorum. >=20 > Obviously the above is not worked out in full detail, but I would = welcome discussion on the direction. And as a final thought.. it would = be good if the planned and unplanned key roll processes are similar. >=20 >=20 > Thanks >=20 > Tim >=20 >=20 >>=20 >> -Tom >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Jan 22 02:44:01 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64FA1241FC; Mon, 22 Jan 2018 02:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0rNCXL1YOOI; Mon, 22 Jan 2018 02:43:57 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A385C1201F8; Mon, 22 Jan 2018 02:43:57 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1edZZz-0009P1-5Q; Mon, 22 Jan 2018 11:43:56 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-180.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1edZZz-0002Xe-1R; Mon, 22 Jan 2018 11:43:55 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tim Bruijnzeels In-Reply-To: <1F0086D3-A2C4-4329-8A1C-8338FAE5ECC9@cisco.com> Date: Mon, 22 Jan 2018 11:43:54 +0100 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8E2DC236-A63E-4139-AF67-D2489F0CB3A6@ripe.net> References: <782CCC97-4BA2-4EF0-9B99-F0D17AE10D86@ripe.net> <1F0086D3-A2C4-4329-8A1C-8338FAE5ECC9@cisco.com> To: sidrops-chairs@ietf.org X-Mailer: Apple Mail (2.3445.5.20) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719a504e141666e6d966f62c48a57d35e50 Archived-At: Subject: Re: [Sidrops] Document on HTTPS on TALs (update to RFC7730) - seeking adoption X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 10:44:00 -0000 Dear co-chairs, Can I ask for an official call for adoption of this item: https://tools.ietf.org/id/draft-tbruijnzeels-sidrops-https-tal-00.txt When adopted, we can include the change that Roque suggested and make it = =E2=80=9Cobsoletes=E2=80=9D RFC7730, rather than updates - it=E2=80=99s = a self-contained document for readability, though most of the text is = straight out of RFC7730. Or I can spin up a -01 if it is needed for = process.. Thanks Tim > On 7 Dec 2017, at 12:37, Roque Gagliano (rogaglia) = wrote: >=20 > I support adoption with this change. >=20 > Roque >=20 >=20 >=20 >=20 > On 07/12/17 10:17, "Tim Bruijnzeels" wrote: >=20 > Hi Roque, WG, >=20 > As I said I believe that you=E2=80=99re right and it should say = =E2=80=9Cobsoletes=E2=80=9D. >=20 > Co-chairs, can you initiate a call for adoption on this? >=20 > I am happy to change =E2=80=9Cupdates=E2=80=9D to =E2=80=9Cobsoletes=E2= =80=9D when adopted. >=20 > Tim >=20 >=20 >=20 >=20 >> On 6 Dec 2017, at 21:11, Roque Gagliano (rogaglia) = wrote: >>=20 >> Hi Tim, >>=20 >> IMHO, If it replaces rather than complements, it should be obsoletes. >>=20 >> I guess there is a formal definition somewhere. >>=20 >> Roque >>=20 >>=20 >>=20 >>=20 >> Sent from my Samsung Galaxy smartphone. >>=20 >> -------- Original message -------- >> From: Tim Bruijnzeels >> Date: 11/30/17 14:39 (GMT+01:00) >> To: "Roque Gagliano (rogaglia)" >> Cc: sidrops@ietf.org >> Subject: Re: [Sidrops] Document on HTTPS on TALs (update to RFC7730) = - seeking adoption >>=20 >>=20 >>> On 30 Nov 2017, at 14:31, Roque Gagliano (rogaglia) = wrote: >>>=20 >>> Hi Tim, >>>=20 >>> Not sure I understand why you are =E2=80=9Cupdates=E2=80=9D RFC 7730 = and not =E2=80=9Cobsoletes=E2=80=9D RFC7730. Could you please elaborate = on this decision? >>=20 >> I believe you=E2=80=99re right and it should indeed say = =E2=80=98obsoletes=E2=80=99 - as in replaces - rather than updates = (parts) of it. That said, most of the text is a straight copy of the = text in 7730. >>=20 >> Tim >>=20 >>=20 >>>=20 >>> Regards, >>> Roque >>>=20 >>>=20 >>> On 30/11/17 14:02, "Sidrops on behalf of Tim Bruijnzeels" = wrote: >>>=20 >>> Dear working group, >>>=20 >>> As discussed at IETF99, and in informal talks with some of you, we = would like to update the TAL format (RFC7730) to allow HTTPS. >>>=20 >>> I worked with George Michaelson on an update. Because RFC7730 = contains quite a few references to =E2=80=98rsync=E2=80=99 we felt that = a new document updating 7730 would be more readable and appropriate then = document updating many small bits of text. The -00 version of this = document is here: = https://tools.ietf.org/id/draft-tbruijnzeels-sidrops-https-tal-00.txt >>>=20 >>> We would like to ask the co-chairs to make a call to the working = group for adoption. >>>=20 >>> In short this update will allow the use of HTTPS instead of, or in = addition to, rsync on TALs. Other than that it contains a section on TLS = verification similar to the one that is included in the delta protocol = (RFC8182) - essentially saying that TLS verification is done on a best = effort basis - and warnings should be uttered in case of issues - but = because the TA certificate can still be validated cryptographically it = MUST still be downloaded. Note that it is a matter of local policy = whether an RP chooses to use different locations if they are present, = but we may want to add some text here recommending the use of HTTPS URIs = that have no TLS verification issues over ones that do - at this point I = am not sure that this is needed, or would need to be normative text, but = I think it would be good to have some discussion on this. >>>=20 >>> For the record, I am not sure what is customary in these cases of = relatively small updates to existing standards. But, I tried to approach = the other authors of RFC7730 (George is already one of them) and ask = them whether they want to remain authors on this new document. Geoff = Huston indicated that he does not need to be on the list, but has no = objections to us doing this work. I have not seen responses from Sam = Weiler or Stephen Kent - it is also possible that they missed my = message. In any case we have no objections if they do wish to stay on as = authors, but for now they are not on the list of the document linked = above. >>>=20 >>> Kind regards, >>>=20 >>> Tim=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>>=20 >>>=20 >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 >=20 >=20 From nobody Fri Jan 26 12:27:20 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E74412778D for ; Fri, 26 Jan 2018 12:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jVOapq5b_tL for ; Fri, 26 Jan 2018 12:27:16 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0082.outbound.protection.outlook.com [104.47.42.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE5A127871 for ; Fri, 26 Jan 2018 12:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K4rq2W1qgDVlK4Q6MfkVGvqEJAowuLshf1gD4peulek=; b=pwWRjxFeVTh6jai/oPUveXHw/6/AAZWbqNOnxbjj62/IGd0kJ39af9/Tjcc6RI18D0cu8h1qZjG83HVXC68pnnSrEVA6cXcpOAotEDqF53Xh7oQgKVNQkfPUcCzGKndKSKnGC/QB1cp6TdKE0DcuoBwcVEp4hWtUU4WEiyCyGyU= Received: from BLUPR18MB0324.namprd18.prod.outlook.com (10.164.18.153) by BLUPR18MB0420.namprd18.prod.outlook.com (10.164.19.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Fri, 26 Jan 2018 20:27:14 +0000 Received: from BLUPR18MB0324.namprd18.prod.outlook.com ([10.164.18.153]) by BLUPR18MB0324.namprd18.prod.outlook.com ([10.164.18.153]) with mapi id 15.20.0444.016; Fri, 26 Jan 2018 20:27:14 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: WG Adoption call for draft-tbruijnzeels-sidrops-https-tal-00.txt Thread-Index: AQHTluQNJn3dcRDtwUy6KH7GaOzx4A== Date: Fri, 26 Jan 2018 20:27:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [2602:306:3005:4f60:e9cd:8e:47f4:11d9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR18MB0420; 6:7rVLI1NcO61VybuBs7fAQfJzJBfUwk7DBAWca3ajhOomqGQYhv7LYRiiPPmdN5tr60Ci6LtTqr2chf/7iaJ/C0lBqitHXsyuD0+Vrg8F4MZihgfe6qVNBcTaPH75SzLiHNzf2XHemYnT8fiOu+El1ENjEfzMYjoDJCzceKfko3uJD4uet85epBFZ3wexOrLsYTQgYgP13YApMy/pT5InZEX3JeQALc6L6UOqTAEE6/ffRMuSWPRehTvS3ggm2J6iVtnUX9VY+zO/btzpL6hB32ELiRN6MKHzyzV8/6+EPdakWFHMUMiyD3cRU2HC4g15Edx2kZsRvfhpxq3eLr0dN9rcz5R/b/CF67TzescJjaUyFuO+Zq0rP1n3dYlf/Utb; 5:8wPpfiP8CCN1FfYcl7k9Nhsvqi+wl92ifkbzubC4MPbnsfHg3MAepog3mrNYRft3GsZhfDxDTYDn7gWDpLtAIOoZWGCwmvGaRnYk4iAy2bHE40kLRRUTBkUcZBbU3d/QdkC5eVd879VcA2vKbChwGLhEYA8qkB6L9s06Lq1Tu9s=; 24:g7SNHa8gCWzkV1vfhjR1ke/H7KfnYrEzBvHrg8J2jDIL/aUpp5EI+keDu66EUXSN9mA3L/7yKH3KL3g5qmKmI/mHOoOTYj7WPwHIyGzjZ/4=; 7:1ZgMrqLA00My+3r5I8eM6AUxjSc/4C7JwwrQ42WcwqFbscVsK5OUS+oVTIDhExNR+Cm+UPodXqQx87POzYv2T2ZZjEQTokp255Y5t/vVRe8YjBvfWXaPGQjTh4BYdcs3pVXSVGQCINOtkEUonmSOZ6Yzn3ZqAraVEbt4AiQ/w5IoTxo4RrLkuABEu6aW1KQsjYD6GfrdmuRN4BG0+ysTSHESKJVi1IFUVpErc7+guUSb9aVY3124gVAn+snFdNT5 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1fb2efb0-7bda-41f9-b53d-08d564fb2fcb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BLUPR18MB0420; x-ms-traffictypediagnostic: BLUPR18MB0420: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231023)(2400081)(944501161)(6041288)(20161123562045)(20161123558120)(20161123564045)(2016111802025)(20161123560045)(6072148)(6043046)(201708071742011); SRVR:BLUPR18MB0420; BCL:0; PCL:0; RULEID:; SRVR:BLUPR18MB0420; x-forefront-prvs: 05641FD966 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(366004)(396003)(376002)(39830400003)(189003)(199004)(54896002)(606006)(14454004)(6116002)(2900100001)(6486002)(6436002)(6506007)(6512007)(6306002)(25786009)(236005)(3660700001)(186003)(82746002)(36756003)(68736007)(316002)(53936002)(6916009)(9326002)(99286004)(1730700003)(81166006)(81156014)(106356001)(5660300001)(83716003)(478600001)(86362001)(8936002)(102836004)(105586002)(7736002)(3280700002)(2501003)(97736004)(77096007)(2351001)(5640700003)(966005)(33656002)(2906002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR18MB0420; H:BLUPR18MB0324.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Q0M8v85agn8VQpJX5KYA1Lox4XbJoxLCFPRBfPHyetjlxtRJxoNbg72aKIpvOAQpepUWrROBevMans7knREiDw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E6CF4BFAA0C6401F900954B1AC120F53arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1fb2efb0-7bda-41f9-b53d-08d564fb2fcb X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2018 20:27:14.2991 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR18MB0420 Archived-At: Subject: [Sidrops] WG Adoption call for draft-tbruijnzeels-sidrops-https-tal-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 20:27:19 -0000 --_000_E6CF4BFAA0C6401F900954B1AC120F53arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNClRoZSBhdXRob3JzIGhhdmUgcmVxdWVzdGVkIFNJRFJPUFMgd29ya2luZyBn cm91cCBhZG9wdGlvbiBjYWxsIG9mIOKAnFJlc291cmNlIFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1 cmUgKFJQS0kpIFRydXN0IEFuY2hvciBMb2NhdG9y4oCdLCAgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9pZC9kcmFmdC10YnJ1aWpuemVlbHMtc2lkcm9wcy1odHRwcy10YWwtMDAudHh0Lg0KDQpQbGVh c2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LiBUaGlzIGFkb3B0aW9uIGNhbGwgd2ls bCBjb25jbHVkZSBvbiBGZWIgOSAyMDE4Lg0KDQpSZWdhcmRzLA0KQ2hyaXMgJiBLZXl1cg0KDQoN Cg== --_000_E6CF4BFAA0C6401F900954B1AC120F53arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <9BAB573B0C8CF243BE877DE206EE7D38@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBGb2xr cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBhdXRob3Jz IGhhdmUgcmVxdWVzdGVkIFNJRFJPUFMgd29ya2luZyBncm91cCBhZG9wdGlvbiBjYWxsIG9mIOKA nFJlc291cmNlIFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgKFJQS0kpIFRydXN0IEFuY2hvciBM b2NhdG9y4oCdLCAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0 LXRicnVpam56ZWVscy1zaWRyb3BzLWh0dHBzLXRhbC0wMC50eHQiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtdGJydWlqbnplZWxzLXNpZHJvcHMtaHR0cHMtdGFsLTAwLnR4dDwvYT4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LiBUaGlzIGFkb3B0aW9uIGNhbGwgd2lsbCBjb25jbHVk ZSBvbiBGZWIgOSAyMDE4LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q2hyaXMgJmFtcDsgS2V5dXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E6CF4BFAA0C6401F900954B1AC120F53arrcuscom_-- From nobody Fri Jan 26 12:36:46 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F3612DA41 for ; Fri, 26 Jan 2018 12:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kx4RY4xyaf2I for ; Fri, 26 Jan 2018 12:36:44 -0800 (PST) Received: from mail-ot0-f170.google.com (mail-ot0-f170.google.com [74.125.82.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6FAA12778D for ; Fri, 26 Jan 2018 12:36:43 -0800 (PST) Received: by mail-ot0-f170.google.com with SMTP id r4so1488546oti.12 for ; Fri, 26 Jan 2018 12:36:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=jhCZBDt3niXZoGYd+ypikUC8Y2iiE84a4VxF/Sl4PcY=; b=arWsg3bXMIhb5lPnvJ76Qmgfd7lay0eQoxvHhlI2GcSOfwPezPlijhB0IqKGYwkfAK NPv4QBLzZFfT78V68p6+yM5xB1RJofJJcYm1HWxfbMi4hi9gVLAD0VPQtK3nRbshJ+AD l3MB/3EYVblErqCA0zY7VXrTcLXTCNAQEP01kADuoqJjco097tnIUOGeB0LoXr6lEXOb ByevESNMTcnbpUBXB+snrrB6ksO0pJjU+1fQHVYTXUMmTH9YbdEqojQSdqrvChS5pYF7 DZDl7dvmhsILRsIwA/YnA0C3vzN2h/bejXYIwcR+8n37gK4bkUuiQGUYDMYyVTuTgbQ7 8wyg== X-Gm-Message-State: AKwxytcM+oeFHdcoFBlEChplvcqJlqgH0gKuUxsletXnjhlczNpjyViQ +IuJ6CDMpw/PbmD2dqXk0w2EB7RXtEA= X-Google-Smtp-Source: AH8x227Oopk3/VjRGHNE7hrQerkXMvjrKuLDCE4rsAze1IfNqLgvtVaTk2X1EDcDY870CVS7wbFEJw== X-Received: by 10.157.58.116 with SMTP id j107mr14259656otc.238.1516999002962; Fri, 26 Jan 2018 12:36:42 -0800 (PST) Received: from vurt.meerval.net (65-98-183-51.static-ip.telepacific.net. [65.98.183.51]) by smtp.gmail.com with ESMTPSA id u58sm473533otf.10.2018.01.26.12.36.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Jan 2018 12:36:42 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 1697c827; Fri, 26 Jan 2018 20:36:41 +0000 (UTC) Date: Fri, 26 Jan 2018 20:36:41 +0000 From: Job Snijders To: Keyur Patel Cc: "sidrops@ietf.org" Message-ID: <20180126203641.GC74143@vurt.meerval.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-tbruijnzeels-sidrops-https-tal-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 20:36:46 -0000 On Fri, Jan 26, 2018 at 08:27:14PM +0000, Keyur Patel wrote: > The authors have requested SIDROPS working group adoption call of > “Resource Public Key Infrastructure (RPKI) Trust Anchor Locator”, > https://tools.ietf.org/id/draft-tbruijnzeels-sidrops-https-tal-00.txt. > > Please send your comments to the list. This adoption call will > conclude on Feb 9 2018. I support adoption. Question about section 2.3: rsync://rpki.example.org/rpki/hedgehog/root.cer Are the < and > chars supposed to be there? I think the authors may want to wrap the example in Kind regards, Job From nobody Sat Jan 27 20:46:02 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A391200FC for ; Sat, 27 Jan 2018 20:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oCXg4zlygKv for ; Sat, 27 Jan 2018 20:45:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590A6120047 for ; Sat, 27 Jan 2018 20:45:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1efeqq-000611-ID; Sun, 28 Jan 2018 04:45:57 +0000 Date: Sun, 28 Jan 2018 13:45:54 +0900 Message-ID: From: Randy Bush To: Keyur Patel Cc: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-tbruijnzeels-sidrops-https-tal-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 04:46:01 -0000 > The authors have requested SIDROPS working group adoption call of > $B!H(BResource Public Key Infrastructure (RPKI) Trust Anchor Locator$B!I(B, > https://tools.ietf.org/id/draft-tbruijnzeels-sidrops-https-tal-00.txt. my criterion for adoption is whether a document is worth the time and effort of discussion. imiho, this draft meets that test. randy From nobody Mon Jan 29 01:46:11 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55A9127775 for ; Mon, 29 Jan 2018 01:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRDIqbNr12pZ for ; Mon, 29 Jan 2018 01:46:07 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF3B13177A for ; Mon, 29 Jan 2018 01:44:21 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eg5z9-0003na-3W; Mon, 29 Jan 2018 10:44:19 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-174.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eg5z8-00084v-Ux; Mon, 29 Jan 2018 10:44:18 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tim Bruijnzeels In-Reply-To: <20180126203641.GC74143@vurt.meerval.net> Date: Mon, 29 Jan 2018 10:44:17 +0100 Cc: Keyur Patel , "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7A9ADD3F-DFDA-4DD7-A440-F4300481635A@ripe.net> References: <20180126203641.GC74143@vurt.meerval.net> To: Job Snijders X-Mailer: Apple Mail (2.3445.5.20) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719f6713b6f1eafa716cfdb2238265df3e5 Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-tbruijnzeels-sidrops-https-tal-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 09:46:10 -0000 Hi Job, all, > On 26 Jan 2018, at 21:36, Job Snijders wrote: >=20 > Question about section 2.3: >=20 > rsync://rpki.example.org/rpki/hedgehog/root.cer > >=20 > Are the < and > chars supposed to be there? I think the authors may = want > to wrap the example in Thanks, I missed this. I am using a markdown source and I am having a = bit of trouble to get it to treat this as artwork when converting to = xml. Should be sorted in the next version! Tim From nobody Tue Jan 30 10:38:21 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1533D12FA95; Tue, 30 Jan 2018 10:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q45KxFk5swEO; Tue, 30 Jan 2018 10:38:14 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532BA12D942; Tue, 30 Jan 2018 10:38:13 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id a63so7431480vkg.6; Tue, 30 Jan 2018 10:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yK7o1IKhWjxvGXnA3JULl+53ow6IYCDn+UtCWBZ7Nc8=; b=XHarW+CHycfp+OJ2xb3ppwncJ/sTPGXmJIOgzBXt97qSgfcHU2U1dciEdh47UcISik tqhpOQbHoA+VpSVHAHQ9mQYj9fgAxERbaX+ahtGQy+FujMcamTHFCgfTOf0Ewwkx9iP9 64umHWUArs2/puuW6Z/0kMx5q1z0cE7a9r5JCl4Ww8ZY69u2S731IzD57Pwc0Sb5ETU2 imOeEqE8qtOtMnRP+NfyxxxBrvwd4XT6ElCAE4hyU/NPD0ZYxfZyEPrACK+TgnVxjCoB eCavmCx3qv77aYyWAEnctJLa5+Myh4qY0DtHusegJD8bpPIp3So03wwujmDxA1sIsLr/ QDDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yK7o1IKhWjxvGXnA3JULl+53ow6IYCDn+UtCWBZ7Nc8=; b=UIq1dfYqhHGqbvCeERLxq/C1uYVwhF7KOfzsrBbEof6+GKs+pTqB/4crBzBn7WAZux DqSWcT+7MFge4yK0stPwG66Pr7fcHBjWMQYGaPAWnhjLG30aCB+KL/CZHo1iL91l1kB0 xROS/SfuPZZYgbz3D4semWwC+N0tN29v7V2+WNvDBwdNCKBc2u1kTVA/EIs5kMea5iyO e1b7VuO/4NCwLtHod2Lf3WszLGW58RTA1jP6jSowI6av9kN8NzfRTCc53DEKUVf6VpB0 z1nPIdUs7ro6Z1wIGiMd/D1PYpQE27lg0mZgJoLmmrt5lMKwagDRKWcqRCMnnl6Debat tu4g== X-Gm-Message-State: AKwxytdqgMoviCeFdtiGC+XmMpw77xYrAygOtMREDg0RqTfegvGQuEJR slEwiGm57Y0RvFj4JnJ6HO/4Ct5nfELkDWC7zCl4gP79 X-Google-Smtp-Source: AH8x227pEOGFuwfvF5QiFsnw+ii6Q8A7tvQuzQnHtj93WDQSHmQTh+QlSLsA8h+vZWZpBAwTWJLYlCForZ2sYSvUloE= X-Received: by 10.31.167.200 with SMTP id q191mr23179137vke.10.1517337492060; Tue, 30 Jan 2018 10:38:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.112.37 with HTTP; Tue, 30 Jan 2018 10:38:11 -0800 (PST) From: Christopher Morrow Date: Tue, 30 Jan 2018 13:38:11 -0500 Message-ID: To: sidrops@ietf.org, sidrops-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a11426c82380046056402aa67" Archived-At: Subject: [Sidrops] Call for Adoption: draft-borchert-sidrops-bgpsec-algs-rfc8208-bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 18:38:21 -0000 --001a11426c82380046056402aa67 Content-Type: text/plain; charset="UTF-8" Howdy WG folks, Oliver has done some work to further his presented material from Singapore: "Extending RFC82088 by adding Experimental/Documentation algorithm IDs" This is reflected in the subject draft/-bis for RFC8208. Can we please take 2 weeks (ending: 02/13/2018 - Feb 13, 2018) to read/review/comment and consider if this document should be adopted by the sidrops working-group as a work item? Draft: https://tools.ietf.org/html/draft-borchert-sidrops-bgpsec-algs-rfc8208-bis-00 thanks! -chris sidrops-chair-02 --001a11426c82380046056402aa67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy WG folks,

Oliver has done some wo= rk to further his presented material from Singapore:
=C2=A0 "Extend= ing RFC82088 by adding Experimental/Documentation algorithm IDs"
=

This is reflected in the subject draft/-bis for RFC8208= . Can we please take 2 weeks (ending: 02/13/2018 - Feb 13, 2018) to read/re= view/comment and consider if this document should be adopted by the sidrops= working-group as a work item?

Draft:=C2=A0
<= div>=C2=A0=C2=A0https://tools.ietf.org/html/draft-borchert-s= idrops-bgpsec-algs-rfc8208-bis-00

thanks!
-chris
sidrops-chair-02
--001a11426c82380046056402aa67-- From nobody Tue Jan 30 15:49:51 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9F312EB57; Tue, 30 Jan 2018 15:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPWLWlf0BMWx; Tue, 30 Jan 2018 15:49:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC19412EBE5; Tue, 30 Jan 2018 15:49:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1egfer-0001zP-DS; Tue, 30 Jan 2018 23:49:45 +0000 Date: Wed, 31 Jan 2018 08:49:43 +0900 Message-ID: From: Randy Bush To: Christopher Morrow Cc: sidrops@ietf.org, sidrops-chairs@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Call for Adoption: draft-borchert-sidrops-bgpsec-algs-rfc8208-bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 23:49:49 -0000 > Oliver has done some work to further his presented material from > Singapore: "Extending RFC82088 by adding Experimental/Documentation > algorithm IDs" ^ someone eight my rfc number > consider if this document should be adopted by the sidrops > working-group as a work item? seems like a good plan; other than i will then have to slog through it. but i commit to doing so. :) randy From nobody Tue Jan 30 18:07:35 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A49131499; Tue, 30 Jan 2018 18:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piARPhU3_CkX; Tue, 30 Jan 2018 18:07:30 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E87712FB65; Tue, 30 Jan 2018 18:07:30 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id g186so8112251vkd.8; Tue, 30 Jan 2018 18:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nXsXLBX2/0b+RhGQHQqnnpJWwz9qZbjLOHi84/YtIFM=; b=LOqqj0CJNDfIvFfPO4N9DlA/bN/LvKcGBVf9mWmCRZ4L4U8hJgr4C0862NWsCO/K6j ljAyMDERUXZOwEXppdQDflm6sbIbU3n4GpZdG1rsHrgF25uLtVXq9TyymJdWjXwAu18U 1I/IXg1t24Q8C+iPUywOw1wQ2fNFeqFJZ3QaYcFX6/wQnzlN3yBsC0uQfOj6Rwctqkoa GItlJhKk9M4zsOAqrtwtApOECChceaTDjrf7EncyyGX1r6kIRNG7qg4s94lw1kxL3Zg6 rnlPQA4eoSPnoZd6Dsfei62nvdgWSPhsVes46A+Rt1FSlUoRb2S1xTvIFJKhkO81PJt2 bnnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nXsXLBX2/0b+RhGQHQqnnpJWwz9qZbjLOHi84/YtIFM=; b=Kk4X5ysUxUS8s17F7QUEWs0u4mxC1mni5Z+fcoFlz6OraZkTiezo2iGL/1NF3WDb/n lx8pCy5YrsdNFE1aW8mnDJoTrKqslhWSVFzrDUICEqShUOyayLGvGirxQQbS67PT9pFT UqNJZb8eW7YLeUf8qwHUoJuhow/ulLj50h7M8me/xD73caXBClCyWWiU5ufx0LGMtQRy EJbgPUvTGkNCushYYNa3UVfA8nmFEa5nVCNVLFRwwHW1Sl/F9HZcgHKnUU7fO2rFUZR8 N0hSe1bnJdX9OWi3U0T5GOqEZrKaAvn/dFT+3KsZ2VPXLzf6T3p9jcEbF3tVoEpJv5ta BEJA== X-Gm-Message-State: AKwxytffw2Il9WWtQDgpw6iP88IHa+gwlvkJ46RlVDPlqHnUh34D2tTW 8i689FMEdtbTBMF0deyVqGcvuAATr33UEpP3S4w= X-Google-Smtp-Source: AH8x224+qoxofJJ8hpd+ZZgY83H0Taslt/2llylyO5lf4UEY1WU0ZVDT3/VkPu7I8epCEywBP5LyIg7rZkB7sAg4CUY= X-Received: by 10.31.41.10 with SMTP id p10mr24408191vkp.110.1517364448875; Tue, 30 Jan 2018 18:07:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.112.37 with HTTP; Tue, 30 Jan 2018 18:07:28 -0800 (PST) In-Reply-To: References: From: Christopher Morrow Date: Tue, 30 Jan 2018 21:07:28 -0500 Message-ID: To: Randy Bush Cc: sidrops@ietf.org, sidrops-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a113ef368f85cc7056408f0ad" Archived-At: Subject: Re: [Sidrops] Call for Adoption: draft-borchert-sidrops-bgpsec-algs-rfc8208-bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 02:07:33 -0000 --001a113ef368f85cc7056408f0ad Content-Type: text/plain; charset="UTF-8" \ On Tue, Jan 30, 2018 at 6:49 PM, Randy Bush wrote: > > Oliver has done some work to further his presented material from > > Singapore: "Extending RFC82088 by adding Experimental/Documentation > > algorithm IDs" ^ > > someone eight my rfc number > > oh keyboard!! RFC 8208: https://tools.ietf.org/html/rfc8208 sorry! :) > > consider if this document should be adopted by the sidrops > > working-group as a work item? > > seems like a good plan; other than i will then have to slog through it. > but i commit to doing so. :) > > thanks! --001a113ef368f85cc7056408f0ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
\

On Tue, Jan 30, 2018 at 6:49 PM, Randy Bush <randy@psg.com>= wrote:
> Oliver has done some work to further his presented material f= rom
> Singapore: "Extending RFC82088 by adding Experimental/Documentati= on
> algorithm IDs"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0^

someone eight my rfc number


oh keybo= ard!! RFC 8208:
=C2=A0=C2=A0https://tools.ietf.org/html/rfc8208

sorry!= :)
=C2=A0
> consider if this document should be adopted by the sidrops
> working-group as a work item?

seems like a good plan; other than i will then have to slog through = it.
but i commit to doing so. :)


thanks!=C2=A0

--001a113ef368f85cc7056408f0ad--