Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding
draft-ietf-acme-caa-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-10-01
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-08-26
|
10 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Sarah Banks was marked no-response |
2019-08-12
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-08-08
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-06-22
|
10 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Hilarie Orman. |
2019-06-20
|
10 | Hugo Landau | New version available: draft-ietf-acme-caa-10.txt |
2019-06-20
|
10 | (System) | New version approved |
2019-06-20
|
10 | (System) | Request for posting confirmation emailed to previous authors: Hugo Landau |
2019-06-20
|
10 | Hugo Landau | Uploaded new revision |
2019-06-20
|
09 | (System) | RFC Editor state changed to EDIT |
2019-06-20
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-06-20
|
09 | (System) | Announcement was received by RFC Editor |
2019-06-20
|
09 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2019-06-20
|
09 | (System) | IANA Action state changed to In Progress |
2019-06-20
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-06-20
|
09 | Cindy Morgan | IESG has approved the document |
2019-06-20
|
09 | Cindy Morgan | Closed "Approve" ballot |
2019-06-20
|
09 | Cindy Morgan | Ballot approval text was generated |
2019-06-20
|
09 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-06-18
|
09 | Benjamin Kaduk | [Ballot comment] Thanks for addressing my Discuss (and Comment!) points! While adding the discussion of the privacy considerations of publishing account URLs suffices to clear … [Ballot comment] Thanks for addressing my Discuss (and Comment!) points! While adding the discussion of the privacy considerations of publishing account URLs suffices to clear my discuss point, I will mention that if we wanted to obscure or anonymize the published information relating to specific account, there are pretty standard ways to do so and I'm happy to talk about it if that's desired. |
2019-06-18
|
09 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-06-16
|
09 | Hugo Landau | New version available: draft-ietf-acme-caa-09.txt |
2019-06-16
|
09 | (System) | New version approved |
2019-06-16
|
09 | (System) | Request for posting confirmation emailed to previous authors: Hugo Landau |
2019-06-16
|
09 | Hugo Landau | Uploaded new revision |
2019-05-30
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-05-30
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-05-30
|
08 | Hugo Landau | New version available: draft-ietf-acme-caa-08.txt |
2019-05-30
|
08 | (System) | New version approved |
2019-05-30
|
08 | (System) | Request for posting confirmation emailed to previous authors: Hugo Landau |
2019-05-30
|
08 | Hugo Landau | Uploaded new revision |
2019-05-30
|
07 | Warren Kumari | [Ballot comment] Thank you for addressing my DISCUSS position. |
2019-05-30
|
07 | Warren Kumari | [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss |
2019-05-30
|
07 | Barry Leiba | [Ballot comment] — Section 4 — If appropriate non-ACME identifiers are not present in the ACME Validation Methods IANA registry, the CA MUST … [Ballot comment] — Section 4 — If appropriate non-ACME identifiers are not present in the ACME Validation Methods IANA registry, the CA MUST use identifiers beginning with the string "ca-", which are defined to have CA- specific meaning. Would it be reasonable to recommend not just "ca-", but "ca--"? Experience has shown that if "flarb" is a common thing among CAs (or whatever) and Verisign implements a "ca-flarb", that will tend to leak and become an unregistered standard... but that's far less likely to happen if it's "ca-verisign-flarb". I'm not suggesting any formalization nor registry for the part, but just the fact that it's included tends to get us away from the problem that BCP 178 is addressing. This is no longer at DISCUSS level, and if the working group thinks this isn't a good idea, go ahead as planned. But please chew it over a bit and see if you can swallow it. — Section 6 — I have no idea what you’re trying to say here. This is a Proposed Standard, right? It defines two new parameters. Are you now trying to say that we have not really defined anything? I don’t understand. No longer a DISCUSS, and no need for further response, but if you can re-word this to explain the situation a bit better, that'd be great. --------------------------------------------- === These have been resolved and/or explained; thanks for that === — Section 5.4 — CAs MUST satisfy this requirement by using URIs which include an authority: "https://a.example.com/account/1234" First (this is not the DISCUSS part), readers who are not extremely familiar with how URIs are constructed — and given that “authority” is a normal English word with a meaning outside the URI world — might not really understand what you mean here. A reference will help, and I suggest it” “…include an authority (see Section 3.2 of [RFC3986])”. Second (this is the DISCUSS part), does this mean that all CAs MUST use URIs that include an authority? Or does it only apply to those with the sort of situation you describe in this section? If the latter, it seems odd that you’re prescribing, at MUST level, a particular solution, where there are certainly others (such as ensuring that the account numbers are unique in the first place). (General: I hope the RFC Editor will be changing most “which” in this document to “that”, according to the Chicago Manual of Style, but I’ll let the RFC Editor address those.) (Also general: For a very short document, this was quite a difficult read. There are quite a few very long, heavy, hard-to-parse sentences, with lots of things run together. While the sentences are grammatically correct, they’re harder on the reader than they ought to be. Picking one of many as an example: Because CAA records are located during validation by walking up the DNS hierarchy until one or more records are found, the use of the "accounturi" and "validationmethods" parameters, or any CAA policy, is not an effective way to restrict or control issuance for subdomains of a domain, where control over those subdomains is delegated to another party (such as via DNS delegation or by providing limited access to manage subdomain DNS records). That’s one sentence. The document in general would benefit from breaking up those sorts of sentences to make it easier to get the sense of what it’s trying to say. For example, the above might go something like this: CAA records are located during validation by walking up the DNS hierarchy until one or more records are found. Sometimes, control over subdomains of a domain is delegated to another party — via DNS delegation, or by providing limited access to manage subdomain DNS records. In those cases CAA policy, including the use of the "accounturi" and "validationmethods" parameters, is not an effective way to restrict or control issuance for subdomains. ) — Section 3 — "CA account" means an object maintained by a specific CA representing a specific entity, or group of related entities, which may request the issuance of certificates. I’m not clear on what the “which” clause goes with: 1. Do you mean that the “specific CA” may request the issuance? 2. Do you mean that the entity or group of entities may request it? 3. Do you mean that the object may be used to request the issuance? Some of this confusion might come from the that/which issue, but I think it’s really the structure of the sentence. I suggest that you re-word the sentence to make it clearer. Maybe (assuming (2) above is correct): NEW A “CA account” is an object maintained by a specific CA, representing a specific entity or group of entities. Those entities may request the issuance of certificates from that CA. END A property with multiple "accounturi" parameters is unsatisfiable. OK, but why not say, then, that there MUST NOT be multiple “accounturi” parameters in a given property? — Section 3.2 — The use of specific kinds of URI may be specified in future RFCs, and CAs not implementing ACME MAY assign and recognise their own URIs arbitrarily. Isn’t this true of CAs that do implement ACME also? The “MAY” in Section 3.1 implies that, surely. -- Section 5.3 — A CA which is unable to ensure consistent processing of the "accounturi" or "validationmethods" parameters for a given CA domain name as specifiable in CAA "issue" or "issuewild" properties MUST NOT implement support for these parameters. Failure to do so will result in an implementation of these parameters which does not provide effective security. “Failure to do so” seems odd after “MUST NOT”. It also makes it sound as though failure to comply with a MUST NOT is an option. I suggest, “Otherwise, the CA would have an implementation…” — Section 5.8 — Because they express a restrictive security policy, misconfiguration of the "accounturi" or "validationmethods" parameters may result in legitimate issuance requests being refused. As written, “they” goes with “misconfiguration”, which is clearly not what you meant (I think you mean it to refer to “the … parameters”). NEW Because the "accounturi" or "validationmethods" parameters express a restrictive security policy, misconfiguration of them may result in legitimate issuance requests being refused. END |
2019-05-30
|
07 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2019-05-30
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-05-30
|
07 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-05-29
|
07 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2019-05-29
|
07 | Warren Kumari | [Ballot discuss] Firstly, thank you for writing this -- I do however have some concerns around Section "5.6. Use with and without DNSSEC" 1: "Where … [Ballot discuss] Firstly, thank you for writing this -- I do however have some concerns around Section "5.6. Use with and without DNSSEC" 1: "Where a domain chooses to secure its nameservers using DNSSEC, the authenticity of its DNS data can be assured, providing that a given CA makes all DNS resolutions via an appropriate, trusted DNSSEC-validating resolver." A: DNSSEC does *not* secure nameservers, it secures the DNS data itself (think object security vs channel security) -- I'd suggest "When a domain is signed using DNSSEC, the authenticity..." B: I'm confused what"appropriate" means in "appropriate, trusted DNSSEC validating resolver" -- if it is trusted I'd assume it is appropriate? Please explain. C: The way that a resolver signals to a client that it has performed validation (and that the answer validated) is to set a single bit (AD) in the response - this is obviously something which should not be relied upon for security sensitive stuff - I'd strongly suggest that i) there be some text around getting the responses from the resolver to the CA machine securely (e.g over DNS-over-TLS), or better yet ii) that the CA machine itself do the DNSSEC validation - there are many libraries / systems to make this easy, e.g Stubby, libunbound, etc. 2: "A domain can use this property to protect itself from the threat posed by a global adversary capable of performing man-in-the-middle attacks, ..." A: What is the purpose of "global" in "global adversary" -- I'm assuming it is trying to communicate something important here, but how is this different to a "local" adversary capable of performing man-in-the-middle attacks? 3: " Use of the "accounturi" or "validationmethods" parameters does not confer additional security against an attacker capable of performing a man-in-the-middle attack against all validation attempts made by a given CA which is authorized by CAA where: 1. A domain does not secure its nameservers using DNSSEC, or 2. That CA does not perform CAA validation using a trusted DNSSEC-validating resolver. Moreover, use of the "accounturi" or "validationmethods" parameters does not mitigate against man-in-the-middle attacks against CAs which do not validate CAA records, or which do not do so using a trusted DNSSEC-validating resolver, ..." Can this document simply say: "When using this method, CA's MUST use a DNSSEC-validating resolver"? -- it will a: make the protocol more secure and b: simplify a bunch of the document and c: isn't a large burden. During the so-called "DNSpionage" incident, it seems that a specific CA was chosen because it didn't do DNSSEC validation (or, perhaps would try validate, but would still issue if DNSSEC validation failed) -- see: https://mailman.nanog.org/pipermail/nanog/2019-March/099852.html |
2019-05-29
|
07 | Warren Kumari | [Ballot comment] Thank you again for writing this, and apologies for not balloting earlier - I've got a cold and am behind on my IETF … [Ballot comment] Thank you again for writing this, and apologies for not balloting earlier - I've got a cold and am behind on my IETF work. |
2019-05-29
|
07 | Warren Kumari | [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari |
2019-05-29
|
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-05-29
|
07 | Adam Roach | [Ballot comment] Thanks to everyone who worked on this extension. I support Barry's first DISCUSS point. Beyond that concern, I have only one comment. --------------------------------------------------------------------------- … [Ballot comment] Thanks to everyone who worked on this extension. I support Barry's first DISCUSS point. Beyond that concern, I have only one comment. --------------------------------------------------------------------------- §5.4: > Suppose that both CA A and CA B issue account URIs of the form > > "account-id:1234" This is a little concerning as an example, as "account-id" isn't a registered URI scheme. Consider instead using: urn:example:account-id:1234 |
2019-05-29
|
07 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-05-29
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-05-28
|
07 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-05-28
|
07 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-05-27
|
07 | Benjamin Kaduk | [Ballot discuss] I think we need to have some privacy considerations text about how this mechanism exposes ACME account URLs, which are otherwise intended to … [Ballot discuss] I think we need to have some privacy considerations text about how this mechanism exposes ACME account URLs, which are otherwise intended to be unguessable, in the public DNS view. While ACME is generally intended to remain secure in the face of such information disclosure, it does have potential to enable some forms of correlation attacks, and could lead to DoS attempts specific to a given account or accounts. |
2019-05-27
|
07 | Benjamin Kaduk | [Ballot comment] I support Barry's Discusses (noting in particular that the "ca-" prefix is not reserved for local use by RFC 8555). Did we … [Ballot comment] I support Barry's Discusses (noting in particular that the "ca-" prefix is not reserved for local use by RFC 8555). Did we consider supplying ABNF descriptions of the parameter values? In particular, this would unambiguously specify whether optional whitespace is admitted in the comma-separated list used by "validationmethods". The shepherd writeup notes that there used to be hyphens in "account-uri" and "accepted-challenges". It seems that rfc6844bis has expanded the grammar to allow such hyphens; do we want to revisit their removal from this document? Noting that rfc6844bis is also slated for approval on this week's telechat, it may be worth updating the references as well, regardless of the decision on hyphens. Section 3 The presence of this parameter constrains the property to which it is attached. Where a CAA property has an "accounturi" parameter, a CA MUST only consider that property to authorize issuance in the context of a given certificate issuance request if the CA recognises the URI specified as identifying the account making that request. nit: perhaps "URI specified in the value portion of the accounturi parameter" for maximum clarity? Section 4 The presence of this parameter constrains the property to which it is attached. A CA MUST only consider a property with the "validationmethods" parameter to authorize issuance where the name of the challenge method being used is one of the names listed in the comma-separated list. nit: I'm not sure that we've really defined "challenge method" in the sense it's used here. (We do define it in the sense of "names listed in the comma-separated list", but it seems like this usage is trying to refer to the actual actions taken by the CA to authorize the issuance request. Section 5.2 I think this section may be predicated on an understanding of CAA "issue"/"issuewild" parameters that does not match my own. (Note that this includes the possibility that my understanding is incorrect.) Specifically, my reading of draft-ietf-lamps-rfc6844bis-06 Section 4.2 indicates that a given paramter is only defined for usage in a CAA "issue" record at the explicit specification of the Issuer, and that the Issuer alone determines their semantics. So when this text says that parameters are not an effective control absent out-of-band establishment of support, that's either a non sequitur or a tautology -- nobody has any business adding parameters to an Issuer's CAA entry unless that Issuer has told them to do so, full stop. Granted, we are complicating things by providing a preestablished specification for a set of parameters that an Issuer may choose to incorporate by reference, but I don't see that as changing the fact that the parameters are still specific to the given Issuer (and their CAA entry). Similarly, "MUST NOT assume" and "SHOULD also document" are repeating requirements from rfc6844bis, when starting from my frame of reference (and thus would not need to use the normative capitalization). Section 5.7 This seems perhaps more appropriate in the core CAA specification than in this document. Conveniently, rfc6844bis is open and in IESG evaluation... |
2019-05-27
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-05-27
|
07 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-05-26
|
07 | Barry Leiba | [Ballot discuss] — Section 4 — If appropriate non-ACME identifiers are not present in the ACME Validation Methods IANA registry, the CA MUST … [Ballot discuss] — Section 4 — If appropriate non-ACME identifiers are not present in the ACME Validation Methods IANA registry, the CA MUST use identifiers beginning with the string "ca-", which are defined to have CA- specific meaning. Was the working group aware of BCP 178 (RFC 6648), and did they consider the “ca-“ prefix in that context? If so, how does the working group propose to avoid the problems outlined by BCP 178? — Section 5.4 — CAs MUST satisfy this requirement by using URIs which include an authority: "https://a.example.com/account/1234" First (this is not the DISCUSS part), readers who are not extremely familiar with how URIs are constructed — and given that “authority” is a normal English word with a meaning outside the URI world — might not really understand what you mean here. A reference will help, and I suggest it” “…include an authority (see Section 3.2 of [RFC3986])”. Second (this is the DISCUSS part), does this mean that all CAs MUST use URIs that include an authority? Or does it only apply to those with the sort of situation you describe in this section? If the latter, it seems odd that you’re prescribing, at MUST level, a particular solution, where there are certainly others (such as ensuring that the account numbers are unique in the first place). — Section 6 — I have no idea what you’re trying to say here. This is a Proposed Standard, right? It defines two new parameters. Are you now trying to say that we have not really defined anything? I don’t understand. |
2019-05-26
|
07 | Barry Leiba | [Ballot comment] (General: I hope the RFC Editor will be changing most “which” in this document to “that”, according to the Chicago Manual of Style, … [Ballot comment] (General: I hope the RFC Editor will be changing most “which” in this document to “that”, according to the Chicago Manual of Style, but I’ll let the RFC Editor address those.) (Also general: For a very short document, this was quite a difficult read. There are quite a few very long, heavy, hard-to-parse sentences, with lots of things run together. While the sentences are grammatically correct, they’re harder on the reader than they ought to be. Picking one of many as an example: Because CAA records are located during validation by walking up the DNS hierarchy until one or more records are found, the use of the "accounturi" and "validationmethods" parameters, or any CAA policy, is not an effective way to restrict or control issuance for subdomains of a domain, where control over those subdomains is delegated to another party (such as via DNS delegation or by providing limited access to manage subdomain DNS records). That’s one sentence. The document in general would benefit from breaking up those sorts of sentences to make it easier to get the sense of what it’s trying to say. For example, the above might go something like this: CAA records are located during validation by walking up the DNS hierarchy until one or more records are found. Sometimes, control over subdomains of a domain is delegated to another party — via DNS delegation, or by providing limited access to manage subdomain DNS records. In those cases CAA policy, including the use of the "accounturi" and "validationmethods" parameters, is not an effective way to restrict or control issuance for subdomains. ) — Section 3 — "CA account" means an object maintained by a specific CA representing a specific entity, or group of related entities, which may request the issuance of certificates. I’m not clear on what the “which” clause goes with: 1. Do you mean that the “specific CA” may request the issuance? 2. Do you mean that the entity or group of entities may request it? 3. Do you mean that the object may be used to request the issuance? Some of this confusion might come from the that/which issue, but I think it’s really the structure of the sentence. I suggest that you re-word the sentence to make it clearer. Maybe (assuming (2) above is correct): NEW A “CA account” is an object maintained by a specific CA, representing a specific entity or group of entities. Those entities may request the issuance of certificates from that CA. END A property with multiple "accounturi" parameters is unsatisfiable. OK, but why not say, then, that there MUST NOT be multiple “accounturi” parameters in a given property? — Section 3.2 — The use of specific kinds of URI may be specified in future RFCs, and CAs not implementing ACME MAY assign and recognise their own URIs arbitrarily. Isn’t this true of CAs that do implement ACME also? The “MAY” in Section 3.1 implies that, surely. -- Section 5.3 — A CA which is unable to ensure consistent processing of the "accounturi" or "validationmethods" parameters for a given CA domain name as specifiable in CAA "issue" or "issuewild" properties MUST NOT implement support for these parameters. Failure to do so will result in an implementation of these parameters which does not provide effective security. “Failure to do so” seems odd after “MUST NOT”. It also makes it sound as though failure to comply with a MUST NOT is an option. I suggest, “Otherwise, the CA would have an implementation…” — Section 5.8 — Because they express a restrictive security policy, misconfiguration of the "accounturi" or "validationmethods" parameters may result in legitimate issuance requests being refused. As written, “they” goes with “misconfiguration”, which is clearly not what you meant (I think you mean it to refer to “the … parameters”). NEW Because the "accounturi" or "validationmethods" parameters express a restrictive security policy, misconfiguration of them may result in legitimate issuance requests being refused. END |
2019-05-26
|
07 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2019-05-24
|
07 | Alvaro Retana | [Ballot comment] (1) I can't claim to fully understand the contents of this document. However, I find the use of Normative language in the following … [Ballot comment] (1) I can't claim to fully understand the contents of this document. However, I find the use of Normative language in the following sentence in the IANA Considerations confusing: "This document merely specifies a RECOMMENDED semantic for parameters..." First of all, there's nothing that can be Normatively enforced in that piece of text. Second, Sections 3-4, where the parameters are specified, are the appropriate place for the Normative specification. Solution: s/RECOMMENDED/recommended (2) I don't think that there's a significant impact, or any at all...but it seems to me that this document should reference draft-ietf-lamps-rfc6844bis instead of RFC6844. |
2019-05-24
|
07 | Alvaro Retana | Ballot comment text updated for Alvaro Retana |
2019-05-24
|
07 | Alvaro Retana | [Ballot comment] I can't claim to fully understand the contents of this document. However, I find the use of Normative language in the following sentence … [Ballot comment] I can't claim to fully understand the contents of this document. However, I find the use of Normative language in the following sentence in the IANA Considerations confusing: "This document merely specifies a RECOMMENDED semantic for parameters..." First of all, there's nothing that can be Normatively enforced in that piece of text. Second, Sections 3-4, where the parameters are specified, are the appropriate place for the Normative specification. Solution: s/RECOMMENDED/recommended |
2019-05-24
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-05-23
|
07 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Hilarie Orman |
2019-05-23
|
07 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Hilarie Orman |
2019-05-21
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-05-21
|
07 | Hugo Landau | New version available: draft-ietf-acme-caa-07.txt |
2019-05-21
|
07 | (System) | New version approved |
2019-05-21
|
07 | (System) | Request for posting confirmation emailed to previous authors: Hugo Landau |
2019-05-21
|
07 | Hugo Landau | Uploaded new revision |
2019-05-21
|
06 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-05-21
|
06 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2019-05-20
|
06 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-05-20
|
06 | Éric Vyncke | [Ballot comment] Hugo, thank you for the work put into this document. Adding some examples was a good idea. I found it interesting that the … [Ballot comment] Hugo, thank you for the work put into this document. Adding some examples was a good idea. I found it interesting that the security section represents roughly 50% of the document ;-) I have two comments and one nit. See below. == COMMENTS == -- Section 2 -- Please use RFC 8174 boiler template for this section ;-) -- Section 3 -- The word 'applicable' is used but never strictly defined. If defined in another document, please add a reference (perhaps in the section 2), else please define it. == NIT == -- abstract -- Expand CAA, CA in the abstract ? |
2019-05-20
|
06 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-05-17
|
06 | Amy Vezza | Placed on agenda for telechat - 2019-05-30 |
2019-05-17
|
06 | Roman Danyliw | Ballot has been issued |
2019-05-17
|
06 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2019-05-17
|
06 | Roman Danyliw | Created "Approve" ballot |
2019-05-17
|
06 | Roman Danyliw | Ballot writeup was changed |
2019-05-17
|
06 | Roman Danyliw | Ballot approval text was generated |
2019-04-11
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Hilarie Orman. |
2019-04-10
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-04-08
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2019-04-08
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-acme-caa-06, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-acme-caa-06, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-04-03
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sarah Banks |
2019-04-03
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sarah Banks |
2019-04-02
|
06 | Roni Even | Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list. |
2019-03-28
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2019-03-28
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2019-03-28
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2019-03-28
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2019-03-27
|
06 | Cindy Morgan | Shepherding AD changed to Roman Danyliw |
2019-03-27
|
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-03-27
|
06 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-04-10): From: The IESG To: IETF-Announce CC: ekr@rtfm.com, Daniel McCarney , acme@ietf.org, cpu@letsencrypt.org, … The following Last Call announcement was sent out (ends 2019-04-10): From: The IESG To: IETF-Announce CC: ekr@rtfm.com, Daniel McCarney , acme@ietf.org, cpu@letsencrypt.org, draft-ietf-acme-caa@ietf.org, acme-chairs@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (CAA Record Extensions for Account URI and ACME Method Binding) to Proposed Standard The IESG has received a request from the Automated Certificate Management Environment WG (acme) to consider the following document: - 'CAA Record Extensions for Account URI and ACME Method Binding' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The CAA DNS record allows a domain to communicate issuance policy to CAs, but only allows a domain to define policy with CA-level granularity. However, the CAA specification also provides facilities for extension to admit more granular, CA-specific policy. This specification defines two such parameters, one allowing specific accounts of a CA to be identified by URI and one allowing specific methods of domain control validation as defined by the ACME protocol to be required. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-acme-caa/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-acme-caa/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-03-27
|
06 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-03-27
|
06 | Eric Rescorla | Last call was requested |
2019-03-27
|
06 | Eric Rescorla | Last call announcement was generated |
2019-03-27
|
06 | Eric Rescorla | Ballot approval text was generated |
2019-03-27
|
06 | Eric Rescorla | Ballot writeup was generated |
2019-03-27
|
06 | Eric Rescorla | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-01-15
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-01-15
|
06 | Hugo Landau | New version available: draft-ietf-acme-caa-06.txt |
2019-01-15
|
06 | (System) | New version approved |
2019-01-15
|
06 | (System) | Request for posting confirmation emailed to previous authors: Hugo Landau |
2019-01-15
|
06 | Hugo Landau | Uploaded new revision |
2018-12-21
|
05 | Eric Rescorla | Waiting for a revised ID |
2018-11-04
|
05 | Eric Rescorla | https://mozphab-ietf.devsvcdev.mozaws.net/D4464 |
2018-11-04
|
05 | Eric Rescorla | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2018-07-05
|
05 | Rich Salz | Technical Summary The ACME-CAA draft extends the base CAA mechanism described by RFC 6844 to allow fine-grained authorization for draft-ACME based CAs. It adds two … Technical Summary The ACME-CAA draft extends the base CAA mechanism described by RFC 6844 to allow fine-grained authorization for draft-ACME based CAs. It adds two new parameters to the "issue" property tag, and the "issuewild" property tag. The new parameters are "accounturi" and "acceptedchallenges" and can be used to extend a CAA policy for an ACME based CA. The "accounturi" parameter allows the domain holder to restrict authorization to issue for a domain to only the ACME account URI specified in the CAA policy. The "acceptedchallenges" parameter allows the domain holder to restrict the ACME challenges that can be used for domain validation of a domain to those specified in the CAA policy. Working Group Summary Earlier drafts used a hyphen character in the "validationmethods" and "accounturi" parameters that was incompatible with the grammar defined in RFC 6844. This has been addressed in the latest draft by removing the hyphen character. Early discussion of the draft addressed issues raised by the community with regards to the security considerations section, and the handling of non-ACME challenge methods. Overall consensus was reached within the WG process without any rough areas and no controversial topics remain unaddressed. Document Quality Let's Encrypt, a large high-volume production ACME based CA, has fully implemented the ACME-CAA draft in a testing environment (not yet promoted to production usage). Let's Encrypt has committed to promoting ACME-CAA features to production in the near future. The overall document quality is high. Developing an implementation based on the specification text is reasonable. Personnel The document shepard is Daniel McCarney. The responsible area director is Eric Rescorla. There are no IANA considerations and no IANA experts/registry work is required. IRTF Note Not applicable. IESG Note Not applicable. IANA Note Not applicable. |
2018-07-05
|
05 | Rich Salz | Responsible AD changed to Eric Rescorla |
2018-07-05
|
05 | Rich Salz | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2018-07-05
|
05 | Rich Salz | IESG state changed to Publication Requested |
2018-07-05
|
05 | Rich Salz | IESG process started in state Publication Requested |
2018-07-05
|
05 | Rich Salz | Notification list changed to Daniel McCarney <cpu@letsencrypt.org> |
2018-07-05
|
05 | Rich Salz | Document shepherd changed to Daniel McCarney |
2018-07-05
|
05 | Rich Salz | Changed consensus to Yes from Unknown |
2018-07-05
|
05 | Rich Salz | Intended Status changed to Proposed Standard from None |
2018-07-05
|
05 | Rich Salz | Changed document writeup |
2018-06-21
|
05 | Hugo Landau | New version available: draft-ietf-acme-caa-05.txt |
2018-06-21
|
05 | (System) | New version approved |
2018-06-21
|
05 | (System) | Request for posting confirmation emailed to previous authors: Hugo Landau |
2018-06-21
|
05 | Hugo Landau | Uploaded new revision |
2018-05-27
|
04 | Hugo Landau | New version available: draft-ietf-acme-caa-04.txt |
2018-05-27
|
04 | (System) | New version approved |
2018-05-27
|
04 | (System) | Request for posting confirmation emailed to previous authors: Hugo Landau |
2018-05-27
|
04 | Hugo Landau | Uploaded new revision |
2018-04-19
|
03 | (System) | Document has expired |
2017-08-30
|
03 | Hugo Landau | New version available: draft-ietf-acme-caa-03.txt |
2017-08-30
|
03 | (System) | New version approved |
2017-08-30
|
03 | (System) | Request for posting confirmation emailed to previous authors: Hugo Landau |
2017-08-30
|
03 | Hugo Landau | Uploaded new revision |
2017-06-29
|
02 | Hugo Landau | New version available: draft-ietf-acme-caa-02.txt |
2017-06-29
|
02 | (System) | New version approved |
2017-06-29
|
02 | (System) | Request for posting confirmation emailed to previous authors: Hugo Landau |
2017-06-29
|
02 | Hugo Landau | Uploaded new revision |
2017-06-08
|
01 | Rich Salz | IETF WG state changed to In WG Last Call from WG Document |
2017-02-04
|
01 | Hugo Landau | New version available: draft-ietf-acme-caa-01.txt |
2017-02-04
|
01 | (System) | New version approved |
2017-02-04
|
01 | (System) | Request for posting confirmation emailed to previous authors: "Hugo Landau" |
2017-02-04
|
01 | Hugo Landau | Uploaded new revision |
2016-11-01
|
00 | Ted Hardie | Added to session: IETF-97: acme Wed-1330 |
2016-10-26
|
00 | Rich Salz | This document now replaces draft-landau-acme-caa instead of None |
2016-10-26
|
00 | Hugo Landau | New version available: draft-ietf-acme-caa-00.txt |
2016-10-26
|
00 | (System) | WG -00 approved |
2016-10-26
|
00 | Hugo Landau | Set submitter to "Hugo Landau ", replaces to draft-landau-acme-caa and sent approval email to group chairs: acme-chairs@ietf.org |
2016-10-26
|
00 | Hugo Landau | Uploaded new revision |