RE: [pkcs11] Groups - RNG_Proposal

Bruce,

thanks for your feedback. Pease find comments inline.

And I would actually appreciate the TC to comment the following: How detailed do we have / do we want to be?

The KMIP DRBG Algorithm Enumeration actually specifies the type of DRBG Algorithm, while our proposal includes the key/hash size (and thus the cryptographic strength) of the internal crypto algorithm. Although not yet relevant, there might be a point in time where NIST specifies a minimum strength that would not allow some hash function (e.g. SHA-1) anymore. A client application should then be able to know whether the device implements a DRBG based on SHA-1 or a stronger SHA algorithm.

If that level of detail is not needed for the foreseeable future, we can agree to use the same DRBG constants as in KMIP.

Best regards,

Dieter

From: Bruce Rich [mailto:bar@cryptsoft.com]
Sent: Mittwoch, 8. Juni 2016 21:15
To: Dieter Bong <Dieter.Bong@utimaco.com>
Cc: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Groups - RNG_Proposal_Draft1.doc uploaded

Dieter,

Thanks for the draft. I tried to map it through what KMIP supports, and came up with a few questions, some of which may be items that still need to be hammered out between the two standards.

I didn't quite get the distinction between "Other than any specified below" and "Vendor defined RNG Algo". Are you thinking that the first is a well-defined standard that just isn't (yet) in the list, and the second is something proprietary? KMIP only has "Unspec" for things that aren't in the list (either RNG algorithm list or DRBG algorithm list).

DBO: You’re right, I should better have used „Unspecified“ instead of "Other than any specified below". And I can’t actually give a good explanation why there is both; in fact I consider them similar if not equal, the one being the KMIP-style and the other being the PKCS#11-style of specifying it (and honestly I have the same question w.r.t. “Unspecified” and “Extensions” in the KMIP definitions for RNG mode). For the final version I’m happy to remove the one or the other.

I'm still scratching my head over the AIS31 items. Don't have a mapping in mind for those yet, so guess I need to do more than skim the references for them. I don't think KMIP really has anything for NTG-1, so that one probably is a KMIP 1.4 addition.

DBO: We included AIS31 as this is used with smartcards and HSM that undergo a Common Criteria certification, which is quite common in Europe and Asia. I think a mapping is actually not easy to achieve, because a) neither NTG nor PTG fit the DRBG definition of NIST, thus cannot be mapped to KMIP’s DRBG Algorithm Enumeration and b) DRG in the sense of AIS31 is a DRBG in the sense of NIST, but the DRG classes do not map to DRBG algorithms (e.g. a random number generator of class DRG.3 may be Hash or HMAC-based, but the AIS 31 class doesn’t make this visible so you wouldn’t know whether to map to “Hash” or “HMAC”). And when using a Common Criteria certified HSM it is more important to knowing the DRG class than knowing whether there is Hash or HMAC inside. To summarize: you’re right, that doesn’t easily map.

At some point down the road, it may be helpful to have committee notes that document the mappings between the two. Putting the mappings in each standard would be awkward from a process view, but something better than a sketch on a piece of paper would be helpful.

Bruce Rich

On Tue, Jun 7, 2016 at 2:19 AM, Dieter Bong <dieter.bong@utimaco.com> wrote:

Submitter's message
1st Draft of a proposal related to C_GenerateRandom, providing information about mode and algorithm/quality of the random number generator, and enabling to choose the RNG algorithm (if supported by the token).
-- Mr. Dieter Bong

Document Name: RNG_Proposal_Draft1.doc

No description provided.
Download Latest Revision
Public Download Link

Submitter: Mr. Dieter Bong
Group: OASIS PKCS 11 TC
Folder: Working Drafts
Date submitted: 2016-06-07 00:19:26

pkcs11 message