Subject: RE: charter revisions

From: "Housley, Russ" <[email-masked]>
Date: Sun, 02 Sep 2001 17:15:30 -0400

>Russ:
>
>Do you honestly believe that CA or company based logos in certificates
>will actually bring critical mass to deployments?

No.  However, I think that mass deployments will not happen without logos.

>If I have 6 certs from the same company CA - logos does nothing for me
>here in cert selection . . .

I agree that logos do not completely solve the problem of selecting 
certificates.  However, when the certificates are from different CAs or 
thay have distinctly different purposes, then a logo can be a big help.

>-----Original Message-----
>From: Housley, Russ [mailto:[email-masked]]
>Sent: Thursday, August 30, 2001 10:33 AM
>To: Steve Hanna
>Cc: Stephen Kent; [email-masked]
>Subject: Re: charter revisions
>
>
>
>Steve Hanna:
>
> >I haven't seen any comments on the revised charter yet. Most of it
> >looks good to me. However, I don't think PKIX should do any work on the
>
> >logotype extension. I know that there is a demand for this from
> >marketing folks, but I don't believe that we should standardize it
> >unless it can be used securely. This does not seem possible.
>
>You and I agree on most things, but we have a major disagreement here.  I
>do not think that we will see widespread deployment of certificates without
>logos.  One measure of success will be the number of certificates that
>average Internet user have.  Hopefully every Internet user will have at
>least one.  I suspect that as we become successful, these logos will be
>the tag by which users select a certificate.
>
>I do not want to see more than one way that logos can be put into
>certificates.  That is the most important reason for PKIX to be involved
>in the definition.  You seem to agree that the market has a demand for
>logos.  Letting each vendor devise an independent way to meet this
>marketing requirement would be very bad for all implementors.
>
>You seem to be concerned with the security of logos.  I am not.  From my
>perspective, we are asking CAs to do many things that are harder than
>including a URL and hash of a the appropriate logo.  In many, many cases,
>this will be the same logo in every certificate that is issued by that CA.
>
>Anyway, we should not have the complete technical debate on a threat
>about the charter.  I strongly encourage the PKIX working group to include
>this area in the charter sent forward to the Area Directors for approval.
>Once the revised charter is approved, we can have the technical debate and
>sort out the details.
>
>Russ

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 4 Sep 2001 14:33:55 -0700

Bob,

Ignoring for a moment the durability of the IPSEC WG, as an IETF WG, PKIX
must eventually close.  Of course, it's the chairs' call as to that precise
timing but towards those considerations, I join those who say that the value
added by addressing logotypes (and concomitantly extending the charter) does
not warrant the energy required to fully address the requirements,
particularly when placed in the context of the WG's predictable closure.

At some point, we should declare victory and go fishing.  In my opinion,
that state is most clearly signaled by closure of the DPV/DPD issues.
Beyond that, I look forward to various other fora to step forward.
Basically, move the feast.

In my individual opinion as a WG participant, logotypes are no more
technically fundamental to PKIX's mission than, say, the use of Subject
Directory Attributes to convey clearance constraints.  In fact, if someone
were to put the two on equal terms and call for a vote, I'd go for the
latter.  What Dave Fillingham et. al. put together deserves far broader
exposure than it's received to date.  My sense is that such considerations
would have longer-reaching impact than logotypes.

But that's just my opinion.  I could be wrong.

Mike

Michael Myers
t: +415.819.1362
e: mailto:[email-masked]
w: http://www.traceroutesecurity.com

> From: Bob Jueneman [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2001 1:11 PM
>
> . . . is there any evidence that  the WG is running out of energy?

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 04 Sep 2001 16:35:57 -0600

Michael,

Certainly you and I, and Russ, and a handful of Steves, and countless others, have been involved in this WG for so long that it sometimes feels like it was our life's mission.  

However, I think it might be a bit premature to suggest that PKIX be disbanded when there is relatively scant evidence (outside of SSL) that even the most basic goals of PKI have been achieved with anything close to ubiquity. To the contrary, lots of people are suggesting that "PKI is dead", without, of course, having an alternative suggestion ― except perhaps to throw the buggers out and have a new team start all over, this time presumably encoding everything in XML.

(There might even be some merit in the "throw the buggers out" school of thought, for if we aren't part of the solution, perhaps we are part of the problem.  I don't think so ― I would prefer to think that we were just ahead of our time. Some of us, of course, may be a little more ahead of our time than others. :-)  And I'm sure we all have our own personal list of those features we would most like to see added, and if push came to shove, which ones we never cared about in the first place.  Speaking only personally, I crossed that point a long time ago with respect to DPV/DPD, TSP, certain forms of cross-certification, and some other things that I probably don't understand well enough to care much about, and happily so.)

But although I might question the wisdom of continuing to proliferate this, that, and the other option during the technical discussion, I wouldn't try to invoke cloture before the debate had even started.

I wouldn't go quite as far as Patrick Henry's "I disagree with what you say, but will defend to the death your right to say it", but I don't think that we need to have that discussion as part of the charter. That seems to be putting the cart before the horse. Instead, we should allow those who espouse the idea to work up an RFC and submit it, and if a rough consensus emerges, so be it.  If not, the idea may languish forever as an experimental RFC, or it may go nowhere at all, with little harm done.  And some careful consideration might prevent someone from going off and offering something really dumb as a proprietary solution.

As far as Dave Fillingham's ideas regarding clearances and other privileges are concerned, I absolutely agree with the basic thought, and would be more than willing to contribute a number of ideas of my own in that arena. If as alleged the PKI "movement" has been less than successful, it is arguably because we have concentrated far too much on identity, and trying to implement the world's finest system of identity-based nonrepudiation, while almost completely ignoring the basic concept of trust, particularly as regards the end user.

No one cares much whether my name is Robert, Bob, or Beelzebub.  What they really want to know is what I am allowed to DO, and whether there is enough money in my account to pay for it, and who says so.  Attribute certificates don't begin to really solve that problem, IMHO, for a host of reasons I won't get into.  

So should we simply that we're tired, throw up our hands, and go fishing, i.e., leave it to the XACML crowd to try it get right?  I hope not.

A friend recently characterized their apartment complex as being made up of the "newly wed, and nearly dead".  This WG may be nearer the second than the first, but I don't think it is time to call for the Last Rights quite yet.

Bob

>>> "Michael Myers" <[email-masked]> 09/04/01 03:33PM >>>
Bob,

Mike

Michael Myers
t: +415.819.1362

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 4 Sep 2001 16:24:42 -0700

Bob,

I read through this but remain firm in my opinion that upon resolution of
the DPV/DPD issues, the working group has achieved its original engineering
mission.  Others may disagree.  This is just one vote.

Further, of course there remains vast battlefields of market share.  But
such issues I feel are better addressed in fora more appropriate to open
discussion of business interests given the sound technical platform PKIX has
defined (modulo resolution of DPV/DPD).

I'm more pleased to read of your support for Dave's efforts.  I'm assuming
as I write this that that design hasn't changed in fundamental substance
since I was last involved in its definition.  Perhaps Dave, John Pawling,
Russ or somebody could confirm my assumptions?

Minimally, I think it would be useful in the long run to have that work
documented as an Informational but perhaps that reach exceeds its grasp.

Mike

Michael Myers
t: +415.819.1362

> Sent: Tuesday, September 04, 2001 3:36 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: charter revisions
>
>
> Michael,
>
> Certainly you and I, and Russ, and a handful of Steves, and
> countless others, have been involved in this WG for so long that
> it sometimes feels like it was our life's mission.
>
> However, I think it might be a bit premature to suggest that PKIX
> be disbanded when there is relatively scant evidence (outside of
> SSL) that even the most basic goals of PKI have been achieved
> with anything close to ubiquity. To the contrary, lots of people
> are suggesting that "PKI is dead", without, of course, having an
> alternative suggestion ¯ except perhaps to throw the buggers out
> and have a new team start all over, this time presumably encoding
> everything in XML.
>
> (There might even be some merit in the "throw the buggers out"
> school of thought, for if we aren't part of the solution, perhaps
> we are part of the problem.  I don't think so ¯ I would prefer to
> think that we were just ahead of our time. Some of us, of course,
> may be a little more ahead of our time than others. :-)  And I'm
> sure we all have our own personal list of those features we would
> most like to see added, and if push came to shove, which ones we
> never cared about in the first place.  Speaking only personally,
> I crossed that point a long time ago with respect to DPV/DPD,
> TSP, certain forms of cross-certification, and some other things
> that I probably don't understand well enough to care much about,
> and happily so.)
>
> But although I might question the wisdom of continuing to
> proliferate this, that, and the other option during the technical
> discussion, I wouldn't try to invoke cloture before the debate
> had even started.
>
> I wouldn't go quite as far as Patrick Henry's "I disagree with
> what you say, but will defend to the death your right to say it",
> but I don't think that we need to have that discussion as part of
> the charter. That seems to be putting the cart before the horse.
> Instead, we should allow those who espouse the idea to work up an
> RFC and submit it, and if a rough consensus emerges, so be it.
> If not, the idea may languish forever as an experimental RFC, or
> it may go nowhere at all, with little harm done.  And some
> careful consideration might prevent someone from going off and
> offering something really dumb as a proprietary solution.
>
> As far as Dave Fillingham's ideas regarding clearances and other
> privileges are concerned, I absolutely agree with the basic
> thought, and would be more than willing to contribute a number of
> ideas of my own in that arena. If as alleged the PKI "movement"
> has been less than successful, it is arguably because we have
> concentrated far too much on identity, and trying to implement
> the world's finest system of identity-based nonrepudiation, while
> almost completely ignoring the basic concept of trust,
> particularly as regards the end user.
>
> No one cares much whether my name is Robert, Bob, or Beelzebub.
> What they really want to know is what I am allowed to DO, and
> whether there is enough money in my account to pay for it, and
> who says so.  Attribute certificates don't begin to really solve
> that problem, IMHO, for a host of reasons I won't get into.
>
> So should we simply that we're tired, throw up our hands, and go
> fishing, i.e., leave it to the XACML crowd to try it get right?
> I hope not.
>
> A friend recently characterized their apartment complex as being
> made up of the "newly wed, and nearly dead".  This WG may be
> nearer the second than the first, but I don't think it is time to
> call for the Last Rights quite yet.
>
> Bob
>

---

From: Peter Williams <[email-masked]>
Date: Tue, 04 Sep 2001 20:11:46 -0700

I think its irrelevant that particular
folks do not wish to do any work
on a potential work topic. Personally,
I have done little or no work on several PKIX
work items for years, their being
largely irrelevant to the Internet
deployment community. 

I did not feel it appropriate to seek to stop others 
however, or voice my personal prejudice toward 
their work area. In the future, these standards
may be very important baselines, as things catch
up to some of our visions.

If there is constituency to do the logotype work,
then let it happen. I cannot judge
whether the material on logotypes is legitimate
or secure, until I see IDs and active WG/list discussion
on actual proposals. 

I do know broadly the underlying issue is pertinent to many current
deployment matters across the world, including internationl
char sets issues where, culturally, unique graphical 
chars are created for an idea/name, and as DNS 
names/attributes/graphical-chars and 509 converge in the hands 
of the business known as VeriSign. 

Personally, I see the  engineering topic as wider than logotypes; its 
about the use of graphic symbols in a non-Roman way of thinking about
identifiers, names and the forms of reliance. To
me this is all very exciting, as a cultural issue set relevant 
to global uptake enters that is little addressed 
in Western-dominated ISO/IETF standards. 

If the chairs are tired, then replace the 
chairs at an appropriate milestone. I dont think anyone 
would think any worse of our chairs for ceding the floor, after
so many years of sterling service. Personally, I'd keep
both of our chairs, but thats for them to decide.

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 10:34 AM
To: [email-masked]; Stephen Kent
Cc: Steve Hanna; [email-masked]
Subject: RE: charter revisions

All,

I agree with Stephen Farrell and Steve Hanna that logotypes are out of
scope.  These needs are better addressed by other forums.  Let's focus the
WG's remaining energy on resolving DPV/DPD issues.

Mike

> On Thursday, August 30, 2001 2:35 AM Stephen Farrell wrote in part:
> . . .
> Steve (K),
>
> I'd have to agree with Steve H, though maybe not as strongly.
> My suggestion would be to limit the additional items to the
> dpd/dpv.

> On  Wednesday, August 29, 2001 2:01 PM Steve Hanna wrote in part:
>
> . . . I don't think PKIX should do any work on the

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 5 Sep 2001 16:17:51 +1200 (NZST)

"Michael Myers" <[email-masked]> writes:

>I agree with Stephen Farrell and Steve Hanna that logotypes are out of scope.

Unaccustomed as I am to agreeing with everyone else, I'll drop in my $0.02 and
concur.  In any case since it's been demonstrated that a sufficiently motivated
person can put a cat MPEG in a cert, I don't see that a simple logo will be any
problem for someone who really wants it.

Peter.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 5 Sep 2001 08:17:28 -0700

Why do logotypes have to be restricted to end entity certificates?

The most usefull place for a logo is in the root certificate so that you
know the trust brand that you are relying upon. Instead of the silly padlock
there should be an icon telling you who the trust provider is (Thawte,
VeriSign, etc.) and the strength (128bit, 40bit, WEP, etc.)

As for the complexity of cross certification etc., if logotypes don't work
in those situations then don't use them. We better hope that the
introduction of logotypes does not cause a problem with the cross
certification mechanism as some seem to believe since if that were true it
would indicate that the cross certification mechanism was broken (which
would imply adding a WG charter item to fix it which I do not see anyone
proposing).

I do consider the introduction of logotypes to be an intrinsic difficulty
for the CA or RA. Whether they would consider the market for them to be
worthwhile is another matter, likely to closely track the level of client
support.

I have not seen a convincing argument on the trademark issue. The registrar
will simply have to authenticate the ownership of the mark the same they
would any other piece of information, and presumably charge accordingly.
This can be subject to a CPS etc.

These issues may not be simple, however the degree of difficulty is
certainly not so great that the idea should be thrown out as some appear to
imply. If there really is concern we can go ask some lawyers and write a
'legal considerations' section to go along with the 'security
considerations' section.

The issue of far greater interest to me is whether any makers of client
application software have any interest in supporting the scheme. If not it
would simply be another crenelation on the specification.

Another issue is size. I don't much want to see the size of certificates
increase yet further. Perhaps a hash of the image and a URL would be
preferable. Perhaps something a bit more.

At any rate there is certainly enough to justify a WG item. If the WG
ultimately decides that it cannot solve the legal and technical difficulties
it can write a note explaining them for the benefit of future WGs.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

> From: Steve Hanna [mailto:[email-masked]]
> Sent: Wednesday, September 05, 2001 10:19 AM
> To: Paul Hoffman / IMC
> Cc: [email-masked]
> Paul Hoffman / IMC wrote:
> > At 11:58 AM -0400 9/4/01, Steve Hanna wrote:
> > >Unless the author of the Internet Draft indicates otherwise, I will
> > >assume that the primary purpose of putting logotypes in 
> certificates
> > >is so that users can view them to make decisions about whether the
> > >certificates are trustworthy. In that case, the risks are 
> much greater
> > >than those for the use case you described.
> > 
> > Are the risks any greater than what we have in 2459 now 
> with spelling
> > errors or things like "FooCA type 1 certificate" vs. "FooCA type 2
> > certificate"? I agree with Russ that the benefits are 
> higher, but I'm
> > not at all convinced that the risks are higher.
> 
> Yes, the risks are greater than those encountered with textual names.
> For one thing, name constraints provide an effective way to limit the
> portion of the name space that can be reached via a cross certificate.
> No corresponding mechanism has been suggested for logotypes 
> nor does it
> seem likely that such a mechanism could be developed.
> 
> My original email cited several other security risks that are greater
> for logotypes than for textual names: CAs may find it harder 
> to verify a
> certificate requester's right to use a logotype than their 
> right to use
> a textual name and logotypes may change appearance radically on
> different devices. Several other risks have been pointed out in the
> recent email discussion: users may not be able to distinguish one
> logotype from another, users may not recall which logotype corresponds
> to which entity, and logotypes are not accessible to vision-impaired
> users or usable on text-only terminals.
> 
> > >Unless we can develop a fairly secure way to meet the "marketing
> > >requirement" for logotypes in certificates, I would say that it is
> > >our obligation as an IETF working group to NOT accept this as a
> > >work item. Much better to have multiple incompatible ways
> > >to do something insecure (probably resulting in little deployment
> > >of this feature) than to have the PKIX working group issue an RFC
> > >explaining the one true way to do it. We are in the Security area,
> > >after all!
> > 
> > The end of that paragraph doesn't follow from the beginning of the
> > paragraph. As long as the method we described doesn't have any
> > security holes, it doesn't matter if we meet some pre-existing
> > marketing "need". Further, some of the multiple, non-interoperable
> > protocols are likely to have security problems; that is worse than
> > having one protocol that doesn't meet the need of some CAs.
> 
> The whole paragraph should be considered predicated by the 
> first clause
> ("Unless..."). If that clause does not apply (i.e., we can develop a
> fairly secure way to place logotypes in certificates), then I 
> don't have
> any objection to having this as a PKIX work item. But I have seen no
> sign that the objections raised so far can be overcome.
> 
> > Mike Myers wrote:
> > They are out of scope; the discussion is whether to add them to
> > the scope.
> 
> Of course, you are right. This is a charter discussion.
> 
> RFC 2418 (BCP 25) says that "IETF developed technologies 
> should not add
> insecurity to the environment in which they run." The IESG 
> has enforced
> this in the past and it seems especially pertinent to a 
> working group in
> the Security Area. I doubt that the IESG or the Security ADs 
> will accept
> this work item in our charter unless we can argue convincingly that we
> can develop something that would not add insecurity to the environment
> in which it is run. I don't think we're there yet.
> 
> -Steve
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 5 Sep 2001 10:19:13 -0700

Bob,

> I wasn't suggesting that logos should be restricted to 
> end-entities, I was only pointing out that such a restriction 
> would immediately make the issue of name subordination and 
> misuse of the logo by some intermediate CA go away.

I didn't understand the problem. If you have bad intermediate CAs you have
rather more problems than just bad logos!

> I can see some significant marketing value in supporting an 
> AUTHENTICATED use of a logo in an end-entity certificate, for 
> example to convey a professional license or association 
> membership in the case of an individual, and accredited 
> membership in a trade or merchant association, such as a Visa brand.

Which is my interest. The fact that a logo must be authenticated is not a
problem if the market will bear the cost. I believe that customers would be
very pleased to pay an additional fee for an enhanced certificate.

> I also like your suggestion of a URL and a message digest, 
> rather than attempting to transport the entire logo itself 
> within the certificate. Both the retrieval and display of the 
> logo could then be optional, and the logo could be cached 
> within the browsers, etc. Although you didn't raise the point 
> regarding the use by visually handicapped users, I was 
> particularly impressed by the original reference to Scalable 
> Vector Graphics, and to the potential use of alternate forms 
> of identification, ranging from a audible logo (spoken, a 
> commercial jingle, or whatever) to a braille pattern. 

I don't see that disabilities issue is relevant. We are talking about an
additional feature, not the sole feature. Browsers for disabled users
already have to deal with the security issue. Logos would not make that
problem any harder. It is already possible to put the DN into Braille.

The spoken logo is more interesting because voice based applications are
increasing. The problem of distinguishing authenticated voice from
unauthenticated is considerably worse however.

> Of course it would be nice to have a solid indication of 
> interest from the client software vendors to address the "if 
> we build it will they come" question, but the absence of such 
> a commitment certainly hasn't stopped us in the past, and it 
> seems quite unlikely that we could ever obtain such a 
> commitment when we are still debating the charter, and 
> haven't begun to work on an RFC yet. 

Absolutely, I just thought I would add in my one legitimate concern.

The concerns raised seemed to be mainly legal quibbles from non-lawyers. I
asked our lawyers and got a pretty enthusiastic response to the idea in
principle but as with the policy document they believe lawyers should be
involved in the drafting of the document. The idea of a legal considerations
section was well received.

> I don't mean to ignore or reject the valid concerns that have 
> been expressed, but I do believe that sufficient technical 
> progress has been made even in this limited dialogue to 
> conclude that this is a valid work item, and one that has a 
> least a reasonable chance of success.

I agree.

		Phill

---

From: "Yuriy Dzambasow" <[email-masked]>
Date: Wed, 5 Sep 2001 16:31:23 -0400

I too agree that logotypes can help foster deployment of certificates to the
broader consumer community.  Consider how merchants use the Visa, MC, and
AMEX logos to denote which credit cards they accept.  Consumers then look
into their wallets and pull out the appropriate credit card (using the logo
as an identifier) based on what the merchant will accept.  Of course, the
merchant still processes the credit card to ensure it is still valid, and
does not solely rely on the logo on the card.  The same approach can be
taken with consumers trying to gain access to services at merchant web
sites.  Therefore, I think it would be helpful to define a standard way of
representing logos in certificates.

Yuriy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Al Arsenault
Sent: Thursday, August 30, 2001 4:43 PM
To: Steve Hanna
Cc: Stephen Kent; [email-masked]
Subject: RE: charter revisions

I agree with Russ here.  The issues involved with logos, while difficult,
are not insurmountable.  They do serve a useful purpose in some
environments, and a standard way of including them will be much better than
letting every CA invents its own.

I believe that the logo work should be in the PKIX charter.

                Al Arsenault
                Chief Security Architect
                Diversinet

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Housley, Russ
Sent: Thursday, August 30, 2001 1:33 PM
To: Steve Hanna
Cc: Stephen Kent; [email-masked]
Subject: Re: charter revisions

Steve Hanna:

>I haven't seen any comments on the revised charter yet. Most of it looks
>good to me. However, I don't think PKIX should do any work on the

You and I agree on most things, but we have a major disagreement here.  I
do not think that we will see widespread deployment of certificates without
logos.  One measure of success will be the number of certificates that
average Internet user have.  Hopefully every Internet user will have at
least one.  I suspect that as we become successful, these logos will be the
tag by which users select a certificate.

I do not want to see more than one way that logos can be put into
certificates.  That is the most important reason for PKIX to be involved in
the definition.  You seem to agree that the market has a demand for
logos.  Letting each vendor devise an independent way to meet this
marketing requirement would be very bad for all implementors.

Anyway, we should not have the complete technical debate on a threat about
the charter.  I strongly encourage the PKIX working group to include this
area in the charter sent forward to the Area Directors for approval.  Once
the revised charter is approved, we can have the technical debate and sort
out the details.

Russ