[openssl-dev] OpenSSL and certain PEM formats

[Sean Leonard]

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??). There is also 
ambiguity/non-standardization around how EKU trust settings are 
propagated/enforced.

If you wanted to record this information, I believe that PKCS #12 is the 
right format for the job. PKCS #12 is convoluted and a lot of people 
hate it for good reasons, but PKCS #12 allows you to transmit arbitrary 
attributes alongside certificates, private keys, and other crypto 
objects. Thus if you want to annotate a certificate with a friendly name 
(alias) or a special key identifier, there are interoperable ways to do 
that. The complicated part then becomes what trust settings are 
interoperable, not the particular packaging format involved.

draft-josefsson-pkix-textual prohibits header annotations inside the 
textual format, because they are not interoperable. (This is a departure 
from PEM [RFC1421], which is based on e-mail messages, which allows for 
headers prior to the base64-encoded body.) Other non-pkix-textual 
formats, such as the OpenSSH Public Key File Format [RFC4716], make 
extensive use of headers.

On that point, that was another reason why I did not include RSA PRIVATE 
KEY. For the command:
openssl genrsa -aes256 2048

You get:
Generating RSA private key, 2048 bit long modulus
...........+++
..................................................+++
e is 65537 (0x10001)
Enter pass phrase:
Verifying - Enter pass phrase:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,5CD4A83156BC97F69CD537D5A2AC1B53

k1QsZFahAmPsiiZUNy4q4njus3QYEtwBmCuGb1Q1d6mpqtLiokv+hdDwk9i/POtV
...
-----END RSA PRIVATE KEY-----

...this is (basically) RFC 1421 PEM format, which is not the same as 
pkix-textual.


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.

I put "certificate" in quotes above because the implementation should 
not expose the root product "certificate" or the subordinate 
"certificates" on the wire (as might be done with TLS or CMS/S/MIME). 
They are not supposed to be real "certificates" but rather just a way to 
reuse most of the validation code.

Sean