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

spell check

Browse source
This commit is contained in:
Randy Bush 2021-03-14 15:26:06 -07:00
parent da1f4578c1
commit 71b1781494
1 changed files with 26 additions and 23 deletions
Download patch file Download diff file Expand all files Collapse all files

49
draft-ymbk-rpki-has-no-identity.xml
View file

@ -65,7 +65,7 @@
<t>In security terms the phrase "Public Key" implies there are also
private keys, a la <xref target="RFC2459"/>. And, as the RPKI has
strong authority over ownership of Internet Number Resources (INRs),
there is a desire to use the private keys to sign arbitraty
there is a desire to use the private keys to sign arbitrary
documents to attest that the 'owner' of those resources has attested
to the authenticity of those documents.</t>
@ -97,46 +97,49 @@
<section anchor="discuss" title="Discussion">
<t>In reality, the INR holder does not even hold the private key
attesting to their resources; the Certification Authority (CA) does.
Which is why schemes such as <xref
target="I-D.ietf-sidrops-rpki-rta"/> and <xref
target="I-D.ietf-sidrops-rpki-rsc"/> must go to great lengths to
extract the supposedly [not really] relevant keys from the CA.</t>
<t>Normally, the INR holder does not hold the private key attesting
to their resources; the Certification Authority (CA) does.</t>
<t>As the INR owner does not have the keying material, they rely on
the CA, to which they presumably must present credentials to
the CA, to which they presumably must present credentials, to
manipulate their INRs. These credentials may be userid/password
(with two factor authentication one hopes), client browser
certificates, etc.</t>
(with two factor authentication one hopes), a hardware token, client
browser certificates, etc.</t>
<t>Hence schemes such as <xref target="I-D.ietf-sidrops-rpki-rta"/>
and <xref target="I-D.ietf-sidrops-rpki-rsc"/> must go to great
lengths to extract the supposedly [not really] relevant keys from
the CA.</t>
<t>For some particular INR, say Bill's Bait and Sushi's AS number,
someone out on the net probably has the credentials to the CA where
it is registered. That could be the owner of BB&amp;S, Roberto's
Taco Stand, or the Government of Elbonia. One simpley can not
know.</t>
someone out on the net probably has the credentials to the CA
account in which it is registered. That could be the owner of
BB&amp;S, Roberto's Taco Stand, or the Government of Elbonia. One
simply can not know.</t>
<t>Then there is the temporal issue. The owner of that AS may be
BB&amp;S today when your document was signed, and could be the
Government of Elbonia tomorrow. If so, is the signature still
valid?</t>
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
change of kets. If so, is the signature still valid?</t>
<t>Beware that, while Ghostbuster Records <xref target="RFC6493"/>
may seem to identify a real world entity, in fact their semantic
content is completely arbitrary, and does not attest to INR
ownership. They are merely a clue for operational support contact
in case of technical RPKI problems.</t>
<t>It is somewhat droll that the CPS template, <xref
target="RFC7382"/>, does not mention any diligence the CA MUST, or
even SHOULD, conduct to assure the INRs are in fact owned by a
registrant.</t>
<t>While Ghostbuster Records <xref target="RFC6493"/> may seem to
identify a real world entity, in fact their content is completely
arbitrary, and do not attest to INR ownership. They are merely an
clue for operational support in case of problems.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>Attempts to use RPKI data to authenticate real world documents or
other artifacts requiring indentiy are invalid and misleading.</t>
other artifacts requiring identity are invalid and misleading.</t>
</section>