Thanks, Joe, for the feedback. I am one of the APNIC staff working on this, and a co-author of the draft.
> 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.
Good call. Such examples mostly live in Geoff's slidepacks at the moment...
> 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.
Serial numbers are discussed in section 4.1.2.2 of RFC 3280:
"Certificate users MUST be able to handle serialNumber values up to 20
octets. Conformant CAs MUST NOT use serialNumber values longer than 20
octets."
> 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.
An example of this in situations where there are contractual or
membership period differences between your upstream and and downstream.
As an APNIC member your APNIC-issued certificates would have validity
related to their typically annual membership, but you might have
relationships with your customers that are expected to last longer. You
can issue certificates to your customer reflecting that longer
relationship, and you don't have to re-issue when your APNIC
certificates are re-issued.
Another example (that just came to mind) is that within a company, you
might delegate resources to different sections. Obviously you expect
those relationships to last indefinitely, and you can reflect that in
the validity period.
> 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?)
I believe there are concerns about the overhead of using unnecessarily
larger keys....
> Section 3.9.1 has a typo, maybe ("cA" vs. "CA")?
No... the ASN.1 definition of BasicConstraints in RFC 3280 calls the
field cA:
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
> 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.
There are two issues here:
1) We want *all* certificates, CRLs, etc to be available and accessible
by only having to implement one protocol. Alternative protocols are
fine, but one protocol is mandatory. This will aid in interoperability.
2) We want a protocol with properties that include fetching complete
trees of objects/files, and, if you already have an old tree, just the
changes. We could implement this in any transport, but RSYNC does this
for free.
> In general, the draft seems to systematically misspell words like
> "authorise" and "recognise", in defiance of the authors' Commonwealth
> origins.
Ummm.... not my call :)
> Also I'm fairly sure "unexpired" is not a word; "non-expired" seems
> better. :-)
Pedant! :-P
Cheers,
Rob
--
Robert Loomans Email: [EMAIL PROTECTED]
Programmer/Analyst, APNIC Phone: +61 7 3858 3100
http://www.apnic.net Fax: +61 7 3858 3199
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Sidr mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sidr
