[Acme] Concerning alternative formats …

[Felipe Gasper]

For what it’s worth:

Regarding alternative formats, I think ACME over WebSocket would be a great 
thing. Replay-nonce would go away, and clients wouldn’t need to poll for the 
certificate unless the connection dropped. The server could send the 
certificate as soon as it’s ready. A simple handshake at the start could take 
the place of JWS, too.

-F

> On Mar 5, 2018, at 12:02 AM, Martin Thomson  wrote:
> 
> Unless you believe that an alternative format is ever desirable.  CBOR
> for version 2 might be a terrible idea, but I know the IETF well
> enough not to rule that out entirely.
> 
> On Mon, Mar 5, 2018 at 3:38 PM, Richard Barnes  wrote:
>> I also note that there's no issue with Accept if we require the use of the
>> Flattened JSON serialization.
>> 
>> https://i.imgflip.com/25r2ui.jpg
>> 
>> https://github.com/ietf-wg-acme/acme/pull/410
>> 
>> On Sun, Mar 4, 2018 at 6:28 PM, Martin Thomson 
>> wrote:
>>> 
>>> That's a bit silly.  I'll follow-up with httpbis.  I think that's an
>>> error, though probably only an error of omission.  7694 was so fixated
>>> on solving the content-coding issue, it neglected the obvious
>>> accompanying fix.
>>> 
>>> On Mon, Mar 5, 2018 at 9:38 AM, Richard Barnes  wrote:
 How about Accept?  It looks like 7694 gives the server a way to specify
 encodings, but not the content type.  But 7231 says that Accept only
 replies
 to response media types.
 
 On Sun, Mar 4, 2018 at 5:33 PM, Martin Thomson
 
 wrote:
> 
> 415 is for the case where a client provides bad request content, so
> yes.
> See rfc7694 for details.
> 
> 406 is for failed conneg. Not something you expect to see much here.
> 
> 
> On 5 Mar. 2018 09:25, "Richard Barnes"  wrote:
> 
> The lengths of the emails in this thread illustrate the complexity risk
> here :)
> 
> In the interest of simplicity, I would really like to stick to
> Flattened
> JSON unless someone has **strong** objections.
> 
> Logan, to your point about library compatibility, two notes: (1) it's
> OK
> if we front-run libraries a little.  It's not hard for libraries to
> upgrade;
> this is only formatting, no crypto changes needed.  (2) Empirically,
> this
> must not be too big a blocker for people, since as Jacob notes, Let's
> Encrypt only supports Flattened JSON right now and they've got a bunch
> of
> clients talking to them.
> 
> As far as headers / response codes: You're correct that 406 is wrong /
> 415
> is right.  But ISTM that Accept is still the right header to say what
> is
> right.  So the server should return 415+Accept.  Copying Thomson to
> check
> our work here.
> 
> --Richard
> 
> On Sun, Mar 4, 2018 at 10:43 AM, Logan Widick 
> wrote:
>> 
>> How about this: Specify a default format (either "application/jose"
>> for
>> Compact Serialization, or "application/jose+json" with Flattened
>> Serialization - I have no preference which one), with optional support
>> for
>> other formats if needed? Even with JOSE libraries that don't support
>> all
>> serializations and/or don't provide control over which serialization
>> is
>> used, a programmer would at least need to know (or experimentally find
>> out)
>> if a JSON serialization or if the compact one is being produced. If a
>> JSON
>> serialization is selected as the default, a programmer should be able
>> to
>> convert between the two JSON serializations easily as needed before
>> and/or
>> after using a JOSE library. If a JSON format is declared as the
>> default but
>> the JOSE library only has the compact one, or vice-versa, conversion
>> before
>> and/or after the JOSE library would be more complex but should still
>> be
>> doable with guidance.
>> 
>> The directory meta item could be defined as something like:
>> 
>> supportedSerializations: An array of supported serialization formats
>> as
>> described in {{jws-serialization-formats}}. If this is not specified,
>> assume
>> that the server only supports [insert selected default here].
>> 
>> Then, the JWS Serialization Formats section could be changed to
>> something
>> like the following:
>> 
>> The JSON Web Signature (JWS) specification {{!RFC7515}} contains
>> multiple
>> JWS serialization formats. When sending an ACME request with a
>> non-empty
>> body, an ACME client implementation SHOULD use the HTTP Content-Type
>> {{!RFC7231}} header to indicate which JWS serialization format is used
>> for
>> encapsulating the ACME request payload.
>> 
>> Each serialization format defined for use in ACME is described with a
>> content type, and a series of ACME-specific restrictions on root JWS
>> and
>> nested JWS instances.  A "root JWS" is a J

Re: [Acme] Explicitly forbid to answer GET requests for account info

[Daniel McCarney]

Thanks Joern, merged.

On Sun, Mar 4, 2018 at 6:57 AM, Jörn Heissler 
wrote:

> Hi,
>
> another PR that slightly changes meaning (SHOULD NOT -> MUST NOT):
> https://github.com/ietf-wg-acme/acme/pull/407
>
> Section "Request Authentication" says:
> "Servers MUST NOT respond to GET requests for resources that might be
> considered sensitive. Account resources are the only sensitive resources
> defined in this specification."
>
> I agree with the "MUST NOT" here as account contains e.g. my contact data.
> Therefore section "Account Information" should also says "MUST NOT":
> "Servers MUST NOT respond to GET requests for account resources..."
>
> Cheers
> Joern Heissler
>
> ___
> 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] Concerning alternative formats …

[Jörn Heissler]

On Mon, Mar 05, 2018 at 09:11:02 -0500, Felipe Gasper wrote:
> Regarding alternative formats, I think ACME over WebSocket would be a great 
> thing. Replay-nonce would go away, and clients wouldn’t need to poll for the 
> certificate unless the connection dropped. The server could send the 
> certificate as soon as it’s ready. A simple handshake at the start could take 
> the place of JWS, too.

Moving to websocket would mean having to specify a new websocket based
protocol and reimplementing all servers/clients.
You'd also need to consider MitM (e.g. by CDN or expensive enterprise MitM
appliances). Doing a handshake at the beginning won't be enough to keep
those from taking over a session after the handshake.

If you wanted to eliminate the polling, it would be possible to change
the finalize endpoint to return the certificate directly, even if it
takes a while until the HTTP response is sent.

Anyway, I'm satisfied with the current protocol. Complexity should (and
can) be addressed by client implementors.


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Concerning alternative formats …

[Felipe Gasper]

> On Mar 5, 2018, at 9:35 AM, Jörn Heissler  
> wrote:
> 
> On Mon, Mar 05, 2018 at 09:11:02 -0500, Felipe Gasper wrote:
>> Regarding alternative formats, I think ACME over WebSocket would be a great 
>> thing. Replay-nonce would go away, and clients wouldn’t need to poll for the 
>> certificate unless the connection dropped. The server could send the 
>> certificate as soon as it’s ready. A simple handshake at the start could 
>> take the place of JWS, too.
> 
> Moving to websocket would mean having to specify a new websocket based
> protocol and reimplementing all servers/clients.

I would think “ACME/bidi” could live alongside ACME/HTTP. The bidirectional 
variant could be described in a separate RFC that gives the differences--which 
would basically just be how to translate the HTTP-specific parts of ACME/HTTP 
to “pure messages”.

WebSocket wouldn’t necessarily be the only persistent-connection format; any 
reliable, message-oriented protocol (e.g., SCTP or WAMP “RawSocket”) could work.

> You'd also need to consider MitM (e.g. by CDN or expensive enterprise MitM
> appliances). Doing a handshake at the beginning won't be enough to keep
> those from taking over a session after the handshake.
> 
> If you wanted to eliminate the polling, it would be possible to change
> the finalize endpoint to return the certificate directly, even if it
> takes a while until the HTTP response is sent.

This would alleviate the polling for the certificate but not for authz status. 
If I have an Order with, say, 5 authzs, I’ll still need to poll for the state 
of those.

A transport layer that allows asynchronous server-to-client communication would 
facilitate quicker feedback to the client and a smoother user experience 
overall. 

-F
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Concerning alternative formats …

[Matthew D. Hardeman]

My working experience is primarily outside the PKI space, but I can offer some 
perspectives on scalability and deployment architecture issues.

WebSocket is entirely appropriate for real-time or near-real-time bidirectional 
communications of an asynchronous nature.

The overhead of WebSocket as a pure transport for the various ACME messages 
back and forth between the client and the server could be done, but would any 
server side implementation ever take full advantage with the appropriate async 
callbacks to actually achieve faster certificate delivery.

Especially with CT logging being a pragmatic requirement, time-to-delivery for 
certificates is likely to increase (slightly) rather than decrease.

In the kind of pattern that getting a certificate represents it seems WebSocket 
would add significant overhead without a lot of performance advantage.

If the content and nature of the messages would change based on WebSocket used 
as a transport, then you’ve got a whole new set of threats to model and 
consider.

Perhaps before going down that road, it would be useful to poll server-side 
implementers and deployers and see if there’s interest in a WebSocket delivery 
channel.


> On Mar 5, 2018, at 8:11 AM, Felipe Gasper  wrote:
> 
> For what it’s worth:
> 
> Regarding alternative formats, I think ACME over WebSocket would be a great 
> thing. Replay-nonce would go away, and clients wouldn’t need to poll for the 
> certificate unless the connection dropped. The server could send the 
> certificate as soon as it’s ready. A simple handshake at the start could take 
> the place of JWS, too.
> 
> -F
> 
>> On Mar 5, 2018, at 12:02 AM, Martin Thomson  wrote:
>> 
>> Unless you believe that an alternative format is ever desirable.  CBOR
>> for version 2 might be a terrible idea, but I know the IETF well
>> enough not to rule that out entirely.
>> 
>> On Mon, Mar 5, 2018 at 3:38 PM, Richard Barnes  wrote:
>>> I also note that there's no issue with Accept if we require the use of the
>>> Flattened JSON serialization.
>>> 
>>> https://i.imgflip.com/25r2ui.jpg
>>> 
>>> https://github.com/ietf-wg-acme/acme/pull/410
>>> 
>>> On Sun, Mar 4, 2018 at 6:28 PM, Martin Thomson 
>>> wrote:
 
 That's a bit silly.  I'll follow-up with httpbis.  I think that's an
 error, though probably only an error of omission.  7694 was so fixated
 on solving the content-coding issue, it neglected the obvious
 accompanying fix.
 
 On Mon, Mar 5, 2018 at 9:38 AM, Richard Barnes  wrote:
> How about Accept?  It looks like 7694 gives the server a way to specify
> encodings, but not the content type.  But 7231 says that Accept only
> replies
> to response media types.
> 
> On Sun, Mar 4, 2018 at 5:33 PM, Martin Thomson
> 
> wrote:
>> 
>> 415 is for the case where a client provides bad request content, so
>> yes.
>> See rfc7694 for details.
>> 
>> 406 is for failed conneg. Not something you expect to see much here.
>> 
>> 
>> On 5 Mar. 2018 09:25, "Richard Barnes"  wrote:
>> 
>> The lengths of the emails in this thread illustrate the complexity risk
>> here :)
>> 
>> In the interest of simplicity, I would really like to stick to
>> Flattened
>> JSON unless someone has **strong** objections.
>> 
>> Logan, to your point about library compatibility, two notes: (1) it's
>> OK
>> if we front-run libraries a little.  It's not hard for libraries to
>> upgrade;
>> this is only formatting, no crypto changes needed.  (2) Empirically,
>> this
>> must not be too big a blocker for people, since as Jacob notes, Let's
>> Encrypt only supports Flattened JSON right now and they've got a bunch
>> of
>> clients talking to them.
>> 
>> As far as headers / response codes: You're correct that 406 is wrong /
>> 415
>> is right.  But ISTM that Accept is still the right header to say what
>> is
>> right.  So the server should return 415+Accept.  Copying Thomson to
>> check
>> our work here.
>> 
>> --Richard
>> 
>> On Sun, Mar 4, 2018 at 10:43 AM, Logan Widick 
>> wrote:
>>> 
>>> How about this: Specify a default format (either "application/jose"
>>> for
>>> Compact Serialization, or "application/jose+json" with Flattened
>>> Serialization - I have no preference which one), with optional support
>>> for
>>> other formats if needed? Even with JOSE libraries that don't support
>>> all
>>> serializations and/or don't provide control over which serialization
>>> is
>>> used, a programmer would at least need to know (or experimentally find
>>> out)
>>> if a JSON serialization or if the compact one is being produced. If a
>>> JSON
>>> serialization is selected as the default, a programmer should be able
>>> to
>>> convert between the two JSON serializations easily as needed before
>>> and/or

Re: [Acme] Concerning alternative formats …

[Felipe Gasper]

> On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman  wrote:
> 
> Especially with CT logging being a pragmatic requirement, time-to-delivery 
> for certificates is likely to increase (slightly) rather than decrease.

Quick point: the alleviation of polling would go for authz status as well as to 
certificate delivery.

A certificate order that has 10 domains needs to poll for the status of all 10 
of those domains’ authorizations as well as the certificate issuance. 
“ACME/bidi” would remove all 11 of those needs to poll.

Thanks for those who have given this suggestion their consideration. I don’t 
mean to “gum up the gears” for the main ACME work, but as I’ve been writing 
ACME clients the polling stuff has stuck out to me like a sore thumb.

It’s worth noting, too, that concerns about overhead may be alleviated if we do 
get a usable WebSocket-over-HTTP/2 implementation. Or, maybe someone will 
expose an SCTP endpoint, or a raw TCP endpoint that implements a simple 
message-boundary layer. I think the question of pure-message, bidirectional 
transport is more relevant than a specific transport implementation.

-F
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Example requests

[Jacob Hoffman-Andrews]

On 03/04/2018 02:17 PM, Richard Barnes wrote:

> Hey Joern,
>
> This is a probably a good thing to have.  I think that rather than
> putting these in the main spec, it might be better to have them in a
> second draft.  This is a pretty common pattern.  For example, for TLS
> 1.3, there's a "test vectors" document separate from the main spec
> [0].  There are a few documents with example "call flows" for SIP
> [1][2].  ACME is probably somewhere in the middle of those two cases.
I agree; the test vectors are a good idea, and should be part of another
document.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Concerning alternative formats …

[Richard Barnes]

Thomson: Could h2 push replace some of the polling here?

On Mon, Mar 5, 2018 at 4:50 PM, Felipe Gasper 
wrote:

>
> > On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman 
> wrote:
> >
> > Especially with CT logging being a pragmatic requirement,
> time-to-delivery for certificates is likely to increase (slightly) rather
> than decrease.
>
> Quick point: the alleviation of polling would go for authz status as well
> as to certificate delivery.
>
> A certificate order that has 10 domains needs to poll for the status of
> all 10 of those domains’ authorizations as well as the certificate
> issuance. “ACME/bidi” would remove all 11 of those needs to poll.
>
> Thanks for those who have given this suggestion their consideration. I
> don’t mean to “gum up the gears” for the main ACME work, but as I’ve been
> writing ACME clients the polling stuff has stuck out to me like a sore
> thumb.
>
> It’s worth noting, too, that concerns about overhead may be alleviated if
> we do get a usable WebSocket-over-HTTP/2 implementation. Or, maybe someone
> will expose an SCTP endpoint, or a raw TCP endpoint that implements a
> simple message-boundary layer. I think the question of pure-message,
> bidirectional transport is more relevant than a specific transport
> implementation.
>
> -F
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Concerning alternative formats …

[Martin Thomson]

Sure.  Plenty of ways to do that.

If your primary concern is issuance, then you don't even need server
push, you can just long-poll.  In HTTP/1.1, that's gross because it
ties up a connection and has some disgusting keep-alive properties.
In h2 there is no opportunity cost to worry about, the connection
remains usable for other things while you wait.  (You can use
prefer:wait to control timing if you want a standards-based solution:
https://tools.ietf.org/html/rfc7240#section-4.3)

On Tue, Mar 6, 2018 at 9:27 AM, Richard Barnes  wrote:
> Thomson: Could h2 push replace some of the polling here?
>
> On Mon, Mar 5, 2018 at 4:50 PM, Felipe Gasper 
> wrote:
>>
>>
>> > On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman 
>> > wrote:
>> >
>> > Especially with CT logging being a pragmatic requirement,
>> > time-to-delivery for certificates is likely to increase (slightly) rather
>> > than decrease.
>>
>> Quick point: the alleviation of polling would go for authz status as well
>> as to certificate delivery.
>>
>> A certificate order that has 10 domains needs to poll for the status of
>> all 10 of those domains’ authorizations as well as the certificate issuance.
>> “ACME/bidi” would remove all 11 of those needs to poll.
>>
>> Thanks for those who have given this suggestion their consideration. I
>> don’t mean to “gum up the gears” for the main ACME work, but as I’ve been
>> writing ACME clients the polling stuff has stuck out to me like a sore
>> thumb.
>>
>> It’s worth noting, too, that concerns about overhead may be alleviated if
>> we do get a usable WebSocket-over-HTTP/2 implementation. Or, maybe someone
>> will expose an SCTP endpoint, or a raw TCP endpoint that implements a simple
>> message-boundary layer. I think the question of pure-message, bidirectional
>> transport is more relevant than a specific transport implementation.
>>
>> -F
>
>

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Fwd: I-D Action: draft-barnes-acme-token-challenge-02.txt

[Mary Barnes]

Hi all,

This update is just to fix some overt cut and past errors as I
inadvertently left references to Service provider code when I was splitting
the generic functionality. Please ignore the -01 as I introduced other
errors in fixing those errors.

It's important to note that this document does not and isn't intended to
reflect the joint proposal that Jon and I had the action to produce based
on previous contributions.  That joint proposal will be posted today.

I have no intention of asking the work group to progress or consider this
document at this juncture, I'm just being pedantic and not wanting a draft
to be out there with those errors, in case someone wanted to compare what I
previously proposed to the joint proposal to be submitted as
draft-peterson-acme-authority-token

Regards,
Mary.

-- Forwarded message --
From: 
Date: Mon, Mar 5, 2018 at 4:29 PM
Subject: I-D Action: draft-barnes-acme-token-challenge-02.txt
To: i-d-annou...@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.


Title   : ACME Token Identifier and Challenges
Author  : Mary Barnes
Filename: draft-barnes-acme-token-challenge-02.txt
Pages   : 10
Date: 2018-03-05

Abstract:
   This document specifies an identifier and challenge type required to
   enable the Automated Certificate Management Environment (ACME) to
   issue certificates using a token for the challenge response.  This
   token is issued by a administrative authority with whom the
   Certification Authority (CA) has a trust relationship.  The entity
   requesting a certificate also has a relationship with the
   administrative authority, such that the administrative authority
   assigns a unique code to the entity.  This entity code is included as
   part of the token that the administrative authority issues.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-barnes-acme-token-challenge/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-barnes-acme-token-challenge-02
https://datatracker.ietf.org/doc/html/draft-barnes-acme-token-challenge-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-barnes-acme-token-challenge-02


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft

directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] I-D Action: draft-ietf-acme-acme-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : Automatic Certificate Management Environment (ACME)
Authors : Richard Barnes
  Jacob Hoffman-Andrews
  Daniel McCarney
  James Kasten
Filename: draft-ietf-acme-acme-10.txt
Pages   : 81
Date: 2018-03-05

Abstract:
   Certificates in PKI using X.509 (PKIX) are used for a number of
   purposes, the most significant of which is the authentication of
   domain names.  Thus, certificate authorities in the Web PKI are
   trusted to verify that an applicant for a certificate legitimately
   represents the domain name(s) in the certificate.  Today, this
   verification is done through a collection of ad hoc mechanisms.  This
   document describes a protocol that a certification authority (CA) and
   an applicant can use to automate the process of verification and
   certificate issuance.  The protocol also provides facilities for
   other certificate management functions, such as certificate
   revocation.

   RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
   this draft is maintained in GitHub.  Suggested changes should be
   submitted as pull requests at https://github.com/ietf-wg-acme/acme
   [1].  Instructions are on that page as well.  Editorial changes can
   be managed in GitHub, but any substantive change should be discussed
   on the ACME mailing list (acme@ietf.org).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-acme-10
https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-10


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] I-D Action: draft-ietf-acme-acme-10.txt

[Daniel McCarney]

Draft 10 highlight reel for the tl;dr crowd:

   - Clarification of JWS serialization. ACME now requires flattened JSON
   serialization - https://github.com/ietf-wg-acme/acme/pull/410
   - Clarification of object status fields and state model (incl. new
   "ready" state for orders): https://github.com/ietf-wg-acme/acme/pull/400
   - Clarification that pre-authorization doesn't allow wildcard
   identifiers - https://github.com/ietf-wg-acme/acme/pull/412
   - Removal of unnecessary KeyAuthorization in challenge update/responses
   - https://github.com/ietf-wg-acme/acme/pull/375

Thank you to the folks that contributed PRs, reviews, and discussion.

- Daniel / cpu

On Mon, Mar 5, 2018 at 5:39 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Automated Certificate Management
> Environment WG of the IETF.
>
> Title   : Automatic Certificate Management Environment
> (ACME)
> Authors : Richard Barnes
>   Jacob Hoffman-Andrews
>   Daniel McCarney
>   James Kasten
> Filename: draft-ietf-acme-acme-10.txt
> Pages   : 81
> Date: 2018-03-05
>
> Abstract:
>Certificates in PKI using X.509 (PKIX) are used for a number of
>purposes, the most significant of which is the authentication of
>domain names.  Thus, certificate authorities in the Web PKI are
>trusted to verify that an applicant for a certificate legitimately
>represents the domain name(s) in the certificate.  Today, this
>verification is done through a collection of ad hoc mechanisms.  This
>document describes a protocol that a certification authority (CA) and
>an applicant can use to automate the process of verification and
>certificate issuance.  The protocol also provides facilities for
>other certificate management functions, such as certificate
>revocation.
>
>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
>this draft is maintained in GitHub.  Suggested changes should be
>submitted as pull requests at https://github.com/ietf-wg-acme/acme
>[1].  Instructions are on that page as well.  Editorial changes can
>be managed in GitHub, but any substantive change should be discussed
>on the ACME mailing list (acme@ietf.org).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-acme-10
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-10
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-10
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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] Concerning alternative formats …

[Matthew D. Hardeman]

> On Mar 5, 2018, at 3:50 PM, Felipe Gasper  wrote:
> 
> 
>> On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman  
>> wrote:
>> 
>> Especially with CT logging being a pragmatic requirement, time-to-delivery 
>> for certificates is likely to increase (slightly) rather than decrease.
> 
> Quick point: the alleviation of polling would go for authz status as well as 
> to certificate delivery.
> 
> A certificate order that has 10 domains needs to poll for the status of all 
> 10 of those domains’ authorizations as well as the certificate issuance. 
> “ACME/bidi” would remove all 11 of those needs to poll.
> 

While it eliminates the need for those 11 targets to poll for, it adds the not 
insignificant infrastructure cost of nailing up a stateful connection.  It’s 
worth mention that the past decade has seen massive improvements in the network 
stack from the low layer up through application layer apis as it would pertain 
to handling a great many of these connections, but there is still some cost to 
nailing up large numbers of concurrent connections.

As others note, h2 offers numerous models under which you could achieve the 
same benefits of getting asynchronous return of results over a single TCP 
session.

I would think that even if you have a clear, consistent, bidirectional 
communication channel that it would still make sense for the individual message 
content to remain unchanged.  (Not optimizing out replay-nonce, etc.)  As a 
general matter, protocols dealing with security and integrity probably achieve 
better and stronger implementations in the field when variability and supported 
cases are reduced to the minimum required to achieve the protocol’s goals.  
Where possible, I would think removal of edge cases, exceptions, and different 
handling for different messaging protocols would be a positive value.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Fwd: I-D Action: draft-barnes-acme-token-challenge-02.txt

[Peterson, Jon]

... and the joint draft Mary was referring to is this:

https://www.ietf.org/id/draft-peterson-acme-authority-token-01.txt

... which provides a generic framework for acquiring an authority token as
a response to ACME challenges. The specific identifier types for the
telephone number and service provider codes we've been exploring can be
found in this draft:

https://www.ietf.org/id/draft-wendt-acme-authority-token-tnauthlist-00.txt

Jon Peterson
Neustar, Inc.



From:  Acme  on behalf of Mary Barnes

Date:  Monday, March 5, 2018 at 2:32 PM
To:  ACME WG 
Subject: [Acme] Fwd: I-D Action: draft-barnes-acme-token-challenge-02.txt


>Hi
> all,
>This update is just to fix some overt cut and past errors as I
>inadvertently left references to Service provider code when I was
>splitting the generic functionality. Please ignore the -01 as I
>introduced other errors in fixing those errors.
>
>It's important to note that this document does not and isn't intended to
>reflect the joint proposal that Jon and I had the action to produce based
>on previous contributions.  That joint proposal will be posted today.
>
>I have no intention of asking the work group to progress or consider this
>document at this juncture, I'm just being pedantic and not wanting a
>draft to be out there with those errors, in case someone wanted to
>compare what I previously proposed to the joint
> proposal to be submitted as draft-peterson-acme-authority-token
>
>Regards,
>Mary. 
>
>-- Forwarded message --
>From: 
>Date: Mon, Mar 5, 2018 at 4:29 PM
>Subject: I-D Action: draft-barnes-acme-token-challenge-02.txt
>To: i-d-annou...@ietf.org
>
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>Title   : ACME Token Identifier and Challenges
>Author  : Mary Barnes
>Filename: draft-barnes-acme-token-challenge-02.txt
>Pages   : 10
>Date: 2018-03-05
>
>Abstract:
>   This document specifies an identifier and challenge type required to
>   enable the Automated Certificate Management Environment (ACME) to
>   issue certificates using a token for the challenge response.  This
>   token is issued by a administrative authority with whom the
>   Certification Authority (CA) has a trust relationship.  The entity
>   requesting a certificate also has a relationship with the
>   administrative authority, such that the administrative authority
>   assigns a unique code to the entity.  This entity code is included as
>   part of the token that the administrative authority issues.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-barnes-acme-token-challenge/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-barnes-acme-token-challenge-02
>https://datatracker.ietf.org/doc/html/draft-barnes-acme-token-challenge-02
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-barnes-acme-token-challenge-02
>
>
>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 .
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>I-D-Announce mailing list
>i-d-annou...@ietf.org
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft 
>
>directories: 
>http://www.ietf.org/shadow.html 
>or 
>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt

[Tim Hollebeek]

I'm generally supportive of this, but one concern I do have, and I admit
I'm mostly just thinking aloud here, is that we are slowly accumulating a
larger and larger number of things that look like certificates, but aren't
due to people playing games with critical extensions.

I think we may come to regret using that trick so much.  Such schemes
are only one software bug away from having rather profound effects
on trust decisions and the entire ecosystem.

The trick is one of the more ugly parts of certificate transparency, and I 
would encourage people to think about whether it is possible to 
accomplish what this draft is trying to accomplish without repeating that 
mistake.

-Tim

> -Original Message-
> From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of internet-
> dra...@ietf.org
> Sent: Friday, March 2, 2018 7:35 PM
> To: i-d-annou...@ietf.org
> Cc: acme@ietf.org
> Subject: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Automated Certificate Management
> Environment WG of the IETF.
> 
> Title   : ACME TLS ALPN Challenge Extension
> Author  : Roland Bracewell Shoemaker
>   Filename: draft-ietf-acme-tls-alpn-00.txt
>   Pages   : 7
>   Date: 2018-03-02
> 
> Abstract:
>This document specifies a new challenge for the Automated Certificate
>Management Environment (ACME) protocol which allows for domain
>control validation using TLS.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-tls-alpn-00
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-tls-alpn-00
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme


smime.p7s
Description: S/MIME cryptographic signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ALPN based TLS challenge

[Tim Hollebeek]

The concerns in this email, many of which I share, are the reason why I’d 
really like to get around to doing a full security analysis of all of the BR 
validation methods at some point.  They’ve mostly been considered in isolation, 
when in reality there are many overlapping themes.

 

Maybe we’ll at least make some progress towards a more unified and coherent 
understanding of validation tomorrow.

 

-Tim

 

From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Ryan Sleevi
Sent: Monday, February 26, 2018 2:09 PM
To: Doug Beattie 
Cc: IETF ACME ; c...@letsencrypt.org
Subject: Re: [Acme] ALPN based TLS challenge

 

 

 

On Mon, Feb 26, 2018 at 3:33 PM, Doug Beattie mailto:doug.beat...@globalsign.com> > wrote:

 

I would find it a bit surprising if the CABF adopted a domain validation method 
that relied on the web hosting provider claiming to do the right thing (to 
separate users on shared IP addresses so they cannot request certs from the 
other customers on that IP address). 

 

I'm surprised that it's seen as surprising, as this is already the implicit 
assumption for the validation methods within the CA/Browser Forum's Baseline 
Requirements.

 

Notable among the comparisons would be to 3.2.2.4.4, which makes a presumption 
that the email provider for the domain has not only observed RFC 2142 Section 
5, but also the CA/Browser Forum specific aliases of "admin" and "administrator"

 

Alternatively, one might consider the comparison to 3.2.2.4.6, in which the 
presumption is made that the /.well-known/ path is restricted from general 
access. Section 8.3 of ACME ( 
https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.3 ) specifically 
encourages the following of redirects when dereferencing the /.well-known/, but 
this understandably opens up attacks should a blanket redirect be used.

 

That said, I do think the artificial distinction between "web hosting provider" 
may be detrimental. Given the existing of the CA/Browser Forum's 3.2.2.4.8, one 
can equally see an attack made under such shared-hosting scenarios by any CA 
that utilizes the .8 methods of validation, in that multiple tenants on that IP 
would have access to respond for that IP (under 3.2.2.5)

 

Has anyone discussed this with the CABF?  I’d recommend that someone send this 
out to the public list for feedback.

 

Considering that the method described is consistent with 3.2.2.4.10 in the 
Baseline Requirements, did you mean to suggest conversations with Root Store 
programs that might otherwise restrict the usage of methods beyond that of the 
Baseline Requirements, such as forbidding 3.2.2.4.1, .5, .9 and .10 without 
specific mitigations?

 

As one such Root Store operator, we're happy to see this method progress within 
the IETF, and believe it provides suitable mitigations for the issues 
disclosed. In retrospect, the introduction of the TLS-SNI method as specified 
in https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.4 , is 
functionally no different than introducing a new e-mail alias in the 3.2.2.4.4 
method of validation - that is, presuming that all at-risk domains (such as 
those that allow arbitrary e-mail registration) must now take steps to block. 
The proposed method provides an opt-in, rather than an opt-out, and thus 
provides suitable mitigation.

 

Much like a domain holder could choose a hosting provider that permits 
arbitrary modification to /.well-known/ or arbitrary DNS modification, I do not 
believe this introduces any additional security holes compared to the 
presently-industry-accepted methods of validating domain control.

 

 

Doug

 

From: Acme [mailto:acme-boun...@ietf.org  ] On 
Behalf Of Daniel McCarney
Sent: Monday, February 26, 2018 2:14 PM
Cc: IETF ACME mailto:acme@ietf.org> >
Subject: Re: [Acme] ALPN based TLS challenge

 

+1

The WG should adopt this document. I will volunteer to help review if adopted.

 

 

On Mon, Feb 26, 2018 at 12:02 PM, Richard Barnes mailto:r...@ipv.sx> > wrote:

+1

 

This approach is a major improvement from earlier efforts at a TLS-based 
challenge.  It follows normal TLS processing logic much more closely, differing 
only in the fact that the certificate presented has an extra extension.  
Minimizing the differences w.r.t. normal behavior seems like a good approach to 
avoiding the sorts of corner cases that have tripped up earlier flavors of 
TLS-based challenges.

 

Before this is finalized as an RFC, we should verify empirically that most 
hosting providers will be secure in the presence of this challenge.  But I'm 
convinced that the approach in Roland's document is likely enough to work that 
we should go ahead and develop a specification, which we can test as it matures.

 

--Richard

 

 

On Fri, Feb 23, 2018 at 11:41 AM, Stephen Farrell mailto:stephen.farr...@cs.tcd.ie> > wrote:



On 23/02/18 16:31, Salz, Rich wrote:
>
>> Here is the ID:
>> https://datatracker.ietf.org/doc/draft-shoemaker-a

Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt

[Jacob Hoffman-Andrews]

On 03/05/2018 04:37 PM, Tim Hollebeek wrote:
> I think we may come to regret using that trick so much.  Such schemes
> are only one software bug away from having rather profound effects
> on trust decisions and the entire ecosystem.
This is a good point, but an important mitigating factor is that these
are self-signed certificates, as compared to CT's precertificates, which
are signed by a trusted issuer but poisoned. And they are only presented
when the acme/1 ALPN is negotiated. So you'd need three software bugs,
each of which would be a game-over bug on its own:

 - ignoring a critical extension
 - trusting a self-signed certificate
 - sending acme/1 ALPN for non-validation traffic

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt

[Tim Hollebeek]

That's a fair point.  Although note that critical extension bugs don't tend
to be
of the "ignore critical extension" variety (though that happens), they tend
to be 
of the "understand the critical extension for the purposes of rejecting it
and then 
getting the logic backwards" or something similar.

The self-signedness is probably the most important mitigating factor ... we
might
want to make sure that the draft has enough requirements to make sure that
the margin of error is two to three software bugs in all compliant
implementations, 
and is never just one.

-Tim

> -Original Message-
> From: Jacob Hoffman-Andrews [mailto:j...@eff.org]
> Sent: Monday, March 5, 2018 5:42 PM
> To: Tim Hollebeek ; acme@ietf.org
> Subject: Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt
> 
> On 03/05/2018 04:37 PM, Tim Hollebeek wrote:
> > I think we may come to regret using that trick so much.  Such schemes
> > are only one software bug away from having rather profound effects on
> > trust decisions and the entire ecosystem.
> This is a good point, but an important mitigating factor is that these are
self-
> signed certificates, as compared to CT's precertificates, which are signed
by a
> trusted issuer but poisoned. And they are only presented when the acme/1
> ALPN is negotiated. So you'd need three software bugs, each of which would
be
> a game-over bug on its own:
> 
>  - ignoring a critical extension
>  - trusting a self-signed certificate
>  - sending acme/1 ALPN for non-validation traffic


smime.p7s
Description: S/MIME cryptographic signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Concerning alternative formats …

[Felipe Gasper]

> On Mar 5, 2018, at 5:58 PM, Matthew D. Hardeman  wrote:
> 
>> On Mar 5, 2018, at 3:50 PM, Felipe Gasper  wrote:
>> 
>> Quick point: the alleviation of polling would go for authz status as well as 
>> to certificate delivery.
>> 
>> A certificate order that has 10 domains needs to poll for the status of all 
>> 10 of those domains’ authorizations as well as the certificate issuance. 
>> “ACME/bidi” would remove all 11 of those needs to poll.
>> 
> 
> While it eliminates the need for those 11 targets to poll for, it adds the 
> not insignificant infrastructure cost of nailing up a stateful connection.  
> It’s worth mention that the past decade has seen massive improvements in the 
> network stack from the low layer up through application layer apis as it 
> would pertain to handling a great many of these connections, but there is 
> still some cost to nailing up large numbers of concurrent connections.

I would think the grand majority of such connections would go away once 
certificate renewals were done. There’d be no reason to hold onto the 
connection afterward, as it ties up resources for the client as well as the 
server.

> As others note, h2 offers numerous models under which you could achieve the 
> same benefits of getting asynchronous return of results over a single TCP 
> session.

I’ve not seen much discussion of h2 server push in this context; its use seems 
(by design) limited to the case of pre-sending resources that the client will 
either accept or reject via RST_STREAM.

There is SSE (Server-Sent Events), but my understanding is that that protocol 
is effectively abandoned, supported browser implementations notwithstanding. 
(Edge/IE in particular doesn’t support it.)

Is there another mechanism that you and Thomson have in mind, or what am I 
missing?

Thank you,
-Felipe Gasper
Mississauga, Ontario
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme