Hi,
Robert,
Thanks for the clarification., but I still have some serious concerns
that I think need to be addressed as we progress this as a WG item.
I looked at your document and I see that section 5 is a "Minimum set of
Signed Attributes." To try to prevent the problem I cited, it really
needs a definitive list of the objects and attributes that MAY be
signed, with a prohibition on signing any other objects/attributes.
This is the opposite of what your text says, as it allows the signer to
include whatever other attributes the signer wishes.
The name of an AS is NOT something that can be validated using the RPKI,
and this needs to made clear to folks using this mechanism. The same is
true for net name, org, country and status. The simplest thing to do
would be to exclude these as signed attributes. I am not very familiar
with the attributes you listed for the four object types, but I suspect
that a more of them will fall into this category.
The intention here is that the owner of the resources can make verifiable
statements. They can claim, by constructing and signing RPSL objects, that
certain facts are true regarding the use of the resource; in other words,
this mechanism allows the holder of the resources to bind their resources
and other info together. So it's really intentional that other attributes
such as org name, AS name, import/export attributes, contact info, ... can
be covered by the signature, even though these are not number resources.
If we state that the only attributes that can be signed are the ones that
carry number resources, and which can also be found in the covering
certificate (ie. your "maximum set" approach, if I understand correctly),
then there is no practical gain for the signature. The only only meaning for
such an object in my interpretation would be "The resource holder has
spoken. They said they have an object." without any verifiable claims about
the actual content of the object.
Based on this, I believe that the current "minimum set" specification is the
right approach.
Also, for each of these objects/attributes, you need to describe what
constitutes validation based on an appropriate cert or ROA, i.e., what
checks MUST be performed by the RP to ensure that the signed
object/attributes are consistent with the ROKI objects used to verify
the signature.
Very good suggestion, I completely agree with it.
Regards,
Robert
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr