[Servercert-wg] Critical Name Constraints (Was: Re: Question on BR 3.2.2.6)

[Dimitris Zacharopoulos (HARICA)]

On 2020-03-03 2:42 μ.μ., Pedro FUENTES wrote:
> Hi Dimitris,
>
> Just to clarify that what I said is that the decision can’t be taken 
> only considering serverAuth, because this requirement applies to every 
> subordinate CA issued under a Root that undergoes BR compliance.
>
> To be clear: a SubCA that only has emailProtection, but that is issued 
> by a Root that needs to be compliant with BR, will need to have the 
> nameConstraints extension set as critical or not depending of the BR 
> mandate, as in other case the Root won’t be compliant with BR.
>
> So even if this WG is not for S/MIME, the decision must be taken 
> considering the impact in other scopes that “the WebPKI”.
>
> Best,
> Pedro
>
> PS Personally I can’t give more information on interoperability 
> issues. We had issues in the past with Apple software, but it seems 
> that it's already solved.


I would like to ask other members if this interpretation is accurate. If 
the CA Certificate is out of scope of the BRs (i.e. not technically 
capable of issuing TLS Certificates), I believe it does not need to 
comply with the BRs. For example, if we create -say- a code-signing CA, 
the CA Certificate Profile described in 7.1.2.2 and 7.1.4.3.1 do not 
apply. This is my understanding after following many discussions and 
conversations in the Forum and SCWG over the last couple of years.


Thanks,
Dimitris.



>
>
>
>> El 3 mar 2020, a las 10:10, Dimitris Zacharopoulos (HARICA) 
>> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> escribió:
>>
>> On 3/3/2020 10:36 π.μ., Pedro FUENTES wrote:
>>> Hello,
>>>
>>> On my side… I’d be keen to align with #2, as I think it’s the way to 
>>> go, but for that we’d need some objective data to assess the impact 
>>> and be sure we aren’t shooting in our foot… Do we have any idea of 
>>> what software nowadays would reject certificates or would 
>>> malfunction if we enforce the critical thing?
>>>
>>
>> Hello Pedro,
>>
>> One of the purposes of this thread is to collect some objective data 
>> to assess the impact :-) If you have evidence to share about TLS 
>> Certificate Issuing CAs, it would be very helpful.
>>
>>
>>> Just as a side comment… In our case, we mostly used name constraints 
>>> for subordinates intended for "S/MIME certificates" (in reality this 
>>> means "personal certificates used for authentication, digital 
>>> signature and secure email", but let’s go for the over-simplified 
>>> term “S/MIME Certificates” I see it’s used in the Forum) so assuming 
>>> a rule that is only considering “the webPKI” is maybe not something 
>>> appropriate. We must see interoperability as a whole as these 
>>> decisions won't only impact TLS certs, because this rule of the BR 
>>> applies to all subordinates, not only the ones having the serverAuth 
>>> EKU.
>>>
>>> Best,
>>> Pedro
>>
>>
>>
>> I don't think conflating S/MIME with serverAuth is useful for this 
>> thread. According to several Root programs, you should not include 
>> emailProtection and serverAuth Extended Key Usages in the same 
>> Issuing CA. Also, please remember that this Working Group does not 
>> discuss issues related to S/MIME Certificates.
>>
>> It would help if you have been using name constraints for serverAuth 
>> Issuing CAs and share your experience with legacy software.
>>
>>
>> Thanks,
>> Dimitris.
>>
>>
>
> *WISeKey SA
> *
> *Pedro Fuentes
> *CSO - PM eSecurity Solutions
> Office: + 41 (0) 22 594 30 00
> Mobile: + 41 (0) 791 274 790
> Address: 29, Rte de Pré-Bois - CP 853 | Geneva 1215 CH - Switzerland
> *Stay connected with WISeKey <http://www.wisekey.com>
> *
> *THIS IS A TRUSTED MAIL*: This message is digitally signed with a 
> WISeKey identity. If you get a mail from WISeKey please check 
> the signature to avoid security risks
>
> *CONFIDENTIALITY: *This email and any files transmitted with it can be 
> confidential and it’s intended solely for the use of the individual or 
> entity to which they are addressed. If you are not the named addressee 
> you should not disseminate, distribute or copy this e-mail. If 
> you have received this email in error please notify the sender
>
> *DISCLAIMER: *WISeKey does not warrant the accuracy or completeness of 
> this message and does not accept any liability for any errors or 
> omissions herein as this message has been transmitted over a public 
> network. Internet communications cannot be guaranteed to be secure or 
> error-free as information may be intercepted, corrupted, or contain 
> viruses. Attachments to this e-mail are checked for viruses; 
> however, we do not accept any liability for any damage sustained by 
> viruses and therefore you are kindly requested to check for viruses 
> upon receipt.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200303/b67e2b23/attachment.html>