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. 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? 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? 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. I would be more comfortable if these attributes were moved to the Optional bucket. <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> 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"><rturner@amalfisystems.com></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>