T10/08-346r1 Posted (SPC-4: Correction to IKEv2-SCSI Certificate Request Payload )

Kevin D Butt kdbutt at us.ibm.com
Fri Oct 24 09:51:05 PDT 2008


Formatted message: <A HREF="r0810241_f.htm">HTML-formatted message</A>

Paul,
Yes, I think so.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 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:
"Paul Suhler" <Paul.Suhler at Quantum.Com>
To:
Kevin D Butt/Tucson/IBM at IBMUS
Cc:
<t10 at t10.org>, <Black_David at emc.com>
Date:
10/24/2008 09:47 AM
Subject:
RE: T10/08-346r1 Posted (SPC-4: Correction to IKEv2-SCSI Certificate 
Request Payload )
Hi, Kevin.
David and I talked this over and we're amenable to changing the wording to 
requiring "one or more" certification authority values.  In the absence of 
other input, my plan is to make that change in the CAP meeting and move 
the proposal as modified.
Would that satisfy your concerns?
Thanks,
Paul From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Wednesday, October 22, 2008 3:07 PM
To: Paul Suhler
Cc: t10 at t10.org
Subject: Re: T10/08-346r1 Posted (SPC-4: Correction to IKEv2-SCSI 
Certificate Request Payload )
Paul, 
IBM takes issue with the following: 
<<Device servers that support certificates should support a mechanism 
outside the scope of this standard for replacing certification authority 
values and shall have the ability to store at least four certification 
authority values to facilitate such replacements. >> 
First, if the requirement is "should support a mechanism outside the scope 
of this standard" then don't mandate what that mechanism shall include 
(i.e., 4 trust anchors).  We are OK with the should support a mechanism, 
but there should be no mandate to require four trust anchors.  If you wish 
to give an example of how IKEv2 does it, then point to an RFC (or whatever 
document) as an example of how one might chose to implement. 
Second, mandating four trust anchors is what is done in FC-SP because the 
certificates are transmitted in-band.  There are certainly potential 
implementations in SCSI where the certificates could be transmitted in 
physically protected enclosures or at some panel, etc.	In these scenarios 
one trust anchors in nonvolatile memory should be plenty.  If additional 
trust anchors are needed they could be transmitted during power up 
processing from the enclosure to the drive.  Or whatever an implementer 
chooses.  You might want to say "shall have the ability to store at least 
one certificate and may need to be able to store more" 
Third, devices may have difficulty putting aside enough nonvolatile 
storage for four certificates - that would be any where from 4k to 8k of 
space depending on type of certificate. 
Please remove the requirement mandating at least four certificates. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 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: 
"Paul Suhler" <Paul.Suhler at Quantum.Com> 
To: 
<t10 at t10.org> 
Date: 
10/22/2008 12:15 PM 
Subject: 
T10/08-346r1 Posted (SPC-4: Correction to IKEv2-SCSI Certificate Request 
Payload )
Hi, everyone. 
David Black and I have revised the original proposal and it has been 
posted.  NOTE:	This includes a new requirement that the device server 
shall support at least four trust anchors.  This was borrowed from FC-SP 
and shouldn't be a problem, but your mileage may vary. 
http://www.t10.org/ftp/t10/document.08/08-346r1.pdf 
Thanks, 
Paul 
___________________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office: 
949.856.7748 | paul.suhler at quantum.com 
___________________________________
Disregard the Quantum Corporation confidentiality notice below.  The 
information contained in this transmission is not confidential. Permission 
is hereby explicitly granted to disclose, copy, and further distribute to 
any individual(s) or organization(s), without restriction.
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information 
is not permitted unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not responsible 
for the proper and complete transmission of the substance of this 
communication or for any delay in its receipt.



More information about the T10 mailing list