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