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

[Paul van Brouwershaven <[e-mail]>]

> 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 <tim.hollebeek=[e-mail]>
Sent: Thursday, July 13, 2023 16:07
To: Paul van Brouwershaven <[e-mail]>; Seo Suchan <[e-mail]>; Mike Ounsworth <[e-mail]>; [e-mail] <[e-mail]>
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 <[e-mail]> On Behalf Of Paul van Brouwershaven
Sent: Thursday, July 13, 2023 5:07 AM
To: Seo Suchan <[e-mail]>; Tim Hollebeek <[e-mail]>; Mike Ounsworth <[e-mail]>; [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, July 13, 2023 09:54
To: Paul van Brouwershaven <[e-mail]<mailto:[e-mail]>>; Tim Hollebeek <[e-mail]<mailto:[e-mail]>>; Tim Hollebeek <[e-mail]<mailto:[e-mail]>>; Mike Ounsworth <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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.