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