diff --git a/draft-ymbk-sidrops-rpki-has-no-identity.xml b/draft-ymbk-sidrops-rpki-has-no-identity.xml
index 881a363..87754f2 100644
--- a/draft-ymbk-sidrops-rpki-has-no-identity.xml
+++ b/draft-ymbk-sidrops-rpki-has-no-identity.xml
@@ -31,29 +31,26 @@
-
- Vigil Security, LLC
-
-
- 516 Dranesville Road
- Herndon
- VA
- 20170
- USA
-
- housley@vigilsec.com
-
-
+
+ Vigil Security, LLC
+
+
+ 516 Dranesville Road
+ Herndon, VA
+ 20170
+ US
+
+ housley@vigilsec.com
+
+
- There is a false notion that internet number resource in the RPKI
- can be associated with the real world identity of the 'owner' of an
- internet number resource, and may therefore be used to authenticate
- real world documents or transactions. This document attempts to put
- that notion to rest.
+ 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.
@@ -82,12 +79,11 @@
In security terms the phrase "Public Key" implies there are also
private keys, a la . And, as the RPKI has
strong authority over ownership of Internet Number Resources (INRs),
- there is a desire to use these private keys to sign arbitrary
- documents to attest that the 'owner' of those resources has
- authorized or authenticated a real world document or transaction.
- Instead, it is an authorization to speak for the named IP address
- blocks and AS numbers themselves, not their unidentifiable
- owners.
+ 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. Instead, it is an
+ authorization to speak for the named IP address blocks and AS
+ numbers themselves, not their unidentifiable owners.
There is a desire is to authenticate real world business
transactions with the signatures of INR holders. E.g. for Bill's
@@ -137,16 +133,16 @@
- An INR holder does not actually hold the private key attesting to
- their resources; a CA does. The INR holder has a real world
- business relationship with the CA for which they have likely signed
- real world documents.
+ 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.
As the INR owner does not have the keying material, they rely on
- the CA, to which they presumably must present credentials, in order
- to manipulate their INRs. These credentials may be userid/password
- (with two factor authentication one hopes), hardware tokens, client
- certificates, etc.
+ 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), a hardware token, client
+ browser certificates, etc.
Hence schemes such as
and must go to great
@@ -156,7 +152,8 @@
System (AS) number, someone out on the net probably has the
credentials to the CA account in which BB&S's INRs are
registered. That could be the owner of BB&S, Roberto's Taco
- Stand, or the Government of Elbonia. One simply can not know.
+ Stand, an IT vendor, or the Government of Elbonia. One simply can
+ not know.
In large operations, INR management is often compartmentalized
with no authority over anything beyond dealing with INR
@@ -165,7 +162,7 @@
to authorize access to BB&S's servers in some colocation
facility.
- There is the temporal issue that the owner of an INR may be
+ 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
@@ -193,18 +190,28 @@
says explicitly "An important property of this PKI is that
certificates do not attest to the identity of the subject."
- The "Template for a Certification Practice Statement (CPS) for
- the Resource PKI (RPKI)" Section 3.1,
- Naming, makes very clear that "The Subject name in each certificate
- SHOULD NOT be meaningful;" and goes on to do so at some length.
+ The Template for a Certification Practice Statement (CPS) for the
+ Resource PKI (RPKI) Section 3.1, Naming,
+ makes very clear that "The Subject name in each certificate SHOULD
+ NOT be meaningful;" and goes on to do so at some length.
Attempts to use RPKI data to authenticate real world documents or
- other artifacts requiring identity are inappropriate and
- dangerous.
+ other artifacts requiring identity are invalid and misleading.
+
+ When a document is signed with the private key associated with a
+ 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
+ schemes such as and the signed message further
+ narrows this scope of INRs. The INRs in the message are a subset of
+ the INRs in the certificate. If the signature is valid, the message
+ content comes from a party that is authorized to speak for that
+ subset of INRs.
Control of INRs for an entity could be used to falsely authorize
transactions or documents for which the INR manager has no