Subject: Re: charter revisions

From: Steve Hanna <[email-masked]>
Date: Tue, 04 Sep 2001 11:58:38 -0400

Stephen Kent wrote:
> Just as a CA may employ various means to verify a subject's claim to
> a name, a CA can employ analogous means to verify a subject's claim
> to a logotype.  In fact, this may be relatively easy to verify if the
> logo is a registered trademark (something a CA could require via its
> CPS).

As Michael Ströder pointed out, this may not be easy for CAs. Requiring
that a logo be a registered trademark doesn't mean that there won't be
conflicts. A particular logo can be trademarked by different parties in
different countries. In fact, it can sometimes be trademarked by
different parties in the same country if there is little likelihood of
confusion (as when the goods identified are very different). And it may
be difficult for a CA to judge whether a particular image matches a
registered trademark. Verifying someone's right to use a DNS name or
email address is much easier.

Do we know of any CAs that want to include logotypes in certificates
that they issue, plan to verify those logotypes, and would be willing to
provide some sort of assurances to back that up in their CPS's?

If not, I will claim that including logotypes in certificates will have
a negative effect on security. Some CAs will be glad to charge extra to
include a logotype, but if the CA does not verify the logotype and
disclaims all responsibility for the correctness of the logotype, then
what's the point? The user will be misled into believing that the
logotypes have some security significance.

Certainly, CAs are welcome to include anything they want in their
certificates. But we should not provide a PKIX blessing unless there is
some security benefit.

> >Second, there's no equivalent to name constraints for use in cross
> >certificates. If I cross certify someone, I just have to trust that they
> >(and anyone they certify) will only put proper logotypes into
> >certificates.
> 
> This has been my greatest concern as well, and I'd like to see a
> better proposal on how to better control use of the extension.
> Stefan rejected some approaches, and provided rationales for the
> rejections, but that doesn't mean that we have to live with the
> current proposal if the WG finds the inherent security problematic.

Since the logotypes are to be used to identify issuers and subjects,
I think we must develop a solution to this problem. Otherwise, a
cross-certificate represents complete trust in the subject to
certify anyone.

> >Third, an apparently innocuous logotype can change appearance radically
> >when scaled to a smaller size or mapped to a different number of colors.
> >This can be exploited to deceive cell phone users into thinking that
> >they're communicating with their bank, for instance.
> 
> I had not considered this issue. we should explore ways that this
> problem might be avoided. presumably anyone displaying a logo on a
> web page has a similar concern, so maybe there are viable means to
> address this issue.

The problem with displaying a logo on a web page is different (unless I
didn't understand you). With a logo in a certificate, we want to make
sure that the person requesting the certificate doesn't trademark a
bogus logo and get it included in their certificate just so they can
trick a user who sees a scaled-down version of the logo into believing
it's a trusted logo. The closest analogy is getting a web server
certificate for paypa1.com (where the letter ell is actually a number
one). If you can get the user to click on an https://www.paypa1.com URL,
the user will think they are viewing a secure paypal website if the font
they use to view URLs displays ell and one the same way.

When viewing a logo on a web page, the user should not make decisions
about whose web page it is based on the logo. Instead, we have been
trying to convince them to look at the host name in the URL and check
that the padlock or key is lit up to indicate that an SSL connection is
in use.

> >Unless these concerns can be addressed, I do not think that this
> >proposal is safe and secure. And I do not think that the IETF should
> >publish an RFC on a fundamentally insecure idea, especially from a
> >security working group.
> 
> The attribute RFC has some problems too, in that bad choices of how
> to map an AC to a PKC can result in security failures, right?  So,
> the issue is not whether there are insecure ways to make use of the
> extension, but whether there are ways to make its use secure and
> whether, on the balance, we think appropriate use of the extension
> is beneficial, from a security (not marketing) perspective.

Agreed. If we believe that IETF standardization of this extension will
be beneficial from a security perspective, then we should go ahead with
it. Otherwise, we should not. I remain unconvinced.

-Steve

P.S. Note that I have no personal advantage (and, as far as I know, my
employer has no corporate advantage) to gain by the adoption or failure
of this particular proposal. My views are my own and don't represent the
views of Sun Microsystems. I just want to see the working group spend
its energies on worthwhile projects.

---

From: Steve Hanna <[email-masked]>
Date: Tue, 04 Sep 2001 11:58:57 -0400

Russ Housley wrote:
> 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.

This is an interesting argument. I think you're saying that the user
will find the logo useful when deciding which of his certificates to
use (such as when signing an email or performing client authentication
over SSL). If this were the primary use of logotypes in certificates,
then the risks of displaying an invalid logo would be considerably
reduced (the user might select the wrong one of his certificates to
authenticate with). However, the current logotype Internet Draft does
not describe this use case. All of the use cases described in section
1.1 of that document have the user looking at a logo to decide
whether a certificate presented by some other party is trustworthy.
In those cases, the risks of making an error are much greater.

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.

> 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.

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!

> Anyway, we should not have the complete technical debate on a
> threat about the charter.

Certainly, we don't need to have the complete technical debate at
this point. But there should be some requirement that work items
be feasible and provide some security benefit before they are
accepted by this working group. Otherwise, we will waste our time
(and confuse the public) by accepting all sort of ideas and then
having to throw them out.

-Steve

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 04 Sep 2001 18:51:13 +0200

Steve,

This is a very late answer, but I took some more vacations. :-)

During the London meeting I presented some preliminary work about an
INFORMATIONAL RFC on PKI Disaster Planning and Recovery and I realized that
this is not included in the new charter.

I would think that the following time table could be appropriate:

 3/04  PKI Disaster Planning and Recovery. INFORMATIONAL RFC.

Would it still be possible to add it to the list ?

I also found that 3/02 for DPV/DPD Protocols RFCs, may be a little bit
optimistic. 3/04 would probably be more appropriate.

Regards,

Denis

> 
> Folks,
> 
> We were pinged about the need to update the PKIX WG charter, both during
> the meeting in London, and via a message the chairs received from the IETF
> Secretariat. So, here is a proposed revision to the charter that Tim and I
> have developed.  Please review it and provide comments by 8/28, so that we
> can post the revised charter by the end of the momth.
> 
> Thanks,
> 
> Steve
> -------
> 
> Description of Working Group:
> 
> The PKIX Working Group was established in the Fall of 1995 with the intent
> of developing Internet standards needed to support an X.509-based PKI. The
> scope of PKIX work has expanded beyond this initial goal. PKIX not only
> profiles ITU PKI standards, but also develops new standards apropos to the
> use of X.509-based PKIs in the Internet.
> 
> PKIX has produced several informational and standards track documents in
> support of the original and revised scope of the WG. The first of these
> standards, RFC 2459, profiled X.509 version 3 certificates and version 2
> CRLs for use in the Internet. Profiles for the use of LDAP v2 for
> certificate and CRL storage (RFC 2587), the Internet X.509 Public Key
> Infrastructure Qualified Certificates Profile (RFC 2875), and the Internet
> X.509 Public Key Infrastructure Certificate Policy and certification
> Practices Framework (RFC 2527 - Informational) are in line with the
> initial scope.
> 
> The Certificate Management Protocol (CMP) (RFC 2510), the Online
> Certificate Status Protocol (OCSP) (RFC 2560), Certificate Management
> Request Format (CRMF) (RFC 2511),  Certificate Management Messages over
> CMS (RFC 2797),  Internet X.509 Public Key Infrastructure Time Stamp
> Protocols (RFC xxxx), and the use of FTP and HTTP for transport of PKI
> operations (RFC 2585) are representative of the expanded scope of PKIX, as
> these are new protocols developed in the working group, not profiles of
> ITU PKI standards.
> 
> A roadmap, providing a guide to the growing set of PKIX document, also has
> been developed as an informational RFC.
> 
> Ongoing PKIX Work items
> 
> An ongoing PKIX task is the progression of existing, standards track RFCs
> from PROPOSED to DRAFT. Also, to the extent that PKIX work relates to
> protocols from other areas, e.g., LDAP, it is necessary to track the
> evolution of the other protocols and produce updated RFCs. For example,
> the LDAP v2 documents from PKIX are evolving to address LDAP v3.
> 
> New Work items for PKIX
> 
> - production of a requirements RFC for delegated path discovery and path
> validation protocols (DPD/DPV) and subsequent production of RFCs for
> protocols that satisfy the requirements
> 
> - development of an RFC for a logotype extension for certificates
> 
> - development of a proxy certificate extension and associated processing
> rules
> 
> Not all of these items may become standards track RFCs. Some may become
> INFORMATIONAL or EXPERIMENTAL RFCs.
> 
> Goals and Milestones:
> 
> Done         PROPOSED Standard RFCs for public key and attribute
> certificate profiles, CMP, OCSP, CMC, CRMF, TSP, Qualified Certificates,
> LDAP v2 schema, use of FTP/HTTP, Diffie-Hellman POP
> Done            INFORMATIONAL RFCs for X.509 PKI policies and practices,
> use of KEA
> Done         Experimental RFC for Data Validation and Certification Server
> Protocols
> 8/01             Production of revised certificate and CRL syntax and
> processing RFC (son-of-2459)
> 10/01          Progression of CRMF, CMP, and CMP Transport to DRAFT
> Standard
> 12/01              Production of revised CMC RFCs (updates and split of
> CMC into several parts)
> 12/ 01              DPD/DVP Requirements RFC
> 12/01           Progression of OCSP to DRAFT Standard
> 3/02               DPV/DPD Protocols RFCs
> 3/02              Logotype Extension RFC
> 3/02              Proxy Certificate RFC
> 7/02               Progression of CMC RFCs to DRAFT Standard

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 04 Sep 2001 18:55:14 +0200

Steve,

I have much sympathy with your position. During the London meeting 
I expressed reservations (not to say more) about this idea.

I have a major problem with the wording below:

"Not all of these items may become standards track RFCs. Some may become
INFORMATIONAL or EXPERIMENTAL RFCs."

It implicity means that the document will either become a STANDARD, an
INFORMATIONAL or an EXPERIMENTAL RFCs, while the logo type document could
never turn out into an RFC at all, because several member of the WG have
expressed reservations. 

ISO has the concept of a "study period" where ideas can be debated before a
NWI is placed on the menu. We don't have officially this equivalent.
However, in that case, it would be wise to adopt a similar approach: 
it seems too early to include the logo type proposal on the charter, at
least using the current wording mentionned above.

However, it also seems difficult to refuse any discussion on that topic,
even if, for some of us, it will be a waste of our time to argue on the
advantages and disadvantages of the proposal. 

So I propose the following compromise: to allow for the discussion on that
topic on the mailing list, without for the time being any commitment from
the WG that the proposal will ever become a STANDARD, an INFORMATIONAL or an
EXPERIMENTAL RFC.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Sep 2001 13:22:52 -0400

>email address is much easier.

The same name may be used for products or by organizations in 
different "areas" if there is a belief that no confusion will result. 
However, a trademark, in its graphic form, is also a copyrighted 
image and as such is subject to a different set of legal rules that 
generally prohibit outright duplication. The legal challenges arise 
when two logos seem too similar to one another, in the eyes of one of 
the logo holders, and this is when courts step in and adjudicate the 
dispute. Nonetheless, this discussion does not argue against the 
ability of a CA to make a judgement about the legitimacy of a 
subject's claim to the right to use a trademarked logo. Perahps the 
point you're making above is that logos may not be as uniquely 
helpful in identifying an organization because of the possibility of 
similar logos being used by entities in different areas. That's a 
fair critique, but in a different dimension.

>provide some sort of assurances to back that up in their CPS's?

Stefan represents one such CA service provider.

>logotypes have some security significance.

PKIX has long adopted the position that a CA should not include data 
in certs that the CA does not verify, even though this is not a 
universally agreed upon position.  The same philosophy could apply 
here.

>certificates. But we should not provide a PKIX blessing unless there is

See comments immediately above.

>cross-certificate represents complete trust in the subject to

I would prefer to find a way to impose some form of constraint on the 
appearance of logos analogous to what we do in cross certs for names 
or policies.  because a logo is not structured, the name constraints 
mechanism can never be used in so precise a fashion, even if we 
choose to put a logo in some name form. but, it would be nice to have 
a way to prevent a CA further down a cross-cert chain from 
introducing a logo if one wants to prevent such action. Just because 
we don't have a mechanism to do this yet doesn't mean we can't work 
toward one.

>that the padlock or key is lit up to indicate that an SSL connection is

The reality is that logos on web pages are designed to inspire 
confidence in users based on visiting the web page, period. Yes, 
someone can put up a similar logo to try to fool people, or even put 
up the valid logo without the permission of the logo owner. We rely 
on the legal system to detect and remedy these problems, ex post 
facto.  That's not as good as preventing them, but many folks argue 
that it is better than not offering a logo-based marking facility. 
When it comes to putting logos in certs, we have a better mechanism 
in many cases, since the binding is secured and there are fewer CAs 
than there are web sites.

>its energies on worthwhile projects.

Same here.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Sep 2001 13:24:45 -0400

>this is not included in the new charter.

Good point. We can include this topic if others support it's inclusion.

>  3/04  PKI Disaster Planning and Recovery. INFORMATIONAL RFC.

OK, pending resolution of the above comment.

>Would it still be possible to add it to the list ?

Yes.

>optimistic. 3/04 would probably be more appropriate.

OK, I'll make that change.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Sep 2001 13:28:09 -0400

>the WG that the proposal will ever become a STANDARD, an INFORMATIONAL or an

I know that I was not the "Steve" to whom the message was addressed, 
but since Tim and I drafted the revised charter I will reply anyway.

We could reword the charter to not require that the new work items 
yield an RFC, i.e., one of more of the proposed items may fail to 
make it as an RFC. However, because publication as an Informational 
RFC is generally an easy thing to do, absent a strong negative 
reactions by a WG, I think it likely that all of the items cited have 
a very good opportunity to become RFCs in one of the 3 forms noted.

Steve

---

From: Steve Hanna <[email-masked]>
Date: Tue, 04 Sep 2001 16:00:12 -0400

Stephen Kent wrote:
> However, a trademark, in its graphic form, is also a copyrighted image
> and as such is subject to a different set of legal rules that
> point you're making above is that logos may not be as uniquely helpful
> in identifying an organization because of the possibility of similar
> logos being used by entities in different areas. That's a fair
> critique, but in a different dimension.

I don't think copyright would help much if two companies had trademarks
in different countries for a logo that looks like a red circle. But
IANAL, so I will abandon that line of argument. Maybe the international
copyright and trademark system is strong enough to ensure that the same
logo cannot be registered by two different entities in different
countries, even if one of those entities is a sham operated by criminals
for the purpose of impersonating the other.

You do make a good point that two logos different enough to be legally
distinct may not be distinguishable to the average user. It's also true
that users may not remember the logo associated with a particular
company. Visa, yes. But maybe not Schwab.

> Stefan represents one such CA service provider.

Really? I haven't heard Stefan say anything about how AddTrust would
verify logotypes or what assurances his company would provide in this
regard. Maybe he told you this in private conversation.

> I would prefer to find a way to impose some form of constraint on
> the appearance of logos analogous to what we do in cross certs for names
> mechanism can never be used in so precise a fashion, even if we choose
> to put a logo in some name form. but, it would be nice to have a way
> to prevent a CA further down a cross-cert chain from introducing a
> logo if one wants to prevent such action. Just because we don't have a
> mechanism to do this yet doesn't mean we can't work toward one.

This would mean that all existing cross-certificates would allow
logotypes in certificates. It might be better to say that certificate
containing a logotype should not be validated (or, at least, the
logotype should be ignored) unless all preceding certificates in the
path have an extension that says logotypes are allowed.

> up the valid logo without the permission of the logo owner. We rely on
> the legal system to detect and remedy these problems, ex post facto.
> That's not as good as preventing them, but many folks argue that it is
> better than not offering a logo-based marking facility.  When it comes
> to putting logos in certs, we have a better mechanism in many cases,
> since the binding is secured and there are fewer CAs than there are
> web sites.

Just seeing a logo on a web page doesn't inspire much confidence in me.
Yes, the logo owner will probably pursue those who misuse the logo. But
the Internet is a rough place. The miscreants may skip town with no
forwarding address and I (the user) will be very sad if I gave them my
brokerage account password and they emptied the account.

That's why we have HTTPS. The end user notices that the padlock or key
is lit up and decides that the host name in the URL is OK, so they enter
their brokerage account password. If we change this so that the user is
deciding that a *logo* is OK, I want to make sure the binding between
the logotype and the public key is secure and that the logotype that
appears in the certificate is properly displayed to the user.

But this is completely pedantic. The original issue was that a logo can
change appearance when it's scaled or mapped to different colors. A pink
circle is different from a green circle for trademark and copyright
purposes. But how do you distinguish them when they're displayed on a
black and white screen? I don't think that web page technology has any
magic bullets in this area. And what about blind users? With URLs, they
can have their screen-reader read the URL back to them. Graphics will be
completely inaccessible.

-Steve

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 4 Sep 2001 14:11:23 -0700

>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.

>explaining the one true way to do it. We are in the Security area,

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.

At 10:34 AM -0700 9/4/01, Michael Myers wrote:
>I agree with Stephen Farrell and Steve Hanna that logotypes are out of
>scope.

They are out of scope; the discussion is whether to add them to the scope.

>   These needs are better addressed by other forums.

Such as...?

>   Let's focus the
>WG's remaining energy on resolving DPV/DPD issues.

The current charter has much more than that already. The "focus" on 
DPV/DPD is already so fuzzy that it is probably just wishful to hope 
for much more.

--Paul Hoffman, Director
--Internet Mail Consortium

---

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

> >   These needs are better addressed by other forums.

Such as whomever chooses to stand up the responsibility, or is PKIX going to
go on forever ratifying extension X, protocol Y and policy Z?  This role
does not strike me as an engineering activity.  Hence my recent advocacy.

To the extent these issues remain relevant to the IETF and its governing
bodies, perhaps those superior organizations may wish to consider their
role.  In *that* regard, IANA's classic role comes to mind but since so much
of what PKI is and does to an enterprise is intrinsically bound up in
enterprise security policy (as it should be), it's not clear to me that an
IANA-like organization is the  best path forward.

Perhaps, Paul, given your exposure IETF/IESG/IAB organizational issues, you
could propose something?

I fear I've stirred the fire more than I should have.

Mike

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 4 Sep 2001 16:51:45 -0700

At 4:44 PM -0700 9/4/01, Michael Myers wrote:
>go on forever ratifying extension X, protocol Y and policy Z?

History say "the latter".

>   This role
>does not strike me as an engineering activity.

Fully agree. Oh, well.

>IANA-like organization is the  best path forward.

IANA is not a body that should pass security standards.

>Perhaps, Paul, given your exposure IETF/IESG/IAB organizational issues, you

I did: I supported putting it in the PKIX WG charter. Seeing some 
vendor interest, and seeing the PKIX WG does a fair job at putting 
out protocols without gaping security holes, and not seeing any other 
reputable (or even half-reputable) organization stepping up, I don't 
see why it should not be done here. Charter creep is pretty common in 
the IETF security area, yes? Should we not fully embrace that?

>I fear I've stirred the fire more than I should have.

Spoken like a true Californian at the end of a long, dry summer.

--Paul Hoffman, Director

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 05 Sep 2001 09:15:54 +0200

Steve,

(deleted text)

> OK, I'll make that change.

With the writing of dates in the reverse way between my country and yours, 
I got confused. I was thinking that April 2002 would be reasonable, not 
for the RFC being published (by experience we know that it takes months 
between an IETF last call being passed and an RFC publication), but for 
a WG last call.

So if we assume WG Last call in April 2002 and IETF last call in June 2002,
then we add 6 months for publication and this makes December 2002 (12/02, 
I presume) for a possible publication.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Sep 2001 09:57:05 -0400

>optimistic. 3/04 would probably be more appropriate.

I think it would be appropriate, as an informational RFC, analogous 
to the PKI P&P RFC.

Comments from others?

Steve

---

From: Steve Hanna <[email-masked]>
Date: Wed, 05 Sep 2001 10:18:39 -0400

> 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.

> 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:
> >I agree with Stephen Farrell and Steve Hanna that logotypes are
> >out of 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: Stephen Kent <[email-masked]>
Date: Wed, 5 Sep 2001 10:32:56 -0400

>for the purpose of impersonating the other.

I hate to beat a dead horse, but ...  Consider the current problem 
for a CA that is asked to issue a cert to Company X, with a DN 
selected by that company. There is not a central registry for DNs 
where the CA can check to verify that the company in question is 
entitled to use the DN it proposes. Certainly this is true if the 
U.S. So, since CAs regularly make value judgements about 
appropriateness of DNs given imperfect inputs, I don't see the logo 
"verification" as something fundamentally different and harder. 
(Gee, for someone who has not been a big supporter of this I seem to 
spend an awful lot of time defending it ...  Stefan, where are you?)

>company. Visa, yes. But maybe not Schwab.

Yep. And if we adopt a logo extension, I would expect to see this as 
part of the security considerations section.

>regard. Maybe he told you this in private conversation.

Stefan certainly has indicated that his interest in pursuing this was 
motivated by his perception of a market need, based on his experience 
as CTO for AddTrust. I inferred that AddTrust would make use of this 
facility if it were available.

>path have an extension that says logotypes are allowed.

I didn't mean to suggest details of solution at this point; I just 
wanted to express what I thought was a good requirement. To be 
analogous to what we can do with policy mapping and inhibition of 
policy mapping and with name constraints, it might sufficient if a CA 
could preclude inclusion of a logo extension in any subsequent cert 
in a path.

>brokerage account password and they emptied the account.

You and I probably are not the folks for whom the logo extension 
would be of great value.

>appears in the certificate is properly displayed to the user.

Agreed.

>can have their screen-reader read the URL back to them. Graphics will be

Good points about the limitations of a logo.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Sep 2001 10:47:58 -0400

>I presume) for a possible publication.

OK.

Steve

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 5 Sep 2001 13:16:46 -0700

>seem likely that such a mechanism could be developed.

I don't think that name constraints works well against spelling 
errors or the kinds of names I specified above. I agree that it will 
probably be impossible to constrain logotypes any more than it is to 
constrain the value within CN.

>a textual name

That is not a security risk, and it is a supposition.

>  and logotypes may change appearance radically on
>different devices.

More radically than the way a UTF-8 name with non-ASCII characters 
will be displayed?

>  Several other risks have been pointed out in the
>logotype from another,

Ditto for names ("Type 1" vs. "Type 3", similar-looking glyphs in 
various fonts)

>  users may not recall which logotype corresponds
>to which entity,

Ditto for names

>  and logotypes are not accessible to vision-impaired

This is indeed an issue.

>sign that the objections raised so far can be overcome.

Then that should come up when discussing the protocols, not the charter.

>in which it is run. I don't think we're there yet.

Trying to predict what the IESG will do is just plain silly (even 
individual IESG members are bad at this).

--Paul Hoffman, Director

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 05 Sep 2001 17:17:09 -0400

Paul Hoffman / IMC wrote:
> >Paul Hoffman / IMC wrote

The distinction is that name constraints is a mechanism; there is no
analogous mechanism for logotypes.  If you have name constraint with
a permitted subtree under "FooCA Type 1", then your browser will reject
all certificates under "FooCA Type 2" regardless of whether the "2" is
an innocent spelling error or a malicious spoof attempt.  What makes
you believe that name constraints don't work well (i.e. that the rejection
of "2" is an undesired outcome)?

> individual IESG members are bad at this).

There is a distinction between what BCP 25 says in black and white,
and attempting to predict how the IESG will interpret BCP 25 when
considering a new work item.   Rather than wasting bandwidth calling
prediction "silly", you should argue substantively about why logotypes
do not add insecurity to the environment in which they run.

I'm agnostic on the actual issue - logotypes in certificates are
both seductive and dangerous.  The potential harm from user
confusion will outweigh the cuteness factor in some circumstances
(promiscuous trust lists) and will not in others (trustworthy CAs who
attempt to make logos meaningful, distinct, and few).  What should
PKIX do about it?  I don't know.

---

From: Steve Hanna <[email-masked]>
Date: Wed, 05 Sep 2001 17:35:34 -0400

> That is not a security risk, and it is a supposition.

The risk is that it may be quite easy for a certificate requester to get
an invalid logotype certified. However, this is a supposition, as you
say. We have heard the CA vendors say "Trust us, we can handle it." And
maybe they can. But I, for one, would be much more comfortable if
logotypes were ignored unless all certificates in the path indicate that
they should be supported. This shouldn't be a problem for those who
think that cross-certification is a bad idea.

> More radically than the way a UTF-8 name with non-ASCII characters

Maybe not, especially when part of the UTF-8 name cannot be rendered
properly on the user's device (because it includes characters that
aren't present in any font on that device, for instance). We should
probably consider adding text to some future successor to 2459 warning
about this case. Maybe we can provide similar text warning that
logotypes in certificates should not be scaled or mapped to different
colors before display. If this requirement cannot be met, the
certificate should be treated as if it did not contain the logotype.

> Ditto for names ("Type 1" vs. "Type 3", similar-looking glyphs in

Users who aren't concerned about security will always just click OK (or
enter their brokerage info at a web site without considering whether
this is secure). It's hard to provide much protection for such users
(although putting logotypes in certificates will make it harder for
programs that try to be smart about what's safe).

But we should try to avoid designing in features that nobody can use
securely. The current system allows a careful user with a properly
configured system to type a URL and have the browser check that the host
name matches the certificate or examine a name in a signed email and
decide whether it is the one desired (ignoring poor fonts, misspellings,
etc). Certifying and examining a logotype is a much more fuzzy process,
open to many more errors.

> Then that should come up when discussing the protocols, not the

But we have a proposal on the table for how to include logotypes in
certificates and the proposal is demonstrably flawed (although this is
subject to some debate). Nobody has been able to come up with any way to
fix it. My conclusion is that it can't be fixed. Shouldn't the question
of whether the work item is feasible be relevant to a discussion of
whether it should be added to the charter?

> individual IESG members are bad at this).

You're probably right. I suggest that our working group chairs make a
decision about whether they still want to include this work item in the
proposed charter. If they want to do so, I would ask that they inform
the Security ADs that the working group did not reach consensus on this
question and point the Security ADs to the discussion here on the list
so that they can make up their own mind. I believe that all of the
relevant arguments in favor and opposed have been raised.

Thanks,

Steve

---

From: Michael Ströder <[email-masked]>
Date: Fri, 07 Sep 2001 20:03:40 +0200

Stephen Kent wrote:
> 
> There is not a central registry for DNs

Hmm, do you really want to argue based on these practices?
Now guess how serious I'll take this argument...

> Good points about the limitations of a logo.

+1

I don't believe that the displaying problems can be solved.

Ciao, Michael.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 08 Sep 2001 10:29:40 +0200

> I don't believe that the displaying problems can be solved.

I am not that convinced, at least the SVG format seem to aim to deal
with the problems above:

http://www.w3.org/TR/SVG-access/

I don't think this is a new problem that only exists for PKIX.  Logos
are already often distorted in the real world: Black and white news
papers, low resolution screens, etc.  It's not impossible to fake
logos outside the PKIX world, and people seem to cope.

Not to say that the problems of cross-certifying etc aren't real, but
I don't think they are impossible to solve.

---

From: Stephen Kent <[email-masked]>
Date: Sun, 9 Sep 2001 19:42:04 -0400

>Now guess how serious I'll take this argument...

OK, you're on. In the U.S. try to find a definitive database that 
will allow a CA to verify an organization's claim to use a DN. On the 
other hand, the U.S.  Patent and Trademark Office (PTO) has a web 
site listing all names in the U.S. to which trademarks have been 
issued.

Your turn ...

>I don't believe that the displaying problems can be solved.

Your belief is not a basis for making this sort of decision. 
Translated to a less self-centric statement, it becomes a hard 
statement to prove.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 24 Sep 2001 11:46:34 +0200

Steve,

There has been a lot of discussions regarding logos and as reply to the 
whole discussion I would like to debate some of your original issues 
concerning logos.

First as a general remark:

Some say that logos are not a security issue and should not be handled in PKIX.

The security issue is indirect but very real. We are dealing with an 
infrastructure for public key recognition. (i.e. who is the owner of this 
key or what is the right key for XX). The user of this infrastructure is 
devices, applications and humans, where humans is the worst kind.

Humans are unpredictable, has bad memory, acts irresponsibly and has low 
calculation capacity. In other words - they need help.
Providing help to humans, in a human way, IS a real security issue. 
Providing bad human interfaces is BAD security.

The simple rule is:
Human recognition of text based names is bad.
Human recognition of visual symbols and visual concepts is good.

This is why we use logotypes and symbols in all possible situations and 
applications in the world where we have a human user.

The common objection is uncertainties of the trustworthiness of logotypes, 
i.e how we can assure what logotype is legitimate for what entity.

This is in fact an issue which goes far beyond PKIX and where PKIX should 
NOT try to provide solutions as little as PKIX try to make standards for 
policies and legal aspects of names and any other attributes. As 
representing a commercial CA service, I see this as the least problem right 
now. If there is a will, there is a way.

But the protocol aspect of logos is a PKIX issue. I.e. how to include them, 
formats and parsing issues together with its relationship with path 
processing and means of specifying policy aspects.

More comments follow in line;

At 17:00 2001-08-29 -0400, Steve Hanna wrote:

>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.
>
>First, CAs will find it very hard to verify whether a particular
>logotype should be included in a particular certificate. They'll just
>need to certify whatever the client gives them and disclaim all
>responsibility for its accuracy. With textual names, at least they can
>make some attempt to verify that the name corresponds to the requesting
>client (by requiring a response from an email address before it's
>certified, for instance).

This is a legal issue that PKIX should move away from. There are many ways 
to tie a logotype to an organization, as there are with names. This is 
nothing new for certificates. The simplest way is to get a signed statement 
from the company tied to some penalty for giving false information. It is 
not fool proof but it may be good enough for many applications.

>(and anyone they certify) will only put proper logotypes into

Correct. If you cross certify a CA you will need to determine if you want 
to link trust to their way of issuing certificates.

>they're communicating with their bank, for instance.

This is an issue we need to discuss further. I have no answer to this but 
it is not a reason not to do the job.

>publish an RFC on a fundamentally insecure idea, especially from a

Following this reasoning we also need to cancel RFC 2459 and all derivative 
work as well. God knows what kind of un trusted information you can put 
into certificates to fool people if you want.

As I said. We need to remove the legal aspects from the PKIX agenda and 
focus on the protocol aspects, and make that aspect SECURE. As representing 
a commercial CA I guarantee that 1) there is a real need for this, 2) it 
will be implemented and 3) there are ways of being sure enough on the 
accuracy of logotypes.

>-Steve

/Stefan