RE: [bdxr] Agenda for Atlantic BDXR TC call 24 June 2020 15:00UTC

["Weddig, Dennis" <dennis.weddig@mpls.frb.org>]

NONCONFIDENTIAL // EXTERNAL

Thank you all, I was running into this as well!

 

FEDERAL RESERVE BANK OF MINNEAPOLIS
Pursuing an economy that works for all of us

 

Dennis Weddig
Platform Engineer, Technology and Risk Group
W 612-204-6370

@minneapolisfed  I  minneapolisfed.org

 

â01000111 01000001 01001101 01000101 00100000 01001111 01001110 00100001â

 

From: bdxr@lists.oasis-open.org <bdxr@lists.oasis-open.org> On Behalf Of Kenneth Bengtsson
Sent: Tuesday, July 7, 2020 5:35 AM
To: Philip Helger <philip@helger.com>; Pim van der Eijk <pvde@sonnenglanz.net>; bdxr@lists.oasis-open.org
Subject: [External] Re: [bdxr] Agenda for Atlantic BDXR TC call 24 June 2020 15:00UTC

 

NONCONFIDENTIAL // EXTERNAL

 

PLEASE NOTE: This email is not from a Federal Reserve address.

Do not click on suspicious links. Do not give out personal or bank information to unknown senders.

 

Thanks both! Figured it out at the end (was using the hex string of the sha256 hash).

 

/Kenneth

 

 

 

From: Philip Helger <philip@helger.com>
Date: Tuesday, July 7, 2020 at 12:07 PM
To: Kenneth Bengtsson <kbengtsson@efact.pe>, Pim van der Eijk <pvde@sonnenglanz.net>, "bdxr@lists.oasis-open.org" <bdxr@lists.oasis-open.org>
Subject: Re: [bdxr] Agenda for Atlantic BDXR TC call 24 June 2020 15:00UTC

 

Hi Kenneth,

the output of a SHA256 algorithm is 256 Bits or 32 bytes. Through the usage of Base32 encoding (RFC 4648) each 5 Bits become a new byte.

As such the 32 * 8 / 5 = 51,2 rounded up to 52 chars.

As such we're below the 63 chars.

BR, Philip

 

Am 07.07.2020 um 11:49 schrieb Kenneth Bengtsson:

Hi Pim

 

Just a follow up question:

 

Iâm reading about the formatting of the BDXL record here: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+BDXL+1.6#eDeliveryBDXL1.6-ConstructingtheDNSquery. If I understand correctly, then:

 

1. You generate a sha256 hash from the party identifier. This produces a 64 character string.
2. The 64 character hash string is base32 encoded. This produces a new 104 character string.
3. Any trailing â=âs are removed. The final string is then 100+ character.

 

However, any single label in a DNS name cannot be more than 63 characters long. How do you get around that?

 

/Kenneth

 

 

 

From: <bdxr@lists.oasis-open.org> on behalf of Pim van der Eijk <pvde@sonnenglanz.net>
Date: Friday, June 26, 2020 at 11:50 AM
To: "bdxr@lists.oasis-open.org" <bdxr@lists.oasis-open.org>
Subject: Re: [bdxr] Agenda for Atlantic BDXR TC call 24 June 2020 15:00UTC

 

 

On 24-06-2020 14:21, Kenneth Bengtsson wrote:

Hi Pim

 

Glad your following the work in the TC even if not attending meetings! :-)

 

We havenât started discussing the format of the hostname yet, nor whether this should be prefixed or which hashing algorithm to use. Our observation is that different implementers are implementing different algorithms (as you are also pointing out), which drives up complexity and cost for software developers and integrators. Backwards compatibility is an inevitable issue when standardizing something that hasnât been standardized before. The appropriate RFC 2119 keyword for a backwards compatible spec would probably be âSHOULDâ.

 

/Kenneth

 

If you go for a recommendation,  the eDelivery BDXL format convention would be the better option than the old one from SML as it avoids the useless (and possibly problematic) "B-" prefix and uses a more capable hashing algorithm.  It is the outcome of extensive discussions ..

 

 

 

-- 

Philip Helger

Philip Helger IT Consulting e.U.

Skype: phelger

Twitter: @philiphelger

GitHub: https://github.com/phax

LinkedIn: https://www.linkedin.com/in/void0/

This e-mail message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message.