Subject: [Spasm] DRAFT charter text

From: Russ Housley <[email-masked]>
Date: Wed, 20 Apr 2016 13:51:10 -0400

This does not include the two things proposed by Eliot or Max earlier today.

Russ

= = = = = = =

The PKIX and S/MIME Working Groups have been closed for some time.  Some
updates are need to the X.509 certificate documents produced by the PKIX
Working Group and the electronic mail security documents produced by the
S/MIME Working Group.

The Some PKIX and S/MIME (SPASM) Working Group is chartered to make the
updates where there is a known constituency and there is a at least one
known approach to the update.  The current charter included updates to
satisfy the following needs:

1. Specify the way to include an i18n email address as a subject
   alternative name and an issuer alternative name.

2. Specify the processing for the Extended Key Usage certificate
   extension when it appears in the certificate of an intermediate
   certification authority.

3. Specify the way to use authenticated encryption in S/MIME.

In addition, the SPASM Working Group may investigate other updates to
the documents produced by the PKIX and S/MIME Working Groups, but the
SPASM Working Group shall not adopt any of these potential work items
without rechartering.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Apr 2016 19:28:16 +0100

Thanks Russ,

I'd love to see folks' comments on this proposed charter, incl.
discussion of whether that list of 3 things are what we think
are the most likely to get done, implemented and deployed. Do
argue for thing-X to replace one of those below if that's what
you want to argue for. Do argue that the above list is correct
if you think that. And please note that a factor for me is
whether or not it seems that people are or are not willing to
help review and comment on others' work and are not just pushing
their own (i.e. whether this discussion looks like a WG discussion
or not).

My own comments are included below.

Cheers,
S.

> This does not include the two things proposed by Eliot or Max earlier today.

s/need/needed/ or s/need/being proposed/

> known approach to the update.  

I think it'd be better to name the specific draft(s) that would
aim to be the starting points for the WG's work in the charter.

> The current charter included updates to

s/included/includes/

> SPASM Working Group shall not adopt any of these potential work items

I'd suggest adding to that something like:

"No such re-charting is envisaged until one or more of the above work
items have been successfully delivered to the RFC editor queue."

I'm not much fussed which stage in the process beyond the WG we choose
as the success criterion but IESG approval and delivery to the RFC
editor queue seems best to me. Main thing is to try encourage those
wanting thing N+1 to be added to the charter to help with thing M
for M<=N.

> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Apr 2016 21:08:30 +0200

Hi Russ,

Please do add the both in.  Good chance your power meter, for instance,
has an 802.1AR certificate.  There are other systems out there that use
them as well.  But there are some gates to deployment and some of this
work is meant to address those gates.

Thanks,

Eliot

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Apr 2016 15:20:21 -0400

Eliot:

Stephen asked the drafting team to limit the number of items to 3.

I think you will need to argue that MUD is a bigger need than the second item.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Apr 2016 20:21:10 +0100

On 20/04/16 20:08, Eliot Lear wrote:
> 
> Please do add the both in.  

FWIW, I am far more likely to want to support a charter that
is very limited, rather than one that is inclusive, so just
adding in work items is not a way to help get a WG chartered.

I'd *really* like to see folks arguing about the relative
merits and priorities of the proposed work items and not just
trying to get their fav things included. If only or mostly the
latter kind of discussion ensues, I will lack confidence that
we have a tractable WG and folks will end up back trying to
find AD sponsorship for work items, which does not scale.
(And there are often some slam-dunk things for AD sponsorship
that clearly do need to get done and clearly don't justify a
WG.)

Note that I'm not picking on Eliot here - the same applies
to all of the proposed work items (incl. those in Russ' list)
and to discussion thereof. And to the overall level of energy
visible on this list. I am very willing to help charter a WG
that will act like one and do needed work.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Apr 2016 20:23:56 +0100

On 20/04/16 20:20, Russ Housley wrote:
> Eliot:
> 
> Stephen asked the drafting team to limit the number of items to 3

3 is a good number from which to start the discussion. I'm not trying
to make that a fixed rule though, but starting with a small list of
stuff for which we're confident of success would be a good plan IMO.

Cheers,
S.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 20 Apr 2016 22:28:12 +0300

Dear Russ,

> This does not include the two things proposed by Eliot or Max earlier

Is there a way to specify an i18n email address as a subject itself, not as
SAN?
If not, it is useful to add it to the point 1.

The IDN domains are used widely enough in Russia so it's an actual problem.

-- 
SY, Dmitry Belyavsky

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 20 Apr 2016 20:57:18 +0100

Hi Dmitry,

> On 20 Apr 2016, at 20:28, Dmitry Belyavsky <[email-masked]> wrote:
> 
> Dear Russ,
> 
> Is there a way to specify an i18n email address as a subject itself, not as SAN?

Are there any situations where extensions to SAN/IAN would not be sufficient.
> The IDN domains are used widely enough in Russia so it's an actual problem. 

Right, this item would deal with IDN domains in email addresses.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 20 Apr 2016 22:56:43 +0300

Dear Alexey,

On Wed, Apr 20, 2016 at 10:57 PM, Alexey Melnikov <[email-masked]
> wrote:

> Are there any situations where extensions to SAN/IAN would not be

I think yes. For example the situation when the address is IDN domain is
primary.

> Right, this item would deal with IDN domains in email addresses.
If I understand correctly, there are different encodings for the left part
(before '@') and for the domain name (IDNA).

-- 
SY, Dmitry Belyavsky

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Apr 2016 16:02:08 -0400

> This does not include the two things proposed by Eliot or Max earlier today.

RFC 5280 has two ways to carry an email address.

Section 4.1.2.6, about the Subject name, says:

   Legacy implementations exist where an electronic mail address is
   embedded in the subject distinguished name as an emailAddress
   attribute [RFC2985].  The attribute value for emailAddress is of type
   IA5String to permit inclusion of the character '@', which is not part
   of the PrintableString character set.  emailAddress attribute values
   are not case-sensitive (e.g., "[email-masked]" is the same as
   "[email-masked]").

   Conforming implementations generating new certificates with
   electronic mail addresses MUST use the rfc822Name in the subject
   alternative name extension (Section 4.2.1.6) to describe such
   identities.  Simultaneous inclusion of the emailAddress attribute in
   the subject distinguished name to support legacy implementations is
   deprecated but permitted.

Section 4.2.1.6, about the Subject Alternative Name, says:

 The subject alternative name extension allows identities to be bound
   to the subject of the certificate.  These identities may be included
   in addition to or in place of the identity in the subject field of
   the certificate.  Defined options include an Internet electronic mail
   address,  …

   SubjectAltName ::= GeneralNames

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

   OtherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

The straightforward way to handle an i18n email address is to specify an OtherName to carry it.

We know that the use of emailAddress is still widely used, but since it is an IA5String, it cannot handle an i18n email address.

Russ

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Apr 2016 22:26:02 +0200

Why should unrelated efforts be measured against each other?  How does
one compare the importance of auto-configuration of IoT devices to email
addressing?  An alternative approach would be that if you're truly
looking to scale, create a maintenance group, deal with the demand that
has pent up, and manage extensions based those who are willing to do work.

But if you are going to go with your approach, I suggest you start with
candidates of all, and then pair down rather than choosing arbitrarily.

Eliot

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Apr 2016 16:36:19 -0400

Dmitry:

> Dear Alexey, 
> 
> On Wed, Apr 20, 2016 at 10:57 PM, Alexey Melnikov <[email-masked]> wrote:
> Hi Dmitry,
> 
> I think yes. For example the situation when the address is IDN domain is primary.
> 
>> 
> If I understand correctly, there are different encodings for the left part (before '@') and for the domain name (IDNA).

IDNA is already handled by RFC 5280.

7.2.  Internationalized Domain Names in GeneralName

   Internationalized Domain Names (IDNs) may be included in certificates
   and CRLs in the subjectAltName and issuerAltName extensions, name
   constraints extension, authority information access extension,
   subject information access extension, CRL distribution points
   extension, and issuing distribution point extension.  Each of these
   extensions uses the GeneralName type; one choice in GeneralName is
   the dNSName field, which is defined as type IA5String.

   IA5String is limited to the set of ASCII characters.  To accommodate
   internationalized domain names in the current structure, conforming
   implementations MUST convert internationalized domain names to the
   ASCII Compatible Encoding (ACE) format as specified in Section 4 of
   RFC 3490 before storage in the dNSName field.  Specifically,
   conforming implementations MUST perform the conversion operation
   specified in Section 4 of RFC 3490, with the following
   clarifications:

      *  in step 1, the domain name SHALL be considered a "stored
         string".  That is, the AllowUnassigned flag SHALL NOT be set;

      *  in step 3, set the flag called "UseSTD3ASCIIRules";

      *  in step 4, process each label with the "ToASCII" operation; and

      *  in step 5, change all label separators to U+002E (full stop).

   When comparing DNS names for equality, conforming implementations
   MUST perform a case-insensitive exact match on the entire DNS name.
   When evaluating name constraints, conforming implementations MUST
   perform a case-insensitive exact match on a label-by-label basis.  As
   noted in Section 4.2.1.10, any DNS name that may be constructed by
   adding labels to the left-hand side of the domain name given as the
   constraint is considered to fall within the indicated subtree.

   Implementations should convert IDNs to Unicode before display.
   Specifically, conforming implementations should perform the
   conversion operation specified in Section 4 of RFC 3490, with the
   following clarifications:

      *  in step 1, the domain name SHALL be considered a "stored
         string".  That is, the AllowUnassigned flag SHALL NOT be set;

      *  in step 3, set the flag called "UseSTD3ASCIIRules";

      *  in step 4, process each label with the "ToUnicode" operation;
         and

      *  skip step 5.

   Note:  Implementations MUST allow for increased space requirements
   for IDNs.  An IDN ACE label will begin with the four additional
   characters "xn--" and may require as many as five ASCII characters to
   specify a single international character.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 20 Apr 2016 23:54:22 +0200

> IDNA is already handled by RFC 5280.

Yes, which is ok for the domain part of the e-mail address.

For the local part one would ideally like to have UTF-8 encoded e-mail address
for upcoming SMTPUTF8 extension (AFAICS not widely implemented yet).  That's why
I've defined 'intlMailAddr' in draft-stroeder-mailboxrelatedobject for LDAP.

Ciao, Michael.

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Apr 2016 18:00:29 -0400

> I've defined 'intlMailAddr' in draft-stroeder-mailboxrelatedobject for LDAP.

IDNA is handled for domainName, but we do not yet have a solution for internationalized email addresses.

That is why the proposed charter text includes:

   Specify the way to include an i18n email address as a subject
   alternative name and an issuer alternative name.

Russ

---

From: Michael Ströder <[email-masked]>
Date: Thu, 21 Apr 2016 00:03:20 +0200

>    alternative name and an issuer alternative name.

It seems my language wasn't clear. I meant:
+1 to the above.

Ciao, Michael.

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2016 23:24:25 -0000

>Right, this item would deal with IDN domains in email addresses.

Since every IDN domain has an ASCII A-label equivalent, why is
this a problem?

I agree that EAI addresses with UTF-8 local parts need at least
a small document update.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Apr 2016 01:37:08 +0100

Hi Eliot,

On 20/04/16 21:26, Eliot Lear wrote:
> addressing?  

Energy and likelihood of implementation/deployment are factors that
are worth considering. The propensity of relevant folks (incl. me
historically, for which I apologise, now knowing a bit more maybe;-)
in this space to document things that are never really implemented or
deployed is real and worth not forgetting. And given the difficulty of
getting 5280 updates widely accepted and, more importantly, deployed,
and the tiny amount of smime in the world (relative to email), there
is a real danger that we waste folks' time here, with the best of
intentions.

> An alternative approach would be that if you're truly

Arguments for/against a generic SEC area maintenance group would be
better discussed on the saag list. (Not sure if that's what you meant
though.) If you want to argue for that, please do start a thread on
saag. Previous iterations of that discussion have not seemed to
reach consensus on creating such a mechanism/WG. That said, MUD
doesn't fit that "maintenance" template, but that's ok - it may be
that folks' opinions have changed. (FWIW, I'd be opposed to such a
generic "maintain security stuff" WG on the basis that it'd likely
not have sufficient energy to do good work, and also on the basis
that such a beast would attract crap; however the arguments against
are not a slam-dunk, so the discussion is worth re-visiting from
time to time and it's been a while.)

> candidates of all, and then pair down rather than choosing arbitrarily.

That was what I think I was proposing. But paired-down based partly
based on whether or not the community are interested in engaging or
not seems like a reasonable consideration in the chartering process.
So - please do engage and argue for your thing, but in the context of
the all the other things about which folks argue here. (IOW, by all
means  do defend your own proposal as worthwhile, but if that's all
that anyone does, then IMO we don't have a viable WG.)

Hope that helps,
S.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 21 Apr 2016 06:29:27 -0500

Dmitry,

Why do you feel the need to have this as a subject rather than using an empty subject and providing a SAN.  This is considered to be the correct way to do this as I remember how RFC 5280 is laid out.

Jim

From: Spasm [mailto:[email-masked]] On Behalf Of Dmitry Belyavsky
Sent: Wednesday, April 20, 2016 2:57 PM
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]; Russ Housley <[email-masked]>
Subject: Re: [Spasm] DRAFT charter text

Dear Alexey, 

On Wed, Apr 20, 2016 at 10:57 PM, Alexey Melnikov <[email-masked] <mailto:[email-masked]> > wrote:

Hi Dmitry,

On 20 Apr 2016, at 20:28, Dmitry Belyavsky <[email-masked] <mailto:[email-masked]> > wrote:

Dear Russ,

On Wed, Apr 20, 2016 at 8:51 PM, Russ Housley <[email-masked] <mailto:[email-masked]> > wrote:

Russ

= = = = = = =

 

 

 

-- 

SY, Dmitry Belyavsky

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 21 Apr 2016 14:53:44 +0300

Dear Jim,

It seems a bit counter-intuitive to me. But yes, it's a possible solution.

On Thu, Apr 21, 2016 at 2:29 PM, Jim Schaad <[email-masked]> wrote:

> Dmitry,
>
>
>
> Why do you feel the need to have this as a subject rather than using an
> empty subject and providing a SAN.  This is considered to be the correct
> way to do this as I remember how RFC 5280 is laid out.
>
>
>
> Jim
>
>
>
>
>
> *From:* Spasm [mailto:[email-masked]] *On Behalf Of *Dmitry
> Belyavsky
> *Sent:* Wednesday, April 20, 2016 2:57 PM
> *To:* Alexey Melnikov <[email-masked]>
> *Cc:* [email-masked]; Russ Housley <[email-masked]>
> *Subject:* Re: [Spasm] DRAFT charter text
>
>
>
> Dear Alexey,
>
>
>

-- 
SY, Dmitry Belyavsky

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Apr 2016 09:48:02 -0400

> candidates of all, and then pair down rather than choosing arbitrarily.

In Buenos Aires, Stephen asked that a draft charter be created from the items that had already been compiled on the S/MIME and PKIX mail lists.  Those lists are here:

	https://mailarchive.ietf.org/arch/msg/smime/Y2WcugFfqDR8q7fgkGquX-PcdpQ

	https://mailarchive.ietf.org/arch/msg/pkix/r46hvskDvSUM5Dg-jvJ85ZdXJls

In addition, Stephen said that the CURDLE WG will handle any documents related to the CFRG algorithms, so no algorithm documents are included in the draft charter.

Now, we are discussing the draft charter….

Russ

---

From: "John Levine" <[email-masked]>
Date: 21 Apr 2016 14:12:29 -0000

>Now, we are discussing the draft charter

If there's room, I'd like to work on S/MIME and PGP key distribution
as in draft-bhjl-x509-srv-00.  I realize the desire to keep the list
of drafts short, but this one is pretty simple, little more than a
profile of RFC 4387.

R's,
John

---

From: Sean Turner <[email-masked]>
Date: Thu, 21 Apr 2016 10:26:07 -0400

I understand and support #1 and #3, but what’s #2 about again?

spt

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Apr 2016 10:50:51 -0400

> I understand and support #1 and #3, but what’s #2 about again?

Please see the thread that begins here: http://mailarchive.ietf.org/arch/msg/pkix/MHwcSWuuzezj4qHuzSmbYeGUbdI

Russ

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 Apr 2016 11:24:04 +0100

> This does not include the two things proposed by Eliot or Max earlier today.

I think this is a reasonable charter to start PKIX/S/MIME work.

---

From: Wei Chuang <[email-masked]>
Date: Wed, 27 Apr 2016 13:28:19 -0700

I also think is a good charter to start PKIX/S/MIME work.

-Wei

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 28 Apr 2016 10:13:12 +0100

Hi Dmitry,

> I think yes. For example the situation when the address is IDN domain is primary.

Sorry, I don't understand what is "primary IDN domain". Can you elaborate?
> If I understand correctly, there are different encodings for the left part (before '@') and for the domain name (IDNA).

The domain part can be encoded as either UTF-8 version or its ASCII encoding (xn--...). I don't think we can prohibit use of any of them.
The left hand side is always in UTF-8.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 28 Apr 2016 10:15:54 +0100

> Since every IDN domain has an ASCII A-label equivalent, why is

It is not. But I was wondering whether we can actually require people to only use A-labels.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 28 Apr 2016 11:10:46 +0200

Alexey Melnikov wrote:
> The domain part can be encoded as either UTF-8 version or its ASCII encoding
> (xn--...). I don't think we can prohibit use of any of them.

But at least there could be a implementation note that encoding the domain part
as ASCII is recommended for backward compability.

> The left hand side is always in UTF-8.

And is usable only with SMTPUTF8 extension.

Ciao, Michael.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 28 Apr 2016 12:15:32 +0300

Hello Alexey,

On Thu, Apr 28, 2016 at 12:13 PM, Alexey Melnikov <[email-masked]

> Sorry, I don't understand what is "primary IDN domain". Can you elaborate?

In Russia a lot of companies have their site in the .рф domains (Cyrillic
unicode).
If users from such companies want to obtain a certificate for any email
address in such a domain,
it seems to me that it should be specified not in SAN but in Subject.

> The domain part can be encoded as either UTF-8 version or its ASCII
> encoding (xn--...). I don't think we can prohibit use of any of them.

In the DNS world domain names are usually presented in the PUNYCODE format.
A lot of programs have to change the presentation for usability purposes,
and it seems to be not a problem.

-- 
SY, Dmitry Belyavsky

---

From: Yoav Nir <[email-masked]>
Date: Fri, 29 Apr 2016 00:33:25 +0300

> On 21 Apr 2016, at 5:50 PM, Russ Housley <[email-masked]> wrote:
> 
> 

That seems like an ugly hack. We have an intermediate CA certificate with EKU for (for example) Code Signing and Email Protection, but the key in that certificate is never ever used for either code signing or email protection. It is only used to sign certificates (OK, and revocation).

I see that all this has been covered in the referenced PKIX thread. What we are being asked to do is to “bless" existing practice, an existing practice that has been documented by the CA/BF, but in fact predates it.  If, as the thread claims, “all the browsers implement this”, it’s a good fit for the Spasm requirement that documents have a high likelihood of being implemented. 

One of the messages in that thread ([1]) states that “the CA/Browser Forum sets standards for Certification Authorities”. That is not strictly true. The CA/BF sets standards for a very specific set of CAs - those that are the so-called “Web PKI”. There are many other CAs used in other contexts, and any RFC that updates or replaces RFC 5280 has to consider those as well. Do we have any information about how much breakage could occur if this requirement was added to path validation libraries in all libraries?

Yoav

[1] https://mailarchive.ietf.org/arch/msg/pkix/Dl_lme0pfswdkxUS3oAVzRiFSjE

---

From: Russ Housley <[email-masked]>
Date: Thu, 28 Apr 2016 19:09:44 -0400

Yoav:

Personally, I would be much happier with an EKU-constrainsts extension.  We have several examples like this that can be used as design patterns. It would be interesting to find out if CAs and reeling parties would migrate their existing code to use such and extension.  That said, let’s get the charter done, then argue the technical merits of potential solutions.

Russ