[JIRA] (OSJ-355) ConcatKDF parameter requirements too restrictive in ECDH

[Stefan Santesson (Jira)]

Stefan Santesson ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=5e1f387fa531f30ca3849078 ) *commented* on OSJ-355 ( https://shibboleth.atlassian.net/browse/OSJ-355?atlOrigin=eyJpIjoiNDNiNjAyYmUxZTJlNDRiYjkwNzlkMjE2M2RkZDFlMGEiLCJwIjoiaiJ9 )

Re: ConcatKDF parameter requirements too restrictive in ECDH ( https://shibboleth.atlassian.net/browse/OSJ-355?atlOrigin=eyJpIjoiNDNiNjAyYmUxZTJlNDRiYjkwNzlkMjE2M2RkZDFlMGEiLCJwIjoiaiJ9 )

Brent. I would say that I agree 100% with assessment here.

I read the same things as you, but what I think is a bit hard as a reader, is how NIST put “ *shall* ” requirements behind optional choices.

In particular in 5.8.2.1 it states that one of the formats defined in 5.8.2.1.1 or 5.8.2.1.2 *“should”* be used. After that it is stated that “ *If* ” you select one of those two formats then the requirements you refer to *“shall”* apply. That actually implies that these rules are recommended but not required.

In the end I personally feel unsure about what it takes to have strict NIST compliance with respect to what a key agreement function MUST support. But in the end that is not all that important for just the reasons you list. NIST compliance is not required by XML enc.

The most important conclusion where we totally agree, is that there should be no negative consequences of relaxing the input requirements and allowing an empty byte array as input.

In our implementation we decided to allow both ““ and “00“ as a representation of an empty byte array to accommodate those who copied the example in the standard. (Which we did encounter from a German dev team effort to implement the standard).

I still think that is the least evil decision.

If you decide to relax these requirements in OpenSAML 4 you would seriously help out on interoperability in the EU eIDAS project as the current recently released node based on OpenSAML 4 can’t decrypt data from any of the existing nodes using implementations that attempted to follow XML enc.

Thanks for considering this!

( https://shibboleth.atlassian.net/browse/OSJ-355#add-comment?atlOrigin=eyJpIjoiNDNiNjAyYmUxZTJlNDRiYjkwNzlkMjE2M2RkZDFlMGEiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/OSJ-355#add-comment?atlOrigin=eyJpIjoiNDNiNjAyYmUxZTJlNDRiYjkwNzlkMjE2M2RkZDFlMGEiLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100201- sha1:66eda1f )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20220628/4ff7f5e0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-dc6816d4-cc78-47c6-b4c8-e158db3323f3
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220628/4ff7f5e0/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-7f142e32-d4d5-493b-83dd-7c530fb6813d
Type: image/png
Size: 425 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220628/4ff7f5e0/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-a7a7a4d5-a90c-4c73-a30c-4d3e1c526ca7
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220628/4ff7f5e0/attachment-0005.png>