OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [kmip-comment] Revoking opaque objects


Hi Dave,

Thank you for your thoughts!

I am CC-ing the email list in order to bring attention to the points below from Dave. Hopefully someone can verify. Either way, it would be great if this could be cleared up in the next version of the spec.

"Given that section 4.20 Revoke says that ââ the object is placed into the âcompromisedâ stateâ by specifying âkey compromiseâ or âCA compromiseâ, and given that an Opaque Object cannot have a State attribute, it follows that one cannot specify âkey compromiseâ or âCA compromiseâ for an Opaque Object." - from Dave's email below

ÂÂÂÂ ÂÂÂ If the above is true, then why can the "compromise date" and the "compromise occurrence date" be set for an opaque object? The "Applies to Object Types" sections in 3.30 and 3.29. If this is true, it would be great if it could be explained.

Thanks,

Alex

On 1/6/2019 5:22 PM, Featherstone David wrote:

Alexis

Â

The specification has a parallel âUsage Guideâ -- e.g. KMIP 1.4 Usage Guide.

Â

You might call the KMIP TCâs attention to the fact that the Usage Guide, section 2.6 Support for Cryptographic Objects, incorrectly [I think] lists the Opaque object.

Â

Cheers,

â Dave

Â

From: Featherstone David
Sent: January-06-19 3:28 PM
To: 'Alexis Abell' <alex.abell@oracle.com>
Subject: RE: [kmip-comment] Revoking opaque objects

Â

Alas, the KMIP TCâs mail server has just advised me that my subscription has expired. i.e. Only you (and not the KMIP TC at large) can see my reply.

Â

If you want the TCâs feedback on my response, then you -- who has the privilege -- Âmust reply to my email (such that the TC membership can see it).

Â

Cheers

Â

From: Featherstone David
Sent: January-06-19 3:20 PM
To: 'Alexis Abell' <alex.abell@oracle.com>
Cc: kmip-comment@lists.oasis-open.org
Subject: RE: [kmip-comment] Revoking opaque objects

Â

Alexis

Â

Below, I have tried to answer your questions. The KMIP specification is generally quite precise in its wording, but some text is open to interpretation.

Â

Cheers,

â Dave

Â

The KMIP 1.4 Specification, Section 2.2.8 Opaque Object says that an Opaque Object is a âManaged Object ââ.

Â

Contrast that statement with Section 2.2.2 Symmetric Key which says that a Symmetric Key is a âManaged Cryptographic Object ââ.

Â

i.e. An Opaque Object is not a âCryptographic Objectâ from the perspective of the KMIP specification.

Â

Table 103, in Section 3.22 State says that the State attribute applies to âAll Cryptographic Objectsâ -- i.e. does not apply to an Opaque Object.

Â

The Compromise Occurrence Date, Compromise Date, Destroy Date, and Revocation Reason attributes can be associated with an Opaque Object without requiring that an Opaque Object also support a State attribute.

  • Can opaque objects be revoked with a revocation reason other than 'key compromise' or 'CA compromise'?

Yes: The Revoke operation can be used to revoke ââ a Managed Cryptographic Object or an Opaque Objectâ, as specified in section 4.20 Revoke.

If neither the âkey compromiseâ nor âCA compromiseâ Revocation Reasons have been specified in the Revoke operation, then the operation cannot [actually, SHALL NOT]specify a Compromise Occurrence Date.

Given that section 4.20 Revoke says that ââ the object is placed into the âcompromisedâ stateâ by specifying âkey compromiseâ or âCA compromiseâ, and given that an Opaque Object cannot have a State attribute, it follows that one cannot specify âkey compromiseâ or âCA compromiseâ for an Opaque Object.

  • If they can, is the deactivation date for that object set? Is the state set to deactivated?

Deactivation Date attribute set: Yes
State attribute set: No (an Opaque Object does not support the State attribute)

  • If an opaque object is revoked or destroyed, is the state set in these cases?

No: See above

---

Â

From: Alexis Abell [mailto:alex.abell@oracle.com]
Sent: January-04-19 3:29 PM
To: kmip-comment@lists.oasis-open.org
Subject: [kmip-comment] Revoking opaque objects

Â

Hello,

I had a question about revoking and the state of opaque objects. I understand that opaque objects can be revoked, but it doesn't specifically say whether or not they can only be revoked with a reason of compromised (via 'key compromise' or 'CA compromise' reasons as per v1.3) or if they can also be revoked with other revocation reasons as well. However, if they are revoked with other revocation reasons, the spec suggests to place the object in a deactivated state, and to set the deactivation date. Under Appendix B. Attribute Cross-Reference, it seems that the Deactivation Date applies to opaque objects, but that State does not. However, in 3.27, it states that the Deactivation Date applies to "All Cryptographic Objects, Templates" and in 3.22, it states that the State applies to "All Cryptographic Objects". The sections for Compromise Occurrence Date, Compromise Date, and Revocation Reason all seem to apply to opaque objects, both in 3.* and in the appendix.

Basically, to summarize:

  • Can opaque objects be revoked with a revocation reason other than 'key compromise' or 'CA compromise'?
  • If they can, is the deactivation date for that object set? Is the state set to deactivated?
  • If an opaque object is revoked or destroyed, is the state set in these cases?

Thanks for your time and help,

Alex Abell


This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]