from:"Alexey Melnikov"

Re: [Acme] [Editorial Errata Reported] RFC8823 (7508)

2023-05-05 Thread Alexey Melnikov


Hi,

On 05/05/2023 01:01, RFC Errata System wrote:

The following errata report has been submitted for RFC8823,
"Extensions to Automatic Certificate Management Environment for End-User S/MIME 
Certificates".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7508

--
Type: Editorial
Reported by: Richard Wang

Section: 3.1 and 3.2

Original Text
-
Figure 1:
   Message-ID:
   From:acme-genera...@example.org
   To:ale...@example.com

Figure 2:
Message-ID:<111-2-...@example.com>
In-Reply-To:
From:ale...@example.com
To:acme-genera...@example.org

Corrected Text
--
Figure 1:
   Message-ID:
   From:acme-genera...@example.com
   To:ale...@example.org

Figure 2:
Message-ID:<111-2-...@example.org>
In-Reply-To:
From:ale...@example.org
To:acme-genera...@example.com


I generally agree that there is a problem that email messages in 
Sections 3.1 and 3.2 don't match the following challenge in Section 3:


{
  "type": "email-reply-00",
  "url":"https://example.com/acme/chall/ABprV_B7yEyA4f";,
  "from":"acme-challenge+2i211oi1204...@example.com",
  "token": "DGyRejmCefe7v4NfDGDKfA"
}

However I propose an alternative fix that might be smaller. I suggest to 
change the above challenge in Section 3:


OLD:

    {
  "type": "email-reply-00",
  "url": "https://example.*com*/acme/chall/ABprV_B7yEyA4f";,
  "from": "acme-challenge+2i211oi1204310@example.*com*",
  "token": "DGyRejmCefe7v4NfDGDKfA"
    }

NEW:

    {
  "type": "email-reply-00",
  "url": "https://example.*org*/acme/chall/ABprV_B7yEyA4f";,
  "from": "acme-challenge+2i211oi1204310@example.*org*",
  "token": "DGyRejmCefe7v4NfDGDKfA"
    }

After this change example.org would be the ACME server domain and 
example.com would be the user domain.*

*


Best Regards,

Alexey



Notes
-
Accoording to RFC8555, the domain example.com used for ACME server, the 
example.org used for the Client.

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.

--
RFC8823 (draft-ietf-acme-email-smime-14)
--
Title   : Extensions to Automatic Certificate Management 
Environment for End-User S/MIME Certificates
Publication Date: April 2021
Author(s)   : A. Melnikov
Category: INFORMATIONAL
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

Re: [Acme] RFC 8823 email-reply-00: How to concatenate the tokens?

2021-08-16 Thread Alexey Melnikov

Hi all,

On 07/06/2021 03:39, Brian Sipos wrote:

Richard,
>From my interpretation, the fact that the two token parts are 
base64url strings is immaterial to the text-string concatenation into 
the ACME "token" value. The Key Authorization calculation of RFC 8555 
also does not care where the token text came from or whether it is a 
base64url encoded text string.

Also be careful about your assumptions about the tokens themselves. 
While RFC 8555 makes requirements about base64url encoded token 
values, RFC 8823 does not make any requirements about the content of 
the "token-part2" text value. The fact that the example looks like 
base64url encoding implies that, but I don't see any requirement on 
the token-part2 generation other than its minimum entropy. An RFC 8823 
implementation could just as well use random ASCII, Latin-1, base16, 
or any other text; base64 just happens to produce more entropy-dense text.

I can confirm that my intent was to suggest straight string 
concatenation without any base64url-decode and re-encoding.

Use of trailing "=" in the example token-part1 
("LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME=") is unfortunate. I 
should have used the same restriction on token-part1 as specified on 
token in RFC 8555: no trailing "=".
>From my reading, the RFC 8823 requirement text is sufficient to 
explain this but having an example of the pre-digest Key Authorization 
value would be helpful to clarify this. The example currently includes 
only the Key Authorization digest but not the intermediate 
concatenated value.

Best Regards,

Alexey

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

Re: [Acme] Short WGLC review of draft-ietf-acme-email-smime-13

2021-02-15 Thread Alexey Melnikov


Hi Fraser,

On 13/12/2020 05:16, Fraser Tweedale wrote:

On Thu, Dec 10, 2020 at 06:23:08PM +, Salz, Rich wrote:

In order to address feedback that came up during AD and WGLC review, Alexey 
posted a new draft.
This link will show the differences: 
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-acme-email-smime-13.txt

Summary is that it adds text about putting the right keyUsage extensions 
(signing, encryption) so that different keys/certs can be used for signing and 
encryption. It’s important to be able to have separate signing and encryption 
keys.

Please send feedback by the end of next week.  Thanks!

There is ambiguity in Section 3.3:

In order to request signing only S/MIME certificate, the CSR MUST
include the key usage extension with digitalSignature and/or
nonRepudiation bits set.

This text does not imply that that other bits, including
keyEncipherment/keyAgreement, MUST NOT be set.  I would suggest
appending "and no other bits set", i.e.:

In order to request signing only S/MIME certificate, the CSR MUST
include the key usage extension with digitalSignature and/or
nonRepudiation bits set, and no other bits set.

Similarly for the subsequent paragraph (which can be solved the same
way):

In order to request encryption only S/MIME certificate, the CSR MUST
include the key usage extension with keyEncipherment and/or
keyAgreement bits set.


I incroprorated your suggestions.

Best Regards,

Alexey

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

Re: [Acme] I-D Action: draft-ietf-acme-email-smime-14.txt

2021-02-15 Thread Alexey Melnikov


On 15/02/2021 18:00, internet-dra...@ietf.org wrote:


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-email-smime-14
https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-14


This version addresses nits from Ben's final review.


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

Re: [Acme] Benjamin Kaduk's Yes on draft-ietf-acme-email-smime-13: (with COMMENT)

2021-02-15 Thread Alexey Melnikov


Hi Ben,

On 13/01/2021 23:04, Benjamin Kaduk via Datatracker wrote:

Thanks for the updates to get to the -13; they look really good.

The new text did inspire one further comment, though I don't see a
particular text change that might result, plus I spotted a few editorial nits.

Section 1

1.  A Mail User Agent (MUA) which has built in ACME client aware of
the extension described in this document.  (We will call such
ACME clients "ACME-email-aware") Such MUA can present nice User
Interface to the user and automate certificate issuance.

(nit?) In the parenthetical, are we calling the ACME clients or the MUA
"ACME-email-aware"?  Also, full stop for the end of the sentence.

Section 3

(nit?) In step 8, the MUST-level requirement in the last sentence probably
promotes it into not being a parenthetical.

Section 3.1

   If S/MIME signing is used, the certificate corresponding to
   the signer MUST have rfc822Name subjectAltName extension with
   the value equal to the From header field email address of the
   "challenge" email.

A strict equality requirement might make it operationally challenging to
use a unique "from" challenge for each request.  I don't see any
feasible alternative, though, as getting into + suffixes in the local
part seems like a non-starter for this document.

I am afraid so.

Also, nit: s/subjectAltName extension/a subjectAltName extension/


Applied all of the above. Thanks.

Best Regards,

Alexey

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

Re: [Acme] S/MIME and ACME: concerns about dual certificates (maybe pull the S/MIME draft back to ACME WG)

2020-11-20 Thread Alexey Melnikov

Hi DKG,

On 19/11/2020 08:51, Daniel Kahn Gillmor wrote:

Over in LAMPS, we've been discussing how a given S/MIME certificate
probably shouldn't expect the same cryptographic key material to be used
for both signing and encryption. [0]

In particular, public keys of type "EC Public Key" can be used for
digital signatures or key agreement.  And a public key of type "RSA" can
be used for digital signatures or key encapsulation.  ("ECDSA" and
"ECDH" key types can only be used for signing or encryption,
respectively, so maybe they aren't affected by this)

So, an S/MIME MUA probably wants to control two distinct certificates
per e-mail account it manages: one for signing, and one for encryption.

It's not clear to me how a MUA is expected to deal with this.

  - should the MUA run the ACME process twice, once per certificate?

Yes.

if
so, how does it specify which certificate is for signing and which is
for encryption?
How does the change in 
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-13 look?

  - If so, are we expecting the users of non-ACME MUAs to jump through
these hoops twice as well, responding to two different e-mail
prompts?
I am open to suggestions, but for simplicity of implementation, I think 
this is acceptable.

  - If not, how does the client communicate both certificate requests to
the server at the same time?  If there's a way to do that, can the
user indicate that they want different issuance parameters for the
different key usages?
If you really want different parameters for different key usages, I 
think you are basically reenforicing my comment above that this would 
require 2 separate requests.

For example, maybe a sensible MUA with an automated workflow might
want to rotate their signing certificate every month (it's cheap and
easy to get a new one, and a validity period of a month on each
certificate limits the window of any particular compromise).  But it
might want to request a new encryption certificate every 6 months
(and it might want the validity window for the encryption certificate
to last for a year, so that any acquaintance that receives mail from
the user will be able to reply encrypted up to a year later without
having to rediscover the user's certificate).  Can/should the MUA
just indicate those preferences in the generated CSRs?  if it's
embedded in the CSR, do we have rules for how a CA ought to verify
the semantics of such a request?
I think in the base ACME this is already indicated in the "notAfter" 
field in the newOrder request. This is not conveyed in the CSR itself.

  - alternately, are we comfortable with just saying that the ACME S/MIME
work doesn't actually support this dual-certificate model, and just
have the same key used for both signing and encryption?  that seems
to go against NIST guidance at least, and risks introducing some kind
of cross-protocol attack.

sorry to bring this up when the draft is already so far into the
editorial review process!

 --dkg

[0] in Message-ID 
CALhKWgj=W-Yo_t=k0fcl+vsfa3ace2lfygetithjqpw-upf...@mail.gmail.com,
 Jonathan Hammell writes:
  > Section 5.2 of NIST SP 800-57-1 rev 5 forbids using a key for both
  > signing and encryption and gives several reasons.

Best Regards,

Alexey

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

Re: [Acme] I-D Action: draft-ietf-acme-email-smime-10.txt

2020-11-18 Thread Alexey Melnikov


Hi Fraser,

On 12/11/2020 11:53, Fraser Tweedale wrote:

On Thu, Nov 12, 2020 at 10:03:32AM +, Alexey Melnikov wrote:

Hi Fraser,

Thank you for your comments.

On 12/11/2020 08:14, Fraser Tweedale wrote:

Hello!

I have some issues with this proposal.

1. It does not adequately explain how the ACME client receives
token-part2.  "Over HTTPS" is vague.  Presumably it comes as a field
in the challenge object, e.g.

"challenges": [
  {
"type": "email-reply-01",
"url": "https://example.com/acme/chall/prV_B7yEyA4";,
"token-part2": "DGyRejmCefe7v4NfDGDKfA"
  }
]

Yes.

This needs to be fully specified in the document.

2. It is not stated whether, in addition to sending the response
email, the client also has to POST to the challenge URL as specified
in RFC 8555 Section 7.5.1 (e.g. to signal that the email has been
sent and the server should prepare to receive and process it).

This might not always be possible when a MUA that doesn't support this
proposal directly is to be used. But I agree that this needs to be
clarified one way or another.


Alexey, thank you for your quick reply.

If an MUA does not support this proposal directly (i.e.  with
integrated ACME client) it will also not be able to create the
order, or finalize it and retrieve certificate.  You have to use a
separate ACME client alongside the MUA.  Therefore it seems OK to
require the ACME client to POST to the challenge URL.  User workflow
would be something like:

1. Use ACME client to submit order, awaits challenge email.

2. Receives challenge email, construct response email (perhaps with
guidance/assistance of ACME client) and send.

3. Tell ACME client that response was sent.  ACME client POSTS to
challenge URL, polls authz resource and, if all went well,
finalizes order and emits certificate.


You are right. I am updating the draft to add "POST to the challenge URL".

Best Regards,

Alexey


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

Re: [Acme] I-D Action: draft-ietf-acme-email-smime-11.txt

2020-11-17 Thread Alexey Melnikov


On 17/11/2020 12:53, internet-dra...@ietf.org wrote:


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-email-smime-11
https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-11
This version addresses DISCUSS and comments from Barry, comments from 
Murray and half of DISCUSS/comments from Ben. I will fix remaining 
comment from Ben in -12.


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

Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)

2020-11-17 Thread Alexey Melnikov


Hi Ben,

On 12/11/2020 23:56, Benjamin Kaduk wrote:

Hi Alexey,

On Thu, Nov 12, 2020 at 04:28:39PM +, Alexey Melnikov wrote:

Hi Ben,

On 05/11/2020 08:03, Benjamin Kaduk via Datatracker wrote:

The more straightforward point is that the procedure in section 3
indicates that token-part2 is returned to the ACME client over HTTPS,
but the stated procedure does not otherwise involve an ACME client in
initiating the newOrder request.  I think we need to clarify the
interaction/relationship between end-user/email client UI/etc and the
ACME client in step 1.  In particular, I think that "[t]his document
doesn't prescribe how exactly S/MIME certificate issuance is initiated"
seems incompatible with requiring there to be an ACME client involved
(and the presumed newOrder ACME request, etc.) unless the "initiate"
operation is supposed to be the way by which the ACME client is
triggered to start the request.

I propose the following new description to address your above DISCUSS
points. This probably needs another editorial pass for readability, but
I think the new description is much better for implementors:

Yes, I like it.  Editorial notes inline...


     The process of issing an S/MIME certificate works as follows. Note
     that the ACME client can be a standalone application (if the MUA is
     not ACME-email-aware) or can be a component of the MUA.

     1.  An end-user initiates issuance of an S/MIME certificate for one
     of her email addresses.  This might be done using email client
     UI, by running a command line tool, by visiting a Certificate
     Authority web page, etc.  This document doesn't prescribe
     specific UI used to initiate S/MIME certificate issuance.

Maybe also add "or where the ACME client is located" or similar at the end
of the sentence?
Yes. Good idea. I included all of your editorial suggestions in the 
upcoming -12. Also see my comment below.

     2.  The ACME-email-aware client component begins the certificate
     issuance process by sending a POST request to the server's
     newOrder resource, including the identifier of type "email".  See
     Section 7.4 of [RFC8555] for more details.

     3.  The ACME server responds to the POST request, including

nit: "an"


     "authorizations" URL for the requested email address.  The ACME
     client then retrieves information about the corresponding "email-
     reply-00" challenge as specified in Section 7.5 of [RFC8555].
     The "token" field of the corresponding "challenges" array element
     (which contains "type": "email-reply-00" as another field)
     contains token-part2. token-part2 should contain at least 128
     bits of entropy.

Per my other message, we should talk about the "url" contents as well.

Yes, I will post -12 shortly and I will address this change in -13.

     4.  After responding to the authorization request the ACME server
     generates another token and a "challenge" email message with the
     subject "ACME: ", where  is the
     base64url encoded [RFC4648] of the token.  The ACME server MUST

nit: missing word ("form" or "version" or something, for "encoded version
of the token")


     generate a fresh token for each S/MIME issuance request
     (authorization request), and token-part1 MUST contain at least
     128 bits of entropy.  The challenge email message structure is
     described in more details in Section 3.1.

We might also note that the "From:" line matches the "url" field of the
challenge object.


     5.  The MUA retrieves and parses the challenge email message. The
     ACME client concatenates "token-part1" (received over email) and
     "token-part2" (received over HTTPS [RFC2818]) to create ACME

(We might in theory length-prefix the token parts before concatenating for
hygiene purposes, but the way they are generated doesn't really seem to
open any attacks.)

nit: "the ACME"


     "token", calculates keyAuthorization (as per Section 8.1 of
     [RFC8555]), then returns the base64url encoded SHA-256 digest
     [FIPS180-4] of the key authorization.  The MUA returns the
     base64url encoded SHA-256 digest obtained from the ACME client in
     the body of a response email message.  The response email message
     structure is described in more details in Section 3.2.

     6.  Once the MUA sends the response email, the ACME client can start
     polling the authorization URL (using POST-as-GET request) to see

nit: "requests" plural


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

Re: [Acme] Barry Leiba's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)

2020-11-12 Thread Alexey Melnikov


Hi Barry,

On 05/11/2020 11:03, Alexey Melnikov wrote:

Hi Barry,

On 29/10/2020 21:33, Barry Leiba wrote: 

  [snip]
The example body contains a “.”, which is not a valid base64url 
character.

It is JWS, which contains a dot.

I'm confused, then.  The text says that it's "one or more line
containing the base64url-encoded SHA-256 digest [FIPS180-4] of the key
authorization".

How can that contain a dot?  The key authorization might, but then you
make a digest of it and encode the digest, and that encoded blob can't
contain a dot, right?  What am I missing (just hit me over the head;
it's OK).

I will come back to you on this.


Yes, you are right and I am wrong. I will fix.

Best Regards,

Alexey


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

Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)

2020-11-12 Thread Alexey Melnikov


Hi Ben,

On 05/11/2020 08:03, Benjamin Kaduk via Datatracker wrote:

The more straightforward point is that the procedure in section 3
indicates that token-part2 is returned to the ACME client over HTTPS,
but the stated procedure does not otherwise involve an ACME client in
initiating the newOrder request.  I think we need to clarify the
interaction/relationship between end-user/email client UI/etc and the
ACME client in step 1.  In particular, I think that "[t]his document
doesn't prescribe how exactly S/MIME certificate issuance is initiated"
seems incompatible with requiring there to be an ACME client involved
(and the presumed newOrder ACME request, etc.) unless the "initiate"
operation is supposed to be the way by which the ACME client is
triggered to start the request.


I propose the following new description to address your above DISCUSS 
points. This probably needs another editorial pass for readability, but 
I think the new description is much better for implementors:


   The process of issing an S/MIME certificate works as follows. Note
   that the ACME client can be a standalone application (if the MUA is
   not ACME-email-aware) or can be a component of the MUA.

   1.  An end-user initiates issuance of an S/MIME certificate for one
   of her email addresses.  This might be done using email client
   UI, by running a command line tool, by visiting a Certificate
   Authority web page, etc.  This document doesn't prescribe
   specific UI used to initiate S/MIME certificate issuance.

   2.  The ACME-email-aware client component begins the certificate
   issuance process by sending a POST request to the server's
   newOrder resource, including the identifier of type "email".  See
   Section 7.4 of [RFC8555] for more details.

   3.  The ACME server responds to the POST request, including
   "authorizations" URL for the requested email address.  The ACME
   client then retrieves information about the corresponding "email-
   reply-00" challenge as specified in Section 7.5 of [RFC8555].
   The "token" field of the corresponding "challenges" array element
   (which contains "type": "email-reply-00" as another field)
   contains token-part2. token-part2 should contain at least 128
   bits of entropy.

   4.  After responding to the authorization request the ACME server
   generates another token and a "challenge" email message with the
   subject "ACME: ", where  is the
   base64url encoded [RFC4648] of the token.  The ACME server MUST
   generate a fresh token for each S/MIME issuance request
   (authorization request), and token-part1 MUST contain at least
   128 bits of entropy.  The challenge email message structure is
   described in more details in Section 3.1.

   5.  The MUA retrieves and parses the challenge email message. The
   ACME client concatenates "token-part1" (received over email) and
   "token-part2" (received over HTTPS [RFC2818]) to create ACME
   "token", calculates keyAuthorization (as per Section 8.1 of
   [RFC8555]), then returns the base64url encoded SHA-256 digest
   [FIPS180-4] of the key authorization.  The MUA returns the
   base64url encoded SHA-256 digest obtained from the ACME client in
   the body of a response email message.  The response email message
   structure is described in more details in Section 3.2.

   6.  Once the MUA sends the response email, the ACME client can start
   polling the authorization URL (using POST-as-GET request) to see
   if the ACME server received and validated the response email
   message.  (See Section 7.5.1 of [RFC8555] for more details.)  If
   the "status" field of the challenge switches to "valid", then the
   ACME client can proceed with request finalization.  The
   Certificate Signing Request (CSR) MUST indicate the exact same
   set of requested identifiers as the initial newOrder request.
   For an identifier of type "email", the PKCS#10 [RFC2986] CSR MUST
   contain the requested email address in an extensionRequest
   attribute [RFC2985] requesting a subjectAltName extension. If a
   request to finalize an order is successful, the ACME server will
   return a 200 (OK) with an updated order object.  If the
   certificate is issued successfully, i.e. if the order "status" is
   "valid", then the ACME client can download the issued S/MIME
   certificate from the URL specified in the "certificate" field.

Best Regards,

Alexey

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

Re: [Acme] I-D Action: draft-ietf-acme-email-smime-10.txt

2020-11-12 Thread Alexey Melnikov




On 12/11/2020 11:53, Fraser Tweedale wrote:

On Thu, Nov 12, 2020 at 10:03:32AM +, Alexey Melnikov wrote:

Hi Fraser,

Thank you for your comments.

On 12/11/2020 08:14, Fraser Tweedale wrote:

Hello!

I have some issues with this proposal.

1. It does not adequately explain how the ACME client receives
token-part2.  "Over HTTPS" is vague.  Presumably it comes as a field
in the challenge object, e.g.

"challenges": [
  {
"type": "email-reply-01",
"url": "https://example.com/acme/chall/prV_B7yEyA4";,
"token-part2": "DGyRejmCefe7v4NfDGDKfA"
  }
]

Yes.

This needs to be fully specified in the document.

2. It is not stated whether, in addition to sending the response
email, the client also has to POST to the challenge URL as specified
in RFC 8555 Section 7.5.1 (e.g. to signal that the email has been
sent and the server should prepare to receive and process it).

This might not always be possible when a MUA that doesn't support this
proposal directly is to be used. But I agree that this needs to be
clarified one way or another.


Alexey, thank you for your quick reply.

If an MUA does not support this proposal directly (i.e.  with
integrated ACME client) it will also not be able to create the
order, or finalize it and retrieve certificate.

Right.

You have to use a
separate ACME client alongside the MUA.

Exactly.

Therefore it seems OK to
require the ACME client to POST to the challenge URL.  User workflow
would be something like:

1. Use ACME client to submit order, awaits challenge email.

2. Receives challenge email, construct response email (perhaps with
guidance/assistance of ACME client) and send.

3. Tell ACME client that response was sent.  ACME client POSTS to
challenge URL, polls authz resource and, if all went well,
finalizes order and emits certificate.

Yes. I am adding something like this to the draft right now.

I suggest explicitly requiring the client to POST to the challenge
URL to advise the server to prepare to receive and validate it.
This is what RFC 8555 implies a client should do, and facilitates
different approaches to server implementation.

Yes, based on feedback from other people I realised that this is
underspecified. I will add description of you points #1 and #2 in the
next revision.

3. What is the motivation for supporting both text/plain and
multipart/alternative in the body of the response email?  This
complicates server implementations, but I can't think why it would
be needed.  Please either explain why both options are needed,
otherwise could it be limited to text/plain?

Basically this needs to work with existing email clients as is and this
is not something that can always (or easily) be controlled by users. A
lot of them will generated multipart/alternative instead of text/plain,
especially if they want to include nicely formatted HTML.


Makes sense.  Could you please mention this reason in the document?


Sure.

Best Regards,

Alexey

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

Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)

2020-11-12 Thread Alexey Melnikov


Hi Ben,

On 06/11/2020 22:29, Benjamin Kaduk wrote:

Hi Alexey,

On Thu, Nov 05, 2020 at 11:07:02AM +, Alexey Melnikov wrote:

Hi Ben,

I am sending you a partial reply, as I am still editing the document
based on some of your more detailed comments:

Sure, happy to handle things in batches.


On 05/11/2020 08:03, Benjamin Kaduk via Datatracker wrote:


--
DISCUSS:
--

I have one point that I am not sure of the significance of and would
like to discuss further, and one point that I think has a fairly
clear/straightforward resolution.

One of the key properties of ACME is that its authenticator provides
assurance that both a party controlling the identifier to be certified
and the ACME client jointly assent to the certification request of that
identifier.  I'm trying to explore a bit more the "jointly assent" part,
and whether it is clear that all steps of the challenge/validation flow
are ultimatetly tied to the same order request.
In the validation flows for the challenge types from 8555, the full
token is returned to the ACME client, which then provides the token to
the entity that controls the identifier being certified, in order to set
up state to expect a verification attempt using that token.  In this
email validation flow, though, the token-part1 is *only* present in the
challenge email, so there is no thread of continuity that allows the
email account holder to tie the validation attempt to the specific
request (i.e., token).  Any message that comes in claiming to be an ACME
challenge would end up being treated as a validation attempt for the
pending request, so the ACME server (or a party pretending to be one)
does not have to provide any proof of knowledge of the pending
validation before the response email is generated.  Some key properties
here seem to include: there is a portion (token-part2) to the response
email that can only be provided by the ACME client, there is a part
(token-part1) to the response email that can only be provided by an
entity that can receive email at the email address being validated, and
that the validation attempt, response email, and ACME order request can
be tied together by unique identifiers.  It seems that we could achieve
all three of these by having the HTTPS response to the ACME client
include a token-part0 as well as the token-part2, with token-part0 being
used as the subject line of the challenge email and token-part1 being
conveyed in some fashion (whether body or headers) of the challenge
email.  Does such a scheme provide any useful properties that are not
provided by the current scheme?

We might need to have a conference call, as I don't fully understand
your concerns here. But let me think about this a bit more.

[We have scheduled a call, out of band.]

Maybe I can try to step through the http case and the email case.
I am sure I will miss some steps since the distinction between user, web
server/email operator, ACME client, and possibly other entities, can be
fuzzy at times.

For HTTP, it's something like:

1) user wants a cert
2) user makes ACME client create a new order
3) ACME server creates the order+challenge, returning token to ACME client
4) user gets token from ACME client and provisions the webserver to handle
   a challenge with that token
5) ACME server makes an HTTP validation query using the token value
6) webserver responds to challenge using key authorization
7) success

Note that in (4) the webserver knows what token to expect, so the
challenge/response are tightly tied to the particular order (because the
token value is tied to the order).

For email, it seems like we're proposing:

1) user wants a cert
2) user directs email client to direct ACME client to create a new order
3) ACME server creates the order+challenge, returns token-part2 to ACME
   client
4) user directs email client or other infrastructure to expect a challenge
   (including token-part2)
5) ACME server sends challenge email with token-part1
6) email client notes that an ACME challenge arrived, searches for
   information about any pending expected challenges, and finds token-part2
7) user/email client produces challenge response including key
   authorization (using token-part1 and token-part2)
Thank you for this. I agree that this level of details is definitely 
missing from the current draft and I will expand on the above in the 
next version of the draft.

The part in (6) where the email client has to search for all/any pending
expected challenges seems much weaker than in the HTTP case, as *any*
incoming message formatted like an ACME challenge could elicit the response
message.
As a side note: the above ("expecting challenges") is true for 
ACME-aware email client, but not for the case of unaware email client.

This would not directly leak token-part2 (IIUC -- there would be
a pre

Re: [Acme] I-D Action: draft-ietf-acme-email-smime-10.txt

2020-11-12 Thread Alexey Melnikov


Hi Fraser,

Thank you for your comments.

On 12/11/2020 08:14, Fraser Tweedale wrote:

Hello!

I have some issues with this proposal.

1. It does not adequately explain how the ACME client receives
token-part2.  "Over HTTPS" is vague.  Presumably it comes as a field
in the challenge object, e.g.

   "challenges": [
 {
   "type": "email-reply-01",
   "url": "https://example.com/acme/chall/prV_B7yEyA4";,
   "token-part2": "DGyRejmCefe7v4NfDGDKfA"
 }
   ]

Yes.

This needs to be fully specified in the document.

2. It is not stated whether, in addition to sending the response
email, the client also has to POST to the challenge URL as specified
in RFC 8555 Section 7.5.1 (e.g. to signal that the email has been
sent and the server should prepare to receive and process it).
This might not always be possible when a MUA that doesn't support this 
proposal directly is to be used. But I agree that this needs to be 
clarified one way or another.

I suggest explicitly requiring the client to POST to the challenge
URL to advise the server to prepare to receive and validate it.
This is what RFC 8555 implies a client should do, and facilitates
different approaches to server implementation.
Yes, based on feedback from other people I realised that this is 
underspecified. I will add description of you points #1 and #2 in the 
next revision.

3. What is the motivation for supporting both text/plain and
multipart/alternative in the body of the response email?  This
complicates server implementations, but I can't think why it would
be needed.  Please either explain why both options are needed,
otherwise could it be limited to text/plain?


Basically this needs to work with existing email clients as is and this 
is not something that can always (or easily) be controlled by users. A 
lot of them will generated multipart/alternative instead of text/plain, 
especially if they want to include nicely formatted HTML.


Best Regards,

Alexey

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

Re: [Acme] Erik Kline's No Objection on draft-ietf-acme-email-smime-10: (with COMMENT)

2020-11-05 Thread Alexey Melnikov


Hi Erik,

On 04/11/2020 07:35, Erik Kline via Datatracker wrote:

--
COMMENT:
--

[ section 2 ]

* Use the 8174 text?

Will do.

[ section 6 ]

* I think it's fair to all-caps RECOMMENDED the use of DNSSEC.


I will review this based on discussions with other ADs about DNSSEC.

Best Regards,

Alexey


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

Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)

2020-11-05 Thread Alexey Melnikov


Hi Ben,

I am sending you a partial reply, as I am still editing the document 
based on some of your more detailed comments:


On 05/11/2020 08:03, Benjamin Kaduk via Datatracker wrote:


--
DISCUSS:
--

I have one point that I am not sure of the significance of and would
like to discuss further, and one point that I think has a fairly
clear/straightforward resolution.

One of the key properties of ACME is that its authenticator provides
assurance that both a party controlling the identifier to be certified
and the ACME client jointly assent to the certification request of that
identifier.  I'm trying to explore a bit more the "jointly assent" part,
and whether it is clear that all steps of the challenge/validation flow
are ultimatetly tied to the same order request.
In the validation flows for the challenge types from 8555, the full
token is returned to the ACME client, which then provides the token to
the entity that controls the identifier being certified, in order to set
up state to expect a verification attempt using that token.  In this
email validation flow, though, the token-part1 is *only* present in the
challenge email, so there is no thread of continuity that allows the
email account holder to tie the validation attempt to the specific
request (i.e., token).  Any message that comes in claiming to be an ACME
challenge would end up being treated as a validation attempt for the
pending request, so the ACME server (or a party pretending to be one)
does not have to provide any proof of knowledge of the pending
validation before the response email is generated.  Some key properties
here seem to include: there is a portion (token-part2) to the response
email that can only be provided by the ACME client, there is a part
(token-part1) to the response email that can only be provided by an
entity that can receive email at the email address being validated, and
that the validation attempt, response email, and ACME order request can
be tied together by unique identifiers.  It seems that we could achieve
all three of these by having the HTTPS response to the ACME client
include a token-part0 as well as the token-part2, with token-part0 being
used as the subject line of the challenge email and token-part1 being
conveyed in some fashion (whether body or headers) of the challenge
email.  Does such a scheme provide any useful properties that are not
provided by the current scheme?
We might need to have a conference call, as I don't fully understand 
your concerns here. But let me think about this a bit more.

The more straightforward point is that the procedure in section 3
indicates that token-part2 is returned to the ACME client over HTTPS,
but the stated procedure does not otherwise involve an ACME client in
initiating the newOrder request.  I think we need to clarify the
interaction/relationship between end-user/email client UI/etc and the
ACME client in step 1.  In particular, I think that "[t]his document
doesn't prescribe how exactly S/MIME certificate issuance is initiated"
seems incompatible with requiring there to be an ACME client involved
(and the presumed newOrder ACME request, etc.) unless the "initiate"
operation is supposed to be the way by which the ACME client is
triggered to start the request.
Yes. When I wrote this text I was thinking either user pushing a button 
on a CA's website saying "initiate S/MIME certificate issuance for me", 
running a command line tool a la Let's Encrypt or pushing a button in an 
ACME-aware MUA. Can you suggest how to clarify this?

--
COMMENT:
--

The discuss point notwithstanding, if we assume that the current
validation process does provide the necessary linkage across steps, it
seems that the procedure would provide only similar properties to the
RFC 8555 validation flows -- I am having a hard time convincing myself
that we definitely have the 128-bit security level for all the
information paths at play.  It seems like having both token-part1 and
token-part2 each be 128+ bits would be fairly low-cost and would give
greater peace of mind that we are not opening up any 64-bit attacks.

Making them both 128 bits is fine with me.

Using "ACME:" as the Subject: marker for both challenge mail and
response mail potentially sets us up for various reflection/janus-like
attacks.
Can you elaborate on this? Responses would have some kind of prefix in 
front of "ACME" (e.g. "Re: ACME: ..."), so they will never be the same 
subjects as in challenges.

We could give some warnings about this in the security
considerations, or just indicate in-band whether it is a challenge or a
response...

Section 3

contains at least 64 bits of entropy.  (ACME server MUST generate
token afresh for each S/MIM

Re: [Acme] Barry Leiba's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)

2020-11-05 Thread Alexey Melnikov


Hi Barry,

On 29/10/2020 21:33, Barry Leiba wrote:


Hi, Alexey, and thanks for the response.  You responded to the first
message, rather than to the second, so you didn't pick up my first
DISCUSS point, repeated here:


I question why this is Informational, and the shepherd writeup doesn't really
explain it.  I get that this fills a gap, and that the working group wants to
see this adopted.  I don't get why, therefore, you aren't proposing a standard
here.  What is the point of making this Informational, and not Proposed
Standard... or Experimental, if you're less sure of whether it will work as
expected?
When asked in the WG there was not enough support to make it a Proposed 
Standard, in particular due to CA requirements for S/MIME evolving 
outside of IETF. The rest is above my paygrade, I am afraid. I just want 
this this to be published :-).



To the other points:


DISCUSS: That said, I don’t understand the need to specifically allow UTF-8
here.  If the subject only contains “ACME:”, FWS, and a base64 string, it will
always be ASCII.  Why are we talking about UTF-8 at all?

The idea is to be as compatible with existing software (e.g. MUAs and
web mail clients). I did some tests and some implementations
unconditionally use UTF-8 charset label even if the data is purely
ASCII. Thus the text above.

OK, I guess that's not a problem.  I might prefer a SHOULD for ASCII,
or some such, and inclusion of an explanation that ASCII is all that's
needed, and that UTF-8 is permitted only for compatibility.  Please
consider that, but this item is no longer at a DISCUSS level: we've
had the discussion.

Ok, I will add SHOULD for US-ASCII. Thank you for the discussion.

 The message MUST also pass
 DMARC validation [RFC7489], which implies DKIM and SPF validation
 [RFC7208].

Two things here, which apply to bullet 9 in Section 3.2 also:

1. DMARC does not imply DKIM *and* SPF validation: DMARC uses DKIM *or* SPF to
do Identifier Alignment.

Sloppy wording on my part. Would something like "which implies
compliance with DKIM [ref] and SPF [ref]" work better?

I think that "which implies validation of DKIM or SPF" is accurate and
better.  In any case, definitely "or", not "and".  But that's only if
we keep the DMARC bit, which is a more important discussion.


2. I have an issue with requiring the use of DMARC at this point, as it’s
specified only in an Informational document in the Independent stream.

This is an Informational document on IETF stream, so the bar is already
pretty low ;-). Besides you know that that DMARC itself is being revised.

That speaks to my first DISCUSS point, at the top of this message, and
is something we need to talk about.  Apart from that, if you want to
wait for the DMARC revision as Proposed Standard, sure.  I'm very much
not happy building standards around what we know to be a problematic,
non-standard protocol that we're working on revising.


No, I am really not happy with waiting for DMARC process to be finished.


In any
case, what’s the point of requiring DMARC?  It seems to me that the
authentication you need is provided by DKIM or S/MIME; what do you need from
DMARC?

We can't use S/MIME, as the whole point of this document is to get an
S/MIME certificate.

Umm...

5.  In order to prove authenticity of a challenge message, it MUST be
either DKIM [RFC6376] signed or S/MIME [RFC8551] signed.

...so you are using S/MIME signing.


I might have got myself confused here, because there is assymetry here. 
S/MIME can be used for ACME challenges, but it can't be used for ACME 
responses.



I suppose just requiring DKIM is fine, but properly configured SPF will
get an extra assurance that the domain owner has a properly (securely,
for some definition of securely) configured email system. So I am open
to suggestions.

You haven't answered what you're trying to get from DMARC.  You can
say that the message has to be signed.  Doesn't that accomplish what
you need?  It seems to me that what DMARC provides beyond that is
Identifier Alignment and sender policy checking, which don't seem to
provide anything you need for this protocol.

I want identifier alignment for sure. Policy checking not so much.

I'd like to understand
why the protocol needs them, or what else it is that it needs from
DMARC.  I don't see why you get any benefit from SPF either -- in
conjunction with DKIM, SPF is only useful in cases where the DKIM
signature is broken -- so let's include that in the discussion as
well.


Actually, if DKIM signature is fine, but SPF is broken, this is still a 
reason to suspect that something is not right.


But I think I will let go of SPF and will remove DMARC/SPF. I will cut & 
paste specific text about identifier alignment into my draft.



 The "Auto-Submitted" header field SHOULD
 include the "type=acme" parameter.

Why not MUST?  What are the consequences of not doing this, and why might it be
hard to?

This is for backward comp

Re: [Acme] Murray Kucherawy's No Objection on draft-ietf-acme-email-smime-10: (with COMMENT)

2020-11-05 Thread Alexey Melnikov


Hi Murray,

Thank you for your comments.

On 05/11/2020 05:46, Murray Kucherawy via Datatracker wrote:

--
COMMENT:
--

I support Barry's DISCUSS, especially the bit that references DMARC.

Ok, I will remove any reference to DMARC. See my upcoming reply to Barry.


You might mention in Security Considerations that the DKIM and DMARC RFCs
discuss their dependence on the DNS as well, and their respective
vulnerabilities.

Ok, I will add that.

It seems to me that the second paragraph of Security Considerations says
approximately the same thing that the (1) bullet does in the same section.


I will review.

Best Regards,

Alexey

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

Re: [Acme] Barry Leiba's Discuss on draft-ietf-acme-email-smime-10: (with DISCUSS and COMMENT)

2020-10-29 Thread Alexey Melnikov


Hi Barry,

Thank you for your comments.

Replying to all but a few of your comments below:

On 28/10/2020 16:55, Barry Leiba via Datatracker wrote:

--
DISCUSS:
--

— Section 3.1 —

[RFC2231] encoding of the message Subject header field
MUST be supported, but when used, only "UTF-8" and "US-ASCII"
charsets MUST be used (i.e. other charsets MUST NOT be used).

NOT DISCUSS: I don’t like the second use of MUST: it’s confusing (for example,
it’s not the case that you always MUST use both charsets).  I suggest this:

NEW
[RFC2231] encoding of the message Subject header field
MUST be supported, and when used, only the "UTF-8" and "US-ASCII"
charsets are allowed: other charsets MUST NOT be used.
END

Done.

DISCUSS: That said, I don’t understand the need to specifically allow UTF-8
here.  If the subject only contains “ACME:”, FWS, and a base64 string, it will
always be ASCII.  Why are we talking about UTF-8 at all?
The idea is to be as compatible with existing software (e.g. MUAs and 
web mail clients). I did some tests and some implementations 
unconditionally use UTF-8 charset label even if the data is purely 
ASCII. Thus the text above.

The message MUST also pass
DMARC validation [RFC7489], which implies DKIM and SPF validation
[RFC7208].

Two things here, which apply to bullet 9 in Section 3.2 also:

1. DMARC does not imply DKIM *and* SPF validation: DMARC uses DKIM *or* SPF to
do Identifier Alignment.
Sloppy wording on my part. Would something like "which implies 
compliance with DKIM [ref] and SPF [ref]" work better?

2. I have an issue with requiring the use of DMARC at this point, as it’s
specified only in an Informational document in the Independent stream.
This is an Informational document on IETF stream, so the bar is already 
pretty low ;-). Besides you know that that DMARC itself is being revised.

In any
case, what’s the point of requiring DMARC?  It seems to me that the
authentication you need is provided by DKIM or S/MIME; what do you need from
DMARC?


We can't use S/MIME, as the whole point of this document is to get an 
S/MIME certificate.


I suppose just requiring DKIM is fine, but properly configured SPF will 
get an extra assurance that the domain owner has a properly (securely, 
for some definition of securely) configured email system. So I am open 
to suggestions.



--
COMMENT:
--

— Section 2 —
Please use the new BCP 14 boilerplate and add a normative reference to RFC 8174.

— Section 3 —

This document defines a new Identifier Type "email" which corresponds
to an (all ASCII) email address [RFC5321] or Internationalized Email
addresses [RFC6531].  (When Internationalized Email addresses are
used, both U-labels and A-labels [RFC5890] are allowed in the domain
part.)

Why “an email address” (singular) when it’s ASCII and “email addresses”
(plural) when they’re internationalized?  I think you mean for this to be a
single address in either case.

Yes, good point.

Also, why capitalize “internationalized”, and
why capitalize “email” only when it’s internationalized?

Probably because I cut and pasted this from somewhere ;-).

I’m also not fond of
putting important things and normative requirements in parentheses.

Good point. Removed.

I suggest this (and similar comments apply to Section 5.1):

NEW
This document defines a new Identifier Type "email" that identifies
an email address.  The address can be all ASCII [RFC5321] or
internationalized [RFC6531]; when an internationalized email
address is used, the domain part can contain both U-labels and
A-labels [RFC5890].
END

Changed, thank you.

2.  The ACME server (run by the Certificate Authority or their
authorized third party) generates a "challenge" email message
with the subject "ACME: ", where  is
the base64url encoded [RFC4648] first part of the token, which
contains at least 64 bits of entropy.  (ACME server MUST generate
token afresh for each S/MIME issuance request.)

When I get to “the token,” my first thought is “What token?”  And in the
description that follows it isn’t clear whether the 64 bits of entropy applies
to token-part1, or to the token itself.  I suggest this:

NEW
2.  The ACME server (run by the Certificate Authority or their
authorized third party) generates a token and a "challenge"
email message with the subject "ACME: ", where
 is the base64url encoded [RFC4648] first part of
the token.  The ACME server MUST generate a fresh token for each
S/MIME issuance request, and token-part1 MUST contain at least
64 bits of entropy.
END

This reads better, thank you.

Re: [Acme] I-D Action: draft-ietf-acme-email-smime-10.txt

2020-10-27 Thread Alexey Melnikov


On 27/10/2020 13:49, internet-dra...@ietf.org wrote:


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-email-smime-10
https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-10


The last 2 versions addressed GenArt and SecDir comments.

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

Re: [Acme] Genart last call review of draft-ietf-acme-email-smime-08

2020-09-24 Thread Alexey Melnikov


Hi Peter,

Thank you for your detailed review. My answers/comments are below:

On 09/07/2020 09:21, Peter Yee via Datatracker wrote:

Reviewer: Peter Yee
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-acme-email-smime-08
Reviewer: Peter Yee
Review Date: 2020-07-09
IETF LC End Date: 2020-07-09
IESG Telechat date: Not scheduled for a telechat

Summary: This Informational Track draft defines an ACME challenge to be used in
the issuance of S/MIME certificates. I have points I'd like to see clarified as
well as some nits that need to be cleaned up before I would declare it ready.
[Ready with Issues]

Major issues: None

Minor issues:

General: this draft doesn’t frame the operation of the ACME request that uses
this challenge. It mentions a token-part2 that magically arrives over HTTPS,
but gives no indication of why this happened or what causes the generation of
the email challenge. Some context around when this challenge is invoked and
what signals the ACME server that this challenge is required would be helpful.

Good point. I've added a paragraph on this.

Page 3, 1st enumerated item: I find the definition of “first part of the token”
to be far looser than it needs to be. You merely say that it needs to contain
64 bits of entropy. Is there an upper bound?

No. I don't believe base ACME has upper bound on tokens either.

Do you need to say anything about it not being reused in another challenge?

This was the intent and I clarified that.

Page 4, example Subject header field: it would be much better if you gave an
actual example of a base64url-encoded value here rather than some explanatory
text in much the same way you have given actual, legal values for Date,
Message-ID, etc.

Ok.

Page 5, section 3.2, 1st enumerated item, 1st sentence: it doesn’t seem like
you particularly care what is in front of “ACME:”. While you say it’s typically
“Re:” , it could be anything. Would there ever be a case to reject a response
message based on what appears before “ACME:”? I’d like to see a little more
rigor here on what’s required. Some characters followed by a colon and a white
space before the “ACME:” suffices?


I would like for email to use standardardized reply prefix, but there 
are variations. E.g. using "Re[]". And don't get me started on 
localized versions, which should be banned from the face of the Earth ;-).


You do have a point that probably anything before "ACME:" can be 
allowed. I will clarify that.



Page 5, section 3.2, 6th enumerated item, 2nd sentence: where it says
“calculated based on”…, it would be preferable to point back to page 3, 2nd
enumerated item where you explicitly indicate that the two token parts are
concatenated.

I clarified that.

Page 5, section 3.2, 6th enumerated item, last sentence: I’m assuming that
ACME-unaware clients are only receiving this email in the case of the email
being bounced to an administrator or returned to the user.
I suppose ACME server processing can be manual, but this is more likely 
to be a misconfiguration.

In either case, it’s
not the client that will be reading this outside-the-block text, it’s a user.
There’s no processing to be done on that text.
Yes, it will be read by a user. I am not sure what needs changing in the 
text.

Page 7, example Subject header field: use a real value here, please.

Nits/editorial comments:


I've applied these and the changes will appear in -09. Use of English 
language articles is not my strong point :-)


Best Regards,

Alexey

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

Re: [Acme] ACME email validation

2020-06-26 Thread Alexey Melnikov


Hi Brian,


On 19/06/2020 23:08, Brian Sipos wrote:

Sebastian,
Thank you very much for this clarification. This would apply to all 
message exchange validation types then (including the one I'm looking 
into).
I notice that the email validation draft does not mention multiple 
attempts from different sources, which RFC8555 does discuss briefly 
[1]. Is there an expectation that an email validation would be 
attempted from multiple ACME server addresses,


If you meant "ACME server IP addresses", then the answer is "yes". 
Section 10.2 text of RFC 8555 applies to the HTTP portion of validation.


If you asking whether it is a good idea for ACME server to use different 
SMTP submission servers when sending ACME challenges, then again this is 
a good idea. But because of how many email systems are configured, there 
is typically a single point in originating network where all traffic can 
be MITMed.


If you meant "ACME server email addresses", then the answer is "no". 
Even though this is not prohibited.



or is a MITM attack on messaging not handled because of the nature of 
email security?


Right. Although use of MTA-to-MTA TLS is becoming a new norm, which 
helps a bit.



Best Regards,

Alexey



[1] https://tools.ietf.org/html/rfc8555#section-10.2 





*From:* Sebastian Nielsen
*Sent:* Friday, June 19, 2020 13:25
*To:* Brian Sipos; acme@ietf.org
*Cc:* alexey.melni...@isode.com
*Subject:* SV: [Acme] ACME email validation

The reason is to prevent email spoofing.

In the case of .well-known or DNS validation, or ALPN, you publish a 
record where ACME fetches. That can’t be spoofed, because ACME itself 
searches for the record, you can’t send ACME a record and have it accept..


In the email case, you instead send ACME the response back via email, 
which could be spoofed, if you had access to only the ACME client, if 
whole the token was given by ACME client.


And in the second case, if whole token was given by email, it could be 
a private key that is being used for another thing – lets say signing 
internal certificates via HSM, where the signing system is misused to 
gain SMIME certificates by signing the token, without having access to 
the corresponding ACME client where the private key is installed. By 
requiring 2 parts of a token, you ensure the client has access to BOTH 
the email inbox AND the ACME client, AND the private key aswell.


To ensure that the person replying to the email BOTH have access to 
the email account AND the ACME client, he must join 2 parts of a 
secure token, and then use his private key to calculate the value.


*Från:*acme-boun...@ietf.org  *För *Brian Sipos
*Skickat:* den 19 juni 2020 00:13
*Till:* acme@ietf.org
*Kopia:* alexey.melni...@isode.com
*Ämne:* [Acme] ACME email validation

All,

In a recent draft I created for using ACME for non-web-PKI 
verification [1] I see that there are many similarities with an 
earlier draft for email verification [2]. In that email protocol, the 
challenge token is split into two parts which arrive at the email 
validation agent through two paths: token-part1 via the validation 
channel, and token-part2 via the ACME channel.


Is there a technical reason why the token is split into two parts like 
this? Is replying with the proper corresponding Key Authorization not 
sufficient to prove ownership of the email address?


I don't see any similar challenge token splitting in other ACME drafts 
and I don't see anything obvious in [2] to indicate why the split is 
useful or needed. I also didn't see any related discussion earlier on 
the ACME mailing list.


Thank you,

Brian S.

[1] https://datatracker.ietf.org/doc/html/draft-sipos-acme-dtnnodeid-00

[2] https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-08

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

Re: [Acme] AD Review of draft-ietf-acme-email-smime-07

2020-06-26 Thread Alexey Melnikov


On 25/06/2020 19:48, Roman Danyliw wrote:


Hi Alexey!


-Original Message-
From: Acme  On Behalf Of Alexey Melnikov
Sent: Tuesday, June 16, 2020 11:38 AM
To: Roman Danyliw ; IETF ACME 
Subject: Re: [Acme] AD Review of draft-ietf-acme-email-smime-07

Hi Roman,

On 22/05/2020 15:54, Roman Danyliw wrote:

[snip]


** Section 7.  Per "Any claims about the correctness orfitness-for-purpose

of the email address must be otherwise assured", I don't follow the intent of
this text.  For example, what is the "correctness ... of the email address"?  
What
is meant by "assurances"?

This was based on feedback from one of reviewers. It is basically saying
that issued ACME certificates don't vouch for anything other than "this
email seems to belong to the entity that requested it". Does this make
sense?

This cautionary clarification makes more sense to me.  Can you fold in some 
language to that effect into a revision.

Given that this is the last of that changes, this update can be made with other 
IETF LC feedback.

Ok, I will do this in -09.


Thanks,
Roman






Best Regards,

Alexey


___
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] Last Call: (Extensions to Automatic Certificate Management Environment for end user S/MIME certificates) to Proposed Standard

2020-06-26 Thread Alexey Melnikov


Hi SM,

On 25/06/2020 20:56, S Moonesamy wrote:

Hi Alexey,
At 11:57 AM 25-06-2020, The IESG wrote:
The IESG has received a request from the Automated Certificate 
Management
Environment WG (acme) to consider the following document: - 
'Extensions to

Automatic Certificate Management Environment for end
   user S/MIME certificates'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits 
final

comments on this action. Please send substantive comments to the


In Section 3.1, there is the following in Point 3 and 5: "The message 
MAY contain Reply-To header field."  Is the duplication a mistake?

Yes, cut & paste error.
Point 6 states that its purpose is to "prove authenticity of a 
challenge message".  How does DKIM prove authenticity [1]?

See my other reply.

Why is there a requirement that the message has to pass DMARC validation?
Because this is the best mail indistry has to offer to prevent message 
spoofing.

  Has forwarding been taken into account [2]?


I don't think my proposal is inteded to work with mailing list 
forwarding. This sounds pretty dangerous and defeats the prescribed 
recipient email validation check. Maybe the document should say 
something about this.


If you are thinking about recipient end alias-type forwarding, then I 
can add some text that validation has to happen before forwarding, but 
this ACME mechanism might still break if the From header field email 
address of the response message doesn't match the email address used to 
request the certificate for.


Best Regards,

Alexey



Regards,
S. Moonesamy

1. Please see Section 5.4 of RFC 6376.
2. That does not work well with SPF.
___
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] Last Call: (Extensions to Automatic Certificate Mana

2020-06-26 Thread Alexey Melnikov


On 25/06/2020 22:40, Sebastian Nielsen wrote:


1: Of course DKIM can be used to validate the authenticity of the email such
as it has been sent from the specified domain.


Right. And the list of header fields to sign in case DKIM is used 
protects most important header fields that must not be tempered with.



2: Validation response messages should NOT be forwarded! Normally, you would
send a response message like from sebast...@sebbe.eu to
certvalid...@ca.example.org
Of course, if ca.example.org is in full control of all email servers, they
can easily do the validation at the leaf server ca.example.org, and then
forward the email message to a internal server for SMIME issuance, for
example by adding a encrypted and signed header with the validation, or
communicating out-of-band - for example with a MySQL server, that the
message X is propely SPF and DKIM validated.

The type of forwarding SPF don't work with, would be if
certvalid...@ca.example.org was forwarded to lets say
suspicious...@gmail.com then if I send a validation reponse to
certvalid...@ca.example.org from sebast...@sebbe.eu , validation would fail
@ GMAIL when they receive the message from ca.example.org which is a server
not on my authorization list.

And a CA running an email server that forwards to an server they are not in
full control of, is a HUGE security risk for SMIME issuance - unless they
have proper agreements in place - for example a subCA that forwards their
validations to the main CA, but still want a "branded" email adress for
their ACME validations - but then their agreements could easily include that
the subCA should do the validations at the leaf server, and then add
information to the email that allows the main CA to see that SPF and DKIM
was propely validated.
Or include the client IP in the message, signed securely, so the main CA can
validate SPF.


I basically agree with this.



-Ursprungligt meddelande-
Från: acme-boun...@ietf.org  För S Moonesamy
Skickat: den 25 juni 2020 21:59
Till: Alexey Melnikov 
Kopia: r...@cert.org; acme@ietf.org; draft-ietf-acme-email-sm...@ietf.org;
acme-cha...@ietf.org
Ämne: Re: [Acme] Last Call:  (Extensions
to Automatic Certificate Mana

Hi Alexey,
At 11:57 AM 25-06-2020, The IESG wrote:

The IESG has received a request from the Automated Certificate
Management Environment WG (acme) to consider the following document: -
'Extensions to Automatic Certificate Management Environment for end
user S/MIME certificates'
as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the

In Section 3.1, there is the following in Point 3 and 5: "The message MAY
contain Reply-To header field."  Is the duplication a mistake?

Point 6 states that its purpose is to "prove authenticity of a challenge
message".  How does DKIM prove authenticity [1]?

Why is there a requirement that the message has to pass DMARC validation?
Has forwarding been taken into account [2]?

Regards,
S. Moonesamy

1. Please see Section 5.4 of RFC 6376.
2. That does not work well with SPF.

___
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-email-smime-08.txt

2020-06-16 Thread Alexey Melnikov


On 16/06/2020 16:47, 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   : Extensions to Automatic Certificate Management 
Environment for end user S/MIME certificates
 Author  : Alexey Melnikov
Filename: draft-ietf-acme-email-smime-08.txt
Pages   : 10
Date: 2020-06-16

Abstract:
This document specifies identifiers and challenges required to enable
the Automated Certificate Management Environment (ACME) to issue
certificates for use by email users that want to use S/MIME.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-email-smime-08
https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-08


This version addresses comments from Roman's AD review.


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

Re: [Acme] AD Review of draft-ietf-acme-email-smime-07

2020-06-16 Thread Alexey Melnikov

Hi Roman,

On 22/05/2020 15:54, Roman Danyliw wrote:

** Section 6.

-- Recommend explicitly naming the registries being updated
-- Per the challenge type, all of the fields in the registry aren't described
here
-- Per the challenge type, the text in Section 3 says that the challenge type is
"email-reply-00" (not "email-reply" as described here)

I recommend something like the following:
NEW:
6.1. Identifier Type

Per this document, a new type has been added to the "ACME Identifier Types" registry
defined in Section 9.7.7 of [RFC8555] with Label "email" and a Reference to this document.

6.2. Challenge Types

Per this document, a new entry have been added to the "ACME Validation Methods"
registry defined in Section 9.7.8 of [RFC8555]. This entry is as follows:

** Section 7. Per "Any claims about the correctness orfitness-for-purpose of the email address must
be otherwise assured", I don't follow the intent of this text. For example, what is the
"correctness ... of the email address"? What is meant by "assurances"?

This was based on feedback from one of reviewers. It is basically saying
that issued ACME certificates don't vouch for anything other than "this
email seems to belong to the entity that requested it". Does this make
sense?

Best Regards,

Alexey

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

Re: [Acme] AD Review of draft-ietf-acme-email-smime-07

2020-05-29 Thread Alexey Melnikov

Hi Roman,

Thank you for your detailed review.

On 22/05/2020 15:54, Roman Danyliw wrote:

Hi!

I completed my AD review of draft-ietf-acme-email-smime-07. Thanks for the
work on this document. Here is my feedback:

** What was the thinking behind the document status being informational?
I don't think there was much thought or discussion of this point. I am
flexible. I think when I started it was not very clear how much
support/interest there were in this, but I noticed more interest over time.

** Section 3.1. This section has no (normative) guidance on populating the To
and From fields.

The To is the email address of the entity which requested S/MIME
certificate issuance. I will clarify that.

There is no guidance regarding the From, as it is implementation choice.
(I am not a fan of mandating specific email address for this, like
postmaster@) Do you think this needs to be stated explicitly?

** Section 3.1. Step 5. Per "If S/MIME signing is used to prove authenticity of the
challenge message, then multipart/signed or "application/pkcs7-mime;
smime-type=signed-data;" media type should be used", is there is a reason that this
should is not normative (i.e., SHOULD)?
This is just restating requirements from other documents, but also
emphasizing that both common alternatives are allowed here. I don't
think this needs normative language.

** Section 6.

-- Recommend explicitly naming the registries being updated
-- Per the challenge type, all of the fields in the registry aren't described
here

I will have a look at these.

-- Per the challenge type, the text in Section 3 says that the challenge type is
"email-reply-00" (not "email-reply" as described here)
Thank you for spotting this, I need to make sure that it is the same
everywhere. I've changed the document to say "email-reply" everywhere.

I recommend something like the following:
NEW:
6.1. Identifier Type

Per this document, a new type has been added to the "ACME Identifier Types" registry
defined in Section 9.7.7 of [RFC8555] with Label "email" and a Reference to this document.

6.2. Challenge Types

Per this document, a new entry have been added to the "ACME Validation Methods"
registry defined in Section 9.7.8 of [RFC8555]. This entry is as follows:

** Editorial nits:
-- Section 3. Typo. s/posession/posession/

I think you meant "possession". Fixed.

-- Section 4. As this document is now headed out of the WG, it seems like it
should be removed.

Removed.

-- Section 7. Typo. s/can can/can/

Fixed.

-- Section 7. Editorial. For readability, I would avoid nested parentheses.

OLD
(by posessing user's password or a secret derived from it that can give read and reply
access ("password equivalent" information), or by being given permissions to
act on user's behalf using email delegation feature)

NEW
(by possessing a user's password or a secret derived from it that can give read and reply
access, such as "password equivalent" information; or by being given
permissions to act on user's behalf using email delegation feature)

Done.

Best Regards,

Alexey

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

Re: [Acme] WG last call for draft-ietf-acme-email-smime-06

2020-05-05 Thread Alexey Melnikov


Hi,

On 04/05/2020 18:48, Ben Schwartz wrote:
On Sun, May 3, 2020 at 1:36 AM Ryan Sleevi <mailto:ryan-i...@sleevi.com>> wrote:



On Sat, May 2, 2020 at 2:11 PM Ben Schwartz
mailto:40google@dmarc.ietf.org>> wrote:


On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov
mailto:alexey.melni...@isode.com>>
wrote:

Hi Ben,

On 21/04/2020 01:12, Ben Schwartz wrote:


On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov
mailto:alexey.melni...@isode.com>> wrote:

Hi Ben,

My apologies for missing your email in March:


And mine for this delayed response.

On 12/03/2020 20:42, Ben Schwartz wrote:

Section 3 says token-part1 "contains at least 64 bit
of entropy", but Section 3.1 says token-part1 "MUST
be at least 64 octet long after decoding".  Is this
difference deliberate?


No, I obviously made a typo when saying octets. I
will fix.


Fixed.



Also 64 octets of entropy is a _lot_.  RFC 8555 says
"the token is required to contain at least 128 bits
of entropy".

The draft seems to be oriented entirely toward use
with e-mail clients that have a built-in ACME-S/MIME
client.  I'm a bit disappointed that the draft
doesn't accommodate users with "naive" email clients
very well, e.g. by allowing customized subject lines.


Actually, I was trying to accommodate naive email
clients, but it was a fine balance trying to specify
minimal requirements.

Can you suggest some specific text to change and then
we can discuss whether or not it should be done? My
thinking about the Subject header field was that I
wanted to have a unique subject (so that ACME email
messages are easily findable). I also wanted to allow
the token in the subject for APIs that can easily
access Subject and not other header fields.

In that case, I would suggest "... subject ending with
"(ACME: )", where ...". That would allow the
first part of the subject (most likely to be seen by a
human) to be human-readable.


After thinking a bit more about this:

As ACME servers are generating ACME challenge emails, the
requirement on them is stricter (they create the first
message in an email thread). I am tempted to leave this as
is. Can you think of a case where ACME servers would be
unable to comply with this restriction?

My concern is that users will not know what to do if they
receive an email whose subject line is "ACME:
awlkNSdpijawrfz...".  Users are used to seeing emails whose
subject line is "Please verify your email address" or "Confirm
your email".  (My inbox is full of them.)  I see no reason to
disallow that here.

Mandating that the subject line be non-human-readable seems
like an unnecessary barrier to adoption.


Are you expecting humans to be the primary interaction point?


Ideally, ACME-aware mail clients will handle these messages in some 
beautiful, mostly-invisible way, but mail clients don't update as fast 
as browsers.  Even many years after most users have ACME-aware 
clients, I think a sizable fraction will have non-aware clients.

Right.


It almost seems that ensuring human unfriendliness is a feature,
not a bug, towards the goal of automation.


That was my expectation after reading draft-06, but Alexey explained 
that human-friendliness was in-scope, hence my suggestions.


Obviously human-friendliness for non ACME aware email clients and ease 
of implementation in ACME aware email clients are in conflict. I would 
be happy to use some compromise if a good balance can be found.



This structure seems especially important if it has a chance to be
adopted by publicly trusted CAs. One of the big concerns with
existing validation approaches is bodies that are rich-text with
links used for approval, and for which anti-spam or scanning
engines inspect (“click”) and cause improper authorizations.


According to this draft, authorization requires sending a specially 
formed reply email, so I think the risk of a scanning engine 
accidentally authorizing is low.


The more structure, the better, towards preventing accidental
authorizations.


Best Regards,

Alexey

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

Re: [Acme] WG last call for draft-ietf-acme-email-smime-06

2020-05-05 Thread Alexey Melnikov


Hi,

On 03/05/2020 06:36, Ryan Sleevi wrote:


On Sat, May 2, 2020 at 2:11 PM Ben Schwartz 
<mailto:40google@dmarc.ietf.org>> wrote:




On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov
mailto:alexey.melni...@isode.com>> wrote:

Hi Ben,

On 21/04/2020 01:12, Ben Schwartz wrote:


On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov
mailto:alexey.melni...@isode.com>> wrote:

Hi Ben,

My apologies for missing your email in March:


And mine for this delayed response.

On 12/03/2020 20:42, Ben Schwartz wrote:

Section 3 says token-part1 "contains at least 64 bit of
entropy", but Section 3.1 says token-part1 "MUST be at
least 64 octet long after decoding".  Is this difference
deliberate?


No, I obviously made a typo when saying octets. I will fix.


Fixed.



Also 64 octets of entropy is a _lot_.  RFC 8555 says
"the token is required to contain at least 128 bits of
entropy".

The draft seems to be oriented entirely toward use with
e-mail clients that have a built-in ACME-S/MIME client. 
I'm a bit disappointed that the draft doesn't
accommodate users with "naive" email clients very well,
e.g. by allowing customized subject lines.


Actually, I was trying to accommodate naive email
clients, but it was a fine balance trying to specify
minimal requirements.

Can you suggest some specific text to change and then we
can discuss whether or not it should be done? My thinking
about the Subject header field was that I wanted to have
a unique subject (so that ACME email messages are easily
findable). I also wanted to allow the token in the
subject for APIs that can easily access Subject and not
other header fields.

In that case, I would suggest "... subject ending with
"(ACME: )", where ...".  That would allow the
first part of the subject (most likely to be seen by a human)
to be human-readable.


After thinking a bit more about this:

As ACME servers are generating ACME challenge emails, the
requirement on them is stricter (they create the first message
in an email thread). I am tempted to leave this as is. Can you
think of a case where ACME servers would be unable to comply
with this restriction?

My concern is that users will not know what to do if they receive
an email whose subject line is "ACME: awlkNSdpijawrfz...".  Users
are used to seeing emails whose subject line is "Please verify
your email address" or "Confirm your email".  (My inbox is full of
them.)  I see no reason to disallow that here.

Mandating that the subject line be non-human-readable seems like
an unnecessary barrier to adoption.


Are you expecting humans to be the primary interaction point? It 
almost seems that ensuring human unfriendliness is a feature, not a 
bug, towards the goal of automation.


This structure seems especially important if it has a chance to be 
adopted by publicly trusted CAs. One of the big concerns with existing 
validation approaches is bodies that are rich-text with links used for 
approval, and for which anti-spam or scanning engines inspect 
(“click”) and cause improper authorizations. The more structure, the 
better, towards preventing accidental authorizations.


Let me try to elaborate on the current choice and talk about 
alternatives. In general there are 3 ways how an ACME email challenge be 
conveyed in email:


1) In the subject line. Some structure would be helpful for automated 
software.


2) In a new header field.

3) In the body of the message, e.g. using "---BEGIN ACME CHALLENGE---" 
line in text/plain or the like.



Unfortunately all of these have their downsides:

#1 is unfriendly to users and can possibly trigger antispam processing. 
(Not sure how much of an issue the last part is)


#2 might not be accessible from libraries that don't support retrieval 
of arbitrary email header fields. (I am not sure how big of a deal this 
is, but I've heard some claims about that.) Also, non ACME aware clients 
might not be able to show this header field, making them unusable for 
manual processing.


#3 would either require use of text/plain (for simplicity of automated 
processing) or it would require HTML parser with downconversion to 
text/plain. I think the latter choice is a rather high barrier of entry 
for implementations that are not fully capable email clients, which I 
suspect would be too hight for some ACME servers.



So I am open to suggestions about the best choice. I think using some 
st

Re: [Acme] WG last call for draft-ietf-acme-email-smime-06

2020-05-02 Thread Alexey Melnikov

Hi Ben,

On 21/04/2020 01:12, Ben Schwartz wrote:
>
> On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov
> mailto:alexey.melni...@isode.com>> wrote:
>
> Hi Ben,
>
> My apologies for missing your email in March:
>
>
> And mine for this delayed response.
>
> On 12/03/2020 20:42, Ben Schwartz wrote:
>> Section 3 says token-part1 "contains at least 64 bit of entropy",
>> but Section 3.1 says token-part1 "MUST be at least 64 octet long
>> after decoding".  Is this difference deliberate?
>
> No, I obviously made a typo when saying octets. I will fix.
>
Fixed.
>
>> Also 64 octets of entropy is a _lot_.  RFC 8555 says "the token
>> is required to contain at least 128 bits of entropy".
>>
>> The draft seems to be oriented entirely toward use with e-mail
>> clients that have a built-in ACME-S/MIME client.  I'm a bit
>> disappointed that the draft doesn't accommodate users with
>> "naive" email clients very well, e.g. by allowing customized
>> subject lines.
>
> Actually, I was trying to accommodate naive email clients, but it
> was a fine balance trying to specify minimal requirements.
>
> Can you suggest some specific text to change and then we can
> discuss whether or not it should be done? My thinking about the
> Subject header field was that I wanted to have a unique subject
> (so that ACME email messages are easily findable). I also wanted
> to allow the token in the subject for APIs that can easily access
> Subject and not other header fields.
>
> In that case, I would suggest "... subject ending with "(ACME:
> )", where ...".  That would allow the first part of the
> subject (most likely to be seen by a human) to be human-readable.

After thinking a bit more about this:

As ACME servers are generating ACME challenge emails, the requirement on
them is stricter (they create the first message in an email thread). I
am tempted to leave this as is. Can you think of a case where ACME
servers would be unable to comply with this restriction?

ACME responses already allow arbitrary prefix to accommodate naive clients.

> Similarly, for Section 3.2. Point 6, I would relax the requirement to
> state that this block must appear somewhere in the body.  That way, if
> the user sees the response message, it can provide some explanation of
> what is going on.
Good idea. Changed.
> For Section 3.1 Point 5, I don't understand why the body is restricted
> to text/plain.  In particular, I think hyperlinks to explanations and
> instructions are likely to be helpful.  I also wonder whether support
> for multipart/multilingual could be useful.
> The body is irrelevant to ACME-aware clients, so it seems like there
> could be a lot of freedom in how this is constructed.

This is true for the challenge email.

There is a requirement on S/MIME (if used) to provide header protection,
but I agree that otherwise the body structure can be pretty flexible.

> Most email clients automatically convert HTTPS URLs to hyperlinks,
> which should make the silly schemes I'm imagining possible, but not
> very attractive, for ordinary users.
>
> Best Regards,
>
> Alexey
>
>> I assume this is deliberate, perhaps because of a desire to use
>> short-TTL S/MIME certificates that would be impractical to
>> provision manually, but the draft doesn't mention a rationale.
>>
>> On Thu, Mar 12, 2020 at 2:52 PM Salz, Rich
>> > <mailto:40akamai@dmarc..ietf.org>> wrote:
>>
>> This mail begins a one-week working group last call on
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/?include_text=1
>>
>>  
>>
>> If you have comments or issues, please post here.
>>
>>  
>>
>> If anyone wants to be a document shepherd, please contact the
>> chairs.
>>
Best Regards,

Alexey


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

Re: [Acme] WG last call for draft-ietf-acme-email-smime-06

2020-04-01 Thread Alexey Melnikov


Hi Ben,

My apologies for missing your email in March:

On 12/03/2020 20:42, Ben Schwartz wrote:
Section 3 says token-part1 "contains at least 64 bit of entropy", but 
Section 3.1 says token-part1 "MUST be at least 64 octet long after 
decoding".  Is this difference deliberate?


No, I obviously made a typo when saying octets. I will fix.

Also 64 octets of entropy is a _lot_.  RFC 8555 says "the token is 
required to contain at least 128 bits of entropy".


The draft seems to be oriented entirely toward use with e-mail clients 
that have a built-in ACME-S/MIME client.  I'm a bit disappointed that 
the draft doesn't accommodate users with "naive" email clients very 
well, e.g. by allowing customized subject lines.


Actually, I was trying to accommodate naive email clients, but it was a 
fine balance trying to specify minimal requirements.


Can you suggest some specific text to change and then we can discuss 
whether or not it should be done? My thinking about the Subject header 
field was that I wanted to have a unique subject (so that ACME email 
messages are easily findable). I also wanted to allow the token in the 
subject for APIs that can easily access Subject and not other header fields.


Best Regards,

Alexey

I assume this is deliberate, perhaps because of a desire to use 
short-TTL S/MIME certificates that would be impractical to provision 
manually, but the draft doesn't mention a rationale.


On Thu, Mar 12, 2020 at 2:52 PM Salz, Rich 
> wrote:


This mail begins a one-week working group last call on
https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/?include_text=1

If you have comments or issues, please post here.

If anyone wants to be a document shepherd, please contact the chairs.

/r$

___
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-email-smime-06.txt

2019-11-03 Thread Alexey Melnikov


Hi Andreas,

On 03/11/2019 11:02, A. Schulze wrote:

Am 01.11.19 um 19:24 schrieb internet-dra...@ietf.org:

   Title   : Extensions to Automatic Certificate Management 
Environment for end user S/MIME certificates
   Author  : Alexey Melnikov
Filename: draft-ietf-acme-email-smime-06.txt
Pages   : 10
Date: 2019-11-01

Hello,

I'v noticed this version enhance the number of header fields MUST be covered by 
DKIM.
But some of us may be are aware of "Breaking DKIM - on Purpose and by Chance" 
[1] published in 2017.

To mitigate such attacks it would be helpful to REQUIRE header fields also 
can't be added.
see https://tools.ietf.org/html/rfc6376#section-3.5, definition of h= and
INFORMATIVE EXPLANATION + NOTE


I should have said that I've noticed your simial comment an an earlier 
email and it is still pending.


If you can suggest some specific text, that would be really great and 
would speed up addressing this issue.


Best Regards,

Alexey


Andreas

[1] https://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html

___
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-email-smime-05.txt

2019-11-01 Thread Alexey Melnikov


Hi Gerd,

Thank you very much for your comments and sorry for taking long time to 
reply to you.


On 15/07/2019 14:01, Gerd v. Egidy wrote:

Hi Alexey,

thanks for continuing your work on the smime draft.


1.  Do we need to handle text/html or multipart/alternative in email
   challenge?  Simplicity suggests "no".  However, for automated
   processing it might be better to use at least multipart/mixed
   with a special MIME type.

hmm. I guess with "automated processing" you mean an acme client on the user
side.

How would a multipart/mixed with a special MIME type help implementing the
client?

The client just needs to detect the challenge email and extract 
from the Subject:-Header. What other data, that could be in the part with the
special mime type, would help implementing such a client?
In many clients automatic processing can be invoked based on receiving a 
particular media type. Also, if an external application is used to 
handle challenge, it can be associated with a particular media type of 
various operating systems.

An ACME CA might want to include multipart/alternative and text/html to
present nicely formatted usage instructions to the user when the ACME client
is not integrated into the MUA. Automated clients should not be confused by
such messages.
This is one of my open issues. I would like to make implementations of 
ACME S/MIME-aware clients as easy as possible. If you have a generic 
email client, support for HTML is pretty much required. But if you don't 
have a generic email client, adding support for HTML might be an extra 
burden. So my question is: does better display of instructions to users 
outweigh extra complexity of handling of text/html? (I am on the fence 
on this. I think you are arguing that the answer is "yes").

The same is true for the challenge response:

When the user manully copies the response from his ACME client program into
his regular MUA, the MUA may compose a multipart/alternative mail with text/
html and text/plain or even just text/html. Also some company disclaimers and
so on could be added automatically.

How about using something like in RFC 7468?




-BEGIN ACME RESPONSE-
LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowy
jxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9
fm21mqTI
-END ACME RESPONSE-

This would allow the ACME server to extract the relevant data from most of
such emails by stripping all html tags and ignoring everything outside the
BEGIN/END block.


Having recently added HTML tag stripping in an email server, I think 
this is a big implementation burden, so I would prefer not to do that.


In regards to using something like RFC 7468: I think adding BEGIN/END 
wrapper would provide some extra help in detecting invalid content, so I 
will add it to the document.



We also should not force the response email to use a subject of "Re: ACME:
", just "ACME: " because MUAs with non-
english language settings may use something else than "Re:" to denote a reply.


I really dislike email clients using localized versions of "Re:", but I 
think you are right :-).


Best Regards,

Alexey


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

[Acme] Alexey Melnikov's No Objection on draft-ietf-acme-star-10: (with COMMENT)

2019-10-21 Thread Alexey Melnikov via Datatracker

Alexey Melnikov has entered the following ballot position for
draft-ietf-acme-star-10: No Objection

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


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


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



--
COMMENT:
--

Thank you for addressing my DISCUSS and comment.


___
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)

2019-10-01 Thread Alexey Melnikov

Hi Roland,

> On 1 Oct 2019, at 01:32, Roland Shoemaker  wrote:
> 
> 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.

Thank you. I will clear my DISCUSS.
> 
>> 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

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

Re: [Acme] Alexey Melnikov's Discuss on draft-ietf-acme-star-09: (with DISCUSS and COMMENT)

2019-09-30 Thread Alexey Melnikov

Hi Thomas,

> On 29 Sep 2019, at 20:03, Thomas Fossati  wrote:
> 
> Hi Alexey,
> 
> Thank you very much for your comments.
> 
>> On 29/09/2019, 17:29, "Alexey Melnikov via Datatracker"  
>> wrote:
>> I have one small issue that I would like to discuss before recommending
>> approval of this document:
>> 
>> Section 6.4 and 6.6 don’t seem to specify IANA registration procedure for new
>> subregistries.
> 
> Are you saying we should say explicitly what the contents of the new
> sub-registries are?

I was talking about rules for adding new values to these 2 subregistries. E.g. 
“Expert Review”, “Specification Required”, “IETF Review”, etc.

Listing initial registrations would be useful as well.

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

[Acme] Alexey Melnikov's Discuss on draft-ietf-acme-star-09: (with DISCUSS and COMMENT)

2019-09-29 Thread Alexey Melnikov via Datatracker

Alexey Melnikov has entered the following ballot position for
draft-ietf-acme-star-09: Discuss

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


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


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



--
DISCUSS:
--

Thank you for this well written document.

I have one small issue that I would like to discuss before recommending 
approval of this document:

Section 6.4 and 6.6 don’t seem to specify IANA registration procedure for new 
subregistries.


--
COMMENT:
--

1.1. Name Delegation Use Case

The proposed mechanism can be used as a building block of an efficient
name-delegation protocol, for example one that exists between a CDN or a cloud
provider and its customers [I-D.ietf-acme-star-delegation]. At any time, the
service customer (i.e., the IdO) can terminate the delegation by simply
instructing the CA to stop the automatic renewal and letting the currently
active certificate expire shortly thereafter. Note that in this case the
delegated entity needs to access the auto-renewed certificate without being in
possession of the ACME account key that was used for initiating the STAR
issuance.

Can you explain the last sentence? I am reading “in this case” as the delegated
entity needs access to renewed certificate once delegation is cancelled, which
doesn’t make sense. Please let me know if I misunderstood.


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

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

2019-09-29 Thread Alexey Melnikov via Datatracker

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] Draft minutes

2018-11-08 Thread Alexey Melnikov

Sorry for nitpicking, but below are my corrections to the minutes. I can
just send the updated version instead of a patch.

> ## Email TLS certs and EMAIL end-user certs, 15 minutes
> Who will read?  Ready for WGLC?
> 
> Paul Hofman: I don't understand the proposed change
> Alexey: At the moment service/port are single. If you wanted to issue multiple
> ports (IMAP/IMAPS) it needs to be multiple requests.
> Paul: I see no reason not to have multiple services.
> Chaair: One array or two?
> Alexey: One array
> Richard: I'm confused. This document is talking about authenticating
> DNS, but what would go into a certificate is a Domain.
> Alexey: In theory you could issue SRV based IDs. In the most common use cases
> that won't be used.

Change to: In the most common use cases DNS IDs would be issued instead.

> Richard: I think this should be updated to cover SRV.

Insert: Alexey: SRV is already covered in the document.

> DKG: I want to agree with Richard. If it's just on name, this is too complex.
> Several steps need including
> Alexey: For DNS there will be slightly specific service name.

Change to: For DNS challenge, there service name is included in the DNS
name used for the ACME challenge.
(_._._acme-challenge. TXT record.)

I think Richard also suggested to create a new DNS-based ACME challenge
type.

> DKG: If the cert being requested isn't specifically for the service, this
> could open an attack to other services for other protocols
> AI: Alexey to add some clarifying text, Richard to send some
> AI: After next draft, WGLC; READ
> 
> Paul Hoffman: These details aren't clear in the current draft.
> Richard: We have a copy of layers of indirection, what I am least clear on is
> the mapping of service to certificate. CA's may want to include SRV into the
> cert if you show control of the domain.
> Alexey: I'm hoping they'll issue certs with the port

Change to: I'm hoping they'll issue certs with the service name

> Richard: I suggest you implement SRV service IDs
> Tim: SRV has been discussed but not implemented
> Tim: The assumption all zones in a domain are controlled by the same identity 
> is no longer true.
> Alexey: I am developing software that could develop software to validate 
> these, but first I need CAs to issue certs against this.

Change to: I am developing client side software that validate these, but
first I need CAs to issue certs against this.
> 
> 

I think it is worth pointing out here that now we moved on to the S/MIME
document:

> Yaron: Are you expecting end user to perform this challenge?
> Alexey: Yes, possibly through copy/pasting the challenge.

Change the above 2:

Yaron: Are you expecting end user to perform this challenge or email client?
Alexey: Both. If email client doesn't support this natively, it is
possible to copy&past the challenge to an external program and then
create a reply with the calculated result.


> Chair: Is there any provisiion for multiple clients?

Alexey: yes

> AI: Tim H and dkg said they would review

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

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

2018-10-19 Thread Alexey Melnikov

Hi Andreas,
Thank you for your comments. My answers below:

On 17/10/2018 19:29, A. Schulze wrote:
> 
> 
> Am 01.09.18 um 13:13 schrieb internet-dra...@ietf.org:
>>
>> 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   : Extensions to Automatic Certificate Management 
>> Environment for end user S/MIME certificates
>> Author  : Alexey Melnikov
>>  Filename: draft-ietf-acme-email-smime-03.txt
>>  Pages   : 7
>>  Date: 2018-09-01
> 
> Hello,
> 
> some comments on the draft:
> 
> 1.
> Section 3.1
>> the prefix "ACME:" is followed by at least one SP or TAB character.
> 
> That makes parser unnecessary complex and offer obfuscation: How will common 
> MUA show messages with 10 TAB characters?
> 
> my suggestion:
> Require exactly one SPACE between "ACME:" and ""
> Best, one could translate this into correct ABNF notation.

That is fine, I don't mind requiring use of a single space.
> 
> 2.
> The example in section 3.1 show a simple plain text message. Why would we use 
> HTML encoded entities like "<" or ">"?
> I suggest to simply quote the email address using ' or "

I mistakenly encoded < and > in XML CDATA. You are right that this
is not needed.

> Also I think there should be a header "MIME-Version: 1.0", as required by 
> https://tools.ietf.org/html/rfc2045#section-4

Good point, I will add.

> But I may be wrong ...
> 
> 3.
> Section 4.1
> Again, text/html or multipart/alternative makes parser more complex.
> I'm against such a requirement.

I think I agree, but I was wondering if some clients can't control this
and just do this automatically.

> I also don't see a need for a special MIME type.

This might be convenient for automatic processing. But I don't have a
strong opinion.

> ACME challenge message should be as simple as possible and readable by users.
> text/plain fit this requirements.
> 
> Section 4.2
> the identifier for an ACME challenge message is a specific subject.
> with a fixed, probably exact known length.
> That should be enough.
I am concerned about automatic message filtering. Having a predictable
way to identify challenges would help.

> new Section 4.3
> Should the draft REQUIRE challenge message to be S/MIME signed?
> It's really not a big deal for a CA to send such messages and allow receivers
> a much better authentication. The signed content should again as simple as 
> possible
> as mentioned above.

I added this as an open issue, thank you.

> 4.
> to circumvent some concerns about weakness, we may introduce limitations:
>  - the CA MUST send from a subdomain that
>* propagate -all as default SPF policy
>* send DKIM signed messages
>* propagate p=reject as DMARC policy.
>  - RFC5322.To MUST be exactly the certificate object. The header MUST be 
> protected by oversigning by a proper DKIM signature.
>  - the message MUST not include RFC5322.Cc Header
>  - automatic clients MUST validate this requirements
> 
>  - the response message MUST have a RFC5322.From that match the certificate 
> object.
>  - the message recieved by CA's MX MUST compare, RFC5321.MailFrom match the 
> certificate object (From == MailFrom)
>  - the message MUST not contain RFC5322.Cc
>  - the CA MUST validate this requirements

I've used some of your suggestions and created an open issue for the rest.

Best Regards,
Alexey

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

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

2018-09-06 Thread Alexey Melnikov


On 04/09/2018 16:16, Gerd v. Egidy wrote:


Hi Alexey,


SMTP does allow choosing an arbitrary "From:" address, so just being able
to send an email with a specific "From:" address alone doesn't prove
anything.

This is true, the document needs to add some text about some form of
validation. Possibly DKIM/DMARC.

fair enough.


Couldn't the token just be transmitted back to the CA via HTTPS like the
rest of the ACME protocol?

As per above, I think this is not good enough.

But wouldn't that create two different levels of validation?

Let's consider user Alice. She, or her domain admin, has set up DNSSEC, DKIM,
SPF and DMARC. When she does the email-reply-00 challenge, mail reception and
sending is proven properly.

But user Bob has none of that, just a basic domain with one A record, no
DNSSEC and nothing else. When he does the email-reply-00 challenge,
essentially just mail reception is proven, as sending could be forged without
issue.

The CA would hand out the same kind of certificates to both of them and a
third party won't know which level of validation was done. Querying the dns
data of Bob won't help, because he could have changed it after the certificate
was issued.
I think it is CA's policy whether they want to trust an email address 
from a domain with no DMARC/DKIM/SPF/etc. But I think the document 
should specify whether there are any minimum requirements on email 
address validation.

Is a CA like Let's Encrypt ok with such a difference?

Or do you want to make the use of DKIM and DMARC mandatory for a user before
he can use the email-reply-00 challenge?
I am leaning this way. Or at least thinking of saying something like "or 
comparable validation" in the document.

DKIM/DMARC already deal with some of this, so I think they should be
encouraged in this context. (They are easy to handle in MTAs, as more
support is available).

Supporting S/MIME might be a reasonable alternative as well.

I'm ok with both of these mechanisms, they would both solve the issue.

I just think if we allow a CA to send S/MIME, there should be something like
"a client MUST support decoding MIME emails" in the RFC so that there is no
surprise if a CA suddenly starts using it.


I agree!

Best Regards,

Alexey

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

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

2018-09-04 Thread Alexey Melnikov


Hi Gerd,

Thank you for your comments!

On 04/09/2018 13:36, Gerd v. Egidy wrote:

Hi Alexey,

thanks for working on the "email-reply-00" challenge. I would very much
welcome a good mechanism to automatically distribute certificates for use with
S/MIME.

I have two questions / suggestions to your proposal:

3.2.  ACME response email
-

You suggest to send the challenge response via email. What is the reason for
choosing email as medium for this?


Because we need some way to prove control over the email address. This 
means both being able to read emails addressed to it and also being able 
to send on behalf of the email address.



SMTP does allow choosing an arbitrary "From:" address, so just being able to
send an email with a specific "From:" address alone doesn't prove anything.
This is true, the document needs to add some text about some form of 
validation. Possibly DKIM/DMARC. I am still thinking about this, so 
maybe better mechanisms are available.

But sending an email does require specific setup on the client side (like smtp
relay server, port, login,...) which makes it harder to use an ACME client
program that is not fully integrated into an email program.

Couldn't the token just be transmitted back to the CA via HTTPS like the rest
of the ACME protocol?

As per above, I think this is not good enough.

Challenge email and mail filtering
-

If "email-reply-00" becomes popular (I'm hoping it will), it will most
probably attract scammers which will try to trick users into giving away
passwords and so on. As the challenge email mostly contains a random token, it
is not easy for mail filtering gateways to filter out scam emails and let
legitimate challenge emails through. I think we should design the protocol in
a way that makes it easy for mail filtering gateways to do the right
thing:

1. Every CA should publish (on their webpage or in a specification document) a
static "From:" address they use when sending their challenges. This could be
used by gateways for whitelisting purposes.

2. As simple whitelisting without further checks isn't a good idea, the
authenticity of the challenge email should be verifiable by the filtering
gateway.
I propose that the CA should sign all challenge emails with S/MIME to do this.
As most email programs already automatically check S/MIME signatures, this
would also allow users of manual acme client programs to verify the
authenticity of the challenge email.


DKIM/DMARC already deal with some of this, so I think they should be 
encouraged in this context. (They are easy to handle in MTAs, as more 
support is available).


Supporting S/MIME might be a reasonable alternative as well.


What do you think?


I am a bit torn between requiring one, the other or even allowing both. 
More feedback from the WG would be useful.


Best Regards,

Alexey

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

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

2018-09-01 Thread Alexey Melnikov

On 01/09/2018 12:13, 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   : Extensions to Automatic Certificate Management 
> Environment for end user S/MIME certificates
>     Author  : Alexey Melnikov
>   Filename: draft-ietf-acme-email-smime-03.txt
>   Pages   : 7
>   Date: 2018-09-01
> 
> Abstract:
>This document specifies identifiers and challenges required to enable
>the Automated Certificate Management Environment (ACME) to issue
>certificates for use by email users that want to use S/MIME.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-email-smime-03
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-03

This version has a bit more meat in it, in particular I've added example
email challenge and response messages that are used to validate owneship
of an email address. I am sure that some details will change over time,
but this is a start.

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

Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

2018-08-30 Thread Alexey Melnikov

Hi all,

On Thu, Aug 30, 2018, at 2:58 AM, Ben Campbell wrote:
> 
> 
>> On Aug 29, 2018, at 8:10 PM, Richard Barnes  wrote:
>> 
>>  
>>> I am not an ART AD, but there is not yet an internationalization
>>> directorate, and seeing statements like "inputs for digest
>>> computations>>> MUST be encoded using the UTF-8 character set" (Section 5) 
>>> without
>>> additional discussion of normalization and/or what the canonical
>>> form for>>> the digest input is makes me nervous.  Has sufficient
>>> internationalization>>> review been performed to ensure that there are no 
>>> latent issues
>>> in this>>> space?
>> 
>> Two of the three ART ADs have already signed off, so we have that
>> going for us :)>> 
>> The only place we have human-readable text is in the problem
>> documents, so at that level, the i18n considerations are handled by
>> that spec.  Other than that, everything is ASCII, so saying "UTF-8"
>> is just a fancy way of saying, "don't send extra zero bytes".>> 
> 
> I am an ART AD, for what it’s worth :-)
> 
> I didn’t sweat this because of the exact reason mentioned; that is,
> this seems mostly not intended to be read by humans.Agreed.

And JSON should be encoded in UTF-8, so stating that explicitly is a
good thing.
> On a related note, I did note some heartburn about the reference to
> RFC 3492 for IDNA, but for the purposes of ACME I suspect that’s the
> right thing to do. OTOH, Alexey is more of an expert on IDNA than I
> am. Alexey?
RFC 3492 defines Punicode, i.e. how to encode U-labels in ASCII to
produce A-labels. This particular encoding hasn't changed between
IDNA2003 and IDNA2008, so I think referencing it is Ok.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

2018-08-29 Thread Alexey Melnikov


Hi Richard,

On 29/08/2018 16:03, Richard Barnes wrote:

Hi Alexey,

Thanks for the comments.  A couple of replies are below; resulting 
edits are in this PR:


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



I deleted comments where we are in agreement. More comments below:



--Richard


On Wed, Aug 29, 2018 at 7:14 AM Alexey Melnikov 
mailto:aamelni...@fastmail.fm>> wrote:


Alexey Melnikov has entered the following ballot position for
draft-ietf-acme-acme-14: 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-acme/



--
COMMENT:
--

Thank you for this very important document. I would like to switch
to "Yes",
but please first review and respond to my comments:

First mentions of JSON and HTTPS need references.

6.4.1.  Replay-Nonce

   The "Replay-Nonce" header field includes a server-generated value
   that the server can use to detect unauthorized replay in future
   client requests.  The server MUST generate the value provided in
   Replay-Nonce in such a way that they are unique to each
message, with
   high probability.  For instance, it is acceptable to generate
Replay-
   Nonces randomly.

   The value of the Replay-Nonce field MUST be an octet string encoded
   according to the base64url encoding described in Section 2 of
   [RFC7515].  Clients MUST ignore invalid Replay-Nonce values.  The
   ABNF [RFC5234] for the Replay-Nonce header field follows:

     base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"

This is not correct ABNF. Change range syntax in Section 3.4 of
RFC 5234


I've updated to try to fix this, but your review on the PR would be 
appreciated.


The correct form is (I didn't check if you usxe correct hex values):

base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_"

(I.e., don't include "%x" after "-" and don't have spaces before or 
after "-".) BTW, you can use "BAP"on tools.ietf.org to verify ABNF.





Please add normative references for Retry-After and Link header
fields.


These already have normative references at their first appearance:

https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-6.5

Do you think those references are incorrect?



I was reading out of order, so this is fine. But a new nit: "header" --> 
"header field". ("Header" is a collection of all HTTP header fields 
present in a request or response).




In 7.1.2:

   contact (optional, array of string):  An array of URLs that the

Which URI schemes are allowed (or at least expected) here?


Basically, servers must support "mailto", and may support others; they 
can specify their requirements in an error message.


You don't mention "mailto:"; till later and you don't even mention 
"tel:". I appreciate that you don't want to have an exhaustive list 
here, but I think you should still provide a bit more guidance.



https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-7.3

The WG discussed this and decided not to have more negotiation here.  
See, e.g.:


https://mailarchive.ietf.org/arch/msg/acme/TW8sbspUIGDGbIldaqWW0k9jKYo


That is fine.




(Similar text in other sections!)


I don't see "sort order" anywhere else, or other relevant usage of 
"order".  Do you have other places in mind?


This might have existed in earlier versions. I will double check.



In 8.3:

   The server SHOULD follow redirects when dereferencing the URL.

Why only a SHOULD?


Some server operators wanted to have the option to require that the 
validation work on the first request.



I think SHOULD basically makes redirects non interoperable. I think a 
bit more text explaining why SHOULD or change this to MUST. Also, if 
there are some security issues related to redirects, adding a pointer 
here would be good.




9.6.  URN Sub-namespace for ACME (urn:ietf:params:acme)

   Repository:  URL-TBD

Who needs to fix this value?


There's a request to the RFC editor below.



Ok.



9.7.1.  Fields in Account Objects

   o  Field type: The type of value to be provided, e.g.., string,
      boolean, array of string

Here and in all similar registries: I think you sho

[Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

2018-08-29 Thread Alexey Melnikov

Alexey Melnikov has entered the following ballot position for
draft-ietf-acme-acme-14: 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-acme/



--
COMMENT:
--

Thank you for this very important document. I would like to switch to "Yes",
but please first review and respond to my comments:

First mentions of JSON and HTTPS need references.

6.4.1.  Replay-Nonce

   The "Replay-Nonce" header field includes a server-generated value
   that the server can use to detect unauthorized replay in future
   client requests.  The server MUST generate the value provided in
   Replay-Nonce in such a way that they are unique to each message, with
   high probability.  For instance, it is acceptable to generate Replay-
   Nonces randomly.

   The value of the Replay-Nonce field MUST be an octet string encoded
   according to the base64url encoding described in Section 2 of
   [RFC7515].  Clients MUST ignore invalid Replay-Nonce values.  The
   ABNF [RFC5234] for the Replay-Nonce header field follows:

 base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"

This is not correct ABNF. Change range syntax in Section 3.4 of RFC 5234

 Replay-Nonce = *base64url

You allow for empty nonce here. Should this be "1*base64url"?

Please add normative references for Retry-After and Link header fields.

In Section 6.6:

  | unsupportedIdentifier   | Identifier is not supported, but may be |
   | | in future

Do you mean "identifier type", not identifier?

   This list is not exhaustive.  The server MAY return errors whose
   "type" field is set to a URI other than those defined above.  Servers
   MUST NOT use the ACME URN namespace Section 9.6 for errors other than
   the standard types.

I think this text is misleading, as you create a registry for these.
I suggest you rephrase and add a reference to the registry.

In 7.1.1:

   caaIdentities (optional, array of string):  Each string MUST be a
  lowercase hostname which the ACME server recognizes as referring

Is hostname fully qualified? U-label IDNA domains not allowed here? Please
clarify.

  to itself for the purposes of CAA record validation as defined in
  [RFC6844].  This allows clients to determine the correct issuer
  domain name to use when configuring CAA records.

Example in 7.1.1 (or maybe even earlier): You probably should say that some
header fields are omitted here.

In 7.1.2:

   contact (optional, array of string):  An array of URLs that the

Which URI schemes are allowed (or at least expected) here?

  server can use to contact the client for issues related to this
  account.  For example, the server may wish to notify the client
  about server-initiated revocation or certificate expiration.

In 7.4:

   Clients SHOULD NOT make any assumptions about the sort order of
   "identifiers" or "authorizations" elements in the returned order
   object.

Why is this a SHOULD NOT and not a MUST NOT?

(Similar text in other sections!)

7.4.2.  Downloading the Certificate

   GET /acme/cert/asdf HTTP/1.1
   Host: example.com
   Accept: application/pkix-cert

I think your example is wrong, as Accept value needs to match
application/pem-certificate-chain returned below:

   HTTP/1.1 200 OK
   Content-Type: application/pem-certificate-chain
   Link: <https://example.com/acme/some-directory>;rel="index"

   -BEGIN CERTIFICATE-
   [End-entity certificate contents]
   -END CERTIFICATE-
   -BEGIN CERTIFICATE-
   [Issuer certificate contents]
   -END CERTIFICATE-
   -BEGIN CERTIFICATE-
   [Other certificate contents]
   -END CERTIFICATE-

In 8.3:

   The server SHOULD follow redirects when dereferencing the URL.

Why only a SHOULD?

9.1.  MIME Type: application/pem-certificate-chain

   The "Media Types" registry should be updated with the following
   additional value:

   MIME media type name: application

   MIME subtype name: pem-certificate-chain

   Required parameters: None

   Optional parameters: None

   Encoding considerations: None

This value has to be one of "7bit", "8bit", "binary" or "framed". I think this
should be "7bit", as PEM is ASCII.

   Security considerations: Carries a cryptographic certificate and its
   associated certificate chain

I suggest you add text saying

Re: [Acme] I-D Action: draft-ietf-acme-email-tls-05.txt

2018-07-25 Thread Alexey Melnikov

On 25/07/2018 11:42, 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   : Extensions to Automatic Certificate Management 
> Environment for email TLS
>     Author  : Alexey Melnikov
>   Filename: draft-ietf-acme-email-tls-05.txt
>   Pages   : 8
>   Date: 2018-07-25
> 
> Abstract:
>This document specifies identifiers and challenges required to enable
>the Automated Certificate Management Environment (ACME) to issue
>certificates for use by TLS email services.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-email-tls/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-email-tls-05
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-tls-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-tls-05

In this version I incorporated input from Richard about use of
challenge-specific parameters. I've also added proper registration of a
new SMTP extension proposed in the document and did a few minor
editorial changes (like adding references).

I think this version is ready for WGLC.

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

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

2018-07-15 Thread Alexey Melnikov

On 27/06/2018 16:57, 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).

Sadly I have a conflict with ACME, but here is status of my documents:

 [snip]

> draft-ietf-acme-email-smime-02

Details of the challenge email need to be flashed out. I am talking to
people who offered to co-edit the document.

> draft-ietf-acme-email-tls-04

I think this document is ready for WGLC. I have a couple of open issues,
but I don't think they prevent WGLC. The two issues are:

1) Is it possible to make ACME issue a single certificate for multiple
related services running on the same host, e.g. for IMAP and IMAPS or
for IMAP and POP3? A single certificate with DNS-ID would cover all
services automatically, but if we want to allow for a finegrainer
control using SRV-ID, there has to be a way to list all services that a
certificate has to cover. Is this problem worth solving? If yes, what is
the best way of doing this? One possible way of doing this is to
rename/extend "service" JWS header parameter to be a comma separated
list of services.

2) I would like the document to support LMTP (RFC 2033, effectively this
is a variant of SMTP, however in order to do this, I need to register
"lmtp" service and possibly a default port.

Best Regards,
Alexey

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

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

2018-03-20 Thread Alexey Melnikov

On 20/03/2018 17:23, 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   : Extensions to Automatic Certificate Management 
> Environment for email TLS
>     Author  : Alexey Melnikov
>   Filename: draft-ietf-acme-email-tls-04.txt
>   Pages   : 8
>   Date: 2018-03-20
> 
> Abstract:
>This document specifies identifiers and challenges required to enable
>the Automated Certificate Management Environment (ACME) to issue
>certificates for use by TLS email services.

I've just added support for POP3 servers, as per John Levine request in
Singapore.

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

Re: [Acme] Draft agenda

2018-03-09 Thread Alexey Melnikov


On 09/03/2018 13:56, Salz, Rich wrote:


We are meeting Weds, 15:20-16:50  90 minutes

  Agenda bashing + Blue sheets + Note Well (5 min)
  Status update (chairs - 5 min)
  Main document (30 min)

  TLS ALPN challenge 10 (min)

  STIR stuff (20 min)

  AOB / Open Mic

Not assigned time: IP Validation, STAR, Email.  Do any of those folks 
want time?  If it’s just a status slide and looking for volunteers, 
let the chairs now and we’ll put it in the update section.


I can do a couple of slides on email. I might not need time to talk, 
maybe you can just show my slides quickly?


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

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

2017-11-12 Thread Alexey Melnikov

On 13/11/2017 05:23, 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   : Extensions to Automatic Certificate Management 
> Environment for email TLS
>     Author  : Alexey Melnikov
>   Filename: draft-ietf-acme-email-tls-02.txt
>   Pages   : 7
>   Date: 2017-11-12
> 
> Abstract:
>This document specifies identifiers and challenges required to enable
>the Automated Certificate Management Environment (ACME) to issue
>certificates for use by TLS email services.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-email-tls/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-email-tls-02
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-tls-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-tls-02

In this version I corrected some typos, added a reference to RFC 7817
and elaborated on various open issues.

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

Re: [Acme] Allowable mailto contacts

2017-10-20 Thread Alexey Melnikov

Hi,

On 19/10/2017 21:52, Logan Widick wrote:
I was not involved with RFC 6068 in any way. However, from my 
understanding of the RFC, that subset ("mailto:us...@example.com 
") might (roughly) look something like:
1. No hfields (that appears to be the RFC 6068 term for the query 
string and its parameters) are allowed (The spec doesn't appear to 
have a fragment)

2. Only one e-mail address per mailto contact

I think these 2 restrictions are very sensible.

Best Regards,
Alexey

Or at least that is how I would understand the constraints.

Sincerely,

Logan Widick

On Oct 19, 2017 3:20 PM, "Jacob Hoffman-Andrews" > wrote:

On 10/19/2017 10:59 AM, Logan Widick wrote:
> What portions of the "mailto" URI scheme (RFC 6068) must an ACME
server
> be able to accept as contacts?

Good question. I think we'd like to specify the narrowest subset
possible, i.e. "mailto:us...@example.com
". What would that look like in
the language of RFC 6068?

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

Re: [Acme] Adopt two email-related drafts

2017-06-09 Thread Alexey Melnikov


Russ,

On 08/06/2017 20:50, Russ Housley wrote:

At the interim, we had strong consensus to adopt Alexsey’s draft (was 
one, is now two) on ACME challenges and certs for email services and 
users:

_https://datatracker.ietf.org/doc/draft-melnikov-acme-email-smime/_


Why is the email address limited to all ASCII?  The LAMPS WG is almost 
done with the document for a certificate to include internationalized 
email addresses in certificates, so I would like to see them included 
here too.


I've done the quickest job I could do to get something published before 
the ACME Interim. As email addresses require new ACME identity type 
anyway, supporting Internationalized Emails should be relatively 
straightforward.

So yes, I am happy to do that.



_https://datatracker.ietf.org/doc/draft-melnikov-acme-email-tls/_


I hope we are not depended in any way on AUTH=SCRAM-SHA-1.


There is no obvious dependency on SCRAM at this point. If you are 
talking about example EHLO response, it includes all sort of other 
capabilities that are not relevant. I am happy to clarify this in the 
document.


Best Regards,
Alexey


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

Re: [Acme] Automated Certificate Management Environment (acme) WG Virtual Meeting: 2017-06-02

2017-06-02 Thread Alexey Melnikov


Hi,

On 18/05/2017 13:59, IESG Secretary wrote:

The Automated Certificate Management Environment (acme) Working Group will hold
a virtual interim meeting on 2017-06-02 from 11:00 to 12:00 America/New_York.

Agenda:
In the early message thread that was labeled “Futures” the following possible 
work items came up:
 Hugo’s CAA draft (already adopted, short, might be ready for 
WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01

The following drafts are possible calls for adoption:
 Yaron Sheffer et al draft on STAR -- 
https://tools.ietf.org/html/draft-sheffer-acme-star-lurk-00
 Mary Barnes on an ACME challenge for ATIS/SIP -- 
https://tools.ietf.org/html/draft-barnes-acme-service-provider-00
 Roland Shoemaker on an ACME challenge for validating IP 
addresses -- https://tools.ietf.org/html/draft-shoemaker-acme-ip-00
And also Jon Petersonet al 
https://tools.ietf.org/html/draft-peterson-acme-telephone-00

In addition, Alexey is interested in helping with an ACME challenge for email 
certificates. Is anyone else interested in helping to draft drafting?


I appreciate that people probably don't have time to read the draft I've 
just posted 
, 
but it provides description of new ACME challenges for issuing TLS 
certificates for email (SMTP, IMAP, etc.) services, as well as a very 
rough outline of how email address ownership validation can be done for 
S/MIME.


If people find the above useful, I am looking for some co-editors to 
complete this work.


Best Regards,
Alexey

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

Re: [Acme] ACME interm meeting poll

2017-05-10 Thread Alexey Melnikov

Hi Yoav,

> On 9 May 2017, at 22:44, Yoav Nir  wrote:
> 
> 
>> On 9 May 2017, at 23:28, Salz, Rich  wrote:
> 
> 
> 
>> In addition, Alexey is interested in helping with an ACME challenge for 
>> email certificates. Is anyone else interested in helping to draft drafting?
> 
> Has there been anything about this on the list?  Anyway, I’d be happy to help 
> with that.

No, just a few private discussions so far.
> 
>> 
>> We would like to know if people are interested in adopting, advancing, 
>> working-on these drafts within the ACME WG. And if anyone will commit to 
>> working on any of them.  If so, then we will discuss them in Prague, and 
>> have a re-chartering discussion to cover this new work.
>>  
>> Please see the Doodle poll and mark your availability.
>>  
>> For the good of the order,
> 
> Had to look that one up.  Learn something new every day…
> 
> 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

56 matches

Mail list logo