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)
RFC 6125

Note: This ballot was opened for revision 14 and is now closed.

(Russ Housley) (was No Objection) Yes

(Alexey Melnikov) Yes

(Robert Sparks) (was Discuss) Yes

(Sean Turner) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

Comment (2011-01-17)
No email
send info
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/

(Adrian Farrel) No Objection

Comment (2011-01-20)
No email
send info
I am ballotting "no objection" based on only a partial review, and trust of the ADs who are authors, ballotted "yes", and raised Discusses.

(Tim Polk) (was Discuss) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) Recuse