Review of the conformance testing section in the profiles spec.

[Robert Relyea <rrelyea@redhat.com>]

After I read through the conformance testing section of the profiles spec, I converted the original proposal and the latest spec chapter to text, and removed the chapter headings (1.xx in the original, 3.x and 4.x in the spec). I then produced the attached diff. Most of the differences are intentional editorial changes made to the current draft. One exception is a missed linked element from the original is still pointing to the original section number in 'Enumerated Types' section (4.6.4 in the current spec). It points to section 1.3.1 and it should point to section 4.3.1. everthing else looks good.

bob

------------------------------------------

diff -w --color -u orig.txt spec.txt 
--- orig.txt	2021-07-20 15:44:28.538349492 -0700
+++ spec.txt	2021-07-20 15:50:19.490637281 -0700
@@ -13,8 +13,8 @@
 Each test case MAY include allowed variations in the description of the test case in addition to the variations noted in this section.
 Other variations not explicitly noted in this section SHALL be deemed non-conformant.
 Variable Items
-An implementation conformant to a Profile MAY vary the following values:
-Provider specific information:
+An implementation conformant to a Profile MAY vary the following values (expressed using the XML name for the items):
+Provider specific information within the Info, SlotInfo and TokenInfo elements:
 1. LibraryDescription
 2. LibraryVersion
 3. ManufacturerID
@@ -27,7 +27,7 @@
 10. utcTime
 Session specific information:
 1. SlotID
-Object
+2. Object
 3. Session
 Object specific information:
 1. Object
@@ -44,10 +44,17 @@
 6. EXPONENT_1
 7. EXPONENT_2
 8. COEFFICIENT
+9. PRIME
+10. SUBPRIME
+11. BASE
+12. EC_POINT
+13. UNIQUE_ID
 Variable behavior
 An implementation conformant to a Profile SHALL allow variation of the following behavior:
 1. A test may omit the clean-up functions at the end of the test provided there is a separate mechanism to remove the created objects during testing.
-2. A test may omit the test identifiers if the consumer is unable to include them in calls.
+2. A test may omit the test identifiers in various attributes if the consumer is unable to include them in calls.
+3. The number of entries and order of entries in the list returned in the C_GetSlotList, C_GetMechanismList, and C_GetInterfaceList functions make vary, provided that at least one entry within the list matches the logical context of the test case.
+PKCS#11 XML Representation
 Normalizing Names
 PKCS#11 parameter and structure field names SHALL be normalized to create a âCamelCaseâ format that would be suitable to be used as a variable name in C/Java or an XML element name.
 Hungarian notation type indicators are entirely omitted from names (i.e. h, ph, ul, pul, and p are omitted).
@@ -73,16 +80,16 @@
 PKCS#11 parameters and structure member elements that represent the count of arrays are omitted as input parameters as the lengths can be determined by a count of the number of XML elements within the call or return XML element within the element representing the PKCS#11 function call.
 Determining Array or List Length
 The PKCS#11 approach of passing in a NULL pointer value and using an input/output parameter to determine the required pointer buffer length for a subsequent call SHALL be encoded as request where the XML element for pointer has no specified value or length for the function call and the returned length is contained in the XML element attribute length.
-XML Root Element
-XML documents representing a sequence of PKCS#11 function calls and returns SHALL have an XML root element of PKCS11.
-XML Namespaces
-If namespaces are necessary within a specific context, then each XML element SHALL use the following namespace:
-urn:oasis:tc:pkcs11:xmlns
 Hexadecimal String Encoding
 Hexadecimal strings SHALL NOT include any white space.
 Hexadecimal strings SHALL use either uppercase âAâ-âFâ or lowercase âaâ-âfâ along with â0â to â9â.
 Numeric values represented as hexadecimal strings SHALL begin with â0xâ.
 Binary values represented as hexadecimal strings SHOULD omit the â0xâ.
+XML Root Element
+XML documents representing a sequence of PKCS#11 function calls and returns SHALL have an XML root element of PKCS11.
+XML Namespaces
+If namespaces are necessary within a specific context, then each XML element SHALL use the following namespace:
+urn:oasis:tc:pkcs11:xmlns
 XML Element Encoding
 For XML, each function call is represented as a sequence of two XML element with optional attributes.
 The parameters to each call are represented as nested XML elements, and any structures used within those parameters are represented as nested XML elements within the nested XML elements.
@@ -90,14 +97,14 @@
 Boolean
 XML value uses [XML-SCHEMA] type xsd:Boolean. The value SHALL be FALSE, false, TRUE or true.
 <TokenPresent value="false"/>
-String
+Text String
 XML value uses [XML-SCHEMA] type xsd:string
 <Pin value="12345678"/>
 Byte String
 XML value uses [XML-SCHEMA] type xsd:hexBinary
 <EncryptedData value="8dce78ad"/>
 Enumerated Type
-XML value uses [XML-SCHEMA] type xsd:string and is either a hexadecimal string or the Enumerated Type Representation name. If an XSD with xsd:enumeration restriction is used to define valid values parsers should also accept any hexadecimal string in addition to the defined enumeration values to allow for user extensions and non-textual encoding parsers.
+XML value uses [XML-SCHEMA]  type xsd:string and is either a hexadecimal string or the 1.3.1 Enumerated Type Representation name. If an XSD with xsd:enumeration restriction is used to define valid values parsers should also accept any hexadecimal string in addition to the defined enumeration values to allow for user extensions and non-textual encoding parsers.
 <Type value="AES_CBC"/>
 <Type value="0x00001082"/>
 <Type value="4426"/>
[rrelyea@localhost nss]$