Re: [Ejbca-develop] nameConstraints extension support in EJBCA

[Arshad N. <ars...@st...>]

Hi Tomas,

Thanks for your response; I will look into the Custom Extensions
section of the EJBCA documentation and see how easy/difficult it is
to include the constraint in CA certificates.

However, I believe you and I may have a misunderstanding about how
the nameConstraints extension is used - although this is not the first
time RFC 5280 has been misunderstood :-).  Here is how I understand it:


Section 4.2.1.10 of RFC 5280 says:

    The name constraints extension, which MUST be used only in a CA
    certificate, indicates a name space within which all subject names
    in subsequent certificates in a certification path MUST be located.

My understanding is that the constraint exists primarily for the use
of the CA software (like EJBCA) to constrain the certificates is issues
to only the permitted sub-trees.

I do not believe application software (such as browsers, e-mail, VPN
software, etc.) need care about the nameConstraints extension even
though they see it in the CA certificates of the chain.  The reason is,
they have other ways of verifying the permitted subtree.

For example, a browser checks the subjectAltName extension for the
FQDN and matches it up with the FQDN of the web-site it is connected
to.  If they do not match, you get the proverbial warnings.  Since the
use of SAN is universal for server SSL certificates, what would it
matter if the nameConstraint had a completely different FQDN in the
permitted sub-tree (as long as the site and the SAN FQDN matched?

Similarly, Maul User Agents are able to verify the use of a digital
certificate for S/MIME against the e-mail header - which has the
sender and recipients' e-mail addresses.  What would the RFC822 name
in the nameConstraint tell the MUA that it doesn't already know?

I believe the nameConstraints extension exists primarily for the use
of CA software vendors so that issuers of certificates can constrain
the issuance of digital certificates to permit or exclude sub-trees.

Am I misunderstanding this?

Arshad Noor
StrongAuth, Inc.


On 05/24/2012 11:58 PM, Tomas Gustavsson wrote:
>
> Hi Arshad,
>
> Currently you can use custom extensions to implement name constraints.
> We have done that for customers.
>
> The main responsibility is for the client, when verifying the
> certificate chain, to reject certificate violating the constraints.
> The client implementations for this is currently not perfect, with
> different flaws on various platforms, as our testing shows.
>
> I'd expect this to work better and be more widely deployed in the future
> though.
>
> Cheers,
> Tomas
>
> On 05/24/2012 10:14 PM, Arshad Noor wrote:
>> Hi,
>>
>> Not sure if I'm reading this correctly, but does EJBCA have support
>> for issuing/understanding certificates with the nameConstraints (OID
>> 2.5.29.30) extension in them, so it can only issue certificates that
>> conform to the constraint?  I don't see any reference to this
>> constraint in its documentation.
>>
>> I did find an old e-mail that seems to indicate that PrimeKey does
>> NOT recommend this extension:
>>
>> http://osdir.com/ml/java.ejbca.devel/2006-02/msg00092.html
>>
>> Unfortunately, because of all the problems recently with CAs being
>> compromised, TTP CAs are now planning to enforce the use of this
>> extension to limit their liability.  However, the CA software must
>> be able to support the use of the constraint and check all CSRs to
>> see if the constraint is satisfied before issuing the certificate.
>> I'm unable to find anything in EJBCA docs that indicate this is
>> supported; can someone please provide some clarification?  Thanks.
>>
>> Arshad Noor
>> StrongAuth, Inc.