[Servercert-wg] Draft Ballot for Cleanups

[Dimitris Zacharopoulos (HARICA)]

On 2019-10-18 4:35 μ.μ., Ryan Sleevi wrote:
>
>
> On Fri, Oct 18, 2019 at 5:31 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>     On 18/10/2019 3:50 π.μ., Ryan Sleevi via Servercert-wg wrote:
>>
>>
>>     On Thu, Oct 17, 2019 at 8:18 PM Jacob Hoffman-Andrews via
>>     Servercert-wg <servercert-wg at cabforum.org
>>     <mailto:servercert-wg at cabforum.org>> wrote:
>>
>>         On Thu, Oct 17, 2019 at 5:14 PM Ryan Sleevi via Servercert-wg
>>         <servercert-wg at cabforum.org
>>         <mailto:servercert-wg at cabforum.org>> wrote:
>>
>>             On Thu, Oct 17, 2019 at 7:59 PM Jacob Hoffman-Andrews via
>>             Servercert-wg <servercert-wg at cabforum.org
>>             <mailto:servercert-wg at cabforum.org>> wrote:
>>
>>                 I'm working my way through the diffs, and overall
>>                 this looks great. Thanks for putting it together. I
>>                 do notice there's one important Effective Date that's
>>                 in the past but you haven't removed: 1 July 2012, the
>>                 overall effective date of the BRs. Is there any
>>                 reason not to remove this one as well?
>>
>>
>>             Nope! No strong view.
>>
>>
>>         I'll work on a PR.
>>
>>
>>     Thanks. I went and merged
>>     https://github.com/sleevi/cabforum-docs/commit/4ed95dc591a228cc5a1ec27842af1a36db77b3ed
>>
>>     In the process, I spotted a few more areas of dates that have now
>>     passed from when we started this whole process. If someone could
>>     spot check
>>     https://github.com/sleevi/cabforum-docs/pull/6/files and make
>>     sure the requirements have stayed the same, that would be great.
>>
>>     Of particular interest are the changes to 4.2.1; while not
>>     consistent with Ballot 197, it's possible that the provisions
>>     might be read that "If the CA obtained the data prior to 1 March
>>     2018" rather than "If the issuance is prior to 1 March 2018, and
>>     the CA obtained the data...". The latter interpretation is what
>>     is spelled out in 197, but the former interpretation can be read
>>     with the way things are worded.
>>
>>     If Wayne, Jacob, or someone interested in this section could give
>>     a spot check (as well as the other sections that have since
>>     passed, such as underscores or CP/CPS changes), that'd be great.
>
>     This is probably something minor but I think there are Subordinate
>     CA Certificates that are used as Trust Anchors in various Root
>     Programs.
>
>
> I'm not sure I understand this bit / what the concern is / what 
> section this causes issue for?

I was looking at 
https://github.com/cabforum/documents/compare/master...sleevi:2019-07-Cleanups

You changed the definition of the Test Certificate in section 1.6.1 to 
say "A Certificate which is issued under a CA where there are no 
certificate paths/chains to a root certificate subject to these 
Requirements."

I pointed out the fact that there can be cases where an Intermediate CA 
Certificate acts as a Trust Anchor and not a root.
>
>     I am also not sure what the goals for Test Certificates really
>     are. Is the intent for Test Certificates to never (past, present
>     and future) chain to a CA Certificate that can ever be used as a
>     Trust Anchor? ANY Trust Anchor? Trust Anchors used for
>     Publicly-Trusted Certificates (as defined in section 1.6.1)?
>
>
> This again goes back to the "default-deny" vs "default-allow". The 
> definition of "Test Certificates" in the BRs was, at least, only 
> intended to be used with a specific validation method. That was the 
> only time Test Certificates were referenced. A Default-Deny would say 
> "Unless I'm doing this validation process, DO NOT issue Test 
> Certificates". A Default-Allow approach says "I can issue as many Test 
> Certificates as I want, for whatever I want, oh, and I can use them 
> for validation as well".

Seeing how you changed the definition of "Test Certificate", I thought 
it would be good to send a clear and unambiguous signal to readers of 
the BRs about what are the expectations and rules for a "Test 
Certificate" with the broader meaning, not scoped within the deprecated 
3.2.2.4.9. I don't think the "default-deny", "default-allow" discussion 
is related to the change of this definition. Setting this definition 
right would avoid misunderstandings about the expectations for 
general-purpose "test certificates".

>
> We removed the validation method a while back - this was 3.2.2.4.9. 
> Under a "Default-Deny", there should be no test certificates. Under a 
> "Default-Allow", the concern is that if we remove the definition, CAs 
> will make up their own interpretation/definition of what a "test 
> certificate" is.
>
> So that's the "why keep it" - which until we resolve unambiguously in 
> favor of "Default-Deny", there's going to be interpretation issues.
>
> So the second half is "What do we expect, if CAs are going to rely on 
> this ambiguity". The expectation is that, for a hierarchy that 
> is-or-will-be publicly trusted, there are zero test certificates ever 
> issued. That is, you can't have a root that is not yet publicly 
> trusted, issue a bunch of "Test Certificates" that violate a bunch of 
> rules ('but it's ok, they're only test certificates' - even if the BRs 
> never say you can violate the rules) - and then apply to have that 
> root publicly trusted. There is at least one CA, which is a member of 
> the Forum, that took that interpretation and view.
>
> So Wayne was highlighting it would be useful to be clear here. 
> However, "clear" means changing the definition in a way at least one 
> CA (historically) disagreed with. So he was suggesting, and I agree, 
> that it would be better as a separate ballot, since that might be more 
> normative than clarity.

I am aware of the issues created from that definition when it was linked 
to 3.2.2.4.9. This is an example of things we want to avoid going 
forward, especially when we describe "extensions" with specific OIDs, 
without providing ASN.1 module like we've done in the EV Guidelines for 
.onion and other extensions. In any case, if you and Wayne want to 
change the definition of the "Test Certificate" to be widely scoped and 
not specifically for 3.2.2.4.9 (which I also support), then my proposed 
language may be useful for you. In the meantime, for the cleanup ballot, 
since method 3.2.2.4.9 is deprecated, I suggest we remove this 
definition and re-introduce it in a future ballot.


>     I also find the first paragraph of 1.1 problematic "The
>     requirements are not mandatory for Certification Authorities
>     unless and until they become adopted and enforced by relying-party
>     Application Software Suppliers". I don't think this meets the
>     current expectations, but that's an issue to discuss separately.
>
>
> It's exactly how it is. I totally welcome a separate discussion, but 
> this seems important and something we should stress. The BRs are not a 
> thing in and of themselves. They are an instrument for the Root 
> Programs to use, adopt, expand, and modify. Their legitimacy, and 
> utility, is derived from Root Programs that use, enforce, and audit 
> against them (and any other requirements they may add)

My concern is not about the Root Programs but about the expectations of 
this community. It would be wrong for any CA to assume that when a CA 
generates a Root Key-Pair and a RootCA Certificate, the Baseline 
Requirements DON'T APPLY UNTIL that Root CA is trusted by an Application 
Software Supplier. Perhaps I am reading this paragraph wrong.


Dimitris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191021/dc67ee2a/attachment-0001.html>