Prerequisite Modeling

[usnistgov]

Prerequisite Modeling

[atvassilev]

Makes sense to me. If everybody agrees, I will update the affected DRBG and RSA specifications accordingly.

[bfussell]

Unless Harold or John see this causing an issue with their implementation plans I don’t
have a problem with the change.

Barry

From: DBugger32 [mailto:[email protected]]
Sent: Wednesday, September 07, 2016 8:52 AM
To: usnistgov/ACVP [email protected]
Subject: [usnistgov/ACVP] Prerequisite Modeling (#5)

Instead of having individual prereq fields (the majority of which will be likely be null) for each algorithm, I think it would be preferable to have array of prereqs. For example, the ECDSA spec currently has...
shaVal
sha2Val
sha3Val
drgbVal
drbg2Val

This is not easy to read much less implement things like validation. Dealing with these in any capacity becomes 5 separate property reads with an inconsistent naming convention.

It would be better to have an array of prereqs, which not allows the easy use of loop, it reduces the data passed around to what is actually needed. It also allows the easy addition of additional prereqs if the need should arise. In the current model, if you want to add a third drbg prereq, that's an API change.

Suggest something along the lines of

prereqVals Prerequisite validations, see section 2.X.X array

Which would look like
[{algorithm: 'drbg', value: '1234'}, {algorithm: 'sha', value: 'same'}]

The allowed prereq algorithms would be supplied in the associated section and used to limit valid inputs.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/5, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGnx9oKUcE3miZJ9aUOGUSAsuu2TMJT1ks5qnrNXgaJpZM4J24hz.

[jfigus]

I see no problem with making this an array.

[atvassilev]

I uploaded an update to the DRBG specification with the new way of defining prerequisites - see Sections 2.2, 2.3 and the capabilities examples in Appendix A. Since this piece of schema specification is common to many of the other specifications it would be good if we all adopt the exact same definitions for the underlying schema objects and properties.

Please take a look and let me know what you think. If you agree, please use the exact same definitions in your spec in order to allow reusing the same code for parsing prerequisites in the ACVP implementation. Having said this, I now wonder if we need to separate the prerequisite schema in its own specification and only refer to it in all other specifications along with defining the acceptable values for prerequisite algorithm names.

[bfussell]

Apostol,

I looked at the change and they seem reasonable. I’ll begin to translate the other docs to that format as well.

Thanks,

Barry

From: Apostol Vassilev [mailto:[email protected]]
Sent: Thursday, September 08, 2016 11:42 AM
To: usnistgov/ACVP [email protected]
Cc: Barry Fussell (bfussell) [email protected]; Comment [email protected]
Subject: Re: [usnistgov/ACVP] Prerequisite Modeling (#5)

I uploaded an update to the DRBG specification with the new way of defining prerequisites - see Sections 2.2, 2.3 and the capabilities examples in Appendix A. Since this piece of schema specification is common to many of the other specifications it would be good if we all adopt the exact same definitions for the underlying schema objects and properties.

Please take a look and let me know what you think. If you agree, please use the exact same definitions in your spec in order to allow reusing the same code for parsing prerequisites in the ACVP implementation. Having said this, I now wonder if we need to separate the prerequisite schema in its own specification and only refer to it in all other specifications along with defining the acceptable values for prerequisite algorithm names.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/5#issuecomment-245640491, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGnx9mN-ZLMJ40hRXQMymSA35Wo_cog0ks5qoCzBgaJpZM4J24hz.

[atvassilev]

Thanks, Barry, I will take care of the RSA spec.

[bfussell]

Apostol,

After further review I think algorithm and valValue require quotes in a few places. I have a few of those in my docs as well.

"prereqVals": [{algorithm: "AES", valValue: "1234"}],

Barry

From: Apostol Vassilev [mailto:[email protected]]
Sent: Thursday, September 08, 2016 4:56 PM
To: usnistgov/ACVP [email protected]
Cc: Barry Fussell (bfussell) [email protected]; Comment [email protected]
Subject: Re: [usnistgov/ACVP] Prerequisite Modeling (#5)

Thanks, Barry, I will take care of the RSA spec.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/5#issuecomment-245737964, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGnx9mm0bYQGrw_NUGPRW06AlfkiwcoQks5qoHZogaJpZM4J24hz.

[atvassilev]

Barry,

I agree and think this is reflected in the examples in Appendix A of the DRBG spec. If I understand you correctly, you are asking to put quotes around the entries in the Table 2 in Section 2.2 as "SHA", "HASH", "TDES", "HMAC". Similarly, the valid values column for valValue should be: actual number, e.g. "123456", or "same". Right?

[bfussell]

Sorry, I was referring to the keywords not the metadata.
Don’t algorithm and valValue require quotes in the example, like this:

"prereqVals": [{“algorithm” : "AES", “valValue” : "1234"}],

Barry

From: Apostol Vassilev [mailto:[email protected]]
Sent: Friday, September 09, 2016 10:34 AM
To: usnistgov/ACVP [email protected]
Cc: Barry Fussell (bfussell) [email protected]; Comment [email protected]
Subject: Re: [usnistgov/ACVP] Prerequisite Modeling (#5)

Barry,

I agree and think this is reflected in the examples in Appendix A of the DRBG spec. If I understand you correctly, you are asking to put quotes around the entries in the Table 2 in Section 2.2 as "SHA", "HASH", "TDES", "HMAC". Similarly, the valid values column for valValue should be: actual number, e.g. "123456", or "same". Right?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/5#issuecomment-245931279, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGnx9qF5fuW_3uUMgQ4UR7FUwhZYc81Hks5qoW5VgaJpZM4J24hz.

[atvassilev]

Yes, you are correct. Checking the JSON conventions, it looks like property names without quotes can only be used if they are literal numerical values or reserved valid identifiers (keywords). I will change the DRBG spec accordingly and the RSA spec that I am currently working on. In fact, the prerequisite change prompted me to revisit the RSA schema and I found a number of needed improvements to make, I will keep in mind the property name convention. Thanks for catching this.

[atvassilev]

I am in the process of revising the RSA spec and wonder if one could define an array of generic JSON objects, each may be different but derive from a generic JSON object. At runtime, one would then identify the type of each of these objects and handle it accordingly. There are similar constructs in C++ but I am not sure about JSON. Any ideas?

[DBugger32]

Not really needed in JSON since the object defines itself. If the
underlying consumer can take advantage of any duck typing -- similar
properties -- that's great, just define the properties that are needed.

On Fri, Sep 9, 2016 at 12:29 PM, Apostol Vassilev [email protected]
wrote:

I am in the process of revising the RSA spec and wonder if one could
define an array of generic JSON objects, each may be different but derive
from a generic JSON object. At runtime, one would then identify the type of
each of these objects and handle it accordingly. There are similar
constructs in C++ but I am not sure about JSON. Any ideas?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABpSYW8HHrtrWZ75O3tPSuhLaLLmwEjJks5qoYmDgaJpZM4J24hz
.

[atvassilev]

So basically you are saying, plop a number of different objects in an array and then identify each object by its properties. This would work for the purposes of the spec just fine, hope it is easy to implement.

[DBugger32]

If you want to be nice you can include a property that says what type the
object is.

On Fri, Sep 9, 2016 at 1:16 PM, Apostol Vassilev [email protected]
wrote:

So basically you are saying, plop a number of different objects in an
array and then identify each object by its properties. This would work for
the purposes of the spec just fine, hope it is easy to implement.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABpSYfn1HcMz_Z240OVF_kcbi0SHuPy6ks5qoZRxgaJpZM4J24hz
.

[atvassilev]

Sure, I have been converging to a similar solution already, just wasn't sure if there was a better way. Thanks

[atvassilev]

I just uploaded updates to the DRBG and RSA specs to put them inline with the new schema for prereq modeling. In the case of RSA, I improved the schema quite a bit. Hopefully, it should now be (much closer to) implementable.

[atvassilev]

Accepted and implemented in all specs.