Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

Here is a pull request: https://github.com/ietf-wg-acme/acme/pull/382

Let me know what you think.

Sincerely,

Logan Widick

On Wed, Jan 3, 2018 at 6:21 PM, Logan Widick  wrote:

> This looks good to me.
>
> As for using JOSE implementations that lack support for the JSON
> serialization formats (and only support the compact one), is there an RFC,
> Internet-Draft, or similar document with an explanation of the conversion
> process already prepared (that can simply be thrown into the ACME draft's
> references section)? Or would it be necessary to include an appendix in the
> ACME draft with an outline of the conversion process? The conversion
> process looks fairly straightforward. However, it would be nice if there
> was a document or part of a document that could be easily referenced.
>
> Logan
>
> On Wed, Jan 3, 2018 at 5:47 PM, Fraser Tweedale  wrote:
>
>> On Thu, Jan 04, 2018 at 12:07:34AM +0100, Jörn Heissler wrote:
>> > Hello and happy new Year!
>> >
>> > I've found an inaccuracy in the ACME specs.
>> >
>> > https://tools.ietf.org/html/rfc7515#section-7 states:
>> >
>> > Applications using this specification need to specify what
>> serialization
>> > and serialization features are used for that application.
>> >
>> > Although this is neither a "SHOULD" nor a "MUST", I think ACME should
>> specify
>> > which serialization formats need to be supported by server
>> implementations.
>> >
>> > RFC7515 defines four serialization formats:
>> >
>> > * JWS Compact Serialization
>> > * General JWS JSON Serialization Syntax
>> >   * One signature only
>> >   * Multiple signatures
>> > * Flattened JWS JSON Serialization Syntax
>> >
>> > https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm
>> l#rfc.section.6.2
>> > states:
>> >
>> > In the examples below, JWS objects are shown in the JSON or
>> > flattened JSON serialization
>> >
>> > All examples in the ACME specification use only the flattened
>> serialization.
>> > Depending on the clarification above, this might need to be amended too.
>> >
>> > Best regards
>> > Jörn Heissler
>>
>> I am the author of a JOSE library, and have had to deal with
>> interoperability issues arising from the multiple serialisations and
>> underspecified applications/protocols.  Please heed my advice.
>>
>> Where there is a choice of JSON serialisation (i.e. exactly one
>> signature), JOSE does not require or recommend a particular
>> serialisation be used.  Not does the specification require or
>> recommend that there be a mechanism for telling a library what JSON
>> serialisation to use.  The outcome of this is that there are:
>>
>> - implementations that unconditionally produce the General JSON
>>   serialisation
>>
>> - implementations that unconditionally produce the Flattened JSON
>>   serialisation (and do not support multiple signatures at all)
>>
>> - implementations that produce the Flattened serialisation when
>>   there is a single signature, and the General JSON serialisation
>>   otherwise
>>
>> Therefore for interoperability and to avoid situations where a
>> conforming JOSE library cannot be used for ACME, I suggest that ACME
>> adopt the following regime:
>>
>> - Conforming ACME implementations MUST process JWS objects using the
>>   Flattened JWS JSON Serialization and SHOULD process JWS objects
>>   using the General JWS JSON Serialization.
>>
>> - Conforming ACME implementations MAY refuse to process JWS objects
>>   with multiple signatures.  If an implementation accepts
>>   multiple-signature JWS objects, it MUST validate at least one
>>   signature using the account's public key.
>>
>> Cheers,
>> Fraser
>>
>> ___
>> 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] Specify which JWS serialization is used

[Logan Widick]

This looks good to me.

As for using JOSE implementations that lack support for the JSON
serialization formats (and only support the compact one), is there an RFC,
Internet-Draft, or similar document with an explanation of the conversion
process already prepared (that can simply be thrown into the ACME draft's
references section)? Or would it be necessary to include an appendix in the
ACME draft with an outline of the conversion process? The conversion
process looks fairly straightforward. However, it would be nice if there
was a document or part of a document that could be easily referenced.

Logan

On Wed, Jan 3, 2018 at 5:47 PM, Fraser Tweedale  wrote:

> On Thu, Jan 04, 2018 at 12:07:34AM +0100, Jörn Heissler wrote:
> > Hello and happy new Year!
> >
> > I've found an inaccuracy in the ACME specs.
> >
> > https://tools.ietf.org/html/rfc7515#section-7 states:
> >
> > Applications using this specification need to specify what
> serialization
> > and serialization features are used for that application.
> >
> > Although this is neither a "SHOULD" nor a "MUST", I think ACME should
> specify
> > which serialization formats need to be supported by server
> implementations.
> >
> > RFC7515 defines four serialization formats:
> >
> > * JWS Compact Serialization
> > * General JWS JSON Serialization Syntax
> >   * One signature only
> >   * Multiple signatures
> > * Flattened JWS JSON Serialization Syntax
> >
> > https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.
> html#rfc.section.6.2
> > states:
> >
> > In the examples below, JWS objects are shown in the JSON or
> > flattened JSON serialization
> >
> > All examples in the ACME specification use only the flattened
> serialization.
> > Depending on the clarification above, this might need to be amended too.
> >
> > Best regards
> > Jörn Heissler
>
> I am the author of a JOSE library, and have had to deal with
> interoperability issues arising from the multiple serialisations and
> underspecified applications/protocols.  Please heed my advice.
>
> Where there is a choice of JSON serialisation (i.e. exactly one
> signature), JOSE does not require or recommend a particular
> serialisation be used.  Not does the specification require or
> recommend that there be a mechanism for telling a library what JSON
> serialisation to use.  The outcome of this is that there are:
>
> - implementations that unconditionally produce the General JSON
>   serialisation
>
> - implementations that unconditionally produce the Flattened JSON
>   serialisation (and do not support multiple signatures at all)
>
> - implementations that produce the Flattened serialisation when
>   there is a single signature, and the General JSON serialisation
>   otherwise
>
> Therefore for interoperability and to avoid situations where a
> conforming JOSE library cannot be used for ACME, I suggest that ACME
> adopt the following regime:
>
> - Conforming ACME implementations MUST process JWS objects using the
>   Flattened JWS JSON Serialization and SHOULD process JWS objects
>   using the General JWS JSON Serialization.
>
> - Conforming ACME implementations MAY refuse to process JWS objects
>   with multiple signatures.  If an implementation accepts
>   multiple-signature JWS objects, it MUST validate at least one
>   signature using the account's public key.
>
> Cheers,
> Fraser
>
> ___
> 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] Specify which JWS serialization is used

[Fraser Tweedale]

On Thu, Jan 04, 2018 at 12:07:34AM +0100, Jörn Heissler wrote:
> Hello and happy new Year!
> 
> I've found an inaccuracy in the ACME specs.
> 
> https://tools.ietf.org/html/rfc7515#section-7 states:
> 
> Applications using this specification need to specify what serialization
> and serialization features are used for that application.
> 
> Although this is neither a "SHOULD" nor a "MUST", I think ACME should specify
> which serialization formats need to be supported by server implementations.
> 
> RFC7515 defines four serialization formats:
> 
> * JWS Compact Serialization
> * General JWS JSON Serialization Syntax
>   * One signature only
>   * Multiple signatures
> * Flattened JWS JSON Serialization Syntax
> 
> https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.6.2
> states:
> 
> In the examples below, JWS objects are shown in the JSON or
> flattened JSON serialization
> 
> All examples in the ACME specification use only the flattened serialization.
> Depending on the clarification above, this might need to be amended too.
> 
> Best regards
> Jörn Heissler

I am the author of a JOSE library, and have had to deal with
interoperability issues arising from the multiple serialisations and
underspecified applications/protocols.  Please heed my advice.

Where there is a choice of JSON serialisation (i.e. exactly one
signature), JOSE does not require or recommend a particular
serialisation be used.  Not does the specification require or
recommend that there be a mechanism for telling a library what JSON
serialisation to use.  The outcome of this is that there are:

- implementations that unconditionally produce the General JSON
  serialisation

- implementations that unconditionally produce the Flattened JSON
  serialisation (and do not support multiple signatures at all)

- implementations that produce the Flattened serialisation when
  there is a single signature, and the General JSON serialisation
  otherwise

Therefore for interoperability and to avoid situations where a
conforming JOSE library cannot be used for ACME, I suggest that ACME
adopt the following regime:

- Conforming ACME implementations MUST process JWS objects using the
  Flattened JWS JSON Serialization and SHOULD process JWS objects
  using the General JWS JSON Serialization.

- Conforming ACME implementations MAY refuse to process JWS objects
  with multiple signatures.  If an implementation accepts
  multiple-signature JWS objects, it MUST validate at least one
  signature using the account's public key.

Cheers,
Fraser


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

Re: [Acme] Specify which JWS serialization is used

[Logan Widick]

I agree that a serialization format (or set of formats) would need to be
standardized. Related thread:
https://www.ietf.org/mail-archive/web/acme/current/msg01690.html

Sincerely,

Logan Widick

On Wed, Jan 3, 2018 at 5:07 PM, Jörn Heissler 
wrote:

> Hello and happy new Year!
>
> I've found an inaccuracy in the ACME specs.
>
> https://tools.ietf.org/html/rfc7515#section-7 states:
>
> Applications using this specification need to specify what
> serialization
> and serialization features are used for that application.
>
> Although this is neither a "SHOULD" nor a "MUST", I think ACME should
> specify
> which serialization formats need to be supported by server implementations.
>
> RFC7515 defines four serialization formats:
>
> * JWS Compact Serialization
> * General JWS JSON Serialization Syntax
>   * One signature only
>   * Multiple signatures
> * Flattened JWS JSON Serialization Syntax
>
> https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.
> html#rfc.section.6.2
> states:
>
> In the examples below, JWS objects are shown in the JSON or
> flattened JSON serialization
>
> All examples in the ACME specification use only the flattened
> serialization.
> Depending on the clarification above, this might need to be amended too.
>
> Best regards
> Jörn 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

[Acme] Specify which JWS serialization is used

[Jörn Heissler]

Hello and happy new Year!

I've found an inaccuracy in the ACME specs.

https://tools.ietf.org/html/rfc7515#section-7 states:

Applications using this specification need to specify what serialization
and serialization features are used for that application.

Although this is neither a "SHOULD" nor a "MUST", I think ACME should specify
which serialization formats need to be supported by server implementations.

RFC7515 defines four serialization formats:

* JWS Compact Serialization
* General JWS JSON Serialization Syntax
  * One signature only
  * Multiple signatures
* Flattened JWS JSON Serialization Syntax

https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.6.2
states:

In the examples below, JWS objects are shown in the JSON or
flattened JSON serialization

All examples in the ACME specification use only the flattened serialization.
Depending on the clarification above, this might need to be amended too.

Best regards
Jörn Heissler


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

Re: [Acme] Stale DNS and high-risk issuance

[Ilari Liusvaara]

On Wed, Jan 03, 2018 at 12:48:45PM +, Tobias Fiebig wrote:
> Hello Ilari,
> > [1] Just as example, the following kinds of stuff are (legimately) seen 
> > fairly
> > often or more:
> > 
> > 
> > - Rolling over the account key for each renewal (this is usually caused
> >   by containers forgetting things).
> > - Rolling over the TLS key for each renewal (some actually recommend
> >   this, I do not). Sometimes with very frequent renewals.
> > - Getting multiple certificates with different keys for multiple
> >   servers with the same name.
> > - Handling validation on separate system and pushing the certificates
> >   (and likely the TLS keys too, probably not in safe manner!) to server
> >   systems. These systems might utilize HTTP redirects (which HTTP-01
> >   does follow) or DNS CNAMEs (which DNS-01 does follow).
> > - Users wiping out the TLS keys and account keys (without backup!) to
> >   "reset" something (admin mistake).
> > - Transferring site between servers and losing the keys (account and
> >   TLS) in the process.
> > - Users using all sorts of whacky ACME clients that just do not
> >   implement anything more than bare minimum for the common case.
> > - Users using HTTPS on servers they don't have proper control of
> >   DNS for (can't edit records, or can only use very few record
> >   types, at worst only A/, or worse yet, A only).
> > 
> > Thinking about recovery is rather important. One of the major reasons HPKP
> > is so hated is lack of pretty much any kind of recovery.
>
> I am seriously interested in surveying this kind of behavior, not only
> to quantify it, but also to understand MOs during systems' operation.
> While some of these cases seem relatively easy to measure (yet sometimes
> not to distinguish, i.e., cases 1 and 2), others seem to be harder
> harder to measure, e.g., the 4th case. The main problem here is that
> this would certainly require cooperation from LE. What are your thoughts
> on this?

I am not sure one could get much useful information about frequency
of many of these even with full validation and issuance logs from CA
(which one probably can not get).

Well, the point was: Keys get rotated or lost. One needs recovery
method. In worst case, DNS can not be used or recovery needs to be
automatic. Also, nasty hacks like how TLS-SNI is done with most
webservers are really to be avoided.


One obvious way that would not need to deal with recovery would be
validating all global IPs seen, or random subset if there are too
many. However, even this might not be problem free (because IPv6).


> > [2] This was actually one of the major reasons why the PoP challenge
> > was removed.
> Well, technically it should be sufficient to do the channel over HTTPs
> to reach the same result in comparison to actually signing the challenge.

Intestingly, the test certificate method in BRs requires keys to
match. The random number in certificate method was split from that,
and it does not have key-matching requirement.

(ACME as protocol was not designed to be able to really deal with key-
matching requirements).



-Ilari

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

Re: [Acme] Stale DNS and high-risk issuance

[Tobias Fiebig]

Hello Ilari,
> [1] Just as example, the following kinds of stuff are (legimately) seen fairly
> often or more:
> 
> 
> - Rolling over the account key for each renewal (this is usually caused
>   by containers forgetting things).
> - Rolling over the TLS key for each renewal (some actually recommend
>   this, I do not). Sometimes with very frequent renewals.
> - Getting multiple certificates with different keys for multiple
>   servers with the same name.
> - Handling validation on separate system and pushing the certificates
>   (and likely the TLS keys too, probably not in safe manner!) to server
>   systems. These systems might utilize HTTP redirects (which HTTP-01
>   does follow) or DNS CNAMEs (which DNS-01 does follow).
> - Users wiping out the TLS keys and account keys (without backup!) to
>   "reset" something (admin mistake).
> - Transferring site between servers and losing the keys (account and
>   TLS) in the process.
> - Users using all sorts of whacky ACME clients that just do not
>   implement anything more than bare minimum for the common case.
> - Users using HTTPS on servers they don't have proper control of
>   DNS for (can't edit records, or can only use very few record
>   types, at worst only A/, or worse yet, A only).
> 
> Thinking about recovery is rather important. One of the major reasons HPKP
> is so hated is lack of pretty much any kind of recovery.
I am seriously interested in surveying this kind of behavior, not only to 
quantify it, but also to understand MOs during systems' operation. While some 
of these cases seem relatively easy to measure (yet sometimes not to 
distinguish, i.e., cases 1 and 2), others seem to be harder harder to measure, 
e.g., the 4th case. The main problem here is that this would certainly require 
cooperation from LE. What are your thoughts on this?

> [2] This was actually one of the major reasons why the PoP challenge was
> removed.
Well, technically it should be sufficient to do the channel over HTTPs to reach 
the same result in comparison to actually signing the challenge.


Met vriendelijke groet,
 
Tobias Fiebig,
Department Engineering Systems and Services

Informatie- en Communicatie Technologie (ICT)
 
TU Delft / Dept. ESS
Faculty of Technology, Policy and Management (TBM)
Building 31
Jaffalaan 5 - room B3.170
2628 BX  Delft
P.O.Box 5015
2600 GA Delft, The Netherlands
T +31 (0)15 27 85700
E  t.fie...@tudelft.nl

Present: Monday t/m Friday
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Challenge objects are provoking implementation mistakes

[Sophie Herold]

Hi,

small note on my changes: I might have changed the meaning of
'fulfilling' and 'responding to' a challenge. I think these terms will
be relevant for clarifying other outstanding issues. Therefore, I would
like to settle on some terms that will be used throughout the standard.

fulfilling a challenge:
  e.g. client provisioning a TXT record

responding to a challenge:
  posting to the challenge url (the server can try validation now)

Best,
Sophie

On 02/01/18 20:51, Daniel McCarney wrote:
> Thanks for the PR Sophie. I voiced a +1 on the Github thread but will also
> echo it here.
> 
> On Wed, Dec 27, 2017 at 8:35 AM, Sophie Herold 
> wrote:
> 
>> Hi,
>>
>> I have posted a PR that implements both changes (not expecting and not
>> returning the keyAuthorization) as basis for a discussion.
>>
>> https://github.com/ietf-wg-acme/acme/pull/375
>>
>> Notably, I think this should be backwards compatible for clients as far
>> as we want it to be. The redundant keyAuthorization would just be
>> ignored by the server.
>>
>> Best,
>> Sophie
>>
>> On 21/12/17 04:07, Jacob Hoffman-Andrews wrote:
>>> On 12/19/2017 03:10 AM, Sophie Herold wrote:
 If the client follows the schema

 1. fulfill challenge
 2. POST challenge URL

 it is unlikely that the keyAuthorization returned by the server would be
 used to fulfill the challenge (again).

 However, it should be possible to obtain a working ACME client by
 POSTing to the challenge URL first and using the keyAuthorization
 returned by the server (and possibly changed by the server) to fulfill
 the challenge afterwards. This should work since the servers challenge
 checks (DNS, HTTP, ...) are not instantaneous and even retried. In this
 case the MitM protection is bypassed by incautious client
>> implementation.
>>>
>>> This is a good point. The other potential issue is reliability: a client
>>> the depends on the returned keyAuthorization rather than the one it
>>> provided might appear to work for a while, then stop working if the
>>> server started validating challenges more quickly.
>>>
>>> I would support a change so that the server does not echo the
>>> keyAuthorization. This brings up another question: Why have the client
>>> include the keyAuthorization in the challenge POST at all? Both sides
>>> can calculate it from scratch, the POST is essentially just "I'm ready
>>> for validation now!" I think we originally included it because we
>>> anticipated had other challenges where the client would be expected to
>>> provide some secret token in the challenge response, or some proof of
>>> control of a key, so including some payload (keyAuthorization) for the
>>> other challenge types seemed stylistically consistent with that.
>>> However, I don't think it's really necessary.
>>>
>>> ___
>>> 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
>>
> 
> 
> 
> ___
> 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