> I think the answers for the last questions about templates and State are
> as follows: The State attribute applies to "all Cryptographic Objects",
> according to table 73 of the spec. According to section 2.2.6 of the
> spec, a Template is a "Managed Object", not a "Cryptographic Object". I'd
> put those two thoughts together to conclude that Templates don't have
> State. So a response for GetAttributesList on a Template should not
> contain the string "State", and a GetAttributes("State") on a Template
> should return an error...since it's not listed in section 11.2, I'll
> speculate INVALID_FIELD. We should probably add that to section 11.2
> (since the original testcases always did a GetAttributesList, followed by
> a GetAttributes, they were never asking for something that didn't exist,
> so we didn't encounter the error variation).
The textual lead in description for State does not state only Cryptographic
Objects or Managed Objects or the usual prose which is included in all the other
descriptions.
Templates are listed in Table 76 through to Table 84 and they are all described
in terms of State transitions and Templates are listed in the "Applies to Object
Types" in each of those tables.
e.g. "Yes, only while in Pre-Active or Active state" to my reading means that
the objects being referred to must have State.
I've read it that Table 73 should have had Templates listed in it or
alternatively all of those following tables are incorrect and need to be reworded.
Table 88 and 90 extend the concept of State to Opaque Objects as well following
a similar path.
Either way, the specification could do with some clarification and the addition
of some use cases should help make the intended behaviour of implementations
clearer.
Reading through those tables I get:
# object type membership
CRYPTO=CERT,KEY,SECRET
UNIQUE_IDENTIFIER:ALL text
OBJECT_TYPE:ALL enum
INITIAL_DATE:ALL date
LAST_CHANGE_DATE:ALL date
CERTIFICATE_TYPE:CERT enum
CERTIFICATE_IDENTIFIER:CERT stru
CERTIFICATE_SUBJECT:CERT stru
CERTIFICATE_ISSUER:CERT stru
DIGEST:CRYPTO,OPAQUE stru
CRYPTOGRAPHIC_USAGE_MASK:CRYPTO,TEMPLATE enum
CRYPTOGRAPHIC_ALGORITHM:KEY,CERT,TEMPLATE enum
CRYPTOGRAPHIC_LENGTH:KEY,CERT,TEMPLATE int4
STATE:CRYPTO enum
Noting that DIGEST may or may not be present depending on whether or not the
server has access to the information to create it. I don't see the logic behind
Digest not being applicable to all objects.
Currently the Cryptsoft server at least has State and Digest as an attribute for
*all* Objects.
Use cases that have GET_ATTRIBUTE_LIST are 3.1.4 step 3 (SYMMETRIC_KEY), 4.1
step 8 (SYMMETRIC_KEY), 11.1 step 2 which is a failure case, 13.2 step 4
(CERTIFICATE), 13.4 step 4 (CERTIFICATE).
http://interop.cryptsoft.com/kmip_uc/
(Note: 13.1 through 13.4 are the new use cases not yet in the use case document).
That does indeed provide a clear indication that we need to add extra use cases
which cover Get Attribute List across all the object types.
Tim.