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@ietf.org mailing lists by 2015-07-23. Exceptionally, comments may be
>> sent to iesg@ietf.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.