Prerequisite Modeling #5
Comments
|
Makes sense to me. If everybody agrees, I will update the affected DRBG and RSA specifications accordingly. |
|
Unless Harold or John see this causing an issue with their implementation plans I don’t Barry From: DBugger32 [mailto:notifications@github.com] 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... 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 The allowed prereq algorithms would be supplied in the associated section and used to limit valid inputs. — |
|
I see no problem with making this an array. |
|
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. |
|
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:notifications@github.com] 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. — |
|
Thanks, Barry, I will take care of the RSA spec. |
|
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:notifications@github.com] Thanks, Barry, I will take care of the RSA spec. — |
|
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? |
|
Sorry, I was referring to the keywords not the metadata. "prereqVals": [{“algorithm” : "AES", “valValue” : "1234"}], Barry From: Apostol Vassilev [mailto:notifications@github.com] 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? — |
|
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. |
|
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? |
|
Not really needed in JSON since the object defines itself. If the On Fri, Sep 9, 2016 at 12:29 PM, Apostol Vassilev notifications@github.com
|
|
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. |
|
If you want to be nice you can include a property that says what type the On Fri, Sep 9, 2016 at 1:16 PM, Apostol Vassilev notifications@github.com
|
|
Sure, I have been converging to a similar solution already, just wasn't sure if there was a better way. Thanks |
|
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. |
|
Accepted and implemented in all specs. |
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.
The text was updated successfully, but these errors were encountered: