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

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Thu, 23 Jan 2003 13:41:28 -0500

As you are no doubt aware, draft-ietf-pkix-ipki-new-rfc2527-01.txt has
been held up at the IESG. Although the individual who is holding it up
was not on today's call (I am pushing on him to either generate
concrete comments or to remove his objection).

However other members of the IESG raised some issues on today's call
that it would be good to address:

1. There is no Security Considerations section. We really need to have
    one.

2. It would be nice to have a "Changes since RFC2527" Section. Now I
    know that this document is just about a complete rewrite of 2527,
    so a section by section narrative would not make sense. However
    what would be helpful would be a simple description of what the
    differences are. I.e., If I am operating a PKI in compliance with
    2527, what do I have to change, if anything, to be in compliance
    with this document.

I am confident that we will get this document unstuck and published,
but the changes above would be nice. Thanks.

                         -Jeff

---

From: "Alice Sturgeon" <[email-masked]>
Date: Thu, 23 Jan 2003 16:24:07 -0500

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.
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.

Alice

Alice Sturgeon
Chair
Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC1 SC 27
and
System Policy Architect
SPYRUS
Phone:     613-232-2350
Cell:         613-291-0331

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jeffrey I. Schiller
Sent: January 23, 2003 1:41 PM
To: Santosh Chokhani; Warwick Ford; Randy V. Sabett; Charles (Chas) R.
Merrill; Stephen S. Wu
Cc: IETF PKIX WG List; Steven M. Bellovin
Subject: IESG Comments on draft-ietf-pkix-ipki-new-rfc2527-01.txt

                         -Jeff