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

Reply via email to