Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Michael Richardson]

Joseph Salowey  wrote:
> On Fri, Oct 30, 2020 at 4:44 AM Michael Richardson 
> wrote:

>>
>> Joseph Salowey  wrote:
>> >> I suggest:
>> >>
>> >> “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
>> >> recovation checks,  MUST implement Certificate Status Requests
>> using OCSP
>> >> stapling as specified in Section 4.4.2.1 of [RFC8446].
>>
>> > [Joe] Thanks Michael,  I think your suggestion is a better way to
>> phrase it
>>
>> Just so that we are clear:  this mandates OCSP+stapling for systems that 
do
>> revocation checks.
>>
>> Systems that don't do revocation checks (current mbedtls), therefore 
don't
>> need to do OCSP or stapling.
>>

> [Joe] That's not how I read your text.  I think your text mandates
> OCSP+stapling for systems that use OCSP for revocation.

> TLS 1.3 RFC 8446 does not mandate a particular revocation mechanism 
either,
> as revocation is part of PKIX.

I thought that someone said that it did.
In which case, we are under no additional compulsion to support revocation
than we were before.

Hannes and Eliot have brought up significant operational challenges in
supporting OCSP in some environments.  I think that it should be a local 
decision.

> Also to be clear you text does not mandate that either servers or clients
> support OCSP Stapling.

> I think it would be appropriate to modify your text to replace "use" with
> support.

> "EAP-TLS servers supporting TLS 1.3 that support OCSP to do certificate
> revocation checks,  MUST implement Certificate Status Requests using OCSP
> stapling as specified in Section 4.4.2.1 of [RFC8446]."

okay.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[






>> --
>> Michael Richardson. o O ( IPv6 IøT consulting 
)
>> Sandelman Software Works Inc, Ottawa and Worldwide
>>
>>

> 
> Alternatives:

> 

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Joseph Salowey]

On Fri, Oct 30, 2020 at 4:44 AM Michael Richardson 
wrote:

>
> Joseph Salowey  wrote:
> >> I suggest:
> >>
> >> “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
> >> recovation checks,  MUST implement Certificate Status Requests
> using OCSP
> >> stapling as specified in Section 4.4.2.1 of [RFC8446].
>
> > [Joe] Thanks Michael,  I think your suggestion is a better way to
> phrase it
>
> Just so that we are clear:  this mandates OCSP+stapling for systems that do
> revocation checks.
>
> Systems that don't do revocation checks (current mbedtls), therefore don't
> need to do OCSP or stapling.
>

[Joe] That's not how I read your text.  I think your text mandates
OCSP+stapling for systems that use OCSP for revocation.

TLS 1.3 RFC 8446 does not mandate a particular revocation mechanism either,
as revocation is part of PKIX.

Also to be clear you text does not mandate that either servers or clients
support OCSP Stapling.

I think it would be appropriate to modify your text to replace "use" with
support.

"EAP-TLS servers supporting TLS 1.3 that support OCSP to do certificate
revocation checks,  MUST implement Certificate Status Requests using OCSP
stapling as specified in Section 4.4.2.1 of [RFC8446]."





> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Michael Richardson]

Joseph Salowey  wrote:
>> I suggest:
>>
>> “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
>> recovation checks,  MUST implement Certificate Status Requests using OCSP
>> stapling as specified in Section 4.4.2.1 of [RFC8446].

> [Joe] Thanks Michael,  I think your suggestion is a better way to phrase 
it

Just so that we are clear:  this mandates OCSP+stapling for systems that do
revocation checks.

Systems that don't do revocation checks (current mbedtls), therefore don't
need to do OCSP or stapling.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide



signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Joseph Salowey]

On Thu, Oct 29, 2020 at 3:12 PM Michael Richardson 
wrote:

>
> Joseph Salowey  wrote:
> > 2. Require Servers to Implement and Recommended to Use OCSP with text
> > similar to the following:
>
> I don't think that this text is quite right.
>
> I note that "RECOMMENDED" is a synonym for SHOULD, and usually we ask
> documents to explain what a reasonable exception might look like.
> This text does not do that.
>
> > “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
> > Requests (OCSP stapling) as specified in Section 4.4.2.1 of
> [RFC8446].  It
> > is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for
> > verifying the status of server certificates as specified in Section
> 4.4.2.1
> > of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the
> certificate
> > status of the EAP-TLS server, it MUST use Certificate Status
> Requests for
> > the server's certificate chain and it MUST treat a CertificateEntry
> (except
> > the trust anchor) without a valid CertificateStatus extension as
> invalid
> > and abort the handshake with an appropriate alert.“
>
> I suggest:
>
> “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
> recovation checks,  MUST implement Certificate Status Requests using OCSP
> stapling as specified in Section 4.4.2.1 of [RFC8446].
>
> It is RECOMMENDED that EAP-TLS peers and servers use OCSP (with stapling)
> for
> verifying the status of server certificates as specified in Section 4.4.2.1
> of [RFC8446].
>  mandated for TLS. I can't find the right place>
>
> When an EAP-TLS peer uses OCSP to verify the certificate status of the
> EAP-TLS server, it MUST use Certificate Status Requests for the server's
> certificate chain and it MUST treat a CertificateEntry (except the trust
> anchor) without a valid CertificateStatus extension as invalid and abort
> the
> handshake with an appropriate alert.“
>
> I don't know much about the last part.
> I suggest it be split as three paragraphs for readability.
>
>
[Joe] Thanks Michael,  I think your suggestion is a better way to phrase it


> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Michael Richardson]

Joseph Salowey  wrote:
> 2. Require Servers to Implement and Recommended to Use OCSP with text
> similar to the following:

I don't think that this text is quite right.

I note that "RECOMMENDED" is a synonym for SHOULD, and usually we ask
documents to explain what a reasonable exception might look like.
This text does not do that.

> “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
> Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It
> is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for
> verifying the status of server certificates as specified in Section 
4.4.2.1
> of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate
> status of the EAP-TLS server, it MUST use Certificate Status Requests for
> the server's certificate chain and it MUST treat a CertificateEntry 
(except
> the trust anchor) without a valid CertificateStatus extension as invalid
> and abort the handshake with an appropriate alert.“

I suggest:

“EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
recovation checks,  MUST implement Certificate Status Requests using OCSP
stapling as specified in Section 4.4.2.1 of [RFC8446].

It is RECOMMENDED that EAP-TLS peers and servers use OCSP (with stapling) for
verifying the status of server certificates as specified in Section 4.4.2.1
of [RFC8446].


When an EAP-TLS peer uses OCSP to verify the certificate status of the
EAP-TLS server, it MUST use Certificate Status Requests for the server's
certificate chain and it MUST treat a CertificateEntry (except the trust
anchor) without a valid CertificateStatus extension as invalid and abort the
handshake with an appropriate alert.“

I don't know much about the last part.
I suggest it be split as three paragraphs for readability.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Joseph Salowey]

On Thu, Oct 29, 2020 at 10:30 AM Max Pala  wrote:

> Hi Eliot, all,
>
>
>
> In our industry we solved this issue by *requiring OCSP stapling if and
> only if the certificate being validated carries the OCSP URI in the
> certificate*.
>
>
>
> This allows us to live in a mixed environment where support for OCSP might
> have been introduced later on and allows the CA to explicitly support OCSP
> for the certificate by including the URL in it.
>
>
>
> If the “ecosystem” policy allows it – you might suggest that if OCSP
> responses are not not provided but the URL where to get OCSP responses is
> known to the device (or it is in the certificate), the device/entity can
> continue with the authentication but it should not enable any device/entity
> functionality before successfully executing (and validating) the OCSP
> protocol first (and disconnect if not reachable/invalid/revoked).
>
>
>

[Joe] So you are in favor of both clients and servers
mandatory implementing OCSP, but only requiring it be used when it is
signalled in the certificate?


> Just my 2 cents.
>
>
>
> Cheers,
> Max
>
>
>
> *From: *Emu  on behalf of Eliot Lear  40cisco@dmarc.ietf.org>
> *Date: *Thursday, October 29, 2020 at 10:53 AM
> *To: *Joseph Salowey 
> *Cc: *EMU WG 
> *Subject: *Re: [Emu] Consensus Call on OCSP usage in
> draft-ietf-emu-eap-tls13-11
>
>
>
> Hi Joe,
>
>
>
> My suggestion is that we add some discussion about what to do in the case
> of no connectivity to the CA.  This will be a not-uncommon occurrence,
> IMHO, in industrial use cases.
>
>
>
> Eliot
>
>
>
> On 29 Oct 2020, at 17:23, Joseph Salowey  wrote:
>
>
>
> An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the
> mandatory requirement for OCSP stapling [1].  The document makes the use of
> OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this
> may not be feasible in all deployments.  This is a quick consensus call for
> this issue.   Please indicate which option below you support and why.
> Please respond by November 5, 2020.
>
> 1. Keep the text as is with OCSP mandatory for all implementations
>
> 2. Require Servers to Implement and Recommended to Use OCSP with text
> similar to the following:
>
> “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
> Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It
> is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for
> verifying the status of server certificates as specified in Section 4.4.2.1
> of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate
> status of the EAP-TLS server, it MUST use Certificate Status Requests for
> the server's certificate chain and it MUST treat a CertificateEntry (except
> the trust anchor) without a valid CertificateStatus extension as invalid
> and abort the handshake with an appropriate alert.“
>
>
>
> Thanks,
>
>
>
> Joe
>
>
>
> [1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/
> [2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
>
>
> ___ Emu mailing list
> Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Tim Cappalli]

+1

From: Emu 
Date: Thursday, October 29, 2020 at 14:10
To: Eliot Lear 
Cc: Max Pala , EMU WG 
Subject: Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11
  +1

> On Oct 29, 2020, at 1:37 PM, Eliot Lear  
> wrote:
>
> Hi Max
>
>> On 29 Oct 2020, at 18:30, Max Pala  wrote:
>>
>> Hi Eliot, all,
>>
>> In our industry we solved this issue by requiring OCSP stapling if and only 
>> if the certificate being validated carries the OCSP URI in the certificate.
>
> Perfectly reasonable.
>
>>
>> This allows us to live in a mixed environment where support for OCSP might 
>> have been introduced later on and allows the CA to explicitly support OCSP 
>> for the certificate by including the URL in it.
>
> Yep.
>
>>
>> If the “ecosystem” policy allows it – you might suggest that if OCSP 
>> responses are not not provided but the URL where to get OCSP responses is 
>> known to the device (or it is in the certificate), the device/entity can 
>> continue with the authentication but it should not enable any device/entity 
>> functionality before successfully executing (and validating) the OCSP 
>> protocol first (and disconnect if not reachable/invalid/revoked).
>>
>> Just my 2 cents.
>>
>
> Worth more.
>
> Eliot
>
>> Cheers,
>> Max
>>
>> From: Emu  on behalf of Eliot Lear 
>> 
>> Date: Thursday, October 29, 2020 at 10:53 AM
>> To: Joseph Salowey 
>> Cc: EMU WG 
>> Subject: Re: [Emu] Consensus Call on OCSP usage in 
>> draft-ietf-emu-eap-tls13-11
>>
>> Hi Joe,
>>
>> My suggestion is that we add some discussion about what to do in the case of 
>> no connectivity to the CA.  This will be a not-uncommon occurrence, IMHO, in 
>> industrial use cases.
>>
>> Eliot
>>
>>
>>> On 29 Oct 2020, at 17:23, Joseph Salowey  wrote:
>>>
>>> An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the 
>>> mandatory requirement for OCSP stapling [1].  The document makes the use of 
>>> OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this 
>>> may not be feasible in all deployments.  This is a quick consensus call for 
>>> this issue.   Please indicate which option below you support and why.  
>>> Please respond by November 5, 2020.
>>>
>>> 1. Keep the text as is with OCSP mandatory for all implementations
>>>
>>> 2. Require Servers to Implement and Recommended to Use OCSP with text 
>>> similar to the following:
>>>
>>> “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status 
>>> Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It 
>>> is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for 
>>> verifying the status of server certificates as specified in Section 4.4.2.1 
>>> of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate 
>>> status of the EAP-TLS server, it MUST use Certificate Status Requests for 
>>> the server's certificate chain and it MUST treat a CertificateEntry (except 
>>> the trust anchor) without a valid CertificateStatus extension as invalid 
>>> and abort the handshake with an appropriate alert.“
>>>
>>> Thanks,
>>>
>>> Joe
>>>
>>> [1] 
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2F0DnfUWPqvKX0_Wo8s-ZypergMHI%2Fdata=04%7C01%7Ctim.cappalli%40microsoft.com%7C78d538dffbd7449646e508d87c35d391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395918459834859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=KrJVJ6Un4%2BHpycHthG7MZPKDJUCHxrCPqib4bMrtRMQ%3Dreserved=0
>>> [2] 
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-emu-eap-tls13-11%23section-5.4data=04%7C01%7Ctim.cappalli%40microsoft.com%7C78d538dffbd7449646e508d87c35d391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395918459834859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=xuERey5ZNv3DjwO10WKS0f2cK87ObmQ6H2WXTzqtBDA%3Dreserved=0
>>> ___
>>> Emu mailing list
>>> Emu@ietf.org
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=04%7C01%7Ctim.cappalli%40microsoft.com%7C78d538dffbd7449646e508d87c35d391%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637395918459834859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Alan DeKok]

  +1

> On Oct 29, 2020, at 1:37 PM, Eliot Lear  
> wrote:
> 
> Hi Max
> 
>> On 29 Oct 2020, at 18:30, Max Pala  wrote:
>> 
>> Hi Eliot, all,
>>  
>> In our industry we solved this issue by requiring OCSP stapling if and only 
>> if the certificate being validated carries the OCSP URI in the certificate. 
> 
> Perfectly reasonable.
> 
>>  
>> This allows us to live in a mixed environment where support for OCSP might 
>> have been introduced later on and allows the CA to explicitly support OCSP 
>> for the certificate by including the URL in it.
> 
> Yep.
> 
>>  
>> If the “ecosystem” policy allows it – you might suggest that if OCSP 
>> responses are not not provided but the URL where to get OCSP responses is 
>> known to the device (or it is in the certificate), the device/entity can 
>> continue with the authentication but it should not enable any device/entity 
>> functionality before successfully executing (and validating) the OCSP 
>> protocol first (and disconnect if not reachable/invalid/revoked).
>>  
>> Just my 2 cents.
>>  
> 
> Worth more.
> 
> Eliot
> 
>> Cheers,
>> Max
>>  
>> From: Emu  on behalf of Eliot Lear 
>> 
>> Date: Thursday, October 29, 2020 at 10:53 AM
>> To: Joseph Salowey 
>> Cc: EMU WG 
>> Subject: Re: [Emu] Consensus Call on OCSP usage in 
>> draft-ietf-emu-eap-tls13-11
>>  
>> Hi Joe,
>>  
>> My suggestion is that we add some discussion about what to do in the case of 
>> no connectivity to the CA.  This will be a not-uncommon occurrence, IMHO, in 
>> industrial use cases.
>>  
>> Eliot
>> 
>> 
>>> On 29 Oct 2020, at 17:23, Joseph Salowey  wrote:
>>>  
>>> An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the 
>>> mandatory requirement for OCSP stapling [1].  The document makes the use of 
>>> OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this 
>>> may not be feasible in all deployments.  This is a quick consensus call for 
>>> this issue.   Please indicate which option below you support and why.  
>>> Please respond by November 5, 2020. 
>>> 
>>> 1. Keep the text as is with OCSP mandatory for all implementations
>>> 
>>> 2. Require Servers to Implement and Recommended to Use OCSP with text 
>>> similar to the following:
>>> 
>>> “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status 
>>> Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It 
>>> is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for 
>>> verifying the status of server certificates as specified in Section 4.4.2.1 
>>> of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate 
>>> status of the EAP-TLS server, it MUST use Certificate Status Requests for 
>>> the server's certificate chain and it MUST treat a CertificateEntry (except 
>>> the trust anchor) without a valid CertificateStatus extension as invalid 
>>> and abort the handshake with an appropriate alert.“
>>>  
>>> Thanks,
>>>  
>>> Joe
>>>  
>>> [1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/
>>> [2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4
>>> ___
>>> Emu mailing list
>>> Emu@ietf.org
>>> https://www.ietf.org/mailman/listinfo/emu
>>  
>> ___ Emu mailing list 
>> Emu@ietf.orghttps://www.ietf.org/mailman/listinfo/emu
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Eliot Lear]

Hi Max

> On 29 Oct 2020, at 18:30, Max Pala  <mailto:madw...@openca.org>> wrote:
> 
> Hi Eliot, all,
>  
> In our industry we solved this issue by requiring OCSP stapling if and only 
> if the certificate being validated carries the OCSP URI in the certificate. 

Perfectly reasonable.

>  
> This allows us to live in a mixed environment where support for OCSP might 
> have been introduced later on and allows the CA to explicitly support OCSP 
> for the certificate by including the URL in it.

Yep.

>  
> If the “ecosystem” policy allows it – you might suggest that if OCSP 
> responses are not not provided but the URL where to get OCSP responses is 
> known to the device (or it is in the certificate), the device/entity can 
> continue with the authentication but it should not enable any device/entity 
> functionality before successfully executing (and validating) the OCSP 
> protocol first (and disconnect if not reachable/invalid/revoked).
>  
> Just my 2 cents.
>  

Worth more.

Eliot

> Cheers,
> Max
>  
> From: Emu mailto:emu-boun...@ietf.org>> on behalf of 
> Eliot Lear  <mailto:lear=40cisco@dmarc.ietf.org>>
> Date: Thursday, October 29, 2020 at 10:53 AM
> To: Joseph Salowey mailto:j...@salowey.net>>
> Cc: EMU WG mailto:emu@ietf.org>>
> Subject: Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11
>  
> Hi Joe,
>  
> My suggestion is that we add some discussion about what to do in the case of 
> no connectivity to the CA.  This will be a not-uncommon occurrence, IMHO, in 
> industrial use cases.
>  
> Eliot
> 
> 
>> On 29 Oct 2020, at 17:23, Joseph Salowey > <mailto:j...@salowey.net>> wrote:
>>  
>> An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the 
>> mandatory requirement for OCSP stapling [1].  The document makes the use of 
>> OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this 
>> may not be feasible in all deployments.  This is a quick consensus call for 
>> this issue.   Please indicate which option below you support and why.  
>> Please respond by November 5, 2020. 
>> 
>> 1. Keep the text as is with OCSP mandatory for all implementations
>> 
>> 2. Require Servers to Implement and Recommended to Use OCSP with text 
>> similar to the following:
>> 
>> “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status 
>> Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It 
>> is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for 
>> verifying the status of server certificates as specified in Section 4.4.2.1 
>> of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate 
>> status of the EAP-TLS server, it MUST use Certificate Status Requests for 
>> the server's certificate chain and it MUST treat a CertificateEntry (except 
>> the trust anchor) without a valid CertificateStatus extension as invalid and 
>> abort the handshake with an appropriate alert.“
>>  
>> Thanks,
>>  
>> Joe
>>  
>> [1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/ 
>> <https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/>
>> [2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4 
>> <https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4>
>> ___
>> Emu mailing list
>> Emu@ietf.org <mailto:Emu@ietf.org>
>> https://www.ietf.org/mailman/listinfo/emu 
>> <https://www.ietf.org/mailman/listinfo/emu>
>  
> ___ Emu mailing list Emu@ietf.org 
> <mailto:Emu@ietf.org>https://www.ietf.org/mailman/listinfo/emu 
> <https://www.ietf.org/mailman/listinfo/emu>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Max Pala]

Hi Eliot, all,

 

In our industry we solved this issue by requiring OCSP stapling if and only if 
the certificate being validated carries the OCSP URI in the certificate. 

 

This allows us to live in a mixed environment where support for OCSP might have 
been introduced later on and allows the CA to explicitly support OCSP for the 
certificate by including the URL in it.

 

If the “ecosystem” policy allows it – you might suggest that if OCSP responses 
are not not provided but the URL where to get OCSP responses is known to the 
device (or it is in the certificate), the device/entity can continue with the 
authentication but it should not enable any device/entity functionality before 
successfully executing (and validating) the OCSP protocol first (and disconnect 
if not reachable/invalid/revoked).

 

Just my 2 cents.

 

Cheers,
Max

 

From: Emu  on behalf of Eliot Lear 

Date: Thursday, October 29, 2020 at 10:53 AM
To: Joseph Salowey 
Cc: EMU WG 
Subject: Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

 

Hi Joe,

 

My suggestion is that we add some discussion about what to do in the case of no 
connectivity to the CA.  This will be a not-uncommon occurrence, IMHO, in 
industrial use cases.

 

Eliot



On 29 Oct 2020, at 17:23, Joseph Salowey  wrote:

 

An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the 
mandatory requirement for OCSP stapling [1].  The document makes the use of 
OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this may 
not be feasible in all deployments.  This is a quick consensus call for this 
issue.   Please indicate which option below you support and why.  Please 
respond by November 5, 2020. 

1. Keep the text as is with OCSP mandatory for all implementations

2. Require Servers to Implement and Recommended to Use OCSP with text similar 
to the following:

“EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests 
(OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It is 
RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for verifying the 
status of server certificates as specified in Section 4.4.2.1 of [RFC8446]. 
When an EAP-TLS peer uses OCSP to verify the certificate status of the EAP-TLS 
server, it MUST use Certificate Status Requests for the server's certificate 
chain and it MUST treat a CertificateEntry (except the trust anchor) without a 
valid CertificateStatus extension as invalid and abort the handshake with an 
appropriate alert.“

 

Thanks,

 

Joe

 

[1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/
[2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

 

___ Emu mailing list Emu@ietf.org 
https://www.ietf.org/mailman/listinfo/emu 

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Eliot Lear]

Hi Joe,

My suggestion is that we add some discussion about what to do in the case of no 
connectivity to the CA.  This will be a not-uncommon occurrence, IMHO, in 
industrial use cases.

Eliot

> On 29 Oct 2020, at 17:23, Joseph Salowey  > wrote:
> 
> An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the 
> mandatory requirement for OCSP stapling [1].  The document makes the use of 
> OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this 
> may not be feasible in all deployments.  This is a quick consensus call for 
> this issue.   Please indicate which option below you support and why.  Please 
> respond by November 5, 2020. 
> 
> 1. Keep the text as is with OCSP mandatory for all implementations
> 
> 2. Require Servers to Implement and Recommended to Use OCSP with text similar 
> to the following:
> 
> “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status 
> Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It is 
> RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for verifying 
> the status of server certificates as specified in Section 4.4.2.1 of 
> [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate status of 
> the EAP-TLS server, it MUST use Certificate Status Requests for the server's 
> certificate chain and it MUST treat a CertificateEntry (except the trust 
> anchor) without a valid CertificateStatus extension as invalid and abort the 
> handshake with an appropriate alert.“
> 
> Thanks,
> 
> Joe
> 
> [1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/ 
> 
> [2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4 
> ___
> Emu mailing list
> Emu@ietf.org 
> https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

[Joseph Salowey]

An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the
mandatory requirement for OCSP stapling [1].  The document makes the use of
OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this
may not be feasible in all deployments.  This is a quick consensus call for
this issue.   Please indicate which option below you support and why.
Please respond by November 5, 2020.

1. Keep the text as is with OCSP mandatory for all implementations

2. Require Servers to Implement and Recommended to Use OCSP with text
similar to the following:

“EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It
is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for
verifying the status of server certificates as specified in Section 4.4.2.1
of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate
status of the EAP-TLS server, it MUST use Certificate Status Requests for
the server's certificate chain and it MUST treat a CertificateEntry (except
the trust anchor) without a valid CertificateStatus extension as invalid
and abort the handshake with an appropriate alert.“

Thanks,

Joe

[1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/
[2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu