Standards

Most PKI consultancies read the standards. I write them.

I’ve authored several RFCs at the IETF and proposed or endorsed twenty ballots at the CA/Browser Forum across the Server Certificate, Code Signing, and S/MIME working groups. That’s not a credential I list for decoration: it’s the reason I can tell you what a requirement actually means and why it was written that way.

CA/Browser Forum Ballots

IETF RFCs

What this means for your organization

Requirements don’t surprise you. Ballots go through discussion, revision, and voting before they take effect, and effective dates are often months out. If you’re watching that process (or talking to someone who is watching), a sunset or a new certificate profile requirement becomes a planned project instead of a last-minute fire drill or an incident. I can tell you what’s in flight, what’s likely to pass, and what it will take for your organization to comply.

Ambiguity gets resolved at the source. Baseline Requirements language is dense and occasionally contradictory. A meaningful share of the ballots above exist precisely because something was unclear or wrong and needed fixing. When your team disagrees about what a clause requires, I’ve seen (or participated in) the argument that produced the clause, and where the text is broken. Most importantly, I know how to get it changed rather than working around it forever.

Your position can be represented. If a proposed requirement is unworkable for your infrastructure, that objection carries more weight raised during the ballot discussion than after the effective date. Standards bodies respond to specific, technically grounded feedback from people who have to implement the result.

Start a consulting conversation →