Subject: [wpkops] First draft charter proposal

From: Tim Moses <[email-masked]>
Date: Wed, 22 Aug 2012 12:44:53 +0000

Colleagues - Here is a first draft of a charter proposal.  Please give it some thought and share the results of your deliberations.  Thanks a lot.  All the best.  Tim.

The Web PKI is the set of systems and procedures most commonly used to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers.  It first appeared in 1993 or thereabouts and has developed continuously in a somewhat organic fashion since then.  Across all the suppliers and the point releases of their products, there are now hundreds of variations on the Web PKI in regular use.  And this can be a source of problems both for end-users and certificate issuers.

For end-users, there is no clear view whether certificate "problems" remain when they see indication of a "good" connection.  For instance, in some browsers, a "good" indication may be displayed when a "revoked" response has been received and "accepted" by the user.  Whereas, other browsers may refuse to display the contents under these circumstances.

And for issuers, it can be difficult to predict what proportion of the user population will accept a certificate chain with certain characteristics.  For instance, when a browser includes a nonce in an OCSP request but the server supplies a response that does not include the nonce, it is hard to know which browsers will accept and which will reject the response.

Starting from the premise that more consistency in Web security behavior is desirable, a natural first step would be to document current and historic browser and server behavior.

Future activities may attempt to prescribe how the Web PKI "should" work, and the prescription may turn out to be a proper subset of the PKIX PKI.  However, that task is explicitly not a goal of the proposed working group.  Instead, the group's goal is merely to describe how the Web PKI "actually" works in the set of browsers and servers that are in common use today.

Additionally, a number of applications (other than the Web) may use the same trust anchors as the ones used by the Web.  These applications include: document signing; code signing; and email.  They may use PKI in a way that differs from the way in which the Web uses it.  Therefore, these applications are explicitly out of scope for the working group.

Also, the reliability of the Web PKI depends critically on the practices of its certificate issuers.  However, the topic of practices is outside the scope of the IETF.  Therefore, this will be left to other competent bodies.

That there are technical shortcomings with Web PKI, as it is practiced today, is well recognized.  And, that there is also some urgency in addressing these shortcomings is also well recognized.  But, it is felt that too much haste can be counter-productive.  The expectation is that the work of this group will bring to light, in a systematic way, aspects of the Web PKI that should be progressed in future working groups of the IETF's Security Area, and that suppliers will be willing to participate in those working groups and modify their products to comply with their standards.

Given the urgency of the required developments and the scale of the task, it is agreed that adherence to the published schedule should take precedence over completeness of the results.  The working group should focus its initial attention on the browser and server versions that make up the largest part of the desktop and mobile Web today.

The output documents will all be BCP-style RFCs.

1.    Agree the working group charter (1 month).

2.    Catalog the products and versions to be analyzed (1 month).

3.    First WG draft of "trust model" document (4 months).

4.    First WG draft of "public-key submission and certificate installation" document (4 months).

5.    First WG draft of "certificate, CRL, and OCSP profile" document (8 months).

6.    First WG draft of "certificate, CRL, and OCSP processing" document (12 months).

7.    First WG draft of "certificate re-issuance" document (4 months).

8.    First WG draft of "certificate renewal" document (4 months).

9.    First WG draft of "certificate revocation" document (8 months).

10. IESG submission of "trust model" document (16 months).

11. IESG submission of "public-key submission and certificate installation" document (16 months).

12. IESG submission of "certificate, CRL, and OCSP profile" document (20 months).

13. IESG submission of "certificate, CRL, and OCSP processing" document (24 months).

14. IESG submission of "certificate re-issuance" document (16 months).

15. IESG submission of "certificate renewal" document (16 months).

16. IESG submission of "certificate revocation" document (20 months)

The schedule is predicated upon the group's ability to recruit a sufficient number of editors and engage either the relevant product experts or other experts willing to test the selected product configurations.

T: +1 613 270 3183

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 22 Aug 2012 10:29:00 -0400

Tim,

This is an excellent first attempt. Comments in line.....

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Moses
Sent: Wednesday, August 22, 2012 8:45 AM
To: [email-masked]'
Subject: [wpkops] First draft charter proposal

So far, this is exceptionally strong!

Milestones

=========

Typically, this is done before the WG is formed. No need for an RFC

When you say "Products", do you mean "Explorer, Chrome and Safari". If so, that might be a problem. In the IETF, we can't talk about peoples products. We have to talk about protocols.

This is true for all WGs. There is no need to say it.

T: +1 613 270 3183

---

From: Tim Moses <[email-masked]>
Date: Wed, 22 Aug 2012 19:00:06 +0000

Thanks Ron.  Very helpful.

On the topic of "products", I'm afraid I did mean specific company's products.  The thinking was that we need to limit the scale of the job, so that our efforts only go towards useful deliverables.  We don't need to waste time documenting how IE3 implemented the Web PKI.  But, we do need to document versions other than the most recent ones, because those still form a significant part of today's Web PKI.  Maybe, we should speak in terms of "the product implementations that make up today's Web PKI", and rely on the participants' judgment to decide which products and versions fall into that category, while (at no time) being explicit about which products those are.

All the best.  Tim.

From: Ronald Bonica [mailto:[email-masked]]
Sent: Wednesday, August 22, 2012 10:29 AM
To: Tim Moses; [email-masked]'
Subject: RE: First draft charter proposal

Tim,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Tim Moses
Sent: Wednesday, August 22, 2012 8:45 AM
To: [email-masked]'
Subject: [wpkops] First draft charter proposal

Milestones

=========

T: +1 613 270 3183

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Aug 2012 21:33:12 +0100

Thanks Tim for that.

I agree with Ron - that's a really good start, but does need work.

My initial thoughts on that:

- I think the milestone list you presented is too detailed for a
charter, especially at this point. But I'd say that can be left
for now though until the overall scope is clearer. So fix that
later and let's try focus on the scope for now.

- I'm not sure that omitting code signing is a good plan, since
the same libraries and trust anchors are used and code-signing
has been a recent attack vector of note. Omitting document
signing and email seems ok to me though as those are much more
enterprisey things, but HTTPS and code-signing are both common
on the public Internet. So I'd like to understand that better.

- I think the putative OPS WG ought document deployed stuff as
you say, but beyond that its scope ought be explicitly limited
to developing (at most) use-cases and/or requirements for any new
protocol. So I'm not at all sure how to interpret some of the
deliverables you envisage. For example, what's the "certificate,
CRL, and OCSP profile" document? If that means "invent a new
profile" then I have a problem with that. If it means "document
deployed deviations from 5280/2560" then that'd be fine I think
but then it ought have a different name.

- As Ron said, the IETF doesn't do product evaluations but I
think that's an easy one, just include in scope documenting
the behaviour of "recent" browsers, web servers and (I guess)
relevant middleboxen, so long as they have non-trivial
deployment.

Cheers,
S.

On 08/22/2012 01:44 PM, Tim Moses wrote:
> _______________________________________________
> wpkops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpkops
>

---

From: Tim Moses <[email-masked]>
Date: Wed, 22 Aug 2012 20:56:36 +0000

Thanks Stephen.  To explain ... when I suggested a profiling activity, I had in mind to describe the subset of PKIX that is actually used in the Web PKI (as well as non-conformant variations).  For instance, I don't believe any publicly-trusted CAs issue delta CRLs or that any browsers use OCSP nonces.  If this is true, then it isn't recorded in any one place.  I had in mind to record those facts.  And, there are - no doubt - many other features of RFC 5280 that are not exercised in the Web PKI.  Do that seem appropriate to you?

All the best.  Tim.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, August 22, 2012 4:33 PM
To: Tim Moses
Cc: [email-masked]'
Subject: Re: [wpkops] First draft charter proposal

Thanks Tim for that.

- I think the milestone list you presented is too detailed for a charter, especially at this point. But I'd say that can be left for now though until the overall scope is clearer. So fix that later and let's try focus on the scope for now.

- I'm not sure that omitting code signing is a good plan, since the same libraries and trust anchors are used and code-signing has been a recent attack vector of note. Omitting document signing and email seems ok to me though as those are much more enterprisey things, but HTTPS and code-signing are both common on the public Internet. So I'd like to understand that better.

- I think the putative OPS WG ought document deployed stuff as you say, but beyond that its scope ought be explicitly limited to developing (at most) use-cases and/or requirements for any new protocol. So I'm not at all sure how to interpret some of the deliverables you envisage. For example, what's the "certificate, CRL, and OCSP profile" document? If that means "invent a new profile" then I have a problem with that. If it means "document deployed deviations from 5280/2560" then that'd be fine I think but then it ought have a different name.

- As Ron said, the IETF doesn't do product evaluations but I think that's an easy one, just include in scope documenting the behaviour of "recent" browsers, web servers and (I guess) relevant middleboxen, so long as they have non-trivial deployment.

Cheers,
S.

---

From: Randy Turner <[email-masked]>
Date: Wed, 22 Aug 2012 14:17:33 -0700

Hi Tim,

I think the problem space you are defining does definitely need some discipline applied to the mostly organic evolution of PKI, as experienced by end users, typically through browsers.

Based on the knowledge gained (acquired) from the participants and their experiences + any landscape analysis of currently shipping behaviors, I think there should be enough "meat" there to justify a WG.

I am expecting (read "hoping") that what will come out of this work however, will not strictly apply to browsers and content servers.

I would think most of the issues/problems and subsequent requirements would probably form a BCP for any user-facing application that utilizes PKI - not just browsers and servers.

No doubt, there will be some use-cases that are browser/server-centric, but I think it might be a "short walk" to factor out the browser/content-server specifics to realize a benefit for PKI apps in general.

I know Stephen may think that email and document signing is more "enterprise-y", but if you're going to bring the subject of "signing" of content into the problem space, any user-facing application that performs signatures should be able to benefit. 

Randy

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Thu, 23 Aug 2012 00:22:48 +0300

+1

Thanks,
M.D.

---

From: "Hill, Brad" <[email-masked]>
Date: Wed, 22 Aug 2012 21:27:40 +0000

I agree with Tim that we should start with a narrow scope focused on the Web PKI rather than documents, etc.,  I also think there are cases that are on the edge - like the programmatic HTTP clients used by mobile aps, embedded browsing contexts with different PKI error handling logic than standalone ones, and, towards the more complex end, web services that use HTTP and the web PKI explicitly but might also use other transports and trust models.  Not clear from the draft charter where to draw the line among these, but there is plenty of work to do and that needs doing urgently.

Brad Hill

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Moses
Sent: Wednesday, August 22, 2012 5:45 AM
To: [email-masked]'
Subject: [wpkops] First draft charter proposal

T: +1 613 270 3183

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Aug 2012 22:37:41 +0100

Hi Tim,

> Thanks Stephen.  To explain ... when I suggested a profiling activity, I had in mind to describe the subset of PKIX that is actually used in the Web PKI (as well as non-conformant variations).  For…

It does, yes.

I think though that it'll be important for this to always be
seen in context so avoiding the (mis-)perception that the
goal is to re-visit PKIX will continue to be important.

Perhaps avoiding the term "profiling" will help - PKIX after
all was setup to profile X.509, which is not what you're
after here. While doing that profiling PKIX had to invent
lots of detailed rules that weren't specified in the CCITT
docs but that were (thought to be) needed for interop, and
its that kind of invention that we want to avoid here I
think.

Maybe focus on saying "document deployed PKI" as much as
possible just to be clear?

S

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Thu, 23 Aug 2012 00:42:13 +0300

Right, but obviously seeking to narrow the scope we need a wider vision, 
right? Exclusion of "documents etc." has its historical reasons, not 
technological. Why not to form a generic vision and based on that try to 
figure out the scope of interest.

Thanks,
M.D.

On 8/23/2012 12:27 AM, Hill, Brad wrote:
>
> I agree with Tim that we should start with a narrow scope focused on 
> the Web PKI rather than documents, etc.,  I also think there are cases 
> that are on the edge -- like the programmatic HTTP clients used by 
> mobile aps, embedded browsing contexts with different PKI error 
> handling logic than standalone ones, and, towards the more complex 
> end, web services that use HTTP and the web PKI explicitly but might 
> also use other transports and trust models.  Not clear from the draft 
> charter where to draw the line among these, but there is plenty of 
> work to do and that needs doing urgently.
>
> Brad Hill
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Tim Moses
> *Sent:* Wednesday, August 22, 2012 5:45 AM
> *To:* [email-masked]'
> *Subject:* [wpkops] First draft charter proposal
>
> Colleagues -- Here is a first draft of a charter proposal.  Please 
> give it some thought and share the results of your deliberations.  
> Thanks a lot.  All the best.  Tim.
>
> The Web PKI is the set of systems and procedures most commonly used to 
> protect the confidentiality, integrity and authenticity of 
> communications between Web browsers and Web content servers.  It first 
> appeared in 1993 or thereabouts and has developed continuously in a 
> somewhat organic fashion since then.  Across all the suppliers and the 
> point releases of their products, there are now hundreds of variations 
> on the Web PKI in regular use.  And this can be a source of problems 
> both for end-users and certificate issuers.
>
> For end-users, there is no clear view whether certificate "problems" 
> remain when they see indication of a "good" connection.  For instance, 
> in some browsers, a "good" indication may be displayed when a 
> "revoked" response has been received and "accepted" by the user.  
> Whereas, other browsers may refuse to display the contents under these 
> circumstances.
>
> And for issuers, it can be difficult to predict what proportion of the 
> user population will accept a certificate chain with certain 
> characteristics.  For instance, when a browser includes a nonce in an 
> OCSP request but the server supplies a response that does not include 
> the nonce, it is hard to know which browsers will accept and which 
> will reject the response.
>
> Starting from the premise that more consistency in Web security 
> behavior is desirable, a natural first step would be to document 
> current and historic browser and server behavior.
>
> Future activities may attempt to prescribe how the Web PKI "should" 
> work, and the prescription may turn out to be a proper subset of the 
> PKIX PKI.  However, that task is explicitly not a goal of the proposed 
> working group.  Instead, the group's goal is merely to describe how 
> the Web PKI "actually" works in the set of browsers and servers that 
> are in common use today.
>
> Additionally, a number of applications (other than the Web) may use 
> the same trust anchors as the ones used by the Web.  These 
> applications include: document signing; code signing; and email.  They 
> may use PKI in a way that differs from the way in which the Web uses 
> it. Therefore, these applications are explicitly out of scope for the 
> working group.
>
> Also, the reliability of the Web PKI depends critically on the 
> practices of its certificate issuers. However, the topic of practices 
> is outside the scope of the IETF.  Therefore, this will be left to 
> other competent bodies.
>
> That there are technical shortcomings with Web PKI, as it is practiced 
> today, is well recognized.  And, that there is also some urgency in 
> addressing these shortcomings is also well recognized.  But, it is 
> felt that too much haste can be counter-productive.  The expectation 
> is that the work of this group will bring to light, in a systematic 
> way, aspects of the Web PKI that should be progressed in future 
> working groups of the IETF's Security Area, and that suppliers will be 
> willing to participate in those working groups and modify their 
> products to comply with their standards.
>
> Given the urgency of the required developments and the scale of the 
> task, it is agreed that adherence to the published schedule should 
> take precedence over completeness of the results.  The working group 
> should focus its initial attention on the browser and server versions 
> that make up the largest part of the desktop and mobile Web today.
>
> 1.Agree the working group charter (1 month).
>
> 2.Catalog the products and versions to be analyzed (1 month).
>
> 3.First WG draft of "trust model" document (4 months).
>
> 4.First WG draft of "public-key submission and certificate 
> installation" document (4 months).
>
> 5.First WG draft of "certificate, CRL, and OCSP profile" document (8 
> months).
>
> 6.First WG draft of "certificate, CRL, and OCSP processing" document 
> (12 months).
>
> 7.First WG draft of "certificate re-issuance" document (4 months).
>
> 8.First WG draft of "certificate renewal" document (4 months).
>
> 9.First WG draft of "certificate revocation" document (8 months).
>
> 10.IESG submission of "trust model" document (16 months).
>
> 11.IESG submission of "public-key submission and certificate 
> installation" document (16 months).
>
> 12.IESG submission of "certificate, CRL, and OCSP profile" document 
> (20 months).
>
> 13.IESG submission of "certificate, CRL, and OCSP processing" document 
> (24 months).
>
> 14.IESG submission of "certificate re-issuance" document (16 months).
>
> 15.IESG submission of "certificate renewal" document (16 months).
>
> 16.IESG submission of "certificate revocation" document (20 months)
>
> The schedule is predicated upon the group's ability to recruit a 
> sufficient number of editors and engage either the relevant product 
> experts or other experts willing to test the selected product 
> configurations.
>
> T: +1 613 270 3183
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Aug 2012 22:44:14 +0100

I've no very strong opinion myself about what's right for this
aspect of the scope of the proposed work.

But I do think the scope in terms of applications needs to be
clear and whatever scope is chosen needs a good justification.
(When I say "applications," I mean the set of applications that
are dependent on the in-scope aspects of PKI, not that this WG
would be saying how HTTPS or S/MIME should work.)

Tim's initial text is clear, but I don't get the justification
for that choice, should it be the one that ends up being made.
In particular, I don't get why code-signing is called out of
scope.

S

---

From: "Ben Wilson" <[email-masked]>
Date: Wed, 22 Aug 2012 15:52:01 -0600

Tim,

How do you envision that any previous or future work product of members of
the CAB Forum on profile-type documents be integrated into the work of this
group?

Namely, in Section 9 of the Baseline Requirements there was some language
about Issuer and Subject Identifiers, and then Appendices A and B discussed
key lengths, algorithms, and certificate extensions. 

I am thinking that because there will be an overlap of participation from
many of the same players it will not be a problem, but will one group end up
deferring to the other on certain types of issues, or are they completely
separate?

Thanks,

Ben

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tim Moses
Sent: Wednesday, August 22, 2012 6:45 AM
To: [email-masked]'
Subject: [wpkops] First draft charter proposal

Colleagues - Here is a first draft of a charter proposal.  Please give it
some thought and share the results of your deliberations.  Thanks a lot.
All the best.  Tim.

The Web PKI is the set of systems and procedures most commonly used to
protect the confidentiality, integrity and authenticity of communications
between Web browsers and Web content servers.  It first appeared in 1993 or
thereabouts and has developed continuously in a somewhat organic fashion
since then.  Across all the suppliers and the point releases of their
products, there are now hundreds of variations on the Web PKI in regular
use.  And this can be a source of problems both for end-users and
certificate issuers.

For end-users, there is no clear view whether certificate "problems" remain
when they see indication of a "good" connection.  For instance, in some
browsers, a "good" indication may be displayed when a "revoked" response has
been received and "accepted" by the user.  Whereas, other browsers may
refuse to display the contents under these circumstances.

And for issuers, it can be difficult to predict what proportion of the user
population will accept a certificate chain with certain characteristics.
For instance, when a browser includes a nonce in an OCSP request but the
server supplies a response that does not include the nonce, it is hard to
know which browsers will accept and which will reject the response.

Starting from the premise that more consistency in Web security behavior is
desirable, a natural first step would be to document current and historic
browser and server behavior.

Future activities may attempt to prescribe how the Web PKI "should" work,
and the prescription may turn out to be a proper subset of the PKIX PKI.
However, that task is explicitly not a goal of the proposed working group.
Instead, the group's goal is merely to describe how the Web PKI "actually"
works in the set of browsers and servers that are in common use today.

Additionally, a number of applications (other than the Web) may use the same
trust anchors as the ones used by the Web.  These applications include:
document signing; code signing; and email.  They may use PKI in a way that
differs from the way in which the Web uses it.  Therefore, these
applications are explicitly out of scope for the working group.

Also, the reliability of the Web PKI depends critically on the practices of
its certificate issuers.  However, the topic of practices is outside the
scope of the IETF.  Therefore, this will be left to other competent bodies.

That there are technical shortcomings with Web PKI, as it is practiced
today, is well recognized.  And, that there is also some urgency in
addressing these shortcomings is also well recognized.  But, it is felt that
too much haste can be counter-productive.  The expectation is that the work
of this group will bring to light, in a systematic way, aspects of the Web
PKI that should be progressed in future working groups of the IETF's
Security Area, and that suppliers will be willing to participate in those
working groups and modify their products to comply with their standards.

Given the urgency of the required developments and the scale of the task, it
is agreed that adherence to the published schedule should take precedence
over completeness of the results.  The working group should focus its
initial attention on the browser and server versions that make up the
largest part of the desktop and mobile Web today.

4.    First WG draft of "public-key submission and certificate installation"
document (4 months).

5.    First WG draft of "certificate, CRL, and OCSP profile" document (8
months).

6.    First WG draft of "certificate, CRL, and OCSP processing" document (12
months).

11. IESG submission of "public-key submission and certificate installation"
document (16 months).

12. IESG submission of "certificate, CRL, and OCSP profile" document (20
months).

13. IESG submission of "certificate, CRL, and OCSP processing" document (24
months).

The schedule is predicated upon the group's ability to recruit a sufficient
number of editors and engage either the relevant product experts or other
experts willing to test the selected product configurations.   

T: +1 613 270 3183

---

From: "Hill, Brad" <[email-masked]>
Date: Wed, 22 Aug 2012 22:29:34 +0000

Moudrick Dadashov wrote:

>Right, but obviously seeking to narrow the scope we need a wider vision, right?
>Exclusion of "documents etc." has its historical reasons, not technological.

I think it does have technological reasons:  Document and code signing has to:

* Deal with problems of long-lived artifacts - including signed objects that may outlive the certificates used to sign them
* Work by default without a direct connection to the entity in control of the certificate
* Support entirely offline verification

   This has also led to different practices about revocation and blacklisting, use of third party time stamping authorities, etc.  The differences are substantial.

Code signing in particular is also HIGHLY vendor-specific.  I may be mistaken, but my impression is that it's not meaningful at all to talk about a single set of practices around code signing that is common across multiple platforms - Java, Apple App Store, Android Apps,  Microsoft Authenticode, Strong Named Assemblies in .NET, etc.

Java and Authenticode may have interoperable certificate formats, but how they are used still differs greatly.  Individual vendors remain in the best position to provide authoritative guidance on their own implementations.

Document signing is a bit more interoperable, though still more fragmented than the Web by regulatory requirements and jurisdictional boundaries, and often additionally by document formats. (PDF vs. Word vs. XML)

I think "the Web" / HTTPS is the only PKI (other than the work PKIX does/did) with enough actually interoperating implementations that a body like the IETF is best-positioned to document current and historical practices.

-Brad

From: Moudrick M. Dadashov [mailto:[email-masked]]
Sent: Wednesday, August 22, 2012 2:42 PM
To: Hill, Brad
Cc: Tim Moses; [email-masked]'
Subject: Re: [wpkops] First draft charter proposal

Right, but obviously seeking to narrow the scope we need a wider vision, right? Exclusion of "documents etc." has its historical reasons, not technological. Why not to form a generic vision and based on that try to figure out the scope of interest.

Thanks,
M.D.

Brad Hill

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Tim Moses
Sent: Wednesday, August 22, 2012 5:45 AM
To: [email-masked]<mailto:[email-masked]>'
Subject: [wpkops] First draft charter proposal

T: +1 613 270 3183

wpkops mailing list

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

---

From: Randy Turner <[email-masked]>
Date: Wed, 22 Aug 2012 15:38:07 -0700

I would agree with the scope that "signing" brings into the potential work of a WG, but I think there might be a fair amount of interoperable S/MIME experience as well that could be discussed.

Code signing is a bit fragmented, although there have been discussions on using CMS for generating signed code containers, but vendors largely do what they want (as you mentioned)

The LTANS working group looked at document archival awhile back, and did some work on timestamping, but I'm not aware of any shipping implementations that standardized their long-term archival strategies regarding signatures or timestamping (not that there aren't any, I just don't keep up with this)

R.

On Aug 22, 2012, at 3:29 PM, Hill, Brad wrote:

> * Deal with problems of long-lived artifacts – including signed objects that may outlive the certificates used to sign them
> Code signing in particular is also HIGHLY vendor-specific.  I may be mistaken, but my impression is that it’s not meaningful at all to talk about a single set of practices around code signing that is common across multiple platforms – Java, Apple App Store, Android Apps,  Microsoft Authenticode, Strong Named Assemblies in .NET, etc. 
>  
> I think “the Web” / HTTPS is the only PKI (other than the work PKIX does/did) with enough actually interoperating implementations that a body like the IETF is best-positioned to document current and historical practices.
>  
> -Brad
>  
> I agree with Tim that we should start with a narrow scope focused on the Web PKI rather than documents, etc.,  I also think there are cases that are on the edge – like the programmatic HTTP clients used by mobile aps, embedded browsing contexts with different PKI error handling logic than standalone ones, and, towards the more complex end, web services that use HTTP and the web PKI explicitly but might also use other transports and trust models.  Not clear from the draft charter where to draw the line among these, but there is plenty of work to do and that needs doing urgently.
>  
> Brad Hill
>  
> Colleagues – Here is a first draft of a charter proposal.  Please give it some thought and share the results of your deliberations.  Thanks a lot.  All the best.  Tim.
>

---

From: Chris Palmer <[email-masked]>
Date: Wed, 22 Aug 2012 16:25:36 -0700

On Wed, Aug 22, 2012 at 3:29 PM, Hill, Brad <[email-masked]> wrote:

> I think “the Web” / HTTPS is the only PKI (other than the work PKIX
> does/did) with enough actually interoperating implementations that a body
> like the IETF is best-positioned to document current and historical
> practices.

Exactly.

The problem of documenting current, real-world behavior for just the
HTTPS PKI is plenty hard enough; I see no reason to increase the scope
to even hairier problems right now. One impossible task at a time,
please.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Aug 2012 19:04:52 -0600

On 8/22/12 4:29 PM, Hill, Brad wrote:

> I think “the Web” / HTTPS is the only PKI (other than the work
> PKIX does/did) with enough actually interoperating
> implementations...

Brad, do you include the use of PKIX certificates in application
technologies like IMAP, LDAP, NETCONF, SIP, SMTP, SNMP, Syslog, and
XMPP as part of or derivative from "the Web PKI"? The proposed charter
seems tightly focused on browsers and HTTPS, but (as documented in RFC
6125) there's plenty of implementation and deployment of PKIX
certificates outside that space.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Randy Turner <[email-masked]>
Date: Wed, 22 Aug 2012 21:22:04 -0700

This was part of what I was alluding to earlier, the value of this work being applied to protocols/applications like the ones described below
(for my own selfish interests, I was thinking about SIP and XMPP :)

Randy

On Aug 22, 2012, at 6:04 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAlA1gbQACgkQNL8k5A2w/vyTrACg0UuaY0WHCWqXn6ZfnIapFG2K
> h6UAoPldt4Pp01duTrgJv9h/c+xsEFZv
> =iDW8
> -----END PGP SIGNATURE-----

---

From: "Hill, Brad" <[email-masked]>
Date: Thu, 23 Aug 2012 04:23:15 +0000

> Brad, do you include the use of PKIX certificates in application technologies
> like IMAP, LDAP, NETCONF, SIP, SMTP, SNMP, Syslog, and XMPP as part of or
> derivative from "the Web PKI"? The proposed charter seems tightly focused
> on browsers and HTTPS, but (as documented in RFC
> 6125) there's plenty of implementation and deployment of PKIX certificates
> outside that space.

Good questions.  They are closer cousins than the offline use cases.  My follow up questions would be:

a) Is there the same perceived need to document the "state of interop" for these uses of PKIX as there is for HTTPS?
b) Are the right experts and stakeholders here and interested in tackling any/some/all of these as part of this proposed WG?
c) Will those people commit to edit and contribute to the relevant deliverables?
d) Does that work depend on or build directly from the HTTPS work, or are there other WGs where it can be undertaken on its own timeline and where the "right people" are already assembled?

-Brad

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2012 6:05 PM
> To: Hill, Brad
> Cc: Moudrick M. Dadashov; [email-masked]'; Tim Moses
> > does/did) with enough actually interoperating implementations...
> 
> Brad, do you include the use of PKIX certificates in application technologies
> like IMAP, LDAP, NETCONF, SIP, SMTP, SNMP, Syslog, and XMPP as part of or
> derivative from "the Web PKI"? The proposed charter seems tightly focused
> on browsers and HTTPS, but (as documented in RFC
> 6125) there's plenty of implementation and deployment of PKIX certificates
> outside that space.
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> 
>

---

From: Randy Turner <[email-masked]>
Date: Wed, 22 Aug 2012 21:23:30 -0700

Yes, I was specifically referring to signing timestamps and/or content as a part of the LTANS work…I just wasn't sure if there were products in the marketplace that could be called "LTANS-compliant" 

R.

On Aug 22, 2012, at 7:05 PM, Santosh Chokhani wrote:

> I do not know what you mean by “shipping” here, but LTANS did work on long term non repudiation and time stamp resulting Evidence Record Structure RFC.
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Turner
> Sent: Wednesday, August 22, 2012 6:38 PM
> To: [email-masked]

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 22 Aug 2012 22:05:05 -0400

I do not know what you mean by "shipping" here, but LTANS did work on long term non repudiation and time stamp resulting Evidence Record Structure RFC.

R.

-Brad

From: Moudrick M. Dadashov [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, August 22, 2012 2:42 PM
To: Hill, Brad
Cc: Tim Moses; [email-masked]<mailto:[email-masked]>'
Subject: Re: [wpkops] First draft charter proposal

Thanks,
M.D.

Brad Hill

T: +1 613 270 3183

wpkops mailing list

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Aug 2012 10:44:17 +0100

FWIW, I'd be *highly* skeptical that an OPS area WG is needed to
address anything whatsoever about LTANS. While it might be fine
work, its just not sufficiently deployed for that to be useful.

S.

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Thu, 23 Aug 2012 13:03:04 +0300

On 8/23/2012 1:29 AM, Hill, Brad wrote:
> * Deal with problems of long-lived artifacts -- including signed 
> objects that may outlive the certificates used to sign them
>

or just to identify those generic building blocks that are common to 
many similar use scenarios. If web client authentication fits into the 
"narrowed scope" why web signing doesn't?
>
>    This has also led to different practices about revocation and 
> blacklisting, use of third party time stamping authorities, etc.  The 
> differences are substantial.
>

Sure, service/application specific specialties are obviously out of scope.
>
> Code signing in particular is also HIGHLY vendor-specific.  I may be 
> mistaken, but my impression is that it's not meaningful at all to talk 
> about a single set of practices around code signing that is common 
> across multiple platforms -- Java, Apple App Store, Android Apps, 
>  Microsoft Authenticode, Strong Named Assemblies in .NET, etc.
>
> Java and Authenticode may have interoperable certificate formats, but 
> how they are used still differs greatly.  Individual vendors remain in 
> the best position to provide authoritative guidance on their own 
> implementations.
>
> Document signing is a bit more interoperable, though still more 
> fragmented than the Web by regulatory requirements and jurisdictional 
> boundaries, and often additionally by document formats. (PDF vs. Word 
> vs. XML)
>
whatever the difference is, the underlying lower level operations 
(building blocks) are almost the same or very close, all we need at this 
stage is to identify them.
>
> I think "the Web" / HTTPS is the only PKI (other than the work PKIX 
> does/did) with enough actually interoperating implementations that a 
> body like the IETF is best-positioned to document current and 
> historical practices.
>
No doubt. Web client authentication, web content signing are second to 
that IMO.

Thanks,
M.D.
>
> -Brad
>
> *From:*Moudrick M. Dadashov [mailto:[email-masked]]
> *Sent:* Wednesday, August 22, 2012 2:42 PM
> *To:* Hill, Brad
> *Cc:* Tim Moses; [email-masked]'
> *Subject:* Re: [wpkops] First draft charter proposal
>
> Right, but obviously seeking to narrow the scope we need a wider 
> vision, right? Exclusion of "documents etc." has its historical 
> reasons, not technological. Why not to form a generic vision and based 
> on that try to figure out the scope of interest.
>
> Thanks,
> M.D.
>
>     I agree with Tim that we should start with a narrow scope focused
>     on the Web PKI rather than documents, etc.,  I also think there
>     are cases that are on the edge -- like the programmatic HTTP
>     clients used by mobile aps, embedded browsing contexts with
>     different PKI error handling logic than standalone ones, and,
>     towards the more complex end, web services that use HTTP and the
>     web PKI explicitly but might also use other transports and trust
>     models.  Not clear from the draft charter where to draw the line
>     among these, but there is plenty of work to do and that needs
>     doing urgently.
>
>     Brad Hill
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] *On Behalf Of *Tim Moses
>     *To:* [email-masked] <mailto:[email-masked]>'
>     The Web PKI is the set of systems and procedures most commonly
>     used to protect the confidentiality, integrity and authenticity of
>     communications between Web browsers and Web content servers.  It
>     first appeared in 1993 or thereabouts and has developed
>     continuously in a somewhat organic fashion since then.  Across all
>     the suppliers and the point releases of their products, there are
>     now hundreds of variations on the Web PKI in regular use.  And
>     this can be a source of problems both for end-users and
>     certificate issuers.
>
>     For end-users, there is no clear view whether certificate
>     "problems" remain when they see indication of a "good"
>     connection.  For instance, in some browsers, a "good" indication
>     may be displayed when a "revoked" response has been received and
>     "accepted" by the user.  Whereas, other browsers may refuse to
>     display the contents under these circumstances.
>
>     And for issuers, it can be difficult to predict what proportion of
>     the user population will accept a certificate chain with certain
>     characteristics.  For instance, when a browser includes a nonce in
>     an OCSP request but the server supplies a response that does not
>     include the nonce, it is hard to know which browsers will accept
>     and which will reject the response.
>
>     Future activities may attempt to prescribe how the Web PKI
>     "should" work, and the prescription may turn out to be a proper
>     subset of the PKIX PKI.  However, that task is explicitly not a
>     goal of the proposed working group.  Instead, the group's goal is
>     merely to describe how the Web PKI "actually" works in the set of
>     browsers and servers that are in common use today.
>
>     Additionally, a number of applications (other than the Web) may
>     use the same trust anchors as the ones used by the Web.  These
>     applications include: document signing; code signing; and email. 
>     They may use PKI in a way that differs from the way in which the
>     Web uses it.  Therefore, these applications are explicitly out of
>     scope for the working group.
>
>     practices of its certificate issuers.  However, the topic of
>     practices is outside the scope of the IETF.  Therefore, this will
>     be left to other competent bodies.
>
>     That there are technical shortcomings with Web PKI, as it is
>     practiced today, is well recognized.  And, that there is also some
>     urgency in addressing these shortcomings is also well recognized.
>     But, it is felt that too much haste can be counter-productive. 
>     The expectation is that the work of this group will bring to
>     light, in a systematic way, aspects of the Web PKI that should be
>     progressed in future working groups of the IETF's Security Area,
>     and that suppliers will be willing to participate in those working
>     groups and modify their products to comply with their standards.
>
>     Given the urgency of the required developments and the scale of
>     the task, it is agreed that adherence to the published schedule
>     should take precedence over completeness of the results.  The
>     working group should focus its initial attention on the browser
>     and server versions that make up the largest part of the desktop
>     and mobile Web today.
>
>     5.First WG draft of "certificate, CRL, and OCSP profile" document
>     (8 months).
>
>     6.First WG draft of "certificate, CRL, and OCSP processing"
>     document (12 months).
>
>     12.IESG submission of "certificate, CRL, and OCSP profile"
>     document (20 months).
>
>     13.IESG submission of "certificate, CRL, and OCSP processing"
>     document (24 months).
>
>     sufficient number of editors and engage either the relevant
>     product experts or other experts willing to test the selected
>     product configurations.
>
>     T: +1 613 270 3183
>
>
>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Tim Moses <[email-masked]>
Date: Thu, 23 Aug 2012 13:43:10 +0000

Hi Ben.  I don't see a conflict.  I think the CA/Browser Forum develops recommendations (both technical and procedural) for modifications to the relevant audit standards (ETSI and WebTrust).  If accepted, these recommendations get enforced "going forward".  The proposal for WPKOPS is that it document existing technical functionality.  The CA/B Forum work is "prescriptive".  The WKPOPS work is "descriptive", but it would describe those CA/B Forum recommendations that have already been enacted.

Now, looking beyond WPKOPS, if this activity were to be successful (and by "successful" I mean that it attracts experts who actually know how the Web PKI works and have the ability to change it) then it could spawn other working groups with a mandate to define how the future Web PKI will work.  But, now I'm getting ahead of myself.

All the best.  Tim.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Wilson
Sent: Wednesday, August 22, 2012 5:52 PM
To: Tim Moses; [email-masked]
Subject: Re: [wpkops] First draft charter proposal

Tim,
How do you envision that any previous or future work product of members of the CAB Forum on profile-type documents be integrated into the work of this group?
Namely, in Section 9 of the Baseline Requirements there was some language about Issuer and Subject Identifiers, and then Appendices A and B discussed key lengths, algorithms, and certificate extensions.
I am thinking that because there will be an overlap of participation from many of the same players it will not be a problem, but will one group end up deferring to the other on certain types of issues, or are they completely separate?
Thanks,
Ben

T: +1 613 270 3183

---

From: Randy Turner <[email-masked]>
Date: Thu, 23 Aug 2012 06:55:09 -0700

Yes, that was my question….they were doing signature-like things, but I wasn't sure about the size of any deployment….(i.e, "shipping products")

R.

---

From: Tim Moses <[email-masked]>
Date: Thu, 23 Aug 2012 14:22:48 +0000

I agree with Brad and Stephen.  We need to be addressing pressing practical problems.  And (in my mind) site-authentication qualifies.  I understand Stephen's concern about code-signing.  But, it seems like significant extra work.  I wonder if it should be left out of the initial charter.  Once we have a better grasp of the type and quantity of resources that we can draw on, we could consider a re-chartering exercise to include it.  All the best.  Tim.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Turner
Sent: Thursday, August 23, 2012 9:55 AM
To: [email-masked]
Subject: Re: [wpkops] First draft charter proposal

Yes, that was my question....they were doing signature-like things, but I wasn't sure about the size of any deployment....(i.e, "shipping products")

R.

On Aug 23, 2012, at 2:44 AM, Stephen Farrell <[email-masked]> wrote:

> address anything whatsoever about LTANS. While it might be fine work, 
> its just not sufficiently deployed for that to be useful.
> 
> S.
> 
>> Yes, I was specifically referring to signing timestamps and/or content as a part of the LTANS work...I just wasn't sure if there were products in the marketplace that could be called "LTANS-compliant" 
>> 
>> R.
>> 
>>> Code signing is a bit fragmented, although there have been 
>>> discussions on using CMS for generating signed code containers, but 
>>> vendors largely do what they want (as you mentioned)
>>> 
>>> The LTANS working group looked at document archival awhile back, and 
>>> did some work on timestamping, but I'm not aware of any shipping 
>>> implementations that standardized their long-term archival 
>>> strategies regarding signatures or timestamping (not that there 
>>> aren't any, I just don't keep up with this)
>>> 
>>> R.
>>> 
>>> 
>>> * Deal with problems of long-lived artifacts - including signed 
>>> fragmented than the Web by regulatory requirements and 
>>> jurisdictional boundaries, and often additionally by document 
>>> formats. (PDF vs. Word vs. XML)
>>>

---

From: Randy Turner <[email-masked]>
Date: Thu, 23 Aug 2012 07:37:17 -0700

I think Stephen's reminder about the "OPS" designation in the proposed WG, is a good one.

If that's the case, then, by definition, it's probably existing pressing issues with deployed standards that's the target (or so it would seem).

By eliminating signing we're saying one of the following:

1.  Signatures are not deployed significantly to end-users, so it's not an OPS problem
2.  Signatures "are" deployed significantly, but there are no perceived issues in the current deployment
3.  The scope of web browser/server use of PKI (site authentication, etc.) by itself is enough for the WG

I think it's #3 

I'm ok with the go-forward  "Once we have a better grasp…" strategy included in the Tim's note below.

R.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 23 Aug 2012 10:38:11 -0400

One problem with a narrow scope is the mechanisms that support the "Web
PKI" also support a lot of the stuff being categorized as out of scope.
It's not clear that focusing on site authentication in isolation is
correct where the documented mechanisms have a (negative) impact on things
like email, mutually authenticated TLS, chat, code signing, etc.  It may
be fine to limit the primary focus in the charter but take care during the
documentation effort to note where mechanisms are reused for purposes
beyond site authentication (even if the reuse is not explored to great
depth).  

On 8/23/12 10:22 AM, "Tim Moses" <[email-masked]> wrote:

>I agree with Brad and Stephen.  We need to be addressing pressing
>practical problems.  And (in my mind) site-authentication qualifies.  I
>understand Stephen's concern about code-signing.  But, it seems like
>significant extra work.  I wonder if it should be left out of the initial
>charter.  Once we have a better grasp of the type and quantity of
>resources that we can draw on, we could consider a re-chartering exercise
>to include it.  All the best.  Tim.
>
>Yes, that was my question....they were doing signature-like things, but I
>wasn't sure about the size of any deployment....(i.e, "shipping products")
>
>R.
>
>
>>> Yes, I was specifically referring to signing timestamps and/or content
>>>as a part of the LTANS work...I just wasn't sure if there were products
>>>in the marketplace that could be called "LTANS-compliant"
>>> 
>>> R.
>>> 
>>>> I do not know what you mean by "shipping" here, but LTANS did work on
>>>>long term non repudiation and time stamp resulting Evidence Record
>>>>Structure RFC.
>>>> 
>>>> I would agree with the scope that "signing" brings into the potential
>>>>work of a WG, but I think there might be a fair amount of
>>>>interoperable S/MIME experience as well that could be discussed.
>>>> 
>>>>>vision, right?
>>>>across multiple platforms - Java, Apple App Store, Android Apps,
>>>>that are on the edge - like the programmatic HTTP clients used by
>>>> Colleagues - Here is a first draft of a charter proposal.  Please
>>>> The Web PKI is the set of systems and procedures most commonly used
>>>>to protect the confidentiality, integrity and authenticity of
>>>>But, it is felt that too much haste can be counter-productive.  The
>>>>expectation is that the work of this group will bring to light, in a
>>>>systematic way, aspects of the Web PKI that should be progressed in
>>>>future working groups of the IETF's Security Area, and that suppliers
>>>>will be willing to participate in those working groups and modify
>>>>their products to comply with their standards.
>>>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Aug 2012 10:52:03 -0400

I think that what is needed most of all in Web PKI space right now is
to arrive at a statement of what applications and servers should
expect so they can be designed to work with the PKI that exists rather
than the infinite set of possibilities that are consistent with PKIX
but not deployed.

At the moment we have a system that depends a great deal on 'lore'
which is only understood by a handful of people and is mostly arrived
at by trial and error:

* Server Lore: The PKI/SSL features that the servers actually support
* Client Lore: The PKI/SSL features that the clients actually implement
* CA Lore: How certs rollover, PKI topology

A lot of the lore results from different people trying to 'do the
right thing' in different ways. Some of it results from one side
trying to do the right thing but not being supported by another.

Quite a bit of the lore results from the common misconception that the
primary purpose of the Web PKI is to encrypt stuff rather than to
assure people that they are talking to the right party and that that
party is accountable in some fashion.

Standards that rely on Lore are not really standards in my view.

On the code signing thing, I agree that running the right code is
probably the most important security concern right now. There is
nothing Chrome can do to improve security if the Chrome executable has
been compromised.

Anti-Virus vendors such as Comodo have been moving away from
traditional AV approaches of looking for badness to a default-deny
approach. We only run the code we know is trustworthy rather than only
nerfing the code known to be bad.

Code signing could be an important part of that approach but it is
actually pretty difficult right now as every code signing scheme is
different and while most are open, some are closed (e.g. iOS). Most of
the schemes out there depend on some form of X.509 PKI and some form
of digital signature. Some only authenticate the installation package,
others have signatures on the running .exe and .obj files, some have
manifests.

It would be nice if there was some form of registry that actually
catalogued all this variation and that might lead to some future
project to come up with a single scheme that could be applied to all
code. There is really no good reason for the Java code signing scheme
to be completely different from the .Net scheme and require a
completely different validation strategy.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Aug 2012 08:59:14 -0600

On 8/22/12 10:23 PM, Hill, Brad wrote:
>> technologies like IMAP, LDAP, NETCONF, SIP, SMTP, SNMP, Syslog,
>> and XMPP as part of or derivative from "the Web PKI"? The
>> proposed charter seems tightly focused on browsers and HTTPS, but
>> (as documented in RFC 6125) there's plenty of implementation and 
>> deployment of PKIX certificates outside that space.
> 
> a) Is there the same perceived need to document the "state of 
> interop" for these uses of PKIX as there is for HTTPS?

I think there is for some of those technologies. In any case, admins
who are requesting certificates for email or IM servers interact with
the very same CAs as admins who are requesting certificates for web
servers. I'd hate to see misalignment creep in because we're
deliberately excluded everything but the web.

> b) Are the right experts and stakeholders here

Well, "here" was just created, and created with "web" in the name.
Turning it around, have the folks who are initiating this effort
reached out to any other application communities?

> and interested in tackling any/some/all of these as part of this
> proposed WG?

I'm here (heavily involved in XMPP) and given that I co-authored RFC
6125 I'm pretty interested in the general topic.

> c) Will those people commit to edit and contribute to the relevant

No idea, since they're not here yet.

> d) Does that work depend on or build directly from the HTTPS work,
> or are there other WGs where it can be undertaken on its own
> timeline and where the "right people" are already assembled?

I think some of the work for other application technologies is
parallel to the HTTPS work, and some of it is downstream. We'll need
to get down to cases and see exactly what work applies more generally
and what work is specific to particular technologies.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Adam Langley <[email-masked]>
Date: Thu, 23 Aug 2012 12:23:00 -0400

On Wed, Aug 22, 2012 at 8:44 AM, Tim Moses <[email-masked]> wrote:
> Colleagues – Here is a first draft of a charter proposal.  Please give it

Do you envision that the WG focuses solely on certificates? I would be
keen, at some point, in documenting the arcane knowledge needed to
write a browser TLS stack (i.e. something like
http://www.ietf.org/mail-archive/web/tls/current/msg07281.html).

I'd be happy to do it in the scope of this WG if that scope includes it.

Cheers

AGL

---

From: Tim Moses <[email-masked]>
Date: Thu, 23 Aug 2012 17:34:52 +0000

Hi Adam.  Personally, I would like to see this sort of material included.  It is all either directly or closely related to the workings of the PKI.  And, as long as we have a volunteer, why would we refuse the offer?  All the best.  Tim.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Thursday, August 23, 2012 12:23 PM
To: Tim Moses
Cc: [email-masked]
Subject: Re: [wpkops] First draft charter proposal

On Wed, Aug 22, 2012 at 8:44 AM, Tim Moses <[email-masked]> wrote:
> Colleagues – Here is a first draft of a charter proposal.  Please give 
> it some thought and share the results of your deliberations.  Thanks a lot.
> All the best.  Tim.

Do you envision that the WG focuses solely on certificates? I would be keen, at some point, in documenting the arcane knowledge needed to write a browser TLS stack (i.e. something like http://www.ietf.org/mail-archive/web/tls/current/msg07281.html).

Cheers

AGL

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Aug 2012 14:04:45 -0400

It occurs to me that rather than looking for participation from the
server providers, what we really need is the maintainer of the SSL
library they all use.

-- 
Website: http://hallambaker.com/

---

From: "Hodges, Jeff" <[email-masked]>
Date: Thu, 23 Aug 2012 19:33:57 +0000

+1

you going to publish draft-agl-tls-oppractices-00 in the I-D repository?
 
________________________________________
From: [email-masked] [[email-masked]] on behalf of Tim Moses [[email-masked]]
Sent: Thursday, August 23, 2012 10:34 AM
To: 'Adam Langley'
Cc: [email-masked]
Subject: Re: [wpkops] First draft charter proposal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Thursday, August 23, 2012 12:23 PM
To: Tim Moses
Cc: [email-masked]
Subject: Re: [wpkops] First draft charter proposal

Cheers

AGL