Re: [Acme] AD Review of draft-ietf-acme-email-smime-07

[Ryan Sleevi <[e-mail]>]

On Fri, May 29, 2020 at 1:08 PM Russ Housley <[e-mail]> wrote:
> >> ** What was the thinking behind the document status being informational?
> > I don't think there was much thought or discussion of this point. I am flexible. I think when I started it was not very clear how much support/interest there were in this, but I noticed more interest over time.
>
> I would like to see standards track.  I wonder what other in the ACME WG think.

With my acknowledged bias towards thinking about policies around CAs
trusted in my employer's products, I think Informational makes sense.

I mention this largely because work is still ongoing within the
broader CA/Root Store industry around establishing requirements around
the issuance and validation of S/MIME certificates, and it's not at
all inconceivable to think things may need to change or be adjusted to
be used within those PKIs. The issuance practices and required level
of validation / validation process are not as well or widely
established and documented, nor are the expectations across vendors as
consistent, and so it's difficult to see that there's a lot of
"running code" for this model, in terms of CAs or Root Stores.

It's also not inconceivable that this may be fine as-is. I'll be the
first to readily admit that while I've read the document, I've not
read it to a degree that I'd be fully comfortable allowing it for use
by CAs that I might delegate to. While I don't for a second think that
alone is somehow reasonable to suggest Informational, when I look at
the broader sector of folks who have engaged within ACME on the draft,
I don't see a a wide variety of participants on the list or in the
minutes, and that makes me think that the lack of detailed review by
existing industry implementers may be a bit more wide-spread.

At the end of the day, I take the view that the question about whether
this provides "sufficient" assurance is going to be situational; it
depends on the needs and policies of the mail provider, the CAs, the
relying parties, MTAs, and root stores. That may be reason to think of
this on the "Experimental" or "Informational" spectrum, or it may be
that folks believe the particular mechanism is well-specified enough
that it deserves to be on the "Standards" track, and whether or not
parties implement or adopt that standard is entirely orthogonal.

Given that this spec describes a very specific method of providing
assurance, and not just a general protocol for assurance
establishment, I do lean towards Informational/Experimental.