Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-04.txt

[Sandra Murphy <[e-mail]>]

Steve, Richard, I don't know if you have noticed, but publication has already been requested for this draft.

I don't regard this issue as critical enough to delay publication.  Of course, If the routing AD has comments he wishes to have addressed before he pushes the draft into IETF Last Call, there would be an opportunity to address it as needed then.  Otherwise, it can be addressed as needed as part of IETF Last Call.

Obviously, this issue must exist in any RFC that provides an example of base64 encoded material, due to the RFC line length limit.  I've looked at some of the (many!) other RFCs that refer to rfc4648.  Some say nothing about the fact that line breaks are present in the example, some add a brief phrase about the RFC publication limits, something like Steve's suggestion.  We can temper the need with knowing that history.

--Sandy, speaking as wg co-chair

On May 28, 2015, at 5:34 PM, Stephen Kent <[e-mail]> wrote:

> Richard,
> 
> Sorry to be late replying to your message, but I just returned from a vacation trip.
> 
> I think we can do one of two things to address the problem you correctly
> identified:
>    1- either say that the example in the doc has been formatted for
>       the RFC, and that no LFs are permitted
>    2- adopt your text to explicitly override the "no NL" rule in 4648.
> 
> Steve
> 
>> Hi Geoff, Sam, George, and Steve,
>> 
>> I spotted a bug in this draft:  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.
>> 
>> Section 2.1 doesn't say anything about adding newlines to the Base64
>> string, yet the example in Section 2.3 contains embedded newlines every
>> 57 characters.
>> 
>> Rather than fix the example in Section 2.3 to conform to the current
>> Section 2.1, I think it would be better to permit newlines in the Base64
>> data:
>> 
>>       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 MAY be inserted into
>>           the Base64 encoded string every 40 or more characters.
>> 
>> The choice of 40 is arbitrary; I just didn't want an implementation to
>> be ridiculous and add a newline after only one or a few characters.
>> 
>> I wouldn't mind changing it to "MUST be inserted every 40 to 76
>> characters" to make it possible to write a parser with fixed-length line
>> buffers.
>> 
>> (I also spotted a few typos, sent off-list.)
>> 
>> -Richard
>> 
>> 
>> On 2015-05-15 01:10, [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>  This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.
>>> 
>>>         Title           : Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
>>>         Authors         : Geoff Huston
>>>                           Samuel Weiler
>>>                           George Michaelson
>>>                           Stephen Kent
>>> 	Filename        : draft-ietf-sidr-rfc6490-bis-04.txt
>>> 	Pages           : 9
>>> 	Date            : 2015-05-14
>>> 
>>> 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.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/
>>> 
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-04
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6490-bis-04
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> sidr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sidr
>>> 
>> 
> 
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr