Re: Use cases of publicly-trusted certificates

[Nick Lamb via dev-security-policy]

On Thu, 27 Dec 2018 16:56:39 -0800
Peter Bowen via dev-security-policy
 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Use cases of publicly-trusted certificates

[Nick Lamb via dev-security-policy]

On Thu, 27 Dec 2018 22:43:19 +0100
Jakob Bohm via dev-security-policy
 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When should honest subscribers expect sudden (24 hours / 120 hours) revocations?

[Nick Lamb via dev-security-policy]

On Sat, 29 Dec 2018 16:32:46 -0800
Peter Bowen via dev-security-policy
 wrote:

>  Consider the following cases:
> 
> - A company grows and moves to larger office space down the street.
> It turns out that the new office is in a different city even though
> the move was only two blocks away.  The accounting department sends
> the CA a move notice so the CA sends invoices to the new address.
> Does this mean the CA has to revoke all existing certificates in 5
> days?

If the certificates have this now useless address in them, then sure,
they're now wrong. Leading to two questions that have awkward answers
for CAs and my present employer: What kind of idiot would put
irrelevant stuff in the certificate and pay extra to do so?

I will also note here that it's not uncommon to give a companies "legal"
address (and even other "legal" details) that have little resemblance to
reality since they were chosen for tax efficiency or to protect a
Person with Significant Control from the lawful authority of the
country in which business is actually done.

My previous employer had a whole lot of certificates which gave the
address of a law firm on a small nominally independent island, they're a
large international company and do almost no business on that island,
but they're legally incorporated there and so that's what they decided
to write on the certificates, of course no actual users check or care.

This has a useful effect in "office move" scenarios because the legal
address does not change. But if you didn't write it at all then you
wouldn't need to care either.

> - Widget LLC is a startup with widgetco.example.  They want to take
> investment so they change to a C-corp and become Widget, Inc.  Widget
> Inc now is the registrant for widgetco.example. Does this now trigger
> the 5 day rule?
> - Same example as above, but the company doesn't remember to update
> the domain registration.  It therefore is invalid, as it points to a
> non-existence entity.  Does this trigger the 5 day rule?

It would matter which of the Ten Blessed Methods was used, in some
(most?) of the Methods the legal name of the domain registrant is
irrelevant and may never be known to the CA. Where the CA is confident
of issuance only because of a relationship to the legal registrant, a
change in registrant could indeed need urgent action by somebody.

> - The IETF publishes a new RFC that "Updates: 5280
> ".  It removes a previously valid
> feature in certificates.  Do all certificates using this feature need
> to be revoked within 5 days?
> 
> - The  IETF publishes a new RFC that "Updates: 5280
> ".  It says it update 5280 as
> follows:

The IETF is not a member organisation. All of us can and should
participate. I know all the major browser vendors have employees who
(on or off the clock) are IETF participants, and I hope that at least
some of the CAs likewise have participants. If a CA believes that their
perspective is lacking they are, of course, free to assign one or more
personnel to track relevant work and even to pay to fly people out to
the periodic physical instantiation of the IETF.

If an IETF working group is updating RFC 5280 anybody - and I mean
anybody you don't even need to do so much as subscribe to a mailing
list first - can email that working group and point out a problem like
"Oh, if you make this change it's disruptive to our business, so please
don't do that without a suitable justification".

You are very likely to be able to achieve the IETF's requirement of
"rough consensus" to avoid changes that are needlessly disruptive.

More importantly IETF changes are often flagged months or years in
advance. In reality I would expect you'd see a Mozilla routine
communication asking CAs about their preparedness for any such change
some time in advance. It's not "five days" if you had a year's warning.

> - A customer has a registered domain name that has characters that
> current internationalized domain name RFCs do not allow (for example
> xn--df-oiy.ws/✪ df.ws).  A CA issues because this is a registered
> domain name according to the responsible TLD registry.  Must this be
> revoked within 5 days if the CA notices?

Seems sane to me. Also seems like a foolhardy practice by the
responsible TLD registry and/or its registrars. I would definitely
suggest annoyed subscribers demand compensation from their registrar
for letting them have a bogus name unless it turns out the registrar
was talked into this despite warning what might happen.

> - A customer has a certificate with a single domain name in the SAN
> which is an internationalized domain name.  The commonName attribute
> in the subject contains the IDN.  However the CN attribute uses
> U-labels while the SAN uses A-labels.  Whether this is allowed has
> been the subject of debate at the CA/Browser Forum as neither BRs nor
> RFCs make this clear.  Do any certificates using U-labels in the CN
> need to