OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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/

Attachment: signature.asc
Description: OpenPGP digital signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]