[cabfpub] Preballot for IPv6 Support

Ryan Sleevi sleevi at google.com
Mon Dec 15 14:02:30 MST 2014


As discussed on our call last week, I'd like to put together a ballot
requiring that CAs support IPv6 for their external (relying party facing)
infrastructure.

As both servers and clients transition to IPv6-only networks, the goal is
to ensure that services RPs need are accessible. For example, an IPv6-only
server that wishes to staple OCSP responses needs to be able to reach the
CA's OCSP responder.

Before proposing dates/timelines, it'd be helpful to understand where the
CA's current infrastructure and plans are, so that we can reach a happy
medium.

Specifically

---MOTION BEGINS---

Update Section 13.2.1 of the Baseline Requirements as follows:

From:
"The CA SHALL make revocation information for Subordinate Certificates and
Subscriber Certificates available in accordance with Appendix B."

To:

"The CA SHALL make revocation information for Subordinate Certificates and
Subscriber Certificates available in accordance with Appendix B.

The CA SHALL make this information available via both IPv4 and IPv6. For
each DNS host included in accordance with Appendix B, lookups to the
authoritative resolver MUST return either or both A and AAAA records if
requested."

Update Appendix B, Section 2(b) of the Baseline Requirements as follows:

From:
"This extension MUST be present and MUST NOT be marked critical. It MUST
contain the HTTP URL of the CA’s CRL service."

To:
"This extension MUST be present and MUST NOT be marked critical. It MUST
contain the HTTP URL of the CA’s CRL service. See Section 13.2.1 for
details."

---MOTION ENDS---

I'm not terribly happy with this wording, but it's a first attempt. Putting
this language in 13.2.2 feels more natural, but Appendix B directly
references 13.2.1.

In particular, this covers two extensions / three services:
- crlDistribution Points (Appendix B, Section 2(b) and Section 3(b) )
- authorityInfoAccess for caIssuers (Appendix B, Section 2(c) and Section
3(c) )
- authorityInfoAccess for OCSP (Appendix B, Section 2(c) and Section 3(c) )

The wording proposal is a little messy since the client can request whether
they want A, AAAA, or both, so it's not necessary that the DNS give AAAA
records back if the client didn't ask (for example).

This doesn't affect the rest of the CAs' infrastructure - they're not
required to use IPv6 internally, they're not required to make their general
webpages IPv6 available, email, etc. This only applies to the key aspects
used by clients (AIA-caIssuers) and servers (CRLDP & AIA-OCSP)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141215/f19aa453/attachment.html 


More information about the Public mailing list