Frank Hecker wrote:
Wan-Teh Chang wrote:
Gervase Markham wrote:
I am interested in investigating with the NSS developers whether it
would be possible to restrict a particular root certificate to
signing end entity certificates only for domains with a particular TLD.
In this context Gerv's reference is to end-entity certs used for
SSL/TLS-enabled servers. My understanding is that name constraints
could be used in a similar way for S/MIME certs, e.g., requiring that
the subject alternative name end in .ll or whatever. I'm guessing for
object signing certs one could implement a restriction based on the
presence of, e.g., C=LL in the subject DN.
Yes, this is technically feasible. The CA's certificate can have
a "name constraints" extension that constrains the domain names in
the .ll name space. See RFC 3280, Section 4.2.1.11 Name Constraints.
Of course using name constraints in the classic sense requires the
cooperation of the CA (since they have to add the extension to the CA
cert). I think Gerv was thinking of the more general case where for
policy reasons we might want to impose constraints on a CA even in the
case where there was no name constraints extension.
In addition, we only parse these kinds of constraints on intermediate
certs (we currently don't have a mechanism to place name constraints on
a trusted root. Even if the trusted root had constraints itself, they
would be ignored once we identify the cert as trusted.
I guess if the NSS code already has code to implement name constraints
anyway (i.e., keying off the extension) then it would be in theory
possible for the code to optionally act as if name constraints were in
effect even if they not specified in the CA cert itself. (E.g., the
name constraints information could be stored as metadata with the root
CA.)
Frank
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
