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@us.ibm.com
http://www-03.ibm.com/servers/storage/


From: "Paul Suhler" <Paul.Suhler@Quantum.Com>
To: Kevin D Butt/Tucson/IBM@IBMUS
Cc: <t10@t10.org>, <Black_David@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@us.ibm.com]
Sent: Wednesday, October 22, 2008 3:07 PM
To: Paul Suhler
Cc: t10@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@us.ibm.com
http://www-03.ibm.com/servers/storage/

From: "Paul Suhler" <Paul.Suhler@Quantum.Com>
To: <t10@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@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.