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

Alexey Melnikov <> Thu, 15 July 2021 10:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6411E3A2543 for <>; Thu, 15 Jul 2021 03:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.305
X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FX8_UPp2QQCZ for <>; Thu, 15 Jul 2021 03:02:06 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 2B4583A254E for <>; Thu, 15 Jul 2021 03:02:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1626343324;; s=june2016;; bh=dK2EofkkSdowUUwHhIsROIAUAbwaY1m2bvLMb4nfxD8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gnn95SUpW3wfB0pbJnt9GTYAxFuowlRIw1bc7kMfwCGBbPszsNzyDWv0Ebxo3t2r1pP1Pu 0ehy87j0Ph63VcqAy0zC8uP57ZB2zHix0TI6FismT/BghhCIY92c5IvYrPvTeW3skFrkOT bJ4WqchrH7hp4Za6Z8s1gsVmLmPY/XE=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Thu, 15 Jul 2021 11:02:03 +0100
To: Bron Gondwana <>,
References: <>
From: Alexey Melnikov <>
Message-ID: <>
Date: Thu, 15 Jul 2021 11:01:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------1A9E788205B8F4933B9296FB"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Jmap] Review: draft-ietf-jmap-smime-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Jul 2021 10:02:21 -0000

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. 
> 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' 
> *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 

Best Regards,