From nobody Mon May 3 15:03:39 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3064B3A13EF; Mon, 3 May 2021 15:03:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: keyur@arrcus.com, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162007941662.29330.5665763278778684349@ietfa.amsl.com> Date: Mon, 03 May 2021 15:03:37 -0700 Archived-At: Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 111 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 22:03:37 -0000 A new meeting session request has just been submitted by Keyur Patel, a Chair of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Keyur Patel Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 70 Conflicts to Avoid: Chair Conflict: grow idr Technology Overlap: opsarea opsec opsawg People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue May 4 19:05:29 2021 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 E29D93A1F05 for ; Tue, 4 May 2021 19:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 UopHwnBUKOqu for ; Tue, 4 May 2021 19:05:25 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 1E2ED3A1F06 for ; Tue, 4 May 2021 19:05:24 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id 76so179320qkn.13 for ; Tue, 04 May 2021 19:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PdbwAHsey6MZEy4raxjQybs7vdxsGyrmTrqqdvBc3Vk=; b=AUkBsebd+XD9FxI/ZDb71mo4+JYIRX5CmuO99jqQdK+VhfHN5P/CZKSmpKm8MzCpR4 HGriH7yNVmQpJcRaqK6qqNhNxa1AsAScKHIpV9U6AUUSF8OAYQnFkCd78lGJKAkzdzz4 O3FW2Zj52CYIq5EaPXV/HFpHFr3vsAMA+OrruH6nbKOhhhQGfdGS/6cAUa1ZvD9U+MbO guYAu00/wxE5k+zWdP1dSi/oJlSHPKLWoYAg5csR//cjm+egN97LAsMOWNUnsNIBopSK zzJ8QznpELg6UgND+RcL0VSQ9o4u0aX8wcEqSeigiQ1Ghy/4Ni5H7OJa7pR31EZ9ey04 TXLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PdbwAHsey6MZEy4raxjQybs7vdxsGyrmTrqqdvBc3Vk=; b=ISg35fkEtvuP0UdzE89QPwVYFELnAj9H/ilZ66pM/xosI0afeqaW3FGmS62pMnlZXq qMIQoXr+fIo9Bs0TGPzCvlSGCcQDY+rIH0CdZg3CL/l3zIgLqOBUoVGpVxC/g7vXvuWs M8FpkE2adJd9diiX7qdDBiLLmM8Ffm1voKZTTnWiYsl68dU56Cb6uceVTqFsdwO/oglB wwgp/WuiyVoQ7SwWFvlJgH1WXbwQBbP8ixnM8pMCuqRXhMrmFW+sQLRGRP2k1Y1QUJo4 jPTIsHD2eNIN87HoH+f5QYoLWr/X/MdUyQkXKz2pkkJ4dcFTlQausO+L14qcSYwWta0L jE6w== X-Gm-Message-State: AOAM531obTTRobbIE0SP6dxmQEgdwzt+hYd8iiN8FMcp3DnrNNBpI/+j 4fqNgl0zMdp+IsVlxFBgumPaa728WVYdjeMkYT0= X-Google-Smtp-Source: ABdhPJyaAGVPpouD6+4c0X9g7Om4gYNuvHHHAZz1XRAJDS6J15YAQkJGGXF5yElCjvODLKS8wEOZWmwuFQJy6PMSeU0= X-Received: by 2002:a37:8084:: with SMTP id b126mr27636031qkd.175.1620180322530; Tue, 04 May 2021 19:05:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Tue, 4 May 2021 22:05:11 -0400 Message-ID: To: Randy Bush Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="00000000000098b91c05c18ba0fd" Archived-At: Subject: Re: [Sidrops] adopt draft-ymbk-sidrops-rpki-has-no-identity please X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 05 May 2021 02:05:28 -0000 --00000000000098b91c05c18ba0fd Content-Type: text/plain; charset="UTF-8" Helo, from the void: Jumping back in time quite a bit (btw, wednesday's Lotto number is 13!!) I think Randy asked for Adoption of this draft, the discussion here was long and useful (to me anyway), I think it shows that we should probably adopt the draft (which several folk actually also ack'd) and have more discussions about same. I note that at least Martin and Tim asked: "Should this draft be used as a method to set security considerations for other docs?" or: "Using this draft to identify the identity/uses/acceptable-uses of the RPKI could be useful and then we can have a better security considerations in our RTA/RSC drafts!" those both also seem useful to me. So, could the author(s) please reissue a renamed redraft of the draft here-in being discoursed? Also: $ diff /tmp/draft-ymbk-sidrops-rpki-has-no-identity-00.txt draft-ymbk-sidrops-rpki-has-no-identity-00.txt 98c98 < There is a desire to authenticate real world business transactions --- > There is a desire is to authenticate real world business transactions the department of redundancy department would prefer if you returned their 'is' to them, they are sad that you have taken an extra from the 'take one' jar ... -chris co-chair-persona NOTE: If you think you are being ignored or in particular I am taking to long, please use a bigger stick to get attention. often many fires are burning so... I may not get to this fire as quickly as one may want... I won't take offence to the beating. (or I'll try mighty hard to not take offence) On Thu, Mar 18, 2021 at 2:15 PM Randy Bush wrote: > i would request wg adoption of draft-ymbk-sidrops-rpki-has-no-identity. > a number of people are already wanting to tweak/tune/fix; and another > draft is already referencing it. > > thanks > > randy > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --00000000000098b91c05c18ba0fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Helo, from the void:
Jumping back in t= ime quite a bit (btw, wednesday's Lotto number is 13!!)
I think Randy asked for Adoption of this draft, the discussion her= e was long and
useful=C2=A0(to me anyway), I think it shows that = we should probably adopt the draft
(which several folk actually a= lso ack'd) and have more discussions about same.

I note t= hat at least Martin and Tim asked:
=C2=A0 "Should this draft be use= d as a method to set security considerations=C2=A0for other docs?"
or:
=C2=A0 "Using this draft to identify the identity/uses/a= cceptable-uses of the RPKI could be useful
=C2=A0 =C2=A0and then = we can have a better security considerations in our RTA/RSC drafts!"

those both also seem useful to me.

So, could= the author(s) please reissue a renamed redraft of the draft here-in being<= /div>
discoursed?

Also:
$ diff /tmp/draft-ymbk-sidrops-rpki-h= as-no-identity-00.txt draft-ymbk-sidrops-rpki-has-no-identity-00.txt
98c= 98
< =C2=A0 =C2=A0There is a desire to authenticate real world busine= ss transactions
---
> =C2=A0 =C2=A0There is a desire is to authent= icate real world business transactions

the dep= artment of redundancy department would prefer if you returned their 'is= ' to them, they are sad
that you have taken an extra from the= 'take one' jar ...=C2=A0

-chris
co-chair-persona

NOTE: If you think you are being= ignored or in particular I am taking to long, please
use a bigge= r stick to get attention. often many fires are burning so... I may not get = to this fire
as quickly as one may want... I won't take offen= ce to the beating. (or I'll try mighty hard to not take
offen= ce)


On Thu, Mar 18, 2021 at 2:15 PM Randy Bush <randy@psg.com> wrote:
i would request wg adoption of draft-ym= bk-sidrops-rpki-has-no-identity.
a number of people are already wanting to tweak/tune/fix; and another
draft is already referencing it.

thanks

randy

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--00000000000098b91c05c18ba0fd-- From nobody Tue May 4 19:36:28 2021 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 CB0083A1FF7 for ; Tue, 4 May 2021 19:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 XNk3sMgL2eV0 for ; Tue, 4 May 2021 19:36:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A88483A1FF5 for ; Tue, 4 May 2021 19:36:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1le7Od-0008De-8u; Wed, 05 May 2021 02:36:19 +0000 Date: Tue, 04 May 2021 19:36:18 -0700 Message-ID: From: Randy Bush To: Christopher Morrow Cc: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] adopt draft-ymbk-sidrops-rpki-has-no-identity please X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 05 May 2021 02:36:27 -0000 > So, could the author(s) please reissue a renamed redraft of the draft > here-in being done > < There is a desire to authenticate real world business transactions > --- > > There is a desire is to authenticate real world business transactions blech. next time randy From nobody Tue May 4 19:47:07 2021 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 8BFEB3A2052 for ; Tue, 4 May 2021 19:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 uJqb3dDYeJWG for ; Tue, 4 May 2021 19:47:03 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 4941E3A2056 for ; Tue, 4 May 2021 19:47:02 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id dl3so562933qvb.3 for ; Tue, 04 May 2021 19:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r1S26h3ksqUYaSuuMa+vq1yILc41x9OaEnSwZFXGrTs=; b=EwHYmb/muw1cA5i1Vb3KtWaASB1lpAtE87We9/PBEGAkw53dFSwJ/uCFFf7Zn34U+3 aAPJjNbggbNLgUEGkXsTO3fBX1AD8WfnkM8JU7DDNg4mJ1t/vTwFL2tZKOxTgUghnaKf sRONwrB18W8Oh6VwwKPL+A1X38Tim3WB1F+rfKOxb/TFRD2zK+Ur+Q3ZfqqaJuYRHgxu j4y1PJCtyUOlRP4QQ++2V7EqT3YM04VeYcK8wD0gHu6bz76fFzUpEqmzHl1U/Z1wCAWQ X3SJwHZqZrVzZAVnKSSelK+qmq6Il5K54Q1VdRhN1sSRwRK8r5QKne105NlbCo46PSBS h8iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r1S26h3ksqUYaSuuMa+vq1yILc41x9OaEnSwZFXGrTs=; b=VHWqxyidNCPUc2dERuMIRrrQA07dsuQLWR0DAjCO8aYSYyafW93jHQtjoCdrrGqMZ1 I1kPZEfGVXqGpupLfmjYVaju8NCl2qaCFdUU49BloyPVZaC1jUZo49Sn5Id0vUWmZycF CUkqWqB3TnCLdQlxf/9lbsdseiCIyCztDTXHhWWJMG01oElQ3MbfyQ4v+JeAh9jE4aI2 94TyK6MsLr0MaaoX3J4u0MCc8/0ycekZL70YbIGPgpguhOpstEQrf6HtmFGsqpOWX1Na D8/NxWXepdTqclrM8BDi1Fs/Ch780nrE3gB61dXsWcNXfcqdkB1kqqCPkp0ShV12uTGL SK9w== X-Gm-Message-State: AOAM530qTjGH9dDBJ0FhGh2QNyq7Ahq64Wz4J6eRR72hEVpb8fLRDAV/ 57QQw7YgNMZS60jxREfVpsFl5vhRnqDh5lpofK83nlyraQk= X-Google-Smtp-Source: ABdhPJzR8SzO0Q3//7so87l4ZAGOL3IxKodDHXIa+JK5dxYh5xwUuAxy8qmrQnbq/gS2HtX63Mi29cKC2kcx+OSqqdY= X-Received: by 2002:ad4:4441:: with SMTP id l1mr28208846qvt.1.1620182817431; Tue, 04 May 2021 19:46:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Tue, 4 May 2021 22:46:46 -0400 Message-ID: To: Randy Bush Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="0000000000004de32705c18c355b" Archived-At: Subject: Re: [Sidrops] adopt draft-ymbk-sidrops-rpki-has-no-identity please X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 05 May 2021 02:47:06 -0000 --0000000000004de32705c18c355b Content-Type: text/plain; charset="UTF-8" On Tue, May 4, 2021 at 10:36 PM Randy Bush wrote: > > So, could the author(s) please reissue a renamed redraft of the draft > > here-in being > > done > thanks! > > > < There is a desire to authenticate real world business transactions > > --- > > > There is a desire is to authenticate real world business > transactions > > blech. next time > > > randy > --0000000000004de32705c18c355b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 4, 2021 at 10:36 PM Randy= Bush <randy@psg.com> wrote:
=
> So, could the = author(s) please reissue a renamed redraft of the draft
> here-in being

done

thanks!
=C2=A0

> <=C2=A0 =C2=A0 There is a desire to authenticate real world busines= s transactions
> ---
> >=C2=A0 =C2=A0 There is a desire is to authenticate real world busi= ness transactions

blech.=C2=A0 next time


<shakeyfist>
=C2=A0
randy
--0000000000004de32705c18c355b-- From nobody Tue May 4 20:57:40 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CB13A22AC; Tue, 4 May 2021 20:57:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <162018705402.22047.6475531442605798117@ietfa.amsl.com> Date: Tue, 04 May 2021 20:57:34 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-has-no-identity-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 03:57:34 -0000 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 : The I in RPKI does not stand for Identity Authors : Randy Bush Russ Housley Filename : draft-ietf-sidrops-rpki-has-no-identity-00.txt Pages : 6 Date : 2021-05-04 Abstract: There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real world identity of the 'owner' of an INR. This document attempts to put that notion to rest. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-has-no-identity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rpki-has-no-identity-00 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-has-no-identity-00 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 nobody Mon May 10 16:15:01 2021 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 02BFD3A2EA8 for ; Mon, 10 May 2021 16:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 NEpc_csImq36 for ; Mon, 10 May 2021 16:14:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 7BBE73A2EA3 for ; Mon, 10 May 2021 16:14:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1lgF6p-00060I-4p for sidrops@ietf.org; Mon, 10 May 2021 23:14:43 +0000 Date: Mon, 10 May 2021 16:14:42 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 10 May 2021 23:15:00 -0000 hi folk, what do i need to work on here before whining about wglc? some solid constructive wg reviewers would be great. [ sad to say, two other (not sidrops) drafts did not get real review until ietf last call. ] randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery From nobody Mon May 10 16:19:53 2021 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 747783A2EC2 for ; Mon, 10 May 2021 16:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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=algebras-org.20150623.gappssmtp.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 xL9z5pztwjxj for ; Mon, 10 May 2021 16:19:46 -0700 (PDT) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 BB4193A2EC0 for ; Mon, 10 May 2021 16:19:46 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id bo23-20020a17090b0917b029015cb1f2fd59so235080pjb.2 for ; Mon, 10 May 2021 16:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h86cVCVJj/qJgVCxVm2MF/X+oGyaBzbCvZ0LOL+XrkA=; b=1RYmSABRpVKMsDw5pC+8xu0mKc40Jhz2JuF1NGhP9/656RO84Oi9orsgQdIEjhbNHU h3GwTr+bkoBDXYkHBbrg41+PWNcIGPU7L/AIfyBGj+BJQBhUf3+/6qy++9fOW+FYNMy5 Y/RnWv98jiLdHa6nlz16w/aQiyuz44aotSe6NUccJSiw6WqEKapqehesbwl4VazmNNqx K2g+vFJJ6fBg36riZuPUPCBjYIk4+riUUrrxGqTgPDVe2tzKM8WlDtCyRE0a50mSb2AN gjnuVHK8iyiowUYvhPjdvli2+630HwKix583ucNr0KePyZ7iuQLeIzILkMPUVrQ8o6tB PgFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h86cVCVJj/qJgVCxVm2MF/X+oGyaBzbCvZ0LOL+XrkA=; b=Eu32k06PVNao+xCOQ3IsnWhrbjni/EgMuU89WviQOTNEZdO0ExREeWmRW4JW7S8k6B P7Z6GcGYkKSICFQnn6c4KjjdW5C6H8RBE0ZRK8vGptmD+c+tC9z5wF+J++saQztiLSV4 Us5sBTPhlsNnbp0M8AdGKUrFHQFH89Bq0geThdwBHOiQ07Ljk1Ab4Sp/A4XikoM+3JL6 sikyHg9MLN/Al+Arlwri+Bh3a6rSIV1P9myOHl19pjoBn+HzoBmgAbjqjuKAI/TIkrVa m7E+UvuGD5RqDCMBpp2T+PFWk9DnpuPoga0/L0G/nTpR0gGvtHh6NUo0g5BjKdAlnFCh F+hQ== X-Gm-Message-State: AOAM532i88dd7irQ9U5ydNjrk4Qx6eghSWiNqwqvbrLNkVH2vlHfd4dO dNRRhKWsxnes0secTxy7vZ6ea2C52OSG6tdcye9ntds2ViQK0Q== X-Google-Smtp-Source: ABdhPJxoZ6IWrebhk72KHJ7Bz5M8XyGD+PrRl+g9cROcgF4lpMQYd/Fsf3gN2qzVe1PrHuxM3Uxz+SQIZhs+AtsTBkY= X-Received: by 2002:a17:902:e986:b029:ee:d430:6bf9 with SMTP id f6-20020a170902e986b02900eed4306bf9mr27331498plb.0.1620688784788; Mon, 10 May 2021 16:19:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: George Michaelson Date: Tue, 11 May 2021 09:19:33 +1000 Message-ID: To: Randy Bush Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 10 May 2021 23:19:52 -0000 I'd like the draft to at least address the idea you could cross sign. Not that the RPKI cert can formally validate the identity, but there is no implicit barrier to using it to countersign, or cosign a structure, saying something like this: If another mechanism can provide positive proof (eg an x509 identity certificate which lies under a non-RPKI TA you trust) then there is no barrier to countersigning an assertion over that proof (the public key and a nonce, for example) binding the INR you can validate inside the RPKI, and an identity which lies outside the RPKI. and No part of the RPKi validation can "prove" the identity in the signing. What it can do, is relate the INR in RPKI, to a specific assertion about identity. Validation of that assertion is not subject to RPKI validation. Validation of the INR which is being associated, is a function of the RPKI -G On Tue, May 11, 2021 at 9:15 AM Randy Bush wrote: > > hi folk, > > what do i need to work on here before whining about wglc? some solid > constructive wg reviewers would be great. > > [ sad to say, two other (not sidrops) drafts did not get real review > until ietf last call. ] > > randy > > --- > randy@psg.com > `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` > signatures are back, thanks to dmarc header butchery > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon May 10 17:03:47 2021 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 070753A3010 for ; Mon, 10 May 2021 17:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 JiE-EVcSbiaH for ; Mon, 10 May 2021 17:03:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 717DE3A300E for ; Mon, 10 May 2021 17:03:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1lgFs9-00068E-Vx; Tue, 11 May 2021 00:03:38 +0000 Date: Mon, 10 May 2021 17:03:37 -0700 Message-ID: From: Randy Bush To: George Michaelson Cc: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 00:03:45 -0000 > If another mechanism can provide positive proof (eg an x509 identity > certificate which lies under a non-RPKI TA you trust) then there is no > barrier to countersigning an assertion over that proof (the public key > and a nonce, for example) binding the INR you can validate inside the > RPKI, and an identity which lies outside the RPKI. > > and > > No part of the RPKi validation can "prove" the identity in the > signing. What it can do, is relate the INR in RPKI, to a specific > assertion about identity. Validation of that assertion is not subject > to RPKI validation. Validation of the INR which is being associated, > is a function of the RPKI are you trying to say the owner of some j random inr is attesting to some identity binding in some k random pki? maybe a concrete example would help me wrap what is left of my head around this. there exists an rpki cert attesting to a holding of 192.83.230.0/24. iij has a corporate x.509-based employee database in which i have a cert. so the unknown owner of 192.83.230.0/24 cross-signs (let's leave out the ugnlies) my iij cert. what is the real world meaning of this? in few small words. or, what is the meaning if i cross-sign the cert for 203.119.101.18 from iij? what are the attestations and what is the trust? randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery From nobody Mon May 10 17:51:08 2021 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 894773A3176 for ; Mon, 10 May 2021 17:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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=algebras-org.20150623.gappssmtp.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 DZE5G5AZBcJ1 for ; Mon, 10 May 2021 17:51:00 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 91D7F3A3177 for ; Mon, 10 May 2021 17:51:00 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id e11so9482786ljn.13 for ; Mon, 10 May 2021 17:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pJKP+27qHOKEPzsJv//VYWKGDewxT+S8wC+yG2g4mxQ=; b=BGkfxbyvMD5HoGI0g0SHVpRwILOaAI/ynOO9/GiRzrSQ4yuTInPi0Xotn/pEE/z0Kv TEb3YFuAh+Y68FrFejwLd/5gAbqzyyIvho9sbcap4JK6A/FFDPpqNgzxmWatAVfAoYS1 J+j5p7OTCB43iWkO3s5I1mll4OwcoZvBz9C0I/DxH5Bk50+YMOGZ5yIHDkbkX0DJ8VV7 CNOvvuCwfihLINKg8bxwDrvBchfubVvAb5X6ON6QwFtn1kmDdAP9yidK6suXXhw1CHE4 kwAVx0MKcqC1P6cDhwZTF8wV4FRn59hpalWFZky3901OnmTzuf1GSqI0Rd7LEMqOHnEz VndA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pJKP+27qHOKEPzsJv//VYWKGDewxT+S8wC+yG2g4mxQ=; b=ub5IxlK4xx5lQGePbL63TJryrf4BReY2PFZELnVI8iTtvFY9yVn3SwTEYazVn1yHA+ e5FswaQdyvIp8H9NIWtv8MlafOr1HCm121d1qgJyP8BEf/2WQCtjg97wtVzgaUVISFP5 ecU4Uc9u0bgMx27danqhYSqcnUFneWatmVaX44W//8GkhmzsSmHNe4kth2S2ZHaFRByE hjyUpltkRLj3bUpDYNaKP8gz38O8GkS+gCdMH4gpJo3N1ew2EfykUABNXKblhoT10c2B CbKTm6GjlH97SXsZd1fStzTGV+cddONlJd+kT5iveb8sKxIQ3xVWMqdJduPVZSgv1acC 8Dxw== X-Gm-Message-State: AOAM533qUzrpX1I7gmubv2XqqYavIa1MlNQPEH6xU6qi6dRYhgeww1vL /pULprbYsvkrg9D3xWRBDzO73Uj867H+phLXnw62SxYpFo3Inw== X-Google-Smtp-Source: ABdhPJy+aTiaM+KCpYx23VfRGzw+BLiD2OYXsn+eMKbvaX7qO71v9qtlBRA0usmty8dEwnzhBbDXAusdlIKhcPJseo8= X-Received: by 2002:a2e:a7c8:: with SMTP id x8mr1708263ljp.209.1620694257339; Mon, 10 May 2021 17:50:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: George Michaelson Date: Tue, 11 May 2021 10:50:46 +1000 Message-ID: To: Randy Bush Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 00:51:07 -0000 holder of RPKI cert over 192.83.230.0/24 creates a nonce, and communicates it OOB to cert holder in "iij has a corporate x.509-based employee database" using their public key: this is private, only can be decoded by private keyholder. the specific person, they sign "I saw nonce" with IIJ corp cert private key. they hand it back to RPKI cert person. holder of RPKI cert validates: yep: under the IIJ TA they signed over the nonce I gave them. This private key, it is the one I passed the nonce to, no matter how indirect that happened, it wound up being a chain from the nonce to the Private Key. If you care, you need to communicate the nonce over some secure channel, but its out of band. You sent them a thing only the bPKI private key holder can decode, they sent you back a reply only the bPKI private keyholder can encode. you then sign over some other assertion, saying "I did a nonce check, and this private key here, which IIJ says is employee X, they seem to check out." with the INR you want to associate. Your RPKI sign, can only validate you control the INR. if you use either RTA or RSC, you co-validate the hash of >some other assertion< but only in X509 cryptographic sense: the hash is asserted to be valid, under the constraint it was signed over by this specific RPKI INR. You cannot validate the >applicability< of that hash, it lies outside the RPKI validation model. neither PKI has to breach its own validation policy. They only ever apply to validate the property of "which INR is associated with the specific assert being made here" for RPKI validation and "which identity, outside of RPKI, is being asserted here" for bPKI validation. why did you trust the bPKI in the first place? You have a TA. Thats what TA do: they tell you to trust things. This isn't an RPKI TA, its a bPKI TA. I can imagine somebody is whispering PGP at this point. -G On Tue, May 11, 2021 at 10:03 AM Randy Bush wrote: > > > If another mechanism can provide positive proof (eg an x509 identity > > certificate which lies under a non-RPKI TA you trust) then there is no > > barrier to countersigning an assertion over that proof (the public key > > and a nonce, for example) binding the INR you can validate inside the > > RPKI, and an identity which lies outside the RPKI. > > > > and > > > > No part of the RPKi validation can "prove" the identity in the > > signing. What it can do, is relate the INR in RPKI, to a specific > > assertion about identity. Validation of that assertion is not subject > > to RPKI validation. Validation of the INR which is being associated, > > is a function of the RPKI > > are you trying to say > > the owner of some j random inr is attesting to some identity binding > in some k random pki? > > maybe a concrete example would help me wrap what is left of my head > around this. > > there exists an rpki cert attesting to a holding of 192.83.230.0/24. > iij has a corporate x.509-based employee database in which i have a > cert. so the unknown owner of 192.83.230.0/24 cross-signs (let's > leave out the ugnlies) my iij cert. what is the real world meaning of > this? in few small words. > > or, what is the meaning if i cross-sign the cert for 203.119.101.18 > from iij? > > what are the attestations and what is the trust? > > randy > > --- > randy@psg.com > `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` > signatures are back, thanks to dmarc header butchery From nobody Tue May 11 07:20:33 2021 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 DE0CF3A1982 for ; Tue, 11 May 2021 07:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 1ogisc-w6iaZ for ; Tue, 11 May 2021 07:20:27 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B273A197F for ; Tue, 11 May 2021 07:20:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2FF4C300BDE for ; Tue, 11 May 2021 10:20:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id st8s0yC73m59 for ; Tue, 11 May 2021 10:20:19 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 9F2FD300B38; Tue, 11 May 2021 10:20:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) From: Russ Housley In-Reply-To: Date: Tue, 11 May 2021 10:20:17 -0400 Cc: Randy Bush , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <4455A207-2637-444B-BDA0-1209425C2EF2@vigilsec.com> References: To: George Michaelson X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 14:20:32 -0000 George: I am confused. The RPKI design purposely avoids binding IIJ's identity = to the resources assigned to IIJ. What kind of assertions need two = signatures, one that ca be validated with an RPKI certificate and the = other can be validated with a certificate from an identity-confirming = PKI? Russ > On May 10, 2021, at 8:50 PM, George Michaelson = wrote: >=20 > holder of RPKI cert over 192.83.230.0/24 creates a nonce, and > communicates it OOB to cert holder in "iij has a corporate x.509-based > employee database" using their public key: this is private, only can > be decoded by private keyholder. >=20 > the specific person, they sign "I saw nonce" with IIJ corp cert > private key. they hand it back to RPKI cert person. >=20 > holder of RPKI cert validates: yep: under the IIJ TA they signed over > the nonce I gave them. This private key, it is the one I passed the > nonce to, no matter how indirect that happened, it wound up being a > chain from the nonce to the Private Key. If you care, you need to > communicate the nonce over some secure channel, but its out of band. >=20 > You sent them a thing only the bPKI private key holder can decode, > they sent you back a reply only the bPKI private keyholder can encode. >=20 > you then sign over some other assertion, saying "I did a nonce check, > and this private key here, which IIJ says is employee X, they seem to > check out." with the INR you want to associate. Your RPKI sign, can > only validate you control the INR. if you use either RTA or RSC, you > co-validate the hash of >some other assertion< but only in X509 > cryptographic sense: the hash is asserted to be valid, under the > constraint it was signed over by this specific RPKI INR. You cannot > validate the >applicability< of that hash, it lies outside the RPKI > validation model. >=20 > neither PKI has to breach its own validation policy. They only ever > apply to validate the property of "which INR is associated with the > specific assert being made here" for RPKI validation and "which > identity, outside of RPKI, is being asserted here" for bPKI > validation. >=20 > why did you trust the bPKI in the first place? You have a TA. Thats > what TA do: they tell you to trust things. This isn't an RPKI TA, its > a bPKI TA. I can imagine somebody is whispering PGP at this point. >=20 > -G >=20 >=20 > On Tue, May 11, 2021 at 10:03 AM Randy Bush wrote: >>=20 >>> If another mechanism can provide positive proof (eg an x509 identity >>> certificate which lies under a non-RPKI TA you trust) then there is = no >>> barrier to countersigning an assertion over that proof (the public = key >>> and a nonce, for example) binding the INR you can validate inside = the >>> RPKI, and an identity which lies outside the RPKI. >>>=20 >>> and >>>=20 >>> No part of the RPKi validation can "prove" the identity in the >>> signing. What it can do, is relate the INR in RPKI, to a specific >>> assertion about identity. Validation of that assertion is not = subject >>> to RPKI validation. Validation of the INR which is being associated, >>> is a function of the RPKI >>=20 >> are you trying to say >>=20 >> the owner of some j random inr is attesting to some identity binding >> in some k random pki? >>=20 >> maybe a concrete example would help me wrap what is left of my head >> around this. >>=20 >> there exists an rpki cert attesting to a holding of 192.83.230.0/24. >> iij has a corporate x.509-based employee database in which i have a >> cert. so the unknown owner of 192.83.230.0/24 cross-signs (let's >> leave out the ugnlies) my iij cert. what is the real world meaning = of >> this? in few small words. >>=20 >> or, what is the meaning if i cross-sign the cert for 203.119.101.18 >> from iij? >>=20 >> what are the attestations and what is the trust? >>=20 >> randy >>=20 >> --- >> randy@psg.com >> `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` >> signatures are back, thanks to dmarc header butchery >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue May 11 07:38:27 2021 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 7DFFA3A1A07 for ; Tue, 11 May 2021 07:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=nlnetlabs.nl 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 yc_Lu8albpzk for ; Tue, 11 May 2021 07:38:19 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.218]) (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 609CA3A1A03 for ; Tue, 11 May 2021 07:38:18 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id C1BEB60561; Tue, 11 May 2021 14:38:15 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1620743893; bh=7P691vb0yGNTfQBi95nToNQl2xHkZsbzN+zkPf9NFK8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Ko2iV409b2nFxQcm//XdcidZOHcy3zHfEPUt9xozl2em03gI0VpiNiixafGm0u+LS h3renWySf8M0SMUBHAua//ASQoc9s4+To3ztSRx+dQ2QX4H0dkwHxC+xP7xPIXpTe7 QhIwVngYK5M6JB0k1rqLx9BSoi2DmXZUI2TS7hgVbvDOrhmPPMgjxdLC73tSDBt/uc I/yBWJotNsMVI2NqKLfpvqd8thjx2E5PLWuLv9TiPnFHOUNWHSkbK9/kQj+6LTOwU/ aic9TGcEvs9qfWoIOuF7C99E52Ti7VkPQuuIl+N9gUHhhuNXCUIls5d0Eh0emY05Ub wwmg/BdwgNPZg== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Tim Bruijnzeels In-Reply-To: <4455A207-2637-444B-BDA0-1209425C2EF2@vigilsec.com> Date: Tue, 11 May 2021 16:38:09 +0200 Cc: George Michaelson , Randy Bush , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <2D988AA2-7860-4F5E-B9D4-87A747A39FD2@nlnetlabs.nl> References: <4455A207-2637-444B-BDA0-1209425C2EF2@vigilsec.com> To: Russ Housley Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 14:38:26 -0000 Russ, all, > On 11 May 2021, at 16:20, Russ Housley wrote: >=20 > George: >=20 > I am confused. The RPKI design purposely avoids binding IIJ's = identity to the resources assigned to IIJ. What kind of assertions need = two signatures, one that ca be validated with an RPKI certificate and = the other can be validated with a certificate from an = identity-confirming PKI? I believe that the main point here is that a parent RPKI CA does not = attest to the identity of a child. It just associates INRs to $their = public key. However, with RSC/RTA the operator of that child CA could then sign an = attestation containing anything else, including a public B-PKI key that = they may wish to associate with their INRs in specific use cases. At least that is how understood George's words. Please correct me if I = misunderstood George :) Tim >=20 > Russ >=20 >=20 >> On May 10, 2021, at 8:50 PM, George Michaelson = wrote: >>=20 >> holder of RPKI cert over 192.83.230.0/24 creates a nonce, and >> communicates it OOB to cert holder in "iij has a corporate = x.509-based >> employee database" using their public key: this is private, only can >> be decoded by private keyholder. >>=20 >> the specific person, they sign "I saw nonce" with IIJ corp cert >> private key. they hand it back to RPKI cert person. >>=20 >> holder of RPKI cert validates: yep: under the IIJ TA they signed over >> the nonce I gave them. This private key, it is the one I passed the >> nonce to, no matter how indirect that happened, it wound up being a >> chain from the nonce to the Private Key. If you care, you need to >> communicate the nonce over some secure channel, but its out of band. >>=20 >> You sent them a thing only the bPKI private key holder can decode, >> they sent you back a reply only the bPKI private keyholder can = encode. >>=20 >> you then sign over some other assertion, saying "I did a nonce check, >> and this private key here, which IIJ says is employee X, they seem to >> check out." with the INR you want to associate. Your RPKI sign, can >> only validate you control the INR. if you use either RTA or RSC, you >> co-validate the hash of >some other assertion< but only in X509 >> cryptographic sense: the hash is asserted to be valid, under the >> constraint it was signed over by this specific RPKI INR. You cannot >> validate the >applicability< of that hash, it lies outside the RPKI >> validation model. >>=20 >> neither PKI has to breach its own validation policy. They only ever >> apply to validate the property of "which INR is associated with the >> specific assert being made here" for RPKI validation and "which >> identity, outside of RPKI, is being asserted here" for bPKI >> validation. >>=20 >> why did you trust the bPKI in the first place? You have a TA. Thats >> what TA do: they tell you to trust things. This isn't an RPKI TA, its >> a bPKI TA. I can imagine somebody is whispering PGP at this point. >>=20 >> -G >>=20 >>=20 >> On Tue, May 11, 2021 at 10:03 AM Randy Bush wrote: >>>=20 >>>> If another mechanism can provide positive proof (eg an x509 = identity >>>> certificate which lies under a non-RPKI TA you trust) then there is = no >>>> barrier to countersigning an assertion over that proof (the public = key >>>> and a nonce, for example) binding the INR you can validate inside = the >>>> RPKI, and an identity which lies outside the RPKI. >>>>=20 >>>> and >>>>=20 >>>> No part of the RPKi validation can "prove" the identity in the >>>> signing. What it can do, is relate the INR in RPKI, to a specific >>>> assertion about identity. Validation of that assertion is not = subject >>>> to RPKI validation. Validation of the INR which is being = associated, >>>> is a function of the RPKI >>>=20 >>> are you trying to say >>>=20 >>> the owner of some j random inr is attesting to some identity binding >>> in some k random pki? >>>=20 >>> maybe a concrete example would help me wrap what is left of my head >>> around this. >>>=20 >>> there exists an rpki cert attesting to a holding of 192.83.230.0/24. >>> iij has a corporate x.509-based employee database in which i have a >>> cert. so the unknown owner of 192.83.230.0/24 cross-signs (let's >>> leave out the ugnlies) my iij cert. what is the real world meaning = of >>> this? in few small words. >>>=20 >>> or, what is the meaning if i cross-sign the cert for 203.119.101.18 >>> from iij? >>>=20 >>> what are the attestations and what is the trust? >>>=20 >>> randy >>>=20 >>> --- >>> randy@psg.com >>> `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` >>> signatures are back, thanks to dmarc header butchery >>=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 From nobody Tue May 11 07:46:13 2021 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 6732B3A1A5A for ; Tue, 11 May 2021 07:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 TI6g5c2iS_22 for ; Tue, 11 May 2021 07:45:58 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA723A1A4C for ; Tue, 11 May 2021 07:45:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B4483300BE3 for ; Tue, 11 May 2021 10:45:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Xxi6-8Zpig6e for ; Tue, 11 May 2021 10:45:51 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 067BA300B38; Tue, 11 May 2021 10:45:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) From: Russ Housley In-Reply-To: <2D988AA2-7860-4F5E-B9D4-87A747A39FD2@nlnetlabs.nl> Date: Tue, 11 May 2021 10:45:49 -0400 Cc: Randy Bush , SIDR Operations WG , George Michaelson Content-Transfer-Encoding: quoted-printable Message-Id: <41914016-4496-4FBC-A753-9481CAEDD231@vigilsec.com> References: <4455A207-2637-444B-BDA0-1209425C2EF2@vigilsec.com> <2D988AA2-7860-4F5E-B9D4-87A747A39FD2@nlnetlabs.nl> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 14:46:12 -0000 Tim: >> I am confused. The RPKI design purposely avoids binding IIJ's = identity to the resources assigned to IIJ. What kind of assertions need = two signatures, one that ca be validated with an RPKI certificate and = the other can be validated with a certificate from an = identity-confirming PKI? >=20 > I believe that the main point here is that a parent RPKI CA does not = attest to the identity of a child. It just associates INRs to $their = public key. >=20 > However, with RSC/RTA the operator of that child CA could then sign an = attestation containing anything else, including a public B-PKI key that = they may wish to associate with their INRs in specific use cases. >=20 > At least that is how understood George's words. Please correct me if I = misunderstood George :) I think that RSC/RTA are saying that the holder of an INR has signed a = statement. The identity is not important in that context. The fact = that the are the holder of that INR is waht is important to validate the = signed statement. Russ From nobody Tue May 11 07:47:05 2021 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 194873A1A6E for ; Tue, 11 May 2021 07:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 2LZHfDO-0j3P for ; Tue, 11 May 2021 07:46:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 143543A1A68 for ; Tue, 11 May 2021 07:46:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1lgTep-0002eZ-Mu; Tue, 11 May 2021 14:46:48 +0000 Date: Tue, 11 May 2021 07:46:47 -0700 Message-ID: From: Randy Bush To: George Michaelson Cc: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 14:47:04 -0000 this confuses me even further. perhaps less words would help. > holder of RPKI cert over 192.83.230.0/24 creates a nonce, and > communicates it OOB to cert holder in "iij has a corporate x.509-based > employee database" using their public key: this is private, only can > be decoded by private keyholder. > > the specific person, they sign "I saw nonce" with IIJ corp cert > private key. they hand it back to RPKI cert person. > > holder of RPKI cert validates: yep: under the IIJ TA they signed over > the nonce I gave them. This private key, it is the one I passed the > nonce to, no matter how indirect that happened, it wound up being a > chain from the nonce to the Private Key. If you care, you need to > communicate the nonce over some secure channel, but its out of band. > > You sent them a thing only the bPKI private key holder can decode, > they sent you back a reply only the bPKI private keyholder can encode. near as i can tell, this was three paragraphs describing a classic nonce exchange to demonstrate proof of possession of a private key (see, i can use important words too:). what am i missing? > you then sign over some other assertion, saying "I did a nonce check, > and this private key here, which IIJ says is employee X, they seem to > check out." with the INR you want to associate. eh what? "this private key here, which IIJ says is employee X?" there ain't no here here. no one has that *private* key except the iij employee. > Your RPKI sign, can only validate you control the INR. if you use > either RTA or RSC, you co-validate the hash of>some other assertion< > but only in X509 cryptographic sense: the hash is asserted to be > valid, under the constraint it was signed over by this specific RPKI > INR. You cannot validate the>applicability< of that hash, it lies > outside the RPKI validation model. a lot of words to say the INR holder can use hacks to sign some hash? a hash of what? > neither PKI has to breach its own validation policy. i suspect that A has to validate B certs up to B's TA which A got by magic. unless you want to add validation signaling; which i suggest that you not do. and how does A know that B has not taken some weird validation altering drug? but let's ignore that and assume we're in drug free normal X.509 world; sorry i could not resist. > They only ever apply to validate the property of "which INR is > associated with the specific assert being made here" for RPKI > validation and "which identity, outside of RPKI, is being asserted > here" for bPKI validation. dragging the bpki in confounds things even further. do you really mean the bpki used to assure the rpki left/right and up/down communication? > why did you trust the bPKI in the first place? You have a TA. Thats > what TA do: they tell you to trust things. This isn't an RPKI TA, its > a bPKI TA. I can imagine somebody is whispering PGP at this point. i thought i knew what an x.509 TA was. though this conversation could start to alter that assurance. >> what is the real world meaning of this? in few small words. what i was hoping for was something such as "this means randy from iij must be the owner of 192.83.230.0/24 and can say authorative things about it by showing you his iij identity badge." or "the owner of 192.83.230.0/24 can speak for randy from iij." but i do not see that you have made that leap; likely due to my being too easily confused. randy From nobody Tue May 11 07:52:55 2021 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 883043A1A51 for ; Tue, 11 May 2021 07:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=nlnetlabs.nl 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 lDdjqBcBZWoR for ; Tue, 11 May 2021 07:52:49 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::218]) (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 E94283A1A5F for ; Tue, 11 May 2021 07:52:47 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 49624601F3; Tue, 11 May 2021 14:52:46 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1620744765; bh=Lc380oECSrFEf/CzErleB7EMjFb8RQtP7B6eak9tv6Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=OEhzyR+tvH5CIZum5HkSObnc6k0x95OE1U5Gha/c6HCTp5VzpmEOiIrBHHAV3Yqvz h84/yP61Kty3lnpc0lyhRxiOFRhCmb65u95a6WjujUmt4651ieya2ahnWEKD+SqULf u2E24r+o0HjxOU4FEkPmDNsRK19IpKwBIpzObRqvBYMTgPOSifGiuj5e6uLeEIp6JB mlX2FJGtlrdITdF/tVL684Omjwug74ku+5KSxkhiApHzMqAlX02buvV683g3nL6fFS PZ2O0QFXAwkeU+oCTbMlYsSFM92F/yTpDu2zlLv9gtDHzbu2sJEAskDYIKWGCnlEp1 9Qbya2w2fQSfw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Tim Bruijnzeels In-Reply-To: <41914016-4496-4FBC-A753-9481CAEDD231@vigilsec.com> Date: Tue, 11 May 2021 16:52:41 +0200 Cc: Randy Bush , SIDR Operations WG , George Michaelson Content-Transfer-Encoding: quoted-printable Message-Id: References: <4455A207-2637-444B-BDA0-1209425C2EF2@vigilsec.com> <2D988AA2-7860-4F5E-B9D4-87A747A39FD2@nlnetlabs.nl> <41914016-4496-4FBC-A753-9481CAEDD231@vigilsec.com> To: Russ Housley Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 14:52:55 -0000 Russ: > On 11 May 2021, at 16:45, Russ Housley wrote: >=20 > Tim: >=20 >>> I am confused. The RPKI design purposely avoids binding IIJ's = identity to the resources assigned to IIJ. What kind of assertions need = two signatures, one that ca be validated with an RPKI certificate and = the other can be validated with a certificate from an = identity-confirming PKI? >>=20 >> I believe that the main point here is that a parent RPKI CA does not = attest to the identity of a child. It just associates INRs to $their = public key. >>=20 >> However, with RSC/RTA the operator of that child CA could then sign = an attestation containing anything else, including a public B-PKI key = that they may wish to associate with their INRs in specific use cases. >>=20 >> At least that is how understood George's words. Please correct me if = I misunderstood George :) >=20 > I think that RSC/RTA are saying that the holder of an INR has signed a = statement. The identity is not important in that context. The fact = that the are the holder of that INR is waht is important to validate the = signed statement. Indeed, I think we are saying the same thing. What I am saying, and understanding George to say, is that data part in = the signed statement can _contain_ identity information. Such as a B-PKI = public key, or public PGP key, to be used in out of band communications = about the resources. But again George, if I misunderstood you correct me.. Tim >=20 > Russ >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue May 11 07:55:29 2021 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 648693A1A7E for ; Tue, 11 May 2021 07:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 aUfmLSk2NpSm for ; Tue, 11 May 2021 07:55:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 5749D3A1A77 for ; Tue, 11 May 2021 07:55:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1lgTn9-0002gp-Fq; Tue, 11 May 2021 14:55:23 +0000 Date: Tue, 11 May 2021 07:55:23 -0700 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: SIDR Operations WG In-Reply-To: References: <4455A207-2637-444B-BDA0-1209425C2EF2@vigilsec.com> <2D988AA2-7860-4F5E-B9D4-87A747A39FD2@nlnetlabs.nl> <41914016-4496-4FBC-A753-9481CAEDD231@vigilsec.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 14:55:28 -0000 aside: "BPKI" has meaning in the RPKI internal protocols. i have come to strongly suspect you are accidentally reusing this keyword for other meanings. randy From nobody Tue May 11 08:03:52 2021 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 F30C33A1ACA for ; Tue, 11 May 2021 08:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=nlnetlabs.nl 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 vIQ_oc-nc0Gc for ; Tue, 11 May 2021 08:03:40 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.218]) (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 079E13A1AC1 for ; Tue, 11 May 2021 08:03:39 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 0AC7B60134; Tue, 11 May 2021 15:03:37 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1620745416; bh=5J2k6KTUJF67eW/Snt7zI3iMOu+Gb6+30cx0hCiLSWw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=f1gb5PxGHtndtWEPo0KX29g2AA+IiUfyYTheqt3VDYS03ConBgYSeME6eFV/h5tMM 6/6gwIcVDm743QhhUoz3Z6XSYftTA6XzdrB51F5rv+VzyP8zcfqB9sVB82K0h+/N8J 3xqzCtmObI/PHTbLOSzrAXX5+6PW4IUAB1PjRld/W8KggTO6hY3PsoKS8P2MRrmsoh JVCrNl9PeUlY6eNXhg25kIAys3jbeUazcma9P2rTl9R58DvZMELfvM8P9T9QHeUt6J TJ726kiUou2jlI+N3goGMShN1rIgc6DWxiL/72pvGJFkyp053EUtR8ZLXDRqpG2BY8 ZuqtLX/yuLxGg== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 11 May 2021 17:03:33 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <0F69F473-EDC3-4038-A6E8-E0971DB96A2B@nlnetlabs.nl> References: <4455A207-2637-444B-BDA0-1209425C2EF2@vigilsec.com> <2D988AA2-7860-4F5E-B9D4-87A747A39FD2@nlnetlabs.nl> <41914016-4496-4FBC-A753-9481CAEDD231@vigilsec.com> To: Randy Bush Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 15:03:46 -0000 > On 11 May 2021, at 16:55, Randy Bush wrote: >=20 > aside: "BPKI" has meaning in the RPKI internal protocols. i have come > to strongly suspect you are accidentally reusing this keyword for = other > meanings. I agree. BPKI is used in the context of provisioning (6492), publication (8181) = and the out-of-band identity exchanges (8183). We may not want to use the term in this context, or if we do then with = proper clarity. This is not about the above RPKI internals. Tim >=20 > randy >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue May 11 09:18:56 2021 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 45F9F3A1D11 for ; Tue, 11 May 2021 09:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 2Q7WIaIYlDO8 for ; Tue, 11 May 2021 09:18:50 -0700 (PDT) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 D8CB93A1C8C for ; Tue, 11 May 2021 09:18:49 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id t4so30700092ejo.0 for ; Tue, 11 May 2021 09:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=iStTgO94h/HCeVxnae3mF4Thl1yqou3bpxytl4ElKBI=; b=T0W3zdIUDMq4YZdCzJiOxM4sT1P556nV18WyfV2Q54r6Iiil40SUwUwTMEb5lGSx9T igP93BwNO02+rNa7adwtGzV6F29tnchXmylIgfk1XifNRMUEtODAoUf0FMRjZU0x5hUG DOUrIqelK+cSyl/BTkIE237YCmkQAjmafYZlg= 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:in-reply-to; bh=iStTgO94h/HCeVxnae3mF4Thl1yqou3bpxytl4ElKBI=; b=kJkFvudcefFc8VY44Zs7MqkvjPH/NCGFJj97dSBwPK8DIXUHKrQNZXayUV2Z+699gY yZCD5engAG05BDJGuWPlkBmRfGFTaIH0sgb/BTDumcm921M4sudozV+l7epy/2osea8C l1boFAS82YpCZKYcNki05j1Pj8L1XLvF+GGwT7Uu7f+qP7SIdSnh49T++wPlrbflN9G+ cAwZmKi2plyzGur/c/b0HG3gLFqG8UYqvaHwyJctsqqSQsV/9q7tIaXVcpdJVpBWqEfI 2mVzzpzVEalHtRQ1kvGjjBT0pYoIzcQhfCQi2El3aDunEzs9mINO6Zzp7TPvReCfRut1 65Gw== X-Gm-Message-State: AOAM533rjsKrpisOuQiM4TCfwxWYEXkVx8z6KJlnr7m85n5oMb74p7FU cm2S9tWNLa8Px3cqNqieFQnujoKnv1nZBw== X-Google-Smtp-Source: ABdhPJwQjGAAo4FXShkEUadbWi0KfSDwKw1C71Pe3m1Eqoz1N6oIpb52n4Piz+MKvYVfYYcCcggpkQ== X-Received: by 2002:a17:906:80cd:: with SMTP id a13mr32353786ejx.109.1620749926876; Tue, 11 May 2021 09:18:46 -0700 (PDT) Received: from snel ([2a10:3781:276:0:21e:c2ff:fefb:f388]) by smtp.gmail.com with ESMTPSA id y22sm11907975eje.26.2021.05.11.09.18.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 May 2021 09:18:46 -0700 (PDT) Date: Tue, 11 May 2021 18:18:44 +0200 From: Job Snijders To: Randy Bush Cc: SIDR Operations WG Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 16:18:54 -0000 Dear Randy & Russ, On Mon, May 10, 2021 at 04:14:42PM -0700, Randy Bush wrote: > hi folk, > > what do i need to work on here before whining about wglc? some solid > constructive wg reviewers would be great. The current -00 title might distract from the substance of the memo. Perhaps: "Clarification on Opaqueness of Resource Public Key Infrastructure (RPKI) Identifiers" Most of the document's content don't appear accessible to newcomers to the RPKI, it reads as if a lot of prior knowledge is required. The 'Discussion' section is somewhat hard to follow. For example, perhaps 'large operations' might be better as 'large corporations' or 'organizations'? The RFC 6480 and RFC 7382 references are useful, but overshadowed by a (to me) somewhat confusing story about sushi and taco. The 'Security' section appears to contain some useful clarifications. > If so, how does one determine if the signature on the real world > document is still valid? Would the EE certificates contained in the signed objects not be periodically validated, including the applicable CRLs? I would suggest to keep the document in the queue, and enrich it based on some field experience with RSC. it shouldn't be too long before the first tests can be conducted with RSC objects. Kind regards, Job From nobody Tue May 11 11:54:40 2021 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 E9EB73A227B for ; Tue, 11 May 2021 11:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 9D7soiEGY7Hc for ; Tue, 11 May 2021 11:54:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2A1563A2279 for ; Tue, 11 May 2021 11:54:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1lgXWd-0003Pq-AR; Tue, 11 May 2021 18:54:35 +0000 Date: Tue, 11 May 2021 11:54:35 -0700 Message-ID: From: Randy Bush To: Job Snijders Cc: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 18:54:40 -0000 hi job, thanks for reading > The current -00 title might distract from the substance of the memo. > Perhaps: "Clarification on Opaqueness of Resource Public Key > Infrastructure (RPKI) Identifiers" in my dotage, i try to impress with words less and less > Most of the document's content don't appear accessible to newcomers to > the RPKI, it reads as if a lot of prior knowledge is required. it's why we have references. but indeed, we have woven a tangled web, as we saw in the secdir review of draft-ietf-opsawg-finding-geofeeds. sympathies to the reviewer. but i doubt we can fix it here. > The 'Discussion' section is somewhat hard to follow. For example, > perhaps 'large operations' might be better as 'large corporations' or > 'organizations'? you really think this make it easier to understand? but sure, organizations it now is. > The RFC 6480 and RFC 7382 references are useful, but overshadowed by a > (to me) somewhat confusing story about sushi and taco. you are not expected to remember bill's bait and sushi. i assume you would prefer examples use more erudite names. sigh. fyi, bb&s is an iconic internet org similar to foo widget company. in this case, bill was bill manning, a friend to many who died recently; hence the bit of memoriam. and roberto's taco stand is just up the road. i strongly recommend the carne asada burrito. >> If so, how does one determine if the signature on the real world >> document is still valid? > > Would the EE certificates contained in the signed objects not > be periodically validated, including the applicable CRLs? you are referring to Then there is the temporal issue. The owner of that AS may be BB&S today when some document was signed, and could be the Government of Elbonia tomorrow. Or the resource could have been administratively moved from one CA to another, likely requiring a change of keys. If so, how does one determine if the signature on the real world document is still valid? are you suggesting automated periodic validation off a cron job or whatever? > I would suggest to keep the document in the queue, and enrich it based > on some field experience with RSC. it shouldn't be too long before the > first tests can be conducted with RSC objects. clue or example on how this will help make this document better? randy From nobody Tue May 11 14:43:36 2021 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 3625D3A278F for ; Tue, 11 May 2021 14:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 eyh45gTuzwzC for ; Tue, 11 May 2021 14:43:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 120123A278C for ; Tue, 11 May 2021 14:43:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1lga9r-0000Rr-Rx; Tue, 11 May 2021 21:43:16 +0000 Date: Tue, 11 May 2021 14:43:15 -0700 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: Russ Housley , George Michaelson , SIDR Operations WG In-Reply-To: <2D988AA2-7860-4F5E-B9D4-87A747A39FD2@nlnetlabs.nl> References: <4455A207-2637-444B-BDA0-1209425C2EF2@vigilsec.com> <2D988AA2-7860-4F5E-B9D4-87A747A39FD2@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 21:43:34 -0000 > However, with RSC/RTA the operator of that child CA could then sign an > attestation containing anything else, including a public B-PKI key > that they may wish to associate with their INRs in specific use cases. is your intent to authorize the non-rpki identity to act in all matters for the INR? i.e. how would one constrain the use cases? e.g. may the non-rpki identity write to the RPKI parent, e.g. ripe, and order the transfer of the INR? and don't tell me about administrative procedures; this is a PKI discussion. so the real-world identity system would sign the rpki INR which then signs the LOA? but why is the rpki INR even needed if the real world identity can simply sign the LOA? i thought that, way back when, ggm was trying to do the inverse. using the rpki private key to authorize some action in the real world. the example i remember was a letter of authorization to run a circuit, aka an LOA for a PNI. and what also confuses me; well i guess many things about this do; is that i am not seeing/understanding where CA cross-certification, in the normal up-the-tree sense, fits. but i am not an expert on this. and can we try to reduce use of long complex erudite seeming text designed to impress rather than explain? randy From nobody Tue May 11 16:45:38 2021 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 C56223A2B19 for ; Tue, 11 May 2021 16:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 oQ1euJFiIM7X for ; Tue, 11 May 2021 16:45:33 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 456A63A2B18 for ; Tue, 11 May 2021 16:45:33 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id i9so24542038lfe.13 for ; Tue, 11 May 2021 16:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jd9HJzycE8kFZwNJn5IXr/C3V0ESnEMqscExPsiSXRY=; b=iB64LzXhU5n9CoF9ohHCqmhuuPK0c5QcmVRy++QVW2Uj6/cP3FvGgY9RfzqcoQOZHZ UcRK3NBE+toDMBIaddfTnjZpSvsVymM+cHU0q4/DuEgjUBGPm33hLGdaT5lN5cPyhiT5 QttPwl4IWqVBs09u5lSPCPh6LmkMMgJwX9Sx+nMesp4iaBfRhksJ7GbTXjmJIrHhQo/x Mu8oZwcKJdrhzprM429IsCxqlHx/6FRMHpPQkldnQFSJsjdsi81uxVQVxlc8ALPLx6OR rImIOVa7jwLry9slnkckV2Wk8pIofdQFJ1O5RDXZoAWQPvH4/+3RO/0U7upP+9Epz/7o E7SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jd9HJzycE8kFZwNJn5IXr/C3V0ESnEMqscExPsiSXRY=; b=g7E47fxEeSuPjj8OSlIY0NnXxW5UNVN5V2iZ1FVhY8EEW6va6izp03v09Bi1uVXuNc NMc14yDXpfkcLnlNk6/Br7gc4BIi7zMxraMXZtoFOs/PrCKK1w8t7OpR7TxeNq3uUWWH Lmhds5cWnecaFB6mrVn9X7RmCE9BTiKAcO58c/QO/sjQJqP51tPRupDeJDZqamhiz9T+ L3+r90ozIZZu3VvNxedgNudm7dP8283mEUEBTBLLoIebgTYxi5LErkw9Jq0rtDzXaTyJ 3oUwF7uG+OsaewIgGB3uVV4g2cTuHVBTb2+NDxLLNg3fGCa0kOgwJyYjDoRE+AJPuNll L3rg== X-Gm-Message-State: AOAM5304bBJuY98othO47JITsvAeqSu0kD7Ir89JLIBE+eELjf09qB0P cHFlTIl8RVdT9UpyRkplNbWmuMc0dG1Y2pVDObEsuA== X-Google-Smtp-Source: ABdhPJxgkncUf09DaNS8T1Tvady5J0QNVvce+X4b3YvBLJT7XO6gEMqGYXVWr2i3XQSqxXtRAtHpiII0i9nMDjG2SnE= X-Received: by 2002:a19:6a06:: with SMTP id u6mr22078775lfu.322.1620776730346; Tue, 11 May 2021 16:45:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: George Michaelson Date: Wed, 12 May 2021 09:45:19 +1000 Message-ID: To: Randy Bush Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 11 May 2021 23:45:37 -0000 You can't provide identity inside RPKI. It's forbidden in the profile. You can use RTA and RSC to sign over things, which could be assertions about identity. RPKI can't "prove" the assertion. But it can associate INR with the assertion. If you do an identity check out of band, with a public-private keypair (for example doing a nonce check) you can use RTA or RSC to sign over things which include the public key you just "checked" in some unstated, undefined, OOB manner. This binds the INR to the validation of that keypair. If you want to define the context of use of the INR and the identity in the RTA and RSC, how you do that is out of scope for RPKI. All your questions about risk and consequence are valid. They're out of scope for RPKI. I think repeatedly saying "you can't provide identity in RPKI" is a bit pointless. Sure: we all know that. You can "bridge" from RPKI to identity, if you use some mechanism to say that, and RSC or RTA can help you do that, without breaching the RPKI profile which forbids directly certifying identity. You asked "how" and I tried to say how. I did it badly. well, that doesn't help me sell the idea, I get that, but I still think this document is a bit pointless. Nobody is trying to say you can certify identity directly, inside RPKI. What I wanted the document to say, which would make it more useful (I think) is that you CAN associate identity and RPKI, if you do it through a mechanism like RTA or RSC. What I say about identity, can be said about Geolocation, or any other quality you want to associate with INR. If it is not permitted inside RPKI, then assert a declaration outside of RPKI, but sign over it using RTA or RSC. Yes, bPKI was a stupid thing to use, to say "some PKI which isn't RPKI" -G From nobody Wed May 12 08:07:41 2021 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 50A403A0930 for ; Wed, 12 May 2021 08:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 q-gIAS2N5IQY for ; Wed, 12 May 2021 08:07:34 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A0C3A0925 for ; Wed, 12 May 2021 08:07:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 664CC300BE1 for ; Wed, 12 May 2021 11:07:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3Yq20vMNmp5T for ; Wed, 12 May 2021 11:07:27 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id B20EC300B38; Wed, 12 May 2021 11:07:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) From: Russ Housley In-Reply-To: Date: Wed, 12 May 2021 11:07:26 -0400 Cc: Randy Bush , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <24319C47-1513-46BC-A20E-232F80C8695B@vigilsec.com> References: To: George Michaelson X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 12 May 2021 15:07:39 -0000 George: I do not understand the value of the "nonce check". CMS allows multiple = parallel signatures. See RFC 4853 for some clarifications, and see RFC = 5752 when there are concerns about stripping one of the signatures. Russ > On May 11, 2021, at 7:45 PM, George Michaelson = wrote: >=20 > You can't provide identity inside RPKI. It's forbidden in the profile. >=20 > You can use RTA and RSC to sign over things, which could be assertions > about identity. RPKI can't "prove" the assertion. But it can associate > INR with the assertion. >=20 > If you do an identity check out of band, with a public-private keypair > (for example doing a nonce check) you can use RTA or RSC to sign over > things which include the public key you just "checked" in some > unstated, undefined, OOB manner. This binds the INR to the validation > of that keypair. >=20 > If you want to define the context of use of the INR and the identity > in the RTA and RSC, how you do that is out of scope for RPKI. >=20 > All your questions about risk and consequence are valid. They're out > of scope for RPKI. >=20 > I think repeatedly saying "you can't provide identity in RPKI" is a > bit pointless. Sure: we all know that. You can "bridge" from RPKI to > identity, if you use some mechanism to say that, and RSC or RTA can > help you do that, without breaching the RPKI profile which forbids > directly certifying identity. >=20 > You asked "how" and I tried to say how. I did it badly. well, that > doesn't help me sell the idea, I get that, but I still think this > document is a bit pointless. Nobody is trying to say you can certify > identity directly, inside RPKI. What I wanted the document to say, > which would make it more useful (I think) is that you CAN associate > identity and RPKI, if you do it through a mechanism like RTA or RSC. >=20 > What I say about identity, can be said about Geolocation, or any other > quality you want to associate with INR. If it is not permitted inside > RPKI, then assert a declaration outside of RPKI, but sign over it > using RTA or RSC. >=20 > Yes, bPKI was a stupid thing to use, to say "some PKI which isn't = RPKI" >=20 > -G >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed May 12 12:07:04 2021 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 C87133A0D05 for ; Wed, 12 May 2021 12:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 TWTDX7IS1JWs for ; Wed, 12 May 2021 12:06:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 419973A0D06 for ; Wed, 12 May 2021 12:06:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1lguC4-0004BV-IW; Wed, 12 May 2021 19:06:52 +0000 Date: Wed, 12 May 2021 12:06:52 -0700 Message-ID: From: Randy Bush To: Russ Housley Cc: George Michaelson , SIDR Operations WG In-Reply-To: <24319C47-1513-46BC-A20E-232F80C8695B@vigilsec.com> References: <24319C47-1513-46BC-A20E-232F80C8695B@vigilsec.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 12 May 2021 19:07:01 -0000 > I do not understand the value of the "nonce check". CMS allows > multiple parallel signatures. See RFC 4853 for some clarifications, > and see RFC 5752 when there are concerns about stripping one of the > signatures. i am lost a few meters higher up; which is what i suspect you may be hinting. at the start of this tangled thread, ggm asked us to include an example of useful "bridging" (ggm's term) MTA/RSC signing. if i had a cms blob signed by an INR CA and by X-CA or whatever, what can i do with it? and i most definitely do not mean the mechanics of signing, proofs of possession, etc. i do not see how it has more authority to issue an LOA for a PNI than would be granted by simply using X-CA. perhaps if X-CA has been used to contract with the issuing RPKI CA, it could authorize modification of RPKI holdings; but no more so than just that X-CA. i suppose that if both signed a blob which somehow encoded that the RPKI INR signer was authorized to represent the X-CA signer in some restricted (i hope) class of transactions, the RPKI INR signer could then issue the LOA for the PNI. this seems a tenuous and therefore dangerous chain (the blob's restrictions must be tested to include the authorization for the LOA[0]), with zero advantage over X-CA just signing the LOA. i keep looping, with the X-CA being the inescapable base real world authority. i think i'll go shopping. :) randy [0] - and who is going down the capybara hole of writing the rfc describing the syntax and semantics of these authorizations and restrictions? --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery From nobody Wed May 12 16:45:50 2021 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 5A1533A1A88 for ; Wed, 12 May 2021 16:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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=algebras-org.20150623.gappssmtp.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 rRxQoYf6yRXX for ; Wed, 12 May 2021 16:45:43 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 50E3F3A1A89 for ; Wed, 12 May 2021 16:45:42 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id p12so31778857ljg.1 for ; Wed, 12 May 2021 16:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pJqZj7yv5n+qE9V0UsLGyei+YUK4Z9Ij0Sfl/NV614Y=; b=CNLZYSk1QnmIQGvTyCLYnXU5WUt/SOR0RxP3MS/9GFT5Vpd+JhITfNI3CFb5CSTkzF 7uziPAikT5kvPtgCabz5mlOJw/5CyGNzp1TPAF26op8utdldub9Loi0G9XAMqlrjvvDG YGWFZ/h9zTI5UHW7rrgIe/HsX2PNMnO34bYskv9jGhVmTapVN2JTR8ThbMEKratB22/L Zd8E1e/QCBoWuO94Ri5UmlxIZivdOeX3rsaTMI565vvNsY5Np8Tij9tbGAwgdqzKAumN rgwnJG2xCf6bBske1Yz2uCROu0edzkNvl8briKlTwrRasJh9ySNJpzTJNUs0Hz0QBMR9 q1Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pJqZj7yv5n+qE9V0UsLGyei+YUK4Z9Ij0Sfl/NV614Y=; b=H+R6Wj0DgZ2mokTEOdBrS0Na9iUQIVETRM7Am+PhXVf6H9sy3Q58qpSs9AnaYk2rh5 OesdyHaOEUd+9zF267/CK8q6Q4ZIQnjAXbCFVdTuYw7GafC19RGkQR40Rzo0plbtMOkD ymK6ofF53+xw0NgZ6VXFUlZTLcV4/3EAXPsTX6hhL9t3XJuWZhG9S+wC4N4XPz+YdPLD +W4L+d7ruw6uv+T6gqpyNhZyAAZzcN5/IBwfUUGBFLOCn+vW24cWCjiG56o16xKORMcc +fBMiV8tHwCh5YcfRz2cvZGX+5gqBkx+iWzFK7svqPfDO9SmIEKc2Yy/z1Ffb/A5elHF xJbQ== X-Gm-Message-State: AOAM533OpQqiCntOMYtKHFja47hvLhq7H4WKiLJ3XRlsIIxgOgY0LFMd E1DNmwjEQJuj/xMMKn53a3Q6bAjpHzVMs6Acl3/bLw== X-Google-Smtp-Source: ABdhPJx5tAh5EQWe91BXML/P16sIl22Iujqgi7yXB0Cntdg87XCeB6uiVFWWV60JPG8Ce405iSmyI4Kle9bjEWJ+n/M= X-Received: by 2002:a05:651c:1a4:: with SMTP id c4mr31405460ljn.112.1620863138827; Wed, 12 May 2021 16:45:38 -0700 (PDT) MIME-Version: 1.0 References: <24319C47-1513-46BC-A20E-232F80C8695B@vigilsec.com> In-Reply-To: From: George Michaelson Date: Thu, 13 May 2021 09:45:27 +1000 Message-ID: To: Randy Bush Cc: Russ Housley , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 12 May 2021 23:45:48 -0000 On Thu, May 13, 2021 at 5:06 AM Randy Bush wrote: > i am lost a few meters higher up; which is what i suspect you may be > hinting. at the start of this tangled thread, ggm asked us to include > an example of useful "bridging" (ggm's term) MTA/RSC signing. > > if i had a cms blob signed by an INR CA and by X-CA or whatever, what > can i do with it? and i most definitely do not mean the mechanics of > signing, proofs of possession, etc. Sorry I ratholed. It was stupid. > > i do not see how it has more authority to issue an LOA for a PNI than > would be granted by simply using X-CA. The LOA, I never quite got why anyone is waving a PDF with a company logo on it, to decide to do something. An RPKI signed LOA, means you can show the IP addresses are legitimate. If its some kind of LOA-like thing about an ASN, same-same: the RPKi can show you control the ASN. But, what shows you're speaking for the logo on the corner of the LOA? Thats how I came into "ok: something else has to certify that this company letterhead really is provably about the company, and you have authority to speak for the company" which is not about the INR, its about the .. identity behind the LOA. > > perhaps if X-CA has been used to contract with the issuing RPKI CA, it > could authorize modification of RPKI holdings; but no more so than just > that X-CA. > > i suppose that if both signed a blob which somehow encoded that the RPKI > INR signer was authorized to represent the X-CA signer in some > restricted (i hope) class of transactions, the RPKI INR signer could > then issue the LOA for the PNI. this seems a tenuous and therefore > dangerous chain (the blob's restrictions must be tested to include the > authorization for the LOA[0]), with zero advantage over X-CA just > signing the LOA. Yes. You have to validate in both domains. It's tedious, but certification is like that. Trust nothing. No? > i keep looping, with the X-CA being the inescapable base real world > authority. Only of the identity assertion. It has no global validity, no testable quality regarding disposition of the INR. You really want the product of both. Thats the CMS, signed independently by both, AS Russ Says, or some construct in the RTA/RSC space which is 'nested' > > i think i'll go shopping. :) > > randy > > [0] - and who is going down the capybara hole of writing the rfc > describing the syntax and semantics of these authorizations and > restrictions? Problem for another day. Never said it wasn't a problem, never said it didn't need to be defined. Wanted to say, Can imagine future uses, and used LOA to exemplify. the B2B cases, don't (yet) have an open-basis. Its (specific)B to (customer)B and the context is private, and defined .. elsewhere. The second identity is defined by the Business which defines the transaction. in the case of AWS or kubectl, its JSON blob bound and the identity part is being solved inside that REST protocol, outside of RPKI with no reference. The signed object is that business establishing you're entitled to say whats to happen to the INR, in their preferred format. Maybe I should have stuck to talking about B2B private, and ignored the identity thing. You decided to stomp on Identity, believing somebody was saying RPKI can "prove" it but that was never my intent: RPKI can be *bound* to identity, or anything else, by CMS or other mechanisms tying both into a common statement. You can bind an LOA identity if you can prove it in some other PKI, to the specific INR, by both PKI being used to sign something. If you want identity or anything else *proven*, you have to use another domain of validation. Proof isn't the binding, its the validation behind what has been said in the binding. RPKI can't validate it. I never sought to say RPKI can prove identity: It can't. -G From nobody Wed May 12 16:55:37 2021 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 877443A1B10 for ; Wed, 12 May 2021 16:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 vwbQkmqG6lf8 for ; Wed, 12 May 2021 16:55:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 E4EB23A1B09 for ; Wed, 12 May 2021 16:55:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1lgyhQ-0004uz-3b; Wed, 12 May 2021 23:55:32 +0000 Date: Wed, 12 May 2021 16:55:31 -0700 Message-ID: From: Randy Bush To: George Michaelson Cc: Russ Housley , SIDR Operations WG In-Reply-To: References: <24319C47-1513-46BC-A20E-232F80C8695B@vigilsec.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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] draft-ietf-sidrops-rpki-has-no-identity-00 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 12 May 2021 23:55:37 -0000 likely more later > The LOA, I never quite got why anyone is waving a PDF with a company > logo on it, to decide to do something. because that is how business is done. and the signature on that piece of paper is kinda important. but they don't wave it; they fax it. yes, in 2021 they fax it. some hipsters use docusign. < rathole > as i just said in chat to an apple support tech while waiting for their manager to do something hardware has advanced far faster than software. and a snail has advanced faster than human computer use. here we are in chat, which i used in the late '70s on the arpanet. and next it will be a phone call. randy From nobody Thu May 27 15:16:10 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4FA3A15B5; Thu, 27 May 2021 15:15:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <162215375938.5302.18021651364512704926@ietfa.amsl.com> Date: Thu, 27 May 2021 15:15:59 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rsc-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2021 22:16:00 -0000 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) object profile for Signed Checklist (RSC) Authors : Job Snijders Tom Harrison Ben Maddison Filename : draft-ietf-sidrops-rpki-rsc-03.txt Pages : 12 Date : 2021-05-27 Abstract: This document defines a Cryptographic Message Syntax (CMS) profile for a general purpose listing of checksums (a 'checklist'), for use with the Resource Public Key Infrastructure (RPKI). The objective is to allow an attestation, in the form of a listing of one or more checksums of arbitrary digital objects (files), to be signed "with resources", and for validation to provide a means to confirm a specific Internet Resource Holder produced the Signed Checklist. The profile is intended to provide for the signing of an arbitrary checksum listing with a specific set of Internet Number Resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-rsc/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-rsc-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 28 02:56:36 2021 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 7E79C3A22BF for ; Fri, 28 May 2021 02:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 Y3lpEcrIdR95 for ; Fri, 28 May 2021 02:56:30 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 AB79E3A22BC for ; Fri, 28 May 2021 02:56:29 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id r23so4196240edw.1 for ; Fri, 28 May 2021 02:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition; bh=ncsXwVO1QAAA91ik5B8ln4GNpDMDWIkegXoY6O2+PCw=; b=kgCSob3Qxe71CDlWv1r1Dj2VeKx7wUgXVjFkj6C4uSbnRy8fp9h3UYlrxKaSaBAa+3 Vx0TppD5WSzb+Z1dKexa+NGWQaXmpwQVpkgquYHsJspCZRp91k7w4iMGX37QBc9AQzbO 7Lb1d3BCVq+JoSIeH4V8beR0ktu3iL6kOD8xU= 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:subject:message-id:mime-version :content-disposition; bh=ncsXwVO1QAAA91ik5B8ln4GNpDMDWIkegXoY6O2+PCw=; b=ekfWcVNxaQHRYX3d9fEHeHcHg0nBYHmZ36STe/GpqO9jKQasQBBaIs36BPs7h1O0Ok 4nxPkiT2jy6g/zOwTxhUJkCo2B6+D8gVuOgV0z6XU68Rxprrsd65yxH4HD7fw1QqxrNL PM/grfoT2yiYfDL51jn4JlhOafRn/UFcKItRYFA5IQyFEy3AD5Ta4BoECKWpBK/9xxX5 LPALcguMiHB0LCgh9FCyRha1AIJfp+8sIKNWa+T4F9ZSgUejpbpox2Q4g+h0jWDHN9Kr l22OCLR9Q57I0rM2b7jwNfs9J7IT+9oVFS0leGxZZSMKVkrczXGPuWqFlJzWD4C9mtn/ VFwg== X-Gm-Message-State: AOAM532bDtq3fd2dUAdvU2sWxahh1rlMhkF/mYK8RLciNe1L+Q8xlWf2 lxaqmaq1m59MVc23iqa9gmIOnMGeU1TYL/yk5xedvOXtUadbHRaE9c310ScciuSzC2KTF2MmpTj yrkoErJppGRGMtU64ybs20a4VVhYhhoBiXFDwqnIQARFIodQJNYp2CWU= X-Google-Smtp-Source: ABdhPJy87ieFwMYKLctNttXhY6zvt91fG+LkLerViGC5WPf7zdwzAOwCjJzX+LIPLrIk6elC7h1Nhg== X-Received: by 2002:a05:6402:2215:: with SMTP id cq21mr8936352edb.28.1622195786968; Fri, 28 May 2021 02:56:26 -0700 (PDT) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id e23sm2479457eds.2.2021.05.28.02.56.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 May 2021 02:56:26 -0700 (PDT) Date: Fri, 28 May 2021 11:56:25 +0200 From: Job Snijders To: sidrops@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rsc-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 28 May 2021 09:56:35 -0000 Dear all, To follow up on posting -03 of the RSC draft. Attached is an example 'checklist.sig' file from which the eContent can be decoded as following: Signed With Resources: 1: IP: 2001:67c:208c::/48 Filenames and Hashes: 1: b42_ipv6_loa.png hash lRbdZL58FyW5/KEXEg5Y6NhCpSBoczmbPd/8kcS2rPA= 2: hash CuE5RyIAXNkvTGqgJNXWs+LmfWKfEXINlHimM6EXocc= The X.509 EE certificate in 'checklist.sig' should decode like below and should be valid under the RIPE NCC Trust Anchor. Kind regards, Job Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha256WithRSAEncryption Issuer: CN = 38e14f92fdc7ccfbfc182361523ae27d697e952f Validity Not Before: May 28 09:31:47 2021 GMT Not After : May 28 09:31:47 2022 GMT Subject: CN = EE Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:95:a7:18:25:5e:ed:e9:4e:32:82:fa:19:7a:a9: 9d:54:75:ad:0f:7d:8a:2a:ed:6a:27:8e:c1:1e:c4: 62:86:07:6d:ff:1b:a6:71:8d:3e:60:72:fd:6b:a8: 34:93:64:dd:e1:e3:4f:0a:43:f8:7e:4b:b2:83:d2: 2e:0b:f8:ce:9c:70:54:1b:18:6d:20:89:40:0d:f0: 33:76:af:e9:27:b2:15:5d:4e:51:84:7f:37:85:e2: d8:f2:4a:3b:17:0a:e9:2c:32:f6:ce:f8:ab:81:e5: c8:69:d4:78:ce:30:41:92:95:5f:32:0b:ac:c2:12: 87:30:a9:bb:c8:6a:92:7d:10:1f:6c:06:be:d1:c2: ea:ac:32:af:5b:f7:09:4d:7d:66:e2:c9:c3:ff:b3: f9:8f:4c:e5:d9:2a:be:2d:a6:25:95:43:5a:79:97: 27:c1:bb:c8:43:80:bb:9f:83:c9:06:8b:5f:24:d2: 7c:4b:55:0a:36:10:bc:f7:62:9e:f2:42:2f:81:22: 99:f7:60:0f:84:39:cd:75:c7:f8:9d:ad:19:d6:71: 39:82:13:73:36:ae:73:27:58:ba:d1:94:ec:79:b9: 1f:34:1d:f0:e7:55:fe:45:65:5e:26:dd:1b:c8:71: 16:6a:fd:fb:53:5b:0e:af:5f:d1:0a:76:27:06:5d: f8:cb Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature X509v3 Subject Key Identifier: B7:D4:EF:59:EE:7C:0E:60:DA:55:97:E3:71:31:90:92:20:C2:8A:A1 X509v3 Authority Key Identifier: keyid:38:E1:4F:92:FD:C7:CC:FB:FC:18:23:61:52:3A:E2:7D:69:7E:95:2F X509v3 Certificate Policies: critical Policy: 1.3.6.1.5.5.7.14.2 sbgp-ipAddrBlock: critical IPv6: 2001:67c:208c::/48 Authority Information Access: CA Issuers - URI:rsync://rpki.ripe.net/repository/DEFAULT/OOFPkv3HzPv8GCNhUjrifWl-lS8.cer X509v3 CRL Distribution Points: Full Name: URI:rsync://chloe.sobornost.net/rpki/RIPE-nljobsnijders/OOFPkv3HzPv8GCNhUjrifWl-lS8.crl Signature Algorithm: sha256WithRSAEncryption 07:56:ed:55:a3:07:55:5b:53:b2:05:fc:d3:08:42:65:87:18: 70:bd:d6:01:40:1c:23:15:ab:f8:eb:7a:44:13:be:ea:99:ed: c9:ad:38:fa:43:e2:64:be:6f:ba:2b:83:74:6f:22:16:1f:8b: 52:ca:c6:01:60:20:ec:2c:1a:9b:2d:8a:fd:9b:8b:4a:be:31: 76:c1:56:a2:97:30:01:57:e6:75:a3:85:73:72:7e:92:16:2a: 9b:a6:79:f6:b1:71:9a:a6:1e:d3:96:d0:7b:37:31:96:b0:1b: 8b:91:7d:40:0e:63:6f:46:da:44:1d:16:99:61:89:0f:bd:71: 76:88:28:94:90:18:1b:c8:d3:0e:33:b3:42:1d:80:69:be:7a: 28:26:22:bd:55:b4:8e:fe:fd:dc:c9:04:78:26:70:16:82:dc: fe:1d:a5:f3:3a:5f:a8:3c:d3:5c:24:17:fb:cd:b3:d7:25:42: ca:21:50:c2:4a:8c:e0:bf:ac:6a:c4:19:27:49:84:eb:10:45: 51:a2:6c:0a:df:a2:16:f6:9c:6f:91:58:24:0a:97:f3:50:41: 81:8b:7d:6a:17:06:2e:2c:7d:b6:de:99:f2:bc:1e:d7:e7:b1: eb:56:1f:c9:36:da:5b:0b:ec:e0:06:b8:99:ec:17:54:b3:fd: 81:25:b2:f3 -----BEGIN CERTIFICATE----- MIIEGzCCAwOgAwIBAgIBADANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEygzOGUx NGY5MmZkYzdjY2ZiZmMxODIzNjE1MjNhZTI3ZDY5N2U5NTJmMB4XDTIxMDUyODA5 MzE0N1oXDTIyMDUyODA5MzE0N1owDTELMAkGA1UEAwwCRUUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCVpxglXu3pTjKC+hl6qZ1Uda0PfYoq7WonjsEe xGKGB23/G6ZxjT5gcv1rqDSTZN3h408KQ/h+S7KD0i4L+M6ccFQbGG0giUAN8DN2 r+knshVdTlGEfzeF4tjySjsXCuksMvbO+KuB5chp1HjOMEGSlV8yC6zCEocwqbvI apJ9EB9sBr7RwuqsMq9b9wlNfWbiycP/s/mPTOXZKr4tpiWVQ1p5lyfBu8hDgLuf g8kGi18k0nxLVQo2ELz3Yp7yQi+BIpn3YA+EOc11x/idrRnWcTmCE3M2rnMnWLrR lOx5uR80HfDnVf5FZV4m3RvIcRZq/ftTWw6vX9EKdicGXfjLAgMBAAGjggFeMIIB WjAOBgNVHQ8BAf8EBAMCB4AwHQYDVR0OBBYEFLfU71nufA5g2lWX43ExkJIgwoqh MB8GA1UdIwQYMBaAFDjhT5L9x8z7/BgjYVI64n1pfpUvMBgGA1UdIAEB/wQOMAww CgYIKwYBBQUHDgIwIgYIKwYBBQUHAQcBAf8EEzARMA8EAgACMAkDBwAgAQZ8IIww ZAYIKwYBBQUHAQEEWDBWMFQGCCsGAQUFBzAChkhyc3luYzovL3Jwa2kucmlwZS5u ZXQvcmVwb3NpdG9yeS9ERUZBVUxUL09PRlBrdjNIelB2OEdDTmhVanJpZldsLWxT OC5jZXIwZAYDVR0fBF0wWzBZoFegVYZTcnN5bmM6Ly9jaGxvZS5zb2Jvcm5vc3Qu bmV0L3Jwa2kvUklQRS1ubGpvYnNuaWpkZXJzL09PRlBrdjNIelB2OEdDTmhVanJp ZldsLWxTOC5jcmwwDQYJKoZIhvcNAQELBQADggEBAAdW7VWjB1VbU7IF/NMIQmWH GHC91gFAHCMVq/jrekQTvuqZ7cmtOPpD4mS+b7org3RvIhYfi1LKxgFgIOwsGpst iv2bi0q+MXbBVqKXMAFX5nWjhXNyfpIWKpumefaxcZqmHtOW0Hs3MZawG4uRfUAO Y29G2kQdFplhiQ+9cXaIKJSQGBvI0w4zs0IdgGm+eigmIr1VtI7+/dzJBHgmcBaC 3P4dpfM6X6g801wkF/vNs9clQsohUMJKjOC/rGrEGSdJhOsQRVGibArfohb2nG+R WCQKl/NQQYGLfWoXBi4sfbbemfK8HtfnsetWH8k22lsL7OAGuJnsF1Sz/YElsvM= ----END CERTIFICATE----- From nobody Fri May 28 02:58:39 2021 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 7F80C3A22CD for ; Fri, 28 May 2021 02:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 etTMBAmUkppC for ; Fri, 28 May 2021 02:58:33 -0700 (PDT) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 0B0513A22C7 for ; Fri, 28 May 2021 02:58:32 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id lz27so4420219ejb.11 for ; Fri, 28 May 2021 02:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Sl1mbDKF5DVQsYX4qmNGb6LqTD+xC5srhFl8QtXVn44=; b=uN16Swm8Iyxmem8oUoj+xWOKYF9skLASfo2bjAa4RuQxB6rQHdl8QCBAQmhGXUiTZm bNv2X8Cx48v/cjyvbkwP15jfip0y6kXF/L1v+PgxgVbKIck7ySjIFDPARY1nEk5FPsZt e82TVWGVChNBGAwhAMIYp9yPZO8mVBTOMY89M= 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:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Sl1mbDKF5DVQsYX4qmNGb6LqTD+xC5srhFl8QtXVn44=; b=I4pjNwBsMfTN11M36bOJ1mlRQHBwwe7gfTd0J5K9cc+IzIJsQAm/m6Rm1nJ1KrNRVR 4DLdRDhd2TzcRqnfAiscEYpBBOaFdYvjN9ebPtqLnLgdOx+Z0oZPDUcIw12vPE9oKB+6 Hm+R4UOTeLNbAz7CY8iv477cTtbSPRDKbhRgxl0f3Cl990LjeuDflJ2oA9OY/KlRIKBe 6v/21wGHJKrfrQGoA6/cgVc8HlSvQmUCgQqG1K6bPYa8Mz42mVEsehGXjjCNZmibOjO5 llOFE5stv84hstcTSSnsDdT3a7QyQ7QO90Avv869GjqQWZOSMbnzNwuQd28yNpPYmGCi qgYA== X-Gm-Message-State: AOAM530hlpMVORFuFtYdi7i/DLE1OdKvYTpMRm00UZ09/VsRtn4tHuHU gunvAPTRDRgvNCKk47pJ03E9tBu4GFvyw6qP/r0jkCZN70TMMmItK5iydo5b4VagbYYreOsTg7G TXeLWfHMXTiZfW93Og1HI1zALk0QT5Cc9xNDQhnP4YCvjiOmUM1f9GDM= X-Google-Smtp-Source: ABdhPJyhyRSZ6G0YhzcslYDq7n0wZLUFQlpU9v4vsxGAgT/YUK0yfj5xwzBd/YBeHehO12BXDkpXww== X-Received: by 2002:a17:906:8591:: with SMTP id v17mr8209234ejx.378.1622195910531; Fri, 28 May 2021 02:58:30 -0700 (PDT) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id g11sm2462458edt.85.2021.05.28.02.58.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 May 2021 02:58:30 -0700 (PDT) Date: Fri, 28 May 2021 11:58:28 +0200 From: Job Snijders To: sidrops@ietf.org Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="m7oiweVoOrHzoisQ" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rsc-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 28 May 2021 09:58:38 -0000 --m7oiweVoOrHzoisQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 28, 2021 at 11:56:25AM +0200, Job Snijders wrote: > Dear all, > > To follow up on posting -03 of the RSC draft. Attached is an example > 'checklist.sig' file from which the eContent can be decoded as > following: > > Signed With Resources: > 1: IP: 2001:67c:208c::/48 > Filenames and Hashes: > 1: b42_ipv6_loa.png > hash lRbdZL58FyW5/KEXEg5Y6NhCpSBoczmbPd/8kcS2rPA= > 2: > hash CuE5RyIAXNkvTGqgJNXWs+LmfWKfEXINlHimM6EXocc= > > The X.509 EE certificate in 'checklist.sig' should decode like below and > should be valid under the RIPE NCC Trust Anchor. Whoops, forgot to actually attach the attachment! :-) Here you go Kind regards, Job --m7oiweVoOrHzoisQ Content-Type: application/pgp-signature Content-Disposition: attachment; filename="checklist.sig" Content-Transfer-Encoding: base64 MIIGjAYJKoZIhvcNAQcCoIIGfTCCBnkCAQMxDTALBglghkgBZQMEAgEwgZMGCyqGSIb3DQEJ EAEwoIGDBIGAMH4wE6ERMA8wDQQCAAIDBwAgAQZ8IIwwCwYJYIZIAWUDBAIBMFowNBYQYjQy X2lwdjZfbG9hLnBuZwQglRbdZL58FyW5/KEXEg5Y6NhCpSBoczmbPd/8kcS2rPAwIgQgCuE5 RyIAXNkvTGqgJNXWs+LmfWKfEXINlHimM6EXocegggQfMIIEGzCCAwOgAwIBAgIBADANBgkq hkiG9w0BAQsFADAzMTEwLwYDVQQDEygzOGUxNGY5MmZkYzdjY2ZiZmMxODIzNjE1MjNhZTI3 ZDY5N2U5NTJmMB4XDTIxMDUyODA5MzE0N1oXDTIyMDUyODA5MzE0N1owDTELMAkGA1UEAwwC RUUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVpxglXu3pTjKC+hl6qZ1Uda0P fYoq7WonjsEexGKGB23/G6ZxjT5gcv1rqDSTZN3h408KQ/h+S7KD0i4L+M6ccFQbGG0giUAN 8DN2r+knshVdTlGEfzeF4tjySjsXCuksMvbO+KuB5chp1HjOMEGSlV8yC6zCEocwqbvIapJ9 EB9sBr7RwuqsMq9b9wlNfWbiycP/s/mPTOXZKr4tpiWVQ1p5lyfBu8hDgLufg8kGi18k0nxL VQo2ELz3Yp7yQi+BIpn3YA+EOc11x/idrRnWcTmCE3M2rnMnWLrRlOx5uR80HfDnVf5FZV4m 3RvIcRZq/ftTWw6vX9EKdicGXfjLAgMBAAGjggFeMIIBWjAOBgNVHQ8BAf8EBAMCB4AwHQYD VR0OBBYEFLfU71nufA5g2lWX43ExkJIgwoqhMB8GA1UdIwQYMBaAFDjhT5L9x8z7/BgjYVI6 4n1pfpUvMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIwIgYIKwYBBQUHAQcBAf8EEzARMA8E AgACMAkDBwAgAQZ8IIwwZAYIKwYBBQUHAQEEWDBWMFQGCCsGAQUFBzAChkhyc3luYzovL3Jw a2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL09PRlBrdjNIelB2OEdDTmhVanJpZlds LWxTOC5jZXIwZAYDVR0fBF0wWzBZoFegVYZTcnN5bmM6Ly9jaGxvZS5zb2Jvcm5vc3QubmV0 L3Jwa2kvUklQRS1ubGpvYnNuaWpkZXJzL09PRlBrdjNIelB2OEdDTmhVanJpZldsLWxTOC5j cmwwDQYJKoZIhvcNAQELBQADggEBAAdW7VWjB1VbU7IF/NMIQmWHGHC91gFAHCMVq/jrekQT vuqZ7cmtOPpD4mS+b7org3RvIhYfi1LKxgFgIOwsGpstiv2bi0q+MXbBVqKXMAFX5nWjhXNy fpIWKpumefaxcZqmHtOW0Hs3MZawG4uRfUAOY29G2kQdFplhiQ+9cXaIKJSQGBvI0w4zs0Id gGm+eigmIr1VtI7+/dzJBHgmcBaC3P4dpfM6X6g801wkF/vNs9clQsohUMJKjOC/rGrEGSdJ hOsQRVGibArfohb2nG+RWCQKl/NQQYGLfWoXBi4sfbbemfK8HtfnsetWH8k22lsL7OAGuJns F1Sz/YElsvMxggGqMIIBpgIBA4AUt9TvWe58DmDaVZfjcTGQkiDCiqEwCwYJYIZIAWUDBAIB oGswGgYJKoZIhvcNAQkDMQ0GCyqGSIb3DQEJEAEwMBwGCSqGSIb3DQEJBTEPFw0yMTA1Mjgw OTMyMDhaMC8GCSqGSIb3DQEJBDEiBCBv5Hhx2C44G40h51U62/P9ONCDHUkD+et7s/eyseXB TTANBgkqhkiG9w0BAQEFAASCAQBOoEkBpDNTzwrhkX6F8IAPheSVZdkeYKn8rTpwB36oAlT1 h+fDQqoSD5K6zDvcqdDbxPQQAjzCDULBdNgOl16/qsa+hZuFlnR4uUZxsWP7dPCSu7CvNDEP 4Dzgnx9HLDdKM6Yxe8sEqZKCM7V6MDkl13A4GpolU6rk9Fc+tpaAF97X7RaudEXcbUcShL7K +4lnef0M7MVk+ktWJbsDRS0hnlsPw1idqyQ58n0Npjkh22vetskYeB2jsKegbDane7TbAcRg ma7GjhKyhB9n5iwZ7ZNCx/wTfN2TGxnRXA5oedt7qUo71pZHzzy7D26g7nW3nb5tT4J/id5d CCNqaJ3Z --m7oiweVoOrHzoisQ-- From nobody Fri May 28 05:36:31 2021 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 5195C3A2758 for ; Fri, 28 May 2021 05:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 yZzwMhEdU7Yo for ; Fri, 28 May 2021 05:36:23 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983DF3A275C for ; Fri, 28 May 2021 05:36:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 24FC7300C27 for ; Fri, 28 May 2021 08:36:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id G9Ko7AyPJ24m for ; Fri, 28 May 2021 08:36:17 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id F3E29300259; Fri, 28 May 2021 08:36:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) From: Russ Housley In-Reply-To: Date: Fri, 28 May 2021 08:36:17 -0400 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2F2A668A-A043-4A69-866E-29F87F723B4D@vigilsec.com> References: To: Job Snijders X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rsc-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 28 May 2021 12:36:29 -0000 Hi Job. I updated my ASN.1 decoder to the (slightly) revised syntax, and it is = able to decode your example. I did not try to validate the signature. Russ > On May 28, 2021, at 5:58 AM, Job Snijders = wrote: >=20 > On Fri, May 28, 2021 at 11:56:25AM +0200, Job Snijders wrote: >> Dear all, >>=20 >> To follow up on posting -03 of the RSC draft. Attached is an example >> 'checklist.sig' file from which the eContent can be decoded as >> following: >>=20 >> Signed With Resources: >> 1: IP: 2001:67c:208c::/48 >> Filenames and Hashes: >> 1: b42_ipv6_loa.png >> hash lRbdZL58FyW5/KEXEg5Y6NhCpSBoczmbPd/8kcS2rPA=3D >> 2: >> hash CuE5RyIAXNkvTGqgJNXWs+LmfWKfEXINlHimM6EXocc=3D >>=20 >> The X.509 EE certificate in 'checklist.sig' should decode like below = and >> should be valid under the RIPE NCC Trust Anchor. >=20 > Whoops, forgot to actually attach the attachment! :-) Here you go >=20 > Kind regards, >=20 > Job > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri May 28 05:38:42 2021 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 053983A2766 for ; Fri, 28 May 2021 05:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 18uNs3s04zK6 for ; Fri, 28 May 2021 05:38:36 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 15C6F3A2764 for ; Fri, 28 May 2021 05:38:35 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id gb17so5100220ejc.8 for ; Fri, 28 May 2021 05:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qUhLjJc3iW+Y4CVakmKW7eUYifuMOMm4vJ03wLwd8z4=; b=aUyg8lQn320jghL1RnFPnUPFiQVNUundTg5PikFTvHcFOV+jQosE3Icg8d6vhbrlQS WLVB8MGctffwtN/aKJ5ZFkaSAqPs1DrJ3hxwhVe6CLZJk3Cwsd56fJVgczSfoOdOnZ6H vhzOso82NBdX44LwGfQikWPiOQKYL2KMFcgec= 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:in-reply-to; bh=qUhLjJc3iW+Y4CVakmKW7eUYifuMOMm4vJ03wLwd8z4=; b=nRPGxaOXgAWKsriiiIDYcCtmB/hsH4fxzd2AwZd1YLgzBmPwLkIk5SjsBbN7p9iLez yhtlrsPNeZXWWaR/BYEeqGo+gtuaueXyCbCNv9V7IR369jjjhtOBp33RYiwSwXQVwffb 8Lbq1YAHQWXR/CC49RDTiuNnc3+7x6699fP+yLq+HxaDGRHJ6Gjm8X2SpPcYB6SkSKjS CPlltRVZR2nFbfH3FFHZIs9uh9cg2Yu0mfANul5Ig/ew74/6tlXwTOVnnUbvb8SLa0Ix trQJ5x1L9icOo1jxIIK8dLS78dPjM+onMOAqVvOrvCB52sFKVk/D0ZWY9a34weUV9mZd FUiw== X-Gm-Message-State: AOAM533hDvL5ZOz7vgG+PucMQfxval/wcpEzEzaWeACL+fXBOADwPzDp Z/fxQkLyhgMgnP+G3CUBYggGxQ== X-Google-Smtp-Source: ABdhPJwEZyTOqTaDblvpGqlCX4ioo/uwQngrRuW8A7AuYF/dBUnJEF7FYJe5cRldTYx0h6+lrrZGrQ== X-Received: by 2002:a17:906:d147:: with SMTP id br7mr8886628ejb.272.1622205512756; Fri, 28 May 2021 05:38:32 -0700 (PDT) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id h7sm2341571ejp.24.2021.05.28.05.38.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 May 2021 05:38:32 -0700 (PDT) Date: Fri, 28 May 2021 14:38:30 +0200 From: Job Snijders To: Russ Housley Cc: sidrops@ietf.org Message-ID: References: <2F2A668A-A043-4A69-866E-29F87F723B4D@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F2A668A-A043-4A69-866E-29F87F723B4D@vigilsec.com> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rsc-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 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, 28 May 2021 12:38:41 -0000 On Fri, May 28, 2021 at 08:36:17AM -0400, Russ Housley wrote: > I updated my ASN.1 decoder to the (slightly) revised syntax, and it is > able to decode your example. I did not try to validate the signature. Great - thank you. Kind regards, Job From nobody Mon May 31 14:47:29 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 223CD3A02BD; Mon, 31 May 2021 14:47:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <162249763406.8470.9816812417529350441@ietfa.amsl.com> Date: Mon, 31 May 2021 14:47:14 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rsc-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2021 21:47:14 -0000 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) object profile for Signed Checklist (RSC) Authors : Job Snijders Tom Harrison Ben Maddison Filename : draft-ietf-sidrops-rpki-rsc-04.txt Pages : 12 Date : 2021-05-31 Abstract: This document defines a Cryptographic Message Syntax (CMS) profile for a general purpose listing of checksums (a 'checklist'), for use with the Resource Public Key Infrastructure (RPKI). The objective is to allow an attestation, in the form of a listing of one or more checksums of arbitrary digital objects (files), to be signed "with resources", and for validation to provide a means to confirm a specific Internet Resource Holder produced the Signed Checklist. The profile is intended to provide for the signing of an arbitrary checksum listing with a specific set of Internet Number Resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-rsc/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-rsc-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/