NONCONFIDENTIAL // EXTERNAL
I donât suppose anyone has a PowerShell, or .NET/C# example? I see where the bas32 encode happens, of the SHA256 string, but I donât understand the â.digest()â part. Is that
what removes the padding? The examples I find talk about digest being a count of digits.
The tools online, when I put in a sha256 string, return a 104 character response to base32 encoding, so I think it is missing something related to the padding.
Sorry, I am not a developer, but trying to learn more. I know powershell, but that is not a development language, so my info is limited. I did read RFC 4648 and it helped explain
what Philip said about the 5 bits being represented by one character, but the encoding table only accounts for alphanumeric, none of the â:ââs
Anyway, sorry for the ânewbâ questions, just trying to learn more.
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 Pim van der Eijk
Sent: Tuesday, July 7, 2020 5:02 AM
To: Kenneth Bengtsson <kbengtsson@efact.pe>; 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.
|
Python 2.7.17 (default, Apr 15 2020, 17:20:14)
[GCC 7.5.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> id = 'urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088:4035811991021'
>>> from hashlib import sha256
>>> from base64 import b32encode
>>> encoded = b32encode(sha256(id).digest()).rstrip('=')
>>> print encoded, len(encoded)
I3QYB36CTAYRFGTHBYCQZDTOJFHGAZJEGLFOOE7727EGVDWRK5QQ 52
On 07-07-2020 11:49, Kenneth Bengtsson wrote:
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:
- You generate a sha256 hash from the party identifier. This produces a 64 character string.
- The 64 character hash string is base32 encoded. This produces a new 104 character string.
- 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
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 ..
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.