[Accepted] SDL 0333 - Handle Scenario Where no Valid Cert is Available

[theresalech]

Hello SDL community,

The review of the revised proposal "SDL 0333 - Handle Scenario Where no Valid Cert is Available" begins now and runs through July 13, 2021. Previous reviews of this proposal took place May 12 - May 25, 2021 and June 2 - June 22, 2021. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0333-handle-scenario-where-no-valid-cert-is-available.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

#1140

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Theresa Lech

Program Manager - Livio
theresa@livio.io

[joeljfischer]

1. In the motivation, you state:

Currently, if an app requests a protected session while SDL Core does not have a valid certificate the request will be pending until Core either is able to retrieve a valid certificate through PTU or if the whole PTU retry sequence fails.

I think the last part of this sentence is missing.

2. A very minor clarification point. The next sentence in the motivation states:

In the default configuration, the PTU retry sequence can take up to 17 minutes, which means that if an app attempts to start a protected service early in Core's lifecycle it will take quite a while for the app to receive a response. This could cause a poor user experience.

I think that "it will take quite a while" should state "it may take quite a while".

---

Overall, I think this proposal is a good change.

[joeygrover]

3. This might be out of scope for this proposal specifically, but in the case that a PTU is updated after a NAK has been sent to the app, is there any mechanism to let the app know that it could try again with more success?

[iCollin]

I think the last part of this sentence is missing.

Perhaps I should move Core after either, this was my intended communication:

Currently, if an app requests a protected session while SDL Core does not have a valid certificate the request will be pending until Core either
a. is able to retrieve a valid certificate through PTU or
b. if the whole PTU retry sequence fails.

I think that "it will take quite a while" should state "it may take quite a while".

I agree.

Currently there is no mechanism to let an app know when a PTU completes successfully. I could see a new notification such as OnCertificateUpdated being useful even without this proposal.

[Jack-Byrne]

3. I agree we could add this new type of notification in this proposal. The goal of this proposal is to improve the handshake process for encrypted services. @joeygrover's comment highlights another potential improvement for the current handshake process. Having a callback notification on a successful cert update seems appropriate.

[joeljfischer]

1. I'm sorry, I understood the last part of that sentence "if the whole PTU retry sequence fails" as incomplete and missing the result. I see what was intended now.

[Jack-Byrne]

3. Instead of creating a new notification lets just add a new parameter to OnPermissionsChanged. Open to suggestions for the description.

    <function name="OnPermissionsChange" functionID="OnPermissionsChangeID" messagetype="notification" since="2.0">
        <description>Provides update to app of which policy-table-enabled functions are available</description>
        <param name="permissionItem" type="PermissionItem" minsize="0" maxsize="500" array="true" mandatory="true">
            <description>Change in permissions for a given set of RPCs</description>
        </param>
        <param name="requireEncryption" type="Boolean" mandatory="false" since="6.0"/>
+      <param name="encryptionReady" type="Boolean" mandatory="false" since="x.x">
+        <description>If true, encryption is ready. If false, encryption is not ready. If omitted, mobile assumes encryption ready.</description>
+        </param>
        
    </function>

[theresalech]

The Steering Committee voted to keep this proposal in review to allow for the conversation to continue on the open item 3. It was noted that there is no action needed for item 1, and the agreed upon revision for item 2 is to change "it will take quite a while" to "it may take quite a while" in the Motivation section of the proposal. 

[theresalech]

The Steering Committee voted to return this proposal for the following revisions: change "it will take quite a while" to "it may take quite a while" in the Motivation section, and add new encryptionReady parameter to OnPermissionsChange as outlined in this comment.