Hi Brian, I think this is a plan, and in particular, if you do this:
> I have generated a new version of the cryptographic content with a test CA > that uses 2048 bit RSA so > all of the certs are consistent. Then there will be no need to explain differences in certificate key sizes because there won't be any ;-). Hence with a new 2048 bit CA cert in the revised draft, I concur that: > However, in practice, I'm not sure that there is any real need to include > text about what > the CAs should do regarding the key sizes of the certs they are signing, > because they have their own > practices and are unlikely to heed this informational RFC. All of your other proposed actions are fine with me, so go ahead and upload a new version of the draft with the proposed changes. Thanks, --David > -----Original Message----- > From: Brian Hibbard [mailto:[email protected]] > Sent: Wednesday, December 08, 2010 3:42 PM > To: Gonzalo Camarillo; Black, David > Cc: Cullen Jennings; Kumiko Ono; Sparks Robert; Adam Roach > Subject: Re: OPS-DIR review of draft-ietf-sipcore-sec-flows-06 > > Hi, > > Thank you for your input, David. > > If everyone is in agreement, here's how I plan to proceed: > > I have generated a new version of the cryptographic content with a test CA > that uses 2048 bit RSA so > all of the certs are consistent. I'm ready to include that in version 08, > unless there are > objections. However, in practice, I'm not sure that there is any real need > to include text about what > the CAs should do regarding the key sizes of the certs they are signing, > because they have their own > practices and are unlikely to heed this informational RFC. In previous > conversations on the WG list, > we established that that means by which the certs are created, managed, > etc., was something we wanted > to avoid altogether, except that we cannot ignore it entirely if we want to > facilitate interop > testing. > > I will change the Section citation in Section 2.2 as you suggest to refer to > Sections 6.1 and 6.2 of > RFC 5280 and not just to Section 6.1.4. Actually, I'm not sure why it was > only 6.1.4 to begin with. > > I will change the reference to CRL validation in Security Considerations to > both Section 3.3 and > Section 6.3 of RFC 5280, instead of just Section 3.3. > > David, if you're OK with it, I would like to use your warning text with some > minor modification as a > new paragraph at the end of Section 5: > > "Please note that the certificate path validation algorithm described in > Section 6 of RFC 5280 is a > complex algorithm for which all of the details matter. There are numerous > ways in which failing to > precisely implement the algorithm as specified in Section 6 of RFC 5280 can > create a security flaw, a > simple example of which is the failure to check the expiration date that is > already mentioned above. > It is important for developers to ensure that this validation is performed > and the results are > verified by their applications or any libraries that they use." > > Thanks, all, > Brian > > > On Dec 3, 2010, at 2:25 PM, <[email protected]> <[email protected]> wrote: > > > I have performed an Operations Directorate review of > > draft-ietf-sipcore-sec-flows-06 > > > > Operations directorate reviews are solicited primarily to help the area > > directors improve their > efficiency, particularly when preparing for IESG telechats, and allowing them > to focus on documents > requiring their attention and spend less time on the trouble-free ones. > Improving the documents is > important, but clearly a secondary purpose. A third purpose is to broaden > the OpsDir reviewers' > exposure to work going on in other parts of the IETF. > > > > Reviews from OpsDir members do not in and of themselves cause the IESG to > > raise issue with a > document. The reviews may, however, convince individual IESG members to raise > concern over a > particular document requiring further discussion. The reviews, particularly > those conducted in last > call and earlier, may also help the document editors improve their documents. > > > > -------------- > > > > Summary: This draft is basically ready for publication, but has nits that > > should be fixed before > publication. > > > > This draft is aimed at improving the productivity of SIP over TLS > > interoperability events and the > interoperability of SIP over TLS implementations. As such, it's a positive > contribution to network > operations and management, as improved interoperability reduces operational > issues that would > otherwise arise. > > > > I found a few nits and have a few suggestions: > > > > The CA certificate uses a 1024-bit RSA key, whereas the host and user > > certificates use 2048-bit RSA > keys. This results in using a 1024-bit RSA key to vouch for the validity of > 2048-bit RSA keys. While > acceptable for interoperability testing, this is not good operational > security practice - I would > suggest asking a PKIX expert (e.g., Steve Kent) for appropriate language to > warn about this. > > > > At the end of Section 2.2, the Section citation from RFC 5280 is wrong. > > Sections 6.1 and 6.2 should > be cited, instead of just Section 6.1.4. Also, the CRL checking in Section > 6.3 of RFC 5280 should be > added as a reference cited in the last paragraph of the security > considerations section. > > > > Somewhere, probably in Section 5, a warning should be added that the > > certificate path validation > algorithm is a complex algorithm for which *all* the details matter - there > are numerous ways in which > failing to precisely implement the algorithm as specified in Section 6 of RFC > 5280 can create a > security flaw, a simple example of which is the failure to check the > expiration date that is already > mentioned in Section 5. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > [email protected] Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
