Re: [pkix] Most credentials map 1:1 onto apps: [was: Are human readable images really all that important?]

[Stefan Santesson <[e-mail]>]

Stephen,

I will not go into detailed arguments with you but there are many things we
agree on. It sure would be ideal if the service you are accessing could
specify what credentials you should pick.

Unfortunately, modern security protocols only provide very simple selections
mechanisms. I once wrote a draft to discuss possible solutions to the
problem: http://tools.ietf.org/html/draft-santesson-credsel-01

>> Is it your opinion that no user ever have any reason to:
>> 
>> 1) See their certificate (e.g. to select one)
> Yes, my opinion is that this should be very rare.

So you agree that the use case exists (it's just very rare).


>> services. These points of single contact are to provide authenticated
>> services and signed information/documents (such as licenses and permits)
>> that are to be examined by citizens and service providers.
> Sorry, how does this relate to having multiple credentials to choose
> from for each app?

Nothing. It has to do with signature verification.


> Will the 
> publisher's logo displayed in the code signing certificate make all the
> difference to the user's decision to accept a download?

Maybe not a logo alone...

But yes, users have an interest;
- to know where the software comes from,
- to know who is providing the service they access,
- to know who signed the permit that grants them the right to conduct
business (EU services directive).

The certificate is the source of this information.

I believe users are naturally capable of understanding the concept of
credentials as it is analogous to the credentials of the physical world. We
just need to offer them a consistent user experience across applications and
platforms and I strongly believe the certificate image can provide an
important contribution.

/Stefan



On 09-12-13 3:05 AM, "Stephen Wilson" <[e-mail]> wrote:

> 
> 
> Stefan Santesson wrote:
>> Stephen,
>> 
>> Thanks for the analysis. I have some clarifying questions.
>> 
>> If we forget about "trust" as the primary driver for a moment.
> Actually, we should forget about "trust" as a driver for PKI for all
> time. The demonstrably best applications for digital certificates have
> nothing to do with "trust" but rather confirmation of a Subject's
> credentials.  The best PKI apps automate formal transactions between
> parties who already recognise one another's qualifications, as expressed
> in the certificates. Examples include medical practitioners, bankers and
> other professionals signing transactions, smartcards and SIM cards
> signing transactions, embedded security like Skype, DDA EMV cards and so
> on.  These apps are context rich.  There is rarely any question about
> the right credential to use when securing these transactions; almost
> always the app itself can invoke the right certificate.
> 
> As the old Italian proverb goes: "It's good to trust; but it's better
> not to".
> 
>> Is it your opinion that no user ever have any reason to:
>> 
>> 1) See their certificate (e.g. to select one)
> Yes, my opinion is that this should be very rare.  PKI-enabled
> applications should almost always be able to invoke the right
> certificate on behalf of the user.
> 
> I think that a typical human user needs to know as much about the
> contents of a digital certificate as they need to know about the
> magneto-resistive properties of the gamma ferrite formulation in the
> magnetic stripe on their credit card.
> 
> PKI technology will become ubiquitous when keys and certificates become
> as deeply embedded and as easy to use as magnetic stripes.  I think that
> the PKI industry is best served by programs and standards that foster
> embedded apps.  I think that initiatives that further the manual use of
> digital certificates, like including images in certs, are possibly
> misguided, because they perpetuate the 15 year old misconception that
> digital certificates are intended to be used by strangers Alice and Bob
> to determine if they can "trust" one another.
>> 2) See any information from it (e.g. Who it is issued to or what it is
>> supposed to be used for)
> This information is almost always highly context specific, even unique
> to the transaction.  For example, if I am signing a prescription, or an
> electronic conveyancing document, or a court order, or a purchase order,
> or a tax return, or an Amercian Express payment, then the software will
> know what certificate to use.  Therefore the certificate issuer etc. is
> redundant in terms of its meaning to the user.  If you already know what
> app you're using, the certificate is a given. Info like what the
> certificate is supposed to be used for is absolutely vital I agree, but
> mainly it's of interest to the receiver's computer which uses it to
> determine whether or not to accept the signature.
> 
>> 3) See the identity of an authenticated opponent (using a certificate as
>> source).
> If this is the case of strangers Alice and Bob exchanging e-mails and
> wondering who the other person really is, then I don't see that an image
> of anything is going to help.  If they are familiar with one another and
> they find a photo helpful as some sort of cue, well then I guess that's
> nice, but it just doesn't seem worthy to me of a whole lot of
> standardisation effort.
>> If this is yes in any situation, then what would you propose as the best
>> means to do it?
>> 
>> 
>> Here are some real use cases that could be useful to consider:
>> 
>> 1) Millions of certificates are used in public eGovernment in Europe. This
>> currently leads to situations where user's need to select a credential (They
>> may have several). First they need to select the type of credential and
>> secondly they need to select one out of a possible many of that type.
> Yes they may have several credentials, but for any given transaction, I
> think that the choice of appropriate credential usually reduces to one.
> This is why I think that Cardspace has yet to prove its worth.  The
> presumption that there is a largeish set of credentials to choose from
> _in_the_context_of_each_transaction_ seems to me to be excessive.
> 
> That is, I predict that in most cases, when you have an Inforcard
> Selector full of credentials and you initiate an application or
> transaction, the business logic will cause all Infocards bar one to be
> greyed out.
> 
> In the case of credit cards when we do often have a non-trivial choice
> (Visa/Amex/MC ...) of credentials for each transaction, I have to say
> that the keys and certificates really should be in chip cards and not
> floating around as soft credentials.  With real cards and hardware-based
> Infocards, then all but one Infocard will be greyed out, with just the
> card that's in the card reader being  highlighted and available to click
> on.
>> 2) In the implementation of the services directive in Europe, each country
>> is required to provide a point of single contact providing secure electronic
>> services. These points of single contact are to provide authenticated
>> services and signed information/documents (such as licenses and permits)
>> that are to be examined by citizens and service providers.
> Sorry, how does this relate to having multiple credentials to choose
> from for each app?
> 
> I should re-iterate, in case of confusion, that I am a very firm
> believer in having multiple credentials/certificates.  It's just that I
> think the choice of credential for each app is usually trivial.  The
> reason why we need multiple credentials is we engage in multiple apps.
>> 3) validation of signature and origin of software, software updates, patch
>> notes etc.
> Again, I am not sure how this relates to multiple credentials, much less
> the idea that an image in a credential will be of great help. Will the
> publisher's logo displayed in the code signing certificate make all the
> difference to the user's decision to accept a download?
> 
> 
> Cheers,
> 
> Stephen Wilson.
> 
>> 
>> /Stefan
>> 
>> 
>> On 09-12-11 4:31 AM, "Stephen Wilson" <[e-mail]> wrote:
>> 
>>> Sorry, I still don't get the point of images in certificates.
>>> 
>>> There seems to be two rationales:
>>> 
>>> (1) To give the RP more information with which to make a trust
>>> decision.  As I mentioned, I think stranger-to-stranger e-commerce and
>>> PKI was one of the greatest red herrings.  It got us into most of the
>>> mess we're still digging ourselves out of.  If Alice and Bob really are
>>> strangers, I don't see that an image of anything at all can help them
>>> over and above the text information in the cert.
>>> 
>>> (2) To give the Subject more information about their own certificates,
>>> to help them pick one.   Cardspace is proffered as an example.  On this
>>> score, I have to say Cardspace has yet to prove itself.  The
>>> fundamental, un-stated assumption behind Cardspace is that for a given
>>> transaction, in general, there will be more than one credential that can
>>> be used to authenticate the 'sender'.  And thus it makes sense to have
>>> an InfoCard selector.  But I actually think for the vast majority of
>>> e-commerce transactions, there is one and only one appropriate
>>> credential, and that choosing it is trivial.
>>> 
>>> For instance, my Acme Bank online banking app can pick my Acme bank
>>> account credential. My health records app can pick my health
>>> credential.  When I'm shopping on line, the merchant server can find and
>>> pick out my credit card credential.  OK, I'll grant you I have more than
>>> one credit card, but you don't really need an image to differentiate
>>> between "Visa" and "Amex".
>>> 
>>> The vast majority of successful PKI applications involve embedded
>>> certificates, selected automatically by machine, and verified
>>> automatically by machine.  Human readable images seem to me to be geared
>>> at fringe applications.
>>> 
>>> I guess there is no harm is developing an RFC for something that is
>>> academic ... except ... focusing on human readable images perpetuates
>>> the misunderstanding that certificates are for humans to read in the
>>> name of "trust".  So for "political" or "marketing" reasons, I think PKI
>>> proponents are better off distancing themselves from these sorts of use
>>> cases, and instead they should concentrate on the mechanised
>>> applications, like embedded certificates, chip devices, digtial
>>> credentials for professionals etc etc.
>>> 
>>> Cheers,
>>> 
>>> Steve.
>>> 
>>> Stephen Wilson
>>> Managing Director
>>> Lockstep Group
>>> 
>>> Phone [phone]
>>> 
>>> www.lockstep.com.au <http://www.lockstep.com.au>
>>> 
>>> 
>>> Lockstep Consulting provides independent specialist advice and analysis
>>> on digital identity and privacy.  Lockstep Technologies develops unique
>>> new smart ID solutions that enhance privacy and prevent identity theft.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Peter Gutmann wrote:
>>>> "D. K. Smetters" <[e-mail]> writes:
>>>> 
>>>>> I think there is at least some support for a:
>>>>> 
>>>>> Stoll, J., Tashman, C. S., Edwards, W., and Spafford, K. 2008. Sesame:
>>>>> informing user security decisions with system visualization. In Proceeding
>>>>> of
>>>>> the Twenty-Sixth Annual SIGCHI Conference on Human Factors in Computing
>>>>> Systems (Florence, Italy, April 05 - 10, 2008). CHI '08. ACM, New York,
>>>>> NY,
>>>>> 1045-1054. 
>>>> Hmm, I'm not sure if that's really too relevant for certimage though, a
>>>> better
>>>> one I think would be Petnames or the coloured URL bar from FF 2 and EV
>>>> certs.
>>>> OTOH these seem to demonstrate the bCanUseTheDamnThing effect, people look
>>>> for
>>>> the colour change and if it's there, everything's OK.  Looking at the
>>>> certimage examples, where are you going to put your large UI with its
>>>> multiple
>>>> lines of information?  What you'll get is just another conditioned
>>>> response,
>>>> UI appears -> bCanUseTheDamnThing = true, and it doesn't matter what the UI
>>>> actually contains.
>>>> 
>>>>> Smetters, D. K. ; Stewart, P. Breaking out of the browser to defend
>>>>> against
>>>>> phishing attacks. Fifth Conference on Email and Anti-Spam (CEAS 2008);
>>>>> 2008
>>>>> August 21-22; Mountain View, CA. (available here:
>>>>> 
http://www.parc.com/content/attachments/breaking_out_browser_6496_parc.pdf>>>>>
)
>>>> What site-specific browsers show is the use of creative thinking to work
>>>> around the failure of PKI to provide effective authentication.  This sort
>>>> of
>>>> thing is what I meant when I mentioned earlier that we should be looking at
>>>> new approaches rather than giving users more of what we already know
>>>> doesn't
>>>> work.  SSB's are probably the best defence against phishing that I know of
>>>> because they're based on established user interaction principles and not
>>>> security dogma.
>>>> 
>>>>> I do wonder about the fact that nobody starts these standardization
>>>>> processes
>>>>> by building toy systems and showing that they are useful, (user studies
>>>>> and
>>>>> all) before attempting to spin them up to the Wider World.
>>>> That system worked wonders for OSI, why should we change it now?  We
>>>> standardise, you implement (or, more frequently, we standardise, you
>>>> ignore).
>>>> 
>>>> Peter.
>>>> _______________________________________________
>>>> pkix mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>> 
>>>> 
>>> _______________________________________________
>>> pkix mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pkix
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix