[Acme] FW: New Version Notification for draft-ietf-acme-star-delegation-09.txt

[Yaron Sheffer]

This is a minor update to address a few remaining comments by Ben.

Thanks,
Yaron

On 6/11/21, 11:27, "internet-dra...@ietf.org"  wrote:


A new version of I-D, draft-ietf-acme-star-delegation-09.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-ietf-acme-star-delegation
Revision:   09
Title:  An ACME Profile for Generating Delegated Certificates
Document date:  2021-06-11
Group:  acme
Pages:  48
URL:
https://www.ietf.org/archive/id/draft-ietf-acme-star-delegation-09.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/
Html:   
https://www.ietf.org/archive/id/draft-ietf-acme-star-delegation-09.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-delegation
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-delegation-09

Abstract:
   This document defines a profile of the Automatic Certificate
   Management Environment (ACME) protocol by which the holder of an
   identifier (e.g., a domain name) can allow a third party to obtain an
   X.509 certificate such that the certificate subject is the delegated
   identifier while the certified public key corresponds to a private
   key controlled by the third party.  A primary use case is that of a
   Content Delivery Network (CDN, the third party) terminating TLS
   sessions on behalf of a content provider (the holder of a domain
   name).  The presented mechanism allows the holder of the identifier
   to retain control over the delegation and revoke it at any time.
   Importantly, this mechanism does not require any modification to the
   deployed TLS clients and servers.




The IETF Secretariat




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

Re: [Acme] Éric Vyncke's No Objection on draft-ietf-acme-star-delegation-07: (with COMMENT)

[Yaron Sheffer]

Thank you Éric for your review. We will be tracking it here: 
https://github.com/yaronf/I-D/issues/176

Yaron

On 4/8/21, 00:02, "Éric Vyncke via Datatracker"  wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-acme-star-delegation-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/



--
COMMENT:
--

Thank you for the work put into this document. The usefulness of this
specification is clear and important!

Special thanks for the doc shepherd's write-up as it writes about the WG
consensus/discussion.

Please find below some blocking DISCUSS points, some non-blocking COMMENT
points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
Should "delegated identifier" be more defined ? Honestly, after reading the
abstract, I have no clue...

-- Section 1 --
In "This document is a companion document to [RFC8739]" is "companion" the
right word? I am not a native English speaker but "companion" sounds like 
the
fates of two documents are bound together, suggest to use "complements" ?

In the abstract CDN is just a use case while, in this introduction section, 
it
is the main goal.

Please expand "NDC" at first use ? Perhaps moving section 1.1 earlier ?

  "We note that other ongoing efforts address the problem of certificate
   delegation for TLS connections, specifically [I-D.ietf-tls-subcerts]
   and [I-D.mglt-lurk-tls13]."
I am trusting the responsible ADs (SEC & TSV) about having 2+ competing IETF
standards...

-- Section 2 --
It is a little unclear whether there is one NDC (one per CDN) or multiple 
NDC
(one per edge-cache). The latter could have scalability issues. Section 1.1
seems to indicate the former but it may be ambiguous.

-- Section 2.3.1.2 --
As I am not an expert in CDN, I wonder whether the example entry for
'cname-map' is correct? (I would have used "abc.ido.ndc.example." as the 
value).

== NITS ==

-- Abstract --
s/This memo defines/This document defines/ AFAIK, the 'memo' wording was 
used
back in the XXth century ;-)

-- Section 1.1 --
s/symmetry/similarity/ ?





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

Re: [Acme] Lars Eggert's Discuss on draft-ietf-acme-star-delegation-07: (with DISCUSS and COMMENT)

[Yaron Sheffer]

Hi Lars,

Thank you for your review. We will be tracking your comments at 
https://github.com/yaronf/I-D/issues/168 (the Discuss) and 
https://github.com/yaronf/I-D/issues/169 (all other comments).

Yaron


On 4/6/21, 15:41, "Lars Eggert via Datatracker"  wrote:

Lars Eggert has entered the following ballot position for
draft-ietf-acme-star-delegation-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/



--
DISCUSS:
--

Section 5.1, paragraph 4, discuss:
>This document requests that IANA create the following new registry
>under the Automated Certificate Management Environment (ACME)
>Protocol:
>
>*  ACME Identifier Object Fields
>
>This registry is administered under a Specification Required policy
>[RFC8126].

RFC8126 strongly suggests that guidance needs to be given to expert 
reviewers
that are supposed to review and approve requests for "Expert Review" and
"Specification Required" registries. This guidance is missing here. What's 
also
missing are designated contact persons and a change controller.

Section 5.6, paragraph 2, discuss:
> 5.6.  CSR Template Extensions
>
>IANA is requested to establish a registry "STAR Delegation CSR
>Template Extensions", with "Expert Review" as its registration
>procedure.

Same as above.


--
COMMENT:
--

Section 1, paragraph 8, comment:
>We note that other ongoing efforts address the problem of certificate
>delegation for TLS connections, specifically [I-D.ietf-tls-subcerts]
>and [I-D.mglt-lurk-tls13].  Compared to these other solutions, the
>current document does not introduce additional latency to the TLS
>connection, nor does it require changes to the TLS network stack of
>either the client or the server.

This paragraph should probably be removed upon publication as an RFC?


---
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to 
let me
know what you did with these suggestions.

Section 3.1, paragraph 10, nit:
-e.g. by restricting field lengths.  In this regard, note that a
+e.g., by restricting field lengths.  In this regard, note that a
++

Section 4.1, paragraph 3, nit:
-This section uses specifically CDNI terminology, e.g. "uCDN" and
+This section uses specifically CDNI terminology, e.g., "uCDN" and
+ +

Section 4.1.2.1, paragraph 5, nit:
-Unlike HTTP based redirection, where the original URL is supplanted
-   ^
+Unlike HTTP-based redirection, where the original URL is supplanted
+   ^





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

Re: [Acme] [Gen-art] Genart last call review of draft-ietf-acme-star-delegation-06

[Yaron Sheffer]

We have already addressed the GenArt comments, thank you Suresh!

I will respond to Lars's review separately.

Yaron

On 4/6/21, 15:52, "Lars Eggert"  wrote:

Suresh, thank you for your review. I have entered a Discuss ballot for this 
document based on my own review.

Lars


> On 2021-3-25, at 21:10, Suresh Krishnan via Datatracker 
 wrote:
> 
> Reviewer: Suresh Krishnan
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-acme-star-delegation-??
> Reviewer: Suresh Krishnan
> Review Date: 2021-03-23
> IETF LC End Date: 2021-03-22
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> There are a few lines longer than 72 characters and this will fail the ID 
Nits
> check. I dug a bit deeper and found out some of these lines were in the 
CDDL in
> Appendix B. Here are the lines if that helps.
> 
> % awk 'length($0)>72 { print length($0) $0}'
> draft-ietf-acme-star-delegation-06.txt 73Intended status: Standards Track
> D. López 76; RSASSA-PSS with SHA-256, MGF-1 with
> SHA-256, and a salt length of 32 bytes 76; RSASSA-PSS with SHA-384, MGF-1 
with
> SHA-384, and a salt length of 48 bytes 76; RSASSA-PSS with SHA-512, MGF-1 
with
> SHA-512, and a salt length of 64 bytes
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



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

Re: [Acme] Francesca Palombini's Discuss on draft-ietf-acme-star-delegation-07: (with DISCUSS and COMMENT)

[Yaron Sheffer]

Hi Francesca,

Thank you for your review and for getting the CBOR community and Carsten 
involved.

We will be tracking your comments here: https://github.com/yaronf/I-D/issues/173

And Carsten's review of CDDL and JSON Schema here: 
https://github.com/yaronf/I-D/issues/170

Thanks,
Yaron

On 4/6/21, 20:09, "Francesca Palombini via Datatracker"  
wrote:

Francesca Palombini has entered the following ballot position for
draft-ietf-acme-star-delegation-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/



--
DISCUSS:
--

EDIT (06-04-2021): Thank you very much to Carsten Bormann for the CDDL 
review:
https://mailarchive.ietf.org/arch/msg/cbor/23A-PFhRY-pdkg2-Kgcd4jqySVo/ 
Authors
- please make sure to answer Carsten's comments (and keep me in cc so I can
clear my DISCUSS).


--
COMMENT:
--

Thank you for the work on this document, which I found clear and easy to 
read.
You can find some minor comments below. The only one that might require more
attention is 7. about IANA expert guidelines missing.

EDIT TO ADD (06-04-2021): I see that Lars has added a discuss about the same
topic - I support that discuss.

Francesca

1. -

   the ACME CA and waits for the explicit revocation based on CRL and
   OCSP to propagate to the relying parties.

   ...

   result, the TLS connection to the dCDN edge is done with an SNI equal

FP: Please expand CRL, OCSP and SNI on first use.

2. -

   *  delegations (required, string): A URL from which a list of
  delegations configured for this account can be fetched via a POST-
  as-GET request.

FP: the second occurrence of "delegation" needs a pointer to the next
subsection - Delegation Objects, otherwise this definition becomes confusing
(delegations is a URL from which a list of delegations can be fetched).

3. -

   An example delegation object is shown in Figure 3.

FP: please note that the examples are in JSON.

4. -

   (Forbidden) and type "urn:ietf:params:acme:error:unknownDelegation".

FP: suggestion to change to:

   (Forbidden), providing a problem document [RFC7807] with type 
   "urn:ietf:params:acme:error:unknownDelegation", as registered in section 
5.5.

The error type appears later on as well (e.g. section 2.3.2), but even 
without
repeating each time, I think this reference at least here where it appears
first would help the reader.

5. -

   The Order object created by the IdO:

   ...

   *  MUST copy the "star-certificate" field from the STAR Order.  The

FP: (suggestion for clarification) because there are 2 Orders going on in
sequence, this bullet point and more precisely "from the STAR Order" is
slightly confusing. You could use Order1 and Order2 as you have used in 
Figure
1 to clarify things (I believe this should be "from the STAR Order2 into
Order1) (Note that this is just a suggestion, the rest of the text is mostly
clear about which Order it refers to) Otherwise, I think it would be good to
add "... from the STAR Order into its Order resource." The same comment 
apply
to the next occurrence:

   *  MUST copy the "certificate" field from the Order, as well as

6. -

   uCDN is configured to delegate to dCDN, and CP is configured to
   delegate to uCDN, both as defined in Section 2.3.1.

FP: Re Figure 12: I assume that 0. refers to the configuration CP and uCDN
share? In this case, why is there no arrow between uCDN and dCDN? If my
assumption is wrong, then what's the meaning of 0?

7. -

FP: This document defines two new registry, one with policy Specification
required and the other Expert review (both of which will need designated
experts). https://tools.ietf.org/html/rfc8126#section-5.3 states that:

   When a designated expert is used, the documentation should give clear
   guidance to the designated expert, laying out criteria for performing
   an evaluation and reasons for rejecting a request.  In the case where

I have noticed that RFC 8555 only provided guidance for one of its 
registries,
and that the registries are quite 

[Acme] FW: New Version Notification for draft-ietf-acme-star-delegation-07.txt

[Yaron Sheffer]

This version of the draft addresses Russ's SecDir review - thank you Russ!

In addition it addresses Suresh's GenArt review which duplicated one of Russ's 
comments.

Thanks,
Yaron

On 3/26/21, 14:26, "internet-dra...@ietf.org"  wrote:


A new version of I-D, draft-ietf-acme-star-delegation-07.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-ietf-acme-star-delegation
Revision:   07
Title:  An ACME Profile for Generating Delegated Certificates
Document date:  2021-03-26
Group:  acme
Pages:  44
URL:
https://www.ietf.org/archive/id/draft-ietf-acme-star-delegation-07.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/
Html:   
https://www.ietf.org/archive/id/draft-ietf-acme-star-delegation-07.html
Htmlized:   
https://tools.ietf.org/html/draft-ietf-acme-star-delegation-07
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-delegation-07

Abstract:
   This memo defines a profile of the Automatic Certificate Management
   Environment (ACME) protocol by which the owner of an identifier
   (e.g., a domain name) can allow a third party to obtain an X.509
   certificate such that the certificate subject is the delegated
   identifier while the certified public key corresponds to a private
   key controlled by the third party.  A primary use case is that of a
   Content Delivery Network (CDN, the third party) terminating TLS
   sessions on behalf of a content provider (the owner of a domain
   name).  The presented mechanism allows the owner of the identifier to
   retain control over the delegation and revoke it at any time.  A key
   property of this mechanism is it does not require any modification to
   the deployed TLS ecosystem.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

Re: [Acme] Secdir last call review of draft-ietf-acme-star-delegation-06

[Yaron Sheffer]

Hi Russ,

Please see the remaining open issues from your review - we have reopened the 
GitHub issues:

https://github.com/yaronf/I-D/issues/139
https://github.com/yaronf/I-D/issues/145
https://github.com/yaronf/I-D/issues/146
https://github.com/yaronf/I-D/issues/147
https://github.com/yaronf/I-D/issues/148

Thanks,
Yaron


On 3/23/21, 15:26, "Russ Housley"  wrote:

Thomas:

Thanks for the diff.  The revised structure looks good to me.  Much more 
clear.

Russ

> On Mar 23, 2021, at 5:58 AM, Thomas Fossati  
wrote:
> 
> Hi Russ,
> 
> A quick follow-up to try and close the issues that you could not confirm
> had been addressed because of the complexity of navigating the markdown
> diffs.
> 
> I have attached the output of rfcdiff, which should give you a more
> comfortable view over those changes.
> 
> On 22/03/2021, 19:30, "Russ Housley"  wrote:
>>   https://github.com/yaronf/I-D/issues/142
>> 
>> The restructuring is quire difficult to review in the markdown.  I
>> cannot be sure this addresses my comment.  That said, the word
>> "besides" does not appear in the document, so this has probably been
>> sorted out.
> 
> Please see the attached rfcdiff output.
> 
>>   https://github.com/yaronf/I-D/issues/144
>> 
>> As with issue 142, it is difficult to review in this form, but I think
>> the concern has been resolved.
> 
> Ditto.
> 
> Also:
> 
>>   https://github.com/yaronf/I-D/issues/150
>> 
>> I cannot check this in markdown format.  Please run IDnits.
> 
> Done on my local copy and it looks good:
> 
> $ idnits draft-ietf-acme-star-delegation-latest.txt
> Inspecting file draft-ietf-acme-star-delegation-latest.txt
> 
> Comment:
> 
>   Found 4 lines with non-ASCII characters.
> 
> Found 0 errors, 0 warnings, 1 comment.
> 
> cheers, t
> 
> 
> 
> 
> 
> 
> 
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
> 
___
> 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] AD Review: draft-ietf-acme-star-delegation-04

[Yaron Sheffer]

Hi Roman,

(1) In fact the existing language is more accurate. The CSR template is sent to 
the NDC in order to constrain what the NDC puts in the CSR. So the text that 
describes the mapping *from* the CSR template *to* the CSR is correct. Also, 
SPKI is freshly generated by the NDC, guided by the constraint on which key 
types it may use. So maybe:

The subject field and its subfields are mapped into the subject field of the 
CSR, as per [RFC5280], Sec. 4.1.2.6. Other extension fields of the CSR template 
are mapped into the CSR according to the table in Section 5.6. The Subject 
Public Key Info field of the CSR is generated by the NDC according to the 
constraints defined by the "keyTypes" object of the template.

(2) It turns out that my coauthor Thomas is a native CDDL speaker. So we will 
include a CDDL schema in addition to the JSON Schema. I concur that developers 
are much more likely to use the latter.

Thanks,
Yaron

On 2/23/21, 18:31, "Roman Danyliw"  wrote:

Hi Yaron!

Thanks for all of the work that went into -05.  It addresses all of my 
concerns but the following:

(1) Section 3.1.  The updated language is helpful, but I recommend a bit 
more precision to cover all of the fields.

OLD
The subject field and its subfields are mapped into the subject field of 
the CSR, as per [RFC5280], Sec. 4.1.2.6. Other extension fields of the CSR 
template are mapped into the CSR according to the table in Section 5.6.

NEW
The "Subject" field and its subfields per Section 4.1.2.6 of [RFC5280] are 
mapped into the "subject" field of the CSR template. The "Subject Public Key 
Info" field and its subfields per Section 4.1.2.7 of [RFC5280] are mapped into 
the "keyTypes" field of the CSR template.  Other extension fields are mapped as 
subfields of the "extensions" field in the CSR template according to the table 
in Section 5.6.

(2) The more thorny issue is how to handle a normative dependence on the 
JSON schema.  Short of it being in the document, whatever is the formal 
language used to define the CSR template needs an appropriate normative 
reference describing it.  Currently, [json-schema-07] in Appendix B would need 
to be normative (not informative).  I confirmed my concern with the ART ADs, 
and there is agreement that neither draft-handrews-json-schema-validation or 
http://json-schema.org will be an adequate normative references (i.e., 
[json-schema-07]).  

IMO, JSON still seems like the right architectural pattern here.  I also 
don't see an issue with the Schema that was specified.

A possible compromise (vetted with the ART ADs) is to follow the pattern of 
RFC8727 which also tried to use JSON Schema but couldn't find a usable 
normative reference -- full disclosure, I was a co-author.  This RFC 
normatively specified the "schema" via CDDL but also informatively provided the 
same schema via [json-schema-07].  Practically, implementers ignore the CDDL 
and use the more assessible JSON.  I appreciate this approach is additional 
work and pulls in another "technology" that isn't a natural fit in the ACME 
ecosystem.  

Do you see any alternatives?

Regards,
Roman

> -Original Message-
> From: Yaron Sheffer 
> Sent: Friday, February 5, 2021 5:45 PM
> To: Roman Danyliw ; IETF ACME 
> Subject: Re: [Acme] AD Review: draft-ietf-acme-star-delegation-04
> 
> Hi Roman,
> 
> Thank you for the detailed review. We will go through your comments and 
will
> rev the document accordingly, but in the meantime, let me respond 
specifically
> to the issue of the CSR template syntax.
> 
> The CSR template is potentially a long/complicated JSON document (example:
> [1]), and we felt that rather than including an informal definition which 
is easy
> to get wrong or a long sequence of examples, our audience would be better
> served by a formal definition.
> 
> To the best of my knowledge, by far the most common way to specify a JSON
> document format is with JSON Schema documents. Granted this spec is still 
a
> moving target, but it's already widely implemented. Also, there are 
discussions
> between the leaders of the JSON Schema effort and people on the HTTP-API
> working group, with the goal of standardizing it there.
> 
> JSON Schema draft-7 is defined by draft-handrews-json-schema-validation-01
> (and a few companion document), and not (as we incorrectly noted) by the
> latest version of that draft. Clearly it's not ideal to refer to a 
specific, expired
> version of an I-D. The situation is mitigated to a certain degree by the 
schema
> document [2] mentioning explicitly the supported version:
> 
>   "$schema": "http://json-schem

[Acme] FW: New Version Notification for draft-ietf-acme-star-delegation-05.txt

[Yaron Sheffer]

This version addresses Roman's (rather extensive) AD review. Thank you Roman!

Regards,
Yaron


On 2/21/21, 20:27, "internet-dra...@ietf.org"  wrote:


A new version of I-D, draft-ietf-acme-star-delegation-05.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-ietf-acme-star-delegation
Revision:   05
Title:  An ACME Profile for Generating Delegated STAR 
Certificates
Document date:  2021-02-21
Group:  acme
Pages:  36
URL:
https://www.ietf.org/archive/id/draft-ietf-acme-star-delegation-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/
Html:   
https://www.ietf.org/archive/id/draft-ietf-acme-star-delegation-05.html
Htmlized:   
https://tools.ietf.org/html/draft-ietf-acme-star-delegation-05
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-delegation-05

Abstract:
   This memo proposes a profile of the ACME protocol that allows the
   owner of an identifier (e.g., a domain name) to delegate to a third
   party access to a certificate associated with said identifier.  A
   primary use case is that of a CDN (the third party) terminating TLS
   sessions on behalf of a content provider (the owner of a domain
   name).  The presented mechanism allows the owner of the identifier to
   retain control over the delegation and revoke it at any time by
   cancelling the associated STAR certificate renewal with the ACME CA.
   Another key property of this mechanism is it does not require any
   modification to the deployed TLS ecosystem.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

Re: [Acme] AD Review: draft-ietf-acme-star-delegation-04

[Yaron Sheffer]

Hi Roman,

Thank you for the detailed review. We will go through your comments and will 
rev the document accordingly, but in the meantime, let me respond specifically 
to the issue of the CSR template syntax.

The CSR template is potentially a long/complicated JSON document (example: 
[1]), and we felt that rather than including an informal definition which is 
easy to get wrong or a long sequence of examples, our audience would be better 
served by a formal definition.

To the best of my knowledge, by far the most common way to specify a JSON 
document format is with JSON Schema documents. Granted this spec is still a 
moving target, but it's already widely implemented. Also, there are discussions 
between the leaders of the JSON Schema effort and people on the HTTP-API 
working group, with the goal of standardizing it there.

JSON Schema draft-7 is defined by draft-handrews-json-schema-validation-01 (and 
a few companion document), and not (as we incorrectly noted) by the latest 
version of that draft. Clearly it's not ideal to refer to a specific, expired 
version of an I-D. The situation is mitigated to a certain degree by the schema 
document [2] mentioning explicitly the supported version: 

  "$schema": "http://json-schema.org/draft-07/schema#;

I hope this clarifies things. Regarding your two related comments:

- Yes, we should have specified the mapping of fields into X.509, and will do 
that when we address your comments.
- The notion of "snippet" is actually well defined when we say, "a JSON Schema 
snippet that defines a type". Formally this is a valid JSON object with a 
"type" attribute, per draft-handrews-json-schema-validation-01 Sec. 6.1.1.

Thanks,
Yaron


[1] 
https://raw.githubusercontent.com/yaronf/I-D/master/STAR-Delegation/CSR-template/example-template.json
[2] 
https://raw.githubusercontent.com/yaronf/I-D/master/STAR-Delegation/CSR-template/template-schema.json


On 2/5/21, 00:50, "Roman Danyliw"  wrote:

Hi!

I did an AD review of draft-ietf-acme-star-delegation-04.  Thanks for this 
work to apply the STAR profile (rfc8739).  Below are my comments.  There are a 
number of editorial clarifications proposed below.  The item that likely needs 
some discussion is the syntax of the CSR template.

** Idnit:
  ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659)

  == Outdated reference: A later version (-04) exists of
 draft-ietf-cdni-interfaces-https-delegation-03

  -- Unexpected draft version: The latest known version of 
 draft-ietf-stir-cert-delegation is -02, but you're referring to -03.

** Section 1.  Editorial.  Missing preposition.
OLD
   This document describes a profile of the ACME protocol [RFC8555] that
   allows the NDC to request the IdO, acting as a profiled ACME server,
   a certificate for a delegated identity
NEW
   This document describes a profile of the ACME protocol [RFC8555] that
   allows the NDC to request from the IdO, acting as a profiled ACME server,
   a certificate for a delegated identity

** Section 2.2.  Editorial.  Recommend symmetry in naming of the orders and 
being explicit on the order in question.
-- second from last bullet.  s/reflected in the NDC order/reflected in 
Order 1 (i.e., the NDC Order)/
-- last bullet.  s/moves its state to "valid"/moves the Order 1 state to 
"valid"/

** Section 2.2. Should the buffering requirement for the CSR be normative - 
s/The IdO must buffer/The IdO MUST buffer/

** Section 2.2.  Per "[No identify validation]", what is meant by that?

** Section 2.3.1.  Editorial.  s/The IdO can delegate multiple names 
through each NDC/The IdO can delegate multiple names to a NDC/

** Section 2.3.1.  Are there any constraints to what the delegation URLs 
could point to?

** Section 2.3.1.  Per "The value of this attribute is the URL pointing to 
the delegation configurationobject that is to be used for this certificate 
request", what is the error handling if the delegation attribute doesn't point 
to a URL found in the delegations URL list?  

** Section 2.3.2.  It might be worth pointing out the obvious when 
clarifying the properties of the Order objects such as:
-- That the value field will be the delegated name

-- The expected symmetry in field values between NDC-generated order object 
and the one made by the IdO

** Section 2.3.2.  Per "When the validation of the identifiers has been 
successfully completed ...", it would be useful to clarify who is doing the 
validation and when.  Figure 1 suggests that there is only a validation process 
between IdO client and CA server.  However, wouldn't the IdO server be checking 
the identifiers submitted by the NDC client too (prior to passing them to the 
CA server too?

** Section 2.3.2 and 2.3.3.  I didn't  understand the titles used to 
organize of content -- "Order Object on the NDC-IdO side" vs. "IdO-CA side".  
They 

[Acme] FW: New Version Notification for draft-ietf-acme-star-delegation-04.txt

[Yaron Sheffer]

Dear ACME team,

We just submitted a major revision to this document. Summary of changes:

* Delegation of non-STAR certificates.
* More IANA clarity, specifically on certificate extensions.
* Add delegation configuration object and extend account and order objects 
accordingly.
* A lot more depth on Security Considerations.

Note: We consider delegation of regular (non-STAR) certificates a useful 
feature, but not a central use case. Therefore we kept most of the body of the 
spec focused on STAR certificates, with the changes for non-STAR certs listed 
in Sec. 2.4.

Thanks,
Yaron

On 8/25/20, 15:20, "internet-dra...@ietf.org"  wrote:


A new version of I-D, draft-ietf-acme-star-delegation-04.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-ietf-acme-star-delegation
Revision:   04
Title:  An ACME Profile for Generating Delegated STAR 
Certificates
Document date:  2020-08-25
Group:  acme
Pages:  33
URL:
https://www.ietf.org/internet-drafts/draft-ietf-acme-star-delegation-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/
Htmlized:   
https://tools.ietf.org/html/draft-ietf-acme-star-delegation-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-delegation
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-delegation-04

Abstract:
   This memo proposes a profile of the ACME protocol that allows the
   owner of an identifier (e.g., a domain name) to delegate to a third
   party access to a certificate associated with said identifier.  A
   primary use case is that of a CDN (the third party) terminating TLS
   sessions on behalf of a content provider (the owner of a domain
   name).  The presented mechanism allows the owner of the identifier to
   retain control over the delegation and revoke it at any time by
   cancelling the associated STAR certificate renewal with the ACME CA.
   Another key property of this mechanism is it does not require any
   modification to the deployed TLS ecosystem.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

Re: [Acme] IETF 107; agenda

[Yaron Sheffer]

It would not be the first time people confused Yoav and myself. I am honored...

Yaron (me) is not planning to be there, I am banned by both my company and my 
government.

Re: STAR, Rich didn't get it completely right: the base STAR is in AUTH48 and 
might actually get published in the next day or two. STAR Delegation has made 
lots of progress since the last meeting, but personally (I have not consulted 
with my coauthors) I think is not ready for LC yet. I'll be happy to present 
the progress remotely, if the meeting does happen.

Thanks,
Yaron



On 3/9/20, 19:42, "Salz, Rich"  wrote:

That is what I get for looking at the "new draft" email from Yaron while 
writing mail to ACME.  Ooops.


On 3/9/20, 1:34 PM, "Yoav Nir"  wrote:

…and Yoav won’t be there either. No idea about Yaron.

> On 9 Mar 2020, at 17:11, Salz, Rich 
 wrote:
> 
> Yaron and I cannot attend and will be remote.  We have volunteers to 
act as chairs for us (on CC).  Looking at the list below, it seems reasonable 
to cancel our session.  PLEASE POST IF YOU DISAGREE.  Of course "they" may 
decide to cancel anyway, but please post your opinion here.
> 
> Let’s look at the documents in our queue and see which need time at 
IETF 107.  See https://datatracker.ietf.org/wg/acme/documents/ to link to the 
document.
> 
> draft-ietf-acme-authority-token-04, ACME Challenges Using an 
Authority Token -and-
> draft-ietf-acme-authority-token-tnauthlist-05,  TNAuthList profile of 
ACME Authority Token
>   Any update from the authors?  Is this ready for WGLC?
>   This has never had much in-person discussion, and the domain 
expertise is in STIR
> 
> draft-ietf-acme-client-00, ACME End User Client and Code Signing 
Certificates
>   Any updates?  This was recently adopted by the WG.
> 
> draft-ietf-acme-integrations-00, ACME Integrations
>   Michael Richardson can present.
> 
> draft-friel-acme-subdomains-02
>   Michael Richardson can present; this is a topic for WG adoption
> 
> draft-ietf-acme-email-smime-06, Extensions to Automatic Certificate 
Management Environment for end user S/MIME certificates
>   Any updates?  Ready for WGLC?
> 
> draft-ietf-acme-star-delegation-03, An ACME Profile for Generating 
Delegated STAR Certificates
>   Yaron just pushed a new update.  Does this need F2F time?  The 
main document (draft-ietf-acme-star-11,  Support for Short-Term, 
Automatically-Renewed (STAR) Certificates in Automated Certificate Management 
Environment (ACME) is already in IESG review and probably wants this one to be 
in the same bundle.)
> 
> 
> ___
> 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] FW: New Version Notification for draft-ietf-acme-star-delegation-03.txt

[Yaron Sheffer]

As promised, we submitted another version of this draft before Vancouver. In 
addition to the recent work on the CSR template, this version includes a lot 
more detail on the STIR and CDNI use cases, including recursive delegation.

We would greatly appreciate your comments!

Thanks,
Yaron

On 3/8/20, 22:41, "internet-dra...@ietf.org"  wrote:


A new version of I-D, draft-ietf-acme-star-delegation-03.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-ietf-acme-star-delegation
Revision:   03
Title:  An ACME Profile for Generating Delegated STAR 
Certificates
Document date:  2020-03-08
Group:  acme
Pages:  26
URL:
https://www.ietf.org/internet-drafts/draft-ietf-acme-star-delegation-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/
Htmlized:   
https://tools.ietf.org/html/draft-ietf-acme-star-delegation-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-delegation
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-delegation-03

Abstract:
   This memo proposes a profile of the ACME protocol that allows the
   owner of an identifier (e.g., a domain name) to delegate to a third
   party access to a certificate associated with said identifier.  A
   primary use case is that of a CDN (the third party) terminating TLS
   sessions on behalf of a content provider (the owner of a domain
   name).  The presented mechanism allows the owner of the identifier to
   retain control over the delegation and revoke it at any time by
   cancelling the associated STAR certificate renewal with the ACME CA.
   Another key property of this mechanism is it does not require any
   modification to the deployed TLS ecosystem.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat





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

[Acme] FW: New Version Notification for draft-ietf-acme-star-delegation-02.txt

[Yaron Sheffer]

Hi,

This version of the draft overhauls the CSR template that defines what 
parameters the Name Delegation Client is allowed to use in its certificate 
request.

This is work in progress, and we expect to publish another version before 
Vancouver.

Thanks,
Yaron

On 2/18/20, 14:40, "internet-dra...@ietf.org"  wrote:


A new version of I-D, draft-ietf-acme-star-delegation-02.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-ietf-acme-star-delegation
Revision:   02
Title:  An ACME Profile for Generating Delegated STAR 
Certificates
Document date:  2020-02-18
Group:  acme
Pages:  19
URL:
https://www.ietf.org/internet-drafts/draft-ietf-acme-star-delegation-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/
Htmlized:   
https://tools.ietf.org/html/draft-ietf-acme-star-delegation-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-delegation
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-delegation-02

Abstract:
   This memo proposes a profile of the ACME protocol that allows the
   owner of an identifier (e.g., a domain name) to delegate to a third
   party access to a certificate associated with said identifier.  A
   primary use case is that of a CDN (the third party) terminating TLS
   sessions on behalf of a content provider (the owner of a domain
   name).  The presented mechanism allows the owner of the identifier to
   retain control over the delegation and revoke it at any time by
   cancelling the associated STAR certificate renewal with the ACME CA.
   Another key property of this mechanism is it does not require any
   modification to the deployed TLS ecosystem.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

[Acme] FW: New Version Notification for draft-ietf-acme-star-10.txt

[Yaron Sheffer]

This version addresses all outstanding IESG comments, including a bunch of 
comments from Ben and two Discusses.

Thanks,
Yaron

On 13/10/2019, 18:08, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-ietf-acme-star-10.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-ietf-acme-star
Revision:   10
Title:  Support for Short-Term, Automatically-Renewed (STAR) 
Certificates in Automated Certificate Management Environment (ACME)
Document date:  2019-10-13
Group:  acme
Pages:  29
URL:
https://www.ietf.org/internet-drafts/draft-ietf-acme-star-10.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-acme-star/
Htmlized:   https://tools.ietf.org/html/draft-ietf-acme-star-10
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-acme-star
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-10

Abstract:
   Public-key certificates need to be revoked when they are compromised,
   that is, when the associated private key is exposed to an
   unauthorized entity.  However the revocation process is often
   unreliable.  An alternative to revocation is issuing a sequence of
   certificates, each with a short validity period, and terminating this
   sequence upon compromise.  This memo proposes an ACME extension to
   enable the issuance of short-term and automatically renewed (STAR)
   X.509 certificates.

   [RFC Editor: please remove before publication]

   While the draft is being developed, the editor's version can be found
   at https://github.com/yaronf/I-D/tree/master/STAR.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

Re: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt

[Yaron Sheffer]

Agree on both points.

 

From: Ryan Sleevi 
Date: Thursday, 10 October 2019 at 18:16
To: Yaron Sheffer 
Cc: Thomas Fossati , Ryan Sleevi 
, "acme@ietf.org" 
Subject: Re: [Acme] Fwd: New Version Notification for 
draft-ietf-acme-star-delegation-01.txt

 

 

 

On Thu, Oct 10, 2019 at 5:22 AM Yaron Sheffer  wrote:

I am wondering though about this sentence: A CA can "also offer additional 
validation methods/issuance flows which also use the "dns-01" method." Doesn't 
specifying "dns-01" restrict the CA to one particular validation/authorization 
flow?

 

No.

 

There's a gap in the assumption here, which is that the CA MUST support 
draft-ietf-acme-caa, which is not specified, and were it specified, runs into 
the set of issues covered in 
https://tools.ietf.org/html/draft-ietf-acme-caa-10#section-5 

 

However, setting that aside, the dns-01 validation method alone doesn't 
restrict the issuance pattern to just being STAR, which is the assertion "To 
restrict certificate delegation only to the protocol defined here:"

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

Re: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt

[Yaron Sheffer]

Hi Ryan,

Apologies for the very late reply. 

I accept your comments below, and we will reword this section as a 
recommendation or best practice. The flexibility of CAA means that the solution 
must be tailored to the particular CA(s) trusted by the IdO. This is 
unfortunate in the sense that we cannot recommend a one-size-fits-all security 
solution, and admins would need to have deeper understanding of the mechanisms 
they are using.

I am wondering though about this sentence: A CA can "also offer additional 
validation methods/issuance flows which also use the "dns-01" method." Doesn't 
specifying "dns-01" restrict the CA to one particular validation/authorization 
flow?

Thanks,
Yaron

On 29/08/2019, 12:38, "Thomas Fossati"  wrote:

Hi Ryan,

Thanks very much for the comments.  I'm going to address some of your
points and let Yaron comment on the rest.

[snip]

> 6.1 Restricting CDNs to the Delegation Mechanism There are RFC 2119
> MUSTs attached here, when it seems these functionally should be
> SHOULDs. That is, I think it's fair to highlight the consideration of
> concerns between the IdO and the CDN, but I don't think it's
> reasonable to normatively specify the policy consideration mechanism.
> For example, as specified, those requirements would not be sufficient
> to guarantee that a conforming CA uses this mechanism, as a number of
> CAs "comply with ACME" (second bullet), but also offer additional
> validation methods/issuance flows which also use the "dns-01" method.
>
> As CAA is intentionally flexible to allow for CA-specific policy
> identifiers to be expressed between the IdO and the CA, I think it's
> best to change these to SHOULD, and to recognize that CAs may devise
> other means of technically expressing this conformance, and that's
> between the IdO and the CA. CAA provides the necessary component (to
> allow them to restrict to CAs that respect CAA, to allow CA-specific
> policy), but I think that's the extent to which policy-specific
> requirements can be made.

 


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

[Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt

[Yaron Sheffer]

The new version contains some significant changes:

- Addition of the STIR use case.
- Refinement of the CDNI use case.
- Addition of the CSR template (partial, more work required).
- Further security considerations (work in progress).

Thanks,
Yaron

 Forwarded Message 
Subject: New Version Notification for draft-ietf-acme-star-delegation-01.txt
Date: Mon, 26 Aug 2019 23:17:15 -0700
From: internet-dra...@ietf.org
To: Yaron Sheffer , Thomas Fossati 
, Antonio Agustin Pastor Perales 
, Antonio Pastor 
, Diego Lopez 




A new version of I-D, draft-ietf-acme-star-delegation-01.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-ietf-acme-star-delegation
Revision:   01
Title:  An ACME Profile for Generating Delegated STAR Certificates
Document date:  2019-08-26
Group:  acme
Pages:  17
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-acme-star-delegation-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/
Htmlized: 
https://tools.ietf.org/html/draft-ietf-acme-star-delegation-01
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-delegation
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-delegation-01


Abstract:
   This memo proposes a profile of the ACME protocol that allows the
   owner of an identifier (e.g., a domain name) to delegate to a third
   party access to a certificate associated with said identifier.  A
   primary use case is that of a CDN (the third party) terminating TLS
   sessions on behalf of a content provider (the owner of a domain
   name).  The presented mechanism allows the owner of the identifier to
   retain control over the delegation and revoke it at any time by
   cancelling the associated STAR certificate renewal with the ACME CA.
   Another key property of this mechanism is it does not require any
   modification to the deployed TLS ecosystem.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

[Acme] Fwd: New Version Notification for draft-ietf-acme-star-07.txt

[Yaron Sheffer]

This new version addresses IANA expert review comments regarding the two 
newly introduced HTTP headers.


Thanks,
Yaron

 Forwarded Message 
Subject: New Version Notification for draft-ietf-acme-star-07.txt
Date: Tue, 20 Aug 2019 13:19:41 -0700
From: internet-dra...@ietf.org
To: Oscar Gonzalez de Dios , Yaron 
Sheffer , Oscar de Dios 
, Thomas Fossati 
, Diego Lopez , 
Antonio Agustin Pastor Perales , 
Antonio Pastor 



A new version of I-D, draft-ietf-acme-star-07.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-ietf-acme-star
Revision:   07
Title:		Support for Short-Term, Automatically-Renewed (STAR) 
Certificates in Automated Certificate Management Environment (ACME)

Document date:  2019-08-20
Group:  acme
Pages:  26
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-acme-star-07.txt

Status: https://datatracker.ietf.org/doc/draft-ietf-acme-star/
Htmlized:   https://tools.ietf.org/html/draft-ietf-acme-star-07
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-acme-star
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-07

Abstract:
   Public-key certificates need to be revoked when they are compromised,
   that is, when the associated private key is exposed to an
   unauthorized entity.  However the revocation process is often
   unreliable.  An alternative to revocation is issuing a sequence of
   certificates, each with a short validity period, and terminating this
   sequence upon compromise.  This memo proposes an ACME extension to
   enable the issuance of short-term and automatically renewed (STAR)
   X.509 certificates.

   [RFC Editor: please remove before publication]

   While the draft is being developed, the editor's version can be found
   at https://github.com/yaronf/I-D/tree/master/STAR.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Acme] Draft notes from 27/3/19

[Yaron Sheffer]

So a few minor naming corrections for the STAR session: Roman is our 
incoming AD, the person from Telefonica is Diego Lopez, and Carl is 
really Cullen.


On 27/03/2019 12:27, Salz, Rich wrote:


Thank you Robin!

Please post corrections here, the chairs will integrate and post to 
the datatracker.


*From: *"wil...@isoc.org" 
*Date: *Wednesday, March 27, 2019 at 12:27 PM
*To: *"acme@ietf.org" 
*Subject: *[Acme] Draft notes from 27/3/19

ACME WG notes, 27/3/19

Milestone: RFC8555 is out!

Rescorla: acme-ip-05 : security considerations section need to be 
updated following my most recent comments on it.


STAR (Short-term Automatically Renewed Certs) - Yaron Sheffer
Proposed moving to publish; authors don’t feel a new WGLC is needed.
=> Chairs asked WG to read the current version, as an informal 
alternative to a new WGLC.


Rescorla: My view is that the changes made are sufficient. Ask the 
incoming AD for his view.

Rowan (incoming AD): ack

Telefonica: there is one implementation, available on Github and in 
use by Telefonica.


Rescorla: Is STAR being used in certificate issuance protocols?
Carl Jennings: isn’t this the point for the chairs to ask if anyone 
plans to implement?
Michael Richardson: ?Anima won’t exactly implement, but does recommend 
it and express a need.



3rd-party device attestation for ACME - Rifaat

Richard Barnes: URL in the ACME JWT specifies the intended destination 
of the request, on the CA’s ACME server. Is that the intended 
modification here?

=> Response inconclusive; RB will re-read the specs.

Carsten Bormann: Does authorization become attestation by being 
packaged as a certificate? What makes this an “attestation”?


Rifaat: the JWT specifies that this device is correctly associated 
with this certificate.


Michael Richardson: ACME challenges essentially “attest to the 
existence of the device”.


Watson Ladd: what kinds of certificate are these?
Rifaat: typically, an identifier for the device (MAC address), and a 
service URI.


Chair: too early to hum for adoption. Draft needs updating to remove 
any ambiguity around terms of art such as “attestation”.



ACME Client Certificates - Kathleen Moriarty

1 - Device certificates:
Yoran Sheffer - this is interesting but not a good fit for cloud 
deployments, where entities might not need their own “name”, but might 
still need a certificate.


Thomas Peterson - IP/DNS not appropriate in all cases.

Paul - would be nice if this could work with IPSEC Cert Protocol

Richard Barnes - if client certs are already identifying themselves by 
one of the methods identified in the draft, no added work is needed. 
No core difference between client certs and server certs except in the 
EKU (which could be ignored under certain certs).


KM - Draft was posted to the mailing list.

2 - End user certs
Should ACME handle these? KM not aware of a use case. Can they be left 
to other organisations?


Alexei Melnikov: S-MIME certs are a subset of these.

Rescorla: don’t think we need a new “meta-framework” to handle end 
user certs.


Thomas  Peterson - I think we should, to simplify enterprise handling 
of browser certs.


Code-signing Certificates

Max - we do a lot of this, e.g. for cable modem certs. The processes 
are really strict; the certs are more than EV certs, and we wouldn’t 
feel comfortable automating this.


Watson Ladd: don’t use SMS/email as pre-authorization methods for 
this. They are too open to compromise, even with 2FA.


Jon: STIR has specified an authorisation token that could be applied 
in this case - at least as *part* of an automation process.


Karthikeyan: we published analysis of ACME last year; Read vs Write 
authentication channels are markedly different in security.


Richard Barnes: consider removing superfluous material from the draft 
as part of the focussing exercise.


Authority Tokens - Jon







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

[Acme] Fwd: New Version Notification for draft-sheffer-acme-star-delegation-01.txt

[Yaron Sheffer]

We submitted a new version of this document, the second one we discussed 
in Bangkok. The only change is the addition of a Security Considerations 
section that explains how the CDN can be prevented from issuing 
certificates for the delegated domain.


Thanks,
Yaron


 Forwarded Message 
Subject: New Version Notification for 
draft-sheffer-acme-star-delegation-01.txt

Date: Tue, 13 Nov 2018 12:39:45 -0800
From: internet-dra...@ietf.org
To: Yaron Sheffer , Thomas Fossati 
, Antonio Agustin Pastor Perales 
, Antonio Pastor 
, Diego Lopez 




A new version of I-D, draft-sheffer-acme-star-delegation-01.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-sheffer-acme-star-delegation
Revision:   01
Title:  An ACME Profile for Generating Delegated STAR Certificates
Document date:  2018-11-13
Group:  Individual Submission
Pages:  13
URL: 
https://www.ietf.org/internet-drafts/draft-sheffer-acme-star-delegation-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-sheffer-acme-star-delegation/
Htmlized: 
https://tools.ietf.org/html/draft-sheffer-acme-star-delegation-01
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-sheffer-acme-star-delegation
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-sheffer-acme-star-delegation-01


Abstract:
   This memo proposes a profile of the ACME protocol that allows the
   owner of an identifier (e.g., a domain name) to delegate to a third
   party access to a certificate associated with said identifier.  A
   primary use case is that of a CDN (the third party) terminating TLS
   sessions on behalf of a content provider (the owner of a domain
   name).  The presented mechanism allows the owner of the identifier to
   retain control over the delegation and revoke it at any time by
   cancelling the associated STAR certificate renewal with the ACME CA.
   Another key property of this mechanism is it does not require any
   modification to the deployed TLS ecosystem.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Acme] Draft minutes

[Yaron Sheffer]

No problem, thank you Rich.

Attached the minutes after a merge of Alexey's corrections and mine.

Thanks,
Yaron

On 11/11/2018 0:32, Salz, Rich wrote:

He mailed it to the chairs and I posted it to the datatracker.  I failed to 
mention this to the list, oops.

On 11/11/18, 4:45 AM, "Yaron Sheffer"  wrote:

 Alexey hasn't posted yet an updated version, and I edited the first part
 of the minutes (the STAR portion only), now attached with my changes.
 
 Chairs, please take a look, some of the changes are potentially

 important, as they refer to action items (I went through the YouTube 
video).
 
 Alexey, can you please merge them with your changes.
 
 Thanks,
 
  Yaron
 
 On 09/11/2018 5:28, Salz, Rich wrote:

 > Nitpicking is why I posted so quickly :)  Please post an edited version!
 >
 > On 11/9/18, 9:51 AM, "Alexey Melnikov"  wrote:
 >
 >  Sorry for nitpicking, but below are my corrections to the minutes. 
I can
 >  just send the updated version instead of a patch.
 >
 >  > ## Email TLS certs and EMAIL end-user certs, 15 minutes
 >  > Who will read?  Ready for WGLC?
 >  >
 >  > Paul Hofman: I don't understand the proposed change
 >  > Alexey: At the moment service/port are single. If you wanted to 
issue multiple
 >  > ports (IMAP/IMAPS) it needs to be multiple requests.
 >  > Paul: I see no reason not to have multiple services.
 >  > Chaair: One array or two?
 >  > Alexey: One array
 >  > Richard: I'm confused. This document is talking about 
authenticating
 >  > DNS, but what would go into a certificate is a Domain.
 >  > Alexey: In theory you could issue SRV based IDs. In the most 
common use cases
 >  > that won't be used.
 >
 >  Change to: In the most common use cases DNS IDs would be issued 
instead.
 >
 >  > Richard: I think this should be updated to cover SRV.
 >
 >  Insert: Alexey: SRV is already covered in the document.
 >
 >  > DKG: I want to agree with Richard. If it's just on name, this is 
too complex.
 >  > Several steps need including
 >  > Alexey: For DNS there will be slightly specific service name.
 >
 >  Change to: For DNS challenge, there service name is included in the 
DNS
 >  name used for the ACME challenge.
 >  (_._._acme-challenge. TXT record.)
 >
 >  I think Richard also suggested to create a new DNS-based ACME 
challenge
 >  type.
 >
 >  > DKG: If the cert being requested isn't specifically for the 
service, this
 >  > could open an attack to other services for other protocols
 >  > AI: Alexey to add some clarifying text, Richard to send some
 >  > AI: After next draft, WGLC; READ
 >  >
 >  > Paul Hoffman: These details aren't clear in the current draft.
 >  > Richard: We have a copy of layers of indirection, what I am least 
clear on is
 >  > the mapping of service to certificate. CA's may want to include 
SRV into the
 >  > cert if you show control of the domain.
 >  > Alexey: I'm hoping they'll issue certs with the port
 >
 >  Change to: I'm hoping they'll issue certs with the service name
 >
 >  > Richard: I suggest you implement SRV service IDs
 >  > Tim: SRV has been discussed but not implemented
 >  > Tim: The assumption all zones in a domain are controlled by the 
same identity is no longer true.
 >  > Alexey: I am developing software that could develop software to 
validate these, but first I need CAs to issue certs against this.
 >
 >  Change to: I am developing client side software that validate 
these, but
 >  first I need CAs to issue certs against this.
 >  >
 >  >
 >
 >  I think it is worth pointing out here that now we moved on to the 
S/MIME
 >  document:
 >
 >  > Yaron: Are you expecting end user to perform this challenge?
 >  > Alexey: Yes, possibly through copy/pasting the challenge.
 >
 >  Change the above 2:
 >
 >  Yaron: Are you expecting end user to perform this challenge or 
email client?
 >  Alexey: Both. If email client doesn't support this natively, it is
 >  possible to copy the challenge to an external program and then
 >  create a reply with the calculated result.
 >
 >
 >  > Chair: Is there any provisiion f

[Acme] draft-ietf-acme-email-smime-03 - comments

[Yaron Sheffer]

  
  
Hi Alexey,


Overall, this seems to be workable and useful.


* In Sec. 3, definition of the format of the email address should
  refer to RFC 5322 (specifically, Sec. 3.4.1) and not 5321.
* I've never seen "*" used to denote wildcards in the context of
email addresses, is this really a problem? "*" is nominally a legal
character in the local-part of an address.
* Is the email address allowed to contain a "+", which typically
introduces a subaddress
(https://en.wikipedia.org/wiki/Email_address#Subaddressing)? In
other words, do I need a different certificate for every subaddress?
RFC 5750 is silent on this.
* Token2 is "returned over HTTPS". Is it part of the ACME
  protocol? Where exactly?
* I think we should say explicitly that both tokens are generated
  freshly for each Order.

* Why include the SHA-256 digest of the key authz in the returned
email, rather than the key authz as-is? Please refer to Sec. 8.1 of
the base draft: key authz is token+"."+thumbprint.
* Can all mail clients generate emails that contain a single
text/plain MIME part? In other words, are there no browser-based
clients that insist on having an "alternative" HTML part? The CA
should be liberal enough to deal with their responses.
* "These identifiers may appear in any sort order" - could you
include an example of the CSR? I could not find an RFC that defines
it for S/MIME.
* 3.1: the subject header is often prepended with all sorts of
fluff, such as "[extern]". I don't know if people also append things
to the header, but if they do, you might want to facilitate parsing
by surrounding the token with some special characters, e.g. "ACME:
[1234abcd]" (note the brackets).
* Please specify that this is base64url without "=" padding.
* ‎The example response shows a key authorization
(digest+thumbprint), and not a sha-256 digest of a key authz which
the text says.
* Also, I suggest to add some boilerplate to the response to make it
easier to parse, e.g. prepend with "ACME:" similarly to the request
subject header.
* Open issue 1: yes, I think a special MIME type is much better than
having a client plug-in that needs to inspect ALL incoming emails.
* IANA Considerations: clarify which registries for each one.


Thanks,
    Yaron

  


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

Re: [Acme] Draft minutes

[Yaron Sheffer]

 regular identifier 
name (the "value" of the CNAME), it is run by the IdO.
Yaron: the CNMAE part i soptional, simplifies synchronization of provisioning.
Richard: What CNAME is provisioned as a result of this?
Yaron Sheffer: CNAME points from DNO to NDC. 

Richard: I'll take a look at the draft and provide feedback

Yaron: This could be used for long-term certs.
Richard: This could be used for short term use case, but I don't see a
reason to join this with long-term.
Chris: If someone finds a solution where they are using them for long term,
more power to them, we should encourage them.
Yoav: What if we don't find such a use case? Right now we don't have any use
cases
Daniel Kahn Gilmore: If you are going to restrict delegation to STAR, how are 
you going to restrict
it? What cut line would you use? Expiration or other?
Yaron Sheffer: The document could restrict with a MUST.
Tim Hollebeek: That (making delegation depend on lifetime) makes things more 
complicated, as this confuses delegation
is for short term, but not for long term. It's more useful in short term, but 
generally useful, should not restict.
Yoav: will want to take to the list.

Chair: Are you requesting this be adopted?
Yaron: That's on the next slide

Rich: put it (restriction to STAR) in the draft as an open issue.

Richard: If a CNAME has been delegated, the NDC "owns" it can do the
HTTP challenge (maybe not the DNS challenge) just by having the record pointed
at it.
Jon Peterson: How does base ACME work when resolving the challenge?
Richard: There are some CDNs today that do this today, for ACME issuance.
Richard: It appears the CNAME here is confusing, but the rest of the document
is sound. There is a scoping question if the CNAME connection is suitable.
Jon: If you only have an account with the NDC, but not the IdO then yeah, you
wouldn't be able to prove ownership.
Richard: ACME accounts are cheap. Except where CA is imposing
conditions. You may, e.g. lock a domain to an account but I'm unsure if that's
being done in practice.
Chris Wendt: Are you locking this to DNS type or open to other identifier 
types? Might want other identifiers in STIR.
Yaron: Once this is a WG document, this is a WG decision, but I don't see a 
reason to lock it to DNS.
Sanjay Mishra: The CNAME used here, the NDC is asking IdO to use it?
Yaron: Yes.

Hum on whether this area is of interest to the group - yes.
AI: Chairs to issue call for adoption in 1-2 weeks, to give people time to read.

## Email TLS certs and EMAIL end-user certs, 15 minutes
Who will read?  Ready for WGLC?

Paul Hofman: I don't understand the proposed change
Alexey: At the moment service/port are single. If you wanted to issue multiple
ports (IMAP/IMAPS) it needs to be multiple requests.
Paul: I see no reason not to have multiple services.
Chaair: One array or two?
Alexey: One array
Richard: I'm confused. This document is talking about authenticating
DNS, but what would go into a certificate is a Domain.
Alexey: In theory you could issue SRV based IDs. In the most common use cases
that won't be used.
Richard: I think this should be updated to cover SRV.
DKG: I want to agree with Richard. If it's just on name, this is too complex.
Several steps need including
Alexey: For DNS there will be slightly specific service name.
DKG: If the cert being requested isn't specifically for the service, this
could open an attack to other services for other protocols
AI: Alexey to add some clarifying text, Richard to send some
AI: After next draft, WGLC; READ

Paul Hoffman: These details aren't clear in the current draft.
Richard: We have a copy of layers of indirection, what I am least clear on is
the mapping of service to certificate. CA's may want to include SRV into the
cert if you show control of the domain.
Alexey: I'm hoping they'll issue certs with the port
Richard: I suggest you implement SRV service IDs
Tim: SRV has been discussed but not implemented
Tim: The assumption all zones in a domain are controlled by the same identity 
is no longer true.
Alexey: I am developing software that could develop software to validate these, 
but first I need CAs to issue certs against this.


Yaron: Are you expecting end user to perform this challenge?
Alexey: Yes, possibly through copy/pasting the challenge.
Chair: Is there any provisiion for multiple clients?
AI: Tim H and dkg said they would review

## TN Authority Token documents, 20 minutes
Updates

AI: Another rev then WGLC


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

[Acme] Fwd: New Version Notification for draft-sheffer-acme-star-delegation-00.txt

[Yaron Sheffer]

This is a complete rewrite of draft-sheffer-acme-star-request, the 
protocol that describes how STAR certificates can be used for 
certificate delegation.


As requested by several WG members, this is now an ACME (-STAR) profile.

Thanks,
Yaron


 Forwarded Message 
Subject: New Version Notification for 
draft-sheffer-acme-star-delegation-00.txt

Date: Fri, 19 Oct 2018 19:29:33 -0700
From: internet-dra...@ietf.org
To: Yaron Sheffer , Thomas Fossati 
, Antonio Agustin Pastor Perales 
, Antonio Pastor 
, Diego Lopez 




A new version of I-D, draft-sheffer-acme-star-delegation-00.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-sheffer-acme-star-delegation
Revision:   00
Title:  An ACME Profile for Generating Delegated STAR Certificates
Document date:  2018-10-19
Group:  Individual Submission
Pages:  12
URL: 
https://www.ietf.org/internet-drafts/draft-sheffer-acme-star-delegation-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-sheffer-acme-star-delegation/
Htmlized: 
https://tools.ietf.org/html/draft-sheffer-acme-star-delegation-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-sheffer-acme-star-delegation



Abstract:
   This memo proposes a profile of the ACME protocol that allows the
   owner of an identifier (e.g., a domain name) to delegate to a third
   party access to a certificate associated with said identifier.  A
   primary use case is that of a CDN (the third party) terminating TLS
   sessions on behalf of a content provider (the owner of a domain
   name).  The presented mechanism allows the owner of the identifier to
   retain control over the delegation and revoke it at any time by
   cancelling the associated STAR certificate renewal with the ACME CA.
   Another key property of this mechanism is it does not require any
   modification to the deployed TLS ecosystem.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

[Acme] Fwd: New Version Notification for draft-ietf-acme-star-04.txt

[Yaron Sheffer]

This version addresses WGLC comments received from Sean, as well as the 
latest changes in the base ACME protocol.


Thanks,
Yaron

 Forwarded Message 
Subject: New Version Notification for draft-ietf-acme-star-04.txt
Date: Fri, 19 Oct 2018 19:27:55 -0700
From: internet-dra...@ietf.org
To: Oscar Gonzalez de Dios , Yaron 
Sheffer , Thomas Fossati 
, Oscar de Dios 
, Diego Lopez 
, Antonio Agustin Pastor Perales 
, Antonio Pastor 




A new version of I-D, draft-ietf-acme-star-04.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-ietf-acme-star
Revision:   04
Title:		Support for Short-Term, Automatically-Renewed (STAR) 
Certificates in Automated Certificate Management Environment (ACME)

Document date:  2018-10-19
Group:  acme
Pages:  22
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-acme-star-04.txt

Status: https://datatracker.ietf.org/doc/draft-ietf-acme-star/
Htmlized:   https://tools.ietf.org/html/draft-ietf-acme-star-04
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-acme-star
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-04

Abstract:
   Public-key certificates need to be revoked when they are compromised,
   that is, when the associated private key is exposed to an
   unauthorized entity.  However the revocation process is often
   unreliable.  An alternative to revocation is issuing a sequence of
   certificates, each with a short validity period, and terminating this
   sequence upon compromise.  This memo proposes an ACME extension to
   enable the issuance of short-term and automatically renewed (STAR)
   X.509 certificates.

   [RFC Editor: please remove before publication]

   While the draft is being developed, the editor's version can be found
   at https://github.com/yaronf/I-D/tree/master/STAR.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Acme] Allow get for certificates?

[Yaron Sheffer]

IMO Richard's proposal is too coarse, in the sense that servers may want 
to publish some certificates with GET and others with POST-as-GET. So 
either this should not be a server-wide flag, or if it is, it should be 
augmented by a per-Order flag where the client can request what it needs.


Before this PR, the expectation is that certificates are only published 
with POST-as-GET by default. But extensions (such as STAR) can mandate 
that specific classes of certs be published with GET. If we don't want 
explicit per-Order signaling, we'd better leave the current text as-is.


Thanks,

    Yaron


On 07/10/18 22:48, Richard Barnes wrote:

I went ahead and posted a PR adding the "meta" field:

https://github.com/ietf-wg-acme/acme/pull/462


On Sun, Oct 7, 2018 at 5:04 AM Thomas Fossati 
mailto:thomas.foss...@nokia.com>> wrote:


The 10/06/2018 17:27, Richard Barnes wrote:
> I'm not hard set against this change, I just don't see much benefit.
>
> Allowing GETs for certificate URLs is so low-risk that we
weren't going to
> access-control it at all until a couple weeks ago. Now it's so
high-risk
> that we need to REQUIRE authentication?  That's "REQUIRED" in
the RFC 2119
> sense, since higher up in the section, it says that servers MUST
return 405
> if they get a GET, except as allowed in that section.
>
> There are reasonable use cases for GETs.  STAR is one, but you could
> imagine non-auto-renewed cases as well.  There's no security
reason to cut
> off those GETs, so I don't understand what value we're
conserving here.
> The PR says that having GETs complicates the security analysis,
but this is
> not some inner part of the protocol, it's the output.

>From the point of view of STAR this is not a big deal.  We have
acme-star where to define both the plain-GET exception - which is
a core
requirement for the delegation workflow - and how the server
advertises
support for it.

My worry is that by accepting this change, other legit plain-GET use
cases are automatically made either more complicated or potentially
insecure (someone might decide that sharing the account key across a
bunch of edge caches or some other HA configuration is a worth
trade-off.)

That said...

> The only argument that seems at all cogent here is that we don't
have
> any up-front signaling for whether a server supports GET or not,
just
> the error code.  So clients have to guess.  Maybe that's enough to
> motivate removing it for now; a later doc could come along and say
> "allow GETs and signal it with this field in the meta object".

 it should be pretty easy to add the needed meta object extension
directly into the acme-acme document if this is the only missing
piece?

> But if we do that, we should be clear that we're removing GET to
keep
> the protocol flow clean, not for any security reason.

Emphatic +1



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

Re: [Acme] ACME breaking change: Most GETs become POSTs

[Yaron Sheffer]

Hi Richard,

I think we're in a good place, even from a STAR perspective (where 
certificates must be accessible with a GET, or the whole thing breaks 
down). To clarify the behavior further, I suggest to add the following 
text after the paragraph that says that "The server MAY allow GET 
requests for certificate resources...":


The server MAY choose to allow GET requests to certain certificate 
resources but not to others. The server can base this decision on 
out-of-band knowledge (e.g., to allow GET requests to certificates owned 
by a certain account) or on order-specific information, such as the 
extension defined in {{?I-D.ietf-acme-star}}.


Thanks,
    Yaron

On 01/09/18 01:08, Richard Barnes wrote:

Hey all,

This thread forked into a couple of different issues, so I wanted to 
post a little end-of-day summary of the issues and where we stand.  
I've updated the PR [1] to reflect most of today's discussion.


===

ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing 
the privacy analysis?


It seems like there's pretty strong agreement that we should get rid 
of GET, as the architecturally cleanest option.


===

ISSUE 2: How should we signal that POST-as-GET request is different 
from other POST requests?


The current PR signals this by sending a JWS with an empty 
(zero-octet) payload, instead of a JSON object.  Jacob and Daniel 
suggested that we should instead use the payload being an empty JSON 
object as the signal.  An earlier draft PR used a field in the 
protected header.


===

ISSUE 3: Should servers be required to allow GET requests for 
certificate URLs?


I had proposed this earlier today; Jacob and Daniel pushed back.  I 
have implemented a compromise in the latest PR, where servers MAY 
accept GET requests.


===

ISSUE 4: How should we address the risk that an attacker can discover 
URLs by probing for Unauthorized vs. Not Found?


There seemed to be agreement on the list that this should be addressed 
with some guidance to servers on how to assign URLs.  I have just 
added some text to the PR for this.


===

It seems to me we're pretty much closed on the first issue, and the 
other three are still open.  Please send comments, so we can resolve 
this issue and get the document back in motion!


Thanks,
--Richard

[1] https://github.com/ietf-wg-acme/acme/pull/445

On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews > wrote:


ACME currently has unauthenticated GETs for some resources. This was
originally discussed in January 2015[1]. We decided to put all
sensitive
data in the account resource and consider all GET resources
public, with
a slant towards transparency.

Adam Roach recently pointed out in his Area Director review that even
when the contents of GET URLs aren’t sensitive, their correlation may
be. For instance, some CAs might consider the grouping of
certificates
by account to be sensitive.

Richard Barnes proposes[2] to change all GETs to POSTs (except
directory
and new-nonce). This will be a breaking change. Clients that were
compatible with previous drafts, informally called ACMEv1 and ACMEv2,
will not be compatible with a draft that mandates POSTs
everywhere. It
will be a painful change, since the ecosystem just started
switching to
ACMEv2, which looked to be near-final.

I think this is the right path forwards. ACME will be a simpler,
better
protocol long-term if all requests are authenticated. However, if
we’re
taking this path we should aim to come to consensus and land the
final
spec quickly to reduce uncertainty for ACME client implementers.

[1]
https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712
[2] https://github.com/ietf-wg-acme/acme/pull/445/files

___
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] Fwd: New Version Notification for draft-ietf-acme-star-03.txt

[Yaron Sheffer]

This new version of the draft adds a discussion of time skew in practice 
and what it implies for the validity term of short-term certificates, as 
well as the considerations related to the Certificate Transparency (CT) 
infrastructure.


Thanks,
Yaron

 Forwarded Message 
Subject: New Version Notification for draft-ietf-acme-star-03.txt
Date: Sat, 03 Mar 2018 12:29:30 -0800
From: internet-dra...@ietf.org
To: Oscar Gonzalez de Dios <oscar.gonzalezded...@telefonica.com>, Yaron 
Sheffer <yaronf.i...@gmail.com>, Thomas Fossati 
<thomas.foss...@nokia.com>, Oscar de Dios 
<oscar.gonzalezded...@telefonica.com>, Diego Lopez 
<diego.r.lo...@telefonica.com>, Antonio Agustin Pastor Perales 
<antonio.pastorpera...@telefonica.com>, Antonio Pastor 
<antonio.pastorpera...@telefonica.com>



A new version of I-D, draft-ietf-acme-star-03.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-ietf-acme-star
Revision:   03
Title:		Support for Short-Term, Automatically-Renewed (STAR) 
Certificates in Automated Certificate Management Environment (ACME)

Document date:  2018-03-03
Group:  acme
Pages:  20
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-acme-star-03.txt

Status: https://datatracker.ietf.org/doc/draft-ietf-acme-star/
Htmlized:   https://tools.ietf.org/html/draft-ietf-acme-star-03
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-03

Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-03

Abstract:
   Public-key certificates need to be revoked when they are compromised,
   that is, when the associated private key is exposed to an attacker.
   However the revocation process is often unreliable.  An alternative
   to revocation is issuing a sequence of certificates, each with a
   short validity period, and terminating this sequence upon compromise.
   This memo proposes an ACME extension to enable the issuance of short-
   term and automatically renewed (STAR) certificates.

   [RFC Editor: please remove before publication]

   While the draft is being developed, the editor's version can be found
   at https://github.com/yaronf/I-D/tree/master/STAR.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

[Acme] Fwd: New Version Notification for draft-ietf-acme-star-02.txt

[Yaron Sheffer]

We just published a new version of the draft, based on inputs from the 
Singapore meeting. Main changes:


- Discovery of STAR capabilities via the directory object
- Use the more generic term Identifier Owner (IdO) instead of Domain 
Name Owner (DNO)

- More precision about what goes in the order
- Clarify server side behavior on cancellation

Thanks,
Yaron

 Forwarded Message 
Subject: New Version Notification for draft-ietf-acme-star-02.txt
Date: Wed, 29 Nov 2017 06:56:16 -0800
From: internet-dra...@ietf.org
To: Oscar Gonzalez de Dios <oscar.gonzalezded...@telefonica.com>, Yaron 
Sheffer <yaronf.i...@gmail.com>, Thomas Fossati 
<thomas.foss...@nokia.com>, Oscar de Dios 
<oscar.gonzalezded...@telefonica.com>, Diego Lopez 
<diego.r.lo...@telefonica.com>, Antonio Agustin Pastor Perales 
<antonio.pastorpera...@telefonica.com>, Antonio Pastor 
<antonio.pastorpera...@telefonica.com>



A new version of I-D, draft-ietf-acme-star-02.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-ietf-acme-star
Revision:   02
Title:		Support for Short-Term, Automatically-Renewed (STAR) 
Certificates in Automated Certificate Management Environment (ACME)

Document date:  2017-11-29
Group:  acme
Pages:  19
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-acme-star-02.txt

Status: https://datatracker.ietf.org/doc/draft-ietf-acme-star/
Htmlized:   https://tools.ietf.org/html/draft-ietf-acme-star-02
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-02

Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-02

Abstract:
   Public-key certificates need to be revoked when they are compromised,
   that is, when the associated private key is exposed to an attacker.
   However the revocation process is often unreliable.  An alternative
   to revocation is issuing a sequence of certificates, each with a
   short validity period, and terminating this sequence upon compromise.
   This memo proposes an ACME extension to enable the issuance of short-
   term and automatically renewed (STAR) certificates.

   [RFC Editor: please remove before publication]

   While the draft is being developed, the editor's version can be found
   at https://github.com/yaronf/I-D/tree/master/STAR.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Acme] Proposed wording for CAA validation-methods section

[Yaron Sheffer]

The second paragraph is hard for me to parse. Let me try to reword it.

The presence of this parameter in a property further constrains 
certificate issuance for that property. Whenever the parameter is 
included in a property, a CA MUST NOT use any validation method unless 
the method is explicitly listed.


Thanks,
Yaron



Since the consensus seems to be to change to "validation-methods",
here's the wording I propose for the validation-methods section:

   Extensions to the CAA Record: validation-methods Parameter
   ==

   A CAA parameter "validation-methods" is also defined for the "issue" and
   "issuewild" properties. The value of this parameter, if specified, MUST
   be a comma-separated string of challenge method names. Each challenge
   method name MUST be either an ACME challenge method name or a
   CA-assigned non-ACME challenge method name.

   The presence of this parameter constrains the property to which it is
   attached. A CA MUST only consider a property with the
   "validation-methods" parameter to authorize issuance where the name of
   the challenge method being used is one of the names listed in the
   comma-separated list.

   Where a CA supports both the "validation-methods" parameter and one or
   more non-ACME challenge methods, it MUST assign identifiers to those
   methods. These identifiers MUST be chosen to minimise the likelihood of
   conflict with any ACME challenge method name; it is RECOMMENDED that, at
   the very least, CAs avoid assigning identifiers ending in a hyphen and
   two digits ("-00").

   A CA SHOULD assign individual identifiers to each of its non-ACME
   challenge methods. However, if it is unable or unwilling to do so, it
   MAY use the fallback identifier of "non-acme" to identify such methods.



--

Subject: Digest Footer

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


--

End of Acme Digest, Vol 34, Issue 1
***



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

Re: [Acme] Consensus -- CAA draft to WGLC?

[Yaron Sheffer]

The problem with saying "Tokens registered as ACME challenge types MUST 
NOT be used to identify non-ACME validation methods" is that ACME might 
want to come up with additional method names in the future, and those 
just might happen to conflict with methods that have been used by other 
organizations in the meantime. This is exactly the kind of mess that 
IANA is designed to prevent.


A simple way to go around this issue is if we changed the draft to use 
"acme-dns-01" instead of "dns-01" and similarly for all ACME methods. 
Then we COULD say that non-ACME CAs MUST not use "acme-*" methods.


To your second point, many enterprise users will want the extra security 
of "use this specific CA AND only with this method". There are probably 
other use cases though.


Thanks,

Yaron


On 06/07/17 00:17, Richard Barnes wrote:
Just for context here: I think the original operating model for CAA 
was that the CA would tell the customer what values to put in there in 
order to authorize issuance.  So it was safe to use arbitrary values 
because it was basically a closed loop CA -> Customer -> CAA -> CA.


Nonetheless, I sympathize with your point here.  With ACME, we're 
moving things in a more standardized / automated direction, so we can 
automate out some of the CA interaction around CAA if we standardize 
some values.


Note that the ACME challenge type values are already registered.  
Would it be sufficient to say something like "Tokens registered as 
ACME challenge types MUST NOT be used to identify non-ACME validation 
methods"?


---

This reminds me a related point that I forgot in my initial review.  
It would be nice if it were possible to specify a validation method 
policy independent of CA.  So I wouldn't have to authorize each CA I 
interact with individually, but I would be able to say "Only validate 
my domains using dns-01".


In fact, is there any reason to have different validation methods per 
CA?  It's a property of the domain owner / certificate applicant, not 
the CA. Is there a reason you would trust CA X to do "http-01" but not 
CA Y?  (I totally understand why "account-uri" is CA-specific, though.)


I would suggest pulling out "validation-methods" from being an 
attribute to being a "tag" / "property", parallel to "issue" and 
"issuewild".




On Wed, Jul 5, 2017 at 3:45 PM, Yaron Sheffer <yaronf.i...@gmail.com 
<mailto:yaronf.i...@gmail.com>> wrote:


I support moving forward with the document.

However I think the treatment of the acme-methods (or
validation-methods) param is inconsistent, before and certainly
after Richard's PR. The original draft only allows ACME methods
and the special name "non-acme". This leaves the responsibility to
ensure names are well defined with the IETF.

If we allow mixing ACME methods with CA-defined methods per
Richard's proposal, we should make sure that there is no overlap.
And even if names are defined by individual CAs, the CA should
provide a precise definition of each validation method. IMO there
are two good options:

- Define an IANA registry for the validation-methods values. (This
is simple enough, and would be my preference).
- Define an IANA registry for prefixes (such as "cabf" mentioned
in Richard's text) and specify that everything else must be
defined by ACME.

Thanks,
Yaron



https://github.com/ietf-wg-acme/acme-caa/pull/2
<https://github.com/ietf-wg-acme/acme-caa/pull/2>

On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich <rs...@akamai.com
<mailto:rs...@akamai.com>> wrote:

There's no listing going on here, since there's no
registry for the

values.  CABF could put tokens in their documents if they
like.

Okay, please propose wording (or did you?  Sorry if so) to
change for the
CAA draft.




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




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

Re: [Acme] Consensus -- CAA draft to WGLC?

[Yaron Sheffer]

I support moving forward with the document.

However I think the treatment of the acme-methods (or 
validation-methods) param is inconsistent, before and certainly after 
Richard's PR. The original draft only allows ACME methods and the 
special name "non-acme". This leaves the responsibility to ensure names 
are well defined with the IETF.


If we allow mixing ACME methods with CA-defined methods per Richard's 
proposal, we should make sure that there is no overlap. And even if 
names are defined by individual CAs, the CA should provide a precise 
definition of each validation method. IMO there are two good options:


- Define an IANA registry for the validation-methods values. (This is 
simple enough, and would be my preference).
- Define an IANA registry for prefixes (such as "cabf" mentioned in 
Richard's text) and specify that everything else must be defined by ACME.


Thanks,
Yaron



https://github.com/ietf-wg-acme/acme-caa/pull/2

On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich  wrote:


There's no listing going on here, since there's no registry for the

values.  CABF could put tokens in their documents if they like.

Okay, please propose wording (or did you?  Sorry if so) to change for the
CAA draft.






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

Re: [Acme] ACME -06: HTTPS authorization

[Yaron Sheffer]

Hi Jacob,


To your first point, I was talking specifically of REST endpoints, not 
of people accessing web servers from a browser. For such configurations 
I think you will agree that HTTPS-only is a valid setup.



Thanks,

Yaron


On 26/06/17 14:59, Jacob Hoffman-Andrews wrote:

On 05/30/2017 08:32 AM, Yaron Sheffer wrote:
- The server only supports HTTPS, and perhaps port 80 is blocked by a 
firewall. This situation applies to many REST endpoints.
This is in general a bad configuration. Leaving port 80 open for the 
purposes of redirects is safe, and provides a better first-time users 
experience (repeat users may take advantage of an HSTS header, which I 
would assume to be present in such a config). And keep in mind that 
validation in ACME follows redirects.


- I am migrating from a non-ACME to an ACME cert, and so the server 
has a perfectly valid HTTPS cert. Or migrating from one ACME CA to a 
different one.

This doesn't make it harder to server HTTP on port 80.
- I would like to ensure (using CAA records) that my CA is not 
subject to a DNS cache corruption attack - a threat that the ACME 
Security Considerations specifically mention.
I think this is the most compelling reason to offer HTTPS 
authorization. In particular, I think it may make sense as a special 
requirement for "high risk" validations. That is, for certain 
validations, the ACME server may choose to require validation over 
HTTPS using a certificate that validates to a certain set of roots.


However, requiring validation over HTTPS using a valid certificate 
would be too onerous for general-purpose certificates, because it 
would mean that server operators who lose their account key and all 
certificate private keys could not recover and issue a certificate 
without manual intervention.


I think HTTPS-with-valid-certificate is an interesting topic for 
future implementation, but is complex enough that we shouldn't try to 
squeeze it into the current document.


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

Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

[Yaron Sheffer]

On 25/06/17 03:52, Martin Thomson wrote:

On 24 June 2017 at 02:24, Yaron Sheffer <yaronf.i...@gmail.com> wrote:

Expires is to ensure that the certificate is not
cached beyond the point where a newer certificate will be issued.  You
should remove this text.

OK

Is there some other common header to denote that the value of a URL is only
good for X time?

Isn't enough to rely on the server echoing your parameters?  (Another
reason to use absolute values for the end of the recurring interval.)
I'm not following you. In Sec. 3.4 we're saying that the (periodically 
rolling) certificate is always available on the same URL, the 
"certificate endpoint". Since the content available at that URL changes 
from time to time, we wanted to indicate its end-of-validity with an 
HTTP header. If "Expires" is not the right header, is there a better way 
to do it?



Don't mention time-sensitive policy actions by the CA/B Forum.

Makes sense.

I disagree. CA/B forum decisions (unlike IETF standards) are mandatory for
some parties to follow and so can be relied upon by the DNO.

This is a protocol.  What CABF do with it is entirely up to them.
They aren't the only ones creating policy that might affect someone
using this protocol.
But people are not obligated to implement IETF protocols. OTOH some 
organizations *are* bound by CA/B Forum rules. And this section is 
predicated on the assumption at all "reasonable" CAs do honor CAA 
records, otherwise a rogue CDN employee can create a certificate for the 
domain on a non-ACME CA, if they only require a proof of ownership of 
the web server.



Can't you simply ensure that the CDN can't modify the CAA record?

This is the minimum we could say.  At this point, I think we are trying
to explore a bit what other mitigations can be put in place.

Unfortunately this is insufficient, because in the case of CDN's, some of
the authorization methods are subject to spoofing.

If the CAA record exists, then spoofing won't result in the
certificate being issued, so what is the problem?
Basic CAA, prior to Hugo's draft, only says which CA you are trusting. 
But that CA can still choose the spoofable http-01 authorization - 
spoofable if you are the CDN and so you control the web pages.


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

Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

[Yaron Sheffer]

Hi Martin, Thomas,

Hi Martin,

Thanks for your review.

On 19/06/2017, 23:34, "Acme on behalf of Martin Thomson"  wrote:

A few brief comments on this draft.


[snip]

I don't understand Section 3.3 at all.  I'd recommend removing this
section.  The DNO will decide what authorizations it requests amply
without this level of proscription in standards.

Yaron: thoughts on this?
This is yet another LURK leftover, where we make assumptions about the 
capabilities of the NDC. Prescription makes sense in some particular 
cases, but I agree this should be folded into the security 
considerations (specifically Sec. 5.1) instead of the protocol's body.



In Section 3.4, the use of the Expires header field is a common
mistake.  This is an HTTP caching directive.  It should probably be
shorter than the expiration time of the certificate (half in fact),
but not for the reasons that you might think.  The purpose of a
recommendation on Expires is to ensure that the certificate is not
cached beyond the point where a newer certificate will be issued.  You
should remove this text.

OK
Is there some other common header to denote that the value of a URL is 
only good for X time?


[snip]




Don't mention time-sensitive policy actions by the CA/B Forum.

Makes sense.
I disagree. CA/B forum decisions (unlike IETF standards) are mandatory 
for some parties to follow and so can be relied upon by the DNO.



Can't you simply ensure that the CDN can't modify the CAA record?

This is the minimum we could say.  At this point, I think we are trying
to explore a bit what other mitigations can be put in place.
Unfortunately this is insufficient, because in the case of CDN's, some 
of the authorization methods are subject to spoofing.


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

Re: [Acme] ACME IP Identifier Validation

[Yaron Sheffer]

Following on comments made in the interim meeting, I would like to 
request the author to add a few paragraphs to clarify the use case(s) of 
these IP-based certs and rev the draft, before we go into the adoption 
discussion on the list.


Thanks,
Yaron

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

Re: [Acme] ACME -06: smaller issues

[Yaron Sheffer]

Resending, this post seems to have been lost in the noise. Should I open 
a PR? Multiple PRs?


Thanks,

Yaron


On 30/05/17 18:52, Yaron Sheffer wrote:
* Order Objects, "authorizations". The text says, "For final orders, 
the authorizations that were completed." Are we using "completed" to 
mean "successfully completed"? Maybe we should say so explicitly.


* Directory object: not wishing to be drawn into the TOS discussion 
again, but I think the example would be more useful, if the URL was 
https://example.com/acme/terms/2017-5-30 instead of 
https://example.com/acme/terms, because clients can then detect 
changes more easily.


* Changes of Terms of Service: the example is missing the mandatory 
Link header that's mentioned in the text.


* Account key roll-over: the current check #8 is "Check that the 
“newKey” field of the key-change object also verifies the inner JWS." 
I think that requiring that "newKey" is bitwise identical to the inner 
"jwk" is both strictier and more correct.


* Account deactivation: shouldn't we also say that all pending Orders 
MUST be invalidated?


* Downloading the Certificate: in the example, the client asks for a 
single cert (Accept: application/pkix-cert) and receives a chain 
(application/pem-certificate-chain) - is this legal? This also seems 
to conflict with the last paragraph of the section.


* MIME Type: application/pem-certificate-chain - typo: "Carries a 
cryptographic certificate" should be "Carries a list of cryptographic 
certificates"


Thanks,
Yaron



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

Re: [Acme] ACME -06: revocation

[Yaron Sheffer]

I know I'm in the rough here, but IMHO for many enterprises, when they 
compare between a certain downtime and a not so certain MITM threat, 
they would decide differently. But I'm not going to argue this point any 
further.


Thanks,

Yaron


On 30/05/17 20:10, Russ Housley wrote:

Yaron:

If a party that has access to the private key is telling the CA that 
the certificate ought to be revoked.  I’m thinking that the CA ought 
to revoke it.  Any party that has access to that private key can do 
far more malicious things.


Russ



On May 30, 2017, at 11:48 AM, Richard Barnes <r...@ipv.sx 
<mailto:r...@ipv.sx>> wrote:




On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer 
<yaronf.i...@gmail.com <mailto:yaronf.i...@gmail.com>> wrote:


When we allow the issued certificate to revoke itself, this has
major implications, in particular for delegated certificates. But
even for regular certs, it is the account's private key that's
more secure (it is managed by the security personnel where such
exist, it is not deployed on multiple servers) and that is the
certificate that should be preferred for revocation. So I suggest
to use MAY for revocation by the issued certificate's private
key, instead of SHOULD.


You MAY not like the latest change we made, which upgraded this 
requirement to MUST :)


https://github.com/ietf-wg-acme/acme/pull/300

Also, including the actual certificate in the request means that
the CA needs to perform multiple preliminary checks that would
not be required if the client sent the certificate URL (or its
serial number). The CA MUST parse the certificate, MUST validate
it, MUST ensure that it was issued by the current CA, and then
MUST identify it in its database of issued certs. More
complexity, more opportunities for security holes.


The idea of including the certificate (as well as allowing a 
certificate to revoke itself) was to support the case where an admin 
just finds a certificate + private key lying around, and wants to 
kill it.  In that case, you have neither the Certificate URI nor the 
account private key.


I would note that we have shifted from referencing keys by value to 
by reference in request JWS objects, requiring clients to track their 
account URIs.  We made that change in the interest of forcing the 
server to look up a public key for the account, reducing the 
likelihood of the server accepting a signature by an unknown key.


We might get some similar benefits here, but maybe not -- after all, 
if the certificate doesn't correspond to a URI, then it's probably 
not from this CA, in which case it the CA can't revoke it anyway.


--Richard


Thanks,
Yaron

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


___
Acme mailing list
Acme@ietf.org <mailto: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] ACME -06 - notBefore/notAfter

[Yaron Sheffer]

OK, that wasn't clear to me in the context. Maybe change to:


The server MUST return an error if it cannot fulfill the request as 
specified (including the CSR any other fields), and MUST NOT issue a 
certificate with contents other than those requested.


On 30/05/17 18:53, Richard Barnes wrote:

"""
The server MUST return an error if it cannot fulfill the request as 
specified, and MUST NOT issue a certificate with contents other than 
those requested.

"""

https://ietf-wg-acme.github.io/acme/#rfc.section.7.4


On Tue, May 30, 2017 at 11:51 AM, Yaron Sheffer <yaronf.i...@gmail.com 
<mailto:yaronf.i...@gmail.com>> wrote:


In the "Applying for Certificate Issuance" section: the notBefore
and notAfter fields are not part of the CSR, and it is not clear
if the server is allowed to change them according to its own
policy. E.g. for a shorter period than requested.

Thanks,
Yaron

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




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

Re: [Acme] ACME -06: revocation

[Yaron Sheffer]

On 30/05/17 18:48, Richard Barnes wrote:



On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer <yaronf.i...@gmail.com 
<mailto:yaronf.i...@gmail.com>> wrote:


When we allow the issued certificate to revoke itself, this has
major implications, in particular for delegated certificates. But
even for regular certs, it is the account's private key that's
more secure (it is managed by the security personnel where such
exist, it is not deployed on multiple servers) and that is the
certificate that should be preferred for revocation. So I suggest
to use MAY for revocation by the issued certificate's private key,
instead of SHOULD.


You MAY not like the latest change we made, which upgraded this 
requirement to MUST :)


https://github.com/ietf-wg-acme/acme/pull/300

Also, including the actual certificate in the request means that
the CA needs to perform multiple preliminary checks that would not
be required if the client sent the certificate URL (or its serial
number). The CA MUST parse the certificate, MUST validate it, MUST
ensure that it was issued by the current CA, and then MUST
identify it in its database of issued certs. More complexity, more
opportunities for security holes.


The idea of including the certificate (as well as allowing a 
certificate to revoke itself) was to support the case where an admin 
just finds a certificate + private key lying around, and wants to kill 
it.  In that case, you have neither the Certificate URI nor the 
account private key.


I would note that we have shifted from referencing keys by value to by 
reference in request JWS objects, requiring clients to track their 
account URIs.  We made that change in the interest of forcing the 
server to look up a public key for the account, reducing the 
likelihood of the server accepting a signature by an unknown key.


We might get some similar benefits here, but maybe not -- after all, 
if the certificate doesn't correspond to a URI, then it's probably not 
from this CA, in which case it the CA can't revoke it anyway.


--Richard


I certainly don't like the latest change :-)

I understand the use case of "finding a key lying around" (although I've 
never personally found a key lying around), but if you think of an 
enterprise with a small group of people managing security but a much 
larger group of people with access to server certs, this provides any 
server admin with a trivial way to DoS the organization by revoking 
www.bigcorp.com, so trivial that people can do it by mistake.


Thanks,

Yaron


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

[Acme] ACME -06 - notBefore/notAfter

[Yaron Sheffer]

In the "Applying for Certificate Issuance" section: the notBefore and 
notAfter fields are not part of the CSR, and it is not clear if the 
server is allowed to change them according to its own policy. E.g. for a 
shorter period than requested.


Thanks,
Yaron

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

Re: [Acme] ACME -06: HTTPS authorization

[Yaron Sheffer]

But removing the restriction would mean that the CA is free to do either 
HTTP or HTTPS, and the client doesn't know what to expect. So if my port 
80 is firewalled, I'm still not in good shape.


Thanks,

Yaron


On 30/05/17 18:38, Richard Barnes wrote:



On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer <yaronf.i...@gmail.com 
<mailto:yaronf.i...@gmail.com>> wrote:


I'm not sure I understand why the section that describes HTTP
validation so specifically forbids using HTTPS.


This was because of the default-vhost attack.

https://ietf-wg-acme.github.io/acme/#rfc.section.11.2

Given that we don't really have any data on how common this 
vulnerability is, I'm split on whether to keep the restriction.


--Richard

On the other hand, I can think of use cases where I would want
*only* HTTPS authorization:

- The server only supports HTTPS, and perhaps port 80 is blocked
by a firewall. This situation applies to many REST endpoints.
- I am migrating from a non-ACME to an ACME cert, and so the
server has a perfectly valid HTTPS cert. Or migrating from one
ACME CA to a different one.
- I would like to ensure (using CAA records) that my CA is not
subject to a DNS cache corruption attack - a threat that the ACME
Security Considerations specifically mention.

I would suggest that we specify a HTTPS validation that's exactly
like http-01, except that it runs over authenticated HTTPS.

Thanks,
Yaron

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




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

[Acme] ACME -06: revocation

[Yaron Sheffer]

When we allow the issued certificate to revoke itself, this has major 
implications, in particular for delegated certificates. But even for 
regular certs, it is the account's private key that's more secure (it is 
managed by the security personnel where such exist, it is not deployed 
on multiple servers) and that is the certificate that should be 
preferred for revocation. So I suggest to use MAY for revocation by the 
issued certificate's private key, instead of SHOULD.


Also, including the actual certificate in the request means that the CA 
needs to perform multiple preliminary checks that would not be required 
if the client sent the certificate URL (or its serial number). The CA 
MUST parse the certificate, MUST validate it, MUST ensure that it was 
issued by the current CA, and then MUST identify it in its database of 
issued certs. More complexity, more opportunities for security holes.


Thanks,
Yaron

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

[Acme] ACME -06: HTTPS authorization

[Yaron Sheffer]

  
  
I'm not sure I understand why the section that describes HTTP
validation so specifically forbids using HTTPS. On the other hand, I
can think of use cases where I would want *only* HTTPS
authorization:

- The server only supports HTTPS, and perhaps port 80 is blocked by
a firewall. This situation applies to many REST endpoints.
- I am migrating from a non-ACME to an ACME cert, and so the server
has a perfectly valid HTTPS cert. Or migrating from one ACME CA to a
different one.
- I would like to ensure (using CAA records) that my CA is not
subject to a DNS cache corruption attack - a threat that the ACME
Security Considerations specifically mention.

I would suggest that we specify a HTTPS validation that's exactly
like http-01, except that it runs over authenticated HTTPS.

Thanks,
    Yaron
  


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

[Acme] Fwd: New Version Notification for draft-sheffer-acme-star-02.txt

[Yaron Sheffer]

We just submitted a new version of our certificate delegation draft, 
which we are requesting the ACME WG to adopt (to be discussed at the 
interim).


The main changes are around terminology (now more general than just 
CDNs) and new text that describes the public cloud use case for this 
solution.


Thanks,

Yaron


 Forwarded Message 
Subject:New Version Notification for draft-sheffer-acme-star-02.txt
Date:   Sat, 27 May 2017 13:06:24 -0700
From:   internet-dra...@ietf.org
To: 	Oscar de Dios <oscar.gonzalezded...@telefonica.com>, Yaron Sheffer 
<yaronf.i...@gmail.com>, Thomas Fossati <thomas.foss...@nokia.com>, 
Diego Lopez <diego.r.lo...@telefonica.com>, Oscar Gonzalez de Dios 
<oscar.gonzalezded...@telefonica.com>




A new version of I-D, draft-sheffer-acme-star-02.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-sheffer-acme-star
Revision:   02
Title:  Use of Short-Term, Automatically-Renewed (STAR) Certificates to 
Delegate Authority over Web Sites
Document date:  2017-05-27
Group:  Individual Submission
Pages:  18
URL:
https://www.ietf.org/internet-drafts/draft-sheffer-acme-star-02.txt
Status: https://datatracker.ietf.org/doc/draft-sheffer-acme-star/
Htmlized:   https://tools.ietf.org/html/draft-sheffer-acme-star-02
Htmlized:   https://datatracker.ietf.org/doc/html/draft-sheffer-acme-star-02
Diff:   https://www.ietf.org/rfcdiff?url2=draft-sheffer-acme-star-02

Abstract:
   This memo proposes two mechanisms that work in concert to allow a
   third party (e.g., a content delivery network) to terminate TLS
   sessions on behalf of a domain name owner (e.g., a content provider).

   The proposed mechanisms are:

  



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

[Acme] Fwd: New Version Notification for draft-sheffer-acme-star-00.txt

[Yaron Sheffer]

We just posted a new version of the STAR (formerly LURK/STAR, note the 
name change) draft. As a reminder: this is a method to use short-term 
certificates to delegate authority over a domain from a content owner to 
a CDN.


In addition to the high-level architecture, the document now includes 
the first version of the actual protocol, a simple REST API. Also, 
discussion of how this draft addresses some of the more difficult 
requirements posed by the CDNI architecture.


We are now working on an implementation.

Thanks,
Yaron


 Forwarded Message 
Subject: New Version Notification for draft-sheffer-acme-star-00.txt
Date: Wed, 19 Apr 2017 13:17:46 -0700
From: internet-dra...@ietf.org
To: Oscar Gonzalez de Dios <oscar.gonzalezded...@telefonica.com>, Oscar 
de Dios <oscar.gonzalezded...@telefonica.com>, Diego Lopez 
<di...@telefonica.es>, Thomas Fossati <thomas.foss...@nokia.com>, Yaron 
Sheffer <yaronf.i...@gmail.com>



A new version of I-D, draft-sheffer-acme-star-00.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:   draft-sheffer-acme-star
Revision:   00
Title:		Use of Short-Term, Automatically-Renewed (STAR) Certificates to 
Delegate Authority over Web Sites

Document date:  2017-04-19
Group:  Individual Submission
Pages:  15
URL: 
https://www.ietf.org/internet-drafts/draft-sheffer-acme-star-00.txt

Status: https://datatracker.ietf.org/doc/draft-sheffer-acme-star/
Htmlized:   https://tools.ietf.org/html/draft-sheffer-acme-star-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-sheffer-acme-star-00



Abstract:
   This memo proposes two mechanisms that work in concert to allow a
   third party (e.g., a content delivery network) to terminate TLS
   sessions on behalf of a domain name owner (e.g., a content provider).

   The proposed mechanisms are:




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Acme] draft-sheffer-acme-star-lurk: key lifetime ?

[Yaron Sheffer]

Date: Fri, 31 Mar 2017 09:07:14 +0300
From: Ilari Liusvaara 
To: "Dr. Pala" 
Cc: acme@ietf.org
Subject: Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ?
Message-ID:
<20170331060714.ga26...@lk-perkele-v2.elisa-laajakaista.fi>
Content-Type: text/plain; charset=utf-8

On Thu, Mar 30, 2017 at 03:36:30PM -0500, Dr. Pala wrote:

Hi Ilari, all,

I strongly disagree with your statement. From a crypto standpoint, key
rotation IS an important point and should be addressed. I think something
could/should be added to the I-D to limit the number of renewal or the
period where the same CSR can be used for certificate re-issuing.

The solution might be as simple as set a validity in the CSR that is
generated (if you want that to be in control of the requesting client). I am
not suggesting the specifics of how to solve it, but I think that this is a
point that should be addressed (possibly something that was in the mind of
the original authors, but did not make it in the document... ?).


I just read the draft. A facility to limit the private key period,
assuming you want to do that, already exists.

And there are a number of sane-looking metrics[1], where any timed key
rotation strictly[2] decreases security.


[1] Basically, anything that considers security issue duration.

[2] Meaning you get '<' operator in comparision, not '<='.


-Ilari


The draft is not very clear on this, but the intent is to limit the 
duration of each delegated certificate, as well as the duration of 
delegation as a whole. Once delegation is over, a new CSR needs to be 
generated.


However if the client wants to use the same private key forever, the CA 
will not stop it from doing that. And as far as I know, neither does a 
CA today.


Thanks,
Yaron

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

Re: [Acme] FW: [ietf-wg-acme/acme] Add CAA text (per IETF98) (#290)

[Yaron Sheffer]

Fulfilling my promise made the other day ?  A PR to address the CAA issue.



Rich's new text reads as follows: "Further, an ACME-based CA can use the 
Certification Authority Authorization record {{!RFC6844}} to prevent it 
from being misdirected and generate an unauthorized issuance."


IMHO we need a "SHOULD" here. If you're an ACME server, there's no 
reason to ignore CAA records. Especially since we are looking into 
adding ACME-specific information into these records, in 
draft-ietf-acme-caa-01.


Thanks,
Yaron

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

Re: [Acme] Proposal for adding arbitrary CA-specific, name-value pairs to registration object

[Yaron Sheffer]

From: Karthikeyan Bhargavan 
To: Ray Cheng 
Cc: "acme@ietf.org" , Jacob Hoffman-Andrews

Subject: Re: [Acme] Proposal for adding arbitrary CA-specific
name-value pairs to registration object
Message-ID: 
Content-Type: text/plain; charset=utf-8

It is worth noting that ?external_secret?, ?ca-account-secret?, and ?token? are 
all secret bearer tokens
and, as such, offer *significantly* less security than the default ACME 
mechanisms, and in some cases
may defeat the purpose of having account keys.

I can see that different vendors may have need for symmetric secrets like these 
for their own use,
but if we were to extend ACME to allow such ?external? secrets, we should 
standardize their secure use.

For example, a much safer way to embed ?external_secret?, ?ca-account-secret?, 
and ?token? would be
to have an ?external-key-id? field, that indicates a MAC key that has been 
exchanged out-of-band;
we would then use MAC-based authentication to bind the MAC key to the relevant 
JWS request,
using the standard nested authentication mechanism we are using in roll-over, 
something like:

Sign (account-key, (request, external-key-id, MAC (external_key, 
Hash(account_key

This would ensure that the external secret is never sent on the wire and is not 
a bearer token,
and the compound authentication guarantees of the resulting protocol are quite 
strong.

More generally, ACME is not a browser-based protocol and there is no need for 
us to rely
on obsolete cookie-like mechanisms; ACME clients and servers are already doing 
crypto,
so why not use MACs instead of passing bearer tokens in URLs or in the request?

Best,
Karthik


My understanding from the meeting was that some of these "secrets" will 
be simple user passwords, making the solution even less appetizing.


Thanks,
Yaron

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

[Acme] draft-ietf-acme-caa-00 - security considerations

[Yaron Sheffer]

Hi,

In the security considerations, specifically 5.6, we omit the trivial 
but most pertinent risk: the CAA record type must be implemented by all 
CAs in order to be fully effective. Any CA that does not honor CAA can 
potentially (mis-)issue a rogue cert for the domain in question.


I suspect that this is by far not the case today. In fact many managed 
DNS servers still do not support this record type either.


Thanks,

Yaron

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

Re: [Acme] URI-based CAA account binding

[Yaron Sheffer]

From: Hugo Landau 
To: Richard Barnes 
Cc: acme@ietf.org
Subject: Re: [Acme] URI-based CAA account binding
Message-ID: <20161003002918.ga5...@andover.lhh.devever.net>
Content-Type: text/plain; charset=iso-8859-1


   Thanks for the draft, Hugo.? In general, the idea of making CAA more
   precise seems like a good vein to explore, and to the dimensions of
   precision overlap with ACME semantics, it makes sense to do it here.

   The other case (besides account URI) that I've heard folks talk about is
   allowing the domain holder to restrict what validation methods the CA
   should be allowed to use.? For example, you might allow DNS validation and
   forbid HTTP validation.? Between ACME and the new, stricter Baseline
   Requirements, it seems like we should be able to come up with a pretty
   comprehensive list of validation methods.? Is this something that would
   make sense to fold into this document?


Alright, so here's some ideas:

-  An ACME-specific 'acme-methods' parameter taking a comma-separated
   list of methods (e.g. "acme-methods=dns-01,http-01").

-  A generic "method-uri" parameter which accepts a URI representing a
   method. For ACME this would be urn:ietf:acme:method:METHOD-NAME.
   Multiple methods would probably be specified via multiple CAA
   records; this would be slightly more obtuse for implementations
   to process than the above, but nothing unreasonable.

There's also the question of whether this should be in the same I-D or a
separate one. I'm fine with putting it in, but if anyone thinks it
should be a separate I-D, let me know.



I support this idea for the reasons listed here: 
https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00#section-4.3.


I think the first option (ACME-specific parameter) is preferred, because 
it is much better defined. I would suggest to include it in the current 
document, and with strict semantics: an ACME implementation that 
supports CAA MUST understand this parameter and MUST NOT use any method 
not listed here.


Thanks,
Yaron

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

Re: [Acme] Short term certificates - two options

[Yaron Sheffer]

Hi Alan,

Please refer back to my answer. We are talking MITM attacks here, not 
regular operation. The attacker can spoof DNS, e.g. by colluding with a 
local ISP.


Thanks,
Yaron

On 25/07/16 20:36, Alan Doherty wrote:

i have to ask how/why would you be sending the user to said cdn supplier (via 
dns)
in the first place
for them to see said expired cert (plus warnings if client gives them)

i agree, user/owner sudden distrust of a previously trusted cdn is the worst 
possible reason to demand CAs provide a method to have insanely short (and thus 
more expensive to provide in terms of resources) certs available

(renewal takes X resources, CA has resources to handle Y normal renewals per 90 
days) based on letsencrypt terms
a 2 day cert is x*45 times the resources thus ,to handle the same amount of 
customers 45 times the server capacity and bandwith to operate

i would suggest for the few requiring/demanding their chosen cdn salt earth and 
delete all data when they leave policy instead pay the extra at start to have 
explicit personalised terms of service drawn up with their cdn supplier they 
will terminate/delete/purge all data within x hours or notification instead

rather than making the CA (and cdn) work harder (not smarter) every day just so 
they (the owner) can have less hassle the 1 day they quit

automation may make repetitive tasks easier, but its still never good to repeat 
tasks more often unnecessarily just because automation has made it possible/easy

(especially as a cdn will normally have a maxed out san cert on each ip to 
enable swapping/loadbalancing reassigning domains to servers on the fly, and 
thus 1 customer demanding a 2 day renewal basically causes all to be 2 day 
renewal)



at 17:38 25/07/2016  Monday, Yaron Sheffer wrote:

I think we are slowly but surely getting into the weeds on this one. When we talk about 
"CDN revocation" (for lack of a better term), we mean that after a certain 
date, the owner of the content:

- Does not want the CDN, or a rogue employee of the CDN, to present the content 
as an authoritative source. If the user sees a big browser warning, that would 
*not* look authoritative.

- Does not want the CDN to be able to MITM the site for more sensitive traffic, 
such as POST messages that contain user passwords.

Short-term certs would handle this use case just fine.

And as a content owner, it's really nice to able to leave a CDN whenever I want 
to, without having to rely on it to keep my secrets for a few more years while 
we no longer have a business relationship.

Thanks,
   Yaron

___
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] Short term certificates - two options

[Yaron Sheffer]

I think we are slowly but surely getting into the weeds on this one. 
When we talk about "CDN revocation" (for lack of a better term), we mean 
that after a certain date, the owner of the content:


- Does not want the CDN, or a rogue employee of the CDN, to present the 
content as an authoritative source. If the user sees a big browser 
warning, that would *not* look authoritative.


- Does not want the CDN to be able to MITM the site for more sensitive 
traffic, such as POST messages that contain user passwords.


Short-term certs would handle this use case just fine.

And as a content owner, it's really nice to able to leave a CDN whenever 
I want to, without having to rely on it to keep my secrets for a few 
more years while we no longer have a business relationship.


Thanks,
Yaron

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

Re: [Acme] Short term certificates - two options

[Yaron Sheffer]

On 22/07/16 13:21, Chris Drake wrote:

Hi Yaron,

Best I can tell, everyone has jumped onto solving a cool problem,
without there actually being any reason to solve it?

I asked about the use case, and CDN authority revocation was all I got
(imho a really *weak* reason).  Maybe I got it wrong?

What *exactly* is a use case for short-term certificates? What about
HSTS/HPKP?
Why would *any* expired short-term certificate be useful?  Practically
no ordinary user cares about bad certs - heck - iPhone users don't even
have a way to check a cert even if they wanted to.

Kind Regards,
Chris Drake



Hi Chris,

Can you please explain why CDN authority revocation is a weak use case?

Let me share my preferred use case: I am running a large web property in 
the cloud, where TLS connections are terminated on a cloud-based load 
balancer (Amazon ELB, for a concrete example). I would like the cloud 
provider to present my identity (www.example.com), but I want to revoke 
this authority as soon as something bad happens, e.g. the cloud provider 
is breached.


There may be alternative solutions, but I think short-term certs are a 
reasonable solution here. Either the content owner gives the cloud 
provider a new cert every X days (option 1), or the cloud provider can 
get the short-term cert directly from the CA (option 2).


A solution that certainly CANNOT work is to give the cloud provider a 
regular 1-year cert and revoke it if a breach occurs. Because we know 
that cert revocation doesn't work.


Thanks,
Yaron

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

Re: [Acme] Attribute Certificates Re: Short term certificates - two options

[Yaron Sheffer]

On 22/07/16 12:56, Richard Barnes wrote:



On Fri, Jul 22, 2016 at 12:52 PM, Yaron Sheffer <yaronf.i...@gmail.com
<mailto:yaronf.i...@gmail.com>> wrote:

On 21/07/16 12:36, Sean Leonard wrote:


On Jul 20, 2016, at 2:51 AM, Yaron Sheffer
<yaronf.i...@gmail.com <mailto:yaronf.i...@gmail.com>> wrote:

Option 2: Certificate Delegation

This option moves more of the responsibility to the ACME server.

1. Domain owner contacts the ACME server and obtains a
"delegation
ticket" which is specific to the TLS server. The ticket is
good for a
long period, e.g. 1 year.

2. TLS server regularly contacts the ACME server, proves
ownership of
the delegation ticket, and receives a short-term certificate.

If something bad happens, the domain owner contacts the ACME
server and
revokes the delegation ticket.


I just wanted to check some intuition out here.

Would an [RFC5755] Attribute Certificate work effectively as a
“delegation ticket”, within the meaning of Option 2 that you’re
proposing?


[snip]


Regards,

Sean


Hi Sean,

Attribute certs would have been a wonderful fit here, but to the
best of my knowledge, they've never been (widely) implemented. They
have been a great idea with no practical use since 2002. And if we
propose to use them here, it's a sure way to kill this option outright.

More specifically, when you say "ACs can be revoked" this is
somewhat ironic. The generally accepted wisdom is that certificates
cannot be reliably revoked today, and in fact this is the main
reason why we need short-term certificates for the CDN use case!


Yeah, I sent the following to Sean yesterday and forgot to CC the list:

"""
I mean, technically yes, ACs would work here, in the sense that a tank
will get you to the office :)

I think the more likely candidate is OAuth, since (a) ACME is based on
HTTP, and (b) OAuth is built for delegating authorization.
"""

--Richard



Hi Richard,

It's kind of early for this level of detail, but don't you think a 
simple JWT (https://tools.ietf.org/html/rfc7519) signed by the ACME 
server is sufficient here?


Thanks,
Yaron

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

Re: [Acme] Attribute Certificates Re: Short term certificates - two options

[Yaron Sheffer]

On 21/07/16 12:36, Sean Leonard wrote:



On Jul 20, 2016, at 2:51 AM, Yaron Sheffer <yaronf.i...@gmail.com> wrote:

Option 2: Certificate Delegation

This option moves more of the responsibility to the ACME server.

1. Domain owner contacts the ACME server and obtains a "delegation
ticket" which is specific to the TLS server. The ticket is good for a
long period, e.g. 1 year.

2. TLS server regularly contacts the ACME server, proves ownership of
the delegation ticket, and receives a short-term certificate.

If something bad happens, the domain owner contacts the ACME server and
revokes the delegation ticket.


I just wanted to check some intuition out here.

Would an [RFC5755] Attribute Certificate work effectively as a “delegation 
ticket”, within the meaning of Option 2 that you’re proposing?

I know people want to hate on ACs, and they aren’t widely deployed. But maybe 
that would be the right kind of pre-existing protocol element for this sort of 
thing.

AC has a Holder field; presumably the holder field would identify the the TLS 
server, the main certificate, or both.

Proving ownership of the delegation ticket, is just transmitting the AC. 
Possession is sufficient.

ACs can be revoked, as they use the same machinery as regular certificates, via 
CRLs (and OCSP). Again, component reuse.

ACs are signed, so they are verifiable as coming from the ACME server. If you 
don’t like full public-key signatures you can generate a “signature” (with a 
new/appropriate OID) based on some shared secret.

ACs have dates. So that part is satisfied.

You can still hate on ACs and invent some different thing; you could also use 
SAML or whatever. Just checking the intuition, and thinking about reusing 
existing componentry. Where do ACs match up, and where do they break down?

Regards,

Sean



Hi Sean,

Attribute certs would have been a wonderful fit here, but to the best of 
my knowledge, they've never been (widely) implemented. They have been a 
great idea with no practical use since 2002. And if we propose to use 
them here, it's a sure way to kill this option outright.


More specifically, when you say "ACs can be revoked" this is somewhat 
ironic. The generally accepted wisdom is that certificates cannot be 
reliably revoked today, and in fact this is the main reason why we need 
short-term certificates for the CDN use case!


Thanks,
Yaron

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

Re: [Acme] Short term certificates - two options

[Yaron Sheffer]

On 21/07/16 12:03, Chris Drake wrote:

Hi Yaron,

The premise seems wrong:

These certificates allow the domain owner to terminate the TLS server's 
authorization when necessary,


What that is technically true, it does not facilitate the *purpose* of
the termination (which would be to prevent continued CDN content
distribution) - clients can simply ignore the "expired certificate"
problem and still get the content.

Trying to build a kludge to use certificates where session keys should
be used instead seems a bad-idea(tm) to me.

Kind Regards,
Chris Drake



Hi Chris,

I am not following your reasoning: the CDN can *always* distribute 
content under a fake or self-signed certificate, even if we have 
real-time termination of its session keys. After all, it (usually) has a 
full copy of the content!


Or are you saying that clients behave differently for expired vs. 
self-signed certs? I am not sure that this is the case.


Thanks,
Yaron

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

Re: [Acme] Short term certificates - two options

[Yaron Sheffer]

Hi Chris,

The LURK CDN use case is described here: 
https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-02#section-5.3


Personally I care more about the case of the TLS server being part of 
the cloud infrastructure (e.g. Amazon ELB or even an on-premise F5 box), 
and talking to enterprise-based servers that hold the long-term credentials.


Thanks,
Yaron

On 20/07/16 23:32, Chris Drake wrote:

Hi Yaron,

What is the use case for these?

Kind Regards,
Chris Drake


Wednesday, July 20, 2016, 7:51:57 PM, you wrote:

YS> Hi,

YS> At the LURK BoF this week there was some interest in having a solution
YS> where a domain owner can delegate to some other entity (which we will
YS> call "the TLS server") the authority to terminate TLS connections on its
YS> behalf, using short-term certificates. These certificates allow the
YS> domain owner to terminate the TLS server's authorization when necessary,
YS> without requiring certificate revocation - which we know doesn't work
YS> reliably. The certificates' validity is measured in days, e.g. 3 days.

YS> First, I would like to request the working group to adopt short-term
YS> certificates as a charter item.

YS> Second, I would like the group's advice in choosing between two very
YS> different approaches to this problem.


YS> Option 1: Certificate Pull

YS> This option is documented in the LURK draft [1], which will be modified
YS> to include feedback received this week, specifically to use more
YS> traditional certification request (CSR) flows. But the basic idea is
YS> very simple:

YS> 1. TLS server generates a CSR once every 3 days for www.example.com,
YS> sends it to the domain owner using an authenticated REST API.

YS> 2. Domain owner validates the CSR, forwards it to ACME server, gets back
YS> a short-term cert.

YS> 3. Domain owner returns the cert to the TLS server.

YS> If something bad happens, the domain owner simply stops forwarding
YS> requests from this particular TLS server.


YS> Option 2: Certificate Delegation

YS> This option moves more of the responsibility to the ACME server.

YS> 1. Domain owner contacts the ACME server and obtains a "delegation
YS> ticket" which is specific to the TLS server. The ticket is good for a
YS> long period, e.g. 1 year.

YS> 2. TLS server regularly contacts the ACME server, proves ownership of
YS> the delegation ticket, and receives a short-term certificate.

YS> If something bad happens, the domain owner contacts the ACME server and
YS> revokes the delegation ticket.


YS> Comparison:

YS> 1. Option 2 is clearly more complicated to specify and to implement.

YS> 2. Option 2 extends the ACME protocol. Many clients can ignore it, but
YS> servers will need to implement it.

YS> 3. Option 1 requires the domain owner to have a server available
YS> regularly, even if it is only a short REST interaction once every few
YS> days. Option 2 doesn't require any such server.

YS> 4. Option 1 looks to the ACME server as a normal cert request, and
YS> therefore will swamp the CT logs with lots of short-term certs. With
YS> Option 2, we can log to CT the issuance of the delegation ticket instead
YS> of the actual certificates.


YS> I would appreciate your input!

YS> Thanks,

YS>   Yaron


YS> [1] https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00






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

Re: [Acme] Short term certificates - two options

[Yaron Sheffer]

Hi Carl,
I agree to both your points in principle, but see Rich's mail.

Thanks,
Yaron

On 20/07/16 17:46, Carl Wallace wrote:


On 7/20/16, 11:32 AM, "Yaron Sheffer" <yaronf.i...@gmail.com> wrote:


Hi Carl,

I think this could work, but I believe there are use cases
(specifically, CDNs) where people do not want to advertise the delegation.


I favor solutions where the relying party can be aware of the delegation
if they want to be.



Besides, I am personally averse to tweaking X.509. IMO it could make
standardization much more difficult.


Maybe to the certificate issuance process, but for general use existing
clients should just work out of the box.



Thanks,
Yaron





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

Re: [Acme] Short term certificates - two options

[Yaron Sheffer]

Sounds interesting, thank you!

I suppose if we have the ACME "application objects" and they support 
renewal/reissuance, that would also apply to my Option 2, i.e. the TLS 
server accessing ACME directly. Of course Option 2 would still require 
an extension of the ACME protocol.


Thanks,
Yaron

On 20/07/16 17:43, Andrew Ayer wrote:

On Wed, 20 Jul 2016 11:51:57 +0200
Yaron Sheffer <yaronf.i...@gmail.com> wrote:


Second, I would like the group's advice in choosing between two very
different approaches to this problem.


I prefer option 1, but with a tweak.  I think the server should only be
required to generate and register a new CSR if the key changes.
Otherwise, the CA should automatically sign new certificates
periodically and they should be retrieved from the CA by the TLS server
using a simple unauthenticated GET operation.  (Since
these certs are static, the CA would ideally serve them via a
highly-available CDN environment, much like pre-generated OCSP
responses.) This would be possible if application objects supported
renewals, as I discuss here:
https://mailarchive.ietf.org/arch/msg/acme/NFgZShOcKH38QV1hh-fT3Dnp8bs
If the domain owner wants to revoke a delegation to terminate TLS, they
just have to contact the ACME server and disable the application.

This is a simpler architecture and much more reliable since you only
need to worry about authenticating and proxying CSRs during key
rotation, which presumably doesn't need to happen that often as long as
your TLS connections use forward secrecy.  The normal day-to-day
certificate refreshes wouldn't depend on the domain owner's
server being up, and would also be resilient to brief outages of the
CA's signing infrastructure.

As for swamping CT logs, that's probably a better question for the CT
mailing list.  I will say that the working group has been trying very
hard to minimize the complexity of TLS clients (see redaction).  Doing
things like logging delegations would necessarily complicate TLS
clients (since TLS clients would need to verify the delegations) so I
suspect the answer will be to just log the short-lived certs and focus
on making logs cope (e.g. log rotation so it's easy to rotate logs when
they get too big).

Regards,
Andrew



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

Re: [Acme] Short term certificates - two options

[Yaron Sheffer]

On 20/07/16 13:07, Tom Ritter wrote:

On 20 July 2016 at 04:51, Yaron Sheffer <yaronf.i...@gmail.com> wrote:

4. Option 1 looks to the ACME server as a normal cert request, and
therefore will swamp the CT logs with lots of short-term certs. With
Option 2, we can log to CT the issuance of the delegation ticket instead
of the actual certificates.


I think the CT community would strongly oppose this notion (I know I
would.)  As a domain owner, I want to know what certificates are
issued for me - that is the purpose of CT. Logging a delegation ticket
does not accomplish this. An attacker who compromises the delegation
ticket has free reign and I would never know.

Maybe there is a way to make this possible, similar to redacted
certificates, but since implementors of CT can't agree on a good way
to make redaction work functionally, it seems unlikely this would be
adopted by CT in the short order.

-tom



Hi Tom,

As far as I understand CT, it is mostly about protecting the rightful 
domain owner from other people issuing their certs for their domains, 
using other CAs. In this case, the delegation ticket is restricted to a 
single CA and so this cannot happen.


BTW, we could associate the delegation ticket with a private key on the 
TLS server which would make it harder to compromise the ticket.


Thanks,
Yaron

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

Re: [Acme] Short term certificates - two options

[Yaron Sheffer]

On 20/07/16 14:43, Niklas Keller wrote:

2016-07-20 11:51 GMT+02:00 Yaron Sheffer <yaronf.i...@gmail.com
<mailto:yaronf.i...@gmail.com>>:

Hi,

At the LURK BoF this week there was some interest in having a solution
where a domain owner can delegate to some other entity (which we will
call "the TLS server") the authority to terminate TLS connections on its
behalf, using short-term certificates. These certificates allow the
domain owner to terminate the TLS server's authorization when necessary,
without requiring certificate revocation - which we know doesn't work
reliably. The certificates' validity is measured in days, e.g. 3 days.

First, I would like to request the working group to adopt short-term
certificates as a charter item.

Second, I would like the group's advice in choosing between two very
different approaches to this problem.


You can already delegate HTTP-01 by redirecting
`/.well-known/acme-challenge/*` (maybe even just for unknown tokens).

Also, for short-lived certificates, there's already the `notAfter` field
when filing applications for a certificate:

https://ietf-wg-acme.github.io/acme/#rfc.section.6.1.3

Regards, Niklas


In fact delegating HTTP-01 is a big security issue in the context of 
rogue CDNs (or CDN employees). Please see 
https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00#section-4.3


Thanks,
Yaron

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

Re: [Acme] Short term certificates - two options

[Yaron Sheffer]

On 20/07/16 13:04, Carl Wallace wrote:



On 7/20/16, 5:51 AM, "Acme on behalf of Yaron Sheffer"
<acme-boun...@ietf.org on behalf of yaronf.i...@gmail.com> wrote:






Option 2 could take the form of a non-critical extension. The flow could
be something along these lines:

- TLS server generates a key pair and sends request for delegation ticket
to the domain owner
- The domain owner prepares an X.509 extension containing the key (or key
identifier), any constraints (e.g., name or validity) and the domain
owner's signature covering that information
- TLS server includes the extension in the request for a certificate
(short lived or otherwise but always consistent with constraints in the
extension)
- CA issues a certificate containing the non-critical extension
- TLS clients that want to understand the delegation can verify the
extension, others would carry on without processing the non-critical
extension

If this were always a long-lived certificate, the pre-certificate
mechanism in CT could be adapted with the domain owner signing instead of
the log (or maybe using CT exactly and acting as a special case log), but
this would complicate issuance.





Hi Carl,

I think this could work, but I believe there are use cases 
(specifically, CDNs) where people do not want to advertise the delegation.


Besides, I am personally averse to tweaking X.509. IMO it could make 
standardization much more difficult.


Thanks,
Yaron

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

[Acme] Short term certificates - two options

[Yaron Sheffer]

Hi,

At the LURK BoF this week there was some interest in having a solution
where a domain owner can delegate to some other entity (which we will
call "the TLS server") the authority to terminate TLS connections on its
behalf, using short-term certificates. These certificates allow the
domain owner to terminate the TLS server's authorization when necessary,
without requiring certificate revocation - which we know doesn't work
reliably. The certificates' validity is measured in days, e.g. 3 days.

First, I would like to request the working group to adopt short-term
certificates as a charter item.

Second, I would like the group's advice in choosing between two very
different approaches to this problem.


Option 1: Certificate Pull

This option is documented in the LURK draft [1], which will be modified
to include feedback received this week, specifically to use more
traditional certification request (CSR) flows. But the basic idea is
very simple:

1. TLS server generates a CSR once every 3 days for www.example.com,
sends it to the domain owner using an authenticated REST API.

2. Domain owner validates the CSR, forwards it to ACME server, gets back
a short-term cert.

3. Domain owner returns the cert to the TLS server.

If something bad happens, the domain owner simply stops forwarding
requests from this particular TLS server.


Option 2: Certificate Delegation

This option moves more of the responsibility to the ACME server.

1. Domain owner contacts the ACME server and obtains a "delegation
ticket" which is specific to the TLS server. The ticket is good for a
long period, e.g. 1 year.

2. TLS server regularly contacts the ACME server, proves ownership of
the delegation ticket, and receives a short-term certificate.

If something bad happens, the domain owner contacts the ACME server and
revokes the delegation ticket.


Comparison:

1. Option 2 is clearly more complicated to specify and to implement.

2. Option 2 extends the ACME protocol. Many clients can ignore it, but
servers will need to implement it.

3. Option 1 requires the domain owner to have a server available
regularly, even if it is only a short REST interaction once every few
days. Option 2 doesn't require any such server.

4. Option 1 looks to the ACME server as a normal cert request, and
therefore will swamp the CT logs with lots of short-term certs. With
Option 2, we can log to CT the issuance of the delegation ticket instead
of the actual certificates.


I would appreciate your input!

Thanks,

 Yaron


[1] https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00

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

[Acme] ACME and CDNs

[Yaron Sheffer]

  
  
In the context of the LURK BoF, I've been thinking about using (an
extension of) ACME to issue short-term certificates to a CDN, so
that the CDN would not need a copy of the origin server's long-term
private key. I believe that this is reasonably easy to do, but what
I don't understand - and I think the current ACME draft does not
cover well - are the security implications of CDNs in general.

Suppose I have a single server, www.example.com, that's getting
a huge amount of traffic and so I'd like to move it to a CDN. What
can I do to prevent the CDN from obtaining an unauthorized (by me)
ACME certificates for this server? Several solutions come to mind:

1. I could use a CAA record to limit issuance of certs for this
server to a particular CA and hope that it will not issue "similar"
certs to multiple accounts. But an ACME CA is not required to limit 
issuance/renewal of certs for a particular name to one particular
account key. And in fact adding such a restriction would mean that
if the account key is lost, the legitimate organization would not be
able to renew the cert.

2. I could rely on certificate transparency (CT) to tell me if a
duplicate cert is ever created. ACME does not require CAs to deploy
CT. So presumably there will be ACME CAs that don't have it and the
attacker will use one of them.

3. A combination of (1) and (2) should sort-of work: use CAA to
stick to a single CA that also deploys CT. The solution is far from
ideal because it only detects but does not prevent bogus certs, and
we know how hard it is to revoke missued certs. Also, ACME does not
mandate CAA support either! On top of that, detection would not be
trivial because certs are being renewed regularly (once every 90
days, say) so one can easily miss the one bogus renewal.

Other ideas?

Thanks,
    Yaron
  


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

Re: [Acme] Supporting off-line (manual) validation

[Yaron Sheffer]

Many clients will want to fail if the CA decides to go offline. I 
think logic that keeps state on the CA is too complex. Better to allow 
the client to say if offline validation is needed, please fail the 
whole transaction.


Thanks,
Yaron

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

[Acme] Revocation: why not cert serial number?

[Yaron Sheffer]

(Resending, sorry about the HTML mail)

The title says it all. People have been using serial numbers for ages to 
identify the cert (and yes, we all know the problems with revocation). 
Why not keep it like that?


Thanks,
Yaron

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

[Acme] Revocation: why not cert serial number?

[Yaron Sheffer]

  
  
The title says it all. People have been using serial numbers for
ages to identify the cert (and yes, we all know the problems with
revocation). Why not keep it like that?

Thanks,
    Yaron
  


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