Re: [Jmap] Review: draft-ietf-jmap-smime-02

[Alexey Melnikov <[e-mail]>]

Hi Bron,

Sorry for missing replying to your message!

On 08/07/2020 13:41, Bron Gondwana wrote:
> Hi Alexey,
>
> Here's a review of the latest smime document.
>
> *Specific Sections:**
> *
>
> 3.  Addition to the capabilities object
>
> Are you happy to use the 'smime' name for just this part rather than 
> "urn:ietf:params:jmap:smimeverify" or something?
That would be fine with me. Can I use "-" :-), e.g. 
"urn:ietf:params:jmap:smime-verify"?
> 4.  Extension to Email/get for S/MIME signature verification
>   smimeStatus: "String|null".
>     Servers MAY return other values not defined below.  Client
>     MUST treat unrecognized values as "unknown" or "signed/failed".  Note
>     that the value of this property might change over time.
>
> Does this need a registry of possible values?
I am ambivalent and open to suggestions on this. My implementation also 
has "encrypted+signed/failed" and "encrypted+signed/verified", but this 
is for cases when messages are both encrypted and signed (and can be 
decrypted, which is not covered by this document).
> In all other cases
>     it is set to the date and time of when S/MIME signature was verified
>     the last time.
>
> I would phrase this as "was most recently verified".  I had to 
> re-parse it because of the two different uses of "time" in the sentence.
I used your suggested text, thank you.
> As recalculating
>     these values is expensive for the server they MAY be cached for up to
>     10 minutes from the moment when they were calculated.
>
> Do we need a way to tell the server that a fresh calculation is 
> required and it must not use its cache?
In -05 the value is automatically recalculated after 10 minutes. Is this 
sufficient? Also, is 10 mins a good default for caching this value?
>
> Examples:
>
> Some of the JSON keys are missing quotes around them.
Fixed in -06.
> 5.  Open Issues
>
> From my memory, the issue here is allowing a query "did you verify 
> this message as being correctly signed in the past, and if so when?".  
> That's really useful when looking back at old emails!  I would like to 
> see that feature, but I'm also not likely to be a heavy user of this 
> feature, so I think feedback from people who use S/MIME is best on that.
-05 has "smimeStatusAtDelivery", which is almost doing what you ask. I 
think it is sufficient. Do you agree?
>
> I think I would just want a single value 
> smimeLastSuccessfulVerification: "UTCDate|null".  Which raises another 
> issue, and I'm not sure if this is an issue with the language in the 
> other specs referenced or specific to this one.
>
> The word "VERIFIED" is used with two different meanings in this 
> document.  IT's used in 'smimeVerifiedAt' to mention a time when a 
> check was done, and it's used in 'signed/verified' to refer to a 
> SUCCESSFUL verification.  These are not the same thing, and I'd be 
> keen to see a different word used for one of them.  "signed/valid" for 
> example.
I would rather not change returned string values, as I already 
implemented them. Maybe change 'smimeVerifiedAt' to 'smimeValidatedAt' 
instead?
>
> *General comments:**
> *
>
> Should we also extend Email/query to have a couple more filters - 
> `hasSmime` and `hasVerifiedSmime` are the two I can think of. - where 
> hasSmime is any status other than NULL, while hasVerifiedSmime is only 
> the value "signed/verified".
Hmm, sound like a good idea. I think this will be used, so I am happy to 
add.

Best Regards,

Alexey