-04 with warren playing rfc editor and johnny comma-seed

This commit is contained in:
Randy Bush 2022-03-03 12:27:47 -08:00
parent e88b419af5
commit 11a782f66b

View file

@ -1,5 +1,5 @@
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -->
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
@ -11,7 +11,7 @@
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc category="std" consensus="true" docName="draft-ietf-sidrops-rpki-has-no-identity-03" ipr="trust200902">
<rfc category="std" consensus="true" submissionType="IETF" docName="draft-ietf-sidrops-rpki-has-no-identity-04" ipr="trust200902">
<front>
@ -49,7 +49,7 @@
<abstract>
<t>There is a false notion that Internet Number Resources (INRs) in
the RPKI can be associated with the real world identity of the 'owner'
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.</t>
</abstract>
@ -74,22 +74,23 @@
<t>The Resource Public Key Infrastructure (RPKI), see <xref
target="RFC6480"/>, "Represents the allocation hierarchy of IP
address space and Autonomous System (AS) numbers," which are
collectively known as Internet Number Resources (INRs). Though
since, it has grown to include other similar resource and routing
data, e.g. Router Keying for BGPsec, <xref target="RFC8635"/>.</t>
collectively known as Internet Number Resources (INRs). Since
initial deployment, the RPKI has grown to include other similar
resource and routing data, e.g. Router Keying for BGPsec, <xref
target="RFC8635"/>.</t>
<t>In security terms the phrase "Public Key" implies there is also a
corresponding private key <xref target="RFC5280"/>. The RPKI's
<t>In security terms, the phrase "Public Key" implies there is also
a corresponding private key <xref target="RFC5280"/>. The RPKI's
strong authority over ownership of INRs has misled some people
toward a desire to use RPKI private keys to sign arbitrary documents
attesting that the INR 'owner' of those resources has attested to
the authenticity of the document content. But in reality, the RPKI
certificate is only an authorization to speak for for the explicitly
certificate is only an authorization to speak for the explicitly
identified INRs; it is explicitly not intended for authentication of
the 'owners' of the INRs. This situation is emphasized in Section
2.1 of <xref target="RFC6480"/>.</t>
<t>It has been suggested that one could authenticate real world
<t>It has been suggested that one could authenticate real-world
business transactions with the signatures of INR holders. E.g.
Bill's Bait and Sushi could use their AS in the RPKI to sign a
Letter of Authorization (LOA) for some other party to rack and stack
@ -115,29 +116,28 @@
<t>The RPKI was designed and specified to sign certificates for use
within the RPKI itself and to generate Route Origin Authorizations
(ROAs), <xref target="RFC6480"/>, for use in routing. Its design
intentionally precluded use for attesting to real world identity as,
intentionally precluded use for attesting to real-world identity as,
among other issues, it would expose the Certification Authority (CA)
to liability.</t>
<t>That the RPKI does not authenticate real world identity is a
feature not a bug. If it tried to do so, aside from the liability,
<t>That the RPKI does not authenticate real-world identity is a
feature, not a bug. If it tried to do so, aside from the liability,
it would end in a world of complexity with no proof of termination,
as X.400 learned.</t>
<t>Registries such as the Regional Internet Resistries (RIRs)
provide INR to real world identity mapping through whois and similar
<t>Registries such as the Regional Internet Registries (RIRs)
provide INR to real-world identity mapping through whois and similar
services. They claim to be authoritative, at least for the INRs
which they allocate.</t>
<t>RPKI-based credentials of INRs MUST NOT be used to authenticate
real world documents or transactions without some formal external
real-world documents or transactions without some formal external
authentication of the INR and the authority for the actually
anonymous INR holder to authenticate the particular document or
transaction.</t>
<t>Note that, if there is sufficient external, i.e. non-RPKI,
verifcation of authority, then use of RPKI-based credentials seems
superfluous.</t>
<t>Given sufficient external, i.e. non-RPKI, verification of
authority, the use of RPKI-based credentials seems superfluous.</t>
</section>
@ -154,8 +154,8 @@
<t>Normally, the INR holder does not hold the private key attesting
to their resources; the Certification Authority (CA) does. The INR
holder has a real world business relationship with the CA for which
they have likely signed real world documents.</t>
holder has a real-world business relationship with the CA for which
they have likely signed real-world documents.</t>
<t>As the INR owner does not have the keying material, they rely on
the CA, to which they presumably present credentials, to manipulate
@ -186,10 +186,10 @@
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?</t>
the real-world document is still valid?</t>
<t>While Ghostbuster Records <xref target="RFC6493"/> may seem to
identify real world entities, their semantic content is completely
identify real-world entities, their semantic content is completely
arbitrary, and does not attest to INR ownership. They are merely
clues for operational support contact in case of technical RPKI
problems.</t>
@ -205,7 +205,7 @@
are a valid legal representative of the organization in possession
of that INR. They could be just an INR administrative person.</t>
<t>Autonomous System Numbers do not identify real world entities.
<t>Autonomous System Numbers do not identify real-world entities.
They are identifiers some network operators 'own' and are only used
for loop detection in routing. They have no inherent semantics other
than uniqueness.</t>
@ -214,10 +214,10 @@
<section anchor="security" title="Security Considerations">
<t>Attempts to use RPKI data to authenticate real world documents or
<t>Attempts to use RPKI data to authenticate real-world documents or
other artifacts requiring identity are invalid and misleading.</t>
<t>When a document is signed with the private key associated with a
<t>When a document is signed with the private key associated with an
RPKI certificate, the signer is speaking for the INRs, the IP
address space and Autonomous System (AS) numbers, in the
certificate. This is not an identity; this is an authorization. In
@ -233,7 +233,7 @@
authority.</t>
<t>RPKI-based credentials of INRs MUST NOT be used to authenticate
real world documents or transactions without some formal external
real-world documents or transactions without some formal external
authentication of the INR and the authority for the actually
anonymous INR holder to authenticate the particular document or
transaction.</t>