Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
draft-saintandre-tls-server-id-check-14

[Ballot comment]
I am ballotting "no objection" based on only a partial review, and trust of the ADs who are authors, ballotted "yes", and raised Discusses.

[Ballot discuss]
I agree with the review comments supporting publishing this as PS and not as BCP.

The majority of this document is specifying behavior that is appropriate to progress through the standards ladder. There is a small section providing guidance to certificate authorities that could be written as a BCP, encouraging "full and immediate instantiation" (see section 5.1 of RFC2026). If it's important to give that section BCP designation, I suggest placing it in a separate document. However, I think it will have the same effect in this document, published as PS.

Assuming the consensus is to move forward as proposed standard, I expect to move to a "Yes" position.

[Ballot comment]
Section 1.5., paragraph 8:
>    These suggestions are not entirely consistent with all practices that
>    are currently followed by certification authorities, client
>    developers, and service providers.  However, they reflect the best
>    aspects of current practices and are expected to become more widely
>    adopted in the coming years.

  This seems to argue that the doc should be a BCP and not a PS?


Section 1.8., paragraph 28:
>      Transport Layer Security [TLS] negotiation; in this specfication

  Nit: s/specfication/specification/


Appendix A., paragraph 1:
>    recommendations in this specfication: email [EMAIL-SRV] and XMPP

  Nit: s/specfication:/specification:/


Section 7.2., paragraph 1:
>          Implemenations MUST NOT match any form of wildcard, such as a

  Nit: s/Implemenations/Implementations/

[Note]: 'There is an open question on whether this document should be a BCP or PS. As the shepherding AD I don't have a strong opinion either way.
' added

Tentatively adding this to the IESG telechat on January 6th. I believe that GenArt, etc. review comments were addressed, but the comments from Cullen still need to be addressed or at least discussed.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

To: IETF-Announce 
From: The IESG
Reply-to: ietf@ietf.org
Subject: Second Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)) to BCP

The IESG has received a request from an individual submitter to consider
the following document:

- 'Representation and Verification of Domain-Based Application Service
  Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
  Certificates in the Context of Transport Layer Security (TLS) '
    as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-12-16. Exceptionally,
comments may be sent to iesg@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

Note that the First IETF Last Call was issued for Proposed Standard.
The purpose of the Second Last Call is to correctly state that this document
is targeting BCP status and to verify consensus for changes resulted from
the First IETF Last Call.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-11.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18634&rfc_flag=0

This is a big improvement.

There are a couple of changes that should be done, before this should be ready for IETF LC:

1) Add a text saying that dNSName subjectAltName SHOULD be present if the protocol allows for manual server hostname configuration in clients (e.g. for IMAP/POP3 DNS SRV is not used by default)

2) Add back text about use of "secure resolution" using DNSSEC, hostfiles, etc?

3) Possibly talk about EKU, if specified for the protocol.