At 3:39 PM +0100 11/27/08, Robert Kisteleki wrote:
Stephen Kent wrote:
However, I worry that we need to tightly restrict which RPSL data
can be validated using an RPKI cert. My concern is that it would be
easy for folks to misinterpret the extent of what an RPLI cert
attests to, and thus accord signed RPSL data more trust than it
deserves. I also worry that using RPKI certs for this purpose might
cause folks to want to have Subject names be meaningful, not
arbitrary, as now required by our specs. So, if Robert is
comfortable with imposing these sorts of constraints, I think it
appropriate to make this a work item.
Section (2) of the draft says:
"2. Meaning of a signature
By signing an RPSL object, the signer of the object expresses that:
o they have the right to use the resource that the object refers to
(ie. found as the primary key or in some other field of the
object);
o ..."
So in fact I already restrict the usage to only those type of
objects that have something to to with actual number resources (ie.
this excludes person objects). I'd be less comfortable to state *in
this document* that the certificate subject names should not be
meaningful; I'd defer that to the higher level documents such as the
certificate profile and architecture documents. However, since this
is only redundancy, not a new requirement, I'm not specifically
against this.
Robert
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.
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.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
