Subject: Re: [dane] draft-ietf-dane-smime

From: Doug Montgomery <[email-masked]>
Date: Thu, 2 Oct 2014 16:56:09 -0400

I am a little confused as to why we seem to couple the use case of key
discovery and distribution in TLS to the use case for
email/network-identity.   These seem to be very different use cases to me.

I looked back at two years of data.   My own, mid-size (3K staff)
organization revokes on average 165 net-identities a month.  We also create
about that number, less you think we are withering away.

Having a scalable, simple, but definitive way to indicate that a previously
valid email-identity/certificate is no longer valid within a given domain
is a useful feature that doesn't seem to have an analog use case in TLS.
  As far as I know we have never revoked our TLS cert ...

I know of other industry sectors attempting to develop rather complex
pub/sub architectures to signal changes in status of email identities from
large mailbox providers to other users/uses of the ID.

Overly coupling the use cases and requirements between these uses seems to
be a red herring to me.    Maybe we should turn the question around and ask
for an explanation why the use cases for TLS should impact the requirements
for SMIMEA?

dougm

On Tue, Sep 30, 2014 at 4:53 PM, Paul Hoffman <[email-masked]> wrote:

> On Sep 29, 2014, at 5:26 AM, Osterweil, Eric <[email-masked]>
> wrote:
>
> > Based on our implementation experience we would like to suggest that the
> following text (taken from Scott Rose's email:
> http://www.ietf.org/mail-archive/web/dane/current/msg06180.html ) be
> incorporated into the current version of the draft-ietf-dane-smime
> document.  We are sending text (below), but at a high-level, the text
> outlines a few useful additions:
> >
> > 1 - Usage #4 (reject) is likely to be very important.  This could either
> emphasize the difference between saying, ``don't use this cert for this
> operation,'' and ``this cert is universally revoked'' or be used to
> selectively override an organization-wide TA for certain employees that
> have left the organization.
> >
> > 2 - The certificate access field (Section 2.1.4) would enable alternate
> discovery mechanisms that could help aid incremental deployment and
> transition schemes.  For example, while cutting over to a DANE solution,
> some enterprises may want to transition users from (say) AD to DANE, and
> this field would enable that.
> >
> > 3 - The ``_encr'' and ``_sign'' labels are excellent additions to the
> management of zone sizes and lookup sizes.  Rather than querying for all
> keys and then locally selecting from them, I (as an RP) likely already know
> which of these I want, and I should be able to look them up separately in
> DANE (and owners should be able to manage them separately in DANE).
> >
> > If anyone objects, please let us know.
>
> Jakob and I think that the three additions are unneeded here, and make the
> draft diverge quite far from the TLSA format without significant value. In
> specific:
>
> 1) This usage type is at least as applicable to TLS as it is to S/MIME. We
> haven't seen anything indicating much use of certificate revocation
> anywhere and, where we have seen it, it is much more common in TLS. If the
> authors really want this feature, it should be an update to TLSA, which
> SMIMEA could then adopt.
>
> 2) Making the record format for SMIMEA different than that of TLSA for
> this feature seems like a bad idea. Alternate discovery mechanisms might be
> important, but they will be just as important for TLS as they are for
> S/MIME. The functionality that the authors want could be added to TLSA by
> adding new Matching Type fields such as "Hash and NAPTR", "Hash and URI",
> and so on. The latter is part of IKEv2 (although the feature is generally
> considered not useful). If the authors really want this feature, it should
> be an update to TLSA, which SMIMEA could then adopt.
>
> 3) There is absolutely no indication that zone size or response size is
> important to SMIMEA, certainly not relative to the added complexity for
> clients, servers, and operators. Currently, the RSA certs for SMIME from
> common CAs are for both signing and encrypting, so this added complexity
> won't buy current users anything. In the future when we are all (hopefully)
> using elliptic curve keys, the zone size and response size will be so much
> smaller than they are now that this change will appear as an
> over-optimization that adds complexity.
>
> When these ideas were brought to the WG earlier this year, we didn't hear
> any significant support. Given that both of us feel that the proposed
> changes make the document harder to implement, we would want to see much
> wider support before we adopt them.
>
> --Paul Hoffman and Jakob Schlyter
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>
>

-- 
DougM at Work

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 2 Oct 2014 23:00:39 +0200

On 2 okt 2014, at 22:56, Doug Montgomery <[email-masked]> wrote:

> Having a scalable, simple, but definitive way to indicate that a previously valid email-identity/certificate is no longer valid within a given domain is a useful feature that doesn't seem to have an analog use case in TLS.

If you trust in DANE, and the certificate is no longer published in DNS, it is not valid - no revocation is needed.
If you do not trust in DANE, normal/legacy revocation procedures (OCSP/CRL) applies.

my 0.01€,

	jakob

---

From: Doug Montgomery <[email-masked]>
Date: Thu, 2 Oct 2014 17:05:14 -0400

And how is that definitively distinguishable from that email identity never
having a CERT in DANE in the first place?

dougm

On Thu, Oct 2, 2014 at 5:00 PM, Jakob Schlyter <[email-masked]> wrote:

> > Having a scalable, simple, but definitive way to indicate that a
> previously valid email-identity/certificate is no longer valid within a
> given domain is a useful feature that doesn't seem to have an analog use
> case in TLS.
>
> If you trust in DANE, and the certificate is no longer published in DNS,
> it is not valid - no revocation is needed.

-- 
DougM at Work

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Oct 2014 15:12:09 -0700

On Oct 2, 2014, at 1:56 PM, Doug Montgomery <[email-masked]> wrote:

> I am a little confused as to why we seem to couple the use case of key discovery and distribution in TLS to the use case for email/network-identity.   These seem to be very different use cases to me.
> 
> I looked back at two years of data.   My own, mid-size (3K staff) organization revokes on average 165 net-identities a month.

This is literally the first data I have seen that indicated that email certs were revoked for other than far edge cases. (I'm assuming that you are equating "net-identities" and email certs...)  Thanks for the data.

But, having said that, NIST isn't a typical organization. The fact that you revoke more than half of your S/MIME certs per year is surprising to me, but that may be because I am not familiar with the policies you used.

> As far as I know we have never revoked our TLS cert ... 

Right: TLS certs are rarely revoked. This can be seen by looking at the CRLs from major CAs. However, looking in those same CRLs shows nearly no S/MIME certs revoked either.

> I know of other industry sectors attempting to develop rather complex pub/sub architectures to signal changes in status of email identities from large mailbox providers to other users/uses of the ID. 

This seems different from what you said above. In a pub/sub architecture, there is no reason to revoke the old cert when an individual gets a new identity because the individual still controls the private key of the earlier identity. In other pub/sub systems I have seen, they use short-lived (~1 month) certs and issue new ones for "continuing" usage, so no revocation is needed.

> Overly coupling the use cases and requirements between these uses seems to be a red herring to me.    Maybe we should turn the question around and ask for an explanation why the use cases for TLS should impact the requirements for SMIMEA?

Or, based on what Jakob and I suggested, why shouldn't features that are needed for either use case be shared?

> If you trust in DANE, and the certificate is no longer published in DNS, it is not valid - no revocation is needed. If you do not trust in DANE, normal/legacy revocation procedures (OCSP/CRL) applies.

On Oct 2, 2014, at 2:05 PM, Doug Montgomery <[email-masked]> wrote:

> And how is that definitively distinguishable from that email identity never having a CERT in DANE in the first place?
> 

It completely depends on whether the enterprise is using SMIMEA for certificate discovery or key distribution. Our draft explicitly states that it is aimed at the latter, but allows the former. Given that the use case in the introduction is for keys, not certificates, the lack of presence in the DNS makes the key invisible.

This is not to say that TLSA/SMIME should not have the feature of carrying "this certificate was revoked" information; the WG may want that. But it seems weird, at least to me, that this feature could be considered only for S/MIME.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Oct 2014 22:46:48 +0000

> having a CERT in DANE in the first place?

It is not, but identities can have multiple associated certificates,
and in fact need to do so during key rotation.  The proposal seems
to suggest a revocation of the "identity" rather than a particular
key and this seems to be operating at the wrong granularity.

Ignoring everything but the CU with usage 4 eliminates the option
of revoking key "A" while publishing a replacement key "B".

Explicit revocation is not a good idea in DANE, the DNS publishes
a sufficiently current state of the world, not a stale assertion
with a one year TTL.  It is I think a mistake to ask where the
handbrake goes on a boat, when one happens to be more familiar with
cars.

In any case if CU=4 is to be a DANE revocation record, it should
have a meaningful selector, matching type and association data.
It shold be an explicit revocation of just the matching certificate
or public key (whether it be associated with a trust-anchor or an
end-entity).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Oct 2014 23:07:24 +0000

On Thu, Oct 02, 2014 at 03:12:09PM -0700, Paul Hoffman wrote:

> This is not to say that TLSA/SMIME should not have the feature of carrying
> "this certificate was revoked" information; the WG may want that. But it
> seems weird, at least to me, that this feature could be considered only
> for S/MIME.

There is an underlying difference that may drive a need for DANE
revocation in SMIME, while DANE revocation remains pointless with
TLS.

    * With TLS communication is real-time, and keys authenticate
      data in motion.  There is no need to revoke keys held by the
      server yesterday once they are no longer published as valid
      today.

    * SMIME encrypts data at rest.  It is not uncommon to access
      messages long after the initial delivery.  If a signing key
      was valid at the time at which the message was initially
      received, the message is authentic.

Which raises an interesting problem.  Since the proposed TLSA RR
does carry a revocation start time, it invalidates *all* past
traffic, also covering the time at which the key was not invalid
or compromised.

To handle revocation correctly with SMIME, the revocation RR would
need a more structured association data (to include a revocation
start time).

Note that there is little need to revoke non-signature keys, just
don't deliver email to the no longer affiliated recipient.  In fact
removing all email encryption keys for a particular recipient risks
rather unpleasant consequences for email security when sensitive
email is sent to multiple recipients.  There may be MUAs that as
a result send cleartext to at least that recipient or perhaps all
recipients.

[ Apple's mail.app automatically enables least common denominator
security when sending mail to multiple recipients, so email is only
encrypted when encryption keys are available for all recipients.
So one would have to be ever vigilant when composing email, to make
sure the security indicators are set to one's satisfaction. ]

-- 
	Viktor.

---

From: Sean Turner <[email-masked]>
Date: Thu, 16 Oct 2014 01:46:55 -0400

Apologies for coming to this late and for this being so long.

On Sep 30, 2014, at 16:53, Paul Hoffman <[email-masked]> wrote:

> On Sep 29, 2014, at 5:26 AM, Osterweil, Eric <[email-masked]> wrote:
> 
> When these ideas were brought to the WG earlier this year, we didn't hear any significant support. Given that both of us feel that the proposed changes make the document harder to implement, we would want to see much wider support before we adopt them.
> 

I guess we know where the authors stand on making the changes ;)

Anyway, put me in the camp that wants to continue the discussion about the possibility of making changes to support the proposed changes to the SMIMEA spec.

WRT:

> 1) This usage type is at least as applicable to TLS as it is to S/MIME. We haven't seen anything indicating much use of certificate revocation anywhere and, where we have seen it, it is much more common in TLS. If the authors really want this feature, it should be an update to TLSA, which SMIMEA could then adopt.
> 
> 2) Making the record format for SMIMEA different than that of TLSA for this feature seems like a bad idea. Alternate discovery mechanisms might be important, but they will be just as important for TLS as they are for S/MIME. The functionality that the authors want could be added to TLSA by adding new Matching Type fields such as "Hash and NAPTR", "Hash and URI", and so on. The latter is part of IKEv2 (although the feature is generally considered not useful). If the authors really want this feature, it should be an update to TLSA, which SMIMEA could then adopt.

Two parts:

1) Comparing the use of revocation of TLS certificates to S/MIME certificates is an interesting way to start because what you say is obviously true; TLS is so much more widely deployed compared to S/MIME (everybody uses TLS - enterprises and some nerds use S/MIME) so of course you’re going to see it much more in/for TLS.  I’d love to know the split between TLS versus S/MIME certificates issued by big box CAs and how often the associated CRLs get checked but I’m sure that’s proprietary (please somebody prove me wrong).

2) I want to push back on the statement above about changing TLSA first and this bit that followed later in the thread:

> Or, based on what Jakob and I suggested, why shouldn't features that are needed for either use case be shared?

The idea that the proponents of these changes need to go change the TLSA spec because you think it applies to both seems a little bit excessive.  If you think the changes apply to both, then great feel free to go and propose those changes get made in the TLSA spec; I see no reason to burden the proponents of these changes with that job.

WRT rarity:

> Right: TLS certs are rarely revoked. This can be seen by looking at the CRLs from major CAs. However, looking in those same CRLs shows nearly no S/MIME certs revoked either.

There might be other reasons to dismiss usage #4 (reject) but we shouldn't do so based on your assertion that there’s no revocation of TLS or S/MIME certs because I believe revocation happens more than rarely.  Rarely to me means I’d have a really hard time finding some revoked certs.

I took the bait and went and looked at some CRLs (my hastily gathered small sample is later) - was this your ploy all along?  If not, I’d be curious to know what you’re looking at to motivate your statement.  What I’m looking at seems to indicate that TLS certificate revocation happens certainly more than on rare occasions.  I also got my hands on some CRLs with S/MIME certificates on ‘em that also seem to indicate it’s also not so rare to revoke S/MIME/ID certificates (also later).

Note: This might be stating the obvious but looking at the exact same CRLs might not give you what you’re looking for in terms of finding revoked TLS and S/MIME certificates: 1) the CA has to put all the revoked certificates on the same CRL and they don’t always do that in fact it looks like many don't that based on the CRL’s issuer name; CRL issuer names include “EV”, “SSL”, etc. for TLS-only CRLs and “Individual”, “Personal”, etc. for S/MIME-only certificates, 2) some of the big box CAs only do TLS certificates so of course you’re not going to see any S/MIME certificates on the CRL, and 3) you can’t tell by looking at CRL entry what the certificate’s KU or EKU is because the entries only contain the serial number, revocation date, and maybe if you’re lucky a revocation reason (you might be able to infer from the reason code but you kinda gotta guess what’s on the CRL based on the name of the CRL issuer or if you dig a little farther based on the certificate’s CP/CPS - I mostly assumed based on the CRL issuer name).

Before the data first a couple of disclaimers:

- I don’t name names for obvious reasons.

- The CRLs are all from public facing TLS servers.  So all of this in some fashion or another is reproducible.

- I made sure to not use duplicate CRLs from the same provider by looking at the AKI if present and issuer name if not.

- To find the CRLs, it wasn’t as easy as following some links to the CA’s repo and downloading them; it is that easy for root and intermediate CA certificates but not for CRLs and not for EE certificates.  Maybe I’m doing it wrong … anyway, to get them I had to go to https enabled websites, click on the browser bar, inspect the certificate, scroll to the CRLDP extension, ctrl-c/v the URI to the CRL into firefox, then use dumpasn1 (still works like a champ) on the downloaded CRL to look at the number of entries.  I then went to the SEQ after the thisUpdate/nextUpdate lines, divided the number next to the SEQ by what seemed to be the average size of each entry, and got an approximate # of entries on the CRL.  See [1] for some interesting observations.  Also, if you’re looking at the CRL’s pointed to in those CA certificates you can find in the repo you’re looking at the wrong CRL - the CRLs pointed to from CA certificates are ARLs disguised as CRLs.

- Other folks were more high tech and ran scripts that looked at a lot more CRLs than my manual method.  I included their results after my plodding results.

And, now for some data on CRLs for TLS certificates:

- Started with search engines: two of ‘em run their own CAs so it’s unsurprising they contain few entries (8 & ~50) and another uses a managed service and that CRL has well more … like ~51K.  The CRL with ~51K entries includes entries back to 2010 and according to the description of the Root CA only TLS certificates are issued by CA subordinates to it so all of those ~51K are TLS certificates.  I went to another one - they don’t offer https:// :(

- A non-US news organization: there’s ~400 entries covering just this year.

- A non-US bank: ~5.2K entries with three years worth of revoked certificates (no reason codes).  I went to another on a different continent and found the same CRL so new data.  I went to a third (on the same continent as the 1st) and got a CA from what I wouldn’t consider one of the typical US big box CAs and found a CRL with ~35 entries from 2014 - no reason codes.

- A non-US tech company: ~10K revoked certs over 4 years with no reason codes.  Another one on a different continent: ~1.8K entries spanning 3 years - reason codes too codes 5, 4, 3, and 1 (in descending order of apperance).

- From a couple of the larger hosting sites: one runs their own CA and it has ~280 entries - all in one year and all but one reason code is 5, another doesn’t run their own CA and the CRL in their certificate has ~2.8K entries but no reason codes (all in 2014), another one has an empty CRL, another one has a CRL with ~500.

And now for more comprehensive data:

   Eric Osterweil has some data that can be found here:
   http://secspider.verisignlabs.com/heartbleed/

   Richard Barnes had some too:  scan of CRLDPs in ~450
   different CRLs: 1.4M entries, median entries per CRL: 390,
   average # of entries 3.2K

This doesn’t seem so rare.

Onto S/MIME:

> But, having said that, NIST isn't a typical organization. The fact that you revoke more than half of your S/MIME certs per year is surprising to me, but that may be because I am not familiar with t…

I’m just as surprised by the # of revoked certificates compared to the # of employees, but I’m also not surprised that the $14.95 and free S/MIME cert CA’s CRLs are empty or at least close to it: 19 entries (covering 8 years), ~180 entries (covering two years).  There’s little incentive for those that have been issued $14.95 or free certificates to ask for them to be revoked especially since most of the changes I see are cessation of operation (I quit, I got fired, etc.).

I think we should be looking at the managed service CA’s CRLs or large enterprise CA CRLs instead because there at least there’s policies that are much more likely to get enforced (you quit they revoke your cert).  Then again, you have to dig a little deeper to find these CRLs by CLRDPs in certificates with signed messages.  Here’s some CRLs from managed PKIs (employee #s from wikipedia) picked from S/MIME messages sent to an IETF ML:

- ~120K employees: ~125K entries spread out over 3 years.  Of the reasons that appear superseded shows up the most then affiliation changed.

- ~100K employees: ~5K entries so far this year.  No reason codes.

- ~25K employees firm has ~36.5K entries covering the last three years.  Not a lot of reason codes but there are 57 key compromise and 244 superseded reasons listed.

- (a University) ~18K students & ~2.5K staff: ~1.9K entries spread out over 3 years.    No reason codes.

- An org (don’t know how many people work there - wikipedia failed me):~1.7K entries.  No reason codes.

Only one of the above is what I’d consider a traditional USG-affiliated org - and it’s not the CRL with the most entries.

NIST #s might be out of whack but I’m not sure how atypical it is for organizations that actually issue certificates to revoke those certificates.

Again, I’m all for debating whether we should define a “revoke" usage and how it works but dismissing the request based on data that to me shows the exact opposite of your observation seems wrong to me and I hope others.

WRT:

> 3) There is absolutely no indication that zone size or response size is important to SMIMEA, certainly not relative to the added complexity for clients, servers, and operators. Currently, the RSA certs for SMIME from common CAs are for both signing and encrypting, so this added complexity won't buy current users anything. In the future when we are all (hopefully) using elliptic curve keys, the zone size and response size will be so much smaller than they are now that this change will appear as an over-optimization that adds complexity.

Four points here:

- On the certificate size, you’re right that EC certificates will be smaller than their RSA-based brethren.  I pulled a RSA-based TLS certificate from a US bank it’s about ~2Kbytes.  An EC-based TLS certificate, which I thought based on the name in the cert was a porn site - not - it’s a bakery, is about ~1Kbytes - an S/MIME cert would be the same size.

- On whether it buys current users anything because RSA-based S/MIME certificates are for both sig+enc, of course it’s not going to buy them anything for my persona-non-validated certificates they don’t offer the ability to get just one usage.  Also, some do in fact issue separate certs.  I don’t think you can lump all the users together.

- On the future, the part you didn’t mention is that EC-based certificates might not specify both digital signature and transport/agreement.  The TLS EC certificates I’m seeing only include only sig.  Whether the S/MIME certs follow suite - I don’t think you can say authoritatively they will or won’t unless you’re a CA who is issuing them.  If the certificates include both KUs then yeah EC certs are about half of RSA certs - but if not then two of ‘em is about the same as one RSA cert.

- Finally on complexity, what’s proposed is definitely more than what’s there now but how much more complex it is I think is in the eyes of the beholder.

spt

[1] 1) One of the other thing to note for CRLs that span more than one year is that the number of revocations seem to be increasing.  I could speculate as to why but maybe we can leave that for another thread. 2) Some of the bigger CRLs are bigger not entirely based on the # of entries it’s also because they used longer serial #s and included reasons codes - a 64MByte CRL had ~300 entries. 3) Interesting to note that in the EC-based cert the spki+(sig+alg id) is like 89+(73+10) octets - could save another 80 octets by not including a subject name and just using the SAN.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 16 Oct 2014 10:58:28 -0400

<chair-hat> 
Thank you Sean 
for supplying numbers and reasons to consider all the points. 

Wg members, please start giving feedback on this tread as to going forward, 
should we in the S/MIME DANE documents explicitly support “policy expression” or 
reject it. 
</chair-hat> 
<personal-hat> 
to me one question to answer is: 
If  X@Y sends S/MIME signed message to  DANE WG on January 20’th 2016. 
X@Y leaves Y on Feb 15’th 2016. 

Is there any value in being able to validate the signature when a document editor gets around to read the message March 15 2016
while updating the document referenced in the email to meet the ID deadline for IETF-95  ? 

	Olafur

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 16 Oct 2014 17:17:49 +0200

On 16 okt 2014, at 16:58, Olafur Gudmundsson <[email-masked]> wrote:

> Is there any value in being able to validate the signature when a document editor gets around to read the message March 15 2016 while updating the document referenced in the email to meet the ID deadline for IETF-95  ? 

You basically want to know if certificate C was valid at time T. A CRL might tell you when a certificate was revoked, whereas OCSP does not. Neither of the proposals discussed in this group so far would help you with that either.

Paul and I advocate that SMIMEA will only tell you if a given certificate is valid in real time (or in the proximity of). Others say an explicit revoked flag would be useful.

I believe your question is interesting, but I suspect it is out of scope for this group. If a given certificate is not valid, you can always go back to a CRL (if one exists) and find out when it was revoked.

	jakob

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 17 Oct 2014 07:46:43 -0700

> The idea that the proponents of these changes need to go change the TLSA spec because you think it applies to both seems a little bit excessive.  If you think the changes apply to both, then great…

Nor do I see a reason for the proponents to burden us with making the changes here if there is no support for them. As you probably saw, another WG member pointed out that there were significant technical issues with the wording of the revocation proposal. If we incorporate that into the S/MIME draft, that draft will get delayed while the proponents get their wording right.

A better process would be for the proponents to offer a standalone draft for the idea that will be an extension that would be usable to both TLSA and SMIMEA and any other documents that come later.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Oct 2014 15:04:49 +0000

On Thu, Oct 16, 2014 at 05:17:49PM +0200, Jakob Schlyter wrote:

> > If  X@Y sends S/MIME signed message to  DANE WG on January 20th 2016. 
> > X@Y leaves Y on Feb 15th 2016. 
> > 
> > Is there any value in being able to validate the signature when a document
> > editor gets around to read the message March 15 2016 while updating the
> > document referenced in the email to meet the ID deadline for IETF-95  ?
> 
> You basically want to know if certificate C was valid at time T. A CRL
> might tell you when a certificate was revoked, whereas OCSP does not.
> Neither of the proposals discussed in this group so far would help you
> with that either.

Perhaps some of you have seen the recent comments by Jerry Leichter
on Perry's cryptography list in the thread about HP revoking their
software signing certificate.  The problem with revocation of
signing certificates for "data at rest" is rather deep.  We simply
don't have correct semantics for this at present.

Revocation that invalidates messages older than the revocation
event is rather sub-optimal.

With email, the MUA and/or mailstore should validate messages when
they first arrive, and record the validity of the signature at that
point.  With validity frozen at time of arrival, it is largely
sufficient to remove the ability of obsolete keys to sign new mail
and delist them as valid keys for receiving new encrypted mail.

> Paul and I advocate that SMIMEA will only tell you if a given certificate
> is valid in real time (or in the proximity of). Others say an explicit
> revoked flag would be useful.

I concur, subsequent revocation of already received and at the time
accepted as valid mail is too little too late.  It has in most
cases already been acted on (for better or for worse) at time of
arrival.

-- 
	Viktor.

---

From: "Osterweil, Eric" <[email-masked]>
Date: Mon, 20 Oct 2014 15:23:57 +0000

> Nor do I see a reason for the proponents to burden us with making the changes here if there is no support for them. As you probably saw, another WG member pointed out that there were significant te…

Hey Paul,

TLS and S/MIME use pretty different security models (session vs. object security), so necessarily coupling the RRs doesn’t seem to make sense.  In addition, to echo what others have already said on the list, I really don’t think it is reasonable to gate updates to the SMIMEA proposal on updating TLSA.

> A better process would be for the proponents to offer a standalone draft for the idea that will be an extension that would be usable to both TLSA and SMIMEA and any other documents that come later.

Just by looking at the list, it seems like there are a number of voices that disagree with you on this.  Also, isn’t the SMIMEA work still an evolving draft?  What else does one need besides: articulated rationale, proposed requirements, operational data, suggested text, and running code from multiple people in order to support suggested revisions?  Please accept the proposed SMIMEA changes into the SMIMEA draft so that we can make progress on this work.

Thank you,

Eric

---

From: "Osterweil, Eric" <[email-masked]>
Date: Mon, 20 Oct 2014 15:24:07 +0000

> cases already been acted on (for better or for worse) at time of

For what it’s worth, I think the proposed text was exactly inline with what you both are suggesting.  The suggestion was a way to help enterprises express their needs (under some circumstances) a little more cleanly in DNS.  For example, a single DANE TA could be used to authorized all of an organization’s S/MIME users, and selective ``user-no-longer-valid'' (i.e. revocation) entries could override this.  This could definitely allow for the fact that the S/MIME cert of a ``user-no-longer-valid'' employee was once valid, but not at the time of querying DNS.  As you both point out (I believe), this is different than other notions of revocation.

I think we are all on the same page, and perhaps the text was not clear enough?  Maybe it's also possible there was some misunderstanding from the protracted email discussion?  The revocation discussion (IIRC) really had to do with an assertion that TLS did not have revocation needs.

Eric

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Oct 2014 15:54:23 +0000

On Mon, Oct 20, 2014 at 03:24:07PM +0000, Osterweil, Eric wrote:

> For example, a single DANE TA could be used to authorized all of an
> organization?s S/MIME users, and selective ``user-no-longer-valid'' (i.e.
> revocation) entries could override this.  

The preferred way to "revoke" a DANE-TA(2) binding for a single
end-entity is to publish a DANE-EE(3) binding for that entity until
the previously issued certificate has expired.

Where normally one would have:

    _smimea._dane.example.com.               1H IN SMIMEA 2 0 1 {blob}
    <entity1-smimea-label>.example.com.      1H IN CNAME _smimea._dane.example.com.
    <entity2-smimea-label>.example.com.      1H IN CNAME _smimea._dane.example.com.
    ....
    <entity100000-smimea-label>.example.com. 1H IN CNAME _smimea._dane.example.com.

When the keys for entity42 are compromised, you publish:

    <entity42-smimea-label>.example.com.     1H IN SMIME 3 1 1 {blob}

(or perhaps "3 0 0" instead of "3 1 1" if that's more appropriate
for SMIME).  Once the compromised certificate has expired back to:

    <entity42-smimea-label>.example.com.     1H IN CNAME _smimea._dane.example.com.

This is fine for validating sender presented chains.  When looking
for a recipient key to encrypt to, an end-entity binding is
unavoidable.

> I think we are all on the same page, and perhaps the text was not clear
> enough?  Maybe it's also possible there was some misunderstanding from
> the protracted email discussion?  The revocation discussion (IIRC) really
> had to do with an assertion that TLS did not have revocation needs.

My view is that revocation is not terribly useful without accurate
signalling of when something was revoked, and whether the revocation
applies to content validated prior to the revocation.  Just publishing
a binary "revoked" bit in DNS would I think be a mistake (do more
harm than good).

With SMIME used so little, there has been little investment in
figuring out how to do revocation correctly.  Reasoning by analogy
with interactive protocols encrypting data in motion is deeply
flawed when applied to data at rest.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Oct 2014 08:54:50 -0700

On Oct 20, 2014, at 8:23 AM, Osterweil, Eric <[email-masked]> wrote:

> TLS and S/MIME use pretty different security models (session vs. object security)

Sure, but how is that difference relevant here? DANE is about distributing certificates and keying information through DNS: it is agnostic to the security model.

> , so necessarily coupling the RRs doesn’t seem to make sense.  

It has so far in the WG. The WG asked us early on to make as few changes as possible to the TLSA definition.

> In addition, to echo what others have already said on the list, I really don’t think it is reasonable to gate updates to the SMIMEA proposal on updating TLSA.

Fully agree, and that's not what I was proposing. The two changes that you have proposed (revocation indication and alternate sources for getting the information) can be done as new values to the existing RR subfields. Doing so would make what you want usable for both SMIMEA and TLSA. Proposals to make those changes can trivially be done as stand-alone Internet Drafts.

> Just by looking at the list, it seems like there are a number of voices that disagree with you on this.  

Where "a number" means "two", and even they didn't actually disagree about creating standalone drafts, simply that the assumption that the use cases might be different.

> Also, isn’t the SMIMEA work still an evolving draft?  

Yes, of course.

> What else does one need besides: articulated rationale, proposed requirements, operational data, suggested text, and running code from multiple people in order to support suggested revisions?  

Consensus in the WG. That may seem anathema to you, but it's the way that the IETF works.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Oct 2014 09:01:56 -0700

On Oct 20, 2014, at 8:24 AM, Osterweil, Eric <[email-masked]> wrote:

> I think we are all on the same page, and perhaps the text was not clear enough?  

I'm with Jakob and Viktor: the text is ill-specified. You are inventing a new revocation mechanism without enough semantics for a relying party to use it in a concrete manner. You also don't say how to use your new revocation information when it conflicts with other revocation information for the same keying material, such as CRLs and OCSP staples for the same certificate.

> Maybe it's also possible there was some misunderstanding from the protracted email discussion?  The revocation discussion (IIRC) really had to do with an assertion that TLS did not have revocation needs.

Did anyone assert that? If so, please point it out. People asserted that revocation happens rarely for TLS certificates.

--Paul Hoffman

---

From: "Osterweil, Eric" <[email-masked]>
Date: Mon, 20 Oct 2014 16:06:56 +0000

> Sure, but how is that difference relevant here? DANE is about distributing certificates and keying information through DNS: it is agnostic to the security model.

The relevant information needed during distribution would seem to vary based on the security model (as evidenced by this thread).  Actually, that’s been one of the main points of this thread.

> It has so far in the WG. The WG asked us early on to make as few changes as possible to the TLSA definition.

Paul, we are all part of the working group.  This is the the working group.  I feel like I must be missing some nuanced distinction you have in mind between working group discussions (like this one) and some other arbitration?

> Fully agree, and that's not what I was proposing. The two changes that you have proposed (revocation indication and alternate sources for getting the information)

Paul, these were not my proposals.  These were proposed by Scott Rose.  I saw merit in them and when they seemed to be dismissed out of hand I voiced my support.  Also, the proposal included the _encr + _sign labels.

> can be done as new values to the existing RR subfields. Doing so would make what you want usable for both SMIMEA and TLSA. Proposals to make those changes can trivially be done as stand-alone Internet Drafts.

But we are still roughing out this draft.  This would seem to be a good opportunity to try and get things write in the initial work.

> Where "a number" means "two", and even they didn't actually disagree about creating standalone drafts, simply that the assumption that the use cases might be different.

I think this thread is devolving.  The number is greater than two, and reviewing the posts of this thread should corroborate the higher level of interest.

> Consensus in the WG. That may seem anathema to you, but it's the way that the IETF works.

Paul, what constituted ``the WG’’ in your mind? 

Eric

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Oct 2014 16:08:33 +0000

On Mon, Oct 20, 2014 at 09:01:56AM -0700, Paul Hoffman wrote:

> > Maybe it's also possible there was some misunderstanding from
> > the protracted email discussion?  The revocation discussion (IIRC)
> > really had to do with an assertion that TLS did not have revocation
> > needs.
> 

I've been known to say that with DANE TLSA, explicit revocation is
superseded by publishing an updated TLSA record.  Don't know whether
that was ever in the context the revocation discussion in question.

Of course that only applies to situations in which DANE is always
used.  DANE is of no help when the verifier is using "traditional"
PKI.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Oct 2014 12:10:18 -0400 (EDT)

> For what it’s worth, I think the proposed text was exactly inline with what you both are suggesting.  The suggestion was a way to help enterprises express their needs (under some circumstances) a l…

For email addresses that are no longer valid, we have an SMTP error
code that prevents delivery. The SMIME and OPENPGPKEY records are not
substitutes for "is a valid email user" and it would needlessly complicate
the records.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Mon, 20 Oct 2014 09:46:16 -0700

[top post at random place in thread ]

I'd like everyone to take a breath and step back for a minute. I'd like to
(off list) arrange a call with Paul and Eric so we can summarize this to be
as concise as possible and then get the WG consensus *on the actual points
under discussion*...

W

On Monday, October 20, 2014, Osterweil, Eric <[email-masked]>
wrote:

>
> On Oct 20, 2014, at 11:54 AM, Paul Hoffman <[email-masked]
> <javascript:;>> wrote:
>
> > On Oct 20, 2014, at 8:23 AM, Osterweil, Eric <[email-masked]
> <javascript:;>> wrote:
> >
> > Sure, but how is that difference relevant here? DANE is about
> distributing certificates and keying information through DNS: it is
> agnostic to the security model.
>
> The relevant information needed during distribution would seem to vary
> based on the security model (as evidenced by this thread).  Actually,
> that’s been one of the main points of this thread.
>
> Paul, we are all part of the working group.  This is the the working
> group.  I feel like I must be missing some nuanced distinction you have in
> mind between working group discussions (like this one) and some other
> arbitration?
>
> >> In addition, to echo what others have already said on the list, I
> really don’t think it is reasonable to gate updates to the SMIMEA proposal
> on updating TLSA.
> >
> > Fully agree, and that's not what I was proposing. The two changes that
> you have proposed (revocation indication and alternate sources for getting
> the information)
>
> Paul, these were not my proposals.  These were proposed by Scott Rose.  I
> saw merit in them and when they seemed to be dismissed out of hand I voiced
> my support.  Also, the proposal included the _encr + _sign labels.
>
> > can be done as new values to the existing RR subfields. Doing so would
> make what you want usable for both SMIMEA and TLSA. Proposals to make those
> changes can trivially be done as stand-alone Internet Drafts.
>
> But we are still roughing out this draft.  This would seem to be a good
> opportunity to try and get things write in the initial work.
>
> >>> A better process would be for the proponents to offer a standalone
> draft for the idea that will be an extension that would be usable to both
> TLSA and SMIMEA and any other documents that come later.
> >>
> > Where "a number" means "two", and even they didn't actually disagree
> about creating standalone drafts, simply that the assumption that the use
> cases might be different.
>
> I think this thread is devolving.  The number is greater than two, and
> reviewing the posts of this thread should corroborate the higher level of
> interest.
>
> >> What else does one need besides: articulated rationale, proposed
> requirements, operational data, suggested text, and running code from
> multiple people in order to support suggested revisions?
> >
> [email-masked] <javascript:;>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Dan York <[email-masked]>
Date: Mon, 20 Oct 2014 16:52:21 +0000

On Oct 20, 2014, at 11:54 AM, Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:

On Oct 20, 2014, at 8:23 AM, Osterweil, Eric <[email-masked]<mailto:[email-masked]>> wrote:

This is a key point to me.  If we are to make DANE truly successful and get DANE-related records out there widely, they need to be *easily* deployed out there.  Right now, for a great number of people out there, their experience of adding DNS records is to go to their DNS hosting provider (or very often their DNS *registrar* that is also doing the DNS hosting for them) and enter in DNS records through some form of web interface.

One of the challenges we *already* face is to get those DNS hosting providers to add support for TLSA records.  I just went to the "domain manager" for an extremely larger registrar/hosting provider and looked at the list of DNS records that I can add as a user:  A, CNAME, MX, TXT, SPF, SRV, AAAA, NS.   No TLSA.  No option I saw to edit the zone file directly.

Until we can get that large DNS registrar/hosting provider to add support for TLSA records to the management GUI, all the people using them can't use DANE.    Given the zillion other things they want to do, I would suspect that it's going to take some good number of customers asking to get them to do so.   And that's just *one* DNS hosting provider.

I think it's going to be hard enough to get DNS hosting providers to add the TLSA record to their list of supported record types, let alone asking them to *also* add the SMIMEA record to the list of supported record types.  BUT... if SMIMEA is basically a renamed TLSA, then you can make that argument to them "it's just the same fields you have for TLSA but with a different name".  If they have already added TLSA support, adding SMIMEA can be just a case of re-using the code.   However, if SMIMEA adds more fields then it means the DNS hosting providers have to develop new code... and so the case has to be made to all of them about why they should add yet-another-record-type to their GUIs.

Personally, I think it would be great if every "DANE-like" usage would just use the TLSA record... then we have to only fight that battle once to get it added into configuration/management GUIs.    But if we are to create other TLSA-like records to have different names, let's at least please keep them the same so that we can get them all more easily deployed.

My 2 cents,
Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Oct 2014 18:29:05 +0000

On Mon, Oct 20, 2014 at 04:52:21PM +0000, Dan York wrote:

> Personally, I think it would be great if every "DANE-like" usage
> would just use the TLSA record... then we have to only fight that
> battle once to get it added into configuration/management GUIs.
> But if we are to create other TLSA-like records to have different
> names, let's at least please keep them the same so that we can get
> them all more easily deployed.

I empathise with the sentiment, but there's a bit more to a friendly
DANE record UI than the RDATA format.

For TLSA, the UI would have an entry box for the port number, and
radio buttons for the protocol (tcp/udp/...).

For SMIMEA there would be a text field for the address localpart,
which used to enter the address.  If (as is almost always the case)
the DNS zone is mastered from some sort of underlying database,
one might even want to store the address (for friendlier search,
...) while using its sha224 hash in the SMIME label.

So there may be *some* code re-use, but doing it right will likely
require custom code for any additional record types with a TLSA-like
RDATA.

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 20 Oct 2014 15:18:08 -0700

> as concise as possible and then get the WG consensus *on the actual points

To help us focus the discussion and help us get make progress, we will
be putting this conversation on hold, and discussing the requirements
document - draft-osterweil-dane-ent-email-reqs-00.

Eric will review the doc, revise it if necessary (along with his
co-chairs) and then either post it or let us know that it is still up
to date and then we'll discuss it and the requirements. This should
let us make progress on this doc...

Thanks to everyone for being willing to discuss this in a civil manner...

w

>> > distributing certificates and keying information through DNS: it is agnostic
>> > to the security model.
>>
>> based on the security model (as evidenced by this thread).  Actually, that’s
>> been one of the main points of this thread.
>>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Oct 2014 10:09:04 +1100

In message <[email-masked]>, Dan York writes:
>
>
> On Oct 20, 2014, at 11:54 AM, Paul Hoffman
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Oct 20, 2014, at 8:23 AM, Osterweil, Eric
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> , so necessarily coupling the RRs doesn't seem to make sense.
>
> This is a key point to me.  If we are to make DANE truly successful and
> get DANE-related records out there widely, they need to be *easily*
> deployed out there.  Right now, for a great number of people out there,
> their experience of adding DNS records is to go to their DNS hosting
> provider (or very often their DNS *registrar* that is also doing the DNS
> hosting for them) and enter in DNS records through some form of web
> interface.
>
> One of the challenges we *already* face is to get those DNS hosting
> providers to add support for TLSA records.  I just went to the "domain
> manager" for an extremely larger registrar/hosting provider and looked at
> the list of DNS records that I can add as a user:  A, CNAME, MX, TXT,
> SPF, SRV, AAAA, NS.   No TLSA.  No option I saw to edit the zone file
> directly.
>
> Until we can get that large DNS registrar/hosting provider to add support
> for TLSA records to the management GUI, all the people using them can't
> use DANE.    Given the zillion other things they want to do, I would
> suspect that it's going to take some good number of customers asking to
> get them to do so.   And that's just *one* DNS hosting provider.
>
> I think it's going to be hard enough to get DNS hosting providers to add
> the TLSA record to their list of supported record types, let alone asking
> them to *also* add the SMIMEA record to the list of supported record
> types.  BUT... if SMIMEA is basically a renamed TLSA, then you can make
> that argument to them "it's just the same fields you have for TLSA but
> with a different name".  If they have already added TLSA support, adding
> SMIMEA can be just a case of re-using the code.   However, if SMIMEA adds
> more fields then it means the DNS hosting providers have to develop new
> code... and so the case has to be made to all of them about why they
> should add yet-another-record-type to their GUIs.
>
> Personally, I think it would be great if every "DANE-like" usage would
> just use the TLSA record... then we have to only fight that battle once
> to get it added into configuration/management GUIs.    But if we are to
> create other TLSA-like records to have different names, let's at least
> please keep them the same so that we can get them all more easily
> deployed.

This is one of the reasons we wrote "named-rrchecker".  It is a
simple tool that can list out the records types it supports so you
can dynamically build a list of named record types to use along side
TYPE#####.

The currently supported type list is:

A NS MD MF CNAME SOA MB MG MR NULL WKS PTR HINFO MINFO MX TXT RP
AFSDB X25 ISDN RT NSAP NSAP-PTR SIG KEY PX GPOS AAAA LOC NXT EID
NIMLOC SRV ATMA NAPTR KX CERT A6 DNAME APL DS SSHFP IPSECKEY RRSIG
NSEC DNSKEY DHCID NSEC3 NSEC3PARAM TLSA HIP CDS CDNSKEY SPF UINFO
UID GID UNSPEC NID L32 L64 LP EUI48 EUI64 URI CAA DLV

It will also parse the matching records using presentation format
if that is known and unknown record format and emit the record in
unknown record format and/or presentation format if that has been
defined.

Unknown record format means you don't have to update the name servers
everytime you update named-rrchecker.  This is suitable to be added
to any master file or to be used as input to nsupdate.

The presentation format is useful for displaying to the user what
they just entered cleaned up / converted from unknown record format.

You don't need to update web forms to add new types.  You just
update named-rrchecker periodically and the front end picks up
support for the new RR type.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Osterweil, Eric" <[email-masked]>
Date: Fri, 31 Oct 2014 14:47:19 +0000

Hey again everyone,

The thread has calmed down a little bit, and I just wanted to add one more attempt to find a middle-ground to this thread: the initial message (below) included suggested text.  Later in the thread, there were some suggested modifications.  Thanks to all of those who spent time thinking about this and offered suggestions!  I’ve taken a couple of minutes to incorporate feedback, and here is some revised suggested text:

On Sep 29, 2014, at 8:26 AM, Osterweil, Eric <[email-masked]> wrote:

> Hey everyone,
> 
> Based on our implementation experience we would like to suggest that the following text (taken from Scott Rose's email: http://www.ietf.org/mail-archive/web/dane/current/msg06180.html ) be incorporated into the current version of the draft-ietf-dane-smime document.  We are sending text (below), but at a high-level, the text outlines a few useful additions:
> 
> 1 - Usage #4 (reject) is likely to be very important.  This could either emphasize the difference between saying, ``don't use this cert for this operation,'' and ``this cert is universally revoked'' or be used to selectively override an organization-wide TA for certain employees that have left the organization.
> 
> 2 - The certificate access field (Section 2.1.4) would enable alternate discovery mechanisms that could help aid incremental deployment and transition schemes.  For example, while cutting over to a DANE solution, some enterprises may want to transition users from (say) AD to DANE, and this field would enable that.
> 
> 3 - The ``_encr'' and ``_sign'' labels are excellent additions to the management of zone sizes and lookup sizes.  Rather than querying for all keys and then locally selecting from them, I (as an RP) likely already know which of these I want, and I should be able to look them up separately in DANE (and owners should be able to manage them separately in DANE).

. . .

2.1.  SMIMEA RDATA Fields

The RDATA for the SMIMEA RR consists of a one-octet certificate usage
field, a one-octet selector field, a one-octet matching type field, a
one-octet certificate access field, and the certificate association
data field.

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Cert. Usage  |   Selector    | Matching Type | Cert. Access  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                 Certificate Association Data                  /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1.  The Certificate Usage Field

A one-octet value, called "certificate usage", specifies the provided
association that will be used to validate the certificate.  This
value will be defined in a new IANA registry in order to make it
easier to add additional certificate usages in the future.  Four of
the initial usages defined in this document are similar to the first
four TLSA [RFC6698] certificate usages.  The certificate usage values
are:

   0 or PKIX-CA -- PKIX-CA is used to specify a CA certificate, or
   the public key of such a certificate, that MUST be found in any of
   the PKIX certification paths for the user.  This certificate usage
   is sometimes referred to as "CA constraint" because it limits
   which CA can be used to issue certificates for a given user.  The
   presented certificate MUST pass PKIX certification path
   validation, and a CA certificate that matches the SMIMEA record
   MUST be included as part of a valid certification path.  Because
   this certificate usage allows both trust anchors and CA
   certificates, the certificate might or might not have the
   basicConstraints extension present.

   1 or PKIX-EE -- PKIX-EE is used to specify an end entity
   certificate, or the public key of such a certificate, that MUST be
   matched with the end entity certificate for the SMIME user.  This
   certificate usage is sometimes referred to as "user certificate
   constraint" because it limits which end entity certificate can be
   used by a given user.  The target user certificate MUST pass PKIX
   certification path validation and MUST match the SMIMEA record.

   2 or DANE-TA -- DANE-TA is used to specify a certificate, or the
   public key of such a certificate, that MUST be used as the trust
   anchor when validating the SMIME user certificate.  This
   certificate usage is sometimes referred to as "trust anchor
   assertion" and allows a domain name administrator to specify a new
   trust anchor -- for example, if the domain issues its own
   certificates under its own CA that is not expected to be in the
   end users' collection of trust anchors.  The target user
   certificate MUST pass PKIX certification path validation, with any
   certificate matching the SMIMEA record considered to be a trust
   anchor for this certification path validation.

   3 or DANE-EE -- DANE-EE is used to specify a certificate, or the
   public key of such a certificate, that MUST match the SMIME user's
   certificate.  This certificate usage is sometimes referred to as
   "domain-issued certificate" because it allows for a domain name
   administrator to issue certificates for a domain without involving
   a third-party CA.  The target user certificate MUST match the
   SMIMEA record.  The difference between certificate usage 1 and
   certificate usage 3 is that certificate usage 1 requires that the
   certificate pass PKIX validation, but PKIX validation is not
   tested for certificate usage 3.

   4 or REJECT -- REJECT is used by the domain owner to assert that
   at the time of querying the DNS, this user's certificate MUST be 
   considered invalid for the requested function (i.e. signature or encryption).  
   This is a stronger assertion than a failed certificate validation check.
   Possible usage scenarios include de-authorizing stale employee credentials
   by selectively overriding TAs that are used to authorize entire organizations.

The certificate usages defined in this document explicitly only apply
to PKIX-formatted certificates in DER encoding [ITU.X690.2002].  If
SMIME allows other formats later, or if extensions to this RR type
are made that accept other formats for certificates, those
certificates will need their own certificate usage values.

2.1.2.  The Selector Field

A one-octet value, called "selector", specifies which part of the
SMIME certificate presented by the server will be matched against the
association data.  This value will be defined in a new IANA registry.
The selectors defined in this document are:

   0 or CERT -- Full certificate: the Certificate binary structure as
   defined in [RFC5280].

   1 or SPKI -- SubjectPublicKeyInfo: DER-encoded binary structure as
   defined in [RFC5280].

(Note that the use of "selector" in this document is completely
unrelated to the use of "selector" in DomainKeys Identified Mail
(DKIM) [RFC6376].)

2.1.3.  The Matching Type Field

A one-octet value, called "matching type", specifies how the
certificate association is presented.  This value will be defined in
a new IANA registry.  The types defined in this document are:

   0 or Full -- Exact match on selected content

   1 or SHA2-256 -- SHA-256 hash of selected content [RFC6234]

   2 or SHA2-512 -- SHA-512 hash of selected content [RFC6234]

If the SMIMEA record's matching type is a hash, having the record use
the same hash algorithm that was used in the signature in the
certificate (if possible) will assist clients that support a small
number of hash algorithms.

2.1.4.  Certificate Access Field

This one octet value indicates an alternative method for certificate
discovery.  Some domain owners may not want to publish user
certificates via DNS but may want to use the DNS to advertise the
means to access them.  If full user certificates are not included in
the Certificate Association Data this field MAY be used to indicate
how the user's certificate can be obtained.  The RDATA certificate
association data MUST be used to validate certificates obtained by
the alternative method.

   0 or NO: No alternative method advertised.

   1 or NAPTR : NAPTR record available.  The same domain name used
   for this SMIMEA request MAY be used again with type NAPTR
   [RFC3403] to retrieve the URI for certificate access.

   2 or WF: X.509 certificates available in WebFinger [RFC7033].

2.1.5.  The Certificate Association Data Field

This field specifies the "certificate association data" to be
matched.  These bytes are either raw data (that is, the full
certificate or its SubjectPublicKeyInfo, depending on the selector)
for matching type Full (0), or the hash of the raw data for matching
types SHA2-256 (1) and SHA2-512 (2).  The data refers to the
certificate in the association, not to the ASN.1 Certificate object.
For certificate usage type REJECT (4) at least one byte of data is
REQUIRED but the value MUST be ignored.

2.2.  SMIMEA RR Presentation Format

The presentation format of the RDATA portion (as defined in
[RFC1035]) is as follows:

o  The certificate usage field MUST be represented either as a
   certificate usage mnemonic or an 8-bit unsigned integer.

o  The selector field MUST be represented either as a selector field
   mnemonic or an 8-bit unsigned integer.

o  The matching type field MUST be represented either as a matching
   type mnemonic or an 8-bit unsigned integer.

o  The certificate access field MUST be represented either as a
   certificate access mnemonic or an 8-bit unsigned integer.

o  The certificate association data field MUST be represented as a
   string of hexadecimal characters.  Whitespace is allowed within
   the string of hexadecimal characters, as described in [RFC1035].

Where practical, the mnemonic form SHOULD be used in order to provide
clarity.

2.3.  SMIMEA RR Examples

In the following examples, the domain name is formed using the rules
in Section 3.

An example of a hashed (SHA2-256) association of a Full PKIX-CA
certificate in the PKIX validation path of a certificate used to
validate a signed S/MIME message.  No alternative certificate access
is advertised.

   1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.example.com. IN SMIMEA (
      0 0 1 0 d2abde240d7cd3ee6b4b28c54df034b9
              7983a1d16e8a410e4561cb106618e971 )

 Alternatively

   1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.example.com. IN SMIMEA (
      PKIX-CA FULL SHA2-256 NO d2abde240d7cd3ee6b4b28c54df034b9
                               7983a1d16e8a410e4561cb106618e971 )

An example resource record providing Full self-signed encryption
certificate:

   1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._encr._smimecert.example.com. IN SMIMEA (
      DANE-EE Cert Full NO 30820307308201efa003020102020... )

An example of resource record invalidating all digital signatures by
identified user:

   1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.example.com. IN SMIMEA (
                         REJECT Cert Full NO 00 )

...

3.  Domain Names for S/MIME Certificate Associations

SMIMEA domain names include function and user labels.  The purpose is
to identify the function specific certificate if a user has multiple
certificates.  Alias MAY be used if a user has a common certificate
for both functions

...

3.1.  Domain Name Preparation

Domain names are prepared for requests in the following manner.

1.  The user name (the "left-hand side" of the email address, called
    the "local-part" in the mail message format definition [RFC5322]
    and the "local part" in the specification for internationalized
    email [RFC6530]), is encoded with Base32 [RFC4648], to become the
    left-most label in the prepared domain name.  This does not
    include the "@" character that separates the left and right sides
    of the email address.

2.  The second left-most label is the function specific label
    segment.  It is selected based on the S/MIME function the MUA is
    performing.  Values are:

       "_encr" for obtaining or validating a certificate or public
       key to be used to encrypt a message.

       "_sign" for certificate validation data to verify a digital
       signature.

    For certificate use cases XXXX-EE (1 and 3) the function specific
    label SHOULD be consistent with the Key Usage field (defined in
    section 4.2.1.3 of [RFC5280]) of the associated certificate.

3.  The string "_smimecert" becomes the third left-most label in the
    prepared domain.  The function specific label segment is separate
    to enable delegation of a single _smimecert zone cut.

4.  The domain name (the "right-hand side" of the email address,
    called the "domain" in [RFC5322]) is appended to the result of
    step 3 to complete the prepared domain name.

...

3.2.  Domain Name Examples

Example 1.  Signature certificate verification: to request an SMIMEA
resource record to verify a signature certificate for a user whose
address is "[email-masked]", you would use:

         "df7f0c341e185f1073a2caef0d37a8b6a11fac62f46beaf459532bb0._sign._smimecert.example.com"

Example 2.  Encryption key discovery: to request an SMIMEA resource
record for encrypting an email to user "[email-masked]" you would
use:

         "550c233eeabd0f03bb42b99956efa56cdadaef7d346a04e351ac1b7a._encr._smimecert.example.com"

4.  Use of SMIMEA Records in SMIME

SMIMEA records are used to publish user certificates or validate user
certificates acquired by other means.  Typically these use cases are
associated with message encryption and signature validation processes
respectively.  Section 2.1 of this document defines the mandatory
matching rules for the data.  Where possible, consistency with
[RFC6698] is maintained.

4.1.  Usable Certificate Associations

An implementation of this protocol makes a DNS query for SMIMEA
records, validates these records using DNSSEC, and uses the resulting
SMIMEA records and validation to modify S/MIME message processing
behavior.

Determining whether an SMIMEA RRSet can be used MUST be based on the
DNSSEC validation state (as defined in [RFC4035]).

o  An SMIMEA RRSet whose DNSSEC validation state is secure MUST be
   used as a certificate association for S/MIME unless a local policy
   would prohibit the use of the specific certificate association in
   the secure SMIMEA RRSet.

o  If the DNSSEC validation state on the response to the request for
   the SMIMEA RRSet is bogus then the RRSet MUST be disregarded and
   considered unusable.  Additional SMIMEA queries may be initiated.

o  If the DNSSEC validation state is indeterminate or insecure then
   the SMIMEA RRSet MUST be disregarded and considered unusable.

MUAs that rely on another entity to perform the DNSSEC signature
validation SHOULD use a secure mechanism between themselves and the
validator.  Examples of secure transports to other hosts include TSIG
[RFC2845], SIG(0) [RFC2931], and IPsec [RFC6071].  Note that it is
not sufficient to use secure transport to a DNS resolver that does
not do DNSSEC signature validation.

If a certificate association contains a certificate usage, selector,
or matching type that is not understood by the MUA, that certificate
association MUST be considered unusable.  If the comparison data for
a certificate is malformed, the certificate association MUST be
considered unusable.

If a certificate association contains a matching type or certificate
association data that uses a cryptographic algorithm that is
considered too weak for the MUA's local policy, the certificate
association MUST be considered unusable.

If a MUA receives zero usable certificate associations from a DNS
request or from its cache, it processes S/MIME requests in the normal
fashion without any input from the SMIMEA records.

If a MUA performing certificate validation receives one or more
usable certificate associations then it MUST attempt to match each
certificate association with the user's certificate until a
successful match is found.  If no certificate associations match then
the certificate MUST be considered invalid.

If a MUA makes an SMIMEA request for an encryption certificate and
the response includes more than one valid certificate, the
certificate with the most recent "Not Before" data SHOULD be
selected. [ Are there better criteria? ]

...

6.  IANA Considerations

6.1.  SMIMEA RRtype

This document uses a new DNS RR type, SMIMEA, whose value will be
allocated by IANA from the Resource Record (RR) TYPEs subregistry of
the Domain Name System (DNS) Parameters registry.

6.2.  SMIMEA Certificate Usage Registry

This document creates a new registry, "SMIMEA Certificate Usages".
The registry policy is "RFC Required".  The initial entries in the
registry are:

  +-------+----------+--------------------------------+-------------+
  | Value | Mnemonic | Short Description              | Reference   |
  +-------+----------+--------------------------------+-------------+
  |   0   | PKIX-CA  | CA      constraint             | [this doc]  |
  |   1   | PKIX-EE  | Service certificate constraint | [this doc]  |
  |   2   | DANE-TA  | Trust anchor assertion         | [this doc]  |
  |   3   | DANE-EE  | Domain-issued certificate      | [this doc]  |
  |   4   | REJECT   | Invalid Certificate or User    | [this doc]  |
  | 5-254 |          | Unassigned                     |             |
  |  255  | PrivCert | Reserved for Private Use       | [this doc]  |
  +-------+----------+--------------------------------+-------------+

Applications to the registry can request specific values that have
yet to be assigned.

6.3.  SMIMEA Selectors

This document creates a new registry, "TLSA Selectors".  The registry
policy is "Specification Required".  The initial entries in the
registry are:

       +-------+----------+--------------------------+-------------+
       | Value | Mnemonic | Short Description        | Reference   |
       +-------+----------+--------------------------+-------------+
       |   0   | Cert     | Full certificate         | [this doc]  |
       |   1   | SPKI     | SubjectPublicKeyInfo     | [this doc]  |
       | 2-254 |          | Unassigned               |             |
       |  255  | PrivSel  | Reserved for Private Use | [this doc]  |
       +-------+----------+--------------------------+-------------+

Applications to the registry can request specific values that have
yet to be assigned.

6.4.  SMIMEA Matching Types

This document creates a new registry, "SMIMEA Matching Types".  The
registry policy is "Specification Required".  The initial entries in
the registry are:

      +-------+-----------+--------------------------+-------------+
      | Value | Mnemonic  | Short Description        | Reference   |
      +-------+-----------+--------------------------+-------------+
      |   0   | Full      | No hash used             | [this doc]  |
      |   1   | SHA2-256  | 256 bit hash by SHA2     | [this doc]  |
      |   2   | SHA2-512  | 512 bit hash by SHA2     | [this doc]  |
      | 3-254 |           | Unassigned               |             |
      |  255  | PrivMatch | Reserved for Private Use | [this doc]  |
      +-------+-----------+--------------------------+-------------+

Applications to the registry can request specific values that have
yet to be assigned.

6.5.  Certificate Access Field

This document creates a new registry, "SMIMEA Certificate Access".
The registry policy is "Specification Required".  The initial entries
in the registry are:

      +-------+-----------+---------------------------+-------------+
      | Value | Mnemonic  | Short Description         | Reference   |
      +-------+-----------+---------------------------+-------------+
      |   0   | NO        | No Alternative Advertised | [this doc]  |
      |   1   | NAPTR     | NAPTR                     | [this doc]  |
      |   2   | WF        | WebFinger                 | [this doc]  |
      | 3-254 |           | Unassigned                |             |
      |  255  | PrivUse   | Reserved for Private Use  | [this doc]  |
      +-------+-----------+---------------------------+-------------+

Applications to the registry can request specific values that have
yet to be assigned.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 31 Oct 2014 11:25:45 -0400 (EDT)

> The thread has calmed down a little bit, and I just wanted to add one more attempt to find a middle-ground to this thread: the initial message (below) included suggested text.  Later in the thread,…

The problem has not gone away though. It would help if you could state
publicly whether any of your suggestions might fall under planned or
actual IPR by Versign? If so, a statement with license conditions
compatible with the IETF process would be useful. Without any such
statements, I'm even feeling uncomfortable reading anything you wrote,
let alone accepting any contributions from members of your company.

So as it stands, I am against any of your suggestions, without having
read them.

Paul

---

From: Danny McPherson <[email-masked]>
Date: Fri, 31 Oct 2014 11:11:19 -0600

> let alone accepting any contributions from members of your company.

Rest assured Verisign is going to follow the IETF IPR disclosure 
procedures in the way that our experts in this area deem appropriate - 
we're well aware there are clear consequences of not doing so -- and 
there are a lot of folks here that are trying to do the right thing.

That said, you're welcome to follow those procedures yourself if 
something concerns you.

> So as it stands, I am against any of your suggestions, without having

Perhaps give them a read such you can have an informed position and 
useful contribution for this discussion?  :-)

Kind regards,

-danny

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 31 Oct 2014 17:28:40 +0000

On Fri, Oct 31, 2014 at 02:47:19PM +0000, Osterweil, Eric wrote:

>    4 or REJECT -- REJECT is used by the domain owner to assert that at
>    the time of querying the DNS, this user's certificate MUST be considered
>    invalid for the requested function (i.e. signature or encryption).
>    Possible usage scenarios include de-authorizing stale employee
>    credentials by selectively overriding TAs that are used to authorize
>    entire organizations.

Which certificate is being invalidated? Why is this needed?  What's
wrong with publishing a "3 1 1" association with an impossible key?

    $ openssl dgst -sha256 </dev/null
    (stdin)= e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

    ;; User's public key cannot be empty, so will never match this record.
    ;;
    1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.example.com.  IN SMIMEA ( DANE-EE SPKI SHA2-256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 )

>    2 or WF: X.509 certificates available in WebFinger [RFC7033].

Once this field is not "NO", what is the meaning of the associated
data field carried with such a record?  Is it still providing a
valid DANE association?

If so, when would one also need to use the "alternative access"?

If not, how is this a DANE SMIMEA record?  At the very least changing
the semantics of the associated data should lead to a new selector
or usage, but more likely an entirely separate DNSSEC validated
record, at which point the application can just query for these
alternative records if it sees fit.  Why does SMIMEA need to
explicitly signal the use of other mechanisms?

-- 
	Viktor.