search

letsencrypt / boulder

An ACME-based certificate authority, written in Go.
Mozilla Public License 2.0
5.17k stars 604 forks source link

What contact types are accepted (currently)? What contact types are valid? #5209

Closed systemcrash closed 3 years ago

systemcrash commented 3 years ago

RFC 8555 is clear that mailto: support is a must, 

   The server SHOULD validate that the contact URLs in the "contact"
   field are valid and supported by the server.  If the server validates
   contact URLs, it MUST support the "mailto" scheme.  Clients MUST NOT
   provide a "mailto" URL in the "contact" field that contains "hfields"
   [RFC6068] or more than one "addr-spec" in the "to" component.  If a
   server encounters a "mailto" contact URL that does not meet these
   criteria, then it SHOULD reject it as invalid.

   If the server rejects a contact URL for using an unsupported scheme,
   it MUST return an error of type "unsupportedContact", with a
   description of the error and what types of contact URLs the server
   considers acceptable.  If the server rejects a contact URL for using
   a supported scheme but an invalid value, then the server MUST return
   an error of type "invalidContact".

but lists contact type as a string array. This could conceivably contain:

tel:...... sip:..... http:...... https:......

A quick search shows that test cases only cover mailto: since those are the most convenient and trivial to notify a user of pending expiry. Are the above+others permissible?

RFC just suggests mailto:

https://tools.ietf.org/html/rfc8555#section-7.3

https://tools.ietf.org/html/rfc8555#section-7.1.2

   contact (optional, array of string):  An array of URLs that the
      server can use to contact the client for issues related to this
      account.  For example, the server may wish to notify the client
      about server-initiated revocation or certificate expiration.  For
      information on supported URL schemes, see Section 7.3.

It feels like valid and accepted are conflated and left up to implementation.

But this implementation only seems to handle and test for mailto:

https://github.com/letsencrypt/boulder/blob/2d14cfb8d1bc56e70e61f8d50d8f5a150e9b6c1d/sa/satest/satest.go#L42

Do other ACME providers support other contact URL types (schemes)?

systemcrash commented 3 years ago

Worth noting:

https://github.com/letsencrypt/boulder/blob/2d14cfb8d1bc56e70e61f8d50d8f5a150e9b6c1d/docs/acme-divergences.md#section-67

aarongable commented 3 years ago

Boulder does not support schemes other than mailto:: https://github.com/letsencrypt/boulder/blob/beee17c510c20fc3a454a554c71a7e86b77d4ffd/ra/ra.go#L397-L399

As you noted, mailto: is the only scheme which MUST be supported per RFC8555, and we have no intentions to widen the scope of valid contact addresses at this time.