Re: [Acme] Specify which JWS serialization is used

[Jörn Heissler]

On Thu, Jan 04, 2018 at 08:03:55 -0600, Logan Widick wrote:
> What do you think of the following:

> Content type application/jose+json: MUST be supported. If used, the JWS
> will need to be in the Flattened or General serialization. Flattened MUST
> be supported; General MAY be supported.

> Content type application/jose: MAY be supported. If used, the JWS MUST use
> the Compact serialization. Or should this content type not be allowed?

Agreed. I wouldn't disallow "compact". And it could be clarified:

The server SHOULD use the "Content-Type" HTTP header as an indication
for the request format.

> JWS Unprotected Header: Not currently used in ACME. Should this be banned
> in ACME?

I don't see much sense in those. But some client implementations might
automatically add an unprotected header like e.g. "cty".
Maybe with a "SHOULD NOT"?

> Multiple signatures: MAY be supported.

> Should messages signed by both MAC keys and private keys be allowed?

This is already forbidden.

> What about Key IDs not issued by the CA?
> Or are multiple signatures more trouble than they're worth to the point of
> banning them entirely?
> 
> Multiple signatures on messages that need to be signed by account key: At
> least one signature MUST be from the account key
> 
> Multiple signatures on revokeCert: Should this be allowed?
> 
> Multiple signatures on externalAccountBinding field of newAccount: Should
> it be possible to bind to multiple pre-existing accounts? Or should this
> not be allowed?
> 
> Multiple signatures on newAccount: Not allowed?
> 
> Multiple signatures on keyChange: Not allowed for outer or inner JWS?

I see no use case. All the authentication is based on accounts and those
have exactly one keypair. Having multiple signatures would equal using
multiple accounts at the same time. That makes no sense to me.
Client libs would probably not generate multiple signatures
automatically.
Multiple signatures should be banned in my opinion.

> JWS Unencoded Payload Option (RFC 7797): Not allowed?

Yep, they would make things very complicated.

> Conversion guide between the different JWS serialization formats: Is it
> completely safe to assume that any and all programmers given the JWS RFC,
> pre-existing JWS implementations with sufficient documentation, and
> pre-existing JSON libraries with sufficient documentation could figure out
> how to convert the serialization formats as needed?

Why, yes! Of course every programmer can do that! ;-)

> Or is the conversion
> guide necessary? If the guide is necessary, then include a reference to a
> separate new or pre-existing conversion guide. If the guide is necessary,
> and there is no pre-existing conversion guide, how should the new
> conversion guide be published? Should the new conversion guide be
> ACME-specific, or more general (possibly with coverage of JWE as well as
> JWS features not utilized in ACME)?

It's not necessary, *most* programmers can figure it out. But it would
doubtlessly be helpful. E.g. I didn't consider the possibility to do
this conversion in an ACME implementation before/after using a preexisting
JOSE lib.
If such a guide were to be published, it should not be ACME-specific.


Cheers
Jörn


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

Re: [Acme] Usage of "unspecified" reason code in CRL / OCSP

[Richard Barnes]

Good point.  Posted a PR: https://github.com/ietf-wg-acme/acme/pull/385

On Fri, Jan 5, 2018 at 6:03 PM, Jörn Heissler 
wrote:

> Hello,
>
> https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.
> html#rfc.section.7.6
> states:
>
> If this field is not set the server SHOULD use the unspecified (0)
> reasonCode value when generating OCSP responses and CRLs.
>
> Yet https://tools.ietf.org/html/rfc5280#section-5.3.1 says the opposite:
>
> the reason code CRL entry extension SHOULD be absent instead
> of using the unspecified (0) reasonCode value.
>
> Could this be reworded somehow? It would make sense to store `0' in a
> database but later don't add a CRLReason extension / ASN.1 field.
>
> Cheers,
> Jörn
>
> ___
> 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] Usage of "unspecified" reason code in CRL / OCSP

[Jörn Heissler]

Hello,

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

If this field is not set the server SHOULD use the unspecified (0)
reasonCode value when generating OCSP responses and CRLs.

Yet https://tools.ietf.org/html/rfc5280#section-5.3.1 says the opposite:

the reason code CRL entry extension SHOULD be absent instead
of using the unspecified (0) reasonCode value.

Could this be reworded somehow? It would make sense to store `0' in a
database but later don't add a CRLReason extension / ASN.1 field.

Cheers,
Jörn


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

Re: [Acme] Clarify that newAuthz endpoint is optional

[Richard Barnes]

I merged.

On Fri, Jan 5, 2018 at 4:43 PM, Daniel McCarney  wrote:

> Why not a MUST? If you don't implement preauthorization, there's no need
>> for a value.  I guess you could provide "null", but ... don't.
>
>
> I have no objections to using MUST over SHOULD. Updated in 5fcaa6c on my
> PR branch.
>
> - Daniel / cpu
>
> On Fri, Jan 5, 2018 at 4:24 PM, Richard Barnes  wrote:
>
>> Why not a MUST? If you don't implement preauthorization, there's no need
>> for a value.  I guess you could provide "null", but ... don't.
>>
>> On Fri, Jan 5, 2018 at 2:33 PM, Daniel McCarney 
>> wrote:
>>
>>> Hi Ilari,
>>>
>>>
 This impiles that if pre-authorization is not supported, newAuthz
 better be absent (this is also useful for detecting pre-authorization
 support if the client can use it somehow).
 I think this should be at least a SHOULD.
>>>
>>>
>>> You're right. My intention is to make the presence of that field an
>>> indicator of pre-authorization support (or lack thereof). I'll update to a
>>> SHOULD in my PR since I agree that maps better.
>>>
>>> Thanks!
>>>
>>>
>>>
>>> On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara <
>>> ilariliusva...@welho.com> wrote:
>>>
 On Fri, Jan 05, 2018 at 02:05:22PM -0500, Daniel McCarney wrote:
 > In Section 7.4.1 "Pre-Authorization" the spec says:
 >
 >  If a CA wishes to allow pre-authorization within ACME, it can offer
 > >  a "new authorization" resource in its directory by adding the field
 > >  "newAuthz" with a URL for the new authorization resource.
 >
 >
 > That text indicates that the CA may wish to *not* support
 pre-authorization
 > in which case the "newAuthz" resource will not be present in the
 directory.
 > E.g. the Let's Encrypt ACME v2 directory[0] does not include this
 resource.
 >
 > I think this should be further emphasized in Section 7.1.1 "Directory"
 > since this is where a developer is likely to look first when trying to
 > determine what directory fields can be assumed present.
 >
 > I opened a PR to add a small note about this to Section 7.1.1:
 > https://github.com/ietf-wg-acme/acme/pull/384
 >
 > This is perhaps a step past the line of being strictly editorial. I
 would
 > appreciate if anyone with objections raise them on-thread over the
 next few
 > days.

 Why MAY? If implementation does not support some functionality that an
 endpoint is exclusively for, it better omit that endpoint. This impiles
 that if pre-authorization is not supported, newAuthz better be absent
 (this is also useful for detecting pre-authorization support if the
 client can use it somehow).

 I think this should be at least a SHOULD.



 -Ilari

>>>
>>>
>>> ___
>>> 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] Clarify that newAuthz endpoint is optional

[Daniel McCarney]

>
> Why not a MUST? If you don't implement preauthorization, there's no need
> for a value.  I guess you could provide "null", but ... don't.


I have no objections to using MUST over SHOULD. Updated in 5fcaa6c on my PR
branch.

- Daniel / cpu

On Fri, Jan 5, 2018 at 4:24 PM, Richard Barnes  wrote:

> Why not a MUST? If you don't implement preauthorization, there's no need
> for a value.  I guess you could provide "null", but ... don't.
>
> On Fri, Jan 5, 2018 at 2:33 PM, Daniel McCarney 
> wrote:
>
>> Hi Ilari,
>>
>>
>>> This impiles that if pre-authorization is not supported, newAuthz better
>>> be absent (this is also useful for detecting pre-authorization support if
>>> the client can use it somehow).
>>> I think this should be at least a SHOULD.
>>
>>
>> You're right. My intention is to make the presence of that field an
>> indicator of pre-authorization support (or lack thereof). I'll update to a
>> SHOULD in my PR since I agree that maps better.
>>
>> Thanks!
>>
>>
>>
>> On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara > > wrote:
>>
>>> On Fri, Jan 05, 2018 at 02:05:22PM -0500, Daniel McCarney wrote:
>>> > In Section 7.4.1 "Pre-Authorization" the spec says:
>>> >
>>> >  If a CA wishes to allow pre-authorization within ACME, it can offer
>>> > >  a "new authorization" resource in its directory by adding the field
>>> > >  "newAuthz" with a URL for the new authorization resource.
>>> >
>>> >
>>> > That text indicates that the CA may wish to *not* support
>>> pre-authorization
>>> > in which case the "newAuthz" resource will not be present in the
>>> directory.
>>> > E.g. the Let's Encrypt ACME v2 directory[0] does not include this
>>> resource.
>>> >
>>> > I think this should be further emphasized in Section 7.1.1 "Directory"
>>> > since this is where a developer is likely to look first when trying to
>>> > determine what directory fields can be assumed present.
>>> >
>>> > I opened a PR to add a small note about this to Section 7.1.1:
>>> > https://github.com/ietf-wg-acme/acme/pull/384
>>> >
>>> > This is perhaps a step past the line of being strictly editorial. I
>>> would
>>> > appreciate if anyone with objections raise them on-thread over the
>>> next few
>>> > days.
>>>
>>> Why MAY? If implementation does not support some functionality that an
>>> endpoint is exclusively for, it better omit that endpoint. This impiles
>>> that if pre-authorization is not supported, newAuthz better be absent
>>> (this is also useful for detecting pre-authorization support if the
>>> client can use it somehow).
>>>
>>> I think this should be at least a SHOULD.
>>>
>>>
>>>
>>> -Ilari
>>>
>>
>>
>> ___
>> 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] Clarify that newAuthz endpoint is optional

[Richard Barnes]

Why not a MUST? If you don't implement preauthorization, there's no need
for a value.  I guess you could provide "null", but ... don't.

On Fri, Jan 5, 2018 at 2:33 PM, Daniel McCarney  wrote:

> Hi Ilari,
>
>
>> This impiles that if pre-authorization is not supported, newAuthz better
>> be absent (this is also useful for detecting pre-authorization support if
>> the client can use it somehow).
>> I think this should be at least a SHOULD.
>
>
> You're right. My intention is to make the presence of that field an
> indicator of pre-authorization support (or lack thereof). I'll update to a
> SHOULD in my PR since I agree that maps better.
>
> Thanks!
>
>
>
> On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara 
> wrote:
>
>> On Fri, Jan 05, 2018 at 02:05:22PM -0500, Daniel McCarney wrote:
>> > In Section 7.4.1 "Pre-Authorization" the spec says:
>> >
>> >  If a CA wishes to allow pre-authorization within ACME, it can offer
>> > >  a "new authorization" resource in its directory by adding the field
>> > >  "newAuthz" with a URL for the new authorization resource.
>> >
>> >
>> > That text indicates that the CA may wish to *not* support
>> pre-authorization
>> > in which case the "newAuthz" resource will not be present in the
>> directory.
>> > E.g. the Let's Encrypt ACME v2 directory[0] does not include this
>> resource.
>> >
>> > I think this should be further emphasized in Section 7.1.1 "Directory"
>> > since this is where a developer is likely to look first when trying to
>> > determine what directory fields can be assumed present.
>> >
>> > I opened a PR to add a small note about this to Section 7.1.1:
>> > https://github.com/ietf-wg-acme/acme/pull/384
>> >
>> > This is perhaps a step past the line of being strictly editorial. I
>> would
>> > appreciate if anyone with objections raise them on-thread over the next
>> few
>> > days.
>>
>> Why MAY? If implementation does not support some functionality that an
>> endpoint is exclusively for, it better omit that endpoint. This impiles
>> that if pre-authorization is not supported, newAuthz better be absent
>> (this is also useful for detecting pre-authorization support if the
>> client can use it somehow).
>>
>> I think this should be at least a SHOULD.
>>
>>
>>
>> -Ilari
>>
>
>
> ___
> 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] Clarify that newAuthz endpoint is optional

[Daniel McCarney]

Hi Ilari,


> This impiles that if pre-authorization is not supported, newAuthz better
> be absent (this is also useful for detecting pre-authorization support if
> the client can use it somehow).
> I think this should be at least a SHOULD.


You're right. My intention is to make the presence of that field an
indicator of pre-authorization support (or lack thereof). I'll update to a
SHOULD in my PR since I agree that maps better.

Thanks!



On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara 
wrote:

> On Fri, Jan 05, 2018 at 02:05:22PM -0500, Daniel McCarney wrote:
> > In Section 7.4.1 "Pre-Authorization" the spec says:
> >
> >  If a CA wishes to allow pre-authorization within ACME, it can offer
> > >  a "new authorization" resource in its directory by adding the field
> > >  "newAuthz" with a URL for the new authorization resource.
> >
> >
> > That text indicates that the CA may wish to *not* support
> pre-authorization
> > in which case the "newAuthz" resource will not be present in the
> directory.
> > E.g. the Let's Encrypt ACME v2 directory[0] does not include this
> resource.
> >
> > I think this should be further emphasized in Section 7.1.1 "Directory"
> > since this is where a developer is likely to look first when trying to
> > determine what directory fields can be assumed present.
> >
> > I opened a PR to add a small note about this to Section 7.1.1:
> > https://github.com/ietf-wg-acme/acme/pull/384
> >
> > This is perhaps a step past the line of being strictly editorial. I would
> > appreciate if anyone with objections raise them on-thread over the next
> few
> > days.
>
> Why MAY? If implementation does not support some functionality that an
> endpoint is exclusively for, it better omit that endpoint. This impiles
> that if pre-authorization is not supported, newAuthz better be absent
> (this is also useful for detecting pre-authorization support if the
> client can use it somehow).
>
> I think this should be at least a SHOULD.
>
>
>
> -Ilari
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Clarify that newAuthz endpoint is optional

[Ilari Liusvaara]

On Fri, Jan 05, 2018 at 02:05:22PM -0500, Daniel McCarney wrote:
> In Section 7.4.1 "Pre-Authorization" the spec says:
> 
>  If a CA wishes to allow pre-authorization within ACME, it can offer
> >  a "new authorization" resource in its directory by adding the field
> >  "newAuthz" with a URL for the new authorization resource.
> 
> 
> That text indicates that the CA may wish to *not* support pre-authorization
> in which case the "newAuthz" resource will not be present in the directory.
> E.g. the Let's Encrypt ACME v2 directory[0] does not include this resource.
> 
> I think this should be further emphasized in Section 7.1.1 "Directory"
> since this is where a developer is likely to look first when trying to
> determine what directory fields can be assumed present.
> 
> I opened a PR to add a small note about this to Section 7.1.1:
> https://github.com/ietf-wg-acme/acme/pull/384
> 
> This is perhaps a step past the line of being strictly editorial. I would
> appreciate if anyone with objections raise them on-thread over the next few
> days.

Why MAY? If implementation does not support some functionality that an
endpoint is exclusively for, it better omit that endpoint. This impiles
that if pre-authorization is not supported, newAuthz better be absent
(this is also useful for detecting pre-authorization support if the
client can use it somehow).

I think this should be at least a SHOULD.



-Ilari

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

[Acme] Let's Encrypt draft-09 test endpoint

[Daniel McCarney]

The list may be interested to know Let's Encrypt has made a test
environment available based on ACME draft-09. The announcement post with
more details is available here:

https://community.letsencrypt.org/t/staging-endpoint-for-acme-v2/49605

Compatible clients can be configured with the following directory URL:

https://acme-staging-v02.api.letsencrypt.org/directory

Bugs & divergences from the spec are welcomed in the community forum:


https://community.letsencrypt.org/t/acme-v2-staging-server-known-bugs-issues/49640

And on the Boulder issue tracker:

https://github.com/letsencrypt/boulder/issues

Thanks!

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

[Acme] Clarify that newAuthz endpoint is optional

[Daniel McCarney]

In Section 7.4.1 "Pre-Authorization" the spec says:

 If a CA wishes to allow pre-authorization within ACME, it can offer
>  a "new authorization" resource in its directory by adding the field
>  "newAuthz" with a URL for the new authorization resource.


That text indicates that the CA may wish to *not* support pre-authorization
in which case the "newAuthz" resource will not be present in the directory.
E.g. the Let's Encrypt ACME v2 directory[0] does not include this resource.

I think this should be further emphasized in Section 7.1.1 "Directory"
since this is where a developer is likely to look first when trying to
determine what directory fields can be assumed present.

I opened a PR to add a small note about this to Section 7.1.1:
https://github.com/ietf-wg-acme/acme/pull/384

This is perhaps a step past the line of being strictly editorial. I would
appreciate if anyone with objections raise them on-thread over the next few
days.

- Daniel / cpu

[0] - https://acme-staging-v02.api.letsencrypt.org/directory
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme