There is one substantive issue I noticed: embedded newlines in the
Base64 string.
Section 2.1 refers to Base64 encoding, defined in RFC4648 Section 4.
RFC4648 Section 3.1 says:
Implementations MUST NOT add line feeds to base-encoded data unless
the specification referring to this document explicitly directs base
encoders to add line feeds after a specific number of characters.
This draft does not say anything about adding newlines to the Base64
string, yet:
* all published TALs (that I could find) contain embedded newlines at
regular intervals, in violation of this specification
* the example in Section 2.3 contains embedded newlines every 57
characters
All existing implementations support embedded newlines at arbitrary
places in the Base64 string, including multiple newlines in a row (if
I'm reading everyone's code correctly).
I see three possible fixes:
1. Add a note next to the example in Section 2.3 that says that
newlines were added to the example due to line length limitations
in the RFC format. Encourage TAL publishers to fix their TALs by
removing the embedded newlines.
2. Permit but don't require newlines. For example, change Section 2.1
item #3 from:
3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509],
encoded in Base64 (see Section 4 of [RFC4648].
to:
3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509],
encoded in Base64 (see Section 4 of [RFC4648]). To avoid
long lines, <CRLF> or <LF> line breaks MAY be inserted into
the Base64 encoded string.
3. Require line breaks in the Base64 string. For example, change
Section 2.1 item #3 from:
3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509],
encoded in Base64 (see Section 4 of [RFC4648].
to:
3) a subjectPublicKeyInfo [RFC5280] in DER format [X.509],
encoded in Base64 (see Section 4 of [RFC4648]). To avoid
long lines, a <CRLF> or <LF> line break MUST be inserted into
the Base64 encoded string every 75 or fewer characters.
I prefer option #3. If I understand correctly, OpenSSL's Base64 BIO
filter has two modes: no newlines permitted or newlines must be
inserted every 79 or fewer characters. The mode is not automatically
detected; the programmer must choose which mode to use. If the standard
guarantees that all lines will be shorter than 79 characters, then
OpenSSL's Base64 BIO filter can be used without any preprocessing. (The
choice of 75 is more-or-less arbitrary. Keeping it less than 80 is
important for OpenSSL compatibility. MIME (RFC2045) and vCard (RFC6350)
both require Base64 strings to be broken up every 75 or fewer
characters, and I figured it might be good to match.)
My second choice is option #2. It still requires preprocessing before
OpenSSL's Base64 BIO filter can be used, but it permits existing practice.
Option #1 is my least favorite. It is the least disruptive to the
document, but it still requires modifying the document so we might as
well modify it to permit existing practice. (Also, getting all of the
RIRs to fix their TALs is probably more work than changing the
specification.)
Nits:
* section 2.1, item 3: missing close parenthesis
* section 2.1: "comprised of" should be "composed of"
* section 2.1: "one of more" should be "one or more"
* section 3, item 4: "These test" should be "These tests"
* regressions of comma changes made by the RFC Editor before RFC6490
was published
-Richard
On 2015-07-09 09:46, The IESG wrote:
>
> The IESG has received a request from the Secure Inter-Domain Routing WG
> (sidr) to consider the following document:
> - 'Resource Public Key Infrastructure (RPKI) Trust Anchor Locator'
> <draft-ietf-sidr-rfc6490-bis-04.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@xxxxxxxx mailing lists by 2015-07-23. Exceptionally, comments may be
> sent to iesg@xxxxxxxx instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document defines a Trust Anchor Locator (TAL) for the Resource
> Public Key Infrastructure (RPKI). This document obsoletes RFC6490 by
> adding support for multiple URIs in a TAL.
>
>
> A down reference exists in this document by using RFC5781 as a Normative
> Reference. RFC5781 has already been accepted by the community as a down
> reference and is properly documented in the DOWNREF Registry.
>
> The DOWNREF Registry can be accessed via
> https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.