Re: [Acme] CAA in draft-ietf-acme-client-01.txt

[Roland Shoemaker]

I think the disconnect here is between CAs and Relying Applications (i.e.
browsers) using CAA. The CA should use CAA to validate if they have
authority to issue, but the relying application must not because the CAA
records are only applicable at the time of issuance and there is no
guarantee that the current CAA records may match the records that were
present in the past (i.e. I may set my CAA record to allow "example-ca",
issue a certificate, and then set my CAA record to an empty string to
prevent issuance from anyone, the check is valid at the time of issuance,
but anyone trying to do post-issuance validation would fail since the
record has changed).

I would support removing the paragraph.

On Tue, Jul 28, 2020 at 7:57 AM Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Hello Carl,
>
> Thank you for your review and I apologize for my extremely tardy response.
>
> On Mon, May 18, 2020 at 11:41 AM Carl Mehner  wrote:
>
>> Looking at the latest draft for acme-client, I noticed that it mentions
>> CAA:
>>CAA helps as anyone verifying a certificate used for code signing can
>>verify that the CA used has been authorized to issue certificates for
>>that organization.
>>
>> However, in the CAA RFC it states:
>>Relying Applications MUST
>>NOT use CAA records as part of certificate validation.
>>
>> I propose removing the statement in acme-client about CAA that is quoted
>> above.
>>
>
> I recall having gone through this conversation before to wind up where the
> draft is now.  RFC8555 has the following:
>
>   caaIdentities (optional, array of string):  The hostnames that the
>   ACME server recognizes as referring to itself for the purposes of
>   CAA record validation as defined in [RFC6844 
> ].  Each string MUST
>   represent the same sequence of ASCII code points that the server
>   will expect to see as the "Issuer Domain Name" in a CAA issue or
>   issuewild property tag.  This allows clients to determine the
>   correct issuer domain name to use when configuring CAA records.
>
>  Section 9.7.8 has the following:
>
>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 to support its use with the ACME extensions to CAA [ACME-CAA 
> ].
>
>
> Section 11.2 has the following:
>
>An ACME-based CA must only use a resolver if it trusts the resolver
>and every component of the network route by which it is accessed.
>Therefore, it is RECOMMENDED that ACME-based CAs operate their own
>DNSSEC-validating resolvers within their trusted network and use
>these resolvers both for CAA record lookups and all record lookups in
>
>furtherance of a challenge scheme (A, , TXT, etc.).
>
> As you point out, https://tools.ietf.org/html/rfc6844, advises against
> its use.
>
> I am happy to edit to consensus.  If a change is needed, I can turn that
> around quickly.
>
> Best regards,
> Kathleen
>
> -carl mehner
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
>
> --
>
> Best regards,
> Kathleen
> ___
> 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] Onion address validation extension

[Roland Shoemaker]

On Thu, Jul 9, 2020 at 6:01 AM Ryan Sleevi  wrote:

>
>
> On Thu, Jul 9, 2020 at 8:30 AM Ilari Liusvaara 
> wrote:
>
>> On Wed, Jul 08, 2020 at 08:03:40PM +0200, Sebastian Nielsen wrote:
>> > Couldn’t it be done in the way that the ACME server creates a nonce.
>>
>> I am not sure why the client nonce is there. And I can not quickly find
>> any discussion about cryptographic reasons.
>
>
> This goes back to when it was originally introduced, and v2 addresses were
> in use. It’s about mitigating the cross-protocol attack scenario.
>
> The desire was to avoid having to introduce a full Tor implementation for
> a CA to validate. It was seen that some POP was needed, not of the TLS Key,
> but if the associated Tor HS key, in order to actually demonstrate some
> association / “ownership” of the domain.
>
> Having the whole CSR be signed meant the CSR would be replayable. So a CA
> provided nonce was added, so the CA can demonstrably prove it was fresh.
> However, if only CA data was used, then particularly with v2 addresses
> (using SHA-1), there was a concern that a malicious CA might try to
> compromise the HS security by making the CSR request a cross-protocol
> signing oracle, supplying hostile nonces. So the client random was added,
> to add entropy and otherwise mitigate this admittedly convoluted case. But
> this was all predicated on v2 just having awful cryptographic properties
> (truncated SHA-1 and 1024-bit RSA says what).
>
> Unfortunately, you’re correct for pointing out that since the OID
> allocations placed the CA attribute over the applicant attribute, the sort
> of the SET of ATTRIBUTES defeats this. Alas, this is why the CABF benefits
> from greater public participation.
>
> The original thread starts around November-2014,
> https://lists.cabforum.org/pipermail/public/2014-November/004569.html .
> It’s easy to miss, because it around the same time there were discussions
> of shortening certificate lifetimes and requiring id-kp-serverAuth in
> certificates, things the CABF is **finally** getting around to doing in 2020
>
> It could be for hash strenthening. However, that explanation is
>> problematic:
>>
>> - The signature scheme is Ed25519, which has built-in hash
>>   strengthening.
>> - For hash strenthening via applicant nonce to actually work, the
>>   CSR must have applicant nonce before CA nonce.
>>
>> However, I do not think it is impossible that it is indeed for hash
>> strengthening and these two details were just missed.
>>
>> > 2 – OR the client can choose to submit the validation result inside
>> > the final CSR. There is a object in the CSR called ”Challenge
>> > password”, which could be ”reused” for this purpose, by filling it
>> > with the result of the validation (ergo a signature by the onion
>> > private key over the nonce).
>>
>> I do not think that would work for two reasons:
>>
>> - ACME protocol is not meant to proceed to CSR sending until after all
>>   names are validated. Breaking that would cause implementation
>>   problems.
>> - The CSRs are assumed to be self-signed, which is a problem here:
>>   - The signature needs to be from Tor key for obvious reasons.
>>   - The Tor keys are Ed25519, which is not allowed in WebPKI,
>> even for subscriber certificates.
>>   - Even if the keys were allowed, using them for TLS is not
>> cryptographically kosher. However, there should be no problems in
>> this case.
>>
>>
>> For designing a cleaner mechanism to propose to CABForum, I think
>> reasonable starting point would be to model it like the ACME key-
>> change endpoint.  However, signing JOSE messages with Tor key is
>> not cryptographically kosher (just like singing CSRs with it is
>> not kosher). However, again there should be no problems in practice
>> (Tor itself never signs with this key, only derives other keys from
>> it).
>
>
> I think the odds of a change in the Forum are low here. I’ll readily
> admit, I am intentionally rather hostile to JOSE / COSE being introduced
> into the CABF, because of the consistent and persistent security failures
> these formats lead to.
>

I think we could probably do this without either the issues with JOSE JWS
or a CSR, for key rollover we require the new key to be sent along with the
signature over the old key so we utilized JWS headers for transmitting both
the signature and the new JWK. Since the onion address encodes the key
directly we already have what we need to validate a signature and all we
really need is the signature itself. A very simple solution would be to
have the client sign some strictly defined ASN.1 object (including say, the
name being validated, and some random value provided by the server) and
send that signature as the challenge response. This would create a higher
bar than using a CSR, since you wouldn't just be able to use some off the
shelf library like OpenSSL to create the challenge response, but since it's
unlikely that existing clients would be able to perform this validation
without 

Re: [Acme] Onion address validation extension

[Roland Shoemaker]

I would be extremely uncomfortable specifying a mechanism like this. It
would be a large divergence from the existing ACME specification, and would
create significant traps for implementers to fall into. Specifically this
would break assumptions in most existing implementations, principally that
an order with valid authorizations can cause an issuance without further
validation. I'm also not sure how this would gel with implementations that
implement authorization reuse. It feels like this would create numerous
opportunities for an implementer to accidentally allow issuance without
actually doing any validation at all, for seemingly little real world
benefit (presumably this would only really save one or two additional
request roundtrips).

I think this is an example of one of the problems with the existing CABF
method of using a CSR as the data/signature transport when something else
would be more appropriate. The validation mechanism and the issuance
request mechanism should be as decoupled as possible to avoid people trying
to stick bits of either in the wrong place.

On Thu, Jul 9, 2020 at 8:51 AM Sebastian Nielsen  wrote:

>
> >>ACME protocol is not meant to proceed to CSR sending until after all
>   names are validated. Breaking that would cause implementation
>   problems.
>
> Thats why there should be 2 validation types, so a client who support the
> new "skip ahead" validation type would know that it only needs to request
> onion-2 validation type, then it would immidiately skip ahead to CSR
> sending without checking if validation passed - since validation then
> occurs at CSR stage.
>
> The reason validation is required inside ACME is because ACME (usually)
> needs to contact external resources to confirm your validations, which
> incurs a delay. If you can prove the ownership of the domain inside the
> actual validation response (ergo a self-validating response that can be
> verified "offline") theres no need to use the full blown ACME
> infrastructure, then you could just submit the response inside the final
> CSR.
>
> Of course this wouldn't work for multiple domains, why the normal
> procedure with checking for validationa (onion-1) would be required.
>
> >>The CSRs are assumed to be self-signed, which is a problem here:
>
> Thats not a problem.
> What I proposed, is that you create a CSR over the normal TLS certificate
> (with its signature belongning the TLS certificate's key) BUT you put your
> onion signature (a signature of the nonce made with the onion private key)
> inside the CSR field called "CSR Challenge Password".
>
> So basically, you create a TOR signature with the TOR key, insert it in
> your final TLS CSR (as CSR Challenge Password), and then sign the TLS CSR
> with the TLS key.
>
> Meaning, that the CSR *are* self-signed, and that they CONTAIN the TOR
> signature made with the TOR private key, making the CSR being dual-use -
> both validating the onion name AND also becomes the grounds for your
> certificate generation.
>
>
> ___
> 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] Onion address validation extension

[Roland Shoemaker]

With the recent passage of SC27 at the CA/Browser Forum there are now
acceptable mechanisms for validating v3 Onion addresses for inclusion in DV
certificates. As such it would be good to extend ACME to be able to make
use of these methods. I've written a short draft that covers what is likely
to be the most interesting validation mechanism to CAs (i.e. the one that
doesn't require actually using Tor directly) and would be interested in
thoughts from the WG.

The defined ACME challenge is basically just an adapted version of the
method defined in Appendix C 2.a of version 1.6.9 of the CABF BRs. I think
in general the usage of a CSR as the transport mechanism for the nonces and
key signature are a bit burdensome, and likely to cause some confusion for
implementers (since it introduces yet another place a CSR is
transferred between the client and server, with another non-standard use).
That said I think the first priority in this document is to get out
something that works with current CABF rules. There could be value though
in defining our own validation mechanism that is a bit more
straightforward alongside the existing CABF method and if/when this
document is standardized we could lobby for it's inclusion as a blessed
CABF validation method.

Thoughts?

https://www.ietf.org/id/draft-shoemaker-acme-onion-02.html
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Revocation via ACME using pre-signed artifact

[Roland Shoemaker]

Hey Matt,

In general I think this is a good idea. It's a concept that has been
discussed in a handful of venues in the past, and would certainly be a good
thing to have.

That said I'm not _entirely_ sure that ACME is the right place to specify
it. I think tying such a mechanism too closely to ACME is, unfortunately, a
barrier to getting the method adopted elsewhere. If we wanted to say get
this mechanism adopted by the CABF as a mandated revocation mechanism for
instance I think it'd be better to define the mechanism in isolation from a
protocol so that it could be subsumed into other APIs more easily. ACME
could then build an endpoint extension that implemented this mechanism. I
guess in practice we could do this in an ACME draft by
separately specifying the mechanism and the API extension, such that the
mechanism could be implemented independently from the API, but I worry it
would end up being forever branded as 'an ACME thing' (which who knows, may
not be a terrible thing).

But yeah, I think this is something that should definitely be considered,
either in ACME or perhaps lamps? I'd be happy to help I-D-ifying any
proposal if you'd like the assistance.

Thanks,
Roland

On Thu, Jun 18, 2020 at 4:21 PM Matt Palmer  wrote:

> Hi everyone,
>
> A corner case of the ACME protocol for certificate revocation by proving
> possession of the private key is that the private key needs to be available
> to the client which is performing the revocation request.  In some cases,
> this is not possible and/or practical, leading to a situation in which
> entirely valid revocation requests cannot be processed via ACME, and need
> to
> be handled via some other mechanism.
>
> The specific use case I have in mind is for revocations for key compromise
> which are carried out by the Pwnedkeys Revokinator, which is a service I
> run
> to request revocation of certificates using keys known to the
> pwnedkeys.com
> database as being compromised.
>
> When pwnedkeys finds a compromised key which is used in an existing
> certificate, it is possible to use the key to request revocation via the
> existing ACME-provided mechanism.  However, it does happen on occasion that
> a certificate is issued for a key which was already in the pwnedkeys
> database, and that causes a problem.
>
> For security reasons, the private keys themselves are not kept online.
> Only
> a proof of compromise (a JWS and CSR whose content states clearly that the
> key is compromised) is available to the public Internet.  As a result, the
> Revokinator cannot execute an ACME revokeCert request, because it doesn't
> have access to the private key to sign the JWS.  At present, that means
> that
> the only solution I have is to e-mail the CA and request that they manually
> revoke the certificate in question, using the CSR as proof of compromise.
>
> Another use case I can think of is analogous to the PGP concept of a
> "revocation certificate".  Consider the case where, for whatever reason, an
> ordinary user of an ACME CA loses access to the private key used in a
> certificate or ACME account, and wishes to notify the CA that the key
> should
> no longer be trusted.  While it is possible to deactivate an account if you
> have the private key, you cannot do so if the keys have been abstracted and
> then destroyed -- say, in a randomware+blackmail attack, which are, sadly,
> all too common.
>
> For these reasons, I'm interested to know if the ACME WG would be willing
> to
> consider adopting a draft specifying a protocol mechanism which extended
> ACME to allow a revocation request to be submitted which did not require
> immediate access to the private key being revoked.  I don't have a document
> prepared, however I've considered the possible mechanisms extensively
> through my other work in demonstrating key compromise, and would be willing
> to put in the time to write a "pre-draft" for consideration if the WG
> expressed in-principle support for adoption.
>
> Thanks,
> - Matt
>
> ___
> 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] [Technical Errata Reported] RFC8555 (6030)

[Roland Shoemaker]

To save people some confusion, I think the reporter is referring to RFC
7231 (Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content) rather
than 7321 (Cryptographic Algorithm Implementation Requirements and Usage
Guidance).

On Wed, Mar 25, 2020 at 3:44 PM RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6030
>
> --
> Type: Technical
> Reported by: Matt Palmer 
>
> Section: 7.2
>
> Original Text
> -
> To get a fresh nonce, the client sends a HEAD request to the newNonce
> resource on the server.  The server's response MUST include a Replay-
> Nonce header field containing a fresh nonce and SHOULD have status
> code 200 (OK).  The server MUST also respond to GET requests for this
> resource, returning an empty body (while still providing a Replay-
> Nonce header) with a status code of 204 (No Content).
>
> Corrected Text
> --
> To get a fresh nonce, the client sends a HEAD request to the newNonce
> resource on the server.  The server's response MUST include a Replay-
> Nonce header field containing a fresh nonce and SHOULD have status
> code 204 (No Content).  The server MUST also respond to GET requests for
> this
> resource, returning an empty body (while still providing a Replay-
> Nonce header) with a status code of 204 (No Content).
>
> Notes
> -
> RFC7321 s4.3.2, says "The server SHOULD send the same header fields in
> response to a HEAD request as it would have sent if the request had been a
> GET".  I can't see any rationale for violating this SHOULD in the
> discussion in the GH issue which introduced the discrepancy in response
> code between GET and HEAD (https://github.com/ietf-wg-acme/acme/pull/371),
> thus (IMHO) it violates the tenets of a SHOULD, as "the full implications"
> do not appear to have "be[en] understood and carefully weighed before
> choosing a different course" (RFC2119, of course).
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8555 (draft-ietf-acme-acme-18)
> --
> Title   : Automatic Certificate Management Environment (ACME)
> Publication Date: March 2019
> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
> Category: PROPOSED STANDARD
> Source  : Automated Certificate Management Environment
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] ACME Renewal Information (ARI) API Proposal

[Roland Shoemaker]

Hey all,

At Let's Encrypt we've been thinking about designing some kind of renewal
information API as an extension to ACME for a while now. Recent events have
brought this back to the forefronts of our minds. Below I've attached a
proposal I've written up detailing our proposal. I'd really like to get
input on this proposal, especially from those working on ACME clients as
this work mostly represents thoughts from ACME server developers, and as
such may not accurately capture issues faced by clients.

If the working group is interested in this as a work product I'll spend
some time developing an ID based on this outline.

Thanks!
Roland



This proposal aims to address two issues that affect both ACME and the
wider web PKI.

The first of these issues is how a CA should inform subscribers of a CA, or
third-party, initiated certificate revocation event. In most cases this is
done via email, or other out-of-band notification channels, which may be
appropriate for CAs that rely on manual processes but seems clunky for ACME
based CAs which heavily rely on automation. For automated ACME clients the
probability that a user will act upon a revocation notice (or even receive
one if they do not provide an account contact) is lower than manually
maintained certificates, leading to the possibility of serving a revoked
certificate until their next renewal window. In cases where the CA has a
buffer before performing the revocation, being able to inform the client of
this impending event would allow for seamless renewal before the revocation
took place, and in the case where the revocation has already taken place
this would help to significantly reduce the impact to the subscriber.

The second issue is how ACME clients should determine when to renew a
regular non-revoked certificate. Most clients take one of two routes. They
are either manually configured to renew at a specific interval (i.e. via
`cron` or similar) or parse the issued certificate to determine the
expiration date and choose some date preceding it to attempt renewal. While
the latter option is better than the former, each can cause issues for both
the client and the issuing CA. The first option causes significant barriers
for the issuing CA changing certificate lifetimes, as the static renewal
window makes assumptions about that lifetime that must be manually updated.
Both options can also cause load clustering for the issuing CA. Being able
to indicate to the client a period in which the issuing CA suggests renewal
would allow dynamic changes to the certificate lifetime and smearing of
load.

## ACME vs. OCSP

The two obvious options for transmitting renewal suggestions to the
subscriber are via an extension to the ACME protocol, or an extension to
the OCSP protocol. Each option has advantages and disadvantages.

For OCSP one of the obvious advantages is that the protocol is already
designed to carry revocation information, which some clients already poll
for. An extension could be added to OCSP responses containing 'recommended
renewal' windows and/or indicators of impending revocation. Using OCSP also
has the advantage of existing serving and caching infrastructure.

The disadvantages of using OCSP mainly revolve around usage of the protocol
by relying parties. In order to avoid intolerance for new OCSP extensions
we would likely want to require clients to indicate that they want this
information, via either an OCSP request extension or an HTTP header, which
could increase caching requirements for the issuing CA and possibly require
changes to their existing caching infrastructure.

For ACME the most obvious advantage is that every ACME client already
understands the protocol, and should have a relatively easy path to being
extended to understand a new API endpoint. Using ACME also allows a more
descriptive, extensible API, rather than requiring us to stuff more
information into a strictly defined ASN.1 extension. Using ACME would allow
for requesting information on multiple certificates in a single request,
which while technically possible via OCSP is in reality rarely supported.

The disadvantages of using ACME mainly revolve around increased load on the
ACME API for the issuing CA. ACME currently has no endpoints that are
designed to be routinely polled, adding one could introduce a significant
load vector which infrastructure has not been designed for. Another
disadvantage is that if the API was authenticated it wouldn't be possible
to viably cache the renewal information at a CDN layer.

On balance it seems like ACME is the better choice for this API.

## Push vs. Pull

The CA could either push information to ACME clients, for instance via
webhook, or it could rely on clients polling for information.

The push method is challenging because many ACME clients run behind
firewalls or don’t have full access to provide external-facing services.
For instance, an ACME client might only have the ability to provision files
under 

Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-07.txt

[Roland Shoemaker]

Hey all,

This revision addresses the comments made in the ARTART, GENART, and SECDIR 
reviews as well as comments made by Benjamin Kaduk, Adam Roach, and Barry Leiba.

Thanks to all for their thorough reviews.
Roland

> On Oct 1, 2019, at 1:35 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Automated Certificate Management Environment 
> WG of the IETF.
> 
>Title   : ACME TLS ALPN Challenge Extension
>Author  : Roland Bracewell Shoemaker
>   Filename: draft-ietf-acme-tls-alpn-07.txt
>   Pages   : 10
>   Date: 2019-10-01
> 
> Abstract:
>   This document specifies a new challenge for the Automated Certificate
>   Management Environment (ACME) protocol that allows for domain control
>   validation using TLS.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-tls-alpn-07
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-tls-alpn-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-tls-alpn-07
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] Artart last call review of draft-ietf-acme-tls-alpn-06

[Roland Shoemaker]

Hey Martin,

Thanks for the thorough review, I agree with all of the suggestions and will be 
incorporating the changes into the next revision. Following up on one point 
about Section 7, I believe you may actually be thinking about another issue we 
had with the http-01 ACME challenge. The issue here was as described, if the 
ACME server was using HTTPS to validate a http-01 challenge and the expected 
domain name didn’t have a proper virtual host configuration many servers would 
redirect the request to a ‘default’ handler. This is called out in RFC 8555 
Section 8.3.

Thanks,
Roland

> On Sep 17, 2019, at 12:40 AM, Martin Thomson via Datatracker 
>  wrote:
> 
> Reviewer: Martin Thomson
> Review result: Ready with Nits
> 
> This is a clear description of a simple protocol that addresses a well-defined
> problem.  I didn't find any real issues, though I have some suggestions that
> might improve the document a little.  My view is that publication without 
> these
> would still produce a useful RFC.
> 
> Suggestions:
> 
> The document should probably talk about minimum TLS versions and expected
> algorithms.  I think that it would be enough to say TLS 1.2 minimum with the
> mandatory cipher suites from that spec.  You might also want to require
> certificates with a PKCS#1v1.5 RSASSA key (as much as those are terrible), but
> to permit use and negotiation of other alternatives.  If your CA supports
> ECDSA, I see no reason not to prepare an ECDSA certificate on that basis, but
> that would be based on extra-textual knowledge, it's no guarantee of
> interoperability.
> 
> Section 4
> I have two suggestions here for making the properties you rely on with the
> protocol clearer to readers.
> 
> You should explicitly say that the "acme-tls/1" protocol as negotiated here
> does not carry application data, it only requires that the server provide
> certificate-based authentication.  AND that the certificate-based
> authentication provided uses an alternative method than that described in RFC
> 5280, even though it uses X.509 certificates.  Both of these are already
> implicit in the text here, but I think that it would help to be very clear
> about these as they are a little surprising ways to use TLS.
> 
> You might also want to explicitly point out that though the protocol does not
> depend on the server providing a valid signature, or even that it successfully
> complete the TLS handshake, these are both required by the protocol and a
> validator MAY withhold authorization if the TLS handshake does not complete
> successfully.  (This is implied in Step 4, but not explained.)
> 
> Nits:
> 
> Section 1
> The history lesson in the appendix is useful.  It helps to articulate why the
> design is this way.  However, I don't think that you need to spend a third of
> the introduction on a reference to that historical information.  I'd cut that
> paragraph entirely.
> 
> Section 3
> https://www.quickanddirtytips.com/sites/default/files/styles/insert_large/public/images/937/use-utilize-pin.png?itok=Bt7A6RQq
> 
> Step 3: s/AMCE/ACME; this sentence is two with a comma-splice
> 
> Section 4
> This is taste only, but I find the extra version decoration on these
> identifiers unnecessary.  Decorate v2 if you are unfortunate enough to need 
> one.
> 
> Section 5
> 
> The parallel list construction in this sentence is a little awkward:
> 
>   "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."
> 
> The first part of this sentence is fine, but the second part "or Host B to be
> served by User A" might be clearer if it said "or a TLS connection with a
> server_name extension identifying Host B to be answered by User A."  Or 
> similar.
> 
> Section 6.2
> Please don't use uppercase for an identifier when the actual protocol is
> identified using lowercase ASCII.  I know that RFC 7301 did this for HTTP/1.1,
> but that was a confusing mistake that doesn't need to be propagated.
> 
> Section 7
> This is not an appendix.  You can make appendices using `` in XML or by
> moving the section under `---back` in kramdown-rfc2629.
> 
> The implication of this text is to say that this is a replacement for an
> important part of ACME.  I would instead say that this is an iteration on an
> earlier design that used the TLS server_name extension to carry the 
> challenge. 
> And that that earlier design was shown to have some serious issues in 
> practice.
> 
> My understanding of the problem differs from what is described here though: 
> the
> problem - as I recall - was that this used high-entropy, generated values for
> the server_name extension and an HTTP or absent ALPN identifier.  These names
> might not have as strong a binding to the user that controlled the validated
> portion of that name (the suffix) as desired.  Some servers would route these
> SNI values to a "default" 

Re: [Acme] Benjamin Kaduk's Yes on draft-ietf-acme-ip-07: (with COMMENT)

[Roland Shoemaker]

Hey Benjamin,

Thanks for the review, I’ve replied to your two comments inline:

> On Sep 30, 2019, at 6:06 PM, Benjamin Kaduk via Datatracker 
>  wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-acme-ip-07: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-acme-ip/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Section 7
> 
> There's perhaps some "action at a distance" going on here, in that we
> try to apply normative requirements on unrelated things.  Perhaps it's
> safer to just say "this document does not define any usage of the
> 'dns-01' challenge to validate IP addresses.  But if we can definitively
> rule out any future use, then it doesn't really matter.

There is currently no way to use the dns-01 method as specified in 8555 for IP 
addresses. Including a MUST NOT here was mainly a belt and bracers attempt to 
prevent future implementers from attempting to come up with a novel way of 
applying the method (there was initially some work in this document that did 
try to do this, but there were enough security concerns with the method 
proposed that the work was discarded.)

> 
> Section 9
> 
> Is there anything to say about issuing certificates for
> non-publicly-routable IP addresses in terms of ensuring that the ACME
> server and client are in the same administrative domain [and enforcing
> that by network topology]?
> 

I feel like this gets into dictating a level of policy that I’m not comfortable 
with in this document, especially given the wide and varying topologies that 
exist within enterprise networks which we are unlikely to be able to properly 
document and restrict (and is likely better served by internally dictated 
policies rather than at the standards level).

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

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

[Roland Shoemaker]

Hey Éric,

Thanks for the review. To answer your two questions:

1. Assuming you are referring to the “type” field of the standard ACME 
identifier object the use of “ip” was thought to be a bit more verbose as to 
what the identifier contained vs. “address”. There could be some confusion with 
using address about what kind of address this was, especially since certain 
types of certificates (i.e. OV and EV) can contain physical mailing addresses 
etc.
2. Allowing only /32 or /128 was mainly just to allow reuse of the existing 
challenge types from RFC 8555. Adding randomized selection from larger ranges 
would be possible but would really require completely new challenge types as 
the modifications that would need to be made (and the specification of the 
randomized processes etc) would alter the existing challenges too much. There 
was also no user demand when we first started working on this for anything 
other than validating individual addresses. If we see demand in the future I 
think new challenge types would make for a nice short extension to the existing 
specification.

Thanks,
Roland

> On Sep 30, 2019, at 2:09 PM, Éric Vyncke via Datatracker  
> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-acme-ip-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-acme-ip/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Short and useful document: thank you for writing it.
> 
> No need to reply to my two questions, but, I would appreciate your answers:
> 1) why using a tag "ip" rather than "address" ?
> 2) unsure whether it is doable, but, why only allowing /32 or /128 addresses? 
> A
> server can listen to a /64 (for some specific applications), so, requesting a
> /64 via ACME would be useful (challenge could be done via a random address out
> of this /64 for example)
> 
> Regards
> 
> -éric
> 
> 

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

Re: [Acme] Warren Kumari's Discuss on draft-ietf-acme-ip-07: (with DISCUSS and COMMENT)

[Roland Shoemaker]

Hey Warren,

Thanks for the review of this document. Overall I don’t find the suggested 
scenario particularly compelling in terms of indicating any security problems 
with the suggested document. The threat model defined in 8555 indicates that 
ACME is not able to mitigate scenarios where an attacker is able to demonstrate 
control of the validation target (whether this is via ARP poisoning on a local 
network in the suggest scenario or via DNS hijacking on the wider internet). 
Beyond that I don’t think this suggested scenario is that realistic. A public 
CA is unable to issue for internal private IP addresses, if the POS was using a 
certificate from an internal CA the attack might be viable, but only if that 
internal CA implemented ACME and allowed arbitrary user registrations which 
would be policy choices outside of the scope of this document.

The second scenario you suggest is also something covered by 8555, if the 
attacker is able to fully control the network, then they can control ACME. This 
is not just the case for IP validation, if an attacker is able to hijack BGP 
routes then they are able to complete validation for both IP and DNS 
identifiers (there is currently a handful of both academic and industry work 
happening to try and mitigate these issues) and is also not just the case for 
ACME, any CA that does network based control validation, automated or not, is 
susceptible to these kinds of attacks. 

Hope that helps clarify my thinking on the topic.
Roland

> On Oct 1, 2019, at 8:25 AM, Warren Kumari via Datatracker  
> wrote:
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-acme-ip-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-acme-ip/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This is either a huge issue, or a complete non-event -- I'm not sure which -
> please help me understand / convince me I'm missing something.
> 
> Contrived, but simple example scenario: My local coffeeshop runs their Point 
> of
> Sale (POS) system on 192.0.2.10. They have a certificate for this (e.g from
> LE), and all of their credit card machines contact the POS system using
> https://192.0.2.10. I now visit the coffee shop, and using e.g ARP spoofing
> grab 192.0.2.10. I then use ACME to request and get a cert for 192.0.2.10. I
> now fire up a webserver, the credit card machines happily connect to me, I
> present a valid cert, and they send me those sweet, sweet credit card numbers.
> 
> I get that this isn't really an issue with ACME itself, but rather A: the
> existence of IP based certificates, and B: the fact that the ability to
> "control" an IP is  more easily under an attackers control than the ability to
> "control" a useful domain name. As another exmaple, I could construct 
> scenarios
> where I use BGP route hijacking to control an address remotely, without having
> to visit the victim network.
> 
> The Security Considerations section *does* say:
> "The CA may wish to perform additional checks not
>   specified in this document.  For example if the CA believes an IP
>   identifier belongs to a ISP or cloud service provider with short
>   delegation periods they may wish to impose additional restrictions on
>   certificates requested for that identifier."
> 
> Again, I understand that ACME is "just" the protocol / means to automate this,
> but it seems that this is a sufficiently dangerous thing to be doing that
> having it more automated is a bad idea. Please don't misunderstand, I really
> like ACME - it's made my life much better, but its power / convenience might 
> be
> dangerous here.
> 
> 
> --
> COMMENT:
> --
> 
> Thank you - this document is clear, understandable and readable.
> Also, thank you to Joel and Tim for their OpsDir reviews.
> 
> 

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

Re: [Acme] Alexey Melnikov's Discuss on draft-ietf-acme-ip-07: (with DISCUSS)

[Roland Shoemaker]

Thanks for the review. Good catch on the FQDN, this looks like it was just an 
error in the example. I’ll push up a revision addressing this.

> On Sep 29, 2019, at 8:38 AM, Alexey Melnikov via Datatracker 
>  wrote:
> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-acme-ip-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-acme-ip/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Thank you for this document.
> 
> I have a trivial thing I would like to discuss before recommending approval 
> of this document:
> 
> Section 3 of RFC 6066 says:
>   "HostName" contains the fully qualified DNS hostname of the server,
>   as understood by the client.  The hostname is represented as a byte
>   string using ASCII encoding without a trailing dot.
> 
> However your example shows in Section 6:
> 
>   For the "tls-alpn-01" challenge the subjectAltName extension in the
>   validation certificate MUST contain a single iPAddress that matches
>   the address being validated.  As [RFC6066] does not permit IP
>   addresses to be used in the SNI extension HostName field the server
>   MUST instead use the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596]
>   reverse mapping of the IP address as the HostName field value instead
>   of the IP address string representation itself.  For example if the
>   IP address being validated is 2001:db8::1 the SNI HostName field
>   should contain "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d
>   .0.1.0.0.2.ip6.arpa.".
> 
> I.e. there is a trailing dot after “arpa”. Is the example wrong or am I 
> missing something?
> 
> 
> 
> 

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

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

[Roland Shoemaker]

Hey Roman,

I’ve address most of the comments below and have a draft of the changes here: 
https://github.com/rolandshoemaker/acme-tls-alpn/compare/in-proc?w=1

There are a few comments I’m not sure I agree with which I’ve responded to 
inline below, if this all looks good to you I’ll push up a new numbered draft.

Thanks!

> On Jun 21, 2019, at 4:57 AM, Roman Danyliw  wrote:
> 
> Hi!
> 
> I conducted as second AD review of draft-ietf-acme-tls-apln per the AD 
> hand-off.  I have the following feedback/questions:
> 
> ** Please address the issues from AD Review #1 and update the text as 
> discussed on the ML (specifically about Section 3 and Section 6):
> https://mailarchive.ietf.org/arch/msg/acme/LQ-_rdrH5xVSxW64T7w3LONZ1RM
> 
> ** Section 3.  (My ASN.1 foo is lacking but ...)  Per the ASN.1 format of 
> acmeIdentifier, where is id-pe defined?  The descriptive text mentions an 
> "extnValue" in the "id-pe-acmeIdentifier extension" where is that defined?

Both id-pe and extnValue are defined in RFC 5280. I’ve added some clarifying 
text to the draft.

> 
> ** Section 3 and Section 3.1.  Per:
> 
> Section 3: Once the TLS handshake has been completed the connection MUST be 
> immediately closed and no further data should be exchanged.
> Vs. 
> Section 3.1: Once the handshake is completed the client MUST NOT exchange any 
> further data with the server and MUST immediately close the connection.
> 
> Why does Section 3 and 3.1 provide slightly different normative language 
> about closing the TLS connections and not exchanging data.  I don't think we 
> need both.
> 
> ** Section 4.  The Security Considerations of RFC8555 hold too.
> 
> Below is additional editorial feedback:
> 
> ** Section 3.  The list of fields, type and token, doesn't follow from the 
> introductory sentence.  Provide some transition and introduction on the 
> presence of those fields.
> 
> ** Section 3.  Cite the base64url alphabet.
> 
> ** Section 3. The purpose of the two HTTP blob isn't made clear; they aren't 
> referenced in the text; and don't have a figure number.  

This follows the challenge definition format in 8555, I agree the GET blob 
doesn’t really make sense and have removed it, but I think the POST is 
appropriate and is referenced in both the preceding and following text.

> 
> ** Section 3.  Specify that that the format is acmeIdentifier ASN.1 as:
>   [X680] ITU-T, "Information technology -- Abstract Syntax Notation
>  One (ASN.1): Specification of basic notation",
>  ITU-T Recommendation X.680, 2015.
> 
> ** Section 3.  Cite ASN.1 DER encoding as:
>[X690] ITU-T, "Information Technology -- ASN.1 encoding rules:
>  Specification of Basic Encoding Rules (BER), Canonical
>  Encoding Rules (CER) and Distinguished Encoding Rules
>  (DER)", ITU-T Recommendation X.690, 2015.
> 
> ** Section 3.  Cite "SNI extension" (RFC6066) on first use
> 
> ** Section 3.  Step 4.  Per "Verify that the ServerHello", consider 
> re-writing this sentence so it doesn't use "contains" five times.
> 
> ** Section 3.  Step 4.  Typo (missing period).
> s/Note that as ACME doesn't support Unicode identifiers all dNSNames MUST be 
> encoded using the [RFC3492] rules./Note that as ACME doesn't support Unicode 
> identifiers.  All dNSNames MUST be encoded using the [RFC3492] rules.

I don’t think splitting this sentence makes sense, both sections rely on each 
other.

> 
> ** Section 7.  Typo.  s/specication/specification/
> 
> Roman
> 
> ___
> 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] Slides for tomorrow.

[Roland Shoemaker]

I’ve been on vacation and was unaware any time had been assigned for TLS-ALPN, 
and also have no meaningful update to provide: the only movement since the last 
meeting is the most recent AD review, which doesn’t suggest any major 
structural changes.

> On Jul 21, 2019, at 8:21 PM, Yoav Nir  wrote:
> 
> It’s now past 11:00 PM and we still don’t have slides for telephony, 
> TLS-ALPN, and STAR delegation.
> 
> What’s up with that?
> 
> Rich & Yoav
> 
>> On 21 Jul 2019, at 12:19, Yoav Nir  wrote:
>> 
>> Hi, presenters.
>> 
>> The meeting is tomorrow morning: 
>> https://datatracker.ietf.org/meeting/105/materials/agenda-105-acme
>> 
>> Please send your slides by EOD today, and also tell me who will be 
>> presenting. We want to have the slides up in plenty of time and the agenda 
>> correct.
>> 
>> Thanks
>> 
>> Rich & Yoav
>> 
> 
> ___
> 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] I-D Action: draft-ietf-acme-ip-05.txt

[Roland Shoemaker]

This revision contains a few small changes that address issues brought up 
during the AD review.

> On Feb 14, 2019, at 1:02 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Automated Certificate Management Environment 
> WG of the IETF.
> 
>Title   : ACME IP Identifier Validation Extension
>Author  : Roland Bracewell Shoemaker
>   Filename: draft-ietf-acme-ip-05.txt
>   Pages   : 5
>   Date: 2019-02-14
> 
> Abstract:
>   This document specifies identifiers and challenges required to enable
>   the Automated Certificate Management Environment (ACME) to issue
>   certificates for IP addresses.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-ip/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-ip-05
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-ip-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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-ip-04

[Roland Shoemaker]

By controlling the reverse tree do you mean the actual DNS zone? If so that 
provide no leverage for an attack. The value sent in the SNI isn’t any value 
retrieved from the DNS for the reverse mapping of the address, but the reverse 
mapping itself. If the IP being validated was 1.2.3.4 then the SNI sent would 
be 4.3.2.1.in-addr.arpa. This was originally suggested when Corey Bonnell 
pointed out that 6066 disallows literal IP addresses in the SNI HostName and 
Rich Salz and Richard Barnes suggested we just use the reverse mapping instead. 
Perhaps the text could be reworked here to clarify this further?

> On Jan 26, 2019, at 6:21 AM, Eric Rescorla  wrote:
> 
> 
> 
> 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-ip-04

[Roland Shoemaker]

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.

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

Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-04.txt

[Roland Shoemaker]

+1, will do.

> On Aug 15, 2018, at 12:54 PM, Russ Housley  wrote:
> 
> Roland:
> 
> Thanks for the update.  In addition to the changes that I requested, you 
> added:
> 
>   The extnValue of the id-pe-acmeIdentifier extension is the ASN.1 DER
>   encoding of the Authorization structure.
> 
> Authorization is just an OCTET STRING.  For clarity, it might be useful to 
> say:
> 
>   The extnValue of the id-pe-acmeIdentifier extension is the ASN.1 DER
>   encoding of the Authorization structure, which contains the SHA-256
>   digest of the key authorization for the challenge.
> 
> Russ
> 
> 
>> On Aug 15, 2018, at 2:37 PM, internet-dra...@ietf.org wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Automated Certificate Management 
>> Environment WG of the IETF.
>> 
>>   Title   : ACME TLS ALPN Challenge Extension
>>   Author  : Roland Bracewell Shoemaker
>>  Filename: draft-ietf-acme-tls-alpn-04.txt
>>  Pages   : 8
>>  Date: 2018-08-15
>> 
>> Abstract:
>>  This document specifies a new challenge for the Automated Certificate
>>  Management Environment (ACME) protocol which allows for domain
>>  control validation using TLS.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-acme-tls-alpn-04
>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-tls-alpn-04
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-tls-alpn-04
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> 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-ietf-acme-tls-alpn-03

[Roland Shoemaker]

The decision to format the OID this way was an early one that I’m not 
completely attached to. That said the existing solution does still feel cleaner 
to me than doing the versioning directly under id-pe. Given it’s unlikely that 
the version with be incremented by anything other than a document from the ACME 
WG, and that doing so is likely to deprecate the existing version it seems more 
prudent to me (from a inexperienced position admittedly) for this WG to manage 
the assignments of the versioned OIDs under the id-pe-acmeIdentifier arc rather 
than have to defer to the registration to the SMI numbers registry.

With that said if there is WG consensus to move to this suggested version I’m 
happy to oblige and move forward with it.

> On Aug 14, 2018, at 12:00 PM, Russ Housley  wrote:
> 
> This document include a particular object identifier, and IANA has not 
> assigned it yet.  Please do not assume that you will get the next available 
> number.  Someone else could get there before you.
> 
> This document uses the following syntax for the certificate extension:
> 
>   id-pe-acmeIdentifier OBJECT IDENTIFIER ::=  { id-pe 31 }
> 
>   id-pe-acmeIdentifier-v1 OBJECT IDENTIFIER ::=  { id-pe-acmeIdentifier 1 
> }
> 
>   acmeValidation-v1 ::= OCTET STRING (SIZE (32))
> 
> I see no reason for the middle value.  This would cause the creation os an 
> additional table for IANA to maintain.
> 
> Instead, I suggest using  { id-pe 31 } directly for the certificate 
> extension.  If a v2 is needed in the future, another number from this same 
> object identifier arc can be assigned for it.
> 
> Russ
> (The IANA Expert for the SMI Security for PKIX Certificate Extension registry)
> ___
> 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] I-D Action: draft-ietf-acme-tls-alpn-02.txt

[Roland Shoemaker]

Yup, thanks for spotting this.

> On Aug 13, 2018, at 10:36 AM, Ilari Liusvaara  
> wrote:
> 
> On Mon, Aug 13, 2018 at 10:23:44AM -0700, internet-dra...@ietf.org wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Automated Certificate Management 
>> Environment WG of the IETF.
>> 
>>Title   : ACME TLS ALPN Challenge Extension
>>  Filename: draft-ietf-acme-tls-alpn-02.txt
> 
> In section 5.1, should the:
> 
>  +-+--++
>  | Decimal | Description  | References |
>  +-+--++
>  | 30  | id-pe-acmeIdentifier | RFC    |
>  +-+--++
> 
> be:
> 
>  +-+--++
>  | Decimal | Description  | References |
>  +-+--++
>  | 31  | id-pe-acmeIdentifier | RFC    |
>  +-+--++
> 
> ?
> 
> Given that in section 3, id-pe 30 was changed to id-pe 31.
> 
> 
> -Ilari
> 
> ___
> 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] WGLC comments: draft-ietf-acme-tls-alpn-01 (Re: Confirming consensus)

[Roland Shoemaker]

Thanks for taking a look. I’ve opened 
https://github.com/rolandshoemaker/acme-tls-alpn/pull/6/files to address most 
of these comments.

For (4) the plan is to simply version it as suggested, that’s why we went with 
a two part OID with the base and then a versioned extension. If we need to 
rotate to a new algorithm we can simply increment that and define whatever new 
algorithm we want in another document.

For (5) I agree with Martin, the input isn’t being duplicated across two 
different PRFs so there shouldn’t really be a problem here.

Once these changes are merged I’ll send an email to Russ Housley to get the OID 
registered, I could swear I already did this but apparently not.

> On Aug 8, 2018, at 7:31 PM, Sean Turner  wrote:
> 
> Couple of comments:
> 
> 0) s2: Use the update text:
> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
> "MAY", and "OPTIONAL" in this document are to be interpreted as
> described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
> appear in all capitals, as shown here.
> 
> 1) s3: For the base64URL safe text can you point to the base document; I 
> think it’s s6.1?  
> 
> 2) s3/s5.1: OID CLASH!  id-pe 30 is already assigned.  See:
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1
> 
> 3) s4: Insert obligatory reference to RFC4086 
> (https://datatracker.ietf.org/doc/rfc4086/) for the randomness considerations 
> of the token.  I’ll submit something against acme-acme so you may just be 
> able to borrow that.
> 
> 4) General: How are you addressing the algorithm agility concerns raised in 
> BCP 201 (https://datatracker.ietf.org/doc/rfc7696/)?  Is it just going to be 
> v2 if you need SHA-384?
> 
> 5) General: Okay so I’m no cryptographer, but should the hash algorithm used 
> in the challenge correspond to the hash algorithm used in the PRF/HKDF?  I 
> mean if I’m going to use TLS 1.3 and TLS_AES_256_GCM_SHA384 should I really 
> use SHA-256?
> 
> 6) s5: I’d probably just add the following in s5.  I think everybody knows 
> what’s going on, but it’s good to be specific:
> 
> [[RFC Editor: please replace  below by the RFC number.]]
> 
> spt
> 
>> On Jul 18, 2018, at 15:56, Salz, Rich  
>> wrote:
>> 
>> 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

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

Re: [Acme] I-D Action: draft-ietf-acme-ip-03.txt

[Roland Shoemaker]

Works for me, I’ll push a version with this change this afternoon.

Corey: thanks for catching this! I went looking for a reference on whether this 
was allowed but apparently completely glazed over the relevant line in 6066.

> On Jul 25, 2018, at 10:59 AM, Salz, Rich  
> wrote:
> 
> Use ip-addr.arpa names?
> 
> 
> ___
> 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

[Roland Shoemaker]

Ah, awesome. Well that makes life a lot easier! I’ll work to get a version of 
ACME-IP that includes this up today or tomorrow.

> On Jul 19, 2018, at 2:05 PM, Ilari Liusvaara  wrote:
> 
> On Thu, Jul 19, 2018 at 01:03:14PM -0700, Roland Shoemaker wrote:
>> One thing that I forgot to bring up during the meeting was an issue
>> that was brought up with regards to the order in which the ACME-TLS-ALPN
>> and ACME-IP drafts are standardized. ACME-IP defines how to use IP
>> addresses with existing challenges and we’d like to include guidance
>> on how to do so with TLS-ALPN, but (as far as I’m aware) we are unable
>> to reference IDs in RFCs so we cannot directly reference
>> draft-ietf-acme-tls-alpn
> 
> This is incorrect. IDs can normatively reference other IDs, if
> there is a "plan" on getting the referenced ID ready to be published.
> If needed, the referencing draft waits for the referenced one in
> RFC-Editor queue.
> 
> So I think the easiest way is to just have normative reference
> ACME-IP -> TLS-ALPN.
> 
> 
> -Ilari

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

Re: [Acme] Confirming consensus

[Roland Shoemaker]

One thing that I forgot to bring up during the meeting was an issue that was 
brought up with regards to the order in which the ACME-TLS-ALPN and ACME-IP 
drafts are standardized. ACME-IP defines how to use IP addresses with existing 
challenges and we’d like to include guidance on how to do so with TLS-ALPN, but 
(as far as I’m aware) we are unable to reference IDs in RFCs so we cannot 
directly reference draft-ietf-acme-tls-alpn (and if we were to include guidance 
on how to use TLS-ALPN with IPs in draft-ietf-acme-tls-alpn we could not 
directly reference draft-ietf-acme-ip). It might be possible to do this in 
draft-ietf-acme-tls-alpn by skirting around any references to IP identifiers 
and just provide the guidance on how to do this _if there is a way_ to do IP 
for validation but it feels a bit hacky.

Does anyone have strong opinions on how to handle this? I feel like the best 
approach may be to just wait for one document to be standardized and then move 
onto the second one (probably TLS-ALPN first since it’s slightly more important 
from my perspective but ¯\_(ツ)_/¯). 

> On Jul 18, 2018, at 11:47 AM, Salz, Rich  
> wrote:
> 
> 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

[Acme] Time for ACME-CAA discussion at 102

[Roland Shoemaker]

I know this is quite late but could we reserve some time for a discussion of 
the (possible) pending issues with regard to the parameter format mismatch 
between ACME-CAA and 6844 and possible solutions.

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

Re: [Acme] Draft authors -- please send a status

[Roland Shoemaker]

Oh, and I don’t think there needs to be any time devoted to either draft as 
nothing major has been added/changed since the last meeting.

> On Jun 27, 2018, at 2:39 PM, Roland Shoemaker  wrote:
> 
> draft-ietf-acme-tls-alpn-01: No changes since last meeting other than a 
> handful of minor editorial changes. The draft method is currently implemented 
> in the Let’s Encrypt staging environment and is planned to be deployed in the 
> production environment in the coming weeks.
> 
> draft-ietf-acme-ip-02: The contentious reverse zone DNS based validation 
> method has been removed from the draft. The document needs a few small 
> changes to be updated to add guidance on the usage of the TLS-ALPN method 
> with IP identifiers.
> 
>> On Jun 27, 2018, at 8:57 AM, Salz, Rich  
>> wrote:
>> 
>> Can the authors of each draft please send a brief (one or two sentences is 
>> fine) status to the mailing list about their drafts?  Also indicate if you 
>> want WG time to present, talk about issues, etc. We are scheduled to meet 
>> during the Tuesday afternoon session, from 17:20-18:20 (last hour, after 
>> oauth).
>> 
>> draft-ietf-acme-acme-12
>> draft-ietf-acme-caa-05  Ready to move to IESG
>> draft-ietf-acme-email-smime-02
>> draft-ietf-acme-email-tls-04
>> draft-ietf-acme-ip-02
>> draft-ietf-acme-star-03
>> draft-ietf-acme-tls-alpn-01
>> 
>> ___
>> 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 authors -- please send a status

[Roland Shoemaker]

draft-ietf-acme-tls-alpn-01: No changes since last meeting other than a handful 
of minor editorial changes. The draft method is currently implemented in the 
Let’s Encrypt staging environment and is planned to be deployed in the 
production environment in the coming weeks.

draft-ietf-acme-ip-02: The contentious reverse zone DNS based validation method 
has been removed from the draft. The document needs a few small changes to be 
updated to add guidance on the usage of the TLS-ALPN method with IP identifiers.

> On Jun 27, 2018, at 8:57 AM, Salz, Rich  
> wrote:
> 
> Can the authors of each draft please send a brief (one or two sentences is 
> fine) status to the mailing list about their drafts?  Also indicate if you 
> want WG time to present, talk about issues, etc. We are scheduled to meet 
> during the Tuesday afternoon session, from 17:20-18:20 (last hour, after 
> oauth).
>  
> draft-ietf-acme-acme-12
> draft-ietf-acme-caa-05  Ready to move to IESG
> draft-ietf-acme-email-smime-02
> draft-ietf-acme-email-tls-04
> draft-ietf-acme-ip-02
> draft-ietf-acme-star-03
> draft-ietf-acme-tls-alpn-01
>  
> ___
> 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] Handling non-conformant CAA property names in ACME-CAA

[Roland Shoemaker]

As previously discussed on the list the two property names defined in 
draft-ietf-acme-caa, "validation-methods” and "account-uri”, do not conform to 
the ABNF syntax in RFC 6844 as they contain hyphens. 6844-bis fixes this by 
expanding the ABNF to be less restrictive but for now this doesn’t really 
address the problem at hand.

Given it is probably unlikely that 6844-bis will be standardized any time soon 
is there any plan to make changes to draft-ietf-acme-caa to address this in the 
short term? Given we are not yet at the point where there is wide 
deployment/adoption of this feature can we take the easy route and simply 
remove the hyphens so that the document at least complies with the existing CAA 
document?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Mail regarding draft-ietf-acme-tls-alpn

[Roland Shoemaker]

The validation certificate should only ever be served for requests that 
negotiate the amce-tls/1 application protocol, which browsers or equivalent 
user software should never do. This allows the server (or load balancer) to 
continue serving normal traffic to users while also serving validation traffic 
to the ACME server.

> On May 25, 2018, at 8:09 AM, Ben Sykes 

Re: [Acme] I-D Action: draft-ietf-acme-ip-02.txt

[Roland Shoemaker]

Ah, yup, good catch. I totally spaced we’d pulled that out.

Likely we’ll want to reference TLS-ALPN here but it kind of ends up being a 
chicken and egg scenario. If draft-ietf-acme-tls-alpn gets standardized first 
we’ll want to mention that in this document updating it’s method to accept IPs, 
if we standardize draft-ietf-acme-ip first we’ll want to mention in 
draft-ietf-acme-tls-alpn that it can work with IP identifiers.

It seems like there is more forward momentum on draft-ietf-acme-tls-alpn so I 
suspect we should just wait for that to be done to get this out the door… 
thoughts?

> On May 19, 2018, at 4:58 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 
> On Fri, May 18, 2018 at 03:16:32PM -0700, Roland Shoemaker wrote:
>> Sorry for the lag on getting this out. Given the discussions at IETF
>> 101 and on the list the main change in this version is the removal of
>> the reverse-dns challenge type. While I still think there is some value
>> in at least having a technical definition of the method there is enough
>> opposition that it’s inclusion in this draft would’ve stopped any
>> forward progress in its tracks. Otherwise there are a few minor editorial
>> changes but not much else.
> 
> I note that TLS-SNI-02 is still there. But that method has gotten ripped
> out from the main ACME spec due to security problems.
> 
> 
> -Ilari

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

Re: [Acme] I-D Action: draft-ietf-acme-ip-02.txt

[Roland Shoemaker]

Sorry for the lag on getting this out. Given the discussions at IETF 101 and on 
the list the main change in this version is the removal of the reverse-dns 
challenge type. While I still think there is some value in at least having a 
technical definition of the method there is enough opposition that it’s 
inclusion in this draft would’ve stopped any forward progress in its tracks. 
Otherwise there are a few minor editorial changes but not much else.

> On May 18, 2018, at 12:49 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Automated Certificate Management Environment 
> WG of the IETF.
> 
>Title   : ACME IP Identifier Validation Extension
>Author  : Roland Bracewell Shoemaker
>   Filename: draft-ietf-acme-ip-02.txt
>   Pages   : 4
>   Date: 2018-05-18
> 
> Abstract:
>   This document specifies identifiers and challenges required to enable
>   the Automated Certificate Management Environment (ACME) to issue
>   certificates for IP addresses.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-ip/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-ip-02
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-ip-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] I-D Action: draft-ietf-acme-ip-01.txt

[Roland Shoemaker]

Little difference from the last draft, mostly small cleanups.

There was some previous discussion about how to handle policy decisions
for issuing certificates for IP addresses. It was suggested that this
draft should contain some stronger language that would allow default
denial of certificate issuance for IP addresses. I think there should
definitely be some process for communicating these kinds of policy
decisions but I don't think this document is the right place for it, nor
do I think this document should attempt to dictate CA policy by
requiring something like this. I believe doing so would be a step back
for any CA implementing this document as they are all currently able to,
and many do, issue certificates for any IP address as long as a user is
able to prove control of it.

I believe we (or the IETF more generally) should instead focus on
developing standards for communicating a policy about issuance for IP
addresses to CAs such as a CAA lookup mechanism that can handle them
(i.e. something like
https://tools.ietf.org/html/draft-shoemaker-caa-ip-01, note this lacks
the tree climbing behavior which after bouncing it around a bit I've
come to the decision that it does actually require).

(I also totally forgot to incorporate the reference to 5952 for IPv6
textual representation, only saw my note about doing that after
submitting the docs, I'll make sure to resolve this in the next version!)

On 09/18/2017 12:15 PM, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Automated Certificate Management Environment 
> WG of the IETF.
> 
> Title   : ACME IP Identifier Validation Extension
> Author  : Roland Bracewell Shoemaker
>   Filename: draft-ietf-acme-ip-01.txt
>   Pages   : 7
>   Date: 2017-09-18
> 
> Abstract:
>This document specifies identifiers and challenges required to enable
>the Automated Certificate Management Environment (ACME) to issue
>certificates for IP addresses.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-ip/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-ip-01
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-ip-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
> 

-- 
Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group

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

Re: [Acme] draft minutes from june 2 interim

[Roland Shoemaker]

Sorry I wasn't able to make it for this call, comments inline:

On 06/02/2017 12:36 PM, Salz, Rich wrote:
> There were about 20 people present on the call.  It lasted about 50 minutes.  
> Would those who were on the call please post corrections here?  Thank you.
> 
> 
>>Hugo's CAA draft (already adopted, short, might be ready for 
>> WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01
> 
> Chairs will call for consensus on moving to WGLC.
> 
>>Yaron Sheffer et al draft on STAR -- 
>> https://tools.ietf.org/html/draft-sheffer-acme-star-lurk-00
> 
> There was discussion on how this overlaps with the tls-subcert document. 
> After some discussion, there was good consensus to ask that this be split 
> into two parts (the ACME-related revalidation and the CDN-related deployment) 
> and the chairs will ask for consensus on adoption.  The split will happen 
> before or after adoption.
> 
>>Mary Barnes on an ACME challenge for ATIS/SIP -- 
>> https://tools.ietf.org/html/draft-barnes-acme-service-provider-00
> 
> There was some discussion, but strong consensus to adopt this by the WG.  
> Chairs will confirm on the list.
> 
>>   And also Jon Peterson et al 
>> https://tools.ietf.org/html/draft-peterson-acme-telephone-00
> 
> Also similar discussion.  General agreement to also adopt this, and keep in 
> close contact with STIR to make sure things progress properly.
>  
>>Roland Shoemaker on an ACME challenge for validating IP 
>> addresses -- https://tools.ietf.org/html/draft-shoemaker-acme-ip-00
> 
> Briefly discussed; Yaron requested clarification on the use-case before 
> considering adoption.

I think there are two main use-cases for this: people who want
certificates for public IPv4/6 addresses which is not incredibly common
but is a feature offered by a number of existing commercial CAs, and is
therefore something ACME should attempt to provide parity with; and
people who want to use ACME in an internal non-public CA for generating
certificates for various services which use them for, i.e., RPC endpoint
authentication.

> 
>> In addition, Alexey is interested in helping with an ACME challenge for 
>> email certificates. Is anyone else interested in helping to draft drafting?
> 
> Alex posted a draft just before the meeting.  Consensus was to split the 
> SMTP-server related part and the user S/MIME related part and work on them 
> separately.
> 
> At the end of the meeting, Kathleen pointed out that Ted has a new role as 
> IAB Chair, and wants to step down from ACME co-chair. The plan would be to 
> have a new co-chair for Prague, and then after the Prague meeting, for Ted to 
> abandonXX relinquish the co-chair role.  If you are interested in 
> volunteering, please let Kathleen (and perhaps ekr and the current chairs) 
> know.
> 
> Related to this, the ACME base document is almost done. The Chairs strongly 
> encouraged Richard et al to finish by mid-June so that we could enter WGLC 
> and address any issues that might come up (if any do) at the Prague meeting.
> 
> Please send/post any corrections by mid-next-week so that we can start the 
> calls for adoption right away.
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
> 

-- 
Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group

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

Re: [Acme] Futures

[Roland Shoemaker]

I'd be interested in getting draft-shoemaker-acme-ip (current draft:
https://www.ietf.org/id/draft-shoemaker-acme-ip-00.txt with a revision
coming in the very near future) adopted by the WG. We are currently
considering implementing the extension defined in it in the Let's Encrypt
server software Boulder and it would be good to get consensus from the
group that it is an appropriate path forward for validating IP addresses.

Thanks,
Roland

--
Software Engineer, Let's Encrypt
Internet Security Research Group / Linux Foundation

On Fri, Apr 21, 2017 at 7:01 PM Salz, Rich  wrote:

> Having talked with the authors, we expect the base ACME draft to be ready
> for WGLC at least a month before the next IETF meeting.
>
>
>
> The CAA document, which we adopted, is very short and straightforward and
> seems like it can be handled easily over email.
>
>
>
> Does anyone have any new work items that would be ready to discuss in
> July?  Any rechartering discussion that looks promising?  If so, please
> post to the mailing list soon.
>
>
>
> Thanks,
>
> Rich and Ted’s Excellent ACME Adventure
>
>
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> Member, OpenSSL Dev Team
>
> 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] Fwd: New Version Notification for draft-shoemaker-acme-ip-00.txt

[Roland Shoemaker]

Probably of interesting to some people here, would love to hear your
thoughts.

 Forwarded Message 
Subject: New Version Notification for draft-shoemaker-acme-ip-00.txt
Date: Mon, 27 Mar 2017 13:30:19 -0700
From: internet-dra...@ietf.org
To: Roland Bracewell Shoemaker <rol...@letsencrypt.org>, Roland
Shoemaker <rol...@letsencrypt.org>


A new version of I-D, draft-shoemaker-acme-ip-00.txt
has been successfully submitted by Roland Bracewell Shoemaker and posted
to the
IETF repository.

Name:   draft-shoemaker-acme-ip
Revision:   00
Title:  ACME IP Identifier Validation Extension
Document date:  2017-03-27
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-shoemaker-acme-ip-00.txt
Status: https://datatracker.ietf.org/doc/draft-shoemaker-acme-ip/
Htmlized:   https://tools.ietf.org/html/draft-shoemaker-acme-ip-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-shoemaker-acme-ip-00


Abstract:
   This document specifies identifiers and challenges required to enable
   the Automated Certificate Management Environment (ACME) to issue
   certificates for IP addresses.




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

The IETF Secretariat

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

[Acme] Possible IETF meeting agenda item: reducing effects of key-compromise

[Roland Shoemaker]

Internally at LE we have been having discussions around how the spec can
most effectively reduce the harm of account key compromise and it seems
like it could be a good topic to bring up at the upcoming IETF meeting.

We've come up with two distinct but not mutually exclusive ideas on this
topic:

* Deactivating authorizations on key roll-over, summarized here:
https://www.ietf.org/mail-archive/web/acme/current/msg01747.html
* Only allowing a single valid authorization per name to exist at the
same time, summarized here:
https://www.ietf.org/mail-archive/web/acme/current/msg01661.html

Both of these proposals would be relatively large changes to the current
follow and introduce certain issues for both individual users and large
service integrators and could definitely use some public discussion
before the spec is finalized.

It would also be good to hear if there are any other thoughts from other
implementors/contributors as to how we can best reduce the damage done
by key compromise in general.

-- 
Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group

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

[Acme] Minimizing risk of key compromise

[Roland Shoemaker]

How would people feel about adding some language to the account key
roll-over section that says that any cached (already valid)
authorizations for identifiers should be deactivated on roll-over? This
would reduce the risk of an attacker gaining control of an account and
all associated authorizations in such a way that the original user could
not revoke the authorizations themselves.

The original user would still be able to revoke any certificates
containing identifiers for these authorizations themselves (by creating
new authorizations for the identifiers in the certificate) but a
attacker could simply add a single new identifier which the original
user does not have control over to prevent this with the current design.

-- 
Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group

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

[Acme] Removing extraneous link relations

[Roland Shoemaker]

I propose we remove the 'author', 'revoke', and 'ct-sct' link relations.
'author' seems to provide no concrete value, and 'revoke' is already
provided by the 'directory' endpoint. The 'ct-sct' relation is also
somewhat pointless as the SCT will be provided by the CA via the
certificate or a OCSP response, if it doesn't provide either of these
then the client should be able to retrieve the SCT itself from the logs
it expects to find the certificate in.

I also agree with Martin's suggestion that we replace the 'directory'
link relation with 'index' as it is already registered and means
basically what we intend.

PR making these changes: https://github.com/ietf-wg-acme/acme/pull/250

-- 
Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group

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

Re: [Acme] Post-IETF-96 PRs

[Roland Shoemaker]

>From the view point of Let's Encrypt/Boulder: Our original plan for
major specification changes has been to provide multiple versioned API
endpoints which implement different verions of ACME. Currently we only
provide acme-v01.api.letsencrypt.org which implements an amalgam of the
first four drafts (documented here:
https://github.com/letsencrypt/boulder/blob/243832822a28e04e46dc26ab3554ac2062731cc6/docs/acme-divergences.md)
but given the number of breaking/major flow changes in draft-03 we plan
to make a second endpoint available (presumably acme-v02) which will be
a strict implementation of the specification once it is finalized.

Assuming, given the recent discussion of entering WGLC, that the
specification is in the process of stabilizing and that the largest
server side implementer most likely won't implement large portions of
the new spec until it is finalized adding fine grained versioning to the
protocol seems like overkill.

I'm not entirely convinced the specification itself needs to provide a
versioning mechanism at all beyond perhaps indicating that if a server
chooses to implement an older version of the specification it should do
so on a distinct endpoint.

On 08/08/2016 07:03 PM, Martin Thomson wrote:
> On 9 August 2016 at 02:53, Richard Barnes  wrote:
>> Again, I'm not totally convinced that semantic mismatches are that big a
>> deal.  The "url" parameter already scopes the signed object to a specific
>> resource, so the only risk would be if that specific resource accepts
>> different object formats that are confusable with one another.  You need
>> some signal to disambiguate, but it's not clear to me that having one big
>> version is the best solution.
> 
> Let's not overwork this one, I don't care that much either way on this
> point.  The suggestion seemed to have a low complexity cost for some
> gain.  That cost doesn't seem to be as low as first expected
> (surprise!).  Thus, I'm not willing to spend too much extra effort to
> keep this.
> 
> ___
> 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] Contact URIs

[Roland Shoemaker]

That sounds good, adding this more specific language about how the server 
should treat non-mailto URIs would make the tel examples make more sense to me.

When you say 'filter' unsupported contacts what do you mean? It seems like 
erroring out seems like it would be more prudent.

On Jul 28, 2016, 3:25 PM -0700, Richard Barnes <r...@ipv.sx>, wrote:
> So how about we add something like this:
>
> - Servers SHOULD only allow contact types they know how to handle
> - ... MUST filter unsupported contacts;
> - ... MUST support "mailto:;
>
> Roland: When you say "explicitly referred to", do you mean in the examples? I 
> would prefer to keep a non-mailto example there, if we're clear that the 
> server can reject it.
>
>
> On Thu, Jul 28, 2016 at 6:21 PM, Roland Shoemaker <rol...@letsencrypt.org 
> (mailto:rol...@letsencrypt.org)> wrote:
> > I agree with Ted that generic URI support should be documented but that 
> > mailto should be the only one explicitly referred to.
> >
> > This was the intention of the original ticket I filled, although maybe not 
> > as coherently.
> >
> >
> > On Jul 28, 2016, 3:17 PM -0700, Ted Hardie <ted.i...@gmail.com 
> > (mailto:ted.i...@gmail.com)>, wrote:
> > > Hi Richard
> > >
> > > On Thu, Jul 28, 2016 at 2:42 PM, Richard Barnes <r...@ipv.sx 
> > > (mailto:r...@ipv.sx)> wrote:
> > > > Roland filed an issue proposing removal of any URIs other than 
> > > > "mailto:;.
> > > >
> > > > https://github.com/ietf-wg-acme/acme/issues/159
> > > >
> > > I think there is another way to look at the issue. Rather than focusing 
> > > on removing PSTN, you could say that he is requesting that mailto: be 
> > > universally supported, where other URI forms would be at the discretion 
> > > of the CA.
> > >
> > > Put that way, I think it's worth consideration. If there is a single 
> > > contact method that ACME requires, mailto makes sense.
> > > > I really strongly disagree with this. At the level of this protocol, we 
> > > > should allow clients to specify whatever types of contact they want, as 
> > > > long as it can be specified in a URI.
> > > >
> > >
> > > A data URI could have instructions on where to show up as a series of 
> > > navigational cues, so "can be specified in a URI" may not be enough.
> > >
> > > Ted
> > >
> > > > I would be willing to have some text that explicitly allows the server 
> > > > to filter the contact list, though, so that it's clear to the client 
> > > > what the server does and doesn't support.
> > > >
> > > > ___
> > > > Acme mailing list
> > > > Acme@ietf.org (mailto:Acme@ietf.org)
> > > > https://www.ietf.org/mailman/listinfo/acme
> > > >
> > >
> > > ___
> > > Acme mailing list
> > > Acme@ietf.org (mailto:Acme@ietf.org)
> > > https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Contact URIs

[Roland Shoemaker]

I agree with Ted that generic URI support should be documented but that mailto 
should be the only one explicitly referred to.

This was the intention of the original ticket I filled, although maybe not as 
coherently.

On Jul 28, 2016, 3:17 PM -0700, Ted Hardie , wrote:
> Hi Richard
>
> On Thu, Jul 28, 2016 at 2:42 PM, Richard Barnes  (mailto:r...@ipv.sx)> wrote:
> > Roland filed an issue proposing removal of any URIs other than "mailto:;.
> >
> > https://github.com/ietf-wg-acme/acme/issues/159
> >
> I think there is another way to look at the issue. Rather than focusing on 
> removing PSTN, you could say that he is requesting that mailto: be 
> universally supported, where other URI forms would be at the discretion of 
> the CA.
>
> Put that way, I think it's worth consideration. If there is a single contact 
> method that ACME requires, mailto makes sense.
> > I really strongly disagree with this. At the level of this protocol, we 
> > should allow clients to specify whatever types of contact they want, as 
> > long as it can be specified in a URI.
> >
>
> A data URI could have instructions on where to show up as a series of 
> navigational cues, so "can be specified in a URI" may not be enough.
>
> Ted
>
> > I would be willing to have some text that explicitly allows the server to 
> > filter the contact list, though, so that it's clear to the client what the 
> > server does and doesn't support.
> >
> > ___
> > Acme mailing list
> > Acme@ietf.org (mailto:Acme@ietf.org)
> > https://www.ietf.org/mailman/listinfo/acme
> >
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Economize on nonces

[Roland Shoemaker]

(Playing devils advocate) Why not just remove the nonce system entirely?

The main use of the nonce system is to protect against TLS termination
at a CDN (or MITM middleboxes) which could, if malicious, replay
requests. Why not instead just recommend local termination of TLS and
that implementing clients should pin the relevant API TLS keys?

This would greatly simplify a number of things, including the rather
annoying need to always start any API flow with a failed request/HEAD to
a random endpoint.

On 07/08/2016 01:55 PM, Jacob Hoffman-Andrews wrote:
> https://github.com/ietf-wg-acme/acme/pull/156
> 
> Previously the server was required to provide a nonce on all successful
> responses, including GETs. This makes certain nonce-storage techniques
> like an
> in-memory list impractical, because the size of the list would have to scale
> with GET requests rather than just authenticated POSTs.
> 
> This change reduces the scope of requests where nonces are required.
> 
> It also tweaks the example section for Replay-Nonce to not define the
> base64url
> character set.
> 
> 
> 
> ___
> 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] Simplifying key rollover

[Roland Shoemaker]

The proposed simplification looks good to me and would make the Boulder
implementation much cleaner overall.

I also agree the ambiguity about which header the 'jwk' field is
provided in should be cleared up, it seems like there is no reason not
to require it in the protected header.

On 06/22/2016 11:26 AM, Jacob Hoffman-Andrews wrote:
> Any objections to the below? We'd like to start implementing in Boulder
> soon.
> 
> On 06/09/2016 03:59 PM, Jacob Hoffman-Andrews wrote:
>> On 03/31/2016 02:27 PM, Jacob Hoffman-Andrews wrote:
>>> I'd like to propose some changes to how we do account key roll-over. I
>>> think the current approach is too complex. The current version is
>>> included below for reference.
>>>
>>> Instead I'd like to propose:
>>>
>>> To update the key on a registration object, POST a double-signed JOSE
>>> object to the registration URL, with the field "key" containing the new
>>> key, in JWK format.
>>>
>>> The double-signed object should have two signatures: one from the old
>>> key, and one from the new key. This ensures that the key rollover is
>>> authorized by the existing account holder, and also proves that the
>>> requester possesses the private key corresponding to the new key.
>>>
>>> What do you all think?
>>>
>>> Relatedly, since we are introduce a self-signature to prove possession
>>> of the new key, we probably want to introduce the same guarantee on
>>> initial account creation. One easy way to achieve this would be to
>>> require that the "jwk" field be provided in the protected header, rather
>>> than in the protected or unprotected header as is allowed today.
>> I've posted a PR for this change, tweaked slightly to use a separate
>> resource: https://github.com/ietf-wg-acme/acme/pull/139.
>>
>> ___
>> 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] Allow user specified revocation reason

[Roland Shoemaker]

I've posted a small PR that allows users to specify the reason when
requesting the revocation of a certificate which is a prerequisite for
Boulder to be able to generate meaningful CRLs.

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

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