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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 30 July 2015 16:08 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9F01A9148 for <ietf@ietfa.amsl.com>; Thu, 30 Jul 2015 09:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsGZG9XYx00M for <ietf@ietfa.amsl.com>; Thu, 30 Jul 2015 09:08:11 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5D71A01CB for <ietf@ietf.org>; Thu, 30 Jul 2015 09:08:11 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3D416284D64; Thu, 30 Jul 2015 16:08:10 +0000 (UTC)
Date: Thu, 30 Jul 2015 16:08:10 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: [sidr] Last Call: <draft-ietf-sidr-rfc6490-bis-04.txt> (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard
Message-ID: <20150730160809.GW4347@mournblade.imrryr.org>
References: <20150709134637.7120.70507.idtracker@ietfa.amsl.com> <55A5E727.7020605@bbn.com> <55B97546.3060200@bbn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <55B97546.3060200@bbn.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/_1ece2syHOIWPswd2AvHZ4EepA4>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2015 16:08:16 -0000

On Wed, Jul 29, 2015 at 08:52:22PM -0400, Richard Hansen wrote:

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

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.