[cryptography] airgaps in CAs

Arshad Noor arshad.noor at strongauth.com
Tue Dec 27 12:23:46 EST 2011

On 12/13/2011 03:45 AM, Adam Back wrote:
> Presumably these sub-CA certs have pathLenConstraint = 0? (Meaning they are
> only authorized to issue site certificates, not further sub-CA
> certificates).


> 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?

	Where certificates contain FQDN, they are issued only by trusted
	Administrators.  While there are no technical constraints, there
	are policy constraints.  Policy enforcement is accomplished
	through the use of manual approvals by trusted Administrators,
	as well as through periodic audits.

> 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?

	While the operational issues are not the primary barrier,
	most companies do not see any business advantage in limiting
	their options wrt how they can issue certs (within the
	constraints of their CP).  If their issuance controls are
	robust, there is little risk that the company PKI will issue
	certs to unauthorized FQDN.

	However, as I indicated in an earlier posting, at least one
	TTP CA we work with is planning on mandating the use of
	nameConstraints to limit their own liability; this is bound
	to cause some friction in companies where M&A activity is
	fairly common.  It remains to be seen how the lawyers will
	negotiate this.

Arshad Noor
StrongAuth, Inc.

More information about the cryptography mailing list