Re: [Acme] [Technical Errata Reported] RFC8555 (7565)

[Richard Barnes]

This seems correct to me.  I would mark it Verified.

On Thu, Jul 13, 2023 at 12:19 PM RFC Errata System <
rfc-edi...@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7565
>
> --
> Type: Technical
> Reported by: Paul Breed 
>
> Section: 8.1
>
> Original Text
> -
>  The "Thumbprint" step indicates the computation specified in
>[RFC7638], using the SHA-256 digest [FIPS180-4].  As noted in
>[RFC7518] any prepended zero octets in the fields of a JWK object
>MUST be stripped before doing the computation.
>
> Corrected Text
> --
> The "Thumbprint" step indicates the computation specified in
>[RFC7638], using the SHA-256 digest [FIPS180-4].  As noted in
>[RFC7518] any additional prepended zero octets in the fields of a JWK
> object
>MUST be stripped before doing the computation.
>Fixed length fields such as found in ECDSA keys should be their natural
> length and
>leading zero octets should not be stripped.
>
> Notes
> -
> This comment was really aimed at the leading 0 octet sometimes used with
> RSA, but the comment is not RSA specific. ECDSA keys can have fixed length
> fields (X,Y) where there can be leading zeros.  This led me astray in
> implementing an ECDSA thumbprint routine for ACME. The result was that
> 1/128 ECDSA keys failed to generate t humbp[rint as leading zeros were
> removed.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8555 (draft-ietf-acme-acme-18)
> --
> Title   : Automatic Certificate Management Environment (ACME)
> Publication Date: March 2019
> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
> Category: PROPOSED STANDARD
> Source  : Automated Certificate Management Environment
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] [Technical Errata Reported] RFC8555 (7565)

[RFC Errata System]

The following errata report has been submitted for RFC8555,
"Automatic Certificate Management Environment (ACME)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7565

--
Type: Technical
Reported by: Paul Breed 

Section: 8.1

Original Text
-
 The "Thumbprint" step indicates the computation specified in
   [RFC7638], using the SHA-256 digest [FIPS180-4].  As noted in
   [RFC7518] any prepended zero octets in the fields of a JWK object
   MUST be stripped before doing the computation.

Corrected Text
--
The "Thumbprint" step indicates the computation specified in
   [RFC7638], using the SHA-256 digest [FIPS180-4].  As noted in
   [RFC7518] any additional prepended zero octets in the fields of a JWK object
   MUST be stripped before doing the computation.  
   Fixed length fields such as found in ECDSA keys should be their natural 
length and 
   leading zero octets should not be stripped.

Notes
-
This comment was really aimed at the leading 0 octet sometimes used with RSA, 
but the comment is not RSA specific. ECDSA keys can have fixed length fields 
(X,Y) where there can be leading zeros.  This led me astray in implementing an 
ECDSA thumbprint routine for ACME. The result was that 1/128 ECDSA keys failed 
to generate t humbp[rint as leading zeros were removed.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8555 (draft-ietf-acme-acme-18)
--
Title   : Automatic Certificate Management Environment (ACME)
Publication Date: March 2019
Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
Category: PROPOSED STANDARD
Source  : Automated Certificate Management Environment
Area: Security
Stream  : IETF
Verifying Party : IESG

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

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

[internet-drafts]

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

   Title   : ACME Integrations for Device Certificate Enrollment
   Authors : Owen Friel
 Richard Barnes
 Rifaat Shekh-Yusef
 Michael Richardson
   Filename: draft-ietf-acme-integrations-17.txt
   Pages   : 23
   Date: 2023-07-13

Abstract:
   This document outlines multiple advanced use cases and integrations
   that ACME facilitates without any modifications or enhancements
   required to the base ACME specification.  The use cases include ACME
   integration with EST, BRSKI and TEAP.

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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-acme-integrations-17

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-integrations-17

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

Re: [Acme] [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Paul van Brouwershaven]

> Thinking some more, I realized that in addition to explicitly considering how 
> issuewild works with this, we also need to consider issueemail.  This does 
> bring up the question of whether these are better as parameters of the 
> various issue tags, or whether we’re better off separating this out into a 
> new "acme-discovery” tag that can be applied across all issuance types.  
> There are pros and cons.  The parameter method makes it easier to be able to 
> have different issuance policies for web and email, which is the entire 
> reason we have separate tags for each.  But I think it’s likely the same 
> server is going to get populated for all the tags, leading to redundancy and 
> potential maintenance issues keeping them in sync.  Or perhaps there’s both a 
> global setting and parameters, although then you get a lot of additional 
> complexity that probably isn’t worth it.  On balance, my gut feeling is that 
> parameters that are handled uniformly across all three issuance tags is 
> probably the best solution, but it could use more discussion and analysis I 
> think.  So I wanted to bring it up.

I would suggest keeping this simple, the different properties with 'issue' 
actually meaning 'issuetls' and no way to block all issuance with a simple 
'issue' property is already confusing enough.

> The other question that occurred to me last night is since this draft is 
> largely about CAA records and tags, and only linked to the ACME protocol 
> itself in its motivation, LAMPS might actually be a better home for the 
> draft, so it lives in the same WG as all the other CAA documents and 
> registries.  But I don’t have strong feelings about that and if people want 
> to continue discussing it at ACME instead, because that’s the motivating use 
> case, I’m fine with that too.

The goal here is ACME discovery,  the draft mostly specifies how the ACME 
client should process the CAA records, so I would keep this in the ACME working 
group unless you want to split this up into multiple standards.


From: Tim Hollebeek 
Sent: Thursday, July 13, 2023 16:07
To: Paul van Brouwershaven ; Seo Suchan 
; Mike Ounsworth ; acme@ietf.org 

Subject: RE: [Acme] [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


A few more comments:



Thinking some more, I realized that in addition to explicitly considering how 
issuewild works with this, we also need to consider issueemail.  This does 
bring up the question of whether these are better as parameters of the various 
issue tags, or whether we’re better off separating this out into a new 
"acme-discovery” tag that can be applied across all issuance types.  There are 
pros and cons.  The parameter method makes it easier to be able to have 
different issuance policies for web and email, which is the entire reason we 
have separate tags for each.  But I think it’s likely the same server is going 
to get populated for all the tags, leading to redundancy and potential 
maintenance issues keeping them in sync.  Or perhaps there’s both a global 
setting and parameters, although then you get a lot of additional complexity 
that probably isn’t worth it.  On balance, my gut feeling is that parameters 
that are handled uniformly across all three issuance tags is probably the best 
solution, but it could use more discussion and analysis I think.  So I wanted 
to bring it up.



The other question that occurred to me last night is since this draft is 
largely about CAA records and tags, and only linked to the ACME protocol itself 
in its motivation, LAMPS might actually be a better home for the draft, so it 
lives in the same WG as all the other CAA documents and registries.  But I 
don’t have strong feelings about that and if people want to continue discussing 
it at ACME instead, because that’s the motivating use case, I’m fine with that 
too.



-Tim



From: Acme  On Behalf Of Paul van Brouwershaven
Sent: Thursday, July 13, 2023 5:07 AM
To: Seo Suchan ; Tim Hollebeek ; 
Mike Ounsworth ; acme@ietf.org
Subject: Re: [Acme] [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



> so It would mean all of parameter definitions can be applied to issuewild 
> too, and if there is only they will be considered?



Yes, the regular CAA selection MUST be followed, or the CA might not be 
authorized to issue the certificate after all.



The parameters can be applied to any CAA property (issue, issuewild, vmc, 
issuemail, etc.) as long as the ACME client supports the protocol, and the CA 
supports the issuance.





From: Seo Suchan mailto:tjtn...@gmail.com>>
Sent: Thursday, July 13, 2023 09:54
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>; 
Tim Hollebeek mailto:tim.holleb...@digicert.com>>; 
Tim Hollebeek mailto:tim.holleb...@digicert.com>>; 
Mike Ounsworth mailto:mike.ounswo...@entrust.com>>; 
acme@ietf.org

Re: [Acme] [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Tim Hollebeek]

I'll accept that the terms of service stuff is already in one ACME spec, so it 
might as well be in all of them.  So I'll retract my suggestion to remove it.

On the issue of 'issuewild', I don't think just stating that the records are 
retrieved according to RFC 8659 is sufficient, because then neither that draft 
nor this one provides any guidance about whether the new parameters can be used 
with issuewild or not.  I think the draft needs to be clear about the 
suitability of the new parameters for each of the issue types, not just 'issue' 
itself.

As you note that's probably a pretty fast fix, just make it explicitly clear 
it's ok, and provide an example.

-Tim

I don't think 8.4.1/2 is in scope or makes the document better.  There are a
wide variety of contractual solutions here, and how a user agrees to a
particular CA's terms of service is not a relevant topic for IETF.
This consideration is included because RFC 8659 section 
7.3.3. describes the 
acceptance of the terms of service, while section 10.5 is also clear that CAs 
need to keep in mind that ACME clients can automate this agreement, possibly 
not involving a human user.

I'm ok to remove or replace this with a more generic comment, any thoughts from 
anyone on this?
Oops, I forgot the most important one.  The draft ignores the existence of the
"issuewild" tag.  This won't work, because both issue and issuewild work 
together
in RFC 8659.  See, for example, section 4.3, third paragraph.  There's a 
requirement
to ignore "issue" records in certain circumstances, and it's not clear how that 
would
interact with the "issue" tags specified in this draft.  I think explicit 
consideration of
issuewild and how it would work together with this draft and RFC 8659 is needed.

This is especially important because ACME can be used in conjunction with the
 issuance of wildcard certificates, and this draft probably needs to specify how
things work for that, too.
I don't think that the draft doesn't ignores this, section 5 item 1 starts with:

1. The ACME client initiates a DNS lookup to retrieve the CAA record(s) 
according to [RFC8659]

where RFC8659 specifies the details on how CAA records must be checked. But I 
agree that this could be made more explicit, I added an example to describe 
this scenario in more detail.

Do you think that is sufficient or should we add in introduction to section 5 
or update item 2 with a normative requirement that the ACME MUST follow RFC8659 
when selecting the valid CAA records for the domain.


From: Tim Hollebeek 
mailto:tim.holleb...@digicert.com>>
Sent: Wednesday, July 12, 2023 22:45
To: Tim Hollebeek 
mailto:tim.hollebeek=40digicert@dmarc.ietf.org>>;
 Mike Ounsworth 
mailto:Mike.Ounsworth=40entrust@dmarc.ietf.org>>;
 acme@ietf.org mailto:acme@ietf.org>>
Cc: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>
Subject: RE: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

Oops, I forgot the most important one.  The draft ignores the existence of the
"issuewild" tag.  This won't work, because both issue and issuewild work 
together
in RFC 8659.  See, for example, section 4.3, third paragraph.  There's a 
requirement
to ignore "issue" records in certain circumstances, and it's not clear how that 
would
interact with the "issue" tags specified in this draft.  I think explicit 
consideration of
issuewild and how it would work together with this draft and RFC 8659 is needed.

This is especially important because ACME can be used in conjunction with the
 issuance of wildcard certificates, and this draft probably needs to specify how
things work for that, too.

-Tim

> -Original Message-
> From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of 
> Tim Hollebeek
> Sent: Wednesday, July 12, 2023 4:32 PM
> To: Mike Ounsworth 
> mailto:Mike.Ounsworth=40entrust@dmarc.ietf.org>>;
> acme@ietf.org
> Cc: Paul van Brouwershaven 
> mailto:paul.vanbrouwersha...@entrust.com>>
> Subject: Re: [Acme] [EXTERNAL] New Version Notification for draft-
> vanbrouwershaven-acme-auto-discovery-00.txt
>
> Some REALLY quick comments from a brief read:
>
> First, I think this is pretty clearly standards track, especially since I 
> expect the
> authors are willing to work together with the IETF community and respond to
> feedback, and it includes normative requirements that are intended to be
> used with a major ecosystem, the WebPKI.
>
> 3.1.1. recommend clarifying the extent to which case matters.  How should
> "TRUE" or "True" be handled?
>
> 4-5. This is WAY in the weeds, and possibly should just be ignored, but 
> there's
> actually no requirement that the CA is able to host content at the domain
> specified in the CAA tag.  At a minimum, they're only required to have
> permission from the domain owner (RFC 8659, first paragraph, item 2, sec

Re: [Acme] [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Tim Hollebeek]

A few more comments:

Thinking some more, I realized that in addition to explicitly considering how 
issuewild works with this, we also need to consider issueemail.  This does 
bring up the question of whether these are better as parameters of the various 
issue tags, or whether we’re better off separating this out into a new 
"acme-discovery” tag that can be applied across all issuance types.  There are 
pros and cons.  The parameter method makes it easier to be able to have 
different issuance policies for web and email, which is the entire reason we 
have separate tags for each.  But I think it’s likely the same server is going 
to get populated for all the tags, leading to redundancy and potential 
maintenance issues keeping them in sync.  Or perhaps there’s both a global 
setting and parameters, although then you get a lot of additional complexity 
that probably isn’t worth it.  On balance, my gut feeling is that parameters 
that are handled uniformly across all three issuance tags is probably the best 
solution, but it could use more discussion and analysis I think.  So I wanted 
to bring it up.

The other question that occurred to me last night is since this draft is 
largely about CAA records and tags, and only linked to the ACME protocol itself 
in its motivation, LAMPS might actually be a better home for the draft, so it 
lives in the same WG as all the other CAA documents and registries.  But I 
don’t have strong feelings about that and if people want to continue discussing 
it at ACME instead, because that’s the motivating use case, I’m fine with that 
too.

-Tim

From: Acme  On Behalf Of Paul van Brouwershaven
Sent: Thursday, July 13, 2023 5:07 AM
To: Seo Suchan ; Tim Hollebeek ; 
Mike Ounsworth ; acme@ietf.org
Subject: Re: [Acme] [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

> so It would mean all of parameter definitions can be applied to issuewild 
> too, and if there is only they will be considered?

Yes, the regular CAA selection MUST be followed, or the CA might not be 
authorized to issue the certificate after all.

The parameters can be applied to any CAA property (issue, issuewild, vmc, 
issuemail, etc.) as long as the ACME client supports the protocol, and the CA 
supports the issuance.


From: Seo Suchan mailto:tjtn...@gmail.com>>
Sent: Thursday, July 13, 2023 09:54
To: Paul van Brouwershaven 
mailto:paul.vanbrouwersha...@entrust.com>>; 
Tim Hollebeek mailto:tim.holleb...@digicert.com>>; 
Tim Hollebeek mailto:tim.holleb...@digicert.com>>; 
Mike Ounsworth mailto:mike.ounswo...@entrust.com>>; 
acme@ietf.org mailto:acme@ietf.org>>
Subject: Re: [Acme] [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


so It would mean all of parameter definitions can be applied to issuewild too, 
and if there is only they will be considered?
2023-07-13 오후 4:47에 Paul van Brouwershaven 이(가) 쓴 글:
3.1.1. recommend clarifying the extent to which case matters.  How should
"TRUE" or "True" be handled?
The document now specifies that this must be a lower-case Boolean
4-5. This is WAY in the weeds, and possibly should just be ignored, but
there's actually no requirement that the CA is able to host content at
the domain specified in the CAA tag.  At a minimum, they're only required
to have permission from the domain owner (RFC 8659, first paragraph,
item 2, second clause).  This might actually even happen due to
acquisitions.  In such situations, a CA might actually be unable to host
content on a .well-known URL for a tag it uses.
CAs could instruct the user to use a new CAA issuer-domain and they pro
Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Paul van Brouwershaven]

> so It would mean all of parameter definitions can be applied to issuewild 
> too, and if there is only they will be considered?

Yes, the regular CAA selection MUST be followed, or the CA might not be 
authorized to issue the certificate after all.

The parameters can be applied to any CAA property (issue, issuewild, vmc, 
issuemail, etc.) as long as the ACME client supports the protocol, and the CA 
supports the issuance.


From: Seo Suchan 
Sent: Thursday, July 13, 2023 09:54
To: Paul van Brouwershaven ; Tim Hollebeek 
; Tim Hollebeek ; Mike 
Ounsworth ; acme@ietf.org 
Subject: Re: [Acme] [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


so It would mean all of parameter definitions can be applied to issuewild too, 
and if there is only they will be considered?

2023-07-13 오후 4:47에 Paul van Brouwershaven 이(가) 쓴 글:
3.1.1. recommend clarifying the extent to which case matters.  How should
"TRUE" or "True" be handled?
The document now specifies that this must be a lower-case Boolean
4-5. This is WAY in the weeds, and possibly should just be ignored, but
there's actually no requirement that the CA is able to host content at
the domain specified in the CAA tag.  At a minimum, they're only required
to have permission from the domain owner (RFC 8659, first paragraph,
item 2, second clause).  This might actually even happen due to
acquisitions.  In such situations, a CA might actually be unable to host
content on a .well-known URL for a tag it uses.
CAs could instruct the user to use a new CAA issuer-domain and they pro
Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Paul van Brouwershaven]

I have rewritten items 3.x in section 
5.1
 and hope this makes it easier to understand, the 
example
 is also slightly updated but might no longer be needed, what do you think?



From: Carl Wallace 
Sent: Wednesday, July 12, 2023 22:02
To: Paul van Brouwershaven ; Mike Ounsworth 
; acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt


The example is good, but it doesn’t quite get at the issue. I think the 
problematic text is “if no common CA is found.” In the example, there is a 
common CA, there are just different priorities. It does help clarify the “as 
few domains” part though. Maybe something like “if all domains do not prefer 
the same CA, the ACME client tries…” would be more clear.



From: Paul van Brouwershaven 
Date: Wednesday, July 12, 2023 at 2:30 PM
To: Carl Wallace , Mike Ounsworth 
, "acme@ietf.org" 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



>> - In 5.1, what does 3.b mean? Can you add an example?
> I will try to add an example here.



Does this example help to clarify the intend of 3.b?

https://vanbroup.github.io/acme-auto-discovery/draft-vanbrouwershaven-acme-auto-discovery.html#name-selecting-a-common-ca-throu



The other changes have also been incorporated.





From: Paul van Brouwershaven 
Sent: Wednesday, July 12, 2023 18:16
To: Carl Wallace ; Mike Ounsworth 
; acme@ietf.org 
Subject: Re: [Acme] FW: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt



Thanks for your detailed review!

- Why is the draft informational and not standards track?

Most people I spoke to, while discussing the idea, thought that it would need 
to be information, but if people here feel that this needs to be changed to 
standards track, I'm fine with that too. I'm relatively new to the drafting 
process.

- Why does absence turn the feature on? Wouldn't this invite sending spurious 
requests for ACME information to CAs configured before this draft existed that 
do not support ACME?

The reason is that with the move to shorter live certificates, automation will 
become essential. If we default to off, we will likely only see CAA records 
with this option enabled.



The benefit of these spurious requests is that it would give a clear signal to 
these CAs that they might need to adopt ACME and/or auto discovery, something 
that is also pushed by the root programs.



If an account binding is required (which is the case for most commercial CAs) 
the user will be asked to establish this binding, but no certificates will be 
issued until the account binding is established. When no account binding is 
required, the certificate will automatically be replaced by the authorized CA.



See also the security considerations in section 8.1.

- Is a boolean the right type for discovery or should it be a string that 
indicates the protocol that is the target of auto-discovery?

The protocol is already indicated by the property (i.e., issue, issuewild, vmc, 
issuemail, etc.)


- Do/ought parent domains apply (as they do in CAA)? If not, it might be worth 
a few words since the usage here is different.

Yes they do, section 5 states "The ACME client initiates a DNS lookup to 
retrieve the CAA record(s) according to [RFC8659]", which specifies how CAA 
lookups need to be performed.

- In the next to last example in 3.2, why does EV without priority go first?

It should not, we updated the logic later, I will get this corrected by 
including a priority here as well.

- In 5.1, you might want to replace the long paragraph with bullets.

This is fixed on 
GitHub
 and will be included in the next release.

- In 5.1, what does 3.b mean? Can you add an example?

I will try to add an example here.

- You should expand QWAC on first use and maybe add an informational reference.

Yes, I will add the meaning of the abbreviations and maybe a reference there.



Thanks,



Paul





From: Carl Wallace 
Sent: Wednesday, July 12, 2023 17:48
To: Mike Ounsworth ; acme@ietf.org 

Cc: Paul van Brouwershaven 
Subject: Re: [Acme] FW: [EXTE

Re: [Acme] [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Seo Suchan]

so It would mean all of parameter definitions can be applied to 
issuewild too, and if there is only they will be considered?


2023-07-13 오후 4:47에 Paul van Brouwershaven 이(가) 쓴 글:


3.1.1. recommend clarifying the extent to which case matters.  How
should
"TRUE" or "True" be handled?

The document now specifies that this must be a lower-case Boolean

4-5. This is WAY in the weeds, and possibly should just be
ignored, but
there's actually no requirement that the CA is able to host content at
the domain specified in the CAA tag.  At a minimum, they're only
required
to have permission from the domain owner (RFC 8659, first paragraph,
item 2, second clause).  This might actually even happen due to
acquisitions.  In such situations, a CA might actually be unable
to host
content on a .well-known URL for a tag it uses.

CAs could instruct the user to use a new CAA issuer-domain and they pro___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [EXTERNAL] New Version Notification for draft-vanbrouwershaven-acme-auto-discovery-00.txt

[Paul van Brouwershaven]

First, I think this is pretty clearly standards track, especially since I expect
the authors are willing to work together with the IETF community and
respond to feedback, and it includes normative requirements that are
intended to be used with a major ecosystem, the WebPKI.
I have updated the draft from informational to standards track.
3.1.1. recommend clarifying the extent to which case matters.  How should
"TRUE" or "True" be handled?
The document now specifies that this must be a lower-case Boolean
4-5. This is WAY in the weeds, and possibly should just be ignored, but
there's actually no requirement that the CA is able to host content at
the domain specified in the CAA tag.  At a minimum, they're only required
to have permission from the domain owner (RFC 8659, first paragraph,
item 2, second clause).  This might actually even happen due to
acquisitions.  In such situations, a CA might actually be unable to host
content on a .well-known URL for a tag it uses.
CAs could instruct the user to use a new CAA issuer-domain and they probably 
would prefer users to update their CAA record anyway. If an acquisition happens 
after this document is adopted, and the discovery information/redirect is 
already in place, this could be covered by contractual arrangements.
I don't think 8.4.1/2 is in scope or makes the document better.  There are a
wide variety of contractual solutions here, and how a user agrees to a
particular CA's terms of service is not a relevant topic for IETF.
This consideration is included because RFC 8659 section 
7.3.3. describes the 
acceptance of the terms of service, while section 10.5 is also clear that CAs 
need to keep in mind that ACME clients can automate this agreement, possibly 
not involving a human user.

I'm ok to remove or replace this with a more generic comment, any thoughts from 
anyone on this?
Oops, I forgot the most important one.  The draft ignores the existence of the
"issuewild" tag.  This won't work, because both issue and issuewild work 
together
in RFC 8659.  See, for example, section 4.3, third paragraph.  There's a 
requirement
to ignore "issue" records in certain circumstances, and it's not clear how that 
would
interact with the "issue" tags specified in this draft.  I think explicit 
consideration of
issuewild and how it would work together with this draft and RFC 8659 is needed.

This is especially important because ACME can be used in conjunction with the
 issuance of wildcard certificates, and this draft probably needs to specify how
things work for that, too.
I don't think that the draft doesn't ignores this, section 5 item 1 starts with:

1. The ACME client initiates a DNS lookup to retrieve the CAA record(s) 
according to [RFC8659]

where RFC8659 specifies the details on how CAA records must be checked. But I 
agree that this could be made more explicit, I added an example to describe 
this scenario in more detail.

Do you think that is sufficient or should we add in introduction to section 5 
or update item 2 with a normative requirement that the ACME MUST follow RFC8659 
when selecting the valid CAA records for the domain.


From: Tim Hollebeek 
Sent: Wednesday, July 12, 2023 22:45
To: Tim Hollebeek ; Mike Ounsworth 
; acme@ietf.org 
Cc: Paul van Brouwershaven 
Subject: RE: [EXTERNAL] New Version Notification for 
draft-vanbrouwershaven-acme-auto-discovery-00.txt

Oops, I forgot the most important one.  The draft ignores the existence of the
"issuewild" tag.  This won't work, because both issue and issuewild work 
together
in RFC 8659.  See, for example, section 4.3, third paragraph.  There's a 
requirement
to ignore "issue" records in certain circumstances, and it's not clear how that 
would
interact with the "issue" tags specified in this draft.  I think explicit 
consideration of
issuewild and how it would work together with this draft and RFC 8659 is needed.

This is especially important because ACME can be used in conjunction with the
 issuance of wildcard certificates, and this draft probably needs to specify how
things work for that, too.

-Tim

> -Original Message-
> From: Acme  On Behalf Of Tim Hollebeek
> Sent: Wednesday, July 12, 2023 4:32 PM
> To: Mike Ounsworth ;
> acme@ietf.org
> Cc: Paul van Brouwershaven 
> Subject: Re: [Acme] [EXTERNAL] New Version Notification for draft-
> vanbrouwershaven-acme-auto-discovery-00.txt
>
> Some REALLY quick comments from a brief read:
>
> First, I think this is pretty clearly standards track, especially since I 
> expect the
> authors are willing to work together with the IETF community and respond to
> feedback, and it includes normative requirements that are intended to be
> used with a major ecosystem, the WebPKI.
>
> 3.1.1. recommend clarifying the extent to which case matters.  How should
> "TRUE" or "True" be handled?
>
> 4-5. This is WAY in the weeds, and possibly should just be ignored, but 
> there's
> a