Subject: Re: Verifying Certificates when CA key update

From: "Tom Gindin" <[email-masked]>
Date: Sun, 5 Aug 2001 23:22:21 -0400

I must not have been clear enough.  IMO the check which improves
security is that the issuer and subject names are equivalent.  Setting
these certificates to v1has independent value only if the RP knows that all
other certificates issued by this CA are v3, which cannot generally be the
case.  Good luck with your implementation.

          Tom Gindin

li yunfeng <[email-masked]> on 08/04/2001 03:34:56 AM

To:   Tom Gindin <[email-masked]>
cc:   [email-masked]
Subject:  Re: Verifying Certificates when CA key update

Thank Tom Gindin for answer me. I think if a attacker
can requre a cross certificate form a CA,then he can
spool as a CA.This is based on the opinion of RFC2510
that when CA update its own key for sign certificate,
it will publish the oldwithnwe ,newwithold,and
newwithnew certificate. If the CA publish the
oldwithold certificate at the same time we can prevent
the attacker's spooling. Because we can trust the
public key in oldwithold certificate not trust the
public key in oldwithnew certificate.
All in all thanks Tom Gindin for giving me these
insturct and i will implement the software as you
teach me that set the version of oldwithnew to v1.

 --- Tom Gindin <[email-masked]> 的正文：>
>
>      While I'm not sure what you mean by "chived"
> here (perhaps
> "spoofed"?), an OldWithNew certificate should be
> distinguishable from
> end-user certificates by several means.  First, the
> subject name and the
> issuer name should match each other.  Second, it
> should IMO be either a v1
> certificate or contain a CA flag in a basic
> constraints extension - I would
> prefer the latter but it would be wise to find out
> from the actual
> implementors which they're using.  The second check
> does not protect
> against an attack by the subject of a cross
> certificate, but the first
> does.
>      Do we need to add to point 1 of 2.4.2.2 (of
> rfc2510bis-04) at least
> the first of these checks?  If so, do we need to
> make the same change in
> 2.4.2.3?  I would think that we do, so thank you for
> bringing this up.
>
>           Tom Gindin
>
>
> li yunfeng <[email-masked]>@mail.imc.org on
> 08/02/2001 12:05:15 AM
>
> Sent by:  [email-masked]
>
>
> To:   [email-masked]
> cc:
> Subject:  Verifying Certificates when CA key update
>
>
>
> In the document "Inernet X.509 Public Key
> Infrastructure Certificate Management Protocols
> <draft-ietf-pkix-rfc2510bits-03.txt>" 2.4.2segment
> says that when CA key update the verifier can verify
> other person's certificate using OLDwhithNEW
> certificate.
> If we use this methord , we will be chived by other
> who get a certificate from CA and say this is old
> with
> new certificate.
>
>
_________________________________________________________
> Do You Yahoo!? 登录免费雅虎电邮!
> http://mail.yahoo.com.cn
> <font
color=#6666FF>无聊？郁闷？高兴？没理由？都来聊天吧！</font>――
> 雅虎全新聊天室!
> http://cn.chat.yahoo.com/c/roomlist.html
>
>

_________________________________________________________
Do You Yahoo!? 登录免费雅虎电邮! http://mail.yahoo.com.cn

<font color=#6666FF>无聊？郁闷？高兴？没理由？都来聊天吧！</font>――
雅虎全新聊天室! http://cn.chat.yahoo.com/c/roomlist.html

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 13 Aug 2001 11:08:19 +0200

Since logotypes in certificates now is an approved PKIX work item there are 
some practical aspects to deal with.

1) Logotype image size or scalable images.

We probably need to define a standard size for logotype images or find 
another way to define scalable logotypes in order to enhance homogeneous 
display of certificates.

The alternative is to allow scalable logotypes but I have been told that 
there are no easy and appropriate ways to do this.

2) Colour and B&W images.

Some clients, such as mobile phones does not have colour display and colour 
images may not work in B&W.
We probably need a convension that allows inclusion of 2 images for each 
logotype (colour and B&W).
Possible solotions are either a convension defined in the ASN.1 structure 
or just a file naming convension for the image files.

Any suggestions?

/Stefan

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 13 Aug 2001 16:29:35 +0200

Stefan Santesson <[email-masked]> writes:

> Since logotypes in certificates now is an approved PKIX work item
> there are some practical aspects to deal with.
>
> another way to define scalable logotypes in order to enhance
> homogeneous display of certificates.
>
> The alternative is to allow scalable logotypes but I have been told
> that there are no easy and appropriate ways to do this.
>
> Some clients, such as mobile phones does not have colour display and
> colour images may not work in B&W.
> We probably need a convension that allows inclusion of 2 images for
> each logotype (colour and B&W).
> Possible solotions are either a convension defined in the ASN.1
> structure or just a file naming convension for the image files.
>
> Any suggestions?

Did you consider W3C's Scalable Vector Graphics (SVG) format?  Two
resource pagees:

http://www.w3.org/Graphics/SVG/Overview.htm8

There is W3C note on accessibility features of SVG that apply to
constraint devices as well:

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

Abstract

Scalable Vector Graphics (SVG) offers a number of features to make
graphics on the Web more accessible than is currently possible, to a
wider group of users. Users who benefit include users with low vision,
color blind or blind users, and users of assistive technologies.  A
number of these SVG features can also increase usability of content
for many users without disabilities, such as users of personal digital
assistants, mobile phones or other non-traditional Web access devices.

Accessibility requires that the features offered by SVG are correctly
used and supported.  This Note describes the SVG features that support
accessibility and illustrates their use with examples.