[cryptography] airgaps in CAs
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
> 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
More information about the cryptography