headers
li yunfeng | 2 Aug 2001 06:05
Picon
Favicon

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
Permalink | Reply | 0 comments |
headers
Tom Gindin | 2 Aug 2001 13:54
Picon
Favicon

Re: Verifying Certificates when CA key update


     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 <forward_li <at> yahoo.com.cn> <at> mail.imc.org on 08/02/2001 12:05:15 AM

Sent by:  owner-ietf-pkix <at> mail.imc.org

To:   ietf-pkix <at> imc.org
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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
li yunfeng | 4 Aug 2001 09:34
Picon
Favicon

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 <tgindin <at> us.ibm.com> 的正文：> 
> 
>      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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Gindin | 6 Aug 2001 05:22
Picon
Favicon

Re: Verifying Certificates when CA key update


     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 <forward_li <at> yahoo.com.cn> on 08/04/2001 03:34:56 AM

To:   Tom Gindin <tgindin <at> us.ibm.com>
cc:   ietf-pkix <at> imc.org
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 <tgindin <at> us.ibm.com> 的正文：>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hideyuki Odahara | 7 Aug 2001 07:23
Picon

draft-ietf-pkix-ac509prof-09 ASN.1 "IMPLICIT"


I've read the draft-ietf-pkix-ac509prof-09 and 
the draft-ietf-pkix-ac509prof-06.
And I found the difference about ASN.1 Notation.
It was "IMPLICIT".

draft-ietf-pkix-ac509prof-09 wrote:
------------------------------------
Appendix B: ASN.1 Module

 PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
              internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
              id-mod-attribute-cert(12)}

    DEFINITIONS IMPLICIT TAGS ::=
                ^^^^^^^^
    BEGIN

    -- EXPORTS ALL --
-------------------------------------

draft-ietf-pkix-ac509prof-06 wrote:
-------------------------------------
Appendix B: ASN.1 Module

 PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
              internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
              id-mod-attribute-cert(12)}

    DEFINITIONS EXPLICIT TAGS ::=
(Continue reading)

Permalink | Reply | 2 comments |
headers
Olivier DUBUISSON | 7 Aug 2001 11:09

Re: draft-ietf-pkix-ac509prof-09 ASN.1 "IMPLICIT"


Hideyuki Odahara wrote:
> 
> I've read the draft-ietf-pkix-ac509prof-09 and
> the draft-ietf-pkix-ac509prof-06.
> And I found the difference about ASN.1 Notation.
> It was "IMPLICIT".
> 
> draft-ietf-pkix-ac509prof-09 wrote:
> ------------------------------------
> Appendix B: ASN.1 Module
> 
>  PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
>               internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
>               id-mod-attribute-cert(12)}
> 
>     DEFINITIONS IMPLICIT TAGS ::=
>                 ^^^^^^^^
>     BEGIN
> 
>     -- EXPORTS ALL --
> -------------------------------------
> 
> draft-ietf-pkix-ac509prof-06 wrote:
> -------------------------------------
> Appendix B: ASN.1 Module
> 
>  PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
>               internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
>               id-mod-attribute-cert(12)}
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Ross | 9 Aug 2001 12:49

Comments requested on ETSI Draft TR "XML format for signature policies"


Request for comments on draft ETSI TR on XML based Signature Policies:

This draft ETSI technical report defines Signature Policies using XML which
are based on the ASN.1 Signature Policies defined in ETSI TS 101 733 and RFC
3125.

This draft TR is offered as a starting point for discussion on XML based
Signature Policies. All comments received will help to determine the future
direction this work item will take in ETSI. This draft technical report is
being made publicly available for review and comment by any company,
individual or organisation with interest in this area.  A copy can be
obtained through the ETSI El Sign web site (see below).

Comments are requested by 14th September.

Background

The development of this technical report

"XML format for signature policies"

is one of the tasks the ETSI Electronic Signature and Infrastructure Working
Group is progressing within the European Electronic Signature
Standardisation
Initiative (EESSI). The ETSI El Sign Web-site (see below) provides further
information about the ETSI activities and the EESSI program.

REQUESTED ACTION
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eissa, Mohamed | 9 Aug 2001 18:07
Picon
Favicon

pki alt-subject and unstructured name


Hi,

I am trying to locate the authoritative document regarding alt-subject and
unstructured name fields in x509 certificates.

What I'm trying to find out is how they are used to map enrollment requests
from one scep server to multiple ca's?

Sincerely,

Mohamed Eissa
Intel Canada
Permalink | Reply | 0 comments |
headers
C Michael Chernick | 9 Aug 2001 20:55
Favicon

Draft NIST S/MIME Profile available (Comment Period Extended)


FYI,

At yesterday's SMIME session at the London IETF, it was suggested that
NIST extend the deadline for comments on the Draft NIST S/MIME V3 Client
Profile.  Also, it was suggested that this notice be sent to the PKIX list
as well as the SMIME list. Thus, I am resending the announcement sent out
by Tim Polk on Monday, 2 July 2001 to the SMIME list.  The deadline for 
comments has been extended until 17 September 2001.

Thanks,
   Mike Chernick

---------Original Message Sent by Tim Polk to SMIME List on 2 July---------
FYI,

I have attached below the announcement for a recently released NIST draft 
document concerning S/MIME V3.  The document is intended to define an 
appropriate subset of the S/MIME standards for broad application in the U.S. 
Federal Government.  NIST will be supporting this document through the 
development of an automated conformance testing tool.  We hope the deployment 
of this tool will ease the development of conformant S/MIME V3 clients!

We are very interested in comments from both developers and the user 
community.  Please take the time to review the draft profile and NIST's plans 
for the automated testing facility.  We would appreciate comments on the 
profile by 17 August 2001 (now extended to 17 September).  Please send  
comments to Mike Chernick (NIST's S/MIME project leader) at <chernick <at> nist.gov>.

BTW, Mike will be presenting an overview of this project in the S/MIME WG
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hoyt L. Kesterson II | 10 Aug 2001 09:48
Picon
Favicon

Canadian contribution on enhancements to public-key and attribute certificates


The Canadian contribution on SC06 N 11987 Revised Working Document on 
Enhancements to Public-key and Attribute Certificates has been 
distributed by the SSC6 Secretariat as SC06 N 12011

It can be found at

 
ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/InputDocuments/6N12011CanadaOnCertWD.pdf

The agenda for the meeting in Flagstaff has been changed such that 
work on X.509 will be on Tuesday and Wednesday, 25 and 26 September, 
instead of Wednesday and Thursday as originally scheduled. The 
complete revised agenda can be found in the revised announcement at

   ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/announcementRev1.doc

The worm that is munching its way through the internet has caused the 
administrator of the ftp.bull.com system to tighten up its port 
control. Unfortunately, the Netscape browser wants to use a port that 
is blocked. The result is that use of the URLs above results in no 
response from the server. I was told that IE works and so does my old 
rock solid VersaTerm FTP Link application.

I spent $30 to hear a Netscape support person tell me that although 
he had confirmed that neither current release of Netscape would work 
and that although his IE browser would work, the fact that one server 
could not be accessed was not important enough to spend time on.

Therefore, I have not been able to check, as i normally do, that the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane