IETF Logo Mail Archive

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

Tim Bruijnzeels <tim@ripe.net> Wed, 15 July 2015 08:55 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBE11A004A; Wed, 15 Jul 2015 01:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 saHNT1LJMnlV; Wed, 15 Jul 2015 01:55:05 -0700 (PDT)
Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20D11A0053; Wed, 15 Jul 2015 01:55:02 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1ZFISx-0007gc-22; Wed, 15 Jul 2015 10:55:00 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-13.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1ZFISw-0002oa-Tn; Wed, 15 Jul 2015 10:54:58 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <55A5E727.7020605@bbn.com>
Date: Wed, 15 Jul 2015 10:55:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F6DFD09-0831-413E-AC52-05DE95F78929@ripe.net>
References: <20150709134637.7120.70507.idtracker@ietfa.amsl.com> <55A5E727.7020605@bbn.com>
To: Richard Hansen <rhansen@bbn.com>
X-Mailer: Apple Mail (2.2102)
X-RIPE-Spam-Level: ----
X-RIPE-Spam-Report: Spam Total Points: -4.3 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719fb9f102c736404b2367677c278e2b05a
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/QMkovcH9Y_OvHYWrvMPSgaYLfbA>
Cc: ietf@ietf.org, sidr@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
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2015 08:55:06 -0000

Hi,

> On Jul 15, 2015, at 6:52 AM, Richard Hansen <rhansen@bbn.com> wrote:
> 
> 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. 

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)

v2.23.0 | Report a Bug | By Email