An object identifies one AS and its prefixes
RFC 9582 defines a ROA with one AS number and a set of IPv4 or IPv6 prefixes. Authorizing multiple ASes for the same prefixes requires corresponding separate objects rather than an unspecified organization-wide permission.
Validation checks the signature, object structure and resource certificate authorizing the listed prefixes. A valid mathematical signature outside that resource scope is insufficient. A ROA does not itself advertise a route or establish that a service is online.
References: [1]
maxLength changes authorization scope
Without maxLength, permission is for the exact listed prefix. A /24 with maxLength 26 also permits contained /25 and /26 routes, but not /27. Longer prefix lengths describe smaller subprefixes, not a larger address block.
An unnecessarily broad maxLength also authorizes subprefixes not intended for announcement. RFC 9319 discusses precise authorizations: broader scope is not automatically stronger protection, and narrowing it still does not validate the entire path.
Objects and route-validation states differ
Origin validation compares prefix, length and origin AS with available authorizations: a match yields Valid, covering authorization without a match yields Invalid, and no covering data yields NotFound. One nonmatch must not obscure another matching authorization.
Operators decide how validation states affect policy. NotFound is not proof of malice, and Valid does not authenticate an entire AS_PATH or every propagation decision. RFC 8481 separates state assignment from policy action.