On Fri, Aug 23, 2019 at 4:18 PM Jeremy Rowley <jeremy.row...@digicert.com>
wrote:

> > I can think of some incremental steps here:
>
> > - Disclosing exact detailed procedures via CP/CPS
>
>
>
> Maybe an addendum to the CPS. Or RPS. I’ll experiment and post something
> to see what the community thinks.
>

Yup. I've seen plenty of CP/CPSes that place extensive detail within
appendices of their CP/CPS. The important part of having this within the
CP/CPS is the (albeit limited) binding to the audit procedure. After all,
the objective of an audit is to ensure the CP/CPS is fairly stated with
respect to the actual operations practiced, across several dimensions, and
so having that allowlist clearly documented, versioned, and audited helps
provide a degree of assurance to RPs that simply placing in the RPS
wouldn't necessarily achieve.


> >  - An emphasis should be on allowlisting. Anything not on the allowlist
> *should* be an exceptional thing.
>
>
>
> This we actually have internally. Or are you saying across the industry?
> The allow list internally is something prevetted by compliance and legal.
> We’re currently (prompted by a certificate problem report) reviewing the
> entire allowed list to see what’s there and taking anything off that I
> don’t like. Basically we’re using your suggestion of
> https://www.gleif.org/en/about-lei/code-lists/gleif-registration-authorities-list
> plus a couple of lists for banking (like FDIC).
>

Ideally, yes, I'd like to see a transition from ad-hoc interpretations into
formalized lists, whether it be through browser policy or through the
Baseline Requirements/EV Guidelines.

I'd love to see a CA take their existing list and propose it, which would
allow for discussion and rationale (e.g. if there are organizations that
should or should not be on that list), but would also help formalize it as
an industry. DigiCert documenting in its CP/CPS is a good first step.
Better would be DigiCert proposing a ballot, although I'm sure members of
the browser community would be happy to propose a ballot on the basis of
whomever publishes their list first.

Regardless, however, the mere act of publishing that list helps develop
tooling to externally vet compliance and consistency with those statements,
and that might amortize some of the internal tooling costs.

 > - For example, stating DigiCert will always use a State from ISO 3166-2
> makes it clear, and also makes it something verifiable (i.e. someone can
> implement an
>
> automated check)
>
>
>
> Maybe what we’ll do is keep a running list of the checks. We’re finalizing
> on spelling out all states. No abbreviations.  This is something we can
> specify in our RPS – how it looks for each field.
>

Why not CP/CPS? This is somewhat a canonical example of the purpose of a
Certificate Profile as specified within a Certificate Policy. Several CAs,
such as Sectigo and SwissSign, include within their CP extensive profiles
of all certificate types they issue. That's somewhat a model for other CAs
to consider and examine.

You can see Appendix C of Sectigo's CP/CPS, or 7.1 of SwissSign.


>  > - Similarly, enumerating the registries used makes it possible, in many
> cases, to automatically check the serialNumber for both format and accuracy
>
>
>
> Checking the registration number for format and accuracy is something I
> proposed for the new project, but I wasn’t sure how feasible it was
> considering the wide variation. You end up with a lot of different numbers.
> I wonder if you could get it to range for formats? That would certainly be
> doable while adding some layers of protection.
>

I agree, it's going to vary based on the registry. However, enumerating the
registries is the first step to being able to enumerate the numbers and
formats. For example, one of the problem reports for a recent set of issues
went ahead and started a opensource GitHub repository to try and collect
some of that information, based on Registry -
https://github.com/bitcynth/company-number-formats/blob/master/formats.md -
so we certainly know it's possible.


> >- Modifying the CA/B Forum documents to formalize those processes, by
> explicitly removing the ambiguity or CA discretion. DigiCert's done well
> here in the past, removing validation methods like 3.2.2.4.1 / 3.2.2.4.5
> due to their misuse and danger
>
>
>
> One ballot I do want to pass is adding a field for the JOI entity
> information. This way everyone can see where the registration number
> originated. Short of a formalized CAB forum list of permitted entities
> (which is also on the table), this would make it very easy to have a
> conversation on whether what the registration number means. There’s
> probably others, but that’s a request that’s been surfacing a few times.
>

I think I'd invert that priority list. I hear that some CA customers,
particularly in the banking sector, get exceptionally nervous for any
change to certificate profiles, even for something as simple and
uncontroversial as a validity period, so extending the EV Guidelines, which
is a much more marked change, seems like it might take years to be
functionally useful and effective. This is definitely a quintessential
example of where reduced validity periods would help improve the security
for relying parties much sooner, and please don't think this criticism is
opposition to the change - just to prioritizing it over an allowlist.

That's because changing the guidelines to an allowlist approach,
formalizing a list of permitted entities, would require no changes to the
certificate profile that relying parties encounter, while providing clear,
auditable, and reliable changes on a much quicker timescale.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to