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@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.