Subject: Re: [sidr] Last Call: <draft-ietf-sidr-rfc6490-bis-04.txt> (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard

From: Richard Hansen <[email-masked]>
Date: Wed, 15 Jul 2015 00:52:55 -0400

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
> [email-masked] mailing lists by 2015-07-23. Exceptionally, comments may be
> sent to [email-masked] 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.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 15 Jul 2015 10:55:01 +0200

Hi,

> On Jul 15, 2015, at 6:52 AM, Richard Hansen <[email-masked]> wrote:
> 
> inserted every 79 or fewer characters. 

I am fine with this option. I agree that it's better to have this explicit. De facto this is what everyone is doing now, and I see no issues with our running code (both trust anchor code producing TALs, and validator code parsing this).

Regards

Tim Bruijnzeels

(RIPE NCC)

---

From: Richard Hansen <[email-masked]>
Date: Wed, 29 Jul 2015 20:52:22 -0400

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:

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

---

From: Rob Austein <[email-masked]>
Date: Thu, 30 Jul 2015 11:51:33 -0400

I think that requiring line breaks is silly.  Most Base64 parsers
handle arbitrary whitespace.  OpenSSL's parser is just plain nasty
(yes, I once made the mistake of reading the code), but even with
OpenSSL's parser there's a straightforward (if ridiculous) workaround:

   http://subvert-rpki.hactrn.net/trunk/rp/rcynic/bio_f_linebreak.c
   http://subvert-rpki.hactrn.net/trunk/rp/rcynic/bio_f_linebreak.h

I really don't think we need to enshrine OpenSSL's warts in the
specification.

I prefer Richard's option 2 (allow but do not require linebreaks),
which is what RFC 6490 RP implementations had to support anyway.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 Jul 2015 16:08:10 +0000

>           the Base64 encoded string every 76 or fewer characters.

If there are linebreaks, for best interoperability, each line should
contain a multiple of 4 base64 output characters, so that the
decoder can process each line without buffering "left-over" data
from the previous line.

Thus whether the width is 76 (from MIME) or 64 (from PEM), ...  it
should be a multiple of 4.

    http://tools.ietf.org/html/rfc4648#section-3.1

Of course if no line breaks are inserted, then the issue does not
arise.

-- 
	Viktor.

---

From: David Mandelberg <[email-masked]>
Date: Thu, 30 Jul 2015 20:05:29 -0400

> every 75.  So I think 76 is a better choice.

For what it's worth, here are line lengths from an assortment of TALs I 
had lying around.

afrinic.tal: 64
apnic-rpki-root-afrinic-origin.tal: 64
apnic-rpki-root-arin-origin.tal: 64
apnic-rpki-root-iana-origin.tal: 64
apnic-rpki-root-lacnic-origin.tal: 64
apnic-rpki-root-ripe-origin.tal: 64
arin.tal: 80
lacnic.tal: 64
ripe-ncc-root.tal: 55
ripe-pilot.tal: 78

Of these, one production TAL (arin.tal) and one non-production TAL 
(ripe-pilot.tal) are longer than 76. However, TALs are generally only 
used locally, and re-wrapping text is rather easy. So I don't think the 
existing TALs should have too large of an impact on whatever decision we 
make.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/