a quick read only. and sorry to wait for wglc, but that's life. at
least i did not wait for ietf lc :)
--
what is "RPSL"? it is not defined, nor is there a cite.
--
2.1. General Attributes, Meta Information
in general, the format/syntax of the attribute part of many fields might
be specified more precisely. have mercy on the people who are gonna
write code to parse this stuff. e.g. time "is expressed as the decimal
representation of an unsigned integer," but what is a decimal
representation? ascii? (note that 3.1.4 does this) i'd even settle for
examples. the "list of attribute names" needs to cite the enumeration
of allowed names, kinda hard if RPSL has no cite. blah blah blah.
--
2.1. General Attributes, Meta Information
2. Reference to the certificate corresponding to the private key
used to sign this object (field "c"). This is a URL of type
"rsync" or "http(s)" that points to a specific resource
certificate in an RPKI repository.
needs a cite
--
2.1. General Attributes, Meta Information
3. Signature method (field "m"): what hash and signature algorithms
were used to create the signature. The allowed algorithms which
can be used for the signature are specified in [RFC6485].
sec folk, is this sufficiently specified that i can get a sure parse?
i am three levels deep in rfcs and am still not sure.
--
2.1. General Attributes, Meta Information
5. The signed attributes (field "a"). This is a list of attribute
names, separated by an ASCII "+" character (if more than one
attribute is enumerated). The list must include any attribute at
most once.
as rfc 2622 has many attributes which are "multi-valued," which of the
set is being signed?
--
Optional fields of the "signature" attribute:
is it a field or an attribute? both are used. decide.
--
One applications for such a mechanism include the case of a route[6]
object, where both the prefix owner's and the AS owner's signature is
expected (if they are different parties).
first, this is an example of why a mild grammar pass is needed.
second, the trust model of the rpki ROA is that the AS owner does not
attest. i do not remember the trust model in RPSL and am too lazy to
try to figure it out as it cites 2725 which says
3. Routes should only be announced with the consent of the holder of
the origin AS number of the announcement and with the consent of
the holder of the address space.
but i just do not have the energy to find how this is stated, validated,
... in this way too looong doc. but the difference in trust models
could be at least noted.
and i have this nagging worry that there is trouble waiting in that list
of urls of certs. the references and referents are not necessarily
stable and the resulting instability of a collection of them could be
interesting.
--
2.2. Signed Attributes
One can look at an RPSL object as an (ordered) set of attributes
uh, i guess one could. but my memory is that the are not strictly
ordered. you may want to say if and why ordering is actually important
to this draft.
--
2.2. Signed Attributes
trust model issue. what attributes may [not] be signed by, for example,
a prefix cert? may prefix certs [not] sign different fields/attributes
than AS certs?
--
The type of the object determines the minimum set of attributes that
MUST be signed. The signer MAY choose to sign additional attributes,
in order to provide integrity protection for those attributes too.
forward ref to sec 4 would be helpful here.
is integrity the only assertion being made if for signed attributes
beyond the minimum set?
with multiple signers, is, for example, the AS holder signing an route:
object really attesting to the holes: and org:?
--
why not mandate the canonic syntax of 3.1.4 in the objects themselves?
--
3.2. Signature Creation
3. Arrange the selected attributes according to the selection
sequence specified in the "a" field as above, omiting all
attributes that will not be signed.
attributes which may be repeated are gonna be fun.
--
back to tex
randy
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
