Re: Name constraints

["Housley, Russ" <rhousley@xxxxxxxxxxxxxxx>]

No, the name constraints extension is not dead.  There are several 
environments that need it.  I have heard from other people frustration 
about the lack of support it browsers.

Son-of-2459 continues to include name constraints.    It says:

    Conforming CAs MUST support key identifiers (sections 4.2.1.1 and
    4.2.1.2), basic constraints (section 4.2.1.10), key usage (section
    4.2.1.3), and certificate policies (section 4.2.1.5) extensions.  If
    the CA issues certificates with an empty sequence for the subject
    field, the CA MUST support the subject alternative name extension
    (section 4.2.1.7).  Support for the remaining extensions is OPTIONAL.
    Conforming CAs MAY support extensions that are not identified within
    this specification; certificate issuers are cautioned that marking
    such extensions as critical may inhibit interoperability.

    At a minimum, applications conforming to this profile MUST recognize
    the following extensions: key usage (section 4.2.1.3), certificate
    policies (section 4.2.1.5), the subject alternative name (section
    4.2.1.7), basic constraints (section 4.2.1.10), name constraints
    (section 4.2.1.11), policy constraints (section 4.2.1.12), extended
    key usage (section 4.2.1.13), and inhibit any-policy (section
    4.2.1.15).

    In addition, applications conforming to this profile SHOULD recognize
    the authority and subject key identifier (sections 4.2.1.1 and
    4.2.1.2), and policy mapping (section 4.2.1.6) extensions.

Part of the slow implementation may be related to the fact that CAs are not 
required to support name constraints.  I think that this is appropriate 
because some environments do not need name constraints, but other 
environments do.

Russ


At 12:44 PM 12/19/2001 -0800, Michael Helm wrote:

>... or the lack of support for them (rfc 2459 4.2.1.11)
>
>I recently "had occasion" to try out name contraints and
>their support in various revisions of the popular web
>browsers, and results are certainly disappointing.
>
>Let "NC" stand for some text along the lines of, "a certificate
>that chains to a CA signing certificate that has a name constraints
>extension set according to rfc 2459 4.2.1.11, marked critical"
>
>Netscape communicator 4.x rejects connection with an NC, saying that
>it has an unknown critical extension.   Disappointing, given that
>rfc 2459 is approaching its 3rd birthday.
>
>IE 5.5 connected  fine with the NC ; but it displays it as a blob.
>
>Netscape 6.x connect with the NC, and in successive revisions display
>or manage the certificate a little better each rev.  However, they still
>don't translate the 2.5.29.30 OID into anything sensible, leaving it
>as hex data.
>
>IE 6 connects with the NC fine, and displays a sensible translation of the
>name constraint info.
>
>Just for kicks, openssl-096b doesn't translate this OID into anything
>readable either (don't see any sign of name constraint support
>in the source).
>
>Note that I haven't had time to generate some bogus certificates (out
>of conformance with name constraints) to test actual compliance.
>But the poor translation behavior by the browsers doesn't inspire
>a lot of confidence.
>
>Is this extension dead?




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================