Subject: [wpkops] Silence is deafening - Trust Model Paper

From: Sharon Boeyen <[email-masked]>
Date: Mon, 24 Jun 2013 16:40:51 +0000

Has everyone lost interest in this work and this WG?

The silence is deafening!

We are going to miss our milestone of adoption of a first WG draft of the Trust Model paper if we don't get some more feedback immediately.

Please take a minute to send a brief email to the list indication whether or not you are in favour of adopting the current draft (with the promised updates) as the first WG draft of the Trust Model paper.

If we get no feedback in the next day or two we'll need to seriously question whether to continue the activity or not.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Jun 2013 15:56:16 -0700

The model in draft draft-webpki-trustmodel does not match the charter for this WG. It over-reaches by talking about "certificate-using clients" that are not web browsers.

Even if the document is more narrowly scoped to meet the charter, it still has many problems. It blithely assumes that all CAs follow their certificate policies (which we have seen is not true), and states that such certificate polices are "accepted" by client suppliers, which is only true if "accepted" means "without any real checking, and generally without any punishment after lapses are found".

The draft also says that "the relying party implicitly accepts" the root store without discussing what this implicit acceptance means. There is no discussion of what user expectations might be (such as surprise that governments can cause certificates issued for sites of enemy governments). 

The WG should consider instead requiring the draft apply to the real-world Web PKI where browsers makers do not hold CAs accountable when lapses are found and users do not understand anything about the role of the root store.

In other words, the WG should consider a much more realistic draft. Otherwise, a reader might think that the WG's eventual RFC describes something operationally useful.

--Paul Hoffman

---

From: Bruce Morton <[email-masked]>
Date: Tue, 25 Jun 2013 02:09:03 +0000

I just wanted to say that the approach to the Trust Model document was to show how the actions of the browser and the CA provide trust between the subscriber and the relying party. A basic model was shown and then some variants. The reason was to show the reality out there that may help people understand the realities and develop better policies. For instance, many people did not understand the issues of a CA issuing a CA certificate.  This was not discussed in browser policies and not referenced in WebTrust 1.0. However, when DigiNotar and Digicert Malaysia were blacklisted, this reality had to be accounted for.

Some general comments on this approach would be useful.

I have also provided some responses to Paul's comments below.

Thanks, Bruce.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Monday, June 24, 2013 6:56 PM
To: Sharon Boeyen
Cc: wpkops WG ([email-masked])
Subject: Re: [wpkops] Silence is deafening - Trust Model Paper

[Bruce Morton] Sorry if this is outside the charter. We might want to consider opening up the charter just a little bit as the relying parties might be using something other than a browser. This might be opening up more and more in the mobile world.

[Bruce Morton]  I think the CAs would concur that a CP and/or CPS is developed based on the requirements from the OS/browser developers. Most CAs have a policy authority to define policy. They may have internal auditors to ensure they are meeting policy and they are annually audited to show compliance to their policies. There are cases where a CA does not meet their policy. There are also cases where the policy is incorrect. In general all CAs endeavor to meet their policies and put corrective action in place where a mistake has been made.

[Bruce Morton] I agree that Relying Party is an issue which is why the word implicit is used. In reality, the Relying Party uses a browser and may respond to a trust dialogue if it appears.

[Bruce Morton] We have seen that OS/browsers do hold CAs accountable. In the past we have seen that DigiNotar and Digicert Malaysia CA certificates have been blacklisted. The browsers also take other actions is counteract the actions of the CAs. Microsoft has rejected all certificates with keys less than 1024-bit RSA. Chrome uses CRLsets rather than the full CRL issued by the CA. CA certificates with MD2/MD5 signatures have been untrusted. I also expect to see CAs with 1024-bit RSA keys to be untrusted in some browsers in the next year.

--Paul Hoffman

_______________________________________________

wpkops mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/wpkops

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Jun 2013 20:56:53 -0700

> [Bruce Morton] Sorry if this is outside the charter. We might want to consider opening up the charter just a little bit as the relying parties might be using something other than a browser. This mi…

Stopping our work and revisiting the charter discussion is certainly a possibility. It seems like a bad idea to me, but others might like it.

> [Bruce Morton]  I think the CAs would concur that a CP and/or CPS is developed based on the requirements from the OS/browser developers.

This WG is supposed to be documenting "how the Web PKI actually works in the set of browsers and servers that are in common use today", not on what CAs would concur about. Your document seems to be about the latter. Maybe we should stop work and recharter to change the focus of the WG to be what CAs would concur about; if the charter changes to that, I suspect a good percentage of the few people who wanted to participate in the WG would walk away; I certainly would.

> Most CAs have a policy authority to define policy. They may have internal auditors to ensure they are meeting policy and they are annually audited to show compliance to their policies. There are cases where a CA does not meet their policy. There are also cases where the policy is incorrect.

And what is the operational effect of the latter two? *That's* much more germane to "how the Web PKI actually works in the set of browsers and servers that are in common use today".

> In general all CAs endeavor to meet their policies and put corrective action in place where a mistake has been made.

How can that statement be measured? Is there a public repository of CA mistakes (not just those discovered by the public) and the corrective action that took place? If so, great; if not, such assurances have little do with ho the Web PKI actually works.

> [Bruce Morton] I agree that Relying Party is an issue which is why the word implicit is used. In reality, the Relying Party uses a browser and may respond to a trust dialogue if it appears.

None of the browsers that I am familiar with display a dialog that says "The certificate for the site you are visiting, www.cia.gov, is issued by a CA that is generally believed to be controlled by the government of <country sometimes unfriendly with the US>. Sound good to you?" The trust model allows such issuance; the "implicitly accepts" needs to deal with that, not with dialog boxes that a browser *could* show be never does in this reality.

> [Bruce Morton] We have seen that OS/browsers do hold CAs accountable.

It seems you forgot the word "sometimes" in there.

> In the past we have seen that DigiNotar and Digicert Malaysia CA certificates have been blacklisted.

...but not some CAs that were found to have defective oversight of subordinate CAs, for example.

> The browsers also take other actions is counteract the actions of the CAs. Microsoft has rejected all certificates with keys less than 1024-bit RSA.

That is not a lapse on Microsoft's part, it is an explicit policy.

> Chrome uses CRLsets rather than the full CRL issued by the CA.

That's unrelated to lapses, yes?

> CA certificates with MD2/MD5 signatures have been untrusted.

How on earth is that considered a "lapse"?

> I also expect to see CAs with 1024-bit RSA keys to be untrusted in some browsers in the next year.

Again: that's a policy, not a lapse.

In summary, it really doesn't feel like this draft meets the current charter. If folks want to have a recharter discussion, fine, but maybe it would be better to ask the editor to stick to the current charter.

--Paul Hoffman

---

From: Michael Jenkins <[email-masked]>
Date: Tue, 25 Jun 2013 12:34:47 -0400

To cut Bruce ein bißchen of slack :) he's writing about the trust model,
not an observation of all the wonderful and glorious ways PKI has failed.
Models don't necessarily reflect reality, so I don't think this paper needs
to document how elements have failed to meet the model /as part of the
model/. It just needs to extract from current operation where trust
relationships exist.

So I agree with Paul, mostly: the trust model paper should talk about
browsers explicitly and solely, and how they store and use certificates for
SSL specifically. It should describe the CA and its CP/CPS, how the auditor
is supposed to use it, how the browser-vendor/trust-store-manager is
supposed to use it. It should probably leave the browser-operator out of
the trust model, because the indications presented to the browser-operator
are disconnected from certificate processing. The paper should not go
halves, trying to put what's out there in the context of traditional
concepts of PKI.

Anticipating a comment, I use "is supposed to" rather than "should". Since
we're describing a model, that's appropriate. If you're going to "work to
improve the consistency of web security behavior", then you've got to have
a target. Substitute "could effectively" if you prefer.

I also think the paper could describe the ways the model doesn't support
security or inspire trust. Browser-vendors do vet CAs for entry into
trust-stores, and do react to catastrophic failures, but don't have an
on-going role in CA accountability. Auditors do inspect CA operations, but
serve a guidance role, are in the employ of the CA itself, and the audit
report is private. These things are inherent to the model, and are
problems.

The gaps created by PKI elements not supporting or actually subverting
trust by violating the model don't really belong in the paper unless the
paper increases in scope. I think those issues would still fit within the
charter, but go beyond describing a model.

On Mon, Jun 24, 2013 at 11:56 PM, Paul Hoffman <[email-masked]>wrote:

> > The model in draft draft-webpki-trustmodel does not match the charter
> for this WG. It over-reaches by talking about "certificate-using clients"
> that are not web browsers.
> > [Bruce Morton] Sorry if this is outside the charter. We might want to
> consider opening up the charter just a little bit as the relying parties
> might be using something other than a browser. This might be opening up
> more and more in the mobile world.
>
> Stopping our work and revisiting the charter discussion is certainly a
> possibility. It seems like a bad idea to me, but others might like it.
>
> > Even if the document is more narrowly scoped to meet the charter, it
> still has many problems. It blithely assumes that all CAs follow their
> certificate policies (which we have seen is not true), and states that such
> certificate polices are "accepted" by client suppliers, which is only true
> if "accepted" means "without any real checking, and generally without any
> punishment after lapses are found".
> > [Bruce Morton]  I think the CAs would concur that a CP and/or CPS is
> developed based on the requirements from the OS/browser developers.
>
> This WG is supposed to be documenting "how the Web PKI actually works in
> the set of browsers and servers that are in common use today", not on what
> CAs would concur about. Your document seems to be about the latter. Maybe
> we should stop work and recharter to change the focus of the WG to be what
> CAs would concur about; if the charter changes to that, I suspect a good
> percentage of the few people who wanted to participate in the WG would walk
> away; I certainly would.
>
> > Most CAs have a policy authority to define policy. They may have
> internal auditors to ensure they are meeting policy and they are annually
> audited to show compliance to their policies. There are cases where a CA
> does not meet their policy. There are also cases where the policy is
> incorrect.
>
> And what is the operational effect of the latter two? *That's* much more
> germane to "how the Web PKI actually works in the set of browsers and
> servers that are in common use today".
>
> > In general all CAs endeavor to meet their policies and put corrective
> action in place where a mistake has been made.
>
> How can that statement be measured? Is there a public repository of CA
> mistakes (not just those discovered by the public) and the corrective
> action that took place? If so, great; if not, such assurances have little
> do with ho the Web PKI actually works.
>
> >  The draft also says that "the relying party implicitly accepts" the
> root store without discussing what this implicit acceptance means. There is
> no discussion of what user expectations might be (such as surprise that
> governments can cause certificates issued for sites of enemy governments).
> > [Bruce Morton] I agree that Relying Party is an issue which is why the
> word implicit is used. In reality, the Relying Party uses a browser and may
> respond to a trust dialogue if it appears.
>
> None of the browsers that I am familiar with display a dialog that says
> "The certificate for the site you are visiting, www.cia.gov, is issued by
> a CA that is generally believed to be controlled by the government of
> <country sometimes unfriendly with the US>. Sound good to you?" The trust
> model allows such issuance; the "implicitly accepts" needs to deal with
> that, not with dialog boxes that a browser *could* show be never does in
> this reality.
>
> > The WG should consider instead requiring the draft apply to the
> real-world Web PKI where browsers makers do not hold CAs accountable when
> lapses are found and users do not understand anything about the role of the
> root store.
> > The browsers also take other actions is counteract the actions of the
> CAs. Microsoft has rejected all certificates with keys less than 1024-bit
> RSA.
>
> In summary, it really doesn't feel like this draft meets the current
> charter. If folks want to have a recharter discussion, fine, but maybe it
> would be better to ask the editor to stick to the current charter.
>
> --Paul Hoffman
>
> [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Jun 2013 10:06:38 -0700

On Jun 25, 2013, at 9:34 AM, Michael Jenkins <[email-masked]> wrote:

> I also think the paper could describe the ways the model doesn't support security or inspire trust. Browser-vendors do vet CAs for entry into trust-stores, and do react to catastrophic failures, but don't have an on-going role in CA accountability. Auditors do inspect CA operations, but serve a guidance role, are in the employ of the CA itself, and the audit report is private. These things are inherent to the model, and are problems. 

Adding these would go a long way towards making the document meet the requirements. A "model" section followed by a "operational reality" section seems reasonable. I was probably unclear in my earlier messages on this thread, making it seem like I wanted to mix the two.

> The gaps created by PKI elements not supporting or actually subverting trust by violating the model don't really belong in the paper unless the paper increases in scope. I think those issues would still fit within the charter, but go beyond describing a model.

My hope is that the document increases in scope to match the top part of the charter. Knowing only the model doesn't help an operator; talking about the model and the operational realities does.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Jun 2013 13:24:00 -0400

Michael,

I agree with Paul's observations. The charter for the WG is 
intentionally narrow.
If folks decide to revise it to be broader, there is no guarantee that a 
new, broader
charter will be approved. With that in mind, the trust model doc needs a 
LOT of work.
Phrases like "is supposed to" may be appropriate, but they ought not 
figure prominently,
as the goal here is to document how browsers and the public TA/CA really 
work.

Steve

---

From: joel jaeggli <[email-masked]>
Date: Tue, 25 Jun 2013 10:35:45 -0700

I came on as AD right after this WG was chartered effectively.

If we seriously consider rechartering at this point we're basically 
declaring the original a failure, which is fine I guess, but I think the 
IESG is going to turn a pretty jaundiced eye on that.

If something truly does not fit under our charter it might well advance 
as individual submission (I'd have to consider that), socialize it 
through and bring it up through opsawg or other alternatives. imho it's 
premature to really explore this.

On 6/25/13 10:24 AM, Stephen Kent wrote:
> If folks decide to revise it to be broader, there is no guarantee that 
> a new, broader
> charter will be approved. With that in mind, the trust model doc needs 
> a LOT of work.
> as the goal here is to document how browsers and the public TA/CA 
> really work.
>
> Steve
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 26 Jun 2013 05:22:34 +0000

There is some weirdness in the charter, in that on the one had it is about documenting real-world behavior ('The working group's goal is to describe how the Web PKI "actually" works in the set of browsers and servers that are in common use today.'), and on the other hand the charter explicitly calls for documenting trust models.

I took this to mean that each participant in the web PKI (CA, server administrator, server developer, browser developer, and browser user) has a mental model of how the whole thing works, and that model guides their actions. For example, the browser user might believe that CAs are supposed to (and unlike Steve, I believe that is a good phrase to use here) verify domain names before issuing certificates. So if a server presents a certificate that says "C=US,ST=WA,L=Redmond,O=Microsoft Corporation,OU=MSCOM,CN=www.microsoft.com", that means that this server is really controlled by Microsoft. This guides their actions, in that when they want to reach Microsoft's website, they'll type "https://www.microsoft.com" and if the padlock appears, they can trust that this is actually Microsoft.

People more versed in protocols will have a more complex model in mind, one that involves the DNS (which pointed the browser at the server), the whois database, registrars, CAs, and email verification. But everyone has some idea in their head about what this WebPKI means, and this informs their actions. It's a real-world mental model and some real-world actions. I think it's well worth it to document this model (although I'm not sure where we could reliably get this information - we're not distributing questionnaires and conducting in-depth interviews with end-users, right?). I also think that the current charter covers this.

Yoav

On Jun 25, 2013, at 8:35 PM, joel jaeggli <[email-masked]> wrote:

> If we seriously consider rechartering at this point we're basically declaring the original a failure, which is fine I guess, but I think the IESG is going to turn a pretty jaundiced eye on that.
> 
> If something truly does not fit under our charter it might well advance as individual submission (I'd have to consider that), socialize it through and bring it up through opsawg or other alternatives. imho it's premature to really explore this.
> 
>> I agree with Paul's observations. The charter for the WG is intentionally narrow.
>> If folks decide to revise it to be broader, there is no guarantee that a new, broader
>> charter will be approved. With that in mind, the trust model doc needs a LOT of work.
>> Phrases like "is supposed to" may be appropriate, but they ought not figure prominently,
>> as the goal here is to document how browsers and the public TA/CA really work.
>> 
>> Steve

---

From: [email-masked]
Date: Wed, 26 Jun 2013 12:34:36 +0200

Hi all,

A new draft has been posted for you to check. It includes some new definitions regarding browsers and CAs policies, and some other contributions.

Regarding what Michael and Paul are saying, I´m disagree. The trust models in the web PKI are not only browsers and are not only related to SSL certificates, this is a widely assumption that it´s not true at all.

For example, in the EU there´s a so called Trust Service Status List (commonly called TSL) which is another trust store managed by every EU member state and regulated by law in which there´s a list with all CAs (and issuing CAs and services) that fulfill the requirements imposed by law that follow some ETSI standards. This is mandate for all the CAs offering qualified certificates but it´s also possible for non qualified certs, like SSL. This is also web PKI because these services are consumed thru web services for example on a machine readable process or thru a web site for human readable process.

There are browsers like Microsoft and other RP like Adobe that are thinking on using these TSLs to adapt their root stores and not doing that job, they will rely on what the EU has implemented and managed by law.

Other example could be all the services that can be used with a qualified certificate issued in a SSCD (smartcard or USB token, we can leave HSM apart) in a web client.

So, in my opinion, the web PKI is more than browsers (and their policies) and SSL certificates. CAs are actually (and this is what this is about, to explain what is out there today) a key factor in this because they feed up the browsers with their certs. The browsers have their policies to indicate what they request the CAs to be admitted (mainly to be audited with some standards, ETSI or Webtrust) and the CAs have their own policies to indicate how they produce those certs and according to the same standards that are going to be used to be audited and presented to the browsers. So I think that in this trust model document, the trust is between the CAs and the browsers, not just the browsers imposing something to the CAs. And both have to be presented.

OTOH I´m agree that a rewording to meet these suggestions shall be included and as I see these are focused on auditing (which is already included), vetting, security measures, etc. but are these necessary to explain in depth? After this first draft on trust model some other are coming to meet also these ones.

regards

Iñigo Barreira
Responsable del Área técnica
[email-masked]

945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

De: [email-masked] [mailto:[email-masked]] En nombre de Michael Jenkins
Enviado el: martes, 25 de junio de 2013 18:35
Para: wpkops WG ([email-masked])
Asunto: Re: [wpkops] Silence is deafening - Trust Model Paper

To cut Bruce ein bißchen of slack :) he's writing about the trust model, not an observation of all the wonderful and glorious ways PKI has failed. Models don't necessarily reflect reality, so I don't think this paper needs to document how elements have failed to meet the model /as part of the model/. It just needs to extract from current operation where trust relationships exist.

So I agree with Paul, mostly: the trust model paper should talk about browsers explicitly and solely, and how they store and use certificates for SSL specifically. It should describe the CA and its CP/CPS, how the auditor is supposed to use it, how the browser-vendor/trust-store-manager is supposed to use it. It should probably leave the browser-operator out of the trust model, because the indications presented to the browser-operator are disconnected from certificate processing. The paper should not go halves, trying to put what's out there in the context of traditional concepts of PKI.

Anticipating a comment, I use "is supposed to" rather than "should". Since we're describing a model, that's appropriate. If you're going to "work to improve the consistency of web security behavior", then you've got to have a target. Substitute "could effectively" if you prefer.

On Mon, Jun 24, 2013 at 11:56 PM, Paul Hoffman <[email-masked]> wrote:

--Paul Hoffman

---

From: [email-masked]
Date: Wed, 26 Jun 2013 12:43:09 +0200

Agreed.

Recently, in the last CAB Forum F2F meeting, an issue arised regarding some certificates that didn´t meet the criteria but claimed to be non-web PKI so not affecting the browsers. The problem came then on how to define/distinguish web PKI and non-web PKI and there´s nothing out there. All of us understand what a webPKI could mean more or less but this chapter is a good opportunity to define. If we are talking about the same topics that are covered in the CAB Forum, well, it´s better to stop now that working for nothing. 

Besides, ETSI has a set of documents (standards) that also "work" in this direction. There are documents which defines policies for CAS issuing different types of certificates, profiles for these type of certificates, guidance to CAs and auditors on how to implement and audit these policies, checklists, governance document on browser behaviours, TSL implementations, definitions, etc.

Regards

Iñigo Barreira

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Yoav Nir
Enviado el: miércoles, 26 de junio de 2013 7:23
Para: joel jaeggli
CC: wpkops WG
Asunto: Re: [wpkops] Silence is deafening - Trust Model Paper

Yoav

On Jun 25, 2013, at 8:35 PM, joel jaeggli <[email-masked]> wrote:

>> If folks decide to revise it to be broader, there is no guarantee 
>> that a new, broader charter will be approved. With that in mind, the trust model doc needs a LOT of work.
>> figure prominently, as the goal here is to document how browsers and the public TA/CA really work.
>> 
>> Steve

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Jun 2013 11:51:04 +0100

Hi,

On 06/26/2013 11:34 AM, [email-masked] wrote:
> For example, in the EU there´s a so called Trust Service Status List
> (commonly called TSL) which is another trust store managed by every
> EU member state and regulated by law in which there´s a list with all
> CAs (and issuing CAs and services) that fulfill the requirements
> imposed by law that follow some ETSI standards. This is mandate for
> all the CAs offering qualified certificates but it´s also possible
> for non qualified certs, like SSL. This is also web PKI because these
> services are consumed thru web services for example on a machine
> readable process or thru a web site for human readable process.

How does that square with the charter requirement that this wg
not delve into stuff that's not much used?

The charter says:

  Only server-authentication behavior encountered in more than 0.1
  percent of connections made by desktop and mobile browsers is to
  be considered.  While it is not intended to apply the threshold
  with any precision, it will be used to justify the inclusion or
  exclusion of a technique.

Is there any evidence as to the level of use of all that ETSI
stuff? My impression is that it'd not meet the rough threshold
above.

BTW: I'd really like to know, I'm not (only) trying to simplify
the work here:-) But simplifying the work here seems like
something that is needed for progress given the relative lack
of activity.

Thanks,
S.

---

From: Sharon Boeyen <[email-masked]>
Date: Wed, 26 Jun 2013 13:04:26 +0000

I also came on as WG co-chair after the group was chartered. I do not believe that even considering any attempt to  expand the charter at this point is a good idea. The documents need to fit within the charter as it is currently stated. If additional work is desirable that can be noted and put on the back burner for the future (whether that be as part of an eventual re-chartering of this group or done in a different WG). 

At the March meeting it was evident to me that this WG has a huge amount of work on its plate already. Since that meeting the group has been quite inactive - not a good combination! We finally have some good discussion going on that I hope will lead us to the point where we get a solid trust model draft that fits within the charter scope (describes current situation and is restricted to web pki) that will form the basis for future work. 

Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of joel jaeggli
Sent: Tuesday, June 25, 2013 1:36 PM
To: Stephen Kent; wpkops WG
Subject: Re: [wpkops] Silence is deafening - Trust Model Paper

On 6/25/13 10:24 AM, Stephen Kent wrote:
> a new, broader charter will be approved. With that in mind, the trust 
> model doc needs a LOT of work.

---

From: David Chadwick <[email-masked]>
Date: Wed, 26 Jun 2013 16:21:40 +0100

I agree with everything Paul says, and in addition, I would add that you
need to separate the human user (who is actually the RP and who will 
suffer any loss) from the certificate using client, which is not the RP 
but is only the software acting on behalf of the RP, and which is 
implicitly trusted by the RP (and this trust is often misplaced)

regards

David

On 24/06/2013 23:56, Paul Hoffman wrote:
> for this WG. It over-reaches by talking about "certificate-using
> clients" that are not web browsers.
>
> still has many problems. It blithely assumes that all CAs follow
> their certificate policies (which we have seen is not true), and
> states that such certificate polices are "accepted" by client
> suppliers, which is only true if "accepted" means "without any real
> checking, and generally without any punishment after lapses are
> found".
>
> root store without discussing what this implicit acceptance means.
> There is no discussion of what user expectations might be (such as
> surprise that governments can cause certificates issued for sites of
> enemy governments).
>
> real-world Web PKI where browsers makers do not hold CAs accountable
> when lapses are found and users do not understand anything about the
> role of the root store.
>
> In other words, the WG should consider a much more realistic draft.
> Otherwise, a reader might think that the WG's eventual RFC describes
> something operationally useful.
>
> --Paul Hoffman _______________________________________________ wpkops
> mailing list [email-masked]

---

From: [email-masked]
Date: Thu, 27 Jun 2013 09:04:15 +0200

Hi,

I don´t know the numbers because I´m not managing it, this is typically done at the ministers in the national governments which are the responsible for managing the TSL, but in any case, I sent an email asking for these numbers, which in any case it´s only for one country.

OTOH, I think this is not about percentages (or at least I don´t see that way) since these TSL are mandated by law. But, if numbers are needed, there are 27 (EU member states) reliable trust stores that must be considered, not just 5 (browsers) and you can add Adobe and Oracle (also have root stores).

IMHO, this document has to take into account all options because if we are only dealing with browsers then I think the CAB forum is doing it now and it will be a useless or repeated (similar) work.

Here´s a link on recent news of Adobe if it´s of interest.
http://blogs.adobe.com/standards/2013/06/25/alignment-of-adobe-approved-trust-list-aatl-and-eu-trust-list-eutl/

Regards

Iñigo Barreira

-----Mensaje original-----
De: Stephen Farrell [mailto:[email-masked]] 
Enviado el: miércoles, 26 de junio de 2013 12:51
Para: Barreira Iglesias, Iñigo
CC: [email-masked]; [email-masked]
Asunto: Re: [wpkops] Silence is deafening - Trust Model Paper

Hi,

On 06/26/2013 11:34 AM, [email-masked] wrote:
> (commonly called TSL) which is another trust store managed by every EU 
> member state and regulated by law in which there´s a list with all CAs 
> (and issuing CAs and services) that fulfill the requirements imposed 
> by law that follow some ETSI standards. This is mandate for all the 
> CAs offering qualified certificates but it´s also possible for non 
> qualified certs, like SSL. This is also web PKI because these services 
> are consumed thru web services for example on a machine readable 
> process or thru a web site for human readable process.

How does that square with the charter requirement that this wg not delve into stuff that's not much used?

The charter says:

Is there any evidence as to the level of use of all that ETSI stuff? My impression is that it'd not meet the rough threshold above.

BTW: I'd really like to know, I'm not (only) trying to simplify the work here:-) But simplifying the work here seems like something that is needed for progress given the relative lack of activity.

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Jun 2013 10:09:56 +0100

Hiya,

On 06/27/2013 08:04 AM, [email-masked] wrote:
> Hi,
> 
> I don´t know the numbers because I´m not managing it, this is
> typically done at the ministers in the national governments which are
> the responsible for managing the TSL, 

Those would be the wrong numbers I think.

The numbers of interest relate to real-world usage in
TLS sessions. I'd be very surprised if any of the ETSI
stuff showed up in anything near 0.1% of TLS sessions.

If it does not then this WG should just ignore it and
concentrate on the 99.9% of stuff that actually happens.

Is anyone claiming that the ETSI stuff shows up in >0.1%
of TLS sessions?

> but in any case, I sent an
> email asking for these numbers, which in any case it´s only for one
> country.
> 
> OTOH, I think this is not about percentages (or at least I don´t see
> that way) since these TSL are mandated by law. 

So what? There are loads of digital signature related laws in
the world. They are all irrelevant for this wg unless they
impact on what is actually used to a non-negligible extent in
the real web pki.

> But, if numbers are
> needed, there are 27 (EU member states) reliable trust stores that
> must be considered, not just 5 (browsers) and you can add Adobe and
> Oracle (also have root stores).

Wrong numbers again. This has nothing to do with how many
implementations exist but rather with what is really commonly
used.

> IMHO, this document has to take into account all options because if
> we are only dealing with browsers then I think the CAB forum is doing
> it now and it will be a useless or repeated (similar) work.

That ("take into account all the options") sounds like a recipe
for failure to me given the lack of activity here and the history
that the PKI community has of spending way too much time on niche
corner cases and ignoring what's actually commonly done. (Sorry
that's a bit of a rant and I'm as guilty as anyone, or was in
the past - I'm reformed now:-)

S.

> Iñigo Barreira Responsable del Área técnica [email-masked] 
> 945067705
> 
> 
> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
> egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada
> (helbidea gaizki idatzi, transmisioak huts egin) eman abisu
> igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje
> contiene informacion privilegiada o confidencial a la que solo tiene
> derecho a acceder el destinatario. Si usted lo recibe por error le
> agradeceriamos que no hiciera uso de la informacion y que se pusiese
> en contacto con el remitente.
> 
> 
> -----Mensaje original----- De: Stephen Farrell
> [mailto:[email-masked]] Enviado el: miércoles, 26 de junio
> de 2013 12:51 Para: Barreira Iglesias, Iñigo CC: [email-masked];
> [email-masked] Asunto: Re: [wpkops] Silence is deafening - Trust
> Model Paper
> 
> 
> Hi,
> 
>> For example, in the EU there´s a so called Trust Service Status
>> List (commonly called TSL) which is another trust store managed by
>> every EU member state and regulated by law in which there´s a list
>> with all CAs (and issuing CAs and services) that fulfill the
>> requirements imposed by law that follow some ETSI standards. This
>> is mandate for all the CAs offering qualified certificates but it´s
>> also possible for non qualified certs, like SSL. This is also web
>> PKI because these services are consumed thru web services for
>> example on a machine readable process or thru a web site for human
>> readable process.
> 
> percent of connections made by desktop and mobile browsers is to be
> considered.  While it is not intended to apply the threshold with any
> precision, it will be used to justify the inclusion or exclusion of a
> technique.
> 
> Is there any evidence as to the level of use of all that ETSI stuff?
> My impression is that it'd not meet the rough threshold above.
> 
> BTW: I'd really like to know, I'm not (only) trying to simplify the
> work here:-) But simplifying the work here seems like something that
> is needed for progress given the relative lack of activity.
> 
> Thanks, S.
> 
>

---

From: [email-masked]
Date: Thu, 27 Jun 2013 14:27:29 +0200

Hi

Then we´re assuming that web PKI means only TLS connections, am I right? So "web" is used only in "browsers"? I think this is not fair. We are talking about trust models and browsers root stores is only "one" of these models, not the only one and we should consider the others. 

I don´t get why we are assuming that web PKI is only referred to the browsers, and if so, the document could be very simple, just pointing to the browsers policies or leave it to the CAB Forum, which is not a standards body like it can be IETF. 

If we´re to produce a standard on trust models we should consider all options, not just one because it´s the most used. That is not an standard.

Regards

Hiya,

The numbers of interest relate to real-world usage in TLS sessions. I'd be very surprised if any of the ETSI stuff showed up in anything near 0.1% of TLS sessions.

If it does not then this WG should just ignore it and concentrate on the 99.9% of stuff that actually happens.

Is anyone claiming that the ETSI stuff shows up in >0.1% of TLS sessions?

> that way) since these TSL are mandated by law.

So what? There are loads of digital signature related laws in the world. They are all irrelevant for this wg unless they impact on what is actually used to a non-negligible extent in the real web pki.

> Oracle (also have root stores).

Wrong numbers again. This has nothing to do with how many implementations exist but rather with what is really commonly used.

> IMHO, this document has to take into account all options because if we 

> are only dealing with browsers then I think the CAB forum is doing it 

> now and it will be a useless or repeated (similar) work.

That ("take into account all the options") sounds like a recipe for failure to me given the lack of activity here and the history that the PKI community has of spending way too much time on niche corner cases and ignoring what's actually commonly done. (Sorry that's a bit of a rant and I'm as guilty as anyone, or was in the past - I'm reformed now:-)

S.

> http://blogs.adobe.com/standards/2013/06/25/alignment-of-adobe-approve <http://blogs.adobe.com/standards/2013/06/25/alignment-of-adobe-approve> 

> d-trust-list-aatl-and-eu-trust-list-eutl/

> Iñigo Barreira Responsable del Área técnica [email-masked] <mailto:[email-masked]> 

> (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, 

> korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene 

> informacion privilegiada o confidencial a la que solo tiene derecho a 

> acceder el destinatario. Si usted lo recibe por error le 

> [mailto:[email-masked]] <mailto:[mailto:[email-masked]]>  Enviado el: miércoles, 26 de junio 

> de 2013 12:51 Para: Barreira Iglesias, Iñigo CC: [email-masked] <mailto:[email-masked]> ; 

> [email-masked] <mailto:[email-masked]>  Asunto: Re: [wpkops] Silence is deafening - Trust 

> On 06/26/2013 11:34 AM, [email-masked] <mailto:[email-masked]>  wrote:

> How does that square with the charter requirement that this wg not 

> delve into stuff that's not much used?

---

From: [email-masked]
Date: Thu, 27 Jun 2013 14:31:32 +0200

About the use of the EU TL, some other points to talk about

1. New proposal for e-procurement Directive (COM(2011) 896 final), of 20 December 2011 E-procurement related provisions: Article 19, Annex IV. Obligatory recognition of tenders accompanied by a qualified electronic certificate included in the "Trusted List", if CA asks for any advanced e-signature.

2. Revision of Professional Qualifications Directive (2005/36/EC), COM(2011) 883 final, 19.12.2011. New Article 57 for PSCs and 57a for e-procedures, where

reference made to Decision 2009/767/EC and 2011/130/EU (for cases where advanced e-signatures required).

Iñigo Barreira

945067705

De: [email-masked] [mailto:[email-masked]] En nombre de [email-masked]
Enviado el: jueves, 27 de junio de 2013 14:27
Para: [email-masked]
CC: [email-masked]; [email-masked]
Asunto: Re: [wpkops] Silence is deafening - Trust Model Paper

Hi

Regards

Hiya,

S.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 27 Jun 2013 13:53:20 +0100

On 27/06/13 13:27, [email-masked] wrote:
> Hi
>
> Then we´re assuming that web PKI means only TLS connections, am I right?

I think we're assuming HTTPS specifically, rather than all TLS 
connections.  "Web" implies HTTP.

> So “web” is used only in “browsers”?

Yes.

http://en.wikipedia.org/wiki/World_Wide_Web says:
"Not to be confused with the Internet.
The World Wide Web (abbreviated as WWW or W3, commonly known as the 
web), is a system of interlinked hypertext documents accessed via the 
Internet. With a web browser, one can view web pages that may contain 
text, images, videos, and other multimedia, and navigate between them 
via hyperlinks."

http://en.wikipedia.org/wiki/Web_browser says:
"A web browser (commonly referred to as a browser) is a software 
application for retrieving, presenting and traversing information 
resources on the World Wide Web."

IMHO, any client that accesses resources on the Web is by definition a 
Browser.

> I think this is not fair. We are
> talking about trust models and browsers root stores is only “one” of
> these models, not the only one and we should consider the others.
>
> I don´t get why we are assuming that web PKI is only referred to the
> browsers,

See above.

> and if so, the document could be very simple, just pointing to
> the browsers policies or leave it to the CAB Forum, which is not a
> standards body like it can be IETF.
>
> If we´re to produce a standard on trust models we should consider all
> options, not just one because it´s the most used. That is not an standard.

All options within the "web PKI"?  Yes.

All options outside the "web PKI"?  No.

> The numbers of interest relate to real-world usage in TLS sessions. I'd
> be very surprised if any of the ETSI stuff showed up in anything near
> 0.1% of TLS sessions.
>
> So what? There are loads of digital signature related laws in the world.
> They are all irrelevant for this wg unless they impact on what is
> actually used to a non-negligible extent in the real web pki.
>
>  > But, if numbers are
>
> implementations exist but rather with what is really commonly used.
>
> That ("take into account all the options") sounds like a recipe for
> failure to me given the lack of activity here and the history that the
> PKI community has of spending way too much time on niche corner cases
> and ignoring what's actually commonly done. (Sorry that's a bit of a
> rant and I'm as guilty as anyone, or was in the past - I'm reformed now:-)
>
> S.
>
>  >
>
>  > http://blogs.adobe.com/standards/2013/06/25/alignment-of-adobe-approve
>
> <mailto:[email-masked]>
>
>  > 945067705
>
>  >
>
>  >
>
>  > [mailto:[email-masked]]
> <mailto:[mailto:[email-masked]]> Enviado el: miércoles, 26 de
> junio
>
>  > de 2013 12:51 Para: Barreira Iglesias, Iñigo CC: [email-masked]
> <mailto:[email-masked]>;
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Jun 2013 14:00:14 +0100

> All options within the "web PKI"?  Yes.

Modulo the charter's 0.1% threshold thingy, right?

If folks here start delving into smartcard based this
or that for client auth for example, then this'll fail.

S.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 27 Jun 2013 13:04:53 +0000

On Jun 27, 2013, at 3:53 PM, Rob Stradling <[email-masked]> wrote:

> I think we're assuming HTTPS specifically, rather than all TLS connections.  "Web" implies HTTP.
> 
> The World Wide Web (abbreviated as WWW or W3, commonly known as the web), is a system of interlinked hypertext documents accessed via the Internet. With a web browser, one can view web pages that may contain text, images, videos, and other multimedia, and navigate between them via hyperlinks."
> 
> "A web browser (commonly referred to as a browser) is a software application for retrieving, presenting and traversing information resources on the World Wide Web."
> 
> IMHO, any client that accesses resources on the Web is by definition a Browser.

I disagree. The world wide web is called that because of the hyperlinks. So my OS downloading an updated using HTTP is not part of the web. Also cURL is not "the web", although it's similar enough that in terms of PKI that I'm not sure we need the distinction. To be "on the web" you need to be able to click hyperlinks. So lynx qualifies but web services do not.

Yoav

---

From: Rob Stradling <[email-masked]>
Date: Thu, 27 Jun 2013 14:15:54 +0100

> Modulo the charter's 0.1% threshold thingy, right?

Sure.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 27 Jun 2013 14:30:42 +0100

> I disagree. The world wide web is called that because of the hyperlinks. So my OS downloading an updated using HTTP is not part of the web. Also cURL is not "the web", although it's similar enough…

Sure.  (Sorry, "accesses resources" was imprecise).

Just "retrieving" doesn't make an application a Browser.  A Browser 
needs to do "retrieving, presenting and traversing".

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 Jun 2013 10:35:30 -0400

Please re-read the charter. The scope of the WG is narrower than you 
seem to wish.
If this is going to be a persistent problem, then maybe you ought not be 
a co-author for
this document.

Steve
------
On 6/27/13 8:27 AM, [email-masked] wrote:
>
> Hi
>
> Then we´re assuming that web PKI means only TLS connections, am I 
> right? So "web" is used only in "browsers"? I think this is not fair. 
> We are talking about trust models and browsers root stores is only 
> "one" of these models, not the only one and we should consider the 
> others.
>
> browsers, and if so, the document could be very simple, just pointing 
> to the browsers policies or leave it to the CAB Forum, which is not a

---

From: [email-masked]
Date: Fri, 28 Jun 2013 11:13:30 +0200

Ok, I´m fine, no problem if this is only for SSL certs. But maybe sometime in the near future there´s a need to deal with a complete trust model in the web.

Iñigo Barreira

945067705

De: Stephen Kent [mailto:[email-masked]] 
Enviado el: jueves, 27 de junio de 2013 16:36
Para: Barreira Iglesias, Iñigo
CC: [email-masked]
Asunto: Re: [wpkops] Silence is deafening - Trust Model Paper

Please re-read the charter. The scope of the WG is narrower than you seem to wish.
If this is going to be a persistent problem, then maybe you ought not be a co-author for 
this document.

Steve
------

	Hi

	Regards

	Hiya,

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Jun 2013 08:20:18 -0700

On Jun 28, 2013, at 2:13 AM, [email-masked] wrote:

> Ok, I´m fine, no problem if this is only for SSL certs.

Just to be clear: it's not just "SSL certs", it is SSL/TLS certs for the web. The charter for this WG can be found at <https://datatracker.ietf.org/wg/wpkops/charter/>

> But maybe sometime in the near future there´s a need to deal with a complete trust model in the web.

Let's see if we can even deal with this limited one first.

--Paul Hoffman

---

From: Jon Callas <[email-masked]>
Date: Fri, 28 Jun 2013 17:08:49 -0700

> Let's see if we can even deal with this limited one first.

I almost think that what I'm going to say goes without saying. However, many things that go without saying ought to be said once or twice anyway.

I'm willing to buy into this if my software that does (e.g.) REST services over SSL are "Web" and my client is a "Browser" even if it's not going to render HTML, but (e.g.) parse some JSON. When I do that, I'm buying into the Web PKI, even though I'm not doing WWW in the way that a True Browser like Chrome/IE/Firefox/Safari might.

	Jon

---

From: Yoav Nir <[email-masked]>
Date: Sat, 29 Jun 2013 07:48:57 +0000

> I'm willing to buy into this if my software that does (e.g.) REST services over SSL are "Web" and my client is a "Browser" even if it's not going to render HTML, but (e.g.) parse some JSON. When I…

I don't think this goes without saying. Your client is not a browser, so it's not part of the charter. It may, however, be along for the ride.

Some of web services use their own single-purpose CA, and even if they use a public CA, some of the clients have hard-coded in them the chain they expect to see. This is not like the Web PKI, where you have many root CAs, all of which are equally trusted to sign certificates for any server on the web. If your client is like that, then it's more secure than the web PKI, but it's not part of the web PKI. If, OTOH, your client trusts the server based on the operating system's list of trusted CAs, this makes your client closer to the Web PKI.

But even if your client trusts the big list, and does a DNS lookup, there are still a whole bunch of vulnerabilities that do not apply to it. It's probably impossible to downgrade it to HTTP. It's impossible to confuse it with look-alike domain names. It's impossible to get it to follow a link into an insecure site. So I think the security properties of your web service are different from those of the web, although some of what could be discussed here might apply.

Yoav