Comments (17)
Makes sense to me. If everybody agrees, I will update the affected DRBG and RSA specifications accordingly.
from acvp.
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.
from acvp.
I see no problem with making this an array.
from acvp.
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.
from acvp.
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.
from acvp.
Thanks, Barry, I will take care of the RSA spec.
from acvp.
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.
from acvp.
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?
from acvp.
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.
from acvp.
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.
from acvp.
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?
from acvp.
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
.
from acvp.
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.
from acvp.
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
.
from acvp.
Sure, I have been converging to a similar solution already, just wasn't sure if there was a better way. Thanks
from acvp.
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.
from acvp.
Accepted and implemented in all specs.
from acvp.
Related Issues (20)
- TLS 1.0/1.1 extended master secret testing HOT 2
- What is RSA primeTest 2powSecStr stands for? HOT 2
- ECDSA PKV sample prompt HOT 2
- KDA Two Step SP800-56CR2 Counter Length Options Seem to Require 0 HOT 2
- Strange behavior for EdDSA SigGen contextLength HOT 6
- FIPS 186-5 RSA keygen testing question about selection of pmod8 and qmod8 values HOT 3
- HMAC testing with pre-computed key blocks HOT 1
- Missing .34 ECDSA changes from documentation.
- kdf-components: IKEv2 KDF - missing SA full-rekeying testing HOT 2
- Clarification Request Regarding Testing Scope for KAS-FFC-SSC HOT 2
- SHAKE - additional line "outLen" in expectedResults from Demo Server for each testcase HOT 2
- What is the format of FixedInfo parameter "l" in RSA-OAEP KTS? HOT 1
- Missing Entry in FIPS186-5 RSA KeyGen / "probableWithProvableAux" Test Vector Group Object HOT 19
- Unable to request ECDSA 186-5 Production Vectors with B and K Curves HOT 1
- RSA FIPS186-5 SigGen test failures HOT 1
- GMAC testing with same GCM parameters HOT 3
- DRBG nonce lengths HOT 7
- Message Length for LMS HOT 5
- Query Available Vector Sets should provide more info HOT 1
- EdDSA: the requested test vectors for SigGen mode has unexpected 'context' and 'contextLength' parameters in some tests
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from acvp.