Subject: [pkix] Proposal: Change the Compatibility Requirement of Name

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Apr 2012 08:58:52 -0400

The only reason that we are having this discussion is that the flag is
misnamed. Criticality is ambiguous and has misled some people into
thinking it means 'important'. Which it does not. Is the subject key
an important field (yes) is it marked critical (nope).

If the flag had been called 'Compatibility' instead we would have
avoided this whole debate (and many others).

All that was being suggested is to change the criticality flag
requirement of the NC extension. But to prevent future confusion I
suggest we rename the flag in 5280bis as well.

On Mon, Apr 9, 2012 at 12:46 PM, Max Pritikin <[email-masked]> wrote:
> +1 (Well stated Stefan)
>
> This is my position as well: The CAs should make this decision based on their own policy. PKIX documents should, as does the X.509 document, recommend the more secure option.
>
> Any client that ignores a critical extension's contents should be publicly hounded as having a security vulnerability.
>
> - max
>
> On Apr 7, 2012, at 6:11 PM, Stefan Santesson wrote:
>
>> Being away for some days, it was quite a read before anyone cared to look
>> in the X.509 spec :)
>>
>> I regret the flaming in this thread, enough said about that.
>>
>> I believe PKIX made a mistake requiring CAs to mark this extension
>> critical, while X.509 allows it to be non-critical.
>>
>> The requirement does not affect client behavior (thoroughly examined in
>> this thread). It just imposes policy on the CA that actually should be up
>> to the CA to decide. A CA that concludes that criticality is important,
>> can always set it critical.
>>
>> IOS as well as OS X are clearly not compliant with RFC 5280, but that is
>> not a good argument to require criticality.
>>
>> /Stefan
>>
>>
>> On 12-04-07 10:53 PM, "Kyle Hamilton" <[email-masked]> wrote:
>>
>>> Nope.  X.509/2008 page 33, section 8.4.2.2:
>>> [...]
>>> This extension may, at the option of the certificate issuer, be either
>>> critical or non-critical . It is recommended that it be
>>> flagged critical, otherwise a certificate user may not check that
>>> subsequent certificates in a certification path are located
>>> in the name space intended by the issuing CA.
>>> [...]
>>>
>>> The criticality mandate is all PKIX.
>>>
>>> -Kyle H
>>>
>>> On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker <[email-masked]>
>>> wrote:
>>>> Isn't it an X509v3 requirement in any case?
>>>>
>>>> On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley <[email-masked]>
>>>> wrote:
>>>>> Ryan:
>>>>>
>>>>>> While Apple's OS X (desktop) implementation will not choke if Name
>>>>>> Constraints is marked critical, it does not support processing name
>>>>>> constraints and will not enforce them - critical or not. It does not
>>>>>> quite
>>>>>> implement all of RFC 2459, let alone 3280 or 5280, nor does 2459
>>>>>> require
>>>>>> that it fail processing if it does not process a critical extension
>>>>>> (although 5280 does).
>>>>>
>>>>> RFC 2459 says:
>>>>>
>>>>>  ...  A
>>>>>  certificate using system MUST reject the certificate if it encounters
>>>>>  a critical extension it does not recognize; however, a non-critical
>>>>>  extension may be ignored if it is not recognized.  ...
>>>>>
>>>>> So, this is not a concept that was added in RFC 3280 or 5280.
>>>>>
>>>>> Russ
>>>>> _______________________________________________
>>>>> pkix mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>>
>>>>
>>>>
>>>> --
>>>> Website: http://hallambaker.com/
>>>> _______________________________________________
>>>> pkix mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/pkix
>>> _______________________________________________
>>> pkix mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>

-- 
Website: http://hallambaker.com/