Why is there a certificate name constraint for .mil


#1

Hi,

I am giving a presentation about Let’s Encrypt soon and to be prepared for questions I was wondering why there is a name constraint for .mil domains.

Kind regards
Till


#2

that’s only for the coss signature of IdenTrust. they wanted it that way.


#3

.mil have their own PKI. They should probably use that instead of LE given the nature of the trust they’re after.


#4

This is probably imposed by US Military and/or Government to explicit avoid LE capability to issue valid certificates on that TLD.


#5

no certainly not. because it’s only on the Intermediate cert by IdenTrust. the LE intermediate doesnt have that.


#6

Hi everybody, as @jsha said in another thread

this was a requirement from IdenTrust. It is not a legal requirement for CAs in the United States.


#7

Well, why right now the .mil signing ability has been removed? Was there pressure on you from the US Government? And you cannot say that it now is a legal requirement, since it wasn’t at the time you wrote that post…


#8

It’s something that IdenTrust required. This could be for any number of reasons - just a precaution, existing contracts with the DoD which won’t allow that, or maybe they want to keep their existing business with the DoD (with Let’s Encrypt’s cross-signed issuer certificate, they could theoretically switch to a CA other than IdenTrust that leads up to the DST root certificate, which they might not like).

IdenTrust obviously has the right to dictate the terms under which they allow their subCAs to operate. Whether or not Let’s Encrypt decides to issue .mil certificates under their own root certificate in the future is another question, but probably not exactly a huge concern given that .mil is only used by one organization.


#9

Sure IdenTrust can enforce that, but only on THEIR root and THEIR signed LE intermediates. Now if you look at the updated CPS (16 March, v1.3, here: https://letsencrypt.org/documents/ISRG-CPS-March-16-2016.pdf) actually ISRG is disallowing the use of .mil. If that won’t seem suspicious to me, IDK…


#10

It also states that:

The ‘.mil’ TLD and its subdomains will always be considered high risk and under no circumstances will
the CA issue certificates for them.

Given that .mil is used exclusively by the US DoD, and they haven’t shown any interest in using Let’s Encrypt, I don’t see where the problem is?


#13

Furthermore, here the problem shows up again that LE is not being transparent about the high risk domains. Why not be transparent? Wasn’t transparency a basic target of LE among others?


#14

I’m not sure I follow. The CPS explicitly state that .mil is always considered high-risk. What’s not transparent about that?


#15

That’s fully transparent. Maybe I should move my “follow-up” question to another thread, but I really really don’t understand why all high risk domains aren’t revealed. Is there anything secret about that?


#16

This seems off-topic, but I’m not sure what the value of a published list of high-risk domain would be. If you own such a domain, you’re one API call to the authorization endpoint away from finding out. If your organization is interested in using Let’s Encrypt while being on that list, I’m sure you’d have no trouble contacting Let’s Encrypt and amending the list if it’s possible without endangering anyone else.

This is generally a very ambiguous area of the Baseline Requirement - maybe something that the CA/B Forum will get rid of in a decade or ten (:expressionless:) when the industry has solved the ownership verification and phishing problem properly, but in the meantime this seems to implicitly call for a security-by-obscurity approach.