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).
Unquestionably.
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.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
