Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)
draft-ietf-pkix-rfc3770bis-03

IANA Comments:
As stated in the IANA Considerations section, this document uses an arc that was delegated by the IANA, however this document itself does not request any IANA Actions.

[Ballot comment]
Other nits:

Section 1: Token Ring here as well, is this reference out of place in a new document?

Section 2:

for use by a peer with the EAP in the LAN environment. Inclusion of
                      ^^^

[Ballot discuss]
Section 1.1. Changes since RFC 3770...

In addition to there being five, not three, items listed here it seems that the list may not be entirely complete. One of the items that was listed was a corrected typo, a diff shows changes beyond this.

Also, one of the changes listed:

      * Uses the terms "peer", "EAP Server", and "supplicant" as they
        are defined in [EAP] and [802.1X].  RFC 3770 used "client"
        and "server".

I think that it is impossible to satisfy both EAP and 802.1x terminology in the same document. I believe EAP uses the term "peer" and 802.1x "supplicant" for effectively the same entity. In this document, it looks like "supplicant" is used in the Introduction, and "peer" elsewhere in the document. Might be a good idea to pick one, refer to that as the chosen term, and perhaps even include a definition of both in a terminology section.


Section 2, was it intentional to delete this line from RFC3770 (and if so, which change was this associated with in section 1.1?)

id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}

[Ballot comment]
Comments from Spencer Dawkins Gen-ART review

In section 1, there is text that says

  Including a list of SSIDs in a certificate extension
  facilitates automated selection of an appropriate X.509 public key
  certificate without human user input.  Alternatively, a companion
  attribute certificate could contain the list of SSIDs.

The document addresses both cases (in Section 3 and in Section 4) - it
would be nice to point to the relevant sections, in this paragraph.

In section 1.1, there is text that says

  This document is primarily same as RFC 3770.  Three changes are
  included:

while at least five changes are listed ("math is hard" ...)

PROTO Questionnaire and Writeup for 3770bis

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

The chairs have both reviewed this version of the Internet Draft and
agree this ID is ready to forward for publication.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

This document has undergone a thorough review.  Most WG members reviewed

the document during WG Last Call for 3770.  The Last Call for 3770bis

allowed new members, and members that were unable to find time to review

3770, an opportunity to review the specification.  I have no remaining

concerns about depth or breadth of reviews.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No such concerns.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No concerns.  This document is stable and has been thoroughly discussed.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The WG consensus is strong but it should be noted that this document has
a more selective audience even within PKIX.  Some members of the WG are

very focused on core documents such as 3280bis and SCVP, and may not have

read this specification.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No.  The editors did a very nice job of achieving consensus.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes

  1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

Yes

-----------------------------------------------------

Document Write-up

Technical Summary

This document defines mechanisms supporting Extensible Authentication
Protocol (EAP) [EAP] authentication methods that employ X.509
public key certificates.  This document defines two EAP extended key usage
values and a public key certificate extension to carry Wireless LAN (WLAN
System Service identifiers (SSIDs), and describes how these mechanisms may
be applied to support authentication in Point-to-Point Protocol (PPP) and
Wireless Local Area Networks (WLAN).

Working Group Summary

The working group had consensus to advance the draft to Proposed
Standard.

Protocol Quality

This document has been reviewed by members of the ietf-pkix@imc.org
mailing list and by the working group chairs.