LOAs for Cross Connects - Something like PeeringDB for XC
randy at psg.com
Mon Feb 22 19:06:08 UTC 2021
>> 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.
More information about the NANOG