I have read draft-ietf-sidr-res-certs-02, and have some comments.
I have decidedly little experience of the guts of X.509 certificates,
but some practical experience of routing systems and resource
assignment. The following comments (and the absence of comments on X.
509 minutiae) should be read in that context.
I have assumed that the intended audience for this draft includes
organisations which assign resources to others (the IANA, RIRs, NIRs,
LIRs) and those which might have a reason to validate a certificate
for a particular resource (RPSL repositories, transit providers being
asked to announce new customer prefixes). Both these groups'
perspectives seem to be well-covered in this document.
There are no examples provided in the document of how these
certificates might be used, once generated. I realise that's a much
wider topic of which a description of the certificates themselves is
a small component; however, some examples might be useful in the
event that this document is ever read in isolation.
Section 3 contains fields described using phrases such as "positive
integer" without including information about the field width -- in
other words, there's no comment on the maximum value that might be
stored. Perhaps this is implicit in the design of X.509, but since I
couldn't find any mention of it in RFC 3280 either, I thought I'd
make the observation here.
In section 3.7 the draft alludes to possible reasons for a resource
certificate's "valid to" field to extend beyond that in the superior
certificate. It's not clear to me why this should be the case. I
don't have strong opinions about this, but it seems possible that an
example would lend some clarity.
In section 3.8 the draft uses normative language to specify key
sizes. Should it not instead specify *minimum* key sizes, or is it an
explicit goal to specify an absolute size? (Would it be bad, for
example, if I chose to use a 4096 bit key instead of the 2048 bit key
I SHOULD use?)
Section 3.9.1 has a typo, maybe ("cA" vs. "CA")?
Section 3.9.2 is missing a space between the "of" and the "[RFC3280]"
at the end of the last paragraph.
In section 3.9.5, why is an rsync URI preferred over any other kind
of URI? There's no normative language surrounding the stated
preference. Is a preference lacking normative teeth worth mentioning?
If so, might it be an idea to indicate that other URIs MAY be used
instead?
In section 3.9.6 and 3.9.7 the rsync URI is specified again, this
time as a MUST with a note that other URIs MAY be used. While I'm
still interested in why the rsync URI is a MUST, the language and the
associated MAY make these sections clearer than 3.9.5.
In general, the draft seems to systematically misspell words like
"authorise" and "recognise", in defiance of the authors' Commonwealth
origins. Also I'm fairly sure "unexpired" is not a word; "non-
expired" seems better. :-)
Joe
_______________________________________________
Sidr mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/sidr
