<HTML dir=ltr><HEAD>
<STYLE title=owaParaStyle><!--P {
        MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
--></STYLE>
</HEAD>
<BODY ocsi="x">
<DIV dir=ltr><FONT color=#000000 size=3 face="Courier New">Rich,</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New"></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New">Thanks, I think I understand the reasoning behind.</FONT></DIV>
<DIV dir=ltr><FONT face="courier new"></FONT> </DIV>
<DIV dir=ltr><FONT face="courier new">I simply do not believe allowing the Name Constraints extension to be marked non-critical will push those dumb clients to become supporting the critical <FONT face="Courier New">Name Constraints extension.</FONT></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New"></FONT> </DIV>
<DIV>
<DIV><FONT size=2>
<DIV dir=ltr><FONT color=#000000 size=3 face="Courier New">Wen-Cheng Wang</FONT></DIV>
<DIV dir=ltr><FONT size=3 face="courier new"></FONT> </DIV></FONT></DIV></DIV>
<DIV style="DIRECTION: ltr" id=divRpF16036><FONT face="Courier New">
<HR tabIndex=-1>
</FONT><FONT size=2 face=Tahoma><B>From:</B> Rich Smith [richard.smith@comodo.com]<BR><B>Sent:</B> Friday, May 25, 2012 9:57 PM<BR><B>To:</B> 王瘢雹文正; 'Ryan Hurst'; 'Chris Palmer'<BR><B>Cc:</B> public@cabforum.org<BR><B>Subject:</B> RE: [cabfpub] More changes to proposed policy update<BR></FONT><BR>
<DIV><PRE style="WORD-WRAP: break-word">Wen-Cheng,
I think if you see Phillip's post on this from April 4, pasted below, you will better understand the reasoning behind this:

"The Criticality Flag is actually mis-named. It does not mean 'important', it should be called the 'Compatibility flag'.

If a client processes the NC extension it is obliged to either process the extension or reject the cert regardless of whether the flag is set or not. 
The criticality flag does not affect the semantics of an extension, the sole and only purpose is to break backwards compatibility."

Currently no one is willing to break backward compatibility because it would adversely affect too many end users.  In simple terms, allowing name constraints to be set non-critical for the short term will allow them to be used and the client software that supports them will process them and those which don't support them will simply ignore them.  However if they are set critical, there is no change from the stand point of the clients that do support them, however for the clients that do not support them, any certificates containing them will fail.  

The alternatives currently available are:

Allow them to be set non-critical, and the clients which support them get the benefit, those that don't behave the same as they would if name constraints were not present, OR;

Don't allow them to be set non-critical, which will mean that they won't be used at all until such time as a critical mass of clients support them.  If no one is actually using them, supporting them will likely not be seen as a high priority by the vendors who don't currently support them, so they may never be added and that critical mass may never be reached.

-Rich</PRE></DIV></DIV></BODY></HTML>