Use cases of publicly-trusted certificates

[Peter Bowen]

In the discussion of how to handle certain certificates that no longer meet
CA/Browser Forum baseline requirements, Wayne asked for the "Reason that
publicly-trusted certificates are in use" by the customers. This seems to
imply that Mozilla has an opinion that the default should not be to use
"publicly-trusted certificates". I've not seen this previously raised, so
I want to better understand the expectations here and what customers should
consider for their future plans.

Is the expectation that "publicly trusted certificates" should only be used
by customers who for servers that are:
- meant to be accessed with a Mozilla web browser, and
- publicly accessible on the Internet (meaning the DNS name is publicly
resolvable to a public IP), and
- committed to complying with a 24-hour (wall time) response time
certificate replacement upon demand by Mozilla?

Is the recommendation from Mozilla that customers who want to allow Mozilla
browsers to access sites but do not want to meet one or both of the other
two use the Firefox policies for Certificates (
https://github.com/mozilla/policy-templates/blob/master/README.md#certificates
) to add a new CA to the browser?

Thanks,
Peter

[Nick Lamb]

As a relying party I read this in the context of the fact that we're talking about names that are anyway prohibited.

Why would you need a publicly trusted certificate that specifies a name that is publicly prohibited?

I guess the answer is "But it works on Windows". And Windows is welcome to implement a parallel "Windows PKI" which can have its own rules about naming and whatever else and so the certificates could be issued in that PKI but not in the Web PKI.

[Jakob Bohm]

On 27/12/2018 13:39, Nick Lamb wrote:
> As a relying party I read this in the context of the fact that we're
> talking about names that are anyway prohibited.
>

The problem here is that the prohibition lies in a complex legal reading
of multiple documents, similar to a situation where a court rules that a
set of laws has an (unexpected to many) legal consequence.

Such rulings frequently come out from the highest federal courts of the
US and the EU, and this is generally referred to as those courts
effectively creating new legislation.

It would benefit the honesty of this discussion if the side that won in
the CAB/F stops pretending that everybody else "should have known" that
their victory was the only legally possible outcome and should never
have acted otherwise.

> Why would you need a publicly trusted certificate that specifies a name
> that is publicly prohibited?
>

Maybe because it is not publicly prohibited in general (the DNS standard
only recommends against it, and other public standards require some such
names for uses such as publishing certain public keys). The prohibition
exists only in the certificate standard (PKIX) and maybe in the registration
policies of TLDs (for TLD+1 names only).

> I guess the answer is "But it works on Windows". And Windows is welcome
> to implement a parallel "Windows PKI" which can have its own rules about
> naming and whatever else and so the certificates could be issued in that
> PKI but not in the Web PKI.

Actually, my only current uses of such names (none with certificates anyway)
are all done using a non-Windows OS, and the names seem to work with every
DNS library and tool tried.

Also it isn't the "Web PKI". It is the "Public TLS PKI", which is not
confined to Web Browsers surfing online shops and social networks, and hasn't
been since at least the day TLS was made an IETF standard.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Jakob Bohm]

Also, is the recommendation that customers should not use publicly
trusted certificates for servers that are meant to be accessed by the
general public using a Mozilla web browser unless they are

> - committed to complying with a 24-hour (wall time) response time
> certificate replacement upon demand by Mozilla?

Which I have repeatedly argued is extremely onerous on a huge subset of
all server operators.

[Ryan Sleevi]

On Thu, Dec 27, 2018 at 9:30 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Also it isn't the "Web PKI". It is the "Public TLS PKI", which is not
> confined to Web Browsers surfing online shops and social networks, and
> hasn't
> been since at least the day TLS was made an IETF standard.
>

This reply is filled with a number of unrelated and unproductive
non-sequitors, but this one is particularly worth calling out as wrong -
historically and factually.

TLS has, as with the specifications that preceded it (SSL, PCT), treated
PKI as an opaque black box for which inputs go in, and a yes/no come out.
TLS has entirely, and intentionally, left unspecified what goes on within
that box. The existence of TLS, much like the existence of S/MIME, no more
defines the PKI than it defines the color of the sky or what time to set
your alarm for the morning.

The concept of the PKI has, even in traces of the X.500 DIT, considered
itself a loose amalgamation of various different PKIs, interoperating where
they are compatible (technology, policies, implementation), but otherwise
managed distinct. This can be seen from the first discussions of audits,
which were concerned about assessing the interoperability of these distinct
PKIs, to the development and foundation of the PKIX WG, which produced a
number of documents to smooth the technological differences (e.g. RFC
5280-and-predecessors) and policy differences (3647 and predecessors).

Yes, it very much is the "Web PKI", and has been for some time. Considering
those sets of CAs bundled in the context for SSL 2.0 and Netscape Navigator
were very much intended for the Web, it would be demonstrable ignorance to
argue otherwise.

[Ryan Sleevi]

On Thu, Dec 27, 2018 at 9:34 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 26/12/2018 22:42, Peter Bowen wrote:

> Also, is the recommendation that customers should not use publicly
> trusted certificates for servers that are meant to be accessed by the
> general public using a Mozilla web browser unless they are
>

> > - committed to complying with a 24-hour (wall time) response time
> > certificate replacement upon demand by Mozilla?
>

Could you help me understand how that question is meaningfully different
than what Peter originally asked?

He described three combined conditions to be met. You've described a
situation "What if you meet two, but not three". I believe that was
originally captured in his question, so what new information is being asked
about here?

[Jakob Bohm]

On 27/12/2018 16:16, Ryan Sleevi wrote:
> On Thu, Dec 27, 2018 at 9:30 AM Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Also it isn't the "Web PKI". It is the "Public TLS PKI", which is not
>> confined to Web Browsers surfing online shops and social networks, and
>> hasn't
>> been since at least the day TLS was made an IETF standard.
>>
>
> This reply is filled with a number of unrelated and unproductive
> non-sequitors, but this one is particularly worth calling out as wrong -
> historically and factually.
>

And I would say that this more accurately describes your reply.

> TLS has, as with the specifications that preceded it (SSL, PCT), treated
> PKI as an opaque black box for which inputs go in, and a yes/no come out.
> TLS has entirely, and intentionally, left unspecified what goes on within
> that box. The existence of TLS, much like the existence of S/MIME, no more
> defines the PKI than it defines the color of the sky or what time to set
> your alarm for the morning.
>
> The concept of the PKI has, even in traces of the X.500 DIT, considered
> itself a loose amalgamation of various different PKIs, interoperating where
> they are compatible (technology, policies, implementation), but otherwise
> managed distinct. This can be seen from the first discussions of audits,
> which were concerned about assessing the interoperability of these distinct
> PKIs, to the development and foundation of the PKIX WG, which produced a
> number of documents to smooth the technological differences (e.g. RFC
> 5280-and-predecessors) and policy differences (3647 and predecessors).

PKIX clearly uses definitions that make it clear that the same PKI
should be used for most/all TLS implementations for the public Internet,
and this is indeed the common practice on any OS that installs a root
store in a shared location rather than inside browser source code.

For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp-
browserWwwServerAuth" . WWW is mentioned only in a comment under the
OID definition.

>
> Yes, it very much is the "Web PKI", and has been for some time. Considering
> those sets of CAs bundled in the context for SSL 2.0 and Netscape Navigator
> were very much intended for the Web, it would be demonstrable ignorance to
> argue otherwise.
>

Netscape Navigator/Communicator used the same PKI for mail and news
servers, Mozilla Thunderbird still does, and both Google and Mozilla use
such certificates for their public mail and NNTP servers.

[Jakob Bohm]

Using Firefox policies to reconfigure the browser is not a relevant
alternative for genuinely public web servers in the age of HTTPS-
everywhere. That's the difference from the other combinations.

[Ryan Sleevi]

On Thu, Dec 27, 2018 at 10:38 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> PKIX clearly uses definitions that make it clear that the same PKI
> should be used for most/all TLS implementations for the public Internet,
> and this is indeed the common practice on any OS that installs a root
> store in a shared location rather than inside browser source code.
>

This is also not correct, and I'm afraid may be a result of a confusion
between certificate profile and what a PKI is. While I would be more than
happy to help identify your confusion and resolve it, I don't think this
would be the best thread. Unfortunately, both your statement of intent and
history are, thankfully, false.

[Ryan Sleevi]

> Using Firefox policies to reconfigure the browser is not a relevant
> alternative for genuinely public web servers in the age of HTTPS-
> everywhere. That's the difference from the other combinations.
>

I'm sorry, but I still fail to see the question there. That seems to be a
statement of opinion.

Do you believe it's mischaracterizing your question as effectively
restating "What happens if you meet two, but not all three?" If you do,
perhaps you could help clarify what your original question is, without any
statement about what you believe or presume the answer to be. That seems
the best way to get the information you feel is lacking.

[Rob Stradling]

On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote:
<snip>

> For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp-
> browserWwwServerAuth" .  WWW is mentioned only in a comment under the
> OID definition.

Hi Jakob.

Are you suggesting that comments in ASN.1 specifications are meaningless
or that they do not convey intent?

Also, are you suggesting that a canonical OID name must clearly convey
the full and precise intent of the purpose(s) for which the OID should
be used?

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

[Jakob Bohm]

Yes, you are consistently mischaracterizing everything I post.

My question was a refinement of the original question to the one case
where the alternative in the original question (configuring the browser
to trust a non-default PKI) would not be meaningful.

[Jakob Bohm]

On 27/12/2018 17:02, Rob Stradling wrote:
> On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote:
> <snip>
>> For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp-
>> browserWwwServerAuth" .  WWW is mentioned only in a comment under the
>> OID definition.
>
> Hi Jakob.
>
> Are you suggesting that comments in ASN.1 specifications are meaningless
> or that they do not convey intent?
>
> Also, are you suggesting that a canonical OID name must clearly convey
> the full and precise intent of the purpose(s) for which the OID should
> be used?
>

In general no. However in this special case, the comment is
inconsistent with everything else.

[Jakob Bohm]

On 27/12/2018 17:13, Jakob Bohm wrote:
> On 27/12/2018 17:02, Rob Stradling wrote:
>> On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote:
>> <snip>
>>> For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp-
>>> browserWwwServerAuth" .  WWW is mentioned only in a comment under the
>>> OID definition.
>>
>> Hi Jakob.
>>
>> Are you suggesting that comments in ASN.1 specifications are meaningless
>> or that they do not convey intent?
>>
>> Also, are you suggesting that a canonical OID name must clearly convey
>> the full and precise intent of the purpose(s) for which the OID should
>> be used?
>>
>
> In general no.  However in this special case, the comment is
> inconsistent with everything else.
>

Furthermore, this particular comment is absent in the actual ASN.1
module at the end of RFC5280, making it clear that it isn't a semantic
comment.

[James Burton]

The main reason that publicly trusted certificates are used by
organizations for all infrastructure (internal and external) is that it's
far cheaper than building and maintaining an internal PKI.

On Thu, Dec 27, 2018 at 4:14 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 27/12/2018 17:02, Rob Stradling wrote:

> > On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote:
> > <snip>
> >> For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp-
> >> browserWwwServerAuth" . WWW is mentioned only in a comment under the
> >> OID definition.
> >
> > Hi Jakob.
> >
> > Are you suggesting that comments in ASN.1 specifications are meaningless
> > or that they do not convey intent?
> >
> > Also, are you suggesting that a canonical OID name must clearly convey
> > the full and precise intent of the purpose(s) for which the OID should
> > be used?
> >
>

> In general no. However in this special case, the comment is
> inconsistent with everything else.
>

> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Ryan Sleevi]

On Thu, Dec 27, 2018 at 11:12 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Yes, you are consistently mischaracterizing everything I post.
>
> My question was a refinement of the original question to the one case
> where the alternative in the original question (configuring the browser
> to trust a non-default PKI) would not be meaningful.
>

I hope you can understand my confusion, as again, you've provided a
statement, but not an actual question.

Peter provided two, fairly simple to understand, very direct questions:

Is the expectation that "publicly trusted certificates" should only be used
> by customers who for servers that are:
> - meant to be accessed with a Mozilla web browser, and
> - publicly accessible on the Internet (meaning the DNS name is publicly
> resolvable to a public IP), and
> - committed to complying with a 24-hour (wall time) response time
> certificate replacement upon demand by Mozilla?



Is the recommendation from Mozilla that customers who want to allow Mozilla
> browsers to access sites but do not want to meet one or both of the other
> two use the Firefox policies for Certificates (
>
> https://github.com/mozilla/policy-templates/blob/master/README.md#certificates
> ) to add a new CA to the browser?

You presented a question as:

Is the recommendation that customers should not use publicly

> trusted certificates for servers that are meant to be accessed by the

> general public using a Mozilla web browser unless they are committed

> to complying with a 24-hour (wall time) response time certificate
> replacement upon demand by Mozilla?

It would appear that it is merely a rephrasing of that first question, but
as a negative question ("should not") rather than Peter's original positive
question ("should only").

Could you help me understand what's different about Peter's first question
and your question? It's very clear you have opinions as to the second
question, but it still seems as if you're merely asking the first question,
but in a way that provides less information. If there's something new or
unique to the question, rephrasing your question may make it clearer. Doing
so without expressing a particular opinion on what the answer should be
seems like an even more positive step forward.

[Nick Lamb]

On Thu, 27 Dec 2018 15:30:01 +0100

Jakob Bohm via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> The problem here is that the prohibition lies in a complex legal
> reading of multiple documents, similar to a situation where a court
> rules that a set of laws has an (unexpected to many) legal
> consequence.

I completely disagree. This prohibition was an obvious fact, well known
to (I had assumed prior to this present fever) everyone who cared about
the Internet's underlying infrastructure.

The only species of technical people I ever ran into previously who
professed "ignorance" of the rule were the sort who see documents like
RFCs as descriptive rather than prescriptive and so their position
would be (as it seems yours is) "Whatever I can do is allowed". Hardly
a useful rule for the Web PKI.

Descriptive documents certainly have their place - I greatly admire
Geoff Pullum's Cambridge Grammar of the English Language, and I
do own the more compact "Student's Introduction" book, both of which
are descriptive since of course a natural language is not defined by
such documents and can only be described by them (and imperfectly,
exactly what's going on in English remains an active area of research).
But that place is not here, the exact workings of DNS are prescribed, in
documents you've called a "complex legal reading of multiple documents"
but more familiarly as "a bunch of pretty readable RFCs on exactly this
topic".

> It would benefit the honesty of this discussion if the side that won
> in the CAB/F stops pretending that everybody else "should have known"
> that their victory was the only legally possible outcome and should
> never have acted otherwise.

I would suggest it would more benefit the honesty of the discussion if
those who somehow convinced themselves of falsehood would accept this
was a serious flaw and resolve to do better in future, rather than
suppose that it was unavoidable and so we have to expect they'll keep
doing it.

Consider it from my position. In one case I know Jakob made an error
but has learned a valuable lesson from it and won't be caught the same
way twice. In the other case Jakob is unreliable on simple matters of
fact and I shouldn't believe anything further he says.

> Maybe because it is not publicly prohibited in general (the DNS
> standard only recommends against it, and other public standards
> require some such names for uses such as publishing certain public
> keys). The prohibition exists only in the certificate standard
> (PKIX) and maybe in the registration policies of TLDs (for TLD+1
> names only).

Nope. You are, as it seems others in your position have done before,
confusing restrictions on all names in DNS with restrictions on names
for _hosts_ in DNS. Lots of things can have underscores in their names,
and will continue to have underscores in their names, but hosts cannot.
Web PKI certs are issued for host names (and IP addresses, and as a
special case, TOR hidden services).

Imagine if, on the same basis, a CA were to insist that they'd
understood Texas to be a US state, and so they'd written C=TX on the
rationale that a "state" is essentially the same kind of thing as a
"country".

I do not doubt they could find a few (mostly Texan) people to defend
this view, but it's obviously wrong, and when the City of Austin
Independent League of Skateboarders protests that they need to keep
getting certificates with C=TX for compatibility reasons we'd have a
good laugh and tell the CA to stop being so stupid, revoke these certs
and move on.

> Also it isn't the "Web PKI". It is the "Public TLS PKI", which is
> not confined to Web Browsers surfing online shops and social
> networks, and hasn't been since at least the day TLS was made an IETF
> standard.

It is _named_ the Web PKI. As you point out, it is lots of things, and
so "Web PKI" is not a good description but its name remains the Web
PKI anyway.

The name for people from my country is "Britons". Again it's not a good
description, since some of them aren't from the island of Great Britain
as the country extends to adjacent islands too. Nevertheless the name is
"Britons".

Nick.

[Jakob Bohm]

Once again, the question was about the special case of the combination
of Peter's two closely related questions for the case where the option
suggested in the second question (using Firefox policies for
Certificates) makes no sense, as the "customer" does not control the
browser.

But you seem insistent on mischaracterizing an unpleasant question in
every way possible.

[Wayne Thayer]

On Wed, Dec 26, 2018 at 2:42 PM Peter Bowen via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> In the discussion of how to handle certain certificates that no longer meet
> CA/Browser Forum baseline requirements, Wayne asked for the "Reason that
> publicly-trusted certificates are in use" by the customers. This seems to
> imply that Mozilla has an opinion that the default should not be to use
> "publicly-trusted certificates". I've not seen this previously raised, so
> I want to better understand the expectations here and what customers should
> consider for their future plans.
>

The context for the question is that at least one of the organizations
having difficulty with the underscore sunset stated that they couldn't just
replace the certificates - they need to ship updates to the client. If you
are hard-coding certificate information into client software, it's fair to
ask why you're using publicly-trusted certificates (PTCs).

I believe a similar concern was discussed at length during the SHA-1 sunset
in relation to payment terminals. As has been suggested, maybe it's simply
a matter of cost. I suspect, however, that it is more about a lack of
recognition of the responsibilities that come along with using PTCs. In the
spirit of incident reporting, I think it would help to have a better
understanding of the decisions that are driving the use of PTCs in these
use cases.

>
> Is the expectation that "publicly trusted certificates" should only be used
> by customers who for servers that are:
> - meant to be accessed with a Mozilla web browser, and
>

No.

- publicly accessible on the Internet (meaning the DNS name is publicly
> resolvable to a public IP), and
>

No.

- committed to complying with a 24-hour (wall time) response time
> certificate replacement upon demand by Mozilla?
>

> Committed to comply with section 4.9.1.1 (Reasons for Revoking a
Subscriber Certificate) of the BRs - yes.

Is the recommendation from Mozilla that customers who want to allow Mozilla
> browsers to access sites but do not want to meet one or both of the other
> two use the Firefox policies for Certificates (
>
> https://github.com/mozilla/policy-templates/blob/master/README.md#certificates
> ) to add a new CA to the browser?
>

> No, that was not my intent. Rather, I am hoping for a better recognition
of the commitments (per the Subscriber Agreement and CPS) and risks
involved when an organization chooses to use PTCs, especially for
non-browser use cases.

Thanks,
> Peter

[Peter Bowen]

On Thu, Dec 27, 2018 at 8:34 AM Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Thu, Dec 27, 2018 at 11:12 AM Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > Yes, you are consistently mischaracterizing everything I post.
> >
> > My question was a refinement of the original question to the one case
> > where the alternative in the original question (configuring the browser
> > to trust a non-default PKI) would not be meaningful.
> >
>
> I hope you can understand my confusion, as again, you've provided a
> statement, but not an actual question.
>
> Peter provided two, fairly simple to understand, very direct questions:
>

>From earlier messages, I realized that the answer to my initial question is
obviously "no", because there is at least one more supported Mozilla
product that uses the same trust store: Thunderbird. The second part is
also faulty, because it doesn't account for certificates for public IP
addresses. Fixing this is makes the question more complex:

Is it the expectation of Mozilla that "publicly trusted certificates" for
server authentication should only be used by customers for servers that are:
a) meant be accessed by Mozilla Firefox and/or Mozilla Thunderbird
- This effectively means the server is serving at least one of HTTP, FTP,
WS (WebSocket), NNTP, IMAP, POP3, SMTP, IRC, or XMPP over TLS (including
iCalendar, CalDAV, WCAP, RSS, and Twitter API over one of the supported
protocols)
b) are publicly accessible on the Internet
- This mean either server is accessed via an IP address is a public IP or
via a hostname is publicly resolvable to a public IP
- Thunderbird does do SRV record lookups, but SRV records are just
pointers to a hostname, so this does not change the above
c) committed to complying with a 24-hour (wall time) response time

certificate replacement upon demand by Mozilla?

This is a longer question, but more accurately reflects how Mozilla uses
publicly trusted certificates.

Is the expectation that "publicly trusted certificates" should only be used
> > by customers who for servers that are:
> > - meant to be accessed with a Mozilla web browser, and
> > - publicly accessible on the Internet (meaning the DNS name is publicly
> > resolvable to a public IP), and
> > - committed to complying with a 24-hour (wall time) response time
> > certificate replacement upon demand by Mozilla?
>

Thanks,
Peter

[Peter Bowen]

On Thu, Dec 27, 2018 at 12:12 PM Wayne Thayer <wth...@mozilla.com> wrote:

> On Wed, Dec 26, 2018 at 2:42 PM Peter Bowen via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> In the discussion of how to handle certain certificates that no longer
>> meet
>> CA/Browser Forum baseline requirements, Wayne asked for the "Reason that
>> publicly-trusted certificates are in use" by the customers. This seems to
>> imply that Mozilla has an opinion that the default should not be to use
>> "publicly-trusted certificates". I've not seen this previously raised, so
>> I want to better understand the expectations here and what customers
>> should
>> consider for their future plans.
>>
>
> The context for the question is that at least one of the organizations
> having difficulty with the underscore sunset stated that they couldn't just
> replace the certificates - they need to ship updates to the client. If you
> are hard-coding certificate information into client software, it's fair to
> ask why you're using publicly-trusted certificates (PTCs).
>

I was not aware of this being an issue in this case. Thanks for this
explanation.

I believe a similar concern was discussed at length during the SHA-1 sunset
> in relation to payment terminals. As has been suggested, maybe it's simply
> a matter of cost. I suspect, however, that it is more about a lack of
> recognition of the responsibilities that come along with using PTCs. In the
> spirit of incident reporting, I think it would help to have a better
> understanding of the decisions that are driving the use of PTCs in these
> use cases
>

I agree that many people developing products do not understand the fully
scope of the responsibilities that come with using Mozilla PTCs. From what
I've personally observed, the requirements are frequently: "I want to have
a third party manage the CA at no cost to me", "I want that third party to
make it relatively easy and fairly inexpensive for arbitrary people and
organizations to get certificates that are signed by/chain to the CA", "I
want some level of assurance that the third party is doing the right things
without having to figure out what the right things are", and (usually only
realized much later) "I want to be able to make a decision on whether the
risk of not revoking a given a certificate outweigh the benefit of leaving
it unrevoked and have the third party not suffer any negative consequences
from my decision".

I have seen these requirements from organizations large and small. They
are not usually written out in these terms, rather there are other
requirements that boil down to these.

> Is the expectation that "publicly trusted certificates" should only be used
>> by customers who for servers that are:
>> - meant to be accessed with a Mozilla web browser, and
>>
>

> No.

>
> - publicly accessible on the Internet (meaning the DNS name is publicly
>> resolvable to a public IP), and
>>
>

> No.

>
> - committed to complying with a 24-hour (wall time) response time
>> certificate replacement upon demand by Mozilla?
>>

>> Committed to comply with section 4.9.1.1 (Reasons for Revoking a
> Subscriber Certificate) of the BRs - yes.
>

In recent revisions to the BRs, it seems that this is extended to 5 days
for many cases, including this underscore case. However I think that many
customers ("subscribers" in BR terminology) would be very surprised at this
requirement, even though it is long standing.

> Is the recommendation from Mozilla that customers who want to allow Mozilla
>> browsers to access sites but do not want to meet one or both of the other
>> two use the Firefox policies for Certificates (
>>
>> https://github.com/mozilla/policy-templates/blob/master/README.md#certificates
>> ) to add a new CA to the browser?
>>
>> No, that was not my intent. Rather, I am hoping for a better recognition
> of the commitments (per the Subscriber Agreement and CPS) and risks
> involved when an organization chooses to use PTCs, especially for

> non-browser use cases.]
>

I think this is a good callout. Mozilla PTCs are a fairly unique situation
because there is very little ability to negotiate terms. Most large
organizations are accustomed to having a set of requirements as a starting
point but working person to person (or organization to organization) to
modify the terms to meet their needs. It is clear that this is not an
option for Mozilla PTCs and this lack of option is very surprising to the
organizations. I'm not sure what can be done about existing deployments of
roots in places other than Mozilla software, but it is clear that CAs
should be working on options for future non-Mozilla software cases if their
customers need more policy flexibility and do not need compatibility with
Mozilla software.

Thanks,
Peter

[Jakob Bohm]

On 27/12/2018 18:03, Nick Lamb wrote:
> On Thu, 27 Dec 2018 15:30:01 +0100
> Jakob Bohm via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> The problem here is that the prohibition lies in a complex legal
>> reading of multiple documents, similar to a situation where a court
>> rules that a set of laws has an (unexpected to many) legal
>> consequence.
>
> I completely disagree. This prohibition was an obvious fact, well known
> to (I had assumed prior to this present fever) everyone who cared about
> the Internet's underlying infrastructure.
>

The group who most definitely were unaware of the very specific reading
of RFC5280 is the subscribers using such host names in ways that passed
all other requirements (including domain name validation).
Not the people seeking to allow these names via ballot 202, similar to
what was done for other RFC5280 deviations in ballots 75, 88 and 144.

> The only species of technical people I ever ran into previously who
> professed "ignorance" of the rule were the sort who see documents like
> RFCs as descriptive rather than prescriptive and so their position
> would be (as it seems yours is) "Whatever I can do is allowed". Hardly
> a useful rule for the Web PKI.
>

You must be traveling in a rather limited bubble of PKIX experts, all of
whom live and breathe the reading of RFC5280. Technical people outside
that bubble may have easily misread the relevant paragraph in RFC5280 in
various ways.

Possible ways to overlook the ban on underscores:

1. Not chasing down the RFC1034/RFC1123 references but relying on
previously learned rules for what can be in a DNS name.

2. Interpreting the wording in RFC5280 section 4.2.1.6 as simply requiring
a canonical encoding of DNS names, thus not allowing e.g. the UTF-8
equivalent of an IDN or duplicate periods, then deferring that encoding
job to a 3rd party PKI library.

3. Relying on practice established in certificates without the SAN extension,
(thus not subject to section 4.2.1.6 rules) and then continuing without
detailed review after it became mandatory to always include the SAN
extension for end entities.

4. Trusting the word of others on how to interpret the rules, those others
being the ones misreading the standards.

> Descriptive documents certainly have their place - I greatly admire
> Geoff Pullum's Cambridge Grammar of the English Language, and I
> do own the more compact "Student's Introduction" book, both of which
> are descriptive since of course a natural language is not defined by
> such documents and can only be described by them (and imperfectly,
> exactly what's going on in English remains an active area of research).
> But that place is not here, the exact workings of DNS are prescribed, in
> documents you've called a "complex legal reading of multiple documents"
> but more familiarly as "a bunch of pretty readable RFCs on exactly this
> topic".
>

The documents that prescribes the exact workings of DNS do not prohibit
(only discourage) DNS names containing underscores. Web browser
interfaces for URL parsing may not allow them, which would be a technical
benefit for at least one usage of such certificates reported in the recent
discussion.

The complex reading comes in the understanding that a single sentence in
RFC5280 elevates the recommendation in the DNS standards to an absolute
requirement in PKIX, combined with the opinion that this particular
effect of the wording is not another errata that should be corrected in
any later update of the PKIX standard, and/or overridden by a BR clause.

>> It would benefit the honesty of this discussion if the side that won
>> in the CAB/F stops pretending that everybody else "should have known"
>> that their victory was the only legally possible outcome and should
>> never have acted otherwise.
>
> I would suggest it would more benefit the honesty of the discussion if
> those who somehow convinced themselves of falsehood would accept this
> was a serious flaw and resolve to do better in future, rather than
> suppose that it was unavoidable and so we have to expect they'll keep
> doing it.
>
> Consider it from my position. In one case I know Jakob made an error
> but has learned a valuable lesson from it and won't be caught the same
> way twice. In the other case Jakob is unreliable on simple matters of
> fact and I shouldn't believe anything further he says.
>

That I disagree with you on certain questions of fact doesn't mean I'm
unreliable, merely that you have not presented any persuasive arguments
that you are not the one being wrong.

I have accepted that a strict, legalistic reading of RFC5280 leads to
the ban on underscores in subject alternative names. I merely dispute
that this was obvious to every reader of those documents, even if they
understood them to be binding technical standards. Hence why I consider
the passing of ballot SC12 as similar to a supreme court ruling that a
combination of laws constitutes an actually enforceable ban on some
established practice (which someone obviously argued for).

>
>> Maybe because it is not publicly prohibited in general (the DNS
>> standard only recommends against it, and other public standards
>> require some such names for uses such as publishing certain public
>> keys). The prohibition exists only in the certificate standard
>> (PKIX) and maybe in the registration policies of TLDs (for TLD+1
>> names only).
>
> Nope. You are, as it seems others in your position have done before,
> confusing restrictions on all names in DNS with restrictions on names
> for _hosts_ in DNS. Lots of things can have underscores in their names,
> and will continue to have underscores in their names, but hosts cannot.
> Web PKI certs are issued for host names (and IP addresses, and as a
> special case, TOR hidden services).
>

Can you point out where in the DNS standards the ban of underscores is a
RFC2119 MUST rather than a SHOULD ? (The lowercase "must" near the end of
RFC1034 section 3.5 is a specification of how to implement the should in
the second paragraph of that section, and the "prudent user" practice
described in the first paragraph of that section. Almost identical wording
is found in RFC1035).

> Imagine if, on the same basis, a CA were to insist that they'd
> understood Texas to be a US state, and so they'd written C=TX on the
> rationale that a "state" is essentially the same kind of thing as a
> "country".
>
> I do not doubt they could find a few (mostly Texan) people to defend
> this view, but it's obviously wrong, and when the City of Austin
> Independent League of Skateboarders protests that they need to keep
> getting certificates with C=TX for compatibility reasons we'd have a
> good laugh and tell the CA to stop being so stupid, revoke these certs
> and move on.
>

A better example is the pre-2015 issuing of .onion names, which do not
exist in the IANA-rooted DNS.

>> Also it isn't the "Web PKI". It is the "Public TLS PKI", which is
>> not confined to Web Browsers surfing online shops and social
>> networks, and hasn't been since at least the day TLS was made an IETF
>> standard.
>
> It is _named_ the Web PKI. As you point out, it is lots of things, and
> so "Web PKI" is not a good description but its name remains the Web
> PKI anyway.
>
> The name for people from my country is "Britons". Again it's not a good
> description, since some of them aren't from the island of Great Britain
> as the country extends to adjacent islands too. Nevertheless the name is
> "Britons".
>

I wrote this in opposition to someone seemingly insisting that the
_name_ implied that all non-web uses are mistakes that should not be
given any credence.

[Jeremy Rowley]

It clearly wasn't understood by everyone. That's why we had two ballots on it, one of them failing to address the issue. You can just look through the long discussions on the topic to see people didn't agree.

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Jakob Bohm via dev-security-policy
Sent: Thursday, December 27, 2018 2:43 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Use cases of publicly-trusted certificates

On 27/12/2018 18:03, Nick Lamb wrote:

> On Thu, 27 Dec 2018 15:30:01 +0100
> Jakob Bohm via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> The problem here is that the prohibition lies in a complex legal
>> reading of multiple documents, similar to a situation where a court
>> rules that a set of laws has an (unexpected to many) legal
>> consequence.
>
> I completely disagree. This prohibition was an obvious fact, well
> known to (I had assumed prior to this present fever) everyone who
> cared about the Internet's underlying infrastructure.
>

The group who most definitely were unaware of the very specific reading of RFC5280 is the subscribers using such host names in ways that passed all other requirements (including domain name validation).
Not the people seeking to allow these names via ballot 202, similar to what was done for other RFC5280 deviations in ballots 75, 88 and 144.

> The only species of technical people I ever ran into previously who
> professed "ignorance" of the rule were the sort who see documents like
> RFCs as descriptive rather than prescriptive and so their position
> would be (as it seems yours is) "Whatever I can do is allowed". Hardly
> a useful rule for the Web PKI.
>

You must be traveling in a rather limited bubble of PKIX experts, all of whom live and breathe the reading of RFC5280. Technical people outside that bubble may have easily misread the relevant paragraph in RFC5280 in various ways.

Possible ways to overlook the ban on underscores:

1. Not chasing down the RFC1034/RFC1123 references but relying on
previously learned rules for what can be in a DNS name.

2. Interpreting the wording in RFC5280 section 4.2.1.6 as simply requiring
a canonical encoding of DNS names, thus not allowing e.g. the UTF-8
equivalent of an IDN or duplicate periods, then deferring that encoding
job to a 3rd party PKI library.

3. Relying on practice established in certificates without the SAN extension,
(thus not subject to section 4.2.1.6 rules) and then continuing without
detailed review after it became mandatory to always include the SAN
extension for end entities.

4. Trusting the word of others on how to interpret the rules, those others
being the ones misreading the standards.

> Descriptive documents certainly have their place - I greatly admire
> Geoff Pullum's Cambridge Grammar of the English Language, and I do own
> the more compact "Student's Introduction" book, both of which are
> descriptive since of course a natural language is not defined by such
> documents and can only be described by them (and imperfectly, exactly
> what's going on in English remains an active area of research).
> But that place is not here, the exact workings of DNS are prescribed,
> in documents you've called a "complex legal reading of multiple documents"
> but more familiarly as "a bunch of pretty readable RFCs on exactly
> this topic".
>

The documents that prescribes the exact workings of DNS do not prohibit (only discourage) DNS names containing underscores. Web browser interfaces for URL parsing may not allow them, which would be a technical benefit for at least one usage of such certificates reported in the recent discussion.

The complex reading comes in the understanding that a single sentence in
RFC5280 elevates the recommendation in the DNS standards to an absolute requirement in PKIX, combined with the opinion that this particular effect of the wording is not another errata that should be corrected in any later update of the PKIX standard, and/or overridden by a BR clause.

>> It would benefit the honesty of this discussion if the side that won
>> in the CAB/F stops pretending that everybody else "should have known"
>> that their victory was the only legally possible outcome and should
>> never have acted otherwise.
>
> I would suggest it would more benefit the honesty of the discussion if
> those who somehow convinced themselves of falsehood would accept this
> was a serious flaw and resolve to do better in future, rather than
> suppose that it was unavoidable and so we have to expect they'll keep
> doing it.
>
> Consider it from my position. In one case I know Jakob made an error
> but has learned a valuable lesson from it and won't be caught the same
> way twice. In the other case Jakob is unreliable on simple matters of
> fact and I shouldn't believe anything further he says.
>

That I disagree with you on certain questions of fact doesn't mean I'm unreliable, merely that you have not presented any persuasive arguments that you are not the one being wrong.

I have accepted that a strict, legalistic reading of RFC5280 leads to the ban on underscores in subject alternative names. I merely dispute that this was obvious to every reader of those documents, even if they understood them to be binding technical standards. Hence why I consider the passing of ballot SC12 as similar to a supreme court ruling that a combination of laws constitutes an actually enforceable ban on some established practice (which someone obviously argued for).

>

>> Maybe because it is not publicly prohibited in general (the DNS
>> standard only recommends against it, and other public standards
>> require some such names for uses such as publishing certain public
>> keys). The prohibition exists only in the certificate standard
>> (PKIX) and maybe in the registration policies of TLDs (for TLD+1
>> names only).
>
> Nope. You are, as it seems others in your position have done before,
> confusing restrictions on all names in DNS with restrictions on names
> for _hosts_ in DNS. Lots of things can have underscores in their
> names, and will continue to have underscores in their names, but hosts cannot.
> Web PKI certs are issued for host names (and IP addresses, and as a
> special case, TOR hidden services).
>

Can you point out where in the DNS standards the ban of underscores is a
RFC2119 MUST rather than a SHOULD ? (The lowercase "must" near the end of
RFC1034 section 3.5 is a specification of how to implement the should in the second paragraph of that section, and the "prudent user" practice described in the first paragraph of that section. Almost identical wording is found in RFC1035).

> Imagine if, on the same basis, a CA were to insist that they'd
> understood Texas to be a US state, and so they'd written C=TX on the
> rationale that a "state" is essentially the same kind of thing as a
> "country".
>
> I do not doubt they could find a few (mostly Texan) people to defend
> this view, but it's obviously wrong, and when the City of Austin
> Independent League of Skateboarders protests that they need to keep
> getting certificates with C=TX for compatibility reasons we'd have a
> good laugh and tell the CA to stop being so stupid, revoke these certs
> and move on.
>

A better example is the pre-2015 issuing of .onion names, which do not exist in the IANA-rooted DNS.

>> Also it isn't the "Web PKI". It is the "Public TLS PKI", which is
>> not confined to Web Browsers surfing online shops and social
>> networks, and hasn't been since at least the day TLS was made an IETF
>> standard.
>
> It is _named_ the Web PKI. As you point out, it is lots of things, and
> so "Web PKI" is not a good description but its name remains the Web
> PKI anyway.
>
> The name for people from my country is "Britons". Again it's not a
> good description, since some of them aren't from the island of Great
> Britain as the country extends to adjacent islands too. Nevertheless
> the name is "Britons".
>

I wrote this in opposition to someone seemingly insisting that the _name_ implied that all non-web uses are mistakes that should not be given any credence.


Enjoy

Jakob
--

Jakob Bohm, CIO, Partner, WiseMo A/S. https://clicktime.symantec.com/a/1/NvI8nVBXrGua0H_mUC6FhSYOxxn3GAjg_XLXNmbVXB0=?d=Tug3wiBvLVI0CccxMfKgxh2qZnxuKqdrvmlxx7SfUafIyVLpggZyNa2YvnkFmStxYAmKMw2hduxHGjtx1kmvLrUAqfl4P8H-PdRJyBEHq88o27yIftfQdga8WEvb0AzXVoR1TwL812ipWXhtlTDqYu9FGxJmXLGwh4n4_EUO3IX3DYxA9tFShluVJFmd3_JEBurArdJ6A6WRgZ9t33tJYH-hOGrPPBSs3sBuo49yuodFXuHVdU1xK2ylu2iRmK3CbCAoKeISzkVn2dII57K1LTEUJVUPhkaYNb_hkGl6yLzPobl_W990qI5dnuW9DA8ZBMK9u2HIG8T9VGabWIfcZDCZpWyByMcbCTUXtZ67YUEvmiiQYGbsAj18VwcD1mDr2EYARZepqcILKoryOAaj6_zPn6s1uQBQGWWkv1hB&u=https%3A%2F%2Fwww.wisemo.com

Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors.

WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://clicktime.symantec.com/a/1/xge3klSg_iQMiHmsh9hZ8yCqd8oxS2EFRR1Sz99TuTw=?d=Tug3wiBvLVI0CccxMfKgxh2qZnxuKqdrvmlxx7SfUafIyVLpggZyNa2YvnkFmStxYAmKMw2hduxHGjtx1kmvLrUAqfl4P8H-PdRJyBEHq88o27yIftfQdga8WEvb0AzXVoR1TwL812ipWXhtlTDqYu9FGxJmXLGwh4n4_EUO3IX3DYxA9tFShluVJFmd3_JEBurArdJ6A6WRgZ9t33tJYH-hOGrPPBSs3sBuo49yuodFXuHVdU1xK2ylu2iRmK3CbCAoKeISzkVn2dII57K1LTEUJVUPhkaYNb_hkGl6yLzPobl_W990qI5dnuW9DA8ZBMK9u2HIG8T9VGabWIfcZDCZpWyByMcbCTUXtZ67YUEvmiiQYGbsAj18VwcD1mDr2EYARZepqcILKoryOAaj6_zPn6s1uQBQGWWkv1hB&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Peter Bowen]

On Thu, Dec 27, 2018 at 9:04 AM Nick Lamb via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Thu, 27 Dec 2018 15:30:01 +0100
> Jakob Bohm via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
> > The problem here is that the prohibition lies in a complex legal
> > reading of multiple documents, similar to a situation where a court
> > rules that a set of laws has an (unexpected to many) legal
> > consequence.
>
> I completely disagree. This prohibition was an obvious fact, well known
> to (I had assumed prior to this present fever) everyone who cared about
> the Internet's underlying infrastructure.
>

> The only species of technical people I ever ran into previously who
> professed "ignorance" of the rule were the sort who see documents like
> RFCs as descriptive rather than prescriptive and so their position
> would be (as it seems yours is) "Whatever I can do is allowed". Hardly
> a useful rule for the Web PKI.
>

As I wrote in the thread on underscores, I am one of the people who
believed it was not clear if underscores were allowed or not. This was
reflected in the earliest versions of certlint/cablint.

If you think it should have been clear, consider the following examples
from the real world:
- The character Asterisk (U+002A, '*') is not allowed in dNSName SANs per
the same rule forbidding Low Line (U+005F, '_'). RFC 5280 does say:
"Finally, the semantics of subject alternative names that include wildcard
characters (e.g., as a placeholder for a set of names) are not addressed by
this specification. Applications with specific requirements MAY use such
names, but they must define the semantics." However it never defines what
"wildcard characters" are acceptable. As Wikipedia helpfully documents,
there are many different characters that can be wildcards:
https://en.wikipedia.org/wiki/Wildcard_character. The very same ballot
that attempted to clarify the status of the Low Line character tried to
clarify wildcards, but it failed. The current BRs state "Wildcard FQDNs
are permitted." in the section about subjectAltName, but the term "Wildcard
FQDN" is never defined. Given the poor drafting, I might be able to argue
that Low Line should be considered a wildcard character that is designed to
match a single character, similar to Full Stop (U+002E, '.') in regular
expressions.

- The meaning of the extendedKeyUsage extension in a CA certificate is
unclear. There are at least two views: 1) It constrains the use of the
public key in the certificate and 2) It constrains the use of end-entity
public keys certified by the CA named in the CA certificate. This has been
discussed multiple times on the IETF PKIX mailing list and no consensus has
been reached. Similarly, the X.509 standard does not clarify. Mozilla
takes the second option, but it is entirely possible that a clarification
could show up in a future RFC or X.500-series doc that goes with the first
option.

These are just two cases where the widely deployed and widely accepted
status does not match the RFC.

> > It would benefit the honesty of this discussion if the side that won
> > in the CAB/F stops pretending that everybody else "should have known"
> > that their victory was the only legally possible outcome and should
> > never have acted otherwise.
>
> I would suggest it would more benefit the honesty of the discussion if
> those who somehow convinced themselves of falsehood would accept this
> was a serious flaw and resolve to do better in future, rather than
> suppose that it was unavoidable and so we have to expect they'll keep
> doing it.
>

Of course people are going to try to do better, but part of that is
understanding that people are not perfect and that even automation can
break. I wrote certlint/cablint with hundreds of tests and continue to get
reports of gaps in the tests. Yes, things will get better, but we need to
get them there in an orderly way.

Thanks,
Peter

[Nick Lamb]

On Thu, 27 Dec 2018 22:43:19 +0100

Jakob Bohm via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> You must be traveling in a rather limited bubble of PKIX experts, all
> of whom live and breathe the reading of RFC5280. Technical people
> outside that bubble may have easily misread the relevant paragraph in
> RFC5280 in various ways.

It's practically a pub quiz question. I appreciate that I might be
unusual in happening to care about this as a lay person, but for a
public CA in the Web PKI correctly understanding this stuff was _their
job_. It isn't OK for them to be bad at their jobs.

> The documents that prescribes the exact workings of DNS do not
> prohibit (only discourage) DNS names containing underscores. Web
> browser interfaces for URL parsing may not allow them, which would be
> a technical benefit for at least one usage of such certificates
> reported in the recent discussion.

We get it, you don't accept that not all DNS names can be names of
hosts. That you still seem determined not to understand this even
when it's explained repeatedly shows that my characterization of this
position was correct.

> That I disagree with you on certain questions of fact doesn't mean
> I'm unreliable, merely that you have not presented any persuasive
> arguments that you are not the one being wrong.

I can't distinguish people who are "actually" unreliable from people
who claim the plain facts are "unpersuasive" to their point of view, and
so I don't. Likewise m.d.s.policy largely doesn't care whether a CA's
problems are a result of incompetence or malfeasance, same outcome
either way: distrust.

> I merely
> dispute that this was obvious to every reader of those documents

Since you like legal analogies, the usual standard in law is that
something was known _or should have been known_. This means that a
declaration that you didn't know something holds no weight if a court
concludes that you _should_ have known it. If you have a responsibility
to know, "I didn't know" is not usually an excuse.

I don't believe subscribers should have known, but I do believe
Certificate Authorities should have known, or, as corporate entities,
should have employed someone who knew that this was an important thing
to understand, did their research and came back with a "No" that had
the effect of setting issuance policy.

Doubtless some ordinary subscribers believe Africa is a country. I
don't have a problem with that. But I hope we agree that a CA should
not sign a certificate which gives C=AP (an ISO code reserved for other
reasons associated with Africa) on the rationale that they thought
Africa is a country.

> A better example is the pre-2015 issuing of .onion names, which do
> not exist in the IANA-rooted DNS.

A better example in the sense that, if this happened today we would
expect CAs not to issue for such a name without first getting a change
to the BRs saying this hierarchy is special ?

If the situation was that CAs had sensibly not issued for underscores,
then asked if they could and been turned down this entire thread would
not exist.

> I wrote this in opposition to someone seemingly insisting that the
> _name_ implied that all non-web uses are mistakes that should not be
> given any credence.

You wrote it in reply to me, and you quoted me. I don't know whether my
reciting these facts will be "persuasive" to you, but once again
refusing to believe something won't stop it being true - it only affects
your credibility.

Nick.

[Nick Lamb]

On Thu, 27 Dec 2018 16:56:39 -0800

Peter Bowen via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> - The character Asterisk (U+002A, '*') is not allowed in dNSName SANs
> per the same rule forbidding Low Line (U+005F, '_'). RFC 5280 does
> say: "Finally, the semantics of subject alternative names that
> include wildcard characters (e.g., as a placeholder for a set of
> names) are not addressed by this specification. Applications with
> specific requirements MAY use such names, but they must define the
> semantics." However it never defines what "wildcard characters" are
> acceptable. As Wikipedia helpfully documents, there are many
> different characters that can be wildcards:
> https://en.wikipedia.org/wiki/Wildcard_character. The very same
> ballot that attempted to clarify the status of the Low Line character
> tried to clarify wildcards, but it failed. The current BRs state
> "Wildcard FQDNs are permitted." in the section about subjectAltName,
> but the term "Wildcard FQDN" is never defined. Given the poor
> drafting, I might be able to argue that Low Line should be considered
> a wildcard character that is designed to match a single character,
> similar to Full Stop (U+002E, '.') in regular expressions.

Are you, in fact, now arguing this? If you, in fact, ever believed
this, do you not think it has very significant implications that should
have been raised previously?

e.g. If these are wildcards, putting one in an EV cert would be a
serious problem. Did you go back and check there were problem reports
for any cases where EV certs have these imaginary underscore wildcards?


Let's be real: There was never any such idea, the underscores are not
"wildcards" they're present because some CAs took a lackadaisical
approach to name validation that suited their customers better.

> - The meaning of the extendedKeyUsage extension in a CA certificate is
> unclear. There are at least two views: 1) It constrains the use of
> the public key in the certificate and 2) It constrains the use of
> end-entity public keys certified by the CA named in the CA
> certificate. This has been discussed multiple times on the IETF PKIX
> mailing list and no consensus has been reached. Similarly, the X.509
> standard does not clarify. Mozilla takes the second option, but it
> is entirely possible that a clarification could show up in a future
> RFC or X.500-series doc that goes with the first option.

In the absence of a consensus from the relevant IETF Working Groups I
don't see why you'd expect a future RFC. Certainly there shouldn't be
any mechanism to get a Standards Track RFC without consensus.

We can't do anything about ISO, if they go completely off the rails I
guess we'd have to decide what to do about that when it happens, it
doesn't feel tempting to try to get ahead of that particular calamity.

> Of course people are going to try to do better, but part of that is
> understanding that people are not perfect and that even automation can
> break. I wrote certlint/cablint with hundreds of tests and continue
> to get reports of gaps in the tests. Yes, things will get better,
> but we need to get them there in an orderly way.

This feels pretty orderly to me?

We're a pretty long way from, say, the end of Vernor Vinge's
novel "Rainbows End", where government spooks issue blanket revocations
for all certificates under a major root CA. (It's fun to imagine how
disappointingly little effect this would have in our real world)


Nick.

[Jakob Bohm]

On 30/12/2018 14:18, Nick Lamb wrote:
> On Thu, 27 Dec 2018 22:43:19 +0100

> Jakob Bohm via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>

>> You must be traveling in a rather limited bubble of PKIX experts, all
>> of whom live and breathe the reading of RFC5280. Technical people
>> outside that bubble may have easily misread the relevant paragraph in
>> RFC5280 in various ways.
>
> It's practically a pub quiz question. I appreciate that I might be
> unusual in happening to care about this as a lay person, but for a
> public CA in the Web PKI correctly understanding this stuff was _their
> job_. It isn't OK for them to be bad at their jobs.

Pub quiz questions are particularly tailored to refer to arcane and
unexpected facts, which some punters have memorized.

>
>> The documents that prescribes the exact workings of DNS do not
>> prohibit (only discourage) DNS names containing underscores. Web
>> browser interfaces for URL parsing may not allow them, which would be
>> a technical benefit for at least one usage of such certificates
>> reported in the recent discussion.
>
> We get it, you don't accept that not all DNS names can be names of
> hosts. That you still seem determined not to understand this even
> when it's explained repeatedly shows that my characterization of this
> position was correct.

I accept that not all DNS names can be names of hosts. I do not accept
(without further proof) that certificate issuance is banned for DNS
labels that do not refer to hosts at all. In this case because some
(unknown) higher level protocol requires the TLS server name to be a
label of a special form, specifically designed not to be a host name.

And I certainly do not expect subscribers to be aware of such arcane
details, subscribers know that certain proof of domain control is
required, and if they provide that proof and get a certificate
accordingly, they expect that to be perfectly valid and reliable
until otherwise informed by the issuing CA.

>
>> That I disagree with you on certain questions of fact doesn't mean
>> I'm unreliable, merely that you have not presented any persuasive
>> arguments that you are not the one being wrong.
>
> I can't distinguish people who are "actually" unreliable from people
> who claim the plain facts are "unpersuasive" to their point of view, and
> so I don't. Likewise m.d.s.policy largely doesn't care whether a CA's
> problems are a result of incompetence or malfeasance, same outcome
> either way: distrust.
>

You keep ignoring that I am arguing the perspective of the subscribers,
not the CAs.

>> I merely
>> dispute that this was obvious to every reader of those documents
>
> Since you like legal analogies, the usual standard in law is that
> something was known _or should have been known_. This means that a
> declaration that you didn't know something holds no weight if a court
> concludes that you _should_ have known it. If you have a responsibility
> to know, "I didn't know" is not usually an excuse.
>
> I don't believe subscribers should have known, but I do believe
> Certificate Authorities should have known, or, as corporate entities,
> should have employed someone who knew that this was an important thing
> to understand, did their research and came back with a "No" that had
> the effect of setting issuance policy.
>

Which is precisely my point. There are lots of people outside the tiny
public CA technical and policy community who are technical experts but
unaware of that highly obscure reading of RFC5280.

> Doubtless some ordinary subscribers believe Africa is a country. I
> don't have a problem with that. But I hope we agree that a CA should
> not sign a certificate which gives C=AP (an ISO code reserved for other
> reasons associated with Africa) on the rationale that they thought
> Africa is a country.
>

Our disagreement would be if multiple such CAs had issued a bunch of
C=AP certificates to relevant organizations for use in some scheme that
has been technically locked to this aspect. In such a case it would be
reasonable to allow those organizations to remove that technical lock,
then get new certificates in an orderly fashion.

>> A better example is the pre-2015 issuing of .onion names, which do
>> not exist in the IANA-rooted DNS.
>
> A better example in the sense that, if this happened today we would
> expect CAs not to issue for such a name without first getting a change
> to the BRs saying this hierarchy is special ?
>
> If the situation was that CAs had sensibly not issued for underscores,
> then asked if they could and been turned down this entire thread would
> not exist.
>

I strongly suspect (but have no data) that underscore certificates may
date back a long time as a practice, perhaps even before the CAB/F was
established.

>> I wrote this in opposition to someone seemingly insisting that the
>> _name_ implied that all non-web uses are mistakes that should not be
>> given any credence.
>
> You wrote it in reply to me, and you quoted me. I don't know whether my
> reciting these facts will be "persuasive" to you, but once again
> refusing to believe something won't stop it being true - it only affects
> your credibility.
>

Sorry, I lost track of the threading, I thought it was to one of the
others.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com