cryptoSubClass values associated to the new cryptoClass values

[toscalix]

Background

There is a new List structure based on an extended number of cryptoClass values.

• Check cryptoClass and cryptoSubClass properties description #71 the new cryptoClass values do not have any cryptoSubClass value associated at this point.
• Check the umbrella ticket for all the work on restructuring the list Restructure the List: cryptoClass and cryptoSubClass #68

Rationale

It would be ideal to classify the algorithms under the new cryptoClass values, that is:

• Message-Authentication-Code
• Key-Derivation-Function
• Random-Number-Generator

by cryptoSubClass values

Description

Define values for the cryptoSubClass property corresponding to the following cryptoClass

• Message-Authentication-Code
• Key-Derivation-Function
• Random-Number-Generator

Add the description to the corresponding list properties description document and add the values to the affected algorithms from the list (yaml files).

Actions

• Create a proposal
  • Provide a rationale, the proposed values and the list of algorithms affected
• Reach consensus about the proposal within the Cryptography Group
• Submit the PR
  • Include the content for the properties description file and the algorithms affected
• Review and approve the PR

DoD

• Link to the proposal
• Consensus reached?
• Link to the PR
• Lin to the new List's properties description .md file

[toscalix]

Summary table

cryptoClass	cryptoSubClass values
Message-Authentication-Code	HMAC, Block-Cipher-MAC, Universal-Hash-MAC
Key-Derivation-Function	Password-Based, Key-Based, Protocol-Specific
Random-Number-Generator	TRNG, DRBG, PRNG

1. Message-Authentication-Code

Proposed cryptoSubClass values

Value	Description	Algorithms in current list
HMAC	Hash-based Message Authentication Code. Constructs a MAC by applying a cryptographic hash function to a combination of the message and a secret key, as defined in RFC 2104 and FIPS 198-1.	(none yet; HMAC-SHA variants are candidates for Issue #43)
Block-Cipher-MAC	MAC constructed using a block cipher as the underlying primitive. Includes CBC-MAC and its variants.	CMAC
Universal-Hash-MAC	MAC based on universal hashing or stream-cipher polynomial evaluation, providing high-performance authentication.	(none yet; Poly1305, UMAC are candidates)

Notes

• GMAC (Galois Message Authentication Code) is the authentication component of GCM mode. If added to the list as a standalone entry, it would fit under Block-Cipher-MAC. Its relationship to block cipher modes is noted but does not require resolution in this issue.
• KMAC (Keccak-based MAC, defined in NIST SP 800-185) could be argued to belong under HMAC (as a hash-based construction) or as a distinct value. Given the current list scope, placing KMAC-family algorithms under HMAC is the simpler choice. The group may revisit if KMAC entries are added in volume.

2. Key-Derivation-Function

Proposed cryptoSubClass values

Value	Description	Algorithms in current list
Password-Based	KDF designed to derive cryptographic keys from a human-readable password or passphrase, typically incorporating a salt and an intentionally slow computation to resist brute-force attacks. Defined in NIST SP 800-132 and RFC 8018.	pbkdf1, pbkdf2, pbe, pbes1, pbes2, argon2
Key-Based	KDF that derives one or more keys from existing keying material (a master secret, shared secret, or session key) rather than a password. Includes extraction-then-expansion schemes (e.g., HKDF, RFC 5869) and counter/feedback/pipeline modes (NIST SP 800-108).	(none yet; HKDF is a candidate for Issue #43)
Protocol-Specific	KDF tightly integrated into a specific protocol, where the derivation logic is defined as part of the protocol specification itself rather than as a standalone primitive.	(none yet; TLS PRF, IKEv2 PRF are candidates)

Notes

• Overlap with Cryptographic-Hash-Function/Password-Hashing: bcrypt, mscash, and mscash2 are currently classified under Cryptographic-Hash-Function/Password-Hashing. Password hashing algorithms are a specialisation of password-based KDFs. Whether these entries migrate to Key-Derivation-Function/Password-Based is a policy question that requires an explicit group decision. This proposal does not resolve it; it should be tracked as a separate item under Issue Restructure the List: cryptoClass and cryptoSubClass #68 or a new issue.

3. Random-Number-Generator

Proposed cryptoSubClass values

Value	Description	Algorithms in current list
TRNG	True Random Number Generator. Derives randomness from a physical entropy source (hardware noise, thermal fluctuations, etc.) rather than a deterministic algorithm. Not seed-reproducible.	(none yet; OS/hardware entropy sources are candidates)
DRBG	Deterministic Random Bit Generator. A cryptographically secure, seed-based algorithm that expands a secret seed into an arbitrarily long sequence of pseudo-random bits. Includes NIST SP 800-90A constructions (Hash_DRBG, HMAC_DRBG, CTR_DRBG) and accumulator-based designs that meet cryptographic security requirements.	fortuna, yarrow, isaac
PRNG	Non-cryptographic Pseudo-Random Number Generator. Produces statistically uniform sequences suitable for simulation and general-purpose use, but does not provide cryptographic security guarantees. Included in the list to support identification of these algorithms in software contexts where their use in place of a CSPRNG would be a security concern.	(none yet; MT19937, PCG, LCG are candidates)

Notes

• fortuna and yarrow are accumulator-based CSPRNGs. Both qualify as DRBG under the broader definition used here (deterministic, cryptographically secure, seed-based).
• isaac is a stream-cipher-based CSPRNG. It qualifies as DRBG under the same definition, though it predates the NIST SP 800-90A framework.
• PRNG inclusion rationale: Non-cryptographic PRNGs are not cryptographic primitives, but their presence in software analysed for SBOM purposes is security-relevant. Identifying them as Random-Number-Generator/PRNG allows tooling to flag their use in contexts requiring cryptographic randomness. This mirrors the list's existing practice of including deprecated and broken algorithms for traceability reasons (see the Algorithm Inclusion and Removal Criteria document).

Open questions for the Cryptography Group

1. Password hashing vs. password-based KDF: Should bcrypt, mscash, and mscash2 move to Key-Derivation-Function/Password-Based, or should Password-Hashing be retained as a subclass under Cryptographic-Hash-Function? This has implications for the Cryptographic-Hash-Function subclass list as well.
2. KMAC placement: If KMAC128/KMAC256 are added (Issue Algorithms that might turn into candidates for SPDX #43), should they go under Message-Authentication-Code/HMAC or warrant a new Keccak-MAC subclass?
3. PRNG inclusion scope: Does the group wish to include non-cryptographic PRNGs (MT19937, PCG, etc.) in the list? If not, the PRNG subclass value can be deferred or removed from this proposal.

[toscalix]

Algorithms affected

Subclass to be added (cryptoClass already correct)

These files already carry the correct top-level cryptoClass following PR#71. They only need the cryptoSubClass property added.

File	Current cryptoClass	Proposed cryptoSubClass
pbkdf1.yaml	Key-Derivation-Function	Password-Based
pbkdf2.yaml	Key-Derivation-Function	Password-Based
pbe.yaml	Key-Derivation-Function	Password-Based
pbes1.yaml	Key-Derivation-Function	Password-Based
pbes2.yaml	Key-Derivation-Function	Password-Based
argon2.yaml	Key-Derivation-Function	Password-Based
fortuna.yaml	Random-Number-Generator	DRBG
yarrow.yaml	Random-Number-Generator	DRBG
isaac.yaml	Random-Number-Generator	DRBG

cryptoClass and subclass both to be updated

File	Current cryptoClass	Proposed cryptoClass	Proposed cryptoSubClass
cmac.yaml	Cryptographic-Hash-Function/Message-Authentication-Code	Message-Authentication-Code	Block-Cipher-MAC

Pending explicit group policy decision

These files are currently classified under Cryptographic-Hash-Function/Password-Hashing. Whether they should migrate to Key-Derivation-Function/Password-Based requires a group decision before any change is made to these files.

File	Current cryptoClass	Question
bcrypt.yaml	Cryptographic-Hash-Function/Password-Hashing	Move to Key-Derivation-Function/Password-Based?
mscash.yaml	Cryptographic-Hash-Function/Password-Hashing	Move to Key-Derivation-Function/Password-Based?
mscash2.yaml	Cryptographic-Hash-Function/Password-Hashing	Move to Key-Derivation-Function/Password-Based?

[toscalix]

Proposal: cryptoSubClass values for Message-Authentication-Code, Key-Derivation-Function, and Random-Number-Generator

This is a more mature proposal. It includes criteria that justifies the proposal because there might be debate in some points. The following considerations apply:

• I focused on areas of agreement, deferring points of debate whenever possible.
  • The list is in early stages and there is a lot we can do before getting into debates about cryptoSubClass specific values
• It would be ideal to have at least one algorithms for each cryptoSubClass
  • I would prioritize the addition of those algorithms right after the approval of this, or an evolved version of this, proposal
• I have created this proposal compiling existing knowledge, documents and with the help of several AI services. But I am not a subject matter expert so there might be errors in my interpretations.
  • I add the references, rules and design criteria for a fair evaluation of the proposal by experts.
  • My main goal is to facilitate consensus within the Cryptography Group

Related issue: #72
Related umbrella issue: #68
Related PR: #71

Summary table

cryptoClass	cryptoSubClass values
Message-Authentication-Code	Hash-Based-MAC, Block-Cipher-MAC, Polynomial-MAC
Key-Derivation-Function	Password-Based, Key-Based
Random-Number-Generator	TRNG, DRBG

Four further questions — the bcrypt/mscash reclassification, the inclusion of non-cryptographic PRNGs, whether DRBG should be split into NIST-conformant and other CSPRNGs, and whether a Protocol-Specific KDF subclass should be added — are presented as separate decision blocks at the end of this proposal. They are deliberately separated so that they can be approved, deferred, or rejected without blocking the main taxonomy.

Methodology

The proposed values are derived from three sources, in order of priority:

1. Algorithms already in the list — the subclasses must cover every algorithm currently classified under each of the three cryptoClass values, including those that will migrate from their previous classification.
2. Normative standards — primary references:
   • MACs: FIPS 198-1 (HMAC), NIST SP 800-38B (CMAC), NIST SP 800-185 (KMAC and other SHA-3 derived functions), RFC 8439 (ChaCha20-Poly1305).
   • KDFs: NIST SP 800-132 (PBKDF), NIST SP 800-108 (key-based KDFs in counter/feedback/pipeline mode), NIST SP 800-56C (two-step KDFs), RFC 8018 (PKCS Characteristic of a hash/encrypted output #5 password-based cryptography), RFC 5869 (HKDF).
   • RNGs: NIST SP 800-90A Rev. 1 (DRBGs), NIST SP 800-90B (entropy sources / TRNGs), NIST SP 800-90C (RBG constructions).
3. The metaeffekt taxonomy — used as a reference for coverage gaps and structural ideas, filtered through the group's governance process.

Each subclass below carries a classification rule in addition to its description. The rule is the operational test a contributor or reviewer applies to decide whether a given algorithm belongs in that subclass.

The taxonomy rests on three explicit design principles, stated in the next section. The values, rules, and decision blocks throughout this document all follow from those principles.

Design principles

These principles govern both this proposal and the evaluation of any future cryptoSubClass additions. They are stated explicitly so that reviewers can apply them consistently and so that subsequent contributions have a stable framework to reason against.

Principle 1 — Subclasses classify by structural properties. A cryptoSubClass value distinguishes algorithms by their structural properties: construction (e.g., block-cipher-based vs. hash-based), input domain (e.g., password vs. full-entropy key), or output type. The test is "what is this algorithm?", not "where is it used?".

Principle 2 — Subclasses do not encode deployment context or certification status. Where an algorithm is deployed (host protocol, application layer) and which standards body has approved it (NIST conformance, FIPS validation) are not subclass distinctions. Those signals are carried in other YAML properties (standards, references, and similar) so that the taxonomy remains a description of algorithms rather than a description of compliance regimes.

Principle 3 — Subclasses are introduced only when an algorithm requires them. A new subclass value is added when at least one existing or planned algorithm needs it for accurate classification. Forward-looking values with no occupants are deferred to the future PR that introduces the algorithm requiring them. This keeps the taxonomy small enough to apply consistently and avoids reserving terminology before its meaning is fixed by use.

These principles are consistent with the list's existing structure (e.g., AES is not subclassed by host protocol, nor by FIPS validation status) and with the goals of PR#71 (a clean, construction-based top-level taxonomy).

1. Message-Authentication-Code

Hash-Based-MAC

Description. MAC constructed using a cryptographic hash function as the underlying primitive. Covers the HMAC construction (RFC 2104, FIPS 198-1), Keccak-based MACs such as KMAC (NIST SP 800-185), and keyed hash functions used as MACs (e.g., BLAKE2 keyed mode, SipHash).

Classification rule. Apply this value when the MAC's security argument reduces to the underlying hash function's properties (collision resistance, pseudo-randomness as a keyed function), regardless of whether the specific construction is HMAC, KMAC, or a native keyed-hash mode.

Algorithms in current list. (none yet; HMAC-SHA variants, KMAC, BLAKE2-MAC are candidates for Issue #43)

Block-Cipher-MAC

Description. MAC constructed using a block cipher as the underlying primitive. Covers CBC-MAC and its variants, CMAC (NIST SP 800-38B), and GMAC (the authentication-only mode of GCM).

Classification rule. Apply this value when the MAC's security argument reduces to the security of an underlying block cipher used as a pseudo-random permutation, and the construction iterates that block cipher over the message.

Algorithms in current list. cmac

Polynomial-MAC

Description. MAC based on polynomial evaluation over a finite field, typically combined with a stream cipher or block cipher for keying. Examples include Poly1305 (RFC 8439) and UMAC (RFC 4418). Sometimes called universal-hash MACs in academic literature.

Classification rule. Apply this value when the MAC's core operation is the evaluation of a message-dependent polynomial under a secret key over a finite field, and security depends on the algebraic properties of that evaluation rather than on a hash function or block cipher round structure.

Algorithms in current list. (none yet; Poly1305, UMAC are candidates)

Notes

• All three values are category names rather than specific construction names. This avoids the ambiguity of using HMAC (a specific construction) as a category that would also need to accommodate non-HMAC hash-based MACs like KMAC and SipHash.
• GMAC fits under Block-Cipher-MAC if added as a standalone entry. Its relationship to block cipher modes is noted but does not require resolution in this issue.

2. Key-Derivation-Function

Password-Based

Description. KDF designed to derive cryptographic keys from a human-readable password or passphrase, typically incorporating a salt and an intentionally slow or memory-hard computation to resist brute-force attacks. Defined in NIST SP 800-132 and RFC 8018.

Classification rule. Apply this value when the input keying material is a human-chosen password or passphrase (low entropy by design) and the construction deliberately imposes computational cost (iteration count, memory hardness, parallelism cost) to make offline brute-force attack expensive.

Algorithms in current list. pbkdf1, pbkdf2, pbe, pbes1, pbes2, argon2

Key-Based

Description. KDF that derives one or more keys from existing cryptographic keying material (a master secret, shared secret, or session key) rather than a password. Includes extraction-then-expansion schemes (NIST SP 800-56C, RFC 5869 / HKDF) and counter/feedback/pipeline modes (NIST SP 800-108).

Classification rule. Apply this value when the input keying material is a full-entropy cryptographic secret (not a password) and the construction is a general-purpose primitive whose definition does not depend on a host protocol's semantics.

Algorithms in current list. (none yet; HKDF is a candidate for Issue #43)

Notes

The two subclasses are differentiated by input domain, which is a structural property of the algorithm. A protocol-coupled construction (such as TLS 1.3 HKDF-Expand-Label or IKEv2 PRF+) is structurally a Key-Based KDF — typically HKDF or a counter-mode construction — used with protocol-specific labels. Whether to also distinguish such usage at the subclass level is treated as a separate question in Decision Block D below.

3. Random-Number-Generator

TRNG

Description. True Random Number Generator. Derives randomness from a physical entropy source (hardware noise, ring oscillators, thermal effects, quantum sources). Conforms to NIST SP 800-90B as an entropy source. Not seed-reproducible.

Classification rule. Apply this value when the output is sourced directly from a physical, non-deterministic process and no deterministic expansion is involved. If the construction reseeds from a physical source but then expands deterministically, classify it as DRBG.

Algorithms in current list. (none yet; OS/hardware entropy sources are candidates)

DRBG

Description. Deterministic Random Bit Generator. A deterministic, seed-based algorithm intended to produce cryptographically secure pseudo-random output. Covers NIST SP 800-90A constructions (Hash_DRBG, HMAC_DRBG, CTR_DRBG) as well as cryptographically secure constructions defined outside the NIST framework (Fortuna, Yarrow, ISAAC, ChaCha20-DRNG).

Classification rule. Apply this value when the algorithm is deterministic and seed-based, produces output suitable for cryptographic use, and is reseedable from an entropy source. Conformance to NIST SP 800-90A is not part of the subclass test; it is tracked through other properties of the YAML entry (e.g., standards, references).

Algorithms in current list. fortuna, yarrow, isaac

Rationale for a single DRBG value (not split into DRBG and CSPRNG)

An earlier draft of this proposal split DRBG (for NIST SP 800-90A-conformant constructions) from CSPRNG (for cryptographically secure deterministic RBGs defined outside that framework). After review, the split has been collapsed. The reasons follow directly from the design principles:

• Per Principle 1, taxonomies categorise by construction, not by certification. Fortuna and Hash_DRBG are both deterministic, seed-based, reseedable, cryptographically secure RBGs. Whether one happens to be in NIST SP 800-90A is a standards-conformance attribute, not a structural property of the algorithm.
• Per Principle 2, the compliance signal belongs in metadata, not in the subclass. SP 800-90A conformance can be expressed via standards, references, or a dedicated property without polluting the subclass taxonomy. SBOM tooling that needs the distinction can read those fields.
• Consistency with the rest of the list. Other entries (e.g., AES) are not split by FIPS validation status. Doing it for RNGs would be inconsistent.

A separate decision block (Decision Block C, below) is reserved in case the group prefers to revisit this and adopt the split anyway.

Algorithms affected

Subclass to be added (cryptoClass already correct)

These files already carry the correct top-level cryptoClass following PR#71. They only need the cryptoSubClass property added.

File	Current cryptoClass	Proposed cryptoSubClass
pbkdf1.yaml	Key-Derivation-Function	Password-Based
pbkdf2.yaml	Key-Derivation-Function	Password-Based
pbe.yaml	Key-Derivation-Function	Password-Based
pbes1.yaml	Key-Derivation-Function	Password-Based
pbes2.yaml	Key-Derivation-Function	Password-Based
argon2.yaml	Key-Derivation-Function	Password-Based
fortuna.yaml	Random-Number-Generator	DRBG
yarrow.yaml	Random-Number-Generator	DRBG
isaac.yaml	Random-Number-Generator	DRBG

cryptoClass and subclass both to be updated

File	Current cryptoClass	Proposed cryptoClass	Proposed cryptoSubClass
cmac.yaml	Cryptographic-Hash-Function/Message-Authentication-Code	Message-Authentication-Code	Block-Cipher-MAC

The bcrypt/mscash/mscash2 question is moved to Decision Block A below and is not part of the main taxonomy proposal.

Deprecations required in the properties description

After the migrations above, the following subclass paths will contain zero algorithms and should be removed from docs/crypto-algorithms-list-properties-description.md as part of the same PR. Leaving them in place would allow future contributions to re-use deprecated values by accident, undermining the taxonomic clean-up that PR#71 began.

Path becoming empty	Reason	Action
Cryptographic-Hash-Function/Message-Authentication-Code	cmac.yaml migrates out (the only algorithm under this path).	Remove Message-Authentication-Code from the Cryptographic-Hash-Function subclass list.
Cryptographic-Hash-Function/Key-Derivation	pbkdf1.yaml, pbkdf2.yaml already migrated out under PR#71.	Remove Key-Derivation from the Cryptographic-Hash-Function subclass list.
Symmetric-Key-Algorithm/Key-Derivation	pbe.yaml, pbes1.yaml, pbes2.yaml already migrated out under PR#71.	Remove Key-Derivation from the Symmetric-Key-Algorithm subclass list.
Symmetric-Key-Algorithm/Random-Number-Generator	fortuna.yaml, yarrow.yaml, isaac.yaml already migrated out under PR#71.	Remove Random-Number-Generator from the Symmetric-Key-Algorithm subclass list.

Each deprecation should be reflected in the property description text by removing the corresponding bullet from the relevant cryptoClass's subclass enumeration.

A fifth path — Cryptographic-Hash-Function/Password-Hashing — would also become empty if Decision Block A is approved. It is listed there rather than here, to keep the two decisions independent.

Additional finding

The file backup-cmac.yaml~ exists in the yaml/ folder. It is a leftover editor backup file (tilde suffix), not a valid algorithm entry. It already shows cryptoClass: Message-Authentication-Code (without a subclass), confirming the intended direction for cmac.yaml. The backup file should be deleted as part of the same PR.

Decision blocks (separable from the main proposal)

The four items below are deliberately separated so that the main taxonomy proposal can move forward independently. Any of them may be approved, deferred, or rejected without affecting the rest of this document.

Decision Block A — Reclassify bcrypt, mscash, mscash2 as Key-Derivation-Function/Password-Based

Current state. All three are classified as Cryptographic-Hash-Function/Password-Hashing.

Proposed change. Migrate them to Key-Derivation-Function/Password-Based.

Arguments in favour.

• Functional equivalence with Argon2. Argon2 is already in Key-Derivation-Function. bcrypt, mscash, and mscash2 serve the same functional purpose (deriving a verifiable bound representation of a password using a slow, salted construction). Keeping them in a different class on naming grounds alone produces an inconsistency users will report as a bug.
• NIST SP 800-132 framing. SP 800-132 treats password hashing and password-based key derivation as the same family of operations; the distinction between "output is a key" and "output is a verifier" is operational, not constructional.
• Eliminates an orphaned subclass. After migration, Cryptographic-Hash-Function/Password-Hashing has zero remaining algorithms and can be removed from the properties description.

Arguments against.

• Some communities use "password hashing" as a deliberately distinct term from "key derivation" and may prefer to preserve the distinction at the taxonomy level.
• The reclassification is a breaking change for any downstream consumer who has cached the current values.

If approved. Migrate the three files; remove Password-Hashing from the Cryptographic-Hash-Function subclass list in the properties description.

File	Current cryptoClass	If approved → cryptoClass	If approved → cryptoSubClass
bcrypt.yaml	Cryptographic-Hash-Function/Password-Hashing	Key-Derivation-Function	Password-Based
mscash.yaml	Cryptographic-Hash-Function/Password-Hashing	Key-Derivation-Function	Password-Based
mscash2.yaml	Cryptographic-Hash-Function/Password-Hashing	Key-Derivation-Function	Password-Based

Decision Block B — Scope of Random-Number-Generator: include non-cryptographic PRNGs?

Question. Should non-cryptographic PRNGs (MT19937, PCG, LCG, Xoshiro family, etc.) be eligible for inclusion in the list as Random-Number-Generator/PRNG entries?

Arguments in favour.

• SBOM use case: identifying a non-cryptographic PRNG in a security-sensitive code path is itself a security-relevant signal. Tooling can flag misuse only if these algorithms are nameable.
• The list already includes broken or deprecated cryptographic algorithms for traceability reasons; non-cryptographic PRNGs would follow the same precedent.

Arguments against.

• The list is the cryptographic algorithm list. Including non-cryptographic primitives expands its scope.
• Non-cryptographic PRNGs are documented well enough elsewhere that duplicating them here adds maintenance burden without clear benefit.

If approved. Add PRNG as a third subclass under Random-Number-Generator with the description: "Non-cryptographic Pseudo-Random Number Generator. Produces statistically uniform sequences suitable for simulation and general-purpose use, but offers no cryptographic security guarantees." Add a classification rule: "Apply this value when the algorithm is deterministic and seed-based but does not claim cryptographic security; typical examples are designed for statistical quality and speed, not adversarial resistance."

If deferred. The main proposal remains valid with the two RNG subclasses shown above.

Decision Block C — Split DRBG into DRBG and CSPRNG

Question. Should the single DRBG value be split into:

• DRBG — restricted to NIST SP 800-90A-conformant constructions (Hash_DRBG, HMAC_DRBG, CTR_DRBG)
• CSPRNG — for cryptographically secure constructions outside SP 800-90A (Fortuna, Yarrow, ISAAC, ChaCha20-DRNG)

Arguments in favour.

• Surfaces NIST SP 800-90A conformance as a first-class signal in the taxonomy.
• Useful for compliance-driven consumers (CRA, FIPS, automotive).

Arguments against.

• Conflicts with Principle 1. Taxonomies should categorise by construction, not by certification. The split conflates "what the algorithm is" with "which standards body has blessed it".
• Conflicts with Principle 2. The conformance signal can be carried in other YAML properties (standards, references) without polluting the subclass.
• Inconsistent with how other categories in the list are treated (AES is not split by FIPS validation).

If approved. Reclassify fortuna, yarrow, and isaac as Random-Number-Generator/CSPRNG; add DRBG and CSPRNG as distinct subclass values with classification rules differentiating them.

If deferred. The main proposal stands with a single DRBG value.

Decision Block D — Add Protocol-Specific as a third KDF subclass

Question. Should Key-Derivation-Function carry a third subclass, Protocol-Specific, for KDFs whose derivation logic is defined inside a specific protocol specification (e.g., TLS 1.3 HKDF-Expand-Label per RFC 8446 §7.1, IKEv2 PRF+ per RFC 7296 §2.13, SSH KEX per RFC 4253 §7.2)?

Arguments in favour.

• SBOM identification. Implementations of TLS, IKEv2, SSH, WPA2/3, and Kerberos frequently include the protocol-specific KDF as a distinct, named code path (e.g., tls13_hkdf_expand_label). SBOM tooling that scans for cryptographic primitives can be more precise if these have a dedicated subclass.
• Regulatory traceability. Under the CRA and equivalent regimes, a protocol-coupled KDF may have different validation requirements than a general-purpose KDF, because the protocol specification itself constrains parameter choices, salt handling, and label semantics.

Arguments against.

• Conflicts with Principle 1. TLS 1.3 HKDF-Expand-Label is structurally HKDF used with protocol-specific labels. The construction is HKDF; the protocol-specific part is the label encoding. Key-Based already covers the construction.
• Conflicts with Principle 2. "Where the KDF is used" is deployment context, not a structural property of the algorithm.
• Conflicts with Principle 3. All current KDF entries fit cleanly under Password-Based. Reserving subclass values that have no occupants creates a classification burden without immediate benefit.
• Inconsistent with the list's existing pattern. The list does not subclass AES, ChaCha20, or any other algorithm by host protocol. Doing it for KDFs alone introduces an asymmetry that careful reviewers will flag.
• Reversible later. If a protocol-specific KDF is proposed for inclusion at a later date, this subclass can be added as part of that PR. There is no pre-existing entry that would need re-tagging.

If approved. Add Protocol-Specific as a third subclass under Key-Derivation-Function with description and classification rule per v3 of this proposal (available on request).

If deferred. The main proposal stands with two KDF subclasses. Protocol-coupled KDFs, if and when they enter the list, are classified as Key-Based until the group revisits this decision.

Open question for the SPDX Cryptography Group

After the decision blocks above, one technical question remains on the main taxonomy proposal:

1. KMAC placement. If KMAC128/KMAC256 are added (Issue Algorithms that might turn into candidates for SPDX #43), the proposal places them under Message-Authentication-Code/Hash-Based-MAC. Does the group prefer a distinct Keccak-MAC subclass instead?