Apologies for coming to this late and for this being so long. On Sep 30, 2014, at 16:53, Paul Hoffman <[email protected]> wrote:
> On Sep 29, 2014, at 5:26 AM, Osterweil, Eric <[email protected]> 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. > > --Paul Hoffman and Jakob Schlyter 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: On Oct 02, 2014, at 18:12, Paul Hoffman <[email protected]> wrote: > On Oct 2, 2014, at 1:56 PM, Doug Montgomery <[email protected]> wrote: > >> 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? 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: On Oct 02, 2014, at 18:12, Paul Hoffman <[email protected]> wrote: > On Oct 2, 2014, at 1:56 PM, Doug Montgomery <[email protected]> wrote: > >> 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. 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: On Oct 02, 2014, at 18:12, Paul Hoffman <[email protected]> wrote: >> 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. 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. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
