SPC-4 Add Security Protocol page for reporting security compliance (T10/11-102)

[Kevin D Butt]

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1105192_f.htm">HTML-formatted message</a>

Gerry,
I like the change to 7.7.1.5.2 FIPS 140 compliance descriptor that makes 
it clear that this certificate applies to the device, but the use needs to 
ensure that the correct mode is being used.
The FIPS 140 compliance descriptor (see table new3) contains information 
that may be used to locate information about a FIPS 140 certificate 
associated with the device. The device may or may not be operating in the 
mode specified by that certificate.
However, I wonder if the statement, "The device may or may not be 
operating in the mode specified by that certificate." belongs in the 
overview (i.e., 7.7.1.5.1 Security compliance information overview)? While 
only the FIPS is currently listed will we need the same statement in each 
additional type added - or does this need examined on a case by case 
basis?
As it stands now, this resolves my objections.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
From:	Gerry Houlder <gerry.houlder at seagate.com>
To:	T10 Reflector <t10 at t10.org>
Date:	05/19/2011 09:13 AM
Subject:	Re: SPC-4 Add Security Protocol page for reporting 
security compliance (T10/11-102)
Sent by:	owner-t10 at t10.org
The discussion at the CAP meeting was riding a fine line between "not 
guaranteeing compliance just because the notice is returned" and "having 
so many mays that the notice is useless". The sentences quoted by Paul 
were already greatly relaxed from the wording discussed in CAP and 
rejected at the plenary meeting. I invite all those that voted no at the 
plenary to review rev. 2 of the proposal to see if that wording satisfies 
their concerns. Note that there are change bars to reflect changes 
requested at the CAP meeting and after the plenary (by Curtis and David 
Black)	and I hope the other interested parties will also see the changes 
as satisfying their concerns.
On Wed, May 18, 2011 at 7:09 PM, Ballard, Curtis C (StorageWorks) <
curtis.ballard at hp.com> wrote:
Paul,
Thanks for the thoughts.
Gerry Houlder (Seagate), David Black (EMC), and myself (Curtis Ballard, 
HP) got together following the plenary meeting last week and worked on 
wording that would make it more clear that the descriptors describe a 
security certificate that “Applies To” the device and that the device
“may 
or may not” be operating in the mode described by the certificate.  That 
wording was not there following the CAP review.
It looks like Gerry has already incorporated those changes in the revision 
posted and the one you reference. 
http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-102r2.pdf
With those revisions I am satisfied that there is sufficient guidance for 
what the descriptors mean.  I don’t feel that adding additional “may” 
statements is necessary.
Curtis Ballard
Hewlett Packard
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Paul 
Suhler
Sent: Wednesday, May 18, 2011 5:27 PM
To: T10 Reflector
Subject: SPC-4 Add Security Protocol page for reporting security 
compliance (T10/11-102)
Hi, everyone.
At last week’s plenary, we decided not to go forward with the revision of 
Gerry’s proposal approved in CAP.  Instead we said that we’d discuss 
alternative wording that would be acceptable.
The issue was that (if I recall correctly) we’d like to be able to report 
this descriptor even if the firmware running in the device had been 
neither submitted nor approved as complying with the cited standard.  In 
such a case, if the SPC-4 wording requires that the standard applies to 
the device, then reporting the descriptor might be considered inaccurate 
or misleading. I think that we want to report the actual Hardware Version, 
Version, and Module Name of the device, which may not appear on the 
compliance certificate on the NIST (or other agency) web site.
One possible change would be to scrub the proposal and use “may” wherever appropriate.  For example, in the latest revision (
http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-102r2.pdf), the first sentence 
in 7.7.1.5.1:
“The security compliance information page contains information about 
security standards that apply to this device.”
Would change to:
“The security compliance information page contains information about 
security standards that may apply to this device.”
The first paragraph of 7.7.1.5.2 already seems weaselly enough:
“The FIPS 140 compliance descriptor (see table new3) contains information 
that may be used to locate information about a FIPS 140 certificate 
associated with the device. The device may or may not be operating in the 
mode specified by that certificate.”
Then,
“The REVISION field is an ASCII character (see 4.4.1) that indicates the 
FIPS 140 revision that applies to the device (see table new4).”
Could change to:
“The REVISION field is an ASCII character (see 4.4.1) that indicates the 
FIPS 140 revision that applies may apply to the device (see table new4).”
Etc., etc. for the other fields.  Perhaps we change “…as reported by 
NIST.” to “… which may be reported by NIST.”  ?
Do we also need to explicitly state up front that the device may or may 
not comply, and that the information in the descriptor should be checked 
against the certifying agency’s web site to determine compliance?
Please share your thoughts.
Thanks,
Paul
_____________________________________________________________________________
________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office: 
949.856.7748 | paul.suhler at quantum.com 
Preserving the World's Most Important Data. Yours.â„¢