[openssl-dev] OpenSSL and certain PEM formats

[Erwann Abalea]

Le 21/12/2014 21:39, Sean Leonard a écrit :
> On 12/21/2014 8:33 AM, Kurt Roeckx wrote:
>> On Sat, Dec 20, 2014 at 02:29:44PM +0000, Dr. Stephen Henson wrote:
>>> On Fri, Dec 19, 2014, Sean Leonard wrote:
>>>
>>>> On Dec 19, 2014, at 11:35 AM, Kurt Roeckx <kurt at roeckx.be> wrote:
>>>>
>>>>> On Fri, Dec 19, 2014 at 03:05:32PM +0000, Viktor Dukhovni wrote:
>>>>>> On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote:
>>>>>>
>>>>>>> Does OpenSSL have documented someplace exactly what it means to 
>>>>>>> have a
>>>>>>> "TRUSTED CERTIFICATE"?
>>>>>> It is a certificate + auxiliary data which specifies a friendly name
>>>>>> plus a set of EKUs.
>>>>> Mozilla provides a list of root certificates and that includes at
>>>>> least the trust settings for that certificate.
>>>> What exactly is the Mozilla (NSS) format? How does it differ from 
>>>> the OpenSSL format?
>>>>
>>> The last time I checked NSS stored the trust data in a database 
>>> (Berkeley DB)
>>> and the trust attributes could be accessed via PKCS#11. I'm not 
>>> aware of any
>>> way to export the certificates to a file which retains the trust 
>>> settings.
>>>
>>> I'm not aware of any standard for trust settings. There certainly 
>>> wasn't
>>> one when this was added to OpenSSL.
>> The source is actually a text file you can see here:
>> https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt 
>>
>>
>> As far as I know they turn the file into a database, not the other
>> way around.
>
> Ok.
>
> Overall I am not convinced that trust settings are the proper subject 
> of interchange between different products. There is a standard 
> validation algorithm (RFC 5280, etc.); however, the algorithm is 
> super-complicated and very few people implement all of its 
> permutations, especially things related to the esoteric name types and 
> name constraints (who implements directory name constraints, for 
> example??). 

OpenSSL implements it, so does Microsoft. I don't know if NSS::libpkix 
implements it, I'm sure NSS:pkix (its recent successor) doesn't. Apple 
doesn't know about NameConstraints. I don't know about GnuTLS, but I 
doubt it does.

> There is also ambiguity/non-standardization around how EKU trust 
> settings are propagated/enforced.

This is a step first taken by Microsoft for public CAs, recently adopted 
by Mozilla. It's completely non standard.
The function offered by this "EKU constraints" logic is normally offered 
by the CertificatePolicies extension, but:
  - it was only used to distinguish EV TLS certs from the rest
  - it's very hard to make it work in practice when considering a lot of 
public CAs and different usages

[...]
> Another way to do it would be for a product to have one 
> product-specific root "certificate", which then has subordinate 
> "certificates" that have all of the RFC 5280-compliant constraints 
> applied to them and that are used as cross-certificates for the actual 
> root CA certificates. Thus if you wanted to restrict Acme Corp's certs 
> to *.acme.com and the Government of the People's Republic of China's 
> certificates to *.cn (DNS) and *@*.cn (e-mail), you would create a 
> master root OpenSSL product "certificate", and issue subordinate CA 
> certs to the "real" roots.

Something like this?

NameConstraints {
   permittedSubTrees {
     { base.dNSName: "cn" },
     { base.emailAddress: "cn" },
     { base.emailAddress: ".cn" }
   }
}

It doesn't restrict IP addresses, it also doesn't address restrictions 
on the type of certificate use (CP/EKU/...).