>> way back, the rirs were very insistant that their use of rpki authority >> was most emphatically not to be considered an identity service. this >> permeated the design; e.g., organization names were specifically >> forbidden in certificate CN, Subject Alternative Name, etc. >> > > yup, I agree... though the b2b stuff George/Geoff have written up LOOKS like > it could be useful for this LOA type discussion. The spaghetti draft appears > to also fill this niche... > > Neither are particularly rooted in the RPKI except that the CA certs are being > used as a method to attest that a 'thing' exists, and that something signed > that 'thing' as proof of knowledge (I guess, really). Effectively this is: > 1) I am 'ca-foo' in a tree that you can trust knows I am 'foo'. > 2) I signed this blob (LOA) > 3) I asked jane at bar.com to sign as well > 4) you can verify me (because rpki tree) and you can verify Jane because > she's > also using her RPKI ca cert. > > this may be a little cumbersome to sort through, especially if all parties > here > aren't party to the RPKI (did equinix plumb the RPKI into their customer > portal > and all of the things required to make a x-connect work in this manner?), but > I > imagine that if this gets wings it could be automated and it could be reliable > and all parties (except the colo folks perhaps?) may already have incentives > in places to use their RPKI goop for this function.
this would work only if the LOA is being sent to someone with whom my contract is signed with a key validating through the same hierarchy, or the credential was associated contractually. i do not think equinix is up to this yet. randy
