attachment

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks Ira, this definitely helps.<br>
<br>
I am still a little concerned that if HCDs are the only products that
use these attributes, does it make sense for them to be mandatory? What
are the chances of other products (PCs, in particular) adopting the
same attributes?<br>
<br>
If we're the only ones using them, will administrators really want to
set up generic networking policies that are enforced only on one
endpoint of the communication path?<br>
<br>
Is it possible that HCDs could be enforced to support a particular
minimum cipher suite, but some of the PCs on the network that are
unable to support that same minimum are still able to join the network?
Then those PCs would be unable to communicate with the HCDs.<br>
<br>
I would be more comfortable if these attributes were moved to the
Optional bucket.<br>
<pre class="moz-signature" cols="76">--
Regards,
Brian Smithson
PM, Security Research
PMP, CISSP, CISA, ISO 27000 PA
Advanced Imaging and Network Technologies
Ricoh Americas Corporation
(408)346-4435</pre>
<br>
<br>
Ira McDonald wrote:
<blockquote
 cite="mid:e395be80901311144u66e70346l4e046d6d082492f3@mail.gmail.com"
 type="cite">
  <pre wrap="">Hi,

I think we *also* want to add references to these two IETF BCPs:

RFC 3766 Determining Strengths For Public Keys Used For Exchanging
     Symmetric Keys. H. Orman, P. Hoffman. April 2004. (Format: TXT=55939
     bytes) (Also BCP0086) (Status: BEST CURRENT PRACTICE) (23 pages)

RFC 4086 Randomness Requirements for Security. D. Eastlake, 3rd, J.
     Schiller, S. Crocker. June 2005. (Format: TXT=114321 bytes)
     (Obsoletes RFC1750) (Also BCP0106) (Status: BEST CURRENT
     PRACTICE) (48 pages)

They are both, by the way, well worth reading.

Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: <a class="moz-txt-link-abbreviated" href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434



On Fri, Jan 30, 2009 at 9:39 PM, Randy Turner <a class="moz-txt-link-rfc2396E" href="mailto:rturner@amalfisystems.com">&lt;rturner@amalfisystems.com&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi Brian,
I think the IANA registry actually has the key length specified as part of
the suite enumeration.
Examples are:
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
There are other suites that don't specify numeric key sizes, but in these
cases, the algorithm itself
(3DES for example) work with a specific key size that doesn't vary.
In this case, we may be able to just specify that we're talking about a
minimum suite, with a reference to RFC 5246 and
the IANA registry itself.
Randy

On Jan 30, 2009, at 6:26 PM, Brian Smithson wrote:

I am still wondering how these two attributes can be used in practice. I
know that we can uniquely identify cipher suites using the IANA
registry, but is there an authoritative source to specify that one suite
is "more minimum" than another? And if you consider different key
lengths that might be acceptable for a given suite, then can we really
say that suite X is more minimum than suite Y even if an HCD supports a
relatively long key length for X but only supports a relatively short
one for Y?

--
Regards,
Brian Smithson
PM, Security Research
PMP, CISSP, CISA, ISO 27000 PA
Advanced Imaging and Network Technologies
Ricoh Americas Corporation
(408)346-4435




    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
</body>
</html>