[Smcwg-public] Methods for email verification

Stephen Davidson Stephen.Davidson at digicert.com
Tue Feb 23 23:26:33 UTC 2021


Thanks for the feedback.



Yes I wrote that section intending a mailbox re-verification at each cert 
issuance.



But I appreciate the arguments in favor of having a re-use period for that 
first verification, particularly in cases where certs may be periodically 
reissued, or when multiple certs are to be issued at the same time (as in the 
case of split signing and encryption certs).



I will adapt that proposed text.



As you may have noticed in Doug’s email, we have now made the draft SMIME BR 
public at https://github.com/srdavidson/smime/tree/PreSBR in a “PreSBR” 
branch, which you can view or Watch.  It’s in active development now and this 
will be the working version of the SBR; it will be pulled into the cabf-smime 
repository later when the dust settles.



Best regards, Stephen





From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Doug 
Beattie via Smcwg-public
Sent: Tuesday, February 23, 2021 12:48 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; Dimitris Zacharopoulos 
(HARICA) <dzacharo at harica.gr>; SMIME Certificate Working Group 
<smcwg-public at cabforum.org>; Wendy Brown - QT3LB-C <wendy.brown at gsa.gov>
Subject: Re: [Smcwg-public] Methods for email verification



Tim – I Agree.



My initial question that started this thread was asking about this statement 
in section 3.2.2.2.2: 
https://github.com/srdavidson/smime/blob/PreSBR/SBR.md#32222--validating-control-over-email-address-via-email

*	Completed validations of Applicant control over the email address must be 
performed for each Certificate issuance.

This sounds like you can’t re-use the email box validation at all, so I wanted 
to see if we can clarify that.  We don’t have the same statement in the prior 
section 3.2.2.2.1 
https://github.com/srdavidson/smime/blob/PreSBR/SBR.md#32221--validating-authority-over-email-address-via-domain 
and assume normal re-use of domain validation applies there.



Wendy Brown asked a similar question to see if they same validation can be 
used for issuance of 2 certs (signing and encryption).  If we take the words 
in 3.2.2.2.2 literally, the answer is no.



If we remove that line in the spec, then both question are resolved, but does 
issuing a second cert to the same email address WITHOUT verifying the email 
address reduce security?  In all cases of domain/email validation re-use, you 
must make sure it’s the same subscriber.  This might be done via sending an 
email (most logical and surely compliant), but there may be service providers 
that host and are the Applicant/Subscriber on behalf of the owner of the 
mailbox. Does the mail box owner need to click a link every time the service 
provider creates a new cert for them?  When the Enterprise does not want to 
hand over full control to issue certs for ALL mailboxes within that domain, it 
needs to be done at the mail box level with the mail box owner in the loop. 
Permitting re-use of the email box level validation provides some value.



Doug





From: Tim Hollebeek <tim.hollebeek at digicert.com 
<mailto:tim.hollebeek at digicert.com> >
Sent: Tuesday, February 23, 2021 11:30 AM
To: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr 
<mailto:dzacharo at harica.gr> >; SMIME Certificate Working Group 
<smcwg-public at cabforum.org <mailto:smcwg-public at cabforum.org> >; Wendy Brown - 
QT3LB-C <wendy.brown at gsa.gov <mailto:wendy.brown at gsa.gov> >; Doug Beattie 
<doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> >
Subject: RE: [Smcwg-public] Methods for email verification



Right, we should follow the CABF validation reuse rules.  I.e. as long as they’re 
both issued within the validation reuse timeframe, the second can reuse the 
first’s validation.



One of the annoying things is that CABF policies and traditional PKI policies 
say basically the same thing in two different ways.



Traditional PKIs have no provisions for reuse of validation, but define 
issuance categories like “renewal” and “replacement” that have pared-down 
validation and issuance rules based on the existence of a previously issued 
certificate with the same validated information.



CABF PKIs forbid “renewal”, etc and treat everything as a new issuance, but 
have validation reuse requirements that in practice … tend to have exactly the 
same effect.  You can renew (etc) a certificate without having to completely 
redo the validation for previously validated information.



It’s mostly just tomayto tomahto, but it is a pain for PKIs that span both 
worlds.



-Tim



From: Smcwg-public <smcwg-public-bounces at cabforum.org 
<mailto:smcwg-public-bounces at cabforum.org> > On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Smcwg-public
Sent: Sunday, February 21, 2021 5:17 AM
To: Wendy Brown - QT3LB-C <wendy.brown at gsa.gov <mailto:wendy.brown at gsa.gov> >; 
SMIME Certificate Working Group <smcwg-public at cabforum.org 
<mailto:smcwg-public at cabforum.org> >; Doug Beattie 
<doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> >
Subject: Re: [Smcwg-public] Methods for email verification





On 18/2/2021 6:25 μ.μ., Wendy Brown - QT3LB-C via Smcwg-public wrote:

also could a single validation of the email address be used for issuance of 
both the signature & encryption certs in the case of the dual certs vs single 
cert case?



That makes perfect sense to me.

Validations in general should be allowed to be reused as it is allowed in 
other Certificate types.


Dimitris.

Wendy

Wendy Brown
Supporting GSA FPKI
Protiviti Government Services

 703-965-2990 (cell)

 <mailto:wendy.brown at gsa.gov> wendy.brown at gsa.gov
wendy.brown at protiviti.com <mailto:wendy.brown at protiviti.com>





On Thu, Feb 18, 2021 at 10:54 AM Doug Beattie via Smcwg-public 
<smcwg-public at cabforum.org <mailto:smcwg-public at cabforum.org> > wrote:

Hi Stephen,



I’m not sure I agree with this statement in section 3.2.2.2.2 Validating 
control over email address via email



*	Completed validations of Applicant control over the email address must be 
performed for each Certificate issuance.



I’d like to permit re-use of that validation over and over for the re-use 
period for that subscriber if possible.  Is there a reason we preclude that? 
For example, an email gateway provider might validate this email address and 
then want to replace certificates more frequently than 397 days, but this 
would require emails to the email box to act on that.



Doug





From: Smcwg-public <smcwg-public-bounces at cabforum.org 
<mailto:smcwg-public-bounces at cabforum.org> > On Behalf Of Stephen Davidson via 
Smcwg-public
Sent: Wednesday, February 17, 2021 6:02 PM
To: SMIME Certificate Working Group <smcwg-public at cabforum.org 
<mailto:smcwg-public at cabforum.org> >
Subject: [Smcwg-public] Methods for email verification



Hello all:



Following our discussion on the call today, I attach draft text for section 
3.2.2.2 of the SMIME BR (SBR) that deals with 1) Validating authority over 
email address via domain and 2) Validating control over email address via 
email.



It aims to fulfill the requirements of the Mozilla policy.  It includes 
comments with some questions that require further discussion.  Additional 
methods can be addressed in future versions of the SBR.



Many thanks for Doug and Sebastian at GlobalSign for their help in drafting 
this.  We’ll discuss this in a future meeting, but feel free to also provide 
feedback here.



Many thanks, Stephen

_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org <mailto:Smcwg-public at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/smcwg-public



_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org <mailto:Smcwg-public at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/smcwg-public



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20210223/68ab00b9/attachment-0001.html>


More information about the Smcwg-public mailing list