Profile

The discussion was very clear about the challenge of FIPS140 validation and that we do not currently support SEED at all in our currrent working draft at of the meeting last week - it isn't there. I said I would add it so we could be SEED or KEY with a recommendation to be both which is aligned with ...

The discussion on PQC formats was a consensus that we would remain aligned with PKCS#11 as usual and allow SEED but not require it and the wait and see bit was just about what the various SDKs end up doing as that would impact our interop testing. If a vendor uses an SDK that doesn't have flexibility ...

Submitter's message As discussed in the TC meeting on 12th Jan, corresponding KMIP changes to mirror the PKCS#11 v3.2 approach to handling SEED as an optional private key format for ML-KEM and ML-DSA. The structure is defined in an algorithm agnostic manner and is usable for all algorithms that ...

[ Bob Relyea ] > So we definitely decided that the token could reject one or the other of these cases. > A slow token may not regenerate CKA_VALUE and fail if CKA_VALUE is not specified. > A token with limitted space may require CKA_SEED. If the application supplies both > it is guarrenteed to work. ...

As discussed and agreed in the TC meeting, attached are the summary graphs to update the KMIP wikipedia page which has been somewhat neglected. As noted in the call, it includes all interop participants that have participated in two or more interops from 2014 onwards with the test results normalised ...