Add trait: Global government-approved crypto

[jceb]

As pointed out in decentralized-identity/did-methods#10 (comment), I think this is a good trait to integrate.

[jceb]

Example definition:

{
    "cryptography_government-approved": {
      "type": "boolean",
      "title": "Government-approved Cryptography",
      "description": "A DID method that implements cryptographic algorithms and protocols explicitly validated and recommended by national cryptographic standards bodies. Example: FIPS 186-4."
    }
}

[ottomorac]

This is not a bad idea as was suggested by @msporny . However I am not sure how would we quantify which government bodies would be valid? For instance if we only restrict this to ENISA and NIST, this might leave out less known government bodies that deal with cryptography from other nations. I know for a fact that Canada also has its own 2 entities: Canadian Centre for Cyber Security (CCCS) and Standards Council of Canada (SCC).

My thoughts are that overall this is not a bad suggestion but let's be very explicit about the definition so as to not make "US and Europe Centric". Another more open definition could be perhaps "At least 2 countries have approved the cryptography associated with the did method". This would be a more flexible definition than restricting to ENISA and NIST.

[msporny]

Yes, agreed that we don't want to make this EU or US centric. The general suggestion is: If we rely solely on cryptography that NO government's national standards bodies have accepted, the DID Method is probably not going to see uptake by governments (who are one of the main authorities that issue credentials). I think all we're looking for here is that the DID Method is flexible in what cryptography it supports (both for the cryptographic ledger and for the verification methods).

For example, a DID Method that supports ECDSA secp256r1 for the ledger and the verification methods is an example of "broadly supported government cryptography". However, one that only supports secp256k1 is a non-starter for many governments because they can't cite it in any national standards and don't have a cryptographic module validation program for it.

That is not to say that DID Methods can't also support secp256k1, flexibility is good, but if a DID Method doesn't meet at least some minimum national standard, it's going to be an uphill battle to get it used broadly.

[mccown]

This would be a helpful trait, but can a moving target as governments occasionally change their cryptography standards. It would also be important to state things like which government, validity dates, reference the gov't standard, etc.

Adding to @jceb's snippet above, it might look something like this:

{
    "cryptography_government-approved": {
      "type": "boolean",
      "title": "Government-approved Cryptography",
      "nation": ["US", "UK", ... ],
      "valid_until" : "2030-01-01",
      "description": "A DID method that implements cryptographic algorithms and protocols explicitly validated and recommended by national cryptographic standards bodies. Example: FIPS 186-4 (with a link to the national standard's page)."
    }
}

[msporny]

This would be a helpful trait, but can a moving target as governments occasionally change their cryptography standards.

Sure, I think what we're looking for here is the ability to just cite the government cryptography standard that the DID Method supports (both for the verifiable data registry/DLT and the verification methods).

I'll also note that the government cryptography standards /rarely/ change. Having some insight into some of those processes, it takes /years/ for new revisions to come out, with document refresh cycles between 5-7 years between refreshes, and even then, not much changing.

[msporny]

I wonder if we don't need to list the nation, but just the standard. For example, there are many nations that just depend on NIST's recommendations (and put a thin national layer on top of the NIST recommendation).

[mccown]

@msporny great points. I think I'm reflecting on what "government approved" means. DID Methods can rely on a NIST standard and can update that at any time. However, by adding "government approved" without stating which government, it could be confusing.

For example, suppose that a DID Method in Country X uses NIST crypto as per Country X's policy. At some point, if Country X changes their crypto requirements (while the NIST standard is still valid) what does "government approved" mean? The NIST standard would still be "government-approved" by the US, but not by Country X.

[jceb]

Thank you all for your feedback. The definition of this trait has been refined and now requires support for cryptographic algorithms that are in use by at least two standardization bodies. Please take a look at the current definition: https://identity.foundation/did-traits/#cryptographyGovernmentApproved . If you're fine with it, I'll close this issue in the next days.

@mccown DID Traits are all of type boolean. At this stage, we're not planning to track additional information like the supported standards. Maybe such metadata can be added in the future.

[mccown]

@jceb I like the "explicitly validated and recommended by two national cryptographic standards bodies" approach.

That will help convey the understanding that the "approval" refers more to the technical merit than a national legislative requirement. I hadn't thought of using two party endorsement that way and I think it is a great one.

[msporny]

@jceb I like the "explicitly validated and recommended by two national cryptographic standards bodies" approach.

Hmm, I'm concerned that "two" might be one too many. :)

For example, (and to be slightly provocative to make the point) I don't know if these cryptographic protocols would meet that bar, but it's clear that a DID Method would need to support them if it were to be used for certain use cases within these national boundaries:

• Suite A - used by US NSA, but not publicly disclosed or standardized.
• ShangMi - used by China, primarily within its borders.
• GOST - used by Russia, primarily by government and within its borders.

If a DID Method wanted to operate in those national borders, it would need to meet the "government-approved crypto" requirement. That's the trait I was trying to get at... it didn't have to do about breadth of support... it had to do with depth: "Do you meet the needs of the use cases desired by a particular nation state?"

[mccown]

@msporny that makes sense as 1 is certainly simpler. However, with 2 it appears like a tech endorsement, but with 1 it appears like a national policy choice.

If a DID Method uses the "government-approved crypto" trait, how will a user/developer know if their own government approves of that crypto?

[jceb]

I am wondering how to shape this trait to make it valuable. The single trait with a boolean value feels not valuable when move away from the 2 governments that approved the crypto. Even the approval by 2 governments isn't very helpful when none of them is my government.

It feels like we'd be better off creating an individual trait for each cryptographic protocol or standards body. From the perspective of DID method author, who will create the first trait assessment, I think assessing cryptographic protocols feels closer to the work of DID method creation than figuring out which protocols are supported by which standards body.

What do you think about creating an individual trait for each cryptographic protocol?

[msporny]

What do you think about creating an individual trait for each cryptographic protocol?

Yes, that feels like it would work, there aren't that many of them:

• Supports FIPS 140-3 (ECDSA and EdDSA)
• Supports FIPS 203 (ML-KEM)
• Supports FIPS 204 (ML-DSA)
• Supports FIPS 205 (SLH-DSA)
• Supports ShangMi (SM)
• Supports GOST (R 34.10)

If we had traits for each one of those, I think we're covered for most of the world. If a new one comes along, we can add it fairly easily.

WDYT?

[jceb]

Awesome, thank you for the list! I'll create a trait for each of them. This clearly provides value while not putting an overly heavy burden on the list of traits. 👍🙏

[ottomorac]

Hello. Sorry to keep jumping in here. And I apologize if this comes across as pedantic, but the intention to keep to 2 governments or more was precisely to keep the list from exploding into too many. So if we are going this route, then let me make some suggestions.

As I understand the list suggested by @msporny would cover:

• US NIST (FIPS family)
• China (ShangMi)
• Russia (Ghost)

This still seems a bit concentrated to me. So how about the following?

• Europe - Some ETSI and ENISA lists might be useful
• Israel - SCALPEL
• Canada CSE - ITSG-31and ITSG-38
• Japan - CRYPTREC
• South Korea - KCMVP
• India - CCA
• Australia - Australian Signals Directorate (ASD)
• Brazil - ICP-Brasil
• United Arab Emirates (UAE) - Telecommunications and Digital Government Regulatory Authority

Let me know your thoughts.

[msporny]

This still seems a bit concentrated to me. So how about the following?

Most national cryptographic standards bodies just follow what NIST does, plus they sometimes introduce their own "national curves".

Warning, table below is summarized by AI (might be inaccurate in places), but it (more or less) matches my understanding. If anyone can see any errors, please say so, but this is why I'm not sure we need to list every national cryptographic standards body (since many of them are, more or less, a copy-paste of what NIST/FIPS has approved:

Region/Body	Supported Curves
US NIST	secp256r1, secp384r1, secp521r1, ed25519, ml-dsa, slh-dsa
China (SM)	SM2 curve (256-bit)
Russia (GOST)	GOST-256, GOST-512
Europe (ETSI/ENISA)	secp256r1, secp384r1, secp521r1, BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1
Israel (SCALPEL)	secp256r1, secp384r1, Brainpool
Canada (CSE)	secp256r1, secp384r1, secp521r1
Japan (CRYPTREC)	secp256r1, secp384r1, secp521r1
South Korea (KCMVP)	K-256, secp256r1
India (CCA)	secp256r1, secp384r1
Australia (ASD)	secp256r1, secp384r1, secp521r1, Brainpool
Brazil (ICP-Brasil)	secp256r1
UAE (TDRA)	secp256r1, secp384r1

I'm not opposed to listing every national body, but it seems like there are more of those than there are supported cryptographic curves. :P

[jceb]

We concluded in today's call, that we want to list the supported curves / key types rather than standards bodies. This will be closer to the core idea of technical traits and less volatile if a standards body make a change to the approved list of key types. The next step is to replace the standards bodies' traits with curve and key type traits.