randy/draft-rpki-has-no-identity
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

more ownership

Browse source
This commit is contained in:
Randy Bush 2022-04-14 15:30:25 -07:00
parent 547178358d
commit 1ad4817e10
1 changed files with 26 additions and 25 deletions
Download patch file Download diff file Expand all files Collapse all files

51
draft-ietf-sidrops-rpki-has-no-identity.xml
View file

@ -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 'holder'
of an INR. This document attempts to put that notion to rest.</t>
</abstract>
@ -80,23 +80,24 @@
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
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 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>
a corresponding private key <xref target="RFC5280"/>. The RPKI
provides strong authority to the current holder of INRs; however,
some people a have a desire to use RPKI private keys to sign
arbitrary documents as the INR 'holder' of those resources with the
inappropriate expectation that the signature will be considered an
attestation to the authenticity of the document content. But in
reality, the RPKI certificate is only an authorization to speak for
the explicitly identified INRs; it is explicitly not intended for
authentication of the 'holders' 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
business transactions with the signatures of INR holders. E.g.
Bill's Bait and Sushi could use the private key attesting to
ownership of their AS in the RPKI to sign a Letter of Authorization
(LOA) for some other party to rack and stack hardware owned by
BB&amp;S. Unfortunately, while this may be technically possible, it
is neither appropriate nor meaningful.</t>
Bill's Bait and Sushi could use the private key attesting to that
they are the holder of their AS in the RPKI to sign a Letter of
Authorization (LOA) for some other party to rack and stack hardware
owned by BB&amp;S. Unfortunately, while this may be technically
possible, it is neither appropriate nor meaningful.</t>
<t>The I in RPKI actually stands for "Infrastructure," as in
Resource Public Key Infrastructure, not for "Identity". In fact,
@ -167,7 +168,7 @@
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
<t>As the INR holder does not have the keying material, they rely on
the CA, to which they presumably present credentials, to manipulate
their INRs. These credentials may be userid/password (with two
factor authentication one hopes), a hardware token, client browser
@ -191,7 +192,7 @@
to authorize access to BB&amp;S's servers in some colocation
facility.</t>
<t>Then there is the temporal issue. The owner of that AS may be
<t>Then there is the temporal issue. The holder of that AS may be
BB&amp;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
@ -200,15 +201,15 @@
<t>While Ghostbuster Records <xref target="RFC6493"/> may seem to
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>
arbitrary, and does not attest to holding of any INRs. They are
merely clues for operational support contact in case of technical
RPKI problems.</t>
<t>Usually, before registering INRs, CAs require proof of INR
ownership via external documentation and authorities. It is
somewhat droll that the CPS Template, <xref target="RFC7382"/>, does
not mention any diligence the CA must, or even might, conduct to
assure the INRs are in fact owned by a registrant.</t>
<t>Usually, before registering INRs, CAs require proof of an INR
holding via external documentation and authorities. It is somewhat
droll that the CPS Template, <xref target="RFC7382"/>, does not
mention any diligence the CA must, or even might, conduct to assure
the INRs are in fact owned by a registrant.</t>
<t>That someone can provide 'proof of possession' of the private key
signing over a particular INR should not be taken to imply that they