Re: [certid] Bad certificate handling

["Jeffrey A. Williams" <[e-mail]>]

Matt and all,


-----Original Message-----
>From: Matt McCutchen <[e-mail]>
>Sent: Sep 26, 2010 10:21 AM
>To: [e-mail]
>Cc: [e-mail]
>Subject: Re: [certid] Bad certificate handling
>
>On Sat, 2010-09-25 at 02:22 +0200, Martin Rex wrote:
>> Section 5.1.4 here:
>> 
>>     http://www.w3.org/TR/wsc-ui/#selfsignedcerts
>> 
>> is much closer what I this would be useful and sensible.
>> 
>> "Pinning" of certs is useful for both, certs that validate fine
>> and certs that do not validate for the two reasons "not trusted"
>> and "server-id-mismatch".
>
>Once again
>(http://www.ietf.org/mail-archive/web/certid/current/msg00338.html), the
>purpose of pinning is to make it possible to connect to servers with
>unverifiable certificates, not to replace the public-CA trust model,
>which is much more difficult to do properly.  The definition of
>"strongly TLS-protected" (http://www.w3.org/TR/wsc-ui/#def-strong-tls)
>includes validated certificates regardless of whether there is a pinned
>certificate.
>
>> What is the idea behind visualizing the full chain?
>> 
>> I've seen the same in 5.1.4 of the WSC-UI document but there's
>> no rationale given and I can not think of one.  If the purpose is
>> memorizing and "pinning" a server cert, there is no point in
>> visualizing the certificate chain.
>> 
>> Either there is no trust, then the chain can be crafted to look
>> like anything,
>
>Not necessarily.  There are some CAs I don't want to enable
>unconditionally as trust anchors, but whose certificates I am willing to
>accept after additional manual verification.  In that case, I would
>check the fingerprint of the top certificate of the presented chain
>against the one I expect.  But you're right that "forcing the user to
>view the entire certification path" may have no real security benefit in
>general, though it sounds impressive.

  You have reiterated two problems here.  One which you refer to
indirectly is that in effect some, if not many CA's have issued
CERTS under questionable circumstances, or have had their CERT
database corrupted/hacked and the currently registered CERTS may
have been compermised in some way.  The second which in a way related
to the first, that being a requirement for the user to view the 
entire certification path, as that path may lead to at any point
a false positive.  Ergo, Self signing CERTS for me anyway given
that the 'Trust Anchors' are of questionable trustworthyness or
may come into such a status without the users prior knowledge
or awareness, is much more comfortable verification consideration,
but of course this my not always be the case.
>
>-- 
>Matt
>
>_______________________________________________
>certid mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/certid

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [e-mail]
Phone: [phone]