Presumably these sub-CA certs have pathLenConstraint = 0? (Meaning they are
only authorized to issue site certificates, not further sub-CA
certificates).
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?
Adam
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
constraint
extension eg ".foocorp.com" meaning it is only valid for creating certs for
*.foocorp.com?
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.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
