Re: [Fed-Talk] Change in Cert Validation in 10.6.4?
Re: [Fed-Talk] Change in Cert Validation in 10.6.4?
- Subject: Re: [Fed-Talk] Change in Cert Validation in 10.6.4?
- From: "Henry B. Hotz" <email@hidden>
- Date: Tue, 29 Jun 2010 11:03:16 -0700
Hmmm. Not to be a nit-picker, but I think you meant RFC 3280 (cert & CRL profile), not 3820 (proxy). That's been superseded by RFC 5280. The changes don't affect your argument though.
> 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.4), subject alternative name (Section
> 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints
> (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended
> key usage (Section 4.2.1.12), and inhibit anyPolicy (Section 4.2.1.14).
Seems like the FBCA cert should be OK, but Apple doesn't like it. Seems like Apple is required to like it per RFC 5280 (or else advertise that they do not conform to the relevant IETF standards).
I also don't think that the NASA CA is in the SystemCACertificates keychain as delivered by Apple. Should we complain about that as well? If there were one there I gather it wouldn't substitute for the chain supplied by the originator.
On Jun 29, 2010, at 6:50 AM, Paul Nelson wrote:
> Getting directly to the point: Apple's CDSA does not conform to RFC 3820 section 4.2.1.11. This section is mandatory, as specified in section 4.2:
>
> At a minimum, applications conforming to this profile [the X.509 version 3 certificate] 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).
>
> I have reported this as a bug to Apple. I think this is a pretty serious problem. As Henry points out, he can read the e-mail, but he is completely deprived of the ability to verify the sender. To me, that is a security bug, but I don't think that Apple sees it that way. Since they fail the validation, they may consider this "safe". However, it leads to the exact opposite behavior in users - deciding to trust a message anyway because they know the software can't do it for them.
>
> Paul Nelson
> Thursby Software Systems, Inc.
>
> On Jun 29, 2010, at 8:26 AM, Miller, Timothy J. wrote:
>
>> You're chaining through the bridge and OS X doesn't grok nameConstraints. Since nameConstraints is marked critical (for damn good reasons :) in cross-certificates, the chain will always be invalid.
>>
>> The cause of this is a combination of factors:
>>
>> - The sender has the Common Policy CA cert installed in his cert store. When this happens, CAPI prefers the bridge chain over the shorter chain to the local root.
>>
>> - Outlook sends the whole chain with the signed message. This is configurable in the Outlook Trust Center S/MIME pane.
>>
>> - OS X appears to only attempt to validate the chain as sent, rather than build it anew. Alternately, the chain failure because of critical extensions not processed doesn't cause the validation engine to seek a different path. I'm not sure which is happening because I haven't constructed test cases.
>>
>> -- Tim
>>
>>
>>> -----Original Message-----
>>> From: fed-talk-bounces+tmiller=email@hidden [mailto:fed-
>>> talk-bounces+tmiller=email@hidden] On Behalf Of Henry B.
>>> Hotz
>>> Sent: Monday, June 28, 2010 6:37 PM
>>> To: Apple Fed Talk
>>> Subject: [Fed-Talk] Change in Cert Validation in 10.6.4?
>>>
>>> I now get the following error when I receive an encrypted email from
>>> someone else at NASA. It doesn't prevent me from actually reading the
>>> email, but I don't recall getting this warning before.
>>>
>>> Looking through the cert I see a critical "name constraints" extension
>>> (OID 2.5.29.30) which seems the most likely suspect, but I may be wrong.
>>> Even if I check the "always trust" box on the FBCA, the "common policy"
>>> cert still fails because it has an invalid issuer.
>>>
>>> Any comments or analysis anyone?
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Fed-talk mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
>
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
email@hidden, or email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden