Apologies if I’m replying to the wrong thread, but I wanted to comment on one point here.
> On May 14, 2024, at 8:54 AM, Dimitris Zacharopoulos (HARICA) via
> Servercert-wg <servercert-wg@cabforum.org> wrote:
>
>
>
> On 14/5/2024 1:27 μ.μ., Adriano Santoni via Servercert-wg wrote:
>> I would agree to consider out-of-scope (of the BRs) a leaf certificate with
>> EKU=clientAuth issued by a SubCA that has EKU={server,client}, provided of
>> course the leaf certificate does not assert a BR TLS policy OID because this
>> would be contradictory.
>>
>> Besides, at least one widely used linter considers a certificate in-scope if
>> it contains EKU=serverAuth and/or it contains a BR policy OID, which seems
>> quite logical to me.
>>
>> Adriano
>>
>>
>>
>
> I think the policy OID is effectively completely ignored (along with anything
> in the subject of the certificate or other extensions) because the
> certificate is by design "incompatible for server TLS", so it is discarded by
> server TLS consumers which are conformant with RFC 5280.
I don’t think it’s entirely germane whether or not the policy OID is discarded
by an application; the inclusion of the policy OID itself is a violation of RFC
5280 by the CA (if it’s included in a certificate or certificate chain where
the leaf certificate being validated doesn’t comply with the policy referenced
by the OID).
Thanks!
-Clint
>
> It is misleading, but it is very difficult to add requirements around what a
> Certificate MUST NOT include (e.g. an existing TLS BR policy OID). I'd prefer
> to clarify that these are out-of-scope of the BRs as long as they are
> structured according to RFC 5280, and do not contain EKU=serverAuth, just
> like we did for the TC non-TLS subCA Profile.
>
> Dimitris.
>
>>
>> Il 14/05/2024 11:33, Dimitris Zacharopoulos (HARICA) via Servercert-wg ha
>> scritto:
>>>
>>> NOTICE: Pay attention - external email - Sender is
>>> 0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000...@amazonses.com
>>> <mailto:0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000...@amazonses.com>
>>>
>>> Dear Members,
>>>
>>> Following-up on an interesting public incident
>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1886467#c11> , I would like
>>> to have a discussion about the scope of the TLS BRs as specified in the
>>> SCWG Charter and in the actual TLS BRs, especially when it comes to
>>> single-purpose "client authentication" certificates (i.e. leaf certificates
>>> that include the id-kp-clientAuth and DO NOT include the id-kp-serverAuth
>>> KeyPurposeId in their extKeyUsage extension).
>>> The TLS BRs describe the profiles of Subordinate CA Certificates issued
>>> from a Root that is in-scope for server TLS authentication, even for the
>>> case of Technically-Constrained non-TLS CA Certificates. There was a lot of
>>> discussion about whether this is permitted based on the SCWG Charter and
>>> there was consensus that Browsers want to make sure that there are some
>>> minimum expectations about the structure of such non-TLS CA certificates,
>>> especially the adherence to RFC 5280. I recall that there was also
>>> consensus that whatever is issued off of these TC non-TLS CAs is not in
>>> scope of the TLS BRs.
>>>
>>> Does this seem like a fair statement about intent of the group on the
>>> expectations of TC non-TLS CAs and their leaf certificates?
>>>
>>> Technically Constrained non-TLS Issuing CAs have a defined profile in the
>>> TLS BRs but IMO it cannot, and should not mandate the profile of non-TLS
>>> leaf certificates based on the CA/Browser Forum Server Certificate Working
>>> Group Charter <https://cabforum.org/working-groups/server/charter/> which
>>> states (emphasis mine):
>>>
>>>> (a) To specify Baseline Requirements, Extended Validation Guidelines, and
>>>> other acceptable practices for the issuance and management of TLS server
>>>> certificates used for authenticating servers accessible through the
>>>> Internet
>>> It gets more interesting when an Issuing CA that is technically capable of
>>> issuing server authentication TLS Certificates (by including the
>>> id-kp-serverAuth KeyPurposeId in its extKeyUsage extension), also includes
>>> the id-kp-clientAuth KeyPurposeId, thus being technically capable of
>>> issuing client authentication TLS Certificates.
>>>
>>> Please recall that a few years back multi-purpose Issuing CAs existed,
>>> where the EKU was not present, and even if it was, it allowed the inclusion
>>> of various KeyPurposeIds.
>>>
>>> Is it ok for such an Issuing CA to create a single-purpose client
>>> authentication TLS Certificate, one that is structured according to RFC
>>> 5280 (thus can be successfully parsed by Relying Party RFC 5280-conformant
>>> software), contains an extKeyUsage extension which contains the
>>> id-kp-clientAuth and DOES NOT include the id-kp-serverAuth KeyPurposeId?
>>>
>>> My understanding is that these particular leaf certificates are allowed to
>>> be issued by a server TLS capable CA and they are considered out-of-scope
>>> of the BRs, in the sense that they are not TLS Server Certificates. The
>>> SCWG has accepted this "risk" with the client authentication certificates
>>> by allowing the co-existence of id-kp-clientAuth and id-kp-serverAuth
>>> KeyPurposeIds and the explicit dis-allowance of id-kp-emailProtection,
>>> id-kp-codeSigning, id-kp-timeStamping, anyExtendedKeyUsage in the CA
>>> Certificate profiles.
>>>
>>> The first paragraph of the TLS BRs (section 1.1) states:
>>>
>>>> .....for the issuance and management of Publicly-Trusted TLS Server
>>>> Certificates;
>>> Provided these certificates follow RFC 5280 and can be properly parsed,
>>> Browsers should never consider such certificates server TLS certificates.
>>> They are by design "technically constrained".
>>>
>>> Thoughts? Disagreements? I know that Apple has already publicly shared an
>>> opinion <https://bugzilla.mozilla.org/show_bug.cgi?id=1886467#c13> on this
>>> matter so I'm hoping to get more feedback from Members here :)
>>>
>>>
>>> Thanks,
>>> Dimitris.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Servercert-wg mailing list
>>> Servercert-wg@cabforum.org <mailto:Servercert-wg@cabforum.org>
>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>>
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg@cabforum.org <mailto:Servercert-wg@cabforum.org>
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
