Subject: Re: IESG Comments on draft-ietf-pkix-ipki-new-rfc2527-01.txt

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 24 Jan 2003 14:39:51 -0500

In message <[email-masked]>, "Alice Sturgeon
" writes:
>There are lots of people, including me, who are looking forward to this new
>RFC being issued.  We should really try to get past the stumbling blocks.
>On the first point, I would only note that RFC 2527 does not have a security
>considerations section.  Is it mandatory that informational RFCs have a
>security considerations section?  Having said that, both the effective RFC
>and the I-D deal extensively with security, and the considerations emanating
>from the provisions of this subject (in both the RFC and the I-D) seem, to
>me, blindingly obvious.  Nonetheless, it would not be difficult to distill
>some of the most important security concepts and put them into a discrete
>section.  Another question: is it appropriate to reference other standards,
>in this context to point readers in the direction of extensive and detailed
>security guidance?  Security considerations would note that developing and
>implementing a CP and CPS imply a total secure environment with controls
>commensurate to the level of assurance and applications to be used.  I'd
>reference some of the ISO standards that help in that regard, such as ISO
>Technical Report 13335 Guidelines on the management of IT security, or ISO
>17799 Code of practice for information security management, as examples.

It's absolutely appropriate.

My own view is that a Security Considerations section should discuss 
residual vulnerabilities, especially non-obvious ones, and the 
appropriate countermasures.  The issue of a total secure environment is 
an obvious candidate.

>On the second point, the authors of the revision did a mapping as is
>recommended in the message below.  This was done for revision purposes, in
>April 2001; I believe the intent was to offer a mapping for those who had
>CPs/CPSs based on RFC 2527, to facilitate a conversion and comparison
>between CPs/CPSs based on the 1999 RFC and those based on the revision, but
>it was planned to offer this separately from the new RFC.  Note that there
>was some argument that, once XML-type tagging is used for automating this
>type of document, then the manual mapping would be unnecessary.  If it
>thought to be desirable, then the mapping that was done (almost two years
>ago now) is probably still available and valid, but I defer to the authors
>on that point.  It should not be overly difficult to extract from the
>mapping the substantive changes that have been made.

A detailed field-by-field mapping isn't necessarily what's called for 
here, though it wouldn't hurt.  A general description of the nature of 
the changes would be useful.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)