Subject: [sidr] base64 line breaks and draft-ietf-sidr-rfc6490-bis-04.txt

From: Sandra Murphy <[email-masked]>
Date: Tue, 4 Aug 2015 07:06:22 -0400

Speaking as document shepherd.

The IETF Last Call for  draft-ietf-sidr-rfc6490-bis-04.txt  ended on 23 July 2015.

One issue of substance arose - permitting or forbidding line breaks in the base64 encoding of the trust anchor, and, if permitted, at what max line length.

I do not see wg consensus about exact resolution.

Various options and various max line lengths have been suggested.  Existing implementations use various line lengths.

More commenters, please.

Preferences for Richard’s option #2 (allow but do not mandate line breaks) or for Richard’s option #3 (mandate line breaks)?  Note that option #3 means we have to settle on a max line length.

—Sandy

http://www.ietf.org/mail-archive/web/sidr/current/msg07142.html IETF Last Call
http://www.ietf.org/mail-archive/web/sidr/current/msg07164.html Richard Hansen
http://www.ietf.org/mail-archive/web/sidr/current/msg07165.html Tim Bruijnzeels
http://www.ietf.org/mail-archive/web/sidr/current/msg07200.html Richard Hansen
http://www.ietf.org/mail-archive/web/sidr/current/msg07201.html Rob Austein
http://www.ietf.org/mail-archive/web/sidr/current/msg07202.html David Mandelberg
http://www.ietf.org/mail-archive/web/ietf/current/msg94157.html Viktor Dukhovni

---

From: t.petch <[email-masked]>
Date: Tue, 4 Aug 2015 12:44:19 +0100

Option 3.

I see a lot of base64 in e-mail and the line breaks are always there so
I did not know they were taboo.  It would be nice to have a sentence or
two as to why they are needed.

Tom Petch

----- Original Message -----
From: "Sandra Murphy" <[email-masked]>
To: "sidr wg list" <[email-masked]>
Cc: "Sandra Murphy" <[email-masked]>
Sent: Tuesday, August 04, 2015 12:06 PM
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Rob Austein <[email-masked]>
Date: Tue, 04 Aug 2015 09:48:55 -0400

At Tue, 4 Aug 2015 07:06:22 -0400, Sandra Murphy wrote:
> One issue of substance arose - permitting or forbidding line breaks
> in the base64 encoding of the trust anchor, and, if permitted, at
> what max line length.

I know I'm going to regret this, but somebody has to say it.

This is not a substantive issue.  This is an example of:

   https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality

In this case it's even sillier than usual, because we have multiple
interoperable implementations in the field and there is no real
problem here that needs to be solved.  So the bikeshed was built years
ago and we are now arguing about what color it should have been
painted in some alternate universe.

> Preferences for Richard?s option #2 (allow but do not mandate line
> breaks) or for Richard?s option #3 (mandate line breaks)?  Note that
> option #3 means we have to settle on a max line length.

Option #2 matches the running code.

Absent some pressing need to make TALs fit on punch cards, the only
benefit that option #3 brings is the opportunity to declare running
code retroactively out of spec for trivial reasons.

---

From: David Mandelberg <[email-masked]>
Date: Tue, 04 Aug 2015 15:08:04 -0400

On 2015-08-04 07:06, Sandra Murphy wrote:
> Preferences for Richard’s option #2 (allow but do not mandate line
> breaks) or for Richard’s option #3 (mandate line breaks)?  Note that

I have a slight preference for #2 since it probably requires the least 
total work. If somebody down the road really can't handle lines longer 
than X columns, locally re-wrapping lines in a TAL is really easy to do 
in many text editors or scripting languages.

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

---

From: Richard Hansen <[email-masked]>
Date: Wed, 05 Aug 2015 00:39:45 -0400

> code retroactively out of spec for trivial reasons.

I'm confused by your "out of spec" comment.  In what way would option #3
render existing code out of spec where option #2 wouldn't?

The advantage to option #3 is compatibility with OpenSSL's lame base64
implementation.

My stated preference for option #3 should not be taken as a strong
preference.  I am OK with option #2:  it's not much harder for people to
implement (working around OpenSSL's problems is annoying but not
difficult), it puts a tiny bit of pressure on OpenSSL to improve their
implementation, and it avoids the need to decide on a specific maximum
line length.

-Richard