Re: [lamps] [EXTERNAL] Re: CAA processing for email addresses

On Sun, Dec 4, 2022 at 4:24 PM Corey Bonnell <Corey.Bonnell=
40digicert.com@dmarc.ietf.org> wrote:

> Hi Antonios,
>
> Thanks for your comments. Responses inline.
>
>
>
>    - Perhaps “mailissue” or “mail” is better (explained in the thread) or
>    even “smime”. This allows for “smimeentity” and “smimeserver” for example,
>    if there’s a future need for that.
>
>
>
> I follow your logic in your previous message and think we should settle on
> a common convention in our two drafts. I’m partial to including a verb in
> the property tag to disambiguate the tag from other property tags that may
> be relevant to the specific certificate type but not specify any
> restrictions on the set of CAs that can issue. Additionally, I think
> there’s value in retaining the “verb-object” tag-naming convention
> established by RFC 6844/8659 with “issuewild”. Otherwise, there will be
> inconsistency in naming depending on the certificate type.
>

Is there a reason the tags are not tied to the Key Usage of the certs?
In particular for S/MIME, you may need to consider certificates only issued
for digital signature and others only for encryption.

>
>    - I don’t know if I would make this critical
>
>
>
> I agree with you and Phillip that this tag shouldn’t be critical by
> default. I’ll clarify this point in an update to the draft in the next few
> days.
>

>    - In terms of adoption, I would like to see CAA for S/MIME, and this
>    is a good and simple way to achieve it.
>
>
>
> I also see CAA for IP addresses as valuable for the ecosystem as well. I
> plan to give your draft a fuller read shortly and will follow up with any
> comments.
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From:* Antonios Chariton <daknob.mac@gmail.com>
> *Sent:* Friday, December 2, 2022 10:51 AM
> *To:* spasm@ietf.org
> *Cc:* Corey Bonnell <Corey.Bonnell@digicert.com>
> *Subject:* Re: [lamps] [EXTERNAL] Re: CAA processing for email addresses
>
>
>
> I think that CAA for S/MIME is useful, and can help enforce policies for
> an enterprise, and even for large e-mail providers (although probably not
> for their main domain gmail.com / hotmail.com / etc.). I participate here
> on my personal capacity and won’t speak on behalf of Gmail.
>
>
>
> Two things I’d maybe consider, one of which is described in my thread[1]
> too:
>
>
>
> - Perhaps “mailissue” or “mail” is better (explained in the thread) or
> even “smime”. This allows for “smimeentity” and “smimeserver” for example,
> if there’s a future need for that.
>
>
>
> - I don’t know if I would make this critical
>
>
>
> Marking this as critical will require all CAs (at least) to build support
> for it, otherwise its presence will block issuance of TLS certificates. My
> suggestion is to make this non-critical (as it is not necessary to use CAA
> for this domain at all), and then require parsing of CAA “mail” (or
> whatever) properties in the requirements that include this doc. In this
> case, it can be the CA/B Forum BRs. If they specify that CAs MUST follow /
> understand / support / conform to … RFCXXXX then you achieve the
> criticality in the publicly trusted space, without breaking all CAA
> implementations in the meantime.
>
>
>
> I would argue that this property is not critical for a CA that does not
> issue S/MIME certs, and in my view the critical flag is for things
> necessary for all CAA uses, not just one.
>
>
>
> In terms of adoption, I would like to see CAA for S/MIME, and this is a
> good and simple way to achieve it. The lack of Certificate Transparency in
> the space will make it more difficult to detect misissuance /
> non-conformity, but when detected it would make it hopefully easier to
> prove. Without speaking on behalf of any Root Program, I imagine this would
> help many stakeholders in the S/MIME ecosystem.
>
>
>
> Antonis
>
>
>
>
>
> 1:
> https://mailarchive.ietf.org/arch/msg/spasm/dQLF1fQQPNX9A59YV4imXRz9ABw/
>
>
>
> On 1 Dec 2022, at 22:42, Phillip Hallam-Baker <phill@hallambaker.com>
> wrote:
>
>
>
> But this is not a proposal that would be relevant to Mail Service
> Operators like Gmail or Hotmail.
>
>
>
> It is only relevant to enterprises running mail services under their own
> DNS name. Outsourcing that to a mail service provider would not impact the
> use of CAA or S/MIMe in the slightest.
>
>
>
>
>
> On Thu, Dec 1, 2022 at 3:02 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>
>
> On 01/12/2022 18:46, Phillip Hallam-Baker wrote:
> > I support adoption of this draft.
>
> In the absence of mail service operators who say they want
> this, I'm against adoption. (If this does originate in CAB
> forum, I'm not aware folks like that are represented there.)
>
> If some mail service operators wanted this, I'd consider what
> they said.
>
> S.
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>