Re: [Acme] Fwd: New Version Notification for draft-biggs-acme-sso-00.txt
On Wed, Dec 9, 2020 at 12:00 PM Richard Barnes wrote: > Hi ACME folks, > > I'd like to bring this proposed extension to ACME to the attention of the > working group. This work builds on Alexei's document defining the "email" > identifier type, and defines > > (1) a mechanism for validating email addresses using SSO, > Apologies for pedantry here, but is this really validating e-mail addresses? It seems like it's delegating validation to an IDP? This might be more of a "Web PKI" semantic quibble, and I understand your plan is to *not* use such CAs and might be moot, but it seems an important enough distinction to call out. That is, as I understand it, the domain holder indicates an SSO IDP that the CA may trust assertions for. The CA then directs the Applicant to authenticate with the IDP, and the IDP returns an assertion to the CA. The CA then accepts that assertion, provided that the global-part (dot-atom) matches, right? The validation isn't of an e-mail address; the validation is of an IDP declaring that e-mail address associated with a given account (e.g. a JWT, a SAML assertion, etc). Note: Is referencing dot-atom correct, in this case, since rfc822Name is restricted to preferred name syntax by virtue of the dependency on RFC 2821, as constrained by Section 2.3.5 ( https://tools.ietf.org/html/rfc2821#section-2.3.5 ) > and (2) some CAA mechanisms to manage issuance of certificates with email > addresses. > Did I miss a normative dependency on / informative reference to RFC 8657 here? It seems relevant, since this is repurposing the parameter space that is CA specific (as called out by https://tools.ietf.org/html/rfc8657#section-6 ), and there's explicitly no IANA registry to deconflict because of that. I realize that the parameters are also specific to the tag, which you're defining a new tag here, but this all seems... messy? That is, to have "validationmethods" semantics not depend on the CA (as it does for issue/issuewild) but instead depend on whether it's issue vs issue-email. > I would like for the ACME WG to take this on as a work item, as a logical > next step following on draft-ietf-acme-email-smime. Any feedback on the > draft would be very welcome. > I'm hesitant as to whether this is a good idea, because this seems like a significant shift in the level of assurance / what's validated, so I don't think it's as clear a logical next step. While I don't plan to implement (and would be opposed to implementing for trusted S/MIME CAs, for example), I acknowledge it has interest for other use cases, and so would be supportive of adopting in order to continue refining the security considerations to be more explicit that validation is being delegated to a third-party, rather than performed by the CA. > > Thanks, > --Richard > > > -- Forwarded message - > From: > Date: Tue, Dec 8, 2020 at 10:09 AM > Subject: New Version Notification for draft-biggs-acme-sso-00.txt > To: Andrew Biggs , Richard L. Barnes > > > > A new version of I-D, draft-biggs-acme-sso-00.txt > has been successfully submitted by Richard Barnes and posted to the > IETF repository. > > Name: draft-biggs-acme-sso > Revision: 00 > Title: Automated Certificate Management Environment (ACME) > Extension for Single Sign On Challenges > Document date: 2020-12-08 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/archive/id/draft-biggs-acme-sso-00.txt > Status: https://datatracker.ietf.org/doc/draft-biggs-acme-sso/ > Html: > https://www.ietf.org/archive/id/draft-biggs-acme-sso-00.html > Htmlized: https://tools.ietf.org/html/draft-biggs-acme-sso-00 > > > Abstract: >This document specifies an extension to the ACME protocol [RFC8555] >to enable ACME servers to validate a client's control of an email >identifier using single sign-on (SSO) technologies. An extension to >the CAA [RFC8659] resource record specification is also defined to >provide domain owners a means to declare a set of SSO providers that >ACME servers may rely upon when employing SSO for identifier >validation on their domain. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme subdomains open items
On Tue, Dec 8, 2020 at 8:14 PM Michael Richardson wrote: > > Alas, I'm equally at a loss to understand what you're asking here, > as I > > can't make much sense of your question? > > dns-01 challenges for bar.bar.foo.example do not have to show control over > foo.example. > Yet, you seem to think that they do. > Thanks for being clear! To respond: No, I don't. I'm highlighting that for a requested identifier of "baz.bar.foo.example", the CA is permitted to challenge for "bar.foo.example" or "foo.example". Indeed, some CAs, by default, will *only* challenge for "foo.example", despite that being a parent of the requested domain, because they want to reduce the effort involved to issue other certificates to that user. Now, I never said a CA "has" to, but it's certainly true that a number of CAs do, in fact, require this as their standard operating procedure, and my understanding is that this proposal was specifically about enabling such cases within ACME. That is, more generally, making a clear and well-lit path where the domain used in the authorization does not match the domain in the certificate. Is that an unreasonable understanding? It seems directly supported in the text of the draft, Section 5.4, https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.4 , example 1. > > >> The client does not demonstrate control over lex.example using > dns-01 when > >> it > >> asks for so.me.comp.lex.example. > > > Is that not literally what this draft is proposing (e.g. > > > https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.2 ) ? > > It demonstrates control (during the authorization) for lex.example, which > allows it to fullfil orders for so.me.comp.lex.example. > > Your line of questioning implies you think the reverse. > 5.2 clearly shows authorization for example.org, followed by an order for > sub.example.com I am again at a loss for what you mean here / what you are attributing to me. Equally, I'm hoping that the "example.org" / "sub.example.com", as I cannot make any sense of what you said otherwise. As to your statement about me thinking the reverse, I'm hoping you can perhaps rephrase the following paragraph in Section 5.1: It may make sense to use the ACME pre-authorization flow for the subdomain use case, **however, that is an operator implementation and deployment decision.** With the ACME pre-authorization flow, the client could pre-authorize for the parent domain once, and then issue multiple newOrder requests for certificates for multiple subdomains. With the section in emphasis (**), it seems clear that this draft is not prescriptive as to whether the example in Section 5.2 (the "pre-authorization flow") needs to be required. To try to be clearer, since it seems you and I may be talking past each other and have been for some time, I'm considering the following flow: - POST /newOrder "so.me.comp.lex.example" Where the server needs to determine the appropriate set of authorizations to return for this case and the set of challenges within those authorizations. Again, this seems directly supported by Section 5.4 of the draft, https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.4 , example 1. > > In the pre-auth flow, the client affirmatively requests > "lex.example" (In > > the illustration here, "example.org"), in order to authorize > > "so.me.comp.lex.example" (in the illustration here, "sub.example.org > "). > > That is, the client explicitly declares their naming scope. > > > However, in the pre-auth flow, you have to know that the client will > want > > to be able to /newOrder for "sub.example.org" (as Step 2 in the > > illustration), since you shouldn't return http-01 authorizations in > Step 1 > > for this case. > > how are http-01 authorizations involved? > The client asks for dns-01 authorizations. Can you point me to the text in the draft you're using to support this statement? As far as I can tell, there's nothing in the draft to indicate that the client asks for dns-01 authorizations. Further, there's nothing as far as I can tell that prohibits, restricts, or even allows a CA to indicate that an http-01 authorization would not be allowed. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Fwd: New Version Notification for draft-biggs-acme-sso-00.txt
Hi ACME folks, I'd like to bring this proposed extension to ACME to the attention of the working group. This work builds on Alexei's document defining the "email" identifier type, and defines (1) a mechanism for validating email addresses using SSO, and (2) some CAA mechanisms to manage issuance of certificates with email addresses. I would like for the ACME WG to take this on as a work item, as a logical next step following on draft-ietf-acme-email-smime. Any feedback on the draft would be very welcome. Thanks, --Richard -- Forwarded message - From: Date: Tue, Dec 8, 2020 at 10:09 AM Subject: New Version Notification for draft-biggs-acme-sso-00.txt To: Andrew Biggs , Richard L. Barnes A new version of I-D, draft-biggs-acme-sso-00.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Name: draft-biggs-acme-sso Revision: 00 Title: Automated Certificate Management Environment (ACME) Extension for Single Sign On Challenges Document date: 2020-12-08 Group: Individual Submission Pages: 12 URL:https://www.ietf.org/archive/id/draft-biggs-acme-sso-00.txt Status: https://datatracker.ietf.org/doc/draft-biggs-acme-sso/ Html: https://www.ietf.org/archive/id/draft-biggs-acme-sso-00.html Htmlized: https://tools.ietf.org/html/draft-biggs-acme-sso-00 Abstract: This document specifies an extension to the ACME protocol [RFC8555] to enable ACME servers to validate a client's control of an email identifier using single sign-on (SSO) technologies. An extension to the CAA [RFC8659] resource record specification is also defined to provide domain owners a means to declare a set of SSO providers that ACME servers may rely upon when employing SSO for identifier validation on their domain. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
