[cryptography] airgaps in CAs

Adam Back adam at cypherspace.org
Tue Dec 13 06:45:25 EST 2011

Presumably these sub-CA certs have pathLenConstraint = 0?  (Meaning they are
only authorized to issue site certificates, not further sub-CA

Otherwise it could run away from them... one compromise and the attacker
gets a sub-sub-CA, rather than a site certificate.

For these sub-CA certs with no name constraints, is there a some other form
of operationally imposed name constraint - ie does the issuing software
impose a choice of owned domains, so that the day to day cert issuer role is
not able to issue certs for non-owned domains?

(With an admin role required to add further valid domains)?

I have to say it doesnt seem that much of an operational headache (for the
justification of removing name constraints).  The only operational task is
to pay an admin fee to the CA and click on a few links in emails to acquired
company domain registration addresses and import the new cert?


On Mon, Dec 12, 2011 at 06:21:41PM -0800, Arshad Noor wrote:
>On 12/9/2011 12:27 AM, Adam Back wrote:
>>Do the air gapped private PKI root certs (and if applicable their
>>non-airgapped sub-CA certs they authorize) have the critical name
>>extension eg ".foocorp.com" meaning it is only valid for creating certs for
>The early ones did.  However, we stopped putting in the constraint as
>we became aware that it created some operational headaches when
>companies merged or acquired other companies, and needed certificates
>under the domain-name of the merged/acquired company (to preserve
>legacy applications and customers) which were different from the
>domain names in the constraint.
>Secondly, the constraint is perceived as protecting the TTP CA's more
>than the Subject; and since the TTP did not mandate it in their CP,
>there was no reason to include it.  (I have already heard that one TTP
>CA is rethinking this and is considering mandating it on all new and
>renewed certs).
>>(I am presuming these private PKI certs are sub-CA certs certified by a CA
>>listed in browsers.)
>In some cases, that is correct.  Others are "closed" PKIs - self-signed
>and only for internal use (example: as in multiple components of
>bio-technology products that strongly authenticate to each other before
>enabling the product's use).
>Arshad Noor
>StrongAuth, Inc.

More information about the cryptography mailing list