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

[Eric Rescorla]

On Thu, Jan 24, 2019 at 11:50 AM Roland Shoemaker 
wrote:

> Comments inline:
>
> > On Dec 24, 2018, at 12:32 PM, Eric Rescorla  wrote:
> >
> > Rich version of this review at:
> > https://mozphab-ietf.devsvcdev.mozaws.net/D4180
> >
> >
> > IMPORTANT
> > S 3.
> > >  used to refer to fully qualified domain names.  If a ACME server
> > >  wishes to request proof that a user controls a IPv4 or IPv6
> address
> > >  it MUST create an authorization with the identifier type "ip".
> The
> > >  value field of the identifier MUST contain the textual form of the
> > >  address as defined in [RFC1123] Section 2.1 for IPv4 and in
> [RFC4291]
> > >  Section 2.2 for IPv6.
> >
> > Are all three variants here valid?
>
> I think requiring the canonical representation defined in 5952 Section 4
> to be supported makes sense, but would be in favor of also allowing
> supporting any of the other 4291 representations if the implementer wishes.
>
> >
> >
> > S 4.
> > >  For the "tls-alpn-01" the subjectAltName extension in the
> validation
> > >  certificate MUST contain a single iPAddress which matches the
> address
> > >  being validated.  As [RFC6066] does not permit IP addresses to be
> > >  used in the SNI extension the server MUST instead use the IN-
> > >  ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse mapping of the
> IP
> > >  address as the SNI value instead of the literal IP address.
> >
> > What happens if an attacker forces an incorrect SNI on you here? I
> > don't see any security analysis below, but I suspect it's bad,
> >
>
> I’m not sure I understand how an attacker would force an incorrect SNI?
> tls-alpn-01 requires that the server verify that the SNI that it is
> provided matches what it expects.
>

I'm talking about an attacker who controls the reverse tree, and thus can
cause the server to use an SNI of his choice.


> COMMENTS
> > S 6.
> > >
> > >   6.  Security Considerations
> > >
> > >  Given the often short delegation periods for IP addresses
> provided by
> > >  various service providers CAs MAY want to impose shorter lifetimes
> > >  for certificates which contain IP identifiers.  They MAY also
> impose
> >
> > https://tools.ietf.org/rfcmarkup?doc=6919#section-6
> >
> > If the WG thinks that providers ought to do this, then it should say
> > so.
> >
>
> I don’t think it makes sense for the document to mandate this as it’s not
> an implementation detail but a policy one which the relevant policy
> authorities (such as CABF) may dictate themselves in the future putting
> this document at odds with those requirements.


I don't agree. It's the IETF's job to provide a complete and clear spec.
The text implies that we think that you ought to use a shorter lifetime and
then the MAY totally undercuts that. This text either should be removed or
you should use a SHOULD or MUST. See also
https://tools.ietf.org/rfcmarkup?doc=6919#section-6

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

Re: [Acme] AD Review: draft-ietf-acme-caa-05

[Eric Rescorla]

This works for me.

-Ekr


On Thu, Jan 3, 2019 at 11:33 AM Salz, Rich  wrote:

> @ekr, is this okay with you?
>
> On 12/28/18, 10:30 PM, "Hugo Landau"  wrote:
>
> On Sat, Dec 29, 2018 at 03:23:35AM +, Salz, Rich wrote:
> >
> > +   Validation methods beginning with the prefix "ca-" are
> reserved for CA-local
> > +   meaning and may not be registered.
> >
> > "need not be" ?  Or "SHOULD NOT be" ?
> My intention was that the rules of the registry state that such names
> MUST NOT be registered. I didn't use a capitalised keyword here for
> consistency with the prose already in that section.
>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-tls-alpn-05

[Eric Rescorla]

On Wed, Dec 26, 2018 at 6:56 AM Ilari Liusvaara 
wrote:

> On Mon, Dec 24, 2018 at 12:47:30PM -0800, Eric Rescorla wrote:
> >
> > S 4.
> > >  properly segregates control of those names to the users that own
> > >  them.  This means that if User A registers Host A and User B
> > >  registers Host B the server should not allow a TLS request using a
> > >  SNI value for Host A to be served by User B or Host B to be
> served by
> > >  User A.  If the server allows User B to serve this request it
> allows
> > >  them to illegitimately validate control of Host A to the ACME
> server.
> >
> > Isn't this the property you say doesn't hold in S 6 below. As I
> > understand it, the rationale for this design is that people who opt in
> > to acme-tls/1 won't do this, no?
>
> No. This is a different property than one mentioned in S6. This is due
> to different SNI used.
>

That appears to be what S 6 says as well:

   domain names they controlled (i.e. if User A registered Host A and
   User B registered Host B with a service provider that User A wouldn't
   be able to respond to SNI traffic for Host B).  This turns out not to

So at minimum some improved text is required here.

-Ekr

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

[Acme] AD Review: draft-ietf-acme-tls-alpn-05

[Eric Rescorla]

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5386


IMPORTANT
S 3.
>  the handshake MUST contain a ALPN extension with the single
>  protocol name "acme-tls/1" and a Server Name Indication [RFC6066]
>  extension containing the domain name being validated.
>
>  4.  Verify that the ServerHello contains a ALPN extension containing
>  the value "acme-tls/1" and that the certificate returned contains

This will not work with TLS 1.3, where ALPN is in EE.


S 4.
>  properly segregates control of those names to the users that own
>  them.  This means that if User A registers Host A and User B
>  registers Host B the server should not allow a TLS request using a
>  SNI value for Host A to be served by User B or Host B to be served by
>  User A.  If the server allows User B to serve this request it allows
>  them to illegitimately validate control of Host A to the ACME server.

Isn't this the property you say doesn't hold in S 6 below. As I
understand it, the rationale for this design is that people who opt in
to acme-tls/1 won't do this, no?


COMMENTS
S 3.
>  that it is returned during a TLS handshake that contains a ALPN
>  extension containing the value "acme-tls/1" and a SNI extension
>  containing the domain name being validated.
>
>  A client responds with an empty object ({}) to acknowledge that the
>  challenge is ready to be validated by the server.  The base64url

This isn't really a response. It posts a message.


S 4.
>  blindly agreeing to use the "acme-tls/1" protocol without actually
>  understanding it.
>
>  To further mitigate the risk of users claiming domain names used by
>  other users on the same infrastructure hosting providers, CDNs, and
>  other service providers should not allow users to provide their own

Should this be a 2119/8174 SHOULD NOT?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] AD Review: draft-ietf-acme-ip-04

[Eric Rescorla]

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4180


IMPORTANT
S 3.
>  used to refer to fully qualified domain names.  If a ACME server
>  wishes to request proof that a user controls a IPv4 or IPv6 address
>  it MUST create an authorization with the identifier type "ip".  The
>  value field of the identifier MUST contain the textual form of the
>  address as defined in [RFC1123] Section 2.1 for IPv4 and in [RFC4291]
>  Section 2.2 for IPv6.

Are all three variants here valid?


S 4.
>  For the "tls-alpn-01" the subjectAltName extension in the validation
>  certificate MUST contain a single iPAddress which matches the address
>  being validated.  As [RFC6066] does not permit IP addresses to be
>  used in the SNI extension the server MUST instead use the IN-
>  ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse mapping of the IP
>  address as the SNI value instead of the literal IP address.

What happens if an attacker forces an incorrect SNI on you here? I
don't see any security analysis below, but I suspect it's bad,


COMMENTS
S 6.
>
>   6.  Security Considerations
>
>  Given the often short delegation periods for IP addresses provided by
>  various service providers CAs MAY want to impose shorter lifetimes
>  for certificates which contain IP identifiers.  They MAY also impose

https://tools.ietf.org/rfcmarkup?doc=6919#section-6

If the WG thinks that providers ought to do this, then it should say
so.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Eric Rescorla]

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4723


After reviewing this document, I'd like to reconsider the proposed
status of this document. Based on Section 5, it doesn't appear that
there are any production implementations of this document. Are there
any existing or planned production implementations from live CAs or
clients?  If not, this seems like a better fit for Experimental.


IMPORTANT
S 3.4.
> present and set to true, the client requests the server to allow
> unauthenticated GET to the star-certificate associated with this
> Order.
>
>  If the server accepts the request, it MUST reflect the key in the
>  Order.

it seems like some security considerations are needed here to prevent
enumeration.


S 4.1.
>  of clock-related breakage reports which account for clients that are
>  more than 24 hours behind - happen to be within 6-7 days.
>
>  In order to avoid these spurious warnings about a not (yet) valid
>  server certificate, it is RECOMMENDED that site owners pre-date their
>  Web facing certificates by 5 to 7 days.  The exact number depends on

I don't understand how this works. The client is able to provide the
notbefore date, which gives a pre-date for the first certificate, but
S 2.2 just says that the re-issue is "before the previous one
expires". So suppose it is currently 2018-07-15" and I ask for a
certificate with "recurrent-start-date=2018-07-10" and "recurrent-
certificate-validity=5", I thus get back a cert with validity
"2018-07-10 -- 2018-07-20", i.e., pre-dated by 5 days. The next
certificate needs to be issued on or before "2018-07-20", but the text
doesn't say when it's notbefore has to be, so it could have validity
"2018-07-19 -- 2018-07-25". It seems like this document needs to
specify an explicit way to pre-date, but it doesn't.


COMMENTS
S 1.
>  new short-term certificate is needed - e.g., every 2-3 days.  If done
>  this way, the process would involve frequent interactions between the
>  registration function of the ACME Certification Authority (CA) and
>  the identity provider infrastructure (e.g.: DNS, web servers),
>  therefore making the issuance of short-term certificates exceedingly
>  dependent on the reliability of both.

I don't see why this is the case. Once you have authorized once, the
CA can just return that no authorizations are required.


S 3.1.1.
>  o  recurrent-certificate-validity (required, integer): the maximum
> validity period of each STAR certificate, an integer that denotes
> a number of seconds.  This is a nominal value which does not
> include any extra validity time which is due to pre-dating.  The
> client can use this value as a hint to configure its polling
> timer.

This text is confusing. The client produces the order, so how is it
using it as a hint.


S 3.1.2.
>
>  Issuing a cancellation for an order that is not in "valid" state has
>  undefined semantics.  A client MUST NOT send such a request, and a
>  server MUST return an error response with status code 400 (Bad
>  Request) and type
>  "urn:ietf:params:acme:error:recurrentCancellationInvalid".

This doesn't sound like undefined semantics. It's just illegal.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-caa-05

[Eric Rescorla]

This SGTM. ACME editors?

-Ekr


On Sat, Dec 22, 2018 at 8:28 AM Hugo Landau  wrote:

> > I'm open to alternative methods of preventing conflicts. A prefix could
> > > be reserved for CA-specific use, e.g. "nonacme-".
> > >
> >
> > That would be fine.
>
> Amended to:
>
>   Where a CA supports both the "validationmethods" parameter and one or
>   more non-ACME challenge methods, it MUST assign identifiers to those
>   methods. If appropriate non-ACME identifiers are not present in the
>   ACME Validation Methods IANA registry, the CA MUST use identifiers
>   beginning with the string "nonacme-". Such identifiers have
>   CA-specific meaning.
>
> Attention should be drawn to the following text in the ACME I-D:
>
>   When evaluating a request for an assignment in this registry, the
> designated
>   expert should ensure that the method being registered has a clear,
>   interoperable definition and does not overlap with existing validation
> methods.
>   That is, it should not be possible for a client and server to follow the
>   same set of actions to fulfill two different validation methods.
>
>   Validation methods do not have to be compatible with ACME in order to be
>   registered.  For example, a CA might wish to register a validation
> method in
>   order to support its use with the ACME extensions to CAA
>   {{?I-D.ietf-acme-caa}}.
>
> Since this is a prefix and not an entry per se, it seems like the
> cleanest way to accommodate this is to amend the ACME I-D, rather than
> use of "IANA Considerations" section, which is currently nil. The ACME
> I-D is already referencing ACME-CAA above. But I'm open to suggestions.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-caa-05

[Eric Rescorla]

On Mon, Dec 3, 2018 at 6:26 PM Hugo Landau  wrote:

> On Sun, Nov 04, 2018 at 07:18:05PM -0800, Eric Rescorla wrote:
> > IMPORTANT
> > S 4.
> > >  Where a CA supports both the "validationmethods" 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").
> >
> > This doesn't seem sufficient to prevent conflicts. You need to either
> > (a) ensure they don't conflict or (b) remove this feature.
> Since the ACME WG appears to have adopted the policy of always assigning
> validation method names according to this scheme, this is effective to
> prevent conflicts.


Traditional practices do not a policy make.


Removing this paragraph is a bad idea because CAs are
> then likely to invent their own ad-hoc solutions if not given guidance
> on non-ACME use cases.
>

What I meant by remove the feature was to prohibit defining non-registered
values.


I'm open to alternative methods of preventing conflicts. A prefix could
> be reserved for CA-specific use, e.g. "nonacme-".
>

That would be fine.


> S 5.4.
> > >  CAA record validation.
> > >
> > >  It is RECOMMENDED that CAs satisfy this requirement by using URIs
> > >  which include an authority:
> > >
> > >  "https://a.example.com/account/1234";
> >
> > What is the reason for ever not including URIs with an authority? This
> > just seems like a recipe for fail.
> In other words, you'd prefer this to be changed to a MUST? Alright.
>

Yes.


> S 5.6.
> > >  1.  Use the "accounturi" parameter to ensure that only accounts
> which
> > >  it controls are authorized to obtain certificates, or
> > >
> > >  2.  Exclusively use validation methods which rely solely on
> > >  information obtained via DNSSEC, and use the
> "validationmethods"
> > >  parameter to ensure that only such methods are used.
> >
> > I don't think this is right unless *also* all CAs do DNSSEC
> > validation, because one CA might not do DNSSEC and *then* the CAA
> > record could be attacked.
> This is supposed to be covered by section "Limited to CAs Processing CAA
> Records" but could be clearer. I'll revise the wording.
>

Thanks.

-ekr


>
>
>
>
>
>
>
> > COMMENTS
> >
> > >   Abstract
> > >
> > >  The CAA DNS record allows a domain to communicate issuance policy
> to
> > >  CAs, but only allows a domain to define policy with CA-level
> > >  granularity.  However, the CAA specification also provides
> facilities
> > >  for extension to admit more granular, CA-specific policy.  This
> > extensions.
> In this context the word is being used as a verb, not a noun.
>
> >
> >
> > S 3.
> > >
> > >  The presence of this parameter constrains the property to which
> it is
> > >  attached.  Where a CAA property has an "accounturi" parameter, a
> CA
> > >  MUST NOT consider that property to authorize issuance in the
> context
> > >  of a given certificate issuance request unless the CA recognises
> the
> > >  URI specified as identifying the account making that request.
> >
> > This is very awkward writing. Can you rephrase in a positive way.
> > I.e.,
> > "The CA MUST only issue if..."
> OK
>
> >
> > S 3.
> > >  MUST NOT consider that property to authorize issuance in the
> context
> > >  of a given certificate issuance request unless the CA recognises
> the
> > >  URI specified as identifying the account making that request.
> > >
> > >  If a certificate issuance request is made to a CA such that no
> > >  account URI is available, because the request is made in the
> absence
> >
> > IMPORTANT What does "available" mean in this context.
> This is explained by the end of the sentence.
>
> >
> >
> > S 3.
> > >  account URI is available, because the request is made in the
> absence
> > >  of any account or the account has no URI assigned to it, a CA MUST
> > >  NOT consider any property having an

[Acme] AD Review: draft-ietf-acme-caa-05

[Eric Rescorla]

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4464


IMPORTANT
S 4.
>  Where a CA supports both the "validationmethods" 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").

This doesn't seem sufficient to prevent conflicts. You need to either
(a) ensure they don't conflict or (b) remove this feature.


S 5.4.
>  CAA record validation.
>
>  It is RECOMMENDED that CAs satisfy this requirement by using URIs
>  which include an authority:
>
>  "https://a.example.com/account/1234";

What is the reason for ever not including URIs with an authority? This
just seems like a recipe for fail.


S 5.6.
>  1.  Use the "accounturi" parameter to ensure that only accounts which
>  it controls are authorized to obtain certificates, or
>
>  2.  Exclusively use validation methods which rely solely on
>  information obtained via DNSSEC, and use the "validationmethods"
>  parameter to ensure that only such methods are used.

I don't think this is right unless *also* all CAs do DNSSEC
validation, because one CA might not do DNSSEC and *then* the CAA
record could be attacked.


S 5.7.
>  parameter to ensure that only such methods are used.
>
>   5.7.  Use without DNSSEC
>
>  Where a domain does not secure its nameservers using DNSSEC, or one
>  or more of the CAs it authorizes do not perform CAA validation

As above, it's not the CAs it authorizes, because only the CAA record
restricts that.
COMMENTS

>   Abstract
>
>  The CAA DNS record allows a domain to communicate issuance policy to
>  CAs, but only allows a domain to define policy with CA-level
>  granularity.  However, the CAA specification also provides facilities
>  for extension to admit more granular, CA-specific policy.  This

extensions.


S 3.
>
>  The presence of this parameter constrains the property to which it is
>  attached.  Where a CAA property has an "accounturi" parameter, a CA
>  MUST NOT consider that property to authorize issuance in the context
>  of a given certificate issuance request unless the CA recognises the
>  URI specified as identifying the account making that request.

This is very awkward writing. Can you rephrase in a positive way.
I.e.,
"The CA MUST only issue if..."


S 3.
>  MUST NOT consider that property to authorize issuance in the context
>  of a given certificate issuance request unless the CA recognises the
>  URI specified as identifying the account making that request.
>
>  If a certificate issuance request is made to a CA such that no
>  account URI is available, because the request is made in the absence

IMPORTANT What does "available" mean in this context.


S 3.
>
>  If a certificate issuance request is made to a CA such that no
>  account URI is available, because the request is made in the absence
>  of any account or the account has no URI assigned to it, a CA MUST
>  NOT consider any property having an "accounturi" parameter as
>  authorizing issuance.

Again, rephrase postiively


S 3.
>  account URI is available, because the request is made in the absence
>  of any account or the account has no URI assigned to it, a CA MUST
>  NOT consider any property having an "accounturi" parameter as
>  authorizing issuance.
>
>  If a CA finds multiple CAA records pertaining to it (i.e., having

pertaining to what? the CA?


S 3.
>  If a CA finds multiple CAA records pertaining to it (i.e., having
>  property "issue" or "issuewild" as applicable and a domain that the
>  CA recognises as its own) with different "accounturi" parameters, the
>  CA MUST NOT consider the CAA record set to authorize issuance unless
>  at least one of the specified account URIs identifies the account of
>  the CA by which issuance is requested.  A property without an

The account of the CA? CAs don't have accounts.

Does this say anything other than "at least one of the records must
match according to the conditions above"




S 3.
>  CA MUST NOT consider the CAA record set to authorize issuance unless
>  at least one of the specified account URIs identifies the account of
>  the CA by which issuance is requested.  A property without an
>  "accounturi" parameter matches any account.  A property with an
>  invalid or unrecognised "accounturi" parameter is unsatisfiable.  A
>  property with multiple "accounturi" parameters is unsatisfiable.

So you have to ignore it?


S 3.
>
>  The presence of an "accounturi" parameter does not replace or
>  supercede the need to validate the domain name specified in an
>   

Re: [Acme] Please consider adding server authentication

[Eric Rescorla]

We seem to still be talking past each other, so I'm going to try one more
time and then probably give up.


On Wed, Oct 24, 2018 at 3:50 PM Kas  wrote:

> On 10/25/2018 12:49 AM, Eric Rescorla wrote:
>
> I would say three things about this:
>
> 1. This has nothing to do with ACME, which is entirely about the
> interaction between the cert-holder and the CA. Speaking as AD (the rest of
> this message is as an individual)  I can tell you that anything having to
> do with populating the client key store would be out of scope for ACME.
>
> Sure it is out of scope
>

What out of scope means here is: the ACME WG should not be working on this.
If you want to work on it, you will need a recharter or to start some other
wG.


but supplying the chain as CA and root certificate doesn't conflict and
> will only secure the protocol, it is as i said you know better but adding
> the ability to obtain such small store from acme server is not bad practice.
>

I honestly don't understand how you think this is going to work. In this
scenario, the clients have no interaction with the ACME server at all. They
may not even be on a network connected to it.

>
> 2. I actually don't agree that it would be better to have the client trust
> anchor store updated via DNS, at least for one of the large well-managed
> clients (e.g., Firefox, Chrome, etc.)  Because of the nature of the WebPKI,
> the question of whether a trust anchor is one that the client should trust
> is to a great extent a policy question. and the clients (or the operating
> systems that they are hosted on) operate root programs which evaluate those
> policy issues  (for instance, determining whether a given CA should be
> distrusted). So, the relevant question is how that information gets
> communicated to the user's machine. There's no particular reason why the
> DNS is a good choice for that.
>
> DNS is running on different servers and will add extra layer of security,
> even letsencrypt as fully trusted ACME service provider by every store, if
> wanted to impersonate example.com and act as acme server running on
> example.com will fail unless it can control DNS records of that domain.
>

It would really help if you were able to explain what your concern is. It's
certainly true that an WebPKI-capable CA can (modulo CT, pinning, etc.)
impersonate another WebPKI CA to an ACME client, but this doesn't seem like
a very interesting threat given that said CA can impersonate *any* site to
*any* client, which is a much more serious type of attack in general. The
IETF has already standardized a set of techniques (including ones based on
DNS) for preventing this type of attack, and ACME clients are free to use
those. But there's nothing required in ACME for that.


> 3. In the particular case of enterprise trust anchors (as opposed to
> preconfigured ones) there are already mechanisms for remotely managing
> machines, and so again. DNS is not a particularly good mechanism for this.
>
> DNS can be used to deliver a pair of encoded data one url and a hash to a
> certificate to establish secure connection and obtain the chain of acme
> server, or the store from acme server contain all the root and CA
> certificates being used by that ACME server, on other hand if only one RFC
> or protocol has defined such request or protocol, then there will be a
> chance to configure Windows to use the store provided by Mozilla.
>

I don't understand what you think this would accomplish. As I said, there
are two cases:

- In the case of system-installed trust anchors, there is already an
existing way to configure them, and the vendors don't want to outsource
that to DNS
- In the case of user-installed (or typically systems-manager installed)
trust anchors, there are also existing ways to configure them via
enterprise policy, and DNS wouldn't be a good choice there either.

Note that neither of these cases involves any kind of connection to the
ACME server.


> I think you got my suggestion and i don't think there will be such a
> chance to standardize such protocols/functionality in near future if ACME
> passed on it, i mean something the online certificate revocation process,
> it is ready to be used.
> And i am not saying it should be DNS, i think you can figure well suited
> approach to enhance this protocol.
>

I'm sorry, I am totally unable to determine what use cases you think you
are trying to solve, and therefore I don't see how to design a protocol to
address them. Again, it would really help if you would describe a concrete
attack. Failing that, I don't think this is a productive interaction.

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

Re: [Acme] Please consider adding server authentication

[Eric Rescorla]

On Wed, Oct 24, 2018 at 2:36 PM Kas  wrote:

>
> On 10/24/2018 11:33 PM, Eric Rescorla wrote:
>
> I don't understand what this means. The client doesn't take its root
>> certificates
>> from the ACME server. In fact, in the most common use cases for ACME,
>> issuance of WebPKI server certs, the server doesn't need to know
>> anything about trust anchors at all (the ACME *client* does, but
>> those are preinstalled and don't need to interact with the ACME server
>> other than doing ordinary WebPKI validation).
>>
>> Client doesn't take its root certificates from ACME server that is true,
>> but when a client utilize ACME protocol to get a certificate from ACME
>> server, this implies that this server is already CA trusted in the eyes of
>> the client, and in both cases if the CA cert used by acme server to issue
>> the certificate leads or not to a trusted root certificate on client side,
>> the client want that certificate and want the full chain and has the power
>> trust it or not,
>>
>
> This is pretty hard to follow but If I'm understanding you correctly, then
> I don't think this is correct. There's just no connection at all between
> the trust anchors in the ACME client and the trust anchor associated with
> the CA part of the ACME server.
>
> Consider the case where I am operating an Enterprise CA for my own
> servers. This CA has a self-signed certificate X that needs to be installed
> in every Web client in my network. The CA itself runs ACME and has a
> certificate that's signed by a WebPKI valid anchor T. The ACME client
> component of my Web server connects to my own ACME server and has trust
> anchor T installed, and is therefore able to validate the ACME server's
> identity at the TLS level. However, because it does not have trust anchor X
> installed, the ACME server cannot issue a certificate which would be
> acceptable to the ACME client [0]. Contrariwise, my Web clients have trust
> anchor X (and likely T) installed, and so will accept certificates from
> both the ordinary WebPKI and from my Enterprise CA.
>
> You seem to have some concern about this, but I can't really figure out
> what it is. Given that a number of people have engaged with you and seem to
> also be confused, I would suggest that the problem is that you aren't being
> clear. I would suggest you draw a diagram of the various states, including
> the initial state, the state you would consider secure, and the state you
> are concerned about.
>
> -Ekr
>
> [0] Note that the ACME client might have a copy of X in order to validate
> the cert chain provided by the ACME server as a means of sanity checking
> but this has nothing to do with the TLS portion.
>
>
> You said "trust anchors in the ACME client and the trust anchor associated
> with the CA part of the ACME server" and in your example "This CA has a
> self-signed certificate X that needs to be installed in every Web client in
> my network."
> there is connection and there will always connection between those,
>

Yes, there is a connection between the Web clients (e.g., browsers) and the
trust anchor in the enterprise CA, but it has nothing to do with ACME.
Generally, the way this works is that when you set up the enterprise CA,
you'd generate the trust anchor which you put into whatever system you use
to manage those clients. But ACME isn't involved at all, because the web
servers that talk to the CA are also not involved.


> There is no need for example as your example will do :
> My point is about "installed" from your example as word and as process,
> ACME is Automatic Certificate Management Environment and thus if this
> "installed" can be automated then it better be, and it can be supplied
> online without preinstalled certificates, all your clients can only need
> the DNS root key and utilize DNSSEC to obtain your X, please correct me if
> i am wrong, on top of that there is RFC 5011 "Automated Updates of DNS
> Security (DNSSEC) Trust Anchors" can update that key in secure way, and you
> can revoke your CA certificate and issue another one to ACME server and all
> your client will be updated automatically, so in my opinion using DNSSEC is
> way more secure than depending on client store.
>

I would say three things about this:

1. This has nothing to do with ACME, which is entirely about the
interaction between the cert-holder and the CA. Speaking as AD (the rest of
this message is as an individual)  I can tell you that anything having to
do with populating the client key store would be out of scope for ACME.
2. I actually don't agree that it would be better to have the client trust
anchor sto

Re: [Acme] Please consider adding server authentication

[Eric Rescorla]

On Wed, Oct 24, 2018 at 1:21 PM Kas  wrote:

>
> On Wed, Oct 24, 2018 at 12:04 PM Kas 
> wrote:
>
> I don't think I agree with this claim. The client's expectations about the
> intended
> server are set by its domain name and it verifies that it is talking to
> the server in
> question via the WebPKI.
>
> Acme protocol doesn't mention anything about verifying domain name, if you
> mean when on TLS connection layer then my replay to Ilari applies here.
>

I don't understand that response. You seem to be assuming that the WebPKI
isn't secure, but htat's not the operational assumption here.


I don't understand what this means. The client doesn't take its root
> certificates
> from the ACME server. In fact, in the most common use cases for ACME,
> issuance of WebPKI server certs, the server doesn't need to know
> anything about trust anchors at all (the ACME *client* does, but
> those are preinstalled and don't need to interact with the ACME server
> other than doing ordinary WebPKI validation).
>
> Client doesn't take its root certificates from ACME server that is true,
> but when a client utilize ACME protocol to get a certificate from ACME
> server, this implies that this server is already CA trusted in the eyes of
> the client, and in both cases if the CA cert used by acme server to issue
> the certificate leads or not to a trusted root certificate on client side,
> the client want that certificate and want the full chain and has the power
> trust it or not,
>

This is pretty hard to follow but If I'm understanding you correctly, then
I don't think this is correct. There's just no connection at all between
the trust anchors in the ACME client and the trust anchor associated with
the CA part of the ACME server.

Consider the case where I am operating an Enterprise CA for my own servers.
This CA has a self-signed certificate X that needs to be installed in every
Web client in my network. The CA itself runs ACME and has a certificate
that's signed by a WebPKI valid anchor T. The ACME client component of my
Web server connects to my own ACME server and has trust anchor T installed,
and is therefore able to validate the ACME server's identity at the TLS
level. However, because it does not have trust anchor X installed, the ACME
server cannot issue a certificate which would be acceptable to the ACME
client [0]. Contrariwise, my Web clients have trust anchor X (and likely T)
installed, and so will accept certificates from both the ordinary WebPKI
and from my Enterprise CA.

You seem to have some concern about this, but I can't really figure out
what it is. Given that a number of people have engaged with you and seem to
also be confused, I would suggest that the problem is that you aren't being
clear. I would suggest you draw a diagram of the various states, including
the initial state, the state you would consider secure, and the state you
are concerned about.

-Ekr

[0] Note that the ACME client might have a copy of X in order to validate
the cert chain provided by the ACME server as a means of sanity checking
but this has nothing to do with the TLS portion.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Eric Rescorla]

On Wed, Oct 24, 2018 at 12:04 PM Kas 
wrote:

>
>
> On 10/24/2018 8:44 PM, Albert ARIBAUD wrote:
> > Hi,
> >
> > Le Wed, 24 Oct 2018 19:15:49 +0300
> > Kas  a écrit:
> >
> >> Wrong and you should not look at a certificate as a public key,
> >> please educate yourself with deeper understanding what do extensions
> >> serve and what critical extension means, i have a Code Signing
> >> certificate can i use it for IIS ? it has a public key ! and it been
> >> vouched by Comodo , do you understand what is CRL Distribution
> >> Points(2.5.29.31) and how that certificate should be checked before
> >> considered trusted ?
> > As an observer to this discussion, I would like to point out that
> > asking your interlocutor(s) what they know or do not know is rarely
> > productive, as people are usually poor judges on how well they know
> > some topic. Plus, even if the answer is accurate enough, it does not
> > help the discussion progress to a fruitful conclusion -- all the more
> > when the questions are asked in bursts.
> >
> > I would kindly advise you to just assume that others in the discussion
> > know enough of the topic to understand a detailed technical argument,
> > and to just lay out in such detail the concrete attack scenario(s) which
> > you are envisioning and concrete proposal(s) for mitigation or
> > protection.
> >
> > People on this list who do know the topic well enough will ask
> > meaningful questions, which will help the discussion progress. People
> > on this list who do not know the topic well enough may indeed ask
> > questions which are irrelevant or suggest solutions which are
> > inefficient, in which case you will be able to point out the concrete
> > reason for the irrelevance or inefficiency, and again, discussion will
> > progress toward a useful conclusion.
> >
> > Amicalement,
> Hi Albert,
> Thank you for clearing that for me, you are right and i was wrong with
> such questions, in fact that paragraph was quoted with text from Alan
> and i should knew better.
>
>
> On 10/24/2018 8:30 PM, Eric Rescorla wrote:
> > Kas,
> >
> > I've read through this entire thread, and TBH, I really don't
> > understand what threat you are concerned with.
> >
> > Can you please describe the specific attack you have in mind?
> >
> > -Ekr
> >
>
> Hi Eric,
>
> I am not talking about a threat or kind of attack per se, please let me
> put the points i trying to convoy in short :
> 1_ MitM is a threat, as there is no way for acme client to make sure he
> is talking to the intended acme server not to an impersonator, according
> to current draft of acme protocol you should :
>

I don't think I agree with this claim. The client's expectations about the
intended
server are set by its domain name and it verifies that it is talking to the
server in
question via the WebPKI.


2_ Depend on TLS layer to establish this trust and this will take us to
> root certificates supplied to the client, here i am suggesting should be
> avoided by implementing different approach as acme sever is de facto a
> trusted CA server and should be handled as such,
>

I don't understand what this means. The client doesn't take its root
certificates
from the ACME server. In fact, in the most common use cases for ACME,
issuance of WebPKI server certs, the server doesn't need to know
anything about trust anchors at all (the ACME *client* does, but
those are preinstalled and don't need to interact with the ACME server
other than doing ordinary WebPKI validation).

-Ekr

3_ Or consider adding to acme protocol a process to authenticate the
> server to the client, this will prevent any threats, but will raise
> different problem, the client should have the full chain to that
> certificate in secure way and can validate and match the resource
> directory url of acme server with specific root certificate to trust,
> hence my suggestion to utilize dns to publish a key ( may the root
> public key,CA's public key, a key intended to sign server response  ...
> something to authenticate the certificate and its acme server)
> 4_ Acme has online and automated certificate revocation protocol which
> is new, so any CA can already start to implement it even for different
> type of certificates ( eg. Code Signing ), that is great but why stop
> here and not add a process to supply the root and CA certificates
> instead on depending what client has.
> 5_ Acme editors know that along with most of you but choose to ignore
> that and that is fine as those points can be interpreted as irrelevant
> to this protocol but at the same time any expansion will not conflict
> with any other protocol, hence the title "Please consider" take this as
> petition to expand Acme for better internet.
>
> and 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] Please consider adding server authentication

[Eric Rescorla]

Kas,

I've read through this entire thread, and TBH, I really don't understand
what threat you are concerned with.

Can you please describe the specific attack you have in mind?

-Ekr


On Wed, Oct 24, 2018 at 9:18 AM Kas  wrote:

>
> On 10/24/2018 4:39 PM, Alan Doherty wrote:
> > At 11:02 24/10/2018  Wednesday, Kas wrote:
> >> Certificate is not just a public key, it has extensions well defined
> and standardized in RFC's, please educate your self with them, how and when
> they should handled and what actions they might trigger, and remember this:
> implementation of such handling is something can't be controlled and let me
> list few facts :
> > the functional part of a cert is just the public key (
> > all the rest and the extentions are just wrapping to give details of who
> else is vouching for it and what identities it is associated with)
> Wrong and you should not look at a certificate as a public key, please
> educate yourself with deeper understanding what do extensions serve and
> what critical extension means, i have a Code Signing certificate can i
> use it for IIS ? it has a public key ! and it been vouched by Comodo ,
> do you understand what is CRL Distribution Points(2.5.29.31) and how
> that certificate should be checked before considered trusted ?
>
> >> 1_ OpenSSL heartbleed went undetected for almost 2 years.
> > this had nothing to do with certs, all to do with the underlying
> encription implementation
> Vulnerabilities are everywhere and they are in implementations
>
> >> 2_ Hackers managed to jailbreak Apple iPhone by simply opening a pdf
> file ( handcrafted file with bad intentions) , imagine yourself opening a
> pdf file and losing the warranty of your phone .( though many people used
> that pdf intentionally )
> > again nothing to do with certs
> Certs are ASN.1 a data structure language and can be utilized to
> compromise a remote device, please search the web for "asn.1
> vulnerability" every system and many software got hacked by using
> handcrafted certificate, in my example how a pdf (Portable Document
> Format) file compromised a system
>
> >> 3_ Many client software's like browsers or email clients like
> Thunderbird will add every CA certificate automatically to their store
> > none will the entire point of the trusted root store is its involitility
> > a user can add roots manually but 0 software will update its root store
> except by normal (to it) software update
> I said CA certificate not root certificate there is difference, CA's in
> most cases will be added automatically to the store as long the root in
> the store, and some will add it as not trusted without root but in many
> cases will be added !
>
> >> ( their own store or the system store ) , MitM can issue CA certificate
> to a client which is in this case SMTP server and this server will use that
> certificate and help distribute this "compromised without losing the
> privatekey" certificate to everyone comes in contacting with that SMTP
> server.
> > thats patently impossible, otherwise new CAs could just use this method
> to gain trustinstead of the current hoop jumping amd auditing they have to
> go through to get included in software root stores
> > (why letsencrypt for example is signed by their own and other(extant in
> older sofware) roots till their own is widespread as software updates the
> signatures from other older CAs are needed (to ensure at least one of the
> root signitures is in potential clients root store)
> There is CA certificates providers and they are sell it, an attacker can
> get one from on by stealing the private key of one, it is not something
> impossible or didn't happen
>
> >> 4_ Keeping private key secret is a MUST, but this doesn't means you
> should trust the certificate from unknown sources, as they might be
> targeting your clients not you.( handcrafted with bad intentions)
> > again as long as it passes my validation (signed by 1 or more widely
> trused roots) it is doing its job (passing and verifying my public key)
> Read about the case of DigiNotar
>
> >> 5_ What if a company like Samsung wanted to issue certificates to its
> devices to make the connections between phones and TV secure, and it don't
> want to ask Apple and Microsoft to add Samsung root certificate to theirs
> system store, then Samsung can't use acme protocol or it can ?
> > it wouldnt prevent them at all
> > or adding their own CAs root to the trusted roots on all future devices
> Right, now how to update or revoke those certificate and keep the
> devices working wouldn't be easier and safe that you bought a TV and the
> paper guide instruct you to put X.com (it has by default) in settings
> and apply the key YYY if that didn't work then visit X.com and get
> the updated key after that it will be automated process, now to access
> that device form you PC instead of accepting the root and install it (
> or adding it to exclusion) you do the same use X and YY
>
> >> and i am here not pointing

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Eric Rescorla]

Thanks for clarifying.

On Mon, Oct 8, 2018 at 10:58 AM Salz, Rich  wrote:

>
>- No, because GET+capability > GET.  If you're going to have GET at
>all, you should have GET+capability
>
>
>
> And more importantly, you do not HAVE to do it; the text just has pointers
> on how to do it if desired.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Eric Rescorla]

My question is whether you would remove the text that JSHA was objecting to
about capabilities URLs.

On Mon, Oct 8, 2018 at 6:31 AM Richard Barnes  wrote:

> Not sure which existing text you're referring to.  No conflict comes to
> mind.
>
> In particular, this seems compatible with the stuff in #post-as-get about
> how the server indicates that it doesn't allow GET.  The model I have in
> mind is that this flag indicates that it's reasonable for the client to try
> GET, but the server may still deny in some cases.  Maybe that could be
> clarified.
>
> On Mon, Oct 8, 2018, 09:24 Eric Rescorla  wrote:
>
>> Speaking as an individual.
>>
>> Just to be clear, this change would be expected to coexist with the
>> existing capabilities text? Richard, does it require that we retain that
>> text?
>>
>> -Ekr
>>
>>
>> On Sun, Oct 7, 2018 at 4:37 PM Salz, Rich  wrote:
>>
>>> WG, this PR adds a new optional indicator that GET can be used to fetch
>>> certificates.
>>>
>>>
>>>
>>> If you opposed please speak up now.
>>>
>>>
>>>
>>> *From: *Richard Barnes 
>>> *Reply-To: *ietf-wg-acme/acme <
>>> reply+006fe294e1a4ec2f9470322136bc74568ac35354a6bccd5792cf000117d224cc92a169ce15e8e...@reply.github.com
>>> >
>>> *Date: *Sunday, October 7, 2018 at 3:47 PM
>>> *To: *ietf-wg-acme/acme 
>>> *Cc: *Subscribed 
>>> *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
>>> requests for certificates are allowed (#462)
>>>
>>>
>>>
>>> This avoids the need for the client to guess. Assumes that #459
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_459&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=6yfRh9z504d7dO7AZHfqVaLK67f8VZUhbutg4HyibIs&e=>
>>> will not be merged.
>>> --
>>> You can view, comment on, or merge this pull request online at:
>>>
>>>   https://github.com/ietf-wg-acme/acme/pull/462
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=zCXMvIeBxWA73LLbBDMobFZR09mkRMCUrP9bM5v_ylk&e=>
>>> Commit Summary
>>>
>>>- Add a meta flag to indicate when GET requests for certificates are
>>>allowed
>>>
>>> File Changes
>>>
>>>- *M* draft-ietf-acme-acme.md
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462_files-23diff-2D0&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=3-t1zAmt-HqR18SwnxsCgquqZyRAmp77GPE5ARp-XPg&e=>
>>>(4)
>>>
>>> Patch Links:
>>>
>>>- https://github.com/ietf-wg-acme/acme/pull/462.patch
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462.patch&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=iLEjv5GNBU4uXvONa0gllnpyj3HovrLyy5nqQK-zvYo&e=>
>>>- https://github.com/ietf-wg-acme/acme/pull/462.diff
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462.diff&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=8CNiNAnFkQae97gch-t0HidpnAqkaBJQ8su695zMYX0&e=>
>>>
>>> —
>>> You are receiving this because you are subscribed to this thread.
>>> Reply to this email directly, view it on GitHub
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=zCXMvIeBxWA73LLbBDMobFZR09mkRMCUrP9bM5v_ylk&e=>,
>>> or mute the thread
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AG-5FilACJeDnYH-2DFetofUArLOJQvAVdpKks5uilpMgaJpZM4XMAP2&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=r8HeHSMQ1w62iouWigror9a1ItZfkYtv9oNryK1PXMo&e=>
>>> .[image:
>>> https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
>>> ___
>>> 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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Eric Rescorla]

Speaking as an individual.

Just to be clear, this change would be expected to coexist with the
existing capabilities text? Richard, does it require that we retain that
text?

-Ekr


On Sun, Oct 7, 2018 at 4:37 PM Salz, Rich  wrote:

> WG, this PR adds a new optional indicator that GET can be used to fetch
> certificates.
>
>
>
> If you opposed please speak up now.
>
>
>
> *From: *Richard Barnes 
> *Reply-To: *ietf-wg-acme/acme <
> reply+006fe294e1a4ec2f9470322136bc74568ac35354a6bccd5792cf000117d224cc92a169ce15e8e...@reply.github.com
> >
> *Date: *Sunday, October 7, 2018 at 3:47 PM
> *To: *ietf-wg-acme/acme 
> *Cc: *Subscribed 
> *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
> requests for certificates are allowed (#462)
>
>
>
> This avoids the need for the client to guess. Assumes that #459
> 
> will not be merged.
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/ietf-wg-acme/acme/pull/462
> 
> Commit Summary
>
>- Add a meta flag to indicate when GET requests for certificates are
>allowed
>
> File Changes
>
>- *M* draft-ietf-acme-acme.md
>
> 
>(4)
>
> Patch Links:
>
>- https://github.com/ietf-wg-acme/acme/pull/462.patch
>
> 
>- https://github.com/ietf-wg-acme/acme/pull/462.diff
>
> 
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 
> .[image:
> https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
> ___
> 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] Allow get for certificates?

[Eric Rescorla]

Speaking as Area Director: there is no process problem with this reference.
Of course, it's a WG decision whether it's advisable.

-Ekr


On Sat, Oct 6, 2018 at 8:31 AM Salz, Rich  wrote:

> In order to address an issue raised during IESG review, unauthenticated
> GET for ACME server resources was changed to a simple POST that had a
> signed message body, providing authentication. Some raised the issue that
> they still wanted GET for certificates, as they’re public information and
> that sometimes a different process (without the account credentials) might
> be involved in the deployment workflow.  STAR was mentioned as an example..
>
>
>
> There is now concern about calling out STAR, as it is still a WG draft and
> the full extent of its requirements are not known.
>
>
>
> If you have anything else to add to this discussion, please do so now.
>
>
>
> diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
>
> index 26f..f1ca93f 100644
>
> --- a/draft-ietf-acme-acme.md
>
> +++ b/draft-ietf-acme-acme.md
>
> @@ -463,17 +463,6 @@ resources (see {{resources}}), in addition to
> POST-as-GET requests
>
> for these resources.  This enables clients to bootstrap into the
>
> ACME authentication system.
>
> -The server MAY allow GET requests for certificate resources in
>
> -order to allow certificates to be fetched by a lower-privileged
>
> -process, e.g., the web server that will use the referenced
>
> -certificate chain.  (See {{?I-D.ietf-acme-star}} for more advanced
>
> -cases.)  A server that allows GET requests for certificate resources
>
> -can still provide a degree of access control by assigning them
>
> -capability URLs {{?W3C.WD-capability-urls-20140218}}.
>
> -As above, if the server does not allow GET requests for a given
>
> -resource, it MUST return an error with status code 405 "Method Not
>
> -Allowed" and type "malformed".
>
> -
>
> ## Request URL Integrity
>
>  It is common in deployment for the entity terminating TLS for HTTPS to be
> different
>
>
> ___
> 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] ACME breaking change: Most GETs become POSTs

[Eric Rescorla]

This is a pretty substantive change and I think this does need to have a
short IETF-LC. Why don't you produce a new draft and let me know when you
believe the WG has consensus
-Ekr


On Thu, Sep 6, 2018 at 8:50 AM, Salz, Rich <
rsalz=40akamai@dmarc.ietf.org> wrote:

> We have already had some discussion on this.  I do not want to reset the
> WGLC.  Please take a look at the PR, it addresses issue that were brought
> up during IESG review.
>
>
>
> If you have objections or concerns, please reply by the end of next week,
> 14 sep.
>
>
>
> *From: *Richard Barnes 
> *Date: *Thursday, September 6, 2018 at 11:02 AM
> *To: *"acme@ietf.org" 
> *Cc: *"" , Eric Rescorla <
> e...@rtfm.com>, Adam Roach 
> *Subject: *Re: [Acme] ACME breaking change: Most GETs become POSTs
> *Resent-From: *
> *Resent-To: *Rich Salz , Yoav Nir 
> *Resent-Date: *Thursday, September 6, 2018 at 11:02 AM
>
>
>
> After the weekend's discussions, I've updated the PR to reflect what I
> understand to be emerging agreement on these topics:
>
>
>
> ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the
> privacy analysis?
>
> PROPOSED RESOLUTION: Yes.
>
>
>
> ISSUE 2: How should we signal that POST-as-GET request is different from
> other POST requests?
>
> PROPOSED RESOLUTION: A JWS with a zero-octet payload ("")
>
>
>
> ISSUE 3: Should servers be required to allow GET requests for certificate
> URLs?
>
> PROPOSED RESOLUTION: No, but they MAY
>
>
>
> ISSUE 4: How should we address the risk that an attacker can discover URLs
> by probing for Unauthorized vs. Not Found?
>
> PROPOSED RESOLUTION: Security considerations that recommend
> non-correlatable URL plans
>
>
>
> https://github.com/ietf-wg-acme/acme/pull/445
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0&e=>
>
>
>
> Adam: Is this looking like an approach that would satisfy your DISCUSS?
>
>
>
> Chairs / EKR: How would you like to proceed on closing this out?  What are
> the next process steps?
>
>
>
>
>
> On Fri, Aug 31, 2018 at 6:08 PM 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0&e=>
>
>
>
> On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews 
> wrote:
>
> ACME currently has unauthentica

Re: [Acme] POST-as-GET payload contents

[Eric Rescorla]

On Wed, Sep 5, 2018 at 9:53 AM, Salz, Rich <
rsalz=40akamai@dmarc.ietf.org> wrote:

>
>- Because being generous in what you receive is harmful.
>
> https://tools.ietf.org/html/draft-iab-protocol-maintenance-00
> 
>
>
>
> Sorry, I disagree with King Martin in this case. :)
>

I think he's still Prince Martin :)

-Ekr


>
> I think mandating a specific requrest body is hard to get right.
>
> ___
> 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] ACME breaking change: Most GETs become POSTs

[Eric Rescorla]

On Fri, Aug 31, 2018 at 12:43 PM, Nico Williams 
wrote:

> On Fri, Aug 31, 2018 at 03:37:01PM -0400, Daniel McCarney wrote:
> > > How does using POST address this?
> >
> > Please read the draft. We're talking about POSTs authenticated with JWS
> not
> > vanilla HTTP POSTs.
>
> That really should have been an HTTP authentication method :(
>

Not really, no. First, HTTP is just being used as a transport here. Second,
authentication is by digital signature, and that's not really
well-supported in HTTP. Third, it's way too late now to be having this
discussion.

-Ekr


>
___
> 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] Confirming consensus

[Eric Rescorla]

On Wed, Jul 25, 2018 at 9:46 AM, Salz, Rich <
rsalz=40akamai@dmarc.ietf.org> wrote:

> There was no email, other than process comments, on these.  Therefore they
> are (re-)entering WGLC.
>
>
>
> @ekr, please put draft-ietf-acme-acme-13 on the IESG agenda.
>

Due to the changes between -12 and -13, I believe it is appropriate to have
another IETFLC. I have requested that.

-Ekr


>
> The other two documents are very short.  Does anyone volunteer to do the
> shepherd writeup?  You can look at https://datatracker.ietf.org/
> doc/draft-ietf-acme-acme/shepherdwriteup/ for a sample.  This is a good
> way for someone new to the IETF process to get involved.
>
>
>
>
>
> *From: *Rich Salz 
> *Date: *Wednesday, July 18, 2018 at 3:56 PM
> *To: *"acme@ietf.org" 
> *Subject: *Re: Confirming consensus
>
>
>
> For completeness, these are
>
> draft-ietf-acme-acme-13
>
> draft-ietf-acme-tls-alpn-01
>
> draft-ietf-acme-ip-02
>
>
>
> *From: *Rich Salz 
> *Date: *Wednesday, July 18, 2018 at 2:47 PM
> *To: *"acme@ietf.org" 
> *Subject: *Confirming consensus
>
>
>
> As discussed in a separate thread, we added mandatory-to-implement JSON
> signing crypto (TLS 1.3 signing algorithms); note that this does not affect
> the certificates themselves.
>
>
>
> We decided to move draft-ietf-acme-tls-alpn and draft-ietf-acme-ip to
> working group last call.
>
>
>
> If you disagree with either of these decisions, please speak up by
> Monday.  Note that the WGLC for the main document is being re-run in
> parallel with IESG and soon IETF review.
>
>
>
>
>
> ___
> 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] Do we need/want mandatory-to-implement signature algorithms?

[Eric Rescorla]

On Thu, May 31, 2018 at 2:03 PM, Richard Barnes  wrote:

>
>
> On Wed, May 30, 2018 at 5:41 PM Stephen Farrell 
> wrote:
>
>>
>> Hi Russ,
>>
>> On 30/05/18 22:31, Russ Housley wrote:
>> > It seems to me that ACME is being used to support certificate
>> > enrollment for many different applications, so the same approach
>> > seems appropriate.
>> I agree with your description of the past:-)
>>
>> I don't agree with not specifying MTI algs though.
>>
>> My main reasons are that I think having MTI algorithms for
>> acme may lead to better interop and less proliferation of
>> algorithms/suites and less broken/non-tested code. (I
>> forget what I thought about this years ago, but I may have
>> changed opinion - it was reasonable for PKIX to not specify
>> MTI algs a decade or two ago, but that that is no longer a
>> good plan, as we now do really use all this stuff.)
>>
>> That said, I don't feel too strongly about it - in practice
>> I reckon all acme clients will in any case want to implement
>> and be able to use whatever works with LE, at least for the
>> next while, and so this won't be a practical problem either
>> way.
>>
>
> I am also not that sanguine about this topic, but I lean in the opposite
> direction.  The list of JWS algorithms [1] is not that long, and not
> growing quickly.  And there's no Ed25519.  So if we were to pick one or
> more MTIs out of this list, we would basically be locking in to ECDSA or
> RSA-PSS.
>
> As far as MTnotI: The SHA-1-based algorithms are already marked
> "Prohibited".  I guess you could ban RSA with PKCS#1v1..5, but that seems
> fairly low-value.
>
> Basically, it seems like the burden of those who want MUSTs here to make a
> proposal for what the MUSTs would be.
>

I made that proposal in a separate message: ECDSA w/ P-256 MUST,  EdDSA
X25519 SHOULD.

-Ekr


> --Richard
>
> [1] https://www.iana.org/assignments/jose/jose.xhtml#
> web-signature-encryption-algorithms
>
> ___
> 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-acme-12

[Eric Rescorla]

On Wed, May 30, 2018 at 12:56 PM, Salz, Rich  wrote:

>
>- Well, we have a fair bit of experience of a lot of people talking to
>Let's Encrypt. That's not really the same as a lot of servers and a lot of
>clients.
>
>
>
> We have multiple CA’s that support it, and other implementations as well.
> Certainly LE dominates, but it’s not the only usage.  And certainly not the
> only anticipated future usage.
>

Right. And the purpose of the MTI is usually to make future interop work
better.

>
>
>- I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with
>X25519.
>
>
>
> That would make the MTI limited to a subset of the WebPKI supported by the
> latest browsers, which seems wrong.  But let’s not bikeshed too much and
> see what the WG consensus is.
>

I'm not following your point here. Remember, I'm not talking about the MTI
for what the *certs* contain, but rather for what the protocol uses for its
in-protocol signatures. There's no reason you can't use an ECDSA key to
authorize issuance of an RSA cert (Which would presumably be in a
self-signed PKCS#10 blob with RSA), or for that matter, an XMSS cert.

The reason I chose those values is because you're already tied to TLS for
the communications and therefore you necessarily have the TLS MTI cipher
suites, which means you already have those algorithms.

-Ekr


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

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Wed, May 30, 2018 at 11:45 AM, Salz, Rich  wrote:

> I believe the working group has decided that MTI algorithms are not
> necessary.  If you want that confirmed on the list, we can ask.
>

Yes, please ask. If I'm going to tell the IESG that no MTI is needed, I
want to tell them that the WG had consensus.


  ACME isn’t just WebPKI, as you know, it’s also becoming STIR and some
> have proposed home environments.
>
>
>
> We have many implementations to serve as proof points that MTI isn’t
> required in the Real World.
>

As I said to Richard, it seems like much of the interop is between clients
and LE. It's not hard to get interop when one side is fixed.

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

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Wed, May 30, 2018 at 11:25 AM, Richard Barnes  wrote:

>
>
> On Tue, May 29, 2018 at 4:02 PM Eric Rescorla  wrote:
>
>>
>>
>> On Mon, May 28, 2018 at 9:57 PM, Russ Housley 
>> wrote:
>>
>>> Eric:
>>>
>>>
>>> > > Do you want to specify a set of acceptable signature algorithms here?
>>>>> >
>>>>> > I am inclined not to.  We have already forbidden "none" and MAC.  We
>>>>> > shouldn't specify "MUST"s here, because CABF sets their own list of
>>>>> > required algorithms, and we don't want to conflict.  I guess you
>>>>> > could specify some MUST NOTs pretty safely, but given that they're
>>>>> > already forbidden by CABF, it seems kind of duplicative.
>>>>>
>>>>> This is about the signatures that ACME accepts, not the signatures
>>>>> in certs. Does CABF have a position on what signature algorithms
>>>>> that ACME uses?
>>>>>
>>>>
>>>> Good point.  As Ryan pointed out, this is not something on which there
>>>> is currently CABF guidance.
>>>>
>>>> Nonetheless, I'm still disinclined to have MUSTs here for other
>>>> reasons.  If they're positive "MUST support" requirements, then we would
>>>> need to come back and revise this document in the event of an algorithm
>>>> break (though admittedly, that would be pretty far down on the TODO list).
>>>> And looking at the current list of JWS algorithms, I don't see any I would
>>>> MUST NOT, except possibly the ones based on SHA-1
>>>>
>>>
>>> Hmm... Common practice in security protocols is to specify MTI
>>> algorithms. Why is this different?
>>>
>>>
>>> PKIX chose not to specify mandatory-to-implement algorithms.  This was
>>> done because the application that made use of the certificate needed to be
>>> able to impose such requirements.
>>>
>>> Here is one place from the PKIX WG archive in 2011 that states this
>>> approach:
>>>
>>>(https://mailarchive.ietf.org/arch/msg/pkix/
>>> blSByMc7SysNNvkFlsFdcrFLrIs)
>>>
>>>PKIX defines PKI specs for a very wide range of apps, which is why we
>>>do not mandate any alg suite.  Different apps may use different alg
>>> suites.
>>>TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for
>>> itself.
>>>
>>> It seems to me that ACME is being used to support certificate enrollment
>>> for many different applications, so the same approach seems appropriate.
>>>
>>
>> Hmm... This seems like it would be more persuasive if there weren't a
>> dependency on TLS and its MTI algorithms
>>
>> From my perspective, this is sort of on the bubble. Historically, I've
>> seen the IESG insist on MTI algorithms, but it's not consistent. I would
>> like to understand if this is something that has strong consensus in the
>> WG, in which case I'll support that (though other IESG members may feel
>> differently) or if it just happened, in which case I'd ask the WG to
>> reconsider.
>>
>
> I think it's more in the latter category in the former, but TBH, I think
> that kind of argues in favor of the status quo -- we have a fair bit of
> implementation / deployment experience, and this has not been an interop
> problem.
>

Well, we have a fair bit of experience of a lot of people talking to Let's
Encrypt. That's not really the same as a lot of servers and a lot of
clients.


In a similar vein, where we have had discussion of versioning (a similar
> issue) there's been consensus *not* to go the traditional route of having
> version numbers -- you just have to know what version of ACME the endpoint
> you're talking to speaks.  It doesn't seem totally crazy to me for the same
> to be true of the signing algorithms you use.
>
> I guess I don't really know what value you're solving for here
>

I'm not sure what's confusing. The IETF has traditionally required MTI
algorithms to ensure that there is a baseline that allows two
implementations to talk to each other. We spent an enormous amount of time
on this in RTCWEB, so it's not exactly ancient history.

..  Just to try to make this concrete, if you were going to propose some
> algorithms to be MTI / MTnotI, what would you list?
>

I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with X25519.

-Ekr


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

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Mon, May 28, 2018 at 9:57 PM, Russ Housley  wrote:

> Eric:
>
>
> > > Do you want to specify a set of acceptable signature algorithms here?
>>> >
>>> > I am inclined not to.  We have already forbidden "none" and MAC.  We
>>> > shouldn't specify "MUST"s here, because CABF sets their own list of
>>> > required algorithms, and we don't want to conflict.  I guess you
>>> > could specify some MUST NOTs pretty safely, but given that they're
>>> > already forbidden by CABF, it seems kind of duplicative.
>>>
>>> This is about the signatures that ACME accepts, not the signatures
>>> in certs. Does CABF have a position on what signature algorithms
>>> that ACME uses?
>>>
>>
>> Good point.  As Ryan pointed out, this is not something on which there is
>> currently CABF guidance.
>>
>> Nonetheless, I'm still disinclined to have MUSTs here for other reasons.
>> If they're positive "MUST support" requirements, then we would need to come
>> back and revise this document in the event of an algorithm break (though
>> admittedly, that would be pretty far down on the TODO list).  And looking
>> at the current list of JWS algorithms, I don't see any I would MUST NOT,
>> except possibly the ones based on SHA-1
>>
>
> Hmm... Common practice in security protocols is to specify MTI algorithms.
> Why is this different?
>
>
> PKIX chose not to specify mandatory-to-implement algorithms.  This was
> done because the application that made use of the certificate needed to be
> able to impose such requirements.
>
> Here is one place from the PKIX WG archive in 2011 that states this
> approach:
>
>(https://mailarchive.ietf.org/arch/msg/pkix/blSByMc7SysNNvkFlsFdcrFLrIs
> )
>
>PKIX defines PKI specs for a very wide range of apps, which is why we
>do not mandate any alg suite.  Different apps may use different alg
> suites.
>TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for itself.
>
> It seems to me that ACME is being used to support certificate enrollment
> for many different applications, so the same approach seems appropriate.
>

Hmm... This seems like it would be more persuasive if there weren't a
dependency on TLS and its MTI algorithms

>From my perspective, this is sort of on the bubble. Historically, I've seen
the IESG insist on MTI algorithms, but it's not consistent. I would like to
understand if this is something that has strong consensus in the WG, in
which case I'll support that (though other IESG members may feel
differently) or if it just happened, in which case I'd ask the WG to
reconsider.
-Ekr


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

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Sun, May 27, 2018 at 3:00 PM, Richard Barnes  wrote:

> Updated PR:
>
> Responses to comments Github: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/710ef835446231ef954b0f6e448718eef04b63fa
> Responses to this email: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/3dd2a10ee55c13ff87772463374a7c0ab4205d5f
>
> Trimming points on which we agree...
>
> On Fri, May 25, 2018 at 12:09 PM Eric Rescorla  wrote:
>
>> > > IMPORTANT
>> > > S 6.2.
>> > > > algorithm in its "alg" field
>> > > >
>> > > >  o  The JWS Payload MUST NOT be detached
>> > > >  o  The JWS Protected Header MUST include the following fields:
>> > > >
>> > > > *  "alg" (Algorithm)
>> > >
>> > > Do you want to specify a set of acceptable signature algorithms here?
>> >
>> > I am inclined not to.  We have already forbidden "none" and MAC.  We
>> > shouldn't specify "MUST"s here, because CABF sets their own list of
>> > required algorithms, and we don't want to conflict.  I guess you
>> > could specify some MUST NOTs pretty safely, but given that they're
>> > already forbidden by CABF, it seems kind of duplicative.
>>
>> This is about the signatures that ACME accepts, not the signatures
>> in certs. Does CABF have a position on what signature algorithms
>> that ACME uses?
>>
>
> Good point.  As Ryan pointed out, this is not something on which there is
> currently CABF guidance.
>
> Nonetheless, I'm still disinclined to have MUSTs here for other reasons.
> If they're positive "MUST support" requirements, then we would need to come
> back and revise this document in the event of an algorithm break (though
> admittedly, that would be pretty far down on the TODO list).  And looking
> at the current list of JWS algorithms, I don't see any I would MUST NOT,
> except possibly the ones based on SHA-1
>

Hmm... Common practice in security protocols is to specify MTI algorithms.
Why is this different?




> >
> Perhaps just a forward reference.
>
> "Further down" here just means "the next paragraph".  Over that distance,
> I don't think a forward reference is really helpful :)
>

OK.



>
>>
>> > > S 7.1.2.
>> > > > initiated deactivation.
>> > > >
>> > > >  contact (optional, array of string):  An array of URLs that the
>> > > > server can use to contact the client for issues related to
>> this
>> > > > account.  For example, the server may wish to notify the
>> client
>> > > > about server-initiated revocation or certificate expiration.
>> > >
>> > > How am I supposed to know the semantics of these strings? And if they
>> > > are non-mailto URLs, what am I supposed to do with them.
>> >
>> > To first order, the semantic is defined by the scheme of the URL --
>> > "mailto" says "email me", "sip" or "tel" says "give me a call", etc.
>> > We have the "unsupportedContact" error type if the server doesn't
>> > know how to leverage a given scheme.
>>
>>
>> > Of course there are URL schemes that don't make sense as a contact
>> > point (e.g., "data:"), but trying to enumerate those seems quixotic.
>> > Better for the CA to check and reject with the error code we have
>> > provided.
>>
>> Well, http would also be hard to know what to do.
>>
>> My semantic question, however was: are these all equivalent and
>> undifferentiated?
>>
>
> I'm not sure I totally understand the question here, but I think the
> answer is "yes".  Either the server has code to handle a given contact URL
> scheme or it doesn't, in which case unsupportedContact.
>
>

This doesn't seem entirely clear:
1. What do I send to the HTTP URI, if anything? What method do I use?
2. If there is >1 URI, are they all semantically equivalent.



>> > > S 7.4.
>> > > >
>> > > >  The order object returned by the server represents a promise
>> that if
>> > > >  the client fulfills the server's requirements before the
>> "expires"
>> > > >  time, then the server will be willing to finalize the order
>> upon
>> > > >  request and issue the requested certificate.  In the order
>

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

Forwarding to the list, per Richard.

On Sun, May 27, 2018 at 3:00 PM, Richard Barnes  wrote:

> Updated PR:
>
> Responses to comments Github: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/710ef835446231ef954b0f6e448718eef04b63fa
> Responses to this email: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/3dd2a10ee55c13ff87772463374a7c0ab4205d5f
>
> Trimming points on which we agree...
>
> On Fri, May 25, 2018 at 12:09 PM Eric Rescorla  wrote:
>
>> > > IMPORTANT
>> > > S 6.2.
>> > > > algorithm in its "alg" field
>> > > >
>> > > >  o  The JWS Payload MUST NOT be detached
>> > > >  o  The JWS Protected Header MUST include the following fields:
>> > > >
>> > > > *  "alg" (Algorithm)
>> > >
>> > > Do you want to specify a set of acceptable signature algorithms here?
>> >
>> > I am inclined not to.  We have already forbidden "none" and MAC.  We
>> > shouldn't specify "MUST"s here, because CABF sets their own list of
>> > required algorithms, and we don't want to conflict.  I guess you
>> > could specify some MUST NOTs pretty safely, but given that they're
>> > already forbidden by CABF, it seems kind of duplicative.
>>
>> This is about the signatures that ACME accepts, not the signatures
>> in certs. Does CABF have a position on what signature algorithms
>> that ACME uses?
>>
>
> Good point.  As Ryan pointed out, this is not something on which there is
> currently CABF guidance.
>
> Nonetheless, I'm still disinclined to have MUSTs here for other reasons.
> If they're positive "MUST support" requirements, then we would need to come
> back and revise this document in the event of an algorithm break (though
> admittedly, that would be pretty far down on the TODO list).  And looking
> at the current list of JWS algorithms, I don't see any I would MUST NOT,
> except possibly the ones based on SHA-1.
>
>
>
>>
>>
>> > > S 6.3.
>> > > >  As noted in Section 6.2 above, all ACME request objects carry
>> a "url"
>> > > >  header parameter in their protected header.  This header
>> parameter
>> > > >  encodes the URL to which the client is directing the request.
>> On
>> > > >  receiving such an object in an HTTP request, the server MUST
>> compare
>> > > >  the "url" header parameter to the request URL.  If the two do
>> not
>> > > >  match, then the server MUST reject the request as unauthorized.
>> > >
>> > > I think you probably need to provide a clear definition of how you
>> > > "compare" them. Is it memcmp? Something else?
>> >
>> > This is specified further down:
>> >
>> > """
>> > The server SHOULD perform the corresponding string equality check,
>> > configuring each resource with the URL string provided to clients
>> > and having the resource check that requests have the same string in
>> > their “url” header parameter.
>> > """
>>
>> Perhaps just a forward reference.
>>
>
> "Further down" here just means "the next paragraph".  Over that distance,
> I don't think a forward reference is really helpful :)
>
>
>
>>
>> > > S 7.1.2.
>> > > > initiated deactivation.
>> > > >
>> > > >  contact (optional, array of string):  An array of URLs that the
>> > > > server can use to contact the client for issues related to
>> this
>> > > > account.  For example, the server may wish to notify the
>> client
>> > > > about server-initiated revocation or certificate expiration.
>> > >
>> > > How am I supposed to know the semantics of these strings? And if they
>> > > are non-mailto URLs, what am I supposed to do with them.
>> >
>> > To first order, the semantic is defined by the scheme of the URL --
>> > "mailto" says "email me", "sip" or "tel" says "give me a call", etc.
>> > We have the "unsupportedContact" error type if the server doesn't
>> > know how to leverage a given scheme.
>>
>>
>> > Of course there are URL schemes that don't make sense as a contact
>> > point (e.g., "data:&

Re: [Acme] acme-ip reverse-dns discussion

[Eric Rescorla]

On Wed, Mar 21, 2018 at 1:55 PM, Roland Bracewell Shoemaker <
rol...@letsencrypt.org> wrote:
>
> The argument for removing this was that there are no technical issues with
> the method as-is but that the reverse DNS zones are historically badly
> managed and that using them for validation will cause problems down the
> line (presumably misissuance by a person who controls the zone but doesn’t
> actually control the IPs the zone represents).


I'm not sure why you don't think this is a technical issue.

In any case, this is part of the argument, but not the only part. The
reason that the forward DNS lookup check is reasonable (to the extent to
which it is) is that forward DNS resolution is an integral part of going to
the site, and therefore control of the DNS substantively *is* control of
the site (i.e., there is fate sharing). By contrast, reverse resolution
forms no part of addressing the site, and therefore control of this region
of the DNS proves nothing about your control of the site. This is, of
course, why the reverse tree is in such bad shape.



> The argument for keeping it is that the IETF (or more specifically the
> ACME WG) should not be where CA or browser policy is dictated and that
> given these methods are currently allowed under the CABF BRs and browser
> root programs it would actually be useful to have a technically defined
> method for validation that can at least be used as a tool for further
> research on the topic.
>

It's not a matter of dictating CA or browser policy, but of not
standardizing a method of validation which we know to be severely flawed.
In no way does this preclude other people from deploying this
authentication mechanism; the standard for registering an identifier in
this space is "Specification Required" and the standard the expert is
supposed to evaluate is quite low (
https://tools.ietf.org/html/draft-ietf-acme-acme-11#section-9.7.8).

   When evaluating a request for an assignment in this registry, the
   designated expert should ensure that the method being registered has
   a clear, interoperable definition and does not overlap with existing
   validation methods.  That is, it should not be possible for a client
   and server to follow the same set of actions to fulfill two different
   validation methods.

If CAs wish to experiment with -- or even use -- this technique, they need
only publish a specification. The difference is that the IETF would not be
endorsing it.

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

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

[Eric Rescorla]

On Wed, Nov 1, 2017 at 7:10 PM, Richard Barnes  wrote:

>
>
> On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren  wrote:
>
>> As a client developer, I slightly prefer submitting the CSR twice. In
>> addition to making the request logic a bit simpler, it causes the client to
>> provide more information about the cert it would like to obtain earlier in
>> the process. This was mentioned in another thread on this topic, but to
>> provide a concrete example of where this might be useful, Let's Encrypt
>> currently refuses to issue for CSRs containing a weak key. By initially
>> providing the CSR, the server is able to immediately reject the request
>> rather than waiting until the end of the process.
>>
>> This approach would mean something else needs to be done to alleviate
>> bloat in in the server's database, but I think it provides a better
>> experience on the client side.
>>
> I think as long as the CSR is also included in the finalize request, we're
> OK for CA bloat -- the CA can throw away the first CSR after it parses it
> and produces the authorizations.
>
> Or rather, they should keep around a hash of the CSR so that they can
> verify that the second CSR is the same.  Since we should require that.
>

This seems like a great opportunity for defects.

-Ekr


>
> --Richard
>
>
>> On 11/01/2017 09:13 AM, Richard Barnes wrote:
>>
>> Some of us have been discussing this off-list, and where we got to was
>> basically as follows:
>>
>> 1. We should have some sort of explicit "finalize" request that triggers
>> issuance of a certificate
>> 2. The finalize request will need to have the CSR attached to it, so that
>> the CA doesn't have to cache the CSR from new-order
>> 3. The "new-order" request still needs to have some sort of description
>> of the certificate being requested, in order to support legacy back-end
>> interfaces,
>> 4. That description can be either:
>>   4.1. In the form of a CSR, or
>>   4.2. In the form of a list of identifiers (as in @cpu's PR [0])
>>
>> On the one hand, sending a CSR twice seems clumsy (as Hugo notes above)
>> and it makes the server parse the CSR twice.  On the other hand, using a
>> CSR both times makes the client logic a bit simpler since you just send the
>> same thing in both requests.
>>
>> Anyone else have thoughts here?
>>
>> --Richard
>>
>>
>> [0] https://github.com/ietf-wg-acme/acme/pull/342
>>
>>
>>
>>
>>
>> On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney 
>> wrote:
>>
>>> Wouldn't it be a lot better not to do the validations at all if you can
 tell at new-order time that you're not going to be willing to issue?
>>>
>>>
>>> Yes, that would be better in this one capacity. However I don't think it
>>> comes close to justify the scaling issues associated with accepting the CSR
>>> up-front, and as mentioned, there are other reasons why validations may
>>> occur for an order that the CA isn't willing to issue at the time of
>>> finalization.
>>>
>>> There also isn't a CAA-PKP so we're bikeshedding about impact on
>>> features that are both unspecified & unimplemented.
>>>
>>> - Daniel / cpu
>>>
>>> On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes  wrote:
>>>


 On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney 
 wrote:

> > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key).
> Implementing that without knowing the public key at validation time
> is annoying.
>
> Can you expand on "annoying"?
>
> It seems completely possible to reject the order finalization message
> based on a CAA-PKP property.
>

 Wouldn't it be a lot better not to do the validations at all if you can
 tell at new-order time that you're not going to be willing to issue?



> In-fact, we already have to be rechecking CAA for authorizations
> validated more than 8 hours ago at the time of issuance so there must be
> code in place to check CAA at finalization and clients must be prepared 
> for
> their order to be rejected at finalization based on CAA already.
>
> I don't see how this is any more annoying.
>
> - cpu
>
> On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara <
> ilariliusva...@welho.com> wrote:
>
>> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote:
>> >
>> > The ACME protocol should permit CAs to implement policy as far as is
>> > reasonably practicable with regard to the workflows around which the
>> > protocol is organised. Providing the CSR up-front allows the CA to
>> > predicate order processing on aspects of that CSR, both with regard
>> to
>> > the present protocol and any future extensions, both now and in the
>> > future in ways that we can and cannot foresee. I don't think it's
>> > appropriate to defer giving critical information to the CA until the
>> > last minute due to a resource utilisation concern which LE has
>> already
>> > proven capable of dealing with, espec

Re: [Acme] AD review of draft-ietf-acme-acme

[Eric Rescorla]

On Tue, Oct 31, 2017 at 12:51 PM, Richard Barnes  wrote:

>
>
> On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty <
> kathleen.moriarty.i...@gmail.com> wrote:
>
>> Hi Richard,
>>
>> On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes  wrote:
>> >
>> >
>> > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty
>> >  wrote:
>> >>
>> >> Hi Richard,
>> >>
>> >> Thanks for posting the diff, I reviewed the changes and they look
>> >> good, but I have a couple of questions.  FYI - I had started looking
>> >> at the PR, but something came up, sorry for the delay and this was a
>> >> good reminder.
>> >>
>> >> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes  wrote:
>> >> > Hi Kathleen,
>> >> >
>> >> > Thanks for the review.  Some responses inline.  I've started a PR to
>> >> > respond
>> >> > to these comments here:
>> >> >
>> >> > https://github.com/ietf-wg-acme/acme/pull/345
>> >> >
>> >> > I agree with Daniel that we should hold off on IETF LC until we've
>> >> > addressed
>> >> > the issues around proactive issuance / caching of CSRs.  That may
>> >> > require a
>> >> > re-WGLC, but once that's closed, it should be safe to send to IETF
>> LC.
>> >> >
>> >> >
>> >> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty
>> >> >  wrote:
>> >> >>
>> >> >> Hello,
>> >> >>
>> >> >> Thank you to the editors and WG for your efforts on
>> >> >> draft-ietf-acme-acme, it's a well written and easy to understand
>> >> >> draft.  I do have a few comments, that need to be address by the
>> >> >> editors and SHEPHERD.
>> >> >>
>> >> >> Please review the idnits.  There are a few warnings that should be
>> >> >> correctable and can be addressed, but more importantly, it calls out
>> >> >> several downrefs that are not in the shepherd writeup.  These need
>> to
>> >> >> be in the writeup and then also mentioned in the IETF last call
>> >> >> announcement (I'll make sure the latter happens).
>> >> >>
>> >> >> Here's my mostly editorial comments:
>> >> >>
>> >> >> Introduction:
>> >> >> It reads very well, but it would be helpful to those unfamiliar with
>> >> >> the work to explicitly state that ACME is about DV certificates.
>> The
>> >> >> first sentence of the last paragraph seems like the best place to
>> add
>> >> >> this in.
>> >> >> Current text:
>> >> >>This document describes an extensible framework for automating
>> the
>> >> >>issuance and domain validation procedure, thereby allowing
>> servers
>> >> >>and infrastructural software to obtain certificates without user
>> >> >>interaction.
>> >> >> Proposed:
>> >> >>This document describes an extensible framework for automating
>> the
>> >> >>issuance and domain validation procedure for DV certificates,
>> >> >> thereby allowing servers
>> >> >>and infrastructural software to obtain certificates without user
>> >> >>interaction.
>> >> >
>> >> >
>> >> > As others have pointed out, ACME is not just about DV.  PR has some
>> >> > clarification on this point.
>> >>
>> >> I see the text on uses in other PKI contexts in the introduction, but
>> >> don't see anything on the certificate types and out-of-band processes
>> >> (as is the case for the STIR use case Mary mentioned).  Maybe I'm
>> >> missing it, can you tell me where to look?
>> >
>> >
>> > I don't think you're missing anything.  What do you mean by "certificate
>> > types and out-of-band processes"?  How is that different from "other PKI
>> > contexts"?
>>
>> I think by PKI-context, you mean the application of use, is that
>> right?  I am separating out the type of certificate (DV, EV, etc.) as
>> you have done in the second paragraph of the introduction.  When
>> reading the rest of the document, there isn't text that says what type
>> of certificate ACME produces without any additional processes
>> (out-of-band authentication/validation).  If you think about
>> administrators who operate servers (whatever the protocol) or even
>> those who may wish to incorporate ACME into a new application, they
>> will may have to figure out what level ACME provides as a default and
>> also know that there can be additional processes added to obtain
>> certificates types at a higher assurance level using ACME.  Since the
>> text already does a nice job of explaining the certificate types, this
>> should be an easy follow up that I think will be very helpful to
>> people outside of the IETF or who look at this in the future.
>>
>> Maybe something like the following:
>>
>>Strictly following the automation enabled by ACME, DV certificates
>> are issued.
>>Additional processes can be provided by the CA to increase the level of
>>validation on an end entity to issue certificates at a higher
>> assurance level,
>>for instance an EV certificate.  > the STIR
>>example Mary mentioned in this thread.>
>>
>> Does that help?  Thinking about this in former roles and having been
>> to some conferences lately, I think being explicit about this will
>> help those trying to evaluate and deploy ACME.  Th

Re: [Acme] v2

[Eric Rescorla]

I agree with MT here. We should just name it v1. That's what IETF change
control means

On Tue, Jun 13, 2017 at 5:54 PM, Martin Thomson 
wrote:

> I don't see the distinction between what LE deploy and ACME as defined
> by the IETF being any different to the distinction between whatever
> any other CA currently deploy and the IETF spec.  It's a thing that
> exists, but I see no reason to accord the LE proprietary protocol any
> special status other than by acknowledging provenance.
>
> This is the IETF version of ACME, and as such it needs no version
> qualification.  I doubt that there will be any confusion from this
> being deployed alongside the proprietary LE protocol.
>
> On 13 June 2017 at 16:26, Richard Barnes  wrote:
> > (Everyone get your bike shed paint out)
> >
> > In talking with a few folks around the community, I've heard people
> refer to
> > the IETF version of ACME as "v2", where implicitly "v1" is the initial
> > version deployed by Let's Encrypt and its clients right now.
> >
> > How would people feel about reflecting this in the draft / RFC?  I've
> posted
> > a PR with the changes this would entail:
> >
> > https://github.com/ietf-wg-acme/acme/pull/321
> >
> > The only question this raises for me is what to do about v1.  Given that
> > Let's Encrypt has evolved their interface some since the first version,
> I'm
> > not sure there's one consolidated spec out there for what they currently
> > have deployed.  So while it would be nice to have a reference to v1 in
> this
> > document if we make it v2, I'm not inclined to worry about it too much.
> I'm
> > willing to leave it up to the LE folks if they want to submit a v1 later
> for
> > historical purposes.
> >
> > Any objections to merging the above PR?
> >
> > --Richard
> >
> >
> > ___
> > 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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Eric Rescorla]

I don't think it's the CA's job to dictate policy in this area.

-Ekr


On Thu, Mar 30, 2017 at 12:26 PM, Dr. Pala  wrote:

> Hi all,
>
> I have a small question about the I-D. In particular, it seems to me that
> this proposal circumvents any limitation on the effective lifetime of a
> short-lived-cert's keypair. From a cryptographic standpoint of view, it is
> good practice to impose strict lifetimes on keys (i.e., usually via
> validity periods in certificates) to limit the issue of successful attacks
> on the crypto scheme (e.g., key factorization). This proposal would
> de-facto remove this property by adopting re-issuing instead of re-keying
> when renewing a certificate.
>
> Although the CA might be able to track the usage of a key from the initial
> CSRs, the automatic issuance of the certificate itself without the
> constraints of the key longevity seems quite dangerous and possibly open to
> a policy of "set-and-forget" that might last for... years... (automatically
> not re-issuing the certificate based on key-size + CSR timestamp would, I
> think, create issues for CDNs as there would be no indication when a new
> LURK/CSR cycle is needed).
>
> Am I reading it wrong / missing something ?
>
> Cheers,
> Max
>
> --
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca
>
> ___
> 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] Generating nonces probabilistically in 6.4.1. Replay-Nonce

[Eric Rescorla]

As the veteran of many arguments about pseudorandomness and uniqueness, I
think
it's reasonable to consider a sufficiently long random string to be unique.

"high probability" actually makes it worse, because 99.99 is actually a
very high
probability but not really a security boundary. If you want to provide more
guidance,
I would suggest instead giving a minimum length for the random string.

-Ekr


On Tue, Mar 28, 2017 at 7:16 AM, Alan Doherty  wrote:

> At 11:46 28/03/2017  Tuesday, Martin Thomson wrote:
> >I agree with Jacob here.  MUST seems appropriate, but requiring
> >uniqueness absolutely imposes a constraint on server design that is so
> >onerous that I would see it as impractical.  (Also, the document
> >doesn't really identify a scope for this uniqueness, which would
> >probably be necessary if you had to avoid random generation.)
>
>
> i think given a large enough set of transactions unique is impossible (and
> guaranteeing a previous use in identical circumstances impossible, unlikely
> but not guaranteeing)
> thus as its impossible mathematically (unless using sequential numbers of
> infinite length)
>
> its better to keep 'high probability' as the possibility of random
> generating a sequence twice is always there, if its truly random
> improbable can be done, impossible is infinitely more work (as would
> require keeping all previous and negative matching an ever growing list
> before use)
>
>
>
> >On 27 March 2017 at 16:46, Jacob Hoffman-Andrews  wrote:
> >> Forwarding on behalf of Erica Portnoy.
> >>
> >> I agree, the uniqueness should be a MUST, but I think "high probability"
> >> should stay so random generation of nonces is acceptable. PR:
> >> https://github.com/ietf-wg-acme/acme/pull/289
> >>
> >>
> >>  Forwarded Message 
> >> Subject:Generating nonces probabilistically in 6.4.1.
> Replay-Nonce
> >> Resent-Date:Fri, 24 Mar 2017 18:19:35 -0700 (PDT)
> >> Resent-From:alias-boun...@ietf.org
> >> Resent-To:  r...@ipv.sx, j...@eff.org, jdkas...@umich.edu
> >> Date:   Fri, 24 Mar 2017 18:03:53 -0700
> >> From:   erica 
> >> To: draft-ietf-acme-a...@ietf.org
> >>
> >>
> >>
> >> In section 6.4.1. Replay-Nonce, it states: "The server should generate
> >> the value provided in Replay-Nonce in such a way that they are unique to
> >> each message, with high probability."
> >>
> >> Should this not be: "The server MUST generate the value provided in
> >> Replay-Nonce in such a way that they are unique to each message."
> >>
> >> This is actually two separate items:
> >> - First, that the server must, not should, generate a unique
> >> Replay-Nonce. I can't imagine that we're ok with the spec allowing a
> >> server to come under replay attacks, so this should probably be MUST.
> >> - Second, do Replay-Nonces need to be certainly unique to each message?
> >> Or are we merely attempting to mostly rule out replay attacks? If we
> >> want to disable them completely, not just with extremely high
> >> probability, then we should remove "with high probability".
> >>
> >> Best,
> >> Erica Portnoy
> >>
> >>
> >> ___
> >> 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 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] Registering a PEM Content-Type

[Eric Rescorla]

On Sun, Mar 12, 2017 at 12:54 PM, Jacob Hoffman-Andrews 
wrote:

> On 03/12/2017 12:50 PM, Salz, Rich wrote:
> > What about saying each certificate SHOULD be a signer on *A* preceding
> certificate?  This allows us to serve a single cert chain for both MD5  and
> SHA1, for example.  (Contrived examples of course.)
> I think the current language (copied from TLS 1.3) conveys that, though
> it's a bit subtle:
>
> > Each following certificate SHOULD directly certify one preceding it.
>

Note: this used to be a MUST-level requirement, but due to the complexities
of the deployed
PKI, in 1.3 it was relaxed to be a SHOULD.

-Ekr


> ___
> 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] Combine "requirements" and "authorizations."

[Eric Rescorla]

I'm basically with Richard here. I don't think that the change that Jacob
suggests is disastrous but it also doesn't seem very well-motivated and
given that we're trying to get to done, the bar for changes like this
should be fairly high. I don't think this rises to it.

On Sat, Oct 29, 2016 at 9:59 AM, Richard Barnes  wrote:

>
>
> On Fri, Oct 28, 2016 at 6:34 PM, Jacob Hoffman-Andrews 
> wrote:
>
>> On 10/28/2016 03:18 PM, Richard Barnes wrote:
>> > I think the crux of our disagreement is actually above.  You seem to
>> > be arguing that authz for different identifier types are as different
>> > from one another as OOB is from DNS-name.  I'm saying that the
>> > identifier validation process is going to be the same for many
>> > different identifiers, so the "authorization" abstraction is meaningful.
>> Can you give an example of how they will be the same? The currently
>> defined dns-01, http-01, and tls-sni-02 challenges can only be used for
>> DNS identifiers.
>>
>
> Sure.  As I said before, you'll use different sets of challenges, but the
> overall flow remains the same.
>
> Imagine an ACME client / server has a module that implements the challenge
> / validation logic for a challenge types.  For an HTTP challenge, it things
> like make the HTTP challenge object, configure an HTTP server, do the HTTP
> requests.  For a putative SMS-based challenge, it would generate the
> challenge object, and orchestrate the sending / responding-to of SMS
> messages.
>
> Then the flow from the server's perspective is:
>
> 1. On new-app requiring a new authz:
> 1.1. Query the list of challenge modules to see which support $IDENTIFIER
> 1.2. For each supported challenge type, construct a challenge object for
> $IDENTIFIER
> 1.3. Assemble the challenges into an authorization object
> 2. When the client responds to a challenge:
> 2.1. Call out to the module that generated the challenge
> 2.2. [[ module goes off and validates the challenge ]]
> 2.3. When the module has finished validating, update the authz with the
> results.
>
> None of that is dependent on the type of identifier being validated.  This
> is a very clean abstraction boundary.  You can see this with the simplicity
> of the API in rocket-skates; the above is exactly what it does.
>
>
>
>> The "oob" challenges can be used by what you propose currently fill the
>> "requirements" niche. Specifically, you would have an authorization of
>> type "oob", containing a single challenge of type "oob."
>>
>
> Now you're the one adding unnecessary levels of abstraction ;)
>
> --Richard
>
> ___
> 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] Combine "requirements" and "authorizations."

[Eric Rescorla]

I'm basically with Richard here. I don't think that the change that Jacob
suggests is disastrous but it also doesn't seem very well-motivated and
given that we're trying to get to done, the bar for changes like this
should be fairly high. I don't think this rises to it.

On Sat, Oct 29, 2016 at 9:59 AM, Richard Barnes  wrote:

>
>
> On Fri, Oct 28, 2016 at 6:34 PM, Jacob Hoffman-Andrews 
> wrote:
>
>> On 10/28/2016 03:18 PM, Richard Barnes wrote:
>> > I think the crux of our disagreement is actually above.  You seem to
>> > be arguing that authz for different identifier types are as different
>> > from one another as OOB is from DNS-name.  I'm saying that the
>> > identifier validation process is going to be the same for many
>> > different identifiers, so the "authorization" abstraction is meaningful.
>> Can you give an example of how they will be the same? The currently
>> defined dns-01, http-01, and tls-sni-02 challenges can only be used for
>> DNS identifiers.
>>
>
> Sure.  As I said before, you'll use different sets of challenges, but the
> overall flow remains the same.
>
> Imagine an ACME client / server has a module that implements the challenge
> / validation logic for a challenge types.  For an HTTP challenge, it things
> like make the HTTP challenge object, configure an HTTP server, do the HTTP
> requests.  For a putative SMS-based challenge, it would generate the
> challenge object, and orchestrate the sending / responding-to of SMS
> messages.
>
> Then the flow from the server's perspective is:
>
> 1. On new-app requiring a new authz:
> 1.1. Query the list of challenge modules to see which support $IDENTIFIER
> 1.2. For each supported challenge type, construct a challenge object for
> $IDENTIFIER
> 1.3. Assemble the challenges into an authorization object
> 2. When the client responds to a challenge:
> 2.1. Call out to the module that generated the challenge
> 2.2. [[ module goes off and validates the challenge ]]
> 2.3. When the module has finished validating, update the authz with the
> results.
>
> None of that is dependent on the type of identifier being validated.  This
> is a very clean abstraction boundary.  You can see this with the simplicity
> of the API in rocket-skates; the above is exactly what it does.
>
>
>
>> The "oob" challenges can be used by what you propose currently fill the
>> "requirements" niche. Specifically, you would have an authorization of
>> type "oob", containing a single challenge of type "oob."
>>
>
> Now you're the one adding unnecessary levels of abstraction ;)
>
> --Richard
>
> ___
> 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] Specify account by kid (reg URL) rather than key. #193

[Eric Rescorla]

I am inclined to agree with Richard here.

In particular, I'm surprised to see Jacob's arguments that key comparison
is a threat because of hash collisions [0]. It seems like if we are
computing fingerprints using hash functions with collision attacks, we've
got bigger problems than this.

-Ekr

[0] Nit: it seems like most useful attacks would be because of pre-images.

On Sun, Oct 2, 2016 at 8:40 AM, Richard Barnes  wrote:

> I can live with this, but I'm not enthusiastic.
>
> tl;dr: Makes things more complicated, security benefit debatable.
>
> It makes me sad to lose the clean layering between cryptographic
> verification and verification of identity.  Before, the need to provide a
> valid signature provided some minimal validation of the request that could
> be performed totally statelessly by the server.  Now, the request
> validation logic needs access to the account DB.  I guess whether you see
> this as a loss depends on whether you regard signature verification or DB
> access as more expensive; I am far more wary of DB access, and state
> coupling in general.
>
> I also don't think the attribution gains here are quite as big as are
> being suggested.  For all requests where the account tied to the key
> matters, the account is identified by the key.  So the error case here
> isn't like an HTTPS client that doesn't check the server's cert and
> proceeds with the connection anyway; an ACME server that doesn't look up
> the account for a key is unable to proceed.
>
> I'll grant that the "kid" approach is somewhat harder to attack than the
> "jwk" approach.  In order to get the server to recognize a bad key pair,
> the attacker needs to get a confusable account URI, and account URIs are
> issued by the server.  So you basically need two bugs instead of one (URI
> allocation + comparison, vs. key comparison).  Nonetheless, key comparison
> does not seem that risky to me -- it's what undergirds every TLS and SSH
> session you've ever engaged in, after all, and I don't recall ever hearing
> about a major vuln in an implementation of these protocols due to a key
> comparison flaw.  I don't have the same confidence in URL allocation and
> comparison routines, which will have much more variability.
>
>
>
> On Tue, Sep 27, 2016 at 9:24 AM, Daniel McCarney 
> wrote:
>
>> I'm also strongly in favour of this change. I think the minimal increase
>> in client
>> state/complexity is offset by the gain of knowing that the category of
>> potential
>> bugs that Jacob mentions are avoided.
>>
>>
>> On Tue, Sep 27, 2016 at 1:01 AM, Martin Thomson > > wrote:
>>
>>> I am inclined to think that this is a good change, on the basis that
>>> it means that the server is minting the identifiers that the client
>>> uses.  I think that Jacob is probably understating the potential for
>>> bugs here.  And key canonicalization is a bad smell.
>>>
>>> On 27 September 2016 at 14:51, Jacob Hoffman-Andrews 
>>> wrote:
>>> > I understand the concern, but I think that clients already have to
>>> store
>>> > a significant amount of state: the ACME directory URL, the private key,
>>> > and the domain names, certificates, and private keys of existing
>>> > certificates. I think that one more item, the account URL, is not a
>>> > heavy burden, especially when weighed against a real flaw in the
>>> > protocol. You could consider it akin to storing a username and password
>>> > for a more traditional login.
>>> >
>>> > All that said, for clients that find it to be a big savings, there is
>>> > always the method of finding the account URL by POSTing again to
>>> new-reg
>>> > with the same key.
>>> >
>>> > On 09/24/2016 06:16 PM, Hugo Landau wrote:
>>> >> I'm somewhat against this on the grounds that it introduces
>>> unnecessary
>>> >> state into clients (the registration URI), increasing their
>>> complexity.
>>> >>
>>> >> ___
>>> >> 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 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 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] Combine "requirements" and "authorizations."

[Eric Rescorla]

On Sun, Oct 2, 2016 at 7:46 AM, Richard Barnes  wrote:

> I'm worried that we're losing a lot of useful, clear semantics here in
> order to save a few bytes.
>
> I understand the impulse here; it is challenging to have multiple status
> values that could conflict with each other, and it's a pain for the client
> to have to go fetch a separate authorization resource to find out what it
> has to do.  That doesn't mean that we've gotten the semantics wrong; we've
> just put the bits in the wrong place.
>
> If we want to do something here, I think the right way to think about it
> is as "inlining" the authorization document in the authorization
> requirement, just as challenge resources are inlined into authorization
> resources.  That is, we would have "authorization" requirement objects
> contain the contents of the authorization resource, in addition to a URL
> for the authorization resource.
>
> However, I'm not really sure that even that is worthwhile.  Consider that
> authorizations can be re-usable for multiple applications; we envisage
> clients being able to authorize a bunch of domains, then issue certificates
> for arbitrary combinations.  It's wasteful to replicate the authorization
> document in each application that uses already-valid authorizations, in
> terms of bytes on the wire, but also in terms of the server's state storage
> (if it stores the authorizations in the application object) or processing
> (if it re-assembles them each time).  At the very least, we need to have
> authorizations continue to be independently addressable in order to
> indicate clearly that the same authorization is being used for different
> applications -- a need that does not necessarily apply to other types of
> requirement objects.
>
> In any case, we should not lose the semantic distinction between "proving
> that you control an identifier" and other things a server requires the
> client to do.
>

+1

I think this is most obvious in the case of payment. A CA might ask me to
prove that I own the identifier once
but pay each time. This seems like it should be first-class.

-Ekr


> This PR also removes two important pieces of functionality:
> - The generic OOB requirement type - Would need to be replaced by new
> authorization types
> - The ability of the protocol to cleanly support new identifier types;
> instead of just defining a new identifier type and some challenges, you
> need to copy / paste the whole definition of the dns-name challenge.
>
> So my preference here would be to be more targeted:
> - Clarify that the "status" of an "authorization" requirement MUST equal
> the status of the underlying authorization
> - Possibly allow inlining of the authorization (not require, for the reuse
> reasons above)
>
>
>
>
> On Thu, Sep 29, 2016 at 5:28 PM, Ted Hardie  wrote:
>
>> On Thu, Sep 29, 2016 at 1:50 PM, Jacob Hoffman-Andrews 
>> wrote:
>>
>>>
>>> This also makes sense. I think URIs make more sense, rather than
 defining a new namespace. And the URIs can contain more information
 about the type. What do other folks think?


>>> I'm a little confused about the proposal, especially how the URI would
>>> contain more information about the type.   Would you mind fleshing this out
>>> a bit?
>>>
>>> Something like this:
>>>
>>> Servers that create authorization objects with a non-standard type
>>> should provide a URL as the type string. This allows non-standard types to
>>> be created in a well-defined namespace, to avoid conflicts. Visiting the
>>> URL in a web browser should result in a human-readable web page describing
>>> the non-standard authorization type.
>>>
>>> However, I'm very open to other suggestions!
>>>
>>
>> Well, I guess I have two thoughts here.  The first is that if we do want
>> to shift to URIs, then we should move DNSname to also being a URI (a URN at
>> IANA or an IANA registry entry).  If the client recognizes it, then it
>> doesn't need to dereference the page, as the content is guaranteed to be
>> the same (especially so in the case of URNs), but it is getting the same
>> sort of identifier for standard and nonstandard types.
>>
>> But I'm not sure that this is the right direction, as I worry that we
>> might lose interoperability over time.  For out-of-band authorizations, I
>> think we could use a single common type and an additional field for
>> dereferencing the out-of-band steps.  But for new general mechanisms, it
>> would be useful if the client knew from examination whether it could or
>> should use the authorization type.  If service A and service B use
>> different URIs for the same mechanism, you have the possibility of a client
>> not recognizing that it can use service B.
>>
>> Imagine for a second that someone creates a method to use an entry in a
>> block chain as an authorization mechanism; if more than one service wants
>> to use the method the 2nd and later either have to refer to the type using
>> the first's URI or making up new URIs that aren't auto

Re: [Acme] Pre-authorization approach

[Eric Rescorla]

On Fri, Aug 26, 2016 at 1:33 PM, Roland Bracewell Shoemaker <
rol...@letsencrypt.org> wrote:

> On 08/26/2016 12:25 PM, Eric Rescorla wrote:
> >
> >
> > On Fri, Aug 26, 2016 at 12:09 PM, Roland Bracewell Shoemaker
> > mailto:rol...@letsencrypt.org>> wrote:
> >
> > On 08/06/2016 10:49 AM, Eric Rescorla wrote:
> > >
> > >
> > > On Sat, Aug 6, 2016 at 10:36 AM, Jacob Hoffman-Andrews <
> j...@eff.org <mailto:j...@eff.org>
> > > <mailto:j...@eff.org <mailto:j...@eff.org>>> wrote:
> > >
> > >
> > > I also think EKR's comment that we need the ability to
> authorize domain
> > > names without immediately issuing is a solid one*. So I think
> we should
> > > take the conservative approach and roll back the
> new-application flow
> > > for now. I do think we should document wildcard validation
> before we
> > > finalize the spec, but new-application may not be the best way
> to do
> > > that.
> > >
> > > *Eric, would you mind repeating what you said for the benefit
> of the
> > > list? All we have right now are the notes and Richard's
> paraphrase.
> > >
> > >
> > > To the best of my memory, my comment was that I thought it was
> unfortunate
> > > that in order to register a domain you would have to generate a
> valid CSR
> > > and potentially actually get it issued. This is especially true if
> the
> > > key you
> > > plan to use for authorization is of a type you never intend to
> issue into an
> > > EE (e.g., you are authorizing with Ed255159 but you are planning to
> > > issue ECDSA and RSA). And it may not be possible to make these
> align
> > > if you have various restrictions due to HSMs.
> >
> > Sorry to jump into this so late but could you elaborate on the use
> case
> > your are suggesting here? I am slightly confused about in what
> > circumstances you would want to authorize a domain for issuance, but
> not
> > actually issue for it.
> >
> > In a situation where you i.e. don't know all of the names you want to
> > issue for in the future why not just wait until you do know all of
> those
> > names to create the authorizations? The same goes for the HSM
> situation
> > you describe, the key will be needed to sign the CSR at some point
> > anyway so why do the authorizations need to be created before the
> key is
> > used?
> >
> >
> > The pattern here is you would have a management box that was responsible
> for
> > the domain authorization process and for signing off on CSRs for other
> > devices
> > but was not itself intended to act as a Web server for the domain (this
> > is more
> > plausible with non-SimpleHTTPS authentication). In that case, you might
> > pre-authorize all the domains but then on-the-fly have the actual origin
> > servers
> > make their own CSRs and get them signed off on by the management box. In
> > this case, you wouldn't ever need an account key to sign the CSR.
> >
>
> I'm still unsure why this is not currently possible with the new-app flow?
>
> Assuming in your example the management box passes back a certificate
> after receiving a CSR from a origin server the only difference I can see
> is there may be increased latency as the management box has to complete
> authorizations instead of instantly getting a certificate back from the
> ACME server.
>

Who says that the origin server is even up at the time you are authorizing
the
management box.

-Ekr


>
> > -Ekr
> >
> >
> > >
> > > -Ekr
> > >
> > >
> > >
> > > ___
> > > 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
> > <https://www.ietf.org/mailman/listinfo/acme>
> >
> >
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Pre-authorization approach

[Eric Rescorla]

On Fri, Aug 26, 2016 at 12:09 PM, Roland Bracewell Shoemaker <
rol...@letsencrypt.org> wrote:

> On 08/06/2016 10:49 AM, Eric Rescorla wrote:
> >
> >
> > On Sat, Aug 6, 2016 at 10:36 AM, Jacob Hoffman-Andrews  > <mailto:j...@eff.org>> wrote:
> >
> >
> > I also think EKR's comment that we need the ability to authorize
> domain
> > names without immediately issuing is a solid one*. So I think we
> should
> > take the conservative approach and roll back the new-application flow
> > for now. I do think we should document wildcard validation before we
> > finalize the spec, but new-application may not be the best way to do
> > that.
> >
> > *Eric, would you mind repeating what you said for the benefit of the
> > list? All we have right now are the notes and Richard's paraphrase.
> >
> >
> > To the best of my memory, my comment was that I thought it was
> unfortunate
> > that in order to register a domain you would have to generate a valid CSR
> > and potentially actually get it issued. This is especially true if the
> > key you
> > plan to use for authorization is of a type you never intend to issue
> into an
> > EE (e.g., you are authorizing with Ed255159 but you are planning to
> > issue ECDSA and RSA). And it may not be possible to make these align
> > if you have various restrictions due to HSMs.
>
> Sorry to jump into this so late but could you elaborate on the use case
> your are suggesting here? I am slightly confused about in what
> circumstances you would want to authorize a domain for issuance, but not
> actually issue for it.
>
> In a situation where you i.e. don't know all of the names you want to
> issue for in the future why not just wait until you do know all of those
> names to create the authorizations? The same goes for the HSM situation
> you describe, the key will be needed to sign the CSR at some point
> anyway so why do the authorizations need to be created before the key is
> used?
>

The pattern here is you would have a management box that was responsible for
the domain authorization process and for signing off on CSRs for other
devices
but was not itself intended to act as a Web server for the domain (this is
more
plausible with non-SimpleHTTPS authentication). In that case, you might
pre-authorize all the domains but then on-the-fly have the actual origin
servers
make their own CSRs and get them signed off on by the management box. In
this case, you wouldn't ever need an account key to sign the CSR.

-Ekr


> >
> > -Ekr
> >
> >
> >
> > ___
> > 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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Terms of service agreement changes

[Eric Rescorla]

On Wed, Aug 17, 2016 at 11:27 AM, Jacob Hoffman-Andrews 
wrote:

> On 08/17/2016 10:47 AM, Eric Rescorla wrote:
> > I don't think the current text is very clear, so I think if we're going
> > to not change
> > that we should keep the text as-is while we discuss what it ought to say.
>
> In other words, don't change the protocol part until we have the legal /
> UI part nailed down?


No, I'm talking solely about this sentence.

-Ekr


> If so, I'd like to see a proposal on the latter. I
> don't have an opinion either way, and I'm not a lawyer.
>
> For reference, here is the relevant section from the BRs:
>
> > The CA SHALL implement a process to ensure that each Subscriber or
> Terms of Use Agreement is legally enforceable against the Applicant. In
> either case, the Agreement MUST apply to the Certificate to be issued
> pursuant to the certificate request. The CA MAY use an electronic or
> "click-through" Agreement provided that the CA has determined that such
> agreements are legally enforceable. A separate Agreement MAY be used for
> each certificate request, or a single Agreement MAY be used to cover
> multiple future certificate requests and the resulting Certificates, so
> long as each Certificate that the CA issues to the Applicant is clearly
> covered by that Subscriber or Terms of Use Agreement.
>
> I'm pretty skeptical that we will come up with meaningful language in an
> RFC to meet any particular legal requirements, which is why I favor not
> trying to over-specify things here.
>
> ___
> 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] Terms of service agreement changes

[Eric Rescorla]

On Wed, Aug 17, 2016 at 10:18 AM, Jacob Hoffman-Andrews 
wrote:

> On 08/17/2016 10:11 AM, Eric Rescorla wrote:
> > Can you tell me more about what you find confusing? Is it just the
> MUST?
> >
> > The whole text.
> > If so, I'm happy to change it to a SHOULD, with the understanding
> that
> > the server is likely to reject such requests.
> >
> >
> > Again, I'd like to step back from the text a bit. It's not a matter of
> > MUST versus SHOULD
> > but about what behavior on the part of the client would be needed to be
> > compliant. For
> > instance, can it send this PDU without ever prompting the user for
> consent.
>
> Can you propose an alternate text? My intent is not to alter the current
> state of things with regards to user consent, but merely to simplify the
> protocol. What is the text that, for you, would indicate the exact same
> things about user consent as the current draft?


I don't think the current text is very clear, so I think if we're going to
not change
that we should keep the text as-is while we discuss what it ought to say.

-Ekr

___
> 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] Terms of service agreement changes

[Eric Rescorla]

On Wed, Aug 17, 2016 at 9:22 AM, Jacob Hoffman-Andrews  wrote:

> On 08/17/2016 08:45 AM, Eric Rescorla wrote:
> > This still just seems confusing, especially with the MUST.
> >
> > Without worrying about text, what behavior are you attempting to require
> the
> > client to engage in?
>
> Can you tell me more about what you find confusing? Is it just the MUST?
>

The whole text.



> If so, I'm happy to change it to a SHOULD, with the understanding that
> the server is likely to reject such requests.


Again, I'd like to step back from the text a bit. It's not a matter of MUST
versus SHOULD
but about what behavior on the part of the client would be needed to be
compliant. For
instance, can it send this PDU without ever prompting the user for consent.

-Ekr



___
> 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] Terms of service agreement changes

[Eric Rescorla]

On Wed, Aug 17, 2016 at 8:18 AM, Jacob Hoffman-Andrews  wrote:

> On 08/16/2016 06:38 PM, Eric Rescorla wrote:
> > This text seems like an attempt to triangulate between what's the
> > protocol and some notion of user consent (which wasn't really present
> > in the original version). If I were to implement this code, I might
> > well just do:
>
> Are you talking about "client indicates its agreement" vs "client
> indicates its operator's agreement?" I wasn't trying to change the
> meaning here, just fixing what looked like a grammar semantics error.
> But I'm not attached to the fix. I just pushed a change back to:
>
> > If the server provides a terms-of-service URL in the directory, the
> client MUST
> > indicate its agreement to the terms at that URL by including the
>
> Look good now?
>

This still just seems confusing, especially with the MUST.

Without worrying about text, what behavior are you attempting to require the
client to engage in?

-Ekr


> ___
> 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] Terms of service agreement changes

[Eric Rescorla]

Hmm...

  If the server provides a terms-of-service URL in the directory, the
  client MUST indicate its operator's agreement to the terms at that URL
  by including the "terms-of-service": "agreed" field in the
  new-registration body.

This text seems like an attempt to triangulate between what's the
protocol and some notion of user consent (which wasn't really present
in the original version). If I were to implement this code, I might
well just do:

  if (tos_url) {
msg['terms-of-service'] = 'agreed';
  }

This "indicates" the operator's agreement, I suppose, but it doesn't
actually reflect having obtained it. If the semantic you want is
"client MUST ask the user" then the text should say that, but it seems
like a sensible client would probably just ask the user "shall I
always answer yes to this" at install time, so it's not clear to me
what is being bought here. In any case, this text seems like it makes
things less clear.

-Ekr



On Tue, Aug 16, 2016 at 6:25 PM, Jacob Hoffman-Andrews  wrote:

> Any further objections to this?
>
> https://github.com/ietf-wg-acme/acme/pull/167/files
>
> On 08/09/2016 12:50 PM, Jacob Hoffman-Andrews wrote:
> > On 08/09/2016 12:42 PM, Ron wrote:
> >>>  - If the CA uses legal auto-update language (most common case by far),
> >>> nothing else is required.
> >>
> >> I think in this case we should specify that the CA MUST notify the user
> >> of this via the ACME protocol (ie. by changing the ToS URL or similar).
> >
> > I'm fine with saying that the directory's terms-of-service URL should
> > always be up-to-date with the latest ToS, *if* the CA is using ACME for
> > ToS agreement.
> >
> >
> > I suspect for most paid CAs, ToS agreement will already have been
> > handled out-of-band, for instance when submitting payment information.
> >
> > ___
> > 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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Pre-authorization approach

[Eric Rescorla]

On Sat, Aug 6, 2016 at 10:36 AM, Jacob Hoffman-Andrews  wrote:
>
>
> I also think EKR's comment that we need the ability to authorize domain
> names without immediately issuing is a solid one*. So I think we should
> take the conservative approach and roll back the new-application flow
> for now. I do think we should document wildcard validation before we
> finalize the spec, but new-application may not be the best way to do that.
>
> *Eric, would you mind repeating what you said for the benefit of the
> list? All we have right now are the notes and Richard's paraphrase.


To the best of my memory, my comment was that I thought it was unfortunate
that in order to register a domain you would have to generate a valid CSR
and potentially actually get it issued. This is especially true if the key
you
plan to use for authorization is of a type you never intend to issue into an
EE (e.g., you are authorizing with Ed255159 but you are planning to
issue ECDSA and RSA). And it may not be possible to make these align
if you have various restrictions due to HSMs.

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

Re: [Acme] Minutes and verifying some decisions

[Eric Rescorla]

On Thu, Jul 28, 2016 at 11:03 PM, Richard Barnes  wrote:

>
>
> On Thu, Jul 28, 2016 at 4:24 PM, Salz, Rich  wrote:
>
>> I’ve posted the minutes here:
>> https://www.ietf.org/proceedings/96/minutes/minutes-96-acme
>>
>>
>>
>> Please review them.
>>
>>
>>
>> At the meeting, we came to consensus on several items, summarized here:
>>
>> * support both old and new 'applications' flow
>>
>> * Add version into protected payload
>>
>> * For issue 157, decided to return 302
>>
>> * drop Challenge; if we need OOB Challenge, we can add it back later.
>>
>> * verify sig_new(M,sig_old(M)) – Richard will be bringing this up to the
>> list, shortkly
>>
>> *  For 156, keep nonces
>>
>
> I seem to recall also agreeing to close #156, since nonces are not a
> scarce resource for servers, but I don't see this reflected in the
> minutes.  Any objections to that?
>

This is my understanding of the discussion in Berlin as well

-Ekr


>
>
>>
>>
>> Here’s the summary of action items:
>>
>> * Russ to draft a paragraph or couple sentences on replacement key
>> operational considerations (Richard will coordinate with Russ)
>>
>> * Request to the mailing list "hey, if you have a post-v1-WGLC, tell us
>> or this may not exist further!"
>>
>>
>>
>> That last item deserves some more explanation. We expect to enter WG last
>> call before IETF-97 in Seoul in November.  If there are items you think we
>> should work on after that, please bring them up here once we enter WGLC;
>> which is to say around September.  We might need to re-charter, or we might
>> want to just stay together to handle errata and IETF last call, or we might
>> want to say say we’re done and disband.
>>
>>
>>
>> Thanks!
>>
>> --
>>
>> Senior Architect, Akamai Technologies
>>
>> IM: richs...@jabber.at Twitter: RichSalz
>>
>>
>>
>> ___
>> 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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Pre-authorization approach

[Eric Rescorla]

On Tue, Jul 26, 2016 at 11:29 PM, Andrew Ayer  wrote:

> On Tue, 26 Jul 2016 23:03:18 +0200
> Richard Barnes  wrote:
>
> > Given those trade-offs, I wonder if some sort of intermediate approach
> > would be better.  The best thing that's come to me so far is to fork
> > the application process:
> >
> > - Add an "identifiers" field to the application object
> > - Each application MUST have exactly one of "csr" and "identifiers"
> > - If "csr" is present, then do what's in the draft now
> > - If "identifiers" is present, then do the same dance, but don't
> > issue the certificate
> >
> > Does that sound sane to folks?  It still seems slightly gross to me,
> > because of the switching based on the presence of fields.  Anyone have
> > better ideas?
>
> This seems sane, and better than option 1.  The switching is gross, but
> perhaps it can be made less gross with this logic:
>
> - "identifiers" MUST be present.
> - "csr" MAY be present.
> - If "csr" is present, its identifiers MUST match "identifiers".
> - A certificate will only be issued if "csr" is present.
>

Yes, this seems basically sound...

-Ekr


> Regards,
> Andrew
>
> ___
> 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

[Eric Rescorla]

On Sun, Jul 24, 2016 at 12:52 PM, Chris Drake  wrote:

> Hi Rich,
>
> > If the certificate expires, the browsers will ignore it.
>
> Yes, exactly, that is my point.  Certificate expiry is a near-useless
> mechanism for CDN revocation.
>

By "Ignore", I believe Rich meant "Reject".

-Ekr


> Kind Regards,
> Chris Drake
>
>
> Sunday, July 24, 2016, 11:26:45 AM, you wrote:
>
> >> What happens to your content *after* you've changed your CDN is *not* a
> problem you can fix with certificates.
>
> SR> Gee, I thought I showed otherwise.
>
> SR> If the certificate expires, the browsers will ignore it.
>
> SR> Ok?
>
>
>
>
> ___
> 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] Preconditions

[Eric Rescorla]

On Wed, Jul 6, 2016 at 8:01 AM, Richard Barnes  wrote:

> In preparation for the impending draft deadline, I'm trying to finalize
> close this out.  It seems like there's some positive reaction to the
> "revise the flow" idea, so I wanted to make a concrete proposal:
>
> 1. Add a section specifying the order of operations for the client:
>   - Register if you haven't done so before
>   - Send a new-cert request
>   - Get back preconditions; satisfy them
>   - Retry the new-cert request
>

I have the same concerns about this that I had in B-A. This seems to put
the client in a position of having to continuously fulfill new requirements
without any guarantee that it will ever lead to success. That seems bad.

-Ekr


> 2. Remove the new-authz URL
>
> Obviously (1) could make for some slightly complicated state management on
> the CA side in some cases, if the CA needs to carry any state between the
> first new-cert request and the second.  But it seems like this can be
> managed, e.g., by carrying state in the authz URLs or the authorizations
> themselves.  And it is technically possible to do it entirely statelessly.
>
> Removing the new-authz URL isn't strictly necessary.  You could leave it
> there as an optional service ("if new-cert in directory {...}"), but
> removing it seems more in the spirit of Langley's "have one joint and keep
> it well oiled" principle.  And while it's a hard breaking change, CAs can
> migrate gradually by leaving it on for a while.
>
> Obviously, the deadline is coming up quickly, so it would be great to get
> feedback today-ish.  It's not critical that we get all the comments now; we
> can discuss between now and the meeting.  This is just a non-trivial bit of
> work, so I wanted to sanity check before I embarked on it.
>
> Thanks,
> --Richard
>
>
>
> On Fri, May 6, 2016 at 3:19 PM, Richard Barnes  wrote:
>
>> Hey all,
>>
>> Just posted a PR with a sketch of the "precondition" idea that we
>> discussed at the F2F in Buenos Aires:
>>
>> https://github.com/ietf-wg-acme/acme/pull/124
>>
>> This change seems pretty simple, and I think it lets us hit a few pain
>> points:
>>
>> * Wildcards: Just send the CSR in and let the CA tell you what to validate
>>
>> * Payment: Specify an "out-of-band" precondition
>>
>> * CA issuance flows: If the CA won't tell you how to authorize until you
>> send in a CSR, this now lets the ACME server lead the client to do
>> authorization after the new-cert request comes in.
>>
>> We may need a little more machinery here, e.g., to be able to have the
>> new-authz endpoint say "that's not going to work directly, just request the
>> cert".  We may even want to just revise the flow, so that instead of
>> reg-authz-cert, the default order is reg-cert-authz-cert.
>>
>> But I thought I'd go ahead and send this first pass out for feedback.
>>
>> What do people think?
>>
>> Thanks,
>> --Richard
>>
>
>
> ___
> 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] Proposal for http challenge: Lookup SRV records before A/AAAA records

[Eric Rescorla]

On Tue, Feb 9, 2016 at 10:37 PM, Michael Wyraz  wrote:

> Hi,
>
> as discussed before, acme/http-01 is difficult to implement if the
> domain being validated does not resolve to the IP address of the machine
> where the client runs on.
>
> Common cases are:
> - multiple physical servers behind a tcp balancer (A-Record resolves to
> the load balancer, not to the server where the acme client runs on).
> - geo based dns resolution (A-Record resolves to the "nearest" server
> which is not necessarily to the server where the acme client runs on)
> - A-Record resolves to a device that is not able to run the acme client
> (hardware firewall, router, load balancer)
>
> I've created a proposal for using SRV (with fallback to A/) to solve
> these issues: https://github.com/ietf-wg-acme/acme/pull/83


This doesn't seem like a great idea. ACME should largely behave the same way
that Web clients do. If you want to muck with DNS just use the DNS
challenges.

-Ekr




> As you can see, the change only affects a small part of the server side
> of the protocol and should have minimal impact to implementations.
>
> Let me know what you think about it.
>
> Kind regards,
> Michael.
>
>
>
> ___
> 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] Server on >= 1024 port

[Eric Rescorla]

On Wed, Dec 2, 2015 at 4:31 PM, James Cloos  wrote:

> > "RB" == Richard Barnes  writes:
>
> JC>> What CAs do any kind of challenge over anything other than smtp?
>
> RB> Let's Encrypt and WoSign spring immediately to mind.  They both do
> RB> web-based validation.
>
> RB> SSLMate also supports HTTP-based validation, and their certs are
> RB> issued by real CAs.
>
> Let's Encrypt is still a future CA, not a current one.
>

In what way?

-Ekr


> [Uttered with the hope that no-one misreads it as in any way negative
> or criticizing.]
>
> But given the others
>
> -JimC
> --
> James Cloos  OpenPGP: 0x997A9F17ED7DAEA6
>
> ___
> 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] Server on >= 1024 port

[Eric Rescorla]

On Wed, Nov 25, 2015 at 9:14 AM, moparisthebest 
wrote:

> Hello all,
>
> On 11/25/2015 05:13 AM, Paul Millar wrote:
> > I was wondering whether people have considered services running on
> > a port other than port 443; in particular, ports greater than
> > 1024.
>
> I'm also somewhat concerned about this, I've read statements like this
> when talking about port 443:
>
> > ACME server needs some sort of assurance that the client controls
> the server.
>
> But I don't really know why that is or should be the case at all?
> Certs aren't really issued to the machine, but rather to any service
> on any port.  There are countless services that run over TLS, IRC
> generally on 6697/7000/, XMPP on 5223, imaps, smtps, pops etc etc etc.
>
> Why shouldn't the client simply be able to tell the ACME server what
> port to test, and the ACME server assume if the client has access to
> ANY port on the server then it should be able to host ANY TLS service
> on that server?
>
>
Because this doesn't match operational reality on a number of shared
hosting systems.

-Ekr



> moparisthebest
>
> ___
> 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] New issue: Clarify how to handle bad requests

[Eric Rescorla]

On Sat, Nov 21, 2015 at 2:36 PM, Yoav Nir  wrote:

>
> > On 21 Nov 2015, at 8:02 PM, Salz, Rich  wrote:
> >
> > Please see https://github.com/ietf-wg-acme/acme/issues/47 for
> background, but discuss it here on the mailing list.
>
> The A in ACME stands for automated, and the protocol we are chartered to
> develop is designed to allow getting and maintaining a certificate for a
> domain that I own without being exposed to the intricacies of PKI and
> without manual intervention. If I own the domain “yoavnir.com” [1], I
> should be able to use a piece of software to get and regularly replace a
> certificate for yoavnir.com [2] without ever seeing any DER [3].
>
> As soon as an ACME server returns an error, the automation goes out the
> window, so we should recommend to minimize those cases as much as possible.
> Returning a good human-readable message is somewhat helpful, but mostly for
> the developer of the ACME client to use in debugging. The error message
> will usually be useless for the end-user - the domain owner.
>
> Going through your examples, of course it makes sense to issue a
> certificate with a validity period that is the minimum of the policy
> validity period and the requested validity period. We cannot expect the
> ACME client to know that “Let’s Encrypt” provides certificate for up to 90
> days, while some other CA provides them for a year. So it makes sense for a
> client to always request a long period (a year? 10 years? 1000 years? Why
> not?)
>

There are certainly cases where that's reasonable, but there are also cases
where it's attractive to the server to have certs with short lifetimes. One
example
would be if (as has been discussed elsewhere) browsers skip revocation
checks for short-lived certs.

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

Re: [Acme] New draft and DANGER

[Eric Rescorla]

This seems OK to me.

-Ekr


On Fri, Oct 2, 2015 at 2:00 PM, Richard Barnes  wrote:

> How about something like this:
>
> Authorized key object is TOKEN.FINGERPRINT, where:
> * TOKEN is the token in the challenge
> * FINGERPRINT is the JWK thumbprint of the account key (per the relevant
> JOSE spec)
>
> Same processing, except neither side has to send the object.  (Might still
> have the client echo the token.)
>
> Jacob, that gets you no base64(JSON), and EKR, that gets you determinacy.
>
> Copasetic?
>
> --Richard
>
>
>
> On Friday, October 2, 2015, Eric Rescorla  wrote:
>
>> I'm fine with having the client generate the object, but I think I'd be
>> more
>> comfortable if the data that the client had to provision for the challenge
>> was deterministic, less for cryptographic reasons but simply to make it
>> easier to reason about the protocol properties.
>>
>> Maybe this is a case for a non-JSON encoding.
>>
>> -Ekr
>>
>>
>> On Thu, Oct 1, 2015 at 7:04 PM, Andrew Ayer  wrote:
>>
>>> On Wed, 30 Sep 2015 21:48:32 -0700
>>> Richard Barnes  wrote:
>>>
>>> > The authorized key object is JSON, which means that the number of
>>> > serializations for it is bounded only be the size of the object the
>>> > server will accept.  If a malicious client can generate an authorized
>>> > key object that collides with a legitimate one (a second preimage),
>>> > then he can authorize his own key.  Having the server generate the
>>> > object puts all of the entropy that goes into the digest under the
>>> > control of the server.
>>> > [...]
>>> > In other words, there's a trade-off here between a little more surety
>>> > in the crypto and a little more protection against the CDN.  Given
>>> > that ambiguity about crypto bit us last time, I opted for the former.
>>>
>>> Well... previously, the protocol was relying on a non-existent property
>>> of digital signatures.  With a client-constructed authorized
>>> key object, it would be relying on the second-preimage resistance of
>>> SHA-256, which is a pretty safe bet, to put it mildly.  (Also, if I
>>> were an attacker with a second-preimage attack against SHA-256, I
>>> wouldn't bother attacking a CA - I'd just mint my own certs ;-)
>>>
>>> > Would it help to clarify that the CA MUST verify the token before
>>> > accepting the response, and the client MUST NOT provision the
>>> > validation until after the response is accepted?
>>>
>>> It would help in that the client would have to make two mistakes
>>> instead of just one.  Nevertheless, if the choice is between counting
>>> on client implementers to not make mistakes and counting on SHA-256 to
>>> have second-preimage resistance, I think the choice is clear.
>>>
>>> -- Andrew
>>>
>>> ___
>>> 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] New draft and DANGER

[Eric Rescorla]

I'm fine with having the client generate the object, but I think I'd be more
comfortable if the data that the client had to provision for the challenge
was deterministic, less for cryptographic reasons but simply to make it
easier to reason about the protocol properties.

Maybe this is a case for a non-JSON encoding.

-Ekr


On Thu, Oct 1, 2015 at 7:04 PM, Andrew Ayer  wrote:

> On Wed, 30 Sep 2015 21:48:32 -0700
> Richard Barnes  wrote:
>
> > The authorized key object is JSON, which means that the number of
> > serializations for it is bounded only be the size of the object the
> > server will accept.  If a malicious client can generate an authorized
> > key object that collides with a legitimate one (a second preimage),
> > then he can authorize his own key.  Having the server generate the
> > object puts all of the entropy that goes into the digest under the
> > control of the server.
> > [...]
> > In other words, there's a trade-off here between a little more surety
> > in the crypto and a little more protection against the CDN.  Given
> > that ambiguity about crypto bit us last time, I opted for the former.
>
> Well... previously, the protocol was relying on a non-existent property
> of digital signatures.  With a client-constructed authorized
> key object, it would be relying on the second-preimage resistance of
> SHA-256, which is a pretty safe bet, to put it mildly.  (Also, if I
> were an attacker with a second-preimage attack against SHA-256, I
> wouldn't bother attacking a CA - I'd just mint my own certs ;-)
>
> > Would it help to clarify that the CA MUST verify the token before
> > accepting the response, and the client MUST NOT provision the
> > validation until after the response is accepted?
>
> It would help in that the client would have to make two mistakes
> instead of just one.  Nevertheless, if the choice is between counting
> on client implementers to not make mistakes and counting on SHA-256 to
> have second-preimage resistance, I think the choice is clear.
>
> -- Andrew
>
> ___
> 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] WIP Tamarin Models for ACME

[Eric Rescorla]

Hi folks,

I spent some time over the past few weeks using the Tamarin theorem prover
[0]
to put together some protocol models for ACME. These are very preliminary
(since I've never really done a Tamarin model before) but they do
illustrate some
relevant security features. In particular, the acmev1 model allows you to
reproduce the duplicate signature vulnerability and the acmev2 model
(representing Richard's PR) doesn't show that, though of course that could
be
pilot error on my part.

If you're interested, you can find the models at:
https://github.com/ekr/tamarin-dv

-Ekr



[0] https://github.com/tamarin-prover/tamarin-prover
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Proposed ACME Charter Language

[Eric Rescorla]

On Mon, Apr 20, 2015 at 9:11 AM, Russ Housley  wrote:

> Stephen:
>
> If that paragraph were removed, would you be happier with the charter?  If
> so, consider it gone.  I'm willing to assume that an attempt to replace
> things that people are using will meet with vigorous discussion.


I would suggest we do as you propose and remove this text. I think there
will
be plenty of occasion for people in the WG to argue about using existing
stuff
versus building anew.

-Ekr


>
> Russ
>
>
> On Apr 20, 2015, at 12:05 PM, Stephen Farrell wrote:
>
> >
> >
> > On 20/04/15 16:57, Russ Housley wrote:
> >> Stephen:
> >>
> >> I did not see the ACME effort as trying to throw everything out.
> >
> > If it is not used, then I don't think we're throwing it out:-)
> >
> >> Rather, throw out the parts that have been an impediment to the kind
> >> of automation proposed by ACME, but document the shortcoming.
> >
> > Sorry, I'm still not getting it. I don't see any need for ACME
> > to document why CMP etc failed or what was wrong with CMP that
> > may have caused it to fail. And the same for CMC etc. BTW by
> > "fail" here I mean: not used by the major deployed PKIs on the
> > public Internet.
> >
> > I also see no need at all to even try to re-use ASN.1 PDU
> > structures that are defined in CRMF etc.
> >
> > I do think that ACME ought learn from the past of course, and
> > am confident that there will be enough participants involved
> > who have that history for that to not be problematic.
> >
> > But I do not think ACME ought be required to re-use any ASN.1
> > PDU definitions from any previous RFCs on this topic.
> >
> > Do we agree or disagree on that last? (I'm trying to get to
> > quite specific meanings for "duplicate.")
> >
> > Cheers,
> > S.
> >
> >
> >
> >>
> >> Russ
> >>
> >> On Apr 20, 2015, at 11:43 AM, Stephen Farrell wrote:
> >>
> >>>
> >>> Hi Russ,
> >>>
> >>> This bit puzzles me a lot, other bits puzzle me a little:-)
> >>>
> >>> On 20/04/15 16:23, Russ Housley wrote:
>  The ACME WG will not duplicate work from previous IETF
>  certificate management efforts.
> >>>
> >>> If accepted, that would seem to me to nullify the entire effort.
> >>> Can you explain why I'm reading it wrong?
> >>>
> >>> ACME absolutely will duplicate work from previous IETF certificate
> >>> management efforts that have failed to get traction over the last
> >>> decade and a half. That is entirely fine IMO and needs no explicit
> >>> justification whatsoever since we have 15 years of crystal clear
> >>> non-use, outside of niche environments. (It is true that what is
> >>> now considered a niche was not so considered back then.)
> >>>
> >>> In fact I believe anyone who claims such duplication is a problem
> >>> should be the one to provide evidence for that by documenting
> >>> exactly why and at what scale.
> >>>
> >>> It is just not credible for us to pretend that CMC, CMP, or EST are
> >>> widely used for certificate management on the public Internet. If
> >>> I'm wrong there I would really love to see the evidence but absent
> >>> such, duplicating bits of functionality present in current RFCs
> >>> that are not at all widely used is what is needed for this effort
> >>> and needs to be encouraged.
> >>>
> >>> I think we really ought bottom out on this aspect before chartering
> >>> - it'd be dumb of us to charter an ACME WG that has to fight all
> >>> the CRMF battles over again, or the ASN.1 vs. whatever issues. So I
> >>> hope lots of voices chime in and say what they think.
> >>>
> >>> S.
> >>>
> >>> ___ 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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Considerations about ACME BoF

[Eric Rescorla]

On Mon, Mar 30, 2015 at 1:00 PM, Scott Rea  wrote:
>
> > On the contrary, letsencrypt could use DANE TLSA records as DV proofs
> > which would drive deployment of DANE.
> I actually think Max is making the opposite argument - that the proposal
> is "anti CA" (or maybe anti X.509) and "pro DANE" and asking for
> justification of why we want to move away from the current
> implementation base to an unproven trust model that extremely few have
> demonstrated a willingness to adopt at this point


Hmm, I'm not sure how you and Max got this out of the discussion in the
meeting, but perhaps I can clarify.

ACME has two potential interactions with DANE.

1. DANE can be used a "proof type" to allow ACME CAs to determine that
a given entity controls a given domain.

2. If an ACME CA (or any CA) issues free certificates based on DANE, then
this is a potential way to allow DANE-based trust to get wider deployment.
This isn't really a property of ACME but rather of free, automatic issuance,
regardless of the protocol.

But in neither case is ACME really about moving to the DANE trust model.

Best,
-Ekr
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme