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

Paul Suhler Paul.Suhler at Quantum.Com
Fri Oct 24 09:47:17 PDT 2008


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

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/
<http://www-03.ibm.com/servers/storage/&gt;  
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
<http://www.t10.org/ftp/t10/document.08/08-346r1.pdf&gt;  
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