For those of you attending the key management meeting next week...

Paul Entzel Paul.Entzel at quantum.com
Fri Dec 2 10:38:41 PST 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* "Paul Entzel" <Paul.Entzel at Quantum.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C5F76F.9DD169AB
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hello,

For those of you attending the key management meeting next week, here's
something to think about over the weekend.

>From some of the documents I have seen I believe we may be better off
not using the term "Key ID" to describe the additional data passed with
the encryption key.  It appears there could be more than just a "Key =
ID"
in the additional data, and the additional data may not even contain a
true "Key ID".  Either way, from the device server's perspective, we
don't care what is in the data.  All we care about is this additional
data must be treated.

Here's my idea.  I would like to coin a new phrase to describe this =
data
to avoid conflicts with other standards.  Let's call it Key Associated
Data (KAD).  I think its usage needs to be optional for both the drive
and the application, so a drive shall support 0 and may support up to N
bytes of KAD (N may be 0).  The software may request 0 to M bytes of =
KAD
be associated with a key that it sets as long as M is less than or =
equal
to N.

I think the drive should be allowed to add the KAD to the stream such
that it is authenticated with the key, but should not be required to.
This allows flexibility in that the KAD can be recorded in a directory
or in control data outside the normal stream of data if the format
dictates.  I do believe the device should report if some or all of the
KAD is authenticated or not.

Referencing T10/05-446r0, we can add the KAD to the page that sets the
encryption key along with a length field.  Each algorithm descriptor
should get a maximum KAD length field added to it (0 indicating KAD is
not supported for this algorithm).  At the conference call, somebody
mentioned there are 3 versions of the KAD that the drive could report,
but I can only come up with 2.  The drive needs to report the KAD for
the key that will be used to encrypt or decrypt data (the KAD sent with
the key assigned to the current initiator).  This KAD value must always
be available as long as the key is valid. =20

The drive also need to be able to report the KAD associated with the
next block should a READ command be issued (similar to READ POSITION).
This KAD value may not always be available for several reasons:

1.      The next block is not encrypted.=20
2.      The next block has not been read from the medium into buffer
where the KAD can be retrieved.=20
3.      There was an error reading the next block.=20
4.      There isn't a next block (EOD).=20
5.      Other reasons I haven't even thought of.=20

To accommodate this, a VALID bit should be included in the status page
that sends this KAD.  If no KAD is associated with the next block, the
VALID bit would be 1 and the KAD length would be 0.

Anyway, think about it, we'll talk about this on Monday.

Paul Entzel

Quantum



------_=_NextPart_001_01C5F76F.9DD169AB
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

 For those of you attending the key management meeting next = week... Hello, For = those of you attending the key management meeting next = week, here;s something to think about = over the weekend. From = some of the documents I have seen I believe we may be better off not = using the term ;Key ID; to describe the additional data = passed with the encryption key.  It appears there could be more = than = just a ;Key ID; in the additional data, = and the additional data may not even contain a true = ;Key ID;.  Either way, from the device server's = perspective, we don't care what is in the data.  All we care about = is this additional data must be treated. Here's my idea.  I would like to coin a new phrase = to describe this data to avoid conflicts with other standards.  = Let's call it Key Associated Data (KAD).  I think its usage needs = to be optional for both the drive and the application, so a drive shall = support 0 and may support up to N bytes of KAD (N may be 0).  The = software may request 0 to M bytes of KAD be associated with a key that = it sets as long as M is less than or equal to N. I = think the drive should be allowed to add the KAD to the stream such = that it is authenticated with the key, but should not be required to. = This allows flexibility in that the KAD can be recorded in a directory = or in control data outside the normal stream of data if the format = dictates.  I do believe the device should report = if some or all of the KAD is authenticated or not. Referencing T10/05-446r0, we can add the KAD to the page that sets the encryption = key along with a length field.  Each algorithm descriptor should get a maximum KAD length = field added to it (0 indicating KAD is not supported for this = algorithm).  = At the conference call, somebody mentioned there are 3 = versions of the KAD that the drive could report, but I can only come up = with 2.  The drive needs to = report the KAD for the key that will be used to encrypt or decrypt data (the KAD sent = with the key assigned to the current = initiator).  This KAD value must = always be available as long as the key is valid.  The = drive also need to be able to report the KAD associated with the next = block = should a READ command be issued (similar = to READ POSITION).  This KAD value may not always be = available for several = reasons: 1.      The next block is not encrypted. 
2.      The next block has not been read from the medium into = buffer where the KAD can be retrieved. 
3.      There was an error reading the next block. 
4.      There isn;t a next block (EOD). 
5.      Other reasons I haven;t even thought = of. To accommodate this, a VALID bit should be included in the status = page that sends this KAD.  If no KAD is associated with the next = block, the VALID bit would be 1 and the KAD length would be = 0. Anyway, think about it, we;ll talk about this on = Monday. Paul = Entzel Quantum 

------_=_NextPart_001_01C5F76F.9DD169AB--





More information about the T10 mailing list