Hi all,
I misread the MIME RFC; it requires line breaks every 76 characters, not
every 75. So I think 76 is a better choice.
My new proposal is to 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 76 or fewer characters.
(This is the same as option #3 in my previous email but with 76 instead
of 75.)
-Richard
On 2015-07-15 00:52, Richard Hansen wrote:
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(_at_)ietf(_dot_)org mailing lists by 2015-07-23. Exceptionally,
comments may be
sent to iesg(_at_)ietf(_dot_)org 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.