RE: [kmip] Comments and potential additions to the Usage Guide

[<Furlong_Judith@emc.com>]

Indra,

I've included some comments/questions below.

Judy

Judith Furlong | Principal Product Manager | EMC Product Security Office
| RSA -The Security Division of EMC | t: 508 249 3698 |  f: 508 249 6107
| e: Furlong_Judith@emc.com 


-----Original Message-----
From: Fitzgerald, Indra [mailto:indra.fitzgerald@hp.com] 
Sent: Tuesday, June 30, 2009 7:10 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] Comments and potential additions to the Usage Guide

All,

During last weeks call, I was asked to send out the comments I exchanged
with Robert. Below is a list of outstanding concerns and comments.
Please let us know if you have any comments, agree or disagree, and if
you would like to see additional clarification and examples in the spec
or Usage Guide.

Regards,
Indra

1.	p.14, 2.1.7.1: Clarify in the Usage Guide that Transparent
Symmetric Key is essentially the same as Raw key type. Raw key type
allows clients to avoid keeping the octet key in a structure.

2.	p.22,3.2, line 352: Name Type includes extension for
vendor-specific implementation. Vendor-specific attributes or operations
are avoided in the spec and Usage Guide. For example, the Usage Guide
specifies that if clients require unique identifiers in a special form,
out-of-bound registration/configuration can be used to communicate this
to the server. We should use a similar approach for server-created
Application Data (as part of the Application Specific Information
attribute). Instead of relying on implied, side-effect functionality,
the spec should either make server-generated Application Data
vendor-specific or require clients to explicitly request the server to
generate Application Data by setting an option specific for this
purpose. As currently specified (in the proposal), the attribute is
confusing, complex, and will lead to interoperability issues. 

3.	Secret Data is considered to be a Cryptographic Object. The
problem is that this may not always be the case. The client could
register a password without using it for crypto purposes (such as key
derivation). If Secret Data is considered to be a Crypto Object, certain
attributes must always have a value. For example, if the password is
just an ordinary password string and not used for key derivation,
clients are still expected to set the Crypto Usage Mask to
00000000000000 (the spec specifies that this attribute must always have
a value for Cryptographic Objects). This can get confusing and it would
make sense to clarify this in the Usage Guide.

[JAF] -- Are you only making changes to the Usage Guide to explain this
use case or are there changes being made to the KMIP Spec as well?  If
so what are those changes?  In section 9.1.2.2.1 where the Cryptographic
Usage Mask Values are identified that the value of 
00000000000000 is not listed.  

4.	Provide additional guidance and clarification on how to specify
Custom Attributes in a message. If required, an example could be
provided in the Usage Guide.

The spec currently states the following:
"The tag type Custom Attribute cannot identify the particular attribute;
hence, such an attribute can only appear in an Attribute Structure with
its name as defined in Section 2.1.1."
	
We should clarify that Attribute Name (as defined in Section 2.1.1)
should be x-<custom attribute> or y-<custom attribute> and not Custom
Attribute. The table should be updated accordingly.

5.	p.45, 4.2, line 774: Cryptographic Length should be a required
attribute for the Create operation. It is required by Register, Create
Key Pair, and Derive Key.

6.	p.49, 4.3: Should we provide guidance on how to register a key
pair? During Create Key Pair, the server is expected to set certain
attributes. For example, the link attribute will be set and certain
attributes, such as Cryptographic Parameters, must be set to the same
value for both public and private key. All this occurs transparently and
clients may not realize that the server is setting these attributes. It
may be helpful to include an example of registering a key pair using the
Register operation in the Usage Guide.

[JAF] -- Yes I believe it would be a good idea to include the register
key pair example in the Usage Guide.

7.	p.49, 4.4, line 831: States that during a re-key, attributes are
changed similarly to performing a Revoke with Revocation Reason of
Superseded. According to p. 34, line 562, issuing a Revoke with
Revocation Reason other than Compromised causes the state to transition
from Active to Deactivated state. This will not work for most clients.
Protect Stop Date usually occurs prior to reaching the Deactivation
Date. Clients would usually perform a rekey, expect the new key to be
used for protect purposes, and continue using the old key for processing
purposes until it reaches the Deactivation Date.

[JAF] -- I agree -- equating a rekey with revocation is not a good
analogy.  Revocation in the PKI sense is the CA breaking the binding
between the subject and the subject's key.  When you rekey either an
asymmetric or symmetric key your saying nothing about the status of the
key that this new key will replace.  As Indra indicates the new key may
be used for new crypto functions going forward but the old key may still
be used for some crypto functions such as decryption, etc.  So the old
key's state is definitely not deactivated.

8.	p.54, 4.6: Three concerns regarding Certify and Re-certify:
a.	The table needs to include the CA to be used to sign the
Certificate Request. We are currently assuming that there exists only
one CA on the server, unless the Certificate Issuer attribute is
supposed to be used for this purpose. If this is the case, we need to
add clarification. If this is not the case, this needs to be discussed.
Should we allow the CA name to be specified or do we require one of the
following: CA public key UID, CA private key UID, or certificate UID?

[JAF] CA's may have more than one certificate -- the normal way to
identify the CA's certificate is to specify the Issuer DN (found in the
CA's certificate) and the Serial Number (of the CA's certificate) --
These two pieces of info are included in the Certificate Issuer
attribute in the KMIP spec.  

b.	Creating a Certificate Request requires the private key. We are
assuming that the client stores the key pair outside of the server and
has the capability to create a Certificate Request. Should the protocol
cover the case where the key pair is stored by the server and the
Certificate Request can be created by the server? This would not only be
more convenient for clients, but would also benefit dumb clients who do
not have the capability to create Certificate Requests.

c.	Line 918 states that if the information in the Certificate
Request conflicts with the attributes specified in Template-Attribute,
the information in the Certificate Request takes precedence. Should we
provide additional guidance/clarification in the Usage Guide? This may
affect Certificate Subject, Cryptographic Algorithm, and Crypto Length.
I am not sure what other attributes can be explicitly specified under
Attributes inside Certificate Request. 

[JAF] PKCS#10 formatted certificates requests have the option to include
attributes in addition to the subject name and subject public key.
Attributes can come in many types, some attributes are defined in PKCS#9
including the general "Requested Extension" which allows you to carry
any of the certificate extensions defined in X.509 and/or RFC 5280.  As
to overlap with KMIP attributes here is a summary of what I can think of
-- some are stretches.
 
The 'subject' in the cert request overlaps with KMIP Cert Subject
The 'subject public key' in the cert request contains info overlapping
with KMIP Crypto Algorithm, Crypto Length and Crypto Parameters
The Key Usage extension (carried in the requested extension attribute)
overlaps with KMIP Crypto Usage Mask
The Private Key Usage extension (carried in the requested extension
attribute) overlaps with KMIP Protect Stop Date
The Subject Key Identifier extension (carried in the requested extension
attribute) overlaps with KMIP Unique Identifier
The Subject Alternative Name extension (carried in the requested
extension attribute) overlaps with KMIP Certificate Subject


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php