Speaking as a regular ol' member
>I am sympathetic to the concerns that Randy has cited. In particular, I >am uncomfortable >with the ability of a signer to enumerate an unconstrained list of >object types that >are signed. We need to consider the semantic of each object that can be >covered by a >sig and decide whether they are consistent with what the RPKI certifies. >If not, then >that object type must be excluded. If we can come to agreement on a >scheme of this >sort, I might be supportive of this proposal. [[First, terminology clarification. RPSL has objects that have attributes. The draft talks about producing a signature for an object. So when you say "object type" I think you mean attributes of an object.]] The draft includes a list of the minimum attributes, per object type(*), that must be included in a signature,. It does specify per object type what the relationship must be between the resources mentioned in the cert and the resources in the object. It also allows the maintainer to specify other attributes in the object that are included in the signature. That last part I think is where you are concerned. We do have the example of the ghostbuster record, where the information being signed has no relationship to the resources included in the certificate that verifies the signature. There's probably a reason that ghostbusters was an acceptable set of information to be signed, with no call for it to be "consistent with what the RPKI certifies". I have a guess that the reason might be in the ghostbusters security consideration section that says: Relying parties are hereby warned that the data in a Ghostbusters Record are self-asserted. These data have not been verified by the CA that issued the CA certificate to the entity that issued the EE certificate used to validate the Ghostbusters Record. Would that same sort of warning relieve your concern here? OTOH. The ghostbusters record content is much more constrained than the attributes in RPSL objects, which might put the RPSL signatures in a whole other league. --Sandy, speaking as regular ol' member (*)(Though not all object types? There are other RPSL object types beyond those included in this draft.) _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
