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


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

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

Subject: Re: [kmip] NIST SP800-57 Part 1 - Normative Reference

On 9/08/2013 6:46 AM, Michael Stevens wrote:
>> The discussion at the time (in the face to face and prior and subsequently) was
>> on whether or not it is a requirement for a KMIP server to automatically revoke
>> a public key managed object when a private key managed object is revoked. 
> To clarify: The problem is not that a KMIP server is required to revoke. The problem is that AKLC-M-3 requires that the KMIP server NOT revoke. A server that does revoke the public key will not return "Preactive" when the state is checked at time 7. This is not listed as an acceptable deviation. 
> The consensus of the group was that for a KMIP server to automatically revoke was not required. The behaviour described by the test case is that for a KMIP server to automatically revoke is forbidden.

Thanks for confirming this email thread is about that particular issue
and not some other (unstated) one - it was entirely unclear what the
context was from John's initial email.

We also discussed (repeatedly) that any dependence on behaviour which
was not mandated by KMIP being performed by a KMIP server would be
inherently non-interoperable and that if this was a behaviour that a
vendor felt was appropriate that a separate profile should be
constructed to cover that range of behaviours (and the other associated
items) as profiles (and not the specification itself) is how these
things are meant to be handled.

Vendors are always free to elect which profiles their products support.

So far we have not seen any profile proposal from Quintessence on any of
the additional behaviours that you have added into your server - and
each of those behaviours in my view has merit in a range of contexts -
however as default behaviours they break interoperability. Many vendors
do extend behaviours as optional items - and allow configuration on a
per user (or other) basis.

We have previously offered to co-author one or more profiles covering
the behaviours we see merit in - and that offer remains open.


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