Re: Please review X.509 part of RFC 2538bis

[Simon Josefsson <[e-mail]>]

"Sean P. Turner" <[e-mail]> writes:

> Simon Josefsson wrote:
>
>>3.  Appropriate Owner Names for CERT RRs
>>
>>   It is recommended that certificate CERT RRs be stored under a domain
>>   name related to their subject, i.e., the name of the entity intended
>>   to control the private key corresponding to the public key being
>>   certified.  It is recommended that certificate revocation list CERT
>>   RRs be stored under a domain name related to their issuer.
>>
>>  
>>
> Should "recommended" be "RECOMMENDED" in the 1st and 2nd sentences?

Whether to enforce CERT RR owner name with RFC 2119 language appear to
be somewhat of a touchy issue.  Some are suggesting to even use SHOULD
or MUST.  I'm adding this as an open issue.

Thanks,
Simon




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB14oEfU049425; Tue, 30 Nov 2004 20:50:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB14oEFR049424; Tue, 30 Nov 2004 20:50:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from micah.software-aus.com.au (cust3103.vic01.dataco.com.au [202.63.62.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB14o8b7049290 for <[e-mail]>; Tue, 30 Nov 2004 20:50:09 -0800 (PST) (envelope-from [e-mail])
Received: from eb2bcom.com (192.168.1.166) by micah.software-aus.com.au (7.1.016.1) (authenticated as steven.legg) id 41A13B7400000F5C; Wed, 1 Dec 2004 15:54:36 +1100
Message-ID: <[e-mail]>
Date: Wed, 01 Dec 2004 15:48:45 +1100
From: Steven Legg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
CC: Steve Hanna <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

David Chadwick wrote:
> Since that time (Spring 2003) suppliers have not moved that far (if at 
> all) towards supporting component matching. Only Steven Legg's 
> Australian company, which had supported component matching prior to 
> publication of the RFCs, and OpenLDAP which I believe can now support 
> it, have done anything in this direction. Attribute extraction on the 
> other hand has double that amount of supporting implementations, plus 
> all clients can naturally support it without any code change.

So is that four client implementations that have support for adding and
modifying entries with certificates according to the attribute extraction
schema using any LDAP directory, or is that four client implementations
that depend on the XPS server to do the attribute extraction for them ?
Isn't there only one XPS(-like) server implementation ? I'm not sure you are
comparing like with like.

Incidentally, yesterday a colleague of mine configured a third-party
LDAP client with no built-in knowledge of component matching to use
component matches in its filters. No re-coding was necessary. Any client
that is configured with LDAP filters in string format or LDAP URLs is
already able to use component matching or the X.509 matching rules.

Regards,
Steven



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB131F7M029272; Tue, 30 Nov 2004 19:01:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB131FK1029271; Tue, 30 Nov 2004 19:01:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB131EU5029264 for <[e-mail]>; Tue, 30 Nov 2004 19:01:14 -0800 (PST) (envelope-from [e-mail])
Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CZKk4-00047G-00 for <[e-mail]>; Wed, 01 Dec 2004 04:01:20 +0100
Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 01 Dec 2004 04:01:19 +0100
Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 01 Dec 2004 04:01:19 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From: Simon Josefsson <[e-mail]>
Subject: Re: Please review X.509 part of RFC 2538bis
Date: Wed, 01 Dec 2004 03:55:58 +0100
Lines: 22
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:23:041201:gmane.ietf.x509::Ch6SaR0FgIIxOVQR:0000000000000000000000000000000000000000000000oYoI
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
Cancel-Lock: sha1:cAa9FBos4+eWSOdqo56ILuNaZ5I=
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Sean P. Turner" <[e-mail]> writes:

> Simon Josefsson wrote:
>
>>3.  Appropriate Owner Names for CERT RRs
>>
>>   It is recommended that certificate CERT RRs be stored under a domain
>>   name related to their subject, i.e., the name of the entity intended
>>   to control the private key corresponding to the public key being
>>   certified.  It is recommended that certificate revocation list CERT
>>   RRs be stored under a domain name related to their issuer.
>>
>>  
>>
> Should "recommended" be "RECOMMENDED" in the 1st and 2nd sentences?

Whether to enforce CERT RR owner name with RFC 2119 language appear to
be somewhat of a touchy issue.  Some are suggesting to even use SHOULD
or MUST.  I'm adding this as an open issue.

Thanks,
Simon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB10lZNu094500; Tue, 30 Nov 2004 16:47:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB10lZrJ094499; Tue, 30 Nov 2004 16:47:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB10lYHE094491 for <[e-mail]>; Tue, 30 Nov 2004 16:47:34 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB10leZv029285 for <[e-mail]>; Wed, 1 Dec 2004 00:47:40 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041130162830.02e9f3f0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Tue, 30 Nov 2004 16:48:16 -0800
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: draft-ietf-pkix-ldap-*: security considerations
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The security considerations sections of these documents
are inadequate and seem to nothing more than echo
general security concerns.  Given the nature of the
information being stored, I would suspect there would
be some significant other considerations.  In particular,
I am surprised not to see any discussion (in the security
consideration section or elsewhere) on the impact of
data inconsistencies between user and certificate objects.

Kurt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB10Rr3Z072606; Tue, 30 Nov 2004 16:27:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB10Rr9V072604; Tue, 30 Nov 2004 16:27:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB10RqDx072437 for <[e-mail]>; Tue, 30 Nov 2004 16:27:52 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iB10RqZv029182 for <[e-mail]>; Wed, 1 Dec 2004 00:27:52 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041130155245.02ea1880@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Tue, 30 Nov 2004 16:24:24 -0800
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: draft-ietf-pkix-ldap-* consistency issues
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

draft-ietf-pkix-ldap-pkc-schema-01 basically proposes to copy certificate
information from the entries representing the entity which possess the
certificate to a separate certificate entry.  I consider relocation not to
be feasible option whatsoever as it will simply break some
existing clients which use basic certificate matching, as well as
existing and future clients which makes component matching with
certificates.  However, the document actually reads as if relocation
of the information is intended.

This text causes me concern:
>   If certificates are stored redundantly in person entries and in      
>   certificate entries below the person entries, maintainers of
>   repositories MUST make sure that the same certificates are stored in
>   the person entry and the respective certificate entries and keep this
>   consistency.  Alternatively, they MUST leave out any certificates in
>   the person entry.

Now, given that maintainers will be hard pressed to ensure
consistency, this specification has stated that the standard
track approach of storing certificates in the person entry
is not to be followed.   This MUST will lead to breakage.

Instead, this document needs to needs to make it clear that
certificates will be stored redundantly, there will be
consistency issues, and then discuss how applications are
to address these consistency issues.

Kurt

PS: I note that these MUSTs appear to apply to users, not to
implementations... they likely should be downcased.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUFwjXY021622; Tue, 30 Nov 2004 07:58:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUFwjfZ021621; Tue, 30 Nov 2004 07:58:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUFwi3K021548 for <[e-mail]>; Tue, 30 Nov 2004 07:58:44 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iAUFwEZv024746; Tue, 30 Nov 2004 15:58:14 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041130072120.03443f28@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Tue, 30 Nov 2004 07:58:49 -0800
To: "David Chadwick" <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Cc: Steve Hanna <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

While there may have been some in this WG that viewed the
value extraction approach as a pragmatic solution to various
specific issues, I believe there are also many, like myself,
who have never considered the value extraction approach, in
general, to be practical.  And, as I noted in my previous
response, I do not consider the value extraction approach
as applied here to certificates and such to be pragmatic
as it simply does not address requirements I am faced with.

In particular, how does this approach providing for matching
upon components of the subject (or other) DNs in the certificate?


At 05:29 AM 11/30/2004, David Chadwick wrote:

>Steve
>
>we have had the meeting at IETF 56 and the majority agreed that component matching was the best long term solution to aim for. That is on the record. But also on the record is the note that vendors appear to be reluctant to support this, and that support for attribute extraction is a short term pragmatic solution that is much easier for suppliers and users to support. It does not add complexity to clients, on the contrary it makes it easier for clients. Consequently the ADs agreed that component matching should be published as Information RFCs.

I assume s/component matching/value extraction/.

Secondly,, I am not so sure the ADs actually agreed with the
informational track publication of the value extraction I-Ds.
I note that one AD in particular voiced significant concerns
about publication of alternatives here.

>Since that time (Spring 2003) suppliers have not moved that far (if at all) towards supporting component matching. Only Steven Legg's Australian company, which had supported component matching prior to publication of the RFCs, and OpenLDAP which I believe can now support it, have done anything in this direction.

Given that component matching was published as a Proposed Standard
in Feb. 2004, the fact that we now have two server implementations
is quite good.  We likely can seek progression to Draft Standard
status shortly.

As we understood long ago, it will take time for this to get on
the radar of LDAP server developers.  That seems to be happening
now.

>Attribute extraction on the other hand has double that amount of supporting implementations, plus all clients can naturally support it without any code change.

How does an existing client designed to work with person objects
become aware of, and make use of, subordinate certificate objects
without being changed?

>So whilst we might all like the ideal today, pragmatically we need to recognise that this is not the situation on the ground today.

Pragmatically, we have to realize that the so-called pragmatic
solution will introduce numerous problems which we could have
avoided if we would have stuck with the so-called elegant solution
we knew avoided these problems.

>If it were I would happily forget the attribute extraction IDs. My main desire is that we need to provide LDAP support to X.509 users today. We should recognise that it will be many years before the big LDAP suppliers might eventually decide to support component matching. After all, there are several very basic features of LDAP that some large LDAP suppliers dont yet support, even though they have been standardised for over 10 years.
>As several well known people have already said, LDAP has not done a good job at supporting PKI.

To the LDAP community, PKI is just another application of the
directory.  The LDAP community tends to focused on mechanisms
which support a wide range of applications (including PKI).
Component matching does this.

I am not sure the LDAP community as a whole sees the danger
in moving to a value extraction approach generally.  I shutter
at the thought of having components of every complex value
extracted into new values, and them in term extracted into more
values.  I would hope it would be obvious that value extraction
is not a wise approach, and will lead to numerous other problems.

>So why believe things will miraculously change overnight with component matching. Be realistic, it wont.

I don't believe I've ever said that we'd miraculously have wide
adoption of component matching overnight.  I expect it will be
years before we see that.

However, I fear that if we are not careful in how we publish
the value extraction approach, we will be living with the
problems of value extraction long after we have broad server
support for component matching.   By noting, using appropriately
strong language, the standard track approach is to be favored,
we might be able to minimize this.  Of course, we'd likely
suffer regardless.

>Unless of course Stefan Santesson can now stand up for his supplier and tell us when they will support component matching. That would indeed be very encouraging to us all.
>
>thanks
>
>David
>
>
>Steve Hanna wrote:
>>David Chadwick wrote:
>> > what ever happened to the concept of let a thousand flowers bloom?
>>Standards work is not about "let a thousand flowers bloom".
>>It's about agreeing on standards that will help systems
>>interoperate and work well together. From my analysis,
>>your proposals do not provide substantial benefit and
>>they do add substantial complexity. I don't think that
>>the Internet community will be well served by publishing
>>these documents. They will only increase confusion for
>>implementors and add complexity for directory clients,
>>which will now need to support several directory schemas.
>>In a separate email, David wrote:
>>
>>>At no time to my knowledge was it suggested that this work be removed
>>>from the PKIX set of IDs, otherwise why would they have continued to be
>>>published with PKIX IDs instead of individual IDs for more than a year
>>>after the meeting. And why would I have continued to report on their
>>>progress at PKIX meetings?
>>
>>At IETF 56, there was a discussion about whether to move
>>to your proposed schemas (at that time, an independent
>>submission) or stick with the current schema and use
>>component matching to solve the problem. I raised concerns
>>about your proposal at that meeting. As noted in the meeting
>>minutes, a straw poll favored component matching but it was
>>agreed to take this discussion to the mailing list. I never
>>saw any discussion on the mailing list.
>>At IETF 57, it was explained that the question had been
>>decided in favor of your schema (with no discussion
>>on the email list). I sent an email to the PKIX list
>>complaining about this and reiterating my concerns about
>>your proposal. Sharon Boeyen sent email supporting my
>>concerns. Nobody sent email favoring the proposals.
>>Now these documents are in Working Group Last Call.
>>I have seen several emails from experienced PKI and
>>directory folks raising concerns about your proposal
>>and little email supporting it. I think it's clear
>>there's no WG consensus in favor of your proposals.
>>I suspect there never was a consensus in favor of
>>them becoming WG drafts. If anything, the consensus
>>seems to be that these documents are not representative
>>of the IETF's future direction and should only be
>>published with an Experimental status and some sort
>>of warning.
>>I'm sorry for any confusion caused by the status of
>>your documents as WG drafts. It seems clear to me that
>>they should never have received such a status since
>>there was never rough consensus in the PKIX WG about
>>taking them on as work items. However, it is better to
>>remove this confusion now by publishing them as
>>Experimental with a warning than to expand the confusion
>>by publishing them as Informational without a warning.
>>Thanks,
>>Steve
>>
>
>-- 
>
>*****************************************************************
>
>David W. Chadwick, BSc PhD
>Professor of Information Systems Security
>IS Institute, University of Salford, Salford M5 4WT
>Tel: [phone]  Fax [phone]
>Mobile: [phone]
>Email: [e-mail]
>Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
>Research Web site: http://sec.isi.salford.ac.uk
>Entrust key validation string: MLJ9-DU5T-HV8J
>PGP Key ID is 0xBC238DE5
>
>*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUFi8oE001760; Tue, 30 Nov 2004 07:44:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUFi85P001759; Tue, 30 Nov 2004 07:44:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUFi7W9001601 for <[e-mail]>; Tue, 30 Nov 2004 07:44:07 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Tue, 30 Nov 2004 15:44:04 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: WG Last Call: Certificate Schema
Date: Tue, 30 Nov 2004 15:43:54 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WG Last Call: Certificate Schema
Thread-Index: AcTW7KYyAXzTclrSS9Gb9veo17sQuAABRUiQ
From: "Stefan Santesson" <[e-mail]>
To: "David Chadwick" <[e-mail]>, "Steve Hanna" <[e-mail]>
Cc: "Tim Polk" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 30 Nov 2004 15:44:04.0058 (UTC) FILETIME=[6B67D3A0:01C4D6F3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAUFi7W9001737
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

It seems that we all agree that these documents don't represent the
desired future direction.

If this is the easy fix solution to overcome temporary shortcomings of
current implementation of existing standards, then we shouldn't make
this into a standard, or anything that looks like a standard or guidance
on future direction.

I lack the discussion and insight on the potential harm that may follow
from diversity in applications where some decide to go the component
matching way or do some other tweak to make use of current schema, while
other implementations chooses the attribute extraction path and creation
of separate entries for certificates.

I fear a great mess out of this diversity and it probably won't help us
get to the target we all seems to agree on.

I regret not speaking up on this before, but a document can be
challenged until it has left the WG, and the fact that a document has
been processed as a WG document is not by itself a guarantee that it
will be published as one.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of David Chadwick
> Sent: den 30 november 2004 14:29
> To: Steve Hanna
> Cc: Tim Polk; [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: WG Last Call: Certificate Schema
> 
> 
> Steve
> 
> we have had the meeting at IETF 56 and the majority agreed that
> component matching was the best long term solution to aim for. That is
> on the record. But also on the record is the note that vendors appear
to
> be reluctant to support this, and that support for attribute
extraction
> is a short term pragmatic solution that is much easier for suppliers
and
> users to support. It does not add complexity to clients, on the
contrary
> it makes it easier for clients. Consequently the ADs agreed that
> component matching should be published as Information RFCs.
> 
> Since that time (Spring 2003) suppliers have not moved that far (if at
> all) towards supporting component matching. Only Steven Legg's
> Australian company, which had supported component matching prior to
> publication of the RFCs, and OpenLDAP which I believe can now support
> it, have done anything in this direction. Attribute extraction on the
> other hand has double that amount of supporting implementations, plus
> all clients can naturally support it without any code change.
> 
> So whilst we might all like the ideal today, pragmatically we need to
> recognise that this is not the situation on the ground today. If it
were
> I would happily forget the attribute extraction IDs. My main desire is
> that we need to provide LDAP support to X.509 users today. We should
> recognise that it will be many years before the big LDAP suppliers
might
> eventually decide to support component matching. After all, there are
> several very basic features of LDAP that some large LDAP suppliers
dont
> yet support, even though they have been standardised for over 10
years.
> As several well known people have already said, LDAP has not done a
good
> job at supporting PKI. So why believe things will miraculously change
> overnight with component matching. Be realistic, it wont. Unless of
> course Stefan Santesson can now stand up for his supplier and tell us
> when they will support component matching. That would indeed be very
> encouraging to us all.
> 
> thanks
> 
> David
> 
> 
> Steve Hanna wrote:
> >
> > David Chadwick wrote:
> >  > what ever happened to the concept of let a thousand flowers
bloom?
> >
> > Standards work is not about "let a thousand flowers bloom".
> > It's about agreeing on standards that will help systems
> > interoperate and work well together. From my analysis,
> > your proposals do not provide substantial benefit and
> > they do add substantial complexity. I don't think that
> > the Internet community will be well served by publishing
> > these documents. They will only increase confusion for
> > implementors and add complexity for directory clients,
> > which will now need to support several directory schemas.
> >
> > In a separate email, David wrote:
> >
> >> At no time to my knowledge was it suggested that this work be
removed
> >> from the PKIX set of IDs, otherwise why would they have continued
to be
> >> published with PKIX IDs instead of individual IDs for more than a
year
> >> after the meeting. And why would I have continued to report on
their
> >> progress at PKIX meetings?
> >
> >
> > At IETF 56, there was a discussion about whether to move
> > to your proposed schemas (at that time, an independent
> > submission) or stick with the current schema and use
> > component matching to solve the problem. I raised concerns
> > about your proposal at that meeting. As noted in the meeting
> > minutes, a straw poll favored component matching but it was
> > agreed to take this discussion to the mailing list. I never
> > saw any discussion on the mailing list.
> >
> > At IETF 57, it was explained that the question had been
> > decided in favor of your schema (with no discussion
> > on the email list). I sent an email to the PKIX list
> > complaining about this and reiterating my concerns about
> > your proposal. Sharon Boeyen sent email supporting my
> > concerns. Nobody sent email favoring the proposals.
> >
> > Now these documents are in Working Group Last Call.
> > I have seen several emails from experienced PKI and
> > directory folks raising concerns about your proposal
> > and little email supporting it. I think it's clear
> > there's no WG consensus in favor of your proposals.
> > I suspect there never was a consensus in favor of
> > them becoming WG drafts. If anything, the consensus
> > seems to be that these documents are not representative
> > of the IETF's future direction and should only be
> > published with an Experimental status and some sort
> > of warning.
> >
> > I'm sorry for any confusion caused by the status of
> > your documents as WG drafts. It seems clear to me that
> > they should never have received such a status since
> > there was never rough consensus in the PKIX WG about
> > taking them on as work items. However, it is better to
> > remove this confusion now by publishing them as
> > Experimental with a warning than to expand the confusion
> > by publishing them as Informational without a warning.
> >
> > Thanks,
> >
> > Steve
> >
> >
> >
> 
> --
> 
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Web site: http://sec.isi.salford.ac.uk
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUEopqq034860; Tue, 30 Nov 2004 06:50:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUEopJs034853; Tue, 30 Nov 2004 06:50:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.funk.com (mail2.funk.com [199.103.155.98] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUEoonj034624 for <[e-mail]>; Tue, 30 Nov 2004 06:50:50 -0800 (PST) (envelope-from [e-mail])
Received: from trilmail.funk.com ([192.168.21.75]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VP6GVJSL; Tue, 30 Nov 2004 09:50:21 -0500
Received: from [127.0.0.1] (hannaxp [192.168.21.6]) by trilmail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TJKX99RC; Tue, 30 Nov 2004 09:50:46 -0500
Message-ID: <[e-mail]>
Date: Tue, 30 Nov 2004 09:50:40 -0500
From: Steve Hanna <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

Thanks for providing some information on server
support for your schema and for component matching.
I would like to mention that component matching
is not the only server-side solution. X.509 and
draft-zeilenga-ldap-x509-00.txt (the successor
to RFC 2587) include a CertificateAssertion that
should be easy to implement on the server side.

You say that "all clients can naturally support
[your schema] without any code change". This isn't
true. Any client that tries to retrieve certificates
from an LDAP directory will need to look in a
different location. If the client doesn't know
which schema is in use (which will often happen
since clients are rarely configured with schema
information), it must look in both places.
Maybe you mean that clients don't need to change
if the certificates are stored in both locations,
but this is only a transitional situation.

So I would say it's more accurate to say that
clients must change for your solution but need
not change for the CertificateAssertion or
component matching solutions. Could you tell me
about any clients that support your solution?
I believe it's true that there are many more
client applications than server applications
so it will be much more difficult to change
the clients than the servers.

Thanks,

Steve

David Chadwick wrote:
> Steve
> 
> we have had the meeting at IETF 56 and the majority agreed that 
> component matching was the best long term solution to aim for. That is 
> on the record. But also on the record is the note that vendors appear to 
> be reluctant to support this, and that support for attribute extraction 
> is a short term pragmatic solution that is much easier for suppliers and 
> users to support. It does not add complexity to clients, on the contrary 
> it makes it easier for clients. Consequently the ADs agreed that 
> component matching should be published as Information RFCs.
> 
> Since that time (Spring 2003) suppliers have not moved that far (if at 
> all) towards supporting component matching. Only Steven Legg's 
> Australian company, which had supported component matching prior to 
> publication of the RFCs, and OpenLDAP which I believe can now support 
> it, have done anything in this direction. Attribute extraction on the 
> other hand has double that amount of supporting implementations, plus 
> all clients can naturally support it without any code change.
> 
> So whilst we might all like the ideal today, pragmatically we need to 
> recognise that this is not the situation on the ground today. If it were 
> I would happily forget the attribute extraction IDs. My main desire is 
> that we need to provide LDAP support to X.509 users today. We should 
> recognise that it will be many years before the big LDAP suppliers might 
> eventually decide to support component matching. After all, there are 
> several very basic features of LDAP that some large LDAP suppliers dont 
> yet support, even though they have been standardised for over 10 years. 
> As several well known people have already said, LDAP has not done a good 
> job at supporting PKI. So why believe things will miraculously change 
> overnight with component matching. Be realistic, it wont. Unless of 
> course Stefan Santesson can now stand up for his supplier and tell us 
> when they will support component matching. That would indeed be very 
> encouraging to us all.
> 
> thanks
> 
> David
> 
> 
> Steve Hanna wrote:
> 
>>
>> David Chadwick wrote:
>>  > what ever happened to the concept of let a thousand flowers bloom?
>>
>> Standards work is not about "let a thousand flowers bloom".
>> It's about agreeing on standards that will help systems
>> interoperate and work well together. From my analysis,
>> your proposals do not provide substantial benefit and
>> they do add substantial complexity. I don't think that
>> the Internet community will be well served by publishing
>> these documents. They will only increase confusion for
>> implementors and add complexity for directory clients,
>> which will now need to support several directory schemas.
>>
>> In a separate email, David wrote:
>>
>>> At no time to my knowledge was it suggested that this work be removed
>>> from the PKIX set of IDs, otherwise why would they have continued to be
>>> published with PKIX IDs instead of individual IDs for more than a year
>>> after the meeting. And why would I have continued to report on their
>>> progress at PKIX meetings?
>>
>>
>>
>> At IETF 56, there was a discussion about whether to move
>> to your proposed schemas (at that time, an independent
>> submission) or stick with the current schema and use
>> component matching to solve the problem. I raised concerns
>> about your proposal at that meeting. As noted in the meeting
>> minutes, a straw poll favored component matching but it was
>> agreed to take this discussion to the mailing list. I never
>> saw any discussion on the mailing list.
>>
>> At IETF 57, it was explained that the question had been
>> decided in favor of your schema (with no discussion
>> on the email list). I sent an email to the PKIX list
>> complaining about this and reiterating my concerns about
>> your proposal. Sharon Boeyen sent email supporting my
>> concerns. Nobody sent email favoring the proposals.
>>
>> Now these documents are in Working Group Last Call.
>> I have seen several emails from experienced PKI and
>> directory folks raising concerns about your proposal
>> and little email supporting it. I think it's clear
>> there's no WG consensus in favor of your proposals.
>> I suspect there never was a consensus in favor of
>> them becoming WG drafts. If anything, the consensus
>> seems to be that these documents are not representative
>> of the IETF's future direction and should only be
>> published with an Experimental status and some sort
>> of warning.
>>
>> I'm sorry for any confusion caused by the status of
>> your documents as WG drafts. It seems clear to me that
>> they should never have received such a status since
>> there was never rough consensus in the PKIX WG about
>> taking them on as work items. However, it is better to
>> remove this confusion now by publishing them as
>> Experimental with a warning than to expand the confusion
>> by publishing them as Informational without a warning.
>>
>> Thanks,
>>
>> Steve
>>
>>
>>
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUESaZS004522; Tue, 30 Nov 2004 06:28:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUESalv004521; Tue, 30 Nov 2004 06:28:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUESZ22004423 for <[e-mail]>; Tue, 30 Nov 2004 06:28:35 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iAUESVZv024144; Tue, 30 Nov 2004 14:28:31 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041129192445.030f2008@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Tue, 30 Nov 2004 06:29:06 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: draft-ietf-pkix-ldap-*-schema WG LC comments
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <6.1.2.0.0.20041126110949.02d3d2c0@127.0.0.1> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

We obviously have different recollections of the prior
conversations.  This may in part due to the fact that there
were many different conversations involving different
participants.  I recall reaching a general consensus (amongst
the participants) that these I-D were to progressed to the RFC
Editor on an Individual basis as either Informational or
Experimental.

Anyways, the reason why I noted my understandings of the prior
conversations was to lead into my comments regarding IESG notes,
as well as to serve as a basis for my recommendation that you
withdraw the I-Ds from WG consideration and take these directly
to the RFC Editor.  I recommend this approach because I do not
believe consensus exists to progress as products of this WG,
or of the IETF.

Please note that I don't dispute that the documents are
presently WG documents and that this is a WG LC.  I personally
don't put any weight in these facts towards the issue of
whether the WG should or should not progress these documents.

At 10:51 AM 11/29/2004, David Chadwick wrote:
>Your objections really do sound like those of someone who is frightened that the component matching approach will not be adopted and that the the current approach will kill it off.

I believe that component matching will become widely implemented,
regardless of the proposed extraction approach is published or not.
However publishing these documents without appropriate caution (which
I believe they currently do not) they offer an alternative approach
to standard track approaches, and that these standard track approaches
should be favored, may not only cause confusion in the community,
but may lead to interoperability problems.

>I hope this is not the case, because I would like to see component matching approach ubiquitously supported. However, many people need LDAP search support today for PKIs, and the current approach provides the simplest and quickest fix for this, though as we all agree, not the most elegant.

The problem with value extraction is that the fix brings far more problems
than it purports to resolve.  You have completely glossed over the complexity
this approach pushes onto clients.   Dealing with multiple entries is simply
not as simple as dealing with one entry.

>regards
>
>David
>
>p.s your technical argument below is flawed. People are not the only entities that possess certificates, and so the object class person is not necessary nor required for the search.

I fully realize that persons are not the only entity that might
possess a certificate.  My point is that the object representing
the entity is not returned by the certificate search.

>The user is only interested in obtaining the certificate containing the subject name with a particular RDN, and the current approach supports this kind of search.

There are a wide range of applications which need to acquir
non-certificate information about the user based upon information
they know about the user's certificate.


>Kurt D. Zeilenga wrote:
>>It was my understanding after previous discussions (involving
>>the authors, chairs, ADs, myself, and others) that these I-Ds
>>would be individually submitted to the RFC Editor for
>>consideration.  I am a bit surprised that they are now being
>>last called in PKIX WG as I was under the impression that the
>>WG has already reached consensus that these I-Ds would not be
>>progressed as products of the PKIX WG.
>>If these had been submitted directly to the RFC Editor, I
>>would have recommended to the IESG that an "IESG note" be
>>added to each I-D that clearly stated the I-D was not a
>>product of the IETF, provided an alternative to a standard
>>track approach, and that the standard track approach
>>should be favored by implementors and deployers.
>>However, as these I-Ds have been submitted to the PKIX WG
>>for consideration, the PXIX WG must reach consensus that the
>>I-Ds are technical sound and appropriate for publication as
>>a products of this WG.  I seriously doubt this WG will now
>>reach consensus that these I-Ds should be published as
>>products of the PKIX WG.
>>I do not believe the value extraction approach to be sound as
>>it doesn't actually address the key problem: matching against
>>arbitrary component values of a certificate (or other complex
>>structures).  For instance, say the application wanted to match
>>all person objects containing a certificate whose subject DN
>>contained an RDN containing an AVA with a common name of X.  This
>>schema simply doesn't support that kind of matching because only
>>select values of the certificate, some of which are themselves
>>complex structures, have been extracted AND, even if they had
>>been, the operation would not find the person object holding
>>the certificate, but a certificate object.
>>I believe the existing standard track approach more than
>>adequately addresses application needs in this area, and that
>>it can and will be implemented.  Not only are there two
>>existing implementations today, one is open source (and available
>>for reuse under non-restrictive terms).  While I cannot speak for
>>the plans of other vendors, I can say that I have been contacted
>>by a number of vendors who made it clear to me that they intend
>>to put implementation of the standard track approach into their
>>product plans.
>>Hence, I oppose progression of the I-Ds as products of the PKIX
>>WG (regardless of track).  I encourage the authors to withdraw
>>the I-Ds from IETF consideration and to submit them directly to
>>the RFC Editor for consideration.
>>I note that I found a number of other issues in the I-Ds.  I will
>>separately provide the WG with my review notes.
>>Regards, Kurt
>
>-- 
>
>*****************************************************************
>
>David W. Chadwick, BSc PhD
>Professor of Information Systems Security
>IS Institute, University of Salford, Salford M5 4WT
>Tel: [phone]  Fax [phone]
>Mobile: [phone]
>Email: [e-mail]
>Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
>Research Web site: http://sec.isi.salford.ac.uk
>Entrust key validation string: MLJ9-DU5T-HV8J
>PGP Key ID is 0xBC238DE5
>
>*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUDTdB0065967; Tue, 30 Nov 2004 05:29:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUDTcif065952; Tue, 30 Nov 2004 05:29:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iapetus.salford.ac.uk (iapetus.salford.ac.uk [146.87.255.98]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAUDTWdQ065743 for <[e-mail]>; Tue, 30 Nov 2004 05:29:33 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 6454 invoked by uid 1236); 30 Nov 2004 13:29:23 -0000
Received: from 146.87.80.63 by iapetus.salford.ac.uk (envelope-from <[e-mail]>, uid 401) with qmail-scanner-1.23  (clamdscan: 0.75.1. uvscan: v4.3.20/v4410. spamassassin: 2.64.   Clear:RC:1(146.87.80.63):.  Processed in 4.888465 secs); 30 Nov 2004 13:29:23 -0000
Received: from 146-87-80-63.salford.ac.uk (HELO [146.87.80.63]) (146.87.80.63) by iapetus.salford.ac.uk (qpsmtpd/0.29-cvs-20040817) with ESMTP; Tue, 30 Nov 2004 13:29:18 +0000
Message-ID: <[e-mail]>
Date: Tue, 30 Nov 2004 13:29:13 +0000
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve

we have had the meeting at IETF 56 and the majority agreed that 
component matching was the best long term solution to aim for. That is 
on the record. But also on the record is the note that vendors appear to 
be reluctant to support this, and that support for attribute extraction 
is a short term pragmatic solution that is much easier for suppliers and 
users to support. It does not add complexity to clients, on the contrary 
it makes it easier for clients. Consequently the ADs agreed that 
component matching should be published as Information RFCs.

Since that time (Spring 2003) suppliers have not moved that far (if at 
all) towards supporting component matching. Only Steven Legg's 
Australian company, which had supported component matching prior to 
publication of the RFCs, and OpenLDAP which I believe can now support 
it, have done anything in this direction. Attribute extraction on the 
other hand has double that amount of supporting implementations, plus 
all clients can naturally support it without any code change.

So whilst we might all like the ideal today, pragmatically we need to 
recognise that this is not the situation on the ground today. If it were 
I would happily forget the attribute extraction IDs. My main desire is 
that we need to provide LDAP support to X.509 users today. We should 
recognise that it will be many years before the big LDAP suppliers might 
eventually decide to support component matching. After all, there are 
several very basic features of LDAP that some large LDAP suppliers dont 
yet support, even though they have been standardised for over 10 years. 
As several well known people have already said, LDAP has not done a good 
job at supporting PKI. So why believe things will miraculously change 
overnight with component matching. Be realistic, it wont. Unless of 
course Stefan Santesson can now stand up for his supplier and tell us 
when they will support component matching. That would indeed be very 
encouraging to us all.

thanks

David


Steve Hanna wrote:
> 
> David Chadwick wrote:
>  > what ever happened to the concept of let a thousand flowers bloom?
> 
> Standards work is not about "let a thousand flowers bloom".
> It's about agreeing on standards that will help systems
> interoperate and work well together. From my analysis,
> your proposals do not provide substantial benefit and
> they do add substantial complexity. I don't think that
> the Internet community will be well served by publishing
> these documents. They will only increase confusion for
> implementors and add complexity for directory clients,
> which will now need to support several directory schemas.
> 
> In a separate email, David wrote:
> 
>> At no time to my knowledge was it suggested that this work be removed
>> from the PKIX set of IDs, otherwise why would they have continued to be
>> published with PKIX IDs instead of individual IDs for more than a year
>> after the meeting. And why would I have continued to report on their
>> progress at PKIX meetings?
> 
> 
> At IETF 56, there was a discussion about whether to move
> to your proposed schemas (at that time, an independent
> submission) or stick with the current schema and use
> component matching to solve the problem. I raised concerns
> about your proposal at that meeting. As noted in the meeting
> minutes, a straw poll favored component matching but it was
> agreed to take this discussion to the mailing list. I never
> saw any discussion on the mailing list.
> 
> At IETF 57, it was explained that the question had been
> decided in favor of your schema (with no discussion
> on the email list). I sent an email to the PKIX list
> complaining about this and reiterating my concerns about
> your proposal. Sharon Boeyen sent email supporting my
> concerns. Nobody sent email favoring the proposals.
> 
> Now these documents are in Working Group Last Call.
> I have seen several emails from experienced PKI and
> directory folks raising concerns about your proposal
> and little email supporting it. I think it's clear
> there's no WG consensus in favor of your proposals.
> I suspect there never was a consensus in favor of
> them becoming WG drafts. If anything, the consensus
> seems to be that these documents are not representative
> of the IETF's future direction and should only be
> published with an Experimental status and some sort
> of warning.
> 
> I'm sorry for any confusion caused by the status of
> your documents as WG drafts. It seems clear to me that
> they should never have received such a status since
> there was never rough consensus in the PKIX WG about
> taking them on as work items. However, it is better to
> remove this confusion now by publishing them as
> Experimental with a warning than to expand the confusion
> by publishing them as Informational without a warning.
> 
> Thanks,
> 
> Steve
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUAO6Eu091387; Tue, 30 Nov 2004 02:24:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAUAO6gC091386; Tue, 30 Nov 2004 02:24:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.daasi.de (rhea.directory.dfn.de [134.2.217.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAUAO4dn091316 for <[e-mail]>; Tue, 30 Nov 2004 02:24:04 -0800 (PST) (envelope-from [e-mail])
Received: by smtp.daasi.de (Postfix, from userid 1009) id 0F675C0F9; Tue, 30 Nov 2004 11:24:01 +0100 (CET)
Received: from daasi.de (marie.directory.dfn.de [134.2.217.72]) by smtp.daasi.de (Postfix) with ESMTP id AF927C0F4; Tue, 30 Nov 2004 11:23:55 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 30 Nov 2004 11:23:55 +0100
From: Peter Gietz <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
Cc: [e-mail], Norbert Klasen <[e-mail]>, David Chadwick <[e-mail]>, Steve Hanna <[e-mail]>
Subject: Re: draft-ietf-pkix-ldap-*-schema WG LC comments
References: <6.1.2.0.0.20041126110949.02d3d2c0@127.0.0.1>
In-Reply-To: <6.1.2.0.0.20041126110949.02d3d2c0@127.0.0.1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE, USER_AGENT version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt D. Zeilenga wrote:

>It was my understanding after previous discussions (involving
>the authors, chairs, ADs, myself, and others) that these I-Ds
>would be individually submitted to the RFC Editor for
>consideration.  I am a bit surprised that they are now being
>last called in PKIX WG as I was under the impression that the
>WG has already reached consensus that these I-Ds would not be
>progressed as products of the PKIX WG.
>  
>
I don't know about such a consensus. David's two drafts had been 
published as WG drafts since quite a while now and I haven't seen any 
protest on the list and at the meetings that I attended. I do know that 
some people on the list opposed our approach, but the longest critical 
threads where about LDAP itself as technology for publishing 
certificates, a discussion that was IMHO rather unfruitful.
[...]

>I do not believe the value extraction approach to be sound as
>it doesn't actually address the key problem: matching against
>arbitrary component values of a certificate (or other complex
>structures).  For instance, say the application wanted to match
>all person objects containing a certificate whose subject DN
>contained an RDN containing an AVA with a common name of X.  This
>schema simply doesn't support that kind of matching because only
>select values of the certificate, some of which are themselves
>complex structures, have been extracted AND, even if they had
>been, the operation would not find the person object holding
>the certificate, but a certificate object.
>
>  
>
As I mentioned before, we have been working on an additional objectclass 
to address the searches for DN parts, which we have already implemented 
to make such searches possible. The PKC draft already contains an 
attribute x509certHolder which contains a DN pointer to the person 
entry.  Our approach makes it possible to store certificate information 
and person information in two separate servers without loosing the 
relation between the two.

>I believe the existing standard track approach more than
>adequately addresses application needs in this area, and that
>it can and will be implemented.  
>

There is one application, which is not addressed by the standard track 
schema: Indexing. The IETF has published the Common Indexing Protocol as 
Standard Track (RFC 2651 - 2657). To provide CIP indexing objects for 
certificate information stored in LDAP you have to extract the cert 
values. I do see central indexes in the future, where people will search 
for the LDAP servers which have the certificate needed for e.g. 
encrypting an email.  The major motivation for our approach were such 
scenarios. And our approach has helped us setting up such.

>Not only are there two
>existing implementations today, one is open source (and available
>for reuse under non-restrictive terms).  While I cannot speak for
>the plans of other vendors, I can say that I have been contacted
>by a number of vendors who made it clear to me that they intend
>to put implementation of the standard track approach into their
>product plans.
>  
>
I do now see that things have changed by now in comparision with the 
time, we started this work. I never opposed the standard track solution. 
In many ways it is much more flexible and not only applicable to 
certificate information. Nevertheless I still am convinced that our 
solution is far easier to implement and that an implementation is 
useful. The two methods component matching and value extraction are in 
some ways complimentary and they are interoperable in the sense that a 
server can provide both without any harm.

>Hence, I oppose progression of the I-Ds as products of the PKIX
>WG (regardless of track).  I encourage the authors to withdraw
>the I-Ds from IETF consideration and to submit them directly to
>the RFC Editor for consideration.
>  
>
I had initially have published the pkc document as individual 
submission, I resubmitted it as WG draft after the partner documents had 
been WG dratfs for quite a while without protest. By having made the 
specs WG drafts some very valuable comments had been made which helped a 
lot to improve the documents. As there had been presentation about the 
drafts in so many pkix meetings I do consider them to be WG drafts now.

>I note that I found a number of other issues in the I-Ds.  I will
>separately provide the WG with my review notes.
>  
>
I am very much looking forward to your comments. The drafts BTW have 
already been influenced by your comments quite a lot already.


I am taking up Steves last proposal to publish them as experimental RFC.

Cheers,

Peter


>Regards, Kurt
>
>
>  
>


-- 
_______________________________________________________________________
 
Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]  
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATKCjki019159; Mon, 29 Nov 2004 12:12:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATKCjiS019158; Mon, 29 Nov 2004 12:12:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.funk.com (mail2.funk.com [199.103.155.98] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATKCf7g019025 for <[e-mail]>; Mon, 29 Nov 2004 12:12:41 -0800 (PST) (envelope-from [e-mail])
Received: from trilmail.funk.com ([192.168.21.75]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VP6GVGX7; Mon, 29 Nov 2004 15:12:05 -0500
Received: from [127.0.0.1] (hannaxp [192.168.21.6]) by trilmail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TJKX99N3; Mon, 29 Nov 2004 15:12:30 -0500
Message-ID: <[e-mail]>
Date: Mon, 29 Nov 2004 15:12:26 -0500
From: Steve Hanna <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Chadwick wrote:
 > what ever happened to the concept of let a thousand flowers bloom?

Standards work is not about "let a thousand flowers bloom".
It's about agreeing on standards that will help systems
interoperate and work well together. From my analysis,
your proposals do not provide substantial benefit and
they do add substantial complexity. I don't think that
the Internet community will be well served by publishing
these documents. They will only increase confusion for
implementors and add complexity for directory clients,
which will now need to support several directory schemas.

In a separate email, David wrote:
> At no time to my knowledge was it suggested that this work be removed
> from the PKIX set of IDs, otherwise why would they have continued to be
> published with PKIX IDs instead of individual IDs for more than a year
> after the meeting. And why would I have continued to report on their
> progress at PKIX meetings?

At IETF 56, there was a discussion about whether to move
to your proposed schemas (at that time, an independent
submission) or stick with the current schema and use
component matching to solve the problem. I raised concerns
about your proposal at that meeting. As noted in the meeting
minutes, a straw poll favored component matching but it was
agreed to take this discussion to the mailing list. I never
saw any discussion on the mailing list.

At IETF 57, it was explained that the question had been
decided in favor of your schema (with no discussion
on the email list). I sent an email to the PKIX list
complaining about this and reiterating my concerns about
your proposal. Sharon Boeyen sent email supporting my
concerns. Nobody sent email favoring the proposals.

Now these documents are in Working Group Last Call.
I have seen several emails from experienced PKI and
directory folks raising concerns about your proposal
and little email supporting it. I think it's clear
there's no WG consensus in favor of your proposals.
I suspect there never was a consensus in favor of
them becoming WG drafts. If anything, the consensus
seems to be that these documents are not representative
of the IETF's future direction and should only be
published with an Experimental status and some sort
of warning.

I'm sorry for any confusion caused by the status of
your documents as WG drafts. It seems clear to me that
they should never have received such a status since
there was never rough consensus in the PKIX WG about
taking them on as work items. However, it is better to
remove this confusion now by publishing them as
Experimental with a warning than to expand the confusion
by publishing them as Informational without a warning.

Thanks,

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATItQGq045299; Mon, 29 Nov 2004 10:55:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATItQGp045298; Mon, 29 Nov 2004 10:55:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon1-mail-2.visp.demon.net (IDENT:[e-mail] [193.195.70.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATItPvb045271 for <[e-mail]>; Mon, 29 Nov 2004 10:55:25 -0800 (PST) (envelope-from [e-mail])
Received: from [82.32.148.41] (82-32-148-41.cable.ubr01.nail.blueyonder.co.uk [82.32.148.41]) by lon1-mail-2.visp.demon.net (MOS 3.4.6-GR) with ESMTP id BRK72573 (AUTH [e-mail]); Mon, 29 Nov 2004 18:55:00 GMT
Message-ID: <[e-mail]>
Date: Mon, 29 Nov 2004 18:54:56 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-ldap-*-schema WG LC comments
References: <6.1.2.0.0.20041126110949.02d3d2c0@127.0.0.1>
In-Reply-To: <6.1.2.0.0.20041126110949.02d3d2c0@127.0.0.1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

P.s. If you are really so concerned with supporting X.509 attributes in 
LDAP, why dont you work on solving a real requirement, such as the 
ability to simply add an attribute certificate to an entry. Even this 
simple feature currently is not possible in LDAP when the entry already 
contains an AC.

regards

David


Kurt D. Zeilenga wrote:
> It was my understanding after previous discussions (involving
> the authors, chairs, ADs, myself, and others) that these I-Ds
> would be individually submitted to the RFC Editor for
> consideration.  I am a bit surprised that they are now being
> last called in PKIX WG as I was under the impression that the
> WG has already reached consensus that these I-Ds would not be
> progressed as products of the PKIX WG.
> 
> If these had been submitted directly to the RFC Editor, I
> would have recommended to the IESG that an "IESG note" be
> added to each I-D that clearly stated the I-D was not a
> product of the IETF, provided an alternative to a standard
> track approach, and that the standard track approach
> should be favored by implementors and deployers.
> 
> However, as these I-Ds have been submitted to the PKIX WG
> for consideration, the PXIX WG must reach consensus that the
> I-Ds are technical sound and appropriate for publication as
> a products of this WG.  I seriously doubt this WG will now
> reach consensus that these I-Ds should be published as
> products of the PKIX WG.
> 
> I do not believe the value extraction approach to be sound as
> it doesn't actually address the key problem: matching against
> arbitrary component values of a certificate (or other complex
> structures).  For instance, say the application wanted to match
> all person objects containing a certificate whose subject DN
> contained an RDN containing an AVA with a common name of X.  This
> schema simply doesn't support that kind of matching because only
> select values of the certificate, some of which are themselves
> complex structures, have been extracted AND, even if they had
> been, the operation would not find the person object holding
> the certificate, but a certificate object.
> 
> I believe the existing standard track approach more than
> adequately addresses application needs in this area, and that
> it can and will be implemented.  Not only are there two
> existing implementations today, one is open source (and available
> for reuse under non-restrictive terms).  While I cannot speak for
> the plans of other vendors, I can say that I have been contacted
> by a number of vendors who made it clear to me that they intend
> to put implementation of the standard track approach into their
> product plans.
> 
> Hence, I oppose progression of the I-Ds as products of the PKIX
> WG (regardless of track).  I encourage the authors to withdraw
> the I-Ds from IETF consideration and to submit them directly to
> the RFC Editor for consideration.
> 
> I note that I found a number of other issues in the I-Ds.  I will
> separately provide the WG with my review notes.
> 
> Regards, Kurt
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATIq7Wb043010; Mon, 29 Nov 2004 10:52:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATIq7XX043007; Mon, 29 Nov 2004 10:52:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon1-mail-2.visp.demon.net (IDENT:[e-mail] [193.195.70.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATIq6lN042911 for <[e-mail]>; Mon, 29 Nov 2004 10:52:06 -0800 (PST) (envelope-from [e-mail])
Received: from [82.32.148.41] (82-32-148-41.cable.ubr01.nail.blueyonder.co.uk [82.32.148.41]) by lon1-mail-2.visp.demon.net (MOS 3.4.6-GR) with ESMTP id BRK71853 (AUTH [e-mail]); Mon, 29 Nov 2004 18:51:32 GMT
Message-ID: <[e-mail]>
Date: Mon, 29 Nov 2004 18:51:29 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-ldap-*-schema WG LC comments
References: <6.1.2.0.0.20041126110949.02d3d2c0@127.0.0.1>
In-Reply-To: <6.1.2.0.0.20041126110949.02d3d2c0@127.0.0.1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt

at the meeting that we all attended, you will recall that these 3 IDs 
were originally standard's track, and that the authors agreed to 
downgrade them to Informational to allow the component matching approach 
to become the only official standards track approach. We did this 
because we knew that it would take a long time for LDAP suppliers to 
implement the latter approach, and we did not want to prejudice this in 
the short time by standardising these 3 IDs, which we know are easier 
for most suppliers to support (ie. they need do nothing except put an 
XPS server in front of their existing LDAP server).

At no time to my knowledge was it suggested that this work be removed 
from the PKIX set of IDs, otherwise why would they have continued to be 
published with PKIX IDs instead of individual IDs for more than a year 
after the meeting. And why would I have continued to report on their 
progress at PKIX meetings? Thus I believe your recollection of this is 
wrong. The IDs are and always have been a product of the IETF and the 
PKIX group in particular. The authors wanted it this way to make sure 
that the approach was widely supported (which I believe it is. We 
already know of 4 implementations which Peter has already informed you 
about). Thus I believe that the WG has reached concensus on these IDs.

Your objections really do sound like those of someone who is frightened 
that the component matching approach will not be adopted and that the 
the current approach will kill it off. I hope this is not the case, 
because I would like to see component matching approach ubiquitously 
supported. However, many people need LDAP search support today for PKIs, 
and the current approach provides the simplest and quickest fix for 
this, though as we all agree, not the most elegant.

regards

David

p.s your technical argument below is flawed. People are not the only 
entities that possess certificates, and so the object class person is 
not necessary nor required for the search. The user is only interested 
in obtaining the certificate containing the subject name with a 
particular RDN, and the current approach supports this kind of search.

Kurt D. Zeilenga wrote:
> It was my understanding after previous discussions (involving
> the authors, chairs, ADs, myself, and others) that these I-Ds
> would be individually submitted to the RFC Editor for
> consideration.  I am a bit surprised that they are now being
> last called in PKIX WG as I was under the impression that the
> WG has already reached consensus that these I-Ds would not be
> progressed as products of the PKIX WG.
> 
> If these had been submitted directly to the RFC Editor, I
> would have recommended to the IESG that an "IESG note" be
> added to each I-D that clearly stated the I-D was not a
> product of the IETF, provided an alternative to a standard
> track approach, and that the standard track approach
> should be favored by implementors and deployers.
> 
> However, as these I-Ds have been submitted to the PKIX WG
> for consideration, the PXIX WG must reach consensus that the
> I-Ds are technical sound and appropriate for publication as
> a products of this WG.  I seriously doubt this WG will now
> reach consensus that these I-Ds should be published as
> products of the PKIX WG.
> 
> I do not believe the value extraction approach to be sound as
> it doesn't actually address the key problem: matching against
> arbitrary component values of a certificate (or other complex
> structures).  For instance, say the application wanted to match
> all person objects containing a certificate whose subject DN
> contained an RDN containing an AVA with a common name of X.  This
> schema simply doesn't support that kind of matching because only
> select values of the certificate, some of which are themselves
> complex structures, have been extracted AND, even if they had
> been, the operation would not find the person object holding
> the certificate, but a certificate object.
> 
> I believe the existing standard track approach more than
> adequately addresses application needs in this area, and that
> it can and will be implemented.  Not only are there two
> existing implementations today, one is open source (and available
> for reuse under non-restrictive terms).  While I cannot speak for
> the plans of other vendors, I can say that I have been contacted
> by a number of vendors who made it clear to me that they intend
> to put implementation of the standard track approach into their
> product plans.
> 
> Hence, I oppose progression of the I-Ds as products of the PKIX
> WG (regardless of track).  I encourage the authors to withdraw
> the I-Ds from IETF consideration and to submit them directly to
> the RFC Editor for consideration.
> 
> I note that I found a number of other issues in the I-Ds.  I will
> separately provide the WG with my review notes.
> 
> Regards, Kurt
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATIK1tc002963; Mon, 29 Nov 2004 10:20:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATIK15n002960; Mon, 29 Nov 2004 10:20:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATIJxKK002663 for <[e-mail]>; Mon, 29 Nov 2004 10:20:00 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 18:20:07 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-ldap-*-schema WG LC comments
Date: Mon, 29 Nov 2004 18:19:51 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-ldap-*-schema WG LC comments
Thread-Index: AcTWJ4qVfLr2O2guQwytcSQz3ojXjwAFJ4dg
From: "Stefan Santesson" <[e-mail]>
To: "Kurt D. Zeilenga" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 29 Nov 2004 18:20:07.0895 (UTC) FILETIME=[0E463670:01C4D640]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iATIK0KK002944
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would also like to state, within this last call period, that I oppose
these documents being published as a product of the PKIX WG.

The approach may provide some values with respect to shortcomings of
current implementations, but the larger issue is whether the approach
embodies the intended and desired path to the future. It seems to me
that creation of separate additional entries for each certificate (or
CRL) is not the appropriate architectural approach.

I agree that publication of these drafts as a product of this WG sends
the wrong message (even if not standards track) since there is an
obvious risk that they will be interpreted as this WGs view of the path
forward.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Kurt D. Zeilenga
> Sent: den 29 november 2004 14:27
> To: [e-mail]
> Subject: draft-ietf-pkix-ldap-*-schema WG LC comments
> 
> 
> It was my understanding after previous discussions (involving
> the authors, chairs, ADs, myself, and others) that these I-Ds
> would be individually submitted to the RFC Editor for
> consideration.  I am a bit surprised that they are now being
> last called in PKIX WG as I was under the impression that the
> WG has already reached consensus that these I-Ds would not be
> progressed as products of the PKIX WG.
> 
> If these had been submitted directly to the RFC Editor, I
> would have recommended to the IESG that an "IESG note" be
> added to each I-D that clearly stated the I-D was not a
> product of the IETF, provided an alternative to a standard
> track approach, and that the standard track approach
> should be favored by implementors and deployers.
> 
> However, as these I-Ds have been submitted to the PKIX WG
> for consideration, the PXIX WG must reach consensus that the
> I-Ds are technical sound and appropriate for publication as
> a products of this WG.  I seriously doubt this WG will now
> reach consensus that these I-Ds should be published as
> products of the PKIX WG.
> 
> I do not believe the value extraction approach to be sound as
> it doesn't actually address the key problem: matching against
> arbitrary component values of a certificate (or other complex
> structures).  For instance, say the application wanted to match
> all person objects containing a certificate whose subject DN
> contained an RDN containing an AVA with a common name of X.  This
> schema simply doesn't support that kind of matching because only
> select values of the certificate, some of which are themselves
> complex structures, have been extracted AND, even if they had
> been, the operation would not find the person object holding
> the certificate, but a certificate object.
> 
> I believe the existing standard track approach more than
> adequately addresses application needs in this area, and that
> it can and will be implemented.  Not only are there two
> existing implementations today, one is open source (and available
> for reuse under non-restrictive terms).  While I cannot speak for
> the plans of other vendors, I can say that I have been contacted
> by a number of vendors who made it clear to me that they intend
> to put implementation of the standard track approach into their
> product plans.
> 
> Hence, I oppose progression of the I-Ds as products of the PKIX
> WG (regardless of track).  I encourage the authors to withdraw
> the I-Ds from IETF consideration and to submit them directly to
> the RFC Editor for consideration.
> 
> I note that I found a number of other issues in the I-Ds.  I will
> separately provide the WG with my review notes.
> 
> Regards, Kurt




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATDQpZ3000643; Mon, 29 Nov 2004 05:26:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iATDQpSO000639; Mon, 29 Nov 2004 05:26:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iATDQobv000439 for <[e-mail]>; Mon, 29 Nov 2004 05:26:50 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iATDQgZv015738 for <[e-mail]>; Mon, 29 Nov 2004 13:26:42 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041126110949.02d3d2c0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Mon, 29 Nov 2004 05:26:56 -0800
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: draft-ietf-pkix-ldap-*-schema WG LC comments
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It was my understanding after previous discussions (involving
the authors, chairs, ADs, myself, and others) that these I-Ds
would be individually submitted to the RFC Editor for
consideration.  I am a bit surprised that they are now being
last called in PKIX WG as I was under the impression that the
WG has already reached consensus that these I-Ds would not be
progressed as products of the PKIX WG.

If these had been submitted directly to the RFC Editor, I
would have recommended to the IESG that an "IESG note" be
added to each I-D that clearly stated the I-D was not a
product of the IETF, provided an alternative to a standard
track approach, and that the standard track approach
should be favored by implementors and deployers.

However, as these I-Ds have been submitted to the PKIX WG
for consideration, the PXIX WG must reach consensus that the
I-Ds are technical sound and appropriate for publication as
a products of this WG.  I seriously doubt this WG will now
reach consensus that these I-Ds should be published as
products of the PKIX WG.

I do not believe the value extraction approach to be sound as
it doesn't actually address the key problem: matching against
arbitrary component values of a certificate (or other complex
structures).  For instance, say the application wanted to match
all person objects containing a certificate whose subject DN
contained an RDN containing an AVA with a common name of X.  This
schema simply doesn't support that kind of matching because only
select values of the certificate, some of which are themselves
complex structures, have been extracted AND, even if they had
been, the operation would not find the person object holding
the certificate, but a certificate object.

I believe the existing standard track approach more than
adequately addresses application needs in this area, and that
it can and will be implemented.  Not only are there two
existing implementations today, one is open source (and available
for reuse under non-restrictive terms).  While I cannot speak for
the plans of other vendors, I can say that I have been contacted
by a number of vendors who made it clear to me that they intend
to put implementation of the standard track approach into their
product plans.

Hence, I oppose progression of the I-Ds as products of the PKIX
WG (regardless of track).  I encourage the authors to withdraw
the I-Ds from IETF consideration and to submit them directly to
the RFC Editor for consideration.

I note that I found a number of other issues in the I-Ds.  I will
separately provide the WG with my review notes.

Regards, Kurt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iARNpj7n081038; Sat, 27 Nov 2004 15:51:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iARNpj3H081037; Sat, 27 Nov 2004 15:51:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iARNpiHK080907 for <[e-mail]>; Sat, 27 Nov 2004 15:51:44 -0800 (PST) (envelope-from [e-mail])
Received: by rproxy.gmail.com with SMTP id 34so118182rns for <[e-mail]>; Sat, 27 Nov 2004 15:51:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=CjsbHsO40dIb9oiMXUH7J7+cHdA73USf7VOKYDW2ASp1rh/BjHG13rxKmpRnD5/uWH8Xo+BnZPa8x7KoZXaoqkOabD4yZ7M9hFC4TmYerJrNNLRzzV4Bu3eJmIMt8i8VZPFwmLWfrwNtwhE0FG2+SvKqjpyngMG4n0VKOXkdD5w=
Received: by 10.38.10.61 with SMTP id 61mr673320rnj; Sat, 27 Nov 2004 15:51:46 -0800 (PST)
Received: by 10.38.206.34 with HTTP; Sat, 27 Nov 2004 15:51:46 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 28 Nov 2004 10:51:46 +1100
From: ronnie sahlberg <[e-mail]>
Reply-To: ronnie sahlberg <[e-mail]>
To: [e-mail]
Subject: [OT] Protocols missing from ethereal, seeking example captures
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi List.

Sorry for the off-topic post but I assume if anyone can help me here
it would be people on this list.

I am one of the core developers of Ethereal (www.ethereal.com  a free
GPL protocol analyzer) and am now trying to make the dissection in
ethereal complete with regards to X509 and related protocols.

While Ethereal has currently got reasonably support for things like
CMS, X509 etc there are still a lot of missing protocols.

What I need to complete this support is essentially example packet
captures containing the various protocols.

If anyone is intyerested in helping me out there, these are the things
that are still missing from the protocols described in your working
groups list of RFCs:

RFC2510 :  
  Example capture containing 5.4 Management Protocol via HTTP
  Example capture containing 5.2 Direct TCP-Based Management Protocol

RFC2511 :
  Example capture containing some messages.

RFC 2560 :
  Example capture containing A.1 OCSP over HTTP

RFC 2797 :
  Example capture containing 7.1  MIME Wrapping
  Example capture containing 7.3  Socket-Based Transport

RFC 3029 :
  Example capture containing 10.1 DVCS Protocol via HTTP or HTTPS

RFC 3161 :
  Example capture containing 3.3. Socket Based Protocol
  Example capture contaionig 3.4. Time-Stamp Protocol via HTTP

Most of the other missings RFCs  I feel comfortable adding without
testing, but the ones above would be very nice to be able to test.

The process of writing the actual code in Ethereal is semitrivial with
the Ethereal asn2eth compiler   but the wrapping inside other
protocols needs to be tested.


If anyone is interested in helping me out  we can take it off list
since it is off topic.

If anyone has any other protocols they need implemented in Ethereal
and have and can provide me with example captures  i will be happy to
add them.


best regards
  ronnie sahlberg



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQ9wJ68096520; Fri, 26 Nov 2004 01:58:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQ9wJt6096515; Fri, 26 Nov 2004 01:58:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.daasi.de (rhea.directory.dfn.de [134.2.217.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQ9wIB5096361 for <[e-mail]>; Fri, 26 Nov 2004 01:58:18 -0800 (PST) (envelope-from [e-mail])
Received: by smtp.daasi.de (Postfix, from userid 1009) id D5858C107; Fri, 26 Nov 2004 10:58:15 +0100 (CET)
Received: from daasi.de (marie.directory.dfn.de [134.2.217.72]) by smtp.daasi.de (Postfix) with ESMTP id 33C34C107; Fri, 26 Nov 2004 10:58:10 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 26 Nov 2004 10:58:09 +0100
From: Peter Gietz <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
Cc: Andrew Sciberras <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, hits=-3.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_LONG_SPARSE,USER_AGENT version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Chadwick wrote:

>
>
> Andrew Sciberras wrote:
>
>> Hi,
>>
>> Do you have any concerns about the fact that the Serial Number
>> attribute (section 5.1.2) does not contain an ordering matching rule?
>
>
> Hi Andrew
>
> yes good idea. It could be useful when searching for a CRL to see if 
> any  certificates with serial numbers GE n have been published in a CRL.
>
> Peter, can you add this to the certificate schema ID please.


Yes I will.

Cheers,

Peter

>
>>
>> Is it intentional that the Serial Number attribute is not 
>> 'SINGLE-VALUE'?
>
>
> See peter's response to this
>
> regards
>
> David
>
>>
>>
>> Section 5.2.3  Key usage Extension
>> If you have a certificate with a keyUsage extension present with a
>> value of zero (i.e. none of the bits are set) what do you do? Do you
>> simply omit using the x509keyUsage atribute? If not, how does the BNF
>> represent such a value?
>>
>> Thanks,
>> Andrew Sciberras
>>
>>
>>
>> On Mon, 15 Nov 2004 17:00:22 -0500, Tim Polk <[e-mail]> wrote:
>>
>>>
>>> This message initiates working group Last Call for the "LDAP Schema for
>>> X.509 Certificates"
>>> specification. The editors have confirmed that all working group issues
>>> have been resolved.
>>>
>>> The URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt 
>>>
>>>
>>> This specification has also been forwarded to the LDAP Directorate 
>>> for a
>>> parallel review.  Assuming successful Last Call and concurrence from 
>>> the
>>> LDAP Directorate, this document will be forwarded to the ADs for
>>> consideration as an Informational track RFC.
>>>
>>> Last Call will run for (at least) two weeks. That is, Last Call will 
>>> not
>>> close before November 29.
>>>
>>> Thanks,
>>>
>>> Tim Polk
>>>
>>>
>>
>>
>>
>>
>


-- 
_______________________________________________________________________
 
Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]  
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQ1WZ1L075190; Thu, 25 Nov 2004 17:32:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAQ1WZPc075189; Thu, 25 Nov 2004 17:32:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon1-mail-1.visp.demon.net (IDENT:[e-mail] [193.195.70.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAQ1WY1r075150 for <[e-mail]>; Thu, 25 Nov 2004 17:32:34 -0800 (PST) (envelope-from [e-mail])
Received: from [80.4.87.77] (cpc4-hudd3-5-0-cust77.hudd.cable.ntl.com [80.4.87.77]) by lon1-mail-1.visp.demon.net (MOS 3.4.6-GR) with ESMTP id BVN09157 (AUTH [e-mail]); Thu, 25 Nov 2004 19:26:45 GMT
Message-ID: <[e-mail]>
Date: Thu, 25 Nov 2004 19:26:43 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andrew Sciberras <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Andrew Sciberras wrote:
> Hi,
> 
> Do you have any concerns about the fact that the Serial Number
> attribute (section 5.1.2) does not contain an ordering matching rule?

Hi Andrew

yes good idea. It could be useful when searching for a CRL to see if any 
  certificates with serial numbers GE n have been published in a CRL.

Peter, can you add this to the certificate schema ID please.

> 
> Is it intentional that the Serial Number attribute is not 'SINGLE-VALUE'?

See peter's response to this

regards

David

> 
> 
> Section 5.2.3  Key usage Extension
> If you have a certificate with a keyUsage extension present with a
> value of zero (i.e. none of the bits are set) what do you do? Do you
> simply omit using the x509keyUsage atribute? If not, how does the BNF
> represent such a value?
> 
> Thanks,
> Andrew Sciberras
> 
> 
> 
> On Mon, 15 Nov 2004 17:00:22 -0500, Tim Polk <[e-mail]> wrote:
> 
>>
>>This message initiates working group Last Call for the "LDAP Schema for
>>X.509 Certificates"
>>specification. The editors have confirmed that all working group issues
>>have been resolved.
>>
>>The URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt
>>
>>This specification has also been forwarded to the LDAP Directorate for a
>>parallel review.  Assuming successful Last Call and concurrence from the
>>LDAP Directorate, this document will be forwarded to the ADs for
>>consideration as an Informational track RFC.
>>
>>Last Call will run for (at least) two weeks. That is, Last Call will not
>>close before November 29.
>>
>>Thanks,
>>
>>Tim Polk
>>
>>
> 
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPJwG5w011707; Thu, 25 Nov 2004 11:58:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAPJwG4N011706; Thu, 25 Nov 2004 11:58:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon1-mail-2.visp.demon.net (IDENT:[e-mail] [193.195.70.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPJwAia011607 for <[e-mail]>; Thu, 25 Nov 2004 11:58:11 -0800 (PST) (envelope-from [e-mail])
Received: from [80.4.87.77] (cpc4-hudd3-5-0-cust77.hudd.cable.ntl.com [80.4.87.77]) by lon1-mail-2.visp.demon.net (MOS 3.4.6-GR) with ESMTP id BRC07463 (AUTH [e-mail]); Thu, 25 Nov 2004 19:57:31 GMT
Message-ID: <[e-mail]>
Date: Thu, 25 Nov 2004 19:57:29 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Steve

what ever happened to the concept of let a thousand flowers bloom?
Or let the best man win? It seems to me that you would like to gag these 
  IDs because you fear that they will be more successful than component 
matching.

Lets face it, LDAP has not served PKIs at all well for the last decade. 
We still are not able to search for certificates, CRLs or ACs for 
goodness sake. And most LDAP suppliers dont really care, since this is 
not where their primary market share is. They have enough new 
requirements being requested from existing users to want to do anything 
for the small number of PKI users.

The 3 LDAP schemas that Peter and I have specified, and implemented in 
the XPS server, allow PKI users to sit an XPS server in front of their 
existing LDAP server (from whichever supplier, since none of them allow 
existing clients to search for the X.509 attributes) and to allow 
existing clients to search for them without needing a software change. 
The only thing that is needed is to configure the client with some new 
attribute types to search for. Now this must be good news for PKI users.

Since Peter has already adequately addressed your points in more detail, 
I wont respond to them individually, unless you would specifically like 
me to

regards

David


Steve Hanna wrote:
> 
> Here are my comments on draft-ietf-pkix-ldap-*schema.
> 
> These schemas are too complex and incompatible with
> existing clients. The costs exceed the benefits.
> 
> The main supposed benefits of your solution are:
> 
> 1) Easier to search for certs
> 
>    Since certificate fields are stored as attributes
>    of LDAP entries, clients can easily search for
>    certificates by certificate field values. However,
>    there are already two good ways to do this: the
>    CertificateAssertion (defined in X.509 and
>    draft-zeilenga-ldap-x509-00.txt) and Component
>    Matching (RFC 3687). You argue that these will
>    take a while to be deployed, but so would your
>    solution. We don't need a third option.
> 
> 2) Easier to download just matching certs
> 
>    Some users (or CAs) have many certificates.
>    Your solution stores each cert as a separate
>    directory entry which makes it easy to download
>    just the ones you want. But there is already a
>    way to do this with the existing schema: the
>    Matched Values Return Filter control (RFC 3876).
>    Again you argue that these will take a while to
>    be deployed, but so would your solution. Also,
>    it's quite rare to have many certificates. Why
>    optimize for this rare case?
> 
> The main costs of your solution are:
> 
> 1) Many more directory entries (>2x)
> 
>    Your solution requires a separate directory entry
>    for every certificate. If each user has an average
>    of one cert, this will double the number of entries
>    in the directory. That's bad enough, but your solution
>    has no value unless each user has many certificates.
>    In that case, the number of entries will more than
>    double.
> 
> 2) Client changes needed
> 
>    You complain that the Matched Values Return Filter
>    control will require servers to be upgraded. But
>    your solution will require all clients to be upgraded
>    to look for certificates and CRLs in a new place.
>    Upgrading all clients is much harder than upgrading
>    a few servers.
> 
> The schema described in RFC 2587 and updated by
> draft-zeilenga-ldap-x509-00.txt seems much more
> reasonable than yours. I understand that the
> zeilenga I-D is actually a product of the ldapbis
> efforts and will probably advance with them.
> Therefore, I suggest that document be advanced in
> lieu of yours.
> 
> I have heard that your drafts are only intended to
> report on some experiments you conducted. That's why
> the documents are going Informational and not Standards
> Track. If that's true, the documents should say so
> clearly and they should go Experimental not Informational.
> 
> In conclusion, it's my view that these documents are
> not useful. In fact, they may cause harm to people
> who implement them without understanding that they
> are purely experimental. I recommend that they not
> be published at all by the IETF. If they are published,
> they should only be published with Experimental status
> with an Applicability Notice describing the problems
> noted above and suggesting that the standard schemas
> be used instead.
> 
> Thanks,
> 
> Steve
> 
> Tim Polk wrote:
> 
>>
>>
>> This message initiates working group Last Call for the "LDAP Schema 
>> for X.509 Certificates"
>> specification. The editors have confirmed that all working group 
>> issues have been resolved.
>>
>> The URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt 
>>
>>
>> This specification has also been forwarded to the LDAP Directorate for 
>> a parallel review.  Assuming successful Last Call and concurrence from 
>> the LDAP Directorate, this document will be forwarded to the ADs for 
>> consideration as an Informational track RFC.
>>
>> Last Call will run for (at least) two weeks. That is, Last Call will 
>> not close before November 29.
>>
>> Thanks,
>>
>> Tim Polk
> 
> 
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPJMqVV089745; Thu, 25 Nov 2004 11:22:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAPJMqnK089741; Thu, 25 Nov 2004 11:22:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon1-mail-1.visp.demon.net (IDENT:[e-mail] [193.195.70.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAPJMZ05089154 for <[e-mail]>; Thu, 25 Nov 2004 11:22:40 -0800 (PST) (envelope-from [e-mail])
Received: from [80.4.87.77] (cpc4-hudd3-5-0-cust77.hudd.cable.ntl.com [80.4.87.77]) by lon1-mail-1.visp.demon.net (MOS 3.4.6-GR) with ESMTP id BVN08261 (AUTH [e-mail]); Thu, 25 Nov 2004 19:21:22 GMT
Message-ID: <[e-mail]>
Date: Thu, 25 Nov 2004 19:21:21 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andrew Sciberras <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: CRL Schema
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Andrew



Andrew Sciberras wrote:
> Hi,
> 
> In Section 2 - 'DIT Structure and Naming', the x509CRLentryNameForm
> Name Frm is defined.
> This makes reference to an attribute called x509serial. Is this
> supposed to read x509serialNumber?
> 


yes you are correct. This is a typo. It should refer to x509serialNumber 
defined in the PKC schema ID. ie.
it is the serial number of the revoked certificate whose entry this is.

> An entry with a x509CRLentry Object Class must contain an
> x509serialNumber attribute within the entry. This attribute must be
> used as a naming attribute as well. CRL's can contain many revoked
> certificate serial numbers. 

Correct, and you can choose to represent each revoked certificate as a 
separate entry, of type x509CRLentry object class.

So, why would you use a serial number to
> form the RDN? 

You are getting confused. This is not the name of the CRL object. CRL 
objects are named with the x509CRLThisUpdate attribute, which is unique 
for each CRL. This is the name of the CRL entry object, and there is 
optionally one of these for each revoked certificate.

regards

David


Do you simply pick one revoked serial number at random
> to use as the distinguished value?
> OR, is this serial number refering to the serial number of the issued
> CRL? Which is counter to the description of x509serialNumber provided
> in Section 4...


> 
> Regards,
> Andrew Sciberras,
> 
> 
> On Mon, 15 Nov 2004 17:26:40 -0500, Tim Polk <[e-mail]> wrote:
> 
>>
>>This message initiates working group Last Call for the "LDAP Schema for
>>X.509 CRLs" specification. The editors have confirmed that all working
>>group issues have been resolved.
>>
>>The URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-03.txt
>>
>>This specification has also been forwarded to the LDAP Directorate for a
>>parallel review.  Assuming successful Last Call and concurrence from the
>>LDAP Directorate, this document will be forwarded to the ADs for
>>consideration as an Informational track RFC.
>>
>>Last Call will run for (at least) two weeks. That is, Last Call will not
>>close before November 29.
>>
>>Thanks,
>>
>>Tim Polk
>>
>>
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMGq4ZV023086; Mon, 22 Nov 2004 08:52:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAMGq4uD023085; Mon, 22 Nov 2004 08:52:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMGq3V0023068 for <[e-mail]>; Mon, 22 Nov 2004 08:52:04 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1CWHQ3-000D00-JV; Mon, 22 Nov 2004 16:52:03 +0000
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 2004 16:52:04 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
CC: "David A. Cooper" <[e-mail]>
Subject: Re: RFC3280bis: policy processing.
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Henson wrote:

> 
> 
> When I looked at this before I also looked at X509 and cross
> referenced the X509 algorithm wording (which uses different
> structures) to the RFC3280 form.
> 
> I finally decided that it was 6.1.4(b)(1) that was at fault and 
> duplicate nodes weren't permitted but it was late and I was tired
> when I looked at it...
> 
> I'll check through my notes to see if I can find the precise sections
> of X509 that lead me to that conclusion.
> 

While I was checking the X509 policy processing against the RFC3280
version I've noticed what I believe to be a discrepancy between the two.

In RFC3280 the policy mapping processing is described in 6.1.4 b(1) as:

> (1)  If the policy_mapping variable is greater than 0, for each node
> in the valid_policy_tree of depth i where ID-P is the valid_policy,
> set expected_policy_set to the set of subjectDomainPolicy values that
> are specified as equivalent to ID-P by the policy mapping extension.
> 
> If no node of depth i in the valid_policy_tree has a valid_policy of
> ID-P but there is a node of depth i with a valid_policy of anyPolicy,
> then generate a child node of the node of depth i-1 that has a
> valid_policy of anyPolicy as follows:

Whereas the corresponding text in X509 is in 10.5.2 d):

> process any policy mappings extension by, for each mapping identified
> in the extension, locate all rows in the 
> authorities-constrained-policy-set table whose [path-depth] column
> entry is equal to the issuer domain policy value in the extension,
> and write the subject domain policy value from the extension in the
> [path-depth+1] column entry of the same row. If the extension maps an
> issuer domain policy to more than one subject domain policy, then the
> affected row must be copied and the new entry added to each row. If
> the value in authoritiesconstrained- policy-set[0, path-depth] is
> any-policy, then write each issuer domain policy identifier from the 
> policy mappings extension in the [path-depth] column, making
> duplicate rows as necessary and retaining qualifiers if they are
> present, and write the subject domain policy value from the extension
> in the [pathdepth+ 1] column entry of the same row.

Translating this into RFC3280 terms it appears the processing of 
anyPolicy is different.

In RFC3280 a new node is added only if a node of depth i doesn't exist 
with a valid policy of ID-P.

In X509 it appears to be saying a new node is added unconditionally.

I believe this difference could result in different outputs from the 
algorithm. In particular the X509 processing will (significantly) result 
in nodes whose parent is anyPolicy which will not appear in the RFC3280 
version.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMGa0UT015630; Mon, 22 Nov 2004 08:36:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAMGa0MY015629; Mon, 22 Nov 2004 08:36:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMGZriI015560 for <[e-mail]>; Mon, 22 Nov 2004 08:35:53 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iAMGYrZv062157; Mon, 22 Nov 2004 16:34:54 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041122074630.02e0cec8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Mon, 22 Nov 2004 08:35:25 -0800
To: Peter Gietz <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Cc: Andrew Sciberras <[e-mail]>, Steve Hanna <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], David Chadwick <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 05:29 AM 11/22/2004, Peter Gietz wrote:
>I only know about a project that had tried to implement component matching in OpenLDAP, but that changed to our solution, before getting it done, because it was too difficult.  May be Kurt knows more. 

Too difficult to be done by those who are not closely
working with server developers...  we had a research intern
(who previously had no LDAP/OpenLDAP experience), working
under the direction of a research engineer (who has solid
LDAP/OpenLDAP experience) and myself, implement GSER &
component matching support in OpenLDAP Software over the
summer.  We're presently finishing the indexing support for
component level searches.

As the implementation is open source, including the ASN.1
compiler, any vendor who chooses to support GSER and
component matching can leverage the existing running code.

Implementing component level matching in the server, I
would argue, is on the same level of complexity as
implementing a "general-purpose parsing server", as both
require ASN.1 awareness.  Implementing in an existing
DSA is a bit harder, just because of integration issues
Now, if your DSA is already ASN.1, such as many which
support DAP, then most of the hard work is already done.

Client libraries need no special code to handle component
matching.  The client just needs to pass in an RFC 2254
filter string which expresses the assertion.  And, if
return of matched values is desired, the client can use
the library support for generating and attaching the
necessary control.

And while client libraries don't need any special support
to handle the value extraction approach, clients must be
specifically designed for the value extraction approach.
Managing (for both read and write) multiple entries for a
user and her certificates is far more complex than managing
a single entry.  And, given that existing applications
expect there to be only a single entry, this approach may
lead to some breakage, especially given this:

>   If certificates are stored redundantly in person entries and in
>   certificate entries below the person entries, maintainers of
>   repositories MUST make sure that the same certificates are stored in
>   the person entry and the respective certificate entries and keep this
>   consistency.  Alternatively, they MUST leave out any certificates in
>   the person entry.

I would argue that if maintainers cannot ensure consistency,
they should not create the value extraction entries.

Kurt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMDTKCO017294; Mon, 22 Nov 2004 05:29:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAMDTKxr017293; Mon, 22 Nov 2004 05:29:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.daasi.de (rhea.directory.dfn.de [134.2.217.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMDTEai017168 for <[e-mail]>; Mon, 22 Nov 2004 05:29:14 -0800 (PST) (envelope-from [e-mail])
Received: by smtp.daasi.de (Postfix, from userid 1009) id 5A0E4C09C; Mon, 22 Nov 2004 14:29:13 +0100 (CET)
Received: from daasi.de (marie.directory.dfn.de [134.2.217.72]) by smtp.daasi.de (Postfix) with ESMTP id 83273C0EE; Mon, 22 Nov 2004 14:29:07 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 2004 14:29:07 +0100
From: Peter Gietz <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andrew Sciberras <[e-mail]>
Cc: Steve Hanna <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], David Chadwick <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]>	 <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE, USER_AGENT version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Andrew Sciberras wrote:

>Hi Peter,
>
>I actually agree with Steve since we support Component Matching,
>however I am a bit confused about your response...
>
>On Fri, 19 Nov 2004 13:33:04 +0100, Peter Gietz <[e-mail]> wrote:
>  
>
>>Steve,
>>
>>Thanks for your comments although our opinions differ. Here is my reply:
>>
>>Steve Hanna wrote:
>>
>>    
>>
>>>Here are my comments on draft-ietf-pkix-ldap-*schema.
>>>
>>>These schemas are too complex and incompatible with
>>>existing clients. The costs exceed the benefits.
>>>      
>>>
>>I don't think so and will try to explain why.
>>
>>
>>
>>    
>>
>>>The main supposed benefits of your solution are:
>>>
>>>1) Easier to search for certs
>>>
>>>   Since certificate fields are stored as attributes
>>>   of LDAP entries, clients can easily search for
>>>   certificates by certificate field values. However,
>>>   there are already two good ways to do this: the
>>>   CertificateAssertion (defined in X.509 and
>>>   draft-zeilenga-ldap-x509-00.txt) and Component
>>>   Matching (RFC 3687). You argue that these will
>>>   take a while to be deployed, but so would your
>>>   solution. We don't need a third option.
>>>
>>>      
>>>
>>The advantage of our solution is that you don't have to change any
>>software, provided clients support configurable search filters,
>>and that should be standard anyway and most generic ldap clients support
>>that.  
>>    
>>
>
>What do you expect will be creating the entries and populating the
>attributes defined within this schema? Client applications are going
>to have to intelligently rip apart a certificate into its ASN.1
>components and populate the Directory with information. This, as I see
>it, would require changes to software. Unless of course the entry
>modifications will be done as a manual process by a person every time
>a certificate is stored within the directory.
>  
>
Ok I was only talking about the LDAP server-client  communication, not 
about data management. But there are several possibilities how to 
implement our schema.

- We have a perl-Script that analyses certificates and creates an LDIF 
file with the appropriate schema. This can and will be published as Open 
Source

- David Chadwick has developped an OpenLDAP proxy that does such a 
conversion totally transparent: add a usercertificate to server 1 and an 
entry with our schema will be automatically created on Server 2.

- I know of at least two other parties that have  developed similiar 
software  to create apropriate LDIFs.

- you can quite easily develop similiar software that, e.g. parses the 
output of OpenSSL

- if you have little data amounts, the manual creation is also an option.


>  
>
>>Implementation of Component Matching will be much more burdensom
>>since ASN.1 parsing is far more complicated and AFAICS only one server
>>product is ASN.1 aware today. With all other products a redesign would
>>have to be done to support Component Matching.
>>    
>>
>
>Only 1 ASN.1 aware server... this doesn't quite sound right to me. 
>  
>
Well lets put it that way ASN.1 awareness would help a lot for 
implementing Component Matching.
My information about the development status of Component Matching might 
be a bit outdated. Thats why I asked the following:

>>May be some vendors could make a statement about their plans for
>>supporting Component Matching to get a better view on this.
>>    
>>
>
>  
>

>Our server, the eB2Bcom View500 server, supports component matching. I
>also think that OpenLDAP can or intends to support it, although Kurt
>Z. could probably comment on this more accurately.
>
>  
>
I only know about a project that had tried to implement component 
matching in OpenLDAP, but that changed to our solution, before getting 
it done, because it was too difficult. May be Kurt knows more.

Cheers,

Peter


>Cheers,
>Andrew Sciberras.
>
>
>  
>


-- 
_______________________________________________________________________
 
Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]  
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAM4CTcB008246; Sun, 21 Nov 2004 20:12:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAM4CTcs008245; Sun, 21 Nov 2004 20:12:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAM4CQiJ008189 for <[e-mail]>; Sun, 21 Nov 2004 20:12:26 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAM4COHV417236 for <[e-mail]>; Sun, 21 Nov 2004 23:12:28 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAM4COBj280828 for <[e-mail]>; Sun, 21 Nov 2004 23:12:24 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAM4COPH012205 for <[e-mail]>; Sun, 21 Nov 2004 23:12:24 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAM4COJH012199; Sun, 21 Nov 2004 23:12:24 -0500
In-Reply-To: <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: pkix <[e-mail]>, Wen-Cheng Wang <[e-mail]>
MIME-Version: 1.0
Subject: Re: 3280bis issue:  checking keyCertSign bit in path validation
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Sun, 21 Nov 2004 23:12:20 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF2 (6.53IBM1)|October 29, 2004) at 11/21/2004 23:12:23, Serialize complete at 11/21/2004 23:12:23
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        David:

        Wasn't the absence of this particular requirement a contributing 
factor to a serious problem once (the one where a well-known piece of RP 
software let EE certificates act as intermediate CA's)?  Verification does 
not need to check every possible requirement in the profile, but this one 
is actually important to RP's.  Indeed, isn't this a slightly better check 
than basicConstraints, because a dedicated CRL signing certificate will 
have basicConstraints.CA true but won't have keyCertSign?

                Tom Gindin






"David A. Cooper" <[e-mail]>
Sent by: [e-mail]
11/19/2004 11:28 AM
 
        To:     Wen-Cheng Wang <[e-mail]>
        cc:     pkix <[e-mail]>
        Subject:        Re: 3280bis issue:  checking keyCertSign bit in 
path validation


I do not believe that this is a place where 3280bis needs to change.

There are many places in which RFC 3280 imposes requirements for the 
issuance of certificates that are not imposed by X.509.  But, RFC 3280 
does not include corresponding checks in section 6 because RFC 3280 does 
not attempt to declare that a certificate (or certification path) that 
would be valid under X.509 is invalid simply because the certificate was 
not issued in accordance with the RFC 3280.

This shows up in a number of places.  For example:
1.      X.509 states that the certificate serial number is an integer;  
RFC 3280 requires CAs to use only non-negative integers that are at most 
20 octets long.
2.      X.509 states that the basicConstraints extension may be critical 
or non-critical; RFC 3280 requires that the extension be critical in 
intermediate (CA) certificates.
In the case of keyUsage,  RFC 3280 imposes the requirement that you quote 
below, X.509 does not.  If the keyUsage extension is not present in a 
certificate, then no restrictions are imposed on the use of the 
certificate (i.e., it would be the same as if the extension were present 
and all bits were set to 1).

Note that keyUsage is different from basicConstraints, where there is both 
an issuing and validation requirement.  That is, a version 3 certificate 
with no basicConstraints extension is effectively the same as a version 3 
certificate with a basicConstraints extension with cA=FALSE.  X.509 
states:
NOTE 1 - If [the basicConstraints] extension is not present, or is flagged 
non-critical and is not recognized by a certificate-using system, then the 
certificate is to be considered an end-entity certificate and cannot be 
used to verify certificate signatures.
So, X.509 imposes a requirement for the basicConstraints extension to be 
present in version 3 intermediate certificates, but it does not impose 
such a requirement for any other extensions.  The language in section 6 of 
RFC 3280 is based on this.

Dave

Wen-Cheng Wang wrote:
RFC 3280 4.1.2.3 mandate that a intermediate CA certificate
MUST contain the keyUsage extension with keyCertSign bit set.

The text says:

   This extension MUST appear in certificates that contain public
   keys that are used to validate digital signatures on other public key
   certificates or CRLs.

However, RFC 3280 path validation algorithm does not
check the existence of the the keyUsage extension properly.

In RFC 3280 6.1.4 step (n), it says:

   If a key usage extension is present, verify that the
   keyCertSign bit is set.

That seems to imply if there is no keyUsage extension
exists in the intermediate CA certificats, then there is nothing
to check. As a result, the path validation algorithm will
accept a CA certificate without keyUsage extension.

I think RFC 3280 6.1.4 step (n) should be changed to:

   If the version of the certificate is v3, verify that a key usage 
extension
   is present and the keyCertSign bit is set.

That means:

For v1 intermeniate certificate, there is nothing to check. However, for 
v3
intermediate certificate, it must contain a key usage extension and
the keyCertSign bit is set.

Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAM47Dqu001858; Sun, 21 Nov 2004 20:07:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAM47D0D001855; Sun, 21 Nov 2004 20:07:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAM47C1i001690 for <[e-mail]>; Sun, 21 Nov 2004 20:07:12 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAM4780V318646 for <[e-mail]>; Sun, 21 Nov 2004 23:07:08 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAM478Bj227680 for <[e-mail]>; Sun, 21 Nov 2004 23:07:08 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAM478wg009547 for <[e-mail]>; Sun, 21 Nov 2004 23:07:08 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAM478a4009542; Sun, 21 Nov 2004 23:07:08 -0500
In-Reply-To: <013c01c4ce1f$7f2844b0$4f85900a@wcwang>
To: "Wen-Cheng Wang" <[e-mail]>
Cc: "pkix" <[e-mail]>
MIME-Version: 1.0
Subject: Re: 3280bis issue:  issues related to self-issued certificates
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Sun, 21 Nov 2004 23:07:02 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF2 (6.53IBM1)|October 29, 2004) at 11/21/2004 23:07:06, Serialize complete at 11/21/2004 23:07:06
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        In general, the issue is whether "CA certificates" include 
dedicated CRL signing certificates whose DN is that of a CA and other 
similar cases such as CMP certificates.  If we need any new term for this, 
it's probably something like "issuer certificate" or "certificate issuance 
certificate".  I went through RFC 3280 quickly looking for all uses of "CA 
certificate" and classifying them in more detail.
        Anyway, this issue is not wholly theoretical or legalistic.  There 
are several practical effects: first, should the CA flag in the BC 
extension be set for CRL signing certs and CMP certs; second, should such 
certs go into the caCertificate directory attribute or into 
userCertificate (and remember that userCertificate is not a member of the 
pkiCA object class, which argues against putting them into 
userCertificate); last, should such certs go into the crossCertificatePair 
attribute if they are not self-issued?  The answers to these three are 
probably tied together, and we should find out what current 
implementations do.
        Here are the references I found in RFC 3280, by section:
4.2.1.2 Reference to BasicConstraints (thus belonging to a CA)
4.2.1.5 Issuer (1st), Cross Certificate (2nd)
4.2.1.6 Issuer (1st), not EE (2nd)
4.2.1.10        Belonging to a CA
4.2.11  Issuer
4.2.2.1 Not EE (1st), not clear - contained in CCPair (2nd)
4.2.2.2 Not EE but misworded - somebody needs to fix this reference ("may 
be included in subject or CA certificates").
5       Not clear and not important
5.1.1.3 Belonging to a CA
5.2.5   Not EE
6.1.2 k Issuer
6.1.4 k Issuer
6.3.2   Belonging to a CA
9       Issuer
C.1 h   Reference to BasicConstraints (thus belonging to a CA)

        In X.509, most of the text suggests that CA-certificate is only 
for Issuers, but 11.2.2 says that the CACertificate attribute should 
contain self-issued certificates.
        Responses to your requests for definitions are in-line.

                Tom Gindin






"Wen-Cheng Wang" <[e-mail]>
11/19/2004 05:06 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     "pkix" <[e-mail]>
        Subject:        Re: 3280bis issue:  issues related to self-issued 
certificates


Tom,

Yes, I do mean certificates of type (b) are self-issued
intermediate certificates. Thanks for correcting my typo.

And, you are right, RFC 3280 4.2.1.10 implies that type (c)
MAY contain a basicConstraints extension with cA = TRUE.
It even implies that type (d) MAY also contain a basicConstraints
extension with cA = TRUE, which are CMP certificates you
refered.

However, after rereading RFC 3280, my feeling is the
definition of the term "CA certificate" is not clear enough.
The meaning of the term "CA certificate" is not consistent
all over the text of RFC 3280.

For example:

RFC 3280 4.2.1.2 says
   To facilitate certification path construction, this extension MUST
   appear in all conforming CA certificates, that is, all certificates
   including the basic constraints extension (section 4.2.1.10) where
   the value of cA is TRUE.

That seems to imply "CA certificates" are "certificates contain the
basicConstraints extension with cA = TRUE". This also implies
that "certificates that do not conatin the basicConstraints extension
with cA = TRUE" are not "CA certificates". (i.e., they are EE
certificates.)

However, RFC 3280 4.2.1.10 says
   This extension (basicConstraints) MAY appear as a critical
   or non-critical extension in CA certificates that contain public keys
   used exclusively for purposes other than validating digital
   signatures on certificates.

That imply "CA certificates" need not conatin "the basicConstraints
extension with cA = TRUE" as long as the keyCertSign bit is not set
in the keyUsage extension it contains (if any).

Actually, I found the X.509 standard itself has some conflicts
about the definition of "CA certificates".

X.509 (2000) 3.3.9 says
   CA-certificate:  A certificate for one CA issued by another CA.

It seems that the term "CA certificate" is simple a synonym of
"cross certificate".

However, X.509 (2000) chapter 7 says
   A CA-certificate is a certificate issued by a CA to a subject that is
   itself a CA and therefore is capable of issuing public-key 
certificates.
   CA-certificates can be themselves categorized by the following types:
     - Self-issued certificate - ...
     - Self-signed certificate - ... 
     - Cross certificate - ...

That means a CA certificate not only can be "a certificate for one CA
issued by another CA" (a cross certificate) but also can be "a
certificate for one CA issued by the CA itself" (a self-issued certificate 
or
a self-signed certificate).

In both X.509 and RFC 3280, mostly the term "a CA certificate" actually
means "a CA certificate with keyCertSign key usage".

For example,

X.509 (2000) 8.2.2.7 (Policy mappings extension) says

   This field, which shall be used in CA-certificates only, ...

RFC 3280 4.2.1.6 (Policy Mappings) says
   This extension is used in CA certificates. ...

In these cases, by "CA certificates" they actually mean
"a CA certificate with keyCertSign key usage" since policy
mappings extension should not appear in a CA certificates
without keyCertSign key usage.

The current usages of the term "CA certificate" in both X.509
and RFC 3280 are not precise enough. As a result, when we
see the term "CA certificate" in X.509 and RFC 3280, we have
to guess its meaning from the context.  It might mean a
Root CA certificate, a cross certificate, an self-issued
intermediate certificate (with keyCertSign key usage ),
a self-issued certificate with cRLSign key usage only, or
a self-issued certificate with key usages other than keyCertSign
and  cRLSign.

To make the useage of the term more precise, I suggest
RFC3280bis (and X.509 as well) should claerly define the
following terms:
  "self-issued certificate"
[TG] I think we have a definition.  If not, it's "a certificate whose 
issuer and subject are the same (or match)."
  "self-signed certificate"
[TG] A self-issued certificate which was signed using the private key 
whose public key appears in the body of the certificate.
  "self-issued intermediate certificate"
[TG] No such thing exists.
  "cross certificate"
[TG] A CA certificate (we can argue about whether it has to have 
keyCertSign set) issued by a different CA.  All CA certificates are either 
self-issued or cross certificates.
  "CA certificate"
[TG] This is the only one that causes real trouble.
  "root CA certificate (a.k.a. root certificate)"
[TG] Not easily defined, unless it's a self-signed certificate used to 
represent a trust anchor.
  "intermediate CA certificate (a.k.a. intermediate certificate)"
[TG] Does this exist outside the context of an RP or a chain?

For example, the term "intermediate CA certificate" might
be defined as follows:

   intermediate CA certificate:
         a cross certificate or a self-issued intermediate certificate

With this definition, the usages of the term "CA certificate" in
both X.509 and RFC 3280 can be more precise.

For example,

X.509 (2000) 8.2.2.7 (Policy mappings extension) can say

   This field, which shall be used in intermediate CA-certificates only, 
...

RFC 3280 4.2.1.6 (Policy Mappings) says
   This extension is used in intermediate CA certificates. ...

Especially, I think we should distinguish between root CA certificates
and intermediate CA certificates because there are many extensions
that should not appear root CA certificates.

As for the distinction of different type of self-signed certificates:
Yes, I think it is better to distinguish between self-signed certs used as 

CA roots and all other self-signed certs. That is why I suggest
the term "root CA certificate" or "root certificate" should be defined.

As for the security problem of CRL signing key compromised, I
do not think "Issue a new CRL signing key and revoke the old one"
can help for solving the problem. Please see the following case:

TA->CA1(keyCertSign Key)->CA1(crlSign Key 1)------>CRL1
TA->CA1(keyCertSign Key)->CA1(crlSign Key 2)------>CRL2

which means the crlSign Key 1 of CA1 is compromised and
CA1 changes to use the crlSign Key 2 for signing CRL.

Since the RP will not check the revocation status of crlSign Key 1,
the path "TA->CA1(keyCertSign Key)->CA1(crlSign Key 1)" will
still look valid from the viewpoint of the RP. Therefore, the RP
will accept CRL1 (signed by crlSign Key 1), which might be
a foged CRL. The RP will never that it should check CRL2 (signed
by crlSign Key 2) for the revocation status of crlSign Key 1.

Wen-Cheng Wang

----- Original Message ----- 
From: "Tom Gindin" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>
Cc: "David A. Cooper" <[e-mail]>; "pkix" <[e-mail]>
Sent: Thursday, November 18, 2004 8:36 PM
Subject: Re: 3280bis issue: issues related to self-issued certificates


> 
>         Wen-Cheng:
> 
>         Do we also need to distinguish between self-signed certs used as 

> CA roots (either v1 or those with keyCertSign set) and all other 
> self-signed certs?
>         Responses below.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Wen-Cheng Wang" <[e-mail]>
> Sent by: [e-mail]
> 11/17/2004 05:36 AM
> 
>         To:     "David A. Cooper" <[e-mail]>, "pkix" 
> <[e-mail]>
>         cc: 
>         Subject:        3280bis issue:  issues related to self-issued 
> certificates
> 
> 
> 
> The definition of the term "self-issued certificate" is too vague.
> 
> The current text of RFC 3280 only mention
> 
> "A certificate is self-issued if the DNs that appear in the subject
>  and issuer fields are identical and are not empty....a CA may
>  issue a certificate to itself to support key rollover or changes in
>  certificate policies.  These self-issued certificates are not counted
>  when evaluating path length or name constraints."
> 
> However, there are many kinds of self-issued certificates. For
> example:
> 
> (a) self-signed certificates (this is a special case of self-issued 
> certificate)
> (b) self-issued certificates with keyCertSign key usage (might with 
> cRLSign key usage as well)
> (c) self-issued certificates with cRLSign key usage only (a CA using 
> separate key for CRL signing)
> (d) self-issued certificates with key usages other than keyCertSign and 
> cRLSign
> 
> Self-issued certificates of type (c) are also known as "self-issued
> intermediate certificates" according to the X.509 (2000) standard.
> Obviously, only self-issued certificates of type (c) are thought to
> be CA certificates. However, they are special CA certificates
> for special purpose (e.g., Key Rollover) so that they do not contribute
> to the path length for purposes of processing some constraint
> extension and name constrains extension in certification path 
validation.
> 
> 
> [TG] You do mean type (b), don't you?
> 
> Self-issued certificates of type (a), (c) and (d) can not be
> intermediate certificates and thus the above special processing
> rule does not apply to them. This is not crystal clear in the current
> text of RFC 3280.
> 
> Obviously, self-issued certificates of type (a) and (b) should conatins
> a basicConstraints extension with cA = TRUE since they are
> CA certificates.
> 
> It is not clear whether self-issued certificates of type (c) should
> also conatins a basicConstraints extension with cA = TRUE.
> 
> [TG] RFC 3280 4.2.1.10 says MAY, and it classifies CMP certificates with 

> them.
> 
> Self-issued certificates of type (d) should be thought as EE
> certificates, therefore they should not contain  a basicConstraints
> extension with cA = TRUE. However, some PKIX WG members
> might not agree to this interpretation.
> 
> When perform path validation, it is not clear what will be the effect
> if some certificate extensions such as polcyMappings, policyConstraints,
> nameConstraints, and inhibitAnyPolicy appear in self-issued 
> intermediate certificates (i.e., self-issued certificate of type (b)).
> The current text only says that this type of self-issued certificates do 

> not
> contribute to the path length for purposes of processing some constraint
> extension and name constrains extension in certification path 
validation,
> it is not clear that whether these extensions can appear in this type of
> self-issued certificate.
> 
> There is a serious security problem related to revocation status
> checking for self-issued certificates of type (b) and (c).
> For type (b), it might be a CA key rollover situation, and if the CA 
> stopped
> using its old key to issue CRL, then there is no way to check the 
> revocation
> status of the new self-issued certificate unless there is another way 
> (e.g.,
> OCSP or other out-of-band mechanism) to check its revocation status.
> If the new key is unfortunately compromised later, this will be a 
serious
> security problem.
> 
> For type (c), since the CA is using separate key for CRL signing and
> its Certificate with cRLSign key usage is signed by itself not signed
> by another CA. Therefore, no one can provide the revocation status
> info for that self-issued certificates unless there is another way 
(e.g.,
> OCSP or other out-of-band mechanism) to check its revocation status.
> If its CRL signing key is unfortunately compromised, this will be a 
> serious
> security problem.
> 
> [TG] Issue a new CRL signing key and revoke the old one.  The revocation 

> will take effect with the same timing effects as the revocation of an EE 

> certificate - an attacker can always replay a CRL until its expiration 
> time.
> 
> Finally, it is not clear that, when a RP choose to use X.500 string 
> matching
> rules (or StringPrep-based String matching rules), whether certificates 
> with
> identical non-empty issuer name and subjec name but with different 
string
> encoding (e.g., one in PrintableString while one in UTF8String) are also
> thought as self-issued certificates.
> 
> Wen-Cheng Wang
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAM2MSav048387; Sun, 21 Nov 2004 18:22:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAM2MSFt048386; Sun, 21 Nov 2004 18:22:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAM2MQkR048306 for <[e-mail]>; Sun, 21 Nov 2004 18:22:28 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06200769bdc6fc20335e@[10.20.30.249]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sun, 21 Nov 2004 18:22:29 -0800
To: [e-mail]
From: Paul Hoffman / VPNC <[e-mail]>
Subject: Re: CORRECTION: RFC 3280bis: Isses about UTF8
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:34 AM +0900 11/20/04, Ryu Inada wrote:
>0) The day of begin to issue UTF8 encoded certificate
>RFC 2459/3280 described that "The UTF8String encoding [RFC 2279]
>is the preferred encoding, and all certificates issued after
>December 31, 2003 MUST use the UTF8String."
>This statement made confuse in some countries include Japan.
>We want to change this statement or delete.

Deleting this is possible if the WG wishes, but doing so would be a 
major blow to getting anyone to pay attention to (much less 
interoperate with) non-ASCII names.

>1) Certificate Retrieval vs. Certificate Matching
>PKIX requires retrieving the certificate, like ldapsearch command.
>It is okay to the certificate retrieval such as a path building.
>But it does not meet to the certificate matching such as a path
>validation.
>DN comparison rule in the path validation MUST be boolean, match
>or not. In stringmatch I-D, it defines the state of matching
>result three state such as match, not match and undefined. It
>makes different result which verifier used.
>It makes confusion of trustiness in PKI world.
>So, we think to define separately the method of certificate
>retrieval and certificate matching.

This sounds like a good idea. Either adopt one path for retrieval and 
a different one for matching, or take "undefined" out of the string 
matching rules.

>2) Code point Matching vs. Byte order Matching
>There are some confusion exist on when an application compares the
>  different encoding type.
>It can compare them by the code point matching or the byte order
>matching.
>For example, if using the code point matching, 'ABC' encoded by
>UTF8String is same as 'ABC' encoded by BMPString. But, if using
>the byte order matching, 'ABC' encoded by UTF8String is not same
>as 'ABC' encoded by BMPString.
>So, 3280bis has to make which matching rule should be used.

Quite true, and it should clearly be "code point matching".

>3) Implementation Requirements for UTF8String
>3a) Requirement for UTF8String processing to the client
>applications
>PKI client application must handle the UTF8String in the
>certificate. At least the application should not reject UTF8
>encoded certificate.
>
>3b) Requirement for verifier (of course including SCVP server)
>PKI path validation module must process the UTF8String in the
>certificates as PKIX says.
>
>3c) Issuing requirements for the CA
>In our just personal opinion, to avoid the confusion of the
>application developers, CA MUST issue the *normalized* UTF8String
>certificates. CA MUST normalize the some strings using the
>UTF8String encoding before issuing the certificate. When CA cannot
>  normalize it by some reasons, CA MUST use the PrintableString for
>  the strings. This is an idea not to complicate the name
>comparison.
>The using the PrintableString should be allowed only temporarily.
>But I have no idea about how long requires to the switchover to
>the UTF8String.
>Anyway, if subject requires any characters out the PrintableString,
>  CA MUST use UTF8String encoding.

I like this up to the "PrintableString" part. That is, putting the 
emphasis on normalization before issuance is good because it will 
increase interoperability. However, falling back to PrintableString 
won't work for many languages. In fact, falling back to anything that 
has fewer characters than the full UCS set is probably a very bad 
idea. It is not clear what we should say here to CAs that cannot 
normalize.

--Paul Hoffman, Director
--VPN Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iALMRF34040353; Sun, 21 Nov 2004 14:27:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iALMRFdM040352; Sun, 21 Nov 2004 14:27:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iALMRENK040346 for <[e-mail]>; Sun, 21 Nov 2004 14:27:14 -0800 (PST) (envelope-from [e-mail])
Received: by rproxy.gmail.com with SMTP id g11so395816rne for <[e-mail]>; Sun, 21 Nov 2004 14:27:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=iOmaeZ5gH1BExvdTnDPJwo/Wa7MDlCQbe2DdtKCX8d/vEJlTRU3amIMXy6gFCRs8t22IYp/WWKB0GPBUB2reAGIT5wA4bJxp41TPiwsY8Hq/f3UGmgmPalc533ulPLDybL3LgGj/0Av422kLlY0hXzMIvBPIVRahYHLgeAoN4js=
Received: by 10.39.1.66 with SMTP id d66mr582771rni; Sun, 21 Nov 2004 14:27:19 -0800 (PST)
Received: by 10.38.81.56 with HTTP; Sun, 21 Nov 2004 14:27:18 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 2004 09:27:18 +1100
From: Andrew Sciberras <[e-mail]>
Reply-To: Andrew Sciberras <[e-mail]>
To: Peter Gietz <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Cc: Steve Hanna <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,

I actually agree with Steve since we support Component Matching,
however I am a bit confused about your response...

On Fri, 19 Nov 2004 13:33:04 +0100, Peter Gietz <[e-mail]> wrote:
> 
> Steve,
> 
> Thanks for your comments although our opinions differ. Here is my reply:
> 
> Steve Hanna wrote:
> 
> > Here are my comments on draft-ietf-pkix-ldap-*schema.
> >
> > These schemas are too complex and incompatible with
> > existing clients. The costs exceed the benefits.
> 
> I don't think so and will try to explain why.
> 
> 
> 
> >
> > The main supposed benefits of your solution are:
> >
> > 1) Easier to search for certs
> >
> >    Since certificate fields are stored as attributes
> >    of LDAP entries, clients can easily search for
> >    certificates by certificate field values. However,
> >    there are already two good ways to do this: the
> >    CertificateAssertion (defined in X.509 and
> >    draft-zeilenga-ldap-x509-00.txt) and Component
> >    Matching (RFC 3687). You argue that these will
> >    take a while to be deployed, but so would your
> >    solution. We don't need a third option.
> >
> The advantage of our solution is that you don't have to change any
> software, provided clients support configurable search filters,
> and that should be standard anyway and most generic ldap clients support
> that.  

What do you expect will be creating the entries and populating the
attributes defined within this schema? Client applications are going
to have to intelligently rip apart a certificate into its ASN.1
components and populate the Directory with information. This, as I see
it, would require changes to software. Unless of course the entry
modifications will be done as a manual process by a person every time
a certificate is stored within the directory.

> Implementation of Component Matching will be much more burdensom
> since ASN.1 parsing is far more complicated and AFAICS only one server
> product is ASN.1 aware today. With all other products a redesign would
> have to be done to support Component Matching.

Only 1 ASN.1 aware server... this doesn't quite sound right to me. 

> 
> May be some vendors could make a statement about their plans for
> supporting Component Matching to get a better view on this.

Our server, the eB2Bcom View500 server, supports component matching. I
also think that OpenLDAP can or intends to support it, although Kurt
Z. could probably comment on this more accurately.

Cheers,
Andrew Sciberras.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iALLT0qb007842; Sun, 21 Nov 2004 13:29:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iALLT0tp007841; Sun, 21 Nov 2004 13:29:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iALLShSh007708 for <[e-mail]>; Sun, 21 Nov 2004 13:28:44 -0800 (PST) (envelope-from [e-mail])
Received: by rproxy.gmail.com with SMTP id g11so390814rne for <[e-mail]>; Sun, 21 Nov 2004 13:28:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=a+orbSK4tU7GqtvGWQMJv0ZH8uBUQiAM9sryZ4AX9kQGQovWJDiTYlKM0ujm5AgkDCbimGO8x2B55EzDv6W9vhSZQ1Vqlb/T9QUF9+YnrmAGOWOjFB7TBbEwLemcnhb07tR6YRJjACu8zThsrvRj6loXZx4o29mL3gSElI+vM5k=
Received: by 10.38.90.35 with SMTP id n35mr566721rnb; Sun, 21 Nov 2004 13:28:47 -0800 (PST)
Received: by 10.38.81.56 with HTTP; Sun, 21 Nov 2004 13:28:47 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 22 Nov 2004 08:28:47 +1100
From: Andrew Sciberras <[e-mail]>
Reply-To: Andrew Sciberras <[e-mail]>
To: Peter Gietz <[e-mail]>
Subject: Re: Certificate Schema (Object Class)
Cc: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks Peter,

I think that the clarification is sufficient, as it would remove a
level of ambiguity within the text.

Cheers,
Andrew.

On Fri, 19 Nov 2004 13:49:22 +0100, Peter Gietz <[e-mail]> wrote:

> We had made the design decision to have a separate object class for the
> certificate extensions which is defined in the same document. I am
> willing to include a reference to that object class  here , e.g. :
> "... or x509subjectRegisteredID. These attributes are provided by the
> auxiliary object class x509PKCext specified in 4.5. which in this case
> is mandatory."
> 
> We could additionally specify a DIT content rule for this, if it makes
> things clearer. But I don't see a way to specify the condition "if
> x509subject is empty then" in such a rule.
> 
> Cheers,
> 
> Peter



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAK90hvc006722; Sat, 20 Nov 2004 01:00:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAK90hZU006721; Sat, 20 Nov 2004 01:00:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw ([202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAK90Yfc006534 for <[e-mail]>; Sat, 20 Nov 2004 01:00:38 -0800 (PST) (envelope-from [e-mail])
Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAK901bg026969; Sat, 20 Nov 2004 17:00:01 +0800
Received: (from root@localhost) by ms20.chttl.com.tw (8.12.10/8.12.10) id iAK900fa007553; Sat, 20 Nov 2004 17:00:00 +0800
Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAK8xxL1007262; Sat, 20 Nov 2004 16:59:59 +0800
Message-ID: <00ec01c4cedf$4f616bb0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Steve Hanna" <[e-mail]>, "David A. Cooper" <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <015d01c4ce27$c68703c0$4f85900a@wcwang> <[e-mail]> <[e-mail]>
Subject: Re: 3280bis issue:  checking keyCertSign bit in path validation
Date: Sat, 20 Nov 2004 16:59:57 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

You are right. There are two kinds of requirements (some of
them are actually recommendations). One kind of requirements
are to be imposed on CAs. The purpose of this kind of
requirements is to enforce all conforming CAs to issue
certificates and CRLs of the common format and therefore
help to achieve interoperability. The other kind of requirements
are to be imposed on RPs. The purpose of this kind of
requirements is to make sure the RPs can handle
certificates and CRLs issued by conforming CAs and
enforce security of their path validation.

Obviously, requirements in section 6 are for RPs. However,
not all requirements in other sections are for CAs. There
are requirements/recommendations in section 4 and 5 for
makeing sure conforming RPs can handle certificates and
CRLs issued by conforming CAs.

I agree that it is a good idea to add a statement in RFC
3280bis to say that the RPs has no obligation to check
equirements/recommendations imposed on CAs. However,
we should be more careful about wording. A "SHOULD NOT"
might be too strong. The validation algorithms specified
in RFC 3280 are simply a "basic" algorithms. As you mentioned,
the RPs are allowed to impose more strict requirements.
I do not see why RFC 3280 should discourage this.

Actually, I had even seen at least one implementation of path
validation algorithm that not only enforces to check the existence
of all mandatory extension fields but also even enforces to
check the criticality falg of the extension. Although the implementor
might misinterpret RFC 3280 so to impose such strict verification,
I think it not harmful as long as the implementation would
not accept "a certification path that would be invalid under RFC
3280".

Base on your recommendation of adding a clarification
statement in RFC 3280bis, I think we can also further try to
clearly distinguish "requirements/recommendations to be
imposed on CAs" and "requirements/recommendations
to be imposed on RPs". In fact, the current text of RFC 3280
already try to distinguish them. As you can see, many
requirements/recommendations in section 4 and 5 are
begin with "Conforming CA MUST/SHOULD/MAY..." or
"Applications MUST/SHOULD/MAY...". However, some
of the requirements/recommendations in section 4 and 5
do not clearly specify the target (CAs or RPs) to be
imposed on.

For example, RFC 3280 4.1.2.3 mandate that "This extension
MUST appear in certificates that contain public keys that are
used to validate digital signatures on other public key
certificates or CRLs." It is not crystal clear whether this
is only a requirements for CAs to issuing certificates or it is
also a requirement for RPs to check the extension.

The source of the ambiguity comes from that RFC3280 has
two kinds of target audiences and sometimes it is not crystal
clear which kind of audience is the statement for. A way to
solve this ambiguity is to further separate each section for a
basic field or a extension field into two sub-sections, namely
"recommendations and requirements for issuers" and
 "recommendations and requirements for applications", and
then put requirements/recommendations for different targets
into different sub-sections.

Another even better way to solve this ambiguity is to split
RFC3280 into two documents. One document will keep the title
"PKIX Certificate and CRL Profiles" but its content be changed
to be a "pure" profile (i.e. it should only specify "recommendations
and requirements for issuers" to make sure conforming issuers
will issue certificates and CRLs of the common format specified
by PKIX. The other document might be titled "PKIX Certification
Path Processing" and it will contains "recommendations and
requirements for applications", including path/CRL validation
algorithms, to make sure the RPs can handle certificates and
CRLs issued by conforming CAs and enforce security of their
path validation. However, split RFC3280 into two documents is
a big change, 3280bis team might think this is out of scope.
But I hope them take this into consideration.

Wen-Cheng Wang


----- Original Message ----- 
From: "Steve Hanna" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: "Wen-Cheng Wang" <[e-mail]>; "pkix" <[e-mail]>
Sent: Saturday, November 20, 2004 1:29 AM
Subject: Re: 3280bis issue: checking keyCertSign bit in path validation


> 
> David,
> 
> Maybe we should add a statement in 3280bis that
> says clearly that relying parties SHOULD NOT
> attempt to enforce every requirement or
> recommendation that RFC 3280 places on certificates.
> They SHOULD only enforce those that are required
> by the algorithm in section 6 or other requirements
> that they have determined are necessary for their
> particular situation.
> 
> I have heard several knowledgable people say that
> their code rejected a cert because it didn't comply
> with some requirement of RFC 3280 even though that
> requirement is not in section 6. While this sort
> of behavior for a relying party is not prohibited
> under RFC 3280, it should be discouraged. We don't
> need to have vigilantes running around rejecting
> certs because their serial number is too long!
> 
> Thanks,
> 
> Steve
> 
> David A. Cooper wrote:
> 
> > I do not believe that this is a place where 3280bis needs to change.
> > 
> > There are many places in which RFC 3280 imposes requirements for the 
> > issuance of certificates that are not imposed by X.509.  But, RFC 3280 
> > does not include corresponding checks in section 6 because RFC 3280 does 
> > not attempt to declare that a certificate (or certification path) that 
> > would be valid under X.509 is invalid simply because the certificate was 
> > not issued in accordance with the RFC 3280.
> > 
> > This shows up in a number of places.  For example:
> > 
> >    1.
> > 
> >       X.509 states that the certificate serial number is an integer; 
> >       RFC 3280 requires CAs to use only non-negative integers that are
> >       at most 20 octets long.
> > 
> >    2.
> > 
> >       X.509 states that the basicConstraints extension may be critical
> >       or non-critical; RFC 3280 requires that the extension be critical
> >       in intermediate (CA) certificates.
> > 
> > In the case of keyUsage,  RFC 3280 imposes the requirement that you 
> > quote below, X.509 does not.  If the keyUsage extension is not present 
> > in a certificate, then no restrictions are imposed on the use of the 
> > certificate (i.e., it would be the same as if the extension were present 
> > and all bits were set to 1).
> > 
> > Note that keyUsage is different from basicConstraints, where there is 
> > both an issuing and validation requirement.  That is, a version 3 
> > certificate with no basicConstraints extension is effectively the same 
> > as a version 3 certificate with a basicConstraints extension with 
> > cA=FALSE.  X.509 states:
> > 
> >     NOTE 1 - If [the basicConstraints] extension is not present, or is
> >     flagged non-critical and is not recognized by a certificate-using
> >     system, then the certificate is to be considered an end-entity
> >     certificate and cannot be used to verify certificate signatures.
> > 
> > So, X.509 imposes a requirement for the basicConstraints extension to be 
> > present in version 3 intermediate certificates, but it does not impose 
> > such a requirement for any other extensions.  The language in section 6 
> > of RFC 3280 is based on this.
> > 
> > Dave
> > 
> > Wen-Cheng Wang wrote:
> > 
> >>RFC 3280 4.1.2.3 mandate that a intermediate CA certificate
> >>MUST contain the keyUsage extension with keyCertSign bit set.
> >>
> >>The text says:
> >>
> >>   This extension MUST appear in certificates that contain public
> >>   keys that are used to validate digital signatures on other public key
> >>   certificates or CRLs.
> >>
> >>However, RFC 3280 path validation algorithm does not
> >>check the existence of the the keyUsage extension properly.
> >>
> >>In RFC 3280 6.1.4 step (n), it says:
> >>
> >>   If a key usage extension is present, verify that the
> >>   keyCertSign bit is set.
> >>
> >>That seems to imply if there is no keyUsage extension
> >>exists in the intermediate CA certificats, then there is nothing
> >>to check. As a result, the path validation algorithm will
> >>accept a CA certificate without keyUsage extension.
> >>
> >>I think RFC 3280 6.1.4 step (n) should be changed to:
> >>
> >>   If the version of the certificate is v3, verify that a key usage extension
> >>   is present and the keyCertSign bit is set.
> >>
> >>That means:
> >>
> >>For v1 intermeniate certificate, there is nothing to check. However, for v3
> >>intermediate certificate, it must contain a key usage extension and
> >>the keyCertSign bit is set.
> >>
> >>Wen-Cheng Wang
> >>
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAK6pq2d024559; Fri, 19 Nov 2004 22:51:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAK6pq6I024558; Fri, 19 Nov 2004 22:51:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw ([202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAK6pjup024463 for <[e-mail]>; Fri, 19 Nov 2004 22:51:48 -0800 (PST) (envelope-from [e-mail])
Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAK6pkgV019173; Sat, 20 Nov 2004 14:51:46 +0800
Received: (from root@localhost) by ms20.chttl.com.tw (8.12.10/8.12.10) id iAK6pkvO020424; Sat, 20 Nov 2004 14:51:46 +0800
Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAK6pjL1020355; Sat, 20 Nov 2004 14:51:46 +0800
Message-ID: <00de01c4cecd$657af130$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <015d01c4ce27$c68703c0$4f85900a@wcwang> <[e-mail]>
Subject: Re: 3280bis issue:  checking keyCertSign bit in path validation
Date: Sat, 20 Nov 2004 14:51:43 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DB_01C4CF10.7362AED0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00DB_01C4CF10.7362AED0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dave,

It is quite natural for a profile to impose more strict recommendation, =
requirements
and security considerations that the standard it is based on.
Since the role of RFC 3280 is to be a profile of X.509, it is supposed =
to be more strict
than what X.509 imposes. Not only on the format of certificates and CRLs =
but also
on the validation algorithm. Therefore, I do not think "a certification =
path that would
be valid under X.509 is invalid under RFC 3280" is a problem. On the =
contrary, I do
think "a certification path that would be invalid under X.509 is valid =
under RFC
3280" will be a problem.

When designing the RFC 3280 path validation algorithm, PKIX WG should
not take "what X.509 says about this" as the only the factor of =
considerations.
Another more important factor is the scurity consideration. And if =
following
more strict scurity considerations, PKIX WG finally conclude that it is =
a flaw
in X.509, then PKIX WG should feed back a defect report to X.509
liaison.

Maybe I should not quote the text from RFC 3280 4.1.2.3, because it =
seems
that my quotation misled the direction of dicussion. Instead, I should =
mention
that the meaning of a v3 certificate without the keyUsage extension is =
not
clear. Both RFC 3280 and X.509 do not have clear interpretation about =
this.
That is my intention. Honestly, my current implementation of path =
validation
algorithm accepts v3 certificates without the keyUsage extension too, =
because
I want my implementation be faithful with respect to RFC 3280. However,
accepting v3 certificates without the keyUsage extension really make me
nervous because the implication is unclear. What if my path validation
implementation accept a certificate of which the subject public key is =
not
supposed to be used for verifying the signature on public key =
certificates?

There may be two kinds of interpretation for a v3 certificate without =
the
keyUsage extension:

The first one is what you mentioned:
   If the keyUsage extension is not present in a v3 certificate, then
   it would be the same as if the extension were present and all bits
   were set to 1. That is, no restrictions are imposed on the key usage
   of the certificate.

The second one is:
   If the keyUsage extension is not present in a v3 certificate, then
   it would be the same as if the extension were present and all bits
   were set to 0. That is, the key is intended for some purpose other
   than those listed in the KeyUsage type.

If we decide to adopt the first interpretation and are sure that
such interpretation will not cause any security problem, then I
will accept the current text of RFC 3280. However, if we decide
to choose the second interpretation, then obviously  the current
text of RFC 3280 needs to be changed.

Please note that X.509 (2000) 8.2.2.3 says:
   A bit set to zero indicates that the key is not intended for that =
purpose.
   If all bits are zero, it indicates the key is intended for some =
purpose
   other than those listed.
That implies if the second interpretation is adopted then by default a
v3 certificate without the keyUsage extension can not be used for
verifying the signature on public key certificates.

Therefore, I think we should try to make consensus on the
interpretation of a v3 certificate without the keyUsage extension
first, then we can decide whether the current text of RFC 3280
need to be changed.

Wen-Cheng Wang
  ----- Original Message -----=20
  From: David A. Cooper=20
  To: Wen-Cheng Wang=20
  Cc: pkix=20
  Sent: Saturday, November 20, 2004 12:28 AM
  Subject: Re: 3280bis issue: checking keyCertSign bit in path =
validation


  I do not believe that this is a place where 3280bis needs to change.

  There are many places in which RFC 3280 imposes requirements for the =
issuance of certificates that are not imposed by X.509.  But, RFC 3280 =
does not include corresponding checks in section 6 because RFC 3280 does =
not attempt to declare that a certificate (or certification path) that =
would be valid under X.509 is invalid simply because the certificate was =
not issued in accordance with the RFC 3280.

  This shows up in a number of places.  For example:

    1.. X.509 states that the certificate serial number is an integer;  =
RFC 3280 requires CAs to use only non-negative integers that are at most =
20 octets long.

    2.. X.509 states that the basicConstraints extension may be critical =
or non-critical; RFC 3280 requires that the extension be critical in =
intermediate (CA) certificates.

  In the case of keyUsage,  RFC 3280 imposes the requirement that you =
quote below, X.509 does not.  If the keyUsage extension is not present =
in a certificate, then no restrictions are imposed on the use of the =
certificate (i.e., it would be the same as if the extension were present =
and all bits were set to 1).

  Note that keyUsage is different from basicConstraints, where there is =
both an issuing and validation requirement.  That is, a version 3 =
certificate with no basicConstraints extension is effectively the same =
as a version 3 certificate with a basicConstraints extension with =
cA=3DFALSE.  X.509 states:

    NOTE 1 - If [the basicConstraints] extension is not present, or is =
flagged non-critical and is not recognized by a certificate-using =
system, then the certificate is to be considered an end-entity =
certificate and cannot be used to verify certificate signatures.

  So, X.509 imposes a requirement for the basicConstraints extension to =
be present in version 3 intermediate certificates, but it does not =
impose such a requirement for any other extensions.  The language in =
section 6 of RFC 3280 is based on this.

  Dave

  Wen-Cheng Wang wrote:

RFC 3280 4.1.2.3 mandate that a intermediate CA certificate
MUST contain the keyUsage extension with keyCertSign bit set.

The text says:

   This extension MUST appear in certificates that contain public
   keys that are used to validate digital signatures on other public key
   certificates or CRLs.

However, RFC 3280 path validation algorithm does not
check the existence of the the keyUsage extension properly.

In RFC 3280 6.1.4 step (n), it says:

   If a key usage extension is present, verify that the
   keyCertSign bit is set.

That seems to imply if there is no keyUsage extension
exists in the intermediate CA certificats, then there is nothing
to check. As a result, the path validation algorithm will
accept a CA certificate without keyUsage extension.

I think RFC 3280 6.1.4 step (n) should be changed to:

   If the version of the certificate is v3, verify that a key usage =
extension
   is present and the keyCertSign bit is set.

That means:

For v1 intermeniate certificate, there is nothing to check. However, for =
v3
intermediate certificate, it must contain a key usage extension and
the keyCertSign bit is set.

Wen-Cheng Wang
------=_NextPart_000_00DB_01C4CF10.7362AED0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3Dtext/html;charset=3DUTF-8>
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV>Dave,</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is quite natural for a profile to impose more strict =
recommendation,=20
requirements</DIV>
<DIV>and security considerations that the standard it is based on.</DIV>
<DIV>Since the role of RFC 3280 is to be a profile of X.509, it is =
supposed to=20
be more strict</DIV>
<DIV>than what X.509 imposes. Not only&nbsp;on the format of =
certificates and=20
CRLs but also</DIV>
<DIV>on the validation algorithm. Therefore, I do not think "a =
certification=20
path that would</DIV>
<DIV>be valid under X.509 is invalid under RFC 3280" is a problem. On =
the=20
contrary, I do</DIV>
<DIV>think "a certification path that would be invalid under X.509 is =
valid=20
under RFC</DIV>
<DIV>3280" will be a problem.</DIV>
<DIV>&nbsp;</DIV>
<DIV>When&nbsp;designing the RFC 3280 path validation algorithm, PKIX WG =

should</DIV>
<DIV>not take "what X.509 says about this" as the only the factor of=20
considerations.</DIV>
<DIV>Another more important factor is the scurity consideration. And if=20
following</DIV>
<DIV>more&nbsp;strict scurity considerations,&nbsp;PKIX WG&nbsp;finally =
conclude=20
that it is a flaw</DIV>
<DIV>in X.509, then&nbsp;PKIX WG&nbsp;should feed back a defect report =
to=20
X.509</DIV>
<DIV>liaison.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Maybe I should not quote the text from RFC 3280 4.1.2.3, because it =

seems</DIV>
<DIV>that&nbsp;my quotation&nbsp;misled the direction of dicussion. =
Instead, I=20
should mention</DIV>
<DIV>that the meaning of a v3 certificate without the keyUsage extension =
is=20
not</DIV>
<DIV>clear.&nbsp;Both RFC 3280 and X.509 do not have clear =
interpretation about=20
this.</DIV>
<DIV>That is my intention. Honestly, my current implementation of path=20
validation</DIV>
<DIV>algorithm accepts v3 certificates without the keyUsage extension =
too,=20
because</DIV>
<DIV>I want my implementation be faithful with respect to RFC 3280.=20
However,</DIV>
<DIV>accepting v3 certificates without the keyUsage extension really =
make=20
me</DIV>
<DIV>nervous because the implication is unclear. What if my path=20
validation</DIV>
<DIV>implementation accept a certificate of which the subject public key =
is=20
not</DIV>
<DIV>supposed to be used for verifying&nbsp;the signature on public key=20
certificates?</DIV>
<DIV>&nbsp;</DIV>
<DIV>There may be two kinds of interpretation for a v3 certificate =
without=20
the</DIV>
<DIV>keyUsage extension:</DIV>
<DIV>&nbsp;</DIV>
<DIV>The first one is&nbsp;what you mentioned:</DIV>
<DIV>&nbsp;&nbsp; If the keyUsage extension is not present in a v3 =
certificate,=20
then</DIV>
<DIV>&nbsp;&nbsp; it would be the&nbsp;same as if the extension were =
present and=20
all bits
<DIV>&nbsp;&nbsp; were set to 1. That is, no restrictions are imposed on =
the key=20
usage</DIV>
<DIV>&nbsp;&nbsp; of the certificate.</DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>The&nbsp;second one is:</DIV>
<DIV>
<DIV>&nbsp;&nbsp; If the keyUsage extension is not present in a v3 =
certificate,=20
then</DIV>
<DIV>&nbsp;&nbsp;&nbsp;it would be the&nbsp;same as if the extension =
were=20
present and all bits
<DIV>&nbsp;&nbsp; were set to 0. That is, the key is intended for some =
purpose=20
other</DIV>
<DIV>&nbsp;&nbsp; than those listed in the KeyUsage type.</DIV>
<DIV><FONT face=3D=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94 =
size=3D2></FONT>&nbsp;</DIV></DIV></DIV></DIV>
<DIV>If we decide to adopt the first interpretation and are sure =
that</DIV>
<DIV>such interpretation will not cause any security problem, then =
I</DIV>
<DIV>will accept the current text of RFC 3280. However, if we =
decide</DIV>
<DIV>to choose the second interpretation, then obviously &nbsp;the =
current</DIV>
<DIV>text of RFC 3280 needs to be changed.</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>Please note that X.509 (2000) 8.2.2.3 says:</DIV>
<DIV>&nbsp;&nbsp; A bit set to zero indicates that the key is not =
intended for=20
that purpose.</DIV>
<DIV>&nbsp;&nbsp; If all bits are zero, it indicates the key is intended =
for=20
some purpose</DIV>
<DIV>&nbsp;&nbsp;&nbsp;other than those listed.</DIV>
<DIV>That implies if the second interpretation is adopted then by =
default=20
a</DIV>
<DIV>v3 certificate without the keyUsage extension can not be used =
for</DIV>
<DIV>verifying&nbsp;the signature on public key certificates.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Therefore, I think we should try to make consensus&nbsp;on =
the</DIV>
<DIV>interpretation of a v3 certificate without the keyUsage =
extension</DIV>
<DIV>first, then we can decide whether the current text of RFC =
3280</DIV>
<DIV>need to be changed.</DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>Wen-Cheng Wang</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt =E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><FONT =
face=3D"Arial Unicode MS">----- Original=20
  Message ----- </FONT></DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94; font-color: black"><FONT=20
  face=3D"Arial Unicode MS"><B>From:</B> </FONT><A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]"><FONT face=3D"Arial Unicode =
MS">David A.=20
  Cooper</FONT></A><FONT face=3D"Arial Unicode MS"> </FONT></DIV>
  <DIV style=3D"FONT: 10pt =E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><FONT =
face=3D"Arial Unicode MS"><B>To:</B>=20
  </FONT><A title=[e-mail] =
href=3D"mailto:[e-mail]"><FONT=20
  face=3D"Arial Unicode MS">Wen-Cheng Wang</FONT></A><FONT=20
  face=3D"Arial Unicode MS"> </FONT></DIV>
  <DIV style=3D"FONT: 10pt =E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><FONT =
face=3D"Arial Unicode MS"><B>Cc:</B>=20
  </FONT><A title=[e-mail] =
href=3D"mailto:[e-mail]"><FONT=20
  face=3D"Arial Unicode MS">pkix</FONT></A><FONT face=3D"Arial Unicode =
MS">=20
  </FONT></DIV>
  <DIV style=3D"FONT: 10pt =E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><FONT =
face=3D"Arial Unicode MS"><B>Sent:</B>=20
  Saturday, November 20, 2004 12:28 AM</FONT></DIV>
  <DIV style=3D"FONT: 10pt =E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><FONT =
face=3D"Arial Unicode MS"><B>Subject:</B> Re:=20
  3280bis issue: checking keyCertSign bit in path =
validation</FONT></DIV>
  <DIV><BR></DIV>I do not believe that this is a place where 3280bis =
needs to=20
  change.<BR><BR>There are many places in which RFC 3280 imposes =
requirements=20
  for the issuance of certificates that are not imposed by X.509.&nbsp; =
But, RFC=20
  3280 does not include corresponding checks in section 6 because RFC =
3280 does=20
  not attempt to declare that a certificate (or certification path) that =
would=20
  be valid under X.509 is invalid simply because the certificate was not =
issued=20
  in accordance with the RFC 3280.<BR><BR>This shows up in a number of=20
  places.&nbsp; For example:<BR>
  <OL>
    <LI>
    <P>X.509 states that the certificate serial number is an =
integer;&nbsp; RFC=20
    3280 requires CAs to use only non-negative integers that are at most =
20=20
    octets long.</P>
    <LI>
    <P>X.509 states that the basicConstraints extension may be critical =
or=20
    non-critical; RFC 3280 requires that the extension be critical in=20
    intermediate (CA) certificates.</P></LI></OL>In the case of =
keyUsage,&nbsp;=20
  RFC 3280 imposes the requirement that you quote below, X.509 does =
not.&nbsp;=20
  If the keyUsage extension is not present in a certificate, then no=20
  restrictions are imposed on the use of the certificate (i.e., it would =
be the=20
  same as if the extension were present and all bits were set to =
1).<BR><BR>Note=20
  that keyUsage is different from basicConstraints, where there is both =
an=20
  issuing and validation requirement.&nbsp; That is, a version 3 =
certificate=20
  with no basicConstraints extension is effectively the same as a =
version 3=20
  certificate with a basicConstraints extension with cA=3DFALSE.&nbsp; =
X.509=20
  states:<BR>
  <BLOCKQUOTE>NOTE 1 - If [the basicConstraints] extension is not =
present, or=20
    is flagged non-critical and is not recognized by a certificate-using =
system,=20
    then the certificate is to be considered an end-entity certificate =
and=20
    cannot be used to verify certificate signatures.<BR></BLOCKQUOTE>So, =
X.509=20
  imposes a requirement for the basicConstraints extension to be present =
in=20
  version 3 intermediate certificates, but it does not impose such a =
requirement=20
  for any other extensions.&nbsp; The language in section 6 of RFC 3280 =
is based=20
  on this.<BR><BR>Dave<BR><BR>Wen-Cheng Wang wrote:<BR>
  <BLOCKQUOTE cite=3Dmid015d01c4ce27$c68703c0$4f85900a@wcwang =
type=3D"cite"><PRE wrap=3D"">RFC 3280 4.1.2.3 mandate that a =
intermediate CA certificate
MUST contain the keyUsage extension with keyCertSign bit set.

The text says:

   This extension MUST appear in certificates that contain public
   keys that are used to validate digital signatures on other public key
   certificates or CRLs.

However, RFC 3280 path validation algorithm does not
check the existence of the the keyUsage extension properly.

In RFC 3280 6.1.4 step (n), it says:

   If a key usage extension is present, verify that the
   keyCertSign bit is set.

That seems to imply if there is no keyUsage extension
exists in the intermediate CA certificats, then there is nothing
to check. As a result, the path validation algorithm will
accept a CA certificate without keyUsage extension.

I think RFC 3280 6.1.4 step (n) should be changed to:

   If the version of the certificate is v3, verify that a key usage =
extension
   is present and the keyCertSign bit is set.

That means:

For v1 intermeniate certificate, there is nothing to check. However, for =
v3
intermediate certificate, it must contain a key usage extension and
the keyCertSign bit is set.

Wen-Cheng Wang</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00DB_01C4CF10.7362AED0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJKdg15072760; Fri, 19 Nov 2004 12:39:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJKdgok072758; Fri, 19 Nov 2004 12:39:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJKde2L072634 for <[e-mail]>; Fri, 19 Nov 2004 12:39:41 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Nov 2004 20:42:39 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: 3280bis: name constraints
Date: Fri, 19 Nov 2004 20:39:18 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3280bis: name constraints
Thread-Index: AcTNkFhvL8yQ6PjFTDGIKuuxU1jeBAA5q7WQ
From: "Stefan Santesson" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 19 Nov 2004 20:42:39.0977 (UTC) FILETIME=[4F94DD90:01C4CE78]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAJKdf2L072748
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I just wanted to point out that this is a source of misunderstanding when implementing name constraints.

I do however agree with your conclusion.

Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 
  
________________________________________
From: David A. Cooper [mailto:[e-mail]] 
Sent: den 18 november 2004 18:02
To: Stefan Santesson
Cc: [e-mail]
Subject: Re: 3280bis: name constraints

Stefan Santesson wrote:

I totally agree with David that the current defined name comparison rules are not logical and do not follow the subtree principle (i.e. to allow all descendent entries but not parallel entries. This is also the case for the concept that xyz.com should be limited to the host (i.e. that [e-mail] is a violation of xyz.com. In my mind, [e-mail] is a perfectly valid subtree of xyz.com. The standard is thus not logical in this aspect.
  
While I agree that the rules for name constraints on rfc822Name is not entirely proper, but I don't see a compelling reason to change them.

RFC 3280 provides three ways to specify name constraints for rfc822Name:
1. specify a particular mailbox: this one seems to be consistent with the general rules for specifying name constraints.
2. A constraint of the form "xyz.com":  This is really indicating a constraint of "xyz.com" with a minimum of 0 or 1 (it doesn't matter since "xyz.com" is not itself a valid email address) and a maximum of 1.
3. A constraint of the form ".xyz.com":  This is really indicating a constraint of "xyz.com" with a minimum of 2 (must add at least one subdomain plus a local-part to the specified subtree) and no maximum.
In order to get the "normal" meaning of "xyz.com" one would need to include two subtree specifications:  "xyz.com" and ".xyz.com".

This seems to have been a way to introduce some flexibility in the specification of name constraints for rfc822Name without introducing the added complexity of the minimum and maximum fields.

Since the rules for specifying constraints on rfc822Name have remain unchanged since RFC 2459, I think it would be best not to change them.

Dave



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJK7pxS053039; Fri, 19 Nov 2004 12:07:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJK7pF6053037; Fri, 19 Nov 2004 12:07:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJK7oSg053025 for <[e-mail]>; Fri, 19 Nov 2004 12:07:50 -0800 (PST) (envelope-from [e-mail])
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CVEyB-00014R-K9; Fri, 19 Nov 2004 15:02:59 -0500
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, pkix mailing list <[e-mail]>, pkix chair <[e-mail]>, pkix  chair <[e-mail]>
Subject: Document Action: 'Internet X.509 Public Key Infrastructure  Warranty Certificate Extension' to Informational RFC 
Message-Id: <[e-mail]>
Date: Fri, 19 Nov 2004 15:02:59 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Warranty Certificate Extension '
   <draft-ietf-pkix-warranty-extn-04.txt> as an Informational RFC

This document is the product of the Public-Key Infrastructure (X.509) Working 
Group. 

The IESG contact persons are Sam Hartman and Russ Housley.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJIjgh4001234; Fri, 19 Nov 2004 10:45:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJIjgwD001233; Fri, 19 Nov 2004 10:45:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJIjfkc001114 for <[e-mail]>; Fri, 19 Nov 2004 10:45:41 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAJIjWjf018044; Fri, 19 Nov 2004 13:45:34 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06200712bdc3e8bd3772@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p0620070abdc298ed82e4@[128.89.89.75]> <[e-mail]>
Date: Fri, 19 Nov 2004 13:17:32 -0500
To: "David A. Cooper" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Proposal on use of CRL issuer in section 3 of RFC3280
Cc: pkix <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,


	<SNIP>
>
>>Also, I'm not sure why we should include the phrase "or some other 
>>mechanism" in the description of how a CA provides revocation 
>>status info.  the more options we allow for this (and especially 
>>the vague sort of phrase cited above), the greater the likelihood 
>>that a client and CA have not chosen common means of 
>>acquiring/publishing this critical info. if this was an indirect 
>>way to alluding to SCVP, let's me more direct.
>
>This wasn't meant to allude to SCVP.  There are many mechanisms for 
>distributing revocation status other than CRLs and OCSP.  I wouldn't 
>want to encourage their use since that would lead to 
>interoperability problems, but I didn't think PKIX profiles 
>precluded the use of revocation status mechanisms that are not 
>described in PKIX documents.
>
>Section 5 of RFC 3280 states:  "Conforming CAs are not required to 
>issue CRLs if other revocation or certificate status mechanisms are 
>provided."
>
>I can certainly remove the phrase "or some other mechanism".  I 
>didn't want to leave the impression that revocation status providers 
>MUST use either CRLs or OCSP, unless the working group really 
>intends to impose such a restriction.

That's a fair question. At first we insisted on CRLs.  Then we added 
OCSP and my assumption was that we wanted to require either CRLs or 
OCSP. If we impose no requirements on support for ANY standard 
revocation service, then I do worry that we create serious 
interoperability problems between RPs and CAs.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHZ1Qn057508; Fri, 19 Nov 2004 09:35:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJHZ1qH057507; Fri, 19 Nov 2004 09:35:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx1.fujixerox.co.jp (mx1.fujixerox.co.jp [192.26.96.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHYsjZ057345 for <[e-mail]>; Fri, 19 Nov 2004 09:35:00 -0800 (PST) (envelope-from [e-mail])
Received: from isvw1.fujixerox.co.jp ([129.249.27.131]) by mx1.fujixerox.co.jp (8.11.6p2a/3.7W) with ESMTP id iAJHYmW17431 for <[e-mail]>; Sat, 20 Nov 2004 02:34:48 +0900 (JST)
Received: from ns1.fujixerox.co.jp (isvw1 [129.249.27.131]) by isvw1.fujixerox.co.jp (8.11.6p2a/3.7W) with ESMTP id iAJHYlk09342 for <[e-mail]>; Sat, 20 Nov 2004 02:34:48 +0900 (JST)
Received: from mail.next.ksp.fujixerox.co.jp (mail.next.ksp.fujixerox.co.jp [129.249.209.162]) by ns1.fujixerox.co.jp (8.11.6p2a/3.7W) with SMTP id iAJHYle05182 for <[e-mail]>; Sat, 20 Nov 2004 02:34:47 +0900 (JST)
Received: (qmail 46050 invoked from network); 19 Nov 2004 17:34:46 -0000
Received: from unknown (HELO carry-on-x31) (129.249.27.105) by mail.next.ksp.fujixerox.co.jp with SMTP; 19 Nov 2004 17:34:46 -0000
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: CORRECTION: RFC 3280bis: Isses about UTF8
From: Ryu Inada <[e-mail]>
Message-Id: <[e-mail]>
X-Mailer: Winbiff [Version 2.43 PL1]
X-Accept-Language: ja,en
Date: Sat, 20 Nov 2004 02:34:49 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please abondan preveious message, We've send draft version by 
mistake.

Thanks David as new 3280bis author who represents all folks.

We guess following issues should be included in 3280bis.
We heard that stringmatch I-D in pkix will be merged into 3280bis,
 from Paul Hoffman. Therefore, the following includes some issues 
for the stringprep and UTF8String.

0) The day of begin to issue UTF8 encoded certificate
RFC 2459/3280 described that "The UTF8String encoding [RFC 2279] 
is the preferred encoding, and all certificates issued after 
December 31, 2003 MUST use the UTF8String."
This statement made confuse in some countries include Japan.
We want to change this statement or delete.

1) Certificate Retrieval vs. Certificate Matching
PKIX requires retrieving the certificate, like ldapsearch command.
It is okay to the certificate retrieval such as a path building. 
But it does not meet to the certificate matching such as a path 
validation.
DN comparison rule in the path validation MUST be boolean, match 
or not. In stringmatch I-D, it defines the state of matching 
result three state such as match, not match and undefined. It 
makes different result which verifier used. 
It makes confusion of trustiness in PKI world.
So, we think to define separately the method of certificate 
retrieval and certificate matching.

2) Code point Matching vs. Byte order Matching
There are some confusion exist on when an application compares the
 different encoding type. 
It can compare them by the code point matching or the byte order 
matching.
For example, if using the code point matching, 'ABC' encoded by 
UTF8String is same as 'ABC' encoded by BMPString. But, if using 
the byte order matching, 'ABC' encoded by UTF8String is not same 
as 'ABC' encoded by BMPString. 
So, 3280bis has to make which matching rule should be used.

3) Implementation Requirements for UTF8String
3a) Requirement for UTF8String processing to the client 
applications
PKI client application must handle the UTF8String in the 
certificate. At least the application should not reject UTF8 
encoded certificate.

3b) Requirement for verifier (of course including SCVP server)
PKI path validation module must process the UTF8String in the 
certificates as PKIX says. 

3c) Issuing requirements for the CA
In our just personal opinion, to avoid the confusion of the 
application developers, CA MUST issue the *normalized* UTF8String 
certificates. CA MUST normalize the some strings using the 
UTF8String encoding before issuing the certificate. When CA cannot
 normalize it by some reasons, CA MUST use the PrintableString for
 the strings. This is an idea not to complicate the name 
comparison. 
The using the PrintableString should be allowed only temporarily. 
But I have no idea about how long requires to the switchover to 
the UTF8String.
Anyway, if subject requires any characters out the PrintableString,
 CA MUST use UTF8String encoding.

Thank you.

--
Ryu Inada <[e-mail]>
Fuji Xerox Co., Ltd.
[phone] ext.6539

Masaki SHIMAOKA <[e-mail]>
SECOM IS Lab.
Core Technology Div.
[phone] (4172)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHTt3W054629; Fri, 19 Nov 2004 09:29:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJHTt2f054628; Fri, 19 Nov 2004 09:29:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx2.fujixerox.co.jp (mx2.fujixerox.co.jp [192.26.96.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHTdXS054328 for <[e-mail]>; Fri, 19 Nov 2004 09:29:46 -0800 (PST) (envelope-from [e-mail])
Received: from isvw2.fujixerox.co.jp ([129.249.27.132]) by mx2.fujixerox.co.jp (8.11.6p2a/3.7W) with ESMTP id iAJHTRY23673 for <[e-mail]>; Sat, 20 Nov 2004 02:29:27 +0900 (JST)
Received: from ns1.fujixerox.co.jp (isvw2 [129.249.27.132]) by isvw2.fujixerox.co.jp (8.11.6p2a/3.7W) with ESMTP id iAJHTRH14608 for <[e-mail]>; Sat, 20 Nov 2004 02:29:27 +0900 (JST)
Received: from mail.next.ksp.fujixerox.co.jp (mail.next.ksp.fujixerox.co.jp [129.249.209.162]) by ns1.fujixerox.co.jp (8.11.6p2a/3.7W) with SMTP id iAJHTPe03334 for <[e-mail]>; Sat, 20 Nov 2004 02:29:25 +0900 (JST)
Received: (qmail 45891 invoked from network); 19 Nov 2004 17:29:24 -0000
Received: from unknown (HELO carry-on-x31) (129.249.27.105) by mail.next.ksp.fujixerox.co.jp with SMTP; 19 Nov 2004 17:29:24 -0000
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RFC 3280bis: Isses about UTF8
From: Ryu Inada <[e-mail]>
Message-Id: <[e-mail]>
X-Mailer: Winbiff [Version 2.43 PL1]
X-Accept-Language: ja,en
Date: Sat, 20 Nov 2004 02:29:27 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks David as new 3280bis author who represents all folks.

We guess following issues should be included in 3280bis.
We heard that stringmatch I-D in pkix will be merged into 3280bis,
 from Paul Hoffman. Therefore, the following includes some issues 
for the stringprep and UTF8String.

0) The day of begin to issue UTF8 encoded certificate
RFC 2459/3280 described that "The UTF8String encoding [RFC 2279] 
is the preferred encoding, and all certificates issued after 
December 31, 2003 MUST use the UTF8String."
This statement made confuse in some countries include Japan.
We want to change this statement or delete.

1) Certificate Retrieval vs. Certificate Matching
PKIX requires retrieving the certificate, like ldapsearch command.
It is okay to the certificate retrieval such as just a path 
building uses. But it does not meet to the certificate matching 
such as a path validation.
DN comparison rule in the path validation MUST be boolean, match 
or not. In stringmatch I-D, it defines the state of matching 
result three state such as match, not match and undefined. It 
makes different result which verifier used. 
It makes confusion of trustiness in PKI world.
So, we think to define separately the method of certificate 
retrieval and certificate matching.

2) Code point Matching vs. Byte order Matching
There are some confusion exist on when an application compares the
 different encoding type. 
It can compare them by the code point matching or the byte order 
matching.
For example, if using the code point matching, 'ABC' encoded by 
UTF8String is same as 'ABC' encoded by BMPString. But, if using 
the byte order matching, 'ABC' encoded by UTF8String is not same 
as 'ABC' encoded by BMPString. 
So, 3280bis has to make which matching rule should be used.

3) Implementation Requirements for UTF8String
3a) Requirement for UTF8String processing to the client 
applications
PKI client application must handle the UTF8String in the 
certificate. At least the application should not reject UTF8 
encoded certificate.
We do not insist PKI client must to process all requirements in 
PKIX says, as path validating and so on.

3b) Requirement for verifier (of course including SCVP server)
PKI path validation module must process the UTF8String in the 
certificates as PKIX says. 

3c) Issuing requirements for the CA
In our just personal opinion, to avoid the confusion of the 
application developers, CA MUST issue the *normalized* UTF8String 
certificates. CA MUST normalize the some strings using the 
UTF8String encoding before issuing the certificate. When CA cannot
 normalize it by some reasons, CA MUST use the PrintableString for
 the strings. This is an idea not to complicate the name 
comparison. 
The using the PrintableString should be allowed only temporarily. 
But I have no idea about how long requires to the switchover to 
the UTF8String.
Anyway, if subject requires any characters out the PrintableString,
 CA MUST use UTF8String encoding.

Thank you.

--
Ryu Inada <[e-mail]>
Fuji Xerox Co., Ltd.
[phone] ext.6539

Masaki SHIMAOKA <[e-mail]>
SECOM IS Lab.
Core Technology Div.
[phone] (4172)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHTj9P054519; Fri, 19 Nov 2004 09:29:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJHTjnc054518; Fri, 19 Nov 2004 09:29:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.funk.com (mail2.funk.com [199.103.155.98] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJHTi0t054457 for <[e-mail]>; Fri, 19 Nov 2004 09:29:45 -0800 (PST) (envelope-from [e-mail])
Received: from trilmail.funk.com ([192.168.21.75]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VP6G4G3D; Fri, 19 Nov 2004 12:29:30 -0500
Received: from [127.0.0.1] (hannaxp [192.168.21.6]) by trilmail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TJKX9823; Fri, 19 Nov 2004 12:28:43 -0500
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 12:29:21 -0500
From: Steve Hanna <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: Wen-Cheng Wang <[e-mail]>, pkix <[e-mail]>
Subject: Re: 3280bis issue:  checking keyCertSign bit in path validation
References: <015d01c4ce27$c68703c0$4f85900a@wcwang> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

Maybe we should add a statement in 3280bis that
says clearly that relying parties SHOULD NOT
attempt to enforce every requirement or
recommendation that RFC 3280 places on certificates.
They SHOULD only enforce those that are required
by the algorithm in section 6 or other requirements
that they have determined are necessary for their
particular situation.

I have heard several knowledgable people say that
their code rejected a cert because it didn't comply
with some requirement of RFC 3280 even though that
requirement is not in section 6. While this sort
of behavior for a relying party is not prohibited
under RFC 3280, it should be discouraged. We don't
need to have vigilantes running around rejecting
certs because their serial number is too long!

Thanks,

Steve

David A. Cooper wrote:

> I do not believe that this is a place where 3280bis needs to change.
> 
> There are many places in which RFC 3280 imposes requirements for the 
> issuance of certificates that are not imposed by X.509.  But, RFC 3280 
> does not include corresponding checks in section 6 because RFC 3280 does 
> not attempt to declare that a certificate (or certification path) that 
> would be valid under X.509 is invalid simply because the certificate was 
> not issued in accordance with the RFC 3280.
> 
> This shows up in a number of places.  For example:
> 
>    1.
> 
>       X.509 states that the certificate serial number is an integer; 
>       RFC 3280 requires CAs to use only non-negative integers that are
>       at most 20 octets long.
> 
>    2.
> 
>       X.509 states that the basicConstraints extension may be critical
>       or non-critical; RFC 3280 requires that the extension be critical
>       in intermediate (CA) certificates.
> 
> In the case of keyUsage,  RFC 3280 imposes the requirement that you 
> quote below, X.509 does not.  If the keyUsage extension is not present 
> in a certificate, then no restrictions are imposed on the use of the 
> certificate (i.e., it would be the same as if the extension were present 
> and all bits were set to 1).
> 
> Note that keyUsage is different from basicConstraints, where there is 
> both an issuing and validation requirement.  That is, a version 3 
> certificate with no basicConstraints extension is effectively the same 
> as a version 3 certificate with a basicConstraints extension with 
> cA=FALSE.  X.509 states:
> 
>     NOTE 1 - If [the basicConstraints] extension is not present, or is
>     flagged non-critical and is not recognized by a certificate-using
>     system, then the certificate is to be considered an end-entity
>     certificate and cannot be used to verify certificate signatures.
> 
> So, X.509 imposes a requirement for the basicConstraints extension to be 
> present in version 3 intermediate certificates, but it does not impose 
> such a requirement for any other extensions.  The language in section 6 
> of RFC 3280 is based on this.
> 
> Dave
> 
> Wen-Cheng Wang wrote:
> 
>>RFC 3280 4.1.2.3 mandate that a intermediate CA certificate
>>MUST contain the keyUsage extension with keyCertSign bit set.
>>
>>The text says:
>>
>>   This extension MUST appear in certificates that contain public
>>   keys that are used to validate digital signatures on other public key
>>   certificates or CRLs.
>>
>>However, RFC 3280 path validation algorithm does not
>>check the existence of the the keyUsage extension properly.
>>
>>In RFC 3280 6.1.4 step (n), it says:
>>
>>   If a key usage extension is present, verify that the
>>   keyCertSign bit is set.
>>
>>That seems to imply if there is no keyUsage extension
>>exists in the intermediate CA certificats, then there is nothing
>>to check. As a result, the path validation algorithm will
>>accept a CA certificate without keyUsage extension.
>>
>>I think RFC 3280 6.1.4 step (n) should be changed to:
>>
>>   If the version of the certificate is v3, verify that a key usage extension
>>   is present and the keyCertSign bit is set.
>>
>>That means:
>>
>>For v1 intermeniate certificate, there is nothing to check. However, for v3
>>intermediate certificate, it must contain a key usage extension and
>>the keyCertSign bit is set.
>>
>>Wen-Cheng Wang
>>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJH3T2E038606; Fri, 19 Nov 2004 09:03:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJH3TK6038605; Fri, 19 Nov 2004 09:03:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.funk.com (mail2.funk.com [199.103.155.98] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJH3Se9038384 for <[e-mail]>; Fri, 19 Nov 2004 09:03:28 -0800 (PST) (envelope-from [e-mail])
Received: from trilmail.funk.com ([192.168.21.75]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VP6G4GKG; Fri, 19 Nov 2004 12:03:03 -0500
Received: from [127.0.0.1] (hannaxp [192.168.21.6]) by trilmail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TJKX982B; Fri, 19 Nov 2004 12:02:15 -0500
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 12:02:53 -0500
From: Steve Hanna <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Gietz <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

First, I should apologize if I came across
as saying that your drafts are crap. That's
not what I wanted to say. They're interesting
ideas and research but I don't see that the
benefits exceed the costs.

Second, thanks for your responses. Thanks
especially for responding in a constructive
and helpful manner to my criticisms. That's
very helpful. I'll respond below.

Peter Gietz wrote:
>> The main supposed benefits of your solution are:
>>
>> 1) Easier to search for certs
>>
>>    Since certificate fields are stored as attributes
>>    of LDAP entries, clients can easily search for
>>    certificates by certificate field values. However,
>>    there are already two good ways to do this: the
>>    CertificateAssertion (defined in X.509 and
>>    draft-zeilenga-ldap-x509-00.txt) and Component
>>    Matching (RFC 3687). You argue that these will
>>    take a while to be deployed, but so would your
>>    solution. We don't need a third option.
>>
> The advantage of our solution is that you don't have to change any 
> software, provided clients support configurable search filters,
> and that should be standard anyway and most generic ldap clients support 
> that.  Implementation of Component Matching will be much more burdensom 
> since ASN.1 parsing is far more complicated and AFAICS only one server 
> product is ASN.1 aware today. With all other products a redesign would 
> have to be done to support Component Matching.
> 
> May be some vendors could make a statement about their plans for 
> supporting Component Matching to get a better view on this.

I agree that Component Matching is complex. What about
the CertificateAssertion? That seems fairly simple.

And I'm not sure that the problem is a critical one
to solve, as described in the next bullet. I expect
that most clients won't use any of these techniques
but will simply download all the certificates in a
directory entry and sort them out on the client.
See below for more on this theme.

>> 2) Easier to download just matching certs
>>
>>    Some users (or CAs) have many certificates.
>>    Your solution stores each cert as a separate
>>    directory entry which makes it easy to download
>>    just the ones you want. But there is already a
>>    way to do this with the existing schema: the
>>    Matched Values Return Filter control (RFC 3876).
>>    Again you argue that these will take a while to
>>    be deployed, but so would your solution. Also,
>>    it's quite rare to have many certificates. Why
>>    optimize for this rare case?
> 
> We expect this case to be less rare in the future. Especially we expect 
> that users will have different certificates for encryption and for 
> signing. It also will be more common that users will have certificates 
> from different CAs.

Yes, some users have two certificates, one for encryption
and one for signing. But it's much simpler to download
the two certificates and then decide which one you want
than to go through all this complexity to identify the
single certificate you want. Users with certificates from
a large number of different CAs stored in their directory
entry will probably be unusual. People who are storing
certificates in an LDAP directory are part of some organization
that runs the directory. That organization probably only
issues one set of certs per user. Don't you agree?

When I wrote a path builder, I tended to download all the
certs in a directory entry and sort them out in the builder.
The request latency far exceeded the extra cost of downloading
a few extra bytes. I recognize that this may not be the best
approach if you're on a very slow link or have little memory
but such a client won't have much success building paths anyway.
They're much better off using DPD (SCVP/XKMS) or getting full
paths in the TLS or other protocol handshake.

So I still don't think this is an important problem to solve.

>> The main costs of your solution are:
>>
>> 1) Many more directory entries (>2x)
>>
>>    Your solution requires a separate directory entry
>>    for every certificate. If each user has an average
>>    of one cert, this will double the number of entries
>>    in the directory. That's bad enough, but your solution
>>    has no value unless each user has many certificates.
>>    In that case, the number of entries will more than
>>    double.
> 
> I agree, but don't see that this is a big problem even for large 
> databases. All LDAP-servers are capable of storing great amounts of 
> entries.

Maybe. I don't think administrators will be pleased with
doubling the number of entries.

>> 2) Client changes needed
>>
>>    You complain that the Matched Values Return Filter
>>    control will require servers to be upgraded. But
>>    your solution will require all clients to be upgraded
>>    to look for certificates and CRLs in a new place.
>>    Upgrading all clients is much harder than upgrading
>>    a few servers.
> 
> Since we decided to use the standard attributes usercertificate and 
> cacertificate within our schema, the certificates should be retrievable 
> by standard clients that perform subtree searches. We are thinking about 
> publishing another object class for additional metadata not extracted 
> from the certificate but, e.g.,  extracted from a peron entry or from 
> the single parts of the subjectDN (email, cn, o, ou, etc.) which are 
> used as search items by clients not aware of our  x509xxx attributes.

As you point out in your draft, storing certs using
both the standard schema and your own is error-prone
and inefficient (storing every cert twice). This should
only be a transitional measure. Clients will need to
be upgraded to use your schema. But I'm glad you are
planning for a gradual upgrade process not a red letter day.

>> I have heard that your drafts are only intended to
>> report on some experiments you conducted. That's why
>> the documents are going Informational and not Standards
>> Track. If that's true, the documents should say so
>> clearly and they should go Experimental not Informational.
> 
> I agree with the ADs that there should only be one standard solution. If 
> in the future we will see that our solution is  implemented  far more 
> often than others, I will make an attempt to reissue our proposal for 
> Standards Track. For now I would be very happy with Informational 
> status. I know of at least 4 implementations of our draft. Thus it is 
> more than just an experiment of one project. 

If the community believes this is a valid approach that
should be pursued further, then Informational seems
appropriate. If it believes that this approach should
not be pursued, then you are probably right that the
documents should not be published as RFCs. Experimental
status would be an intermediate position.

I should note that this is not the first time
I have objected to your proposal. I objected once
at an IETF meeting and (I believe) once before on
the PKIX list. I agree that if I'm the only person
objecting, then the documents should be approved.
But I want to make sure that my arguments are stated
so that others can consider them carefully and not
simply approve the documents without understanding
the tradeoffs involved.

If others share my concerns, I encourage them to speak
up. We all have a duty to try to make PKI work, for
the sake of our employers and customers. I think these
documents are a step in the wrong direction.

Of course, I concede that these documents are not
Standards Track at this time but I think that if we
publish them as RFCs without an Applicability Statement
or other guidance, people will perceive them as a
statement of future direction.

Thanks,

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJGT5rp018643; Fri, 19 Nov 2004 08:29:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJGT5gW018642; Fri, 19 Nov 2004 08:29:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJGT39j018617 for <[e-mail]>; Fri, 19 Nov 2004 08:29:03 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAJGSg2x025698; Fri, 19 Nov 2004 11:28:42 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAJGS5YA022514; Fri, 19 Nov 2004 11:28:06 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 11:28:44 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wen-Cheng Wang <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: 3280bis issue:  checking keyCertSign bit in path validation
References: <015d01c4ce27$c68703c0$4f85900a@wcwang>
In-Reply-To: <015d01c4ce27$c68703c0$4f85900a@wcwang>
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
I do not believe that this is a place where 3280bis needs to change.<br>
<br>
There are many places in which RFC 3280 imposes requirements for the
issuance of certificates that are not imposed by X.509.  But, RFC 3280
does not include corresponding checks in section 6 because RFC 3280
does not attempt to declare that a certificate (or certification path)
that would be valid under X.509 is invalid simply because the
certificate was not issued in accordance with the RFC 3280.<br>
<br>
This shows up in a number of places.  For example:<br>
<ol>
  <li>
    <p>X.509 states that the certificate serial number is an integer; 
RFC 3280 requires CAs to use only non-negative integers that are at
most 20 octets long.</p>
  </li>
  <li>
    <p>X.509 states that the basicConstraints extension may be critical
or non-critical; RFC 3280 requires that the extension be critical in
intermediate (CA) certificates.</p>
  </li>
</ol>
In the case of keyUsage,  RFC 3280 imposes the requirement that you
quote below, X.509 does not.  If the keyUsage extension is not present
in a certificate, then no restrictions are imposed on the use of the
certificate (i.e., it would be the same as if the extension were
present and all bits were set to 1).<br>
<br>
Note that keyUsage is different from basicConstraints, where there is
both an issuing and validation requirement.  That is, a version 3
certificate with no basicConstraints extension is effectively the same
as a version 3 certificate with a basicConstraints extension with
cA=FALSE.  X.509 states:<br>
<blockquote>NOTE 1 - If [the basicConstraints] extension is not
present, or is flagged non-critical and is not recognized by a
certificate-using system, then the certificate is to be considered an
end-entity certificate and cannot be used to verify certificate
signatures.<br>
</blockquote>
So, X.509 imposes a requirement for the basicConstraints extension to
be present in version 3 intermediate certificates, but it does not
impose such a requirement for any other extensions.  The language in
section 6 of RFC 3280 is based on this.<br>
<br>
Dave<br>
<br>
Wen-Cheng Wang wrote:<br>
<blockquote type="cite" cite="mid015d01c4ce27$c68703c0$4f85900a@wcwang">
  <pre wrap="">RFC 3280 4.1.2.3 mandate that a intermediate CA certificate
MUST contain the keyUsage extension with keyCertSign bit set.

The text says:

   This extension MUST appear in certificates that contain public
   keys that are used to validate digital signatures on other public key
   certificates or CRLs.

However, RFC 3280 path validation algorithm does not
check the existence of the the keyUsage extension properly.

In RFC 3280 6.1.4 step (n), it says:

   If a key usage extension is present, verify that the
   keyCertSign bit is set.

That seems to imply if there is no keyUsage extension
exists in the intermediate CA certificats, then there is nothing
to check. As a result, the path validation algorithm will
accept a CA certificate without keyUsage extension.

I think RFC 3280 6.1.4 step (n) should be changed to:

   If the version of the certificate is v3, verify that a key usage extension
   is present and the keyCertSign bit is set.

That means:

For v1 intermeniate certificate, there is nothing to check. However, for v3
intermediate certificate, it must contain a key usage extension and
the keyCertSign bit is set.

Wen-Cheng Wang</pre>
</blockquote>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJCnUx9042175; Fri, 19 Nov 2004 04:49:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJCnT8t042174; Fri, 19 Nov 2004 04:49:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.daasi.de (rhea.directory.dfn.de [134.2.217.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJCnSAb042165 for <[e-mail]>; Fri, 19 Nov 2004 04:49:28 -0800 (PST) (envelope-from [e-mail])
Received: by smtp.daasi.de (Postfix, from userid 1009) id D254DC102; Fri, 19 Nov 2004 13:49:29 +0100 (CET)
Received: from daasi.de (marie.directory.dfn.de [134.2.217.72]) by smtp.daasi.de (Postfix) with ESMTP id BD4BCC0FF; Fri, 19 Nov 2004 13:49:22 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 13:49:22 +0100
From: Peter Gietz <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andrew Sciberras <[e-mail]>
Cc: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Certificate Schema (Object Class)
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, hits=-3.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_LONG_SPARSE,USER_AGENT version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Andrew Sciberras wrote:

>Hi,
>
>I'm looking at the x509userCertificate Object Class...
>
>( 1.3.6.1.4.1.10126.1.5.4.2.4
>         NAME 'x509userCertificate'
>         SUP x509PKC
>         STRUCTURAL
>         MUST userCertificate
>         MAY  x509subject )
>
>This definition is followed with the statement:
>"   The attribute type x509subject is specified here as a MAY attribute.
>   Nevertheless if this attribute is not used at least one of the
>   following attributes MUST be filled in: x509subjectRfc822Name,
>   x509subjectDnsName, x509subjectDirectoryName, x509subjectURI,
>   x509subjectIpAddress, or x509subjectRegisteredID."
>
>This is either problematic or not specified clearly enough. 
>In order for one of these attributes to be present in the entry then
>they should be an optional attribute within the x509userCertificate
>object class.
>  
>
We had made the design decision to have a separate object class for the 
certificate extensions which is defined in the same document. I am 
willing to include a reference to that object class  here , e.g. :
"... or x509subjectRegisteredID. These attributes are provided by the 
auxiliary object class x509PKCext specified in 4.5. which in this case 
is mandatory."

We could additionally specify a DIT content rule for this, if it makes 
things clearer. But I don't see a way to specify the condition "if 
x509subject is empty then" in such a rule.

Cheers,

Peter

>If there is a reason why they shouldn't be in the optional list, then
>I think text that makes reference to the use of  DIT Content Rules to
>permit this.
>
>Regards,
>Andrew Sciberras
>eB2Bcom Pty Ltd
>
>  
>


-- 
_______________________________________________________________________
 
Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]  
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJCXElP035712; Fri, 19 Nov 2004 04:33:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJCXE4B035711; Fri, 19 Nov 2004 04:33:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.daasi.de (rhea.directory.dfn.de [134.2.217.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJCXDLP035690 for <[e-mail]>; Fri, 19 Nov 2004 04:33:13 -0800 (PST) (envelope-from [e-mail])
Received: by smtp.daasi.de (Postfix, from userid 1009) id A1896C10C; Fri, 19 Nov 2004 13:33:11 +0100 (CET)
Received: from daasi.de (marie.directory.dfn.de [134.2.217.72]) by smtp.daasi.de (Postfix) with ESMTP id 2C402C0FF; Fri, 19 Nov 2004 13:33:05 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 13:33:04 +0100
From: Peter Gietz <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
Cc: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_LONG_SPARSE,USER_AGENT version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

Thanks for your comments although our opinions differ. Here is my reply:

Steve Hanna wrote:

> Here are my comments on draft-ietf-pkix-ldap-*schema.
>
> These schemas are too complex and incompatible with
> existing clients. The costs exceed the benefits.

I don't think so and will try to explain why.

>
> The main supposed benefits of your solution are:
>
> 1) Easier to search for certs
>
>    Since certificate fields are stored as attributes
>    of LDAP entries, clients can easily search for
>    certificates by certificate field values. However,
>    there are already two good ways to do this: the
>    CertificateAssertion (defined in X.509 and
>    draft-zeilenga-ldap-x509-00.txt) and Component
>    Matching (RFC 3687). You argue that these will
>    take a while to be deployed, but so would your
>    solution. We don't need a third option.
>
The advantage of our solution is that you don't have to change any 
software, provided clients support configurable search filters,
and that should be standard anyway and most generic ldap clients support 
that.  Implementation of Component Matching will be much more burdensom 
since ASN.1 parsing is far more complicated and AFAICS only one server 
product is ASN.1 aware today. With all other products a redesign would 
have to be done to support Component Matching.

May be some vendors could make a statement about their plans for 
supporting Component Matching to get a better view on this.

> 2) Easier to download just matching certs
>
>    Some users (or CAs) have many certificates.
>    Your solution stores each cert as a separate
>    directory entry which makes it easy to download
>    just the ones you want. But there is already a
>    way to do this with the existing schema: the
>    Matched Values Return Filter control (RFC 3876).
>    Again you argue that these will take a while to
>    be deployed, but so would your solution. Also,
>    it's quite rare to have many certificates. Why
>    optimize for this rare case?

We expect this case to be less rare in the future. Especially we expect 
that users will have different certificates for encryption and for 
signing. It also will be more common that users will have certificates 
from different CAs.

>
> The main costs of your solution are:
>
> 1) Many more directory entries (>2x)
>
>    Your solution requires a separate directory entry
>    for every certificate. If each user has an average
>    of one cert, this will double the number of entries
>    in the directory. That's bad enough, but your solution
>    has no value unless each user has many certificates.
>    In that case, the number of entries will more than
>    double.

I agree, but don't see that this is a big problem even for large 
databases. All LDAP-servers are capable of storing great amounts of entries.

>
> 2) Client changes needed
>
>    You complain that the Matched Values Return Filter
>    control will require servers to be upgraded. But
>    your solution will require all clients to be upgraded
>    to look for certificates and CRLs in a new place.
>    Upgrading all clients is much harder than upgrading
>    a few servers.

Since we decided to use the standard attributes usercertificate and 
cacertificate within our schema, the certificates should be retrievable 
by standard clients that perform subtree searches. We are thinking about 
publishing another object class for additional metadata not extracted 
from the certificate but, e.g.,  extracted from a peron entry or from 
the single parts of the subjectDN (email, cn, o, ou, etc.) which are 
used as search items by clients not aware of our  x509xxx attributes.

>
> The schema described in RFC 2587 and updated by
> draft-zeilenga-ldap-x509-00.txt seems much more
> reasonable than yours. I understand that the
> zeilenga I-D is actually a product of the ldapbis
> efforts and will probably advance with them.
> Therefore, I suggest that document be advanced in
> lieu of yours.

As you can see in our draft, we never said that our schema is the only 
valid solution. We only say that with today's software our solution is 
better deployable and that they are an ideal solution for indexing systems.

>
> I have heard that your drafts are only intended to
> report on some experiments you conducted. That's why
> the documents are going Informational and not Standards
> Track. If that's true, the documents should say so
> clearly and they should go Experimental not Informational.

I agree with the ADs that there should only be one standard solution. If 
in the future we will see that our solution is  implemented  far more 
often than others, I will make an attempt to reissue our proposal for 
Standards Track. For now I would be very happy with Informational 
status. I know of at least 4 implementations of our draft. Thus it is 
more than just an experiment of one project. Since you don't want to 
have our drafts published at all, I cannot see your point here. If 
Experimental Track leads to more consensus, then it is ok with me, but 
still I think Informational is more appropriate. Nothing in the 
definition of Informational in RFC2026 Par 4.2.2. seems to be against that:

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to verification
   that there has been adequate coordination with the standards process
   (see section 4.2.3).

   Specifications that have been prepared outside of the Internet
   community and are not incorporated into the Internet Standards
   Process by any of the provisions of section 10 may be published as
   Informational RFCs, with the permission of the owner and the
   concurrence of the RFC Editor.

>
> In conclusion, it's my view that these documents are
> not useful. In fact, they may cause harm to people
> who implement them without understanding that they
> are purely experimental. I recommend that they not
> be published at all by the IETF. If they are published,
> they should only be published with Experimental status
> with an Applicability Notice describing the problems
> noted above and suggesting that the standard schemas
> be used instead.
>
We already wrote that there is a standard way for storing LDAP 
certificates in place that might in the furure also solve most of the 
problems addressed by us. Current implementations do not solve them with 
that standard. In addition our schema provides the only solution for 
large scale certificate index systems.

An Applicability Notice saying "This spec is bad and crap, don't 
implement it" seems to be nonsens to me, since if it is only bad and 
crap it shouldn't be published at all. I for one, but AFAICS besides you 
all other commentors in this last call  don't think that it is crap.

There might be a formulation of an Applicability Notice that makes more 
sense.

Cheers,

Peter

> Thanks,
>
> Steve
>
> Tim Polk wrote:
>
>>
>>
>> This message initiates working group Last Call for the "LDAP Schema 
>> for X.509 Certificates"
>> specification. The editors have confirmed that all working group 
>> issues have been resolved.
>>
>> The URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt 
>>
>>
>> This specification has also been forwarded to the LDAP Directorate 
>> for a parallel review.  Assuming successful Last Call and concurrence 
>> from the LDAP Directorate, this document will be forwarded to the ADs 
>> for consideration as an Informational track RFC.
>>
>> Last Call will run for (at least) two weeks. That is, Last Call will 
>> not close before November 29.
>>
>> Thanks,
>>
>> Tim Polk
>
>
>
>


-- 
_______________________________________________________________________
 
Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]  
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJB6WIv093565; Fri, 19 Nov 2004 03:06:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJB6W50093564; Fri, 19 Nov 2004 03:06:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gate3.chttl.com.tw ([203.75.28.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJB6NTP093421 for <[e-mail]>; Fri, 19 Nov 2004 03:06:28 -0800 (PST) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by gate3.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAJB6DqB007469; Fri, 19 Nov 2004 19:06:13 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id iAJB6CdJ011161; Fri, 19 Nov 2004 19:06:12 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAJB6BZG011092; Fri, 19 Nov 2004 19:06:11 +0800
Message-ID: <015d01c4ce27$c68703c0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "pkix" <[e-mail]>
Subject: 3280bis issue:  checking keyCertSign bit in path validation
Date: Fri, 19 Nov 2004 19:06:10 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

RFC 3280 4.1.2.3 mandate that a intermediate CA certificate
MUST contain the keyUsage extension with keyCertSign bit set.

The text says:

   This extension MUST appear in certificates that contain public
   keys that are used to validate digital signatures on other public key
   certificates or CRLs.

However, RFC 3280 path validation algorithm does not
check the existence of the the keyUsage extension properly.

In RFC 3280 6.1.4 step (n), it says:

   If a key usage extension is present, verify that the
   keyCertSign bit is set.

That seems to imply if there is no keyUsage extension
exists in the intermediate CA certificats, then there is nothing
to check. As a result, the path validation algorithm will
accept a CA certificate without keyUsage extension.

I think RFC 3280 6.1.4 step (n) should be changed to:

   If the version of the certificate is v3, verify that a key usage extension
   is present and the keyCertSign bit is set.

That means:

For v1 intermeniate certificate, there is nothing to check. However, for v3
intermediate certificate, it must contain a key usage extension and
the keyCertSign bit is set.

Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJAm2UG083944; Fri, 19 Nov 2004 02:48:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJAm2iZ083943; Fri, 19 Nov 2004 02:48:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw ([202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJAlx4H083873 for <[e-mail]>; Fri, 19 Nov 2004 02:48:00 -0800 (PST) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAJAltnk006182; Fri, 19 Nov 2004 18:47:55 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id iAJAltY7005986; Fri, 19 Nov 2004 18:47:55 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAJAlqZG005915; Fri, 19 Nov 2004 18:47:54 +0800
Message-ID: <014f01c4ce25$3891fd60$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <01ef01c4cc91$5b509b30$4f85900a@wcwang> <[e-mail]>
Subject: Re: 3280bis issue:  issues related to self-issued certificates
Date: Fri, 19 Nov 2004 18:47:51 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,

Please see my response in-line.

Wen-Cheng Wang

----- Original Message ----- 
From: "David A. Cooper" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>
Cc: "pkix" <[e-mail]>
Sent: Friday, November 19, 2004 3:27 AM
Subject: Re: 3280bis issue: issues related to self-issued certificates


> Wen-Cheng Wang wrote:
>
> >The definition of the term "self-issued certificate" is too vague.
> >
> >The current text of RFC 3280 only mention
> >
> >"A certificate is self-issued if the DNs that appear in the subject
> > and issuer fields are identical and are not empty....a CA may
> > issue a certificate to itself to support key rollover or changes in
> > certificate policies.  These self-issued certificates are not counted
> > when evaluating path length or name constraints."
> >
> >However, there are many kinds of self-issued certificates. For
> >example:
> >
> >(a) self-signed certificates (this is a special case of self-issued certificate)
> >(b) self-issued certificates with keyCertSign key usage (might with cRLSign key usage as well)
> >(c) self-issued certificates with cRLSign key usage only (a CA using separate key for CRL
signing)
> >(d) self-issued certificates with key usages other than keyCertSign and cRLSign
> >
> >Self-issued certificates of type (c) are also known as "self-issued
> >intermediate certificates" according to the X.509 (2000) standard.
> >Obviously, only self-issued certificates of type (c) are thought to
> >be CA certificates. However, they are special CA certificates
> >for special purpose (e.g., Key Rollover) so that they do not contribute
> >to the path length for purposes of processing some constraint
> >extension and name constrains extension in certification path validation.
> >
> >Self-issued certificates of type (a), (c) and (d) can not be
> >intermediate certificates and thus the above special processing
> >rule does not apply to them. This is not crystal clear in the current
> >text of RFC 3280.
> >
>
> I think the rules are spelled out very clearly in section 6.
>
> Self-signed certificates are only used as a source of trust anchor
> information.  Section 6.1.1 step (d) specifies the information that is
> to be extracted from the self-signed certificate (and also indicates
> that this information does not need to be provided in the form of a
> self-signed certificate).  X509 explicitly states that self-signed
> certificates may not appear as intermediate certificates, and this
> should probably be stated in 3280bis as well.
>
> In sections 6.1.3, 6.1.4, and 6.1.5, self-issued certificates (whether
> intermediate or not) are treated in exactly the same manner as other
> certificates except where the text explicitly states that they should be
> treated differently.
>
> For example, in section 6.1.4, steps (a) and (b) do not provide an
> exception for self-issued certificates, so any policyMappings extension
> would be processed the same as if it were in a non-self-issued
> certificate.  Similarly, step (i) indicates that a policyConstraints
> extension should be processed the same for self-issued and
> non-self-issued certificates.  However, step (h) indicates that the
> explicit_policy and policy_mapping counters would not be decremented
> when processing a self-issued certificate.
>
> In general, if a constraint extension appears in a self-issued
> certificate (other than a self-signed certificate), it is processed in
> the same way as if it appeared in a non-self-issued certificate.
> However, intermediate self-issued certificates are usually (but not
> always) exempted from the constraints imposed by certificates that
> preceded it in the path.
>
> >Obviously, self-issued certificates of type (a) and (b) should conatins
> >a basicConstraints extension with cA = TRUE since they are
> >CA certificates.
> >
> >It is not clear whether self-issued certificates of type (c) should
> >also conatins a basicConstraints extension with cA = TRUE.
> >
> >Self-issued certificates of type (d) should be thought as EE
> >certificates, therefore they should not contain  a basicConstraints
> >extension with cA = TRUE. However, some PKIX WG members
> >might not agree to this interpretation.
> >
> This confusion is very unfortunate.  X.509 is very clear: "The cA
> component indicates if the certified public key may be used to verify
> certificate signatures."
>
> So the problem is with RFC 3280.  X.509 is quite clear that the cA bit
> is not set to true for self-issued certificates of types (c) and (d)
> because the certified public key may not be used to verify certificate
> signatures.
I think X.509 is also not quite clear about that.
X.509 (2000) 8.2.2.3 says:
   The bit keyCertSign is for use in CA-certificates only. If KeyUsage
   is set to keyCertSign and the basic constraints extension is present
   in the same certificate, the value of the cA component of that extension
   shall be set to TRUE. CAs may also use other of the defined key usage
   bits in KeyUsage, e.g. digitalSignature for providing authentication and
   integrity of on-line administration transactions.

It looks like CA-certificates might contain the basic constraints extension
with the cA value set to TRUE and contains key usage extension without
the keyCertSign bit set.

X.509 (2000) 11.2.2 says:
  The cACertificate attribute of a CA's directory entry shall be used to store
   self-issued certificates (if any) and certificates issued to this CA by CAs
   in the same realm as this CA. In the case of v3 certificates, these
   certificates shall include a basicConstraints extension with the cA value
   set to TRUE. The definition of realm is purely a matter of local policy.

That seems to imply that all self-issued v3 certificates (intermediate or
non-intermediate) shall include a basicConstraints extension with the
cA value set to TRUE.

As I mentioned in my mail to reply to Tom, X.509 itself is not consistent
with the definition of CA certificates. I think we have to clarify what kind
of interpretation is suitable for PKIX.

>
> >When perform path validation, it is not clear what will be the effect
> >if some certificate extensions such as policyMappings, policyConstraints,
> >nameConstraints, and inhibitAnyPolicy appear in self-issued
> >intermediate certificates (i.e., self-issued certificate of type (b)).
> >The current text only says that this type of self-issued certificates do not
> >contribute to the path length for purposes of processing some constraint
> >extension and name constrains extension in certification path validation,
> >it is not clear that whether these extensions can appear in this type of
> >self-issued certificate.
> >
> >There is a serious security problem related to revocation status
> >checking for self-issued certificates of type (b) and (c).
> >For type (b), it might be a CA key rollover situation, and if the CA stopped
> >using its old key to issue CRL, then there is no way to check the revocation
> >status of the new self-issued certificate unless there is another way (e.g.,
> >OCSP or other out-of-band mechanism) to check its revocation status.
> >If the new key is unfortunately compromised later, this will be a serious
> >security problem.
> >
> >For type (c), since the CA is using separate key for CRL signing and
> >its Certificate with cRLSign key usage is signed by itself not signed
> >by another CA. Therefore, no one can provide the revocation status
> >info for that self-issued certificates unless there is another way (e.g.,
> >OCSP or other out-of-band mechanism) to check its revocation status.
> >If its CRL signing key is unfortunately compromised, this will be a serious
> >security problem.
> >
> I think it is important to address these issues, but believe that will
> need to be in a separate document, not in 3280bis.

I have no objection on having a separate document to address these issues.
However, I think RFC 3280bis should at lease mention these issues
in the security consideration section.

It seems that RFC 3280 and X.509 are encouraging implementors
to use self-issued certificates (especially for key rollover and separating
CRL signing key). However, the more deep I investigate issues related to
them, the more I think it is not a good idea to adopt self-issued certificates.

We should have some cautions in RFC 3280bis to remind implementors
the security issues thay will face it they adopt self-issued certificates.

>
> >Finally, it is not clear that, when a RP choose to use X.500 string matching
> >rules (or StringPrep-based String matching rules), whether certificates with
> >identical non-empty issuer name and subjec name but with different string
> >encoding (e.g., one in PrintableString while one in UTF8String) are also
> >thought as self-issued certificates.
> >
> If the issuer and subject name in a certificate match (according to the
> rules specified in stringprep or whatever), the the certificate is a
> self-issued certificate.  The problem, of course, is that many relying
> parties, using more limited matching rules, will not recognize that the
> certificate is self-issued and will treat it as a non-self-issued
> certificate.
>
> Dave
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJA7Elx063547; Fri, 19 Nov 2004 02:07:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJA7ETr063546; Fri, 19 Nov 2004 02:07:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw ([202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJA78Dh063408 for <[e-mail]>; Fri, 19 Nov 2004 02:07:08 -0800 (PST) (envelope-from [e-mail])
Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAJA6v7c003535; Fri, 19 Nov 2004 18:06:57 +0800
Received: (from root@localhost) by ms20.chttl.com.tw (8.12.10/8.12.10) id iAJA6ut7010264; Fri, 19 Nov 2004 18:06:56 +0800
Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAJA6rL1010194; Fri, 19 Nov 2004 18:06:53 +0800
Message-ID: <013c01c4ce1f$7f2844b0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <[e-mail]>
Subject: Re: 3280bis issue:  issues related to self-issued certificates
Date: Fri, 19 Nov 2004 18:06:51 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

Yes, I do mean certificates of type (b) are self-issued
intermediate certificates. Thanks for correcting my typo.

And, you are right, RFC 3280 4.2.1.10 implies that type (c)
MAY contain a basicConstraints extension with cA = TRUE.
It even implies that type (d) MAY also contain a basicConstraints
extension with cA = TRUE, which are CMP certificates you
refered.

However, after rereading RFC 3280, my feeling is the
definition of the term "CA certificate" is not clear enough.
The meaning of the term "CA certificate" is not consistent
all over the text of RFC 3280.

For example:

RFC 3280 4.2.1.2 says
   To facilitate certification path construction, this extension MUST
   appear in all conforming CA certificates, that is, all certificates
   including the basic constraints extension (section 4.2.1.10) where
   the value of cA is TRUE.

That seems to imply "CA certificates" are "certificates contain the
basicConstraints extension with cA = TRUE". This also implies
that "certificates that do not conatin the basicConstraints extension
with cA = TRUE" are not "CA certificates". (i.e., they are EE
certificates.)

However, RFC 3280 4.2.1.10 says
   This extension (basicConstraints) MAY appear as a critical
   or non-critical extension in CA certificates that contain public keys
   used exclusively for purposes other than validating digital
   signatures on certificates.

That imply "CA certificates" need not conatin "the basicConstraints
extension with cA = TRUE" as long as the keyCertSign bit is not set
in the keyUsage extension it contains (if any).

Actually, I found the X.509 standard itself has some conflicts
about the definition of "CA certificates".

X.509 (2000) 3.3.9 says
   CA-certificate:  A certificate for one CA issued by another CA.

It seems that the term "CA certificate" is simple a synonym of
"cross certificate".

However, X.509 (2000) chapter 7 says
   A CA-certificate is a certificate issued by a CA to a subject that is
   itself a CA and therefore is capable of issuing public-key certificates.
   CA-certificates can be themselves categorized by the following types:
     - Self-issued certificate - ...
     - Self-signed certificate - ... 
     - Cross certificate - ...

That means a CA certificate not only can be "a certificate for one CA
issued by another CA" (a cross certificate) but also can be "a
certificate for one CA issued by the CA itself" (a self-issued certificate or
a self-signed certificate).

In both X.509 and RFC 3280, mostly the term "a CA certificate" actually
means "a CA certificate with keyCertSign key usage".

For example,

X.509 (2000) 8.2.2.7 (Policy mappings extension) says

   This field, which shall be used in CA-certificates only, ...

RFC 3280 4.2.1.6 (Policy Mappings) says
   This extension is used in CA certificates. ...

In these cases, by "CA certificates" they actually mean
"a CA certificate with keyCertSign key usage" since policy
mappings extension should not appear in a CA certificates
without keyCertSign key usage.

The current usages of the term "CA certificate" in both X.509
and RFC 3280 are not precise enough. As a result, when we
see the term "CA certificate" in X.509 and RFC 3280, we have
to guess its meaning from the context.  It might mean a
Root CA certificate, a cross certificate, an self-issued
intermediate certificate (with keyCertSign key usage ),
a self-issued certificate with cRLSign key usage only, or
a self-issued certificate with key usages other than keyCertSign
and  cRLSign.

To make the useage of the term more precise, I suggest
RFC3280bis (and X.509 as well) should claerly define the
following terms:
  "self-issued certificate"
  "self-signed certificate"
  "self-issued intermediate certificate"
  "cross certificate"
  "CA certificate"
  "root CA certificate (a.k.a. root certificate)"
  "intermediate CA certificate (a.k.a. intermediate certificate)"

For example, the term "intermediate CA certificate" might
be defined as follows:

   intermediate CA certificate:
         a cross certificate or a self-issued intermediate certificate

With this definition, the usages of the term "CA certificate" in
both X.509 and RFC 3280 can be more precise.

For example,

X.509 (2000) 8.2.2.7 (Policy mappings extension) can say

   This field, which shall be used in intermediate CA-certificates only, ...

RFC 3280 4.2.1.6 (Policy Mappings) says
   This extension is used in intermediate CA certificates. ...

Especially, I think we should distinguish between root CA certificates
and intermediate CA certificates because there are many extensions
that should not appear root CA certificates.

As for the distinction of different type of self-signed certificates:
Yes, I think it is better to distinguish between self-signed certs used as 
CA roots and all other self-signed certs. That is why I suggest
the term "root CA certificate" or "root certificate" should be defined.

As for the security problem of CRL signing key compromised, I
do not think "Issue a new CRL signing key and revoke the old one"
can help for solving the problem. Please see the following case:

TA->CA1(keyCertSign Key)->CA1(crlSign Key 1)------>CRL1
TA->CA1(keyCertSign Key)->CA1(crlSign Key 2)------>CRL2

which means the crlSign Key 1 of CA1 is compromised and
CA1 changes to use the crlSign Key 2 for signing CRL.

Since the RP will not check the revocation status of crlSign Key 1,
the path "TA->CA1(keyCertSign Key)->CA1(crlSign Key 1)" will
still look valid from the viewpoint of the RP. Therefore, the RP
will accept CRL1 (signed by crlSign Key 1), which might be
a foged CRL. The RP will never that it should check CRL2 (signed
by crlSign Key 2) for the revocation status of crlSign Key 1.

Wen-Cheng Wang

----- Original Message ----- 
From: "Tom Gindin" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>
Cc: "David A. Cooper" <[e-mail]>; "pkix" <[e-mail]>
Sent: Thursday, November 18, 2004 8:36 PM
Subject: Re: 3280bis issue: issues related to self-issued certificates


> 
>         Wen-Cheng:
> 
>         Do we also need to distinguish between self-signed certs used as 
> CA roots (either v1 or those with keyCertSign set) and all other 
> self-signed certs?
>         Responses below.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Wen-Cheng Wang" <[e-mail]>
> Sent by: [e-mail]
> 11/17/2004 05:36 AM
>  
>         To:     "David A. Cooper" <[e-mail]>, "pkix" 
> <[e-mail]>
>         cc: 
>         Subject:        3280bis issue:  issues related to self-issued 
> certificates
> 
> 
> 
> The definition of the term "self-issued certificate" is too vague.
> 
> The current text of RFC 3280 only mention
> 
> "A certificate is self-issued if the DNs that appear in the subject
>  and issuer fields are identical and are not empty....a CA may
>  issue a certificate to itself to support key rollover or changes in
>  certificate policies.  These self-issued certificates are not counted
>  when evaluating path length or name constraints."
> 
> However, there are many kinds of self-issued certificates. For
> example:
> 
> (a) self-signed certificates (this is a special case of self-issued 
> certificate)
> (b) self-issued certificates with keyCertSign key usage (might with 
> cRLSign key usage as well)
> (c) self-issued certificates with cRLSign key usage only (a CA using 
> separate key for CRL signing)
> (d) self-issued certificates with key usages other than keyCertSign and 
> cRLSign
> 
> Self-issued certificates of type (c) are also known as "self-issued
> intermediate certificates" according to the X.509 (2000) standard.
> Obviously, only self-issued certificates of type (c) are thought to
> be CA certificates. However, they are special CA certificates
> for special purpose (e.g., Key Rollover) so that they do not contribute
> to the path length for purposes of processing some constraint
> extension and name constrains extension in certification path validation.
> 
> 
> [TG] You do mean type (b), don't you?
> 
> Self-issued certificates of type (a), (c) and (d) can not be
> intermediate certificates and thus the above special processing
> rule does not apply to them. This is not crystal clear in the current
> text of RFC 3280.
> 
> Obviously, self-issued certificates of type (a) and (b) should conatins
> a basicConstraints extension with cA = TRUE since they are
> CA certificates.
> 
> It is not clear whether self-issued certificates of type (c) should
> also conatins a basicConstraints extension with cA = TRUE.
> 
> [TG] RFC 3280 4.2.1.10 says MAY, and it classifies CMP certificates with 
> them.
> 
> Self-issued certificates of type (d) should be thought as EE
> certificates, therefore they should not contain  a basicConstraints
> extension with cA = TRUE. However, some PKIX WG members
> might not agree to this interpretation.
> 
> When perform path validation, it is not clear what will be the effect
> if some certificate extensions such as polcyMappings, policyConstraints,
> nameConstraints, and inhibitAnyPolicy appear in self-issued 
> intermediate certificates (i.e., self-issued certificate of type (b)).
> The current text only says that this type of self-issued certificates do 
> not
> contribute to the path length for purposes of processing some constraint
> extension and name constrains extension in certification path validation,
> it is not clear that whether these extensions can appear in this type of
> self-issued certificate.
> 
> There is a serious security problem related to revocation status
> checking for self-issued certificates of type (b) and (c).
> For type (b), it might be a CA key rollover situation, and if the CA 
> stopped
> using its old key to issue CRL, then there is no way to check the 
> revocation
> status of the new self-issued certificate unless there is another way 
> (e.g.,
> OCSP or other out-of-band mechanism) to check its revocation status.
> If the new key is unfortunately compromised later, this will be a serious
> security problem.
> 
> For type (c), since the CA is using separate key for CRL signing and
> its Certificate with cRLSign key usage is signed by itself not signed
> by another CA. Therefore, no one can provide the revocation status
> info for that self-issued certificates unless there is another way (e.g.,
> OCSP or other out-of-band mechanism) to check its revocation status.
> If its CRL signing key is unfortunately compromised, this will be a 
> serious
> security problem.
> 
> [TG] Issue a new CRL signing key and revoke the old one.  The revocation 
> will take effect with the same timing effects as the revocation of an EE 
> certificate - an attacker can always replay a CRL until its expiration 
> time.
> 
> Finally, it is not clear that, when a RP choose to use X.500 string 
> matching
> rules (or StringPrep-based String matching rules), whether certificates 
> with
> identical non-empty issuer name and subjec name but with different string
> encoding (e.g., one in PrintableString while one in UTF8String) are also
> thought as self-issued certificates.
> 
> Wen-Cheng Wang
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ9F1x5039165; Fri, 19 Nov 2004 01:15:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJ9F1uc039164; Fri, 19 Nov 2004 01:15:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ9Ex5S038967 for <[e-mail]>; Fri, 19 Nov 2004 01:14:59 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA15146; Fri, 19 Nov 2004 10:27:04 +0100
Received: from bull.net ([129.181.81.121]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111910145036:2700 ; Fri, 19 Nov 2004 10:14:50 +0100 
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 10:14:54 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: 3280bis: indirectCRL boolean in IDP (3/3)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/11/2004 10:14:52, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/11/2004 10:14:54, Serialize complete at 19/11/2004 10:14:54
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Dave,<br>
<blockquote type="cite" cite="[e-mail]">&nbsp;Denis,<br>
  <br>
This is the last time that I am going to comment on this, either here
or on the X.500 list.<br>
</blockquote>
Maybe not, since as you will see, we are close to an agreement.<br>
<blockquote type="cite" cite="[e-mail]">
  <ol>
    <li>
      <p>"CA" and "CRL issuer" define types of entities, not roles.&nbsp; An
entity that issues public key certificates <b>is</b> a CA.&nbsp; An entity
that issues CRLs <b>is</b> a CRL issuer.&nbsp; Thus, a CA may issue CRLs
and a CRL issuer may issue certificates.</p>
    </li>
    <li>
      <p>The issuer of an indirect CRL may also certificates.&nbsp; If it
does
issue certificates, then it may issue a single CRL that covers its own
certificates in addition to the certificates of other CA.&nbsp; This is why
RFC 3280 states: "If [the certificateIssuer] extension is not present
on the first entry in an indirect CRL, the certificate issuer defaults
to the CRL issuer."&nbsp; If a CA issues a CRL that covers both its own
certificates and the certificates of other CAs, and the first entry in
the CRL corresponds to a certificate issued by the issuer of the CRL,
then the certificateIssuer extension does not need to be included in
that entry.</p>
    </li>
    <li>The indirectCRL flag in the issuingDistributionPoint extension
is
set whenever the CRL covers certificates signed by an entity other than
the issuer of the CRL.&nbsp; That is, if the CRL covers any certificate that
has an <b>issuer</b> name different from the <b>issuer<i> </i></b>name
in the CRL, then the indirectCRL flag is set to TRUE. </li>
  </ol>
</blockquote>
>From 1, since an "entity
that issues CRLs <b>is</b> a CRL issuer", an entity that issues
certificates cannot be called a CRL issuer. <br>
This is exactly why we have problems with the current text. From 2, the
sentence "the issuer of an indirect CRL may also certificates" is in
contradiction with 1: an entity that issues public key certificates <b>is</b>
a CA, not a CRL issuer. This only a problem of naming but this problem
needs to be sort out. See below.<br>
<br>
I would reformulate slightly your sentence: "If an authority issues
certificates, then the same authority&nbsp; may issue a single CRL that
covers its own
certificates in addition to the certificates of other CAs." This is why
RFC 3280 should state: "If [the certificateIssuer] extension is not
present
on the first entry in an indirect CRL, the certificate issuer defaults
to the name contained in the issuer field of the CRL."&nbsp; If you can
agree with this modification, then this will solve my concern.<br>
<br>
About 3, RFC 3280 states: <span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;">"The CRL
issuer MUST assert the indirectCRL boolean,
if the scope of the CRL includes certificates issued by authorities
other than
the CRL issuer.<span style="">"&nbsp; </span></span>You said: "The
indirectCRL flag in the issuingDistributionPoint extension is
set whenever the CRL covers certificates signed by an entity other than
the issuer of the CRL." I fully agree with your text which should come
into replacement of the RFC 3280 quoted sentence.<br>
<br>
I also agree with your additional explantion, which is: "if the CRL
covers any certificate that
has an <b>issuer</b> name different from the <b>issuer<i> </i></b>name
in the CRL, then the indirectCRL flag is set to TRUE, otherwise it is
not." This additional sentence could be useful.<br>
<br>
This demonstrates that through a dialogue, it is possible to come to
agreements.<br>
<br>
Denis<br>
<br>
<blockquote type="cite" cite="[e-mail]">Denis
Pinkas wrote:<br>
  <blockquote type="cite" cite="[e-mail]">
    <meta http-equiv="Content-Type" content="text/html;">
    <title></title>
    <meta http-equiv="Content-Type"
 content="text/html;charset=ISO-8859-1">
    <title></title>
    <meta http-equiv="Content-Type"
 content="text/html;charset=ISO-8859-1">
    <title></title>
David,<br>
    <blockquote type="cite" cite="[e-mail]">&nbsp;Denis
Pinkas wrote:<br>
      <blockquote type="cite" cite="[e-mail]">
        <meta http-equiv="Content-Type" content="text/html;">
        <title></title>
        <meta http-equiv="Content-Type"
 content="text/html;charset=ISO-8859-1">
        <title></title>
James,<br>
        <br>
        <blockquote type="cite"
 cite="[e-mail]">
          <pre wrap="">The indirectCRL field should not be redefined.
CRL issuers do issue certificates if they are also CAs (as they often
are).  </pre>
        </blockquote>
When the term CRL Issuer is used, it means an entity issuing CRLs, not
certificates. <br>
If an entity issues public key certificates, then it is called a CA.</blockquote>
This is not true.&nbsp; Paragraph 3 of section 5 in RFC 3280 begins: "CRL
issuers issue CRLs.&nbsp; In general, the CRL issuer is the CA."<br>
    </blockquote>
which means: " In general, the CA is also the CRL issuer". <br>
    <blockquote type="cite" cite="[e-mail]">A CRL
issuer is an entity that issues CRLs.&nbsp; </blockquote>
Correct.<br>
    <blockquote type="cite" cite="[e-mail]">A CRL
issuer may or may
not be a CA (i.e., an entity that issues certificates).&nbsp; </blockquote>
Not exactly. An entity which issues CRLs may or may not also issue
certificates.<br>
    <blockquote type="cite" cite="[e-mail]">An
entity
that
issues indirect CRLs may or may not be a CA.&nbsp; </blockquote>
I have a problem here. If you look at James proposal, he is proposing:<br>
    <span class="032531201-18112004">
    <div><font face="Arial"><font><font color="#008080" size="2"><span
 class="032531201-18112004"><font color="#ff0000">Indirect&nbsp;</font><font
 color="#008080">CRL Issuer: an optional system to which a CA delegates
the publication of certificate revocation lists;</font></span></font></font></font><br>
    </div>
    </span>If there is a delegation, this means that it does not issue
CRLs
for itself.<br>
    <blockquote type="cite" cite="[e-mail]">If it
is
a
CA, then it
may issue a single CRL that covers its own certificates in addition to
the certificates of other CAs.&nbsp; </blockquote>
Same problem as above.<br>
    <br>
    <blockquote type="cite" cite="[e-mail]">
      <blockquote type="cite" cite="[e-mail]">The
question is the meaning of the indirectCRL boolean in IDP.<br>
        <br>
If we take a look at X.509, it is defined in the following way:<br>
        <br>
        <span lang="EN-GB" style="font-size: 10pt; font-family: Times;">"<big>If
        </big></span><big><big><big><big><big><b style=""><span
 lang="EN-GB" style="font-size: 9pt; font-family: Helvetica;">indirectCRL</span></b></big><span
 lang="EN-GB" style="font-size: 10pt; font-family: Times;"><big> is
true, then the CRL may contain revocation
notifications from authorities <br>
other than the issuer of the CRL.</big> "<br>
        <br>
        <big>Note the sentence, even incorrect at the end (and thus
duplicating
an incorrect sentence from X.509)<br>
&nbsp;is using the plural, i.e. "</big></span></big></big></big></big><big><big><big><big><span
 lang="EN-GB" style="font-size: 10pt; font-family: Times;"><big>from
authorities" </big></span></big></big></big></big>which means it is an
indirect CRL of type b).<br>
      </blockquote>
You are misreading this sentence.&nbsp; This does not mean that the
indirectCRL flag is only set to true if the CRL may contain revocation
notifications from more than one authority other than the issuer of the
CRL.&nbsp; As long as the scope of the CRL includes certificates issued by
an entity other than the issuer of the CRL then the indirectCRL flag
must be set to true.</blockquote>
We cannot understand each other since you are still using the words
"certificates issued by an entity other than the issuer of the CRL". <br>
If we address the prtoblem from the relying party point of view, maybe
we will be able to have a common level of understanding.<br>
    <blockquote type="cite" cite="[e-mail]">If some
people are misinterpreting the current text to mean that the
flag should only be set if the CRL covers more than one CA other than
the CRL issuer then we can work on rewording the text.&nbsp; But, we can not
change the meaning of the indirectCRL flag.<br>
    </blockquote>
The goal is not to change the meaning, whatever the meaning is, but to
clarify the meaning so that we may all understand the same thing. <br>
Then we will have to undertstand (and agree) what kind of processing a
RP can do with that flag. I can provide the beginning of the story:<br>
    <br>
"A RP got a CRL that is supposed to be about a given certificate for
which a path has been constructed.<br>
The RP can check if the two following conditions are true: <br>
    <br>
&nbsp;1) the name of the issuer of the CRL is the same as the name of the CA,<br>
&nbsp;2) the CRL is signed using the same key as the key of the CA.<br>
    <br>
If it is the case then this CRL is issued by the CA, acting as a CRL
Issuer."<br>
    <br>
Now what kind of test should be done with the indirectCRL boolean in
the IDP ?<br>
Can that boolean be set to TRUE in any case ? <br>
    <br>
Denis<br>
    <blockquote type="cite" cite="[e-mail]">Dave<br>
    </blockquote>
  </blockquote>
</blockquote>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ9D3DF036583; Fri, 19 Nov 2004 01:13:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJ9D3J9036582; Fri, 19 Nov 2004 01:13:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ9CrPv036298 for <[e-mail]>; Fri, 19 Nov 2004 01:12:54 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA12756; Fri, 19 Nov 2004 10:24:55 +0100
Received: from bull.net ([129.181.81.121]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111910124214:2695 ; Fri, 19 Nov 2004 10:12:42 +0100 
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 10:12:43 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/11/2004 10:12:42, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/11/2004 10:12:44, Serialize complete at 19/11/2004 10:12:44
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

>CA1->CA2  with nameing constraints permitted XYW2 means:
>
>  CA1 issued a certificate to CA2 and sets a permitted subtree allowing
>  CA2 to issue certs starting with XYZ2 
>
>CA1->CA2  with nameing constraints permitted XYW2 means:
>
>  CA1 issues a certificate to CA3 and sets a permitted subtree allowing
>  CA3 to issue certs starting with XYZ3 
>
>CA2 and CA3 want to use CA1 as CRLissuer, i.e. that the rule
>in the policy agreed with CA1. Thus they set crlUssuer = CA1 in
>all certs they they create. 
>
>But CA2 and CA3 cannot issue a certificate with a DN=CA1 with a CRLSign bit
>since this would violate the naming constraints in that path!
>  
>
You say that this is incompatible with naming constraints.
One solution would be to remove or change naming constraints.

Denis








Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ430TU071693; Thu, 18 Nov 2004 20:03:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJ430xC071692; Thu, 18 Nov 2004 20:03:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ42r2v071649 for <[e-mail]>; Thu, 18 Nov 2004 20:02:53 -0800 (PST) (envelope-from [e-mail])
Received: by rproxy.gmail.com with SMTP id g11so70295rne for <[e-mail]>; Thu, 18 Nov 2004 20:02:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=qyF8VjfIvTrYXK7ClC0nvVdNpOOfnWw8OgO9iPOUCwVrQ8hQU7wk50I93Z5hHzrgIzlrOKA5JphGsumXL+KAcd2OwAGF3BJMi4nTaaUe5idiw6WL35fT+A6e2xvfGQrGQ5R3/eofMX4Rz9C5Rc9iNc31yw+ORyYhIrOy/TvJCJk=
Received: by 10.38.92.23 with SMTP id p23mr225195rnb; Thu, 18 Nov 2004 20:02:59 -0800 (PST)
Received: by 10.38.81.56 with HTTP; Thu, 18 Nov 2004 20:02:59 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 15:02:59 +1100
From: Andrew Sciberras <[e-mail]>
Reply-To: Andrew Sciberras <[e-mail]>
To: Tim Polk <[e-mail]>
Subject: Re: WG Last Call: CRL Schema
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

In Section 2 - 'DIT Structure and Naming', the x509CRLentryNameForm
Name Frm is defined.
This makes reference to an attribute called x509serial. Is this
supposed to read x509serialNumber?

An entry with a x509CRLentry Object Class must contain an
x509serialNumber attribute within the entry. This attribute must be
used as a naming attribute as well. CRL's can contain many revoked
certificate serial numbers. So, why would you use a serial number to
form the RDN? Do you simply pick one revoked serial number at random
to use as the distinguished value?
OR, is this serial number refering to the serial number of the issued
CRL? Which is counter to the description of x509serialNumber provided
in Section 4...

Regards,
Andrew Sciberras,


On Mon, 15 Nov 2004 17:26:40 -0500, Tim Polk <[e-mail]> wrote:
> 
> 
> This message initiates working group Last Call for the "LDAP Schema for
> X.509 CRLs" specification. The editors have confirmed that all working
> group issues have been resolved.
> 
> The URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-03.txt
> 
> This specification has also been forwarded to the LDAP Directorate for a
> parallel review.  Assuming successful Last Call and concurrence from the
> LDAP Directorate, this document will be forwarded to the ADs for
> consideration as an Informational track RFC.
> 
> Last Call will run for (at least) two weeks. That is, Last Call will not
> close before November 29.
> 
> Thanks,
> 
> Tim Polk
> 
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ3ld0a066643; Thu, 18 Nov 2004 19:47:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJ3ldtq066642; Thu, 18 Nov 2004 19:47:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ3lcDd066632 for <[e-mail]>; Thu, 18 Nov 2004 19:47:39 -0800 (PST) (envelope-from [e-mail])
Received: by rproxy.gmail.com with SMTP id g11so68567rne for <[e-mail]>; Thu, 18 Nov 2004 19:47:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=lwfuq7wux1Wu7cA+B/XMfHGverCEvu0gss0U0XlL2AbAv/gYB76JVUXv8j8PrMtUVTtl+3rA2n87XUSUqZy5q887X0n9xgJmNmIl8+NdLb/0CJD2LiDekCYz8wVgTyCUh/3Lem99qIjqaIQjGPEcDtDvYQre9q/d/JZFG0AS9kU=
Received: by 10.38.67.12 with SMTP id p12mr219146rna; Thu, 18 Nov 2004 19:47:45 -0800 (PST)
Received: by 10.38.81.56 with HTTP; Thu, 18 Nov 2004 19:47:45 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 14:47:45 +1100
From: Andrew Sciberras <[e-mail]>
Reply-To: Andrew Sciberras <[e-mail]>
To: Tim Polk <[e-mail]>
Subject: Certificate Schema (Object Class)
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

I'm looking at the x509userCertificate Object Class...

( 1.3.6.1.4.1.10126.1.5.4.2.4
         NAME 'x509userCertificate'
         SUP x509PKC
         STRUCTURAL
         MUST userCertificate
         MAY  x509subject )

This definition is followed with the statement:
"   The attribute type x509subject is specified here as a MAY attribute.
   Nevertheless if this attribute is not used at least one of the
   following attributes MUST be filled in: x509subjectRfc822Name,
   x509subjectDnsName, x509subjectDirectoryName, x509subjectURI,
   x509subjectIpAddress, or x509subjectRegisteredID."

This is either problematic or not specified clearly enough. 
In order for one of these attributes to be present in the entry then
they should be an optional attribute within the x509userCertificate
object class.
If there is a reason why they shouldn't be in the optional list, then
I think text that makes reference to the use of  DIT Content Rules to
permit this.

Regards,
Andrew Sciberras
eB2Bcom Pty Ltd



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ3cjPQ064843; Thu, 18 Nov 2004 19:38:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJ3cjuR064842; Thu, 18 Nov 2004 19:38:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ3chKj064834 for <[e-mail]>; Thu, 18 Nov 2004 19:38:44 -0800 (PST) (envelope-from [e-mail])
Received: by rproxy.gmail.com with SMTP id f1so59214rne for <[e-mail]>; Thu, 18 Nov 2004 19:38:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Y4v0623tiCGXnVFhEemlCbo8xtFbZXa6uSx312B+Z4BQ06cShO+fHyfo5Sf8NgWWAYypXyx26h+R44WdXKJEQBGiMLIFxnsjbnM5SB1l7IgxTpWKyoO8l8wXxHi9yIcCYgfFIVE4l2sn3fB7dWBkw3P6oyqOi5chW5enHHoS21k=
Received: by 10.38.125.32 with SMTP id x32mr214474rnc; Thu, 18 Nov 2004 19:38:49 -0800 (PST)
Received: by 10.38.81.56 with HTTP; Thu, 18 Nov 2004 19:38:49 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 14:38:49 +1100
From: Andrew Sciberras <[e-mail]>
Reply-To: Andrew Sciberras <[e-mail]>
To: Peter Gietz <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Cc: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi

On Thu, 18 Nov 2004 10:14:02 +0100, Peter Gietz <[e-mail]> wrote:
> Hi Andrew,
> 
> Thanks for your comments:
> 
> Andrew Sciberras wrote:
> 
> >Hi,
> >
> >Do you have any concerns about the fact that the Serial Number
> >attribute (section 5.1.2) does not contain an ordering matching rule?
> >
> >Is it intentional that the Serial Number attribute is not 'SINGLE-VALUE'?
> >
> >
> Yes that was intentional, since the attribute is used as multivalue in
> the CRL document. I quote David Chadwick:
 
Not a problem. :) 
I do have a some comments about this, but I'll do it in a subsequent email. 


> >
> >Section 5.2.3  Key usage Extension
> >If you have a certificate with a keyUsage extension present with a
> >value of zero (i.e. none of the bits are set) what do you do? Do you
> >simply omit using the x509keyUsage atribute? If not, how does the BNF
> >represent such a value?
> >
> >
> I will include Norbert's proposed text into the draft to get this one
> straight.

Excellent. 

> 
> Cheers,
> 
> Peter
> 


Cheers,
Andrew.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ10eoK008743; Thu, 18 Nov 2004 17:00:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJ10e55008742; Thu, 18 Nov 2004 17:00:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ10a5q008707 for <[e-mail]>; Thu, 18 Nov 2004 17:00:39 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAJ10aG4502054 for <[e-mail]>; Thu, 18 Nov 2004 20:00:36 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAJ10a9H287720 for <[e-mail]>; Thu, 18 Nov 2004 20:00:36 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAJ10aH9011414 for <[e-mail]>; Thu, 18 Nov 2004 20:00:36 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAJ10aMP011409; Thu, 18 Nov 2004 20:00:36 -0500
In-Reply-To: <[e-mail]>
Subject: Re: 3280bis: indirectCRL boolean in IDP (3/3)
To: Denis Pinkas <[e-mail]>
Cc: "David A. Cooper" <[e-mail]>, pkix <[e-mail]>
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <[e-mail]>
From: Tom Gindin <[e-mail]>
Date: Thu, 18 Nov 2004 19:44:02 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF2 (6.53IBM1)|October 29, 2004) at 11/18/2004 20:00:35
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Denis:

      The indirectCRL boolean is set in any CRL which governs certificates
whose issuers have DN's different from the DN of the CRL's signer.  This is
independent of whether it is legal for the same CRL to govern certificates
whose issuers have the same DN as that of the CRL's signer.  I believe
these formulations are observable by RP's, and the first one is just a
restatement of RFC 3280 5.2.5.  However, the indirectCRL boolean has no
function in the verification of a certificate which doesn't contain the
cRLIssuer field in a CRL Distribution Points extension unless you ban CRL's
with both direct and indirect entries.  It does have a function in the
verification of a certificate which does contain cRLIssuer.
      BTW, I don't know how much use this field is to implementors as a
boolean and I think it might have been more useful as a SET of issuer
names.  However, we can hardly change its definition in a profile of X.509.

            Tom Gindin
P.S. -      The opinions in this message are mine, and not necessarily
those of my employer.



                                                                                           
                      Denis Pinkas                                                         
                      <Denis.Pinkas@bul        To:       "David A. Cooper"                 
                      l.net>                    <[e-mail]>                    
                      Sent by:                 cc:       pkix <[e-mail]>          
                      owner-ietf-pkix@m        Subject:  Re: 3280bis: indirectCRL boolean  
                      ail.imc.org               in IDP (3/3)                               
                                                                                           
                                                                                           
                      11/18/2004 09:09                                                     
                      AM                                                                   
                                                                                           




David,
       Denis Pinkas wrote:
            James,

                  The indirectCRL field should not be redefined.
                  CRL issuers do issue certificates if they are also CAs
                  (as they often
                  are).
            When the term CRL Issuer is used, it means an entity issuing
            CRLs, not certificates.
            If an entity issues public key certificates, then it is called
            a CA.
      This is not true.  Paragraph 3 of section 5 in RFC 3280 begins: "CRL
      issuers issue CRLs.  In general, the CRL issuer is the CA."
which means: " In general, the CA is also the CRL issuer".
      A CRL issuer is an entity that issues CRLs.
Correct.
      A CRL issuer may or may not be a CA (i.e., an entity that issues
      certificates).
Not exactly. An entity which issues CRLs may or may not also issue
certificates.
      An entity that issues indirect CRLs may or may not be a CA.
I have a problem here. If you look at James proposal, he is proposing:
Indirect CRL Issuer: an optional system to which a CA delegates the
publication of certificate revocation lists;
If there is a delegation, this means that it does not issue CRLs for
itself.
      If it is a CA, then it may issue a single CRL that covers its own
      certificates in addition to the certificates of other CAs.
Same problem as above.

            The question is the meaning of the indirectCRL boolean in IDP.

            If we take a look at X.509, it is defined in the following way:

            "If indirectCRL is true, then the CRL may contain revocation
            notifications from authorities
            other than the issuer of the CRL. "

            Note the sentence, even incorrect at the end (and thus
            duplicating an incorrect sentence from X.509)
             is using the plural, i.e. "from authorities" which means it is
            an indirect CRL of type b).
      You are misreading this sentence.  This does not mean that the
      indirectCRL flag is only set to true if the CRL may contain
      revocation notifications from more than one authority other than the
      issuer of the CRL.  As long as the scope of the CRL includes
      certificates issued by an entity other than the issuer of the CRL
      then the indirectCRL flag must be set to true.
We cannot understand each other since you are still using the words
"certificates issued by an entity other than the issuer of the CRL".
If we address the prtoblem from the relying party point of view, maybe we
will be able to have a common level of understanding.
      If some people are misinterpreting the current text to mean that the
      flag should only be set if the CRL covers more than one CA other than
      the CRL issuer then we can work on rewording the text.  But, we can
      not change the meaning of the indirectCRL flag.
The goal is not to change the meaning, whatever the meaning is, but to
clarify the meaning so that we may all understand the same thing.
Then we will have to undertstand (and agree) what kind of processing a RP
can do with that flag. I can provide the beginning of the story:

"A RP got a CRL that is supposed to be about a given certificate for which
a path has been constructed.
The RP can check if the two following conditions are true:

 1) the name of the issuer of the CRL is the same as the name of the CA,
 2) the CRL is signed using the same key as the key of the CA.

If it is the case then this CRL is issued by the CA, acting as a CRL
Issuer."

Now what kind of test should be done with the indirectCRL boolean in the
IDP ?
Can that boolean be set to TRUE in any case ?

Denis
      Dave



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ0I7oK093068; Thu, 18 Nov 2004 16:18:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAJ0I7NU093067; Thu, 18 Nov 2004 16:18:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-35.mail.demon.net (anchor-post-35.mail.demon.net [194.217.242.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAJ0I6tv093056 for <[e-mail]>; Thu, 18 Nov 2004 16:18:06 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-35.mail.demon.net with esmtp (Exim 4.42) id 1CUwTI-000A8L-IB; Fri, 19 Nov 2004 00:17:53 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 00:18:58 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: RFC3280bis: policy processing.
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David A. Cooper wrote:
>   Stephen Henson wrote:
> 
>> While implementing policy processing for OpenSSL a couple of issues
>> arose in RFC3280 6.1.3:
>>
>> 2. In order for the valid_policy_tree to be a "tree" some additional
>> conditions were required. Specifically:
>>
>> a. The same OID cannot occur multiple times in the same certificate
>> policyIdentifier field of a Certificate Policies extension.
> 
> Yes.  The certificatePolicies extension logically contains a set of 
> certificate policies, referenced by OID.  So, the same OID should not 
> appear more than once.
> 
>> b. The same OID cannot occur multiple times in the subjectDomainPolicy
>> of the Policy Mappings extensions.
> 
> Actually, the same OID can occur multiple times in the 
> subjectDomainPolicy.  See below:
> 
> Certificate 1:
> 
>     certificatePolicies:  Red
>     policyMappings: Red -> Gold, Red -> Silver
> 
> Certificate 2:
> 
>     certificatePolicies:  Gold, Silver
>     policyMappings: Gold -> Medium, Silver -> Medium
> 
> Certificate 3:
> 
>     certificatePolicies:  Medium
> 
>                           +-----------------+
>                           |      Red        |
>                           +-----------------+
>                           |       {}        |
>                           +-----------------+ node of depth i-2
>                           |      FALSE      |
>                           +-----------------+
>                           |  {Gold, Silver} |
>                           +-----------------+
>                              /           \
>                             /             \
>                            /               \
>                           /                 \
>             +-----------------+           +-----------------+
>             |      Gold       |           |     Silver      |
>             +-----------------+           +-----------------+
>             |       {}        |           |       {}        |
>             +-----------------+ nodes of  +-----------------+
>             |      FALSE      | depth i-1 |      FALSE      |
>             +-----------------+           +-----------------+
>             |    {Medium}     |           |    {Medium}     |
>             +-----------------+           +-----------------+
>                      |                             |
>                      |                             |
>                      |                             |
>             +-----------------+           +-----------------+
>             |     Medium      |           |     Medium      |
>             +-----------------+           +-----------------+
>             |       {}        |           |       {}        |
>             +-----------------+ nodes of  +-----------------+
>             |      FALSE      | depth i   |      FALSE      |
>             +-----------------+           +-----------------+
>             |    {Medium}     |           |    {Medium}     |
>             +-----------------+           +-----------------+
> 

Ah, now I'd also assumed that you couldn't have duplicate nodes at the 
same depth. If that's allowed then it changes things...

>> 3. The use of the phrase "for each" in 6.1.4 b(1) implied to me that
>> there could me more than one node in the policy tree of depth i where
>> ID-P is the valid policy whereas there can be at most one. If condition
>> #2a above is valid there can be at most one. 
> 
> Perhaps the problem is with 6.1.3 (d)(1)(i).  Perhaps this step also 
> needs to state "for each node of depth i-1 where P-OID is in the 
> expected_policy_set...."  Would that clear up the confusion?
> 

There certainly seems a problem with the wording of either 
6.1.3(d)(1)(i) or 6.1.4 b(1). The current wording of 6.1.3 (d)(1)(i):

>             (i)  If the valid_policy_tree includes a node of depth i-1
>             where P-OID is in the expected_policy_set, create a child
>             node as follows: set the valid_policy to OID-P; set the
>             qualifier_set to P-Q, and set the expected_policy_set to
>             {P-OID}.

could well be interpreted to mean that only one child node is created if 
there's an appropriate node of depth i-1 which would mean you wouldn't 
get the situation in your example above at depth i.

When I looked at this before I also looked at X509 and cross referenced 
the X509 algorithm wording (which uses different structures) to the 
RFC3280 form.

I finally decided that it was 6.1.4(b)(1) that was at fault and 
duplicate nodes weren't permitted but it was late and I was tired when I 
looked at it...

I'll check through my notes to see if I can find the precise sections of 
X509 that lead me to that conclusion.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIN1GE6065590; Thu, 18 Nov 2004 15:01:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIN1Gf4065584; Thu, 18 Nov 2004 15:01:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from micah.software-aus.com.au (cust3103.vic01.dataco.com.au [202.63.62.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIN1ECv065552 for <[e-mail]>; Thu, 18 Nov 2004 15:01:14 -0800 (PST) (envelope-from [e-mail])
Received: from eb2bcom.com (192.168.1.166) by micah.software-aus.com.au (7.1.016.1) (authenticated as steven.legg) id 418EAC33000012A3; Fri, 19 Nov 2004 10:05:55 +1100
Message-ID: <[e-mail]>
Date: Fri, 19 Nov 2004 10:00:02 +1100
From: Steven Legg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: "Kurt D. Zeilenga" <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]> <6.1.2.0.0.20041118133645.02dade68@127.0.0.1>
In-Reply-To: <6.1.2.0.0.20041118133645.02dade68@127.0.0.1>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

And likewise for draft-legg-ldap-binary-xx.txt, upon which
draft-zeilenga-ldap-x509-00.txt depends.

Kurt D. Zeilenga wrote:
> Just to clarify a few non-technical points.  (I intend
> to offer my technical comments after I complete my
> review of the I-Ds).
> 
> At 11:26 AM 11/18/2004, Steve Hanna wrote:
> 
>>The schema described in RFC 2587 and updated by
>>draft-zeilenga-ldap-x509-00.txt [...]. I understand that the
>>zeilenga I-D is actually a product of the ldapbis
>>efforts and will probably advance with them.
> 
> 
> draft-zeilenga-ldap-x509-00.txt is presently an individual
> submission to the IETF.  Hence, it is not a product of
> the LDAPBIS WG.
> 
> It is my hope that after appropriate review by the PKIX WG,
> the LDAPBIS WG, and other parties, to submit this document
> to the IESG for Standard Track consideration.  Precisely
> how it will be forwarded (by me as Individual, by Bob as
> LDAPBIS WG co-chair, or by an PXIX co-chair) to the IESG
> is yet to be determined, but certainly will be coordinated
> with the chairs of both PKIX and LDAPBIS WGs.
> 
> It is my hope that this I-D will be published in conjunction
> with the revised LDAP TS being prepared by the LDAPBIS WG.
> 
> Kurt 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAILsPqa044290; Thu, 18 Nov 2004 13:54:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAILsPfM044289; Thu, 18 Nov 2004 13:54:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAILsPrF044232 for <[e-mail]>; Thu, 18 Nov 2004 13:54:25 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iAILrnZv036096; Thu, 18 Nov 2004 21:53:49 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041118133645.02dade68@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Thu, 18 Nov 2004 13:54:15 -0800
To: Steve Hanna <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Cc: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Just to clarify a few non-technical points.  (I intend
to offer my technical comments after I complete my
review of the I-Ds).

At 11:26 AM 11/18/2004, Steve Hanna wrote:
>The schema described in RFC 2587 and updated by
>draft-zeilenga-ldap-x509-00.txt [...]. I understand that the
>zeilenga I-D is actually a product of the ldapbis
>efforts and will probably advance with them.

draft-zeilenga-ldap-x509-00.txt is presently an individual
submission to the IETF.  Hence, it is not a product of
the LDAPBIS WG.

It is my hope that after appropriate review by the PKIX WG,
the LDAPBIS WG, and other parties, to submit this document
to the IESG for Standard Track consideration.  Precisely
how it will be forwarded (by me as Individual, by Bob as
LDAPBIS WG co-chair, or by an PXIX co-chair) to the IESG
is yet to be determined, but certainly will be coordinated
with the chairs of both PKIX and LDAPBIS WGs.

It is my hope that this I-D will be published in conjunction
with the revised LDAP TS being prepared by the LDAPBIS WG.

Kurt 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIKhm1l018392; Thu, 18 Nov 2004 12:43:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIKhm0E018391; Thu, 18 Nov 2004 12:43:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIKhlkl018384 for <[e-mail]>; Thu, 18 Nov 2004 12:43:48 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAIKgv2x026770; Thu, 18 Nov 2004 15:42:57 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAIKggYA025211; Thu, 18 Nov 2004 15:42:42 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 15:43:20 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: 3280bis: indirectCRL boolean in IDP (3/3)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Denis,<br>
<br>
This is the last time that I am going to comment on this, either here
or on the X.500 list.<br>
<br>
<ol>
  <li>
    <p>"CA" and "CRL issuer" define types of entities, not roles.&nbsp; An
entity that issues public key certificates <b>is</b> a CA.&nbsp; An entity
that issues CRLs <b>is</b> a CRL issuer.&nbsp; Thus, a CA may issue CRLs
and a CRL issuer may issue certificates.</p>
  </li>
  <li>
    <p>The issuer of an indirect CRL may also certificates.&nbsp; If it does
issue certificates, then it may issue a single CRL that covers its own
certificates in addition to the certificates of other CA.&nbsp; This is why
RFC 3280 states: "If [the certificateIssuer] extension is not present
on the first entry in an indirect CRL, the certificate issuer defaults
to the CRL issuer."&nbsp; If a CA issues a CRL that covers both its own
certificates and the certificates of other CAs, and the first entry in
the CRL corresponds to a certificate issued by the issuer of the CRL,
then the certificateIssuer extension does not need to be included in
that entry.</p>
  </li>
  <li>The indirectCRL flag in the issuingDistributionPoint extension is
set whenever the CRL covers certificates signed by an entity other than
the issuer of the CRL.&nbsp; That is, if the CRL covers any certificate that
has an <b>issuer</b> name different from the <b>issuer<i> </i></b>name
in the CRL, then the indirectCRL flag is set to TRUE, otherwise it is
not.<br>
  </li>
</ol>
<br>
Denis Pinkas wrote:<br>
<blockquote type="cite" cite="[e-mail]">
  <meta http-equiv="Content-Type" content="text/html;">
  <title></title>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
David,<br>
  <blockquote type="cite" cite="[e-mail]">&nbsp;Denis
Pinkas wrote:<br>
    <blockquote type="cite" cite="[e-mail]">
      <meta http-equiv="Content-Type" content="text/html;">
      <title></title>
      <meta http-equiv="Content-Type"
 content="text/html;charset=ISO-8859-1">
      <title></title>
James,<br>
      <br>
      <blockquote type="cite"
 cite="[e-mail]">
        <pre wrap="">The indirectCRL field should not be redefined.
CRL issuers do issue certificates if they are also CAs (as they often
are).  </pre>
      </blockquote>
When the term CRL Issuer is used, it means an entity issuing CRLs, not
certificates. <br>
If an entity issues public key certificates, then it is called a CA.</blockquote>
This is not true.&nbsp; Paragraph 3 of section 5 in RFC 3280 begins: "CRL
issuers issue CRLs.&nbsp; In general, the CRL issuer is the CA."<br>
  </blockquote>
which means: " In general, the CA is also the CRL issuer". <br>
  <blockquote type="cite" cite="[e-mail]">A CRL
issuer is an entity that issues CRLs.&nbsp; </blockquote>
Correct.<br>
  <blockquote type="cite" cite="[e-mail]">A CRL
issuer may or may
not be a CA (i.e., an entity that issues certificates).&nbsp; </blockquote>
Not exactly. An entity which issues CRLs may or may not also issue
certificates.<br>
  <blockquote type="cite" cite="[e-mail]">An entity
that
issues indirect CRLs may or may not be a CA.&nbsp; </blockquote>
I have a problem here. If you look at James proposal, he is proposing:<br>
  <span class="032531201-18112004">
  <div><font face="Arial"><font><font color="#008080" size="2"><span
 class="032531201-18112004"><font color="#ff0000">Indirect&nbsp;</font><font
 color="#008080">CRL Issuer: an optional system to which a CA delegates
the publication of certificate revocation lists;</font></span></font></font></font><br>
  </div>
  </span>If there is a delegation, this means that it does not issue
CRLs
for itself.<br>
  <blockquote type="cite" cite="[e-mail]">If it is
a
CA, then it
may issue a single CRL that covers its own certificates in addition to
the certificates of other CAs.&nbsp; </blockquote>
Same problem as above.<br>
  <br>
  <blockquote type="cite" cite="[e-mail]">
    <blockquote type="cite" cite="[e-mail]">The
question is the meaning of the indirectCRL boolean in IDP.<br>
      <br>
If we take a look at X.509, it is defined in the following way:<br>
      <br>
      <span lang="EN-GB" style="font-size: 10pt; font-family: Times;">"<big>If
      </big></span><big><big><big><big><big><b style=""><span
 lang="EN-GB" style="font-size: 9pt; font-family: Helvetica;">indirectCRL</span></b></big><span
 lang="EN-GB" style="font-size: 10pt; font-family: Times;"><big> is
true, then the CRL may contain revocation
notifications from authorities <br>
other than the issuer of the CRL.</big> "<br>
      <br>
      <big>Note the sentence, even incorrect at the end (and thus
duplicating
an incorrect sentence from X.509)<br>
&nbsp;is using the plural, i.e. "</big></span></big></big></big></big><big><big><big><big><span
 lang="EN-GB" style="font-size: 10pt; font-family: Times;"><big>from
authorities" </big></span></big></big></big></big>which means it is an
indirect CRL of type b).<br>
    </blockquote>
You are misreading this sentence.&nbsp; This does not mean that the
indirectCRL flag is only set to true if the CRL may contain revocation
notifications from more than one authority other than the issuer of the
CRL.&nbsp; As long as the scope of the CRL includes certificates issued by
an entity other than the issuer of the CRL then the indirectCRL flag
must be set to true.</blockquote>
We cannot understand each other since you are still using the words
"certificates issued by an entity other than the issuer of the CRL". <br>
If we address the prtoblem from the relying party point of view, maybe
we will be able to have a common level of understanding.<br>
  <blockquote type="cite" cite="[e-mail]">If some
people are misinterpreting the current text to mean that the
flag should only be set if the CRL covers more than one CA other than
the CRL issuer then we can work on rewording the text.&nbsp; But, we can not
change the meaning of the indirectCRL flag.<br>
  </blockquote>
The goal is not to change the meaning, whatever the meaning is, but to
clarify the meaning so that we may all understand the same thing. <br>
Then we will have to undertstand (and agree) what kind of processing a
RP can do with that flag. I can provide the beginning of the story:<br>
  <br>
"A RP got a CRL that is supposed to be about a given certificate for
which a path has been constructed.<br>
The RP can check if the two following conditions are true: <br>
  <br>
&nbsp;1) the name of the issuer of the CRL is the same as the name of the CA,<br>
&nbsp;2) the CRL is signed using the same key as the key of the CA.<br>
  <br>
If it is the case then this CRL is issued by the CA, acting as a CRL
Issuer."<br>
  <br>
Now what kind of test should be done with the indirectCRL boolean in
the IDP ?<br>
Can that boolean be set to TRUE in any case ? <br>
  <br>
Denis<br>
  <blockquote type="cite" cite="[e-mail]">Dave<br>
  </blockquote>
</blockquote>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIKGoGM009261; Thu, 18 Nov 2004 12:16:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIKGnX8009260; Thu, 18 Nov 2004 12:16:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIKGnml009251 for <[e-mail]>; Thu, 18 Nov 2004 12:16:49 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAIKGMmc017269; Thu, 18 Nov 2004 15:16:22 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAIKFsYA007498; Thu, 18 Nov 2004 15:15:54 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 15:16:32 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Proposal on use of CRL issuer in section 3 of RFC3280
References: <[e-mail]> <p0620070abdc298ed82e4@[128.89.89.75]>
In-Reply-To: <p0620070abdc298ed82e4@[128.89.89.75]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:

> David,
>
> A few comments on your proposed 3280bis, section 3 text:
>
> the term "publishes" in the definition of CRL issuer seems to 
> emphasize promulgation vs. signing or CRLs. 

RFC 3280 states:  "CRL issuer: an optional system to which a CA 
delegates the publication of certificate revocation lists;"

I was just trying to minimize the changes.  I could always change this 
to sign, generate, create, whatever.

> I suggest using the phrase "revocation status" vs. status here.

OK.

> Also, I'm not sure why we should include the phrase "or some other 
> mechanism" in the description of how a CA provides revocation status 
> info.  the more options we allow for this (and especially the vague 
> sort of phrase cited above), the greater the likelihood that a client 
> and CA have not chosen common means of acquiring/publishing this 
> critical info. if this was an indirect way to alluding to SCVP, let's 
> me more direct. 

This wasn't meant to allude to SCVP.  There are many mechanisms for 
distributing revocation status other than CRLs and OCSP.  I wouldn't 
want to encourage their use since that would lead to interoperability 
problems, but I didn't think PKIX profiles precluded the use of 
revocation status mechanisms that are not described in PKIX documents.

Section 5 of RFC 3280 states:  "Conforming CAs are not required to issue 
CRLs if other revocation or certificate status mechanisms are provided."

I can certainly remove the phrase "or some other mechanism".  I didn't 
want to leave the impression that revocation status providers MUST use 
either CRLs or OCSP, unless the working group really intends to impose 
such a restriction.

Dave




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIK4HER005155; Thu, 18 Nov 2004 12:04:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIK4HMm005154; Thu, 18 Nov 2004 12:04:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIK4Gf9005148 for <[e-mail]>; Thu, 18 Nov 2004 12:04:16 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAIK482x019996; Thu, 18 Nov 2004 15:04:08 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAIK3rYA000023; Thu, 18 Nov 2004 15:03:53 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 15:04:31 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Henson <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: RFC3280bis: policy processing.
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Stephen Henson wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">While
implementing policy processing for OpenSSL a couple of issues
  <br>
arose in RFC3280 6.1.3:
  <br>
  <br>
2. In order for the valid_policy_tree to be a "tree" some additional
  <br>
conditions were required. Specifically:
  <br>
  <br>
a. The same OID cannot occur multiple times in the same certificate
  <br>
policyIdentifier field of a Certificate Policies extension.</blockquote>
Yes.&nbsp; The certificatePolicies extension logically contains a set of
certificate policies, referenced by OID.&nbsp; So, the same OID should not
appear more than once.<br>
<blockquote type="cite"
 cite="[e-mail]">b. The same OID
cannot occur multiple times in the subjectDomainPolicy
  <br>
of the Policy Mappings extensions.
  <br>
</blockquote>
Actually, the same OID can occur multiple times in the
subjectDomainPolicy.&nbsp; See below:<br>
<br>
<tt>Certificate 1:<br>
</tt>
<blockquote>certificatePolicies:&nbsp; Red<br>
policyMappings: Red -&gt; Gold, Red -&gt; Silver<br>
</blockquote>
<tt>Certificate 2:<br>
</tt>
<blockquote>certificatePolicies:&nbsp; Gold, Silver<br>
policyMappings: Gold -&gt; Medium, Silver -&gt; Medium<br>
</blockquote>
<tt>Certificate 3:</tt><br>
<tt>
</tt>
<blockquote>certificatePolicies:&nbsp; Medium<br>
</blockquote>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Red&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+ node of depth i-2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FALSE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; {Gold, Silver} |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gold&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Silver&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+ nodes of&nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FALSE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>| depth i-1 |</tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
FALSE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; {</tt><tt>Medium</tt><tt>}&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; {</tt><tt>Medium</tt><tt>}&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
</tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
</tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt><br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>Medium</tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>Medium</tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+ nodes of&nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FALSE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>| depth i &nbsp; |</tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
FALSE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt><tt>|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; {Medium}&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; {</tt><tt>Medium</tt><tt>}&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; +-----------------+<br>
<br>
</tt>
<blockquote type="cite"
 cite="[e-mail]">3. The use of
the phrase "for each" in 6.1.4 b(1) implied to me that
  <br>
there could me more than one node in the policy tree of depth i where
  <br>
ID-P is the valid policy whereas there can be at most one. If condition
  <br>
#2a above is valid there can be at most one.
</blockquote>
<br>
Perhaps the problem is with 6.1.3 (d)(1)(i).&nbsp; Perhaps this step also
needs to state "for each node of depth i-1 where P-OID is in the
expected_policy_set...."&nbsp; Would that clear up the confusion?<br>
<br>
Dave<br>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIJRPus091405; Thu, 18 Nov 2004 11:27:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIJRPMH091404; Thu, 18 Nov 2004 11:27:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIJROkT091398 for <[e-mail]>; Thu, 18 Nov 2004 11:27:25 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAIJR9mc009147; Thu, 18 Nov 2004 14:27:09 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAIJQjYA005144; Thu, 18 Nov 2004 14:26:54 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 14:27:23 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wen-Cheng Wang <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: 3280bis issue:  issues related to self-issued certificates
References: <01ef01c4cc91$5b509b30$4f85900a@wcwang>
In-Reply-To: <01ef01c4cc91$5b509b30$4f85900a@wcwang>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wen-Cheng Wang wrote:

>The definition of the term "self-issued certificate" is too vague.
>
>The current text of RFC 3280 only mention
>
>"A certificate is self-issued if the DNs that appear in the subject
> and issuer fields are identical and are not empty....a CA may
> issue a certificate to itself to support key rollover or changes in
> certificate policies.  These self-issued certificates are not counted
> when evaluating path length or name constraints."
>
>However, there are many kinds of self-issued certificates. For
>example:
>
>(a) self-signed certificates (this is a special case of self-issued certificate)
>(b) self-issued certificates with keyCertSign key usage (might with cRLSign key usage as well)
>(c) self-issued certificates with cRLSign key usage only (a CA using separate key for CRL signing)
>(d) self-issued certificates with key usages other than keyCertSign and cRLSign
>
>Self-issued certificates of type (c) are also known as "self-issued
>intermediate certificates" according to the X.509 (2000) standard.
>Obviously, only self-issued certificates of type (c) are thought to
>be CA certificates. However, they are special CA certificates
>for special purpose (e.g., Key Rollover) so that they do not contribute
>to the path length for purposes of processing some constraint
>extension and name constrains extension in certification path validation.
>
>Self-issued certificates of type (a), (c) and (d) can not be
>intermediate certificates and thus the above special processing
>rule does not apply to them. This is not crystal clear in the current
>text of RFC 3280.
>

I think the rules are spelled out very clearly in section 6.

Self-signed certificates are only used as a source of trust anchor 
information.  Section 6.1.1 step (d) specifies the information that is 
to be extracted from the self-signed certificate (and also indicates 
that this information does not need to be provided in the form of a 
self-signed certificate).  X509 explicitly states that self-signed 
certificates may not appear as intermediate certificates, and this 
should probably be stated in 3280bis as well.

In sections 6.1.3, 6.1.4, and 6.1.5, self-issued certificates (whether 
intermediate or not) are treated in exactly the same manner as other 
certificates except where the text explicitly states that they should be 
treated differently.

For example, in section 6.1.4, steps (a) and (b) do not provide an 
exception for self-issued certificates, so any policyMappings extension 
would be processed the same as if it were in a non-self-issued 
certificate.  Similarly, step (i) indicates that a policyConstraints 
extension should be processed the same for self-issued and 
non-self-issued certificates.  However, step (h) indicates that the 
explicit_policy and policy_mapping counters would not be decremented 
when processing a self-issued certificate.

In general, if a constraint extension appears in a self-issued 
certificate (other than a self-signed certificate), it is processed in 
the same way as if it appeared in a non-self-issued certificate.  
However, intermediate self-issued certificates are usually (but not 
always) exempted from the constraints imposed by certificates that 
preceded it in the path.

>Obviously, self-issued certificates of type (a) and (b) should conatins
>a basicConstraints extension with cA = TRUE since they are
>CA certificates.
>
>It is not clear whether self-issued certificates of type (c) should
>also conatins a basicConstraints extension with cA = TRUE.
>
>Self-issued certificates of type (d) should be thought as EE
>certificates, therefore they should not contain  a basicConstraints
>extension with cA = TRUE. However, some PKIX WG members
>might not agree to this interpretation.
>
This confusion is very unfortunate.  X.509 is very clear: "The cA 
component indicates if the certified public key may be used to verify 
certificate signatures."

So the problem is with RFC 3280.  X.509 is quite clear that the cA bit 
is not set to true for self-issued certificates of types (c) and (d) 
because the certified public key may not be used to verify certificate 
signatures.

>When perform path validation, it is not clear what will be the effect
>if some certificate extensions such as policyMappings, policyConstraints,
>nameConstraints, and inhibitAnyPolicy appear in self-issued 
>intermediate certificates (i.e., self-issued certificate of type (b)).
>The current text only says that this type of self-issued certificates do not
>contribute to the path length for purposes of processing some constraint
>extension and name constrains extension in certification path validation,
>it is not clear that whether these extensions can appear in this type of
>self-issued certificate.
>
>There is a serious security problem related to revocation status
>checking for self-issued certificates of type (b) and (c).
>For type (b), it might be a CA key rollover situation, and if the CA stopped
>using its old key to issue CRL, then there is no way to check the revocation
>status of the new self-issued certificate unless there is another way (e.g.,
>OCSP or other out-of-band mechanism) to check its revocation status.
>If the new key is unfortunately compromised later, this will be a serious
>security problem.
>
>For type (c), since the CA is using separate key for CRL signing and
>its Certificate with cRLSign key usage is signed by itself not signed
>by another CA. Therefore, no one can provide the revocation status
>info for that self-issued certificates unless there is another way (e.g.,
>OCSP or other out-of-band mechanism) to check its revocation status.
>If its CRL signing key is unfortunately compromised, this will be a serious
>security problem.
>
I think it is important to address these issues, but believe that will 
need to be in a separate document, not in 3280bis.

>Finally, it is not clear that, when a RP choose to use X.500 string matching
>rules (or StringPrep-based String matching rules), whether certificates with
>identical non-empty issuer name and subjec name but with different string
>encoding (e.g., one in PrintableString while one in UTF8String) are also
>thought as self-issued certificates.
>
If the issuer and subject name in a certificate match (according to the 
rules specified in stringprep or whatever), the the certificate is a 
self-issued certificate.  The problem, of course, is that many relying 
parties, using more limited matching rules, will not recognize that the 
certificate is self-issued and will treat it as a non-self-issued 
certificate.

Dave



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIJQP8j091134; Thu, 18 Nov 2004 11:26:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIJQPmK091133; Thu, 18 Nov 2004 11:26:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.funk.com (mail2.funk.com [199.103.155.98] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIJQN9g091075 for <[e-mail]>; Thu, 18 Nov 2004 11:26:24 -0800 (PST) (envelope-from [e-mail])
Received: from trilmail.funk.com ([192.168.21.75]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VP6G4CY1; Thu, 18 Nov 2004 14:26:11 -0500
Received: from [127.0.0.1] (hannaxp [192.168.21.6]) by trilmail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TJKX98CG; Thu, 18 Nov 2004 14:25:23 -0500
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 14:26:02 -0500
From: Steve Hanna <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are my comments on draft-ietf-pkix-ldap-*schema.

These schemas are too complex and incompatible with
existing clients. The costs exceed the benefits.

The main supposed benefits of your solution are:

1) Easier to search for certs

    Since certificate fields are stored as attributes
    of LDAP entries, clients can easily search for
    certificates by certificate field values. However,
    there are already two good ways to do this: the
    CertificateAssertion (defined in X.509 and
    draft-zeilenga-ldap-x509-00.txt) and Component
    Matching (RFC 3687). You argue that these will
    take a while to be deployed, but so would your
    solution. We don't need a third option.

2) Easier to download just matching certs

    Some users (or CAs) have many certificates.
    Your solution stores each cert as a separate
    directory entry which makes it easy to download
    just the ones you want. But there is already a
    way to do this with the existing schema: the
    Matched Values Return Filter control (RFC 3876).
    Again you argue that these will take a while to
    be deployed, but so would your solution. Also,
    it's quite rare to have many certificates. Why
    optimize for this rare case?

The main costs of your solution are:

1) Many more directory entries (>2x)

    Your solution requires a separate directory entry
    for every certificate. If each user has an average
    of one cert, this will double the number of entries
    in the directory. That's bad enough, but your solution
    has no value unless each user has many certificates.
    In that case, the number of entries will more than
    double.

2) Client changes needed

    You complain that the Matched Values Return Filter
    control will require servers to be upgraded. But
    your solution will require all clients to be upgraded
    to look for certificates and CRLs in a new place.
    Upgrading all clients is much harder than upgrading
    a few servers.

The schema described in RFC 2587 and updated by
draft-zeilenga-ldap-x509-00.txt seems much more
reasonable than yours. I understand that the
zeilenga I-D is actually a product of the ldapbis
efforts and will probably advance with them.
Therefore, I suggest that document be advanced in
lieu of yours.

I have heard that your drafts are only intended to
report on some experiments you conducted. That's why
the documents are going Informational and not Standards
Track. If that's true, the documents should say so
clearly and they should go Experimental not Informational.

In conclusion, it's my view that these documents are
not useful. In fact, they may cause harm to people
who implement them without understanding that they
are purely experimental. I recommend that they not
be published at all by the IETF. If they are published,
they should only be published with Experimental status
with an Applicability Notice describing the problems
noted above and suggesting that the standard schemas
be used instead.

Thanks,

Steve

Tim Polk wrote:

> 
> 
> This message initiates working group Last Call for the "LDAP Schema for 
> X.509 Certificates"
> specification. The editors have confirmed that all working group issues 
> have been resolved.
> 
> The URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt
> 
> This specification has also been forwarded to the LDAP Directorate for a 
> parallel review.  Assuming successful Last Call and concurrence from the 
> LDAP Directorate, this document will be forwarded to the ADs for 
> consideration as an Informational track RFC.
> 
> Last Call will run for (at least) two weeks. That is, Last Call will not 
> close before November 29.
> 
> Thanks,
> 
> Tim Polk




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIIfTRD075969; Thu, 18 Nov 2004 10:41:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIIfTHL075968; Thu, 18 Nov 2004 10:41:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIIfSag075926 for <[e-mail]>; Thu, 18 Nov 2004 10:41:28 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAIIfPjf023415; Thu, 18 Nov 2004 13:41:26 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p0620070abdc298ed82e4@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 18 Nov 2004 13:40:27 -0500
To: "David A. Cooper" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Proposal on use of CRL issuer in section 3 of RFC3280
Cc: pkix <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

A few comments on your proposed 3280bis, section 3 text:

the term "publishes" in the definition of CRL issuer seems to 
emphasize promulgation vs. signing or CRLs.

I suggest using the phrase "revocation status" vs. status here.

Also, I'm not sure why we should include the phrase "or some other 
mechanism" in the description of how a CA provides revocation status 
info.  the more options we allow for this (and especially the vague 
sort of phrase cited above), the greater the likelihood that a client 
and CA have not chosen common means of acquiring/publishing this 
critical info. if this was an indirect way to alluding to SCVP, let's 
me more direct.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIHj7Db057574; Thu, 18 Nov 2004 09:45:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIHj6WX057573; Thu, 18 Nov 2004 09:45:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIHj6c0057517 for <[e-mail]>; Thu, 18 Nov 2004 09:45:06 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAIHiojr019850; Thu, 18 Nov 2004 12:44:57 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06200706bdc28dc5e556@[128.89.89.75]>
In-Reply-To:  <[e-mail].a u>
References:  <[e-mail].a u>
Date: Thu, 18 Nov 2004 12:36:03 -0500
To: "Manger, James H" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: 3280bis: indirectCRL boolean in IDP (3/3)
Cc: "pkix" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James,

I agree with you broader interpretation of the term "CRL Issuer." I 
think it was introduced in X.509 to accommodate both the traditional 
case of a CA issuing CRLs and a non-CA, issuing only CRLs.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIH9mDg045430; Thu, 18 Nov 2004 09:09:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIH9mFR045429; Thu, 18 Nov 2004 09:09:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIH9l5u045404 for <[e-mail]>; Thu, 18 Nov 2004 09:09:47 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAIH9imc017064; Thu, 18 Nov 2004 12:09:44 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAIH9aYA000044; Thu, 18 Nov 2004 12:09:37 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 12:10:14 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: DNS name constraints
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Manger, James H wrote:

>Shouldn't the DNS name constraint use the same rules as for host part of
>URIs and email addresses?
>For DNS names, RFC 3280 says "simply adding to the left hand side of the
>name satisfies the name constraint" [4.2.1.11, page 38].  This implies a
>constraint of "foo.bar.com" is satisfied by "myfoo.bar.com" -- which
>must be an error.
>
The language in 3280bis will be changed to make it clear that 
"myfoo.bar.com" does not fall within the subtree of "foo.bar.com" since 
"myfoo.bar.com" is not hierarchically subordinate to "foo.bar.com".  The 
actual rule is that "foo.bar.com" is satisfied by "foo.bar.com" and any 
domain name that can be constructed by adding additional subdomains to 
the left hand side of "foo.bar.com".

Note that the constraints for DNS names still differ from those for 
rfc822Name and URIs.  For URIs (and rfc822Name), one can either specify 
all URIs on a particular host or all URIs on hosts whose DNS names are 
subordinate to the specified DNS name. For DNS names, one can only 
specify a subtree that includes both the specified DNS name and DNS 
names that are hierarchically subordinate to the specified name.  I 
don't think that there is a compelling reason to provide additional 
options for specifying DNS name constraints.

Dave



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIH1QgW042880; Thu, 18 Nov 2004 09:01:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIH1QVe042879; Thu, 18 Nov 2004 09:01:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIH1QRR042870 for <[e-mail]>; Thu, 18 Nov 2004 09:01:26 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAIH1Hmc015727; Thu, 18 Nov 2004 12:01:17 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAIH18YA024099; Thu, 18 Nov 2004 12:01:08 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 12:01:46 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Stefan Santesson wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">I totally agree with David that the current defined name comparison rules are not logical and do not follow the subtree principle (i.e. to allow all descendent entries but not parallel entries. This is also the case for the concept that xyz.com should be limited to the host (i.e. that <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> is a violation of xyz.com. In my mind, <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> is a perfectly valid subtree of xyz.com. The standard is thus not logical in this aspect.
  </pre>
</blockquote>
While I agree that the rules for name constraints on rfc822Name is not
entirely proper, but I don't see a compelling reason to change them.<br>
<br>
RFC 3280 provides three ways to specify name constraints for rfc822Name:<br>
<ol>
  <li>
    <p>specify a particular mailbox: this one seems to be consistent
with the general rules for specifying name constraints.</p>
  </li>
  <li>
    <p>A constraint of the form "xyz.com":&nbsp; This is really indicating a
constraint of "xyz.com" with a minimum of 0 or 1 (it doesn't matter
since "xyz.com" is not itself a valid email address) and a maximum of 1.</p>
  </li>
  <li>
    <p>A constraint of the form ".xyz.com":&nbsp; This is really indicating
a constraint of "xyz.com" with a minimum of 2 (must add at least one
subdomain plus a local-part to the specified subtree) and no maximum.</p>
  </li>
</ol>
In order to get the "normal" meaning of "xyz.com" one would need to
include two subtree specifications:&nbsp; "xyz.com" and ".xyz.com".<br>
<br>
This seems to have been a way to introduce some flexibility in the
specification of name constraints for rfc822Name without introducing
the added complexity of the minimum and maximum fields.<br>
<br>
Since the rules for specifying constraints on rfc822Name have remain
unchanged since RFC 2459, I think it would be best not to change them.<br>
<br>
Dave<br>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIGAejE025440; Thu, 18 Nov 2004 08:10:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIGAeum025439; Thu, 18 Nov 2004 08:10:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIGAdi4025432 for <[e-mail]>; Thu, 18 Nov 2004 08:10:40 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAIGAI2x008929 for <[e-mail]>; Thu, 18 Nov 2004 11:10:18 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAIG9wYA016868 for <[e-mail]>; Thu, 18 Nov 2004 11:09:58 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 11:10:36 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Proposal on use of CRL issuer in section 3 of RFC3280
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
All,<br>
<br>
It is clear that the use of the term "CRL issuer" in section 3 of RFC
3280 has been causing a lot of confusion, since some people have
interpreted this section as providing a definition of "CRL issuer"
rather than just providing a description of the corresponding diagram.<br>
<br>
I believe that this section should be changed in 3280bis.&nbsp; Below is a
proposal (with changes in <font color="#3333ff">blue</font>) for a
revision to this section.<br>
<br>
Dave<br>
<br>
<tt>----------------------------------------------------------------------------<br>
</tt>
<blockquote><tt>3&nbsp; Overview of Approach</tt><br>
  <br>
  <tt>&nbsp;&nbsp; Following is a simplified view of the architectural model
assumed by</tt><br>
  <tt>&nbsp;&nbsp; the PKIX specifications.</tt><br>
  <br>
  <tt>&nbsp;&nbsp; The components in this model are:</tt><br>
  <br>
  <tt>&nbsp;&nbsp; end entity: user of PKI certificates and/or end user system
that is</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the subject of a certificate;</tt><br>
  <tt>&nbsp;&nbsp; CA:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certification authority;</tt><br>
  <tt>&nbsp;&nbsp; RA:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; registration authority, i.e., an optional system
to which</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a CA delegates certain management functions;</tt><br>
  <tt>&nbsp;&nbsp; <font color="#3333ff">CRL issuer: a system which</font></tt><font
 color="#3333ff"><tt> publishes certificate revocation lists;</tt></font><br>
  <tt>&nbsp;&nbsp; repository: a system or collection of distributed systems that
stores</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificates and CRLs and serves as a means of</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; distributing these certificates and CRLs to end
entities.</tt><br>
  <br>
  <tt><font color="#3333ff">&nbsp;&nbsp; CAs are responsible for indicating the
status of the certificates that<br>
&nbsp;&nbsp; they issue.&nbsp; Status information may be provided using the Online<br>
&nbsp;&nbsp; Certificate Status Protocol (OCSP) [RFC 2560], certificate revocation<br>
&nbsp;&nbsp; lists (CRLs), or some other mechanism.&nbsp; In general, when status
information<br>
&nbsp;&nbsp; is provided using CRLs, the CA is also the CRL issuer.&nbsp; However, a CA<br>
&nbsp;&nbsp; may delegate the responsibility for issuing CRLs to a different
entity.<br>
&nbsp;&nbsp; <br>
  </font></tt><tt>&nbsp;&nbsp; Note that an Attribute Authority (AA) might also
choose to delegate</tt><br>
  <tt>&nbsp;&nbsp; the publication of CRLs.</tt><br>
  <br>
  <tt>&nbsp;&nbsp; +---+</tt><br>
  <tt>&nbsp;&nbsp; | C |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------------+</tt><br>
  <tt>&nbsp;&nbsp; | e | &lt;--------------------&gt;| End entity |</tt><br>
  <tt>&nbsp;&nbsp; | r |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Operational&nbsp;&nbsp;&nbsp;&nbsp; +------------+</tt><br>
  <tt>&nbsp;&nbsp; | t |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transactions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^</tt><br>
  <tt>&nbsp;&nbsp; | i |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and management&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; Management</tt><br>
  <tt>&nbsp;&nbsp; | f |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transactions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; transactions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PKI</tt><br>
  <tt>&nbsp;&nbsp; | i |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; users</tt><br>
  <tt>&nbsp;&nbsp; | c |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v</tt><br>
  <tt>&nbsp;&nbsp; | a | =======================&nbsp; +--+------------+&nbsp;
==============</tt><br>
  <tt>&nbsp;&nbsp; | t |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^</tt><br>
  <tt>&nbsp;&nbsp; | e |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PKI</tt><br>
  <tt>&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
management</tt><br>
  <tt>&nbsp;&nbsp; | &amp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
entities</tt><br>
  <tt>&nbsp;&nbsp; |&nbsp;&nbsp; | &lt;---------------------|&nbsp; RA&nbsp; |&lt;----+&nbsp;&nbsp;&nbsp;&nbsp; |</tt><br>
  <tt>&nbsp;&nbsp; | C |&nbsp; Publish certificate&nbsp; +------+&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |</tt><br>
  <tt>&nbsp;&nbsp; | R |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |</tt><br>
  <tt>&nbsp;&nbsp; | L |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |</tt><br>
  <tt>&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v&nbsp;&nbsp;&nbsp;&nbsp; v</tt><br>
  <tt>&nbsp;&nbsp; | R |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------------+</tt><br>
  <tt>&nbsp;&nbsp; | e | &lt;------------------------------|&nbsp;&nbsp;&nbsp;&nbsp; CA&nbsp;&nbsp;&nbsp;&nbsp; |</tt><br>
  <tt>&nbsp;&nbsp; | p |&nbsp;&nbsp; Publish certificate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------------+</tt><br>
  <tt>&nbsp;&nbsp; | o |&nbsp;&nbsp; Publish CRL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^</tt><br>
  <tt>&nbsp;&nbsp; | s |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; Management</tt><br>
  <tt>&nbsp;&nbsp; | i |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------------+&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; transactions</tt><br>
  <tt>&nbsp;&nbsp; | t | &lt;--------------| CRL Issuer |&lt;----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt><br>
  <tt>&nbsp;&nbsp; | o |&nbsp;&nbsp; Publish CRL&nbsp; +------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; v</tt><br>
  <tt>&nbsp;&nbsp; | r |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------+</tt><br>
  <tt>&nbsp;&nbsp; | y |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; CA&nbsp; |</tt><br>
  <tt>&nbsp;&nbsp; +---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------+</tt><br>
  <br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 1 - PKI Entities</tt><br>
</blockquote>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIG1fMx022223; Thu, 18 Nov 2004 08:01:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIG1fFV022222; Thu, 18 Nov 2004 08:01:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.funk.com (mail2.funk.com [199.103.155.98] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIG1enY022124 for <[e-mail]>; Thu, 18 Nov 2004 08:01:40 -0800 (PST) (envelope-from [e-mail])
Received: from trilmail.funk.com ([192.168.21.75]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VP6G4B4T; Thu, 18 Nov 2004 11:01:16 -0500
Received: from [127.0.0.1] (hannaxp [192.168.21.6]) by trilmail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TJKX979N; Thu, 18 Nov 2004 11:00:28 -0500
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 11:01:08 -0500
From: Steve Hanna <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James points out several ways that a path validation
toolkit can interface with a relying party application
to allow certs to contain names that have not been
properly checked against name constraints while ensuring
that the relying party does not rely on those names.

One big problem with this is that it is prohibited
by X.509. If the toolkit does this, then it's not
conforming to X.509. We can't allow it in 3280bis
because then we wouldn't be a profile of X.509.
We could try to convince the X.509 folks, but I
don't think that's in scope for the 3280bis effort.

Instead, I suggest that we leave the language in 3280
as is (maybe clarifying it to explain this problem).
And toolkits should allow applications to specify
their own name constraint processing code, adding
support for new name forms.

Providing such extension capabilities will help a bit
with the problem described by Terry, but it certainly
won't solve it. If you include new name forms in a
critical name constraints extension in a CA cert, then
relying parties who don't understand those forms will
reject that cert. You'll need to upgrade those relying
parties before you can use name constraints with the
new name form. Unfortunately, I think it's the best
we can do unless someone is willing to try to get X.509
changed.

This does add support to the view that 3280bis should
REQUIRE support for name constraints on all the name
forms where name constraints semantics are described in
3280bis. Writing name constraints code isn't hard. Adding
it later is.

Thanks,

Steve

Manger, James H wrote:
> Actually, the path will be valid in most cases.  The unsupported name 
> will usually match the unsupported constraint -- it's just that the code 
> cannot confirm that (as it is unsupported).  The code thinks "validity 
> unknown" so, to be fail-safe, it (reluctantly) says "treat as invalid".
>  
> Path validation logic in a generic toolkit could, in fact, take into 
> account the names an application intends to use... just ask the app or 
> allowed the app to tell you.  Consider an app only interested in a 
> particular policy id, key usage and name form.  Only the policy id can 
> be specified as an input to the standardised path processing rules.  
> Microsoft Crypto API still allows the key usage to be passed to that 
> toolkit, however.  It is not that much of a stretch to imagine a toolkit 
> API accepting a list of name forms.
>  
> Alternatively (or additionally), 3280bis could RECOMMEND that path 
> processing toolkits provide a mechanism to allow users to plugin new 
> modules to handle name constraints on otherwise unsupported name forms.
>  
>  
>  
> ------------------------------------------------------------------------
> *From:* Stefan Santesson [mailto:[e-mail]]
> *Sent:* Wednesday, 17 November 2004 8:25 PM
> *To:* Manger, James H; [e-mail]
> *Subject:* RE: 3280bis: name constraints
> 
>     It is not the end entity certificate that is valid or invalid in
>     case of a breach of name constraints. It is the path that is invalid.
> 
>      
> 
>     A CA certificate that contains a name constraints extension makes a
>     statement that this CA certificate is ONLY valid in a path if
>     subsequent certificates fall within these name boundaries.
> 
>      
> 
>     You may choose to trust the EE certificates anyway, but you can’t
>     use that name constrained CA certificate as the means to do it.
> 
>     You have to either.
> 
>      
> 
>     1) Directly trust the EE cert, or;
> 
>     2) Find another path using another CA certificate.
> 
>      
> 
>     Since few applications have native support for path validation and
>     instead rely on toolkits to do the work, there is no means for the
>     path validation logic in the generic toolkit to do take into account
>     what name forms the application intends to make use of.
> 
>      
> 
>     *Stefan Santesson*
>     Microsoft Security Center of Excellence (SCOE)
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* [e-mail]
>     [mailto:[e-mail]] *On Behalf Of *Manger, James H
>     *Sent:* den 17 november 2004 03:00
>     *To:* [e-mail]
>     *Subject:* RE: 3280bis: name constraints
> 
>      
> 
>     I agree with Terry -- having to reject a cert due to the presence of
>     a name (& name-constraint) of a type that you are going to
>     completely ignore is unnecessarily restrictive.  There is no attack
>     that is prevented by this rejection.  It just hinders the uptake of
>     useful new features as they can break backward compatibility.
> 
>      
> 
>     Consider a directory that strongly authenticates users.  It is only
>     interested in the user's DN.  It never does anything with email
>     address, URI, DNS etc.  Yet if it doesn't implement the rules for
>     processing name constraints on those names (which I believe have
>     never been detailed in X.509, only RFC 3280) then it cannot accept
>     any cert chain that includes (in addition to a DN) an email address,
>     URI, DNS etc and an associated constraint.
> 
>     Similarly an email application that is only interested in email
>     addresses; a TLS proxy that is only interested in DNS names...
> 
>      
> 
>     The subjectAltName extension says any unrecognised or unsupported
>     names can be ignored (even if critical only one name from the
>     extension needs to be supported).  The nameConstraints extension
>     basically contradicts this by saying you can't actually ignore these
>     names as they affect whether the cert is acceptable or not.
> 
>      
> 
>     David Cooper's suggestion of issuing separate certs for each name
>     form that you want to constrain sounds ungainly.  Company
>     A certifying company B may well want to constrain directoryNames to
>     "c=AU, o=Company B" and URIs, DNS names and email addresses to
>     ".companyB.com.au".  Should it issue 1 cross-cert (with all
>     constraints), 4 cross-certs to the one company B CA, 4 cross-certs
>     to 4 separate CA hierarchies in company B...
> 
>      
> 
>     ...but the problem lies with X.509's text & limitations for name
>     constraints .. so perhaps 3280bis cannot fix it.
> 
>      
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIFLRUn007962; Thu, 18 Nov 2004 07:21:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIFLRAR007961; Thu, 18 Nov 2004 07:21:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIFLPYE007890 for <[e-mail]>; Thu, 18 Nov 2004 07:21:26 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAIFLHn13623; Thu, 18 Nov 2004 16:21:17 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 18 Nov 2004 16:21:17 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAIFLGc09921; Thu, 18 Nov 2004 16:21:16 +0100 (MET)
Date: Thu, 18 Nov 2004 16:21:16 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

CA1->CA2  with nameing constraints permitted XYW2 means:

  CA1 issued a certificate to CA2 and sets a permitted subtree allowing
  CA2 to issue certs starting with XYZ2 

CA1->CA2  with nameing constraints permitted XYW2 means:

  CA1 issues a certificate to CA3 and sets a permitted subtree allowing
  CA3 to issue certs starting with XYZ3 

CA2 and CA3 want to use CA1 as CRLissuer, i.e. that the rule
in the policy agreed with CA1. Thus they set crlUssuer = CA1 in
all certs they they create. 

But CA2 and CA3 cannot issue a certificate with a DN=CA1 with a CRLSign bit
since this would violate the naming constraints in that path!



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIE9Zob081477; Thu, 18 Nov 2004 06:09:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIE9ZWv081476; Thu, 18 Nov 2004 06:09:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIE9VMR081453 for <[e-mail]>; Thu, 18 Nov 2004 06:09:32 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA29746; Thu, 18 Nov 2004 15:21:33 +0100
Received: from bull.net ([129.181.81.53]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111815092019:2024 ; Thu, 18 Nov 2004 15:09:20 +0100 
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 15:09:20 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: 3280bis: indirectCRL boolean in IDP (3/3)
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/11/2004 15:09:21, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/11/2004 15:09:24, Serialize complete at 18/11/2004 15:09:24
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
David,<br>
<blockquote type="cite" cite="[e-mail]">&nbsp;Denis
Pinkas wrote:<br>
  <blockquote type="cite" cite="[e-mail]">
    <meta http-equiv="Content-Type" content="text/html;">
    <title></title>
    <meta http-equiv="Content-Type"
 content="text/html;charset=ISO-8859-1">
    <title></title>
James,<br>
    <br>
    <blockquote type="cite"
 cite="[e-mail]">
      <pre wrap="">The indirectCRL field should not be redefined.
CRL issuers do issue certificates if they are also CAs (as they often
are).  </pre>
    </blockquote>
When the term CRL Issuer is used, it means an entity issuing CRLs, not
certificates. <br>
If an entity issues public key certificates, then it is called a CA.</blockquote>
This is not true.&nbsp; Paragraph 3 of section 5 in RFC 3280 begins: "CRL
issuers issue CRLs.&nbsp; In general, the CRL issuer is the CA."<br>
</blockquote>
which means: " In general, the CA is also the CRL issuer". <br>
<blockquote type="cite" cite="[e-mail]">A CRL
issuer is an entity that issues CRLs.&nbsp; </blockquote>
Correct.<br>
<blockquote type="cite" cite="[e-mail]">A CRL
issuer may or may
not be a CA (i.e., an entity that issues certificates).&nbsp; </blockquote>
Not exactly. An entity which issues CRLs may or may not also issue
certificates.<br>
<blockquote type="cite" cite="[e-mail]">An entity
that
issues indirect CRLs may or may not be a CA.&nbsp; </blockquote>
I have a problem here. If you look at James proposal, he is proposing:<br>
<span class="032531201-18112004">
<div><font face="Arial"><font><font color="#008080" size="2"><span
 class="032531201-18112004"><font color="#ff0000">Indirect&nbsp;</font><font
 color="#008080">CRL Issuer: an optional system to which a CA delegates
the publication of certificate revocation lists;</font></span></font></font></font><br>
</div>
</span>If there is a delegation, this means that it does not issue CRLs
for itself.<br>
<blockquote type="cite" cite="[e-mail]">If it is a
CA, then it
may issue a single CRL that covers its own certificates in addition to
the certificates of other CAs.&nbsp; </blockquote>
Same problem as above.<br>
<br>
<blockquote type="cite" cite="[e-mail]">
  <blockquote type="cite" cite="[e-mail]">The
question is the meaning of the indirectCRL boolean in IDP.<br>
    <br>
If we take a look at X.509, it is defined in the following way:<br>
    <br>
    <span lang="EN-GB" style="font-size: 10pt; font-family: Times;">"<big>If
    </big></span><big><big><big><big><big><b style=""><span lang="EN-GB"
 style="font-size: 9pt; font-family: Helvetica;">indirectCRL</span></b></big><span
 lang="EN-GB" style="font-size: 10pt; font-family: Times;"><big> is
true, then the CRL may contain revocation
notifications from authorities <br>
other than the issuer of the CRL.</big> "<br>
    <br>
    <big>Note the sentence, even incorrect at the end (and thus
duplicating
an incorrect sentence from X.509)<br>
&nbsp;is using the plural, i.e. "</big></span></big></big></big></big><big><big><big><big><span
 lang="EN-GB" style="font-size: 10pt; font-family: Times;"><big>from
authorities" </big></span></big></big></big></big>which means it is an
indirect CRL of type b).<br>
  </blockquote>
You are misreading this sentence.&nbsp; This does not mean that the
indirectCRL flag is only set to true if the CRL may contain revocation
notifications from more than one authority other than the issuer of the
CRL.&nbsp; As long as the scope of the CRL includes certificates issued by
an entity other than the issuer of the CRL then the indirectCRL flag
must be set to true.</blockquote>
We cannot understand each other since you are still using the words
"certificates issued by an entity other than the issuer of the CRL". <br>
If we address the prtoblem from the relying party point of view, maybe
we will be able to have a common level of understanding.<br>
<blockquote type="cite" cite="[e-mail]">If some
people are misinterpreting the current text to mean that the
flag should only be set if the CRL covers more than one CA other than
the CRL issuer then we can work on rewording the text.&nbsp; But, we can not
change the meaning of the indirectCRL flag.<br>
</blockquote>
The goal is not to change the meaning, whatever the meaning is, but to
clarify the meaning so that we may all understand the same thing. <br>
Then we will have to undertstand (and agree) what kind of processing a
RP can do with that flag. I can provide the beginning of the story:<br>
<br>
"A RP got a CRL that is supposed to be about a given certificate for
which a path has been constructed.<br>
The RP can check if the two following conditions are true: <br>
<br>
&nbsp;1) the name of the issuer of the CRL is the same as the name of the CA,<br>
&nbsp;2) the CRL is signed using the same key as the key of the CA.<br>
<br>
If it is the case then this CRL is issued by the CA, acting as a CRL
Issuer."<br>
<br>
Now what kind of test should be done with the indirectCRL boolean in
the IDP ?<br>
Can that boolean be set to TRUE in any case ? <br>
<br>
Denis<br>
<blockquote type="cite" cite="[e-mail]">Dave<br>
</blockquote>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIE7SLg080833; Thu, 18 Nov 2004 06:07:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIE7SKM080832; Thu, 18 Nov 2004 06:07:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIE7KMq080746 for <[e-mail]>; Thu, 18 Nov 2004 06:07:22 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA43246; Thu, 18 Nov 2004 15:19:12 +0100
Received: from bull.net ([129.181.81.53]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111815064709:2022 ; Thu, 18 Nov 2004 15:06:47 +0100 
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 15:06:46 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: 3280bis: indirectCRL boolean in IDP (3/3)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/11/2004 15:06:50, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/11/2004 15:07:03, Serialize complete at 18/11/2004 15:07:03
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
James,<br>
<br>
The fix to the text that you are proposing is interresting. However ...<br>
<blockquote type="cite"
 cite="[e-mail]"><span
 class="032531201-18112004">
  <div dir="ltr" align="left"><font face="Arial"><font color="#0000ff"><font
 size="2"><span class="032531201-18112004">I think Denis is saying the
term "CRL issuer" is only used for authorities that issue CRLs but not
certificates.&nbsp; </span></font></font></font></div>
  </span></blockquote>
No. This is not exactly what I am saying. "CRL Issuer" is a role
endorsed by an authority in its capacity to issue CRLs.<br>
In the same way, a "Certificate Issuer" is a role endorsed by an
authority in its capacity to issue public key certificates.<br>
The same authority can have both roles, but only for the certificates
it issues.<br>
<blockquote type="cite"
 cite="[e-mail]"><span
 class="032531201-18112004">
  <div dir="ltr" align="left"><font face="Arial"><font color="#0000ff"><font
 size="2"><span class="032531201-18112004">A CA that issues CRLs cannot
be called a "CRL issuer". &nbsp;I find this usage unnatural, awkward,
inconsistent with X.509 and partially inconsistent with RFC 3280.&nbsp; </span>To
my mind,&nbsp;<span class="032531201-18112004">if an authority issues CRLs
it can be called a "CRL issuer" -- regardless of </span>whether or not&nbsp;<span
 class="032531201-18112004">it</span> also issue<span
 class="032531201-18112004">s</span> certificates.</font></font></font></div>
  </span></blockquote>
This last point is correct.<br>
<blockquote type="cite"
 cite="[e-mail]"><span
 class="032531201-18112004">
  <div dir="ltr" align="left"><font face="Arial" color="#0000ff"
 size="2"><span class="032531201-18112004">RFC 3280 section 3 "Overview
of Approach" supports Denis's interpretation:</span></font></div>
  <div dir="ltr" align="left"><font face="Arial" color="#0000ff"
 size="2"><span class="032531201-18112004">"<font color="#008080">CRL
issuer: an optional system to which a CA delegates the publication of
certificate revocation lists;</font>"</span></font><br>
  </div>
  </span></blockquote>
<blockquote type="cite"
 cite="[e-mail]"><span
 class="032531201-18112004">
  <div dir="ltr" align="left"><font face="Arial" color="#0000ff"
 size="2"><span class="032531201-18112004">
  <div dir="ltr" align="left"><font face="Arial" color="#0000ff"
 size="2"><span class="032531201-18112004">But section 5 "CRL and CRL
Extension Profile" certainly doesn't:</span></font></div>
  <div dir="ltr" align="left"><font face="Arial" color="#0000ff"
 size="2"><span class="032531201-18112004">"<font color="#008000">CRL
issuers issue CRLs.&nbsp; In general, the CRL issuer is the CA.</font>"</span></font></div>
  </span></font></div>
  </span></blockquote>
which means: " In general, the CA is also the CRL issuer" . <br>
<blockquote type="cite"
 cite="[e-mail]"><span
 class="032531201-18112004">
  <div dir="ltr" align="left"><font face="Arial" color="#0000ff"
 size="2"><span class="032531201-18112004">Lots of other text also
doesn't support Denis's interpretation:</span></font></div>
  <div dir="ltr" align="left"><font face="Arial" color="#0000ff"
 size="2"><span class="032531201-18112004">S</span></font><font
 face="Arial" color="#0000ff" size="2"><span class="032531201-18112004">ection
4.1.2.6: "</span></font><font face="Arial" color="#0000ff" size="2"><span
 class="032531201-18112004"><font color="#008080">If the subject is a
CRL issuer (e.g., the key usage extension, as discussed in 4.2.1.3, is
present and the value of cRLSign is TRUE)...</font>", which can be true
for a CA.</span></font></div>
  <div dir="ltr" align="left"><font face="Arial" color="#0000ff"
 size="2"><span class="032531201-18112004">Section 4.2.1.14:&nbsp;"<font
 color="#008080">If the certificate issuer is also the CRL issuer ...</font>"</span></font></div>
  </span></blockquote>
which means: "If the same authority is at the same time a certificate
issuer and a CRL issuer ..." <br>
<blockquote type="cite"
 cite="[e-mail]"><span
 class="032531201-18112004">
  <div dir="ltr" align="left"><font face="Arial"><font color="#0000ff"><font
 size="2"><span class="032531201-18112004">Also "</span><font
 color="#008080">If the certificate issuer is not the CRL issue</font><span
 class="032531201-18112004"><font color="#008080">r ...</font>"</span></font></font></font></div>
  </span></blockquote>
which means:: "If the certificate issuer is not issuing directly the
CRLs.<br>
<blockquote type="cite"
 cite="[e-mail]"><span
 class="032531201-18112004">
  <div dir="ltr" align="left"><font face="Arial"><font color="#0000ff"><font
 size="2"><span class="032531201-18112004">Also consider the <font
 color="#008080">nameRelativeToCRLIssuer</font> field, which can be
appended to the CA name.</span></font></font></font></div>
  <div dir="ltr" align="left"><font face="Arial" color="#0000ff"
 size="2"><span class="032531201-18112004">Section 5: "<font
 color="#008000">Whenever the CRL issuer is not the CA...</font>"</span></font></div>
  </span></blockquote>
which is correct.<br>
<blockquote type="cite"
 cite="[e-mail]"><span
 class="032531201-18112004">
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="032531201-18112004">Section 5.1.1.3: </span>"<font
 color="#008080">CAs that are also CRL issuers MAY use<span
 class="032531201-18112004">...</span></font>"</font></font></font></div>
  <div><font><font><font face="Arial" color="#0000ff" size="2"><span
 class="032531201-18112004">etc.</span></font></font></font></div>
  </span></blockquote>
which means: "Authorities which are both CAs and CRL issuers MAY use
..."<br>
<blockquote type="cite"
 cite="[e-mail]"><span
 class="032531201-18112004">
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="032531201-18112004"><strong>Proposal</strong>: In section 3
"Overview of Approach", rename the "CRL Issuer" component to "Indirect
CRL Issuer" (adding the word "Indirect" in three places).</span></font></font></font></div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="032531201-18112004">"<font color="#008080">...</font></span></font></font></font></div>
  <div><font face="Arial"><font><font color="#008080" size="2"><span
 class="032531201-18112004"><font color="#ff0000">Indirect&nbsp;</font><font
 color="#008080">CRL Issuer: an optional system to which a CA delegates
the publication of certificate revocation lists;</font></span></font></font></font></div>
  <div><font face="Arial"><font><font color="#008080" size="2"><span
 class="032531201-18112004">...</span></font></font></font></div>
  <div><font face="Arial"><font><font color="#008080" size="2"><span
 class="032531201-18112004">...might also chose to delegate the
publication of CRLs to an <font color="#ff0000">Indirect </font>CRL
issuer.</span></font></font></font></div>
  <div><font face="Arial"><font><font color="#008080" size="2"><span
 class="032531201-18112004">...</span></font></font></font></div>
  <div><font face="Arial"><font><font color="#008080" size="2"><span
 class="032531201-18112004">&nbsp;&nbsp; +----------------------------+</span></font></font></font></div>
  <div><font face="Arial"><font><font color="#008080" size="2"><span
 class="032531201-18112004">&nbsp;&nbsp; | <font color="#ff0000">Indirect </font>CRL
Issuer |</span></font></font></font></div>
  <div><font face="Arial"><font><font color="#008080" size="2"><span
 class="032531201-18112004">&nbsp;&nbsp; +----------------------------+</span></font></font></font></div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="032531201-18112004"><font color="#008080">...</font>"</span></font></font></font></div>
  <div>&nbsp;</div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="032531201-18112004">Other sentences in the body of the RFC
mentioning CRL issuer can remain unchanged.</span></font></font></font>
  <br>
  </div>
  </span></blockquote>
"Indirect CRL issuer" would be clear but in many other places we would
also need to use that naming.<br>
However we would then need to clarify whetehr the term "CRL issuer"
used without
any qualifier in front of it <br>
would mean:<br>
<br>
&nbsp;a) a CA which issues certificate revocation status information, only
for the certificates it issues, or<br>
&nbsp;b) either case a) above or an indirect CRL issuer ?<br>
<br>
I believe that your proposal is for a) otherwise we would have to
introduce a difference <br>
between an "indirect CRL issuer" and a "direct CRL issuer"<br>
<br>
Denis
&nbsp;
<blockquote type="cite"
 cite="[e-mail]"><span
 class="032531201-18112004">
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="032531201-18112004">RE:&nbsp;"may contain revocation notifications
from authorities other than the issuer of the CRL"</span></font></font></font></div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="032531201-18112004">Replacing "authorities" with "one or more
authorities" does not change the meaning of this English sentence at
all -- it covers "type a)" and "type b)" indirect CRLs.</span></font></font></font></div>
  <div>&nbsp;</div>
  <div><br>
  </div>
  <blockquote style="margin-right: 0px;">
    <div class="OutlookMessageHeader" lang="en-us" dir="ltr"
 align="left">
    <hr tabindex="-1"> <font face="Tahoma" size="2"><b>From:</b> Denis
Pinkas [<a class="moz-txt-link-freetext"
 href="mailto:[e-mail]">mailto:[e-mail]</a>] <br>
    <b>Sent:</b> Thursday, 18 November 2004 12:30 AM<br>
    <b>To:</b> Manger, James H<br>
    <b>Cc:</b> <a class="moz-txt-link-abbreviated"
 href="mailto:[e-mail]">[e-mail]</a>; pkix<br>
    <b>Subject:</b> Re: 3280bis: indirectCRL boolean in IDP (3/3)<br>
    </font><br>
    </div>
James,<br>
    <br>
    <blockquote
 cite="[e-mail]"
 type="cite">
      <pre wrap="">The indirectCRL field should not be redefined.
CRL issuers do issue certificates if they are also CAs (as they often
are).
  </pre>
    </blockquote>
When the term CRL Issuer is used, it means an entity issuing CRLs, not
certificates. <br>
If an entity issues public key certificates, then it is called a CA.<br>
    <br>
The question is the meaning of the indirectCRL boolean in IDP.<br>
    <br>
If we take a look at X.509, it is defined in the following way:<br>
    <br>
    <span lang="EN-GB" style="font-size: 10pt; font-family: Times;">"<big>If
    </big></span><big><big><big><big><big><b><span lang="EN-GB"
 style="font-size: 9pt; font-family: Helvetica;">indirectCRL</span></b></big><span
 lang="EN-GB" style="font-size: 10pt; font-family: Times;"><big> is
true, then the CRL may contain revocation notifications from
authorities <br>
other than the issuer of the CRL.</big> "<br>
    <br>
    <big>Note the sentence, even incorrect at the end (and thus
duplicating an incorrect sentence from X.509)<br>
&nbsp;is using the plural, i.e. "</big></span></big></big></big></big><big><big><big><big><span
 lang="EN-GB" style="font-size: 10pt; font-family: Times;"><big>from
authorities" </big></span></big></big></big></big>which means it is an
indirect CRL of type b).<br>
    <br>
Denis<br>
    <br>
    <blockquote
 cite="[e-mail]"
 type="cite">
      <pre wrap="">The indirectCRL field does not only indicate a "type b) indirect CRL" --
it must also be set to true for a "type a) indirect CRL".

Proposed action: don't accept Denis's proposed correction or proposed
note.

-----Original Message-----
From: <a
 class="moz-txt-link-abbreviated"
 href="mailto:[e-mail]">[e-mail]</a> [<a
 class="moz-txt-link-freetext"
 href="mailto:[e-mail]">mailto:[e-mail]</a>]
On Behalf Of Denis Pinkas
Sent: Sunday, 14 November 2004 1:00 AM
To: <a
 class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Cc: pkix
Subject: 3280bis: indirectCRL boolean in IDP (3/3)


3280bis: indirectCRL boolean in IDP (3/3)

This is a change and an addition proposal related to indirect CRLs.

&gt;From section 5.2.5 Issuing Distribution Point, "the CRL issuer MUST
assert the indirectCRL boolean, if the scope of the CRL includes
certificates issued by authorities other than the CRL issuer".

This sentence is incorrect since CRL issuers do not issue certificates.


Proposed correction: 

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of the
CRL includes certificate identifiers from multiple authorities"
 
This boolean indicates a type b) indirect CRL but is named indirectCRL
boolean which is confusing with type a) indirect CRLs.

A note should be mentioned to clarify the ambiguity of the naming.

Proposed note: 

"The name of the boolean "indirectCRL" designates an indirect CRL that
includes certificate identifiers from multiple authorities, and not an
indirect CRL that includes certificate identifiers from a single CA.
An alternative name for that boolean would be: multipleCAs."

Denis



  </pre>
    </blockquote>
    <br>
  </blockquote>
  </span></blockquote>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIE6fTR080585; Thu, 18 Nov 2004 06:06:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIE6fuE080584; Thu, 18 Nov 2004 06:06:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIE6ZPh080511 for <[e-mail]>; Thu, 18 Nov 2004 06:06:37 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA18254; Thu, 18 Nov 2004 15:18:27 +0100
Received: from bull.net ([129.181.81.53]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111815061470:2020 ; Thu, 18 Nov 2004 15:06:14 +0100 
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 15:06:13 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/11/2004 15:06:15, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/11/2004 15:06:17, Serialize complete at 18/11/2004 15:06:17
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
Peter,<br>
<blockquote type="cite"
 cite="[e-mail]">
  <blockquote type="cite">
    <pre wrap="">In the following, there is an attempt to define that single method.

The requirements for the CA would be:

"The CA that places a CRL DP extension in a certificate with a cRLIssuer
field present SHALL issue a CRL Issuer certificate for the DN contained
in that cRLIssuer field".
    </pre>
  </blockquote>
  <pre wrap=""><!----></pre>
</blockquote>
Your example illustrates once again the naming problem that we
currently have .<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">CA1 : C=WW, O=org1 which issues certs and CRLs for all CAs.
  </pre>
</blockquote>
A CA does not issue CRLs for other CAs. Only a CRL Issuer can do this.<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">CA1-&gt;CA2 : C=WW, O=org2 with this as permitted name space 
CA1-&gt;CA3 : C=WW, O=org3 with the permitted name space</pre>
</blockquote>
I do not understand what this notation means.<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">CA2/3 wants to put C=WW, O=org1 into a CRLIssuer, it can do so. 
  </pre>
</blockquote>
If I understand correctly, you mean CA2 or CA3 wants to nominate a CRL
Issuer that has the above
DN (i.e. C=WW, O=org1). <br>
CA2 or CA3 will issue a certifcate that has the CRLsign bit set in key
Usage to the entity which has (C=WW, O=org1) as subject name.<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">How can CA2/3 issue a cert to CA1? 
  </pre>
</blockquote>
There is no certificate "issued to CA1".&nbsp; There is a certificate issued
by CA2 or CA3 to a CRL issuer that has a given DN.<br>
<br>
Denis<br>
<br>
&nbsp;<br>
<pre wrap="">
</pre>
<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">  


  </pre>
</blockquote>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIDEux1064125; Thu, 18 Nov 2004 05:14:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAIDEuQ3064124; Thu, 18 Nov 2004 05:14:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAIDEtvL064100 for <[e-mail]>; Thu, 18 Nov 2004 05:14:56 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1CUm7c-000PVv-KF; Thu, 18 Nov 2004 13:14:48 +0000
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 13:15:38 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
CC: "David A. Cooper" <[e-mail]>
Subject: RFC3280bis: policy processing.
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

While implementing policy processing for OpenSSL a couple of issues
arose in RFC3280 6.1.3:

1. The OID-P typo which has already been mentioned.

2. In order for the valid_policy_tree to be a "tree" some additional
conditions were required. Specifically:

a. The same OID cannot occur multiple times in the same certificate
policyIdentifier field of a Certificate Policies extension.
b. The same OID cannot occur multiple times in the subjectDomainPolicy
of the Policy Mappings extensions.

[The same OID can occur in issuerDomainPolicy: indeed that's the only
way the top node of Fig 4 could be produced.]

3. The use of the phrase "for each" in 6.1.4 b(1) implied to me that
there could me more than one node in the policy tree of depth i where
ID-P is the valid policy whereas there can be at most one. If condition
#2a above is valid there can be at most one.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAICaj4O045305; Thu, 18 Nov 2004 04:36:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAICajB8045304; Thu, 18 Nov 2004 04:36:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAICaiE0045234 for <[e-mail]>; Thu, 18 Nov 2004 04:36:44 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAICafW7321958 for <[e-mail]>; Thu, 18 Nov 2004 07:36:41 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAICaff0287418 for <[e-mail]>; Thu, 18 Nov 2004 07:36:41 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAICaf1I003121 for <[e-mail]>; Thu, 18 Nov 2004 07:36:41 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAICafqU003111; Thu, 18 Nov 2004 07:36:41 -0500
In-Reply-To: <01ef01c4cc91$5b509b30$4f85900a@wcwang>
To: "Wen-Cheng Wang" <[e-mail]>
Cc: "David A. Cooper" <[e-mail]>, "pkix" <[e-mail]>
MIME-Version: 1.0
Subject: Re: 3280bis issue:  issues related to self-issued certificates
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 07:36:36 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF2 (6.53IBM1)|October 29, 2004) at 11/18/2004 07:36:40, Serialize complete at 11/18/2004 07:36:40
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Wen-Cheng:

        Do we also need to distinguish between self-signed certs used as 
CA roots (either v1 or those with keyCertSign set) and all other 
self-signed certs?
        Responses below.

                Tom Gindin





"Wen-Cheng Wang" <[e-mail]>
Sent by: [e-mail]
11/17/2004 05:36 AM
 
        To:     "David A. Cooper" <[e-mail]>, "pkix" 
<[e-mail]>
        cc: 
        Subject:        3280bis issue:  issues related to self-issued 
certificates



The definition of the term "self-issued certificate" is too vague.

The current text of RFC 3280 only mention

"A certificate is self-issued if the DNs that appear in the subject
 and issuer fields are identical and are not empty....a CA may
 issue a certificate to itself to support key rollover or changes in
 certificate policies.  These self-issued certificates are not counted
 when evaluating path length or name constraints."

However, there are many kinds of self-issued certificates. For
example:

(a) self-signed certificates (this is a special case of self-issued 
certificate)
(b) self-issued certificates with keyCertSign key usage (might with 
cRLSign key usage as well)
(c) self-issued certificates with cRLSign key usage only (a CA using 
separate key for CRL signing)
(d) self-issued certificates with key usages other than keyCertSign and 
cRLSign

Self-issued certificates of type (c) are also known as "self-issued
intermediate certificates" according to the X.509 (2000) standard.
Obviously, only self-issued certificates of type (c) are thought to
be CA certificates. However, they are special CA certificates
for special purpose (e.g., Key Rollover) so that they do not contribute
to the path length for purposes of processing some constraint
extension and name constrains extension in certification path validation.


[TG] You do mean type (b), don't you?

Self-issued certificates of type (a), (c) and (d) can not be
intermediate certificates and thus the above special processing
rule does not apply to them. This is not crystal clear in the current
text of RFC 3280.

Obviously, self-issued certificates of type (a) and (b) should conatins
a basicConstraints extension with cA = TRUE since they are
CA certificates.

It is not clear whether self-issued certificates of type (c) should
also conatins a basicConstraints extension with cA = TRUE.

[TG] RFC 3280 4.2.1.10 says MAY, and it classifies CMP certificates with 
them.

Self-issued certificates of type (d) should be thought as EE
certificates, therefore they should not contain  a basicConstraints
extension with cA = TRUE. However, some PKIX WG members
might not agree to this interpretation.

When perform path validation, it is not clear what will be the effect
if some certificate extensions such as polcyMappings, policyConstraints,
nameConstraints, and inhibitAnyPolicy appear in self-issued 
intermediate certificates (i.e., self-issued certificate of type (b)).
The current text only says that this type of self-issued certificates do 
not
contribute to the path length for purposes of processing some constraint
extension and name constrains extension in certification path validation,
it is not clear that whether these extensions can appear in this type of
self-issued certificate.

There is a serious security problem related to revocation status
checking for self-issued certificates of type (b) and (c).
For type (b), it might be a CA key rollover situation, and if the CA 
stopped
using its old key to issue CRL, then there is no way to check the 
revocation
status of the new self-issued certificate unless there is another way 
(e.g.,
OCSP or other out-of-band mechanism) to check its revocation status.
If the new key is unfortunately compromised later, this will be a serious
security problem.

For type (c), since the CA is using separate key for CRL signing and
its Certificate with cRLSign key usage is signed by itself not signed
by another CA. Therefore, no one can provide the revocation status
info for that self-issued certificates unless there is another way (e.g.,
OCSP or other out-of-band mechanism) to check its revocation status.
If its CRL signing key is unfortunately compromised, this will be a 
serious
security problem.

[TG] Issue a new CRL signing key and revoke the old one.  The revocation 
will take effect with the same timing effects as the revocation of an EE 
certificate - an attacker can always replay a CRL until its expiration 
time.

Finally, it is not clear that, when a RP choose to use X.500 string 
matching
rules (or StringPrep-based String matching rules), whether certificates 
with
identical non-empty issuer name and subjec name but with different string
encoding (e.g., one in PrintableString while one in UTF8String) are also
thought as self-issued certificates.

Wen-Cheng Wang





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI9EE1k004990; Thu, 18 Nov 2004 01:14:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI9EElk004989; Thu, 18 Nov 2004 01:14:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.daasi.de (rhea.directory.dfn.de [134.2.217.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI9EABk004823 for <[e-mail]>; Thu, 18 Nov 2004 01:14:11 -0800 (PST) (envelope-from [e-mail])
Received: by smtp.daasi.de (Postfix, from userid 1009) id 092AAC118; Thu, 18 Nov 2004 10:14:07 +0100 (CET)
Received: from daasi.de (marie.directory.dfn.de [134.2.217.72]) by smtp.daasi.de (Postfix) with ESMTP id 47BA2C116; Thu, 18 Nov 2004 10:14:02 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 18 Nov 2004 10:14:02 +0100
From: Peter Gietz <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040208)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andrew Sciberras <[e-mail]>
Cc: Tim Polk <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: Certificate Schema
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE, USER_AGENT version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Andrew,

Thanks for your comments:

Andrew Sciberras wrote:

>Hi,
>
>Do you have any concerns about the fact that the Serial Number
>attribute (section 5.1.2) does not contain an ordering matching rule?
>
>Is it intentional that the Serial Number attribute is not 'SINGLE-VALUE'?
>  
>
Yes that was intentional, since the attribute is used as multivalue in 
the CRL document. I quote David Chadwick:

"serial number became multivalued because CRLs contain lists of revoked 
serial numbers. So in order to use the same attribute in PKC and CRL 
entries, we made it multivalued. Which is not actually a problem for a 
PKC entry in reality, cos a PKC can never hold more than one value. If 
it was made single valued then we would need to define a new attribute 
to hold exactly the same information in a CRL."

>
>Section 5.2.3  Key usage Extension
>If you have a certificate with a keyUsage extension present with a
>value of zero (i.e. none of the bits are set) what do you do? Do you
>simply omit using the x509keyUsage atribute? If not, how does the BNF
>represent such a value?
>  
>
I will include Norbert's proposed text into the draft to get this one 
straight.

Cheers,

Peter

>Thanks,
>Andrew Sciberras
>
>
>
>On Mon, 15 Nov 2004 17:00:22 -0500, Tim Polk <[e-mail]> wrote:
>  
>
>>This message initiates working group Last Call for the "LDAP Schema for
>>X.509 Certificates"
>>specification. The editors have confirmed that all working group issues
>>have been resolved.
>>
>>The URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt
>>
>>This specification has also been forwarded to the LDAP Directorate for a
>>parallel review.  Assuming successful Last Call and concurrence from the
>>LDAP Directorate, this document will be forwarded to the ADs for
>>consideration as an Informational track RFC.
>>
>>Last Call will run for (at least) two weeks. That is, Last Call will not
>>close before November 29.
>>
>>Thanks,
>>
>>Tim Polk
>>
>>
>>    
>>
>
>  
>


-- 
_______________________________________________________________________
 
Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]  
D-72074 Tübingen                        email: [e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI7n5ie047670; Wed, 17 Nov 2004 23:49:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI7n5gm047669; Wed, 17 Nov 2004 23:49:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from siamail.sia.it (mail.sia.it [193.203.230.133] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI7n15q047451 for <[e-mail]>; Wed, 17 Nov 2004 23:49:04 -0800 (PST) (envelope-from [e-mail])
Received: from ntexch06.office.corp.sia.it ([10.2.101.30]) by siamail.sia.it (8.12.11/8.12.11) with ESMTP id iAI7mX8j005582; Thu, 18 Nov 2004 08:48:33 +0100 (MET)
Received: from NTEXCH00.office.corp.sia.it ([10.2.101.129]) by ntexch06.office.corp.sia.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Nov 2004 08:48:33 +0100
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
Content-class: urn:content-classes:message
Subject: R: serialNumber Attribute
Date: Thu, 18 Nov 2004 08:48:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: serialNumber Attribute
Importance: normal
Thread-Index: AcTMxy384CUA1tupSkO52+1A5xQ+gwAe0Ueg
From: "Santoni Adriano" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 18 Nov 2004 07:48:33.0149 (UTC) FILETIME=[00B39AD0:01C4CD43]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAI7n55q047663
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Afaik, the serialNumber attribute is being used in several european countries, in qualified certificates, to carry a personal identification code assigned by the local fiscal or healthcare authority. Soon, this approach will be adopted in Italy as well.

Adriano Santoni
Actalis S.p.A.


-----Messaggio originale-----
Da: [e-mail] [mailto:[e-mail]] Per conto di Stefan Santesson
Inviato: mercoledì 17 novembre 2004 17.59
A: Stephen Kent; [e-mail]
Cc: [e-mail]
Oggetto: RE: serialNumber Attribute



I would guess that the certificate is using the definitions outlined in RFC 3739 (Qualified Certificate Profile), which contains guidance on the use of serialNumber in DN when issuing ID certificates to people.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Stephen Kent
> Sent: den 17 november 2004 15:44
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: serialNumber Attribute
> 
> 
> At 2:02 PM +0100 11/17/04, [e-mail] wrote:
> >Hi,
> >
> >Not having found a reference specifies in the RFC, I call upon you to
> solve a
> >problem currently met by certain Frecnh CA.
> >
> >  Certificates were emitted with in the DN a serialNumber attribute 
> >containing a value different from the serialNumber contained in the 
> >certificate.
> >
> >  This is correct ?
> >
> >I don't find reference in RFC3280 for attribute serialNumber in 
> >certificate, it is subjected to the conditon of the paragraph 4.1.2.2 
> >"Serial number"
?
> >
> >Thanhs Yannick
> 
> The serialNumber attribute that may appear in a DN is in no way 
> related to the serial number value that appears in the cert.  Sorry 
> that the names cause confusion, but the text defining each of these 
> values in a cert is pretty clear.
> 
> Steve


*******************Internet Email Confidentiality Footer*******************


Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati.
Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 



Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of ACTALIS S.p.A. Besides, The contents of this message shall be understood as neither given nor endorsed by ACTALIS S.p.A.. 
ACTALIS S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI4crBh029351; Wed, 17 Nov 2004 20:38:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI4cr8Y029350; Wed, 17 Nov 2004 20:38:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI4cpQ9029249 for <[e-mail]>; Wed, 17 Nov 2004 20:38:52 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAI4cnm5136320 for <[e-mail]>; Wed, 17 Nov 2004 23:38:49 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAI4cnb3259722 for <[e-mail]>; Wed, 17 Nov 2004 23:38:49 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAI4cmVX022797 for <[e-mail]>; Wed, 17 Nov 2004 23:38:48 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAI4cmbx022794; Wed, 17 Nov 2004 23:38:48 -0500
In-Reply-To: <[e-mail]>
Subject: Re: 3280bis: name constraints
To: "David A. Cooper" <[e-mail]>
Cc: [e-mail], Stephen Henson <[e-mail]>
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <[e-mail]>
From: Tom Gindin <[e-mail]>
Date: Wed, 17 Nov 2004 23:36:49 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF2 (6.53IBM1)|October 29, 2004) at 11/17/2004 23:38:47
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      David:

      X.509 doesn't give any support to handling the comparison for
excluded subtrees differently than the one for permitted, even though the
natural intent of excluded subtrees for DN's is probably closer to "if all
the attribute/value pairs in the constraint exactly match ones in the
subject, exclude it" - somebody who puts in an excluded subtree for "C=US,
O=Enron" doesn't really want "C=US, ST=TX, O=Enron" to pass.
      On Terry's point from Monday, we might be best off declaring that any
name constraints extension containing a constraint for otherName,
ediPartyName, x400Address (where we give no guidance) or registeredID
SHOULD or at least MAY be non-critical.  Although Permanent Identifier name
constraints do make sense (it makes perfectly good sense to use the
assigner field as a constraint), to declare that an unrecognized name
constraint should make a non-critical SubjectAltName form unacceptable is
likely to deter the use of such forms.  The same applies to registeredID,
even though many implementors know the OID leading substring match.

            Tom Gindin




                                                                                           
                      "David A. Cooper"                                                    
                      <david.cooper@nis        To:       Stephen Henson                    
                      t.gov>                    <[e-mail]>        
                      Sent by:                 cc:       [e-mail]                 
                      owner-ietf-pkix@m        Subject:  Re: 3280bis: name constraints     
                      ail.imc.org                                                          
                                                                                           
                                                                                           
                      11/16/2004 09:51                                                     
                      AM                                                                   
                                                                                           




Stephen Henson wrote:
      David A. Cooper wrote:
            I was not aware of any confusion over the meaning of name
            constraints imposed on rfc822Name or directoryName.  Could you
            provide more information about what needs to be clarified?

      With rfc822Name it was mentioned that the comparision should be to
      compare the RHS against the constraint. The discussion was whether a
      constraint of, for example, [e-mail] would *only* match
      [e-mail] or whether [e-mail] was allowed as well.
      I can't recall if any consensus was reached over this: I'll see if I
      can find the reference.
Here is the current text for name constraints on rfc822Name:
      A name constraint for Internet mail addresses MAY specify a
      particular mailbox, all addresses at a particular host, or all
      mailboxes in a domain.  To indicate a particular mailbox, the
      constraint is the complete mail address.  For example, "[e-mail]"
      indicates the root mailbox on the host "xyz.com".  To indicate all
      Internet mail addresses on a particular host, the constraint is
      specified as the host name.  For example, the constraint "xyz.com" is
      satisfied by any mail address at the host "xyz.com".  To specify any
      address within a domain, the constraint is specified with a leading
      period (as with URIs).  For example, ".xyz.com" indicates all the
      Internet mail addresses in the domain "xyz.com", but not Internet
      mail addresses on the host "xyz.com".
As I read this, one can specify three types of constraints:
   1. a specific email address
   2. all email addresses on a particular host
   3. all email address on all hosts whose DNS names are hierarchically
      subordinate to the specified name
There is no option to specify a set of email addresses on a particular host
that fit a certain pattern.  So, "[e-mail]" would not match
"[e-mail]" since RFC 3280 states that "[e-mail]" is
specifying a particular mailbox, not a set of mailboxes.  In my opinion
this is the correct behavior.  Name constraints are designed to specify
constraints in terms of subtrees.  Logically, "[e-mail]" is not
hierarchically subordinate to "[e-mail]", the two are siblings.

      As far as directoryName is concerned I've not seen a description or a
      reference to the algorithm used for this type of constraint. Some
      private communications with some vendors suggested that this wasn't
      obvious and also produced the worrying comment that "everyone does
      this differently".
I have never heard this.  It seems to me that the rules are fairly simple.
A DN consists of a SEQUENCE of RDN.  A subtree specification for name
constraints on DNs consists of a SEQUENCE of RDN.  If the subtree
specification is a sequence of n RDNs, then a DN matches if and only if the
DN consists of a sequence of at least n RDNs and the first n RDNs in the DN
match the the RDNs in the subtree specification in order.  The rules for
comparing RDNs are the same as are used to compare issuer and subject names
when verifying name chaining.

So, are these vendors who are unclear on how to process name constraints on
directoryNames also unclear on how to compare issuer and subject names, or
is the confusion limited to name constraints?

Dave




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI4PwY5025565; Wed, 17 Nov 2004 20:25:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI4Pwrc025564; Wed, 17 Nov 2004 20:25:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw ([202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI4Pspn025515 for <[e-mail]>; Wed, 17 Nov 2004 20:25:54 -0800 (PST) (envelope-from [e-mail])
Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAI4PnwG002444; Thu, 18 Nov 2004 12:25:49 +0800
Received: (from root@localhost) by ms20.chttl.com.tw (8.12.10/8.12.10) id iAI4PnGG012072; Thu, 18 Nov 2004 12:25:49 +0800
Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAI4PlL1012002; Thu, 18 Nov 2004 12:25:48 +0800
Message-ID: <003901c4cd26$ad516320$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: CRL SCOPE in rfc3280
Date: Thu, 18 Nov 2004 12:25:46 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C4CD69.BAC7E860"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01C4CD69.BAC7E860
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Marc,

By "the scope of the CRL", it means the scope specified by
the onlyContainsUserCerts flag, the onlyContainsCACerts flag, the
onlySomeReasons flags, the indirectCRL flag, and the
onlyContainsAttributeCerts flag, if any, in the same IDP extension.

(Please note that the new X.509 Technical Corrigendum 3 had already
remove onlyContainsAttributeCerts flag from IDP extension.)

With legal combinations of these flags, you can specify different scope =
of the CRL.
For example, an IDP extension with onlyContainsUserCerts =3D TRUE and
onlySomeReasons contains keyCompromise and cACompromise flags means
that the CRL scope only covers  EE certificates revoked by the reasons =
of Key
Compromise or CA Compromise.

With distributionPoint field absent, it means the the CRL issuer must =
guarantee
that all revoked unexpired certificates within that scope must be listed =
in
that CRL.

With distributionPoint field present, it means that the CRL might be a =
"partitioned"
CRL of that scope.

If there is no any flags in the IDP extension, it means the scope covers =
all revoked
unexpired certificates (include CA certificatee and EE certificates =
revoked by any
reason). However, it might be "partitioned" (depend on whether =
distributionPoint field
present)

If there is no IDP extension, it means the scope covers all revoked
unexpired certificates and it is not a "partitioned" CRL. That means
it is a full CRL.

Therefore, the part 'within the scope of the CRL' in that statement =
should not
be removed.

Wen-Cheng Wang
  ----- Original Message -----=20
  From: [e-mail]=20
  To: [e-mail]=20
  Sent: Thursday, November 18, 2004 6:21 AM
  Subject: CRL SCOPE in rfc3280


  Hi,

  In rfc 3280 say about distribution point:=20

  If the distributionPoint field is absent, the CRL MUST contain entries =
for all revoked unexpired certificates issued by the CRL issuer, if any, =
within the scope of the CRL.

  Can someone explain to me what mean the last part of the sentence =
exactly in this context? The part 'within the scope of the CRL'. I would =
have wrote :

  If the distributionPoint field is absent, the CRL MUST contain entries =
for all revoked unexpired certificates issued by the CRL issuer, if any.

  Thanks...

  Marc



------=_NextPart_000_0036_01C4CD69.BAC7E860
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Marc,</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>By "the scope of the CRL", it means the scope specified by</DIV>
<DIV>the onlyContainsUserCerts flag, the onlyContainsCACerts=20
flag,&nbsp;the</DIV>
<DIV>onlySomeReasons flags, the indirectCRL flag, and the</DIV>
<DIV>onlyContainsAttributeCerts flag, if any, in the same IDP =
extension.</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>
<DIV>(Please note that the new X.509 Technical Corrigendum 3 had =
already</DIV>
<DIV>remove onlyContainsAttributeCerts flag from IDP =
extension.)</DIV></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>With&nbsp;legal combinations of these flags, you can specify =
different=20
scope of the CRL.</DIV>
<DIV>For example, an IDP extension with onlyContainsUserCerts =3D TRUE =
and</DIV>
<DIV>onlySomeReasons contains keyCompromise and cACompromise flags =
means</DIV>
<DIV>that the CRL scope only covers&nbsp; EE certificates revoked by the =
reasons=20
of Key</DIV>
<DIV>Compromise&nbsp;or CA Compromise.</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>With distributionPoint field absent, it means the the CRL issuer =
must=20
guarantee</DIV>
<DIV>that all revoked unexpired certificates within that scope must be =
listed=20
in</DIV>
<DIV>that CRL.</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>With distributionPoint field present, it means that the =
CRL&nbsp;might=20
be&nbsp;a "partitioned"</DIV>
<DIV>CRL of that scope.</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>If there is no any flags in the IDP extension, it means the scope =
covers=20
all revoked</DIV>
<DIV>unexpired certificates (include CA certificatee and&nbsp;EE=20
certificates&nbsp;revoked by any</DIV>
<DIV>reason). However, it might be "partitioned" (depend on&nbsp;whether =

distributionPoint field</DIV>
<DIV>present)</DIV>
<DIV>
<DIV>&nbsp;</DIV>
<DIV>If there is no&nbsp;IDP extension, it means the scope covers all=20
revoked</DIV>
<DIV>unexpired certificates and it is not a "partitioned" CRL. That =
means</DIV>
<DIV>it is a full CRL.</DIV>
<DIV>
<DIV>&nbsp;</DIV>
<DIV>Therefore, the part 'within the scope of the CRL' in that statement =
should=20
not</DIV>
<DIV>be removed.</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>Wen-Cheng Wang</DIV><FONT =
face=3D=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94 size=3D2></FONT></DIV></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt =E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94; font-color: black"><B>From:</B>=20
  <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><B>Sent:</B> Thursday, November =
18, 2004 6:21=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><B>Subject:</B> CRL SCOPE in =
rfc3280</DIV>
  <DIV><BR></DIV>Hi,<BR><BR>In rfc 3280 say about distribution point: =
<BR><BR>If=20
  the distributionPoint field is absent, the CRL MUST contain entries =
for all=20
  revoked unexpired certificates issued by the CRL issuer, if any, =
within the=20
  scope of the CRL.<BR><BR>Can someone explain to me what mean the last =
part of=20
  the sentence exactly in this context? The part 'within the scope of =
the CRL'.=20
  I would have wrote :<BR><BR>If the distributionPoint field is absent, =
the CRL=20
  MUST contain entries for all revoked unexpired certificates issued by =
the CRL=20
  issuer, if=20
any.<BR><BR>Thanks...<BR><BR>Marc<BR><BR><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0036_01C4CD69.BAC7E860--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI38u6f099566; Wed, 17 Nov 2004 19:08:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI38utE099565; Wed, 17 Nov 2004 19:08:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.vtcif.telstra.com.au (mailbo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI38tSu099550 for <[e-mail]>; Wed, 17 Nov 2004 19:08:56 -0800 (PST) (envelope-from [e-mail])
Received: from mailai.vtcif.telstra.com.au (mailai.vtcif.telstra.com.au [202.12.142.17]) by mailbo.vtcif.telstra.com.au (Postfix) with ESMTP id A886523FE8 for <[e-mail]>; Thu, 18 Nov 2004 14:08:51 +1100 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id 2AF2A1DA84 for <[e-mail]>; Thu, 18 Nov 2004 14:08:51 +1100 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA15187 for <[e-mail]>; Thu, 18 Nov 2004 14:08:50 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CD1B.BB9742C0"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Subject: RE: 3280bis: indirectCRL boolean in IDP (3/3)
Date: Thu, 18 Nov 2004 14:07:26 +1100
Message-ID: <[e-mail]>
Thread-Topic: 3280bis: indirectCRL boolean in IDP (3/3)
Thread-Index: AcTMqZMxhwsQqYcYSfyQ4j3XW8UjSAAYidLQ
From: "Manger, James H" <[e-mail]>
To: "pkix" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4CD1B.BB9742C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think Denis is saying the term "CRL issuer" is only used for
authorities that issue CRLs but not certificates.  A CA that issues CRLs
cannot be called a "CRL issuer".  I find this usage unnatural, awkward,
inconsistent with X.509 and partially inconsistent with RFC 3280.  To my
mind, if an authority issues CRLs it can be called a "CRL issuer" --
regardless of whether or not it also issues certificates.
=20
RFC 3280 section 3 "Overview of Approach" supports Denis's
interpretation:
"CRL issuer: an optional system to which a CA delegates the publication
of certificate revocation lists;"

But section 5 "CRL and CRL Extension Profile" certainly doesn't:
"CRL issuers issue CRLs.  In general, the CRL issuer is the CA."
Lots of other text also doesn't support Denis's interpretation:
Section 4.1.2.6: "If the subject is a CRL issuer (e.g., the key usage
extension, as discussed in 4.2.1.3, is present and the value of cRLSign
is TRUE)...", which can be true for a CA.
Section 4.2.1.14: "If the certificate issuer is also the CRL issuer ..."
Also "If the certificate issuer is not the CRL issuer ..."
Also consider the nameRelativeToCRLIssuer field, which can be appended
to the CA name.
Section 5: "Whenever the CRL issuer is not the CA..."
Section 5.1.1.3: "CAs that are also CRL issuers MAY use..."
etc.
=20
Proposal: In section 3 "Overview of Approach", rename the "CRL Issuer"
component to "Indirect CRL Issuer" (adding the word "Indirect" in three
places).
"...
Indirect CRL Issuer: an optional system to which a CA delegates the
publication of certificate revocation lists;
...
...might also chose to delegate the publication of CRLs to an Indirect
CRL issuer.
...
   +----------------------------+
   | Indirect CRL Issuer |
   +----------------------------+
..."
=20
Other sentences in the body of the RFC mentioning CRL issuer can remain
unchanged.
=20
=20
=20
RE: "may contain revocation notifications from authorities other than
the issuer of the CRL"
Replacing "authorities" with "one or more authorities" does not change
the meaning of this English sentence at all -- it covers "type a)" and
"type b)" indirect CRLs.
=20



  _____ =20

From: Denis Pinkas [mailto:[e-mail]]=20
Sent: Thursday, 18 November 2004 12:30 AM
To: Manger, James H
Cc: [e-mail]; pkix
Subject: Re: 3280bis: indirectCRL boolean in IDP (3/3)


James,



The indirectCRL field should not be redefined.

CRL issuers do issue certificates if they are also CAs (as they often

are).

 =20

When the term CRL Issuer is used, it means an entity issuing CRLs, not
certificates.=20
If an entity issues public key certificates, then it is called a CA.

The question is the meaning of the indirectCRL boolean in IDP.

If we take a look at X.509, it is defined in the following way:

"If indirectCRL is true, then the CRL may contain revocation
notifications from authorities=20
other than the issuer of the CRL. "

Note the sentence, even incorrect at the end (and thus duplicating an
incorrect sentence from X.509)
 is using the plural, i.e. "from authorities" which means it is an
indirect CRL of type b).

Denis



The indirectCRL field does not only indicate a "type b) indirect CRL" --

it must also be set to true for a "type a) indirect CRL".



Proposed action: don't accept Denis's proposed correction or proposed

note.



-----Original Message-----

From: [e-mail] [mailto:[e-mail]]

On Behalf Of Denis Pinkas

Sent: Sunday, 14 November 2004 1:00 AM

To: [e-mail]

Cc: pkix

Subject: 3280bis: indirectCRL boolean in IDP (3/3)





3280bis: indirectCRL boolean in IDP (3/3)



This is a change and an addition proposal related to indirect CRLs.



>From section 5.2.5 Issuing Distribution Point, "the CRL issuer MUST

assert the indirectCRL boolean, if the scope of the CRL includes

certificates issued by authorities other than the CRL issuer".



This sentence is incorrect since CRL issuers do not issue certificates.





Proposed correction:=20



"The CRL issuer MUST assert the indirectCRL boolean, if the scope of the

CRL includes certificate identifiers from multiple authorities"

=20

This boolean indicates a type b) indirect CRL but is named indirectCRL

boolean which is confusing with type a) indirect CRLs.



A note should be mentioned to clarify the ambiguity of the naming.



Proposed note:=20



"The name of the boolean "indirectCRL" designates an indirect CRL that

includes certificate identifiers from multiple authorities, and not an

indirect CRL that includes certificate identifiers from a single CA.

An alternative name for that boolean would be: multipleCAs."



Denis







 =20



------_=_NextPart_001_01C4CD1B.BB9742C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE></TITLE>

<META content=3D"MSHTML 6.00.2800.1459" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff><SPAN class=3D032531201-18112004>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004>I think Denis is saying the term "CRL issuer" =
is only=20
used for authorities that issue CRLs but not certificates.&nbsp; A CA =
that=20
issues CRLs cannot be called a "CRL issuer". &nbsp;I find this usage =
unnatural,=20
awkward, inconsistent with X.509 and partially inconsistent with RFC =
3280.&nbsp;=20
</SPAN>To my mind,&nbsp;<SPAN class=3D032531201-18112004>if an authority =
issues=20
CRLs it can be called a "CRL issuer" -- regardless of </SPAN>whether or=20
not&nbsp;<SPAN class=3D032531201-18112004>it</SPAN> also issue<SPAN=20
class=3D032531201-18112004>s</SPAN> =
certificates.</FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D032531201-18112004>RFC 3280 section 3 "Overview of Approach" =
supports=20
Denis's interpretation:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D032531201-18112004>"<FONT color=3D#008080>CRL issuer: an =
optional system to=20
which a CA delegates the publication of certificate revocation=20
lists;</FONT>"<BR>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D032531201-18112004>But section 5 "CRL and CRL Extension Profile" =
certainly=20
doesn't:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D032531201-18112004>"<FONT color=3D#008000>CRL issuers issue =
CRLs.&nbsp; In=20
general, the CRL issuer is the=20
CA.</FONT>"</SPAN></FONT></DIV></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D032531201-18112004>Lots of other text also doesn't support =
Denis's=20
interpretation:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D032531201-18112004>S</SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><SPAN class=3D032531201-18112004>ection 4.1.2.6: =
"</SPAN></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D032531201-18112004><FONT=20
color=3D#008080>If the subject is a CRL issuer (e.g., the key usage =
extension, as=20
discussed in 4.2.1.3, is present and the value of cRLSign is =
TRUE)...</FONT>",=20
which can be true for a CA.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D032531201-18112004>Section 4.2.1.14:&nbsp;"<FONT =
color=3D#008080>If the=20
certificate issuer is also the CRL issuer =
...</FONT>"</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004>Also "</SPAN><FONT color=3D#008080>If the =
certificate=20
issuer is not the CRL issue</FONT><SPAN class=3D032531201-18112004><FONT =

color=3D#008080>r ...</FONT>"</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004>Also consider the <FONT=20
color=3D#008080>nameRelativeToCRLIssuer</FONT> field, which can be =
appended to the=20
CA name.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D032531201-18112004>Section 5: "<FONT color=3D#008000>Whenever =
the CRL issuer=20
is not the CA...</FONT>"</SPAN></FONT></DIV>
<DIV></SPAN><SPAN class=3D032531201-18112004></SPAN><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2><SPAN class=3D032531201-18112004>Section =
5.1.1.3:=20
</SPAN>"<FONT color=3D#008080>CAs that are also CRL issuers MAY use<SPAN =

class=3D032531201-18112004>...</SPAN></FONT>"</FONT></FONT></FONT></DIV>
<DIV><FONT><FONT><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D032531201-18112004>etc.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004><STRONG>Proposal</STRONG>: In section 3 =
"Overview of=20
Approach", rename the "CRL Issuer" component to "Indirect CRL Issuer" =
(adding=20
the word "Indirect" in three places).</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004>"<FONT=20
color=3D#008080>...</FONT></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT><FONT color=3D#008080 size=3D2><SPAN=20
class=3D032531201-18112004><FONT =
color=3D#ff0000>Indirect&nbsp;</FONT><FONT=20
color=3D#008080>CRL Issuer: an optional system to which a CA delegates =
the=20
publication of certificate revocation=20
lists;</FONT></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT><FONT color=3D#008080 size=3D2><SPAN=20
class=3D032531201-18112004>...</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT><FONT color=3D#008080 size=3D2><SPAN=20
class=3D032531201-18112004>...might also chose to delegate the =
publication of CRLs=20
to an <FONT color=3D#ff0000>Indirect </FONT>CRL=20
issuer.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT><FONT color=3D#008080 size=3D2><SPAN=20
class=3D032531201-18112004>...</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT><FONT color=3D#008080 size=3D2><SPAN=20
class=3D032531201-18112004>&nbsp;&nbsp;=20
+----------------------------+</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT><FONT color=3D#008080 size=3D2><SPAN=20
class=3D032531201-18112004>&nbsp;&nbsp; | <FONT color=3D#ff0000>Indirect =
</FONT>CRL=20
Issuer |</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT><FONT color=3D#008080 size=3D2><SPAN=20
class=3D032531201-18112004>&nbsp;&nbsp;=20
+----------------------------+</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004><FONT=20
color=3D#008080>...</FONT>"</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004>Other sentences in the body of the RFC =
mentioning CRL=20
issuer can remain unchanged.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004>RE:&nbsp;"may contain revocation =
notifications from=20
authorities other than the issuer of the =
CRL"</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004>Replacing "authorities" with "one or more =
authorities"=20
does not change the meaning of this English sentence at all -- it covers =
"type=20
a)" and "type b)" indirect CRLs.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D032531201-18112004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><BR></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Denis Pinkas=20
  [mailto:[e-mail]] <BR><B>Sent:</B> Thursday, 18 November =
2004=20
  12:30 AM<BR><B>To:</B> Manger, James H<BR><B>Cc:</B> =
[e-mail];=20
  pkix<BR><B>Subject:</B> Re: 3280bis: indirectCRL boolean in IDP=20
  (3/3)<BR></FONT><BR></DIV>
  <DIV></DIV>James,<BR><BR>
  <BLOCKQUOTE=20
  =
cite=[e-mail]=
stra.com.au=20
  type=3D"cite"><PRE wrap=3D"">The indirectCRL field should not be =
redefined.
CRL issuers do issue certificates if they are also CAs (as they often
are).
  </PRE></BLOCKQUOTE>When the term CRL Issuer is used, it means an =
entity=20
  issuing CRLs, not certificates. <BR>If an entity issues public key=20
  certificates, then it is called a CA.<BR><BR>The question is the =
meaning of=20
  the indirectCRL boolean in IDP.<BR><BR>If we take a look at X.509, it =
is=20
  defined in the following way:<BR><BR><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Times">"<BIG>If=20
  </BIG></SPAN><BIG><BIG><BIG><BIG><BIG><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica">indirectCRL</SPAN></B></BIG><SPAN=20
  lang=3DEN-GB style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Times"><BIG> is =
true, then the=20
  CRL may contain revocation notifications from authorities <BR>other =
than the=20
  issuer of the CRL.</BIG> "<BR><BR><BIG>Note the sentence, even =
incorrect at=20
  the end (and thus duplicating an incorrect sentence from =
X.509)<BR>&nbsp;is=20
  using the plural, i.e.=20
  "</BIG></SPAN></BIG></BIG></BIG></BIG><BIG><BIG><BIG><BIG><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Times"><BIG>from authorities"=20
  </BIG></SPAN></BIG></BIG></BIG></BIG>which means it is an indirect CRL =
of type=20
  b).<BR><BR>Denis<BR><BR>
  <BLOCKQUOTE=20
  =
cite=[e-mail]=
stra.com.au=20
  type=3D"cite"><PRE wrap=3D"">The indirectCRL field does not only =
indicate a "type b) indirect CRL" --
it must also be set to true for a "type a) indirect CRL".

Proposed action: don't accept Denis's proposed correction or proposed
note.

-----Original Message-----
From: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[e-mail]">[e-mail]=
</A> [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]
On Behalf Of Denis Pinkas
Sent: Sunday, 14 November 2004 1:00 AM
To: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[e-mail]">[e-mail]</A>
Cc: pkix
Subject: 3280bis: indirectCRL boolean in IDP (3/3)


3280bis: indirectCRL boolean in IDP (3/3)

This is a change and an addition proposal related to indirect CRLs.

&gt;From section 5.2.5 Issuing Distribution Point, "the CRL issuer MUST
assert the indirectCRL boolean, if the scope of the CRL includes
certificates issued by authorities other than the CRL issuer".

This sentence is incorrect since CRL issuers do not issue certificates.


Proposed correction:=20

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of the
CRL includes certificate identifiers from multiple authorities"
=20
This boolean indicates a type b) indirect CRL but is named indirectCRL
boolean which is confusing with type a) indirect CRLs.

A note should be mentioned to clarify the ambiguity of the naming.

Proposed note:=20

"The name of the boolean "indirectCRL" designates an indirect CRL that
includes certificate identifiers from multiple authorities, and not an
indirect CRL that includes certificate identifiers from a single CA.
An alternative name for that boolean would be: multipleCAs."

Denis



  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4CD1B.BB9742C0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI0ABFm034284; Wed, 17 Nov 2004 16:10:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAI0ABC3034283; Wed, 17 Nov 2004 16:10:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailao.vtcif.telstra.com.au (mailao.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAI0A9V3034260 for <[e-mail]>; Wed, 17 Nov 2004 16:10:10 -0800 (PST) (envelope-from [e-mail])
Received: from mailai.vtcif.telstra.com.au (mailai.vtcif.telstra.com.au [202.12.142.17]) by mailao.vtcif.telstra.com.au (Postfix) with ESMTP id C516023E59 for <[e-mail]>; Thu, 18 Nov 2004 11:10:02 +1100 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id 68CC61DA81 for <[e-mail]>; Thu, 18 Nov 2004 11:10:02 +1100 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA16453 for <[e-mail]>; Thu, 18 Nov 2004 11:10:01 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CD02.9D88E680"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Subject: RE: 3280bis: name constraints
Date: Thu, 18 Nov 2004 11:07:38 +1100
Message-ID: <[e-mail]>
Thread-Topic: 3280bis: name constraints
Thread-Index: AcTMMAMpjNZtMRm+SR+RyZxi/uiAWAAB2EQgABOR0AAAHahGIA==
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4CD02.9D88E680
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Actually, the path will be valid in most cases.  The unsupported name
will usually match the unsupported constraint -- it's just that the code
cannot confirm that (as it is unsupported).  The code thinks "validity
unknown" so, to be fail-safe, it (reluctantly) says "treat as invalid".
=20
Path validation logic in a generic toolkit could, in fact, take into
account the names an application intends to use... just ask the app or
allowed the app to tell you.  Consider an app only interested in a
particular policy id, key usage and name form.  Only the policy id can
be specified as an input to the standardised path processing rules.
Microsoft Crypto API still allows the key usage to be passed to that
toolkit, however.  It is not that much of a stretch to imagine a toolkit
API accepting a list of name forms.
=20
Alternatively (or additionally), 3280bis could RECOMMEND that path
processing toolkits provide a mechanism to allow users to plugin new
modules to handle name constraints on otherwise unsupported name forms.
=20
=20
=20
  _____ =20

From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Wednesday, 17 November 2004 8:25 PM
To: Manger, James H; [e-mail]
Subject: RE: 3280bis: name constraints



It is not the end entity certificate that is valid or invalid in case of
a breach of name constraints. It is the path that is invalid.

=20

A CA certificate that contains a name constraints extension makes a
statement that this CA certificate is ONLY valid in a path if subsequent
certificates fall within these name boundaries.

=20

You may choose to trust the EE certificates anyway, but you can't use
that name constrained CA certificate as the means to do it.

You have to either.

=20

1) Directly trust the EE cert, or;

2) Find another path using another CA certificate.

=20

Since few applications have native support for path validation and
instead rely on toolkits to do the work, there is no means for the path
validation logic in the generic toolkit to do take into account what
name forms the application intends to make use of.=20

=20

Stefan Santesson=20
Microsoft Security Center of Excellence (SCOE)=20
 =20


  _____ =20


From: [e-mail] [mailto:[e-mail]]
On Behalf Of Manger, James H
Sent: den 17 november 2004 03:00
To: [e-mail]
Subject: RE: 3280bis: name constraints

=20

I agree with Terry -- having to reject a cert due to the presence of a
name (& name-constraint) of a type that you are going to completely
ignore is unnecessarily restrictive.  There is no attack that is
prevented by this rejection.  It just hinders the uptake of useful new
features as they can break backward compatibility.

=20

Consider a directory that strongly authenticates users.  It is only
interested in the user's DN.  It never does anything with email address,
URI, DNS etc.  Yet if it doesn't implement the rules for processing name
constraints on those names (which I believe have never been detailed in
X.509, only RFC 3280) then it cannot accept any cert chain that includes
(in addition to a DN) an email address, URI, DNS etc and an associated
constraint.

Similarly an email application that is only interested in email
addresses; a TLS proxy that is only interested in DNS names...

=20

The subjectAltName extension says any unrecognised or unsupported names
can be ignored (even if critical only one name from the extension needs
to be supported).  The nameConstraints extension basically contradicts
this by saying you can't actually ignore these names as they affect
whether the cert is acceptable or not.

=20

David Cooper's suggestion of issuing separate certs for each name form
that you want to constrain sounds ungainly.  Company A certifying
company B may well want to constrain directoryNames to "c=3DAU, =
o=3DCompany
B" and URIs, DNS names and email addresses to ".companyB.com.au".
Should it issue 1 cross-cert (with all constraints), 4 cross-certs to
the one company B CA, 4 cross-certs to 4 separate CA hierarchies in
company B...

=20

...but the problem lies with X.509's text & limitations for name
constraints .. so perhaps 3280bis cannot fix it.

=20


------_=_NextPart_001_01C4CD02.9D88E680
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<META content=3D"MSHTML 6.00.2800.1459" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 3.0cm 2.0cm 3.0cm 2.0cm; =
}
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; COLOR: black; FONT-FAMILY: "Times =
New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; COLOR: black; FONT-FAMILY: "Times =
New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; COLOR: black; FONT-FAMILY: "Times =
New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: =
"Times New Roman"
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; COLOR: black; FONT-FAMILY: =
"Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DDA vLink=3Dpurple link=3Dblue bgColor=3Dwhite>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D246262223-17112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Actually, the path will&nbsp;be valid in most =
cases.&nbsp;=20
The&nbsp;unsupported name will usually match the unsupported constraint =
-- it's=20
just that the code cannot confirm that (as it is unsupported).&nbsp; The =

code&nbsp;thinks "validity unknown" so, to be fail-safe, it =
(reluctantly) says=20
"treat as invalid".</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D246262223-17112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D246262223-17112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Path validation logic in a generic toolkit =
could,=20
in&nbsp;fact,&nbsp;take into account the names an application intends to =

use...&nbsp;just ask the app or allowed the app to&nbsp;tell you.&nbsp; =
Consider=20
an app only interested in a particular policy id, key usage and name=20
form.&nbsp;&nbsp;Only the&nbsp;policy id can be specified as an input to =
the=20
standardised path processing rules.&nbsp; <SPAN =
class=3D246262223-17112004><FONT=20
face=3DArial color=3D#0000ff size=3D2>Microsoft Crypto API still allows =
the=20
</FONT></SPAN>key usage to be passed to that toolkit, however.&nbsp; It =
is not=20
that much of a stretch to imagine a toolkit API accepting a list of name =

forms.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D246262223-17112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D246262223-17112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Alternatively (or additionally), 3280bis could =
RECOMMEND=20
that path processing toolkits provide a mechanism to allow users to =
plugin new=20
modules to handle</FONT></SPAN><SPAN class=3D246262223-17112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2> </FONT></SPAN><SPAN =
class=3D246262223-17112004><FONT=20
face=3DArial color=3D#0000ff size=3D2>name constraints on otherwise =
unsupported name=20
forms.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D246262223-17112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D246262223-17112004></SPAN><SPAN=20
class=3D246262223-17112004><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D246262223-17112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DTahoma size=3D2><B>From:</B> =
Stefan Santesson=20
[mailto:[e-mail]] <BR><B>Sent:</B> Wednesday, 17 November =
2004 8:25=20
PM<BR><B>To:</B> Manger, James H; [e-mail]<BR><B>Subject:</B> =
RE:=20
3280bis: name constraints<BR></FONT><BR></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">It is not =
the end=20
  entity certificate that is valid or invalid in case of a breach of =
name=20
  constraints. It is the path that is invalid.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">A CA =
certificate that=20
  contains a name constraints extension makes a statement that this CA=20
  certificate is ONLY valid in a path if subsequent certificates fall =
within=20
  these name boundaries.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">You may =
choose to=20
  trust the EE certificates anyway, but you can&#8217;t use that name =
constrained CA=20
  certificate as the means to do it.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">You have to =

  either.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">1) Directly =
trust the=20
  EE cert, or;</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">2) Find =
another path=20
  using another CA certificate.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Since few=20
  applications have native support for path validation and instead rely =
on=20
  toolkits to do the work, there is no means for the path validation =
logic in=20
  the generic toolkit to do take into account what name forms the =
application=20
  intends to make use of. </SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <DIV>
  <P><B><FONT face=3DArial color=3Dolive size=3D2><SPAN lang=3DEN-GB=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: olive; =
FONT-FAMILY: Arial">Stefan=20
  Santesson</SPAN></FONT></B><FONT color=3Dnavy><SPAN lang=3DEN-GB=20
  style=3D"COLOR: navy"> <BR></SPAN></FONT><FONT face=3DArial =
color=3Dolive=20
  size=3D2><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: olive; FONT-FAMILY: Arial">Microsoft =
Security=20
  Center of Excellence (SCOE)</SPAN></FONT><FONT color=3Dnavy><SPAN =
lang=3DEN-GB=20
  style=3D"COLOR: navy"> <BR></SPAN></FONT><FONT face=3DArial =
color=3Dnavy><SPAN=20
  lang=3DEN-GB style=3D"COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;</SPAN></FONT><FONT=20
  color=3Dnavy><SPAN lang=3DEN-GB style=3D"COLOR: navy"> =
</SPAN></FONT></P></DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" color=3Dblack size=3D3><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 12pt; COLOR: windowtext">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma color=3Dblack =
size=3D2><SPAN lang=3DEN-US=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: windowtext; =
FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma color=3Dblack size=3D2><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: Tahoma">=20
  [e-mail] [mailto:[e-mail]] =
<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Manger, James =
H<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> den 17 november 2004=20
  03:00<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
  [e-mail]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B>=20
  RE: 3280bis: name constraints</SPAN></FONT></P></DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =

  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I agree =
with Terry --=20
  having to reject a cert due to the presence of a name (&amp; =
name-constraint)=20
  of a type that you are going to completely ignore is unnecessarily=20
  restrictive.&nbsp; There is no attack that is prevented by this=20
  rejection.&nbsp; It just hinders the uptake of useful new features as =
they can=20
  break backward compatibility.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =

  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Consider a =
directory=20
  that strongly authenticates users.&nbsp; It is only interested in the =
user's=20
  DN.&nbsp; It never does anything with email address, URI, DNS =
etc.&nbsp; Yet=20
  if it doesn't implement the rules for processing name constraints on =
those=20
  names (which I believe have never been detailed in X.509, only RFC =
3280) then=20
  it cannot accept any cert chain that includes (in addition to a DN) an =
email=20
  address, URI, DNS etc&nbsp;and an associated =
constraint.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Similarly =
an email=20
  application that is only interested in email addresses; a TLS proxy =
that is=20
  only interested in DNS names...</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =

  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">The =
subjectAltName=20
  extension says any unrecognised or unsupported names can be ignored =
(even if=20
  critical only&nbsp;one name from the extension needs to be =
supported).&nbsp;=20
  The nameConstraints extension basically contradicts this by saying you =
can't=20
  actually&nbsp;ignore these names as they affect whether the cert is =
acceptable=20
  or not.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =

  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">David =
Cooper's=20
  suggestion of issuing separate certs for each name form that you want =
to=20
  constrain sounds ungainly.&nbsp; Company A&nbsp;certifying company B =
may well=20
  want to constrain directoryNames to "c=3DAU, o=3DCompany B" and URIs, =
DNS names=20
  and&nbsp;email addresses to ".companyB.com.au".&nbsp; Should it issue =
1=20
  cross-cert (with all constraints), 4 cross-certs to the&nbsp;one =
company B CA,=20
  4 cross-certs to 4 separate CA hierarchies in company =
B...</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =

  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">...but the =
problem=20
  lies with X.509's text &amp; limitations&nbsp;for name constraints .. =
so=20
  perhaps 3280bis cannot fix it.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt"></SPAN></FONT>&nbsp;</P></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4CD02.9D88E680--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHMLDUb071512; Wed, 17 Nov 2004 14:21:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHMLDHf071511; Wed, 17 Nov 2004 14:21:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from outmx010.isp.belgacom.be (outmx010.isp.belgacom.be [195.238.3.233]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHMLCt3071500 for <[e-mail]>; Wed, 17 Nov 2004 14:21:13 -0800 (PST) (envelope-from [e-mail])
Received: from outmx010.isp.belgacom.be (localhost [127.0.0.1]) by outmx010.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id iAHMLBMc000736 for <[e-mail]>; Wed, 17 Nov 2004 23:21:11 +0100 (envelope-from <[e-mail]>)
Received: from multimail.skynet.be (webmailfront001.isp.belgacom.be [195.238.3.60]) by outmx010.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with SMTP id iAHML9N6000727 for [e-mail]; Wed, 17 Nov 2004 23:21:09 +0100 (envelope-from <[e-mail]>)
Message-Id: <[e-mail]>
X-Webmail-posting-IP: 81.241.26.150
From: [e-mail]
Subject: CRL SCOPE in rfc3280
To: [e-mail]
Date: Wed, 17 Nov 2004 23:21:09 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=-----boundalter150977
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-------boundalter150977
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

Hi,

In rfc 3280 say about distribution point: 

If the distributionPoint field is absent, the CRL MUST contain entries for all revoked unexpired certificates issued by the CRL issuer, if any, within the scope of the CRL.

Can someone explain to me what mean the last part of the sentence exactly in this context? The part 'within the scope of the CRL'. I would have wrote :

If the distributionPoint field is absent, the CRL MUST contain entries for all revoked unexpired certificates issued by the CRL issuer, if any.

Thanks...

Marc



-------boundalter150977
Content-Type: text/html
Content-Transfer-Encoding: 8bit
Content-Disposition: inline

Hi,<br><br>In rfc 3280 say about distribution point: <br><br>If the distributionPoint field is absent, the CRL MUST contain entries for all revoked unexpired certificates issued by the CRL issuer, if any, within the scope of the CRL.<br><br>Can someone explain to me what mean the last part of the sentence exactly in this context? The part 'within the scope of the CRL'. I would have wrote :<br><br>If the distributionPoint field is absent, the CRL MUST contain entries for all revoked unexpired certificates issued by the CRL issuer, if any.<br><br>Thanks...<br><br>Marc<br><br><br>
-------boundalter150977--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHLfRbu058935; Wed, 17 Nov 2004 13:41:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHLfR4p058934; Wed, 17 Nov 2004 13:41:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHLfM5e058909 for <[e-mail]>; Wed, 17 Nov 2004 13:41:22 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAHLek2x017355; Wed, 17 Nov 2004 16:40:46 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAHLeTYA010812; Wed, 17 Nov 2004 16:40:34 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 17 Nov 2004 16:41:05 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: 3280bis: indirectCRL boolean in IDP (3/3)
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Denis Pinkas wrote:<br>
<blockquote type="cite" cite="[e-mail]">
  <meta http-equiv="Content-Type" content="text/html;">
  <title></title>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
James,<br>
  <br>
  <blockquote type="cite"
 cite="[e-mail]">
    <pre wrap="">The indirectCRL field should not be redefined.
CRL issuers do issue certificates if they are also CAs (as they often
are).  </pre>
  </blockquote>
When the term CRL Issuer is used, it means an entity issuing CRLs, not
certificates. <br>
If an entity issues public key certificates, then it is called a CA.</blockquote>
This is not true.&nbsp; Paragraph 3 of section 5 in RFC 3280 begins: "CRL
issuers issue CRLs.&nbsp; In general, the CRL issuer is the CA."<br>
<br>
A CRL issuer is an entity that issues CRLs.&nbsp; A CRL issuer may or may
not be a CA (i.e., an entity that issues certificates).&nbsp; An entity that
issues indirect CRLs may or may not be a CA.&nbsp; If it is a CA, then it
may issue a single CRL that covers its own certificates in addition to
the certificates of other CAs.<br>
<blockquote type="cite" cite="[e-mail]">The
question is the meaning of the indirectCRL boolean in IDP.<br>
  <br>
If we take a look at X.509, it is defined in the following way:<br>
  <br>
  <span lang="EN-GB" style="font-size: 10pt; font-family: Times;">"<big>If
  </big></span><big><big><big><big><big><b style=""><span lang="EN-GB"
 style="font-size: 9pt; font-family: Helvetica;">indirectCRL</span></b></big><span
 lang="EN-GB" style="font-size: 10pt; font-family: Times;"><big> is
true, then the CRL may contain revocation
notifications from authorities <br>
other than the issuer of the CRL.</big> "<br>
  <br>
  <big>Note the sentence, even incorrect at the end (and thus
duplicating
an incorrect sentence from X.509)<br>
&nbsp;is using the plural, i.e. "</big></span></big></big></big></big><big><big><big><big><span
 lang="EN-GB" style="font-size: 10pt; font-family: Times;"><big>from
authorities" </big></span></big></big></big></big>which means it is an
indirect CRL of type b).</blockquote>
<br>
You are misreading this sentence.&nbsp; This does not mean that the
indirectCRL flag is only set to true if the CRL may contain revocation
notifications from more than one authority other than the issuer of the
CRL.&nbsp; As long as the scope of the CRL includes certificates issued by
an entity other than the issuer of the CRL then the indirectCRL flag
must be set to true.<br>
<br>
If some people are misinterpreting the current text to mean that the
flag should only be set if the CRL covers more than one CA other than
the CRL issuer then we can work on rewording the text.&nbsp; But, we can not
change the meaning of the indirectCRL flag.<br>
<br>
Dave<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHGxHv9055037; Wed, 17 Nov 2004 08:59:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHGxHcR055035; Wed, 17 Nov 2004 08:59:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHGxEU6054906 for <[e-mail]>; Wed, 17 Nov 2004 08:59:15 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 16:59:07 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: serialNumber Attribute
Date: Wed, 17 Nov 2004 16:59:01 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: serialNumber Attribute
Thread-Index: AcTMvnigiUoJSmnoSF2Mx2PBxzZpEgAB+msw
From: "Stefan Santesson" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 17 Nov 2004 16:59:07.0584 (UTC) FILETIME=[C0589C00:01C4CCC6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAHGxFU6055007
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would guess that the certificate is using the definitions outlined in
RFC 3739 (Qualified Certificate Profile), which contains guidance on the
use of serialNumber in DN when issuing ID certificates to people.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Stephen Kent
> Sent: den 17 november 2004 15:44
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: serialNumber Attribute
> 
> 
> At 2:02 PM +0100 11/17/04, [e-mail] wrote:
> >Hi,
> >
> >Not having found a reference specifies in the RFC, I call upon you to
> solve a
> >problem currently met by certain Frecnh CA.
> >
> >  Certificates were emitted with in the DN a serialNumber attribute
> >containing a
> >value different from the serialNumber contained in the certificate.
> >
> >  This is correct ?
> >
> >I don't find reference in RFC3280 for attribute serialNumber in
> >certificate, it
> >is subjected to the conditon of the paragraph 4.1.2.2 "Serial number"
?
> >
> >Thanhs Yannick
> 
> The serialNumber attribute that may appear in a DN is in no way
> related to the serial number value that appears in the cert.  Sorry
> that the names cause confusion, but the text defining each of these
> values in a cert is pretty clear.
> 
> Steve




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHGochO051852; Wed, 17 Nov 2004 08:50:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHGocd3051851; Wed, 17 Nov 2004 08:50:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHGobER051773 for <[e-mail]>; Wed, 17 Nov 2004 08:50:37 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1CUT0p-000CIy-Jg; Wed, 17 Nov 2004 16:50:31 +0000
Message-ID: <[e-mail]>
Date: Wed, 17 Nov 2004 16:51:19 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], david.cooper@nist
Subject: Re: 3280bis: extension criticality treatment
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester wrote:
>> I can recall threads where it was stated that recognized extensions
>> MUST be processed irrespective of the their criticality. Should we
>> clarify this in RFC3280bis?
> 
> 
> I suggest to add explicitely:
> 
> If extensions are treated, thus MUST be done independantly from the
> value of criticality bit.
> 
> unless this text already appears somewhere, or can be concluded by
> simply binary logic from other MUST's MAY etc.
> 

X509 leaves no doubt:

> When a certificate-using implementation recognizes and is able to
> process an extension, then the certificate-using implementation shall
> process the extension regardless of the value of the criticality
> flag.

I've lost count of the number of "bug reports" I've received prompted 
by rejection of a certificate path due to a processing of a
non-critical extension. They typically quote variations on the "its
non-critical so it can be ignored" argument.

This suggests, to me at least, that even if this can be inferred from 
the other text, it isn't clear enough and should be explicitly stated.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHGA90O038423; Wed, 17 Nov 2004 08:10:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHGA9Km038422; Wed, 17 Nov 2004 08:10:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHGA9t3038380 for <[e-mail]>; Wed, 17 Nov 2004 08:10:09 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAHGA3jf017783 for <[e-mail]>; Wed, 17 Nov 2004 11:10:04 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06200709bdc1270585ef@[128.89.89.75]>
Date: Wed, 17 Nov 2004 11:09:05 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft meeting minutes
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please review and comment on these minutes from last week's PKIX 
meeting.  I plan to submit them to the Secretariat by 11/24.

Steve
-------

PKIX WG Meeting 11/10/04

Edited by Steve Kent

Chairs: Stephen Kent <[e-mail]> & Tim Polk <[e-mail]>

The PKIX WG met once during the 61st IETF. A total of approximately 
55 individuals participated in the meeting.


Document status - Tim Polk (NIST)
	One new RFC: SHA-224. Three documents approved by IESG, now 
in RFC Editor's queue: public key algorithms, CMPbis, and Permanent 
identifier. Warranty extension awaiting AD followup. Five documents 
under Security AD review (includes awaiting corrections by authors): 
AC policies, Certificate path building, Certificate Store, PKIX 
repository, and CRMFbis. In WG last call: SCVP. Almost ready for WG 
last call: SIM, various LDAP documents, and Elliptic curve 
algorithms. See slides for additional details.


SCVP (version 16) - Trevor Freeman (Microsoft)
	Lots of changes have been made from v15; many were editorial 
but also many substantive changes and some new features. Another rev 
of the document will be needed. We need to ensure that the ASN.1 is 
correct, once we agree on the functionality, and so we will compile 
it to verify. Presentation reviewed changes and new features 
(relative to v15). See slides for additional details.


3280bis - Tim Polk (NIST)
       The co-chairs have selected a lead editor for RFC 3280bis and 
formed a design team to develop a -00 draft from a issues list 
complied from PKIX mail messages and mail to the RFC 3280 editors. 
Draft -00 is expected late in 2004. See slides for additional details.


Using AIA in CRLs - Stefan Santesson (Microsoft)
A new PKIX document proposing extending use of the AIA certificate 
extension in CRLs, to facilitate locating the certificate for the 
signer of a CRL. This is a simple, new use of this existing 
(certificate) extension, with straightforward semantics. Examples 
were presented showing how this new capability accommodates CA rekey 
and indirect CRL situations. This solution is preferable to use of 
SIA, since SIA would work only a subset of the cases presented, and 
because inserting AIA in CRLs is easier than inserting SIA in 
certificates, given the relative frequency of issuance of each. See 
slides for additional details.


CRL Processing Rules Issues - Santosh Chokhani (Orion)
       This presentation provides a review of issues in CRL processing 
when different keys are used for signing certificates vs. the CRLs 
that revoke those certificates. This is allowed in X.509 and 3280 for 
various purposes, e.g., indirect CRLs, CA key rollover, etc. However, 
these standards do not address the details of how to ensure that the 
right public key is used to verify CRL signatures in these cases. 
Problems also may arise due to conflicts in CA names (assigned under 
different administrative entities). Finally, some problems also may 
arise when OCSP is used (in lieu of CRLs) and this presentation 
proposes means to address these problems as well. Russ notes that for 
this and for Stafan's presentation, a critical feature is that the 
SAME trust anchor must be used to verify the target certificates and 
certificates for the corresponding CRLs. See slides for additional 
details.


LDAP Schemas - David Chadwick (Univ. of Salford)
	PKIX has a suite of LDAP-PKIX drafts forming a comprehensive 
solution for LDAP based PKI information distribution. No significant 
change since the last meeting, just minor updates. So the versions 
posted last week should not be ready for last call, which will be 
issued by mid-November. Goal is to issue these as Informational RFCs. 
In parallel, we will pass these I-Ds to the LDAP folks for review. 
See slides for additional details.


LDAP PKIX Schema Issues - Kurt Zeilenga (LDAP WG co-chair)
       This presentation discussed remaining issues associated with 
PKI LDAP schemas. See slide for additional details.


Lightweight OCSP - Ryan Hurst (Microsoft)
	This presentation discusses a new document (not a PKIX work 
item) that describes how to use OCSP in "response pre-production" 
environments. The document also includes a profile for OCSP clients 
and servers, and proposes some new extensions to improve 
functionality. Initial intent was to make this an informational RFC, 
but they are reconsidering its status, perhaps shooting for a 
standards track document as an individual submission. See slides for 
additional details.


Algorithm IDs for ECC in PKIX - Tim Polk presented for Daniel Brown (Certicom)
	There have been changes since the previous version, for 
better alignment with NIST algorithm publications. The document also 
provides info for other EC curves, not just the NIST ones. Suggestion 
from Russ is to edit this document to address only NIST approved 
curves, and use a separate document for other curves and for MQV 
(e.g., vs. EC-DSA and EC-RSA). Issue arose as to whether we need a 
means of restricting use of a key to a SET of EC algorithms, vs. an 
individual (EC) algorithm. Russ advises that this is NOT a good idea, 
given experience with RSA keys. See slides for additional details.


User Interface Requirements for PKIX - Baehyo Park (KISA)
       This presentation describes a personal draft, not a PKIX work 
item.  The presentation is a follow-up to a presentation on draft -00 
at IETF-60. The speaker used his laptop to demonstrate the GUI he 
proposes, though a scripted scenario.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHFBCOn018037; Wed, 17 Nov 2004 07:11:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHFBCQp018035; Wed, 17 Nov 2004 07:11:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHFBBGZ018010 for <[e-mail]>; Wed, 17 Nov 2004 07:11:11 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAHFAXn25274; Wed, 17 Nov 2004 16:10:33 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 17 Nov 2004 16:10:33 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAHFAWN05783; Wed, 17 Nov 2004 16:10:32 +0100 (MET)
Date: Wed, 17 Nov 2004 16:10:32 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> In the following, there is an attempt to define that single method.
> 
> The requirements for the CA would be:
> 
> "The CA that places a CRL DP extension in a certificate with a cRLIssuer
> field present SHALL issue a CRL Issuer certificate for the DN contained
> in that cRLIssuer field".

CA1 : C=WW, O=org1 which issues certs and CRLs for all CAs.

CA1->CA2 : C=WW, O=org2 with this as permitted name space 
CA1->CA3 : C=WW, O=org3 with the permitted name space 


CA2/3 wants to put C=WW, O=org1 into a CRLIssuer, it can do so. 

How can CA2/3 issue a cert to CA1? 

  



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHEk4Ox008195; Wed, 17 Nov 2004 06:46:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHEk4JP008194; Wed, 17 Nov 2004 06:46:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHEk3rP008131 for <[e-mail]>; Wed, 17 Nov 2004 06:46:03 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAHEjnjh012297; Wed, 17 Nov 2004 09:45:54 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06200703bdc113cd04f0@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 17 Nov 2004 09:43:49 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: serialNumber Attribute
Cc: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:02 PM +0100 11/17/04, [e-mail] wrote:
>Hi,
>
>Not having found a reference specifies in the RFC, I call upon you to solve a
>problem currently met by certain Frecnh CA.
>
>  Certificates were emitted with in the DN a serialNumber attribute 
>containing a
>value different from the serialNumber contained in the certificate.
>
>  This is correct ?
>
>I don't find reference in RFC3280 for attribute serialNumber in 
>certificate, it
>is subjected to the conditon of the paragraph 4.1.2.2 "Serial number" ?
>
>Thanhs Yannick

The serialNumber attribute that may appear in a DN is in no way 
related to the serial number value that appears in the cert.  Sorry 
that the names cause confusion, but the text defining each of these 
values in a cert is pretty clear.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHEVUlB003132; Wed, 17 Nov 2004 06:31:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHEVUOH003131; Wed, 17 Nov 2004 06:31:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHEVTNI003107 for <[e-mail]>; Wed, 17 Nov 2004 06:31:29 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAHEVUn24666; Wed, 17 Nov 2004 15:31:30 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 17 Nov 2004 15:31:30 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAHEVTe05630; Wed, 17 Nov 2004 15:31:29 +0100 (MET)
Date: Wed, 17 Nov 2004 15:31:29 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: 3280bis: extension criticality treatment
Cc: david.cooper@nist
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> I can recall threads where it was stated that recognized extensions MUST 
> be processed irrespective of the their criticality. Should we clarify 
> this in RFC3280bis?

I suggest to add explicitely: 

  If extensions are treated, thus MUST be done independantly from
  the value of criticality bit. 

unless this text already appears somewhere, or can be concluded
by simply binary logic from other MUST's MAY etc. 

 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHDx0sJ092196; Wed, 17 Nov 2004 05:59:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHDx0uO092195; Wed, 17 Nov 2004 05:59:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft3.fr.colt.net (smtp-ft3.fr.colt.net [213.41.78.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHDwxEo092142 for <[e-mail]>; Wed, 17 Nov 2004 05:58:59 -0800 (PST) (envelope-from [e-mail])
Received: from [10.0.0.51] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft3.fr.colt.net with ESMTP id iAHDwmF07631 for <[e-mail]>; Wed, 17 Nov 2004 14:58:54 +0100
Message-ID: <[e-mail]>
Date: Wed, 17 Nov 2004 14:58:48 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041018
X-Accept-Language: fr, en-us, en, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: serialNumber Attribute
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:

> Certificates were emitted with in the DN a serialNumber attribute containing a
>value different from the serialNumber contained in the certificate.
>
> This is correct ? 
>  
>
There is no relationship at all between the two values, there is no 
reason to expect they would identical.

>I don't find reference in RFC3280 for attribute serialNumber in certificate, it
>is subjected to the conditon of the paragraph 4.1.2.2 "Serial number" ?
>  
>
The serialNumber attribute that you can use in the DN is defined in X.520.
Inside RFC3280 it's referenced as X520SerialNumber, but RFC3280 doesn't 
say much about it.

RFC 2256 has a little more information about it.
In PKI usage, this attribute is supposed to be used to avoid duplicated 
DN for two users, when the other attributes present in the DN are not 
sufficient.
It can have any value adequate for this.







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHDURjk076110; Wed, 17 Nov 2004 05:30:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHDURHV076109; Wed, 17 Nov 2004 05:30:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHDUPm0076046 for <[e-mail]>; Wed, 17 Nov 2004 05:30:26 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA51974; Wed, 17 Nov 2004 14:42:19 +0100
Received: from bull.net ([129.181.81.78]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111714300695:787 ; Wed, 17 Nov 2004 14:30:06 +0100 
Message-ID: <[e-mail]>
Date: Wed, 17 Nov 2004 14:30:06 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: [e-mail], pkix <[e-mail]>
Subject: Re: 3280bis: indirectCRL boolean in IDP (3/3)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 17/11/2004 14:30:07, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 17/11/2004 14:30:09, Serialize complete at 17/11/2004 14:30:09
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
James,<br>
<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">The indirectCRL field should not be redefined.
CRL issuers do issue certificates if they are also CAs (as they often
are).
  </pre>
</blockquote>
When the term CRL Issuer is used, it means an entity issuing CRLs, not
certificates. <br>
If an entity issues public key certificates, then it is called a CA.<br>
<br>
The question is the meaning of the indirectCRL boolean in IDP.<br>
<br>
If we take a look at X.509, it is defined in the following way:<br>
<br>
<span lang="EN-GB" style="font-size: 10pt; font-family: Times;">"<big>If
</big></span><big><big><big><big><big><b style=""><span lang="EN-GB"
 style="font-size: 9pt; font-family: Helvetica;">indirectCRL</span></b></big><span
 lang="EN-GB" style="font-size: 10pt; font-family: Times;"><big> is
true, then the CRL may contain revocation
notifications from authorities <br>
other than the issuer of the CRL.</big> "<br>
<br>
<big>Note the sentence, even incorrect at the end (and thus duplicating
an incorrect sentence from X.509)<br>
&nbsp;is using the plural, i.e. "</big></span></big></big></big></big><big><big><big><big><span
 lang="EN-GB" style="font-size: 10pt; font-family: Times;"><big>from
authorities" </big></span></big></big></big></big>which means it is an
indirect CRL of type b).<br>
<br>
Denis<br>
<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">The indirectCRL field does not only indicate a "type b) indirect CRL" --
it must also be set to true for a "type a) indirect CRL".

Proposed action: don't accept Denis's proposed correction or proposed
note.

-----Original Message-----
From: <a
 class="moz-txt-link-abbreviated"
 href="mailto:[e-mail]">[e-mail]</a> [<a
 class="moz-txt-link-freetext"
 href="mailto:[e-mail]">mailto:[e-mail]</a>]
On Behalf Of Denis Pinkas
Sent: Sunday, 14 November 2004 1:00 AM
To: <a
 class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Cc: pkix
Subject: 3280bis: indirectCRL boolean in IDP (3/3)


3280bis: indirectCRL boolean in IDP (3/3)

This is a change and an addition proposal related to indirect CRLs.

&gt;From section 5.2.5 Issuing Distribution Point, "the CRL issuer MUST
assert the indirectCRL boolean, if the scope of the CRL includes
certificates issued by authorities other than the CRL issuer".

This sentence is incorrect since CRL issuers do not issue certificates.


Proposed correction: 

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of the
CRL includes certificate identifiers from multiple authorities"
 
This boolean indicates a type b) indirect CRL but is named indirectCRL
boolean which is confusing with type a) indirect CRLs.

A note should be mentioned to clarify the ambiguity of the naming.

Proposed note: 

"The name of the boolean "indirectCRL" designates an indirect CRL that
includes certificate identifiers from multiple authorities, and not an
indirect CRL that includes certificate identifiers from a single CA.
An alternative name for that boolean would be: multipleCAs."

Denis



  </pre>
</blockquote>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHCuAjv063782; Wed, 17 Nov 2004 04:56:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHCuAGw063781; Wed, 17 Nov 2004 04:56:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHCu8sQ063764 for <[e-mail]>; Wed, 17 Nov 2004 04:56:09 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAHCu8n23238; Wed, 17 Nov 2004 13:56:08 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 17 Nov 2004 13:56:08 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAHCu7G05376; Wed, 17 Nov 2004 13:56:07 +0100 (MET)
Date: Wed, 17 Nov 2004 13:56:07 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: 3280bis issue: paragraph titles and field names.
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Subchapter 4.1.2 and others seems to use inconsistent names.

For example: 

4.1.2  TBSCertificate  


   ... The remainder of this section describes the syntax and
   semantics of these fields. 
                      XXXXXX

4.1.2.1  Version

   This field describes 

5.1.2.1  Version 

   .. 

These should be 'version'  since it is the field and not the type.

4.1.2.2  Serial number

should be serialNumber (also in the text)

4.1.2.3  Signature

should be signature    



   This field MUST contain the same algorithm identifier as the
   signatureAlgorithm field in the sequence Certificate (section
   4.1.1.2). 



   This field MUST contain the same algorithm identifier as the
   signatureAlgorithm field in the surrounding sequence Certificate
   (section 4.1.1.2). 

4.1.2.4  Issuer (should be issuer)

   The issuer field 

Ah, some texts start with 'This field', others with 'The xxx field'

and so on up to

4.1.2.9  Extensions

This continues in various other areas. 

A possible solution to avoid lower case title may be to write
something like "Field signature' and 'Type XXX'



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHClUM9060659; Wed, 17 Nov 2004 04:47:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHClU72060658; Wed, 17 Nov 2004 04:47:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from citron.linagora.com (citron.linagora.com [195.68.36.78]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHClTt6060603 for <[e-mail]>; Wed, 17 Nov 2004 04:47:29 -0800 (PST) (envelope-from [e-mail])
Received: from sgi2.linagora.com (sgi2.linagora.com [195.68.36.75]) by citron.linagora.com (Postfix) with ESMTP id 82D4D8703 for <[e-mail]>; Wed, 17 Nov 2004 14:05:07 +0100 (CET)
Received: from sgi2 (sgi2 [127.0.0.1]) by localhost (Postfix) with SMTP id 3C024198D5F for <[e-mail]>; Wed, 17 Nov 2004 13:47:20 +0100 (CET)
Received: from tomate.linagora.lan (intranet.linagora.lan [192.168.1.3]) by sgi2.linagora.com (Postfix) with ESMTP id F0C01198D4F for <[e-mail]>; Wed, 17 Nov 2004 13:47:19 +0100 (CET)
Received: by tomate.linagora.lan (Postfix, from userid 81) id BF37F7DB; Wed, 17 Nov 2004 14:02:30 +0100 (CET)
Received: from fw-lan.linagora.lan (fw-lan.linagora.lan [192.168.1.254])  by tomate.linagora.lan (IMP) with HTTP  for <[e-mail]>; Wed, 17 Nov 2004 14:02:30 +0100
Message-ID: <[e-mail]>
Date: Wed, 17 Nov 2004 14:02:30 +0100
From: [e-mail]
To: "[e-mail]" <[e-mail]>
Subject: serialNumber Attribute
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 192.168.1.254
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Not having found a reference specifies in the RFC, I call upon you to solve a
problem currently met by certain Frecnh CA. 

 Certificates were emitted with in the DN a serialNumber attribute containing a
value different from the serialNumber contained in the certificate.

 This is correct ? 

I don't find reference in RFC3280 for attribute serialNumber in certificate, it
is subjected to the conditon of the paragraph 4.1.2.2 "Serial number" ?

Thanhs Yannick 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHAb8nF065776; Wed, 17 Nov 2004 02:37:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHAb8YH065765; Wed, 17 Nov 2004 02:37:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gate3.chttl.com.tw ([203.75.28.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHAb46V065632 for <[e-mail]>; Wed, 17 Nov 2004 02:37:05 -0800 (PST) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by gate3.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAHAb190019350; Wed, 17 Nov 2004 18:37:01 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id iAHAb0ss002599; Wed, 17 Nov 2004 18:37:00 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAHAb0ZG002530; Wed, 17 Nov 2004 18:37:00 +0800
Message-ID: <01fb01c4cc91$5def61f0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "pkix" <[e-mail]>
Subject: 3280bis issue:  Name Rollover certificate
Date: Wed, 17 Nov 2004 18:36:59 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The current text of RFC 3280 recommend using "name rollover" certificates to
support an orderly migration to UTF8String encoding.

However, I recall that there being a number of threads discussing whether
the recommendation works. It was finally concluded that the recommendation
does not work. Therefore, shouldn't the recommendation of using "name rollover"
certificates be removed from son of RFC 3280.

Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHAb8OM065767; Wed, 17 Nov 2004 02:37:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHAb7Nb065743; Wed, 17 Nov 2004 02:37:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw ([202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHAb4Rh065569 for <[e-mail]>; Wed, 17 Nov 2004 02:37:05 -0800 (PST) (envelope-from [e-mail])
Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAHAawrt019792; Wed, 17 Nov 2004 18:36:58 +0800
Received: (from root@localhost) by ms20.chttl.com.tw (8.12.10/8.12.10) id iAHAawBs023448; Wed, 17 Nov 2004 18:36:58 +0800
Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAHAavL1023379; Wed, 17 Nov 2004 18:36:57 +0800
Message-ID: <01f501c4cc91$5ca24880$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "pkix" <[e-mail]>
Subject: 3280bis issue:  caIssuers AccessMethod in AIA and caRepository AccessMethod in SIA
Date: Wed, 17 Nov 2004 18:36:56 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a recall that recent discussions in the WG mailing list
have agreed that the current text of caIssuers AccessMethod
in AIA and caRepository AccessMethod in SIA is not crystal clear
and need to be clarified in RFC3280bis.

Especally, if their AccessLocaltion are URIs, then what kinds
of objects will be retrieved from those URIs and what will be
the MIME types of the retrieved objects.

Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHAb8Bu065766; Wed, 17 Nov 2004 02:37:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHAb7jo065732; Wed, 17 Nov 2004 02:37:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gate3.chttl.com.tw ([203.75.28.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHAb49j065524 for <[e-mail]>; Wed, 17 Nov 2004 02:37:05 -0800 (PST) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by gate3.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAHAavhh019340; Wed, 17 Nov 2004 18:36:57 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id iAHAatOX002524; Wed, 17 Nov 2004 18:36:55 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAHAatZG002455; Wed, 17 Nov 2004 18:36:55 +0800
Message-ID: <01ef01c4cc91$5b509b30$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "pkix" <[e-mail]>
Subject: 3280bis issue:  issues related to self-issued certificates
Date: Wed, 17 Nov 2004 18:36:54 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The definition of the term "self-issued certificate" is too vague.

The current text of RFC 3280 only mention

"A certificate is self-issued if the DNs that appear in the subject
 and issuer fields are identical and are not empty....a CA may
 issue a certificate to itself to support key rollover or changes in
 certificate policies.  These self-issued certificates are not counted
 when evaluating path length or name constraints."

However, there are many kinds of self-issued certificates. For
example:

(a) self-signed certificates (this is a special case of self-issued certificate)
(b) self-issued certificates with keyCertSign key usage (might with cRLSign key usage as well)
(c) self-issued certificates with cRLSign key usage only (a CA using separate key for CRL signing)
(d) self-issued certificates with key usages other than keyCertSign and cRLSign

Self-issued certificates of type (c) are also known as "self-issued
intermediate certificates" according to the X.509 (2000) standard.
Obviously, only self-issued certificates of type (c) are thought to
be CA certificates. However, they are special CA certificates
for special purpose (e.g., Key Rollover) so that they do not contribute
to the path length for purposes of processing some constraint
extension and name constrains extension in certification path validation.

Self-issued certificates of type (a), (c) and (d) can not be
intermediate certificates and thus the above special processing
rule does not apply to them. This is not crystal clear in the current
text of RFC 3280.

Obviously, self-issued certificates of type (a) and (b) should conatins
a basicConstraints extension with cA = TRUE since they are
CA certificates.

It is not clear whether self-issued certificates of type (c) should
also conatins a basicConstraints extension with cA = TRUE.

Self-issued certificates of type (d) should be thought as EE
certificates, therefore they should not contain  a basicConstraints
extension with cA = TRUE. However, some PKIX WG members
might not agree to this interpretation.

When perform path validation, it is not clear what will be the effect
if some certificate extensions such as polcyMappings, policyConstraints,
nameConstraints, and inhibitAnyPolicy appear in self-issued 
intermediate certificates (i.e., self-issued certificate of type (b)).
The current text only says that this type of self-issued certificates do not
contribute to the path length for purposes of processing some constraint
extension and name constrains extension in certification path validation,
it is not clear that whether these extensions can appear in this type of
self-issued certificate.

There is a serious security problem related to revocation status
checking for self-issued certificates of type (b) and (c).
For type (b), it might be a CA key rollover situation, and if the CA stopped
using its old key to issue CRL, then there is no way to check the revocation
status of the new self-issued certificate unless there is another way (e.g.,
OCSP or other out-of-band mechanism) to check its revocation status.
If the new key is unfortunately compromised later, this will be a serious
security problem.

For type (c), since the CA is using separate key for CRL signing and
its Certificate with cRLSign key usage is signed by itself not signed
by another CA. Therefore, no one can provide the revocation status
info for that self-issued certificates unless there is another way (e.g.,
OCSP or other out-of-band mechanism) to check its revocation status.
If its CRL signing key is unfortunately compromised, this will be a serious
security problem.

Finally, it is not clear that, when a RP choose to use X.500 string matching
rules (or StringPrep-based String matching rules), whether certificates with
identical non-empty issuer name and subjec name but with different string
encoding (e.g., one in PrintableString while one in UTF8String) are also
thought as self-issued certificates.

Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHAaxlq065595; Wed, 17 Nov 2004 02:37:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHAax4A065583; Wed, 17 Nov 2004 02:36:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw ([202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHAaun4065321 for <[e-mail]>; Wed, 17 Nov 2004 02:36:56 -0800 (PST) (envelope-from [e-mail])
Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAHAajEG019764; Wed, 17 Nov 2004 18:36:45 +0800
Received: (from root@localhost) by ms20.chttl.com.tw (8.12.10/8.12.10) id iAHAaieU023289; Wed, 17 Nov 2004 18:36:44 +0800
Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAHAaiL1023220; Wed, 17 Nov 2004 18:36:44 +0800
Message-ID: <01dd01c4cc91$54c13950$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "pkix" <[e-mail]>
Subject: 3280bis issue:  DP name matching between IDP and CRLDP
Date: Wed, 17 Nov 2004 18:36:43 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In CRL processing/validation specified by both RFC 3280
and the X.509 standards, there is a requirement that at least 
 one of names in the distribution point name field (if present)
of the IDP extension (if present) of the CRL must match
one of the names in the distribution point name field of one
distribution point field of the CRLDP extension of the certificate.
Alternative, one of names in the distribution point name field
(if present) of the IDP extension (if present) of the CRL must
match one of the names in the cRLIssuer field of one
distribution point field of the CRLDP extension of the certificate.

However, RFC 3280 did not clearly specify the distribution point
name matching rule. Does two names need to be exactly matched
(binary matched)? Can a Stringprep-based matching (e.g., the text
string matching profile proposed by Paul Hoffman and Steve Hanna)
be used? What about case sensitivibility or whitespace ignorability?

Since they are all of GeneralNames type, they can be in various
name forms. They might be DN, URI,  RFC822 Name, DNS Name,
or IP Address. For URI, they might be http URI, ftp URI, mailto URI,
ldap URI. Different name form might need different matching rules.
Alternative, we might stipulate that "Binary Matching" must be use
for DP name matching between IDP and CRLDP for security reason. 

Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHAb0Ch065603; Wed, 17 Nov 2004 02:37:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHAaxcj065592; Wed, 17 Nov 2004 02:36:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw ([202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHAauku065403 for <[e-mail]>; Wed, 17 Nov 2004 02:36:56 -0800 (PST) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAHAao15019778; Wed, 17 Nov 2004 18:36:50 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id iAHAan29002369; Wed, 17 Nov 2004 18:36:49 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAHAanZG002300; Wed, 17 Nov 2004 18:36:49 +0800
Message-ID: <01e301c4cc91$57a34aa0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "pkix" <[e-mail]>
Subject: 3280bis issue:  allow path/CRL validation relative to a time in the past
Date: Wed, 17 Nov 2004 18:36:48 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The current certification path validation algorithm and CRL
validation algorithm defined in RFC 3280 assume the validation
is relative to the current time. However, this does not align with
RFC 3379 and SCVP. In RFC 3379 and SCVP, the validation
can be relative to the current time and a time in the past. In
practice, a RP often need to validate a certification path relative
to a time in the past.
For example, when a RP receieves a digital signature, the
signing time must be a time in the past. In such situation,
the RP need to make sure the signer's certificate is valid
at the time the signature was signed.

I proposed to to change the input item "(b) the current date/time"
of section 6.1.1 into "(b) the validation time T, where T may be the
current time or a time in the past", and then replace all references
of "the current time" in the path and CRL validation algorithm with
"the validation time T".

With this simple modification, RFC 3280 can be a solid base of
 RFC 3379 and SCVP.

Wen-Cheng Wang




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHAb0it065613; Wed, 17 Nov 2004 02:37:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAHAaxYR065601; Wed, 17 Nov 2004 02:36:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw ([202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAHAavY9065469 for <[e-mail]>; Wed, 17 Nov 2004 02:36:58 -0800 (PST) (envelope-from [e-mail])
Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAHAaqjO019783; Wed, 17 Nov 2004 18:36:53 +0800
Received: (from root@localhost) by ms20.chttl.com.tw (8.12.10/8.12.10) id iAHAaqgl023366; Wed, 17 Nov 2004 18:36:52 +0800
Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAHAaqL1023297; Wed, 17 Nov 2004 18:36:52 +0800
Message-ID: <01e901c4cc91$593cd660$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "pkix" <[e-mail]>
Subject: 3280bis issue: to keep aligned with X.509 (2000) Technical Corrigendum 3
Date: Wed, 17 Nov 2004 18:36:51 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

ITU-T X.509 (2000) Technical Corrigendum 3 (X.509 TC 3)
had alreay come in force. In X.509 TC 3, a noticeable change
is the Issuing Distribution Point extension has now split into
two extensions, namely the Issuing Distribution Point (IDP)
extension and the AA Issuing Distribution Point (AA IDP)
extension.

In the new IDP extension, some of the field names has been
changed but the semantics are kept backward-compatible. In
addition, the onlyContainsAttributeCerts field has be removed
from the IDP extension, while the AA IDP extension take
the role to specify the CRL scope related to attribute authority
and attribute certificate.

Should the syntax of the IDP extension in RFC 3280 be modified
to keep aligned with X.509 (2000) TC 3?

Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH9SSDl014768; Wed, 17 Nov 2004 01:28:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAH9SSL0014765; Wed, 17 Nov 2004 01:28:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH9SRXH014626 for <[e-mail]>; Wed, 17 Nov 2004 01:28:27 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 09:28:17 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CC87.C5D51791"
Subject: RE: 3280bis: name constraints
Date: Wed, 17 Nov 2004 09:25:09 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3280bis: name constraints
Thread-Index: AcTMMAMpjNZtMRm+SR+RyZxi/uiAWAAB2EQgABOR0AA=
From: "Stefan Santesson" <[e-mail]>
To: "Manger, James H" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 17 Nov 2004 09:28:17.0625 (UTC) FILETIME=[C5506C90:01C4CC87]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4CC87.C5D51791
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It is not the end entity certificate that is valid or invalid in case of
a breach of name constraints. It is the path that is invalid.

=20

A CA certificate that contains a name constraints extension makes a
statement that this CA certificate is ONLY valid in a path if subsequent
certificates fall within these name boundaries.

=20

You may choose to trust the EE certificates anyway, but you can't use
that name constrained CA certificate as the means to do it.

You have to either.

=20

1) Directly trust the EE cert, or;

2) Find another path using another CA certificate.

=20

Since few applications have native support for path validation and
instead rely on toolkits to do the work, there is no means for the path
validation logic in the generic toolkit to do take into account what
name forms the application intends to make use of.=20

=20

Stefan Santesson=20
Microsoft Security Center of Excellence (SCOE)=20
 =20

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Manger, James H
Sent: den 17 november 2004 03:00
To: [e-mail]
Subject: RE: 3280bis: name constraints

=20

I agree with Terry -- having to reject a cert due to the presence of a
name (& name-constraint) of a type that you are going to completely
ignore is unnecessarily restrictive.  There is no attack that is
prevented by this rejection.  It just hinders the uptake of useful new
features as they can break backward compatibility.

=20

Consider a directory that strongly authenticates users.  It is only
interested in the user's DN.  It never does anything with email address,
URI, DNS etc.  Yet if it doesn't implement the rules for processing name
constraints on those names (which I believe have never been detailed in
X.509, only RFC 3280) then it cannot accept any cert chain that includes
(in addition to a DN) an email address, URI, DNS etc and an associated
constraint.

Similarly an email application that is only interested in email
addresses; a TLS proxy that is only interested in DNS names...

=20

The subjectAltName extension says any unrecognised or unsupported names
can be ignored (even if critical only one name from the extension needs
to be supported).  The nameConstraints extension basically contradicts
this by saying you can't actually ignore these names as they affect
whether the cert is acceptable or not.

=20

David Cooper's suggestion of issuing separate certs for each name form
that you want to constrain sounds ungainly.  Company A certifying
company B may well want to constrain directoryNames to "c=3DAU, =
o=3DCompany
B" and URIs, DNS names and email addresses to ".companyB.com.au".
Should it issue 1 cross-cert (with all constraints), 4 cross-certs to
the one company B CA, 4 cross-certs to 4 separate CA hierarchies in
company B...

=20

...but the problem lies with X.509's text & limitations for name
constraints .. so perhaps 3280bis cannot fix it.

=20

	=20

=09
________________________________


	From: [e-mail]
[mailto:[e-mail]] On Behalf Of David A. Cooper
	Sent: Wednesday, 17 November 2004 2:19 AM
	To: Terry Hayes
	Cc: [e-mail]
	Subject: Re: 3280bis: name constraints

	...
	my opinion, the answer to your concern is not to change the
semantics of name constraints, but to be careful in your use of name
constraints and alternative names.  At the moment, in the U.S. Federal
PKI, we only impose name constraints on the directoryName form and I
have not seen a compelling reason to impose constraints on other name
forms.
=09
	If you do feel the need to impose name constraints on some name
form for which many applications may not be able to process the
constraint, then I would suggest issuing separate certificates for the
application(s) that use that name form.  For example, if you have an
application that uses X.400 names and you feel the need to impose name
constraints on X.400 names, issue subscribers two certificates:  one
certificate with an X.400 name for use with the application that uses
the X.400 name (presumably this application can process the X.400 name
constraints) and a second certificate without an X.400 name.  If a CA
imposes a constraint on a particular name form, but no subsequent
certificate includes a subject name or subjectAltName of that form, then
there is no processing to be done so the application can accept the path
despite not being able to process constraints for that name form.
=09
	Terry Hayes wrote:
=09
=09

	In my opinion, a requirement such as this is too restrictive,
and will prevent additional capabilities from being added to a PKI.
	=20
	As long as an application never makes use of a particular name
form, it should be free to ignore constraints that apply to that name
form.  Notice that to do this, it must recognize and process the name
constraint extension as required by the extension processing rules.
	=20
	If applications are required to reject certificates paths with
constraints for name forms that they do not recognize, they will be
prevented from using certificates that have those name forms added to
them for other applications.  This will impede the use of certificates
for these new applications, since older clients will not be able to
function.
	=20
	Terry Hayes


------_=_NextPart_001_01C4CC87.C5D51791
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0cm;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body bgcolor=3Dwhite lang=3DDA link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>It is not the =
end entity
certificate that is valid or invalid in case of a breach of name =
constraints. It
is the path that is invalid.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>A CA certificate =
that
contains a name constraints extension makes a statement that this CA
certificate is ONLY valid in a path if subsequent certificates fall =
within
these name boundaries.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>You may choose =
to trust
the EE certificates anyway, but you can&#8217;t use that name =
constrained CA
certificate as the means to do it.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>You have to =
either.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>1) Directly =
trust the EE
cert, or;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>2) Find another =
path
using another CA certificate.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Since few =
applications
have native support for path validation and instead rely on toolkits to =
do the
work, there is no means for the path validation logic in the generic =
toolkit to
do take into account what name forms the application intends to make use =
of. </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></p>

<div>

<p><b><font size=3D2 color=3Dolive face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
 10.0pt;font-family:Arial;color:olive;font-weight:bold'>Stefan =
Santesson</span></font></b><font
color=3Dnavy><span lang=3DEN-GB style=3D'color:navy'> <br>
</span></font><font size=3D2 color=3Dolive face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Microsoft =
Security Center of Excellence (SCOE)</span></font><font =
color=3Dnavy><span lang=3DEN-GB
style=3D'color:navy'> <br>
</span></font><font color=3Dnavy face=3DArial><span lang=3DEN-GB =
style=3D'font-family:
Arial;color:navy'>&nbsp;</span></font><font color=3Dnavy><span =
lang=3DEN-GB
style=3D'color:navy'> </span></font></p>

</div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;
color:windowtext'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Tahoma;color:windowtext'> [e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Manger, James H<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 17 november =
2004 03:00<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: 3280bis: =
name
constraints</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I agree with Terry -- having to =
reject a
cert due to the presence of a name (&amp; name-constraint) of a type =
that you
are going to completely ignore is unnecessarily restrictive.&nbsp; There =
is no
attack that is prevented by this rejection.&nbsp; It just hinders the =
uptake of
useful new features as they can break backward =
compatibility.</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Consider a directory that strongly
authenticates users.&nbsp; It is only interested in the user's DN.&nbsp; =
It
never does anything with email address, URI, DNS etc.&nbsp; Yet if it =
doesn't
implement the rules for processing name constraints on those names =
(which I
believe have never been detailed in X.509, only RFC 3280) then it cannot =
accept
any cert chain that includes (in addition to a DN) an email address, =
URI, DNS
etc&nbsp;and an associated constraint.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Similarly an email application that =
is
only interested in email addresses; a TLS proxy that is only interested =
in DNS
names...</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>The subjectAltName extension says =
any
unrecognised or unsupported names can be ignored (even if critical
only&nbsp;one name from the extension needs to be supported).&nbsp; The
nameConstraints extension basically contradicts this by saying you can't
actually&nbsp;ignore these names as they affect whether the cert is =
acceptable
or not.</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>David Cooper's suggestion of =
issuing
separate certs for each name form that you want to constrain sounds
ungainly.&nbsp; Company A&nbsp;certifying company B may well want to =
constrain
directoryNames to &quot;c=3DAU, o=3DCompany B&quot; and URIs, DNS names
and&nbsp;email addresses to &quot;.companyB.com.au&quot;.&nbsp; Should =
it issue
1 cross-cert (with all constraints), 4 cross-certs to the&nbsp;one =
company B
CA, 4 cross-certs to 4 separate CA hierarchies in company =
B...</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>...but the problem lies with =
X.509's text
&amp; limitations&nbsp;for name constraints .. so perhaps 3280bis cannot =
fix
it.</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
color=3Dblack
face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma;
font-weight:bold'>From:</span></font></b><font size=3D2 =
face=3DTahoma><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>David A. Cooper<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, 17 =
November 2004
2:19 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Terry Hayes<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: 3280bis: =
name
constraints</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>...<br>
my opinion, the answer to your concern is not to change the semantics of =
name
constraints, but to be careful in your use of name constraints and =
alternative
names.&nbsp; At the moment, in the U.S. Federal PKI, we only impose name
constraints on the directoryName form and I have not seen a compelling =
reason
to impose constraints on other name forms.<br>
<br>
If you do feel the need to impose name constraints on some name form for =
which
many applications may not be able to process the constraint, then I =
would
suggest issuing separate certificates for the application(s) that use =
that name
form.&nbsp; For example, if you have an application that uses X.400 =
names and
you feel the need to impose name constraints on X.400 names, issue =
subscribers
two certificates:&nbsp; one certificate with an X.400 name for use with =
the
application that uses the X.400 name (presumably this application can =
process
the X.400 name constraints) and a second certificate without an X.400
name.&nbsp; If a CA imposes a constraint on a particular name form, but =
no subsequent
certificate includes a subject name or subjectAltName of that form, then =
there
is no processing to be done so the application can accept the path =
despite not
being able to process constraints for that name form.<br>
<br>
Terry Hayes wrote:<br>
<br>
</span></font></p>

<pre wrap=3D""><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>In my opinion, a requirement such as this is =
too restrictive, and will prevent additional capabilities from being =
added to a PKI.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>As long as an application never makes use of =
a particular name form, it should be free to ignore constraints that =
apply to that name form.&nbsp; Notice that to do this, it must recognize =
and process the name constraint extension as required by the extension =
processing rules.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>If applications are required to reject =
certificates paths with constraints for name forms that they do not =
recognize, they will be prevented from using certificates that have =
those name forms added to them for other applications.&nbsp; This will =
impede the use of certificates for these new applications, since older =
clients will not be able to function.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Terry Hayes</span></font></pre></blockquote>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C4CC87.C5D51791--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH218g6050856; Tue, 16 Nov 2004 18:01:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAH2188V050855; Tue, 16 Nov 2004 18:01:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailao.ntcif.telstra.com.au (mailao.ntcif.telstra.com.au [202.12.233.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH217xV050847 for <[e-mail]>; Tue, 16 Nov 2004 18:01:08 -0800 (PST) (envelope-from [e-mail])
Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailao.ntcif.telstra.com.au (Postfix) with ESMTP id 88B8915FA9 for <[e-mail]>; Wed, 17 Nov 2004 13:01:13 +1100 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 409DBFF84 for <[e-mail]>; Wed, 17 Nov 2004 13:01:13 +1100 (EST)
Received: from WSMSG0005.srv.dir.telstra.com (wsmsg0005.srv.dir.telstra.com [192.74.168.134]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA04995 for <[e-mail]>; Wed, 17 Nov 2004 13:01:12 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4CC49.22C066D0"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Subject: RE: 3280bis: name constraints
Date: Wed, 17 Nov 2004 12:59:56 +1100
Message-ID: <[e-mail]>
Thread-Topic: 3280bis: name constraints
Thread-Index: AcTMMAMpjNZtMRm+SR+RyZxi/uiAWAAB2EQg
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4CC49.22C066D0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

I agree with Terry -- having to reject a cert due to the presence of a
name (& name-constraint) of a type that you are going to completely
ignore is unnecessarily restrictive.  There is no attack that is
prevented by this rejection.  It just hinders the uptake of useful new
features as they can break backward compatibility.
=20
Consider a directory that strongly authenticates users.  It is only
interested in the user's DN.  It never does anything with email address,
URI, DNS etc.  Yet if it doesn't implement the rules for processing name
constraints on those names (which I believe have never been detailed in
X.509, only RFC 3280) then it cannot accept any cert chain that includes
(in addition to a DN) an email address, URI, DNS etc and an associated
constraint.
Similarly an email application that is only interested in email
addresses; a TLS proxy that is only interested in DNS names...
=20
The subjectAltName extension says any unrecognised or unsupported names
can be ignored (even if critical only one name from the extension needs
to be supported).  The nameConstraints extension basically contradicts
this by saying you can't actually ignore these names as they affect
whether the cert is acceptable or not.
=20
David Cooper's suggestion of issuing separate certs for each name form
that you want to constrain sounds ungainly.  Company A certifying
company B may well want to constrain directoryNames to "c=3DAU, =
o=3DCompany
B" and URIs, DNS names and email addresses to ".companyB.com.au".
Should it issue 1 cross-cert (with all constraints), 4 cross-certs to
the one company B CA, 4 cross-certs to 4 separate CA hierarchies in
company B...
=20
...but the problem lies with X.509's text & limitations for name
constraints .. so perhaps 3280bis cannot fix it.
=20



  _____ =20

From: [e-mail] [mailto:[e-mail]]
On Behalf Of David A. Cooper
Sent: Wednesday, 17 November 2004 2:19 AM
To: Terry Hayes
Cc: [e-mail]
Subject: Re: 3280bis: name constraints


...
my opinion, the answer to your concern is not to change the semantics of
name constraints, but to be careful in your use of name constraints and
alternative names.  At the moment, in the U.S. Federal PKI, we only
impose name constraints on the directoryName form and I have not seen a
compelling reason to impose constraints on other name forms.

If you do feel the need to impose name constraints on some name form for
which many applications may not be able to process the constraint, then
I would suggest issuing separate certificates for the application(s)
that use that name form.  For example, if you have an application that
uses X.400 names and you feel the need to impose name constraints on
X.400 names, issue subscribers two certificates:  one certificate with
an X.400 name for use with the application that uses the X.400 name
(presumably this application can process the X.400 name constraints) and
a second certificate without an X.400 name.  If a CA imposes a
constraint on a particular name form, but no subsequent certificate
includes a subject name or subjectAltName of that form, then there is no
processing to be done so the application can accept the path despite not
being able to process constraints for that name form.

Terry Hayes wrote:


In my opinion, a requirement such as this is too restrictive, and will
prevent additional capabilities from being added to a PKI.



As long as an application never makes use of a particular name form, it
should be free to ignore constraints that apply to that name form.
Notice that to do this, it must recognize and process the name
constraint extension as required by the extension processing rules.



If applications are required to reject certificates paths with
constraints for name forms that they do not recognize, they will be
prevented from using certificates that have those name forms added to
them for other applications.  This will impede the use of certificates
for these new applications, since older clients will not be able to
function.



Terry Hayes


------_=_NextPart_001_01C4CC49.22C066D0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE></TITLE>

<META content=3D"MSHTML 6.00.2800.1459" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D068555223-16112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I agree with Terry -- having to reject a cert =
due to the=20
presence of a name (&amp; name-constraint) of a type that you=20
</FONT></SPAN><SPAN class=3D068555223-16112004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>are going to completely ignore is unnecessarily =
restrictive.&nbsp;=20
</FONT></SPAN><SPAN class=3D068555223-16112004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>There is no attack that is prevented by this rejection.&nbsp; =
It just=20
hinders the uptake of useful new features as they can break backward=20
compatibility.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D068555223-16112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D068555223-16112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Consider a directory that strongly =
authenticates=20
users.&nbsp; It is only interested in the user's DN.&nbsp; It never does =

anything with email address, URI, DNS etc.&nbsp; Yet if it doesn't =
implement the=20
rules for processing name constraints on those names (which I believe =
have never=20
been detailed in X.509, only RFC 3280) then it cannot accept any cert =
chain that=20
includes </FONT></SPAN><SPAN class=3D068555223-16112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>(in addition to a DN) an email address, URI, =
DNS=20
etc&nbsp;and an associated constraint.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D068555223-16112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Similarly an email application that is only =
interested in=20
email addresses; a TLS proxy that is only interested in DNS=20
names...</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D068555223-16112004></SPAN><SPAN=20
class=3D068555223-16112004></SPAN><SPAN class=3D068555223-16112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D068555223-16112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>The subjectAltName extension says any =
unrecognised or=20
unsupported names can be ignored (even if critical only&nbsp;one name =
from the=20
extension needs to be supported).&nbsp; The nameConstraints extension =
basically=20
contradicts this by saying you can't actually&nbsp;ignore these names as =
they=20
affect whether the cert is acceptable or not.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D068555223-16112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D068555223-16112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>David Cooper's suggestion of issuing separate =
certs for=20
each name form that you want to constrain sounds ungainly.&nbsp;=20
</FONT></SPAN><FONT face=3DArial><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D068555223-16112004>Company A&nbsp;certifying company B may well =
want to=20
constrain directoryNames to "c=3DAU, o=3DCompany B" and URIs, DNS names=20
and&nbsp;email addresses to ".companyB.com.au".&nbsp; Should it issue 1=20
cross-cert (with all constraints), 4 cross-certs to the&nbsp;one company =
B CA, 4=20
cross-certs to 4 separate CA hierarchies in company=20
B...</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D068555223-16112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D068555223-16112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>...but the problem lies with X.509's text &amp; =

limitations&nbsp;for name constraints .. so perhaps 3280bis cannot fix=20
it.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D068555223-16112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><BR>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =

  [mailto:[e-mail]] <B>On Behalf Of </B>David A.=20
  Cooper<BR><B>Sent:</B> Wednesday, 17 November 2004 2:19 =
AM<BR><B>To:</B> Terry=20
  Hayes<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> Re: 3280bis: =
name=20
  constraints<BR></FONT><BR></DIV>
  <DIV></DIV>...<BR>my opinion, the answer to your concern is not to =
change the=20
  semantics of name constraints, but to be careful in your use of name=20
  constraints and alternative names.&nbsp; At the moment, in the U.S. =
Federal=20
  PKI, we only impose name constraints on the directoryName form and I =
have not=20
  seen a compelling reason to impose constraints on other name =
forms.<BR><BR>If=20
  you do feel the need to impose name constraints on some name form for =
which=20
  many applications may not be able to process the constraint, then I =
would=20
  suggest issuing separate certificates for the application(s) that use =
that=20
  name form.&nbsp; For example, if you have an application that uses =
X.400 names=20
  and you feel the need to impose name constraints on X.400 names, issue =

  subscribers two certificates:&nbsp; one certificate with an X.400 name =
for use=20
  with the application that uses the X.400 name (presumably this =
application can=20
  process the X.400 name constraints) and a second certificate without =
an X.400=20
  name.&nbsp; If a CA imposes a constraint on a particular name form, =
but no=20
  subsequent certificate includes a subject name or subjectAltName of =
that form,=20
  then there is no processing to be done so the application can accept =
the path=20
  despite not being able to process constraints for that name =
form.<BR><BR>Terry=20
  Hayes wrote:<BR>
  <BLOCKQUOTE cite=[e-mail] type=3D"cite"><PRE =
wrap=3D"">In my opinion, a requirement such as this is too restrictive, =
and will prevent additional capabilities from being added to a PKI.

As long as an application never makes use of a particular name form, it =
should be free to ignore constraints that apply to that name form.  =
Notice that to do this, it must recognize and process the name =
constraint extension as required by the extension processing rules.

If applications are required to reject certificates paths with =
constraints for name forms that they do not recognize, they will be =
prevented from using certificates that have those name forms added to =
them for other applications.  This will impede the use of certificates =
for these new applications, since older clients will not be able to =
function.

Terry Hayes
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4CC49.22C066D0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH1mL8a045833; Tue, 16 Nov 2004 17:48:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAH1mLot045832; Tue, 16 Nov 2004 17:48:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw ([202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH1mEM3045661 for <[e-mail]>; Tue, 16 Nov 2004 17:48:16 -0800 (PST) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAH1lhgx009365; Wed, 17 Nov 2004 09:47:43 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id iAH1lh81032209; Wed, 17 Nov 2004 09:47:43 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAH1lgZG032066; Wed, 17 Nov 2004 09:47:42 +0800
Message-ID: <006901c4cc47$6d4c2e70$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Manuel Gil Perez" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <005401c4c81b$99f48e70$[e-mail]> <012201c4c85e$852b3960$4f85900a@wcwang> <003401c4cc15$58f7a260$[e-mail]>
Subject: Re: Bridge CA and crossCertificatePair
Date: Wed, 17 Nov 2004 09:47:41 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Manuel,

You misinterpret the meaning of a multi-valued
attribute.

I am sure that by "a multi-valued attribute"
it means that one can store multiple values
in a single attribute. I recommend you to
read the LDAP spec.

Wen-Cheng Wang

----- Original Message ----- 
From: "Manuel Gil Perez" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>; <[e-mail]>
Sent: Wednesday, November 17, 2004 3:47 AM
Subject: Re: Bridge CA and crossCertificatePair


> Wen-Cheng...
>
> In line...
>
> ----- Original Message ----- 
> Sent: Friday, November 12, 2004 3:22 AM
> Subject: Re: Bridge CA and crossCertificatePair
>
>
> > Pérez,
> >
> > The syntax need not to be changed.
>
> Agree.
>
> > The crossCertificatePair is a multi-valued attribute.
> > That means you can store multiple CertificatePair
> > objects in a crossCertificatePair attribute.
>
> I think that your comment isn't correct. "The crossCertificatePair is a
> multi-valued attribute"... perfect, but you can only store a CertificatePair
> in a crossCertificatePair attribute. This crossCertificatePair attribute can
> appear zero, one or more times in the pkiCA entry.
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH1S8ok036930; Tue, 16 Nov 2004 17:28:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAH1S88f036929; Tue, 16 Nov 2004 17:28:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailao.ntcif.telstra.com.au (mailao.ntcif.telstra.com.au [202.12.233.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH1S7jq036846 for <[e-mail]>; Tue, 16 Nov 2004 17:28:07 -0800 (PST) (envelope-from [e-mail])
Received: from mailbi.ntcif.telstra.com.au (mailbi.ntcif.telstra.com.au [202.12.162.19]) by mailao.ntcif.telstra.com.au (Postfix) with ESMTP id 23E0415F77; Wed, 17 Nov 2004 12:28:04 +1100 (EST)
Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id C5603FF82; Wed, 17 Nov 2004 12:28:03 +1100 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 9032641EC7; Wed, 17 Nov 2004 12:28:03 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Subject: 3280bis: DNS name constraints
Date: Wed, 17 Nov 2004 12:26:39 +1100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3280bis: DNS name constraints
Thread-Index: AcTMMAMpjNZtMRm+SR+RyZxi/uiAWAAE+TUg
From: "Manger, James H" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAH1S8jq036924
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Shouldn't the DNS name constraint use the same rules as for host part of
URIs and email addresses?
For DNS names, RFC 3280 says "simply adding to the left hand side of the
name satisfies the name constraint" [4.2.1.11, page 38].  This implies a
constraint of "foo.bar.com" is satisfied by "myfoo.bar.com" -- which
must be an error.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH0PY7o010667; Tue, 16 Nov 2004 16:25:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAH0PYDL010666; Tue, 16 Nov 2004 16:25:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAH0PXvi010584 for <[e-mail]>; Tue, 16 Nov 2004 16:25:33 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Nov 2004 00:25:18 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: 3280bis: name constraints
Date: Wed, 17 Nov 2004 00:25:23 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3280bis: name constraints
Thread-Index: AcTMLOZ7gxmnJXkJT066pwbOI+1oUQADF7kQ
From: "Stefan Santesson" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "Terry Hayes" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 17 Nov 2004 00:25:18.0793 (UTC) FILETIME=[EAD12B90:01C4CC3B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAH0PYvi010661
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

First I would suggest that this whole discussion of criticality is invalid in the context of name constraints and rfc 3280

1. RFC 3280 requires that the name constraints extension MUST be critical (take a look at end of 3rd paragraph in section 4.2.1.11  Name Constraints)

2. RFC 3280 path validation requires the path validation software to understand and process name constraints.

So, any implementation that does not process name constraints is by definition NOT compliant with RFC 3280.

Further....

I totally agree with David that the current defined name comparison rules are not logical and do not follow the subtree principle (i.e. to allow all descendent entries but not parallel entries. This is also the case for the concept that xyz.com should be limited to the host (i.e. that [e-mail] is a violation of xyz.com. In my mind, [e-mail] is a perfectly valid subtree of xyz.com. The standard is thus not logical in this aspect.

Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 
  
________________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of David A. Cooper
Sent: den 16 november 2004 16:19
To: Terry Hayes
Cc: [e-mail]
Subject: Re: 3280bis: name constraints

Terry,

Even if I agreed with you that name constraints should work as you describe, there would still be a couple of problems.  First, this would be a change from RFC 3280, which is probably outside the scope for changes that we are allowed to make in 3280bis.  Second, this would make 3280bis inconsistent with X.509, which is certainly not something we can do, since 3280bis is a profile of X.509.

X.509 states (among other things):
If excludedSubtrees is present, any certificate issued by the subject CA or subsequent CAs in the certification path that has a subject name within these subtrees is unacceptable.
If the [nameConstraints] extension is present and is flagged critical, a certificate-using implementation must recognize and process all name forms for which there is both a subtree specification (permitted or excluded) in the extension and a corresponding value in the subject field or subjectAltNames extension of any subsequent certificate in the certification path. If an unrecognized name form appears in both a subtree specification and a subsequent certificate, that certificate shall be handled as if an unrecognized critical extension was encountered. If any subject name in the certificate falls within an excluded subtree, the certificate is unacceptable.
X.509 is quite clear that if a certificate includes a name that falls within an excludedSubtree or does not fall within any permittedSubtree, then the certificate is unacceptable not just the name.  In order for a certificate to be acceptable, all names must satisfy name constraints, not just the name(s) that is of interest to the application.  If the nameConstraints extension is critical and the application can not process one or more of the constraints, then it must reject the certification path since it is unable to verify that the name constraints have been satisfied.

In my opinion, the answer to your concern is not to change the semantics of name constraints, but to be careful in your use of name constraints and alternative names.  At the moment, in the U.S. Federal PKI, we only impose name constraints on the directoryName form and I have not seen a compelling reason to impose constraints on other name forms.

If you do feel the need to impose name constraints on some name form for which many applications may not be able to process the constraint, then I would suggest issuing separate certificates for the application(s) that use that name form.  For example, if you have an application that uses X.400 names and you feel the need to impose name constraints on X.400 names, issue subscribers two certificates:  one certificate with an X.400 name for use with the application that uses the X.400 name (presumably this application can process the X.400 name constraints) and a second certificate without an X.400 name.  If a CA imposes a constraint on a particular name form, but no subsequent certificate includes a subject name or subjectAltName of that form, then there is no processing to be done so the application can accept the path despite not being able to process constraints for that name form.

There is another option:  the nameConstraints extension could be marked non-critical.  X.509 states:
If the [nameConstraints] extension is present and is flagged non-critical and a certificate-using implementation does not recognize a name form used in any base component, then that subtree specification may be ignored.
Granted, RFC 3280 states that the nameConstraints extension MUST be critical, but if there were sufficient interest in changing this in 3280bis to state that the extension can be set to either critical or non-critical, I would be willing to support that.

Dave


Terry Hayes wrote:

In my opinion, a requirement such as this is too restrictive, and will prevent additional capabilities from being added to a PKI.

As long as an application never makes use of a particular name form, it should be free to ignore constraints that apply to that name form.  Notice that to do this, it must recognize and process the name constraint extension as required by the extension processing rules.

If applications are required to reject certificates paths with constraints for name forms that they do not recognize, they will be prevented from using certificates that have those name forms added to them for other applications.  This will impede the use of certificates for these new applications, since older clients will not be able to function.

Terry Hayes


David A. Cooper wrote on 11/15/2004, 2:08 PM:
  

X.509 does have a rule that one must reject a critical extension unless 
you can process all of the fields in the extension. So, for name 
constraints, if a critical nameConstraints extension includes a 
constraint on a name form and that name form appears in the subject 
field or subjectAltName extension of a subsequent certificate, then path 
must be rejected.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJodmE068846; Tue, 16 Nov 2004 11:50:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJodLd068845; Tue, 16 Nov 2004 11:50:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJocEX068758 for <[e-mail]>; Tue, 16 Nov 2004 11:50:38 -0800 (PST) (envelope-from [e-mail])
Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D416331408 for <[e-mail]>; Tue, 16 Nov 2004 20:50:35 +0100 (CET)
Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with SMTP id B67FD313FB for <[e-mail]>; Tue, 16 Nov 2004 20:50:35 +0100 (CET)
Received: (qmail 12240 invoked from network); 16 Nov 2004 19:50:00 -0000
Received: from ycaro.dif.um.es (HELO ycaro) (155.54.210.68) by aries.dif.um.es with SMTP; 16 Nov 2004 19:50:00 -0000
Message-ID: <003501c4cc15$89ee6ca0$[e-mail]>
Reply-To: "Manuel Gil Perez" <[e-mail]>
From: "Manuel Gil Perez" <[e-mail]>
To: "Matt Cooper" <[e-mail]>, "'Tom Gindin'" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Bridge CA and crossCertificatePair
Date: Tue, 16 Nov 2004 20:50:34 +0100
Organization: ANTS Research Group
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Many thanks to all.

Now, I understand how these attributes are managed. In the doc it's not very 
precise.

Thanks.

------
Manuel Gil Pérez


----- Original Message ----- 
Sent: Friday, November 12, 2004 3:01 PM
Subject: RE: Bridge CA and crossCertificatePair


>
>
> Quite right Tom, it is definitely multivalued.  If it was inferred that it
> was not in the doc, it was in error.  Thanks for pointing this out, we'll
> look at it.
>
> And Manuel, to expand on what Tom's message, the encoding spec you
> originally found is correct. The encoding should be a single pair of
> certificates. As Tom said, since crossCertificatePair is multivalued, you
> simply store as many encoded pairs as you need in the directory.  It's 
> just
> like certificates; the ASN.1 spec is only for one certificate; and you may
> store as many as you need in the directory.
>
> Incidentally, the reason crossCertificatePair is done this way is so that
> related cross certificates may be associated. In other words, if we are 
> CAs
> and I were to issue you a certificate and you were to issue me a
> certificate, we would put these two certificates together as a pair in our
> respective crossCertificatePair entries.
>
>
> Matt Cooper
> Orion Security Solutions
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> (Mob) 703.981.2269
> (Off) 703.917.0060 x. 30
> (Fax) 703.917.0260
> Visit our website!
> http://www.orionsec.com
>
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On
> Behalf Of Tom Gindin
> Sent: Friday, November 12, 2004 12:09 AM
> To: Manuel Gil Perez; Matt Cooper
> Cc: [e-mail]
> Subject: Re: Bridge CA and crossCertificatePair
>
>
>        Manuel:
>
>        CrossCertificatePair has AFAIK always been considered to be a
> multi-valued attribute, as you can see from (for example) RFC 2587 section
> 3.2 where the existence of multiple CA Certificates in the caCertificate
> attribute and of multiple 'forward' elements in the crossCertificatePair
> attribute is discussed in consecutive paragraphs.  However, the
> certpathbuild draft lists userCertificate and caCertificate as 
> multi-valued
> but doesn't make that statement about CrossCertificatePair.
> It should probably change to do so, unless it's too late in the process.
>        Please note that the syntax of caCertificate is just a certificate,
> not a sequence of them.
>
>                Tom Gindin
>
>
>
>
>
>
> "Manuel Gil Perez" <[e-mail]>
> Sent by: [e-mail]
> 11/11/2004 01:23 PM
> Please respond to "Manuel Gil Perez"
>
>        To:     <[e-mail]>
>        cc:
>        Subject:        Bridge CA and crossCertificatePair
>
>
>
> Dear PKIX members,
>
> I need to develop a bridge CA where it must store one or more
> cross-certificates. Revising the RFCs (about LDAP, X.509, etc.) and 
> looking
> up on the web I conclude that it is technically possible (in accordance 
> with
> RFC 3280) to store one or more cross-certificate into my bridge CA (this
> value is multi-valued).
>
> But really, according to the specification (see below), I can only store 
> one
> pair of cross-certificates. Is it possible that the attribute
> CertificatePair is not correct and should be changed for the following??
>
> CertificatePair ::= SEQUENCE SIZE(1..MAX) OF CertificateForwardReverse;
>
> CertificateForwardReverse ::= SEQUENCE {
>   forward [0] Certificate OPTIONAL,
>   reverse [1] Certificate OPTIONAL,
>   -- at least one of the pair shall be present -- }
>
> In any case... can somebody send me the correct specification for the
> attribute CertificatePair??
>
> Many thanks, and best regards...
>
> ------
> Manuel Gil Pérez
> http://pki.umu.euro6ix.org
>
>
> ======
>
> pkiCA OBJECT-CLASS ::= {
>   SUBCLASS OF { top}
>   KIND auxiliary
>   MAY CONTAIN {
>      cACertificate |
>      certificateRevocationList |
>      authorityRevocationList |
>      crossCertificatePair }
>   ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22) }
>
> crossCertificatePair ATTRIBUTE ::= {
>   WITH SYNTAX CertificatePair
>   EQUALITY MATCHING RULE certificatePairExactMatch
>    ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40) }
>
> CertificatePair ::= SEQUENCE {
>   forward [0] Certificate OPTIONAL,
>   reverse [1] Certificate OPTIONAL,
>   -- at least one of the pair shall be present -- }
>
>
>
>
>
>
>
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJnIDa068011; Tue, 16 Nov 2004 11:49:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJnIGU068010; Tue, 16 Nov 2004 11:49:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJnHWN067921 for <[e-mail]>; Tue, 16 Nov 2004 11:49:17 -0800 (PST) (envelope-from [e-mail])
Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6FF54313FB for <[e-mail]>; Tue, 16 Nov 2004 20:49:14 +0100 (CET)
Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with SMTP id 509DF313E8 for <[e-mail]>; Tue, 16 Nov 2004 20:49:14 +0100 (CET)
Received: (qmail 12216 invoked from network); 16 Nov 2004 19:48:38 -0000
Received: from ycaro.dif.um.es (HELO ycaro) (155.54.210.68) by aries.dif.um.es with SMTP; 16 Nov 2004 19:48:38 -0000
Message-ID: <003401c4cc15$58f7a260$[e-mail]>
Reply-To: "Manuel Gil Perez" <[e-mail]>
From: "Manuel Gil Perez" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <005401c4c81b$99f48e70$[e-mail]> <012201c4c85e$852b3960$4f85900a@wcwang>
Subject: Re: Bridge CA and crossCertificatePair
Date: Tue, 16 Nov 2004 20:47:59 +0100
Organization: ANTS Research Group
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wen-Cheng...

In line...

----- Original Message ----- 
Sent: Friday, November 12, 2004 3:22 AM
Subject: Re: Bridge CA and crossCertificatePair


> Pérez,
>
> The syntax need not to be changed.

Agree.

> The crossCertificatePair is a multi-valued attribute.
> That means you can store multiple CertificatePair
> objects in a crossCertificatePair attribute.

I think that your comment isn't correct. "The crossCertificatePair is a 
multi-valued attribute"... perfect, but you can only store a CertificatePair 
in a crossCertificatePair attribute. This crossCertificatePair attribute can 
appear zero, one or more times in the pkiCA entry.

Regards.

> Wen-Cheng Wang
>
> ----- Original Message ----- 
> Sent: Friday, November 12, 2004 2:23 AM
> Subject: Bridge CA and crossCertificatePair
>>
>> Dear PKIX members,
>>
>> I need to develop a bridge CA where it must store one or more
>> cross-certificates. Revising the RFCs (about LDAP, X.509, etc.) and 
>> looking
>> up on the web I conclude that it is technically possible (in accordance 
>> with
>> RFC 3280) to store one or more cross-certificate into my bridge CA (this
>> value is multi-valued).
>>
>> But really, according to the specification (see below), I can only store 
>> one
>> pair of cross-certificates. Is it possible that the attribute
>> CertificatePair is not correct and should be changed for the following??
>>
>> CertificatePair ::= SEQUENCE SIZE(1..MAX) OF CertificateForwardReverse;
>>
>> CertificateForwardReverse ::= SEQUENCE {
>>    forward [0] Certificate OPTIONAL,
>>    reverse [1] Certificate OPTIONAL,
>>    -- at least one of the pair shall be present -- }
>>
>> In any case... can somebody send me the correct specification for the
>> attribute CertificatePair??
>>
>> Many thanks, and best regards...
>>
>> ------
>> Manuel Gil Pérez
>> http://pki.umu.euro6ix.org
>>
>>
>> ======
>>
>> pkiCA OBJECT-CLASS ::= {
>>    SUBCLASS OF { top}
>>    KIND auxiliary
>>    MAY CONTAIN {
>>       cACertificate |
>>       certificateRevocationList |
>>       authorityRevocationList |
>>       crossCertificatePair }
>>    ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22) }
>>
>> crossCertificatePair ATTRIBUTE ::= {
>>    WITH SYNTAX CertificatePair
>>    EQUALITY MATCHING RULE certificatePairExactMatch
>>     ID joint-iso-ccitt(2) ds(5) attributeType(4) 
>> crossCertificatePair(40) }
>>
>> CertificatePair ::= SEQUENCE {
>>    forward [0] Certificate OPTIONAL,
>>    reverse [1] Certificate OPTIONAL,
>>    -- at least one of the pair shall be present -- } 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTYZ1055902; Tue, 16 Nov 2004 11:29:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTYqt055901; Tue, 16 Nov 2004 11:29:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTWoI055794 for <[e-mail]>; Tue, 16 Nov 2004 11:29:33 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25878 invoked by uid 1365); 16 Nov 2004 19:27:52 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:06 2004
Received: (qmail 24731 invoked from network); 16 Nov 2004 19:21:06 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:06 +0000
Received: (qmail 20189 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 26347 invoked by uid 1114); 15 Nov 2004 04:20:07 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 04:20:04 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF3k1gO093208; Sun, 14 Nov 2004 19:46:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAF3k1HK093207; Sun, 14 Nov 2004 19:46:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailao.ntcif.telstra.com.au (mailao.ntcif.telstra.com.au [202.12.233.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF3k0LM093196 for <[e-mail]>; Sun, 14 Nov 2004 19:46:00 -0800 (PST) (envelope-from [e-mail])
Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailao.ntcif.telstra.com.au (Postfix) with ESMTP id 03AE712B34; Mon, 15 Nov 2004 14:45:56 +1100 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 9A811FF85; Mon, 15 Nov 2004 14:45:56 +1100 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA01582; Mon, 15 Nov 2004 14:45:56 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Subject: RE: 3280bis: indirectCRL boolean in IDP (3/3)
Date: Mon, 15 Nov 2004 14:44:42 +1100
Message-ID: <[e-mail]>
Thread-Topic: 3280bis: indirectCRL boolean in IDP (3/3)
Thread-Index: AcTJl2Gx9laDRMh2Q0a9n1CX4TXQ4gBKvZgw
From: "Manger, James H" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>, "pkix" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAF3k1LM093202
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The indirectCRL field should not be redefined.
CRL issuers do issue certificates if they are also CAs (as they often
are).
The indirectCRL field does not only indicate a "type b) indirect CRL" --
it must also be set to true for a "type a) indirect CRL".

Proposed action: don't accept Denis's proposed correction or proposed
note.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Denis Pinkas
Sent: Sunday, 14 November 2004 1:00 AM
To: [e-mail]
Cc: pkix
Subject: 3280bis: indirectCRL boolean in IDP (3/3)


3280bis: indirectCRL boolean in IDP (3/3)

This is a change and an addition proposal related to indirect CRLs.

>From section 5.2.5 Issuing Distribution Point, "the CRL issuer MUST
assert the indirectCRL boolean, if the scope of the CRL includes
certificates issued by authorities other than the CRL issuer".

This sentence is incorrect since CRL issuers do not issue certificates.


Proposed correction: 

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of the
CRL includes certificate identifiers from multiple authorities"
 
This boolean indicates a type b) indirect CRL but is named indirectCRL
boolean which is confusing with type a) indirect CRLs.

A note should be mentioned to clarify the ambiguity of the naming.

Proposed note: 

"The name of the boolean "indirectCRL" designates an indirect CRL that
includes certificate identifiers from multiple authorities, and not an
indirect CRL that includes certificate identifiers from a single CA.
An alternative name for that boolean would be: multipleCAs."

Denis





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTWqB055874; Tue, 16 Nov 2004 11:29:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTWoX055873; Tue, 16 Nov 2004 11:29:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTUU9055775 for <[e-mail]>; Tue, 16 Nov 2004 11:29:31 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25875 invoked by uid 1365); 16 Nov 2004 19:27:52 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:57 2004
Received: (qmail 24344 invoked from network); 16 Nov 2004 19:20:57 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:57 +0000
Received: (qmail 19997 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 1500 invoked by uid 1114); 15 Nov 2004 23:59:15 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 23:59:13 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFNjZvo051702; Mon, 15 Nov 2004 15:45:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFNjZ7Z051701; Mon, 15 Nov 2004 15:45:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imo-m22.mx.aol.com (imo-m22.mx.aol.com [64.12.137.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFNjWdB051637 for <[e-mail]>; Mon, 15 Nov 2004 15:45:34 -0800 (PST) (envelope-from [e-mail])
Received: from [e-mail] by imo-m22.mx.aol.com (mail_out_v37_r3.8.) id n.1eb.2de090ac (16109); Mon, 15 Nov 2004 18:45:28 -0500 (EST)
Received: from  pc655301.ad.aol.aoltw.net (h-10-169-155-109.nscp.aoltw.net [10.169.155.109]) by air-id12.mx.aol.com (v103.7) with ESMTP id MAILINID121-3eed41993f9673; Mon, 15 Nov 2004 18:45:27 -0500
Date: Mon, 15 Nov 2004 15:45:25 -0800
From: "Terry Hayes" <[e-mail]>
Subject: Re: 3280bis: name constraints
To: "David A. Cooper" <[e-mail]>, "Stephen Henson" <[e-mail]>
cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-Mailer: AOL Fanfare (20040831Branch.4205.162 Win)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-AOL-IP: 10.169.155.109
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS,RATWR10_MESSID
X-Comodo-Spam-Score: -3.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In my opinion, a requirement such as this is too restrictive, and will prevent additional capabilities from being added to a PKI.

As long as an application never makes use of a particular name form, it should be free to ignore constraints that apply to that name form.  Notice that to do this, it must recognize and process the name constraint extension as required by the extension processing rules.

If applications are required to reject certificates paths with constraints for name forms that they do not recognize, they will be prevented from using certificates that have those name forms added to them for other applications.  This will impede the use of certificates for these new applications, since older clients will not be able to function.

Terry Hayes


David A. Cooper wrote on 11/15/2004, 2:08 PM:
> 
> 
> X.509 does have a rule that one must reject a critical extension unless 
> you can process all of the fields in the extension. So, for name 
> constraints, if a critical nameConstraints extension includes a 
> constraint on a name form and that name form appears in the subject 
> field or subjectAltName extension of a subsequent certificate, then path 
> must be rejected.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTWb8055872; Tue, 16 Nov 2004 11:29:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTWYD055871; Tue, 16 Nov 2004 11:29:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTUjV055783 for <[e-mail]>; Tue, 16 Nov 2004 11:29:31 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25887 invoked by uid 1365); 16 Nov 2004 19:27:52 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:57 2004
Received: (qmail 24356 invoked from network); 16 Nov 2004 19:20:57 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:57 +0000
Received: (qmail 20117 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 15807 invoked by uid 1114); 11 Nov 2004 14:15:55 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Thu, 11 Nov 2004 14:15:51 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABDrs6Q026634; Thu, 11 Nov 2004 05:53:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iABDrshT026633; Thu, 11 Nov 2004 05:53:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABDrrJl026621 for <[e-mail]>; Thu, 11 Nov 2004 05:53:54 -0800 (PST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Thu, 11 Nov 2004 08:55:42 -0500
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002A_01C4C7CB.F685AA20"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Briefing on CRL Path for IETF PKIX WG Meeting
Thread-Index: AcTH7KNeloV37Xs7TJmzBRT6D5vBWQAARe/g
From: "Dave Engberg" <[e-mail]>
To: <[e-mail]>
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00,HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TITLE_EMPTY,TW_PK
X-Comodo-Spam-Score: -4.5
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01C4C7CB.F685AA20
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_002B_01C4C7CB.F685AA20"


------=_NextPart_001_002B_01C4C7CB.F685AA20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 
I think that there is a confusion between the logical identity of a CA and
the provable denotation of its certificates. 
 
For a PKI administrator, it may be philosophically correct to say that the
CA is defined by its name alone.  Of course, it is not useful (or even
correct?) to say that every X.509 certificate with the same subject Name
denotes the same CA.  For relying parties, Name equality is a necessary but
not sufficient requirement for determining whether two certs refer to the
same entity.
 
For relying party processing, I think that it is more useful to consider a
CA to be a an entity with a single Name and one or more Public Keys.  For a
relying party:
 
* Two certs with the same subject Name and Public Key always denote the same
entity.
 
* Two certs with different subject Names always denote different entities.
 
* Two certs with the same subject Name and different Public Keys denote the
same entity if and only if a trusted path can be found to both according to
Santosh's algorithm.
 
 
Of course, all this talk about theoretical CA identity for CRL processing
has obscured Santosh's original recommendation that if you care at all about
interoperability, your CA should always sign a CRL with the same key used to
sign any certs holding that CRL's distributionPoint URI.  The confusion on
this list makes it seem like this recommendation should be repeated.
 
(In fact, if the goal of the spec was interoperability, I'd make Santosh's
recommendation mandatory instead of hoping that all COTS PKI apps will
implement all these baroque discovery and validation edge cases.  The value
of this alternate-key CRL signing is pretty low compared to the complexity
it introduces for relying parties ...)
 


  _____  

From: [e-mail] [mailto:[e-mail]] On
Behalf Of David A. Cooper
Sent: Wednesday, November 10, 2004 9:34 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting


Denis,

X.509 states:


NOTE 1 - Although the CAs are unambiguously defined by a distinguished name
in the DIT, this does not imply that there is any relationship between the
organization of the CAs and the DIT.


Where in X.509 does it say or even imply that a CA in not defined by name
alone, but that a name is always relative to the CA which has issued it?  I
can't find anything in X.509 to support this.  On the other hand, there is
plenty to support the notion a CA is defined by name alone.  In addition to
the above quote, note that the cRLDistributionPoints extension identifies an
indirect CRL issuer by name alone as does the certificateIssuer CRL entry
extension.  This makes sense if a CA can be identified by name alone but
does not make sense if a CA name is only relative to the CA which has issued
it.  Similarly, in many protocols, a certificate is identified by issuer
name and serial number.  These two pieces of information would not be
sufficient to identify a certificate if your interpretation were correct.

 ...
 
Dave


Denis Pinkas wrote: 

Slide 5. The statement " A CA is defined by name alone" is 
wrong. A CA is not simply defined by a name alone. A name, 
for X.509, is always relative to the CA which has issued it. 
So the "clarification' to say that a CA is unambiguously 
defined by name is wrong. Then since the other slides are 
based on that wrong assumption, they are wrong as well. 

 ... 


------=_NextPart_001_002B_01C4C7CB.F685AA20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV><FONT face=3DArial=20
color=3D#0000ff size=3D2><SPAN class=3D365335512-11112004>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>I think that there is a confusion between the =
logical=20
identity of a CA and the provable denotation of its certificates.=20
</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>For a PKI administrator, it may be =
philosophically=20
correct to say that the CA&nbsp;is defined by its name alone.&nbsp; Of =
course,=20
it is not useful (or even correct?) to say that every X.509 certificate =
with the=20
same subject Name denotes the same CA.&nbsp; </SPAN></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2><SPAN class=3D365335512-11112004>For relying =
parties, Name=20
equality is a necessary but not sufficient requirement for determining =
whether=20
two certs refer to the same entity.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>For relying party processing, I =
think&nbsp;that it is=20
more useful to consider a CA to be a an entity with a single Name and =
one or=20
more Public Keys.&nbsp; For a relying party:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>* Two certs with the same subject Name and =
Public Key=20
always denote the same entity.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>* Two certs with different subject Names =
always denote=20
different entities.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><SPAN class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>* Two certs with the same subject Name and =
different=20
Public Keys denote the same entity if and only if&nbsp;a trusted path =
can be=20
found to both according to Santosh's algorithm.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>Of course, all this talk about theoretical=20
CA&nbsp;identity for CRL processing has obscured Santosh's original=20
recommendation that if you care at all about interoperability, your CA =
should=20
always sign a CRL with the same key used to sign any certs holding that =
CRL's=20
distributionPoint URI.&nbsp; The confusion on this list makes it seem =
like this=20
recommendation should be repeated.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>(In fact, if the goal of the spec was =
interoperability,=20
I'd make Santosh's recommendation mandatory instead of hoping that all =
COTS PKI=20
apps will implement all these baroque discovery and validation edge =
cases.&nbsp;=20
The value of this&nbsp;alternate-key CRL signing is pretty low compared =
to the=20
complexity it introduces for relying parties ...)</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><SPAN class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><BR></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>David A.=20
Cooper<BR><B>Sent:</B> Wednesday, November 10, 2004 9:34 =
PM<BR><B>To:</B> Denis=20
Pinkas<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> Re: Briefing =
on CRL=20
Path for IETF PKIX WG Meeting<BR></FONT><BR></DIV>
<DIV></DIV>Denis,<BR><BR>X.509 states:<BR>
<BLOCKQUOTE>NOTE 1 - Although the CAs are unambiguously defined by a=20
  distinguished name in the DIT, this does not imply that there is any=20
  relationship between the organization of the CAs and the =
DIT.<BR></BLOCKQUOTE>
<DIV>Where in X.509 does it say or even imply that a CA in not defined =
by name=20
alone, but that a name is always relative to the CA which has issued =
it?&nbsp; I=20
can't find anything in X.509 to support this.&nbsp; On the other hand, =
there is=20
plenty to support the notion a CA is defined by name alone.&nbsp; In =
addition to=20
the above quote, note that the cRLDistributionPoints extension =
identifies an=20
indirect CRL issuer by name alone as does the certificateIssuer CRL =
entry=20
extension.&nbsp; This makes sense if a CA can be identified by name =
alone but=20
does not make sense if a CA name is only relative to the CA which has =
issued=20
it.&nbsp; Similarly, in many protocols, a certificate is identified by =
issuer=20
name and serial number.&nbsp; These two pieces of information would not =
be=20
sufficient to identify a certificate if your interpretation were=20
correct.<BR><BR><SPAN class=3D365335512-11112004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;...</FONT></SPAN></DIV>
<DIV><SPAN =
class=3D365335512-11112004>&nbsp;</SPAN><BR>Dave<BR><BR><BR>Denis=20
Pinkas wrote: </DIV>
<BLOCKQUOTE cite=[e-mail] type=3D"cite">Slide 5. =
The=20
  statement " A CA is defined by name alone" is <BR>wrong. A CA is not =
simply=20
  defined by a name alone. A name, <BR>for X.509, is always relative to =
the CA=20
  which has issued it. <BR>So the "clarification' to say that a CA is=20
  unambiguously <BR>defined by name is wrong. Then since the other =
slides are=20
  <BR>based on that wrong assumption, they are wrong as =
well.&nbsp;<BR><BR><SPAN=20
  class=3D365335512-11112004><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;...&nbsp;</FONT></SPAN></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_002B_01C4C7CB.F685AA20--

------=_NextPart_000_002A_01C4C7CB.F685AA20
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII1jCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA4wwggL1oAMCAQICARkwDQYJKoZI
hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE
AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDQwNzEyMTMwMjE4WhcNMDUw
NzI2MTMwMjE4WjBnMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRYwFAYD
VQQDEw1EYXZpZCBFbmdiZXJnMSYwJAYJKoZIhvcNAQkBFhdkZW5nYmVyZ0Bjb3Jlc3RyZWV0LmNv
bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJXX+JZ1oaEb2TCawk31rzpOIRTHZyP
UGTUGNyMasqczNZATvXu2RTlon8dwEuO4evr5KE9iDe0jQSkj1g5HBEsFAH+JPU7Y0uYupm/kiyr
6FiyhBCQtWhrcNii0yahcIEbH/fBAf5V10Y2wHKFrPH6uTrj+YGhBpaXxkEZpXCe2QZtkR/kcbKa
QaMCaU27vLAZ4QT6vJTf5oG/SD1KU232kYttiLeRjnePWipH8In7crGPhgJCeQP5UtE9uHDjOStt
eZxXsWAzU7oW9nb9jHL2xOWPQyhBs4JaPvgSdFkenI6L8flsQm72U8lrV/4dqKu330m5pH89XTYl
o2PcqIUCAwEAAaOB2DCB1TAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDov
L2NybC5nZW90cnVzdC5jb20vY3Jscy9jb3Jlc3RyZWV0LmNybDAiBgNVHREEGzAZgRdkZW5nYmVy
Z0Bjb3Jlc3RyZWV0LmNvbTAfBgNVHSMEGDAWgBTY7H+TGMVmA8MQbDwE9neFPv8LtjBABggrBgEF
BQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9nZW90cnVzdC1vY3NwLmNvcmVzdHJlZXQuY29t
LzANBgkqhkiG9w0BAQUFAAOBgQAtAQMtzyIzARw6d/sy1qPn+Mqr7aPEJFofkSW57NE639PcrXmC
E9LzVm5mtmoNkeeyHDOgla79ez8MzndDxhlwQvNdaiu124jWbgEoHC1q2K4McbaJlxjhPbCpFr7Z
CzxQxOmFxXjb16XGotrxX1aj2YWuAAdt9H3x+tHBXCn+WDGCAxowggMWAgEBMFcwUjELMAkGA1UE
BhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkCARkwCQYFKw4DAhoFAKCCAZgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTExMTM1MzUwWjAjBgkqhkiG9w0BCQQxFgQUAjcGKd6s
WM6BKoj2typYAFnHwEgwZgYJKwYBBAGCNxAEMVkwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP
Q29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0
eQIBGTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG
9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgsq
hkiG9w0BCRACCzFZoFcwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEp
MCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCARkwDQYJKoZIhvcNAQEB
BQAEggEAFRD4yos2Q36KTCeEt0DejpnbEZITe5rT3ed58pJ3yom1HRoai403UDQH/g25Hw7AUJVl
+HyNXQvQN/OBpFhLa5+B7s7iym9PkT1IUJ9HRqiZAKBQ/n9nfHr8Y/IxFvFXKJgiTWnWZzade2sO
yuMlGHtOgz+YARYitNzsOWzTaRyz7LofZ94+E1ov8znXk5rKjibmXAt0IslKXVKFgqKaL0StbHmR
vOae6lRwHgslLxD9XNBgvox/yvOMkRFwH3dQt4QWh/L8Ug12iieKkOj6O1j24Sa2LYBaYNrXBLtP
H7rQED4kQB2Hr4TM3s0xXfyDXTzRbygxxFjLt6GsdeIRKgAAAAAAAA==

------=_NextPart_000_002A_01C4C7CB.F685AA20--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTVKc055857; Tue, 16 Nov 2004 11:29:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTVS6055856; Tue, 16 Nov 2004 11:29:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTTrw055751 for <[e-mail]>; Tue, 16 Nov 2004 11:29:30 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25881 invoked by uid 1365); 16 Nov 2004 19:27:52 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:57 2004
Received: (qmail 24357 invoked from network); 16 Nov 2004 19:20:57 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:57 +0000
Received: (qmail 20096 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 29485 invoked by uid 1114); 11 Nov 2004 16:02:06 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Thu, 11 Nov 2004 16:02:04 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABFW3kp047675; Thu, 11 Nov 2004 07:32:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iABFW3Rg047674; Thu, 11 Nov 2004 07:32:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id iABFW3JF047655 for <[e-mail]>; Thu, 11 Nov 2004 07:32:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 26215 invoked by uid 0); 11 Nov 2004 15:31:58 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (130.129.135.212) by woodstock.binhost.com with SMTP; 11 Nov 2004 15:31:58 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Thu, 11 Nov 2004 10:31:57 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: a heads up on the next edition of X.509
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I just got a "heads up" message from Hoyt Kesterson.

Hoyt believes that the ISO/ITU-T Directory group will publish the 5th 
edition of X.509 by June 2005. They have a policy of supporting the current 
edition and the previous edition. At the moment they support (meaning that 
they will process defect reports) the 3rd and 4th editions.  So, in June 
they will drop support of the 3rd edition.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTVpN055855; Tue, 16 Nov 2004 11:29:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTVLh055854; Tue, 16 Nov 2004 11:29:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTTQE055733 for <[e-mail]>; Tue, 16 Nov 2004 11:29:29 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25896 invoked by uid 1365); 16 Nov 2004 19:27:52 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:58 2004
Received: (qmail 24364 invoked from network); 16 Nov 2004 19:20:57 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:57 +0000
Received: (qmail 20099 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 27350 invoked by uid 1114); 9 Nov 2004 21:26:13 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 09 Nov 2004 21:26:10 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9LAA1N091336; Tue, 9 Nov 2004 13:10:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9LAAZs091335; Tue, 9 Nov 2004 13:10:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9LA9YX091318 for <[e-mail]>; Tue, 9 Nov 2004 13:10:10 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9LAB1X025923 for <[e-mail]>; Tue, 9 Nov 2004 16:10:13 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 16:10:11 -0500
Message-ID: <007c01c4c6a0$8118ce10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

Can you explain the following from your post in relation of CRL path
matching and how you mitigate it and CRL path matching does not.  I quote
you:

"In replying to Santosh, you have discussed attacks which come from
unrelated CA's as the primary security threat associated with CRL issuers.
I agree with that, and have blocked those."

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Gindin
Sent: Tuesday, November 09, 2004 1:40 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



        Denis:

        It is indeed possible for two CA's to choose the same CRL issuer 
DN, while meaning two distinct entities.  However, what are the 
consequences?  In one case, a CA which has certified a subordinate CA can 
"take over" the issuer ID of that subordinate (outside hierarchies, only 
RP's who are trusting the CA through the issuer of that cross-certificate 
are affected).  In the other, a CA which originally delegated revocation 
to its superior can reclaim it.  Which of these is an attack?
        I don't know why the RP needs a rule which declares "a CRL issuer 
must be certified by the CA whose certificates it is issuing a CRL for", 
and which prohibits subordinate CA's from having their hierarchical 
superior issue CRL's for them.  In replying to Santosh, you have discussed 
attacks which come from unrelated CA's as the primary security threat 
associated with CRL issuers.  I agree with that, and have blocked those.
        BTW, Santosh is right that a certificate issued to a CRL Issuer by 
a CA which ordinarily delegates CRL's to that issuer is not practically 
revocable by CRL.  However, IMO a certificate may be useful even if a 
revocation check on it is not feasible.  Much client software checks 
certificate chains without checking revocation, being satisfied with the 
certification that "this key pair was once possessed by the subject". This 
applies equally to self-issued certificates.
        Before declaring that a rule should (or should not) prevent the 
use of a superior CA's CRL Issuer to produce CRL's for a subordinate CA, 
we should probably find out if anybody actually does that.  I hope that 
nobody actually has sibling CA's producing their CRL's.

                Tom Gindin






Denis Pinkas <[e-mail]>
11/09/2004 09:17 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     [e-mail]
        Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting


Tom,

>         Denis:

> Would a reasonable formulation of this rule be that a CRL Issuer
> certificate governing the certificates of a given CA must have been 
> directly issued by one of the certificates in the chain being verified 
> (including the CA's own certificate), by the trust anchor for that 
chain, 
> or by a certificate which is a rollover of one of the certificates in
the 
> first two grouips?

No. This would not be a good formulation, since two different CAs from the
chain could choose the same DN to designate different CRL Issuers.

The RP needs to have an unambiguous way to know exactly which CA from the
chain is the one which has nominated the CRL Issuer.

Denis

> For this purpose, a certificate is a rollover of its
> issuer certificate if it is self-issued but not self-signed, and the 
> relationship is associative (i.e. if A is a rollover of B which is a 
> rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D 
has 
> a CRL issuer and the path to D goes A (the anchor) to B to C to D, the
CRL 
> issuer certificate may be issued by A, B, C, or D, or by B' in the 
> case
> where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued 

> through any other anchor nor through any CA whose DN is not in the 
> path.

> Only one further liberalization of this rule might make sense, which 
> is
> that C' would be considered a rollover of C on a path where C is issued 
by 
> B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels 
> that

> this is safe?
>         The good news about this heuristic is that it can be coded.  I
> think any of these variants resist Julien's attack, under the fairly 
> reasonable assumptions that no CA issues certificates to bogus entities 
> with its own name and that any CA which directly issued your 
> cross-certificate and wants to have a CRL issuer masquerade as that CA 
can 
> do so by issuing a bogus CA cert just as easily as by issuing a bogus
CRL 
> Issuer one.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> Denis Pinkas <[e-mail]>
> Sent by: [e-mail]
> 11/05/2004 10:04 AM
> 
>         To:     Santosh Chokhani <[e-mail]>
>         cc:     [e-mail]
>         Subject:        Re: Briefing on CRL Path for IETF PKIX WG 
Meeting
> 
> 
> 
> Santosh,
> 
> 
>>Denis,
>>
>>See responses in-line in [SC:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, November 04, 2004 12:40 PM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>Santosh,
>>
>>See responses in-line in [DP:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Wednesday, November 03, 2004 9:48 AM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>Santosh,
>>
>> > Denis,
>>
>> > The matching algorithm proposed checks/compares the ancestors.
>>
>>The matching algorithm is missing to say "who" trusts "somebody" for
> 
> "what".
> 
>>Unless this is clearly said, there is no trust possible and thus no 
>>algorithm possible.
>>
>>[SC: The two paths needs to be verified in accordance with 3280 in 
>>order

> 
> to
> 
>>establish trust]
>>
>>[DP: the certification path needs to be verified according to RFC 
>>3280.
> 
> The
> 
>>problem is that RFC 3280 does not tell how to verify that the CRL 
>>comes
>>from the right CRL Issuer. Your assumption that the "two paths needs to 
> 
> be
> 
>>verified in accordance with 3280 in order to establish trust" is thus
>>incorrect].
>>
>>[SC: When you augment 3280 with the algorithm I proposed, that takes
> 
> care of
> 
>>it.  It goes without saying that 3280 needs to be augmented with the 
>>algorithm]
> 
> 
> This is exactly what I disagree with.
> 
> Let us talk about the key issue. The question is: how can a RP 
> (relying
> party) know that, for a given end-user certificate, the CRL he got is 
> indeed 
> issued by the right CRL Issuer ?
> 
> In the following discussion, I am only considering the case where the
CRL 
> Issuer is *not* the CA (this CA is called CA 1).
> 
> CA 2 is a CA that has issued a CA certificate to CA 1.
> 
> The text is currently so vague that different models are indeed
> theoritically possible. In particular:
> 
>   a) the CRL Issuer is nominated by CA 1 that has issued
>      the end-user certificate. This case would make sense
>      when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>      that role to one or more CRL Issuers. This means that
>      a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
> 
>   b) the CRL Issuer is nominated by CA 2 that has issued a CA
>      certificate to CA 1. This case would make sense when CA 2
>      has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>      certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>      then only choose a CRL Issuer that has been granted
>      the authorization to issue CRLs by CA 2.
> 
> I wonder if I understand correctly the model you proposed, but (please
> correct if wrong) you have a set of trust points to verify the 
> certification 
> chain, and another set of trust points to verify what you call a 
> certification path for the CRL Issuer.
> 
> There would be many problems with such a model to define correctly
> validation policies, since the two chains would be unrelated and any CA 
> from 
> that chain could nominate CRL Issuers used by any CA.
> 
> In options a) and b) mentioned above, a single trust point is used to
> validate both the certification chain and the CRL Issuer.
> 
> In any case, we need to clarify this topic in 3280bis, whatever the
> clarification will be.
> 
> 
>>This algorithm is nothing more than formalism of something you agreed
>>to in 2003 on this list.
>>
>>I don't think so.
>>
>>[SC: Go back to September 2003 archive of your response to my post and
> 
> tell
> 
>>me what is not covered]
>>
>>[DP: You would need to be more precise and provide me an extract of 
>>what

> 
> you
> 
>>refer to]
>>
>>[SC: It was short string of e-mails on the subject matter in September
> 
> 2003.
> 
> Hum !!! Hum !!!
> Do not mention "free" assertions when you are not sure about.
> 
> Denis
> 
> 
>>I am sure you can find it from the archives.  It may be overcome by
> 
> events
> 
>>since your recent postings show that you agree with me]
>>
>>Denis
> 
> 
> 
> 
> 
> 
> 






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTTaB055837; Tue, 16 Nov 2004 11:29:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTTI2055836; Tue, 16 Nov 2004 11:29:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTSjf055714 for <[e-mail]>; Tue, 16 Nov 2004 11:29:28 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25872 invoked by uid 1365); 16 Nov 2004 19:27:51 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:57 2004
Received: (qmail 24338 invoked from network); 16 Nov 2004 19:20:57 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:57 +0000
Received: (qmail 19991 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 1486 invoked by uid 1114); 10 Nov 2004 13:04:23 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 13:04:21 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAACe6sc002209; Wed, 10 Nov 2004 04:40:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAACe6Og002208; Wed, 10 Nov 2004 04:40:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAACe2kp002099 for <[e-mail]>; Wed, 10 Nov 2004 04:40:04 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA85112; Wed, 10 Nov 2004 13:51:50 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111013394651:755 ; Wed, 10 Nov 2004 13:39:46 +0100 
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 13:39:45 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'pkix'" <[e-mail]>
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <002d01c4c668$bf7ee780$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 13:39:46, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 13:39:48, Serialize complete at 10/11/2004 13:39:48
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

My response with [DP: ]

As to circularity, the problem is as follows.

Let us say CA A delegates the CRL issuance to Authority B.  Your proposal
requires that A issue a certificate to B will get in the way of a CA not
issuing CRLs because if the CA does not issue CRL, how would the revocation
status of certificate A --> B be checked?

[DP: I would rephrase the problem in the following way:

Let us say CA A delegates the CRL issuance to CRL Issuer B.
This requires that CA A issues a CRL Issuer certificate to CRL Issuer B.

The question you asked is then:
"How to make sure that this CRL Issuer certificate is not revoked ?"

This depends what kind of information tha CA A places in the CRL DP
extension of the CRL Issuer certificate issued to CRL Issuer B.

There are, at least, two answers:

1) there is no cRLIssuer field in the CRL DP extension:
    this means that the CA is directly taking care of the revocation
    status of its CRL Issuers: it will issue CRLs only for the
    CRL Issuers.

2) there is no CRL DP extension at all:
    this would mean that the CA does not issue CRLs for its CRL Issuers.
    In case one of the CRL issuers would need to be revoked, it will ask
    its "normal" upper CA to revoke its own certificate. By implication,
    the CRL Issuer certificate that was issued would become invalid.]

Both approaches have advantages and disavantages.
Anyway, thank you for raising the question.

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTSBN055807; Tue, 16 Nov 2004 11:29:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTSl3055806; Tue, 16 Nov 2004 11:29:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTNZD055660 for <[e-mail]>; Tue, 16 Nov 2004 11:29:27 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25890 invoked by uid 1365); 16 Nov 2004 19:27:52 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:06 2004
Received: (qmail 24751 invoked from network); 16 Nov 2004 19:21:06 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:06 +0000
Received: (qmail 20150 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 22587 invoked by uid 1114); 15 Nov 2004 14:17:49 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 14:17:47 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFDjYrk054733; Mon, 15 Nov 2004 05:45:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFDjYSa054732; Mon, 15 Nov 2004 05:45:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFDjWon054696 for <[e-mail]>; Mon, 15 Nov 2004 05:45:33 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1CThAj-000EJq-Lw for [e-mail]; Mon, 15 Nov 2004 13:45:34 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 13:46:18 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: Re: Is that right?set the valid_policy to OID-P;
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

alan wrote:

> ietf-pkix£¬
>
> In rfc3280,
> 6.1.3  Basic Certificate Processing
> (d)
> 	(1)
> 		(i)If the valid_policy_tree includes a node of depth i-1
>             where P-OID is in the expected_policy_set, create a child
>             node as follows: set the valid_policy to OID-P; set the
>             qualifier_set to P-Q, and set the expected_policy_set to
>             {P-OID}.
> OID-P is what?
>
> I can't make sure for this word.
>

When I implemented this for OpenSSL I assumed it was a typo and should
say P-OID. The example in figure 4 supports this.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTRih055798; Tue, 16 Nov 2004 11:29:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTR0u055797; Tue, 16 Nov 2004 11:29:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTPiQ055701 for <[e-mail]>; Tue, 16 Nov 2004 11:29:26 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25884 invoked by uid 1365); 16 Nov 2004 19:27:52 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:06 2004
Received: (qmail 24732 invoked from network); 16 Nov 2004 19:21:06 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:06 +0000
Received: (qmail 20171 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 8134 invoked by uid 1114); 16 Nov 2004 18:23:38 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 16 Nov 2004 18:23:35 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGHxMM8015710; Tue, 16 Nov 2004 09:59:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGHxMKn015709; Tue, 16 Nov 2004 09:59:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGHxLc5015682 for <[e-mail]>; Tue, 16 Nov 2004 09:59:21 -0800 (PST) (envelope-from [e-mail])
Received: from piyush (c-24-6-179-46.client.comcast.net[24.6.179.46]) by comcast.net (sccrmhc12) with SMTP id <20041116175918012008u4ike>; Tue, 16 Nov 2004 17:59:18 +0000
Message-ID: <001301c4cc05$f6bfbc40$[e-mail]>
From: "piyush" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Terry Hayes" <[e-mail]>, "David A. Cooper" <[e-mail]>, "Stephen Henson" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: 3280bis: name constraints
Date: Tue, 16 Nov 2004 09:59:04 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The fact that the extension is a name constraint becomes immaterial if the 
path building software chooses to ignore it.
The software may ignore the extension if it is marked as non critical,  as 
per rfc 3280.

In practice, there may be some benefits to marking the name constraint 
extension non critical.
RP may configure the path building software to ignore/enforce the extension 
based on the importance of the transaction.
e.g. - for email validation, the RP may configure the path validation 
software to ignore name constraints.
      - for a million dollar internet transaction, the RP may configure the 
software to always enforce name constraints.

-Piyush


----- Original Message ----- 
From: "Stefan Santesson" <[e-mail]>
To: "Terry Hayes" <[e-mail]>; "David A. Cooper" 
<[e-mail]>; "Stephen Henson" 
<[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, November 16, 2004 8:27 AM
Subject: RE: 3280bis: name constraints


>
> This is a truth with modification.
>
> A relying party can always accept any certificates for any use for any
> reason but that is not the point.
>
> The point is to decide when path validation according to RFC 3280
> rejects the certificate path as invalid. This is done within strict
> rules.
>
> Any constrained name form that is violated in the path renders the path
> invalid. Critical or non-critical extensions does not make any
> difference in this regard.
>
>
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>
>> -----Original Message-----
>> From: [e-mail]
> [mailto:[e-mail]]
>> On Behalf Of Terry Hayes
>> Sent: den 16 november 2004 00:45
>> To: David A. Cooper; Stephen Henson
>> Cc: [e-mail]
>> Subject: Re: 3280bis: name constraints
>>
>>
>> In my opinion, a requirement such as this is too restrictive, and will
>> prevent additional capabilities from being added to a PKI.
>>
>> As long as an application never makes use of a particular name form,
> it
>> should be free to ignore constraints that apply to that name form.
> Notice
>> that to do this, it must recognize and process the name constraint
>> extension as required by the extension processing rules.
>>
>> If applications are required to reject certificates paths with
> constraints
>> for name forms that they do not recognize, they will be prevented from
>> using certificates that have those name forms added to them for other
>> applications.  This will impede the use of certificates for these new
>> applications, since older clients will not be able to function.
>>
>> Terry Hayes
>>
>>
>> David A. Cooper wrote on 11/15/2004, 2:08 PM:
>> >
>> >
>> > X.509 does have a rule that one must reject a critical extension
> unless
>> > you can process all of the fields in the extension. So, for name
>> > constraints, if a critical nameConstraints extension includes a
>> > constraint on a name form and that name form appears in the subject
>> > field or subjectAltName extension of a subsequent certificate, then
> path
>> > must be rejected.
>
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTOvw055744; Tue, 16 Nov 2004 11:29:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTOGb055742; Tue, 16 Nov 2004 11:29:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTMG4055650 for <[e-mail]>; Tue, 16 Nov 2004 11:29:23 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25911 invoked by uid 1365); 16 Nov 2004 19:27:52 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:07 2004
Received: (qmail 24773 invoked from network); 16 Nov 2004 19:21:07 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:07 +0000
Received: (qmail 20192 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 3436 invoked by uid 1114); 13 Nov 2004 14:37:09 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Sat, 13 Nov 2004 14:37:07 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADDwks7076280; Sat, 13 Nov 2004 05:58:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADDwkC7076279; Sat, 13 Nov 2004 05:58:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADDwjrd076249 for <[e-mail]>; Sat, 13 Nov 2004 05:58:45 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA35764; Sat, 13 Nov 2004 15:10:48 +0100
Received: from bull.net ([129.181.81.126]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111314584053:1054 ; Sat, 13 Nov 2004 14:58:40 +0100 
Message-ID: <[e-mail]>
Date: Sat, 13 Nov 2004 14:59:54 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: pkix <[e-mail]>
Subject: 3280bis: indirectCRL boolean in IDP (3/3)
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 02:58:41 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 02:58:41 PM, Serialize complete at 11/13/2004 02:58:41 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

3280bis: indirectCRL boolean in IDP (3/3)

This is a change and an addition proposal related to indirect CRLs.

>From section 5.2.5 Issuing Distribution Point, "the CRL issuer MUST
assert the indirectCRL boolean, if the scope of the CRL includes
certificates issued by authorities other than the CRL issuer".

This sentence is incorrect since CRL issuers do not issue
certificates.  

Proposed correction: 

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of
the CRL includes certificate identifiers from multiple authorities"
 
This boolean indicates a type b) indirect CRL but is named indirectCRL
boolean which is confusing with type a) indirect CRLs.

A note should be mentioned to clarify the ambiguity of the naming.

Proposed note: 

"The name of the boolean "indirectCRL" designates an indirect CRL that
includes certificate identifiers from multiple authorities, and not an
indirect CRL that includes certificate identifiers from a single CA.
An alternative name for that boolean would be: multipleCAs."

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTOBh055731; Tue, 16 Nov 2004 11:29:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTNHV055730; Tue, 16 Nov 2004 11:29:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTLrX055643 for <[e-mail]>; Tue, 16 Nov 2004 11:29:22 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25832 invoked by uid 1365); 16 Nov 2004 19:27:51 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:55 2004
Received: (qmail 24258 invoked from network); 16 Nov 2004 19:20:54 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:54 +0000
Received: (qmail 20042 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 23863 invoked by uid 1114); 9 Nov 2004 21:02:33 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 09 Nov 2004 21:02:30 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9KhnNo083565; Tue, 9 Nov 2004 12:43:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9KhnZd083564; Tue, 9 Nov 2004 12:43:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9KhnKJ083556 for <[e-mail]>; Tue, 9 Nov 2004 12:43:49 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9Khq1X001099 for <[e-mail]>; Tue, 9 Nov 2004 15:43:52 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 15:43:52 -0500
Message-ID: <006f01c4c69c$d2d26c60$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA9KhnKJ083559
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

See responses in line in [SC:}

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 2:06 PM
To: Denis Pinkas; Santosh Chokhani; Julien Stern
Cc: [e-mail]
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting


It seams that we have a problem with agreeing on the security assumptions
more than on the technical matters.

I recognize that Julien's scenario is a valid remark, at least in theory.
The point Julien is that there is a problem if an attacker that has obtained
a rouge CA under a valid root actually could fool an RP software to accept
the rouge path to the target certificate. IF the RP accept the path over the
rouge CA then that rouge CA could also defeat the proposed algorithm.

The question is just if this is a valid threat or not.

Denis is making a valid remark that different CA's in the certificate path
may certify different CRL Issuers with the same name by accident and the
algorithm doesn't account for that.

[SC: This is only an issue in the context of indirect CRL.  For the direct
CRL issuer, the algorithm will disambiguate the issues].

The question is if this is a valid threat or not.

Both Denis and Julien's scenarios require intentional malicious behaviour of
the CRL issuer or the CDP and the IDP wouldn't match (the storage location
pointer would differ).

[SC: I have not seen a scenario from Denis.  I have a different and simple
take on Julien's scenario.  First, Julien's scenario will not come about for
the relying parties who do not trust the rogue CA.  Second, the algorithm
makes sure that who ever is the certificate issuer from the relying party
perspective can only revoke the certificate.  Third, even if the same key
was used, in Julien's scenario relying party can always be fooled into using
bad revocation information along with bogus certificate minted by the rogue
CA.]

Both scenarios also require the attacker to convince the RP to NOT obtain
the correct CRL through the CDP pointer and instead accept the rough CRL
from other source OR it requires the attacker to hack the server holding the
real CRL and replace the real CRL with the rough CRL.

----------------

In Denis scenario I would suggest that we can exclude presence of a rouge CA
in the original certificate path, because if the original cert path has a
rouge CA, then all bets are off anyway.

This leaves us with Julien's scenario.

-----------------

So the main question is which of these threats that is in scope or out of
scope 

1) Presence of a trusted Rouge CA that is NOT part of the original
certificate path.

2) The ability of the attacker to fool the RP to pick a rouge path and rouge
CRL where the IDP and CDP match.

Questions/remarks:
- If both these threats are in scope then Julien's scenario is also valid.
- If there threats are out of scope, then what threat remains that requires
Santosh algorithm in the first place?

[SC: The threat that the algorithm mitigates is one of accidental error and
one of malfeasance.  Let me illustrate.  Let us say that both Microsoft and
VeriSign roots are in a relying party trust anchor  set.  Let us say that
that we have Microsoft --> Orion CA --> Chokhani.  Chokhani is an end entity
with serial number 10.  Let us also say that VeriSign has certified another
Orion.  So, we have VeriSign -->  Orion CA --> CRL X.  Now, some one can
compromise Chokhani key and play the CRL X  that does not contain 10 and
make the relying party access Chokhani certificate which actually has been
compromised.  In this case, all four CAs and Chokhani are playing nice, but
some one else just ate our lunch.]

I'm still pro Santosh algorithm since it limits complexity in path
processing but it would be good to know if there are any threats that
require Santosh algorithm which remains if at least problem 1 above is out
of scope.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTOkX055734; Tue, 16 Nov 2004 11:29:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTOoP055732; Tue, 16 Nov 2004 11:29:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTLd1055642 for <[e-mail]>; Tue, 16 Nov 2004 11:29:22 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25844 invoked by uid 1365); 16 Nov 2004 19:27:51 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:05 2004
Received: (qmail 24687 invoked from network); 16 Nov 2004 19:21:05 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:05 +0000
Received: (qmail 20111 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 23626 invoked by uid 1114); 10 Nov 2004 01:34:10 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 01:34:08 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA1HZmh096450; Tue, 9 Nov 2004 17:17:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA1HZIV096449; Tue, 9 Nov 2004 17:17:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA1HYdC096442 for <[e-mail]>; Tue, 9 Nov 2004 17:17:34 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 10DB141B2E for <[e-mail]>; Wed, 10 Nov 2004 02:17:32 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id D77A4440E7 for <[e-mail]>; Wed, 10 Nov 2004 02:18:05 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25215-02 for <[e-mail]>; Wed, 10 Nov 2004 02:18:02 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 419F3440AF for <[e-mail]>; Wed, 10 Nov 2004 02:18:02 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 10 Nov 2004 02:17:29 +0100
From: "Julien Stern" <[e-mail]>
Date: Wed, 10 Nov 2004 02:17:29 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <006f01c4c69c$d2d26c60$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <006f01c4c69c$d2d26c60$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

comments in line with [JS]

On Tue, Nov 09, 2004 at 03:43:52PM -0500, Santosh Chokhani wrote:
> 
> Stefan,
> 
> See responses in line in [SC:}
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]] 
> Sent: Tuesday, November 09, 2004 2:06 PM
> To: Denis Pinkas; Santosh Chokhani; Julien Stern
> Cc: [e-mail]
> Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> It seams that we have a problem with agreeing on the security assumptions
> more than on the technical matters.
> 
> I recognize that Julien's scenario is a valid remark, at least in theory.
> The point Julien is that there is a problem if an attacker that has obtained
> a rouge CA under a valid root actually could fool an RP software to accept
> the rouge path to the target certificate. IF the RP accept the path over the
> rouge CA then that rouge CA could also defeat the proposed algorithm.
> 
> The question is just if this is a valid threat or not.
> 
> Denis is making a valid remark that different CA's in the certificate path
> may certify different CRL Issuers with the same name by accident and the
> algorithm doesn't account for that.
> 
> [SC: This is only an issue in the context of indirect CRL.  For the direct
> CRL issuer, the algorithm will disambiguate the issues].
> 
> The question is if this is a valid threat or not.
> 
> Both Denis and Julien's scenarios require intentional malicious behaviour of
> the CRL issuer or the CDP and the IDP wouldn't match (the storage location
> pointer would differ).
> 
> [SC: I have not seen a scenario from Denis.  I have a different and simple
> take on Julien's scenario.

> First, Julien's scenario will not come about for
> the relying parties who do not trust the rogue CA.

[JS: this is true, but the rogue CA could be anywhere in the hierarchy
of any trusted anchor. Also, if you assume no CA rogue CA is trusted, your
algorithm mostly only simplifies path construction.]

> Second, the algorithm
> makes sure that who ever is the certificate issuer from the relying party
> perspective can only revoke the certificate.

[JS: the whole point being that it is simple to conterfeit the certicate
issuer from the relying party perspective. Trust in X509 in going down,
not up. This is how the attck works.]

> Third, even if the same key
> was used, in Julien's scenario relying party can always be fooled into using
> bad revocation information along with bogus certificate minted by the rogue
> CA.]

[JS: it might be possible to perform an attack even when the same key is
used, but my current scenario does not. The attack would be much more
complex. It do not see to what scenario you refer to.]


> 
> Both scenarios also require the attacker to convince the RP to NOT obtain
> the correct CRL through the CDP pointer and instead accept the rough CRL
> from other source OR it requires the attacker to hack the server holding the
> real CRL and replace the real CRL with the rough CRL.
> 
> ----------------
> 
> In Denis scenario I would suggest that we can exclude presence of a rouge CA
> in the original certificate path, because if the original cert path has a
> rouge CA, then all bets are off anyway.
> 
> This leaves us with Julien's scenario.
> 
> -----------------
> 
> So the main question is which of these threats that is in scope or out of
> scope 
> 
> 1) Presence of a trusted Rouge CA that is NOT part of the original
> certificate path.
> 
> 2) The ability of the attacker to fool the RP to pick a rouge path and rouge
> CRL where the IDP and CDP match.
> 
> Questions/remarks:
> - If both these threats are in scope then Julien's scenario is also valid.
> - If there threats are out of scope, then what threat remains that requires
> Santosh algorithm in the first place?
> 
> [SC: The threat that the algorithm mitigates is one of accidental error and
> one of malfeasance.  Let me illustrate.  Let us say that both Microsoft and
> VeriSign roots are in a relying party trust anchor  set.  Let us say that
> that we have Microsoft --> Orion CA --> Chokhani.  Chokhani is an end entity
> with serial number 10.  Let us also say that VeriSign has certified another
> Orion.  So, we have VeriSign -->  Orion CA --> CRL X.  Now, some one can
> compromise Chokhani key and play the CRL X  that does not contain 10 and
> make the relying party access Chokhani certificate which actually has been
> compromised.  In this case, all four CAs and Chokhani are playing nice, but
> some one else just ate our lunch.]

[JS: it seems to me that you assume that you can force the use of a
CRL over an other for the attack you described work.

So the difference between our threat models, security wise, is that
you assume all CA are honests and never compromised but can make mistakes,
while I assume a CA can act in a dishonest way. It that correct ?]

> 
> I'm still pro Santosh algorithm since it limits complexity in path
> processing but it would be good to know if there are any threats that
> require Santosh algorithm which remains if at least problem 1 above is out
> of scope.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTNjj055713; Tue, 16 Nov 2004 11:29:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTNB2055712; Tue, 16 Nov 2004 11:29:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTLqc055641 for <[e-mail]>; Tue, 16 Nov 2004 11:29:22 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25859 invoked by uid 1365); 16 Nov 2004 19:27:51 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:05 2004
Received: (qmail 24710 invoked from network); 16 Nov 2004 19:21:05 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:05 +0000
Received: (qmail 20126 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 17578 invoked by uid 1114); 16 Nov 2004 02:25:18 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 16 Nov 2004 02:25:15 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAG1nQvP096768; Mon, 15 Nov 2004 17:49:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAG1nQl2096767; Mon, 15 Nov 2004 17:49:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAG1nPae096758 for <[e-mail]>; Mon, 15 Nov 2004 17:49:25 -0800 (PST) (envelope-from [e-mail])
Received: by rproxy.gmail.com with SMTP id g11so517382rne for <[e-mail]>; Mon, 15 Nov 2004 17:49:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eWP7qi/8+D57W+qQy/VZOXDKJSuiotOyJvegOSYi2H/uRyuu5+BQAL6ngaPciI2YLqzHZ2tW5chIxN5w+zQYSkFRq+g1apE6roHNt9NoK0KPj2/VblvErT5tc9t61cywFq95EtkPGd3O7qv1+1f3m+IdD15xoDiD+Ac+Wwdqkxs=
Received: by 10.38.4.61 with SMTP id 61mr467665rnd; Mon, 15 Nov 2004 17:49:30 -0800 (PST)
Received: by 10.38.81.56 with HTTP; Mon, 15 Nov 2004 17:49:30 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 12:49:30 +1100
From: Andrew Sciberras <[e-mail]>
Reply-To: Andrew Sciberras <[e-mail]>
To: Tim Polk <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]>
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,TW_PK
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Do you have any concerns about the fact that the Serial Number
attribute (section 5.1.2) does not contain an ordering matching rule?

Is it intentional that the Serial Number attribute is not 'SINGLE-VALUE'?


Section 5.2.3  Key usage Extension
If you have a certificate with a keyUsage extension present with a
value of zero (i.e. none of the bits are set) what do you do? Do you
simply omit using the x509keyUsage atribute? If not, how does the BNF
represent such a value?

Thanks,
Andrew Sciberras



On Mon, 15 Nov 2004 17:00:22 -0500, Tim Polk <[e-mail]> wrote:
> 
> 
> This message initiates working group Last Call for the "LDAP Schema for
> X.509 Certificates"
> specification. The editors have confirmed that all working group issues
> have been resolved.
> 
> The URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt
> 
> This specification has also been forwarded to the LDAP Directorate for a
> parallel review.  Assuming successful Last Call and concurrence from the
> LDAP Directorate, this document will be forwarded to the ADs for
> consideration as an Informational track RFC.
> 
> Last Call will run for (at least) two weeks. That is, Last Call will not
> close before November 29.
> 
> Thanks,
> 
> Tim Polk
> 
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTKGu055703; Tue, 16 Nov 2004 11:29:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTKBS055702; Tue, 16 Nov 2004 11:29:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTILX055623 for <[e-mail]>; Tue, 16 Nov 2004 11:29:19 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25853 invoked by uid 1365); 16 Nov 2004 19:27:51 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:05 2004
Received: (qmail 24709 invoked from network); 16 Nov 2004 19:21:05 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:05 +0000
Received: (qmail 20141 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 31638 invoked by uid 1114); 12 Nov 2004 19:31:28 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Fri, 12 Nov 2004 19:31:26 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACIqOBn005224; Fri, 12 Nov 2004 10:52:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACIqO79005223; Fri, 12 Nov 2004 10:52:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACIqNKj005178 for <[e-mail]>; Fri, 12 Nov 2004 10:52:23 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iACIqFjh026165 for <[e-mail]>; Fri, 12 Nov 2004 13:52:17 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06110407bdbab5097407@[128.89.89.75]>
Date: Fri, 12 Nov 2004 13:49:43 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: send me your slides, please
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I still need slides from the following folks, to complete the meeting 
notes and prepare our package for delivery to the Secretariat:

Tim Polk (2 slide sets)
David Chadwick
Daniel Brown
Baehyo Park

My thanks to Trevor, Stefan, Ryan, Santosh and Kurt for delivery of 
their slides. Stefan wins the prize for first delivery.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTKPZ055700; Tue, 16 Nov 2004 11:29:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTKt4055698; Tue, 16 Nov 2004 11:29:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTI8H055610 for <[e-mail]>; Tue, 16 Nov 2004 11:29:19 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25865 invoked by uid 1365); 16 Nov 2004 19:27:51 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:06 2004
Received: (qmail 24730 invoked from network); 16 Nov 2004 19:21:06 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:06 +0000
Received: (qmail 20162 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 23338 invoked by uid 1114); 15 Nov 2004 22:22:32 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 22:22:30 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFM849L025459; Mon, 15 Nov 2004 14:08:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFM841B025458; Mon, 15 Nov 2004 14:08:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFM84YP025444 for <[e-mail]>; Mon, 15 Nov 2004 14:08:04 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAFM7omc006850; Mon, 15 Nov 2004 17:07:50 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAFM7ZYA017782; Mon, 15 Nov 2004 17:07:36 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 17:08:06 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Henson <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

I already have a note that the processing of dNSName in name constraints 
needs to be clarified.  In particular, it needs to be made clear that 
"f.example.com" falls within the subtree "example.com", but 
"fexample.com" does not.

X.509 does have a rule that one must reject a critical extension unless 
you can process all of the fields in the extension. So, for name 
constraints, if a critical nameConstraints extension includes a 
constraint on a name form and that name form appears in the subject 
field or subjectAltName extension of a subsequent certificate, then path 
must be rejected.  The same applies if the minimum or maximum field is 
included and the relying party can not process those fields.  I can add 
text in 3280bis that states this.

I was not aware of any confusion over the meaning of name constraints 
imposed on rfc822Name or directoryName.  Could you provide more 
information about what needs to be clarified?

Dave

Stephen Henson wrote:

> IMHO some clarification of the nameConstraints extension should be 
> included in RFC3280bis.
>
> I can recall there being a number of threads discussing the meaning of 
> name constraints for various types including the interpretation of the 
> rfc822Name and dNSName fields. At the time various people had come to 
> different conclusions based on the existing text.
>
> I've not seen a description of how directoryName types are handled or 
> a discussion on this.
>
> IIRC X509 includes a note that if an unhandled constraint type is 
> encountered the certificate should be rejected: should RFC3280bis 
> include this too?
>
> What about the minimum and maximum fields: should an implementation 
> reject a certificate where these are present?
>
> Steve.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTJHp055670; Tue, 16 Nov 2004 11:29:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTJrs055668; Tue, 16 Nov 2004 11:29:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT8RJ055452 for <[e-mail]>; Tue, 16 Nov 2004 11:29:09 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25817 invoked by uid 1365); 16 Nov 2004 19:27:50 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:53 2004
Received: (qmail 24236 invoked from network); 16 Nov 2004 19:20:52 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:52 +0000
Received: (qmail 19960 invoked by alias); 16 Nov 2004 19:20:49 +0000
Delivered-To: [e-mail]
Received: (qmail 11501 invoked by uid 1114); 12 Nov 2004 03:03:38 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Fri, 12 Nov 2004 03:03:35 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAC2NROa083167; Thu, 11 Nov 2004 18:23:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAC2NRkb083166; Thu, 11 Nov 2004 18:23:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw ([202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAC2NG57083061 for <[e-mail]>; Thu, 11 Nov 2004 18:23:26 -0800 (PST) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAC2MvW5010003; Fri, 12 Nov 2004 10:22:57 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id iAC2MvHf014382; Fri, 12 Nov 2004 10:22:57 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAC2MuZG014313; Fri, 12 Nov 2004 10:22:57 +0800
Message-ID: <012201c4c85e$852b3960$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Manuel Gil Perez" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <005401c4c81b$99f48e70$[e-mail]>
Subject: Re: Bridge CA and crossCertificatePair
Date: Fri, 12 Nov 2004 10:22:55 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Pérez,

The syntax need not to be changed.

The crossCertificatePair is a multi-valued attribute.
That means you can store multiple CertificatePair
objects in a crossCertificatePair attribute.

Wen-Cheng Wang

----- Original Message ----- 
From: "Manuel Gil Perez" <[e-mail]>
To: <[e-mail]>
Sent: Friday, November 12, 2004 2:23 AM
Subject: Bridge CA and crossCertificatePair


>
> Dear PKIX members,
>
> I need to develop a bridge CA where it must store one or more
> cross-certificates. Revising the RFCs (about LDAP, X.509, etc.) and looking
> up on the web I conclude that it is technically possible (in accordance with
> RFC 3280) to store one or more cross-certificate into my bridge CA (this
> value is multi-valued).
>
> But really, according to the specification (see below), I can only store one
> pair of cross-certificates. Is it possible that the attribute
> CertificatePair is not correct and should be changed for the following??
>
> CertificatePair ::= SEQUENCE SIZE(1..MAX) OF CertificateForwardReverse;
>
> CertificateForwardReverse ::= SEQUENCE {
>    forward [0] Certificate OPTIONAL,
>    reverse [1] Certificate OPTIONAL,
>    -- at least one of the pair shall be present -- }
>
> In any case... can somebody send me the correct specification for the
> attribute CertificatePair??
>
> Many thanks, and best regards...
>
> ------
> Manuel Gil Pérez
> http://pki.umu.euro6ix.org
>
>
> ======
>
> pkiCA OBJECT-CLASS ::= {
>    SUBCLASS OF { top}
>    KIND auxiliary
>    MAY CONTAIN {
>       cACertificate |
>       certificateRevocationList |
>       authorityRevocationList |
>       crossCertificatePair }
>    ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22) }
>
> crossCertificatePair ATTRIBUTE ::= {
>    WITH SYNTAX CertificatePair
>    EQUALITY MATCHING RULE certificatePairExactMatch
>     ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40) }
>
> CertificatePair ::= SEQUENCE {
>    forward [0] Certificate OPTIONAL,
>    reverse [1] Certificate OPTIONAL,
>    -- at least one of the pair shall be present -- }
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTIUJ055662; Tue, 16 Nov 2004 11:29:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTIq8055661; Tue, 16 Nov 2004 11:29:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTGeM055571 for <[e-mail]>; Tue, 16 Nov 2004 11:29:17 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25847 invoked by uid 1365); 16 Nov 2004 19:27:51 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:56 2004
Received: (qmail 24300 invoked from network); 16 Nov 2004 19:20:56 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:56 +0000
Received: (qmail 20093 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 10914 invoked by uid 1114); 9 Nov 2004 19:29:54 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 09 Nov 2004 19:29:52 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9J7JqH051155; Tue, 9 Nov 2004 11:07:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9J7Jh4051154; Tue, 9 Nov 2004 11:07:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9J7HmT051090 for <[e-mail]>; Tue, 9 Nov 2004 11:07:18 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Nov 2004 19:07:12 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 19:05:32 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Briefing on CRL Path for IETF PKIX WG Meeting
Thread-Index: AcTGb6uqmFdvSd13QGCfcDcDRIxv2QAE3mLw
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Julien Stern" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 09 Nov 2004 19:07:12.0789 (UTC) FILETIME=[51C7D450:01C4C68F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA9J7ImT051148
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It seams that we have a problem with agreeing on the security
assumptions more than on the technical matters.

I recognize that Julien's scenario is a valid remark, at least in
theory. The point Julien is that there is a problem if an attacker that
has obtained a rouge CA under a valid root actually could fool an RP
software to accept the rouge path to the target certificate. IF the RP
accept the path over the rouge CA then that rouge CA could also defeat
the proposed algorithm.

The question is just if this is a valid threat or not.

Denis is making a valid remark that different CA's in the certificate
path may certify different CRL Issuers with the same name by accident
and the algorithm doesn't account for that.

The question is if this is a valid threat or not.

Both Denis and Julien's scenarios require intentional malicious
behaviour of the CRL issuer or the CDP and the IDP wouldn't match (the
storage location pointer would differ).

Both scenarios also require the attacker to convince the RP to NOT
obtain the correct CRL through the CDP pointer and instead accept the
rough CRL from other source OR it requires the attacker to hack the
server holding the real CRL and replace the real CRL with the rough CRL.

----------------

In Denis scenario I would suggest that we can exclude presence of a
rouge CA in the original certificate path, because if the original cert
path has a rouge CA, then all bets are off anyway.

This leaves us with Julien's scenario.

-----------------

So the main question is which of these threats that is in scope or out
of scope 

1) Presence of a trusted Rouge CA that is NOT part of the original
certificate path.

2) The ability of the attacker to fool the RP to pick a rouge path and
rouge CRL where the IDP and CDP match.


Questions/remarks:
- If both these threats are in scope then Julien's scenario is also
valid.
- If there threats are out of scope, then what threat remains that
requires Santosh algorithm in the first place?

I'm still pro Santosh algorithm since it limits complexity in path
processing but it would be good to know if there are any threats that
require Santosh algorithm which remains if at least problem 1 above is
out of scope.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTFci055639; Tue, 16 Nov 2004 11:29:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTFcP055638; Tue, 16 Nov 2004 11:29:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTDrJ055531 for <[e-mail]>; Tue, 16 Nov 2004 11:29:14 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25838 invoked by uid 1365); 16 Nov 2004 19:27:51 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:55 2004
Received: (qmail 24286 invoked from network); 16 Nov 2004 19:20:55 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:55 +0000
Received: (qmail 19982 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 15607 invoked by uid 1114); 10 Nov 2004 10:22:09 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 10:22:06 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA9nIFn080528; Wed, 10 Nov 2004 01:49:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA9nIZI080527; Wed, 10 Nov 2004 01:49:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA9nB59080354 for <[e-mail]>; Wed, 10 Nov 2004 01:49:15 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA09770; Wed, 10 Nov 2004 11:00:48 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111010484573:648 ; Wed, 10 Nov 2004 10:48:45 +0100 
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 10:48:45 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <002001c4c67a$1cbe4d80$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 10:48:45, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 10:48:48, Serialize complete at 10/11/2004 10:48:48
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

This was a response to Tom. It would be fair if you let Tom some time to 
respond to it.

See my two responses below.

> Denis.
> 
> See responses in-line in [SC:]
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Denis Pinkas
> Sent: Tuesday, November 09, 2004 9:18 AM
> To: Tom Gindin
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Tom,
> 
>>        Denis:
> 
>>Would a reasonable formulation of this rule be that a CRL Issuer
>>certificate governing the certificates of a given CA must have been 
>>directly issued by one of the certificates in the chain being verified 
>>(including the CA's own certificate), by the trust anchor for that chain, 
>>or by a certificate which is a rollover of one of the certificates in the 
>>first two grouips?  
> 
> 
> No. This would not be a good formulation, since two different CAs from the
> chain could choose the same DN to designate different CRL Issuers.
> 
> [SC: For indirect CRL to work, it is a fair assumption that two CAs will not
> share a name in the trust path nominated by the certificate issuing CA]

[DP: there is no such "fair assumption"].

> The RP needs to have an unambiguous way to know exactly which CA from the
> chain is the one which has nominated the CRL Issuer.
> 
> [SC: I suspect you mean that the relying party needs to have an unambiguous
> way to know exactly which authority was nominated as the indirect CRL Issuer
> by the certificate issuer.  

[DP: Your suspicion is incorrect. This is not what I said. Another way to 
express the same point would be:

"the relying party needs to have an unambiguous way to know exactly which CA 
has nominated the CRL Issuer, whose DN is present in the cRLIssuer field 
from the CRL DP extension".]

[SC: What you say does not make sense.]

See above.

Denis

> Denis
> 
> 
>>For this purpose, a certificate is a rollover of its
>>issuer certificate if it is self-issued but not self-signed, and the 
>>relationship is associative (i.e. if A is a rollover of B which is a 
>>rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D has
> 
> 
>>a CRL issuer and the path to D goes A (the anchor) to B to C to D, the CRL
> 
> 
>>issuer certificate may be issued by A, B, C, or D, or by B' in the case 
>>where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued 
>>through any other anchor nor through any CA whose DN is not in the path. 
>>Only one further liberalization of this rule might make sense, which is 
>>that C' would be considered a rollover of C on a path where C is issued by
> 
> 
>>B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels that 
>>this is safe?
>>        The good news about this heuristic is that it can be coded.  I 
>>think any of these variants resist Julien's attack, under the fairly 
>>reasonable assumptions that no CA issues certificates to bogus entities 
>>with its own name and that any CA which directly issued your 
>>cross-certificate and wants to have a CRL issuer masquerade as that CA can
> 
> 
>>do so by issuing a bogus CA cert just as easily as by issuing a bogus CRL 
>>Issuer one.
>>
>>                Tom Gindin




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTDnJ055625; Tue, 16 Nov 2004 11:29:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTDJv055620; Tue, 16 Nov 2004 11:29:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTBSu055498 for <[e-mail]>; Tue, 16 Nov 2004 11:29:11 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25826 invoked by uid 1365); 16 Nov 2004 19:27:51 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:54 2004
Received: (qmail 24251 invoked from network); 16 Nov 2004 19:20:54 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:54 +0000
Received: (qmail 19967 invoked by alias); 16 Nov 2004 19:20:49 +0000
Delivered-To: [e-mail]
Received: (qmail 5051 invoked by uid 1114); 16 Nov 2004 05:40:28 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 16 Nov 2004 05:40:25 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAG58qlc065502; Mon, 15 Nov 2004 21:08:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAG58qws065501; Mon, 15 Nov 2004 21:08:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAG58lCD065324 for <[e-mail]>; Mon, 15 Nov 2004 21:08:51 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAG58kG4465416 for <[e-mail]>; Tue, 16 Nov 2004 00:08:46 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAG58kJf238564 for <[e-mail]>; Tue, 16 Nov 2004 00:08:46 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAG58kFX027505 for <[e-mail]>; Tue, 16 Nov 2004 00:08:46 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAG58kvM027501; Tue, 16 Nov 2004 00:08:46 -0500
Subject: 3280 Issue - Are extra Anchor Parameters permitted?
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <[e-mail]>
From: Tom Gindin <[e-mail]>
Date: Tue, 16 Nov 2004 00:08:17 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF2 (6.53IBM1)|October 29, 2004) at 11/16/2004 00:08:45
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      David:

      This has come up on the list before, in late August and early
September.  However, it is an open issue in RFC 3280 whether or not
compliant path validation permits an RP to set variables corresponding to
the various constraint extensions, or whether it requires instead that the
variables corresponding to the constraint extensions always be initialized
to the values given in 6.1.2 b, c, and k.  I don't believe that anybody
thinks that support for setting those extensions to other values is
mandatory for compliance.

            Tom Gindin




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTDLS055624; Tue, 16 Nov 2004 11:29:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTDrE055619; Tue, 16 Nov 2004 11:29:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTB07055499 for <[e-mail]>; Tue, 16 Nov 2004 11:29:11 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25829 invoked by uid 1365); 16 Nov 2004 19:27:51 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:05 2004
Received: (qmail 24690 invoked from network); 16 Nov 2004 19:21:05 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:05 +0000
Received: (qmail 20135 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 25258 invoked by uid 1114); 15 Nov 2004 22:37:18 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 22:37:16 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMP5WA030015; Mon, 15 Nov 2004 14:25:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFMP5tL030014; Mon, 15 Nov 2004 14:25:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMP29W029997 for <[e-mail]>; Mon, 15 Nov 2004 14:25:02 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAFMOu2x011989; Mon, 15 Nov 2004 17:24:56 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAFMOLYB000248; Mon, 15 Nov 2004 17:24:21 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Nov 2004 17:00:22 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call: Certificate Schema
Cc: [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,TW_PK
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message initiates working group Last Call for the "LDAP Schema for 
X.509 Certificates"
specification. The editors have confirmed that all working group issues 
have been resolved.

The URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt

This specification has also been forwarded to the LDAP Directorate for a 
parallel review.  Assuming successful Last Call and concurrence from the 
LDAP Directorate, this document will be forwarded to the ADs for 
consideration as an Informational track RFC.

Last Call will run for (at least) two weeks. That is, Last Call will not 
close before November 29.

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTCt1055593; Tue, 16 Nov 2004 11:29:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTCfo055590; Tue, 16 Nov 2004 11:29:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTA2p055491 for <[e-mail]>; Tue, 16 Nov 2004 11:29:10 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25823 invoked by uid 1365); 16 Nov 2004 19:27:50 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:05 2004
Received: (qmail 24689 invoked from network); 16 Nov 2004 19:21:05 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:05 +0000
Received: (qmail 20123 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 13971 invoked by uid 1114); 15 Nov 2004 07:58:58 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 07:58:56 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF7Txk2043863; Sun, 14 Nov 2004 23:29:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAF7TxbA043862; Sun, 14 Nov 2004 23:29:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF7TwNe043832 for <[e-mail]>; Sun, 14 Nov 2004 23:29:58 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id IAA43254; Mon, 15 Nov 2004 08:42:02 +0100
Received: from bull.net ([129.181.81.63]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111508295039:1073 ; Mon, 15 Nov 2004 08:29:50 +0100 
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 08:31:09 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: pkix <[e-mail]>
Subject: 3280bis: root CA key update (self-issued certificates)
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/15/2004 08:29:51 AM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/15/2004 08:29:53 AM, Serialize complete at 11/15/2004 08:29:53 AM
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=windows-1252; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In RFC 2510, there are explanations about the means to update
a root key. These explanations should be incorporated into 3280bis
since they are not part of a "management protocol" but simply the
generation of self-issued certificates that are placed in a repository.

It is proposed to define what a self-issued certificate is:

self-issued certificate: a public-key certificate where the issuer
and the subject are the same CA. A CA may use self-issued
certificates, for example, during a key rollover operation to provide
trust from the old key to the new key.

The following text is a proposal based on the text from section 2.4
of RFC 2510 to be incorporated in 3280bis:

X. Root CA key update

This discussion only applies to CAs that are considered to be
a trust anchor for some relying party.

A graceful, scheduled change-over from one non-compromised CA
key pair to the next (CA key update) must be supported (note
that if the CA key is compromised, re-initialization must be
performed for all relying parties trusting that CA).

The basis of the procedure described here is that the CA protects
its new public key using its previous private key and vice versa.

Thus when a CA updates its key pair using this procedure it must
generate three self-issued CA certificates if these certificates
are made available using a repository.

The data structure used to protect the new and old CA public keys is
a self-issued certificate (which may contain certificate extensions).

X.1 CA Operator actions

To change the root key of the CA using this procedure, the CA operator
does the following:

1. Generate a new key pair;

2. Create a certificate containing the old CA public key signed
with the new private key (the "old with new" certificate);

3. Create a certificate containing the new CA public key signed
with the old private key (the "new with old" certificate);

4. Create a certificate containing the new CA public key signed
with the new private key (the "new with new" certificate);

5. Publish these certificates in a repository and/or via other
means;

The "old with new" certificate must have a validity period starting
at the generation time of the old key pair and ending at the expiry
date of the old public key.

The "new with old" certificate must have a validity period starting
at the generation time of the new key pair and ending at the time by
which all relying parties of this CA will securely possess the new CA
public key (at the latest, the expiry date of the old public key).

The "new with new" certificate must have a validity period starting
at the generation time of the new key pair and ending at the time by
which relying parties will no more be trusting the public key
contained in the self-signed certificate.

This scheme forces relying parties to acquire the new CA
self-signed certificate before the expiry of the last self-signed
certificate they trusted that was signed with the old CA private
key (via the "out-of-band" means).

At a given time a total of four self-issued certificates will exist:
OldWithOld; OldWithNew; NewWithOld; and NewWithNew.

X.2. Relying party actions

All relying parties require secure local access to some information,
at a minimum, the name of a CA which is directly trusted by this
entity and that CA's public key, or a self-signed certificate of
a CA. Such local trusted storage is referred to here as the relying
party's Personal Security Environment (PSE).

A relying party may directly obtain using out-of-bands means the
“new with new" certificate. The PSE will then contain two self-
signed certificates, i.e. “old with old" certificate and “new with
new" certificate.

When “out-of bands means” are or cannot be used, a relying party
which only has “old with old" certificate, will need to obtain from
a repository both, the "new with new" certificate and the "new
with old" certificate. It will then verify the "new with old"
certificate using the old key and after acquiring the new CA public
key will verify the "new with new" certificate. The PSE will then
contain two self-signed certificates: the "old with old"
certificate and the "new with new" certificate.

There may be however cases where it is not possible to update the
PSE (e.g. it is "hardwired" into the end entity's cryptographic
equipment). Such relying parties, will need keep in a secondary
storage the two certificates they have acquired and this will allow
relying parties to continue to check certificates up to the end of
the validity period of the “old by old” self-signed certificate.

Finally it may happen that a relying party is only installed with
the "new with new" certificate. Those relying parties will need to
acquire from a repository the “old with new” certificate so that
they may be able to verify certificates issued using the old key.


Denis





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTB1F055570; Tue, 16 Nov 2004 11:29:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTBHj055565; Tue, 16 Nov 2004 11:29:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT8oo055445 for <[e-mail]>; Tue, 16 Nov 2004 11:29:08 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25814 invoked by uid 1365); 16 Nov 2004 19:27:50 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:05 2004
Received: (qmail 24675 invoked from network); 16 Nov 2004 19:21:04 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:04 +0000
Received: (qmail 20129 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 24972 invoked by uid 1114); 12 Nov 2004 05:33:09 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Fri, 12 Nov 2004 05:33:07 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAC59V7a017321; Thu, 11 Nov 2004 21:09:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAC59Vhg017320; Thu, 11 Nov 2004 21:09:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAC59U1a017305 for <[e-mail]>; Thu, 11 Nov 2004 21:09:30 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAC59aMW363774 for <[e-mail]>; Fri, 12 Nov 2004 00:09:36 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAC59Q72289214 for <[e-mail]>; Fri, 12 Nov 2004 00:09:26 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAC59Qh1013636 for <[e-mail]>; Fri, 12 Nov 2004 00:09:26 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAC59QxW013633; Fri, 12 Nov 2004 00:09:26 -0500
In-Reply-To: <005401c4c81b$99f48e70$[e-mail]>
To: "Manuel Gil Perez" <[e-mail]>, [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: Bridge CA and crossCertificatePair
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 12 Nov 2004 00:09:23 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF1|October 13, 2004) at 11/12/2004 00:09:25, Serialize complete at 11/12/2004 00:09:25
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAC59U1a017307
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Manuel:

        CrossCertificatePair has AFAIK always been considered to be a 
multi-valued attribute, as you can see from (for example) RFC 2587 section 
3.2 where the existence of multiple CA Certificates in the caCertificate 
attribute and of multiple 'forward' elements in the crossCertificatePair 
attribute is discussed in consecutive paragraphs.  However, the 
certpathbuild draft lists userCertificate and caCertificate as 
multi-valued but doesn't make that statement about CrossCertificatePair. 
It should probably change to do so, unless it's too late in the process.
        Please note that the syntax of caCertificate is just a 
certificate, not a sequence of them.

                Tom Gindin






"Manuel Gil Perez" <[e-mail]>
Sent by: [e-mail]
11/11/2004 01:23 PM
Please respond to "Manuel Gil Perez"
 
        To:     <[e-mail]>
        cc: 
        Subject:        Bridge CA and crossCertificatePair



Dear PKIX members,

I need to develop a bridge CA where it must store one or more 
cross-certificates. Revising the RFCs (about LDAP, X.509, etc.) and 
looking 
up on the web I conclude that it is technically possible (in accordance 
with 
RFC 3280) to store one or more cross-certificate into my bridge CA (this 
value is multi-valued).

But really, according to the specification (see below), I can only store 
one 
pair of cross-certificates. Is it possible that the attribute 
CertificatePair is not correct and should be changed for the following??

CertificatePair ::= SEQUENCE SIZE(1..MAX) OF CertificateForwardReverse;

CertificateForwardReverse ::= SEQUENCE {
   forward [0] Certificate OPTIONAL,
   reverse [1] Certificate OPTIONAL,
   -- at least one of the pair shall be present -- }

In any case... can somebody send me the correct specification for the 
attribute CertificatePair??

Many thanks, and best regards...

------
Manuel Gil Pérez
http://pki.umu.euro6ix.org


======

pkiCA OBJECT-CLASS ::= {
   SUBCLASS OF { top}
   KIND auxiliary
   MAY CONTAIN {
      cACertificate |
      certificateRevocationList |
      authorityRevocationList |
      crossCertificatePair }
   ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22) }

crossCertificatePair ATTRIBUTE ::= {
   WITH SYNTAX CertificatePair
   EQUALITY MATCHING RULE certificatePairExactMatch
    ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40) 
}

CertificatePair ::= SEQUENCE {
   forward [0] Certificate OPTIONAL,
   reverse [1] Certificate OPTIONAL,
   -- at least one of the pair shall be present -- } 







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTBBj055572; Tue, 16 Nov 2004 11:29:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTBxP055567; Tue, 16 Nov 2004 11:29:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT3R8055374 for <[e-mail]>; Tue, 16 Nov 2004 11:29:04 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25799 invoked by uid 1365); 16 Nov 2004 19:27:50 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:52 2004
Received: (qmail 24211 invoked from network); 16 Nov 2004 19:20:52 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:52 +0000
Received: (qmail 19952 invoked by alias); 16 Nov 2004 19:20:49 +0000
Delivered-To: [e-mail]
Received: (qmail 19948 invoked by uid 1114); 10 Nov 2004 22:54:49 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 22:54:46 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAMbXa1040448; Wed, 10 Nov 2004 14:37:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAMbXkR040447; Wed, 10 Nov 2004 14:37:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAAMbWp0040411 for <[e-mail]>; Wed, 10 Nov 2004 14:37:32 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 10997 invoked by uid 0); 10 Nov 2004 22:37:25 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (130.129.135.212) by woodstock.binhost.com with SMTP; 10 Nov 2004 22:37:25 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Wed, 10 Nov 2004 17:28:34 -0500
To: ChungKil Kim <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: DVCS ASN.1 module definition error
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Looks like a bug to me.  Peter, can you send the RFC Editor an errata entry.

Russ

At 03:02 AM 11/5/2004, ChungKil Kim wrote:

>hi there.
>
>i found asn.1 definition error.
>see following definition(rfc3029 Page 15).
>
>
>Data ::= CHOICE {
>message OCTET STRING ,
>messageImprint DigestInfo,
>certs SEQUENCE SIZE (1..MAX) OF
>TargetEtcChain
>}
>
>DigestInfo ::= SEQUENCE {
>digestAlgorithm DigestAlgorithmIdentifier,
>digest Digest
>}
>
>messageImprint and certs have same tag type. it can't be CHOICE. right?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJTBKA055566; Tue, 16 Nov 2004 11:29:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJTB27055563; Tue, 16 Nov 2004 11:29:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT9gr055463 for <[e-mail]>; Tue, 16 Nov 2004 11:29:09 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25856 invoked by uid 1365); 16 Nov 2004 19:27:51 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:56 2004
Received: (qmail 24317 invoked from network); 16 Nov 2004 19:20:56 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:56 +0000
Received: (qmail 19988 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 14156 invoked by uid 1114); 10 Nov 2004 14:40:54 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 14:40:52 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAELefZ044295; Wed, 10 Nov 2004 06:21:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAELeDQ044293; Wed, 10 Nov 2004 06:21:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAELeKX044287 for <[e-mail]>; Wed, 10 Nov 2004 06:21:40 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (ASQ2-127-115.usae.bah.com [156.80.127.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iAAELftg004013 for <[e-mail]>; Wed, 10 Nov 2004 09:21:41 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Wed, 10 Nov 2004 09:21:35 -0500
Message-ID: <000401c4c730$990f7060$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAAELeKX044288
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

We are not communicating effectively.  I am sure others are not following us
either.

I will glad to discuss things with you after the PKIX meeting today, if you
are around.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Wednesday, November 10, 2004 7:40 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



Santosh,

My response with [DP: ]

As to circularity, the problem is as follows.

Let us say CA A delegates the CRL issuance to Authority B.  Your proposal
requires that A issue a certificate to B will get in the way of a CA not
issuing CRLs because if the CA does not issue CRL, how would the revocation
status of certificate A --> B be checked?

[DP: I would rephrase the problem in the following way:

Let us say CA A delegates the CRL issuance to CRL Issuer B. This requires
that CA A issues a CRL Issuer certificate to CRL Issuer B.

The question you asked is then:
"How to make sure that this CRL Issuer certificate is not revoked ?"

This depends what kind of information tha CA A places in the CRL DP
extension of the CRL Issuer certificate issued to CRL Issuer B.

There are, at least, two answers:

1) there is no cRLIssuer field in the CRL DP extension:
    this means that the CA is directly taking care of the revocation
    status of its CRL Issuers: it will issue CRLs only for the
    CRL Issuers.

2) there is no CRL DP extension at all:
    this would mean that the CA does not issue CRLs for its CRL Issuers.
    In case one of the CRL issuers would need to be revoked, it will ask
    its "normal" upper CA to revoke its own certificate. By implication,
    the CRL Issuer certificate that was issued would become invalid.]

Both approaches have advantages and disavantages.
Anyway, thank you for raising the question.

Denis





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT8Id055529; Tue, 16 Nov 2004 11:29:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJT80O055528; Tue, 16 Nov 2004 11:29:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT7og055432 for <[e-mail]>; Tue, 16 Nov 2004 11:29:07 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25811 invoked by uid 1365); 16 Nov 2004 19:27:50 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:52 2004
Received: (qmail 24229 invoked from network); 16 Nov 2004 19:20:52 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:52 +0000
Received: (qmail 19925 invoked by alias); 16 Nov 2004 19:20:49 +0000
Delivered-To: [e-mail]
Received: (qmail 19346 invoked by uid 1114); 16 Nov 2004 19:15:59 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 16 Nov 2004 19:15:57 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGIwiLO041720; Tue, 16 Nov 2004 10:58:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGIwivS041719; Tue, 16 Nov 2004 10:58:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGIwgNG041669 for <[e-mail]>; Tue, 16 Nov 2004 10:58:43 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAGIwin09626; Tue, 16 Nov 2004 19:58:44 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 16 Nov 2004 19:58:44 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAGIwhU02280; Tue, 16 Nov 2004 19:58:43 +0100 (MET)
Date: Tue, 16 Nov 2004 19:58:43 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: 3280bis: name constraints
Cc: [e-mail]
X-Sun-Charset: US-ASCII
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> The fact that the extension is a name constraint becomes immaterial if the 
> path building software chooses to ignore it.
> The software may ignore the extension if it is marked as non critical,  as 
> per rfc 3280.
> 
> In practice, there may be some benefits to marking the name constraint 
> extension non critical.
> RP may configure the path building software to ignore/enforce the extension 
> based on the importance of the transaction.
> e.g. - for email validation, the RP may configure the path validation 
> software to ignore name constraints.
>       - for a million dollar internet transaction, the RP may configure the 
> software to always enforce name constraints.

RP software may also simply not be able to support constraints
And since this is actually a constraint for CAs, consequences of violation
may be enforcable by organisational means. "Dear CA, we told you not to
issue certs with these constraints." 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT6pB055501; Tue, 16 Nov 2004 11:29:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJT6f8055500; Tue, 16 Nov 2004 11:29:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT3uS055372 for <[e-mail]>; Tue, 16 Nov 2004 11:29:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25790 invoked by uid 1365); 16 Nov 2004 19:27:50 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:52 2004
Received: (qmail 24209 invoked from network); 16 Nov 2004 19:20:52 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:52 +0000
Received: (qmail 19926 invoked by alias); 16 Nov 2004 19:20:49 +0000
Delivered-To: [e-mail]
Received: (qmail 30077 invoked by uid 1114); 10 Nov 2004 02:32:45 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 02:32:41 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA29hRc019013; Tue, 9 Nov 2004 18:09:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA29hmA019012; Tue, 9 Nov 2004 18:09:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA29gRR019006 for <[e-mail]>; Tue, 9 Nov 2004 18:09:42 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id iAA29mT0426954 for <[e-mail]>; Tue, 9 Nov 2004 21:09:48 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAA29mZY251100 for <[e-mail]>; Tue, 9 Nov 2004 21:09:48 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAA29l2f027457 for <[e-mail]>; Tue, 9 Nov 2004 21:09:47 -0500
Received: from d01mc062.pok.ibm.com (d01mc062.pok.ibm.com [9.56.227.225]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAA29lfn027440; Tue, 9 Nov 2004 21:09:47 -0500
In-Reply-To: <007c01c4c6a0$8118ce10$[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
To: "Santosh Chokhani" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <[e-mail]>
From: Tom Gindin <[e-mail]>
Date: Tue, 9 Nov 2004 21:07:38 -0500
X-MIMETrack: Serialize by Router on D01MC062/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 11/09/2004 21:09:46
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Santosh:

      I apologize for not having realized exactly how close the effects of
your algorithm and mine actually are.  I started from some of Denis'
formulations without having fully analyzed your initialization part 3, and
rederived something very close to yours.  In practice, the difference
between the matching algorithms mainly reduces to the difference between
"the subject and issuer DN's of the non-self-issued certificates must
match" and "must be the same certificate or a rollover thereof", and your
formulation allows a superior CA to rekey its subordinate without any
rollovers while mine forbids that.  Of course, I'm not really sure why the
issuer DN's need to be compared separately, since Issuer (N) must match
Subject (N-1) and the subjects are being compared.
      More substantively, I don't understand why it's permissible in your
algorithm for NCert to be NCRL-2 or NCRL-3, which corresponds to a
subordinate CA issuing its superior's CRL Issuer certificate.  In mine,
NCert may never be less than NCRL.  This difference does allow an attack
against yours which doesn't work against mine, but it is not an "unrelated
CA" attack.  Instead, it's a case of a subordinate CA of the EE's issuer
issuing a CRL Issuer certificate with the same DN (but a different key) as
that used in the EE certificate.
      In view of the minimal effective differences, it is probably
reasonable to consider my technique an optimization of yours in that it
doesn't need to perform independent path building.  You can easily enough
get rid of the difference cited in my second paragraph by replacing your
MIN step by "Verify that NCert >= NCRL", and using NCRL as the upper bound
of the loop.

            Tom Gindin




                                                                                                                                       
                      "Santosh                                                                                                         
                      Chokhani"                To:       <[e-mail]>                                                           
                      <chokhani@orionse        cc:                                                                                     
                      c.com>                   Subject:  RE: Briefing on CRL Path for IETF PKIX WG Meeting                             
                      Sent by:                                                                                                         
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      11/09/2004 04:10                                                                                                 
                      PM                                                                                                               
                                                                                                                                       





Tom,

Can you explain the following from your post in relation of CRL path
matching and how you mitigate it and CRL path matching does not.  I quote
you:

"In replying to Santosh, you have discussed attacks which come from
unrelated CA's as the primary security threat associated with CRL issuers.
I agree with that, and have blocked those."

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Gindin
Sent: Tuesday, November 09, 2004 1:40 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



        Denis:

        It is indeed possible for two CA's to choose the same CRL issuer
DN, while meaning two distinct entities.  However, what are the
consequences?  In one case, a CA which has certified a subordinate CA can
"take over" the issuer ID of that subordinate (outside hierarchies, only
RP's who are trusting the CA through the issuer of that cross-certificate
are affected).  In the other, a CA which originally delegated revocation
to its superior can reclaim it.  Which of these is an attack?
        I don't know why the RP needs a rule which declares "a CRL issuer
must be certified by the CA whose certificates it is issuing a CRL for",
and which prohibits subordinate CA's from having their hierarchical
superior issue CRL's for them.  In replying to Santosh, you have discussed
attacks which come from unrelated CA's as the primary security threat
associated with CRL issuers.  I agree with that, and have blocked those.
        BTW, Santosh is right that a certificate issued to a CRL Issuer by
a CA which ordinarily delegates CRL's to that issuer is not practically
revocable by CRL.  However, IMO a certificate may be useful even if a
revocation check on it is not feasible.  Much client software checks
certificate chains without checking revocation, being satisfied with the
certification that "this key pair was once possessed by the subject". This
applies equally to self-issued certificates.
        Before declaring that a rule should (or should not) prevent the
use of a superior CA's CRL Issuer to produce CRL's for a subordinate CA,
we should probably find out if anybody actually does that.  I hope that
nobody actually has sibling CA's producing their CRL's.

                Tom Gindin






Denis Pinkas <[e-mail]>
11/09/2004 09:17 AM

        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     [e-mail]
        Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting


Tom,

>         Denis:

> Would a reasonable formulation of this rule be that a CRL Issuer
> certificate governing the certificates of a given CA must have been
> directly issued by one of the certificates in the chain being verified
> (including the CA's own certificate), by the trust anchor for that
chain,
> or by a certificate which is a rollover of one of the certificates in
the
> first two grouips?

No. This would not be a good formulation, since two different CAs from the
chain could choose the same DN to designate different CRL Issuers.

The RP needs to have an unambiguous way to know exactly which CA from the
chain is the one which has nominated the CRL Issuer.

Denis

> For this purpose, a certificate is a rollover of its
> issuer certificate if it is self-issued but not self-signed, and the
> relationship is associative (i.e. if A is a rollover of B which is a
> rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D
has
> a CRL issuer and the path to D goes A (the anchor) to B to C to D, the
CRL
> issuer certificate may be issued by A, B, C, or D, or by B' in the
> case
> where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued

> through any other anchor nor through any CA whose DN is not in the
> path.

> Only one further liberalization of this rule might make sense, which
> is
> that C' would be considered a rollover of C on a path where C is issued
by
> B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels
> that

> this is safe?
>         The good news about this heuristic is that it can be coded.  I
> think any of these variants resist Julien's attack, under the fairly
> reasonable assumptions that no CA issues certificates to bogus entities
> with its own name and that any CA which directly issued your
> cross-certificate and wants to have a CRL issuer masquerade as that CA
can
> do so by issuing a bogus CA cert just as easily as by issuing a bogus
CRL
> Issuer one.
>
>                 Tom Gindin
>
>
>
>
>
>
> Denis Pinkas <[e-mail]>
> Sent by: [e-mail]
> 11/05/2004 10:04 AM
>
>         To:     Santosh Chokhani <[e-mail]>
>         cc:     [e-mail]
>         Subject:        Re: Briefing on CRL Path for IETF PKIX WG
Meeting
>
>
>
> Santosh,
>
>
>>Denis,
>>
>>See responses in-line in [SC:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, November 04, 2004 12:40 PM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>Santosh,
>>
>>See responses in-line in [DP:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Wednesday, November 03, 2004 9:48 AM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>Santosh,
>>
>> > Denis,
>>
>> > The matching algorithm proposed checks/compares the ancestors.
>>
>>The matching algorithm is missing to say "who" trusts "somebody" for
>
> "what".
>
>>Unless this is clearly said, there is no trust possible and thus no
>>algorithm possible.
>>
>>[SC: The two paths needs to be verified in accordance with 3280 in
>>order

>
> to
>
>>establish trust]
>>
>>[DP: the certification path needs to be verified according to RFC
>>3280.
>
> The
>
>>problem is that RFC 3280 does not tell how to verify that the CRL
>>comes
>>from the right CRL Issuer. Your assumption that the "two paths needs to
>
> be
>
>>verified in accordance with 3280 in order to establish trust" is thus
>>incorrect].
>>
>>[SC: When you augment 3280 with the algorithm I proposed, that takes
>
> care of
>
>>it.  It goes without saying that 3280 needs to be augmented with the
>>algorithm]
>
>
> This is exactly what I disagree with.
>
> Let us talk about the key issue. The question is: how can a RP
> (relying
> party) know that, for a given end-user certificate, the CRL he got is
> indeed
> issued by the right CRL Issuer ?
>
> In the following discussion, I am only considering the case where the
CRL
> Issuer is *not* the CA (this CA is called CA 1).
>
> CA 2 is a CA that has issued a CA certificate to CA 1.
>
> The text is currently so vague that different models are indeed
> theoritically possible. In particular:
>
>   a) the CRL Issuer is nominated by CA 1 that has issued
>      the end-user certificate. This case would make sense
>      when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>      that role to one or more CRL Issuers. This means that
>      a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
>
>   b) the CRL Issuer is nominated by CA 2 that has issued a CA
>      certificate to CA 1. This case would make sense when CA 2
>      has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>      certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>      then only choose a CRL Issuer that has been granted
>      the authorization to issue CRLs by CA 2.
>
> I wonder if I understand correctly the model you proposed, but (please
> correct if wrong) you have a set of trust points to verify the
> certification
> chain, and another set of trust points to verify what you call a
> certification path for the CRL Issuer.
>
> There would be many problems with such a model to define correctly
> validation policies, since the two chains would be unrelated and any CA
> from
> that chain could nominate CRL Issuers used by any CA.
>
> In options a) and b) mentioned above, a single trust point is used to
> validate both the certification chain and the CRL Issuer.
>
> In any case, we need to clarify this topic in 3280bis, whatever the
> clarification will be.
>
>
>>This algorithm is nothing more than formalism of something you agreed
>>to in 2003 on this list.
>>
>>I don't think so.
>>
>>[SC: Go back to September 2003 archive of your response to my post and
>
> tell
>
>>me what is not covered]
>>
>>[DP: You would need to be more precise and provide me an extract of
>>what

>
> you
>
>>refer to]
>>
>>[SC: It was short string of e-mails on the subject matter in September
>
> 2003.
>
> Hum !!! Hum !!!
> Do not mention "free" assertions when you are not sure about.
>
> Denis
>
>
>>I am sure you can find it from the archives.  It may be overcome by
>
> events
>
>>since your recent postings show that you agree with me]
>>
>>Denis
>
>
>
>
>
>
>








Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT53J055488; Tue, 16 Nov 2004 11:29:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJT5lw055487; Tue, 16 Nov 2004 11:29:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT3N4055373 for <[e-mail]>; Tue, 16 Nov 2004 11:29:04 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25793 invoked by uid 1365); 16 Nov 2004 19:27:50 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:00 2004
Received: (qmail 24488 invoked from network); 16 Nov 2004 19:21:00 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:00 +0000
Received: (qmail 20033 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 14184 invoked by uid 1114); 10 Nov 2004 14:40:56 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 14:40:53 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEJh7E043470; Wed, 10 Nov 2004 06:19:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAEJhJT043469; Wed, 10 Nov 2004 06:19:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEJght043403 for <[e-mail]>; Wed, 10 Nov 2004 06:19:42 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAAEJSD03881; Wed, 10 Nov 2004 15:19:28 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 10 Nov 2004 15:19:28 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAAEJRh24307; Wed, 10 Nov 2004 15:19:27 +0100 (MET)
Date: Wed, 10 Nov 2004 15:19:27 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Cc: [e-mail]
X-Sun-Charset: US-ASCII
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

3280 5.1.1.3:  

   CRL checking in turn requires a separate
   certification path to be constructed and validated for the CA's CRL
   signature validation certificate. Applications that perform CRL
   checking MUST support certification path validation when certificates
                         XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   and CRLs are digitally signed with the same CA private key.  These
   applications SHOULD support certification path validation when
                               XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   certificates and CRLs are digitally signed with different CA private
   keys.

what 'certification path validation' is meant here? 
I guess the validation of the initial certificate? 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT2TT055442; Tue, 16 Nov 2004 11:29:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJT2vm055441; Tue, 16 Nov 2004 11:29:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT1Au055351 for <[e-mail]>; Tue, 16 Nov 2004 11:29:01 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25784 invoked by uid 1365); 16 Nov 2004 19:27:49 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:50 2004
Received: (qmail 24201 invoked from network); 16 Nov 2004 19:20:50 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:50 +0000
Received: (qmail 19954 invoked by alias); 16 Nov 2004 19:20:49 +0000
Delivered-To: [e-mail]
Received: (qmail 14207 invoked by uid 1114); 10 Nov 2004 14:40:57 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 14:40:53 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAECdu8040666; Wed, 10 Nov 2004 06:12:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAECdaL040665; Wed, 10 Nov 2004 06:12:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAECZlN040571 for <[e-mail]>; Wed, 10 Nov 2004 06:12:38 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 10 Nov 2004 15:12:24 +0100
Date: Wed, 10 Nov 2004 15:12:25 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: several key in same certificate
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.65
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.65 on Emacs 21.3 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Wed, 10 Nov 2004 14:00:22 +0100, [e-mail] said:

yquenechdu> it is possible to have several key in the same certificate ?
yquenechdu> if so, which document refers to that.

Well...  if we use our imagination a little bit, it's perfectly
possible to have more public keys in certificate extensions :-).
There's no document that I know covering this, as the idea came
to my mind just now, prompted by your question.  I've no idea if
someone has done something like that or not...

So, in all seriousness, I will assume that you're really asking about
public keys that are used for certificate verification, and in that
case, what you ask is certainly not possible, and it should be
apparent if you read RFC 3280 or X.509 accurately.

Now, to get a real discussion going (if you want), why do you want to
have more than one public key in your certificate?  What would they be
used for, and most specifically, how would the appropriate key be
selected for the operation you want to perform?

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT2Qe055431; Tue, 16 Nov 2004 11:29:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJT2G7055430; Tue, 16 Nov 2004 11:29:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJT0jh055336 for <[e-mail]>; Tue, 16 Nov 2004 11:29:01 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25781 invoked by uid 1365); 16 Nov 2004 19:27:49 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:04 2004
Received: (qmail 24653 invoked from network); 16 Nov 2004 19:21:04 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:04 +0000
Received: (qmail 20120 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 2524 invoked by uid 1114); 14 Nov 2004 03:20:14 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Sun, 14 Nov 2004 03:20:13 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAE2dMi6002878; Sat, 13 Nov 2004 18:39:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAE2dM2O002877; Sat, 13 Nov 2004 18:39:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.quimbik.com (mail1.quimbik.com [198.87.27.232]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAE2dLYK002856 for <[e-mail]>; Sat, 13 Nov 2004 18:39:21 -0800 (PST) (envelope-from [e-mail])
Received: from nma.com (adsl-63-204-17-85.dsl.snfc21.pacbell.net [63.204.17.85]) by mail1.quimbik.com (Postfix) with ESMTP id F2AF233C4D4; Sat, 13 Nov 2004 18:39:10 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 13 Nov 2004 18:39:09 -0800
From: Ed Gerck <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: [e-mail], pkix <[e-mail]>
Subject: Re: 3280bis: certificate revocation status responsibility (1/3)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas wrote:


> Hereafter is a proposal:
> 
> "X. Certificate revocation status responsibility
> 
> The authority that issues certificates (public-key or attribute) has
> the responsibility to indicate the revocation status of certificates
> it issues. Generally, certificates are subject to possible subsequent
> revocation. This revocation, and notification of the revocation may be
> done directly by the same authority that issued the certificate, or
> indirectly by another authority duly authorized by the authority that
> issued the certificate."

This addition, considering how many questions I received when recently
stating the same in the ID draft-gerck-pkix-revocation-01.txt, seems to
be quite necessary.

Because the revocation status of a certificate refers to conditions that
a conforming issuer CA authoritatively defines for each certificate
(for example, revocation is delegated to X), this addition makes clear
that in PKIX a certificate is either revoked or not revoked. It does not
matter who you ask.

> RFC 3280 does not provide a formal definition for an indirect CRL, but
> it could be inferred from the content of section 5, whenever the CRL
> issuer is not the CA that issued the certificates, the CRL is referred
> to as an indirect CRL.
> 
> Proposed definition:
> 
> "indirect CRL: A revocation list that is not issued directly by a CA
> but by authority duly authorized by a CA".

Again, this clarification seems necessary.

> Other parts of RFC 3280 explain that an indirect CRL may be understood
> as a revocation list that provides revocation information about
> certificates either issued by:
> 
>    a) a single CA, or
>    b) multiple CAs.
> 
> In case a), called "indirect CRL of type a)", an indirect CRL provides
> revocation information for certificates issued by one CA, and for
> which a delegation has been granted by that CA.
> 
> In case b), called "indirect CRL of type b)", an indirect CRL still
> provides revocation information for certificates issued by one CA, but
> also for certificates issued by others CAs.
> 
> It should then be explained how a relying party may verify that
> delegation has indeed been granted by a CA to a CRL Issuer.
> 
> The following text is proposed to be happened after the previous
> proposed text:
> 
> "Assuming that the relying party has found a candidate CRL, the DN
> contained in the issuer field from the CRL SHALL match the subject DN
> contained a CRL Issuer certificate (i.e. a certificate which has the
> cRLSign bit set in the keyUsage extension) issued to the CRL Issuer by
> the CA that has issued the certificate to be tested.
> 
> In order to prevent DN ambiguity, the CRL Issuer SHALL not accept to
> manage revocation status information for a given CA DN, if it already
> manages revocation status information for another CA that has the same
> DN."

However, because multiple mechanisms are available to an issuer CA to
define revocation, CAs with the same DN could use different mechanisms
without ambiguity (even if we just distinguish CAs by their DNs). These
mechanisms include a CDP extension with a URI DistributionPointName, an
AIA extension with an OCSP access descriptor, and an AIA extension with
an HTTP CRL access descriptor.

Could your proposal reflect these possiblitities as well?


Cheers,
Ed Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSwv0055386; Tue, 16 Nov 2004 11:28:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSwbF055379; Tue, 16 Nov 2004 11:28:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSsb0055254 for <[e-mail]>; Tue, 16 Nov 2004 11:28:56 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25820 invoked by uid 1365); 16 Nov 2004 19:27:50 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:54 2004
Received: (qmail 24243 invoked from network); 16 Nov 2004 19:20:54 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:54 +0000
Received: (qmail 19975 invoked by alias); 16 Nov 2004 19:20:49 +0000
Delivered-To: [e-mail]
Received: (qmail 25280 invoked by uid 1114); 15 Nov 2004 22:37:33 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 22:37:31 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMP9E4030041; Mon, 15 Nov 2004 14:25:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFMP906030039; Mon, 15 Nov 2004 14:25:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMP7Qj030021 for <[e-mail]>; Mon, 15 Nov 2004 14:25:07 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAFMOvmc009907; Mon, 15 Nov 2004 17:24:57 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAFMOcYB000413; Mon, 15 Nov 2004 17:24:38 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Nov 2004 17:26:40 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call: CRL Schema
Cc: [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message initiates working group Last Call for the "LDAP Schema for 
X.509 CRLs" specification. The editors have confirmed that all working 
group issues have been resolved.

The URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-03.txt

This specification has also been forwarded to the LDAP Directorate for a 
parallel review.  Assuming successful Last Call and concurrence from the 
LDAP Directorate, this document will be forwarded to the ADs for 
consideration as an Informational track RFC.

Last Call will run for (at least) two weeks. That is, Last Call will not 
close before November 29.

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSvag055361; Tue, 16 Nov 2004 11:28:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSvMM055360; Tue, 16 Nov 2004 11:28:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSpxd055230 for <[e-mail]>; Tue, 16 Nov 2004 11:28:55 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25778 invoked by uid 1365); 16 Nov 2004 19:27:49 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:01 2004
Received: (qmail 24048 invoked from network); 16 Nov 2004 19:20:01 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:01 +0000
Received: (qmail 19798 invoked by alias); 16 Nov 2004 19:20:01 +0000
Delivered-To: [e-mail]
Received: (qmail 20316 invoked by uid 1114); 10 Nov 2004 15:18:20 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 15:18:18 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEwFqO055987; Wed, 10 Nov 2004 06:58:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAEwF48055986; Wed, 10 Nov 2004 06:58:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEwExQ055941 for <[e-mail]>; Wed, 10 Nov 2004 06:58:14 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Nov 2004 14:58:09 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Wed, 10 Nov 2004 14:58:22 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Briefing on CRL Path for IETF PKIX WG Meeting
Thread-Index: AcTHCoypbgfSJ6UJQISxer5tDzY27gAKetQb
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 10 Nov 2004 14:58:09.0756 (UTC) FILETIME=[B173B1C0:01C4C735]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAAEwExQ055981
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,
 
<snip>
>Denis is making a valid remark that different CA's in the certificate
>path may certify different CRL Issuers with the same name by accident
>
>[DP: Thank you for the acknowledgment]
>
>and the algorithm doesn't account for that.
>
>[Santosh: since you intercept every mail, I guess you will notice that
>Stefan mentions that your algorithm has indeed a problem].

I didn't say that. My conclusion was that this is only applicable to indirect CRLs where IDP/CDP match is required, which mitigates this issue (unless you have a rouge CA).
 
I guess this also address the rest of your remarks.
 
 
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSwVx055385; Tue, 16 Nov 2004 11:28:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSwew055378; Tue, 16 Nov 2004 11:28:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSsj8055253 for <[e-mail]>; Tue, 16 Nov 2004 11:28:56 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25808 invoked by uid 1365); 16 Nov 2004 19:27:50 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:04 2004
Received: (qmail 24674 invoked from network); 16 Nov 2004 19:21:04 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:04 +0000
Received: (qmail 20227 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 32621 invoked by uid 1114); 15 Nov 2004 23:48:28 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 23:48:26 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFNWvnH048449; Mon, 15 Nov 2004 15:32:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFNWvEK048448; Mon, 15 Nov 2004 15:32:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFNWu0p048441 for <[e-mail]>; Mon, 15 Nov 2004 15:32:56 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-30.mail.demon.net with esmtp (Exim 4.42) id 1CTqLA-000Fej-2G; Mon, 15 Nov 2004 23:32:56 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 23:33:42 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David A. Cooper wrote:
> 
> X.509 does have a rule that one must reject a critical extension unless 
> you can process all of the fields in the extension. So, for name 
> constraints, if a critical nameConstraints extension includes a 
> constraint on a name form and that name form appears in the subject 
> field or subjectAltName extension of a subsequent certificate, then path 
> must be rejected.  The same applies if the minimum or maximum field is 
> included and the relying party can not process those fields.  I can add 
> text in 3280bis that states this.
> 

OK.

> I was not aware of any confusion over the meaning of name constraints 
> imposed on rfc822Name or directoryName.  Could you provide more 
> information about what needs to be clarified?
> 

With rfc822Name it was mentioned that the comparision should be to 
compare the RHS against the constraint. The discussion was whether a 
constraint of, for example, [e-mail] would *only* match 
[e-mail] or whether [e-mail] was allowed as well. I 
can't recall if any consensus was reached over this: I'll see if I can 
find the reference.

As far as directoryName is concerned I've not seen a description or a 
reference to the algorithm used for this type of constraint. Some 
private communications with some vendors suggested that this wasn't 
obvious and also produced the worrying comment that "everyone does this 
differently".

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJStJw055346; Tue, 16 Nov 2004 11:28:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSt1F055345; Tue, 16 Nov 2004 11:28:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSmQL055210 for <[e-mail]>; Tue, 16 Nov 2004 11:28:51 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25769 invoked by uid 1365); 16 Nov 2004 19:27:49 +0000
MBOX-Line: From gate  Tue Nov 16 19:19:58 2004
Received: (qmail 24032 invoked from network); 16 Nov 2004 19:19:58 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:19:58 +0000
Received: (qmail 19793 invoked by alias); 16 Nov 2004 19:19:57 +0000
Delivered-To: [e-mail]
Received: (qmail 17465 invoked by uid 1114); 16 Nov 2004 19:04:57 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 16 Nov 2004 19:04:55 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGImKEw036622; Tue, 16 Nov 2004 10:48:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGImKBm036621; Tue, 16 Nov 2004 10:48:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGImKx4036614 for <[e-mail]>; Tue, 16 Nov 2004 10:48:20 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAGImL2x024464; Tue, 16 Nov 2004 13:48:21 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAGIlqYA014369; Tue, 16 Nov 2004 13:47:53 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 13:48:26 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: piyush <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <001301c4cc05$f6bfbc40$[e-mail]>
In-Reply-To: <001301c4cc05$f6bfbc40$[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,HTML_TITLE_EMPTY,MIME_HTML_ONLY,RATWR10_MESSID
X-Comodo-Spam-Score: -4.2
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Piyush,<br>
<br>
This is not really how the criticality flag is supposed to be used.
According to the standard, an application may ignore a non-critical
extension if it <u>can not</u> process it.&nbsp; Applications that can
process the extension are expected to do so, not to ask the user
whether to process or ignore the extension.<br>
<br>
Setting a constraint extension like name constraints to non-critical
should be thought of as a path forward.&nbsp; A CA that sets nameConstraints
to non-critical is indicating that it really wants relying parties to
reject certificates that do not satisfy the constraint, but the CA is
worried that many relying parties will be unable to process the
constraint.&nbsp; Setting the extension to critical may cause such relying
parties to have to reject all certificates as a result of being unable
to process the constraint, even if certificates that violate the
constraint are unlikely to be encountered.&nbsp; Setting the extension to
non-critical indicates that the CA wants the constraint to be imposed,
but is willing to take the risk that some relying parties will accept
certificates that violate the constraint rather than prevent such
relying parties from accepting any certificates at all.&nbsp; As more and
more relying parties are upgraded to be able to fully process the
constraint, fewer and fewer relying parties will be at risk of
accepting certificates that violate the constraint.&nbsp; If relying parties
interpret setting the criticality bit to FALSE to mean that the
extension can be processed or ignored at the relying parties whim, even
if the relying party is capable of processing the extension, then this
no longer works.<br>
<br>
Dave<br>
<br>
piyush wrote:<br>
<blockquote type="cite"
 cite="mid001301c4cc05$f6bfbc40$[e-mail]">The fact
that the extension is a name constraint becomes immaterial if the path
building software chooses to ignore it.
  <br>
The software may ignore the extension if it is marked as non critical,&nbsp;
as per rfc 3280.
  <br>
  <br>
In practice, there may be some benefits to marking the name constraint
extension non critical.
  <br>
RP may configure the path building software to ignore/enforce the
extension based on the importance of the transaction.
  <br>
e.g. - for email validation, the RP may configure the path validation
software to ignore name constraints.
  <br>
&nbsp;&nbsp;&nbsp;&nbsp; - for a million dollar internet transaction, the RP may configure
the software to always enforce name constraints.
  <br>
  <br>
-Piyush<br>
</blockquote>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJStt2055319; Tue, 16 Nov 2004 11:28:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJStXI055316; Tue, 16 Nov 2004 11:28:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSlfc055185 for <[e-mail]>; Tue, 16 Nov 2004 11:28:50 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25760 invoked by uid 1365); 16 Nov 2004 19:27:48 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:04 2004
Received: (qmail 24632 invoked from network); 16 Nov 2004 19:21:03 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:03 +0000
Received: (qmail 20223 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 7907 invoked by uid 1114); 9 Nov 2004 19:09:20 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 09 Nov 2004 19:09:15 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9IdYpW042999; Tue, 9 Nov 2004 10:39:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9IdYDx042998; Tue, 9 Nov 2004 10:39:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9IdVV7042991 for <[e-mail]>; Tue, 9 Nov 2004 10:39:32 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iA9IdYBS269660 for <[e-mail]>; Tue, 9 Nov 2004 13:39:34 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA9IdY4l269360 for <[e-mail]>; Tue, 9 Nov 2004 13:39:34 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iA9IdYr4024873 for <[e-mail]>; Tue, 9 Nov 2004 13:39:34 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iA9IdYpi024865; Tue, 9 Nov 2004 13:39:34 -0500
In-Reply-To: <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 9 Nov 2004 13:39:32 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF1|October 13, 2004) at 11/09/2004 13:39:33, Serialize complete at 11/09/2004 13:39:33
Content-Type: text/plain; charset="US-ASCII"
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Denis:

        It is indeed possible for two CA's to choose the same CRL issuer 
DN, while meaning two distinct entities.  However, what are the 
consequences?  In one case, a CA which has certified a subordinate CA can 
"take over" the issuer ID of that subordinate (outside hierarchies, only 
RP's who are trusting the CA through the issuer of that cross-certificate 
are affected).  In the other, a CA which originally delegated revocation 
to its superior can reclaim it.  Which of these is an attack?
        I don't know why the RP needs a rule which declares "a CRL issuer 
must be certified by the CA whose certificates it is issuing a CRL for", 
and which prohibits subordinate CA's from having their hierarchical 
superior issue CRL's for them.  In replying to Santosh, you have discussed 
attacks which come from unrelated CA's as the primary security threat 
associated with CRL issuers.  I agree with that, and have blocked those.
        BTW, Santosh is right that a certificate issued to a CRL Issuer by 
a CA which ordinarily delegates CRL's to that issuer is not practically 
revocable by CRL.  However, IMO a certificate may be useful even if a 
revocation check on it is not feasible.  Much client software checks 
certificate chains without checking revocation, being satisfied with the 
certification that "this key pair was once possessed by the subject". This 
applies equally to self-issued certificates.
        Before declaring that a rule should (or should not) prevent the 
use of a superior CA's CRL Issuer to produce CRL's for a subordinate CA, 
we should probably find out if anybody actually does that.  I hope that 
nobody actually has sibling CA's producing their CRL's.

                Tom Gindin






Denis Pinkas <[e-mail]>
11/09/2004 09:17 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     [e-mail]
        Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting


Tom,

>         Denis:

> Would a reasonable formulation of this rule be that a CRL Issuer 
> certificate governing the certificates of a given CA must have been 
> directly issued by one of the certificates in the chain being verified 
> (including the CA's own certificate), by the trust anchor for that 
chain, 
> or by a certificate which is a rollover of one of the certificates in 
the 
> first two grouips? 

No. This would not be a good formulation, since two different CAs from
the chain could choose the same DN to designate different CRL Issuers.

The RP needs to have an unambiguous way to know exactly which CA from
the chain is the one which has nominated the CRL Issuer.

Denis

> For this purpose, a certificate is a rollover of its 
> issuer certificate if it is self-issued but not self-signed, and the 
> relationship is associative (i.e. if A is a rollover of B which is a 
> rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D 
has 
> a CRL issuer and the path to D goes A (the anchor) to B to C to D, the 
CRL 
> issuer certificate may be issued by A, B, C, or D, or by B' in the case 
> where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued 

> through any other anchor nor through any CA whose DN is not in the path. 

> Only one further liberalization of this rule might make sense, which is 
> that C' would be considered a rollover of C on a path where C is issued 
by 
> B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels that 

> this is safe?
>         The good news about this heuristic is that it can be coded.  I 
> think any of these variants resist Julien's attack, under the fairly 
> reasonable assumptions that no CA issues certificates to bogus entities 
> with its own name and that any CA which directly issued your 
> cross-certificate and wants to have a CRL issuer masquerade as that CA 
can 
> do so by issuing a bogus CA cert just as easily as by issuing a bogus 
CRL 
> Issuer one.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> Denis Pinkas <[e-mail]>
> Sent by: [e-mail]
> 11/05/2004 10:04 AM
> 
>         To:     Santosh Chokhani <[e-mail]>
>         cc:     [e-mail]
>         Subject:        Re: Briefing on CRL Path for IETF PKIX WG 
Meeting
> 
> 
> 
> Santosh,
> 
> 
>>Denis,
>>
>>See responses in-line in [SC:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]] 
>>Sent: Thursday, November 04, 2004 12:40 PM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>Santosh,
>>
>>See responses in-line in [DP:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Wednesday, November 03, 2004 9:48 AM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>Santosh,
>>
>> > Denis,
>>
>> > The matching algorithm proposed checks/compares the ancestors.
>>
>>The matching algorithm is missing to say "who" trusts "somebody" for 
> 
> "what".
> 
>>Unless this is clearly said, there is no trust possible and thus no
>>algorithm possible.
>>
>>[SC: The two paths needs to be verified in accordance with 3280 in order 

> 
> to
> 
>>establish trust]
>>
>>[DP: the certification path needs to be verified according to RFC 3280. 
> 
> The
> 
>>problem is that RFC 3280 does not tell how to verify that the CRL comes 
>>from the right CRL Issuer. Your assumption that the "two paths needs to 
> 
> be 
> 
>>verified in accordance with 3280 in order to establish trust" is thus 
>>incorrect].
>>
>>[SC: When you augment 3280 with the algorithm I proposed, that takes 
> 
> care of
> 
>>it.  It goes without saying that 3280 needs to be augmented with the
>>algorithm]
> 
> 
> This is exactly what I disagree with.
> 
> Let us talk about the key issue. The question is: how can a RP (relying 
> party) know that, for a given end-user certificate, the CRL he got is 
> indeed 
> issued by the right CRL Issuer ?
> 
> In the following discussion, I am only considering the case where the 
CRL 
> Issuer is *not* the CA (this CA is called CA 1).
> 
> CA 2 is a CA that has issued a CA certificate to CA 1.
> 
> The text is currently so vague that different models are indeed 
> theoritically possible. In particular:
> 
>   a) the CRL Issuer is nominated by CA 1 that has issued
>      the end-user certificate. This case would make sense
>      when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>      that role to one or more CRL Issuers. This means that
>      a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
> 
>   b) the CRL Issuer is nominated by CA 2 that has issued a CA
>      certificate to CA 1. This case would make sense when CA 2
>      has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>      certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>      then only choose a CRL Issuer that has been granted
>      the authorization to issue CRLs by CA 2.
> 
> I wonder if I understand correctly the model you proposed, but (please 
> correct if wrong) you have a set of trust points to verify the 
> certification 
> chain, and another set of trust points to verify what you call a 
> certification path for the CRL Issuer.
> 
> There would be many problems with such a model to define correctly 
> validation policies, since the two chains would be unrelated and any CA 
> from 
> that chain could nominate CRL Issuers used by any CA.
> 
> In options a) and b) mentioned above, a single trust point is used to 
> validate both the certification chain and the CRL Issuer.
> 
> In any case, we need to clarify this topic in 3280bis, whatever the 
> clarification will be.
> 
> 
>>This algorithm is nothing more than formalism of something you agreed 
>>to in 2003 on this list.
>>
>>I don't think so.
>>
>>[SC: Go back to September 2003 archive of your response to my post and 
> 
> tell
> 
>>me what is not covered]
>>
>>[DP: You would need to be more precise and provide me an extract of what 

> 
> you
> 
>>refer to]
>>
>>[SC: It was short string of e-mails on the subject matter in September 
> 
> 2003.
> 
> Hum !!! Hum !!!
> Do not mention "free" assertions when you are not sure about.
> 
> Denis
> 
> 
>>I am sure you can find it from the archives.  It may be overcome by 
> 
> events
> 
>>since your recent postings show that you agree with me]
>>
>>Denis
> 
> 
> 
> 
> 
> 
> 






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJStXE055318; Tue, 16 Nov 2004 11:28:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSsXr055315; Tue, 16 Nov 2004 11:28:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSljQ055186 for <[e-mail]>; Tue, 16 Nov 2004 11:28:50 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25766 invoked by uid 1365); 16 Nov 2004 19:27:49 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:04 2004
Received: (qmail 24642 invoked from network); 16 Nov 2004 19:21:04 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:04 +0000
Received: (qmail 20207 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 12351 invoked by uid 1114); 16 Nov 2004 15:37:16 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 16 Nov 2004 15:37:13 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGFKUOU056159; Tue, 16 Nov 2004 07:20:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGFKUYw056158; Tue, 16 Nov 2004 07:20:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGFKTw4056151 for <[e-mail]>; Tue, 16 Nov 2004 07:20:30 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAGFJL2x013217; Tue, 16 Nov 2004 10:19:21 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAGFIjYA029636; Tue, 16 Nov 2004 10:18:46 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 10:19:18 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Terry Hayes <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,HTML_TITLE_EMPTY,MIME_HTML_ONLY,RATWR10_MESSID
X-Comodo-Spam-Score: -4.2
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Terry,<br>
<br>
Even if I agreed with you that name constraints should work as you
describe, there would still be a couple of problems.&nbsp; First, this would
be a change from RFC 3280, which is probably outside the scope for
changes that we are allowed to make in 3280bis.&nbsp; Second, this would
make 3280bis inconsistent with X.509, which is certainly not something
we can do, since 3280bis is a profile of X.509.<br>
<br>
X.509 states (among other things):<br>
<blockquote>
  <p>If excludedSubtrees is present, any certificate issued by the
subject CA or subsequent CAs in the certification path that has a
subject name within these subtrees is unacceptable.</p>
If the [<b>nameConstraints</b>] extension is present and is flagged
critical, a certificate-using implementation must recognize and process
all name forms for which there is both a subtree specification
(permitted or excluded) in the extension and a corresponding value in
the <b>subject</b> field or <b>subjectAltNames</b> extension of any
subsequent certificate in the certification path. If an unrecognized
name form appears in both a subtree specification and a subsequent
certificate, that certificate shall be handled as if an unrecognized
critical extension was encountered. If any subject name in the
certificate falls within an excluded subtree, the certificate is
unacceptable.<br>
</blockquote>
X.509 is quite clear that if a certificate includes a name that falls
within an excludedSubtree or does not fall within any permittedSubtree,
then the certificate is unacceptable not just the name.&nbsp; In order for a
certificate to be acceptable, all names must satisfy name constraints,
not just the name(s) that is of interest to the application.&nbsp; If the
nameConstraints extension is critical and the application can not
process one or more of the constraints, then it must reject the
certification path since it is unable to verify that the name
constraints have been satisfied.<br>
<br>
In my opinion, the answer to your concern is not to change the
semantics of name constraints, but to be careful in your use of name
constraints and alternative names.&nbsp; At the moment, in the U.S. Federal
PKI, we only impose name constraints on the directoryName form and I
have not seen a compelling reason to impose constraints on other name
forms.<br>
<br>
If you do feel the need to impose name constraints on some name form
for which many applications may not be able to process the constraint,
then I would suggest issuing separate certificates for the
application(s) that use that name form.&nbsp; For example, if you have an
application that uses X.400 names and you feel the need to impose name
constraints on X.400 names, issue subscribers two certificates:&nbsp; one
certificate with an X.400 name for use with the application that uses
the X.400 name (presumably this application can process the X.400 name
constraints) and a second certificate without an X.400 name.&nbsp; If a CA
imposes a constraint on a particular name form, but no subsequent
certificate includes a subject name or subjectAltName of that form,
then there is no processing to be done so the application can accept
the path despite not being able to process constraints for that name
form.<br>
<br>
There is another option:&nbsp; the nameConstraints extension could be marked
non-critical.&nbsp; X.509 states:<br>
<blockquote>If the [<b>nameConstraints</b>] extension is present and is
flagged non-critical and a certificate-using implementation does not
recognize a name form used in any <b>base</b> component, then that
subtree specification may be ignored.<br>
</blockquote>
Granted, RFC 3280 states that the nameConstraints extension MUST be
critical, but if there were sufficient interest in changing this in
3280bis to state that the extension can be set to either critical or
non-critical, I would be willing to support that.<br>
<br>
Dave<br>
<br>
<br>
Terry Hayes wrote:<br>
<blockquote type="cite" cite="[e-mail]">
  <pre wrap="">In my opinion, a requirement such as this is too restrictive, and will prevent additional capabilities from being added to a PKI.

As long as an application never makes use of a particular name form, it should be free to ignore constraints that apply to that name form.  Notice that to do this, it must recognize and process the name constraint extension as required by the extension processing rules.

If applications are required to reject certificates paths with constraints for name forms that they do not recognize, they will be prevented from using certificates that have those name forms added to them for other applications.  This will impede the use of certificates for these new applications, since older clients will not be able to function.

Terry Hayes


David A. Cooper wrote on 11/15/2004, 2:08 PM:
  </pre>
  <blockquote type="cite">
    <pre wrap="">
X.509 does have a rule that one must reject a critical extension unless 
you can process all of the fields in the extension. So, for name 
constraints, if a critical nameConstraints extension includes a 
constraint on a name form and that name form appears in the subject 
field or subjectAltName extension of a subsequent certificate, then path 
must be rejected.</pre>
  </blockquote>
</blockquote>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSkP2055228; Tue, 16 Nov 2004 11:28:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSktx055227; Tue, 16 Nov 2004 11:28:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSfFq055114 for <[e-mail]>; Tue, 16 Nov 2004 11:28:43 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25754 invoked by uid 1365); 16 Nov 2004 19:27:48 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:03 2004
Received: (qmail 24614 invoked from network); 16 Nov 2004 19:21:03 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:03 +0000
Received: (qmail 20239 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 20225 invoked by uid 1114); 11 Nov 2004 18:54:18 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Thu, 11 Nov 2004 18:54:16 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABIOlxr080934; Thu, 11 Nov 2004 10:24:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iABIOlN2080933; Thu, 11 Nov 2004 10:24:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABIOkE6080900 for <[e-mail]>; Thu, 11 Nov 2004 10:24:46 -0800 (PST) (envelope-from [e-mail])
Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9C912308DD for <[e-mail]>; Thu, 11 Nov 2004 19:24:34 +0100 (CET)
Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with SMTP id A855F30E67 for <[e-mail]>; Thu, 11 Nov 2004 19:23:52 +0100 (CET)
Received: (qmail 496 invoked from network); 11 Nov 2004 18:23:12 -0000
Received: from ycaro.dif.um.es (HELO ycaro) (155.54.210.68) by aries.dif.um.es with SMTP; 11 Nov 2004 18:23:12 -0000
Message-ID: <005401c4c81b$99f48e70$[e-mail]>
Reply-To: "Manuel Gil Perez" <[e-mail]>
From: "Manuel Gil Perez" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Bridge CA and crossCertificatePair
Date: Thu, 11 Nov 2004 19:23:52 +0100
Organization: ANTS Research Group
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear PKIX members,

I need to develop a bridge CA where it must store one or more 
cross-certificates. Revising the RFCs (about LDAP, X.509, etc.) and looking 
up on the web I conclude that it is technically possible (in accordance with 
RFC 3280) to store one or more cross-certificate into my bridge CA (this 
value is multi-valued).

But really, according to the specification (see below), I can only store one 
pair of cross-certificates. Is it possible that the attribute 
CertificatePair is not correct and should be changed for the following??

CertificatePair ::= SEQUENCE SIZE(1..MAX) OF CertificateForwardReverse;

CertificateForwardReverse ::= SEQUENCE {
   forward [0] Certificate OPTIONAL,
   reverse [1] Certificate OPTIONAL,
   -- at least one of the pair shall be present -- }

In any case... can somebody send me the correct specification for the 
attribute CertificatePair??

Many thanks, and best regards...

------
Manuel Gil Pérez
http://pki.umu.euro6ix.org


======

pkiCA OBJECT-CLASS ::= {
   SUBCLASS OF { top}
   KIND auxiliary
   MAY CONTAIN {
      cACertificate |
      certificateRevocationList |
      authorityRevocationList |
      crossCertificatePair }
   ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22) }

crossCertificatePair ATTRIBUTE ::= {
   WITH SYNTAX CertificatePair
   EQUALITY MATCHING RULE certificatePairExactMatch
    ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40) }

CertificatePair ::= SEQUENCE {
   forward [0] Certificate OPTIONAL,
   reverse [1] Certificate OPTIONAL,
   -- at least one of the pair shall be present -- } 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJShGE055195; Tue, 16 Nov 2004 11:28:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJShbJ055193; Tue, 16 Nov 2004 11:28:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSc3I055057 for <[e-mail]>; Tue, 16 Nov 2004 11:28:40 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25742 invoked by uid 1365); 16 Nov 2004 19:27:48 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:03 2004
Received: (qmail 24592 invoked from network); 16 Nov 2004 19:21:02 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:02 +0000
Received: (qmail 19923 invoked by alias); 16 Nov 2004 19:20:49 +0000
Delivered-To: [e-mail]
Received: (qmail 24440 invoked by uid 1114); 12 Nov 2004 14:48:31 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Fri, 12 Nov 2004 14:48:27 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACE2u36014033; Fri, 12 Nov 2004 06:02:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACE2uWk014032; Fri, 12 Nov 2004 06:02:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACE2pqF013969 for <[e-mail]>; Fri, 12 Nov 2004 06:02:51 -0800 (PST) (envelope-from [e-mail])
Received: from wmcooper (pcp09266381pcs.arlngt01.va.comcast.net [69.143.109.88]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iACE2gNE011332; Fri, 12 Nov 2004 09:02:42 -0500
Message-Id: <[e-mail]>
From: "Matt Cooper" <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>, "'Manuel Gil Perez'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Bridge CA and crossCertificatePair
Date: Fri, 12 Nov 2004 09:01:19 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTIgMWdHIloHgh6QRS3yh8trsz6oQAOuf2w
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iACE2pqF013982
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Quite right Tom, it is definitely multivalued.  If it was inferred that it
was not in the doc, it was in error.  Thanks for pointing this out, we'll
look at it.

And Manuel, to expand on what Tom's message, the encoding spec you
originally found is correct. The encoding should be a single pair of
certificates. As Tom said, since crossCertificatePair is multivalued, you
simply store as many encoded pairs as you need in the directory.  It's just
like certificates; the ASN.1 spec is only for one certificate; and you may
store as many as you need in the directory.

Incidentally, the reason crossCertificatePair is done this way is so that
related cross certificates may be associated. In other words, if we are CAs
and I were to issue you a certificate and you were to issue me a
certificate, we would put these two certificates together as a pair in our
respective crossCertificatePair entries.

 
Matt Cooper
Orion Security Solutions
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101
(Mob) 703.981.2269
(Off) 703.917.0060 x. 30
(Fax) 703.917.0260
Visit our website!
http://www.orionsec.com
 


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Gindin
Sent: Friday, November 12, 2004 12:09 AM
To: Manuel Gil Perez; Matt Cooper
Cc: [e-mail]
Subject: Re: Bridge CA and crossCertificatePair


        Manuel:

        CrossCertificatePair has AFAIK always been considered to be a
multi-valued attribute, as you can see from (for example) RFC 2587 section
3.2 where the existence of multiple CA Certificates in the caCertificate
attribute and of multiple 'forward' elements in the crossCertificatePair
attribute is discussed in consecutive paragraphs.  However, the
certpathbuild draft lists userCertificate and caCertificate as multi-valued
but doesn't make that statement about CrossCertificatePair. 
It should probably change to do so, unless it's too late in the process.
        Please note that the syntax of caCertificate is just a certificate,
not a sequence of them.

                Tom Gindin






"Manuel Gil Perez" <[e-mail]>
Sent by: [e-mail]
11/11/2004 01:23 PM
Please respond to "Manuel Gil Perez"
 
        To:     <[e-mail]>
        cc: 
        Subject:        Bridge CA and crossCertificatePair



Dear PKIX members,

I need to develop a bridge CA where it must store one or more
cross-certificates. Revising the RFCs (about LDAP, X.509, etc.) and looking
up on the web I conclude that it is technically possible (in accordance with
RFC 3280) to store one or more cross-certificate into my bridge CA (this
value is multi-valued).

But really, according to the specification (see below), I can only store one
pair of cross-certificates. Is it possible that the attribute
CertificatePair is not correct and should be changed for the following??

CertificatePair ::= SEQUENCE SIZE(1..MAX) OF CertificateForwardReverse;

CertificateForwardReverse ::= SEQUENCE {
   forward [0] Certificate OPTIONAL,
   reverse [1] Certificate OPTIONAL,
   -- at least one of the pair shall be present -- }

In any case... can somebody send me the correct specification for the
attribute CertificatePair??

Many thanks, and best regards...

------
Manuel Gil Pérez
http://pki.umu.euro6ix.org


======

pkiCA OBJECT-CLASS ::= {
   SUBCLASS OF { top}
   KIND auxiliary
   MAY CONTAIN {
      cACertificate |
      certificateRevocationList |
      authorityRevocationList |
      crossCertificatePair }
   ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22) }

crossCertificatePair ATTRIBUTE ::= {
   WITH SYNTAX CertificatePair
   EQUALITY MATCHING RULE certificatePairExactMatch
    ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40) }

CertificatePair ::= SEQUENCE {
   forward [0] Certificate OPTIONAL,
   reverse [1] Certificate OPTIONAL,
   -- at least one of the pair shall be present -- } 








Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSckP055142; Tue, 16 Nov 2004 11:28:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSca1055139; Tue, 16 Nov 2004 11:28:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSWaH054982 for <[e-mail]>; Tue, 16 Nov 2004 11:28:36 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25733 invoked by uid 1365); 16 Nov 2004 19:27:48 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:02 2004
Received: (qmail 24571 invoked from network); 16 Nov 2004 19:21:02 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:02 +0000
Received: (qmail 19951 invoked by alias); 16 Nov 2004 19:20:49 +0000
Delivered-To: [e-mail]
Received: (qmail 16617 invoked by uid 1114); 10 Nov 2004 22:33:02 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 22:33:00 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAALtl6C023631; Wed, 10 Nov 2004 13:55:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAALtlEU023630; Wed, 10 Nov 2004 13:55:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAALtdpB023482 for <[e-mail]>; Wed, 10 Nov 2004 13:55:42 -0800 (PST) (envelope-from [e-mail])
Received: from [10.67.86.181] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAALtTjf021038; Wed, 10 Nov 2004 16:55:32 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06110404bdb83d94f42c@[10.67.86.181]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 10 Nov 2004 16:54:32 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: several key in same certificate
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:00 PM +0100 11/10/04, [e-mail] wrote:
>Hi,
>
>it is possible to have several key in the same certificate ?
>if so, which document refers to that.
>
>Thanks
>Yann

the short, simple answer is no.

a longer answer follows:

For CA certs this would be a very confusing situation, and so I do 
not expect to see this construct approved. we have enough complexity 
with path processing and the potential for a CRL to be signed by a 
key other than the one used to sign a cert beng checked against said 
CRL ...


For EE certs, I know of one instance where a lagre PKI did put two 
keys into one cert: one key for signature and one for encryption, for 
e-mail.  It was messy, but invisible to the path validation logic, so 
it was not so awful. Still, one could not use the keyusage extension 
say which key was for which purpose, which illustrates the sort of 
problems that arise when one tries to do something like this.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSa5u055113; Tue, 16 Nov 2004 11:28:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSaV9055111; Tue, 16 Nov 2004 11:28:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSXuU054993 for <[e-mail]>; Tue, 16 Nov 2004 11:28:34 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25739 invoked by uid 1365); 16 Nov 2004 19:27:48 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:02 2004
Received: (qmail 24584 invoked from network); 16 Nov 2004 19:21:02 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:02 +0000
Received: (qmail 20039 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 15590 invoked by uid 1114); 10 Nov 2004 10:22:08 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 10:22:06 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA9oZkn081463; Wed, 10 Nov 2004 01:50:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA9oZus081462; Wed, 10 Nov 2004 01:50:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA9oUYQ081371 for <[e-mail]>; Wed, 10 Nov 2004 01:50:32 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA48552; Wed, 10 Nov 2004 11:02:10 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111010500750:650 ; Wed, 10 Nov 2004 10:50:07 +0100 
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 10:50:07 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Santosh Chokhani <[e-mail]>, [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 10:50:07, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 10:50:09, Serialize complete at 10/11/2004 10:50:09
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

My comments with [DP: ]

( ... text relative to Julien deleted)

Denis is making a valid remark that different CA's in the certificate
path may certify different CRL Issuers with the same name by accident

[DP: Thank you for the acknowledgment]

and the algorithm doesn't account for that.

[Santosh: since you intercept every mail, I guess you will notice that 
Stefan mentions that your algorithm has indeed a problem].

The question is if this is a valid threat or not.

Both Denis and Julien's scenarios require intentional malicious
behaviour of the CRL issuer or the CDP and the IDP wouldn't match (the
storage location pointer would differ).

[DP: No. In my scenario there is no intentional malicious
behaviour of the CRL issuer. Anybody can make an interception attack an 
substitute one CRL by another].

Both scenarios also require the attacker to convince the RP to NOT
obtain the correct CRL through the CDP pointer and instead accept the
rough CRL from other source OR it requires the attacker to hack the
server holding the real CRL and replace the real CRL with the rough CRL.

[DP: No. There is no notion of a "rough CRL". Both CRLs are real CRLs but 
issued by two CAs which happened to have the same DN (but these DNs have 
been given by two different CAs)]

----------------

In Denis scenario I would suggest that we can exclude presence of a
rouge CA in the original certificate path, because if the original cert
path has a rouge CA, then all bets are off anyway.

[DP: Your suggestion would not work. It is not possible to exclude the fact 
that two CAs in a certification path may issue the same DN to two different 
CRL Issuers: when a CA is naming a CRL Issuer, it does not need to check if 
that name has been given or not by another CA from the chain.]

( ... remaining of text relative to Julien deleted)

Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSaHJ055112; Tue, 16 Nov 2004 11:28:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSaLs055110; Tue, 16 Nov 2004 11:28:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSVqn054975 for <[e-mail]>; Tue, 16 Nov 2004 11:28:34 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25730 invoked by uid 1365); 16 Nov 2004 19:27:48 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:11 2004
Received: (qmail 24967 invoked from network); 16 Nov 2004 19:21:11 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:11 +0000
Received: (qmail 20262 invoked by alias); 16 Nov 2004 19:20:52 +0000
Delivered-To: [e-mail]
Received: (qmail 15088 invoked by uid 1114); 16 Nov 2004 18:47:25 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 16 Nov 2004 18:47:22 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGITEMX028549; Tue, 16 Nov 2004 10:29:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGITEZT028548; Tue, 16 Nov 2004 10:29:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGITDJ5028535 for <[e-mail]>; Tue, 16 Nov 2004 10:29:14 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAGISamc018070; Tue, 16 Nov 2004 13:28:36 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAGISGYA029020; Tue, 16 Nov 2004 13:28:16 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 13:28:49 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dr Stephen Henson <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

See comments in-line

Dr Stephen Henson wrote:

> David A. Cooper wrote:
>
>>   Stephen Henson wrote:
>>
>>> David A. Cooper wrote:
>>>
>>>> I was not aware of any confusion over the meaning of name 
>>>> constraints imposed on rfc822Name or directoryName.  Could you 
>>>> provide more information about what needs to be clarified?
>>>
>>>
>>>
>>> With rfc822Name it was mentioned that the comparision should be to 
>>> compare the RHS against the constraint. The discussion was whether a 
>>> constraint of, for example, [e-mail] would *only* match 
>>> [e-mail] or whether [e-mail] was allowed as 
>>> well. I can't recall if any consensus was reached over this: I'll 
>>> see if I can find the reference. 
>>
>>
>> Here is the current text for name constraints on rfc822Name:
>>
>>     A name constraint for Internet mail addresses MAY specify a
>>     particular mailbox, all addresses at a particular host, or all
>>     mailboxes in a domain.  To indicate a particular mailbox, the
>>     constraint is the complete mail address.  For example,
>>     "[e-mail]" indicates the root mailbox on
>>     the host "xyz.com".  To indicate all Internet mail addresses on a
>>     particular host, the constraint is specified as the host name.  For
>>     example, the constraint "xyz.com" is satisfied by any mail address
>>     at the host "xyz.com".  To specify any address within a domain, the
>>     constraint is specified with a leading period (as with URIs).  For
>>     example, ".xyz.com" indicates all the Internet mail addresses in the
>>     domain "xyz.com", but not Internet mail addresses on the host 
>> "xyz.com".
>>
>> As I read this, one can specify three types of constraints:
>>
>>    1. a specific email address
>>    2. all email addresses on a particular host
>>    3. all email address on all hosts whose DNS names are hierarchically
>>       subordinate to the specified name
>>
>> There is no option to specify a set of email addresses on a 
>> particular host that fit a certain pattern.  So, 
>> "[e-mail]" would not match "[e-mail]" since RFC 
>> 3280 states that "[e-mail]" is specifying a particular 
>> mailbox, not a set of mailboxes.  In my opinion this is the correct 
>> behavior.  Name constraints are designed to specify constraints in 
>> terms of subtrees.  Logically, "[e-mail]" is not 
>> hierarchically subordinate to "[e-mail]", the two are siblings.
>>
>
> Yes that's how I'd interpreted it. In more explicit terms: perform a 
> RHS match unless the constraint is of the form user@hostname where 
> only an exact match will satisfy it. 

Actually, this is not the case.  RFC 3280 states that constraints of the 
form "xyz.com" are matched only by email addresses on the host xyz.com.  
So, if the constraint were "xyz.com", one would perform a RHS match on 
"@xyz.com".  One could perform a RHS match for constraints of the form 
".xyz.com".

> There were suggestions that some had interpreted it in a different 
> way. At least one thread discussing this is at:
>
> http://www.imc.org/ietf-pkix/old-archive-02/msg01718.html

I saw that there was at least one response that completely 
misinterpreted the meaning of various constraints on rfc822Names.  I get 
the feeling, though, that this wsa not a case of someone misinterpreting 
the text but rather someone who did not read the text.  There are no 
changes we can make in 3280bis to address that problem.

Dave



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSZKq055099; Tue, 16 Nov 2004 11:28:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSZfF055098; Tue, 16 Nov 2004 11:28:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSWar054984 for <[e-mail]>; Tue, 16 Nov 2004 11:28:34 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25736 invoked by uid 1365); 16 Nov 2004 19:27:48 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:02 2004
Received: (qmail 24572 invoked from network); 16 Nov 2004 19:21:02 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:02 +0000
Received: (qmail 20078 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 3468 invoked by uid 1114); 13 Nov 2004 14:37:10 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Sat, 13 Nov 2004 14:37:07 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADE4ngV077690; Sat, 13 Nov 2004 06:04:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADE4nML077689; Sat, 13 Nov 2004 06:04:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADE4lVj077647 for <[e-mail]>; Sat, 13 Nov 2004 06:04:48 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA50600; Sat, 13 Nov 2004 15:16:50 +0100
Received: from bull.net ([129.181.81.126]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111315044270:1055 ; Sat, 13 Nov 2004 15:04:42 +0100 
Message-ID: <[e-mail]>
Date: Sat, 13 Nov 2004 15:05:56 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: pkix <[e-mail]>
Subject: 3280bis: keyUsage
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 03:04:43 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 03:04:44 PM, Serialize complete at 11/13/2004 03:04:44 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Is it really necessary to recall that keyUsage needs to be aligned with 
the revised text of X.509 which was adopted at the Geneva 2004 meeting ?

A text to be added in the security considerations section for 
hightligthing the poosible dangers to have both bits 0 and 1 set should 
also be added. This text has been proposed and accepted at the ISO 
Geneva 2004 meeting.

Denis


 






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSZsk055090; Tue, 16 Nov 2004 11:28:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSZQe055089; Tue, 16 Nov 2004 11:28:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSV32054963 for <[e-mail]>; Tue, 16 Nov 2004 11:28:34 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25727 invoked by uid 1365); 16 Nov 2004 19:27:48 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:02 2004
Received: (qmail 24550 invoked from network); 16 Nov 2004 19:21:02 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:02 +0000
Received: (qmail 19979 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 13532 invoked by uid 1114); 15 Nov 2004 20:59:51 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 20:59:49 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFKS307099577; Mon, 15 Nov 2004 12:28:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFKS32U099576; Mon, 15 Nov 2004 12:28:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFKS3Od099562 for <[e-mail]>; Mon, 15 Nov 2004 12:28:03 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAFKRimc019230 for <[e-mail]>; Mon, 15 Nov 2004 15:27:44 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAFKRLYA006070 for <[e-mail]>; Mon, 15 Nov 2004 15:27:22 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 15:27:52 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: ietf-pkix <[e-mail]>
Subject: Re: Is that right?set the valid_policy to OID-P;
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree that "OID-P" should have been "P-OID". I will fix it in 3280bis.

Dave

Stephen Henson wrote:

>alan wrote:
>
>>ietf-pkix£¬
>>
>>In rfc3280,
>>6.1.3  Basic Certificate Processing
>>(d)
>>	(1)
>>		(i)If the valid_policy_tree includes a node of depth i-1
>>            where P-OID is in the expected_policy_set, create a child
>>            node as follows: set the valid_policy to OID-P; set the
>>            qualifier_set to P-Q, and set the expected_policy_set to
>>            {P-OID}.
>>OID-P is what?
>>
>>I can't make sure for this word.
>>
>When I implemented this for OpenSSL I assumed it was a typo and should
>say P-OID. The example in figure 4 supports this.
>
>Steve.
>  
>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSW51055049; Tue, 16 Nov 2004 11:28:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSWcT055048; Tue, 16 Nov 2004 11:28:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSQwH054915 for <[e-mail]>; Tue, 16 Nov 2004 11:28:28 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25718 invoked by uid 1365); 16 Nov 2004 19:27:48 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:11 2004
Received: (qmail 24945 invoked from network); 16 Nov 2004 19:21:10 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:10 +0000
Received: (qmail 20246 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 11928 invoked by uid 1114); 16 Nov 2004 15:33:47 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 16 Nov 2004 15:33:45 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGEsKbk047386; Tue, 16 Nov 2004 06:54:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGEsK5J047385; Tue, 16 Nov 2004 06:54:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGEsJC7047379 for <[e-mail]>; Tue, 16 Nov 2004 06:54:19 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAGEp32x007138; Tue, 16 Nov 2004 09:51:03 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAGEoYYA008091; Tue, 16 Nov 2004 09:50:34 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 09:51:07 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Henson <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,HTML_TITLE_EMPTY,MIME_HTML_ONLY,RATWR10_MESSID
X-Comodo-Spam-Score: -4.2
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Stephen Henson wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">David A. Cooper
wrote:&nbsp;
  <br>
  <blockquote type="cite">I was not aware of any confusion over the
meaning of name constraints imposed on rfc822Name or directoryName.&nbsp;
Could you provide more information about what needs to be clarified?
    <br>
  </blockquote>
  <br>
With rfc822Name it was mentioned that the comparision should be to
compare the RHS against the constraint. The discussion was whether a
constraint of, for example, <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> would *only* match
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> or whether <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> was allowed as well. I
can't recall if any consensus was reached over this: I'll see if I can
find the reference.
</blockquote>
Here is the current text for name constraints on rfc822Name:<br>
<blockquote>A name constraint for Internet mail addresses MAY specify a
particular mailbox, all addresses at a particular host, or all
mailboxes in a domain.&nbsp; To indicate a particular mailbox, the
constraint is the complete mail address.&nbsp; For example, <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">"[e-mail]"</a>
indicates the root mailbox on the host "xyz.com".&nbsp; To indicate all
Internet mail addresses on a particular host, the constraint is
specified as the host name.&nbsp; For example, the constraint "xyz.com" is
satisfied by any mail address at the host "xyz.com".&nbsp; To specify any
address within a domain, the constraint is specified with a leading
period (as with URIs).&nbsp; For example, ".xyz.com" indicates all the
Internet mail addresses in the domain "xyz.com", but not Internet mail
addresses on the host "xyz.com".<br>
</blockquote>
As I read this, one can specify three types of constraints:<br>
<ol>
  <li>a specific email address</li>
  <li>all email addresses on a particular host</li>
  <li>all email address on all hosts whose DNS names are hierarchically
subordinate to the specified name<br>
  </li>
</ol>
There is no option to specify a set of email addresses on a particular
host that fit a certain pattern.&nbsp; So, <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">"[e-mail]"</a> would not
match <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">"[e-mail]"</a> since RFC 3280 states that
<a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">"[e-mail]"</a> is specifying a particular mailbox, not a set of
mailboxes.&nbsp; In my opinion this is the correct behavior.&nbsp; Name
constraints are designed to specify constraints in terms of subtrees.&nbsp;
Logically, <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">"[e-mail]"</a> is not hierarchically subordinate to
<a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">"[e-mail]"</a>, the two are siblings.<br>
<br>
<blockquote type="cite"
 cite="[e-mail]">As far as
directoryName is concerned I've not seen a description or a reference
to the algorithm used for this type of constraint. Some private
communications with some vendors suggested that this wasn't obvious and
also produced the worrying comment that "everyone does this
differently".
  <br>
</blockquote>
I have never heard this.&nbsp; It seems to me that the rules are fairly
simple.&nbsp; A DN consists of a SEQUENCE of RDN.&nbsp; A subtree specification
for name constraints on DNs consists of a SEQUENCE of RDN.&nbsp; If the
subtree specification is a sequence of <i>n</i> RDNs, then a DN
matches if and only if the DN consists of a sequence of at least <i>n</i>
RDNs and the first <i>n</i> RDNs in the DN match the the RDNs in the
subtree specification in order.&nbsp; The rules for comparing RDNs are the
same as are used to compare issuer and subject names when verifying
name chaining.<br>
<br>
So, are these vendors who are unclear on how to process name
constraints on directoryNames also unclear on how to compare issuer and
subject names, or is the confusion limited to name constraints?<br>
<br>
Dave<br>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSU3U055028; Tue, 16 Nov 2004 11:28:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSUxd055027; Tue, 16 Nov 2004 11:28:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSNEA054858 for <[e-mail]>; Tue, 16 Nov 2004 11:28:26 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25703 invoked by uid 1365); 16 Nov 2004 19:27:47 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:01 2004
Received: (qmail 24520 invoked from network); 16 Nov 2004 19:21:01 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:01 +0000
Received: (qmail 20054 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 18159 invoked by uid 1114); 9 Nov 2004 20:18:39 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 09 Nov 2004 20:18:35 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9JvnZB064050; Tue, 9 Nov 2004 11:57:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9Jvntt064049; Tue, 9 Nov 2004 11:57:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9JvmoF064042 for <[e-mail]>; Tue, 9 Nov 2004 11:57:48 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9Jvo1X029684 for <[e-mail]>; Tue, 9 Nov 2004 14:57:50 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 14:57:50 -0500
Message-ID: <006b01c4c696$64c124b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA9JvnoF064043
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MY_FNAMEB
X-Comodo-Spam-Score: -4.2
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

None of your comment seem to object to the path matching algorithm.

Please see specific responses below.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 9:24 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting


Santosh,

> Denis,
> 
> When you look at 3280 and add what I propose, what do you see is 
> missing?

Since you asked ... I will explain what is wrong in your slides.

Slide 5. The statement " A CA is defined by name alone" is wrong. A CA is
not simply defined by a name alone. A name, for X.509, is always relative to
the CA which has issued it. So the "clarification' to say that a CA is
unambiguously defined by name is wrong. Then since the other slides are
based on that wrong assumption, they are wrong as well.

[SC: Here is the quote from X.509 "NOTE 1 - Although the CAs are
unambiguously defined by a distinguished name in the DIT, this does not
imply that there is any relationship between the organization of the CAs and
the DIT."]

Slide 7:  There is no "need to account for multiple CAs with the same name".
This formulation is pretty bad. A CA must provide different names to two
different entities. Since a CA name is relative to another CA name space,
there cannot be two CAs with the same name.

[SC: There is requirement or mechanism that ensures that a relying party
with multiple trust anchors will not encounter two CAs with the same name.
If a relying party has two trust anchors A and B and there are two distinct
companies with the same name C, it is possible that one C is certified via A
and another via B.]

Slide 8: The statement : "There can be more than one CA with the same name"
is wrong. Once again, a (CA) name is always relative to a CA name space.

[SC: There is requirement or mechanism that ensures that a relying party
with multiple trust anchors will not encounter two CAs with the same name.
If a relying party has two trust anchors A and B and there are two distinct
companies with the same name C, it is possible that one C is certified via A
and another via B.]

Slide 8: The statement "starting from a TA, the relying party can match the
CA names in [ ] the CRL certification paths" is wrong as well. There is no
such notion of a "CRL certification path".

[SC: When you get a CRL by the Issuer name of the CA and the signature does
not verify, you will need to develop a certification path for the CRL.  Your
other choices are: do not check revocation information, or take the CRL on
faith even though signature has not been verified.  I do not consider either
of these choices in compliance with 3280.  Feel free to provide other
choices that do not entail building a certification path for the CRL.]

[SC: From the long discourse below, it seems that you are focused only on
indirect CRL issuance problem.  The path matching algorithm tries to solve
that as well as when the CA has used different keys to sign certificates and
CRL (e.g., due to key roll over or in general using two keys to sign the two
objects.]

As indicated in RFC 3280, a CRL issuer is an optional
system to which a CA delegates the publication of CRLs.
This sentence is correct, but vague. (X.509 does not provide
a clear definition of what a CRL Issuer is).

Page 43 from RFC 3280: "The cRLIssuer identifies the entity
who signs and issues the CRL. If present, the cRLIssuer MUST contain at
least one an X.500 distinguished name (DN).

A CA will thus identify the DN of the CRL Issuer in the cRLIssuer field from
a CRL distribution point extension.

[SC: So far, I agree and the briefing is aligned with this]

That DN needs to be compared with a subject DN from a CRL Issuer
certificate, i.e. a certificate which has the cRLSign bit set (and that has
that DN as the subject name).

[SC: cRLSign bit is out side the scope of path matching.  All 3280 checks
for CRL imply.  As to name matching.  As to the name match check, that is
what bullet 1 on slide 13 does.]

The question is then simply : how can a RP know that that CRL Issuer
certificate has been issued by the right CA ?

A simple answer to that question is to say that the CA that has placed the
CRL DP extension must be the one that has issued the CRL Issuer certificate.

[SC: This is one model.  There are other model where the CA need not issue a
certificate to the indirect CRL issuer]

This means something very important. The TA used to verify
the CRL Issuer certificate is the same as the one used to verify the
certificate to be validated. All intermediate CAs are identical.

[SC: The path matching algorithm accounts for this.  Since there is no
requirement for the certificate issuing CA to directly issue a certificate
to the indirect CRL issuer, the matching algorithm may terminates
prematurely.]

This rule can easily be interpreted by a relying party since
it needs first to have the certification path.

This is not the case for the algorithm you proposed, where different TAs are
used on one side to validate the certificate to be validated and on the
other side the CRL Issuer certificate.

[SC: The algorithm requires that the DN representing the same TA be used for
both paths. (See bullet 1 on slide 12.  The reason the same key (and hence
TA) is not used is to accommodate the case of the TA having been re-keyed.]

In this algorithm, two CRL Issuers with the same DN might appear in
different certification paths. So multiple CRL Issuer names could match the
criteria. The algorithm you proposed is flawed.

[SC: Can you give a more concrete example of it.  I know that the rules are
liberal for indirect CRL issuer since I do not believe that direct
delegation model is required]

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Monday, November 08, 2004 11:35 AM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Santosh,
> 
> 
>>Denis,
> 
> 
>>What you are describing is already in 3280 and X.509.
> 
> 
> If it is the case, would you copy and paste that text, please ? 
> Otherwise, I understand that you agree with my text.
> 
> Denis
> 
> 
>>If you identity specific problem with the algorithm, I will be glad to
>>act on it or respond.
>>
>>As to Julien scenario, I would generalize that a relying party is not
>>safe if it trusts a rogue CA for all name spaces and policies.  That 
>>is a fact of life for the whole PKI, including (but not just for) the 
>>path matching algorithm.
>>
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>Sent: Monday, November 08, 2004 9:20 AM
>>To: Julien Stern
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>
>>Julien,
>>
>>You are quite right. There is a major problem with Santosh's proposal.
>>
>>Instead of trying to debug the proposed algorithm, it would be much
>>better to describe first what the trust model is.
>>
>>Leaving aside indirect CRLs, which may be supported by a trillion of
>>all different and unrelated models, there are several questions to 
>>answer:
>>
>>First question: What is a CRL Issuer ?
>>
>>Hereafter is a strawman proposal:
>>
>>CRL Issuer : an authority that issues and signs CRLs. When the CRL is
>>not signed by the CA itself, the CRL shall be signed by a CRL Issuer
> 
> identified
> 
>>in the CRL distribution point extension of the certificate.
>>
>>Second question : How is the CRL Issuer identified in the CRL
>>distribution point extension of the certificate ?
>>
>>Hereafter a strawman response: it is identified using cRLIssuer.
>>
>>         cRLIssuer               [2]     GeneralNames
>>
>>Third question: which form of name shall be used ?
>>
>>GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
>>
>>GeneralName ::= CHOICE {
>>      otherName                       [0]     AnotherName,
>>      rfc822Name                      [1]     IA5String,
>>      dNSName                         [2]     IA5String,
>>      x400Address                     [3]     ORAddress,
>>      directoryName                   [4]     Name,
>>      ediPartyName                    [5]     EDIPartyName,
>>      uniformResourceIdentifier       [6]     IA5String,
>>      iPAddress                       [7]     OCTET STRING,
>>      registeredID                    [8]     OBJECT IDENTIFIER }
>>
>>RFC 3280 states: "the cRLIssuer MUST contain at least one an X.500 
>>distinguished name (DN)".
>>
>>Fourth question: which CA shall certify that name ?
>>
>>Neither RFC 3280 nor X.509 provides a response for that question. Put
>>in another way, who will nominate the CRL Issuer and thus will issue 
>>the CRL Issuer certificate ?
>>
>>  ... and we are back with the two proposals I made (on which I got no 
>>response from Santosh):
>>
>>Here it is again:
>>
>>The CRL Issuer is *not* the CA. This CA is called CA 1.
>>CA 2 is a CA that has issued a CA certificate to CA 1.
>>
>>  a) the CRL Issuer is nominated by CA 1 that has issued
>>     the end-user certificate. This case would make sense
>>     when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>>     that role to one or more CRL Issuers. This means that
>>     a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
>>
>>  b) the CRL Issuer is nominated by CA 2 that has issued a CA
>>     certificate to CA 1. This case would make sense when CA 2
>>     has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>>     certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>>     then only choose a CRL Issuer that has been granted
>>     the authorization to issue CRLs by CA 2.
>>
>>Other cases are the trillion cases of indirect CRLs.
>>
>>Denis
> 
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSQ98054971; Tue, 16 Nov 2004 11:28:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSQDL054969; Tue, 16 Nov 2004 11:28:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSLX3054822 for <[e-mail]>; Tue, 16 Nov 2004 11:28:23 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25700 invoked by uid 1365); 16 Nov 2004 19:27:47 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:10 2004
Received: (qmail 24924 invoked from network); 16 Nov 2004 19:21:10 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:10 +0000
Received: (qmail 20271 invoked by alias); 16 Nov 2004 19:20:52 +0000
Delivered-To: [e-mail]
Received: (qmail 9494 invoked by uid 1114); 16 Nov 2004 18:34:33 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 16 Nov 2004 18:34:31 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGIEsrT022446; Tue, 16 Nov 2004 10:14:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGIEsGE022444; Tue, 16 Nov 2004 10:14:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGIEqD3022394 for <[e-mail]>; Tue, 16 Nov 2004 10:14:52 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1CU7qu-0008Rh-96; Tue, 16 Nov 2004 18:14:52 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 18:15:39 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: piyush <[e-mail]>
CC: Stefan Santesson <[e-mail]>, Terry Hayes <[e-mail]>, "David A. Cooper" <[e-mail]>, Stephen Henson <[e-mail]>, [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <001301c4cc05$f6bfbc40$[e-mail]>
In-Reply-To: <001301c4cc05$f6bfbc40$[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

piyush wrote:

> The fact that the extension is a name constraint becomes immaterial if 
> the path building software chooses to ignore it.
> The software may ignore the extension if it is marked as non critical,  
> as per rfc 3280.
> 

That's not my understanding. The relevant text in RFC3280 about 
criticality is:

> A certificate using system MUST reject the certificate if it encounters
> a critical extension it does not recognize; however, a non-critical
> extension MAY be ignored if it is not recognized.

I notice this doesn't explicitly say what an implementation should do if 
it encounters a non-critical extension that it does recognize.

I can recall threads where it was stated that recognized extensions MUST 
be processed irrespective of the their criticality. Should we clarify 
this in RFC3280bis?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSPae054961; Tue, 16 Nov 2004 11:28:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSPBb054958; Tue, 16 Nov 2004 11:28:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSK8n054817 for <[e-mail]>; Tue, 16 Nov 2004 11:28:23 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25697 invoked by uid 1365); 16 Nov 2004 19:27:47 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:01 2004
Received: (qmail 24509 invoked from network); 16 Nov 2004 19:21:01 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:01 +0000
Received: (qmail 20051 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 14192 invoked by uid 1114); 10 Nov 2004 14:40:56 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 14:40:53 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEQ10F045811; Wed, 10 Nov 2004 06:26:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAEQ1EZ045810; Wed, 10 Nov 2004 06:26:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEPxPC045800 for <[e-mail]>; Wed, 10 Nov 2004 06:26:00 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAAEQ1D03964; Wed, 10 Nov 2004 15:26:01 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 10 Nov 2004 15:26:01 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAAEQ0R24333; Wed, 10 Nov 2004 15:26:00 +0100 (MET)
Date: Wed, 10 Nov 2004 15:26:00 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Cc: [e-mail]
X-Sun-Charset: US-ASCII
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-2.8 required=5.0 tests=BAYES_00,BLANK_LINES_70_80
X-Comodo-Spam-Score: -2.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

IMO you can ignore my previous message concerning chapter 5.1.1.3 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSN2W054941; Tue, 16 Nov 2004 11:28:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSNP8054940; Tue, 16 Nov 2004 11:28:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSIPW054797 for <[e-mail]>; Tue, 16 Nov 2004 11:28:19 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25694 invoked by uid 1365); 16 Nov 2004 19:27:47 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:10 2004
Received: (qmail 24923 invoked from network); 16 Nov 2004 19:21:10 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:10 +0000
Received: (qmail 20233 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 4882 invoked by uid 1114); 10 Nov 2004 03:37:15 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 03:37:12 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA3MZr8048249; Tue, 9 Nov 2004 19:22:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA3MZPu048248; Tue, 9 Nov 2004 19:22:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA3MYLk048242 for <[e-mail]>; Tue, 9 Nov 2004 19:22:34 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iAA3Me4a025237; Tue, 9 Nov 2004 22:22:40 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 22:22:34 -0500
Message-ID: <001a01c4c6d4$88a68f80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAA3MZLk048243
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

See responses in-line in [SC:]

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 9:08 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting


      Santosh:

      I apologize for not having realized exactly how close the effects of
your algorithm and mine actually are.  I started from some of Denis'
formulations without having fully analyzed your initialization part 3, and
rederived something very close to yours.  In practice, the difference
between the matching algorithms mainly reduces to the difference between
"the subject and issuer DN's of the non-self-issued certificates must match"
and "must be the same certificate or a rollover thereof", and your
formulation allows a superior CA to rekey its subordinate without any
rollovers while mine forbids that.

[SC: My algorithm permits roll over certificates.  I simply ignore them.  I
think a more secure and practical model is a CA getting a certificate from
parent when it re-keys.  There is no mechanism in X.509 that is both simple
and secure to promulgate revocation status of self-issued certificates.
Thus, it is important to account for a practice that is more secure.]

  Of course, I'm not really sure why the issuer DN's need to be compared
separately, since Issuer (N) must match Subject (N-1) and the subjects are
being compared.

[SC: Defense in depth.  I thought about comparing one sets of names only
since X.509 and 3280 requires name chaining during path validation.  But, I
also know that some well known and well used products do not do it.  I see
this an opportunity to reinforce the name chaining need.]

      More substantively, I don't understand why it's permissible in your
algorithm for NCert to be NCRL-2 or NCRL-3, which corresponds to a
subordinate CA issuing its superior's CRL Issuer certificate.  In mine,
NCert may never be less than NCRL.

[SC: If you note on slide 11, for direct CRL, Ncert = NCRL +1.  For indirect
CRL, we should add a rule that NCRL < NCERT (after NCRL has been decremented
by 1 in bullet 2.  I have added that.]

  This difference does allow an attack against yours which doesn't work
against mine, but it is not an "unrelated CA" attack.  Instead, it's a case
of a subordinate CA of the EE's issuer issuing a CRL Issuer certificate with
the same DN (but a different key) as that used in the EE certificate.
      In view of the minimal effective differences, it is probably
reasonable to consider my technique an optimization of yours in that it
doesn't need to perform independent path building.  You can easily enough
get rid of the difference cited in my second paragraph by replacing your MIN
step by "Verify that NCert >= NCRL", and using NCRL as the upper bound of
the loop.

            Tom Gindin




 

                      "Santosh

                      Chokhani"                To:       <[e-mail]>

                      <chokhani@orionse        cc:

                      c.com>                   Subject:  RE: Briefing on CRL
Path for IETF PKIX WG Meeting                             
                      Sent by:

                      owner-ietf-pkix@m

                      ail.imc.org

 

 

                      11/09/2004 04:10

                      PM

 






Tom,

Can you explain the following from your post in relation of CRL path
matching and how you mitigate it and CRL path matching does not.  I quote
you:

"In replying to Santosh, you have discussed attacks which come from
unrelated CA's as the primary security threat associated with CRL issuers. I
agree with that, and have blocked those."

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Gindin
Sent: Tuesday, November 09, 2004 1:40 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



        Denis:

        It is indeed possible for two CA's to choose the same CRL issuer DN,
while meaning two distinct entities.  However, what are the consequences?
In one case, a CA which has certified a subordinate CA can "take over" the
issuer ID of that subordinate (outside hierarchies, only RP's who are
trusting the CA through the issuer of that cross-certificate are affected).
In the other, a CA which originally delegated revocation to its superior can
reclaim it.  Which of these is an attack?
        I don't know why the RP needs a rule which declares "a CRL issuer
must be certified by the CA whose certificates it is issuing a CRL for", and
which prohibits subordinate CA's from having their hierarchical superior
issue CRL's for them.  In replying to Santosh, you have discussed attacks
which come from unrelated CA's as the primary security threat associated
with CRL issuers.  I agree with that, and have blocked those.
        BTW, Santosh is right that a certificate issued to a CRL Issuer by a
CA which ordinarily delegates CRL's to that issuer is not practically
revocable by CRL.  However, IMO a certificate may be useful even if a
revocation check on it is not feasible.  Much client software checks
certificate chains without checking revocation, being satisfied with the
certification that "this key pair was once possessed by the subject". This
applies equally to self-issued certificates.
        Before declaring that a rule should (or should not) prevent the use
of a superior CA's CRL Issuer to produce CRL's for a subordinate CA, we
should probably find out if anybody actually does that.  I hope that nobody
actually has sibling CA's producing their CRL's.

                Tom Gindin






Denis Pinkas <[e-mail]>
11/09/2004 09:17 AM

        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     [e-mail]
        Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting


Tom,

>         Denis:

> Would a reasonable formulation of this rule be that a CRL Issuer 
> certificate governing the certificates of a given CA must have been 
> directly issued by one of the certificates in the chain being verified 
> (including the CA's own certificate), by the trust anchor for that
chain,
> or by a certificate which is a rollover of one of the certificates in
the
> first two grouips?

No. This would not be a good formulation, since two different CAs from the
chain could choose the same DN to designate different CRL Issuers.

The RP needs to have an unambiguous way to know exactly which CA from the
chain is the one which has nominated the CRL Issuer.

Denis

> For this purpose, a certificate is a rollover of its
> issuer certificate if it is self-issued but not self-signed, and the 
> relationship is associative (i.e. if A is a rollover of B which is a 
> rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D
has
> a CRL issuer and the path to D goes A (the anchor) to B to C to D, the
CRL
> issuer certificate may be issued by A, B, C, or D, or by B' in the 
> case where B is the issuer of B' and DN(B) = DN(B'); but it may not be 
> issued

> through any other anchor nor through any CA whose DN is not in the 
> path.

> Only one further liberalization of this rule might make sense, which 
> is that C' would be considered a rollover of C on a path where C is 
> issued
by
> B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels 
> that

> this is safe?
>         The good news about this heuristic is that it can be coded.  I 
> think any of these variants resist Julien's attack, under the fairly 
> reasonable assumptions that no CA issues certificates to bogus 
> entities with its own name and that any CA which directly issued your 
> cross-certificate and wants to have a CRL issuer masquerade as that CA
can
> do so by issuing a bogus CA cert just as easily as by issuing a bogus
CRL
> Issuer one.
>
>                 Tom Gindin
>
>
>
>
>
>
> Denis Pinkas <[e-mail]>
> Sent by: [e-mail]
> 11/05/2004 10:04 AM
>
>         To:     Santosh Chokhani <[e-mail]>
>         cc:     [e-mail]
>         Subject:        Re: Briefing on CRL Path for IETF PKIX WG
Meeting
>
>
>
> Santosh,
>
>
>>Denis,
>>
>>See responses in-line in [SC:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, November 04, 2004 12:40 PM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>Santosh,
>>
>>See responses in-line in [DP:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Wednesday, November 03, 2004 9:48 AM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>Santosh,
>>
>> > Denis,
>>
>> > The matching algorithm proposed checks/compares the ancestors.
>>
>>The matching algorithm is missing to say "who" trusts "somebody" for
>
> "what".
>
>>Unless this is clearly said, there is no trust possible and thus no 
>>algorithm possible.
>>
>>[SC: The two paths needs to be verified in accordance with 3280 in 
>>order

>
> to
>
>>establish trust]
>>
>>[DP: the certification path needs to be verified according to RFC 
>>3280.
>
> The
>
>>problem is that RFC 3280 does not tell how to verify that the CRL 
>>comes from the right CRL Issuer. Your assumption that the "two paths 
>>needs to
>
> be
>
>>verified in accordance with 3280 in order to establish trust" is thus 
>>incorrect].
>>
>>[SC: When you augment 3280 with the algorithm I proposed, that takes
>
> care of
>
>>it.  It goes without saying that 3280 needs to be augmented with the 
>>algorithm]
>
>
> This is exactly what I disagree with.
>
> Let us talk about the key issue. The question is: how can a RP 
> (relying
> party) know that, for a given end-user certificate, the CRL he got is 
> indeed issued by the right CRL Issuer ?
>
> In the following discussion, I am only considering the case where the
CRL
> Issuer is *not* the CA (this CA is called CA 1).
>
> CA 2 is a CA that has issued a CA certificate to CA 1.
>
> The text is currently so vague that different models are indeed 
> theoritically possible. In particular:
>
>   a) the CRL Issuer is nominated by CA 1 that has issued
>      the end-user certificate. This case would make sense
>      when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>      that role to one or more CRL Issuers. This means that
>      a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
>
>   b) the CRL Issuer is nominated by CA 2 that has issued a CA
>      certificate to CA 1. This case would make sense when CA 2
>      has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>      certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>      then only choose a CRL Issuer that has been granted
>      the authorization to issue CRLs by CA 2.
>
> I wonder if I understand correctly the model you proposed, but (please 
> correct if wrong) you have a set of trust points to verify the 
> certification chain, and another set of trust points to verify what 
> you call a certification path for the CRL Issuer.
>
> There would be many problems with such a model to define correctly 
> validation policies, since the two chains would be unrelated and any 
> CA from that chain could nominate CRL Issuers used by any CA.
>
> In options a) and b) mentioned above, a single trust point is used to 
> validate both the certification chain and the CRL Issuer.
>
> In any case, we need to clarify this topic in 3280bis, whatever the 
> clarification will be.
>
>
>>This algorithm is nothing more than formalism of something you agreed 
>>to in 2003 on this list.
>>
>>I don't think so.
>>
>>[SC: Go back to September 2003 archive of your response to my post and
>
> tell
>
>>me what is not covered]
>>
>>[DP: You would need to be more precise and provide me an extract of 
>>what

>
> you
>
>>refer to]
>>
>>[SC: It was short string of e-mails on the subject matter in September
>
> 2003.
>
> Hum !!! Hum !!!
> Do not mention "free" assertions when you are not sure about.
>
> Denis
>
>
>>I am sure you can find it from the archives.  It may be overcome by
>
> events
>
>>since your recent postings show that you agree with me]
>>
>>Denis
>
>
>
>
>
>
>









Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSK1e054903; Tue, 16 Nov 2004 11:28:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSJxw054902; Tue, 16 Nov 2004 11:28:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSGUa054772 for <[e-mail]>; Tue, 16 Nov 2004 11:28:17 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25685 invoked by uid 1365); 16 Nov 2004 19:27:47 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:10 2004
Received: (qmail 24908 invoked from network); 16 Nov 2004 19:21:09 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:09 +0000
Received: (qmail 20236 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 7767 invoked by uid 1114); 15 Nov 2004 16:16:31 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 16:16:30 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFFswCc096334; Mon, 15 Nov 2004 07:54:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFFswF8096333; Mon, 15 Nov 2004 07:54:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFFsupp096244 for <[e-mail]>; Mon, 15 Nov 2004 07:54:57 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAFFsrD16263 for <[e-mail]>; Mon, 15 Nov 2004 16:54:53 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 15 Nov 2004 16:54:53 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAFFsr809681 for [e-mail]; Mon, 15 Nov 2004 16:54:53 +0100 (MET)
Date: Mon, 15 Nov 2004 16:54:53 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
X-Sun-Charset: US-ASCII
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Slide 7:  There is no "need to account for multiple CAs with the same 
> name". This formulation is pretty bad. A CA must provide different 
> names to two different entities. Since a CA name is relative to 
> another CA name space, there cannot be two CAs with the same name.
> 
> [SC: There is XX requirement or mechanism that ensures that a relying 
> party

It seems to me that there is a missing *no* where I added the XX.

> with multiple trust anchors will not encounter two CAs with the same 
> name. If a relying party has two trust anchors A and B and there are 
> two distinct companies with the same name C, it is possible that one C 
> is certified via A and another via B.]
> 
> [DP1: The assumption : "there is requirement or mechanism that ensures 
> that a relying party with multiple trust anchors will not encounter 
> two CAs with the same name" is fully wrong ! The same name may be 
> found.]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSKTH054905; Tue, 16 Nov 2004 11:28:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSKkv054904; Tue, 16 Nov 2004 11:28:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSGeZ054776 for <[e-mail]>; Tue, 16 Nov 2004 11:28:17 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25688 invoked by uid 1365); 16 Nov 2004 19:27:47 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:01 2004
Received: (qmail 24508 invoked from network); 16 Nov 2004 19:21:01 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:01 +0000
Received: (qmail 19957 invoked by alias); 16 Nov 2004 19:20:49 +0000
Delivered-To: [e-mail]
Received: (qmail 31729 invoked by uid 1114); 12 Nov 2004 19:34:02 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Fri, 12 Nov 2004 19:33:59 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACJNGK8013121; Fri, 12 Nov 2004 11:23:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACJNG1D013120; Fri, 12 Nov 2004 11:23:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACJNFiu013111 for <[e-mail]>; Fri, 12 Nov 2004 11:23:16 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iACJM62x030874 for <[e-mail]>; Fri, 12 Nov 2004 14:22:06 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iACJLZYB018811 for <[e-mail]>; Fri, 12 Nov 2004 14:21:36 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 12 Nov 2004 14:25:47 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Deadline for issues list for 3280bis
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I have previously requested that issues be submitted to David Cooper of 
NIST as the first step in this process, but only a handful of issues have 
been submitted to date.  I assume that means no one has any problems with 
the document's content!  If you are aware of outstanding issues, please 
submit them to David without delay at <[e-mail]>.

Please recall that the PKIX WG is shutting down.  This process cannot be 
allowed to go on forever.  To ensure that the 3280bis revision process is 
as efficient as possible, I am establishing a ***November 19**** deadline 
for submission of issues.  This is a hard deadline!  If  issues are raised 
after the 19th, they will be considered too late for consideration.

A word on scope: I have previously stated that new features would not be 
considered because we were going straight to DRAFT.  One of the ADs has 
informed me that the changes we are *required* to make with respect to 
processing international name forms will necessitate cycling at Proposed 
yet again.  This gives us some additional latitude in selecting which 
issues to address.  However, since we are trying to shut down, issues that 
would require definition of new features must be very well defined to 
ensure rapid completion of this document.

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSIk3054870; Tue, 16 Nov 2004 11:28:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSI7l054845; Tue, 16 Nov 2004 11:28:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSFxF054740 for <[e-mail]>; Tue, 16 Nov 2004 11:28:15 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25664 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:59 2004
Received: (qmail 24453 invoked from network); 16 Nov 2004 19:20:59 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:59 +0000
Received: (qmail 20016 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 27059 invoked by uid 1114); 9 Nov 2004 21:24:57 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Tue, 09 Nov 2004 21:24:55 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9L73Ox090299; Tue, 9 Nov 2004 13:07:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9L730F090298; Tue, 9 Nov 2004 13:07:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9L72Vn090292 for <[e-mail]>; Tue, 9 Nov 2004 13:07:02 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9L761X023653 for <[e-mail]>; Tue, 9 Nov 2004 16:07:06 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 16:07:06 -0500
Message-ID: <007b01c4c6a0$119c4ee0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA9L72Vn090293
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

One more thing.  Aside from the threat the algorithm mitigates described at
the end of the e-mail, the algorithm mitigates threats for Julien's rogue CA
scenario.  If the relying party had the legitimate path from the left side
of his diagram, using the path matching will ensure that they do not accept
the CRL from the rogue side.  Without the algorithm, they would.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 3:44 PM
To: '[e-mail]'
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting


Stefan,

See responses in line in [SC:}

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 2:06 PM
To: Denis Pinkas; Santosh Chokhani; Julien Stern
Cc: [e-mail]
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting


It seams that we have a problem with agreeing on the security assumptions
more than on the technical matters.

I recognize that Julien's scenario is a valid remark, at least in theory.
The point Julien is that there is a problem if an attacker that has obtained
a rouge CA under a valid root actually could fool an RP software to accept
the rouge path to the target certificate. IF the RP accept the path over the
rouge CA then that rouge CA could also defeat the proposed algorithm.

The question is just if this is a valid threat or not.

Denis is making a valid remark that different CA's in the certificate path
may certify different CRL Issuers with the same name by accident and the
algorithm doesn't account for that.

[SC: This is only an issue in the context of indirect CRL.  For the direct
CRL issuer, the algorithm will disambiguate the issues].

The question is if this is a valid threat or not.

Both Denis and Julien's scenarios require intentional malicious behaviour of
the CRL issuer or the CDP and the IDP wouldn't match (the storage location
pointer would differ).

[SC: I have not seen a scenario from Denis.  I have a different and simple
take on Julien's scenario.  First, Julien's scenario will not come about for
the relying parties who do not trust the rogue CA.  Second, the algorithm
makes sure that who ever is the certificate issuer from the relying party
perspective can only revoke the certificate.  Third, even if the same key
was used, in Julien's scenario relying party can always be fooled into using
bad revocation information along with bogus certificate minted by the rogue
CA.]

Both scenarios also require the attacker to convince the RP to NOT obtain
the correct CRL through the CDP pointer and instead accept the rough CRL
from other source OR it requires the attacker to hack the server holding the
real CRL and replace the real CRL with the rough CRL.

----------------

In Denis scenario I would suggest that we can exclude presence of a rouge CA
in the original certificate path, because if the original cert path has a
rouge CA, then all bets are off anyway.

This leaves us with Julien's scenario.

-----------------

So the main question is which of these threats that is in scope or out of
scope 

1) Presence of a trusted Rouge CA that is NOT part of the original
certificate path.

2) The ability of the attacker to fool the RP to pick a rouge path and rouge
CRL where the IDP and CDP match.

Questions/remarks:
- If both these threats are in scope then Julien's scenario is also valid.
- If there threats are out of scope, then what threat remains that requires
Santosh algorithm in the first place?

[SC: The threat that the algorithm mitigates is one of accidental error and
one of malfeasance.  Let me illustrate.  Let us say that both Microsoft and
VeriSign roots are in a relying party trust anchor  set.  Let us say that
that we have Microsoft --> Orion CA --> Chokhani.  Chokhani is an end entity
with serial number 10.  Let us also say that VeriSign has certified another
Orion.  So, we have VeriSign -->  Orion CA --> CRL X.  Now, some one can
compromise Chokhani key and play the CRL X  that does not contain 10 and
make the relying party access Chokhani certificate which actually has been
compromised.  In this case, all four CAs and Chokhani are playing nice, but
some one else just ate our lunch.]

I'm still pro Santosh algorithm since it limits complexity in path
processing but it would be good to know if there are any threats that
require Santosh algorithm which remains if at least problem 1 above is out
of scope.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSIGl054872; Tue, 16 Nov 2004 11:28:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSIX2054864; Tue, 16 Nov 2004 11:28:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSFni054736 for <[e-mail]>; Tue, 16 Nov 2004 11:28:15 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25679 invoked by uid 1365); 16 Nov 2004 19:27:47 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:09 2004
Received: (qmail 24863 invoked from network); 16 Nov 2004 19:21:09 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:09 +0000
Received: (qmail 20102 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 10451 invoked by uid 1114); 11 Nov 2004 02:13:31 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Thu, 11 Nov 2004 02:13:29 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB1gcJO016292; Wed, 10 Nov 2004 17:42:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAB1gcjo016291; Wed, 10 Nov 2004 17:42:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB1gWc5016208 for <[e-mail]>; Wed, 10 Nov 2004 17:42:37 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id E3CE6348BA; Thu, 11 Nov 2004 14:42:30 +1300 (NZDT)
Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23855-03; Thu, 11 Nov 2004 14:42:30 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 51ACC348C8; Thu, 11 Nov 2004 14:42:30 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 01B9537747; Thu, 11 Nov 2004 14:42:30 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CS3yr-0004aT-00; Thu, 11 Nov 2004 14:42:33 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
In-Reply-To: <000401c4c730$990f7060$[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 11 Nov 2004 14:42:33 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,DRUGS_ANXIETY,FROM_ENDS_IN_NUMS
X-Comodo-Spam-Score: -3.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Santosh Chokhani" <[e-mail]> writes:

>We are not communicating effectively.  I am sure others are not following us
>either.

Well, there had been an off-list suggestion that this thread be used as a
substitute for generic-brand valium...

Peter :-).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSIN3054873; Tue, 16 Nov 2004 11:28:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSI5w054867; Tue, 16 Nov 2004 11:28:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSEK4054735 for <[e-mail]>; Tue, 16 Nov 2004 11:28:15 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25676 invoked by uid 1365); 16 Nov 2004 19:27:47 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:00 2004
Received: (qmail 24477 invoked from network); 16 Nov 2004 19:21:00 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:00 +0000
Received: (qmail 20029 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 6225 invoked by uid 1114); 10 Nov 2004 17:23:11 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 17:23:10 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAH5dPt002112; Wed, 10 Nov 2004 09:05:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAH5dwv002111; Wed, 10 Nov 2004 09:05:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from citron.linagora.com (citron.linagora.com [195.68.36.78]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAH5cSn002092 for <[e-mail]>; Wed, 10 Nov 2004 09:05:38 -0800 (PST) (envelope-from [e-mail])
Received: from sgi2.linagora.com (sgi2.linagora.com [195.68.36.75]) by citron.linagora.com (Postfix) with ESMTP id 975968703; Wed, 10 Nov 2004 18:22:20 +0100 (CET)
Received: from sgi2 (sgi2 [127.0.0.1]) by localhost (Postfix) with SMTP id 208D5199B34; Wed, 10 Nov 2004 18:05:38 +0100 (CET)
Received: from tomate.linagora.lan (intranet.linagora.lan [192.168.1.3]) by sgi2.linagora.com (Postfix) with ESMTP id F3D0D199B32; Wed, 10 Nov 2004 18:05:37 +0100 (CET)
Received: by tomate.linagora.lan (Postfix, from userid 81) id 7192B7DB; Wed, 10 Nov 2004 18:19:39 +0100 (CET)
Received: from fw-lan.linagora.lan (fw-lan.linagora.lan [192.168.1.254])  by tomate.linagora.lan (IMP) with HTTP  for <[e-mail]>; Wed, 10 Nov 2004 18:19:39 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 18:19:39 +0100
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: Re: several key in same certificate
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 192.168.1.254
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME
X-Comodo-Spam-Score: -4.7
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

thank you for your preceding answer

> So, in all seriousness, I will assume that you're really asking about
> public keys that are used for certificate verification, and in that
> case, what you ask is certainly not possible, and it should be
> apparent if you read RFC 3280 or X.509 accurately.
>
I know RFC3280, I thought that perhaps somebody with have the idee of such a
process.

> Now, to get a real discussion going (if you want), why do you want to
> have more than one public key in your certificate?  What would they be
> used for, and most specifically, how would the appropriate key be
> selected for the operation you want to perform?
>
Because currently I have several keys (certificates) for the same entity. Each
certificate allows a particular function (different extendedKeyUsage and KeyUsage)

 I wondered whether the IETF, there a had been a reflexion, to extend a
certificate containing only one identity with several key and of the specific
extensions by keys.

An application could according to Keyusage and ExtendedKeyusage to take the good
key for for example applying a signature.

Thanks
Yannick Quenec'hdu



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSIZV054861; Tue, 16 Nov 2004 11:28:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSHvu054834; Tue, 16 Nov 2004 11:28:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSEf3054724 for <[e-mail]>; Tue, 16 Nov 2004 11:28:15 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25667 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:09 2004
Received: (qmail 24856 invoked from network); 16 Nov 2004 19:21:08 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:08 +0000
Received: (qmail 20230 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 19875 invoked by uid 1114); 15 Nov 2004 21:52:09 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 21:52:06 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFLXDtU016140; Mon, 15 Nov 2004 13:33:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFLXDfY016139; Mon, 15 Nov 2004 13:33:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFLXC3c016066 for <[e-mail]>; Mon, 15 Nov 2004 13:33:12 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1CToTB-000MxJ-Ly; Mon, 15 Nov 2004 21:33:05 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 21:33:51 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
CC: "David A. Cooper" <[e-mail]>
Subject: 3280bis: name constraints
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

IMHO some clarification of the nameConstraints extension should be 
included in RFC3280bis.

I can recall there being a number of threads discussing the meaning of 
name constraints for various types including the interpretation of the 
rfc822Name and dNSName fields. At the time various people had come to 
different conclusions based on the existing text.

I've not seen a description of how directoryName types are handled or a 
discussion on this.

IIRC X509 includes a note that if an unhandled constraint type is 
encountered the certificate should be rejected: should RFC3280bis 
include this too?

What about the minimum and maximum fields: should an implementation 
reject a certificate where these are present?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSFhS054819; Tue, 16 Nov 2004 11:28:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSFko054818; Tue, 16 Nov 2004 11:28:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJS2GU054595 for <[e-mail]>; Tue, 16 Nov 2004 11:28:04 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25661 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:08 2004
Received: (qmail 24842 invoked from network); 16 Nov 2004 19:21:08 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:08 +0000
Received: (qmail 20144 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 25724 invoked by uid 1114); 15 Nov 2004 22:44:19 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Mon, 15 Nov 2004 22:44:18 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMP9su030040; Mon, 15 Nov 2004 14:25:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFMP9Ur030038; Mon, 15 Nov 2004 14:25:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMP78v030025 for <[e-mail]>; Mon, 15 Nov 2004 14:25:07 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAFMOv2x011999; Mon, 15 Nov 2004 17:24:57 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAFMOYYB000386; Mon, 15 Nov 2004 17:24:34 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Nov 2004 17:06:40 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call: Attribute Certificate Schema
Cc: [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message initiates working group Last Call for the "LDAP Schema for 
X.509 Attribute Certificates" specification. The editors have confirmed 
that all working group issues have been resolved.

The URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-02.txt

This specification has also been forwarded to the LDAP Directorate for a 
parallel review.  Assuming successful Last Call and concurrence from the 
LDAP Directorate, this document will be forwarded to the ADs for 
consideration as an Informational track RFC.

Last Call will run for (at least) two weeks. That is, Last Call will not 
close before November 29.

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSCvY054794; Tue, 16 Nov 2004 11:28:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSCWu054793; Tue, 16 Nov 2004 11:28:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJRxu9054508 for <[e-mail]>; Tue, 16 Nov 2004 11:28:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25597 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:00 2004
Received: (qmail 24487 invoked from network); 16 Nov 2004 19:21:00 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:00 +0000
Received: (qmail 19945 invoked by alias); 16 Nov 2004 19:20:49 +0000
Delivered-To: [e-mail]
Received: (qmail 15632 invoked by uid 1114); 10 Nov 2004 10:23:02 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 10:23:00 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA9uYVp085145; Wed, 10 Nov 2004 01:56:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA9uYFp085144; Wed, 10 Nov 2004 01:56:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA9uU8X085061 for <[e-mail]>; Wed, 10 Nov 2004 01:56:31 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA81482; Wed, 10 Nov 2004 11:08:18 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111010561418:653 ; Wed, 10 Nov 2004 10:56:14 +0100 
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 10:56:13 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <006b01c4c696$64c124b0$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 10:56:14, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 10:56:15, Serialize complete at 10/11/2004 10:56:15
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

My responses with [DP1:]

===================================================================

Denis,

None of your comment seem to object to the path matching algorithm.

Please see specific responses below.

Santosh,

 > Denis,
 >
 > When you look at 3280 and add what I propose, what do you see is
 > missing?

Since you asked ... I will explain what is wrong in your slides.

Slide 5. The statement " A CA is defined by name alone" is wrong. A CA is
not simply defined by a name alone. A name, for X.509, is always relative to
the CA which has issued it. So the "clarification' to say that a CA is
unambiguously defined by name is wrong. Then since the other slides are
based on that wrong assumption, they are wrong as well.

[SC: Here is the quote from X.509 "NOTE 1 - Although the CAs are
unambiguously defined by a distinguished name in the DIT, this does not
imply that there is any relationship between the organization of the CAs and
the DIT."]

[DP1:  ... and this tells you exactly what I said]

Slide 7:  There is no "need to account for multiple CAs with the same name".
This formulation is pretty bad. A CA must provide different names to two
different entities. Since a CA name is relative to another CA name space,
there cannot be two CAs with the same name.

[SC: There is requirement or mechanism that ensures that a relying party
with multiple trust anchors will not encounter two CAs with the same name.
If a relying party has two trust anchors A and B and there are two distinct
companies with the same name C, it is possible that one C is certified via A
and another via B.]

[DP1: The assumption : "there is requirement or mechanism that ensures
that a relying party with multiple trust anchors will not encounter
two CAs with the same name" is fully wrong ! The same name may be found.]

Slide 8: The statement : "There can be more than one CA with the same name"
is wrong. Once again, a (CA) name is always relative to a CA name space.

[SC: There is requirement or mechanism that ensures that a relying party
with multiple trust anchors will not encounter two CAs with the same name.
If a relying party has two trust anchors A and B and there are two distinct
companies with the same name C, it is possible that one C is certified via A
and another via B.]

[DP1: See above]

Slide 8: The statement "starting from a TA, the relying party can match the
CA names in [ ] the CRL certification paths" is wrong as well. There is no
such notion of a "CRL certification path".

[SC: When you get a CRL by the Issuer name of the CA and the signature does
not verify, you will need to develop a certification path for the CRL.  Your
other choices are: do not check revocation information, or take the CRL on
faith even though signature has not been verified.  I do not consider either
of these choices in compliance with 3280.  Feel free to provide other
choices that do not entail building a certification path for the CRL.]

[DP1: It is quite the reverse. You got a CRL and you need to find out
if it is signed by the right key. You have to go down the tree and
not up the tree to make the right verification. You need to know
if the CA has nominated or not the candidate CRL Issuer, make sure
that the nomination is correct and has not been revoked. None of the
choices you mention are assumptions that I am making]

[SC: From the long discourse below, it seems that you are focused only on
indirect CRL issuance problem.  The path matching algorithm tries to solve
that as well as when the CA has used different keys to sign certificates and
CRL (e.g., due to key roll over or in general using two keys to sign the two
objects.]

[DP1: Before geeting into complicated cases like key rollover, we need
to make sure that the simple case where the CA is not signing the CRLs
for a given certificate is correctly addressed. There is no notion of
"CRL certification path"]

As indicated in RFC 3280, a CRL issuer is an optional
system to which a CA delegates the publication of CRLs.
This sentence is correct, but vague. (X.509 does not provide
a clear definition of what a CRL Issuer is).

Page 43 from RFC 3280: "The cRLIssuer identifies the entity
who signs and issues the CRL. If present, the cRLIssuer MUST contain at
least one an X.500 distinguished name (DN).

A CA will thus identify the DN of the CRL Issuer in the cRLIssuer field from
a CRL distribution point extension.

[SC: So far, I agree and the briefing is aligned with this]

[DP1: I am glad you agree with this, but I would not say that your
briefing is aligned with this]

That DN needs to be compared with a subject DN from a CRL Issuer
certificate, i.e. a certificate which has the cRLSign bit set (and that has
that DN as the subject name).

[SC: cRLSign bit is out side the scope of path matching.  All 3280 checks
for CRL imply.  As to name matching.  As to the name match check, that is
what bullet 1 on slide 13 does.]

[DP1: path matching is a mandatory feature, other tests need to be done;
in particular whether it is a CRL Issuer certificate. Only a test on
the keyUsage extension may provide you with this guarantee. Name matching
is more complicated that a DN comparison. DN comparison can only be made
if you know that th DNs are assigned by the same CA].

The question is then simply : how can a RP know that that CRL Issuer
certificate has been issued by the right CA ?

A simple answer to that question is to say that the CA that has placed the
CRL DP extension must be the one that has issued the CRL Issuer certificate.

[SC: This is one model.  There are other model where the CA need not issue a
certificate to the indirect CRL issuer]

[DP1: This is indeed the simpler model which SHALL be at least supported.
I envisaged another model, and it may be debatable if it should be
supported or not. I do do envisage more than two models, otherwise
we have a trillon cases where CRL Issuer issues revocation status
information for certificates and do not have received any delegation
of authority for that]

This means something very important. The TA used to verify
the CRL Issuer certificate is the same as the one used to verify the
certificate to be validated. All intermediate CAs are identical.

[SC: The path matching algorithm accounts for this.  Since there is no
requirement for the certificate issuing CA to directly issue a certificate
to the indirect CRL issuer, the matching algorithm may terminates
prematurely.]

[DP1: the problem is that the algorithm allows much more that this !
Then we can debate around the sentence you used above: "since there is
no requirement for the certificate issuing CA to directly issue
a certificate to the indirect CRL issuer". The big question is still
how the RP can know which CA is *allowed to nominate* the CRL Issuer.
As said earlier, the simplest model is precisely that the certificate
issuing CA directly issues a certificate to the indirect CRL issuer]

This rule can easily be interpreted by a relying party since
it needs first to have the certification path.

This is not the case for the algorithm you proposed, where different TAs are
used on one side to validate the certificate to be validated and on the
other side the CRL Issuer certificate.

[SC: The algorithm requires that the DN representing the same TA be used for
both paths. (See bullet 1 on slide 12.  The reason the same key (and hence
TA) is not used is to accommodate the case of the TA having been re-keyed.]

[DP1: Your statement saying that "the algorithm requires that the DN
representing the same TA be used for both paths" is wrong. For TAs what
is important is both the value of the public key and of the DN, but not
the value of the DN alone. In addition, this is not an assumption made
in your slides]

In this algorithm, two CRL Issuers with the same DN might appear in
different certification paths. So multiple CRL Issuer names could match the
criteria. The algorithm you proposed is flawed.

[SC: Can you give a more concrete example of it.  I know that the rules are
liberal for indirect CRL issuer since I do not believe that direct
delegation model is required]

[DP1: Quite easy.
Let us consider a certification chain: TA -> CA1 -> CA2 -> CA3.
CA1 can nominate a CRL Issuer with the following DN:
C0=US, DN="Gold CRLIssuer".
CA3 can also nominate a CRL Issuer with the following DN:
C0=US, DN="Gold CRLIssuer"].

[DP1: I believe that this long thread is sufficient to convince the chairs
that there is indeed yet not a consensus on that topic, and that instead
of slides we would need to agree on text addition in 3280bis. However,
before this, we need to agree on the concepts. I would have liked to
have corridor discussions with you on that topic before the PKIX meeting,
however I can't make it. I would think that a conference call, with a
moderator, would be useful if you are still not convinced by the above
arguments. Now, maybe someone else, in a face to face meeting before
or after the PKIX meeting could explain you better that I can do why
we have no consensus].

Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJSBFO054786; Tue, 16 Nov 2004 11:28:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJSBIg054785; Tue, 16 Nov 2004 11:28:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJS0IU054573 for <[e-mail]>; Tue, 16 Nov 2004 11:28:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25655 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:08 2004
Received: (qmail 24836 invoked from network); 16 Nov 2004 19:21:08 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:08 +0000
Received: (qmail 20153 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 23841 invoked by uid 1114); 13 Nov 2004 18:43:22 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Sat, 13 Nov 2004 18:43:19 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADI9VLq032763; Sat, 13 Nov 2004 10:09:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADI9VZV032762; Sat, 13 Nov 2004 10:09:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id iADI9Ull032740 for <[e-mail]>; Sat, 13 Nov 2004 10:09:30 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 4384 invoked by uid 0); 13 Nov 2004 18:09:18 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.244.63) by woodstock.binhost.com with SMTP; 13 Nov 2004 18:09:18 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Sat, 13 Nov 2004 13:09:18 -0500
To: Peter Sylvester <[e-mail]>, [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: DVCS ASN.1 module definition error
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please send errata to the RFC Editor.

Russ


At 10:09 AM 11/13/2004, Peter Sylvester wrote:

> >
> > Looks like a bug to me.  Peter, can you send the RFC Editor an errata 
> entry.
> >
>
>Yes, it's a bug. There is another bug that didn't find its way into the 
>final text.
>
>A more or less known know implementation uses the following syntax peiecs.
>
>Data ::= CHOICE {
>       message           OCTET STRING ,
>       messageImprint    DigestInfo,
>       certs             [0] SEQUENCE SIZE (1..MAX) OF TargetEtcChain
>}
>
>PathProcInput ::= SEQUENCE {
>      acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF 
> PolicyInformation,
>      inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
>      explicitPolicyReqd          [0] BOOLEAN DEFAULT FALSE,
>      inhibitAnyPolicy            [1] BOOLEAN DEFAULT FALSE
>}
>
>
>
> > Russ
> >
> > At 03:02 AM 11/5/2004, ChungKil Kim wrote:
> >
> > >hi there.
> > >
> > >i found asn.1 definition error.
> > >see following definition(rfc3029 Page 15).
> > >
> > >
> > >Data ::= CHOICE {
> > >message OCTET STRING ,
> > >messageImprint DigestInfo,
> > >certs SEQUENCE SIZE (1..MAX) OF
> > >TargetEtcChain
> > >}
> > >
> > >DigestInfo ::= SEQUENCE {
> > >digestAlgorithm DigestAlgorithmIdentifier,
> > >digest Digest
> > >}
> > >
> > >messageImprint and certs have same tag type. it can't be CHOICE. right?
> >
> >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJS9Zu054725; Tue, 16 Nov 2004 11:28:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJS9sR054709; Tue, 16 Nov 2004 11:28:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJRxv8054510 for <[e-mail]>; Tue, 16 Nov 2004 11:28:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25610 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:07 2004
Received: (qmail 24795 invoked from network); 16 Nov 2004 19:21:07 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:07 +0000
Received: (qmail 20132 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 5458 invoked by uid 1114); 11 Nov 2004 12:45:42 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Thu, 11 Nov 2004 12:45:40 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABC8njJ077156; Thu, 11 Nov 2004 04:08:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iABC8nhp077155; Thu, 11 Nov 2004 04:08:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABC8iS5077115 for <[e-mail]>; Thu, 11 Nov 2004 04:08:44 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iABC852x002511; Thu, 11 Nov 2004 07:08:05 -0500
Received: from [129.6.54.231] (sk.ncsl.nist.gov [129.6.54.231]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iABC7QYA015629; Thu, 11 Nov 2004 07:07:33 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 21:34:21 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <009e01c4c5b2$16d7f9c0$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12,HTML_MESSAGE,HTML_TITLE_EMPTY,MIME_HTML_ONLY,RATWR10_MESSID
X-Comodo-Spam-Score: -3.6
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Denis,<br>
<br>
X.509 states:<br>
<blockquote>NOTE 1 - Although the CAs are
unambiguously defined by a distinguished name in the DIT, this does not
imply that there is any relationship between the organization of the
CAs and
the DIT.<br>
</blockquote>
Where in X.509 does it say or even imply that a CA in not defined by
name alone, but that a name is always relative to the CA which has
issued it?&nbsp; I can't find anything in X.509 to support this.&nbsp; On the
other hand, there is plenty to support the notion a CA is defined by
name alone.&nbsp; In addition to the above quote, note that the
cRLDistributionPoints extension identifies an indirect CRL issuer by
name alone as does the certificateIssuer CRL entry extension.&nbsp; This
makes sense if a CA can be identified by name alone but does not make
sense if a CA name is only relative to the CA which has issued it.&nbsp;
Similarly, in many protocols, a certificate is identified by issuer
name and serial number.&nbsp; These two pieces of information would not be
sufficient to identify a certificate if your interpretation were
correct.<br>
<br>
I also do not understand your scenarios for indirect CRL issuance
(below).&nbsp; A CA is always allowed to issue CRLs that cover its own
certificates or delegate the issuance of CRLs to another entity.&nbsp; If
one CA issues a cross-certificate to another CA with cRLSign set to
FALSE, that does not mean that the subject CA is not permitted to issue
CRLs.&nbsp; It simply means that the subject public key in that
cross-certificate can not be used to verify CRL signatures. It could
simply be that the subject CA uses different keys to sign certificates
and CRLs.&nbsp; The subject CA could always create a self-issued certificate
with cRLSign set to TRUE in which the subject public key in the
self-issued certificate corresponds to the CRL signing key.&nbsp; This would
not be contrary to X.509 at all.<br>
<br>
Dave<br>
<br>
<br>
Denis Pinkas wrote:
<blockquote cite="[e-mail]" type="cite">Slide 5.
The statement " A CA is defined by name alone" is
  <br>
wrong. A CA is not simply defined by a name alone. A name,
  <br>
for X.509, is always relative to the CA which has issued it.
  <br>
So the "clarification' to say that a CA is unambiguously
  <br>
defined by name is wrong. Then since the other slides are
  <br>
based on that wrong assumption, they are wrong as well.
  <br>
  <br>
Slide 7:&nbsp; There is no "need to account for multiple CAs with
  <br>
the same name". This formulation is pretty bad. A CA must
  <br>
provide different names to two different entities. Since a CA
  <br>
name is relative to another CA name space, there cannot be
  <br>
two CAs with the same name.
  <br>
  <br>
Slide 8: The statement : "There can be more than one CA with
  <br>
the same name" is wrong. Once again, a (CA) name is always
  <br>
relative to a CA name space.
  <br>
</blockquote>
<br>
Denis Pinkas wrote:
<blockquote cite="[e-mail]" type="cite"> The CRL
Issuer is *not* the CA. This CA is called CA 1. <br>
CA 2 is a CA that has issued a CA certificate to CA 1. <br>
  <br>
&nbsp;a) the CRL Issuer is nominated by CA 1 that has issued <br>
&nbsp;&nbsp;&nbsp; the end-user certificate. This case would make sense <br>
&nbsp;&nbsp;&nbsp; when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates <br>
&nbsp;&nbsp;&nbsp; that role to one or more CRL Issuers. This means that <br>
&nbsp;&nbsp;&nbsp; a CRL Issuer certificate is issued by CA 1 to every CRL Issuer. <br>
  <br>
&nbsp;b) the CRL Issuer is nominated by CA 2 that has issued a CA <br>
&nbsp;&nbsp;&nbsp; certificate to CA 1. This case would make sense when CA 2 <br>
&nbsp;&nbsp;&nbsp; has not allowed CA 1 to issue CRLs. This means that a CRL Issuer <br>
&nbsp;&nbsp;&nbsp; certificate is issued by CA 2 to every CRL Issuer. CA 1 may <br>
&nbsp;&nbsp;&nbsp; then only choose a CRL Issuer that has been granted <br>
&nbsp;&nbsp;&nbsp; the authorization to issue CRLs by CA 2.<br>
</blockquote>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJS9b0054727; Tue, 16 Nov 2004 11:28:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJS9cr054711; Tue, 16 Nov 2004 11:28:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJRxa2054504 for <[e-mail]>; Tue, 16 Nov 2004 11:28:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25643 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:59 2004
Received: (qmail 24431 invoked from network); 16 Nov 2004 19:20:59 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:59 +0000
Received: (qmail 20026 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 23590 invoked by uid 1114); 10 Nov 2004 01:32:55 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 01:32:52 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA141Ei091334; Tue, 9 Nov 2004 17:04:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA141e9091333; Tue, 9 Nov 2004 17:04:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA140GM091238 for <[e-mail]>; Tue, 9 Nov 2004 17:04:00 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id B7DD741AF1 for <[e-mail]>; Wed, 10 Nov 2004 02:03:54 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 6D265440E7 for <[e-mail]>; Wed, 10 Nov 2004 02:04:28 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25213-01 for <[e-mail]>; Wed, 10 Nov 2004 02:04:25 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id EFFC0440AF for <[e-mail]>; Wed, 10 Nov 2004 02:04:24 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 10 Nov 2004 02:03:52 +0100
From: "Julien Stern" <[e-mail]>
Date: Wed, 10 Nov 2004 02:03:52 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

see my comments in-line with [JS].

On Tue, Nov 09, 2004 at 07:05:32PM -0000, Stefan Santesson wrote:
> It seams that we have a problem with agreeing on the security
> assumptions more than on the technical matters.
>
> I recognize that Julien's scenario is a valid remark, at least in
> theory. The point Julien is that there is a problem if an attacker that
> has obtained a rouge CA under a valid root actually could fool an RP
> software to accept the rouge path to the target certificate. IF the RP
> accept the path over the rouge CA then that rouge CA could also defeat
> the proposed algorithm.
> 
> The question is just if this is a valid threat or not.
> 
> Denis is making a valid remark that different CA's in the certificate
> path may certify different CRL Issuers with the same name by accident
> and the algorithm doesn't account for that.
> 
> The question is if this is a valid threat or not.
> 
> Both Denis and Julien's scenarios require intentional malicious
> behaviour of the CRL issuer or the CDP and the IDP wouldn't match (the
> storage location pointer would differ).
> 
> Both scenarios also require the attacker to convince the RP to NOT
> obtain the correct CRL through the CDP pointer and instead accept the
> rough CRL from other source OR it requires the attacker to hack the
> server holding the real CRL and replace the real CRL with the rough CRL.
> 
> ----------------
> 
> In Denis scenario I would suggest that we can exclude presence of a
> rouge CA in the original certificate path, because if the original cert
> path has a rouge CA, then all bets are off anyway.
> 
> This leaves us with Julien's scenario.
> 
> -----------------
> 
> So the main question is which of these threats that is in scope or out
> of scope 
> 
> 1) Presence of a trusted Rouge CA that is NOT part of the original
> certificate path.
> 
> 2) The ability of the attacker to fool the RP to pick a rouge path and
> rouge CRL where the IDP and CDP match.

[JS thanks for this nice summary of the situation (well, for my
threat at least, I'll let Denis comment on his).

At you said in the beginning of your email, I think we need to define
at least a minimal security and adversarial model.

I though that the strict separation of two different hierachies that
are not cross-certified could be a security goal.

I also though that the compromise of a CA is a plausible scenario,
and that it should not affect any other CA above it or in unrelated
hierarchy.

However, it is true that in practice, the attack is fairly difficult
to mount, even assuming a CA compromise.]

> Questions/remarks:
> - If both these threats are in scope then Julien's scenario is also
> valid.
> - If there threats are out of scope, then what threat remains that
> requires Santosh algorithm in the first place?
> 
> I'm still pro Santosh algorithm since it limits complexity in path
> processing but it would be good to know if there are any threats that
> require Santosh algorithm which remains if at least problem 1 above is
> out of scope.

[JS: Santosh algorithm clearly renders the attack more difficult, and
may prevent mistake.

But what is does is ensuring that two certificates belong to
the same entities, assuming that the CAs in their respectives trust
path are uncompromised and never gave the same DN to two different
entities.

This algorithm can certainly be useful, for CRL, and maybe other things.
However, as I have shown, it only renders the attack harder, not
impossible. What we need is a algorithm that shows the certificates
belong to the same entity AND that this entity actually delivered
the certificate.

It my threat model is considered unrealistic, I'm also in favor
of Santosh algorithm. Otherwise, I think it is only a patch on a
security hole, and that we should find a way to actually plug this hole.

Maybe could we simply add an extension in the EE certificate specifying
the public key of the CRL Issuer ? The CA could simply and securely
delegate to his other key or to an other entity this way.]

--
Julien



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJS9xk054729; Tue, 16 Nov 2004 11:28:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJS995054718; Tue, 16 Nov 2004 11:28:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJRxTn054501 for <[e-mail]>; Tue, 16 Nov 2004 11:28:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25640 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:08 2004
Received: (qmail 24815 invoked from network); 16 Nov 2004 19:21:08 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:08 +0000
Received: (qmail 20180 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 21829 invoked by uid 1114); 10 Nov 2004 15:30:59 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 15:30:55 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFEtXn063634; Wed, 10 Nov 2004 07:14:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAFEtj6063633; Wed, 10 Nov 2004 07:14:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFErho063624 for <[e-mail]>; Wed, 10 Nov 2004 07:14:54 -0800 (PST) (envelope-from [e-mail])
Received: from real2.localdomain ([192.168.2.11]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAAFEjmc011326 for <[e-mail]>; Wed, 10 Nov 2004 10:14:45 -0500
Received: from real2.localdomain (real2.localdomain [127.0.0.1]) by real2.localdomain (8.12.8/8.12.8) with ESMTP id iAAFEjF6025229 for <[e-mail]>; Wed, 10 Nov 2004 10:14:45 -0500
Received: (from apache@localhost) by real2.localdomain (8.12.8/8.12.8/Submit) id iAAFEfmT025218 for [e-mail]; Wed, 10 Nov 2004 10:14:41 -0500
Received: from 130.129.132.131 ([130.129.132.131])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Wed, 10 Nov 2004 10:14:41 -0500
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 10:14:41 -0500
From: [e-mail]
To: [e-mail]
Subject: Updated PKIX Agenda - 61st IETF
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 130.129.132.131
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME
X-Comodo-Spam-Score: -4.7
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

Just thought I would pass on a few minor updates to the PKIX agenda.  I made a 
few changes in the ordering, updated the SCVP URL (it is -16, not -15), 
inserted a presentation for Lightwieght OCSP, and reflected two speaker 
changes (BaeHyo Park will present the User Interface Requirements; I will 
present Dan Brown's Elliptic Curve slides.)

Thanks,

Tim

=========================================================================


Public-Key Infrastructure (X.509) WG (pkix)

Wednesday, November 10 at 1300-1500
===================================

CHAIRS: Stephen Kent <[e-mail]>
        Tim Polk <[e-mail]>

1. WG Status and Direction

1.1 Document Status Review [Tim Polk (NIST)]

       The working group has a number of Internet-Drafts.  Many
       documents are with the ADs or in various stages of WG Last Call.
       Several others are ready for Last Call. (10 min.)

2. PKIX WG Specifications

2.1 Simple Certificate Validation Protocol (SCVP)
       Trveor Freeman (Microsoft)
         submitted new draft, available soon at
      http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-16.txt

      A new draft has been submitted with significant enhancements.  This
      presentation will highlight those changes and their rationale.
      (30 min.)

2.2 3280bis
        Tim Polk (NIST)
        (no draft)

      The co-chairs have selected a lead editor for RFC 3280bis and formed
      a design team to develop a -00 draft from a issues list complied from
      PKIX mail messages and mail to the RFC 3280 editors.  Draft -00 is
      expected late in 2004.  This presentation will focus on scope and
      process.
      (10 min.)

2.3 Discovering CRL Signer Certificates Using AIA
        Stefan Santesson (Microsoft)
        (draft after meeting)

      The ADs have approved a new PKIX document on this topic.  The first draft
      will be posted after this meeting.  This presentation will describe the
      problem and the projected -00 solution.
      (5 min.)

2.4 Issues and Recommendations on CRL Processing Rules
        Santosh Chokhani (Orion)
        (no draft)

      This presentation will provide a comprehensive review of issues in
      CRL Processing.  Issues are identified in RFCs 3280 and 2560; changes
      are proposed to resolve these issues.  Relationship with ISO's X.509
      standard is also addressed
      (15 min.)

2.5 LDAP Schemas
         David Chadwick (Univ. of Salford)
  http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-03.txt
  http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-02.txt

      The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution
      for LDAP based PKI information distribution.  New drafts of two documenta
      have been submitted since IETF 60 and are in WG Last Call.  (10 min.)

2.6 LDAP PKIX Schema Issues
      Kent Zeilenga (LDAP WG co-chair)
      (no draft)

      This presentation identify remaining issues for PKI LDAP schemas and
      (where applicable) ways to address them.
      (10 min.)

2.7 Lightweight OCSP for High Volume Environments
      Ryan Hurst (Microsoft)
      ttp://www.ietf.org/internet-drafts/
                         draft-ietf-pkix-lightweight-ocsp-profile-01.txt
      
      This document profiles OCSP for use in high volume PKI environments
      and PKI environments that require a lightweight solution to minimize
      bandwidth and client side processing.

      (10 min.)

2.8 Algorithm IDs for Elliptic Curve Cryptography in PKIX
      Tim Polk (NIST) for Daniel Brown (Certicom)
      http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-00.txt

      This document is stable and ready for progression.  The WG needs to
      select a startegy for progression: progress indpendently or in a
      revision of RFC 3279?
      (10 min.)

3. Related Specifications & Liaison Presentations

      Time allowing, liaison presentations will be accommodated to ensure the
      PKIX WG is aware of related specifications currently progressing as
      individual drafts.

    3.1 User Interface Requirements for PKIX
      BaeHyo Park (KISA)
      http://www.ietf.org/internet-drafts/draft-choi-pkix-ui-01.txt

      This document is a personal draft.  The presentation is a follow-up to
      a presentation on draft -00 at IETF-60.  Many people asked about the all
      important look and feel of the user interface; this short demonstration
      should further understanding and promote additional discussion.
      (10 min.)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJS9fG054726; Tue, 16 Nov 2004 11:28:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJS82D054708; Tue, 16 Nov 2004 11:28:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJRxkH054517 for <[e-mail]>; Tue, 16 Nov 2004 11:28:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25621 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:08 2004
Received: (qmail 24814 invoked from network); 16 Nov 2004 19:21:07 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:07 +0000
Received: (qmail 20168 invoked by alias); 16 Nov 2004 19:20:51 +0000
Delivered-To: [e-mail]
Received: (qmail 4715 invoked by uid 1114); 10 Nov 2004 03:35:56 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 03:35:53 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA3BeBT043457; Tue, 9 Nov 2004 19:11:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA3BeKw043456; Tue, 9 Nov 2004 19:11:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA3BdLK043448 for <[e-mail]>; Tue, 9 Nov 2004 19:11:39 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iAA3Bj4a017537 for <[e-mail]>; Tue, 9 Nov 2004 22:11:45 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 22:11:39 -0500
Message-ID: <001701c4c6d3$02170a40$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAA3BdLK043450
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00
X-Comodo-Spam-Score: -4.9
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

The basic point is that there are many ways to compromise the security of
X.509 once a relying party trusts a rogue CA.  Path matching algorithm will
not fix that.  Whether you use the algorithm or not, these problems remain.
If you do not use the algorithm, there are attacks that will not be
mitigated.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Tuesday, November 09, 2004 8:17 PM
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



Santosh,

comments in line with [JS]

On Tue, Nov 09, 2004 at 03:43:52PM -0500, Santosh Chokhani wrote:
> 
> Stefan,
> 
> See responses in line in [SC:}
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Tuesday, November 09, 2004 2:06 PM
> To: Denis Pinkas; Santosh Chokhani; Julien Stern
> Cc: [e-mail]
> Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> It seams that we have a problem with agreeing on the security 
> assumptions more than on the technical matters.
> 
> I recognize that Julien's scenario is a valid remark, at least in 
> theory. The point Julien is that there is a problem if an attacker 
> that has obtained a rouge CA under a valid root actually could fool an 
> RP software to accept the rouge path to the target certificate. IF the 
> RP accept the path over the rouge CA then that rouge CA could also 
> defeat the proposed algorithm.
> 
> The question is just if this is a valid threat or not.
> 
> Denis is making a valid remark that different CA's in the certificate 
> path may certify different CRL Issuers with the same name by accident 
> and the algorithm doesn't account for that.
> 
> [SC: This is only an issue in the context of indirect CRL.  For the 
> direct CRL issuer, the algorithm will disambiguate the issues].
> 
> The question is if this is a valid threat or not.
> 
> Both Denis and Julien's scenarios require intentional malicious 
> behaviour of the CRL issuer or the CDP and the IDP wouldn't match (the 
> storage location pointer would differ).
> 
> [SC: I have not seen a scenario from Denis.  I have a different and 
> simple take on Julien's scenario.

> First, Julien's scenario will not come about for
> the relying parties who do not trust the rogue CA.

[JS: this is true, but the rogue CA could be anywhere in the hierarchy of
any trusted anchor. Also, if you assume no CA rogue CA is trusted, your
algorithm mostly only simplifies path construction.]

> Second, the algorithm
> makes sure that who ever is the certificate issuer from the relying 
> party perspective can only revoke the certificate.

[JS: the whole point being that it is simple to conterfeit the certicate
issuer from the relying party perspective. Trust in X509 in going down, not
up. This is how the attck works.]

> Third, even if the same key
> was used, in Julien's scenario relying party can always be fooled into 
> using bad revocation information along with bogus certificate minted 
> by the rogue CA.]

[JS: it might be possible to perform an attack even when the same key is
used, but my current scenario does not. The attack would be much more
complex. It do not see to what scenario you refer to.]


> 
> Both scenarios also require the attacker to convince the RP to NOT 
> obtain the correct CRL through the CDP pointer and instead accept the 
> rough CRL from other source OR it requires the attacker to hack the 
> server holding the real CRL and replace the real CRL with the rough 
> CRL.
> 
> ----------------
> 
> In Denis scenario I would suggest that we can exclude presence of a 
> rouge CA in the original certificate path, because if the original 
> cert path has a rouge CA, then all bets are off anyway.
> 
> This leaves us with Julien's scenario.
> 
> -----------------
> 
> So the main question is which of these threats that is in scope or out 
> of scope
> 
> 1) Presence of a trusted Rouge CA that is NOT part of the original 
> certificate path.
> 
> 2) The ability of the attacker to fool the RP to pick a rouge path and 
> rouge CRL where the IDP and CDP match.
> 
> Questions/remarks:
> - If both these threats are in scope then Julien's scenario is also 
> valid.
> - If there threats are out of scope, then what threat remains that
requires
> Santosh algorithm in the first place?
> 
> [SC: The threat that the algorithm mitigates is one of accidental 
> error and one of malfeasance.  Let me illustrate.  Let us say that 
> both Microsoft and VeriSign roots are in a relying party trust anchor  
> set.  Let us say that that we have Microsoft --> Orion CA --> 
> Chokhani.  Chokhani is an end entity with serial number 10.  Let us 
> also say that VeriSign has certified another Orion.  So, we have 
> VeriSign -->  Orion CA --> CRL X.  Now, some one can compromise 
> Chokhani key and play the CRL X  that does not contain 10 and make the 
> relying party access Chokhani certificate which actually has been 
> compromised.  In this case, all four CAs and Chokhani are playing 
> nice, but some one else just ate our lunch.]

[JS: it seems to me that you assume that you can force the use of a CRL over
an other for the attack you described work.

So the difference between our threat models, security wise, is that you
assume all CA are honests and never compromised but can make mistakes, while
I assume a CA can act in a dishonest way. It that correct ?]

> 
> I'm still pro Santosh algorithm since it limits complexity in path 
> processing but it would be good to know if there are any threats that 
> require Santosh algorithm which remains if at least problem 1 above is 
> out of scope.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJS9t1054728; Tue, 16 Nov 2004 11:28:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJS9uT054717; Tue, 16 Nov 2004 11:28:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJRxqf054500 for <[e-mail]>; Tue, 16 Nov 2004 11:28:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25605 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:58 2004
Received: (qmail 24402 invoked from network); 16 Nov 2004 19:20:58 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:58 +0000
Received: (qmail 20004 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 3453 invoked by uid 1114); 13 Nov 2004 14:37:10 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Sat, 13 Nov 2004 14:37:07 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADDtqNB075896; Sat, 13 Nov 2004 05:55:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADDtqZY075895; Sat, 13 Nov 2004 05:55:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADDtonq075869 for <[e-mail]>; Sat, 13 Nov 2004 05:55:51 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA32962; Sat, 13 Nov 2004 15:07:45 +0100
Received: from bull.net ([129.181.81.126]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111314553651:1052 ; Sat, 13 Nov 2004 14:55:36 +0100 
Message-ID: <[e-mail]>
Date: Sat, 13 Nov 2004 14:56:49 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: pkix <[e-mail]>
Subject: 3280bis: certificate revocation status responsibility (1/3)
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 02:55:37 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 02:55:40 PM, Serialize complete at 11/13/2004 02:55:40 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

3280bis: certificate revocation status responsibility (1/3)

This is an addition proposal related to indirect CRLs.

X.509 states in section 7.3:

"7.3  Certificate validity

The authority that issues certificates (public-key or attribute) also
has the responsibility to indicate the validity of certificates it
issues.  Generally, certificates are subject to possible subsequent
revocation. This revocation, and notification of the revocation may be
done directly by the same authority that issued the certificate, or
indirectly by another authority duly authorized by the authority that
issued the certificate. "

This text from section 7.3 of X.509 should be imported into RFC 3280 and
this will close the issue about which entity MUST nominate the CRL
Issuer. The title of that section should be renamed "certificate
revocation status responsibility" and should be slightly re-arranged.
Hereafter is a proposal:

"X. Certificate revocation status responsibility

The authority that issues certificates (public-key or attribute) has
the responsibility to indicate the revocation status of certificates
it issues. Generally, certificates are subject to possible subsequent
revocation. This revocation, and notification of the revocation may be
done directly by the same authority that issued the certificate, or
indirectly by another authority duly authorized by the authority that
issued the certificate."

RFC 3280 does not provide a formal definition for an indirect CRL, but
it could be inferred from the content of section 5, whenever the CRL
issuer is not the CA that issued the certificates, the CRL is referred
to as an indirect CRL.

Proposed definition:

"indirect CRL: A revocation list that is not issued directly by a CA
but by authority duly authorized by a CA".

Other parts of RFC 3280 explain that an indirect CRL may be understood
as a revocation list that provides revocation information about
certificates either issued by:

    a) a single CA, or
    b) multiple CAs.

In case a), called "indirect CRL of type a)", an indirect CRL provides
revocation information for certificates issued by one CA, and for
which a delegation has been granted by that CA.

In case b), called "indirect CRL of type b)", an indirect CRL still
provides revocation information for certificates issued by one CA, but
also for certificates issued by others CAs.

It should then be explained how a relying party may verify that
delegation has indeed been granted by a CA to a CRL Issuer.

The following text is proposed to be happened after the previous
proposed text:

"Assuming that the relying party has found a candidate CRL, the DN
contained in the issuer field from the CRL SHALL match the subject DN
contained a CRL Issuer certificate (i.e. a certificate which has the
cRLSign bit set in the keyUsage extension) issued to the CRL Issuer by
the CA that has issued the certificate to be tested.

In order to prevent DN ambiguity, the CRL Issuer SHALL not accept to
manage revocation status information for a given CA DN, if it already
manages revocation status information for another CA that has the same
DN."

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJS75o054681; Tue, 16 Nov 2004 11:28:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJS7dV054673; Tue, 16 Nov 2004 11:28:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJRx2l054519 for <[e-mail]>; Tue, 16 Nov 2004 11:28:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25624 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:59 2004
Received: (qmail 24424 invoked from network); 16 Nov 2004 19:20:59 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:59 +0000
Received: (qmail 20010 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 15908 invoked by uid 1114); 10 Nov 2004 14:50:28 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 14:50:25 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEaJ4c049568; Wed, 10 Nov 2004 06:36:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAEaJ7w049567; Wed, 10 Nov 2004 06:36:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEaELH049523 for <[e-mail]>; Wed, 10 Nov 2004 06:36:17 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA75672; Wed, 10 Nov 2004 15:48:08 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111015360404:824 ; Wed, 10 Nov 2004 15:36:04 +0100 
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 15:36:02 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: Julien Stern <[e-mail]>
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <006b01c4c696$64c124b0$[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 15:36:04, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 15:36:08, Serialize complete at 10/11/2004 15:36:08
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To the list,

After a direct (phone) talk with Julien, we came to the conclusion that, for 
the time being (i.e. without changing anything in the definition CRL DP 
extension), there is a *single* method which is secure for any CA (different 
from the TA) in a certification chain.

In the following, there is an attempt to define that single method.

The requirements for the CA would be:

"The CA that places a CRL DP extension in a certificate with a cRLIssuer
field present SHALL issue a CRL Issuer certificate for the DN contained
in that cRLIssuer field".

  ... while the requirements for RPs would be :

"When a CRL is not signed by the CA that has issued the certificate
to be validated, then that CRL SHALL be *verified* by the RP using
the public key of a CRL Issuer contained in a CRL Issuer certificate
that has been issued by the CA that has placed a CRL DP extension
in the certificate to be validated and where the DN contained in
the subject field from that CRL Issuer certificate SHALL match
the DN contained in the cRLIssuer field of the CRL DP extension."

Additional sentences would need to address the means to make sure
that the CRL Issuer certificate is not revoked (see my previous
e-mail on that topic).

Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJS7vt054683; Tue, 16 Nov 2004 11:28:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJS7fC054680; Tue, 16 Nov 2004 11:28:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJRxSP054509 for <[e-mail]>; Tue, 16 Nov 2004 11:28:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25600 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:21:09 2004
Received: (qmail 24877 invoked from network); 16 Nov 2004 19:21:09 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:21:09 +0000
Received: (qmail 20105 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 388 invoked by uid 1114); 10 Nov 2004 16:48:18 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 16:48:16 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAGSZBL091502; Wed, 10 Nov 2004 08:28:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAGSZ81091501; Wed, 10 Nov 2004 08:28:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from citron.linagora.com (citron.linagora.com [195.68.36.78]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAGSRLd091424 for <[e-mail]>; Wed, 10 Nov 2004 08:28:27 -0800 (PST) (envelope-from [e-mail])
Received: from sgi2.linagora.com (sgi2.linagora.com [195.68.36.75]) by citron.linagora.com (Postfix) with ESMTP id 5A88C8726; Wed, 10 Nov 2004 17:45:02 +0100 (CET)
Received: from sgi2 (sgi2 [127.0.0.1]) by localhost (Postfix) with SMTP id D6087199B31; Wed, 10 Nov 2004 17:28:19 +0100 (CET)
Received: from tomate.linagora.lan (intranet.linagora.lan [192.168.1.3]) by sgi2.linagora.com (Postfix) with ESMTP id 82CB1199B33; Wed, 10 Nov 2004 17:28:19 +0100 (CET)
Received: by tomate.linagora.lan (Postfix, from userid 81) id B7D847DB; Wed, 10 Nov 2004 17:42:20 +0100 (CET)
Received: from fw-lan.linagora.lan (fw-lan.linagora.lan [192.168.1.254])  by tomate.linagora.lan (IMP) with HTTP  for <[e-mail]>; Wed, 10 Nov 2004 17:42:20 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 17:42:20 +0100
From: [e-mail]
To: Richard Levitte - VMS Whacker <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: several key in same certificate
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 192.168.1.254
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME
X-Comodo-Spam-Score: -4.7
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

thank you for your preceding answer 

> So, in all seriousness, I will assume that you're really asking about
> public keys that are used for certificate verification, and in that
> case, what you ask is certainly not possible, and it should be
> apparent if you read RFC 3280 or X.509 accurately.
> 
I know RFC3280, I thought that perhaps somebody with have the idee of such a
process. 

> Now, to get a real discussion going (if you want), why do you want to
> have more than one public key in your certificate?  What would they be
> used for, and most specifically, how would the appropriate key be
> selected for the operation you want to perform?
> 
Because currently I have several keys (certificates) for the same entity. Each
certificate allows a particular function (different extendedKeyUsage and KeyUsage) 

 I wondered whether the IETF, there a had been a reflexion, to extend a
certificate containing only one identity with several key and of the specific
extensions by keys.

An application could according to Keyusage and ExtendedKeyusage to take the good
key for for example applying a signature.

Thanks
Yannick Quenec'hdu
> Cheers,
> Richard
> 
> -----
> Please consider sponsoring my work on free software.
> See http://www.free.lp.se/sponsoring.html for details.
> 
> -- 
> Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
> Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
> T: [phone] |                             | SWEDEN
>      "Price, performance, quality...  choose the two you like"
> 
> 
> 






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJS7RK054682; Tue, 16 Nov 2004 11:28:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGJS7bk054679; Tue, 16 Nov 2004 11:28:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kylie.comodo.net (comodo.gotadsl.co.uk [62.3.237.187]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGJS2eE054591 for <[e-mail]>; Tue, 16 Nov 2004 11:28:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25658 invoked by uid 1365); 16 Nov 2004 19:27:46 +0000
MBOX-Line: From gate  Tue Nov 16 19:20:59 2004
Received: (qmail 24446 invoked from network); 16 Nov 2004 19:20:59 +0000
Received: from jason.comodo.net (192.168.128.202) by 192.168.0.201 with DES-CBC3-SHA encrypted SMTP; 16 Nov 2004 19:20:59 +0000
Received: (qmail 20036 invoked by alias); 16 Nov 2004 19:20:50 +0000
Delivered-To: [e-mail]
Received: (qmail 3756 invoked by uid 1114); 13 Nov 2004 14:41:08 +0000
Received-SPF: pass (jason.comodo.net: local policy)
Received: from above.proper.com (HELO above.proper.com) (208.184.76.39) by jason.comodo.net (qpsmtpd/0.28) with ESMTP; Sat, 13 Nov 2004 14:41:07 +0000
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADDuqYQ076025; Sat, 13 Nov 2004 05:56:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADDuqDb076024; Sat, 13 Nov 2004 05:56:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADDup3p076001 for <[e-mail]>; Sat, 13 Nov 2004 05:56:51 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA32968; Sat, 13 Nov 2004 15:08:54 +0100
Received: from bull.net ([129.181.81.126]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111314564453:1053 ; Sat, 13 Nov 2004 14:56:44 +0100 
Message-ID: <[e-mail]>
Date: Sat, 13 Nov 2004 14:57:58 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: pkix <[e-mail]>
Subject: 3280bis: CRL processing for indirect CRLs (2/3)
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 02:56:46 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 02:56:47 PM, Serialize complete at 11/13/2004 02:56:47 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Comodo-Spam-Check-By: jason.comodo.net
X-Comodo-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RATWR10_MESSID
X-Comodo-Spam-Score: -4.8
X-Comodo-ClamAV-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-ClamAV-Virus-Version: clamscan / ClamAV version 0.75.1
X-Comodo-F-Prot-Virus-Check-By: jason.comodo.net - PASSED!
X-Comodo-F-Prot-Virus-Program: F-PROT ANTIVIRUS Program version: 4.4.7 Engine version: 3.14.13 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

3280bis: CRL processing for indirect CRLs (2/3)

This is an addition proposal related to indirect CRLs.

The following text is proposed:

"X. CRL processing for indirect CRLs

X.1. Basic processing

For an indirect CRL, the relying party :

 - SHOULD fetch a CRL looking at the content of distributionPoint
   field the from the CRL DP extension of the certificate for which
   a revocation status is looked for, 

 - SHALL find a CRL Isssuer certificate that contains the DN of the
   CRL Issuer as indicated in the cRLIssuer field from the CRL DP
   extension,

 - SHALL verify that this CRL Isssuer certificate is signed by the CA
   which has issued the certificate for which a revocation status is
   looked for.

 - SHALL verify that this CRL Isssuer certificate is not revoked
   (see section X.2)
 
     If the indirectCRL boolean from the Issuing Distribution

     Point extension of the CRL is missing or set to FALSE, SHALL find
     out a CRL entry containing the certificate serial number of the
     certificate for which a revocation status is looked for. If no
     entry is found, then the certificate is valid. If an entry is
     found, then the certificate is revoked. 

     If the indirectCRL boolean from the Issuing Distribution Point
     extension of the CRL is set to TRUE, SHALL find out all CRL
     entries containing the certificate serial number of the
     certificate for which a revocation status is looked for.

       If no entry is found, the certificate is valid.

       If an entry is found, then for each found entry the following
       processing SHALL be done: 

          SHALL compare the DN contained in the issuer field from
          the certificate for which a revocation status is looked for,
          with the DN contained in every the certificateIssuer entry
          extension.  

             If there is no match and if there is no certificateIssuer
             entry extension present before this CRL entry, then the
             certificate is revoked.
 
             If there is a match and if the certificateIssuer entry
             extension present before this CRL entry matches the name
             of the DN contained in the issuer field from the
             certificate for which a revocation status is looked for,
             then the certificate is revoked.
 
             Otherwise, the certificate is valid. 

X.2 Verification that the CRL Isssuer certificate is not revoked
 
(text to be provided) ".

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGIwiLO041720; Tue, 16 Nov 2004 10:58:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGIwivS041719; Tue, 16 Nov 2004 10:58:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGIwgNG041669 for <[e-mail]>; Tue, 16 Nov 2004 10:58:43 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAGIwin09626; Tue, 16 Nov 2004 19:58:44 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 16 Nov 2004 19:58:44 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAGIwhU02280; Tue, 16 Nov 2004 19:58:43 +0100 (MET)
Date: Tue, 16 Nov 2004 19:58:43 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: 3280bis: name constraints
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> The fact that the extension is a name constraint becomes immaterial if the 
> path building software chooses to ignore it.
> The software may ignore the extension if it is marked as non critical,  as 
> per rfc 3280.
> 
> In practice, there may be some benefits to marking the name constraint 
> extension non critical.
> RP may configure the path building software to ignore/enforce the extension 
> based on the importance of the transaction.
> e.g. - for email validation, the RP may configure the path validation 
> software to ignore name constraints.
>       - for a million dollar internet transaction, the RP may configure the 
> software to always enforce name constraints.

RP software may also simply not be able to support constraints
And since this is actually a constraint for CAs, consequences of violation
may be enforcable by organisational means. "Dear CA, we told you not to
issue certs with these constraints." 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGIoGWZ038134; Tue, 16 Nov 2004 10:50:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGIoGNL038132; Tue, 16 Nov 2004 10:50:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGIoGJV038078 for <[e-mail]>; Tue, 16 Nov 2004 10:50:16 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-31.mail.demon.net with esmtp (Exim 4.42) id 1CU8PO-0003dF-3N; Tue, 16 Nov 2004 18:50:30 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 18:51:03 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David A. Cooper wrote:

> See comments in-line
> 
> Dr Stephen Henson wrote:
> 
>> David A. Cooper wrote:
>>
>>>   Stephen Henson wrote:
>>>
>>>> David A. Cooper wrote:
>>>>
>>>> With rfc822Name it was mentioned that the comparision should be to 
>>>> compare the RHS against the constraint. The discussion was whether a 
>>>> constraint of, for example, [e-mail] would *only* match 
>>>> [e-mail] or whether [e-mail] was allowed as 
>>>> well. I can't recall if any consensus was reached over this: I'll 
>>>> see if I can find the reference. 
>>>
>>>
>>>
>>> Here is the current text for name constraints on rfc822Name:
>>>
>>>     A name constraint for Internet mail addresses MAY specify a
>>>     particular mailbox, all addresses at a particular host, or all
>>>     mailboxes in a domain.  To indicate a particular mailbox, the
>>>     constraint is the complete mail address.  For example,
>>>     "[e-mail]" indicates the root mailbox on
>>>     the host "xyz.com".  To indicate all Internet mail addresses on a
>>>     particular host, the constraint is specified as the host name.  For
>>>     example, the constraint "xyz.com" is satisfied by any mail address
>>>     at the host "xyz.com".  To specify any address within a domain, the
>>>     constraint is specified with a leading period (as with URIs).  For
>>>     example, ".xyz.com" indicates all the Internet mail addresses in the
>>>     domain "xyz.com", but not Internet mail addresses on the host 
>>> "xyz.com".
>>>
>>> As I read this, one can specify three types of constraints:
>>>
>>>    1. a specific email address
>>>    2. all email addresses on a particular host
>>>    3. all email address on all hosts whose DNS names are hierarchically
>>>       subordinate to the specified name
>>>
>>> There is no option to specify a set of email addresses on a 
>>> particular host that fit a certain pattern.  So, 
>>> "[e-mail]" would not match "[e-mail]" since RFC 
>>> 3280 states that "[e-mail]" is specifying a particular 
>>> mailbox, not a set of mailboxes.  In my opinion this is the correct 
>>> behavior.  Name constraints are designed to specify constraints in 
>>> terms of subtrees.  Logically, "[e-mail]" is not 
>>> hierarchically subordinate to "[e-mail]", the two are siblings.
>>>
>>
>> Yes that's how I'd interpreted it. In more explicit terms: perform a 
>> RHS match unless the constraint is of the form user@hostname where 
>> only an exact match will satisfy it. 
> 
> 
> Actually, this is not the case.  RFC 3280 states that constraints of the 
> form "xyz.com" are matched only by email addresses on the host xyz.com.  
> So, if the constraint were "xyz.com", one would perform a RHS match on 
> "@xyz.com".  One could perform a RHS match for constraints of the form 
> ".xyz.com".
> 

Yes, now I've re-read it I'd agree with that.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGImKEw036622; Tue, 16 Nov 2004 10:48:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGImKBm036621; Tue, 16 Nov 2004 10:48:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGImKx4036614 for <[e-mail]>; Tue, 16 Nov 2004 10:48:20 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAGImL2x024464; Tue, 16 Nov 2004 13:48:21 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAGIlqYA014369; Tue, 16 Nov 2004 13:47:53 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 13:48:26 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: piyush <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <001301c4cc05$f6bfbc40$[e-mail]>
In-Reply-To: <001301c4cc05$f6bfbc40$[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Piyush,<br>
<br>
This is not really how the criticality flag is supposed to be used.
According to the standard, an application may ignore a non-critical
extension if it <u>can not</u> process it.&nbsp; Applications that can
process the extension are expected to do so, not to ask the user
whether to process or ignore the extension.<br>
<br>
Setting a constraint extension like name constraints to non-critical
should be thought of as a path forward.&nbsp; A CA that sets nameConstraints
to non-critical is indicating that it really wants relying parties to
reject certificates that do not satisfy the constraint, but the CA is
worried that many relying parties will be unable to process the
constraint.&nbsp; Setting the extension to critical may cause such relying
parties to have to reject all certificates as a result of being unable
to process the constraint, even if certificates that violate the
constraint are unlikely to be encountered.&nbsp; Setting the extension to
non-critical indicates that the CA wants the constraint to be imposed,
but is willing to take the risk that some relying parties will accept
certificates that violate the constraint rather than prevent such
relying parties from accepting any certificates at all.&nbsp; As more and
more relying parties are upgraded to be able to fully process the
constraint, fewer and fewer relying parties will be at risk of
accepting certificates that violate the constraint.&nbsp; If relying parties
interpret setting the criticality bit to FALSE to mean that the
extension can be processed or ignored at the relying parties whim, even
if the relying party is capable of processing the extension, then this
no longer works.<br>
<br>
Dave<br>
<br>
piyush wrote:<br>
<blockquote type="cite"
 cite="mid001301c4cc05$f6bfbc40$[e-mail]">The fact
that the extension is a name constraint becomes immaterial if the path
building software chooses to ignore it.
  <br>
The software may ignore the extension if it is marked as non critical,&nbsp;
as per rfc 3280.
  <br>
  <br>
In practice, there may be some benefits to marking the name constraint
extension non critical.
  <br>
RP may configure the path building software to ignore/enforce the
extension based on the importance of the transaction.
  <br>
e.g. - for email validation, the RP may configure the path validation
software to ignore name constraints.
  <br>
&nbsp;&nbsp;&nbsp;&nbsp; - for a million dollar internet transaction, the RP may configure
the software to always enforce name constraints.
  <br>
  <br>
-Piyush<br>
</blockquote>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGITEMX028549; Tue, 16 Nov 2004 10:29:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGITEZT028548; Tue, 16 Nov 2004 10:29:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGITDJ5028535 for <[e-mail]>; Tue, 16 Nov 2004 10:29:14 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAGISamc018070; Tue, 16 Nov 2004 13:28:36 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAGISGYA029020; Tue, 16 Nov 2004 13:28:16 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 13:28:49 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dr Stephen Henson <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

See comments in-line

Dr Stephen Henson wrote:

> David A. Cooper wrote:
>
>>   Stephen Henson wrote:
>>
>>> David A. Cooper wrote:
>>>
>>>> I was not aware of any confusion over the meaning of name 
>>>> constraints imposed on rfc822Name or directoryName.  Could you 
>>>> provide more information about what needs to be clarified?
>>>
>>>
>>>
>>> With rfc822Name it was mentioned that the comparision should be to 
>>> compare the RHS against the constraint. The discussion was whether a 
>>> constraint of, for example, [e-mail] would *only* match 
>>> [e-mail] or whether [e-mail] was allowed as 
>>> well. I can't recall if any consensus was reached over this: I'll 
>>> see if I can find the reference. 
>>
>>
>> Here is the current text for name constraints on rfc822Name:
>>
>>     A name constraint for Internet mail addresses MAY specify a
>>     particular mailbox, all addresses at a particular host, or all
>>     mailboxes in a domain.  To indicate a particular mailbox, the
>>     constraint is the complete mail address.  For example,
>>     "[e-mail]" indicates the root mailbox on
>>     the host "xyz.com".  To indicate all Internet mail addresses on a
>>     particular host, the constraint is specified as the host name.  For
>>     example, the constraint "xyz.com" is satisfied by any mail address
>>     at the host "xyz.com".  To specify any address within a domain, the
>>     constraint is specified with a leading period (as with URIs).  For
>>     example, ".xyz.com" indicates all the Internet mail addresses in the
>>     domain "xyz.com", but not Internet mail addresses on the host 
>> "xyz.com".
>>
>> As I read this, one can specify three types of constraints:
>>
>>    1. a specific email address
>>    2. all email addresses on a particular host
>>    3. all email address on all hosts whose DNS names are hierarchically
>>       subordinate to the specified name
>>
>> There is no option to specify a set of email addresses on a 
>> particular host that fit a certain pattern.  So, 
>> "[e-mail]" would not match "[e-mail]" since RFC 
>> 3280 states that "[e-mail]" is specifying a particular 
>> mailbox, not a set of mailboxes.  In my opinion this is the correct 
>> behavior.  Name constraints are designed to specify constraints in 
>> terms of subtrees.  Logically, "[e-mail]" is not 
>> hierarchically subordinate to "[e-mail]", the two are siblings.
>>
>
> Yes that's how I'd interpreted it. In more explicit terms: perform a 
> RHS match unless the constraint is of the form user@hostname where 
> only an exact match will satisfy it. 

Actually, this is not the case.  RFC 3280 states that constraints of the 
form "xyz.com" are matched only by email addresses on the host xyz.com.  
So, if the constraint were "xyz.com", one would perform a RHS match on 
"@xyz.com".  One could perform a RHS match for constraints of the form 
".xyz.com".

> There were suggestions that some had interpreted it in a different 
> way. At least one thread discussing this is at:
>
> http://www.imc.org/ietf-pkix/old-archive-02/msg01718.html

I saw that there was at least one response that completely 
misinterpreted the meaning of various constraints on rfc822Names.  I get 
the feeling, though, that this wsa not a case of someone misinterpreting 
the text but rather someone who did not read the text.  There are no 
changes we can make in 3280bis to address that problem.

Dave



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGIEsrT022446; Tue, 16 Nov 2004 10:14:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGIEsGE022444; Tue, 16 Nov 2004 10:14:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGIEqD3022394 for <[e-mail]>; Tue, 16 Nov 2004 10:14:52 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1CU7qu-0008Rh-96; Tue, 16 Nov 2004 18:14:52 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 18:15:39 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: piyush <[e-mail]>
CC: Stefan Santesson <[e-mail]>, Terry Hayes <[e-mail]>, "David A. Cooper" <[e-mail]>, Stephen Henson <[e-mail]>, [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <001301c4cc05$f6bfbc40$[e-mail]>
In-Reply-To: <001301c4cc05$f6bfbc40$[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

piyush wrote:

> The fact that the extension is a name constraint becomes immaterial if 
> the path building software chooses to ignore it.
> The software may ignore the extension if it is marked as non critical,  
> as per rfc 3280.
> 

That's not my understanding. The relevant text in RFC3280 about 
criticality is:

> A certificate using system MUST reject the certificate if it encounters
> a critical extension it does not recognize; however, a non-critical
> extension MAY be ignored if it is not recognized.

I notice this doesn't explicitly say what an implementation should do if 
it encounters a non-critical extension that it does recognize.

I can recall threads where it was stated that recognized extensions MUST 
be processed irrespective of the their criticality. Should we clarify 
this in RFC3280bis?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGHxMM8015710; Tue, 16 Nov 2004 09:59:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGHxMKn015709; Tue, 16 Nov 2004 09:59:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGHxLc5015682 for <[e-mail]>; Tue, 16 Nov 2004 09:59:21 -0800 (PST) (envelope-from [e-mail])
Received: from piyush (c-24-6-179-46.client.comcast.net[24.6.179.46]) by comcast.net (sccrmhc12) with SMTP id <20041116175918012008u4ike>; Tue, 16 Nov 2004 17:59:18 +0000
Message-ID: <001301c4cc05$f6bfbc40$[e-mail]>
From: "piyush" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Terry Hayes" <[e-mail]>, "David A. Cooper" <[e-mail]>, "Stephen Henson" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: 3280bis: name constraints
Date: Tue, 16 Nov 2004 09:59:04 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The fact that the extension is a name constraint becomes immaterial if the 
path building software chooses to ignore it.
The software may ignore the extension if it is marked as non critical,  as 
per rfc 3280.

In practice, there may be some benefits to marking the name constraint 
extension non critical.
RP may configure the path building software to ignore/enforce the extension 
based on the importance of the transaction.
e.g. - for email validation, the RP may configure the path validation 
software to ignore name constraints.
      - for a million dollar internet transaction, the RP may configure the 
software to always enforce name constraints.

-Piyush


----- Original Message ----- 
From: "Stefan Santesson" <[e-mail]>
To: "Terry Hayes" <[e-mail]>; "David A. Cooper" 
<[e-mail]>; "Stephen Henson" 
<[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, November 16, 2004 8:27 AM
Subject: RE: 3280bis: name constraints


>
> This is a truth with modification.
>
> A relying party can always accept any certificates for any use for any
> reason but that is not the point.
>
> The point is to decide when path validation according to RFC 3280
> rejects the certificate path as invalid. This is done within strict
> rules.
>
> Any constrained name form that is violated in the path renders the path
> invalid. Critical or non-critical extensions does not make any
> difference in this regard.
>
>
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>
>> -----Original Message-----
>> From: [e-mail]
> [mailto:[e-mail]]
>> On Behalf Of Terry Hayes
>> Sent: den 16 november 2004 00:45
>> To: David A. Cooper; Stephen Henson
>> Cc: [e-mail]
>> Subject: Re: 3280bis: name constraints
>>
>>
>> In my opinion, a requirement such as this is too restrictive, and will
>> prevent additional capabilities from being added to a PKI.
>>
>> As long as an application never makes use of a particular name form,
> it
>> should be free to ignore constraints that apply to that name form.
> Notice
>> that to do this, it must recognize and process the name constraint
>> extension as required by the extension processing rules.
>>
>> If applications are required to reject certificates paths with
> constraints
>> for name forms that they do not recognize, they will be prevented from
>> using certificates that have those name forms added to them for other
>> applications.  This will impede the use of certificates for these new
>> applications, since older clients will not be able to function.
>>
>> Terry Hayes
>>
>>
>> David A. Cooper wrote on 11/15/2004, 2:08 PM:
>> >
>> >
>> > X.509 does have a rule that one must reject a critical extension
> unless
>> > you can process all of the fields in the extension. So, for name
>> > constraints, if a critical nameConstraints extension includes a
>> > constraint on a name form and that name form appears in the subject
>> > field or subjectAltName extension of a subsequent certificate, then
> path
>> > must be rejected.
>
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGHK5aS002423; Tue, 16 Nov 2004 09:20:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGHK5B9002422; Tue, 16 Nov 2004 09:20:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGHK44f002416 for <[e-mail]>; Tue, 16 Nov 2004 09:20:04 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-34.mail.demon.net with esmtp (Exim 4.42) id 1CU6zv-000Hsq-Dt for [e-mail]; Tue, 16 Nov 2004 17:20:07 +0000
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 17:20:54 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David A. Cooper wrote:

>   Stephen Henson wrote:
> 
>> David A. Cooper wrote: 
>>
>>> I was not aware of any confusion over the meaning of name constraints 
>>> imposed on rfc822Name or directoryName.  Could you provide more 
>>> information about what needs to be clarified?
>>
>>
>> With rfc822Name it was mentioned that the comparision should be to 
>> compare the RHS against the constraint. The discussion was whether a 
>> constraint of, for example, [e-mail] 
>> <mailto:[e-mail]> would *only* match [e-mail] 
>> <mailto:[e-mail]> or whether [e-mail] 
>> <mailto:[e-mail]> was allowed as well. I can't recall if 
>> any consensus was reached over this: I'll see if I can find the 
>> reference. 
> 
> Here is the current text for name constraints on rfc822Name:
> 
>     A name constraint for Internet mail addresses MAY specify a
>     particular mailbox, all addresses at a particular host, or all
>     mailboxes in a domain.  To indicate a particular mailbox, the
>     constraint is the complete mail address.  For example,
>     "[e-mail]" <mailto:[e-mail]> indicates the root mailbox on
>     the host "xyz.com".  To indicate all Internet mail addresses on a
>     particular host, the constraint is specified as the host name.  For
>     example, the constraint "xyz.com" is satisfied by any mail address
>     at the host "xyz.com".  To specify any address within a domain, the
>     constraint is specified with a leading period (as with URIs).  For
>     example, ".xyz.com" indicates all the Internet mail addresses in the
>     domain "xyz.com", but not Internet mail addresses on the host "xyz.com".
> 
> As I read this, one can specify three types of constraints:
> 
>    1. a specific email address
>    2. all email addresses on a particular host
>    3. all email address on all hosts whose DNS names are hierarchically
>       subordinate to the specified name
> 
> There is no option to specify a set of email addresses on a particular 
> host that fit a certain pattern.  So, "[e-mail]" 
> <mailto:[e-mail]> would not match "[e-mail]" 
> <mailto:[e-mail]> since RFC 3280 states that 
> "[e-mail]" <mailto:[e-mail]> is specifying a 
> particular mailbox, not a set of mailboxes.  In my opinion this is the 
> correct behavior.  Name constraints are designed to specify constraints 
> in terms of subtrees.  Logically, "[e-mail]" 
> <mailto:[e-mail]> is not hierarchically subordinate to 
> "[e-mail]" <mailto:[e-mail]>, the two are siblings.
> 

Yes that's how I'd interpreted it. In more explicit terms: perform a RHS
match unless the constraint is of the form user@hostname where only an
exact match will satisfy it.

There were suggestions that some had interpreted it in a different way.
At least one thread discussing this is at:

http://www.imc.org/ietf-pkix/old-archive-02/msg01718.html

>> As far as directoryName is concerned I've not seen a description or a 
>> reference to the algorithm used for this type of constraint. Some 
>> private communications with some vendors suggested that this wasn't 
>> obvious and also produced the worrying comment that "everyone does 
>> this differently".
> 
> I have never heard this.  It seems to me that the rules are fairly 
> simple.  A DN consists of a SEQUENCE of RDN.  A subtree specification 
> for name constraints on DNs consists of a SEQUENCE of RDN.  If the 
> subtree specification is a sequence of /n/ RDNs, then a DN matches if 
> and only if the DN consists of a sequence of at least /n/ RDNs and the 
> first /n/ RDNs in the DN match the the RDNs in the subtree specification 
> in order.  The rules for comparing RDNs are the same as are used to 
> compare issuer and subject names when verifying name chaining.
> 

If we could include a sentence or two explicitly stating that it would
avoid any possibly confusion.

> So, are these vendors who are unclear on how to process name constraints 
> on directoryNames also unclear on how to compare issuer and subject 
> names, or is the confusion limited to name constraints?
> 

It was only name constraints. One area was concerning an RDN consisting
of more than one AttributeTypeAndValue. If RDNs in name constraints
follow the issuer and subject name comparison rules then that resolves
that case.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGGRmRC084983; Tue, 16 Nov 2004 08:27:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGGRmWt084982; Tue, 16 Nov 2004 08:27:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGGRkZu084888 for <[e-mail]>; Tue, 16 Nov 2004 08:27:47 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Nov 2004 16:26:21 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: 3280bis: name constraints
Date: Tue, 16 Nov 2004 16:27:32 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3280bis: name constraints
Thread-Index: AcTLdQy8Su7hvfj3TlqkqzUV9c/q6gAg216A
From: "Stefan Santesson" <[e-mail]>
To: "Terry Hayes" <[e-mail]>, "David A. Cooper" <[e-mail]>, "Stephen Henson" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 16 Nov 2004 16:26:21.0534 (UTC) FILETIME=[02136FE0:01C4CBF9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAGGRlZu084969
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a truth with modification.

A relying party can always accept any certificates for any use for any
reason but that is not the point.

The point is to decide when path validation according to RFC 3280
rejects the certificate path as invalid. This is done within strict
rules.

Any constrained name form that is violated in the path renders the path
invalid. Critical or non-critical extensions does not make any
difference in this regard.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Terry Hayes
> Sent: den 16 november 2004 00:45
> To: David A. Cooper; Stephen Henson
> Cc: [e-mail]
> Subject: Re: 3280bis: name constraints
> 
> 
> In my opinion, a requirement such as this is too restrictive, and will
> prevent additional capabilities from being added to a PKI.
> 
> As long as an application never makes use of a particular name form,
it
> should be free to ignore constraints that apply to that name form.
Notice
> that to do this, it must recognize and process the name constraint
> extension as required by the extension processing rules.
> 
> If applications are required to reject certificates paths with
constraints
> for name forms that they do not recognize, they will be prevented from
> using certificates that have those name forms added to them for other
> applications.  This will impede the use of certificates for these new
> applications, since older clients will not be able to function.
> 
> Terry Hayes
> 
> 
> David A. Cooper wrote on 11/15/2004, 2:08 PM:
> >
> >
> > X.509 does have a rule that one must reject a critical extension
unless
> > you can process all of the fields in the extension. So, for name
> > constraints, if a critical nameConstraints extension includes a
> > constraint on a name form and that name form appears in the subject
> > field or subjectAltName extension of a subsequent certificate, then
path
> > must be rejected.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGFKUOU056159; Tue, 16 Nov 2004 07:20:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGFKUYw056158; Tue, 16 Nov 2004 07:20:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGFKTw4056151 for <[e-mail]>; Tue, 16 Nov 2004 07:20:30 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAGFJL2x013217; Tue, 16 Nov 2004 10:19:21 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAGFIjYA029636; Tue, 16 Nov 2004 10:18:46 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 10:19:18 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Terry Hayes <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Terry,<br>
<br>
Even if I agreed with you that name constraints should work as you
describe, there would still be a couple of problems.&nbsp; First, this would
be a change from RFC 3280, which is probably outside the scope for
changes that we are allowed to make in 3280bis.&nbsp; Second, this would
make 3280bis inconsistent with X.509, which is certainly not something
we can do, since 3280bis is a profile of X.509.<br>
<br>
X.509 states (among other things):<br>
<blockquote>
  <p>If excludedSubtrees is present, any certificate issued by the
subject CA or subsequent CAs in the certification path that has a
subject name within these subtrees is unacceptable.</p>
If the [<b>nameConstraints</b>] extension is present and is flagged
critical, a certificate-using implementation must recognize and process
all name forms for which there is both a subtree specification
(permitted or excluded) in the extension and a corresponding value in
the <b>subject</b> field or <b>subjectAltNames</b> extension of any
subsequent certificate in the certification path. If an unrecognized
name form appears in both a subtree specification and a subsequent
certificate, that certificate shall be handled as if an unrecognized
critical extension was encountered. If any subject name in the
certificate falls within an excluded subtree, the certificate is
unacceptable.<br>
</blockquote>
X.509 is quite clear that if a certificate includes a name that falls
within an excludedSubtree or does not fall within any permittedSubtree,
then the certificate is unacceptable not just the name.&nbsp; In order for a
certificate to be acceptable, all names must satisfy name constraints,
not just the name(s) that is of interest to the application.&nbsp; If the
nameConstraints extension is critical and the application can not
process one or more of the constraints, then it must reject the
certification path since it is unable to verify that the name
constraints have been satisfied.<br>
<br>
In my opinion, the answer to your concern is not to change the
semantics of name constraints, but to be careful in your use of name
constraints and alternative names.&nbsp; At the moment, in the U.S. Federal
PKI, we only impose name constraints on the directoryName form and I
have not seen a compelling reason to impose constraints on other name
forms.<br>
<br>
If you do feel the need to impose name constraints on some name form
for which many applications may not be able to process the constraint,
then I would suggest issuing separate certificates for the
application(s) that use that name form.&nbsp; For example, if you have an
application that uses X.400 names and you feel the need to impose name
constraints on X.400 names, issue subscribers two certificates:&nbsp; one
certificate with an X.400 name for use with the application that uses
the X.400 name (presumably this application can process the X.400 name
constraints) and a second certificate without an X.400 name.&nbsp; If a CA
imposes a constraint on a particular name form, but no subsequent
certificate includes a subject name or subjectAltName of that form,
then there is no processing to be done so the application can accept
the path despite not being able to process constraints for that name
form.<br>
<br>
There is another option:&nbsp; the nameConstraints extension could be marked
non-critical.&nbsp; X.509 states:<br>
<blockquote>If the [<b>nameConstraints</b>] extension is present and is
flagged non-critical and a certificate-using implementation does not
recognize a name form used in any <b>base</b> component, then that
subtree specification may be ignored.<br>
</blockquote>
Granted, RFC 3280 states that the nameConstraints extension MUST be
critical, but if there were sufficient interest in changing this in
3280bis to state that the extension can be set to either critical or
non-critical, I would be willing to support that.<br>
<br>
Dave<br>
<br>
<br>
Terry Hayes wrote:<br>
<blockquote type="cite" cite="[e-mail]">
  <pre wrap="">In my opinion, a requirement such as this is too restrictive, and will prevent additional capabilities from being added to a PKI.

As long as an application never makes use of a particular name form, it should be free to ignore constraints that apply to that name form.  Notice that to do this, it must recognize and process the name constraint extension as required by the extension processing rules.

If applications are required to reject certificates paths with constraints for name forms that they do not recognize, they will be prevented from using certificates that have those name forms added to them for other applications.  This will impede the use of certificates for these new applications, since older clients will not be able to function.

Terry Hayes


David A. Cooper wrote on 11/15/2004, 2:08 PM:
  </pre>
  <blockquote type="cite">
    <pre wrap="">
X.509 does have a rule that one must reject a critical extension unless 
you can process all of the fields in the extension. So, for name 
constraints, if a critical nameConstraints extension includes a 
constraint on a name form and that name form appears in the subject 
field or subjectAltName extension of a subsequent certificate, then path 
must be rejected.</pre>
  </blockquote>
</blockquote>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGEsKbk047386; Tue, 16 Nov 2004 06:54:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAGEsK5J047385; Tue, 16 Nov 2004 06:54:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAGEsJC7047379 for <[e-mail]>; Tue, 16 Nov 2004 06:54:19 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAGEp32x007138; Tue, 16 Nov 2004 09:51:03 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAGEoYYA008091; Tue, 16 Nov 2004 09:50:34 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 09:51:07 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Henson <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Stephen Henson wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">David A. Cooper
wrote:&nbsp;
  <br>
  <blockquote type="cite">I was not aware of any confusion over the
meaning of name constraints imposed on rfc822Name or directoryName.&nbsp;
Could you provide more information about what needs to be clarified?
    <br>
  </blockquote>
  <br>
With rfc822Name it was mentioned that the comparision should be to
compare the RHS against the constraint. The discussion was whether a
constraint of, for example, <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> would *only* match
<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> or whether <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> was allowed as well. I
can't recall if any consensus was reached over this: I'll see if I can
find the reference.
</blockquote>
Here is the current text for name constraints on rfc822Name:<br>
<blockquote>A name constraint for Internet mail addresses MAY specify a
particular mailbox, all addresses at a particular host, or all
mailboxes in a domain.&nbsp; To indicate a particular mailbox, the
constraint is the complete mail address.&nbsp; For example, <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">"[e-mail]"</a>
indicates the root mailbox on the host "xyz.com".&nbsp; To indicate all
Internet mail addresses on a particular host, the constraint is
specified as the host name.&nbsp; For example, the constraint "xyz.com" is
satisfied by any mail address at the host "xyz.com".&nbsp; To specify any
address within a domain, the constraint is specified with a leading
period (as with URIs).&nbsp; For example, ".xyz.com" indicates all the
Internet mail addresses in the domain "xyz.com", but not Internet mail
addresses on the host "xyz.com".<br>
</blockquote>
As I read this, one can specify three types of constraints:<br>
<ol>
  <li>a specific email address</li>
  <li>all email addresses on a particular host</li>
  <li>all email address on all hosts whose DNS names are hierarchically
subordinate to the specified name<br>
  </li>
</ol>
There is no option to specify a set of email addresses on a particular
host that fit a certain pattern.&nbsp; So, <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">"[e-mail]"</a> would not
match <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">"[e-mail]"</a> since RFC 3280 states that
<a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">"[e-mail]"</a> is specifying a particular mailbox, not a set of
mailboxes.&nbsp; In my opinion this is the correct behavior.&nbsp; Name
constraints are designed to specify constraints in terms of subtrees.&nbsp;
Logically, <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">"[e-mail]"</a> is not hierarchically subordinate to
<a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">"[e-mail]"</a>, the two are siblings.<br>
<br>
<blockquote type="cite"
 cite="[e-mail]">As far as
directoryName is concerned I've not seen a description or a reference
to the algorithm used for this type of constraint. Some private
communications with some vendors suggested that this wasn't obvious and
also produced the worrying comment that "everyone does this
differently".
  <br>
</blockquote>
I have never heard this.&nbsp; It seems to me that the rules are fairly
simple.&nbsp; A DN consists of a SEQUENCE of RDN.&nbsp; A subtree specification
for name constraints on DNs consists of a SEQUENCE of RDN.&nbsp; If the
subtree specification is a sequence of <i>n</i> RDNs, then a DN
matches if and only if the DN consists of a sequence of at least <i>n</i>
RDNs and the first <i>n</i> RDNs in the DN match the the RDNs in the
subtree specification in order.&nbsp; The rules for comparing RDNs are the
same as are used to compare issuer and subject names when verifying
name chaining.<br>
<br>
So, are these vendors who are unclear on how to process name
constraints on directoryNames also unclear on how to compare issuer and
subject names, or is the confusion limited to name constraints?<br>
<br>
Dave<br>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAG58qlc065502; Mon, 15 Nov 2004 21:08:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAG58qws065501; Mon, 15 Nov 2004 21:08:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAG58lCD065324 for <[e-mail]>; Mon, 15 Nov 2004 21:08:51 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAG58kG4465416 for <[e-mail]>; Tue, 16 Nov 2004 00:08:46 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAG58kJf238564 for <[e-mail]>; Tue, 16 Nov 2004 00:08:46 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAG58kFX027505 for <[e-mail]>; Tue, 16 Nov 2004 00:08:46 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAG58kvM027501; Tue, 16 Nov 2004 00:08:46 -0500
Subject: 3280 Issue - Are extra Anchor Parameters permitted?
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <[e-mail]>
From: Tom Gindin <[e-mail]>
Date: Tue, 16 Nov 2004 00:08:17 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF2 (6.53IBM1)|October 29, 2004) at 11/16/2004 00:08:45
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      David:

      This has come up on the list before, in late August and early
September.  However, it is an open issue in RFC 3280 whether or not
compliant path validation permits an RP to set variables corresponding to
the various constraint extensions, or whether it requires instead that the
variables corresponding to the constraint extensions always be initialized
to the values given in 6.1.2 b, c, and k.  I don't believe that anybody
thinks that support for setting those extensions to other values is
mandatory for compliance.

            Tom Gindin




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAG1nQvP096768; Mon, 15 Nov 2004 17:49:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAG1nQl2096767; Mon, 15 Nov 2004 17:49:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAG1nPae096758 for <[e-mail]>; Mon, 15 Nov 2004 17:49:25 -0800 (PST) (envelope-from [e-mail])
Received: by rproxy.gmail.com with SMTP id g11so517382rne for <[e-mail]>; Mon, 15 Nov 2004 17:49:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eWP7qi/8+D57W+qQy/VZOXDKJSuiotOyJvegOSYi2H/uRyuu5+BQAL6ngaPciI2YLqzHZ2tW5chIxN5w+zQYSkFRq+g1apE6roHNt9NoK0KPj2/VblvErT5tc9t61cywFq95EtkPGd3O7qv1+1f3m+IdD15xoDiD+Ac+Wwdqkxs=
Received: by 10.38.4.61 with SMTP id 61mr467665rnd; Mon, 15 Nov 2004 17:49:30 -0800 (PST)
Received: by 10.38.81.56 with HTTP; Mon, 15 Nov 2004 17:49:30 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 16 Nov 2004 12:49:30 +1100
From: Andrew Sciberras <[e-mail]>
Reply-To: Andrew Sciberras <[e-mail]>
To: Tim Polk <[e-mail]>
Subject: Re: WG Last Call: Certificate Schema
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Do you have any concerns about the fact that the Serial Number
attribute (section 5.1.2) does not contain an ordering matching rule?

Is it intentional that the Serial Number attribute is not 'SINGLE-VALUE'?


Section 5.2.3  Key usage Extension
If you have a certificate with a keyUsage extension present with a
value of zero (i.e. none of the bits are set) what do you do? Do you
simply omit using the x509keyUsage atribute? If not, how does the BNF
represent such a value?

Thanks,
Andrew Sciberras



On Mon, 15 Nov 2004 17:00:22 -0500, Tim Polk <[e-mail]> wrote:
> 
> 
> This message initiates working group Last Call for the "LDAP Schema for
> X.509 Certificates"
> specification. The editors have confirmed that all working group issues
> have been resolved.
> 
> The URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt
> 
> This specification has also been forwarded to the LDAP Directorate for a
> parallel review.  Assuming successful Last Call and concurrence from the
> LDAP Directorate, this document will be forwarded to the ADs for
> consideration as an Informational track RFC.
> 
> Last Call will run for (at least) two weeks. That is, Last Call will not
> close before November 29.
> 
> Thanks,
> 
> Tim Polk
> 
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFNjZvo051702; Mon, 15 Nov 2004 15:45:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFNjZ7Z051701; Mon, 15 Nov 2004 15:45:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imo-m22.mx.aol.com (imo-m22.mx.aol.com [64.12.137.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFNjWdB051637 for <[e-mail]>; Mon, 15 Nov 2004 15:45:34 -0800 (PST) (envelope-from [e-mail])
Received: from [e-mail] by imo-m22.mx.aol.com (mail_out_v37_r3.8.) id n.1eb.2de090ac (16109); Mon, 15 Nov 2004 18:45:28 -0500 (EST)
Received: from  pc655301.ad.aol.aoltw.net (h-10-169-155-109.nscp.aoltw.net [10.169.155.109]) by air-id12.mx.aol.com (v103.7) with ESMTP id MAILINID121-3eed41993f9673; Mon, 15 Nov 2004 18:45:27 -0500
Date: Mon, 15 Nov 2004 15:45:25 -0800
From: "Terry Hayes" <[e-mail]>
Subject: Re: 3280bis: name constraints
To: "David A. Cooper" <[e-mail]>, "Stephen Henson" <[e-mail]>
cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
X-Mailer: AOL Fanfare (20040831Branch.4205.162 Win)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-AOL-IP: 10.169.155.109
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In my opinion, a requirement such as this is too restrictive, and will prevent additional capabilities from being added to a PKI.

As long as an application never makes use of a particular name form, it should be free to ignore constraints that apply to that name form.  Notice that to do this, it must recognize and process the name constraint extension as required by the extension processing rules.

If applications are required to reject certificates paths with constraints for name forms that they do not recognize, they will be prevented from using certificates that have those name forms added to them for other applications.  This will impede the use of certificates for these new applications, since older clients will not be able to function.

Terry Hayes


David A. Cooper wrote on 11/15/2004, 2:08 PM:
> 
> 
> X.509 does have a rule that one must reject a critical extension unless 
> you can process all of the fields in the extension. So, for name 
> constraints, if a critical nameConstraints extension includes a 
> constraint on a name form and that name form appears in the subject 
> field or subjectAltName extension of a subsequent certificate, then path 
> must be rejected.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFNWvnH048449; Mon, 15 Nov 2004 15:32:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFNWvEK048448; Mon, 15 Nov 2004 15:32:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFNWu0p048441 for <[e-mail]>; Mon, 15 Nov 2004 15:32:56 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-30.mail.demon.net with esmtp (Exim 4.42) id 1CTqLA-000Fej-2G; Mon, 15 Nov 2004 23:32:56 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 23:33:42 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David A. Cooper wrote:
> 
> X.509 does have a rule that one must reject a critical extension unless 
> you can process all of the fields in the extension. So, for name 
> constraints, if a critical nameConstraints extension includes a 
> constraint on a name form and that name form appears in the subject 
> field or subjectAltName extension of a subsequent certificate, then path 
> must be rejected.  The same applies if the minimum or maximum field is 
> included and the relying party can not process those fields.  I can add 
> text in 3280bis that states this.
> 

OK.

> I was not aware of any confusion over the meaning of name constraints 
> imposed on rfc822Name or directoryName.  Could you provide more 
> information about what needs to be clarified?
> 

With rfc822Name it was mentioned that the comparision should be to 
compare the RHS against the constraint. The discussion was whether a 
constraint of, for example, [e-mail] would *only* match 
[e-mail] or whether [e-mail] was allowed as well. I 
can't recall if any consensus was reached over this: I'll see if I can 
find the reference.

As far as directoryName is concerned I've not seen a description or a 
reference to the algorithm used for this type of constraint. Some 
private communications with some vendors suggested that this wasn't 
obvious and also produced the worrying comment that "everyone does this 
differently".

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMP9E4030041; Mon, 15 Nov 2004 14:25:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFMP906030039; Mon, 15 Nov 2004 14:25:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMP7Qj030021 for <[e-mail]>; Mon, 15 Nov 2004 14:25:07 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAFMOvmc009907; Mon, 15 Nov 2004 17:24:57 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAFMOcYB000413; Mon, 15 Nov 2004 17:24:38 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Nov 2004 17:26:40 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call: CRL Schema
Cc: [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message initiates working group Last Call for the "LDAP Schema for 
X.509 CRLs" specification. The editors have confirmed that all working 
group issues have been resolved.

The URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-03.txt

This specification has also been forwarded to the LDAP Directorate for a 
parallel review.  Assuming successful Last Call and concurrence from the 
LDAP Directorate, this document will be forwarded to the ADs for 
consideration as an Informational track RFC.

Last Call will run for (at least) two weeks. That is, Last Call will not 
close before November 29.

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMP9su030040; Mon, 15 Nov 2004 14:25:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFMP9Ur030038; Mon, 15 Nov 2004 14:25:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMP78v030025 for <[e-mail]>; Mon, 15 Nov 2004 14:25:07 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAFMOv2x011999; Mon, 15 Nov 2004 17:24:57 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAFMOYYB000386; Mon, 15 Nov 2004 17:24:34 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Nov 2004 17:06:40 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call: Attribute Certificate Schema
Cc: [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message initiates working group Last Call for the "LDAP Schema for 
X.509 Attribute Certificates" specification. The editors have confirmed 
that all working group issues have been resolved.

The URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-02.txt

This specification has also been forwarded to the LDAP Directorate for a 
parallel review.  Assuming successful Last Call and concurrence from the 
LDAP Directorate, this document will be forwarded to the ADs for 
consideration as an Informational track RFC.

Last Call will run for (at least) two weeks. That is, Last Call will not 
close before November 29.

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMP5WA030015; Mon, 15 Nov 2004 14:25:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFMP5tL030014; Mon, 15 Nov 2004 14:25:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMP29W029997 for <[e-mail]>; Mon, 15 Nov 2004 14:25:02 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAFMOu2x011989; Mon, 15 Nov 2004 17:24:56 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAFMOLYB000248; Mon, 15 Nov 2004 17:24:21 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Nov 2004 17:00:22 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call: Certificate Schema
Cc: [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message initiates working group Last Call for the "LDAP Schema for 
X.509 Certificates"
specification. The editors have confirmed that all working group issues 
have been resolved.

The URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt

This specification has also been forwarded to the LDAP Directorate for a 
parallel review.  Assuming successful Last Call and concurrence from the 
LDAP Directorate, this document will be forwarded to the ADs for 
consideration as an Informational track RFC.

Last Call will run for (at least) two weeks. That is, Last Call will not 
close before November 29.

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMMRH0029368; Mon, 15 Nov 2004 14:22:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFMMRxW029367; Mon, 15 Nov 2004 14:22:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av2-2-sn3.vrr.skanova.net (av2-2-sn3.vrr.skanova.net [81.228.9.108]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFMMQsJ029321 for <[e-mail]>; Mon, 15 Nov 2004 14:22:27 -0800 (PST) (envelope-from [e-mail])
Received: by av2-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 006D637F30; Mon, 15 Nov 2004 23:22:21 +0100 (CET)
Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av2-2-sn3.vrr.skanova.net (Postfix) with ESMTP id E55DB37E60 for <[e-mail]>; Mon, 15 Nov 2004 23:22:21 +0100 (CET)
Received: from rsaedoscymkikx (t8o913p74.telia.com [213.64.26.194]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id E38C838002 for <[e-mail]>; Mon, 15 Nov 2004 23:22:20 +0100 (CET)
Message-ID: <00e001c4cb61$9561fe30$80c5a8c0@rsaedoscymkikx>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Microsoft launches e-sign client
Date: Mon, 15 Nov 2004 23:22:23 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Microsoft today pre-announced the availability of a smart client for
handling e-signatures for C2G (Citizen-to-Government) services and
similar on-line activities.  The announcement was made in the paper
edition of Computer Sweden,  by MSFT spokesman Predrag Mitrovic.

It may look a bit surprising that the announcement was not in CNET
but the fact is that Liliput country Sweden have magnitudes more on-
line consumers with digital certificates than for example the US.
Something between 8-10% of the population currently have an electronic
citizen-ID and at least 5% are actively using such for on-line banking.

The EU governments are likely to appreciate this initiative as existing
e-signature solutions in addition to [also] being proprietary, usually are
NDA-protected and fairly costly.  My assumption is that the Microsoft
solution will be free and a default install although it may not run on older
Windows versions.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFM849L025459; Mon, 15 Nov 2004 14:08:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFM841B025458; Mon, 15 Nov 2004 14:08:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFM84YP025444 for <[e-mail]>; Mon, 15 Nov 2004 14:08:04 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAFM7omc006850; Mon, 15 Nov 2004 17:07:50 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAFM7ZYA017782; Mon, 15 Nov 2004 17:07:36 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 17:08:06 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Henson <[e-mail]>
CC: [e-mail]
Subject: Re: 3280bis: name constraints
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

I already have a note that the processing of dNSName in name constraints 
needs to be clarified.  In particular, it needs to be made clear that 
"f.example.com" falls within the subtree "example.com", but 
"fexample.com" does not.

X.509 does have a rule that one must reject a critical extension unless 
you can process all of the fields in the extension. So, for name 
constraints, if a critical nameConstraints extension includes a 
constraint on a name form and that name form appears in the subject 
field or subjectAltName extension of a subsequent certificate, then path 
must be rejected.  The same applies if the minimum or maximum field is 
included and the relying party can not process those fields.  I can add 
text in 3280bis that states this.

I was not aware of any confusion over the meaning of name constraints 
imposed on rfc822Name or directoryName.  Could you provide more 
information about what needs to be clarified?

Dave

Stephen Henson wrote:

> IMHO some clarification of the nameConstraints extension should be 
> included in RFC3280bis.
>
> I can recall there being a number of threads discussing the meaning of 
> name constraints for various types including the interpretation of the 
> rfc822Name and dNSName fields. At the time various people had come to 
> different conclusions based on the existing text.
>
> I've not seen a description of how directoryName types are handled or 
> a discussion on this.
>
> IIRC X509 includes a note that if an unhandled constraint type is 
> encountered the certificate should be rejected: should RFC3280bis 
> include this too?
>
> What about the minimum and maximum fields: should an implementation 
> reject a certificate where these are present?
>
> Steve.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFLXDtU016140; Mon, 15 Nov 2004 13:33:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFLXDfY016139; Mon, 15 Nov 2004 13:33:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFLXC3c016066 for <[e-mail]>; Mon, 15 Nov 2004 13:33:12 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1CToTB-000MxJ-Ly; Mon, 15 Nov 2004 21:33:05 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 21:33:51 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
CC: "David A. Cooper" <[e-mail]>
Subject: 3280bis: name constraints
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

IMHO some clarification of the nameConstraints extension should be 
included in RFC3280bis.

I can recall there being a number of threads discussing the meaning of 
name constraints for various types including the interpretation of the 
rfc822Name and dNSName fields. At the time various people had come to 
different conclusions based on the existing text.

I've not seen a description of how directoryName types are handled or a 
discussion on this.

IIRC X509 includes a note that if an unhandled constraint type is 
encountered the certificate should be rejected: should RFC3280bis 
include this too?

What about the minimum and maximum fields: should an implementation 
reject a certificate where these are present?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from cl-194-102-155-61.cablelink.mures.rdsnet.ro (cl-194-102-155-61.cablelink.mures.rdsnet.ro [194.102.155.61]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAFLE1kx011902; Mon, 15 Nov 2004 13:14:04 -0800 (PST) (envelope-from [e-mail])
Received: from  [196.59.88.179] by cl-194-102-155-61.cablelink.mures.rdsnet.ro with SMTP; Tue, 16 Nov 2004 01:12:50 +0400
Message-ID: <9-9b8i0g-57l@3m5qtjrc20xmu>
From: "Administrator" <[e-mail]>
To: [e-mail]
Subject: ADV:      Staff Announcement
Date: Tue, 16 Nov 04 01:12:50 GMT
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: AOL 7.0 for Windows US sub 118
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5848._.B5CA_1_916_A4"

This is a multi-part message in MIME format.

--5848._.B5CA_1_916_A4
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Nonprofit Organizations: Members and Staff

You Must Respond By 5 P.M. Wednesday, November 17, 2004.

Through a special arrangement, Avtech Direct is offering a limited
allotment of BRAND NEW, top of-the-line, name-brand desktop computers
at more than 50% off MSRP to all Nonprofit Members and Staff
who respond to this message before 5 P.M., Wednesday, November 17, 2004

All desktop computers are brand-new packed in their original boxes,
and come with a full manufacturer's warranty plus
a 100% satisfaction guarantee.

These professional grade Desktops are fully equipped with 2005
next generation technology, making these the best performing
computers money can buy.

Avtech Direct is offering these feature rich, top performing
Desktops with the latest technology at an amazing price
to all who call:

    1-800-795-8466 by 5 P.M. Wednesday, November 17, 2004

The fast and powerful AT-3200 series Desktop features: 

      * IBM Processor for amazing speed and performance
      * 128MB DDR RAM,  -- Upgradeable to 1024
      * 20 GB UDMA Hard Drive, -- Upgradeable to 80 GB
      * 52X CD-Rom Drive, -- Upgradeable to DVD/CDRW
      * Next Generation 2005 Technology
      * Premium video and sound -- For enhanced colors and graphics
      * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0
      * Soft Touch Keyboard and scroll mouse
      * Internet Ready
      * Network Ready
      * 1 Year parts and labor warranty
      * Priority customer service and tech support

MSRP $499 ........................................ Your Cost $227

How to qualify:

  1. You must be a Member, Staff or Associate of a Nonprofit.
  2. All desktop computers will be available on a
     first come first serve basis.
  3. You must call 1-800-795-8466 by 5 P.M. Wednesday, November 17, 2004.
     and we will hold the desktops you request on will call. 
  4. You are not obligated in any way.
  5. 100% Satisfaction Guaranteed.
  6. Ask for Department C.
   
   
Call Avtech Direct
1-800-795-8466 before 5 P.M. Wednesday, November 17, 2004


Visit our website at http://www.avtechcomputers.com


If you wish to unsubscribe from this list, please go to
http://www./www.avtechcomputers.com/announcements.asp



Avtech Direct
22647 Ventura Blvd. Suite 374
Woodland Hills, CA 91364
--5848._.B5CA_1_916_A4--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFKS307099577; Mon, 15 Nov 2004 12:28:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFKS32U099576; Mon, 15 Nov 2004 12:28:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFKS3Od099562 for <[e-mail]>; Mon, 15 Nov 2004 12:28:03 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAFKRimc019230 for <[e-mail]>; Mon, 15 Nov 2004 15:27:44 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iAFKRLYA006070 for <[e-mail]>; Mon, 15 Nov 2004 15:27:22 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 15:27:52 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: ietf-pkix <[e-mail]>
Subject: Re: Is that right?set the valid_policy to OID-P;
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree that "OID-P" should have been "P-OID". I will fix it in 3280bis.

Dave

Stephen Henson wrote:

>alan wrote:
>
>>ietf-pkix£¬
>>
>>In rfc3280,
>>6.1.3  Basic Certificate Processing
>>(d)
>>	(1)
>>		(i)If the valid_policy_tree includes a node of depth i-1
>>            where P-OID is in the expected_policy_set, create a child
>>            node as follows: set the valid_policy to OID-P; set the
>>            qualifier_set to P-Q, and set the expected_policy_set to
>>            {P-OID}.
>>OID-P is what?
>>
>>I can't make sure for this word.
>>
>When I implemented this for OpenSSL I assumed it was a typo and should
>say P-OID. The example in figure 4 supports this.
>
>Steve.
>  
>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFFswCc096334; Mon, 15 Nov 2004 07:54:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFFswF8096333; Mon, 15 Nov 2004 07:54:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFFsupp096244 for <[e-mail]>; Mon, 15 Nov 2004 07:54:57 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAFFsrD16263 for <[e-mail]>; Mon, 15 Nov 2004 16:54:53 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 15 Nov 2004 16:54:53 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAFFsr809681 for [e-mail]; Mon, 15 Nov 2004 16:54:53 +0100 (MET)
Date: Mon, 15 Nov 2004 16:54:53 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Slide 7:  There is no "need to account for multiple CAs with the same 
> name". This formulation is pretty bad. A CA must provide different 
> names to two different entities. Since a CA name is relative to 
> another CA name space, there cannot be two CAs with the same name.
> 
> [SC: There is XX requirement or mechanism that ensures that a relying 
> party

It seems to me that there is a missing *no* where I added the XX.

> with multiple trust anchors will not encounter two CAs with the same 
> name. If a relying party has two trust anchors A and B and there are 
> two distinct companies with the same name C, it is possible that one C 
> is certified via A and another via B.]
> 
> [DP1: The assumption : "there is requirement or mechanism that ensures 
> that a relying party with multiple trust anchors will not encounter 
> two CAs with the same name" is fully wrong ! The same name may be 
> found.]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFDjYrk054733; Mon, 15 Nov 2004 05:45:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAFDjYSa054732; Mon, 15 Nov 2004 05:45:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAFDjWon054696 for <[e-mail]>; Mon, 15 Nov 2004 05:45:33 -0800 (PST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1CThAj-000EJq-Lw for [e-mail]; Mon, 15 Nov 2004 13:45:34 +0000
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 13:46:18 +0000
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: Re: Is that right?set the valid_policy to OID-P;
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

alan wrote:

> ietf-pkix£¬
>
> In rfc3280,
> 6.1.3  Basic Certificate Processing
> (d)
> 	(1)
> 		(i)If the valid_policy_tree includes a node of depth i-1
>             where P-OID is in the expected_policy_set, create a child
>             node as follows: set the valid_policy to OID-P; set the
>             qualifier_set to P-Q, and set the expected_policy_set to
>             {P-OID}.
> OID-P is what?
>
> I can't make sure for this word.
>

When I implemented this for OpenSSL I assumed it was a typo and should
say P-OID. The example in figure 4 supports this.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF7Txk2043863; Sun, 14 Nov 2004 23:29:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAF7TxbA043862; Sun, 14 Nov 2004 23:29:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF7TwNe043832 for <[e-mail]>; Sun, 14 Nov 2004 23:29:58 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id IAA43254; Mon, 15 Nov 2004 08:42:02 +0100
Received: from bull.net ([129.181.81.63]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111508295039:1073 ; Mon, 15 Nov 2004 08:29:50 +0100 
Message-ID: <[e-mail]>
Date: Mon, 15 Nov 2004 08:31:09 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: pkix <[e-mail]>
Subject: 3280bis: root CA key update (self-issued certificates)
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/15/2004 08:29:51 AM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/15/2004 08:29:53 AM, Serialize complete at 11/15/2004 08:29:53 AM
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=windows-1252; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In RFC 2510, there are explanations about the means to update
a root key. These explanations should be incorporated into 3280bis
since they are not part of a "management protocol" but simply the
generation of self-issued certificates that are placed in a repository.

It is proposed to define what a self-issued certificate is:

self-issued certificate: a public-key certificate where the issuer
and the subject are the same CA. A CA may use self-issued
certificates, for example, during a key rollover operation to provide
trust from the old key to the new key.

The following text is a proposal based on the text from section 2.4
of RFC 2510 to be incorporated in 3280bis:

X. Root CA key update

This discussion only applies to CAs that are considered to be
a trust anchor for some relying party.

A graceful, scheduled change-over from one non-compromised CA
key pair to the next (CA key update) must be supported (note
that if the CA key is compromised, re-initialization must be
performed for all relying parties trusting that CA).

The basis of the procedure described here is that the CA protects
its new public key using its previous private key and vice versa.

Thus when a CA updates its key pair using this procedure it must
generate three self-issued CA certificates if these certificates
are made available using a repository.

The data structure used to protect the new and old CA public keys is
a self-issued certificate (which may contain certificate extensions).

X.1 CA Operator actions

To change the root key of the CA using this procedure, the CA operator
does the following:

1. Generate a new key pair;

2. Create a certificate containing the old CA public key signed
with the new private key (the "old with new" certificate);

3. Create a certificate containing the new CA public key signed
with the old private key (the "new with old" certificate);

4. Create a certificate containing the new CA public key signed
with the new private key (the "new with new" certificate);

5. Publish these certificates in a repository and/or via other
means;

The "old with new" certificate must have a validity period starting
at the generation time of the old key pair and ending at the expiry
date of the old public key.

The "new with old" certificate must have a validity period starting
at the generation time of the new key pair and ending at the time by
which all relying parties of this CA will securely possess the new CA
public key (at the latest, the expiry date of the old public key).

The "new with new" certificate must have a validity period starting
at the generation time of the new key pair and ending at the time by
which relying parties will no more be trusting the public key
contained in the self-signed certificate.

This scheme forces relying parties to acquire the new CA
self-signed certificate before the expiry of the last self-signed
certificate they trusted that was signed with the old CA private
key (via the "out-of-band" means).

At a given time a total of four self-issued certificates will exist:
OldWithOld; OldWithNew; NewWithOld; and NewWithNew.

X.2. Relying party actions

All relying parties require secure local access to some information,
at a minimum, the name of a CA which is directly trusted by this
entity and that CA's public key, or a self-signed certificate of
a CA. Such local trusted storage is referred to here as the relying
party's Personal Security Environment (PSE).

A relying party may directly obtain using out-of-bands means the
“new with new" certificate. The PSE will then contain two self-
signed certificates, i.e. “old with old" certificate and “new with
new" certificate.

When “out-of bands means” are or cannot be used, a relying party
which only has “old with old" certificate, will need to obtain from
a repository both, the "new with new" certificate and the "new
with old" certificate. It will then verify the "new with old"
certificate using the old key and after acquiring the new CA public
key will verify the "new with new" certificate. The PSE will then
contain two self-signed certificates: the "old with old"
certificate and the "new with new" certificate.

There may be however cases where it is not possible to update the
PSE (e.g. it is "hardwired" into the end entity's cryptographic
equipment). Such relying parties, will need keep in a secondary
storage the two certificates they have acquired and this will allow
relying parties to continue to check certificates up to the end of
the validity period of the “old by old” self-signed certificate.

Finally it may happen that a relying party is only installed with
the "new with new" certificate. Those relying parties will need to
acquire from a repository the “old with new” certificate so that
they may be able to verify certificates issued using the old key.


Denis





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF3k1gO093208; Sun, 14 Nov 2004 19:46:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAF3k1HK093207; Sun, 14 Nov 2004 19:46:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailao.ntcif.telstra.com.au (mailao.ntcif.telstra.com.au [202.12.233.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF3k0LM093196 for <[e-mail]>; Sun, 14 Nov 2004 19:46:00 -0800 (PST) (envelope-from [e-mail])
Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailao.ntcif.telstra.com.au (Postfix) with ESMTP id 03AE712B34; Mon, 15 Nov 2004 14:45:56 +1100 (EST)
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 9A811FF85; Mon, 15 Nov 2004 14:45:56 +1100 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA01582; Mon, 15 Nov 2004 14:45:56 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Subject: RE: 3280bis: indirectCRL boolean in IDP (3/3)
Date: Mon, 15 Nov 2004 14:44:42 +1100
Message-ID: <[e-mail]>
Thread-Topic: 3280bis: indirectCRL boolean in IDP (3/3)
Thread-Index: AcTJl2Gx9laDRMh2Q0a9n1CX4TXQ4gBKvZgw
From: "Manger, James H" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>, "pkix" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAF3k1LM093202
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The indirectCRL field should not be redefined.
CRL issuers do issue certificates if they are also CAs (as they often
are).
The indirectCRL field does not only indicate a "type b) indirect CRL" --
it must also be set to true for a "type a) indirect CRL".

Proposed action: don't accept Denis's proposed correction or proposed
note.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Denis Pinkas
Sent: Sunday, 14 November 2004 1:00 AM
To: [e-mail]
Cc: pkix
Subject: 3280bis: indirectCRL boolean in IDP (3/3)


3280bis: indirectCRL boolean in IDP (3/3)

This is a change and an addition proposal related to indirect CRLs.

>From section 5.2.5 Issuing Distribution Point, "the CRL issuer MUST
assert the indirectCRL boolean, if the scope of the CRL includes
certificates issued by authorities other than the CRL issuer".

This sentence is incorrect since CRL issuers do not issue certificates.


Proposed correction: 

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of the
CRL includes certificate identifiers from multiple authorities"
 
This boolean indicates a type b) indirect CRL but is named indirectCRL
boolean which is confusing with type a) indirect CRLs.

A note should be mentioned to clarify the ambiguity of the naming.

Proposed note: 

"The name of the boolean "indirectCRL" designates an indirect CRL that
includes certificate identifiers from multiple authorities, and not an
indirect CRL that includes certificate identifiers from a single CA.
An alternative name for that boolean would be: multipleCAs."

Denis





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF0a0Zv080183; Sun, 14 Nov 2004 16:36:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAF0a0qY080182; Sun, 14 Nov 2004 16:36:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hotmail.com (bay24-dav17.bay24.hotmail.com [64.4.18.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAF0ZxSF080172 for <[e-mail]>; Sun, 14 Nov 2004 16:35:59 -0800 (PST) (envelope-from [e-mail])
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 14 Nov 2004 16:36:00 -0800
Received: from 202.196.53.253 by BAY24-DAV17.phx.gbl with DAV; Mon, 15 Nov 2004 00:35:11 +0000
X-Originating-IP: [202.196.53.253]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
Date: Mon, 15 Nov 2004 08:35:24 +0800
From: "alan" <[e-mail]>
To: "ietf-pkix" <[e-mail]>
Subject: Is that right?set the valid_policy to OID-P;
X-mailer: Foxmail 5.0 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 15 Nov 2004 00:36:00.0491 (UTC) FILETIME=[147903B0:01C4CAAB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id iAF0ZxSF080175
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

ietf-pkix£¬

In rfc3280,
6.1.3  Basic Certificate Processing
(d)
	(1)
		(i)If the valid_policy_tree includes a node of depth i-1
            where P-OID is in the expected_policy_set, create a child
            node as follows: set the valid_policy to OID-P; set the
            qualifier_set to P-Q, and set the expected_policy_set to
            {P-OID}.
OID-P is what?

I can't make sure for this word.

thanks a lot.

alan,[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAE2dMi6002878; Sat, 13 Nov 2004 18:39:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAE2dM2O002877; Sat, 13 Nov 2004 18:39:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.quimbik.com (mail1.quimbik.com [198.87.27.232]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAE2dLYK002856 for <[e-mail]>; Sat, 13 Nov 2004 18:39:21 -0800 (PST) (envelope-from [e-mail])
Received: from nma.com (adsl-63-204-17-85.dsl.snfc21.pacbell.net [63.204.17.85]) by mail1.quimbik.com (Postfix) with ESMTP id F2AF233C4D4; Sat, 13 Nov 2004 18:39:10 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 13 Nov 2004 18:39:09 -0800
From: Ed Gerck <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: [e-mail], pkix <[e-mail]>
Subject: Re: 3280bis: certificate revocation status responsibility (1/3)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas wrote:


> Hereafter is a proposal:
> 
> "X. Certificate revocation status responsibility
> 
> The authority that issues certificates (public-key or attribute) has
> the responsibility to indicate the revocation status of certificates
> it issues. Generally, certificates are subject to possible subsequent
> revocation. This revocation, and notification of the revocation may be
> done directly by the same authority that issued the certificate, or
> indirectly by another authority duly authorized by the authority that
> issued the certificate."

This addition, considering how many questions I received when recently
stating the same in the ID draft-gerck-pkix-revocation-01.txt, seems to
be quite necessary.

Because the revocation status of a certificate refers to conditions that
a conforming issuer CA authoritatively defines for each certificate
(for example, revocation is delegated to X), this addition makes clear
that in PKIX a certificate is either revoked or not revoked. It does not
matter who you ask.

> RFC 3280 does not provide a formal definition for an indirect CRL, but
> it could be inferred from the content of section 5, whenever the CRL
> issuer is not the CA that issued the certificates, the CRL is referred
> to as an indirect CRL.
> 
> Proposed definition:
> 
> "indirect CRL: A revocation list that is not issued directly by a CA
> but by authority duly authorized by a CA".

Again, this clarification seems necessary.

> Other parts of RFC 3280 explain that an indirect CRL may be understood
> as a revocation list that provides revocation information about
> certificates either issued by:
> 
>    a) a single CA, or
>    b) multiple CAs.
> 
> In case a), called "indirect CRL of type a)", an indirect CRL provides
> revocation information for certificates issued by one CA, and for
> which a delegation has been granted by that CA.
> 
> In case b), called "indirect CRL of type b)", an indirect CRL still
> provides revocation information for certificates issued by one CA, but
> also for certificates issued by others CAs.
> 
> It should then be explained how a relying party may verify that
> delegation has indeed been granted by a CA to a CRL Issuer.
> 
> The following text is proposed to be happened after the previous
> proposed text:
> 
> "Assuming that the relying party has found a candidate CRL, the DN
> contained in the issuer field from the CRL SHALL match the subject DN
> contained a CRL Issuer certificate (i.e. a certificate which has the
> cRLSign bit set in the keyUsage extension) issued to the CRL Issuer by
> the CA that has issued the certificate to be tested.
> 
> In order to prevent DN ambiguity, the CRL Issuer SHALL not accept to
> manage revocation status information for a given CA DN, if it already
> manages revocation status information for another CA that has the same
> DN."

However, because multiple mechanisms are available to an issuer CA to
define revocation, CAs with the same DN could use different mechanisms
without ambiguity (even if we just distinguish CAs by their DNs). These
mechanisms include a CDP extension with a URI DistributionPointName, an
AIA extension with an OCSP access descriptor, and an AIA extension with
an HTTP CRL access descriptor.

Could your proposal reflect these possiblitities as well?


Cheers,
Ed Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADI9VLq032763; Sat, 13 Nov 2004 10:09:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADI9VZV032762; Sat, 13 Nov 2004 10:09:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id iADI9Ull032740 for <[e-mail]>; Sat, 13 Nov 2004 10:09:30 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 4384 invoked by uid 0); 13 Nov 2004 18:09:18 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.244.63) by woodstock.binhost.com with SMTP; 13 Nov 2004 18:09:18 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Sat, 13 Nov 2004 13:09:18 -0500
To: Peter Sylvester <[e-mail]>, [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: DVCS ASN.1 module definition error
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please send errata to the RFC Editor.

Russ


At 10:09 AM 11/13/2004, Peter Sylvester wrote:

> >
> > Looks like a bug to me.  Peter, can you send the RFC Editor an errata 
> entry.
> >
>
>Yes, it's a bug. There is another bug that didn't find its way into the 
>final text.
>
>A more or less known know implementation uses the following syntax peiecs.
>
>Data ::= CHOICE {
>       message           OCTET STRING ,
>       messageImprint    DigestInfo,
>       certs             [0] SEQUENCE SIZE (1..MAX) OF TargetEtcChain
>}
>
>PathProcInput ::= SEQUENCE {
>      acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF 
> PolicyInformation,
>      inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
>      explicitPolicyReqd          [0] BOOLEAN DEFAULT FALSE,
>      inhibitAnyPolicy            [1] BOOLEAN DEFAULT FALSE
>}
>
>
>
> > Russ
> >
> > At 03:02 AM 11/5/2004, ChungKil Kim wrote:
> >
> > >hi there.
> > >
> > >i found asn.1 definition error.
> > >see following definition(rfc3029 Page 15).
> > >
> > >
> > >Data ::= CHOICE {
> > >message OCTET STRING ,
> > >messageImprint DigestInfo,
> > >certs SEQUENCE SIZE (1..MAX) OF
> > >TargetEtcChain
> > >}
> > >
> > >DigestInfo ::= SEQUENCE {
> > >digestAlgorithm DigestAlgorithmIdentifier,
> > >digest Digest
> > >}
> > >
> > >messageImprint and certs have same tag type. it can't be CHOICE. right?
> >
> >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADFAIHK093286; Sat, 13 Nov 2004 07:10:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADFAI5D093285; Sat, 13 Nov 2004 07:10:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADFACuG093187 for <[e-mail]>; Sat, 13 Nov 2004 07:10:12 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iADF9xD18783; Sat, 13 Nov 2004 16:09:59 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sat, 13 Nov 2004 16:09:59 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iADF9v104579; Sat, 13 Nov 2004 16:09:57 +0100 (MET)
Date: Sat, 13 Nov 2004 16:09:57 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: DVCS ASN.1 module definition error
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Looks like a bug to me.  Peter, can you send the RFC Editor an errata entry.
> 

Yes, it's a bug. There is another bug that didn't find its way into the final text. 

A more or less known know implementation uses the following syntax peiecs.

Data ::= CHOICE {
      message           OCTET STRING ,
      messageImprint    DigestInfo,
      certs             [0] SEQUENCE SIZE (1..MAX) OF TargetEtcChain
}

PathProcInput ::= SEQUENCE {
     acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF PolicyInformation,
     inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
     explicitPolicyReqd          [0] BOOLEAN DEFAULT FALSE,
     inhibitAnyPolicy            [1] BOOLEAN DEFAULT FALSE
}



> Russ
> 
> At 03:02 AM 11/5/2004, ChungKil Kim wrote:
> 
> >hi there.
> >
> >i found asn.1 definition error.
> >see following definition(rfc3029 Page 15).
> >
> >
> >Data ::= CHOICE {
> >message OCTET STRING ,
> >messageImprint DigestInfo,
> >certs SEQUENCE SIZE (1..MAX) OF
> >TargetEtcChain
> >}
> >
> >DigestInfo ::= SEQUENCE {
> >digestAlgorithm DigestAlgorithmIdentifier,
> >digest Digest
> >}
> >
> >messageImprint and certs have same tag type. it can't be CHOICE. right?
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADE4ngV077690; Sat, 13 Nov 2004 06:04:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADE4nML077689; Sat, 13 Nov 2004 06:04:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADE4lVj077647 for <[e-mail]>; Sat, 13 Nov 2004 06:04:48 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA50600; Sat, 13 Nov 2004 15:16:50 +0100
Received: from bull.net ([129.181.81.126]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111315044270:1055 ; Sat, 13 Nov 2004 15:04:42 +0100 
Message-ID: <[e-mail]>
Date: Sat, 13 Nov 2004 15:05:56 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: pkix <[e-mail]>
Subject: 3280bis: keyUsage
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 03:04:43 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 03:04:44 PM, Serialize complete at 11/13/2004 03:04:44 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Is it really necessary to recall that keyUsage needs to be aligned with 
the revised text of X.509 which was adopted at the Geneva 2004 meeting ?

A text to be added in the security considerations section for 
hightligthing the poosible dangers to have both bits 0 and 1 set should 
also be added. This text has been proposed and accepted at the ISO 
Geneva 2004 meeting.

Denis


 






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADDwks7076280; Sat, 13 Nov 2004 05:58:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADDwkC7076279; Sat, 13 Nov 2004 05:58:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADDwjrd076249 for <[e-mail]>; Sat, 13 Nov 2004 05:58:45 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA35764; Sat, 13 Nov 2004 15:10:48 +0100
Received: from bull.net ([129.181.81.126]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111314584053:1054 ; Sat, 13 Nov 2004 14:58:40 +0100 
Message-ID: <[e-mail]>
Date: Sat, 13 Nov 2004 14:59:54 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: pkix <[e-mail]>
Subject: 3280bis: indirectCRL boolean in IDP (3/3)
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 02:58:41 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 02:58:41 PM, Serialize complete at 11/13/2004 02:58:41 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

3280bis: indirectCRL boolean in IDP (3/3)

This is a change and an addition proposal related to indirect CRLs.

>From section 5.2.5 Issuing Distribution Point, "the CRL issuer MUST
assert the indirectCRL boolean, if the scope of the CRL includes
certificates issued by authorities other than the CRL issuer".

This sentence is incorrect since CRL issuers do not issue
certificates.  

Proposed correction: 

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of
the CRL includes certificate identifiers from multiple authorities"
 
This boolean indicates a type b) indirect CRL but is named indirectCRL
boolean which is confusing with type a) indirect CRLs.

A note should be mentioned to clarify the ambiguity of the naming.

Proposed note: 

"The name of the boolean "indirectCRL" designates an indirect CRL that
includes certificate identifiers from multiple authorities, and not an
indirect CRL that includes certificate identifiers from a single CA.
An alternative name for that boolean would be: multipleCAs."

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADDuqYQ076025; Sat, 13 Nov 2004 05:56:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADDuqDb076024; Sat, 13 Nov 2004 05:56:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADDup3p076001 for <[e-mail]>; Sat, 13 Nov 2004 05:56:51 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA32968; Sat, 13 Nov 2004 15:08:54 +0100
Received: from bull.net ([129.181.81.126]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111314564453:1053 ; Sat, 13 Nov 2004 14:56:44 +0100 
Message-ID: <[e-mail]>
Date: Sat, 13 Nov 2004 14:57:58 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: pkix <[e-mail]>
Subject: 3280bis: CRL processing for indirect CRLs (2/3)
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 02:56:46 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 02:56:47 PM, Serialize complete at 11/13/2004 02:56:47 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

3280bis: CRL processing for indirect CRLs (2/3)

This is an addition proposal related to indirect CRLs.

The following text is proposed:

"X. CRL processing for indirect CRLs

X.1. Basic processing

For an indirect CRL, the relying party :

 - SHOULD fetch a CRL looking at the content of distributionPoint
   field the from the CRL DP extension of the certificate for which
   a revocation status is looked for, 

 - SHALL find a CRL Isssuer certificate that contains the DN of the
   CRL Issuer as indicated in the cRLIssuer field from the CRL DP
   extension,

 - SHALL verify that this CRL Isssuer certificate is signed by the CA
   which has issued the certificate for which a revocation status is
   looked for.

 - SHALL verify that this CRL Isssuer certificate is not revoked
   (see section X.2)
 
     If the indirectCRL boolean from the Issuing Distribution

     Point extension of the CRL is missing or set to FALSE, SHALL find
     out a CRL entry containing the certificate serial number of the
     certificate for which a revocation status is looked for. If no
     entry is found, then the certificate is valid. If an entry is
     found, then the certificate is revoked. 

     If the indirectCRL boolean from the Issuing Distribution Point
     extension of the CRL is set to TRUE, SHALL find out all CRL
     entries containing the certificate serial number of the
     certificate for which a revocation status is looked for.

       If no entry is found, the certificate is valid.

       If an entry is found, then for each found entry the following
       processing SHALL be done: 

          SHALL compare the DN contained in the issuer field from
          the certificate for which a revocation status is looked for,
          with the DN contained in every the certificateIssuer entry
          extension.  

             If there is no match and if there is no certificateIssuer
             entry extension present before this CRL entry, then the
             certificate is revoked.
 
             If there is a match and if the certificateIssuer entry
             extension present before this CRL entry matches the name
             of the DN contained in the issuer field from the
             certificate for which a revocation status is looked for,
             then the certificate is revoked.
 
             Otherwise, the certificate is valid. 

X.2 Verification that the CRL Isssuer certificate is not revoked
 
(text to be provided) ".

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADDtqNB075896; Sat, 13 Nov 2004 05:55:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iADDtqZY075895; Sat, 13 Nov 2004 05:55:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iADDtonq075869 for <[e-mail]>; Sat, 13 Nov 2004 05:55:51 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA32962; Sat, 13 Nov 2004 15:07:45 +0100
Received: from bull.net ([129.181.81.126]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111314553651:1052 ; Sat, 13 Nov 2004 14:55:36 +0100 
Message-ID: <[e-mail]>
Date: Sat, 13 Nov 2004 14:56:49 +0100
From: Denis Pinkas <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: pkix <[e-mail]>
Subject: 3280bis: certificate revocation status responsibility (1/3)
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 02:55:37 PM, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/13/2004 02:55:40 PM, Serialize complete at 11/13/2004 02:55:40 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

3280bis: certificate revocation status responsibility (1/3)

This is an addition proposal related to indirect CRLs.

X.509 states in section 7.3:

"7.3  Certificate validity

The authority that issues certificates (public-key or attribute) also
has the responsibility to indicate the validity of certificates it
issues.  Generally, certificates are subject to possible subsequent
revocation. This revocation, and notification of the revocation may be
done directly by the same authority that issued the certificate, or
indirectly by another authority duly authorized by the authority that
issued the certificate. "

This text from section 7.3 of X.509 should be imported into RFC 3280 and
this will close the issue about which entity MUST nominate the CRL
Issuer. The title of that section should be renamed "certificate
revocation status responsibility" and should be slightly re-arranged.
Hereafter is a proposal:

"X. Certificate revocation status responsibility

The authority that issues certificates (public-key or attribute) has
the responsibility to indicate the revocation status of certificates
it issues. Generally, certificates are subject to possible subsequent
revocation. This revocation, and notification of the revocation may be
done directly by the same authority that issued the certificate, or
indirectly by another authority duly authorized by the authority that
issued the certificate."

RFC 3280 does not provide a formal definition for an indirect CRL, but
it could be inferred from the content of section 5, whenever the CRL
issuer is not the CA that issued the certificates, the CRL is referred
to as an indirect CRL.

Proposed definition:

"indirect CRL: A revocation list that is not issued directly by a CA
but by authority duly authorized by a CA".

Other parts of RFC 3280 explain that an indirect CRL may be understood
as a revocation list that provides revocation information about
certificates either issued by:

    a) a single CA, or
    b) multiple CAs.

In case a), called "indirect CRL of type a)", an indirect CRL provides
revocation information for certificates issued by one CA, and for
which a delegation has been granted by that CA.

In case b), called "indirect CRL of type b)", an indirect CRL still
provides revocation information for certificates issued by one CA, but
also for certificates issued by others CAs.

It should then be explained how a relying party may verify that
delegation has indeed been granted by a CA to a CRL Issuer.

The following text is proposed to be happened after the previous
proposed text:

"Assuming that the relying party has found a candidate CRL, the DN
contained in the issuer field from the CRL SHALL match the subject DN
contained a CRL Issuer certificate (i.e. a certificate which has the
cRLSign bit set in the keyUsage extension) issued to the CRL Issuer by
the CA that has issued the certificate to be tested.

In order to prevent DN ambiguity, the CRL Issuer SHALL not accept to
manage revocation status information for a given CA DN, if it already
manages revocation status information for another CA that has the same
DN."

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACJNGK8013121; Fri, 12 Nov 2004 11:23:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACJNG1D013120; Fri, 12 Nov 2004 11:23:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACJNFiu013111 for <[e-mail]>; Fri, 12 Nov 2004 11:23:16 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iACJM62x030874 for <[e-mail]>; Fri, 12 Nov 2004 14:22:06 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iACJLZYB018811 for <[e-mail]>; Fri, 12 Nov 2004 14:21:36 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 12 Nov 2004 14:25:47 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Deadline for issues list for 3280bis
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I have previously requested that issues be submitted to David Cooper of 
NIST as the first step in this process, but only a handful of issues have 
been submitted to date.  I assume that means no one has any problems with 
the document's content!  If you are aware of outstanding issues, please 
submit them to David without delay at <[e-mail]>.

Please recall that the PKIX WG is shutting down.  This process cannot be 
allowed to go on forever.  To ensure that the 3280bis revision process is 
as efficient as possible, I am establishing a ***November 19**** deadline 
for submission of issues.  This is a hard deadline!  If  issues are raised 
after the 19th, they will be considered too late for consideration.

A word on scope: I have previously stated that new features would not be 
considered because we were going straight to DRAFT.  One of the ADs has 
informed me that the changes we are *required* to make with respect to 
processing international name forms will necessitate cycling at Proposed 
yet again.  This gives us some additional latitude in selecting which 
issues to address.  However, since we are trying to shut down, issues that 
would require definition of new features must be very well defined to 
ensure rapid completion of this document.

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACIqOBn005224; Fri, 12 Nov 2004 10:52:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACIqO79005223; Fri, 12 Nov 2004 10:52:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACIqNKj005178 for <[e-mail]>; Fri, 12 Nov 2004 10:52:23 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iACIqFjh026165 for <[e-mail]>; Fri, 12 Nov 2004 13:52:17 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06110407bdbab5097407@[128.89.89.75]>
Date: Fri, 12 Nov 2004 13:49:43 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: send me your slides, please
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I still need slides from the following folks, to complete the meeting 
notes and prepare our package for delivery to the Secretariat:

Tim Polk (2 slide sets)
David Chadwick
Daniel Brown
Baehyo Park

My thanks to Trevor, Stefan, Ryan, Santosh and Kurt for delivery of 
their slides. Stefan wins the prize for first delivery.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACE2u36014033; Fri, 12 Nov 2004 06:02:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iACE2uWk014032; Fri, 12 Nov 2004 06:02:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iACE2pqF013969 for <[e-mail]>; Fri, 12 Nov 2004 06:02:51 -0800 (PST) (envelope-from [e-mail])
Received: from wmcooper (pcp09266381pcs.arlngt01.va.comcast.net [69.143.109.88]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iACE2gNE011332; Fri, 12 Nov 2004 09:02:42 -0500
Message-Id: <[e-mail]>
From: "Matt Cooper" <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>, "'Manuel Gil Perez'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Bridge CA and crossCertificatePair
Date: Fri, 12 Nov 2004 09:01:19 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTIgMWdHIloHgh6QRS3yh8trsz6oQAOuf2w
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iACE2pqF013982
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Quite right Tom, it is definitely multivalued.  If it was inferred that it
was not in the doc, it was in error.  Thanks for pointing this out, we'll
look at it.

And Manuel, to expand on what Tom's message, the encoding spec you
originally found is correct. The encoding should be a single pair of
certificates. As Tom said, since crossCertificatePair is multivalued, you
simply store as many encoded pairs as you need in the directory.  It's just
like certificates; the ASN.1 spec is only for one certificate; and you may
store as many as you need in the directory.

Incidentally, the reason crossCertificatePair is done this way is so that
related cross certificates may be associated. In other words, if we are CAs
and I were to issue you a certificate and you were to issue me a
certificate, we would put these two certificates together as a pair in our
respective crossCertificatePair entries.

 
Matt Cooper
Orion Security Solutions
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101
(Mob) 703.981.2269
(Off) 703.917.0060 x. 30
(Fax) 703.917.0260
Visit our website!
http://www.orionsec.com
 


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Gindin
Sent: Friday, November 12, 2004 12:09 AM
To: Manuel Gil Perez; Matt Cooper
Cc: [e-mail]
Subject: Re: Bridge CA and crossCertificatePair


        Manuel:

        CrossCertificatePair has AFAIK always been considered to be a
multi-valued attribute, as you can see from (for example) RFC 2587 section
3.2 where the existence of multiple CA Certificates in the caCertificate
attribute and of multiple 'forward' elements in the crossCertificatePair
attribute is discussed in consecutive paragraphs.  However, the
certpathbuild draft lists userCertificate and caCertificate as multi-valued
but doesn't make that statement about CrossCertificatePair. 
It should probably change to do so, unless it's too late in the process.
        Please note that the syntax of caCertificate is just a certificate,
not a sequence of them.

                Tom Gindin






"Manuel Gil Perez" <[e-mail]>
Sent by: [e-mail]
11/11/2004 01:23 PM
Please respond to "Manuel Gil Perez"
 
        To:     <[e-mail]>
        cc: 
        Subject:        Bridge CA and crossCertificatePair



Dear PKIX members,

I need to develop a bridge CA where it must store one or more
cross-certificates. Revising the RFCs (about LDAP, X.509, etc.) and looking
up on the web I conclude that it is technically possible (in accordance with
RFC 3280) to store one or more cross-certificate into my bridge CA (this
value is multi-valued).

But really, according to the specification (see below), I can only store one
pair of cross-certificates. Is it possible that the attribute
CertificatePair is not correct and should be changed for the following??

CertificatePair ::= SEQUENCE SIZE(1..MAX) OF CertificateForwardReverse;

CertificateForwardReverse ::= SEQUENCE {
   forward [0] Certificate OPTIONAL,
   reverse [1] Certificate OPTIONAL,
   -- at least one of the pair shall be present -- }

In any case... can somebody send me the correct specification for the
attribute CertificatePair??

Many thanks, and best regards...

------
Manuel Gil Pérez
http://pki.umu.euro6ix.org


======

pkiCA OBJECT-CLASS ::= {
   SUBCLASS OF { top}
   KIND auxiliary
   MAY CONTAIN {
      cACertificate |
      certificateRevocationList |
      authorityRevocationList |
      crossCertificatePair }
   ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22) }

crossCertificatePair ATTRIBUTE ::= {
   WITH SYNTAX CertificatePair
   EQUALITY MATCHING RULE certificatePairExactMatch
    ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40) }

CertificatePair ::= SEQUENCE {
   forward [0] Certificate OPTIONAL,
   reverse [1] Certificate OPTIONAL,
   -- at least one of the pair shall be present -- } 








Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAC59V7a017321; Thu, 11 Nov 2004 21:09:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAC59Vhg017320; Thu, 11 Nov 2004 21:09:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAC59U1a017305 for <[e-mail]>; Thu, 11 Nov 2004 21:09:30 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAC59aMW363774 for <[e-mail]>; Fri, 12 Nov 2004 00:09:36 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAC59Q72289214 for <[e-mail]>; Fri, 12 Nov 2004 00:09:26 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAC59Qh1013636 for <[e-mail]>; Fri, 12 Nov 2004 00:09:26 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAC59QxW013633; Fri, 12 Nov 2004 00:09:26 -0500
In-Reply-To: <005401c4c81b$99f48e70$[e-mail]>
To: "Manuel Gil Perez" <[e-mail]>, [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: Bridge CA and crossCertificatePair
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 12 Nov 2004 00:09:23 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF1|October 13, 2004) at 11/12/2004 00:09:25, Serialize complete at 11/12/2004 00:09:25
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAC59U1a017307
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Manuel:

        CrossCertificatePair has AFAIK always been considered to be a 
multi-valued attribute, as you can see from (for example) RFC 2587 section 
3.2 where the existence of multiple CA Certificates in the caCertificate 
attribute and of multiple 'forward' elements in the crossCertificatePair 
attribute is discussed in consecutive paragraphs.  However, the 
certpathbuild draft lists userCertificate and caCertificate as 
multi-valued but doesn't make that statement about CrossCertificatePair. 
It should probably change to do so, unless it's too late in the process.
        Please note that the syntax of caCertificate is just a 
certificate, not a sequence of them.

                Tom Gindin






"Manuel Gil Perez" <[e-mail]>
Sent by: [e-mail]
11/11/2004 01:23 PM
Please respond to "Manuel Gil Perez"
 
        To:     <[e-mail]>
        cc: 
        Subject:        Bridge CA and crossCertificatePair



Dear PKIX members,

I need to develop a bridge CA where it must store one or more 
cross-certificates. Revising the RFCs (about LDAP, X.509, etc.) and 
looking 
up on the web I conclude that it is technically possible (in accordance 
with 
RFC 3280) to store one or more cross-certificate into my bridge CA (this 
value is multi-valued).

But really, according to the specification (see below), I can only store 
one 
pair of cross-certificates. Is it possible that the attribute 
CertificatePair is not correct and should be changed for the following??

CertificatePair ::= SEQUENCE SIZE(1..MAX) OF CertificateForwardReverse;

CertificateForwardReverse ::= SEQUENCE {
   forward [0] Certificate OPTIONAL,
   reverse [1] Certificate OPTIONAL,
   -- at least one of the pair shall be present -- }

In any case... can somebody send me the correct specification for the 
attribute CertificatePair??

Many thanks, and best regards...

------
Manuel Gil Pérez
http://pki.umu.euro6ix.org


======

pkiCA OBJECT-CLASS ::= {
   SUBCLASS OF { top}
   KIND auxiliary
   MAY CONTAIN {
      cACertificate |
      certificateRevocationList |
      authorityRevocationList |
      crossCertificatePair }
   ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22) }

crossCertificatePair ATTRIBUTE ::= {
   WITH SYNTAX CertificatePair
   EQUALITY MATCHING RULE certificatePairExactMatch
    ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40) 
}

CertificatePair ::= SEQUENCE {
   forward [0] Certificate OPTIONAL,
   reverse [1] Certificate OPTIONAL,
   -- at least one of the pair shall be present -- } 







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAC2NROa083167; Thu, 11 Nov 2004 18:23:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAC2NRkb083166; Thu, 11 Nov 2004 18:23:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw ([202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAC2NG57083061 for <[e-mail]>; Thu, 11 Nov 2004 18:23:26 -0800 (PST) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id iAC2MvW5010003; Fri, 12 Nov 2004 10:22:57 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id iAC2MvHf014382; Fri, 12 Nov 2004 10:22:57 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id iAC2MuZG014313; Fri, 12 Nov 2004 10:22:57 +0800
Message-ID: <012201c4c85e$852b3960$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Manuel Gil Perez" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <005401c4c81b$99f48e70$[e-mail]>
Subject: Re: Bridge CA and crossCertificatePair
Date: Fri, 12 Nov 2004 10:22:55 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Pérez,

The syntax need not to be changed.

The crossCertificatePair is a multi-valued attribute.
That means you can store multiple CertificatePair
objects in a crossCertificatePair attribute.

Wen-Cheng Wang

----- Original Message ----- 
From: "Manuel Gil Perez" <[e-mail]>
To: <[e-mail]>
Sent: Friday, November 12, 2004 2:23 AM
Subject: Bridge CA and crossCertificatePair


>
> Dear PKIX members,
>
> I need to develop a bridge CA where it must store one or more
> cross-certificates. Revising the RFCs (about LDAP, X.509, etc.) and looking
> up on the web I conclude that it is technically possible (in accordance with
> RFC 3280) to store one or more cross-certificate into my bridge CA (this
> value is multi-valued).
>
> But really, according to the specification (see below), I can only store one
> pair of cross-certificates. Is it possible that the attribute
> CertificatePair is not correct and should be changed for the following??
>
> CertificatePair ::= SEQUENCE SIZE(1..MAX) OF CertificateForwardReverse;
>
> CertificateForwardReverse ::= SEQUENCE {
>    forward [0] Certificate OPTIONAL,
>    reverse [1] Certificate OPTIONAL,
>    -- at least one of the pair shall be present -- }
>
> In any case... can somebody send me the correct specification for the
> attribute CertificatePair??
>
> Many thanks, and best regards...
>
> ------
> Manuel Gil Pérez
> http://pki.umu.euro6ix.org
>
>
> ======
>
> pkiCA OBJECT-CLASS ::= {
>    SUBCLASS OF { top}
>    KIND auxiliary
>    MAY CONTAIN {
>       cACertificate |
>       certificateRevocationList |
>       authorityRevocationList |
>       crossCertificatePair }
>    ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22) }
>
> crossCertificatePair ATTRIBUTE ::= {
>    WITH SYNTAX CertificatePair
>    EQUALITY MATCHING RULE certificatePairExactMatch
>     ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40) }
>
> CertificatePair ::= SEQUENCE {
>    forward [0] Certificate OPTIONAL,
>    reverse [1] Certificate OPTIONAL,
>    -- at least one of the pair shall be present -- }
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABIOlxr080934; Thu, 11 Nov 2004 10:24:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iABIOlN2080933; Thu, 11 Nov 2004 10:24:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABIOkE6080900 for <[e-mail]>; Thu, 11 Nov 2004 10:24:46 -0800 (PST) (envelope-from [e-mail])
Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9C912308DD for <[e-mail]>; Thu, 11 Nov 2004 19:24:34 +0100 (CET)
Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with SMTP id A855F30E67 for <[e-mail]>; Thu, 11 Nov 2004 19:23:52 +0100 (CET)
Received: (qmail 496 invoked from network); 11 Nov 2004 18:23:12 -0000
Received: from ycaro.dif.um.es (HELO ycaro) (155.54.210.68) by aries.dif.um.es with SMTP; 11 Nov 2004 18:23:12 -0000
Message-ID: <005401c4c81b$99f48e70$[e-mail]>
Reply-To: "Manuel Gil Perez" <[e-mail]>
From: "Manuel Gil Perez" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Bridge CA and crossCertificatePair
Date: Thu, 11 Nov 2004 19:23:52 +0100
Organization: ANTS Research Group
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear PKIX members,

I need to develop a bridge CA where it must store one or more 
cross-certificates. Revising the RFCs (about LDAP, X.509, etc.) and looking 
up on the web I conclude that it is technically possible (in accordance with 
RFC 3280) to store one or more cross-certificate into my bridge CA (this 
value is multi-valued).

But really, according to the specification (see below), I can only store one 
pair of cross-certificates. Is it possible that the attribute 
CertificatePair is not correct and should be changed for the following??

CertificatePair ::= SEQUENCE SIZE(1..MAX) OF CertificateForwardReverse;

CertificateForwardReverse ::= SEQUENCE {
   forward [0] Certificate OPTIONAL,
   reverse [1] Certificate OPTIONAL,
   -- at least one of the pair shall be present -- }

In any case... can somebody send me the correct specification for the 
attribute CertificatePair??

Many thanks, and best regards...

------
Manuel Gil Pérez
http://pki.umu.euro6ix.org


======

pkiCA OBJECT-CLASS ::= {
   SUBCLASS OF { top}
   KIND auxiliary
   MAY CONTAIN {
      cACertificate |
      certificateRevocationList |
      authorityRevocationList |
      crossCertificatePair }
   ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22) }

crossCertificatePair ATTRIBUTE ::= {
   WITH SYNTAX CertificatePair
   EQUALITY MATCHING RULE certificatePairExactMatch
    ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40) }

CertificatePair ::= SEQUENCE {
   forward [0] Certificate OPTIONAL,
   reverse [1] Certificate OPTIONAL,
   -- at least one of the pair shall be present -- } 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABFW3kp047675; Thu, 11 Nov 2004 07:32:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iABFW3Rg047674; Thu, 11 Nov 2004 07:32:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id iABFW3JF047655 for <[e-mail]>; Thu, 11 Nov 2004 07:32:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 26215 invoked by uid 0); 11 Nov 2004 15:31:58 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (130.129.135.212) by woodstock.binhost.com with SMTP; 11 Nov 2004 15:31:58 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Thu, 11 Nov 2004 10:31:57 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: a heads up on the next edition of X.509
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I just got a "heads up" message from Hoyt Kesterson.

Hoyt believes that the ISO/ITU-T Directory group will publish the 5th 
edition of X.509 by June 2005. They have a policy of supporting the current 
edition and the previous edition. At the moment they support (meaning that 
they will process defect reports) the 3rd and 4th editions.  So, in June 
they will drop support of the 3rd edition.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABDrs6Q026634; Thu, 11 Nov 2004 05:53:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iABDrshT026633; Thu, 11 Nov 2004 05:53:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABDrrJl026621 for <[e-mail]>; Thu, 11 Nov 2004 05:53:54 -0800 (PST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Thu, 11 Nov 2004 08:55:42 -0500
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002A_01C4C7CB.F685AA20"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Briefing on CRL Path for IETF PKIX WG Meeting
Thread-Index: AcTH7KNeloV37Xs7TJmzBRT6D5vBWQAARe/g
From: "Dave Engberg" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01C4C7CB.F685AA20
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_002B_01C4C7CB.F685AA20"


------=_NextPart_001_002B_01C4C7CB.F685AA20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 
I think that there is a confusion between the logical identity of a CA and
the provable denotation of its certificates. 
 
For a PKI administrator, it may be philosophically correct to say that the
CA is defined by its name alone.  Of course, it is not useful (or even
correct?) to say that every X.509 certificate with the same subject Name
denotes the same CA.  For relying parties, Name equality is a necessary but
not sufficient requirement for determining whether two certs refer to the
same entity.
 
For relying party processing, I think that it is more useful to consider a
CA to be a an entity with a single Name and one or more Public Keys.  For a
relying party:
 
* Two certs with the same subject Name and Public Key always denote the same
entity.
 
* Two certs with different subject Names always denote different entities.
 
* Two certs with the same subject Name and different Public Keys denote the
same entity if and only if a trusted path can be found to both according to
Santosh's algorithm.
 
 
Of course, all this talk about theoretical CA identity for CRL processing
has obscured Santosh's original recommendation that if you care at all about
interoperability, your CA should always sign a CRL with the same key used to
sign any certs holding that CRL's distributionPoint URI.  The confusion on
this list makes it seem like this recommendation should be repeated.
 
(In fact, if the goal of the spec was interoperability, I'd make Santosh's
recommendation mandatory instead of hoping that all COTS PKI apps will
implement all these baroque discovery and validation edge cases.  The value
of this alternate-key CRL signing is pretty low compared to the complexity
it introduces for relying parties ...)
 


  _____  

From: [e-mail] [mailto:[e-mail]] On
Behalf Of David A. Cooper
Sent: Wednesday, November 10, 2004 9:34 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting


Denis,

X.509 states:


NOTE 1 - Although the CAs are unambiguously defined by a distinguished name
in the DIT, this does not imply that there is any relationship between the
organization of the CAs and the DIT.


Where in X.509 does it say or even imply that a CA in not defined by name
alone, but that a name is always relative to the CA which has issued it?  I
can't find anything in X.509 to support this.  On the other hand, there is
plenty to support the notion a CA is defined by name alone.  In addition to
the above quote, note that the cRLDistributionPoints extension identifies an
indirect CRL issuer by name alone as does the certificateIssuer CRL entry
extension.  This makes sense if a CA can be identified by name alone but
does not make sense if a CA name is only relative to the CA which has issued
it.  Similarly, in many protocols, a certificate is identified by issuer
name and serial number.  These two pieces of information would not be
sufficient to identify a certificate if your interpretation were correct.

 ...
 
Dave


Denis Pinkas wrote: 

Slide 5. The statement " A CA is defined by name alone" is 
wrong. A CA is not simply defined by a name alone. A name, 
for X.509, is always relative to the CA which has issued it. 
So the "clarification' to say that a CA is unambiguously 
defined by name is wrong. Then since the other slides are 
based on that wrong assumption, they are wrong as well. 

 ... 


------=_NextPart_001_002B_01C4C7CB.F685AA20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV><FONT face=3DArial=20
color=3D#0000ff size=3D2><SPAN class=3D365335512-11112004>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>I think that there is a confusion between the =
logical=20
identity of a CA and the provable denotation of its certificates.=20
</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>For a PKI administrator, it may be =
philosophically=20
correct to say that the CA&nbsp;is defined by its name alone.&nbsp; Of =
course,=20
it is not useful (or even correct?) to say that every X.509 certificate =
with the=20
same subject Name denotes the same CA.&nbsp; </SPAN></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2><SPAN class=3D365335512-11112004>For relying =
parties, Name=20
equality is a necessary but not sufficient requirement for determining =
whether=20
two certs refer to the same entity.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>For relying party processing, I =
think&nbsp;that it is=20
more useful to consider a CA to be a an entity with a single Name and =
one or=20
more Public Keys.&nbsp; For a relying party:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>* Two certs with the same subject Name and =
Public Key=20
always denote the same entity.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>* Two certs with different subject Names =
always denote=20
different entities.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><SPAN class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>* Two certs with the same subject Name and =
different=20
Public Keys denote the same entity if and only if&nbsp;a trusted path =
can be=20
found to both according to Santosh's algorithm.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>Of course, all this talk about theoretical=20
CA&nbsp;identity for CRL processing has obscured Santosh's original=20
recommendation that if you care at all about interoperability, your CA =
should=20
always sign a CRL with the same key used to sign any certs holding that =
CRL's=20
distributionPoint URI.&nbsp; The confusion on this list makes it seem =
like this=20
recommendation should be repeated.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004>(In fact, if the goal of the spec was =
interoperability,=20
I'd make Santosh's recommendation mandatory instead of hoping that all =
COTS PKI=20
apps will implement all these baroque discovery and validation edge =
cases.&nbsp;=20
The value of this&nbsp;alternate-key CRL signing is pretty low compared =
to the=20
complexity it introduces for relying parties ...)</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D365335512-11112004></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><SPAN class=3D365335512-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><BR></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>David A.=20
Cooper<BR><B>Sent:</B> Wednesday, November 10, 2004 9:34 =
PM<BR><B>To:</B> Denis=20
Pinkas<BR><B>Cc:</B> [e-mail]<BR><B>Subject:</B> Re: Briefing =
on CRL=20
Path for IETF PKIX WG Meeting<BR></FONT><BR></DIV>
<DIV></DIV>Denis,<BR><BR>X.509 states:<BR>
<BLOCKQUOTE>NOTE 1 - Although the CAs are unambiguously defined by a=20
  distinguished name in the DIT, this does not imply that there is any=20
  relationship between the organization of the CAs and the =
DIT.<BR></BLOCKQUOTE>
<DIV>Where in X.509 does it say or even imply that a CA in not defined =
by name=20
alone, but that a name is always relative to the CA which has issued =
it?&nbsp; I=20
can't find anything in X.509 to support this.&nbsp; On the other hand, =
there is=20
plenty to support the notion a CA is defined by name alone.&nbsp; In =
addition to=20
the above quote, note that the cRLDistributionPoints extension =
identifies an=20
indirect CRL issuer by name alone as does the certificateIssuer CRL =
entry=20
extension.&nbsp; This makes sense if a CA can be identified by name =
alone but=20
does not make sense if a CA name is only relative to the CA which has =
issued=20
it.&nbsp; Similarly, in many protocols, a certificate is identified by =
issuer=20
name and serial number.&nbsp; These two pieces of information would not =
be=20
sufficient to identify a certificate if your interpretation were=20
correct.<BR><BR><SPAN class=3D365335512-11112004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;...</FONT></SPAN></DIV>
<DIV><SPAN =
class=3D365335512-11112004>&nbsp;</SPAN><BR>Dave<BR><BR><BR>Denis=20
Pinkas wrote: </DIV>
<BLOCKQUOTE cite=[e-mail] type=3D"cite">Slide 5. =
The=20
  statement " A CA is defined by name alone" is <BR>wrong. A CA is not =
simply=20
  defined by a name alone. A name, <BR>for X.509, is always relative to =
the CA=20
  which has issued it. <BR>So the "clarification' to say that a CA is=20
  unambiguously <BR>defined by name is wrong. Then since the other =
slides are=20
  <BR>based on that wrong assumption, they are wrong as =
well.&nbsp;<BR><BR><SPAN=20
  class=3D365335512-11112004><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;...&nbsp;</FONT></SPAN></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_002B_01C4C7CB.F685AA20--

------=_NextPart_000_002A_01C4C7CB.F685AA20
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII1jCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA4wwggL1oAMCAQICARkwDQYJKoZI
hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE
AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDQwNzEyMTMwMjE4WhcNMDUw
NzI2MTMwMjE4WjBnMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRYwFAYD
VQQDEw1EYXZpZCBFbmdiZXJnMSYwJAYJKoZIhvcNAQkBFhdkZW5nYmVyZ0Bjb3Jlc3RyZWV0LmNv
bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJXX+JZ1oaEb2TCawk31rzpOIRTHZyP
UGTUGNyMasqczNZATvXu2RTlon8dwEuO4evr5KE9iDe0jQSkj1g5HBEsFAH+JPU7Y0uYupm/kiyr
6FiyhBCQtWhrcNii0yahcIEbH/fBAf5V10Y2wHKFrPH6uTrj+YGhBpaXxkEZpXCe2QZtkR/kcbKa
QaMCaU27vLAZ4QT6vJTf5oG/SD1KU232kYttiLeRjnePWipH8In7crGPhgJCeQP5UtE9uHDjOStt
eZxXsWAzU7oW9nb9jHL2xOWPQyhBs4JaPvgSdFkenI6L8flsQm72U8lrV/4dqKu330m5pH89XTYl
o2PcqIUCAwEAAaOB2DCB1TAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDov
L2NybC5nZW90cnVzdC5jb20vY3Jscy9jb3Jlc3RyZWV0LmNybDAiBgNVHREEGzAZgRdkZW5nYmVy
Z0Bjb3Jlc3RyZWV0LmNvbTAfBgNVHSMEGDAWgBTY7H+TGMVmA8MQbDwE9neFPv8LtjBABggrBgEF
BQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9nZW90cnVzdC1vY3NwLmNvcmVzdHJlZXQuY29t
LzANBgkqhkiG9w0BAQUFAAOBgQAtAQMtzyIzARw6d/sy1qPn+Mqr7aPEJFofkSW57NE639PcrXmC
E9LzVm5mtmoNkeeyHDOgla79ez8MzndDxhlwQvNdaiu124jWbgEoHC1q2K4McbaJlxjhPbCpFr7Z
CzxQxOmFxXjb16XGotrxX1aj2YWuAAdt9H3x+tHBXCn+WDGCAxowggMWAgEBMFcwUjELMAkGA1UE
BhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkCARkwCQYFKw4DAhoFAKCCAZgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMTExMTM1MzUwWjAjBgkqhkiG9w0BCQQxFgQUAjcGKd6s
WM6BKoj2typYAFnHwEgwZgYJKwYBBAGCNxAEMVkwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP
Q29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0
eQIBGTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG
9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgsq
hkiG9w0BCRACCzFZoFcwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEp
MCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCARkwDQYJKoZIhvcNAQEB
BQAEggEAFRD4yos2Q36KTCeEt0DejpnbEZITe5rT3ed58pJ3yom1HRoai403UDQH/g25Hw7AUJVl
+HyNXQvQN/OBpFhLa5+B7s7iym9PkT1IUJ9HRqiZAKBQ/n9nfHr8Y/IxFvFXKJgiTWnWZzade2sO
yuMlGHtOgz+YARYitNzsOWzTaRyz7LofZ94+E1ov8znXk5rKjibmXAt0IslKXVKFgqKaL0StbHmR
vOae6lRwHgslLxD9XNBgvox/yvOMkRFwH3dQt4QWh/L8Ug12iieKkOj6O1j24Sa2LYBaYNrXBLtP
H7rQED4kQB2Hr4TM3s0xXfyDXTzRbygxxFjLt6GsdeIRKgAAAAAAAA==

------=_NextPart_000_002A_01C4C7CB.F685AA20--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABC8njJ077156; Thu, 11 Nov 2004 04:08:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iABC8nhp077155; Thu, 11 Nov 2004 04:08:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iABC8iS5077115 for <[e-mail]>; Thu, 11 Nov 2004 04:08:44 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iABC852x002511; Thu, 11 Nov 2004 07:08:05 -0500
Received: from [129.6.54.231] (sk.ncsl.nist.gov [129.6.54.231]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iABC7QYA015629; Thu, 11 Nov 2004 07:07:33 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 21:34:21 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <009e01c4c5b2$16d7f9c0$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Denis,<br>
<br>
X.509 states:<br>
<blockquote>NOTE 1 - Although the CAs are
unambiguously defined by a distinguished name in the DIT, this does not
imply that there is any relationship between the organization of the
CAs and
the DIT.<br>
</blockquote>
Where in X.509 does it say or even imply that a CA in not defined by
name alone, but that a name is always relative to the CA which has
issued it?&nbsp; I can't find anything in X.509 to support this.&nbsp; On the
other hand, there is plenty to support the notion a CA is defined by
name alone.&nbsp; In addition to the above quote, note that the
cRLDistributionPoints extension identifies an indirect CRL issuer by
name alone as does the certificateIssuer CRL entry extension.&nbsp; This
makes sense if a CA can be identified by name alone but does not make
sense if a CA name is only relative to the CA which has issued it.&nbsp;
Similarly, in many protocols, a certificate is identified by issuer
name and serial number.&nbsp; These two pieces of information would not be
sufficient to identify a certificate if your interpretation were
correct.<br>
<br>
I also do not understand your scenarios for indirect CRL issuance
(below).&nbsp; A CA is always allowed to issue CRLs that cover its own
certificates or delegate the issuance of CRLs to another entity.&nbsp; If
one CA issues a cross-certificate to another CA with cRLSign set to
FALSE, that does not mean that the subject CA is not permitted to issue
CRLs.&nbsp; It simply means that the subject public key in that
cross-certificate can not be used to verify CRL signatures. It could
simply be that the subject CA uses different keys to sign certificates
and CRLs.&nbsp; The subject CA could always create a self-issued certificate
with cRLSign set to TRUE in which the subject public key in the
self-issued certificate corresponds to the CRL signing key.&nbsp; This would
not be contrary to X.509 at all.<br>
<br>
Dave<br>
<br>
<br>
Denis Pinkas wrote:
<blockquote cite="[e-mail]" type="cite">Slide 5.
The statement " A CA is defined by name alone" is
  <br>
wrong. A CA is not simply defined by a name alone. A name,
  <br>
for X.509, is always relative to the CA which has issued it.
  <br>
So the "clarification' to say that a CA is unambiguously
  <br>
defined by name is wrong. Then since the other slides are
  <br>
based on that wrong assumption, they are wrong as well.
  <br>
  <br>
Slide 7:&nbsp; There is no "need to account for multiple CAs with
  <br>
the same name". This formulation is pretty bad. A CA must
  <br>
provide different names to two different entities. Since a CA
  <br>
name is relative to another CA name space, there cannot be
  <br>
two CAs with the same name.
  <br>
  <br>
Slide 8: The statement : "There can be more than one CA with
  <br>
the same name" is wrong. Once again, a (CA) name is always
  <br>
relative to a CA name space.
  <br>
</blockquote>
<br>
Denis Pinkas wrote:
<blockquote cite="[e-mail]" type="cite"> The CRL
Issuer is *not* the CA. This CA is called CA 1. <br>
CA 2 is a CA that has issued a CA certificate to CA 1. <br>
  <br>
&nbsp;a) the CRL Issuer is nominated by CA 1 that has issued <br>
&nbsp;&nbsp;&nbsp; the end-user certificate. This case would make sense <br>
&nbsp;&nbsp;&nbsp; when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates <br>
&nbsp;&nbsp;&nbsp; that role to one or more CRL Issuers. This means that <br>
&nbsp;&nbsp;&nbsp; a CRL Issuer certificate is issued by CA 1 to every CRL Issuer. <br>
  <br>
&nbsp;b) the CRL Issuer is nominated by CA 2 that has issued a CA <br>
&nbsp;&nbsp;&nbsp; certificate to CA 1. This case would make sense when CA 2 <br>
&nbsp;&nbsp;&nbsp; has not allowed CA 1 to issue CRLs. This means that a CRL Issuer <br>
&nbsp;&nbsp;&nbsp; certificate is issued by CA 2 to every CRL Issuer. CA 1 may <br>
&nbsp;&nbsp;&nbsp; then only choose a CRL Issuer that has been granted <br>
&nbsp;&nbsp;&nbsp; the authorization to issue CRLs by CA 2.<br>
</blockquote>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB1gcJO016292; Wed, 10 Nov 2004 17:42:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAB1gcjo016291; Wed, 10 Nov 2004 17:42:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAB1gWc5016208 for <[e-mail]>; Wed, 10 Nov 2004 17:42:37 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id E3CE6348BA; Thu, 11 Nov 2004 14:42:30 +1300 (NZDT)
Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23855-03; Thu, 11 Nov 2004 14:42:30 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 51ACC348C8; Thu, 11 Nov 2004 14:42:30 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 01B9537747; Thu, 11 Nov 2004 14:42:30 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CS3yr-0004aT-00; Thu, 11 Nov 2004 14:42:33 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
In-Reply-To: <000401c4c730$990f7060$[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 11 Nov 2004 14:42:33 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Santosh Chokhani" <[e-mail]> writes:

>We are not communicating effectively.  I am sure others are not following us
>either.

Well, there had been an off-list suggestion that this thread be used as a
substitute for generic-brand valium...

Peter :-).



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAMbXa1040448; Wed, 10 Nov 2004 14:37:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAMbXkR040447; Wed, 10 Nov 2004 14:37:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id iAAMbWp0040411 for <[e-mail]>; Wed, 10 Nov 2004 14:37:32 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 10997 invoked by uid 0); 10 Nov 2004 22:37:25 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (130.129.135.212) by woodstock.binhost.com with SMTP; 10 Nov 2004 22:37:25 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Wed, 10 Nov 2004 17:28:34 -0500
To: ChungKil Kim <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: DVCS ASN.1 module definition error
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Looks like a bug to me.  Peter, can you send the RFC Editor an errata entry.

Russ

At 03:02 AM 11/5/2004, ChungKil Kim wrote:

>hi there.
>
>i found asn.1 definition error.
>see following definition(rfc3029 Page 15).
>
>
>Data ::= CHOICE {
>message OCTET STRING ,
>messageImprint DigestInfo,
>certs SEQUENCE SIZE (1..MAX) OF
>TargetEtcChain
>}
>
>DigestInfo ::= SEQUENCE {
>digestAlgorithm DigestAlgorithmIdentifier,
>digest Digest
>}
>
>messageImprint and certs have same tag type. it can't be CHOICE. right?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAALtl6C023631; Wed, 10 Nov 2004 13:55:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAALtlEU023630; Wed, 10 Nov 2004 13:55:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAALtdpB023482 for <[e-mail]>; Wed, 10 Nov 2004 13:55:42 -0800 (PST) (envelope-from [e-mail])
Received: from [10.67.86.181] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAALtTjf021038; Wed, 10 Nov 2004 16:55:32 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06110404bdb83d94f42c@[10.67.86.181]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 10 Nov 2004 16:54:32 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: several key in same certificate
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:00 PM +0100 11/10/04, [e-mail] wrote:
>Hi,
>
>it is possible to have several key in the same certificate ?
>if so, which document refers to that.
>
>Thanks
>Yann

the short, simple answer is no.

a longer answer follows:

For CA certs this would be a very confusing situation, and so I do 
not expect to see this construct approved. we have enough complexity 
with path processing and the potential for a CRL to be signed by a 
key other than the one used to sign a cert beng checked against said 
CRL ...


For EE certs, I know of one instance where a lagre PKI did put two 
keys into one cert: one key for signature and one for encryption, for 
e-mail.  It was messy, but invisible to the path validation logic, so 
it was not so awful. Still, one could not use the keyusage extension 
say which key was for which purpose, which illustrates the sort of 
problems that arise when one tries to do something like this.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAH5dPt002112; Wed, 10 Nov 2004 09:05:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAH5dwv002111; Wed, 10 Nov 2004 09:05:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from citron.linagora.com (citron.linagora.com [195.68.36.78]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAH5cSn002092 for <[e-mail]>; Wed, 10 Nov 2004 09:05:38 -0800 (PST) (envelope-from [e-mail])
Received: from sgi2.linagora.com (sgi2.linagora.com [195.68.36.75]) by citron.linagora.com (Postfix) with ESMTP id 975968703; Wed, 10 Nov 2004 18:22:20 +0100 (CET)
Received: from sgi2 (sgi2 [127.0.0.1]) by localhost (Postfix) with SMTP id 208D5199B34; Wed, 10 Nov 2004 18:05:38 +0100 (CET)
Received: from tomate.linagora.lan (intranet.linagora.lan [192.168.1.3]) by sgi2.linagora.com (Postfix) with ESMTP id F3D0D199B32; Wed, 10 Nov 2004 18:05:37 +0100 (CET)
Received: by tomate.linagora.lan (Postfix, from userid 81) id 7192B7DB; Wed, 10 Nov 2004 18:19:39 +0100 (CET)
Received: from fw-lan.linagora.lan (fw-lan.linagora.lan [192.168.1.254])  by tomate.linagora.lan (IMP) with HTTP  for <[e-mail]>; Wed, 10 Nov 2004 18:19:39 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 18:19:39 +0100
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: Re: several key in same certificate
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 192.168.1.254
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

thank you for your preceding answer

> So, in all seriousness, I will assume that you're really asking about
> public keys that are used for certificate verification, and in that
> case, what you ask is certainly not possible, and it should be
> apparent if you read RFC 3280 or X.509 accurately.
>
I know RFC3280, I thought that perhaps somebody with have the idee of such a
process.

> Now, to get a real discussion going (if you want), why do you want to
> have more than one public key in your certificate?  What would they be
> used for, and most specifically, how would the appropriate key be
> selected for the operation you want to perform?
>
Because currently I have several keys (certificates) for the same entity. Each
certificate allows a particular function (different extendedKeyUsage and KeyUsage)

 I wondered whether the IETF, there a had been a reflexion, to extend a
certificate containing only one identity with several key and of the specific
extensions by keys.

An application could according to Keyusage and ExtendedKeyusage to take the good
key for for example applying a signature.

Thanks
Yannick Quenec'hdu



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAGSZBL091502; Wed, 10 Nov 2004 08:28:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAGSZ81091501; Wed, 10 Nov 2004 08:28:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from citron.linagora.com (citron.linagora.com [195.68.36.78]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAGSRLd091424 for <[e-mail]>; Wed, 10 Nov 2004 08:28:27 -0800 (PST) (envelope-from [e-mail])
Received: from sgi2.linagora.com (sgi2.linagora.com [195.68.36.75]) by citron.linagora.com (Postfix) with ESMTP id 5A88C8726; Wed, 10 Nov 2004 17:45:02 +0100 (CET)
Received: from sgi2 (sgi2 [127.0.0.1]) by localhost (Postfix) with SMTP id D6087199B31; Wed, 10 Nov 2004 17:28:19 +0100 (CET)
Received: from tomate.linagora.lan (intranet.linagora.lan [192.168.1.3]) by sgi2.linagora.com (Postfix) with ESMTP id 82CB1199B33; Wed, 10 Nov 2004 17:28:19 +0100 (CET)
Received: by tomate.linagora.lan (Postfix, from userid 81) id B7D847DB; Wed, 10 Nov 2004 17:42:20 +0100 (CET)
Received: from fw-lan.linagora.lan (fw-lan.linagora.lan [192.168.1.254])  by tomate.linagora.lan (IMP) with HTTP  for <[e-mail]>; Wed, 10 Nov 2004 17:42:20 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 17:42:20 +0100
From: [e-mail]
To: Richard Levitte - VMS Whacker <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: several key in same certificate
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 192.168.1.254
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

thank you for your preceding answer 

> So, in all seriousness, I will assume that you're really asking about
> public keys that are used for certificate verification, and in that
> case, what you ask is certainly not possible, and it should be
> apparent if you read RFC 3280 or X.509 accurately.
> 
I know RFC3280, I thought that perhaps somebody with have the idee of such a
process. 

> Now, to get a real discussion going (if you want), why do you want to
> have more than one public key in your certificate?  What would they be
> used for, and most specifically, how would the appropriate key be
> selected for the operation you want to perform?
> 
Because currently I have several keys (certificates) for the same entity. Each
certificate allows a particular function (different extendedKeyUsage and KeyUsage) 

 I wondered whether the IETF, there a had been a reflexion, to extend a
certificate containing only one identity with several key and of the specific
extensions by keys.

An application could according to Keyusage and ExtendedKeyusage to take the good
key for for example applying a signature.

Thanks
Yannick Quenec'hdu
> Cheers,
> Richard
> 
> -----
> Please consider sponsoring my work on free software.
> See http://www.free.lp.se/sponsoring.html for details.
> 
> -- 
> Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
> Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
> T: [phone] |                             | SWEDEN
>      "Price, performance, quality...  choose the two you like"
> 
> 
> 






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFxUcd082116; Wed, 10 Nov 2004 07:59:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAFxSCL082090; Wed, 10 Nov 2004 07:59:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFxOPS081963 for <[e-mail]>; Wed, 10 Nov 2004 07:59:24 -0800 (PST) (envelope-from [e-mail])
Received: from [10.0.0.51] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft6.fr.colt.net with ESMTP id iAAFxHM10841; Wed, 10 Nov 2004 16:59:17 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 16:59:11 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041018
X-Accept-Language: fr, en-us, en, ja
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: several key in same certificate
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:

>it is possible to have several key in the same certificate ?
>if so, which document refers to that.
>  
>
Hi, Yannick.

The one-to-one relation between a cert and a public key is really deeply 
grounded in x509.

The problems that makes one want to have several keys inside one cert 
should be solved by using several certificates that will be handled as 
equivalent by the PKI software, and correct any problem in the software 
that makes this not feasible. Especially restrictions on having several 
certificates with the same DN.

This rejoins what is being discussed here since a while : Two CA certs 
with the same DN from the same issuer ? They represent the same CA 
entity and must treated as such. The same applies for the end-user.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFnIiR078218; Wed, 10 Nov 2004 07:49:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAFnIx0078217; Wed, 10 Nov 2004 07:49:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFnGAP078210 for <[e-mail]>; Wed, 10 Nov 2004 07:49:17 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAAFnHD05225 for <[e-mail]>; Wed, 10 Nov 2004 16:49:17 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 10 Nov 2004 16:49:17 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAAFnHH24646 for [e-mail]; Wed, 10 Nov 2004 16:49:17 +0100 (MET)
Date: Wed, 10 Nov 2004 16:49:17 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Updated PKIX Agenda - 61st IETF
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please make the list of pending docs available on the mailing list.
As soon as you have it, immediately after the meeting would
be fine. 

Thanks



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFEtXn063634; Wed, 10 Nov 2004 07:14:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAFEtj6063633; Wed, 10 Nov 2004 07:14:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAFErho063624 for <[e-mail]>; Wed, 10 Nov 2004 07:14:54 -0800 (PST) (envelope-from [e-mail])
Received: from real2.localdomain ([192.168.2.11]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iAAFEjmc011326 for <[e-mail]>; Wed, 10 Nov 2004 10:14:45 -0500
Received: from real2.localdomain (real2.localdomain [127.0.0.1]) by real2.localdomain (8.12.8/8.12.8) with ESMTP id iAAFEjF6025229 for <[e-mail]>; Wed, 10 Nov 2004 10:14:45 -0500
Received: (from apache@localhost) by real2.localdomain (8.12.8/8.12.8/Submit) id iAAFEfmT025218 for [e-mail]; Wed, 10 Nov 2004 10:14:41 -0500
Received: from 130.129.132.131 ([130.129.132.131])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Wed, 10 Nov 2004 10:14:41 -0500
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 10:14:41 -0500
From: [e-mail]
To: [e-mail]
Subject: Updated PKIX Agenda - 61st IETF
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 130.129.132.131
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

Just thought I would pass on a few minor updates to the PKIX agenda.  I made a 
few changes in the ordering, updated the SCVP URL (it is -16, not -15), 
inserted a presentation for Lightwieght OCSP, and reflected two speaker 
changes (BaeHyo Park will present the User Interface Requirements; I will 
present Dan Brown's Elliptic Curve slides.)

Thanks,

Tim

=========================================================================


Public-Key Infrastructure (X.509) WG (pkix)

Wednesday, November 10 at 1300-1500
===================================

CHAIRS: Stephen Kent <[e-mail]>
        Tim Polk <[e-mail]>

1. WG Status and Direction

1.1 Document Status Review [Tim Polk (NIST)]

       The working group has a number of Internet-Drafts.  Many
       documents are with the ADs or in various stages of WG Last Call.
       Several others are ready for Last Call. (10 min.)

2. PKIX WG Specifications

2.1 Simple Certificate Validation Protocol (SCVP)
       Trveor Freeman (Microsoft)
         submitted new draft, available soon at
      http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-16.txt

      A new draft has been submitted with significant enhancements.  This
      presentation will highlight those changes and their rationale.
      (30 min.)

2.2 3280bis
        Tim Polk (NIST)
        (no draft)

      The co-chairs have selected a lead editor for RFC 3280bis and formed
      a design team to develop a -00 draft from a issues list complied from
      PKIX mail messages and mail to the RFC 3280 editors.  Draft -00 is
      expected late in 2004.  This presentation will focus on scope and
      process.
      (10 min.)

2.3 Discovering CRL Signer Certificates Using AIA
        Stefan Santesson (Microsoft)
        (draft after meeting)

      The ADs have approved a new PKIX document on this topic.  The first draft
      will be posted after this meeting.  This presentation will describe the
      problem and the projected -00 solution.
      (5 min.)

2.4 Issues and Recommendations on CRL Processing Rules
        Santosh Chokhani (Orion)
        (no draft)

      This presentation will provide a comprehensive review of issues in
      CRL Processing.  Issues are identified in RFCs 3280 and 2560; changes
      are proposed to resolve these issues.  Relationship with ISO's X.509
      standard is also addressed
      (15 min.)

2.5 LDAP Schemas
         David Chadwick (Univ. of Salford)
  http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-03.txt
  http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-02.txt

      The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution
      for LDAP based PKI information distribution.  New drafts of two documenta
      have been submitted since IETF 60 and are in WG Last Call.  (10 min.)

2.6 LDAP PKIX Schema Issues
      Kent Zeilenga (LDAP WG co-chair)
      (no draft)

      This presentation identify remaining issues for PKI LDAP schemas and
      (where applicable) ways to address them.
      (10 min.)

2.7 Lightweight OCSP for High Volume Environments
      Ryan Hurst (Microsoft)
      ttp://www.ietf.org/internet-drafts/
                         draft-ietf-pkix-lightweight-ocsp-profile-01.txt
      
      This document profiles OCSP for use in high volume PKI environments
      and PKI environments that require a lightweight solution to minimize
      bandwidth and client side processing.

      (10 min.)

2.8 Algorithm IDs for Elliptic Curve Cryptography in PKIX
      Tim Polk (NIST) for Daniel Brown (Certicom)
      http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-00.txt

      This document is stable and ready for progression.  The WG needs to
      select a startegy for progression: progress indpendently or in a
      revision of RFC 3279?
      (10 min.)

3. Related Specifications & Liaison Presentations

      Time allowing, liaison presentations will be accommodated to ensure the
      PKIX WG is aware of related specifications currently progressing as
      individual drafts.

    3.1 User Interface Requirements for PKIX
      BaeHyo Park (KISA)
      http://www.ietf.org/internet-drafts/draft-choi-pkix-ui-01.txt

      This document is a personal draft.  The presentation is a follow-up to
      a presentation on draft -00 at IETF-60.  Many people asked about the all
      important look and feel of the user interface; this short demonstration
      should further understanding and promote additional discussion.
      (10 min.)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEwFqO055987; Wed, 10 Nov 2004 06:58:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAEwF48055986; Wed, 10 Nov 2004 06:58:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEwExQ055941 for <[e-mail]>; Wed, 10 Nov 2004 06:58:14 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Nov 2004 14:58:09 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Wed, 10 Nov 2004 14:58:22 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Briefing on CRL Path for IETF PKIX WG Meeting
Thread-Index: AcTHCoypbgfSJ6UJQISxer5tDzY27gAKetQb
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 10 Nov 2004 14:58:09.0756 (UTC) FILETIME=[B173B1C0:01C4C735]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAAEwExQ055981
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,
 
<snip>
>Denis is making a valid remark that different CA's in the certificate
>path may certify different CRL Issuers with the same name by accident
>
>[DP: Thank you for the acknowledgment]
>
>and the algorithm doesn't account for that.
>
>[Santosh: since you intercept every mail, I guess you will notice that
>Stefan mentions that your algorithm has indeed a problem].

I didn't say that. My conclusion was that this is only applicable to indirect CRLs where IDP/CDP match is required, which mitigates this issue (unless you have a rouge CA).
 
I guess this also address the rest of your remarks.
 
 
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEaJ4c049568; Wed, 10 Nov 2004 06:36:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAEaJ7w049567; Wed, 10 Nov 2004 06:36:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEaELH049523 for <[e-mail]>; Wed, 10 Nov 2004 06:36:17 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA75672; Wed, 10 Nov 2004 15:48:08 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111015360404:824 ; Wed, 10 Nov 2004 15:36:04 +0100 
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 15:36:02 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: Julien Stern <[e-mail]>
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <006b01c4c696$64c124b0$[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 15:36:04, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 15:36:08, Serialize complete at 10/11/2004 15:36:08
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To the list,

After a direct (phone) talk with Julien, we came to the conclusion that, for 
the time being (i.e. without changing anything in the definition CRL DP 
extension), there is a *single* method which is secure for any CA (different 
from the TA) in a certification chain.

In the following, there is an attempt to define that single method.

The requirements for the CA would be:

"The CA that places a CRL DP extension in a certificate with a cRLIssuer
field present SHALL issue a CRL Issuer certificate for the DN contained
in that cRLIssuer field".

  ... while the requirements for RPs would be :

"When a CRL is not signed by the CA that has issued the certificate
to be validated, then that CRL SHALL be *verified* by the RP using
the public key of a CRL Issuer contained in a CRL Issuer certificate
that has been issued by the CA that has placed a CRL DP extension
in the certificate to be validated and where the DN contained in
the subject field from that CRL Issuer certificate SHALL match
the DN contained in the cRLIssuer field of the CRL DP extension."

Additional sentences would need to address the means to make sure
that the CRL Issuer certificate is not revoked (see my previous
e-mail on that topic).

Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEQ10F045811; Wed, 10 Nov 2004 06:26:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAEQ1EZ045810; Wed, 10 Nov 2004 06:26:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEPxPC045800 for <[e-mail]>; Wed, 10 Nov 2004 06:26:00 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAAEQ1D03964; Wed, 10 Nov 2004 15:26:01 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 10 Nov 2004 15:26:01 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAAEQ0R24333; Wed, 10 Nov 2004 15:26:00 +0100 (MET)
Date: Wed, 10 Nov 2004 15:26:00 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

IMO you can ignore my previous message concerning chapter 5.1.1.3 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAELefZ044295; Wed, 10 Nov 2004 06:21:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAELeDQ044293; Wed, 10 Nov 2004 06:21:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAELeKX044287 for <[e-mail]>; Wed, 10 Nov 2004 06:21:40 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (ASQ2-127-115.usae.bah.com [156.80.127.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iAAELftg004013 for <[e-mail]>; Wed, 10 Nov 2004 09:21:41 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Wed, 10 Nov 2004 09:21:35 -0500
Message-ID: <000401c4c730$990f7060$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAAELeKX044288
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

We are not communicating effectively.  I am sure others are not following us
either.

I will glad to discuss things with you after the PKIX meeting today, if you
are around.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Wednesday, November 10, 2004 7:40 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



Santosh,

My response with [DP: ]

As to circularity, the problem is as follows.

Let us say CA A delegates the CRL issuance to Authority B.  Your proposal
requires that A issue a certificate to B will get in the way of a CA not
issuing CRLs because if the CA does not issue CRL, how would the revocation
status of certificate A --> B be checked?

[DP: I would rephrase the problem in the following way:

Let us say CA A delegates the CRL issuance to CRL Issuer B. This requires
that CA A issues a CRL Issuer certificate to CRL Issuer B.

The question you asked is then:
"How to make sure that this CRL Issuer certificate is not revoked ?"

This depends what kind of information tha CA A places in the CRL DP
extension of the CRL Issuer certificate issued to CRL Issuer B.

There are, at least, two answers:

1) there is no cRLIssuer field in the CRL DP extension:
    this means that the CA is directly taking care of the revocation
    status of its CRL Issuers: it will issue CRLs only for the
    CRL Issuers.

2) there is no CRL DP extension at all:
    this would mean that the CA does not issue CRLs for its CRL Issuers.
    In case one of the CRL issuers would need to be revoked, it will ask
    its "normal" upper CA to revoke its own certificate. By implication,
    the CRL Issuer certificate that was issued would become invalid.]

Both approaches have advantages and disavantages.
Anyway, thank you for raising the question.

Denis





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEJh7E043470; Wed, 10 Nov 2004 06:19:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAEJhJT043469; Wed, 10 Nov 2004 06:19:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAEJght043403 for <[e-mail]>; Wed, 10 Nov 2004 06:19:42 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iAAEJSD03881; Wed, 10 Nov 2004 15:19:28 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 10 Nov 2004 15:19:28 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iAAEJRh24307; Wed, 10 Nov 2004 15:19:27 +0100 (MET)
Date: Wed, 10 Nov 2004 15:19:27 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

3280 5.1.1.3:  

   CRL checking in turn requires a separate
   certification path to be constructed and validated for the CA's CRL
   signature validation certificate. Applications that perform CRL
   checking MUST support certification path validation when certificates
                         XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   and CRLs are digitally signed with the same CA private key.  These
   applications SHOULD support certification path validation when
                               XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   certificates and CRLs are digitally signed with different CA private
   keys.

what 'certification path validation' is meant here? 
I guess the validation of the initial certificate? 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAECdu8040666; Wed, 10 Nov 2004 06:12:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAAECdaL040665; Wed, 10 Nov 2004 06:12:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAAECZlN040571 for <[e-mail]>; Wed, 10 Nov 2004 06:12:38 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 10 Nov 2004 15:12:24 +0100
Date: Wed, 10 Nov 2004 15:12:25 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: several key in same certificate
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.65
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.65 on Emacs 21.3 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Wed, 10 Nov 2004 14:00:22 +0100, [e-mail] said:

yquenechdu> it is possible to have several key in the same certificate ?
yquenechdu> if so, which document refers to that.

Well...  if we use our imagination a little bit, it's perfectly
possible to have more public keys in certificate extensions :-).
There's no document that I know covering this, as the idea came
to my mind just now, prompted by your question.  I've no idea if
someone has done something like that or not...

So, in all seriousness, I will assume that you're really asking about
public keys that are used for certificate verification, and in that
case, what you ask is certainly not possible, and it should be
apparent if you read RFC 3280 or X.509 accurately.

Now, to get a real discussion going (if you want), why do you want to
have more than one public key in your certificate?  What would they be
used for, and most specifically, how would the appropriate key be
selected for the operation you want to perform?

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAACkb2s005669; Wed, 10 Nov 2004 04:46:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAACkbvw005668; Wed, 10 Nov 2004 04:46:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from citron.linagora.com (citron.linagora.com [195.68.36.78]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAACkZqD005562 for <[e-mail]>; Wed, 10 Nov 2004 04:46:36 -0800 (PST) (envelope-from [e-mail])
Received: from sgi2.linagora.com (sgi2.linagora.com [195.68.36.75]) by citron.linagora.com (Postfix) with ESMTP id 5C8D68703 for <[e-mail]>; Wed, 10 Nov 2004 14:03:04 +0100 (CET)
Received: from sgi2 (sgi2 [127.0.0.1]) by localhost (Postfix) with SMTP id B7432199B25 for <[e-mail]>; Wed, 10 Nov 2004 13:46:22 +0100 (CET)
Received: from tomate.linagora.lan (intranet.linagora.lan [192.168.1.3]) by sgi2.linagora.com (Postfix) with ESMTP id 566F5199B24 for <[e-mail]>; Wed, 10 Nov 2004 13:46:22 +0100 (CET)
Received: by tomate.linagora.lan (Postfix, from userid 81) id 71A367DB; Wed, 10 Nov 2004 14:00:22 +0100 (CET)
Received: from fw-lan.linagora.lan (fw-lan.linagora.lan [192.168.1.254])  by tomate.linagora.lan (IMP) with HTTP  for <[e-mail]>; Wed, 10 Nov 2004 14:00:22 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 14:00:22 +0100
From: [e-mail]
To: [e-mail]
Subject: several key in same certificate
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 192.168.1.254
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, 

it is possible to have several key in the same certificate ?
if so, which document refers to that.

Thanks
Yann



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAACe6sc002209; Wed, 10 Nov 2004 04:40:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAACe6Og002208; Wed, 10 Nov 2004 04:40:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAACe2kp002099 for <[e-mail]>; Wed, 10 Nov 2004 04:40:04 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA85112; Wed, 10 Nov 2004 13:51:50 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111013394651:755 ; Wed, 10 Nov 2004 13:39:46 +0100 
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 13:39:45 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'pkix'" <[e-mail]>
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <002d01c4c668$bf7ee780$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 13:39:46, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 13:39:48, Serialize complete at 10/11/2004 13:39:48
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

My response with [DP: ]

As to circularity, the problem is as follows.

Let us say CA A delegates the CRL issuance to Authority B.  Your proposal
requires that A issue a certificate to B will get in the way of a CA not
issuing CRLs because if the CA does not issue CRL, how would the revocation
status of certificate A --> B be checked?

[DP: I would rephrase the problem in the following way:

Let us say CA A delegates the CRL issuance to CRL Issuer B.
This requires that CA A issues a CRL Issuer certificate to CRL Issuer B.

The question you asked is then:
"How to make sure that this CRL Issuer certificate is not revoked ?"

This depends what kind of information tha CA A places in the CRL DP
extension of the CRL Issuer certificate issued to CRL Issuer B.

There are, at least, two answers:

1) there is no cRLIssuer field in the CRL DP extension:
    this means that the CA is directly taking care of the revocation
    status of its CRL Issuers: it will issue CRLs only for the
    CRL Issuers.

2) there is no CRL DP extension at all:
    this would mean that the CA does not issue CRLs for its CRL Issuers.
    In case one of the CRL issuers would need to be revoked, it will ask
    its "normal" upper CA to revoke its own certificate. By implication,
    the CRL Issuer certificate that was issued would become invalid.]

Both approaches have advantages and disavantages.
Anyway, thank you for raising the question.

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA9uYVp085145; Wed, 10 Nov 2004 01:56:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA9uYFp085144; Wed, 10 Nov 2004 01:56:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA9uU8X085061 for <[e-mail]>; Wed, 10 Nov 2004 01:56:31 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA81482; Wed, 10 Nov 2004 11:08:18 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111010561418:653 ; Wed, 10 Nov 2004 10:56:14 +0100 
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 10:56:13 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <006b01c4c696$64c124b0$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 10:56:14, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 10:56:15, Serialize complete at 10/11/2004 10:56:15
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

My responses with [DP1:]

===================================================================

Denis,

None of your comment seem to object to the path matching algorithm.

Please see specific responses below.

Santosh,

 > Denis,
 >
 > When you look at 3280 and add what I propose, what do you see is
 > missing?

Since you asked ... I will explain what is wrong in your slides.

Slide 5. The statement " A CA is defined by name alone" is wrong. A CA is
not simply defined by a name alone. A name, for X.509, is always relative to
the CA which has issued it. So the "clarification' to say that a CA is
unambiguously defined by name is wrong. Then since the other slides are
based on that wrong assumption, they are wrong as well.

[SC: Here is the quote from X.509 "NOTE 1 - Although the CAs are
unambiguously defined by a distinguished name in the DIT, this does not
imply that there is any relationship between the organization of the CAs and
the DIT."]

[DP1:  ... and this tells you exactly what I said]

Slide 7:  There is no "need to account for multiple CAs with the same name".
This formulation is pretty bad. A CA must provide different names to two
different entities. Since a CA name is relative to another CA name space,
there cannot be two CAs with the same name.

[SC: There is requirement or mechanism that ensures that a relying party
with multiple trust anchors will not encounter two CAs with the same name.
If a relying party has two trust anchors A and B and there are two distinct
companies with the same name C, it is possible that one C is certified via A
and another via B.]

[DP1: The assumption : "there is requirement or mechanism that ensures
that a relying party with multiple trust anchors will not encounter
two CAs with the same name" is fully wrong ! The same name may be found.]

Slide 8: The statement : "There can be more than one CA with the same name"
is wrong. Once again, a (CA) name is always relative to a CA name space.

[SC: There is requirement or mechanism that ensures that a relying party
with multiple trust anchors will not encounter two CAs with the same name.
If a relying party has two trust anchors A and B and there are two distinct
companies with the same name C, it is possible that one C is certified via A
and another via B.]

[DP1: See above]

Slide 8: The statement "starting from a TA, the relying party can match the
CA names in [ ] the CRL certification paths" is wrong as well. There is no
such notion of a "CRL certification path".

[SC: When you get a CRL by the Issuer name of the CA and the signature does
not verify, you will need to develop a certification path for the CRL.  Your
other choices are: do not check revocation information, or take the CRL on
faith even though signature has not been verified.  I do not consider either
of these choices in compliance with 3280.  Feel free to provide other
choices that do not entail building a certification path for the CRL.]

[DP1: It is quite the reverse. You got a CRL and you need to find out
if it is signed by the right key. You have to go down the tree and
not up the tree to make the right verification. You need to know
if the CA has nominated or not the candidate CRL Issuer, make sure
that the nomination is correct and has not been revoked. None of the
choices you mention are assumptions that I am making]

[SC: From the long discourse below, it seems that you are focused only on
indirect CRL issuance problem.  The path matching algorithm tries to solve
that as well as when the CA has used different keys to sign certificates and
CRL (e.g., due to key roll over or in general using two keys to sign the two
objects.]

[DP1: Before geeting into complicated cases like key rollover, we need
to make sure that the simple case where the CA is not signing the CRLs
for a given certificate is correctly addressed. There is no notion of
"CRL certification path"]

As indicated in RFC 3280, a CRL issuer is an optional
system to which a CA delegates the publication of CRLs.
This sentence is correct, but vague. (X.509 does not provide
a clear definition of what a CRL Issuer is).

Page 43 from RFC 3280: "The cRLIssuer identifies the entity
who signs and issues the CRL. If present, the cRLIssuer MUST contain at
least one an X.500 distinguished name (DN).

A CA will thus identify the DN of the CRL Issuer in the cRLIssuer field from
a CRL distribution point extension.

[SC: So far, I agree and the briefing is aligned with this]

[DP1: I am glad you agree with this, but I would not say that your
briefing is aligned with this]

That DN needs to be compared with a subject DN from a CRL Issuer
certificate, i.e. a certificate which has the cRLSign bit set (and that has
that DN as the subject name).

[SC: cRLSign bit is out side the scope of path matching.  All 3280 checks
for CRL imply.  As to name matching.  As to the name match check, that is
what bullet 1 on slide 13 does.]

[DP1: path matching is a mandatory feature, other tests need to be done;
in particular whether it is a CRL Issuer certificate. Only a test on
the keyUsage extension may provide you with this guarantee. Name matching
is more complicated that a DN comparison. DN comparison can only be made
if you know that th DNs are assigned by the same CA].

The question is then simply : how can a RP know that that CRL Issuer
certificate has been issued by the right CA ?

A simple answer to that question is to say that the CA that has placed the
CRL DP extension must be the one that has issued the CRL Issuer certificate.

[SC: This is one model.  There are other model where the CA need not issue a
certificate to the indirect CRL issuer]

[DP1: This is indeed the simpler model which SHALL be at least supported.
I envisaged another model, and it may be debatable if it should be
supported or not. I do do envisage more than two models, otherwise
we have a trillon cases where CRL Issuer issues revocation status
information for certificates and do not have received any delegation
of authority for that]

This means something very important. The TA used to verify
the CRL Issuer certificate is the same as the one used to verify the
certificate to be validated. All intermediate CAs are identical.

[SC: The path matching algorithm accounts for this.  Since there is no
requirement for the certificate issuing CA to directly issue a certificate
to the indirect CRL issuer, the matching algorithm may terminates
prematurely.]

[DP1: the problem is that the algorithm allows much more that this !
Then we can debate around the sentence you used above: "since there is
no requirement for the certificate issuing CA to directly issue
a certificate to the indirect CRL issuer". The big question is still
how the RP can know which CA is *allowed to nominate* the CRL Issuer.
As said earlier, the simplest model is precisely that the certificate
issuing CA directly issues a certificate to the indirect CRL issuer]

This rule can easily be interpreted by a relying party since
it needs first to have the certification path.

This is not the case for the algorithm you proposed, where different TAs are
used on one side to validate the certificate to be validated and on the
other side the CRL Issuer certificate.

[SC: The algorithm requires that the DN representing the same TA be used for
both paths. (See bullet 1 on slide 12.  The reason the same key (and hence
TA) is not used is to accommodate the case of the TA having been re-keyed.]

[DP1: Your statement saying that "the algorithm requires that the DN
representing the same TA be used for both paths" is wrong. For TAs what
is important is both the value of the public key and of the DN, but not
the value of the DN alone. In addition, this is not an assumption made
in your slides]

In this algorithm, two CRL Issuers with the same DN might appear in
different certification paths. So multiple CRL Issuer names could match the
criteria. The algorithm you proposed is flawed.

[SC: Can you give a more concrete example of it.  I know that the rules are
liberal for indirect CRL issuer since I do not believe that direct
delegation model is required]

[DP1: Quite easy.
Let us consider a certification chain: TA -> CA1 -> CA2 -> CA3.
CA1 can nominate a CRL Issuer with the following DN:
C0=US, DN="Gold CRLIssuer".
CA3 can also nominate a CRL Issuer with the following DN:
C0=US, DN="Gold CRLIssuer"].

[DP1: I believe that this long thread is sufficient to convince the chairs
that there is indeed yet not a consensus on that topic, and that instead
of slides we would need to agree on text addition in 3280bis. However,
before this, we need to agree on the concepts. I would have liked to
have corridor discussions with you on that topic before the PKIX meeting,
however I can't make it. I would think that a conference call, with a
moderator, would be useful if you are still not convinced by the above
arguments. Now, maybe someone else, in a face to face meeting before
or after the PKIX meeting could explain you better that I can do why
we have no consensus].

Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA9oZkn081463; Wed, 10 Nov 2004 01:50:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA9oZus081462; Wed, 10 Nov 2004 01:50:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA9oUYQ081371 for <[e-mail]>; Wed, 10 Nov 2004 01:50:32 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA48552; Wed, 10 Nov 2004 11:02:10 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111010500750:650 ; Wed, 10 Nov 2004 10:50:07 +0100 
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 10:50:07 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Santosh Chokhani <[e-mail]>, [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 10:50:07, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 10:50:09, Serialize complete at 10/11/2004 10:50:09
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

My comments with [DP: ]

( ... text relative to Julien deleted)

Denis is making a valid remark that different CA's in the certificate
path may certify different CRL Issuers with the same name by accident

[DP: Thank you for the acknowledgment]

and the algorithm doesn't account for that.

[Santosh: since you intercept every mail, I guess you will notice that 
Stefan mentions that your algorithm has indeed a problem].

The question is if this is a valid threat or not.

Both Denis and Julien's scenarios require intentional malicious
behaviour of the CRL issuer or the CDP and the IDP wouldn't match (the
storage location pointer would differ).

[DP: No. In my scenario there is no intentional malicious
behaviour of the CRL issuer. Anybody can make an interception attack an 
substitute one CRL by another].

Both scenarios also require the attacker to convince the RP to NOT
obtain the correct CRL through the CDP pointer and instead accept the
rough CRL from other source OR it requires the attacker to hack the
server holding the real CRL and replace the real CRL with the rough CRL.

[DP: No. There is no notion of a "rough CRL". Both CRLs are real CRLs but 
issued by two CAs which happened to have the same DN (but these DNs have 
been given by two different CAs)]

----------------

In Denis scenario I would suggest that we can exclude presence of a
rouge CA in the original certificate path, because if the original cert
path has a rouge CA, then all bets are off anyway.

[DP: Your suggestion would not work. It is not possible to exclude the fact 
that two CAs in a certification path may issue the same DN to two different 
CRL Issuers: when a CA is naming a CRL Issuer, it does not need to check if 
that name has been given or not by another CA from the chain.]

( ... remaining of text relative to Julien deleted)

Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA9nIFn080528; Wed, 10 Nov 2004 01:49:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA9nIZI080527; Wed, 10 Nov 2004 01:49:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA9nB59080354 for <[e-mail]>; Wed, 10 Nov 2004 01:49:15 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA09770; Wed, 10 Nov 2004 11:00:48 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004111010484573:648 ; Wed, 10 Nov 2004 10:48:45 +0100 
Message-ID: <[e-mail]>
Date: Wed, 10 Nov 2004 10:48:45 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <002001c4c67a$1cbe4d80$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 10:48:45, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/11/2004 10:48:48, Serialize complete at 10/11/2004 10:48:48
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

This was a response to Tom. It would be fair if you let Tom some time to 
respond to it.

See my two responses below.

> Denis.
> 
> See responses in-line in [SC:]
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Denis Pinkas
> Sent: Tuesday, November 09, 2004 9:18 AM
> To: Tom Gindin
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Tom,
> 
>>        Denis:
> 
>>Would a reasonable formulation of this rule be that a CRL Issuer
>>certificate governing the certificates of a given CA must have been 
>>directly issued by one of the certificates in the chain being verified 
>>(including the CA's own certificate), by the trust anchor for that chain, 
>>or by a certificate which is a rollover of one of the certificates in the 
>>first two grouips?  
> 
> 
> No. This would not be a good formulation, since two different CAs from the
> chain could choose the same DN to designate different CRL Issuers.
> 
> [SC: For indirect CRL to work, it is a fair assumption that two CAs will not
> share a name in the trust path nominated by the certificate issuing CA]

[DP: there is no such "fair assumption"].

> The RP needs to have an unambiguous way to know exactly which CA from the
> chain is the one which has nominated the CRL Issuer.
> 
> [SC: I suspect you mean that the relying party needs to have an unambiguous
> way to know exactly which authority was nominated as the indirect CRL Issuer
> by the certificate issuer.  

[DP: Your suspicion is incorrect. This is not what I said. Another way to 
express the same point would be:

"the relying party needs to have an unambiguous way to know exactly which CA 
has nominated the CRL Issuer, whose DN is present in the cRLIssuer field 
from the CRL DP extension".]

[SC: What you say does not make sense.]

See above.

Denis

> Denis
> 
> 
>>For this purpose, a certificate is a rollover of its
>>issuer certificate if it is self-issued but not self-signed, and the 
>>relationship is associative (i.e. if A is a rollover of B which is a 
>>rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D has
> 
> 
>>a CRL issuer and the path to D goes A (the anchor) to B to C to D, the CRL
> 
> 
>>issuer certificate may be issued by A, B, C, or D, or by B' in the case 
>>where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued 
>>through any other anchor nor through any CA whose DN is not in the path. 
>>Only one further liberalization of this rule might make sense, which is 
>>that C' would be considered a rollover of C on a path where C is issued by
> 
> 
>>B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels that 
>>this is safe?
>>        The good news about this heuristic is that it can be coded.  I 
>>think any of these variants resist Julien's attack, under the fairly 
>>reasonable assumptions that no CA issues certificates to bogus entities 
>>with its own name and that any CA which directly issued your 
>>cross-certificate and wants to have a CRL issuer masquerade as that CA can
> 
> 
>>do so by issuing a bogus CA cert just as easily as by issuing a bogus CRL 
>>Issuer one.
>>
>>                Tom Gindin




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA3MZr8048249; Tue, 9 Nov 2004 19:22:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA3MZPu048248; Tue, 9 Nov 2004 19:22:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA3MYLk048242 for <[e-mail]>; Tue, 9 Nov 2004 19:22:34 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iAA3Me4a025237; Tue, 9 Nov 2004 22:22:40 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'Tom Gindin'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 22:22:34 -0500
Message-ID: <001a01c4c6d4$88a68f80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAA3MZLk048243
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

See responses in-line in [SC:]

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 9:08 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting


      Santosh:

      I apologize for not having realized exactly how close the effects of
your algorithm and mine actually are.  I started from some of Denis'
formulations without having fully analyzed your initialization part 3, and
rederived something very close to yours.  In practice, the difference
between the matching algorithms mainly reduces to the difference between
"the subject and issuer DN's of the non-self-issued certificates must match"
and "must be the same certificate or a rollover thereof", and your
formulation allows a superior CA to rekey its subordinate without any
rollovers while mine forbids that.

[SC: My algorithm permits roll over certificates.  I simply ignore them.  I
think a more secure and practical model is a CA getting a certificate from
parent when it re-keys.  There is no mechanism in X.509 that is both simple
and secure to promulgate revocation status of self-issued certificates.
Thus, it is important to account for a practice that is more secure.]

  Of course, I'm not really sure why the issuer DN's need to be compared
separately, since Issuer (N) must match Subject (N-1) and the subjects are
being compared.

[SC: Defense in depth.  I thought about comparing one sets of names only
since X.509 and 3280 requires name chaining during path validation.  But, I
also know that some well known and well used products do not do it.  I see
this an opportunity to reinforce the name chaining need.]

      More substantively, I don't understand why it's permissible in your
algorithm for NCert to be NCRL-2 or NCRL-3, which corresponds to a
subordinate CA issuing its superior's CRL Issuer certificate.  In mine,
NCert may never be less than NCRL.

[SC: If you note on slide 11, for direct CRL, Ncert = NCRL +1.  For indirect
CRL, we should add a rule that NCRL < NCERT (after NCRL has been decremented
by 1 in bullet 2.  I have added that.]

  This difference does allow an attack against yours which doesn't work
against mine, but it is not an "unrelated CA" attack.  Instead, it's a case
of a subordinate CA of the EE's issuer issuing a CRL Issuer certificate with
the same DN (but a different key) as that used in the EE certificate.
      In view of the minimal effective differences, it is probably
reasonable to consider my technique an optimization of yours in that it
doesn't need to perform independent path building.  You can easily enough
get rid of the difference cited in my second paragraph by replacing your MIN
step by "Verify that NCert >= NCRL", and using NCRL as the upper bound of
the loop.

            Tom Gindin




 

                      "Santosh

                      Chokhani"                To:       <[e-mail]>

                      <chokhani@orionse        cc:

                      c.com>                   Subject:  RE: Briefing on CRL
Path for IETF PKIX WG Meeting                             
                      Sent by:

                      owner-ietf-pkix@m

                      ail.imc.org

 

 

                      11/09/2004 04:10

                      PM

 






Tom,

Can you explain the following from your post in relation of CRL path
matching and how you mitigate it and CRL path matching does not.  I quote
you:

"In replying to Santosh, you have discussed attacks which come from
unrelated CA's as the primary security threat associated with CRL issuers. I
agree with that, and have blocked those."

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Gindin
Sent: Tuesday, November 09, 2004 1:40 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



        Denis:

        It is indeed possible for two CA's to choose the same CRL issuer DN,
while meaning two distinct entities.  However, what are the consequences?
In one case, a CA which has certified a subordinate CA can "take over" the
issuer ID of that subordinate (outside hierarchies, only RP's who are
trusting the CA through the issuer of that cross-certificate are affected).
In the other, a CA which originally delegated revocation to its superior can
reclaim it.  Which of these is an attack?
        I don't know why the RP needs a rule which declares "a CRL issuer
must be certified by the CA whose certificates it is issuing a CRL for", and
which prohibits subordinate CA's from having their hierarchical superior
issue CRL's for them.  In replying to Santosh, you have discussed attacks
which come from unrelated CA's as the primary security threat associated
with CRL issuers.  I agree with that, and have blocked those.
        BTW, Santosh is right that a certificate issued to a CRL Issuer by a
CA which ordinarily delegates CRL's to that issuer is not practically
revocable by CRL.  However, IMO a certificate may be useful even if a
revocation check on it is not feasible.  Much client software checks
certificate chains without checking revocation, being satisfied with the
certification that "this key pair was once possessed by the subject". This
applies equally to self-issued certificates.
        Before declaring that a rule should (or should not) prevent the use
of a superior CA's CRL Issuer to produce CRL's for a subordinate CA, we
should probably find out if anybody actually does that.  I hope that nobody
actually has sibling CA's producing their CRL's.

                Tom Gindin






Denis Pinkas <[e-mail]>
11/09/2004 09:17 AM

        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     [e-mail]
        Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting


Tom,

>         Denis:

> Would a reasonable formulation of this rule be that a CRL Issuer 
> certificate governing the certificates of a given CA must have been 
> directly issued by one of the certificates in the chain being verified 
> (including the CA's own certificate), by the trust anchor for that
chain,
> or by a certificate which is a rollover of one of the certificates in
the
> first two grouips?

No. This would not be a good formulation, since two different CAs from the
chain could choose the same DN to designate different CRL Issuers.

The RP needs to have an unambiguous way to know exactly which CA from the
chain is the one which has nominated the CRL Issuer.

Denis

> For this purpose, a certificate is a rollover of its
> issuer certificate if it is self-issued but not self-signed, and the 
> relationship is associative (i.e. if A is a rollover of B which is a 
> rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D
has
> a CRL issuer and the path to D goes A (the anchor) to B to C to D, the
CRL
> issuer certificate may be issued by A, B, C, or D, or by B' in the 
> case where B is the issuer of B' and DN(B) = DN(B'); but it may not be 
> issued

> through any other anchor nor through any CA whose DN is not in the 
> path.

> Only one further liberalization of this rule might make sense, which 
> is that C' would be considered a rollover of C on a path where C is 
> issued
by
> B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels 
> that

> this is safe?
>         The good news about this heuristic is that it can be coded.  I 
> think any of these variants resist Julien's attack, under the fairly 
> reasonable assumptions that no CA issues certificates to bogus 
> entities with its own name and that any CA which directly issued your 
> cross-certificate and wants to have a CRL issuer masquerade as that CA
can
> do so by issuing a bogus CA cert just as easily as by issuing a bogus
CRL
> Issuer one.
>
>                 Tom Gindin
>
>
>
>
>
>
> Denis Pinkas <[e-mail]>
> Sent by: [e-mail]
> 11/05/2004 10:04 AM
>
>         To:     Santosh Chokhani <[e-mail]>
>         cc:     [e-mail]
>         Subject:        Re: Briefing on CRL Path for IETF PKIX WG
Meeting
>
>
>
> Santosh,
>
>
>>Denis,
>>
>>See responses in-line in [SC:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, November 04, 2004 12:40 PM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>Santosh,
>>
>>See responses in-line in [DP:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Wednesday, November 03, 2004 9:48 AM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>Santosh,
>>
>> > Denis,
>>
>> > The matching algorithm proposed checks/compares the ancestors.
>>
>>The matching algorithm is missing to say "who" trusts "somebody" for
>
> "what".
>
>>Unless this is clearly said, there is no trust possible and thus no 
>>algorithm possible.
>>
>>[SC: The two paths needs to be verified in accordance with 3280 in 
>>order

>
> to
>
>>establish trust]
>>
>>[DP: the certification path needs to be verified according to RFC 
>>3280.
>
> The
>
>>problem is that RFC 3280 does not tell how to verify that the CRL 
>>comes from the right CRL Issuer. Your assumption that the "two paths 
>>needs to
>
> be
>
>>verified in accordance with 3280 in order to establish trust" is thus 
>>incorrect].
>>
>>[SC: When you augment 3280 with the algorithm I proposed, that takes
>
> care of
>
>>it.  It goes without saying that 3280 needs to be augmented with the 
>>algorithm]
>
>
> This is exactly what I disagree with.
>
> Let us talk about the key issue. The question is: how can a RP 
> (relying
> party) know that, for a given end-user certificate, the CRL he got is 
> indeed issued by the right CRL Issuer ?
>
> In the following discussion, I am only considering the case where the
CRL
> Issuer is *not* the CA (this CA is called CA 1).
>
> CA 2 is a CA that has issued a CA certificate to CA 1.
>
> The text is currently so vague that different models are indeed 
> theoritically possible. In particular:
>
>   a) the CRL Issuer is nominated by CA 1 that has issued
>      the end-user certificate. This case would make sense
>      when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>      that role to one or more CRL Issuers. This means that
>      a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
>
>   b) the CRL Issuer is nominated by CA 2 that has issued a CA
>      certificate to CA 1. This case would make sense when CA 2
>      has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>      certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>      then only choose a CRL Issuer that has been granted
>      the authorization to issue CRLs by CA 2.
>
> I wonder if I understand correctly the model you proposed, but (please 
> correct if wrong) you have a set of trust points to verify the 
> certification chain, and another set of trust points to verify what 
> you call a certification path for the CRL Issuer.
>
> There would be many problems with such a model to define correctly 
> validation policies, since the two chains would be unrelated and any 
> CA from that chain could nominate CRL Issuers used by any CA.
>
> In options a) and b) mentioned above, a single trust point is used to 
> validate both the certification chain and the CRL Issuer.
>
> In any case, we need to clarify this topic in 3280bis, whatever the 
> clarification will be.
>
>
>>This algorithm is nothing more than formalism of something you agreed 
>>to in 2003 on this list.
>>
>>I don't think so.
>>
>>[SC: Go back to September 2003 archive of your response to my post and
>
> tell
>
>>me what is not covered]
>>
>>[DP: You would need to be more precise and provide me an extract of 
>>what

>
> you
>
>>refer to]
>>
>>[SC: It was short string of e-mails on the subject matter in September
>
> 2003.
>
> Hum !!! Hum !!!
> Do not mention "free" assertions when you are not sure about.
>
> Denis
>
>
>>I am sure you can find it from the archives.  It may be overcome by
>
> events
>
>>since your recent postings show that you agree with me]
>>
>>Denis
>
>
>
>
>
>
>









Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA3BeBT043457; Tue, 9 Nov 2004 19:11:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA3BeKw043456; Tue, 9 Nov 2004 19:11:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA3BdLK043448 for <[e-mail]>; Tue, 9 Nov 2004 19:11:39 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iAA3Bj4a017537 for <[e-mail]>; Tue, 9 Nov 2004 22:11:45 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 22:11:39 -0500
Message-ID: <001701c4c6d3$02170a40$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAA3BdLK043450
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

The basic point is that there are many ways to compromise the security of
X.509 once a relying party trusts a rogue CA.  Path matching algorithm will
not fix that.  Whether you use the algorithm or not, these problems remain.
If you do not use the algorithm, there are attacks that will not be
mitigated.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Tuesday, November 09, 2004 8:17 PM
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



Santosh,

comments in line with [JS]

On Tue, Nov 09, 2004 at 03:43:52PM -0500, Santosh Chokhani wrote:
> 
> Stefan,
> 
> See responses in line in [SC:}
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Tuesday, November 09, 2004 2:06 PM
> To: Denis Pinkas; Santosh Chokhani; Julien Stern
> Cc: [e-mail]
> Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> It seams that we have a problem with agreeing on the security 
> assumptions more than on the technical matters.
> 
> I recognize that Julien's scenario is a valid remark, at least in 
> theory. The point Julien is that there is a problem if an attacker 
> that has obtained a rouge CA under a valid root actually could fool an 
> RP software to accept the rouge path to the target certificate. IF the 
> RP accept the path over the rouge CA then that rouge CA could also 
> defeat the proposed algorithm.
> 
> The question is just if this is a valid threat or not.
> 
> Denis is making a valid remark that different CA's in the certificate 
> path may certify different CRL Issuers with the same name by accident 
> and the algorithm doesn't account for that.
> 
> [SC: This is only an issue in the context of indirect CRL.  For the 
> direct CRL issuer, the algorithm will disambiguate the issues].
> 
> The question is if this is a valid threat or not.
> 
> Both Denis and Julien's scenarios require intentional malicious 
> behaviour of the CRL issuer or the CDP and the IDP wouldn't match (the 
> storage location pointer would differ).
> 
> [SC: I have not seen a scenario from Denis.  I have a different and 
> simple take on Julien's scenario.

> First, Julien's scenario will not come about for
> the relying parties who do not trust the rogue CA.

[JS: this is true, but the rogue CA could be anywhere in the hierarchy of
any trusted anchor. Also, if you assume no CA rogue CA is trusted, your
algorithm mostly only simplifies path construction.]

> Second, the algorithm
> makes sure that who ever is the certificate issuer from the relying 
> party perspective can only revoke the certificate.

[JS: the whole point being that it is simple to conterfeit the certicate
issuer from the relying party perspective. Trust in X509 in going down, not
up. This is how the attck works.]

> Third, even if the same key
> was used, in Julien's scenario relying party can always be fooled into 
> using bad revocation information along with bogus certificate minted 
> by the rogue CA.]

[JS: it might be possible to perform an attack even when the same key is
used, but my current scenario does not. The attack would be much more
complex. It do not see to what scenario you refer to.]


> 
> Both scenarios also require the attacker to convince the RP to NOT 
> obtain the correct CRL through the CDP pointer and instead accept the 
> rough CRL from other source OR it requires the attacker to hack the 
> server holding the real CRL and replace the real CRL with the rough 
> CRL.
> 
> ----------------
> 
> In Denis scenario I would suggest that we can exclude presence of a 
> rouge CA in the original certificate path, because if the original 
> cert path has a rouge CA, then all bets are off anyway.
> 
> This leaves us with Julien's scenario.
> 
> -----------------
> 
> So the main question is which of these threats that is in scope or out 
> of scope
> 
> 1) Presence of a trusted Rouge CA that is NOT part of the original 
> certificate path.
> 
> 2) The ability of the attacker to fool the RP to pick a rouge path and 
> rouge CRL where the IDP and CDP match.
> 
> Questions/remarks:
> - If both these threats are in scope then Julien's scenario is also 
> valid.
> - If there threats are out of scope, then what threat remains that
requires
> Santosh algorithm in the first place?
> 
> [SC: The threat that the algorithm mitigates is one of accidental 
> error and one of malfeasance.  Let me illustrate.  Let us say that 
> both Microsoft and VeriSign roots are in a relying party trust anchor  
> set.  Let us say that that we have Microsoft --> Orion CA --> 
> Chokhani.  Chokhani is an end entity with serial number 10.  Let us 
> also say that VeriSign has certified another Orion.  So, we have 
> VeriSign -->  Orion CA --> CRL X.  Now, some one can compromise 
> Chokhani key and play the CRL X  that does not contain 10 and make the 
> relying party access Chokhani certificate which actually has been 
> compromised.  In this case, all four CAs and Chokhani are playing 
> nice, but some one else just ate our lunch.]

[JS: it seems to me that you assume that you can force the use of a CRL over
an other for the attack you described work.

So the difference between our threat models, security wise, is that you
assume all CA are honests and never compromised but can make mistakes, while
I assume a CA can act in a dishonest way. It that correct ?]

> 
> I'm still pro Santosh algorithm since it limits complexity in path 
> processing but it would be good to know if there are any threats that 
> require Santosh algorithm which remains if at least problem 1 above is 
> out of scope.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA29hRc019013; Tue, 9 Nov 2004 18:09:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA29hmA019012; Tue, 9 Nov 2004 18:09:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA29gRR019006 for <[e-mail]>; Tue, 9 Nov 2004 18:09:42 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id iAA29mT0426954 for <[e-mail]>; Tue, 9 Nov 2004 21:09:48 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAA29mZY251100 for <[e-mail]>; Tue, 9 Nov 2004 21:09:48 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAA29l2f027457 for <[e-mail]>; Tue, 9 Nov 2004 21:09:47 -0500
Received: from d01mc062.pok.ibm.com (d01mc062.pok.ibm.com [9.56.227.225]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iAA29lfn027440; Tue, 9 Nov 2004 21:09:47 -0500
In-Reply-To: <007c01c4c6a0$8118ce10$[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
To: "Santosh Chokhani" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <[e-mail]>
From: Tom Gindin <[e-mail]>
Date: Tue, 9 Nov 2004 21:07:38 -0500
X-MIMETrack: Serialize by Router on D01MC062/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 11/09/2004 21:09:46
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Santosh:

      I apologize for not having realized exactly how close the effects of
your algorithm and mine actually are.  I started from some of Denis'
formulations without having fully analyzed your initialization part 3, and
rederived something very close to yours.  In practice, the difference
between the matching algorithms mainly reduces to the difference between
"the subject and issuer DN's of the non-self-issued certificates must
match" and "must be the same certificate or a rollover thereof", and your
formulation allows a superior CA to rekey its subordinate without any
rollovers while mine forbids that.  Of course, I'm not really sure why the
issuer DN's need to be compared separately, since Issuer (N) must match
Subject (N-1) and the subjects are being compared.
      More substantively, I don't understand why it's permissible in your
algorithm for NCert to be NCRL-2 or NCRL-3, which corresponds to a
subordinate CA issuing its superior's CRL Issuer certificate.  In mine,
NCert may never be less than NCRL.  This difference does allow an attack
against yours which doesn't work against mine, but it is not an "unrelated
CA" attack.  Instead, it's a case of a subordinate CA of the EE's issuer
issuing a CRL Issuer certificate with the same DN (but a different key) as
that used in the EE certificate.
      In view of the minimal effective differences, it is probably
reasonable to consider my technique an optimization of yours in that it
doesn't need to perform independent path building.  You can easily enough
get rid of the difference cited in my second paragraph by replacing your
MIN step by "Verify that NCert >= NCRL", and using NCRL as the upper bound
of the loop.

            Tom Gindin




                                                                                                                                       
                      "Santosh                                                                                                         
                      Chokhani"                To:       <[e-mail]>                                                           
                      <chokhani@orionse        cc:                                                                                     
                      c.com>                   Subject:  RE: Briefing on CRL Path for IETF PKIX WG Meeting                             
                      Sent by:                                                                                                         
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      11/09/2004 04:10                                                                                                 
                      PM                                                                                                               
                                                                                                                                       





Tom,

Can you explain the following from your post in relation of CRL path
matching and how you mitigate it and CRL path matching does not.  I quote
you:

"In replying to Santosh, you have discussed attacks which come from
unrelated CA's as the primary security threat associated with CRL issuers.
I agree with that, and have blocked those."

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Gindin
Sent: Tuesday, November 09, 2004 1:40 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



        Denis:

        It is indeed possible for two CA's to choose the same CRL issuer
DN, while meaning two distinct entities.  However, what are the
consequences?  In one case, a CA which has certified a subordinate CA can
"take over" the issuer ID of that subordinate (outside hierarchies, only
RP's who are trusting the CA through the issuer of that cross-certificate
are affected).  In the other, a CA which originally delegated revocation
to its superior can reclaim it.  Which of these is an attack?
        I don't know why the RP needs a rule which declares "a CRL issuer
must be certified by the CA whose certificates it is issuing a CRL for",
and which prohibits subordinate CA's from having their hierarchical
superior issue CRL's for them.  In replying to Santosh, you have discussed
attacks which come from unrelated CA's as the primary security threat
associated with CRL issuers.  I agree with that, and have blocked those.
        BTW, Santosh is right that a certificate issued to a CRL Issuer by
a CA which ordinarily delegates CRL's to that issuer is not practically
revocable by CRL.  However, IMO a certificate may be useful even if a
revocation check on it is not feasible.  Much client software checks
certificate chains without checking revocation, being satisfied with the
certification that "this key pair was once possessed by the subject". This
applies equally to self-issued certificates.
        Before declaring that a rule should (or should not) prevent the
use of a superior CA's CRL Issuer to produce CRL's for a subordinate CA,
we should probably find out if anybody actually does that.  I hope that
nobody actually has sibling CA's producing their CRL's.

                Tom Gindin






Denis Pinkas <[e-mail]>
11/09/2004 09:17 AM

        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     [e-mail]
        Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting


Tom,

>         Denis:

> Would a reasonable formulation of this rule be that a CRL Issuer
> certificate governing the certificates of a given CA must have been
> directly issued by one of the certificates in the chain being verified
> (including the CA's own certificate), by the trust anchor for that
chain,
> or by a certificate which is a rollover of one of the certificates in
the
> first two grouips?

No. This would not be a good formulation, since two different CAs from the
chain could choose the same DN to designate different CRL Issuers.

The RP needs to have an unambiguous way to know exactly which CA from the
chain is the one which has nominated the CRL Issuer.

Denis

> For this purpose, a certificate is a rollover of its
> issuer certificate if it is self-issued but not self-signed, and the
> relationship is associative (i.e. if A is a rollover of B which is a
> rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D
has
> a CRL issuer and the path to D goes A (the anchor) to B to C to D, the
CRL
> issuer certificate may be issued by A, B, C, or D, or by B' in the
> case
> where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued

> through any other anchor nor through any CA whose DN is not in the
> path.

> Only one further liberalization of this rule might make sense, which
> is
> that C' would be considered a rollover of C on a path where C is issued
by
> B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels
> that

> this is safe?
>         The good news about this heuristic is that it can be coded.  I
> think any of these variants resist Julien's attack, under the fairly
> reasonable assumptions that no CA issues certificates to bogus entities
> with its own name and that any CA which directly issued your
> cross-certificate and wants to have a CRL issuer masquerade as that CA
can
> do so by issuing a bogus CA cert just as easily as by issuing a bogus
CRL
> Issuer one.
>
>                 Tom Gindin
>
>
>
>
>
>
> Denis Pinkas <[e-mail]>
> Sent by: [e-mail]
> 11/05/2004 10:04 AM
>
>         To:     Santosh Chokhani <[e-mail]>
>         cc:     [e-mail]
>         Subject:        Re: Briefing on CRL Path for IETF PKIX WG
Meeting
>
>
>
> Santosh,
>
>
>>Denis,
>>
>>See responses in-line in [SC:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, November 04, 2004 12:40 PM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>Santosh,
>>
>>See responses in-line in [DP:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Wednesday, November 03, 2004 9:48 AM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>Santosh,
>>
>> > Denis,
>>
>> > The matching algorithm proposed checks/compares the ancestors.
>>
>>The matching algorithm is missing to say "who" trusts "somebody" for
>
> "what".
>
>>Unless this is clearly said, there is no trust possible and thus no
>>algorithm possible.
>>
>>[SC: The two paths needs to be verified in accordance with 3280 in
>>order

>
> to
>
>>establish trust]
>>
>>[DP: the certification path needs to be verified according to RFC
>>3280.
>
> The
>
>>problem is that RFC 3280 does not tell how to verify that the CRL
>>comes
>>from the right CRL Issuer. Your assumption that the "two paths needs to
>
> be
>
>>verified in accordance with 3280 in order to establish trust" is thus
>>incorrect].
>>
>>[SC: When you augment 3280 with the algorithm I proposed, that takes
>
> care of
>
>>it.  It goes without saying that 3280 needs to be augmented with the
>>algorithm]
>
>
> This is exactly what I disagree with.
>
> Let us talk about the key issue. The question is: how can a RP
> (relying
> party) know that, for a given end-user certificate, the CRL he got is
> indeed
> issued by the right CRL Issuer ?
>
> In the following discussion, I am only considering the case where the
CRL
> Issuer is *not* the CA (this CA is called CA 1).
>
> CA 2 is a CA that has issued a CA certificate to CA 1.
>
> The text is currently so vague that different models are indeed
> theoritically possible. In particular:
>
>   a) the CRL Issuer is nominated by CA 1 that has issued
>      the end-user certificate. This case would make sense
>      when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>      that role to one or more CRL Issuers. This means that
>      a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
>
>   b) the CRL Issuer is nominated by CA 2 that has issued a CA
>      certificate to CA 1. This case would make sense when CA 2
>      has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>      certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>      then only choose a CRL Issuer that has been granted
>      the authorization to issue CRLs by CA 2.
>
> I wonder if I understand correctly the model you proposed, but (please
> correct if wrong) you have a set of trust points to verify the
> certification
> chain, and another set of trust points to verify what you call a
> certification path for the CRL Issuer.
>
> There would be many problems with such a model to define correctly
> validation policies, since the two chains would be unrelated and any CA
> from
> that chain could nominate CRL Issuers used by any CA.
>
> In options a) and b) mentioned above, a single trust point is used to
> validate both the certification chain and the CRL Issuer.
>
> In any case, we need to clarify this topic in 3280bis, whatever the
> clarification will be.
>
>
>>This algorithm is nothing more than formalism of something you agreed
>>to in 2003 on this list.
>>
>>I don't think so.
>>
>>[SC: Go back to September 2003 archive of your response to my post and
>
> tell
>
>>me what is not covered]
>>
>>[DP: You would need to be more precise and provide me an extract of
>>what

>
> you
>
>>refer to]
>>
>>[SC: It was short string of e-mails on the subject matter in September
>
> 2003.
>
> Hum !!! Hum !!!
> Do not mention "free" assertions when you are not sure about.
>
> Denis
>
>
>>I am sure you can find it from the archives.  It may be overcome by
>
> events
>
>>since your recent postings show that you agree with me]
>>
>>Denis
>
>
>
>
>
>
>








Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA1HZmh096450; Tue, 9 Nov 2004 17:17:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA1HZIV096449; Tue, 9 Nov 2004 17:17:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA1HYdC096442 for <[e-mail]>; Tue, 9 Nov 2004 17:17:34 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 10DB141B2E for <[e-mail]>; Wed, 10 Nov 2004 02:17:32 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id D77A4440E7 for <[e-mail]>; Wed, 10 Nov 2004 02:18:05 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25215-02 for <[e-mail]>; Wed, 10 Nov 2004 02:18:02 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 419F3440AF for <[e-mail]>; Wed, 10 Nov 2004 02:18:02 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 10 Nov 2004 02:17:29 +0100
From: "Julien Stern" <[e-mail]>
Date: Wed, 10 Nov 2004 02:17:29 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <006f01c4c69c$d2d26c60$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <006f01c4c69c$d2d26c60$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

comments in line with [JS]

On Tue, Nov 09, 2004 at 03:43:52PM -0500, Santosh Chokhani wrote:
> 
> Stefan,
> 
> See responses in line in [SC:}
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]] 
> Sent: Tuesday, November 09, 2004 2:06 PM
> To: Denis Pinkas; Santosh Chokhani; Julien Stern
> Cc: [e-mail]
> Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> It seams that we have a problem with agreeing on the security assumptions
> more than on the technical matters.
> 
> I recognize that Julien's scenario is a valid remark, at least in theory.
> The point Julien is that there is a problem if an attacker that has obtained
> a rouge CA under a valid root actually could fool an RP software to accept
> the rouge path to the target certificate. IF the RP accept the path over the
> rouge CA then that rouge CA could also defeat the proposed algorithm.
> 
> The question is just if this is a valid threat or not.
> 
> Denis is making a valid remark that different CA's in the certificate path
> may certify different CRL Issuers with the same name by accident and the
> algorithm doesn't account for that.
> 
> [SC: This is only an issue in the context of indirect CRL.  For the direct
> CRL issuer, the algorithm will disambiguate the issues].
> 
> The question is if this is a valid threat or not.
> 
> Both Denis and Julien's scenarios require intentional malicious behaviour of
> the CRL issuer or the CDP and the IDP wouldn't match (the storage location
> pointer would differ).
> 
> [SC: I have not seen a scenario from Denis.  I have a different and simple
> take on Julien's scenario.

> First, Julien's scenario will not come about for
> the relying parties who do not trust the rogue CA.

[JS: this is true, but the rogue CA could be anywhere in the hierarchy
of any trusted anchor. Also, if you assume no CA rogue CA is trusted, your
algorithm mostly only simplifies path construction.]

> Second, the algorithm
> makes sure that who ever is the certificate issuer from the relying party
> perspective can only revoke the certificate.

[JS: the whole point being that it is simple to conterfeit the certicate
issuer from the relying party perspective. Trust in X509 in going down,
not up. This is how the attck works.]

> Third, even if the same key
> was used, in Julien's scenario relying party can always be fooled into using
> bad revocation information along with bogus certificate minted by the rogue
> CA.]

[JS: it might be possible to perform an attack even when the same key is
used, but my current scenario does not. The attack would be much more
complex. It do not see to what scenario you refer to.]


> 
> Both scenarios also require the attacker to convince the RP to NOT obtain
> the correct CRL through the CDP pointer and instead accept the rough CRL
> from other source OR it requires the attacker to hack the server holding the
> real CRL and replace the real CRL with the rough CRL.
> 
> ----------------
> 
> In Denis scenario I would suggest that we can exclude presence of a rouge CA
> in the original certificate path, because if the original cert path has a
> rouge CA, then all bets are off anyway.
> 
> This leaves us with Julien's scenario.
> 
> -----------------
> 
> So the main question is which of these threats that is in scope or out of
> scope 
> 
> 1) Presence of a trusted Rouge CA that is NOT part of the original
> certificate path.
> 
> 2) The ability of the attacker to fool the RP to pick a rouge path and rouge
> CRL where the IDP and CDP match.
> 
> Questions/remarks:
> - If both these threats are in scope then Julien's scenario is also valid.
> - If there threats are out of scope, then what threat remains that requires
> Santosh algorithm in the first place?
> 
> [SC: The threat that the algorithm mitigates is one of accidental error and
> one of malfeasance.  Let me illustrate.  Let us say that both Microsoft and
> VeriSign roots are in a relying party trust anchor  set.  Let us say that
> that we have Microsoft --> Orion CA --> Chokhani.  Chokhani is an end entity
> with serial number 10.  Let us also say that VeriSign has certified another
> Orion.  So, we have VeriSign -->  Orion CA --> CRL X.  Now, some one can
> compromise Chokhani key and play the CRL X  that does not contain 10 and
> make the relying party access Chokhani certificate which actually has been
> compromised.  In this case, all four CAs and Chokhani are playing nice, but
> some one else just ate our lunch.]

[JS: it seems to me that you assume that you can force the use of a
CRL over an other for the attack you described work.

So the difference between our threat models, security wise, is that
you assume all CA are honests and never compromised but can make mistakes,
while I assume a CA can act in a dishonest way. It that correct ?]

> 
> I'm still pro Santosh algorithm since it limits complexity in path
> processing but it would be good to know if there are any threats that
> require Santosh algorithm which remains if at least problem 1 above is out
> of scope.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA141Ei091334; Tue, 9 Nov 2004 17:04:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iAA141e9091333; Tue, 9 Nov 2004 17:04:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iAA140GM091238 for <[e-mail]>; Tue, 9 Nov 2004 17:04:00 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id B7DD741AF1 for <[e-mail]>; Wed, 10 Nov 2004 02:03:54 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 6D265440E7 for <[e-mail]>; Wed, 10 Nov 2004 02:04:28 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25213-01 for <[e-mail]>; Wed, 10 Nov 2004 02:04:25 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id EFFC0440AF for <[e-mail]>; Wed, 10 Nov 2004 02:04:24 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 10 Nov 2004 02:03:52 +0100
From: "Julien Stern" <[e-mail]>
Date: Wed, 10 Nov 2004 02:03:52 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

see my comments in-line with [JS].

On Tue, Nov 09, 2004 at 07:05:32PM -0000, Stefan Santesson wrote:
> It seams that we have a problem with agreeing on the security
> assumptions more than on the technical matters.
>
> I recognize that Julien's scenario is a valid remark, at least in
> theory. The point Julien is that there is a problem if an attacker that
> has obtained a rouge CA under a valid root actually could fool an RP
> software to accept the rouge path to the target certificate. IF the RP
> accept the path over the rouge CA then that rouge CA could also defeat
> the proposed algorithm.
> 
> The question is just if this is a valid threat or not.
> 
> Denis is making a valid remark that different CA's in the certificate
> path may certify different CRL Issuers with the same name by accident
> and the algorithm doesn't account for that.
> 
> The question is if this is a valid threat or not.
> 
> Both Denis and Julien's scenarios require intentional malicious
> behaviour of the CRL issuer or the CDP and the IDP wouldn't match (the
> storage location pointer would differ).
> 
> Both scenarios also require the attacker to convince the RP to NOT
> obtain the correct CRL through the CDP pointer and instead accept the
> rough CRL from other source OR it requires the attacker to hack the
> server holding the real CRL and replace the real CRL with the rough CRL.
> 
> ----------------
> 
> In Denis scenario I would suggest that we can exclude presence of a
> rouge CA in the original certificate path, because if the original cert
> path has a rouge CA, then all bets are off anyway.
> 
> This leaves us with Julien's scenario.
> 
> -----------------
> 
> So the main question is which of these threats that is in scope or out
> of scope 
> 
> 1) Presence of a trusted Rouge CA that is NOT part of the original
> certificate path.
> 
> 2) The ability of the attacker to fool the RP to pick a rouge path and
> rouge CRL where the IDP and CDP match.

[JS thanks for this nice summary of the situation (well, for my
threat at least, I'll let Denis comment on his).

At you said in the beginning of your email, I think we need to define
at least a minimal security and adversarial model.

I though that the strict separation of two different hierachies that
are not cross-certified could be a security goal.

I also though that the compromise of a CA is a plausible scenario,
and that it should not affect any other CA above it or in unrelated
hierarchy.

However, it is true that in practice, the attack is fairly difficult
to mount, even assuming a CA compromise.]

> Questions/remarks:
> - If both these threats are in scope then Julien's scenario is also
> valid.
> - If there threats are out of scope, then what threat remains that
> requires Santosh algorithm in the first place?
> 
> I'm still pro Santosh algorithm since it limits complexity in path
> processing but it would be good to know if there are any threats that
> require Santosh algorithm which remains if at least problem 1 above is
> out of scope.

[JS: Santosh algorithm clearly renders the attack more difficult, and
may prevent mistake.

But what is does is ensuring that two certificates belong to
the same entities, assuming that the CAs in their respectives trust
path are uncompromised and never gave the same DN to two different
entities.

This algorithm can certainly be useful, for CRL, and maybe other things.
However, as I have shown, it only renders the attack harder, not
impossible. What we need is a algorithm that shows the certificates
belong to the same entity AND that this entity actually delivered
the certificate.

It my threat model is considered unrealistic, I'm also in favor
of Santosh algorithm. Otherwise, I think it is only a patch on a
security hole, and that we should find a way to actually plug this hole.

Maybe could we simply add an extension in the EE certificate specifying
the public key of the CRL Issuer ? The CA could simply and securely
delegate to his other key or to an other entity this way.]

--
Julien



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9LAA1N091336; Tue, 9 Nov 2004 13:10:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9LAAZs091335; Tue, 9 Nov 2004 13:10:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9LA9YX091318 for <[e-mail]>; Tue, 9 Nov 2004 13:10:10 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9LAB1X025923 for <[e-mail]>; Tue, 9 Nov 2004 16:10:13 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 16:10:11 -0500
Message-ID: <007c01c4c6a0$8118ce10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

Can you explain the following from your post in relation of CRL path
matching and how you mitigate it and CRL path matching does not.  I quote
you:

"In replying to Santosh, you have discussed attacks which come from
unrelated CA's as the primary security threat associated with CRL issuers.
I agree with that, and have blocked those."

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Gindin
Sent: Tuesday, November 09, 2004 1:40 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



        Denis:

        It is indeed possible for two CA's to choose the same CRL issuer 
DN, while meaning two distinct entities.  However, what are the 
consequences?  In one case, a CA which has certified a subordinate CA can 
"take over" the issuer ID of that subordinate (outside hierarchies, only 
RP's who are trusting the CA through the issuer of that cross-certificate 
are affected).  In the other, a CA which originally delegated revocation 
to its superior can reclaim it.  Which of these is an attack?
        I don't know why the RP needs a rule which declares "a CRL issuer 
must be certified by the CA whose certificates it is issuing a CRL for", 
and which prohibits subordinate CA's from having their hierarchical 
superior issue CRL's for them.  In replying to Santosh, you have discussed 
attacks which come from unrelated CA's as the primary security threat 
associated with CRL issuers.  I agree with that, and have blocked those.
        BTW, Santosh is right that a certificate issued to a CRL Issuer by 
a CA which ordinarily delegates CRL's to that issuer is not practically 
revocable by CRL.  However, IMO a certificate may be useful even if a 
revocation check on it is not feasible.  Much client software checks 
certificate chains without checking revocation, being satisfied with the 
certification that "this key pair was once possessed by the subject". This 
applies equally to self-issued certificates.
        Before declaring that a rule should (or should not) prevent the 
use of a superior CA's CRL Issuer to produce CRL's for a subordinate CA, 
we should probably find out if anybody actually does that.  I hope that 
nobody actually has sibling CA's producing their CRL's.

                Tom Gindin






Denis Pinkas <[e-mail]>
11/09/2004 09:17 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     [e-mail]
        Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting


Tom,

>         Denis:

> Would a reasonable formulation of this rule be that a CRL Issuer
> certificate governing the certificates of a given CA must have been 
> directly issued by one of the certificates in the chain being verified 
> (including the CA's own certificate), by the trust anchor for that 
chain, 
> or by a certificate which is a rollover of one of the certificates in
the 
> first two grouips?

No. This would not be a good formulation, since two different CAs from the
chain could choose the same DN to designate different CRL Issuers.

The RP needs to have an unambiguous way to know exactly which CA from the
chain is the one which has nominated the CRL Issuer.

Denis

> For this purpose, a certificate is a rollover of its
> issuer certificate if it is self-issued but not self-signed, and the 
> relationship is associative (i.e. if A is a rollover of B which is a 
> rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D 
has 
> a CRL issuer and the path to D goes A (the anchor) to B to C to D, the
CRL 
> issuer certificate may be issued by A, B, C, or D, or by B' in the 
> case
> where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued 

> through any other anchor nor through any CA whose DN is not in the 
> path.

> Only one further liberalization of this rule might make sense, which 
> is
> that C' would be considered a rollover of C on a path where C is issued 
by 
> B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels 
> that

> this is safe?
>         The good news about this heuristic is that it can be coded.  I
> think any of these variants resist Julien's attack, under the fairly 
> reasonable assumptions that no CA issues certificates to bogus entities 
> with its own name and that any CA which directly issued your 
> cross-certificate and wants to have a CRL issuer masquerade as that CA 
can 
> do so by issuing a bogus CA cert just as easily as by issuing a bogus
CRL 
> Issuer one.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> Denis Pinkas <[e-mail]>
> Sent by: [e-mail]
> 11/05/2004 10:04 AM
> 
>         To:     Santosh Chokhani <[e-mail]>
>         cc:     [e-mail]
>         Subject:        Re: Briefing on CRL Path for IETF PKIX WG 
Meeting
> 
> 
> 
> Santosh,
> 
> 
>>Denis,
>>
>>See responses in-line in [SC:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, November 04, 2004 12:40 PM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>Santosh,
>>
>>See responses in-line in [DP:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Wednesday, November 03, 2004 9:48 AM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>Santosh,
>>
>> > Denis,
>>
>> > The matching algorithm proposed checks/compares the ancestors.
>>
>>The matching algorithm is missing to say "who" trusts "somebody" for
> 
> "what".
> 
>>Unless this is clearly said, there is no trust possible and thus no 
>>algorithm possible.
>>
>>[SC: The two paths needs to be verified in accordance with 3280 in 
>>order

> 
> to
> 
>>establish trust]
>>
>>[DP: the certification path needs to be verified according to RFC 
>>3280.
> 
> The
> 
>>problem is that RFC 3280 does not tell how to verify that the CRL 
>>comes
>>from the right CRL Issuer. Your assumption that the "two paths needs to 
> 
> be
> 
>>verified in accordance with 3280 in order to establish trust" is thus
>>incorrect].
>>
>>[SC: When you augment 3280 with the algorithm I proposed, that takes
> 
> care of
> 
>>it.  It goes without saying that 3280 needs to be augmented with the 
>>algorithm]
> 
> 
> This is exactly what I disagree with.
> 
> Let us talk about the key issue. The question is: how can a RP 
> (relying
> party) know that, for a given end-user certificate, the CRL he got is 
> indeed 
> issued by the right CRL Issuer ?
> 
> In the following discussion, I am only considering the case where the
CRL 
> Issuer is *not* the CA (this CA is called CA 1).
> 
> CA 2 is a CA that has issued a CA certificate to CA 1.
> 
> The text is currently so vague that different models are indeed
> theoritically possible. In particular:
> 
>   a) the CRL Issuer is nominated by CA 1 that has issued
>      the end-user certificate. This case would make sense
>      when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>      that role to one or more CRL Issuers. This means that
>      a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
> 
>   b) the CRL Issuer is nominated by CA 2 that has issued a CA
>      certificate to CA 1. This case would make sense when CA 2
>      has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>      certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>      then only choose a CRL Issuer that has been granted
>      the authorization to issue CRLs by CA 2.
> 
> I wonder if I understand correctly the model you proposed, but (please
> correct if wrong) you have a set of trust points to verify the 
> certification 
> chain, and another set of trust points to verify what you call a 
> certification path for the CRL Issuer.
> 
> There would be many problems with such a model to define correctly
> validation policies, since the two chains would be unrelated and any CA 
> from 
> that chain could nominate CRL Issuers used by any CA.
> 
> In options a) and b) mentioned above, a single trust point is used to
> validate both the certification chain and the CRL Issuer.
> 
> In any case, we need to clarify this topic in 3280bis, whatever the
> clarification will be.
> 
> 
>>This algorithm is nothing more than formalism of something you agreed
>>to in 2003 on this list.
>>
>>I don't think so.
>>
>>[SC: Go back to September 2003 archive of your response to my post and
> 
> tell
> 
>>me what is not covered]
>>
>>[DP: You would need to be more precise and provide me an extract of 
>>what

> 
> you
> 
>>refer to]
>>
>>[SC: It was short string of e-mails on the subject matter in September
> 
> 2003.
> 
> Hum !!! Hum !!!
> Do not mention "free" assertions when you are not sure about.
> 
> Denis
> 
> 
>>I am sure you can find it from the archives.  It may be overcome by
> 
> events
> 
>>since your recent postings show that you agree with me]
>>
>>Denis
> 
> 
> 
> 
> 
> 
> 






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9L73Ox090299; Tue, 9 Nov 2004 13:07:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9L730F090298; Tue, 9 Nov 2004 13:07:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9L72Vn090292 for <[e-mail]>; Tue, 9 Nov 2004 13:07:02 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9L761X023653 for <[e-mail]>; Tue, 9 Nov 2004 16:07:06 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 16:07:06 -0500
Message-ID: <007b01c4c6a0$119c4ee0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA9L72Vn090293
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

One more thing.  Aside from the threat the algorithm mitigates described at
the end of the e-mail, the algorithm mitigates threats for Julien's rogue CA
scenario.  If the relying party had the legitimate path from the left side
of his diagram, using the path matching will ensure that they do not accept
the CRL from the rogue side.  Without the algorithm, they would.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 3:44 PM
To: '[e-mail]'
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting


Stefan,

See responses in line in [SC:}

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 2:06 PM
To: Denis Pinkas; Santosh Chokhani; Julien Stern
Cc: [e-mail]
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting


It seams that we have a problem with agreeing on the security assumptions
more than on the technical matters.

I recognize that Julien's scenario is a valid remark, at least in theory.
The point Julien is that there is a problem if an attacker that has obtained
a rouge CA under a valid root actually could fool an RP software to accept
the rouge path to the target certificate. IF the RP accept the path over the
rouge CA then that rouge CA could also defeat the proposed algorithm.

The question is just if this is a valid threat or not.

Denis is making a valid remark that different CA's in the certificate path
may certify different CRL Issuers with the same name by accident and the
algorithm doesn't account for that.

[SC: This is only an issue in the context of indirect CRL.  For the direct
CRL issuer, the algorithm will disambiguate the issues].

The question is if this is a valid threat or not.

Both Denis and Julien's scenarios require intentional malicious behaviour of
the CRL issuer or the CDP and the IDP wouldn't match (the storage location
pointer would differ).

[SC: I have not seen a scenario from Denis.  I have a different and simple
take on Julien's scenario.  First, Julien's scenario will not come about for
the relying parties who do not trust the rogue CA.  Second, the algorithm
makes sure that who ever is the certificate issuer from the relying party
perspective can only revoke the certificate.  Third, even if the same key
was used, in Julien's scenario relying party can always be fooled into using
bad revocation information along with bogus certificate minted by the rogue
CA.]

Both scenarios also require the attacker to convince the RP to NOT obtain
the correct CRL through the CDP pointer and instead accept the rough CRL
from other source OR it requires the attacker to hack the server holding the
real CRL and replace the real CRL with the rough CRL.

----------------

In Denis scenario I would suggest that we can exclude presence of a rouge CA
in the original certificate path, because if the original cert path has a
rouge CA, then all bets are off anyway.

This leaves us with Julien's scenario.

-----------------

So the main question is which of these threats that is in scope or out of
scope 

1) Presence of a trusted Rouge CA that is NOT part of the original
certificate path.

2) The ability of the attacker to fool the RP to pick a rouge path and rouge
CRL where the IDP and CDP match.

Questions/remarks:
- If both these threats are in scope then Julien's scenario is also valid.
- If there threats are out of scope, then what threat remains that requires
Santosh algorithm in the first place?

[SC: The threat that the algorithm mitigates is one of accidental error and
one of malfeasance.  Let me illustrate.  Let us say that both Microsoft and
VeriSign roots are in a relying party trust anchor  set.  Let us say that
that we have Microsoft --> Orion CA --> Chokhani.  Chokhani is an end entity
with serial number 10.  Let us also say that VeriSign has certified another
Orion.  So, we have VeriSign -->  Orion CA --> CRL X.  Now, some one can
compromise Chokhani key and play the CRL X  that does not contain 10 and
make the relying party access Chokhani certificate which actually has been
compromised.  In this case, all four CAs and Chokhani are playing nice, but
some one else just ate our lunch.]

I'm still pro Santosh algorithm since it limits complexity in path
processing but it would be good to know if there are any threats that
require Santosh algorithm which remains if at least problem 1 above is out
of scope.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9KhnNo083565; Tue, 9 Nov 2004 12:43:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9KhnZd083564; Tue, 9 Nov 2004 12:43:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9KhnKJ083556 for <[e-mail]>; Tue, 9 Nov 2004 12:43:49 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9Khq1X001099 for <[e-mail]>; Tue, 9 Nov 2004 15:43:52 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 15:43:52 -0500
Message-ID: <006f01c4c69c$d2d26c60$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA9KhnKJ083559
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

See responses in line in [SC:}

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 2:06 PM
To: Denis Pinkas; Santosh Chokhani; Julien Stern
Cc: [e-mail]
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting


It seams that we have a problem with agreeing on the security assumptions
more than on the technical matters.

I recognize that Julien's scenario is a valid remark, at least in theory.
The point Julien is that there is a problem if an attacker that has obtained
a rouge CA under a valid root actually could fool an RP software to accept
the rouge path to the target certificate. IF the RP accept the path over the
rouge CA then that rouge CA could also defeat the proposed algorithm.

The question is just if this is a valid threat or not.

Denis is making a valid remark that different CA's in the certificate path
may certify different CRL Issuers with the same name by accident and the
algorithm doesn't account for that.

[SC: This is only an issue in the context of indirect CRL.  For the direct
CRL issuer, the algorithm will disambiguate the issues].

The question is if this is a valid threat or not.

Both Denis and Julien's scenarios require intentional malicious behaviour of
the CRL issuer or the CDP and the IDP wouldn't match (the storage location
pointer would differ).

[SC: I have not seen a scenario from Denis.  I have a different and simple
take on Julien's scenario.  First, Julien's scenario will not come about for
the relying parties who do not trust the rogue CA.  Second, the algorithm
makes sure that who ever is the certificate issuer from the relying party
perspective can only revoke the certificate.  Third, even if the same key
was used, in Julien's scenario relying party can always be fooled into using
bad revocation information along with bogus certificate minted by the rogue
CA.]

Both scenarios also require the attacker to convince the RP to NOT obtain
the correct CRL through the CDP pointer and instead accept the rough CRL
from other source OR it requires the attacker to hack the server holding the
real CRL and replace the real CRL with the rough CRL.

----------------

In Denis scenario I would suggest that we can exclude presence of a rouge CA
in the original certificate path, because if the original cert path has a
rouge CA, then all bets are off anyway.

This leaves us with Julien's scenario.

-----------------

So the main question is which of these threats that is in scope or out of
scope 

1) Presence of a trusted Rouge CA that is NOT part of the original
certificate path.

2) The ability of the attacker to fool the RP to pick a rouge path and rouge
CRL where the IDP and CDP match.

Questions/remarks:
- If both these threats are in scope then Julien's scenario is also valid.
- If there threats are out of scope, then what threat remains that requires
Santosh algorithm in the first place?

[SC: The threat that the algorithm mitigates is one of accidental error and
one of malfeasance.  Let me illustrate.  Let us say that both Microsoft and
VeriSign roots are in a relying party trust anchor  set.  Let us say that
that we have Microsoft --> Orion CA --> Chokhani.  Chokhani is an end entity
with serial number 10.  Let us also say that VeriSign has certified another
Orion.  So, we have VeriSign -->  Orion CA --> CRL X.  Now, some one can
compromise Chokhani key and play the CRL X  that does not contain 10 and
make the relying party access Chokhani certificate which actually has been
compromised.  In this case, all four CAs and Chokhani are playing nice, but
some one else just ate our lunch.]

I'm still pro Santosh algorithm since it limits complexity in path
processing but it would be good to know if there are any threats that
require Santosh algorithm which remains if at least problem 1 above is out
of scope.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9JvnZB064050; Tue, 9 Nov 2004 11:57:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9Jvntt064049; Tue, 9 Nov 2004 11:57:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9JvmoF064042 for <[e-mail]>; Tue, 9 Nov 2004 11:57:48 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9Jvo1X029684 for <[e-mail]>; Tue, 9 Nov 2004 14:57:50 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 14:57:50 -0500
Message-ID: <006b01c4c696$64c124b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA9JvnoF064043
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

None of your comment seem to object to the path matching algorithm.

Please see specific responses below.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 9:24 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting


Santosh,

> Denis,
> 
> When you look at 3280 and add what I propose, what do you see is 
> missing?

Since you asked ... I will explain what is wrong in your slides.

Slide 5. The statement " A CA is defined by name alone" is wrong. A CA is
not simply defined by a name alone. A name, for X.509, is always relative to
the CA which has issued it. So the "clarification' to say that a CA is
unambiguously defined by name is wrong. Then since the other slides are
based on that wrong assumption, they are wrong as well.

[SC: Here is the quote from X.509 "NOTE 1 - Although the CAs are
unambiguously defined by a distinguished name in the DIT, this does not
imply that there is any relationship between the organization of the CAs and
the DIT."]

Slide 7:  There is no "need to account for multiple CAs with the same name".
This formulation is pretty bad. A CA must provide different names to two
different entities. Since a CA name is relative to another CA name space,
there cannot be two CAs with the same name.

[SC: There is requirement or mechanism that ensures that a relying party
with multiple trust anchors will not encounter two CAs with the same name.
If a relying party has two trust anchors A and B and there are two distinct
companies with the same name C, it is possible that one C is certified via A
and another via B.]

Slide 8: The statement : "There can be more than one CA with the same name"
is wrong. Once again, a (CA) name is always relative to a CA name space.

[SC: There is requirement or mechanism that ensures that a relying party
with multiple trust anchors will not encounter two CAs with the same name.
If a relying party has two trust anchors A and B and there are two distinct
companies with the same name C, it is possible that one C is certified via A
and another via B.]

Slide 8: The statement "starting from a TA, the relying party can match the
CA names in [ ] the CRL certification paths" is wrong as well. There is no
such notion of a "CRL certification path".

[SC: When you get a CRL by the Issuer name of the CA and the signature does
not verify, you will need to develop a certification path for the CRL.  Your
other choices are: do not check revocation information, or take the CRL on
faith even though signature has not been verified.  I do not consider either
of these choices in compliance with 3280.  Feel free to provide other
choices that do not entail building a certification path for the CRL.]

[SC: From the long discourse below, it seems that you are focused only on
indirect CRL issuance problem.  The path matching algorithm tries to solve
that as well as when the CA has used different keys to sign certificates and
CRL (e.g., due to key roll over or in general using two keys to sign the two
objects.]

As indicated in RFC 3280, a CRL issuer is an optional
system to which a CA delegates the publication of CRLs.
This sentence is correct, but vague. (X.509 does not provide
a clear definition of what a CRL Issuer is).

Page 43 from RFC 3280: "The cRLIssuer identifies the entity
who signs and issues the CRL. If present, the cRLIssuer MUST contain at
least one an X.500 distinguished name (DN).

A CA will thus identify the DN of the CRL Issuer in the cRLIssuer field from
a CRL distribution point extension.

[SC: So far, I agree and the briefing is aligned with this]

That DN needs to be compared with a subject DN from a CRL Issuer
certificate, i.e. a certificate which has the cRLSign bit set (and that has
that DN as the subject name).

[SC: cRLSign bit is out side the scope of path matching.  All 3280 checks
for CRL imply.  As to name matching.  As to the name match check, that is
what bullet 1 on slide 13 does.]

The question is then simply : how can a RP know that that CRL Issuer
certificate has been issued by the right CA ?

A simple answer to that question is to say that the CA that has placed the
CRL DP extension must be the one that has issued the CRL Issuer certificate.

[SC: This is one model.  There are other model where the CA need not issue a
certificate to the indirect CRL issuer]

This means something very important. The TA used to verify
the CRL Issuer certificate is the same as the one used to verify the
certificate to be validated. All intermediate CAs are identical.

[SC: The path matching algorithm accounts for this.  Since there is no
requirement for the certificate issuing CA to directly issue a certificate
to the indirect CRL issuer, the matching algorithm may terminates
prematurely.]

This rule can easily be interpreted by a relying party since
it needs first to have the certification path.

This is not the case for the algorithm you proposed, where different TAs are
used on one side to validate the certificate to be validated and on the
other side the CRL Issuer certificate.

[SC: The algorithm requires that the DN representing the same TA be used for
both paths. (See bullet 1 on slide 12.  The reason the same key (and hence
TA) is not used is to accommodate the case of the TA having been re-keyed.]

In this algorithm, two CRL Issuers with the same DN might appear in
different certification paths. So multiple CRL Issuer names could match the
criteria. The algorithm you proposed is flawed.

[SC: Can you give a more concrete example of it.  I know that the rules are
liberal for indirect CRL issuer since I do not believe that direct
delegation model is required]

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Monday, November 08, 2004 11:35 AM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Santosh,
> 
> 
>>Denis,
> 
> 
>>What you are describing is already in 3280 and X.509.
> 
> 
> If it is the case, would you copy and paste that text, please ? 
> Otherwise, I understand that you agree with my text.
> 
> Denis
> 
> 
>>If you identity specific problem with the algorithm, I will be glad to
>>act on it or respond.
>>
>>As to Julien scenario, I would generalize that a relying party is not
>>safe if it trusts a rogue CA for all name spaces and policies.  That 
>>is a fact of life for the whole PKI, including (but not just for) the 
>>path matching algorithm.
>>
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>Sent: Monday, November 08, 2004 9:20 AM
>>To: Julien Stern
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>
>>Julien,
>>
>>You are quite right. There is a major problem with Santosh's proposal.
>>
>>Instead of trying to debug the proposed algorithm, it would be much
>>better to describe first what the trust model is.
>>
>>Leaving aside indirect CRLs, which may be supported by a trillion of
>>all different and unrelated models, there are several questions to 
>>answer:
>>
>>First question: What is a CRL Issuer ?
>>
>>Hereafter is a strawman proposal:
>>
>>CRL Issuer : an authority that issues and signs CRLs. When the CRL is
>>not signed by the CA itself, the CRL shall be signed by a CRL Issuer
> 
> identified
> 
>>in the CRL distribution point extension of the certificate.
>>
>>Second question : How is the CRL Issuer identified in the CRL
>>distribution point extension of the certificate ?
>>
>>Hereafter a strawman response: it is identified using cRLIssuer.
>>
>>         cRLIssuer               [2]     GeneralNames
>>
>>Third question: which form of name shall be used ?
>>
>>GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
>>
>>GeneralName ::= CHOICE {
>>      otherName                       [0]     AnotherName,
>>      rfc822Name                      [1]     IA5String,
>>      dNSName                         [2]     IA5String,
>>      x400Address                     [3]     ORAddress,
>>      directoryName                   [4]     Name,
>>      ediPartyName                    [5]     EDIPartyName,
>>      uniformResourceIdentifier       [6]     IA5String,
>>      iPAddress                       [7]     OCTET STRING,
>>      registeredID                    [8]     OBJECT IDENTIFIER }
>>
>>RFC 3280 states: "the cRLIssuer MUST contain at least one an X.500 
>>distinguished name (DN)".
>>
>>Fourth question: which CA shall certify that name ?
>>
>>Neither RFC 3280 nor X.509 provides a response for that question. Put
>>in another way, who will nominate the CRL Issuer and thus will issue 
>>the CRL Issuer certificate ?
>>
>>  ... and we are back with the two proposals I made (on which I got no 
>>response from Santosh):
>>
>>Here it is again:
>>
>>The CRL Issuer is *not* the CA. This CA is called CA 1.
>>CA 2 is a CA that has issued a CA certificate to CA 1.
>>
>>  a) the CRL Issuer is nominated by CA 1 that has issued
>>     the end-user certificate. This case would make sense
>>     when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>>     that role to one or more CRL Issuers. This means that
>>     a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
>>
>>  b) the CRL Issuer is nominated by CA 2 that has issued a CA
>>     certificate to CA 1. This case would make sense when CA 2
>>     has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>>     certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>>     then only choose a CRL Issuer that has been granted
>>     the authorization to issue CRLs by CA 2.
>>
>>Other cases are the trillion cases of indirect CRLs.
>>
>>Denis
> 
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9J7JqH051155; Tue, 9 Nov 2004 11:07:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9J7Jh4051154; Tue, 9 Nov 2004 11:07:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9J7HmT051090 for <[e-mail]>; Tue, 9 Nov 2004 11:07:18 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Nov 2004 19:07:12 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 19:05:32 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Briefing on CRL Path for IETF PKIX WG Meeting
Thread-Index: AcTGb6uqmFdvSd13QGCfcDcDRIxv2QAE3mLw
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Julien Stern" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 09 Nov 2004 19:07:12.0789 (UTC) FILETIME=[51C7D450:01C4C68F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA9J7ImT051148
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It seams that we have a problem with agreeing on the security
assumptions more than on the technical matters.

I recognize that Julien's scenario is a valid remark, at least in
theory. The point Julien is that there is a problem if an attacker that
has obtained a rouge CA under a valid root actually could fool an RP
software to accept the rouge path to the target certificate. IF the RP
accept the path over the rouge CA then that rouge CA could also defeat
the proposed algorithm.

The question is just if this is a valid threat or not.

Denis is making a valid remark that different CA's in the certificate
path may certify different CRL Issuers with the same name by accident
and the algorithm doesn't account for that.

The question is if this is a valid threat or not.

Both Denis and Julien's scenarios require intentional malicious
behaviour of the CRL issuer or the CDP and the IDP wouldn't match (the
storage location pointer would differ).

Both scenarios also require the attacker to convince the RP to NOT
obtain the correct CRL through the CDP pointer and instead accept the
rough CRL from other source OR it requires the attacker to hack the
server holding the real CRL and replace the real CRL with the rough CRL.

----------------

In Denis scenario I would suggest that we can exclude presence of a
rouge CA in the original certificate path, because if the original cert
path has a rouge CA, then all bets are off anyway.

This leaves us with Julien's scenario.

-----------------

So the main question is which of these threats that is in scope or out
of scope 

1) Presence of a trusted Rouge CA that is NOT part of the original
certificate path.

2) The ability of the attacker to fool the RP to pick a rouge path and
rouge CRL where the IDP and CDP match.


Questions/remarks:
- If both these threats are in scope then Julien's scenario is also
valid.
- If there threats are out of scope, then what threat remains that
requires Santosh algorithm in the first place?

I'm still pro Santosh algorithm since it limits complexity in path
processing but it would be good to know if there are any threats that
require Santosh algorithm which remains if at least problem 1 above is
out of scope.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9IdYpW042999; Tue, 9 Nov 2004 10:39:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9IdYDx042998; Tue, 9 Nov 2004 10:39:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9IdVV7042991 for <[e-mail]>; Tue, 9 Nov 2004 10:39:32 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iA9IdYBS269660 for <[e-mail]>; Tue, 9 Nov 2004 13:39:34 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA9IdY4l269360 for <[e-mail]>; Tue, 9 Nov 2004 13:39:34 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iA9IdYr4024873 for <[e-mail]>; Tue, 9 Nov 2004 13:39:34 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iA9IdYpi024865; Tue, 9 Nov 2004 13:39:34 -0500
In-Reply-To: <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 9 Nov 2004 13:39:32 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF1|October 13, 2004) at 11/09/2004 13:39:33, Serialize complete at 11/09/2004 13:39:33
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Denis:

        It is indeed possible for two CA's to choose the same CRL issuer 
DN, while meaning two distinct entities.  However, what are the 
consequences?  In one case, a CA which has certified a subordinate CA can 
"take over" the issuer ID of that subordinate (outside hierarchies, only 
RP's who are trusting the CA through the issuer of that cross-certificate 
are affected).  In the other, a CA which originally delegated revocation 
to its superior can reclaim it.  Which of these is an attack?
        I don't know why the RP needs a rule which declares "a CRL issuer 
must be certified by the CA whose certificates it is issuing a CRL for", 
and which prohibits subordinate CA's from having their hierarchical 
superior issue CRL's for them.  In replying to Santosh, you have discussed 
attacks which come from unrelated CA's as the primary security threat 
associated with CRL issuers.  I agree with that, and have blocked those.
        BTW, Santosh is right that a certificate issued to a CRL Issuer by 
a CA which ordinarily delegates CRL's to that issuer is not practically 
revocable by CRL.  However, IMO a certificate may be useful even if a 
revocation check on it is not feasible.  Much client software checks 
certificate chains without checking revocation, being satisfied with the 
certification that "this key pair was once possessed by the subject". This 
applies equally to self-issued certificates.
        Before declaring that a rule should (or should not) prevent the 
use of a superior CA's CRL Issuer to produce CRL's for a subordinate CA, 
we should probably find out if anybody actually does that.  I hope that 
nobody actually has sibling CA's producing their CRL's.

                Tom Gindin






Denis Pinkas <[e-mail]>
11/09/2004 09:17 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     [e-mail]
        Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting


Tom,

>         Denis:

> Would a reasonable formulation of this rule be that a CRL Issuer 
> certificate governing the certificates of a given CA must have been 
> directly issued by one of the certificates in the chain being verified 
> (including the CA's own certificate), by the trust anchor for that 
chain, 
> or by a certificate which is a rollover of one of the certificates in 
the 
> first two grouips? 

No. This would not be a good formulation, since two different CAs from
the chain could choose the same DN to designate different CRL Issuers.

The RP needs to have an unambiguous way to know exactly which CA from
the chain is the one which has nominated the CRL Issuer.

Denis

> For this purpose, a certificate is a rollover of its 
> issuer certificate if it is self-issued but not self-signed, and the 
> relationship is associative (i.e. if A is a rollover of B which is a 
> rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D 
has 
> a CRL issuer and the path to D goes A (the anchor) to B to C to D, the 
CRL 
> issuer certificate may be issued by A, B, C, or D, or by B' in the case 
> where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued 

> through any other anchor nor through any CA whose DN is not in the path. 

> Only one further liberalization of this rule might make sense, which is 
> that C' would be considered a rollover of C on a path where C is issued 
by 
> B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels that 

> this is safe?
>         The good news about this heuristic is that it can be coded.  I 
> think any of these variants resist Julien's attack, under the fairly 
> reasonable assumptions that no CA issues certificates to bogus entities 
> with its own name and that any CA which directly issued your 
> cross-certificate and wants to have a CRL issuer masquerade as that CA 
can 
> do so by issuing a bogus CA cert just as easily as by issuing a bogus 
CRL 
> Issuer one.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> Denis Pinkas <[e-mail]>
> Sent by: [e-mail]
> 11/05/2004 10:04 AM
> 
>         To:     Santosh Chokhani <[e-mail]>
>         cc:     [e-mail]
>         Subject:        Re: Briefing on CRL Path for IETF PKIX WG 
Meeting
> 
> 
> 
> Santosh,
> 
> 
>>Denis,
>>
>>See responses in-line in [SC:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]] 
>>Sent: Thursday, November 04, 2004 12:40 PM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>Santosh,
>>
>>See responses in-line in [DP:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Wednesday, November 03, 2004 9:48 AM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>Santosh,
>>
>> > Denis,
>>
>> > The matching algorithm proposed checks/compares the ancestors.
>>
>>The matching algorithm is missing to say "who" trusts "somebody" for 
> 
> "what".
> 
>>Unless this is clearly said, there is no trust possible and thus no
>>algorithm possible.
>>
>>[SC: The two paths needs to be verified in accordance with 3280 in order 

> 
> to
> 
>>establish trust]
>>
>>[DP: the certification path needs to be verified according to RFC 3280. 
> 
> The
> 
>>problem is that RFC 3280 does not tell how to verify that the CRL comes 
>>from the right CRL Issuer. Your assumption that the "two paths needs to 
> 
> be 
> 
>>verified in accordance with 3280 in order to establish trust" is thus 
>>incorrect].
>>
>>[SC: When you augment 3280 with the algorithm I proposed, that takes 
> 
> care of
> 
>>it.  It goes without saying that 3280 needs to be augmented with the
>>algorithm]
> 
> 
> This is exactly what I disagree with.
> 
> Let us talk about the key issue. The question is: how can a RP (relying 
> party) know that, for a given end-user certificate, the CRL he got is 
> indeed 
> issued by the right CRL Issuer ?
> 
> In the following discussion, I am only considering the case where the 
CRL 
> Issuer is *not* the CA (this CA is called CA 1).
> 
> CA 2 is a CA that has issued a CA certificate to CA 1.
> 
> The text is currently so vague that different models are indeed 
> theoritically possible. In particular:
> 
>   a) the CRL Issuer is nominated by CA 1 that has issued
>      the end-user certificate. This case would make sense
>      when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>      that role to one or more CRL Issuers. This means that
>      a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
> 
>   b) the CRL Issuer is nominated by CA 2 that has issued a CA
>      certificate to CA 1. This case would make sense when CA 2
>      has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>      certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>      then only choose a CRL Issuer that has been granted
>      the authorization to issue CRLs by CA 2.
> 
> I wonder if I understand correctly the model you proposed, but (please 
> correct if wrong) you have a set of trust points to verify the 
> certification 
> chain, and another set of trust points to verify what you call a 
> certification path for the CRL Issuer.
> 
> There would be many problems with such a model to define correctly 
> validation policies, since the two chains would be unrelated and any CA 
> from 
> that chain could nominate CRL Issuers used by any CA.
> 
> In options a) and b) mentioned above, a single trust point is used to 
> validate both the certification chain and the CRL Issuer.
> 
> In any case, we need to clarify this topic in 3280bis, whatever the 
> clarification will be.
> 
> 
>>This algorithm is nothing more than formalism of something you agreed 
>>to in 2003 on this list.
>>
>>I don't think so.
>>
>>[SC: Go back to September 2003 archive of your response to my post and 
> 
> tell
> 
>>me what is not covered]
>>
>>[DP: You would need to be more precise and provide me an extract of what 

> 
> you
> 
>>refer to]
>>
>>[SC: It was short string of e-mails on the subject matter in September 
> 
> 2003.
> 
> Hum !!! Hum !!!
> Do not mention "free" assertions when you are not sure about.
> 
> Denis
> 
> 
>>I am sure you can find it from the archives.  It may be overcome by 
> 
> events
> 
>>since your recent postings show that you agree with me]
>>
>>Denis
> 
> 
> 
> 
> 
> 
> 






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9GZMEP003067; Tue, 9 Nov 2004 08:35:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9GZMmq003066; Tue, 9 Nov 2004 08:35:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9GZLu7003060 for <[e-mail]>; Tue, 9 Nov 2004 08:35:22 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9GZO1X032377 for <[e-mail]>; Tue, 9 Nov 2004 11:35:24 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 11:35:23 -0500
Message-ID: <002001c4c67a$1cbe4d80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA9GZMu7003061
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis.

See responses in-line in [SC:]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Tuesday, November 09, 2004 9:18 AM
To: Tom Gindin
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



Tom,

>         Denis:

> Would a reasonable formulation of this rule be that a CRL Issuer
> certificate governing the certificates of a given CA must have been 
> directly issued by one of the certificates in the chain being verified 
> (including the CA's own certificate), by the trust anchor for that chain, 
> or by a certificate which is a rollover of one of the certificates in the 
> first two grouips?  

No. This would not be a good formulation, since two different CAs from the
chain could choose the same DN to designate different CRL Issuers.

[SC: For indirect CRL to work, it is a fair assumption that two CAs will not
share a name in the trust path nominated by the certificate issuing CA]

The RP needs to have an unambiguous way to know exactly which CA from the
chain is the one which has nominated the CRL Issuer.

[SC: I suspect you mean that the relying party needs to have an unambiguous
way to know exactly which authority was nominated as the indirect CRL Issuer
by the certificate issuer.  What you say does not make sense.]

Denis

> For this purpose, a certificate is a rollover of its
> issuer certificate if it is self-issued but not self-signed, and the 
> relationship is associative (i.e. if A is a rollover of B which is a 
> rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D has

> a CRL issuer and the path to D goes A (the anchor) to B to C to D, the CRL

> issuer certificate may be issued by A, B, C, or D, or by B' in the case 
> where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued 
> through any other anchor nor through any CA whose DN is not in the path. 
> Only one further liberalization of this rule might make sense, which is 
> that C' would be considered a rollover of C on a path where C is issued by

> B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels that 
> this is safe?
>         The good news about this heuristic is that it can be coded.  I 
> think any of these variants resist Julien's attack, under the fairly 
> reasonable assumptions that no CA issues certificates to bogus entities 
> with its own name and that any CA which directly issued your 
> cross-certificate and wants to have a CRL issuer masquerade as that CA can

> do so by issuing a bogus CA cert just as easily as by issuing a bogus CRL 
> Issuer one.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> Denis Pinkas <[e-mail]>
> Sent by: [e-mail]
> 11/05/2004 10:04 AM
>  
>         To:     Santosh Chokhani <[e-mail]>
>         cc:     [e-mail]
>         Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> Santosh,
> 
> 
>>Denis,
>>
>>See responses in-line in [SC:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, November 04, 2004 12:40 PM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>Santosh,
>>
>>See responses in-line in [DP:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Wednesday, November 03, 2004 9:48 AM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>Santosh,
>>
>> > Denis,
>>
>> > The matching algorithm proposed checks/compares the ancestors.
>>
>>The matching algorithm is missing to say "who" trusts "somebody" for
> 
> "what".
> 
>>Unless this is clearly said, there is no trust possible and thus no 
>>algorithm possible.
>>
>>[SC: The two paths needs to be verified in accordance with 3280 in 
>>order
> 
> to
> 
>>establish trust]
>>
>>[DP: the certification path needs to be verified according to RFC 
>>3280.
> 
> The
> 
>>problem is that RFC 3280 does not tell how to verify that the CRL 
>>comes
>>from the right CRL Issuer. Your assumption that the "two paths needs to 
> 
> be
> 
>>verified in accordance with 3280 in order to establish trust" is thus
>>incorrect].
>>
>>[SC: When you augment 3280 with the algorithm I proposed, that takes
> 
> care of
> 
>>it.  It goes without saying that 3280 needs to be augmented with the 
>>algorithm]
> 
> 
> This is exactly what I disagree with.
> 
> Let us talk about the key issue. The question is: how can a RP 
> (relying
> party) know that, for a given end-user certificate, the CRL he got is 
> indeed 
> issued by the right CRL Issuer ?
> 
> In the following discussion, I am only considering the case where the 
> CRL
> Issuer is *not* the CA (this CA is called CA 1).
> 
> CA 2 is a CA that has issued a CA certificate to CA 1.
> 
> The text is currently so vague that different models are indeed
> theoritically possible. In particular:
> 
>   a) the CRL Issuer is nominated by CA 1 that has issued
>      the end-user certificate. This case would make sense
>      when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>      that role to one or more CRL Issuers. This means that
>      a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
> 
>   b) the CRL Issuer is nominated by CA 2 that has issued a CA
>      certificate to CA 1. This case would make sense when CA 2
>      has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>      certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>      then only choose a CRL Issuer that has been granted
>      the authorization to issue CRLs by CA 2.
> 
> I wonder if I understand correctly the model you proposed, but (please
> correct if wrong) you have a set of trust points to verify the 
> certification 
> chain, and another set of trust points to verify what you call a 
> certification path for the CRL Issuer.
> 
> There would be many problems with such a model to define correctly
> validation policies, since the two chains would be unrelated and any CA 
> from 
> that chain could nominate CRL Issuers used by any CA.
> 
> In options a) and b) mentioned above, a single trust point is used to
> validate both the certification chain and the CRL Issuer.
> 
> In any case, we need to clarify this topic in 3280bis, whatever the
> clarification will be.
> 
> 
>>This algorithm is nothing more than formalism of something you agreed
>>to in 2003 on this list.
>>
>>I don't think so.
>>
>>[SC: Go back to September 2003 archive of your response to my post and
> 
> tell
> 
>>me what is not covered]
>>
>>[DP: You would need to be more precise and provide me an extract of 
>>what
> 
> you
> 
>>refer to]
>>
>>[SC: It was short string of e-mails on the subject matter in September
> 
> 2003.
> 
> Hum !!! Hum !!!
> Do not mention "free" assertions when you are not sure about.
> 
> Denis
> 
> 
>>I am sure you can find it from the archives.  It may be overcome by
> 
> events
> 
>>since your recent postings show that you agree with me]
>>
>>Denis
> 
> 
> 
> 
> 
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9G0KdS092159; Tue, 9 Nov 2004 08:00:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9G0KrB092158; Tue, 9 Nov 2004 08:00:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9G0JZo092152 for <[e-mail]>; Tue, 9 Nov 2004 08:00:19 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9G0J1X005548 for <[e-mail]>; Tue, 9 Nov 2004 11:00:19 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 11:00:19 -0500
Message-ID: <000601c4c675$361ba070$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I missed one of your questions.  Here is the response.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Tuesday, November 09, 2004 9:12 AM
To: Santosh Chokhani
Cc: pkix
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
<Snip>

What would be the content of the CRL DP extension from the CRL Issuer
certificate ?

[SC: In a simple case, the cRLIssuer field can be the DN of CRL issuer.
Assuming the CRL is published in directory, no other fields need to be
populated.  If the DP is populated to assist relying parties, the DP could
be an URL to the CRL]

Denis

 > Denis

 >>Russ




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9EV5ug056431; Tue, 9 Nov 2004 06:31:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9EV5Uf056429; Tue, 9 Nov 2004 06:31:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9EV5mk056418 for <[e-mail]>; Tue, 9 Nov 2004 06:31:05 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 ([130.129.132.95]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9EV11X005491 for <[e-mail]>; Tue, 9 Nov 2004 09:31:06 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 09:30:51 -0500
Message-ID: <002d01c4c668$bf7ee780$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA9EV5mk056423
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I am sorry if you did not expect me to respond.  I am not aware of any rule
that we are not supposed to respond to the e-mail.

As to circularity, the problem is as follows.

Let us say CA A delegates the CRL issuance to Authority B.  Your proposal
requires that A issue a certificate to B will get in the way of a CA not
issuing CRLs because if the CA does not issue CRL, how would the revocation
status of certificate A --> B be checked?

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 9:12 AM
To: Santosh Chokhani
Cc: pkix
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting


Santosh,

This was a response to Russ that you intercepted.

 >>>First question: What is a CRL Issuer ?
 >>
 >
 >>RFC 3280 says:
 >
 >
 >>   CRL issuer: an optional system to which a CA delegates the
 >>               publication of certificate revocation lists;
  >
 > True, but thus is vague. Page 43 adds further explanations:  >
 >     The cRLIssuer identifies the entity who signs and issues the CRL.
 >     If present, the cRLIssuer MUST contain at least one an X.500
 >     distinguished name (DN), ...
 >
 > So here is a strawman proposal for 3280bis:
 >
 > "CRL issuer: an authority that issues and signs CRLs. When a CRL is not
> signed by the CA itself, the CRL shall be signed by a CRL Issuer
identified  > in the CRL distribution point extension of the certificate.  >
> {SC: I do not have objections to it, but I am not sure of the difference
> between the two.  Also, note that if the certificate issuer signs the CRL,
> crlIssuer field must be absent in the CRL DP.]

   ... which is covered by the sentence :
       "When a CRL is not signed by the CA itself, ..."

 > Note: in the later case, the CRL Issuer certificate shall be issued
 >        by that CA."
 >
 > [SC: I have objection to this on two grounds: One, this is a new
constraints  > and breaks some existing implementations,

Let us see what the second objection is.

 > Two, if the CA wanted to delegate
 > all CRL issuance, having this requirement will either cause a circular  >
problem (insecure)

With this sentence, you have not demonstrated any circular problem, nor any
insecurity.

 > or not permit the CA to promulgate the revocation status
 > of the certificate issued to the CRL Issuer.]

What would be the content of the CRL DP extension from the CRL Issuer
certificate ?

Denis

 > Denis

 >>Russ





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9EOpJL054086; Tue, 9 Nov 2004 06:24:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9EOpjO054085; Tue, 9 Nov 2004 06:24:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9EOm6L053996 for <[e-mail]>; Tue, 9 Nov 2004 06:24:49 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA72368; Tue, 9 Nov 2004 15:36:34 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110915243002:296 ; Tue, 9 Nov 2004 15:24:30 +0100 
Message-ID: <[e-mail]>
Date: Tue, 09 Nov 2004 15:24:29 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <009e01c4c5b2$16d7f9c0$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/11/2004 15:24:30, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/11/2004 15:24:32, Serialize complete at 09/11/2004 15:24:32
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

> Denis,
> 
> When you look at 3280 and add what I propose, what do you see is missing?

Since you asked ... I will explain what is wrong in your slides.

Slide 5. The statement " A CA is defined by name alone" is
wrong. A CA is not simply defined by a name alone. A name,
for X.509, is always relative to the CA which has issued it.
So the "clarification' to say that a CA is unambiguously
defined by name is wrong. Then since the other slides are
based on that wrong assumption, they are wrong as well.

Slide 7:  There is no "need to account for multiple CAs with
the same name". This formulation is pretty bad. A CA must
provide different names to two different entities. Since a CA
name is relative to another CA name space, there cannot be
two CAs with the same name.

Slide 8: The statement : "There can be more than one CA with
the same name" is wrong. Once again, a (CA) name is always
relative to a CA name space.

Slide 8: The statement "starting from a TA, the relying party
can match the CA names in [ ] the CRL certification paths" is
wrong as well. There is no such notion of a "CRL
certification path".

As indicated in RFC 3280, a CRL issuer is an optional
system to which a CA delegates the publication of CRLs.
This sentence is correct, but vague. (X.509 does not provide
a clear definition of what a CRL Issuer is).

Page 43 from RFC 3280: "The cRLIssuer identifies the entity
who signs and issues the CRL. If present, the cRLIssuer MUST
contain at least one an X.500 distinguished name (DN).

A CA will thus identify the DN of the CRL Issuer in the
cRLIssuer field from a CRL distribution point extension.

That DN needs to be be compared with a subject DN from a CRL Issuer
certificate, i.e. a certificate which has the cRLSign bit set
(and that has that DN as the subject name).

The question is then simply : how can a RP know that that CRL Issuer
certificate has been issued by the right CA ?

A simple answer to that question is to say that the CA that has
placed the CRL DP extension must be the one that has issued the
CRL Issuer certificate.

This means something very important. The TA used to verify
the CRL Issuer certificate is the same as the one used to verify
the certificate to be validated. All intermediate CAs are
identical.

This rule can easily be interpreted by a relying party since
it needs first to have the certification path.

This is not the case for the algorithm you proposed, where
different TAs are used on one side to validate the certificate to be
validated and on the other side the CRL Issuer certificate.

In this algorithm, two CRL Issuers with the same DN might appear
in different certification paths. So multiple CRL Issuer names
could match the criteria. The algorithm you proposed is flawed.

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Monday, November 08, 2004 11:35 AM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Santosh,
> 
> 
>>Denis,
> 
> 
>>What you are describing is already in 3280 and X.509.
> 
> 
> If it is the case, would you copy and paste that text, please ? Otherwise, I
> understand that you agree with my text.
> 
> Denis
> 
> 
>>If you identity specific problem with the algorithm, I will be glad to 
>>act on it or respond.
>>
>>As to Julien scenario, I would generalize that a relying party is not 
>>safe if it trusts a rogue CA for all name spaces and policies.  That 
>>is a fact of life for the whole PKI, including (but not just for) the 
>>path matching algorithm.
>>
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>Sent: Monday, November 08, 2004 9:20 AM
>>To: Julien Stern
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>
>>Julien,
>>
>>You are quite right. There is a major problem with Santosh's proposal.
>>
>>Instead of trying to debug the proposed algorithm, it would be much 
>>better
>>to describe first what the trust model is.
>>
>>Leaving aside indirect CRLs, which may be supported by a trillion of 
>>all
>>different and unrelated models, there are several questions to answer:
>>
>>First question: What is a CRL Issuer ?
>>
>>Hereafter is a strawman proposal:
>>
>>CRL Issuer : an authority that issues and signs CRLs. When the CRL is 
>>not
>>signed by the CA itself, the CRL shall be signed by a CRL Issuer
> 
> identified 
> 
>>in the CRL distribution point extension of the certificate.
>>
>>Second question : How is the CRL Issuer identified in the CRL 
>>distribution
>>point extension of the certificate ?
>>
>>Hereafter a strawman response: it is identified using cRLIssuer.
>>
>>         cRLIssuer               [2]     GeneralNames
>>
>>Third question: which form of name shall be used ?
>>
>>GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
>>
>>GeneralName ::= CHOICE {
>>      otherName                       [0]     AnotherName,
>>      rfc822Name                      [1]     IA5String,
>>      dNSName                         [2]     IA5String,
>>      x400Address                     [3]     ORAddress,
>>      directoryName                   [4]     Name,
>>      ediPartyName                    [5]     EDIPartyName,
>>      uniformResourceIdentifier       [6]     IA5String,
>>      iPAddress                       [7]     OCTET STRING,
>>      registeredID                    [8]     OBJECT IDENTIFIER }
>>
>>RFC 3280 states: "the cRLIssuer MUST contain at least one an X.500
>>distinguished name (DN)".
>>
>>Fourth question: which CA shall certify that name ?
>>
>>Neither RFC 3280 nor X.509 provides a response for that question. Put 
>>in another way, who will nominate the CRL Issuer and thus will issue 
>>the CRL Issuer certificate ?
>>
>>  ... and we are back with the two proposals I made (on which I got no
>>response from Santosh):
>>
>>Here it is again:
>>
>>The CRL Issuer is *not* the CA. This CA is called CA 1.
>>CA 2 is a CA that has issued a CA certificate to CA 1.
>>
>>  a) the CRL Issuer is nominated by CA 1 that has issued
>>     the end-user certificate. This case would make sense
>>     when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>>     that role to one or more CRL Issuers. This means that
>>     a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
>>
>>  b) the CRL Issuer is nominated by CA 2 that has issued a CA
>>     certificate to CA 1. This case would make sense when CA 2
>>     has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>>     certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>>     then only choose a CRL Issuer that has been granted
>>     the authorization to issue CRLs by CA 2.
>>
>>Other cases are the trillion cases of indirect CRLs.
>>
>>Denis
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9EIAIG050881; Tue, 9 Nov 2004 06:18:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9EIAIQ050880; Tue, 9 Nov 2004 06:18:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9EI4Un050796 for <[e-mail]>; Tue, 9 Nov 2004 06:18:07 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA82868; Tue, 9 Nov 2004 15:30:02 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110915175877:287 ; Tue, 9 Nov 2004 15:17:58 +0100 
Message-ID: <[e-mail]>
Date: Tue, 09 Nov 2004 15:17:58 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/11/2004 15:17:58, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/11/2004 15:18:00, Serialize complete at 09/11/2004 15:18:00
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

>         Denis:

> Would a reasonable formulation of this rule be that a CRL Issuer 
> certificate governing the certificates of a given CA must have been 
> directly issued by one of the certificates in the chain being verified 
> (including the CA's own certificate), by the trust anchor for that chain, 
> or by a certificate which is a rollover of one of the certificates in the 
> first two grouips?  

No. This would not be a good formulation, since two different CAs from
the chain could choose the same DN to designate different CRL Issuers.

The RP needs to have an unambiguous way to know exactly which CA from
the chain is the one which has nominated the CRL Issuer.

Denis

> For this purpose, a certificate is a rollover of its 
> issuer certificate if it is self-issued but not self-signed, and the 
> relationship is associative (i.e. if A is a rollover of B which is a 
> rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D has 
> a CRL issuer and the path to D goes A (the anchor) to B to C to D, the CRL 
> issuer certificate may be issued by A, B, C, or D, or by B' in the case 
> where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued 
> through any other anchor nor through any CA whose DN is not in the path. 
> Only one further liberalization of this rule might make sense, which is 
> that C' would be considered a rollover of C on a path where C is issued by 
> B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels that 
> this is safe?
>         The good news about this heuristic is that it can be coded.  I 
> think any of these variants resist Julien's attack, under the fairly 
> reasonable assumptions that no CA issues certificates to bogus entities 
> with its own name and that any CA which directly issued your 
> cross-certificate and wants to have a CRL issuer masquerade as that CA can 
> do so by issuing a bogus CA cert just as easily as by issuing a bogus CRL 
> Issuer one.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> Denis Pinkas <[e-mail]>
> Sent by: [e-mail]
> 11/05/2004 10:04 AM
>  
>         To:     Santosh Chokhani <[e-mail]>
>         cc:     [e-mail]
>         Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> Santosh,
> 
> 
>>Denis,
>>
>>See responses in-line in [SC:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]] 
>>Sent: Thursday, November 04, 2004 12:40 PM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>Santosh,
>>
>>See responses in-line in [DP:]
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Wednesday, November 03, 2004 9:48 AM
>>To: Santosh Chokhani
>>Cc: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>Santosh,
>>
>> > Denis,
>>
>> > The matching algorithm proposed checks/compares the ancestors.
>>
>>The matching algorithm is missing to say "who" trusts "somebody" for 
> 
> "what".
> 
>>Unless this is clearly said, there is no trust possible and thus no
>>algorithm possible.
>>
>>[SC: The two paths needs to be verified in accordance with 3280 in order 
> 
> to
> 
>>establish trust]
>>
>>[DP: the certification path needs to be verified according to RFC 3280. 
> 
> The
> 
>>problem is that RFC 3280 does not tell how to verify that the CRL comes 
>>from the right CRL Issuer. Your assumption that the "two paths needs to 
> 
> be 
> 
>>verified in accordance with 3280 in order to establish trust" is thus 
>>incorrect].
>>
>>[SC: When you augment 3280 with the algorithm I proposed, that takes 
> 
> care of
> 
>>it.  It goes without saying that 3280 needs to be augmented with the
>>algorithm]
> 
> 
> This is exactly what I disagree with.
> 
> Let us talk about the key issue. The question is: how can a RP (relying 
> party) know that, for a given end-user certificate, the CRL he got is 
> indeed 
> issued by the right CRL Issuer ?
> 
> In the following discussion, I am only considering the case where the CRL 
> Issuer is *not* the CA (this CA is called CA 1).
> 
> CA 2 is a CA that has issued a CA certificate to CA 1.
> 
> The text is currently so vague that different models are indeed 
> theoritically possible. In particular:
> 
>   a) the CRL Issuer is nominated by CA 1 that has issued
>      the end-user certificate. This case would make sense
>      when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>      that role to one or more CRL Issuers. This means that
>      a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
> 
>   b) the CRL Issuer is nominated by CA 2 that has issued a CA
>      certificate to CA 1. This case would make sense when CA 2
>      has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>      certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>      then only choose a CRL Issuer that has been granted
>      the authorization to issue CRLs by CA 2.
> 
> I wonder if I understand correctly the model you proposed, but (please 
> correct if wrong) you have a set of trust points to verify the 
> certification 
> chain, and another set of trust points to verify what you call a 
> certification path for the CRL Issuer.
> 
> There would be many problems with such a model to define correctly 
> validation policies, since the two chains would be unrelated and any CA 
> from 
> that chain could nominate CRL Issuers used by any CA.
> 
> In options a) and b) mentioned above, a single trust point is used to 
> validate both the certification chain and the CRL Issuer.
> 
> In any case, we need to clarify this topic in 3280bis, whatever the 
> clarification will be.
> 
> 
>>This algorithm is nothing more than formalism of something you agreed 
>>to in 2003 on this list.
>>
>>I don't think so.
>>
>>[SC: Go back to September 2003 archive of your response to my post and 
> 
> tell
> 
>>me what is not covered]
>>
>>[DP: You would need to be more precise and provide me an extract of what 
> 
> you
> 
>>refer to]
>>
>>[SC: It was short string of e-mails on the subject matter in September 
> 
> 2003.
> 
> Hum !!! Hum !!!
> Do not mention "free" assertions when you are not sure about.
> 
> Denis
> 
> 
>>I am sure you can find it from the archives.  It may be overcome by 
> 
> events
> 
>>since your recent postings show that you agree with me]
>>
>>Denis
> 
> 
> 
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9ECX8M048364; Tue, 9 Nov 2004 06:12:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9ECXrO048363; Tue, 9 Nov 2004 06:12:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9ECVZg048238 for <[e-mail]>; Tue, 9 Nov 2004 06:12:32 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA49780; Tue, 9 Nov 2004 15:24:24 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110915121986:281 ; Tue, 9 Nov 2004 15:12:19 +0100 
Message-ID: <[e-mail]>
Date: Tue, 09 Nov 2004 15:12:19 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <00a101c4c64e$f4ee6770$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/11/2004 15:12:19, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/11/2004 15:12:21, Serialize complete at 09/11/2004 15:12:21
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

This was a response to Russ that you intercepted.

 >>>First question: What is a CRL Issuer ?
 >>
 >
 >>RFC 3280 says:
 >
 >
 >>   CRL issuer: an optional system to which a CA delegates the
 >>               publication of certificate revocation lists;
  >
 > True, but thus is vague. Page 43 adds further explanations:
 >
 >     The cRLIssuer identifies the entity who signs and issues the CRL.
 >     If present, the cRLIssuer MUST contain at least one an X.500
 >     distinguished name (DN), ...
 >
 > So here is a strawman proposal for 3280bis:
 >
 > "CRL issuer: an authority that issues and signs CRLs. When a CRL is not
 > signed by the CA itself, the CRL shall be signed by a CRL Issuer identified
 > in the CRL distribution point extension of the certificate.
 >
 > {SC: I do not have objections to it, but I am not sure of the difference
 > between the two.  Also, note that if the certificate issuer signs the CRL,
 > crlIssuer field must be absent in the CRL DP.]

   ... which is covered by the sentence :
       "When a CRL is not signed by the CA itself, ..."

 > Note: in the later case, the CRL Issuer certificate shall be issued
 >        by that CA."
 >
 > [SC: I have objection to this on two grounds: One, this is a new constraints
 > and breaks some existing implementations,

Let us see what the second objection is.

 > Two, if the CA wanted to delegate
 > all CRL issuance, having this requirement will either cause a circular
 > problem (insecure)

With this sentence, you have not demonstrated any circular problem,
nor any insecurity.

 > or not permit the CA to promulgate the revocation status
 > of the certificate issued to the CRL Issuer.]

What would be the content of the CRL DP extension from the CRL Issuer
certificate ?

Denis

 > Denis

 >>Russ




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9DhBGP034051; Tue, 9 Nov 2004 05:43:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9DhBce034050; Tue, 9 Nov 2004 05:43:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9DhB6t034041 for <[e-mail]>; Tue, 9 Nov 2004 05:43:11 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 ([130.129.132.95]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9DhB1X005516 for <[e-mail]>; Tue, 9 Nov 2004 08:43:12 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 08:43:06 -0500
Message-ID: <001001c4c662$0e950b80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA9DhB6t034045
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

How do you check the revocation status of a self-issued certificates?  If
the old key can be used to sign CRL, why not just issue CRL using the old as
well as new key and not worry about roll over certificate.

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 7:46 AM
To: Denis Pinkas
Cc: Santosh Chokhani; [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting


        Denis:

        Would a reasonable formulation of this rule be that a CRL Issuer 
certificate governing the certificates of a given CA must have been 
directly issued by one of the certificates in the chain being verified 
(including the CA's own certificate), by the trust anchor for that chain, 
or by a certificate which is a rollover of one of the certificates in the 
first two grouips?  For this purpose, a certificate is a rollover of its 
issuer certificate if it is self-issued but not self-signed, and the 
relationship is associative (i.e. if A is a rollover of B which is a 
rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D has 
a CRL issuer and the path to D goes A (the anchor) to B to C to D, the CRL 
issuer certificate may be issued by A, B, C, or D, or by B' in the case 
where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued 
through any other anchor nor through any CA whose DN is not in the path. 
Only one further liberalization of this rule might make sense, which is 
that C' would be considered a rollover of C on a path where C is issued by 
B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels that 
this is safe?
        The good news about this heuristic is that it can be coded.  I 
think any of these variants resist Julien's attack, under the fairly 
reasonable assumptions that no CA issues certificates to bogus entities 
with its own name and that any CA which directly issued your 
cross-certificate and wants to have a CRL issuer masquerade as that CA can 
do so by issuing a bogus CA cert just as easily as by issuing a bogus CRL 
Issuer one.

                Tom Gindin






Denis Pinkas <[e-mail]>
Sent by: [e-mail]
11/05/2004 10:04 AM
 
        To:     Santosh Chokhani <[e-mail]>
        cc:     [e-mail]
        Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting



Santosh,

> Denis,
> 
> See responses in-line in [SC:]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, November 04, 2004 12:40 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Santosh,
> 
> See responses in-line in [DP:]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, November 03, 2004 9:48 AM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> Santosh,
> 
>  > Denis,
> 
>  > The matching algorithm proposed checks/compares the ancestors.
> 
> The matching algorithm is missing to say "who" trusts "somebody" for
"what".
> Unless this is clearly said, there is no trust possible and thus no 
> algorithm possible.
> 
> [SC: The two paths needs to be verified in accordance with 3280 in 
> order
to
> establish trust]
> 
> [DP: the certification path needs to be verified according to RFC 
> 3280.
The
> problem is that RFC 3280 does not tell how to verify that the CRL 
> comes
> from the right CRL Issuer. Your assumption that the "two paths needs to 
be 
> verified in accordance with 3280 in order to establish trust" is thus
> incorrect].
> 
> [SC: When you augment 3280 with the algorithm I proposed, that takes
care of
> it.  It goes without saying that 3280 needs to be augmented with the 
> algorithm]

This is exactly what I disagree with.

Let us talk about the key issue. The question is: how can a RP (relying 
party) know that, for a given end-user certificate, the CRL he got is 
indeed 
issued by the right CRL Issuer ?

In the following discussion, I am only considering the case where the CRL 
Issuer is *not* the CA (this CA is called CA 1).

CA 2 is a CA that has issued a CA certificate to CA 1.

The text is currently so vague that different models are indeed 
theoritically possible. In particular:

  a) the CRL Issuer is nominated by CA 1 that has issued
     the end-user certificate. This case would make sense
     when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
     that role to one or more CRL Issuers. This means that
     a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.

  b) the CRL Issuer is nominated by CA 2 that has issued a CA
     certificate to CA 1. This case would make sense when CA 2
     has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
     certificate is issued by CA 2 to every CRL Issuer. CA 1 may
     then only choose a CRL Issuer that has been granted
     the authorization to issue CRLs by CA 2.

I wonder if I understand correctly the model you proposed, but (please 
correct if wrong) you have a set of trust points to verify the 
certification 
chain, and another set of trust points to verify what you call a 
certification path for the CRL Issuer.

There would be many problems with such a model to define correctly 
validation policies, since the two chains would be unrelated and any CA 
from 
that chain could nominate CRL Issuers used by any CA.

In options a) and b) mentioned above, a single trust point is used to 
validate both the certification chain and the CRL Issuer.

In any case, we need to clarify this topic in 3280bis, whatever the 
clarification will be.

> This algorithm is nothing more than formalism of something you agreed
> to in 2003 on this list.
> 
> I don't think so.
> 
> [SC: Go back to September 2003 archive of your response to my post and
tell
> me what is not covered]
> 
> [DP: You would need to be more precise and provide me an extract of 
> what
you
> 
> refer to]
> 
> [SC: It was short string of e-mails on the subject matter in September
2003.

Hum !!! Hum !!!
Do not mention "free" assertions when you are not sure about.

Denis

> I am sure you can find it from the archives.  It may be overcome by 
events
> since your recent postings show that you agree with me]
> 
> Denis








Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9CjlKB009988; Tue, 9 Nov 2004 04:45:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9Cjl13009987; Tue, 9 Nov 2004 04:45:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9CjkgN009973 for <[e-mail]>; Tue, 9 Nov 2004 04:45:46 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id iA9CjlBS420600 for <[e-mail]>; Tue, 9 Nov 2004 07:45:47 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA9CjlZY268166 for <[e-mail]>; Tue, 9 Nov 2004 07:45:47 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iA9CjkVG030815 for <[e-mail]>; Tue, 9 Nov 2004 07:45:47 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iA9CjkV8030812; Tue, 9 Nov 2004 07:45:46 -0500
In-Reply-To: <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: Santosh Chokhani <[e-mail]>, [e-mail]
MIME-Version: 1.0
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 9 Nov 2004 07:45:43 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF1|October 13, 2004) at 11/09/2004 07:45:46, Serialize complete at 11/09/2004 07:45:46
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Denis:

        Would a reasonable formulation of this rule be that a CRL Issuer 
certificate governing the certificates of a given CA must have been 
directly issued by one of the certificates in the chain being verified 
(including the CA's own certificate), by the trust anchor for that chain, 
or by a certificate which is a rollover of one of the certificates in the 
first two grouips?  For this purpose, a certificate is a rollover of its 
issuer certificate if it is self-issued but not self-signed, and the 
relationship is associative (i.e. if A is a rollover of B which is a 
rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D has 
a CRL issuer and the path to D goes A (the anchor) to B to C to D, the CRL 
issuer certificate may be issued by A, B, C, or D, or by B' in the case 
where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued 
through any other anchor nor through any CA whose DN is not in the path. 
Only one further liberalization of this rule might make sense, which is 
that C' would be considered a rollover of C on a path where C is issued by 
B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels that 
this is safe?
        The good news about this heuristic is that it can be coded.  I 
think any of these variants resist Julien's attack, under the fairly 
reasonable assumptions that no CA issues certificates to bogus entities 
with its own name and that any CA which directly issued your 
cross-certificate and wants to have a CRL issuer masquerade as that CA can 
do so by issuing a bogus CA cert just as easily as by issuing a bogus CRL 
Issuer one.

                Tom Gindin






Denis Pinkas <[e-mail]>
Sent by: [e-mail]
11/05/2004 10:04 AM
 
        To:     Santosh Chokhani <[e-mail]>
        cc:     [e-mail]
        Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting



Santosh,

> Denis,
> 
> See responses in-line in [SC:]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, November 04, 2004 12:40 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Santosh,
> 
> See responses in-line in [DP:]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, November 03, 2004 9:48 AM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> Santosh,
> 
>  > Denis,
> 
>  > The matching algorithm proposed checks/compares the ancestors.
> 
> The matching algorithm is missing to say "who" trusts "somebody" for 
"what".
> Unless this is clearly said, there is no trust possible and thus no
> algorithm possible.
> 
> [SC: The two paths needs to be verified in accordance with 3280 in order 
to
> establish trust]
> 
> [DP: the certification path needs to be verified according to RFC 3280. 
The
> problem is that RFC 3280 does not tell how to verify that the CRL comes 
> from the right CRL Issuer. Your assumption that the "two paths needs to 
be 
> verified in accordance with 3280 in order to establish trust" is thus 
> incorrect].
> 
> [SC: When you augment 3280 with the algorithm I proposed, that takes 
care of
> it.  It goes without saying that 3280 needs to be augmented with the
> algorithm]

This is exactly what I disagree with.

Let us talk about the key issue. The question is: how can a RP (relying 
party) know that, for a given end-user certificate, the CRL he got is 
indeed 
issued by the right CRL Issuer ?

In the following discussion, I am only considering the case where the CRL 
Issuer is *not* the CA (this CA is called CA 1).

CA 2 is a CA that has issued a CA certificate to CA 1.

The text is currently so vague that different models are indeed 
theoritically possible. In particular:

  a) the CRL Issuer is nominated by CA 1 that has issued
     the end-user certificate. This case would make sense
     when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
     that role to one or more CRL Issuers. This means that
     a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.

  b) the CRL Issuer is nominated by CA 2 that has issued a CA
     certificate to CA 1. This case would make sense when CA 2
     has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
     certificate is issued by CA 2 to every CRL Issuer. CA 1 may
     then only choose a CRL Issuer that has been granted
     the authorization to issue CRLs by CA 2.

I wonder if I understand correctly the model you proposed, but (please 
correct if wrong) you have a set of trust points to verify the 
certification 
chain, and another set of trust points to verify what you call a 
certification path for the CRL Issuer.

There would be many problems with such a model to define correctly 
validation policies, since the two chains would be unrelated and any CA 
from 
that chain could nominate CRL Issuers used by any CA.

In options a) and b) mentioned above, a single trust point is used to 
validate both the certification chain and the CRL Issuer.

In any case, we need to clarify this topic in 3280bis, whatever the 
clarification will be.

> This algorithm is nothing more than formalism of something you agreed 
> to in 2003 on this list.
> 
> I don't think so.
> 
> [SC: Go back to September 2003 archive of your response to my post and 
tell
> me what is not covered]
> 
> [DP: You would need to be more precise and provide me an extract of what 
you
> 
> refer to]
> 
> [SC: It was short string of e-mails on the subject matter in September 
2003.

Hum !!! Hum !!!
Do not mention "free" assertions when you are not sure about.

Denis

> I am sure you can find it from the archives.  It may be overcome by 
events
> since your recent postings show that you agree with me]
> 
> Denis







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9BQTum059936; Tue, 9 Nov 2004 03:26:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA9BQT9S059935; Tue, 9 Nov 2004 03:26:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA9BQTEq059917 for <[e-mail]>; Tue, 9 Nov 2004 03:26:29 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA9BQS1X026427 for <[e-mail]>; Tue, 9 Nov 2004 06:26:29 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 9 Nov 2004 06:26:22 -0500
Message-ID: <00a101c4c64e$f4ee6770$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA9BQTEq059929
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

See responses in-line in [SC]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Tuesday, November 09, 2004 3:31 AM
To: Russ Housley
Cc: [e-mail]; David A. Cooper
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



Russ,

> Denis:

>> First question: What is a CRL Issuer ?

> RFC 3280 says:

>    CRL issuer: an optional system to which a CA delegates the
>                publication of certificate revocation lists;

True, but thus is vague. Page 43 adds further explanations:

    The cRLIssuer identifies the entity who signs and issues the CRL.
    If present, the cRLIssuer MUST contain at least one an X.500
    distinguished name (DN), ...

So here is a strawman proposal for 3280bis:

"CRL issuer: an authority that issues and signs CRLs. When a CRL is not
signed by the CA itself, the CRL shall be signed by a CRL Issuer identified
in the CRL distribution point extension of the certificate.

{SC: I do not have objections to it, but I am not sure of the difference
between the two.  Also, note that if the certificate issuer signs the CRL,
crlIssuer field must be absent in the CRL DP.]

Note: in the later case, the CRL Issuer certificate shall be issued
       by that CA."

[SC: I have objection to this on two grounds: One, this is a new constraints
and breaks some existing implementations,  Two, if the CA wanted to delegate
all CRL issuance, having this requirement will either cause a circular
problem (insecure) or not permit the CA to promulgate the revocation status
of the certificate issued to the CRL Issuer.]

Denis

> Russ
> 
> 
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA98UjPT038079; Tue, 9 Nov 2004 00:30:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA98UjhY038078; Tue, 9 Nov 2004 00:30:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA98Ug43037981 for <[e-mail]>; Tue, 9 Nov 2004 00:30:44 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA61794; Tue, 9 Nov 2004 09:42:37 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110909303260:72 ; Tue, 9 Nov 2004 09:30:32 +0100 
Message-ID: <[e-mail]>
Date: Tue, 09 Nov 2004 09:30:32 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail], "David A. Cooper" <[e-mail]>
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <[e-mail]> <00b001c4c4f7$81d877b0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/11/2004 09:30:32, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/11/2004 09:30:35, Serialize complete at 09/11/2004 09:30:35
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

> Denis:

>> First question: What is a CRL Issuer ?

> RFC 3280 says:

>    CRL issuer: an optional system to which a CA delegates the
>                publication of certificate revocation lists;

True, but thus is vague. Page 43 adds further explanations:

    The cRLIssuer identifies the entity who signs and issues the CRL.
    If present, the cRLIssuer MUST contain at least one an X.500
    distinguished name (DN), ...

So here is a strawman proposal for 3280bis:

"CRL issuer: an authority that issues and signs CRLs. When a CRL is
not signed by the CA itself, the CRL shall be signed by a CRL Issuer
identified in the CRL distribution point extension of the certificate.

Note: in the later case, the CRL Issuer certificate shall be issued
       by that CA."

Denis

> Russ
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8JoboM088947; Mon, 8 Nov 2004 11:50:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8JobdY088939; Mon, 8 Nov 2004 11:50:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [130.129.135.64] ([130.129.67.27]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8JoX9E088908; Mon, 8 Nov 2004 11:50:34 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06110417bdb57e46b073@[130.129.135.64]>
In-Reply-To: <[e-mail]>
References: <p06110406bda564ea5155@[10.20.30.249]> <[e-mail]>
Date: Mon, 8 Nov 2004 14:50:41 -0500
To: "Sean P. Turner" <[e-mail]>
From: Paul Hoffman / VPNC <[e-mail]>
Subject: Re: Suggestion for revising RFC 3280
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 1:42 PM -0500 11/8/04, Sean P. Turner wrote:
>Or at least have a paragraph that gets removed prior to RFC 
>publication to tell everybody where changes were made.

This is only useful if the stuff that is the summary is a *complete* 
and *exact* changelog. Most of us summarize too far when we write 
these sections. I still would prefer a "changes-only" draft.

--Paul Hoffman, Director
--VPN Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8IiO7W059570; Mon, 8 Nov 2004 10:44:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8IiOFL059569; Mon, 8 Nov 2004 10:44:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp005.bizmail.sc5.yahoo.com (smtp005.bizmail.sc5.yahoo.com [66.163.175.82]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA8IiNnD059551 for <[e-mail]>; Mon, 8 Nov 2004 10:44:24 -0800 (PST) (envelope-from [e-mail])
Received: from unknown (HELO ?127.0.0.1?) ([e-mail]@130.129.133.55 with plain) by smtp005.bizmail.sc5.yahoo.com with SMTP; 8 Nov 2004 18:44:20 -0000
Message-ID: <[e-mail]>
Date: Mon, 08 Nov 2004 13:42:12 -0500
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman / VPNC <[e-mail]>
CC: [e-mail]
Subject: Re: Suggestion for revising RFC 3280
References: <p06110406bda564ea5155@[10.20.30.249]>
In-Reply-To: <p06110406bda564ea5155@[10.20.30.249]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Or at least have a paragraph that gets removed prior to RFC publication 
to tell everybody where changes were made.

spt

Paul Hoffman / VPNC wrote:

>
> Instead of starting rfc3280bis, start a draft called something like 
> "rfc3280-changes". Have that draft be short, and contain *only* 
> changes to 3280. Only after there is consensus on the -changes draft 
> should you roll the changes in.
>
> No one reads all of 3280 these days, so expecting people to search 
> through rfc3280bis for different sections is not reasonable.
>
> --Paul Hoffman, Director
> --VPN Consortium
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8IhI97059279; Mon, 8 Nov 2004 10:43:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8IhI0J059278; Mon, 8 Nov 2004 10:43:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA8IhA1w059242 for <[e-mail]>; Mon, 8 Nov 2004 10:43:10 -0800 (PST) (envelope-from [e-mail])
Received: from unknown (HELO ?127.0.0.1?) ([e-mail]@130.129.133.55 with plain) by smtp003.bizmail.yahoo.com with SMTP; 8 Nov 2004 18:43:07 -0000
Message-ID: <[e-mail]>
Date: Mon, 08 Nov 2004 13:40:55 -0500
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Simon Josefsson <[e-mail]>
CC: [e-mail]
Subject: Re: Please review X.509 part of RFC 2538bis
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>3.  Appropriate Owner Names for CERT RRs
>
>   It is recommended that certificate CERT RRs be stored under a domain
>   name related to their subject, i.e., the name of the entity intended
>   to control the private key corresponding to the public key being
>   certified.  It is recommended that certificate revocation list CERT
>   RRs be stored under a domain name related to their issuer.
>
>  
>
Should "recommended" be "RECOMMENDED" in the 1st and 2nd sentences?

spt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8GhXqf013296; Mon, 8 Nov 2004 08:43:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8GhX9K013295; Mon, 8 Nov 2004 08:43:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8GhWLw013286 for <[e-mail]>; Mon, 8 Nov 2004 08:43:32 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA8GhYRB021003 for <[e-mail]>; Mon, 8 Nov 2004 11:43:35 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Mon, 8 Nov 2004 11:43:34 -0500
Message-ID: <009e01c4c5b2$16d7f9c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA8GhXLw013290
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

When you look at 3280 and add what I propose, what do you see is missing?

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Monday, November 08, 2004 11:35 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting


Santosh,

> Denis,

> What you are describing is already in 3280 and X.509.

If it is the case, would you copy and paste that text, please ? Otherwise, I
understand that you agree with my text.

Denis

> If you identity specific problem with the algorithm, I will be glad to 
> act on it or respond.
> 
> As to Julien scenario, I would generalize that a relying party is not 
> safe if it trusts a rogue CA for all name spaces and policies.  That 
> is a fact of life for the whole PKI, including (but not just for) the 
> path matching algorithm.
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Denis Pinkas
> Sent: Monday, November 08, 2004 9:20 AM
> To: Julien Stern
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> Julien,
> 
> You are quite right. There is a major problem with Santosh's proposal.
> 
> Instead of trying to debug the proposed algorithm, it would be much 
> better
> to describe first what the trust model is.
> 
> Leaving aside indirect CRLs, which may be supported by a trillion of 
> all
> different and unrelated models, there are several questions to answer:
> 
> First question: What is a CRL Issuer ?
> 
> Hereafter is a strawman proposal:
> 
> CRL Issuer : an authority that issues and signs CRLs. When the CRL is 
> not
> signed by the CA itself, the CRL shall be signed by a CRL Issuer
identified 
> in the CRL distribution point extension of the certificate.
> 
> Second question : How is the CRL Issuer identified in the CRL 
> distribution
> point extension of the certificate ?
> 
> Hereafter a strawman response: it is identified using cRLIssuer.
> 
>          cRLIssuer               [2]     GeneralNames
> 
> Third question: which form of name shall be used ?
> 
> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
> 
> GeneralName ::= CHOICE {
>       otherName                       [0]     AnotherName,
>       rfc822Name                      [1]     IA5String,
>       dNSName                         [2]     IA5String,
>       x400Address                     [3]     ORAddress,
>       directoryName                   [4]     Name,
>       ediPartyName                    [5]     EDIPartyName,
>       uniformResourceIdentifier       [6]     IA5String,
>       iPAddress                       [7]     OCTET STRING,
>       registeredID                    [8]     OBJECT IDENTIFIER }
> 
> RFC 3280 states: "the cRLIssuer MUST contain at least one an X.500
> distinguished name (DN)".
> 
> Fourth question: which CA shall certify that name ?
> 
> Neither RFC 3280 nor X.509 provides a response for that question. Put 
> in another way, who will nominate the CRL Issuer and thus will issue 
> the CRL Issuer certificate ?
> 
>   ... and we are back with the two proposals I made (on which I got no
> response from Santosh):
> 
> Here it is again:
> 
> The CRL Issuer is *not* the CA. This CA is called CA 1.
> CA 2 is a CA that has issued a CA certificate to CA 1.
> 
>   a) the CRL Issuer is nominated by CA 1 that has issued
>      the end-user certificate. This case would make sense
>      when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>      that role to one or more CRL Issuers. This means that
>      a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
> 
>   b) the CRL Issuer is nominated by CA 2 that has issued a CA
>      certificate to CA 1. This case would make sense when CA 2
>      has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>      certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>      then only choose a CRL Issuer that has been granted
>      the authorization to issue CRLs by CA 2.
> 
> Other cases are the trillion cases of indirect CRLs.
> 
> Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8GeVJ5012420; Mon, 8 Nov 2004 08:40:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8GeVtO012419; Mon, 8 Nov 2004 08:40:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8GeVJ5012413 for <[e-mail]>; Mon, 8 Nov 2004 08:40:31 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA8GeXRB018510 for <[e-mail]>; Mon, 8 Nov 2004 11:40:33 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Mon, 8 Nov 2004 11:40:33 -0500
Message-ID: <009d01c4c5b1$aab41b70$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA8GeVJ5012414
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Please look at the pkix archives of 11/4/2003 t0 11/6/2003, specifically my
posting, your responses, and my responses to your issues.

The subject of e-mails is "CRL Certification Path"

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Monday, November 08, 2004 9:20 AM
To: Julien Stern
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



Julien,

You are quite right. There is a major problem with Santosh's proposal.

Instead of trying to debug the proposed algorithm, it would be much better 
to describe first what the trust model is.

Leaving aside indirect CRLs, which may be supported by a trillion of all 
different and unrelated models, there are several questions to answer:

First question: What is a CRL Issuer ?

Hereafter is a strawman proposal:

CRL Issuer : an authority that issues and signs CRLs. When the CRL is not 
signed by the CA itself, the CRL shall be signed by a CRL Issuer identified 
in the CRL distribution point extension of the certificate.

Second question : How is the CRL Issuer identified in the CRL distribution 
point extension of the certificate ?

Hereafter a strawman response: it is identified using cRLIssuer.

         cRLIssuer               [2]     GeneralNames

Third question: which form of name shall be used ?

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {
      otherName                       [0]     AnotherName,
      rfc822Name                      [1]     IA5String,
      dNSName                         [2]     IA5String,
      x400Address                     [3]     ORAddress,
      directoryName                   [4]     Name,
      ediPartyName                    [5]     EDIPartyName,
      uniformResourceIdentifier       [6]     IA5String,
      iPAddress                       [7]     OCTET STRING,
      registeredID                    [8]     OBJECT IDENTIFIER }

RFC 3280 states: "the cRLIssuer MUST contain at least one an X.500 
distinguished name (DN)".

Fourth question: which CA shall certify that name ?

Neither RFC 3280 nor X.509 provides a response for that question. Put in
another way, who will nominate the CRL Issuer and thus will issue the 
CRL Issuer certificate ?

  ... and we are back with the two proposals I made (on which I got no 
response from Santosh):

Here it is again:

The CRL Issuer is *not* the CA. This CA is called CA 1.
CA 2 is a CA that has issued a CA certificate to CA 1.

  a) the CRL Issuer is nominated by CA 1 that has issued
     the end-user certificate. This case would make sense
     when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
     that role to one or more CRL Issuers. This means that
     a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.

  b) the CRL Issuer is nominated by CA 2 that has issued a CA
     certificate to CA 1. This case would make sense when CA 2
     has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
     certificate is issued by CA 2 to every CRL Issuer. CA 1 may
     then only choose a CRL Issuer that has been granted
     the authorization to issue CRLs by CA 2.

Other cases are the trillion cases of indirect CRLs.

Denis

>>Julien,
>>
>>In your example also, the rouge CA is not able to impact the behavior 
>>of the certificate chain under the proper CA hierarchy.  There is no 
>>PKI security to a certificate taken alone without a certification path 
>>starting at a trust anchor.  If you trust the certificate chain 
>>starting with a rogue CA, you are in trouble.
>>
>>The rogue CA can only revoke a certificate in its certification path.
> 
> 
> Santosh,
> 
> I just don't understand your reasoning any more.
> I though that the goal of your "path matching algorithm" was to 
> prevent a Rogue CA from revoking certificates issued by an other 
> unrelated CA.
> 
> I though this very stated fairly clearly in 
> draft-ietf-pkix-certpathbuild-04.txt section 8.2 (although you are not 
> listed as a co-author so it may not represent your view (?)).
> 
> If we assume that there is no rogue CA at all then, we do not need to 
> check anything anyway. Now, if we assume there can indeed be a rogue 
> CA, the example I gave you shows that a Rogue CA can _still_ revoke 
> any certificate from any unrelated CA in spite of your proposal.
> 
> We seem to have a disagrement on the core security assumptions. I will 
> attempt in the next days to write a small note to formalize my points, 
> by precisely defining the security model I envision, then maybe we can 
> find the source of our mutual un-understanding.
> 
> --
> Julien
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Julien Stern
>>Sent: Sunday, November 07, 2004 11:04 AM
>>To: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>
>>On Sat, Nov 06, 2004 at 08:22:04PM -0500, Santosh Chokhani wrote:
>>
>>>Julien,
>>>
>>>If you have certification path for the certificate ending at the 
>>>rogue
>>>root, all bets about 3280 not just CRL path matching are off.
>>>
>>>For example, all the rogue PKI hierarchy needs to do is issue the end
>>>certificates (by certifying the legitimate EE public keys) using its 
>>>keys and then it can also issue CRLs even using a key that matches the 
>>>certificate signing keys.
>>
>>Santosh,
>>
>>As I said in my other email,
>>the fact that any CA ("rogue" or not) can issue a cert to any EE and 
>>revoke this very cert is normal behavior. The problem I was 
>>underligning is that a rogue CA can revoke an EE cert already issued 
>>by an _other_ unrelated CA.
>>
>>--
>>Julien
>>
>>
>>>-----Original Message-----
>>>From: [e-mail]
>>>[mailto:[e-mail]] On Behalf Of Julien Stern
>>>Sent: Saturday, November 06, 2004 5:58 PM
>>>To: [e-mail]
>>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>>
>>>
>>>
>>>On Sat, Nov 06, 2004 at 12:02:20PM -0500, Santosh Chokhani wrote:
>>>
>>>>Julien,
>>>>
>>>>Even if a CA down in the chain had the same name as VeriSign, the 
>>>>matching algorithm will work since all the CA DNs starting and 
>>>>including that of the trust anchor and up to the end of the CRL path 
>>>>(in case of direct CRL) must match those in the certificate 
>>>>certification path.  Thus, a downstream VeriSign can not masquerade 
>>>>an upstream VeriSign.
>>>>
>>>>The only way a CA can masquerade as another CA is if all the CASs in 
>>>>their paths (including the trust anchor) have the same DN.  In order 
>>>>for that to happen, a CA at same level must certify two distinct 
>>>>authorities for the same DN.  X.509 does not permit. That.  If CA 
>>>>does this wrong, all bets are off.  For that matter, a CA could post 
>>>>its private key on the Internet.  We do not have defense against 
>>>>that.
>>>
>>>I disagree with the previous paragraph.
>>>What you describe is one way to masquerade as an other CA. My example 
>>>is an other way to do so. You seem to assume that certification paths 
>>>from EE to TAs are unique. If a create a rogue cert which matches a 
>>>real CA DN and key, the path building algorithm might pick my 
>>>certificate.
>>>
>>>Consequently, your algorithm works if
>>>1) No CA issues two certificates to two entities with the same DN. 
>>>AND
>>>2) No CA issues a certificate matching the DN and key of another CA.
>>>
>>>My example uses the second case, not the first one.
>>>
>>>
>>>>You are encouraged to carefully read, analyze, and understand the 
>>>>algorithm.
>>>
>>>I read it very carefully, analyzed it, hopefully understood it, and
>>>actually implemented it. It was during the implementation that what I 
>>>think is a the flaw was highlighted.
>>>
>>>If you also have a implementation, would you like me to produce a set
>>>of certificates which highlight the problem I talking about ?
>>>
>>>--
>>>Julien
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail] 
>>>>[mailto:[e-mail]] On Behalf Of Julien Stern
>>>>Sent: Saturday, November 06, 2004 9:43 AM
>>>>To: [e-mail]
>>>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>>>
>>>>
>>>>
>>>>David,
>>>>
>>>>See response in-line.
>>>>
>>>>On Fri, Nov 05, 2004 at 04:37:52PM -0500, David A. Cooper wrote:
>>>>
>>>>>Julien,
>>>>>
>>>>>I don't believe that the scenario you described indicates a flaw
>>>>>in
>>>>>X.509/RFC 3280. Your scenario begins with the assumption that your 
>>>>>were able to get a CA to issue you a CA certificate with a subject 
>>>>>DN of Verisign (you further assumed that were valid certification 
>>>>>paths from one or more trust anchors used by relying parties to this 
>>>>>CA).
>>>>>
>>>>>Once an attacker has been issued a valid CA certificate the system 
>>>>>is compromised (until the certificate that has been issued to the 
>>>>>attacker has been revoked). In your scenario, you could just as 
>>>>>easily have obtained a CA certificate (with keyCertSign set) with a 
>>>>>public key corresponding to a private key that you knew. You would 
>>>>>then be able to issue bogus certificates, not just revoke 
>>>>>legitimate ones. If an attacker were issued a CA certificate from 
>>>>>one of the CAs in my PKI (such that my relying parties would 
>>>>>validate certificates issued by that CA), that CA's ability to 
>>>>>revoke valid certificates would be the least of my concerns since 
>>>>>the CA could also issue bogus certificates.
>>>>
>>>>I do not think that the issue you describe and the one I described
>>>>are
>>>>situed at the same level.
>>>>
>>>>Let me explain:
>>>>Assume your configuration trusts exactly two TAs, say Verisign and 
>>>>Thawte. Also assume that both of them have a complex hierarchy of 
>>>>CAs
>>>
>>>below them.
>>>
>>>>Now, all the CAs in these two hierarchies can produce "valid" EE 
>>>>certs, that is, certs that will be validated by path verification 
>>>>algorithm.
>>>>
>>>>The fact that one of the CA low in the hierarchy would have the same 
>>>>DN as Verisign does not change anything to the problem. And while 
>>>>this "should not happen", this does not endanger security as long as 
>>>>your TAs are legitimate. If a CA produces bogus certificates, (which 
>>>>cannot be theoretically prevented), its certificate should be 
>>>>revoked, but the DN is irrelevant.
>>>>
>>>>Now, in my (admitedly twisted, my possible) scenario,
>>>>the DN _is_ relevant for security. A dishonest CA with a normal
>>>>unique DN cannot revoke all Verisign certificates, but a dishonest 
>>>>CA with the same
>>>
>>>DN
>>>
>>>>as Verisign could revoke all verisign certificates even if located
>>>>low
>>>
>>>below
>>>
>>>>Thawte hierarchy.
>>>>
>>>>
>>>>>I would also like to point out that a PKI in which two different
>>>>>CAs
>>>>>have the same name is invalid. The algorithm that Santosh has 
>>>>>proposed works to mitigate the damage that would result if two 
>>>>>different CAs in a PKI were using the same DN, but this is a 
>>>>>scenario that should never happen in the first place. From my point 
>>>>>of view, the main benefit of Santosh's proposal is that it improves 
>>>>>efficiency by reducing the number of paths that one needs to 
>>>>>consider during path discovery without putting undue restrictions on 
>>>>>the PKI architecture.
>>>>
>>>>I think Santosh algorithm is very nice, but as you said, it only 
>>>>mitigates the risk, and I believe I proposed a scenario in which I 
>>>>can fool this algorithm.
>>>>
>>>>A also personally agree that a PKI in which two different entities 
>>>>have the same DN is invalid (although the consensus on this does not 
>>>>seem to be general). However, we have to assume it could happen, 
>>>>possibly due to a dishonest participant. And, in fact, for pure 
>>>>certificate path verification, this possibly invalid situation does 
>>>>not adversely affect security. Hence, we also have to ensure that it 
>>>>does not affect security when processing CRLs. We all agree it 
>>>>currently does, and IMHO the issue is not entirely solved by Santosh 
>>>>algorithm. If a CRL signer key belongs to a given CA, I think it has 
>>>>to be cryptographically binded to the CA certificate signing key in 
>>>>some way.
>>>>
>>>>
>>>>>I know that Denis Pinkas has stated: "For X.509, I do *not* say 
>>>>>X.500, a
>>>>>DN is only relative to the CA who has given it." Presumably he is 
>>>>>arguing that it is perfectly legitimate for two CAs in a PKI to have
>>>>
>>the
>>
>>>>>same name; the only requirement being that a CA can not issue two 
>>>>>certificates with the same subject DN in which the subjects are 
>>>>>different entities. If this is the case though, I would like to 
>>>>>know where X.509 says this or even what text in X.509 implies that 
>>>>>this is the case. Section 7 of X.509 states "CAs are unambiguously 
>>>>>defined by
>>>>
>>a
>>
>>>>>distinguished name in the DIT", which seems to contradict Denis'
>>>>
>>claim.
>>
>>>>>In conclusion, in X.509 it is not legitimate for two different
>>>>>entities to have the same DN and it is particularly important to 
>>>>>ensure that two different CAs in a PKI do not use the same DN. At 
>>>>>the same time, defense-in-depth is always a good strategy and in 
>>>>>that light Santosh's algorithm does a good job of protecting 
>>>>>against the risk that a PKI will
>>>>
>>>>>evolve in which two different CAs do use the same DN.
>>>>
>>>>As I have just said before, I personally concur with your analysis, 
>>>>but think that the proposed defence-in-depth is not sufficient and 
>>>>that we need cryptographic binding.
>>>>
>>>>Sincerely,
>>>>
>>>>--
>>>>Julien
>>>>
>>>>
>>>>>Julien Stern wrote:
>>>>>
>>>>>
>>>>>>All,
>>>>>>
>>>>>>I believe X509 and PKIX are even much more flawed with respect to 
>>>>>>CRL validation that underligned by Santosh. The flaw appear as 
>>>>>>soon as it
>>>>>
>>>>>>valid to sign a certificate and a CRL with different keys.
>>>>>>
>>>>>>I think the flaw CANNOT be solved without modifying the existing
>>>>>>certificates or simply disallowing these different keys. Let me
>>>>>>explain:
>>>>>>
>>>>>>We all agree that a CA is defined by name. However, if two CAs
>>>>>>have the same name, one of them may be able to revoke the other 
>>>>>>CA certificates. I believe we agree on this flaw of X509 and 
>>>>>>RFC3280, but I think the algorithm proposed by Santosh does not 
>>>>>>change the situation.
>>>>>>
>>>>>>The flaw is more severe and is due to the fact that, when a CA is 
>>>>>>using two different certificates for signing certificate and 
>>>>>>signing CRLs, they are unrelated. In order to solve the flaw, we 
>>>>>>need to link these two certificates by an other mean that the 
>>>>>>ancestors. Actually, we probably need to sign the CRL signing 
>>>>>>certificate with the certificate signing certificate.
>>>>>>
>>>>>>More precisely, if a CA, _any_ CA, whose certificate validates
>>>>>>with respect to one of your Trust Anchor, agrees to deliver me a 
>>>>>>certificate whose DN is the same DN as Verisign, I will easily be 
>>>>>>able to revoke all Verisign certificates.
>>>>>>
>>>>>>The simple attack goes as follow:
>>>>>>
>>>>>>1) Find any moderately honest CA who agrees to sign me a 
>>>>>>certificate signing certificate and a CRL signing certificate 
>>>>>>whose DNs match Verisign DN.
>>>>>>
>>>>>>2) For the certificate signing certificate, send a CSR whose
>>>>>>public key matches the _real_ Verisign CA certificate.
>>>>>>
>>>>>>3) For the CRL signing certificate, send a CSR whose public key
>>>>>>correspond to a private key I know.
>>>>>>
>>>>>>4) Finally, simply revoke any legitimate Verisign user by
>>>>>>producing CRLs signed with this private key.
>>>>>>
>>>>>>A path building algorithm will have two choices to go up when
>>>>>>validating a Verisign certificate, (that is, two certificate with 
>>>>>>matching DN and key). It it chooses mine, then, the path building 
>>>>>>chain will go up to the same TA as the chain coming from my CRL 
>>>>>>and all the DNs will match.
>>>>>>
>>>>>>Conclusions:
>>>>>>
>>>>>>- The current CRL checking algorithm is flawed
>>>>>>- Santosh proposal solves some problems but unfortunately, not
>>>>>>all
>>>>>>- A possible way to solve the problem would be:
>>>>>>
>>>>>>1) Simply disallow different keys for certificate and CRL signing
>>>>>>2) If different keys are allowed, then the CRL signing key MUST
>>>>>>be
>>>>>>signed with the certificate signing key with an appropriate 
>>>>>>delegation extension (aka ~ indirect CRLs)
>>>>>>
>>>>>
>>>>
>>>
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8GbbMe011773; Mon, 8 Nov 2004 08:37:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8Gbb7w011772; Mon, 8 Nov 2004 08:37:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8GbZ3i011721 for <[e-mail]>; Mon, 8 Nov 2004 08:37:36 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA16344; Mon, 8 Nov 2004 17:49:26 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110817372459:1946 ; Mon, 8 Nov 2004 17:37:24 +0100 
Message-ID: <[e-mail]>
Date: Mon, 08 Nov 2004 17:34:49 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <007701c4c5aa$dc368810$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/11/2004 17:37:24, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/11/2004 17:37:25, Serialize complete at 08/11/2004 17:37:25
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

> Denis,

> What you are describing is already in 3280 and X.509.

If it is the case, would you copy and paste that text, please ?
Otherwise, I understand that you agree with my text.

Denis

> If you identity specific problem with the algorithm, I will be glad to act
> on it or respond.
> 
> As to Julien scenario, I would generalize that a relying party is not safe
> if it trusts a rogue CA for all name spaces and policies.  That is a fact of
> life for the whole PKI, including (but not just for) the path matching
> algorithm.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Denis Pinkas
> Sent: Monday, November 08, 2004 9:20 AM
> To: Julien Stern
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> Julien,
> 
> You are quite right. There is a major problem with Santosh's proposal.
> 
> Instead of trying to debug the proposed algorithm, it would be much better 
> to describe first what the trust model is.
> 
> Leaving aside indirect CRLs, which may be supported by a trillion of all 
> different and unrelated models, there are several questions to answer:
> 
> First question: What is a CRL Issuer ?
> 
> Hereafter is a strawman proposal:
> 
> CRL Issuer : an authority that issues and signs CRLs. When the CRL is not 
> signed by the CA itself, the CRL shall be signed by a CRL Issuer identified 
> in the CRL distribution point extension of the certificate.
> 
> Second question : How is the CRL Issuer identified in the CRL distribution 
> point extension of the certificate ?
> 
> Hereafter a strawman response: it is identified using cRLIssuer.
> 
>          cRLIssuer               [2]     GeneralNames
> 
> Third question: which form of name shall be used ?
> 
> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
> 
> GeneralName ::= CHOICE {
>       otherName                       [0]     AnotherName,
>       rfc822Name                      [1]     IA5String,
>       dNSName                         [2]     IA5String,
>       x400Address                     [3]     ORAddress,
>       directoryName                   [4]     Name,
>       ediPartyName                    [5]     EDIPartyName,
>       uniformResourceIdentifier       [6]     IA5String,
>       iPAddress                       [7]     OCTET STRING,
>       registeredID                    [8]     OBJECT IDENTIFIER }
> 
> RFC 3280 states: "the cRLIssuer MUST contain at least one an X.500 
> distinguished name (DN)".
> 
> Fourth question: which CA shall certify that name ?
> 
> Neither RFC 3280 nor X.509 provides a response for that question. Put in
> another way, who will nominate the CRL Issuer and thus will issue the 
> CRL Issuer certificate ?
> 
>   ... and we are back with the two proposals I made (on which I got no 
> response from Santosh):
> 
> Here it is again:
> 
> The CRL Issuer is *not* the CA. This CA is called CA 1.
> CA 2 is a CA that has issued a CA certificate to CA 1.
> 
>   a) the CRL Issuer is nominated by CA 1 that has issued
>      the end-user certificate. This case would make sense
>      when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
>      that role to one or more CRL Issuers. This means that
>      a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.
> 
>   b) the CRL Issuer is nominated by CA 2 that has issued a CA
>      certificate to CA 1. This case would make sense when CA 2
>      has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
>      certificate is issued by CA 2 to every CRL Issuer. CA 1 may
>      then only choose a CRL Issuer that has been granted
>      the authorization to issue CRLs by CA 2.
> 
> Other cases are the trillion cases of indirect CRLs.
> 
> Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8GMpXQ006550; Mon, 8 Nov 2004 08:22:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8GMpXL006549; Mon, 8 Nov 2004 08:22:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA8GMo9x006531 for <[e-mail]>; Mon, 8 Nov 2004 08:22:50 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 10501 invoked by uid 0); 8 Nov 2004 16:22:47 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (130.129.135.212) by woodstock.binhost.com with SMTP; 8 Nov 2004 16:22:47 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Mon, 08 Nov 2004 11:22:45 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
In-Reply-To: <[e-mail]>
References: <[e-mail]> <00b001c4c4f7$81d877b0$[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

>First question: What is a CRL Issuer ?

RFC 3280 says:

    CRL issuer: an optional system to which a CA delegates the
                publication of certificate revocation lists;

Russ





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8FpmgI096149; Mon, 8 Nov 2004 07:51:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8FpmMO096148; Mon, 8 Nov 2004 07:51:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8FpmBr096137 for <[e-mail]>; Mon, 8 Nov 2004 07:51:48 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA8FpoRB004247 for <[e-mail]>; Mon, 8 Nov 2004 10:51:50 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Mon, 8 Nov 2004 10:51:50 -0500
Message-ID: <007701c4c5aa$dc368810$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA8FpmBr096141
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

What you are describing is already in 3280 and X.509.

If you identity specific problem with the algorithm, I will be glad to act
on it or respond.

As to Julien scenario, I would generalize that a relying party is not safe
if it trusts a rogue CA for all name spaces and policies.  That is a fact of
life for the whole PKI, including (but not just for) the path matching
algorithm.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Monday, November 08, 2004 9:20 AM
To: Julien Stern
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



Julien,

You are quite right. There is a major problem with Santosh's proposal.

Instead of trying to debug the proposed algorithm, it would be much better 
to describe first what the trust model is.

Leaving aside indirect CRLs, which may be supported by a trillion of all 
different and unrelated models, there are several questions to answer:

First question: What is a CRL Issuer ?

Hereafter is a strawman proposal:

CRL Issuer : an authority that issues and signs CRLs. When the CRL is not 
signed by the CA itself, the CRL shall be signed by a CRL Issuer identified 
in the CRL distribution point extension of the certificate.

Second question : How is the CRL Issuer identified in the CRL distribution 
point extension of the certificate ?

Hereafter a strawman response: it is identified using cRLIssuer.

         cRLIssuer               [2]     GeneralNames

Third question: which form of name shall be used ?

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {
      otherName                       [0]     AnotherName,
      rfc822Name                      [1]     IA5String,
      dNSName                         [2]     IA5String,
      x400Address                     [3]     ORAddress,
      directoryName                   [4]     Name,
      ediPartyName                    [5]     EDIPartyName,
      uniformResourceIdentifier       [6]     IA5String,
      iPAddress                       [7]     OCTET STRING,
      registeredID                    [8]     OBJECT IDENTIFIER }

RFC 3280 states: "the cRLIssuer MUST contain at least one an X.500 
distinguished name (DN)".

Fourth question: which CA shall certify that name ?

Neither RFC 3280 nor X.509 provides a response for that question. Put in
another way, who will nominate the CRL Issuer and thus will issue the 
CRL Issuer certificate ?

  ... and we are back with the two proposals I made (on which I got no 
response from Santosh):

Here it is again:

The CRL Issuer is *not* the CA. This CA is called CA 1.
CA 2 is a CA that has issued a CA certificate to CA 1.

  a) the CRL Issuer is nominated by CA 1 that has issued
     the end-user certificate. This case would make sense
     when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
     that role to one or more CRL Issuers. This means that
     a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.

  b) the CRL Issuer is nominated by CA 2 that has issued a CA
     certificate to CA 1. This case would make sense when CA 2
     has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
     certificate is issued by CA 2 to every CRL Issuer. CA 1 may
     then only choose a CRL Issuer that has been granted
     the authorization to issue CRLs by CA 2.

Other cases are the trillion cases of indirect CRLs.

Denis

>>Julien,
>>
>>In your example also, the rouge CA is not able to impact the behavior 
>>of the certificate chain under the proper CA hierarchy.  There is no 
>>PKI security to a certificate taken alone without a certification path 
>>starting at a trust anchor.  If you trust the certificate chain 
>>starting with a rogue CA, you are in trouble.
>>
>>The rogue CA can only revoke a certificate in its certification path.
> 
> 
> Santosh,
> 
> I just don't understand your reasoning any more.
> I though that the goal of your "path matching algorithm" was to 
> prevent a Rogue CA from revoking certificates issued by an other 
> unrelated CA.
> 
> I though this very stated fairly clearly in 
> draft-ietf-pkix-certpathbuild-04.txt section 8.2 (although you are not 
> listed as a co-author so it may not represent your view (?)).
> 
> If we assume that there is no rogue CA at all then, we do not need to 
> check anything anyway. Now, if we assume there can indeed be a rogue 
> CA, the example I gave you shows that a Rogue CA can _still_ revoke 
> any certificate from any unrelated CA in spite of your proposal.
> 
> We seem to have a disagrement on the core security assumptions. I will 
> attempt in the next days to write a small note to formalize my points, 
> by precisely defining the security model I envision, then maybe we can 
> find the source of our mutual un-understanding.
> 
> --
> Julien
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Julien Stern
>>Sent: Sunday, November 07, 2004 11:04 AM
>>To: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>
>>On Sat, Nov 06, 2004 at 08:22:04PM -0500, Santosh Chokhani wrote:
>>
>>>Julien,
>>>
>>>If you have certification path for the certificate ending at the 
>>>rogue
>>>root, all bets about 3280 not just CRL path matching are off.
>>>
>>>For example, all the rogue PKI hierarchy needs to do is issue the end
>>>certificates (by certifying the legitimate EE public keys) using its 
>>>keys and then it can also issue CRLs even using a key that matches the 
>>>certificate signing keys.
>>
>>Santosh,
>>
>>As I said in my other email,
>>the fact that any CA ("rogue" or not) can issue a cert to any EE and 
>>revoke this very cert is normal behavior. The problem I was 
>>underligning is that a rogue CA can revoke an EE cert already issued 
>>by an _other_ unrelated CA.
>>
>>--
>>Julien
>>
>>
>>>-----Original Message-----
>>>From: [e-mail]
>>>[mailto:[e-mail]] On Behalf Of Julien Stern
>>>Sent: Saturday, November 06, 2004 5:58 PM
>>>To: [e-mail]
>>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>>
>>>
>>>
>>>On Sat, Nov 06, 2004 at 12:02:20PM -0500, Santosh Chokhani wrote:
>>>
>>>>Julien,
>>>>
>>>>Even if a CA down in the chain had the same name as VeriSign, the 
>>>>matching algorithm will work since all the CA DNs starting and 
>>>>including that of the trust anchor and up to the end of the CRL path 
>>>>(in case of direct CRL) must match those in the certificate 
>>>>certification path.  Thus, a downstream VeriSign can not masquerade 
>>>>an upstream VeriSign.
>>>>
>>>>The only way a CA can masquerade as another CA is if all the CASs in 
>>>>their paths (including the trust anchor) have the same DN.  In order 
>>>>for that to happen, a CA at same level must certify two distinct 
>>>>authorities for the same DN.  X.509 does not permit. That.  If CA 
>>>>does this wrong, all bets are off.  For that matter, a CA could post 
>>>>its private key on the Internet.  We do not have defense against 
>>>>that.
>>>
>>>I disagree with the previous paragraph.
>>>What you describe is one way to masquerade as an other CA. My example 
>>>is an other way to do so. You seem to assume that certification paths 
>>>from EE to TAs are unique. If a create a rogue cert which matches a 
>>>real CA DN and key, the path building algorithm might pick my 
>>>certificate.
>>>
>>>Consequently, your algorithm works if
>>>1) No CA issues two certificates to two entities with the same DN. 
>>>AND
>>>2) No CA issues a certificate matching the DN and key of another CA.
>>>
>>>My example uses the second case, not the first one.
>>>
>>>
>>>>You are encouraged to carefully read, analyze, and understand the 
>>>>algorithm.
>>>
>>>I read it very carefully, analyzed it, hopefully understood it, and
>>>actually implemented it. It was during the implementation that what I 
>>>think is a the flaw was highlighted.
>>>
>>>If you also have a implementation, would you like me to produce a set
>>>of certificates which highlight the problem I talking about ?
>>>
>>>--
>>>Julien
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail] 
>>>>[mailto:[e-mail]] On Behalf Of Julien Stern
>>>>Sent: Saturday, November 06, 2004 9:43 AM
>>>>To: [e-mail]
>>>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>>>
>>>>
>>>>
>>>>David,
>>>>
>>>>See response in-line.
>>>>
>>>>On Fri, Nov 05, 2004 at 04:37:52PM -0500, David A. Cooper wrote:
>>>>
>>>>>Julien,
>>>>>
>>>>>I don't believe that the scenario you described indicates a flaw
>>>>>in
>>>>>X.509/RFC 3280. Your scenario begins with the assumption that your 
>>>>>were able to get a CA to issue you a CA certificate with a subject 
>>>>>DN of Verisign (you further assumed that were valid certification 
>>>>>paths from one or more trust anchors used by relying parties to this 
>>>>>CA).
>>>>>
>>>>>Once an attacker has been issued a valid CA certificate the system 
>>>>>is compromised (until the certificate that has been issued to the 
>>>>>attacker has been revoked). In your scenario, you could just as 
>>>>>easily have obtained a CA certificate (with keyCertSign set) with a 
>>>>>public key corresponding to a private key that you knew. You would 
>>>>>then be able to issue bogus certificates, not just revoke 
>>>>>legitimate ones. If an attacker were issued a CA certificate from 
>>>>>one of the CAs in my PKI (such that my relying parties would 
>>>>>validate certificates issued by that CA), that CA's ability to 
>>>>>revoke valid certificates would be the least of my concerns since 
>>>>>the CA could also issue bogus certificates.
>>>>
>>>>I do not think that the issue you describe and the one I described
>>>>are
>>>>situed at the same level.
>>>>
>>>>Let me explain:
>>>>Assume your configuration trusts exactly two TAs, say Verisign and 
>>>>Thawte. Also assume that both of them have a complex hierarchy of 
>>>>CAs
>>>
>>>below them.
>>>
>>>>Now, all the CAs in these two hierarchies can produce "valid" EE 
>>>>certs, that is, certs that will be validated by path verification 
>>>>algorithm.
>>>>
>>>>The fact that one of the CA low in the hierarchy would have the same 
>>>>DN as Verisign does not change anything to the problem. And while 
>>>>this "should not happen", this does not endanger security as long as 
>>>>your TAs are legitimate. If a CA produces bogus certificates, (which 
>>>>cannot be theoretically prevented), its certificate should be 
>>>>revoked, but the DN is irrelevant.
>>>>
>>>>Now, in my (admitedly twisted, my possible) scenario,
>>>>the DN _is_ relevant for security. A dishonest CA with a normal
>>>>unique DN cannot revoke all Verisign certificates, but a dishonest 
>>>>CA with the same
>>>
>>>DN
>>>
>>>>as Verisign could revoke all verisign certificates even if located
>>>>low
>>>
>>>below
>>>
>>>>Thawte hierarchy.
>>>>
>>>>
>>>>>I would also like to point out that a PKI in which two different
>>>>>CAs
>>>>>have the same name is invalid. The algorithm that Santosh has 
>>>>>proposed works to mitigate the damage that would result if two 
>>>>>different CAs in a PKI were using the same DN, but this is a 
>>>>>scenario that should never happen in the first place. From my point 
>>>>>of view, the main benefit of Santosh's proposal is that it improves 
>>>>>efficiency by reducing the number of paths that one needs to 
>>>>>consider during path discovery without putting undue restrictions on 
>>>>>the PKI architecture.
>>>>
>>>>I think Santosh algorithm is very nice, but as you said, it only 
>>>>mitigates the risk, and I believe I proposed a scenario in which I 
>>>>can fool this algorithm.
>>>>
>>>>A also personally agree that a PKI in which two different entities 
>>>>have the same DN is invalid (although the consensus on this does not 
>>>>seem to be general). However, we have to assume it could happen, 
>>>>possibly due to a dishonest participant. And, in fact, for pure 
>>>>certificate path verification, this possibly invalid situation does 
>>>>not adversely affect security. Hence, we also have to ensure that it 
>>>>does not affect security when processing CRLs. We all agree it 
>>>>currently does, and IMHO the issue is not entirely solved by Santosh 
>>>>algorithm. If a CRL signer key belongs to a given CA, I think it has 
>>>>to be cryptographically binded to the CA certificate signing key in 
>>>>some way.
>>>>
>>>>
>>>>>I know that Denis Pinkas has stated: "For X.509, I do *not* say 
>>>>>X.500, a
>>>>>DN is only relative to the CA who has given it." Presumably he is 
>>>>>arguing that it is perfectly legitimate for two CAs in a PKI to have
>>>>
>>the
>>
>>>>>same name; the only requirement being that a CA can not issue two 
>>>>>certificates with the same subject DN in which the subjects are 
>>>>>different entities. If this is the case though, I would like to 
>>>>>know where X.509 says this or even what text in X.509 implies that 
>>>>>this is the case. Section 7 of X.509 states "CAs are unambiguously 
>>>>>defined by
>>>>
>>a
>>
>>>>>distinguished name in the DIT", which seems to contradict Denis'
>>>>
>>claim.
>>
>>>>>In conclusion, in X.509 it is not legitimate for two different
>>>>>entities to have the same DN and it is particularly important to 
>>>>>ensure that two different CAs in a PKI do not use the same DN. At 
>>>>>the same time, defense-in-depth is always a good strategy and in 
>>>>>that light Santosh's algorithm does a good job of protecting 
>>>>>against the risk that a PKI will
>>>>
>>>>>evolve in which two different CAs do use the same DN.
>>>>
>>>>As I have just said before, I personally concur with your analysis, 
>>>>but think that the proposed defence-in-depth is not sufficient and 
>>>>that we need cryptographic binding.
>>>>
>>>>Sincerely,
>>>>
>>>>--
>>>>Julien
>>>>
>>>>
>>>>>Julien Stern wrote:
>>>>>
>>>>>
>>>>>>All,
>>>>>>
>>>>>>I believe X509 and PKIX are even much more flawed with respect to 
>>>>>>CRL validation that underligned by Santosh. The flaw appear as 
>>>>>>soon as it
>>>>>
>>>>>>valid to sign a certificate and a CRL with different keys.
>>>>>>
>>>>>>I think the flaw CANNOT be solved without modifying the existing
>>>>>>certificates or simply disallowing these different keys. Let me
>>>>>>explain:
>>>>>>
>>>>>>We all agree that a CA is defined by name. However, if two CAs
>>>>>>have the same name, one of them may be able to revoke the other 
>>>>>>CA certificates. I believe we agree on this flaw of X509 and 
>>>>>>RFC3280, but I think the algorithm proposed by Santosh does not 
>>>>>>change the situation.
>>>>>>
>>>>>>The flaw is more severe and is due to the fact that, when a CA is 
>>>>>>using two different certificates for signing certificate and 
>>>>>>signing CRLs, they are unrelated. In order to solve the flaw, we 
>>>>>>need to link these two certificates by an other mean that the 
>>>>>>ancestors. Actually, we probably need to sign the CRL signing 
>>>>>>certificate with the certificate signing certificate.
>>>>>>
>>>>>>More precisely, if a CA, _any_ CA, whose certificate validates
>>>>>>with respect to one of your Trust Anchor, agrees to deliver me a 
>>>>>>certificate whose DN is the same DN as Verisign, I will easily be 
>>>>>>able to revoke all Verisign certificates.
>>>>>>
>>>>>>The simple attack goes as follow:
>>>>>>
>>>>>>1) Find any moderately honest CA who agrees to sign me a 
>>>>>>certificate signing certificate and a CRL signing certificate 
>>>>>>whose DNs match Verisign DN.
>>>>>>
>>>>>>2) For the certificate signing certificate, send a CSR whose
>>>>>>public key matches the _real_ Verisign CA certificate.
>>>>>>
>>>>>>3) For the CRL signing certificate, send a CSR whose public key
>>>>>>correspond to a private key I know.
>>>>>>
>>>>>>4) Finally, simply revoke any legitimate Verisign user by
>>>>>>producing CRLs signed with this private key.
>>>>>>
>>>>>>A path building algorithm will have two choices to go up when
>>>>>>validating a Verisign certificate, (that is, two certificate with 
>>>>>>matching DN and key). It it chooses mine, then, the path building 
>>>>>>chain will go up to the same TA as the chain coming from my CRL 
>>>>>>and all the DNs will match.
>>>>>>
>>>>>>Conclusions:
>>>>>>
>>>>>>- The current CRL checking algorithm is flawed
>>>>>>- Santosh proposal solves some problems but unfortunately, not
>>>>>>all
>>>>>>- A possible way to solve the problem would be:
>>>>>>
>>>>>>1) Simply disallow different keys for certificate and CRL signing
>>>>>>2) If different keys are allowed, then the CRL signing key MUST
>>>>>>be
>>>>>>signed with the certificate signing key with an appropriate 
>>>>>>delegation extension (aka ~ indirect CRLs)
>>>>>>
>>>>>
>>>>
>>>
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8FEwmF084096; Mon, 8 Nov 2004 07:14:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8FEwvg084095; Mon, 8 Nov 2004 07:14:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8FEvF3084070 for <[e-mail]>; Mon, 8 Nov 2004 07:14:57 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA8FEuRB010281 for <[e-mail]>; Mon, 8 Nov 2004 10:14:57 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Mon, 8 Nov 2004 10:14:56 -0500
Message-ID: <005801c4c5a5$b5100c20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA8FEwF3084090
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

The security of the solution and assumptions are on par with what X.509 and
3280 are based on.

It disambiguates between two CRL Issuer with the same name.

The scenario of a rogue CA can cause all sorts of problems for the relying
party and not just in deciding if the CRL is from the correct issuer.

If the relying party recognizes the difference (which it should) between the
two CAs at the top of the trust graph in your example, then the rogue CA can
not fool the relying party into accepting its certification path and CRL.

Furthermore, you have provided one scenario where a rogue CA can revoke
certificates it did not issue.  I have provided another scenario where the
same rogue CA can fool the relying parties into using its (meaning rogue
CA's) certificates and CRLs for a subscriber.  The point being, that PKI
does not offer much protection against the rogue CA trusted by a relying
party aside from constraining trust graphs with respect to name spaces and
certificate policies.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Monday, November 08, 2004 7:45 AM
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



On Sun, Nov 07, 2004 at 01:27:53PM -0500, Santosh Chokhani wrote:
> Julien,
> 
> In your example also, the rouge CA is not able to impact the behavior 
> of the certificate chain under the proper CA hierarchy.  There is no 
> PKI security to a certificate taken alone without a certification path 
> starting at a trust anchor.  If you trust the certificate chain 
> starting with a rogue CA, you are in trouble.
> 
> The rogue CA can only revoke a certificate in its certification path.

Santosh,

I just don't understand your reasoning any more.
I though that the goal of your "path matching algorithm" was to prevent a
Rogue CA from revoking certificates issued by an other unrelated CA.

I though this very stated fairly clearly in
draft-ietf-pkix-certpathbuild-04.txt section 8.2 (although you are not
listed as a co-author so it may not represent your view (?)).

If we assume that there is no rogue CA at all then, we do not need to check
anything anyway. Now, if we assume there can indeed be a rogue CA, the
example I gave you shows that a Rogue CA can _still_ revoke any certificate
from any unrelated CA in spite of your proposal.

We seem to have a disagrement on the core security assumptions. I will
attempt in the next days to write a small note to formalize my points, by
precisely defining the security model I envision, then maybe we can find the
source of our mutual un-understanding.

--
Julien

> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Sunday, November 07, 2004 11:04 AM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> On Sat, Nov 06, 2004 at 08:22:04PM -0500, Santosh Chokhani wrote:
> > 
> > Julien,
> > 
> > If you have certification path for the certificate ending at the 
> > rogue
> > root, all bets about 3280 not just CRL path matching are off.
> > 
> > For example, all the rogue PKI hierarchy needs to do is issue the 
> > end
> > certificates (by certifying the legitimate EE public keys) using its 
> > keys and then it can also issue CRLs even using a key that matches the 
> > certificate signing keys.
> 
> Santosh,
> 
> As I said in my other email,
> the fact that any CA ("rogue" or not) can issue a cert to any EE and 
> revoke this very cert is normal behavior. The problem I was 
> underligning is that a rogue CA can revoke an EE cert already issued 
> by an _other_ unrelated CA.
> 
> --
> Julien
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Saturday, November 06, 2004 5:58 PM
> > To: [e-mail]
> > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > 
> > On Sat, Nov 06, 2004 at 12:02:20PM -0500, Santosh Chokhani wrote:
> > > 
> > > Julien,
> > > 
> > > Even if a CA down in the chain had the same name as VeriSign, the 
> > > matching algorithm will work since all the CA DNs starting and 
> > > including that of the trust anchor and up to the end of the CRL 
> > > path (in case of direct CRL) must match those in the certificate 
> > > certification path.  Thus, a downstream VeriSign can not 
> > > masquerade an upstream VeriSign.
> > > 
> > > The only way a CA can masquerade as another CA is if all the CASs 
> > > in their paths (including the trust anchor) have the same DN.  In 
> > > order for that to happen, a CA at same level must certify two 
> > > distinct authorities for the same DN.  X.509 does not permit. 
> > > That.  If CA does this wrong, all bets are off.  For that matter, 
> > > a CA could post its private key on the Internet.  We do not have 
> > > defense against that.
> > 
> > I disagree with the previous paragraph.
> > What you describe is one way to masquerade as an other CA. My 
> > example is an other way to do so. You seem to assume that 
> > certification paths from EE to TAs are unique. If a create a rogue 
> > cert which matches a real CA DN and key, the path building algorithm 
> > might pick my certificate.
> > 
> > Consequently, your algorithm works if
> > 1) No CA issues two certificates to two entities with the same DN. 
> > AND
> > 2) No CA issues a certificate matching the DN and key of another CA.
> > 
> > My example uses the second case, not the first one.
> > 
> > > You are encouraged to carefully read, analyze, and understand the 
> > > algorithm.
> > 
> > I read it very carefully, analyzed it, hopefully understood it, and
> > actually implemented it. It was during the implementation that what I 
> > think is a the flaw was highlighted.
> > 
> > If you also have a implementation, would you like me to produce a 
> > set
> > of certificates which highlight the problem I talking about ?
> > 
> > --
> > Julien
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of Julien Stern
> > > Sent: Saturday, November 06, 2004 9:43 AM
> > > To: [e-mail]
> > > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > > 
> > > 
> > > 
> > > David,
> > > 
> > > See response in-line.
> > > 
> > > On Fri, Nov 05, 2004 at 04:37:52PM -0500, David A. Cooper wrote:
> > > > Julien,
> > > > 
> > > > I don't believe that the scenario you described indicates a flaw
> > > > in
> > > > X.509/RFC 3280. Your scenario begins with the assumption that your 
> > > > were able to get a CA to issue you a CA certificate with a subject 
> > > > DN of Verisign (you further assumed that were valid certification 
> > > > paths from one or more trust anchors used by relying parties to this

> > > > CA).
> > > > 
> > > > Once an attacker has been issued a valid CA certificate the 
> > > > system is compromised (until the certificate that has been 
> > > > issued to the attacker has been revoked). In your scenario, you 
> > > > could just as easily have obtained a CA certificate (with 
> > > > keyCertSign set) with a public key corresponding to a private 
> > > > key that you knew. You would then be able to issue bogus 
> > > > certificates, not just revoke legitimate ones. If an attacker 
> > > > were issued a CA certificate from one of the CAs in my PKI (such 
> > > > that my relying parties would validate certificates issued by 
> > > > that CA), that CA's ability to revoke valid certificates would 
> > > > be the least of my concerns since the CA could also issue bogus 
> > > > certificates.
> > > 
> > > I do not think that the issue you describe and the one I described
> > > are
> > > situed at the same level.
> > > 
> > > Let me explain:
> > > Assume your configuration trusts exactly two TAs, say Verisign and 
> > > Thawte. Also assume that both of them have a complex hierarchy of 
> > > CAs
> > below them.
> > > 
> > > Now, all the CAs in these two hierarchies can produce "valid" EE 
> > > certs, that is, certs that will be validated by path verification 
> > > algorithm.
> > > 
> > > The fact that one of the CA low in the hierarchy would have the 
> > > same DN as Verisign does not change anything to the problem. And 
> > > while this "should not happen", this does not endanger security as 
> > > long as your TAs are legitimate. If a CA produces bogus 
> > > certificates, (which cannot be theoretically prevented), its 
> > > certificate should be revoked, but the DN is irrelevant.
> > > 
> > > Now, in my (admitedly twisted, my possible) scenario,
> > > the DN _is_ relevant for security. A dishonest CA with a normal
> > > unique DN cannot revoke all Verisign certificates, but a dishonest 
> > > CA with the same
> > DN
> > > as Verisign could revoke all verisign certificates even if located
> > > low
> > below
> > > Thawte hierarchy.
> > > 
> > > > I would also like to point out that a PKI in which two different
> > > > CAs
> > > > have the same name is invalid. The algorithm that Santosh has 
> > > > proposed works to mitigate the damage that would result if two 
> > > > different CAs in a PKI were using the same DN, but this is a 
> > > > scenario that should never happen in the first place. From my point 
> > > > of view, the main benefit of Santosh's proposal is that it improves 
> > > > efficiency by reducing the number of paths that one needs to 
> > > > consider during path discovery without putting undue restrictions on

> > > > the PKI architecture.
> > > 
> > > I think Santosh algorithm is very nice, but as you said, it only 
> > > mitigates the risk, and I believe I proposed a scenario in which I 
> > > can fool this algorithm.
> > > 
> > > A also personally agree that a PKI in which two different entities 
> > > have the same DN is invalid (although the consensus on this does 
> > > not seem to be general). However, we have to assume it could 
> > > happen, possibly due to a dishonest participant. And, in fact, for 
> > > pure certificate path verification, this possibly invalid 
> > > situation does not adversely affect security. Hence, we also have 
> > > to ensure that it does not affect security when processing CRLs. 
> > > We all agree it currently does, and IMHO the issue is not entirely 
> > > solved by Santosh algorithm. If a CRL signer key belongs to a 
> > > given CA, I think it has to be cryptographically binded to the CA 
> > > certificate signing key in some way.
> > > 
> > > > I know that Denis Pinkas has stated: "For X.509, I do *not* say 
> > > > X.500, a
> > > > DN is only relative to the CA who has given it." Presumably he is 
> > > > arguing that it is perfectly legitimate for two CAs in a PKI to have
> the
> > 
> > > > same name; the only requirement being that a CA can not issue 
> > > > two certificates with the same subject DN in which the subjects 
> > > > are different entities. If this is the case though, I would like 
> > > > to know where X.509 says this or even what text in X.509 implies 
> > > > that this is the case. Section 7 of X.509 states "CAs are 
> > > > unambiguously defined by
> a
> > > > distinguished name in the DIT", which seems to contradict Denis'
> claim.
> > > > 
> > > > In conclusion, in X.509 it is not legitimate for two different
> > > > entities to have the same DN and it is particularly important to 
> > > > ensure that two different CAs in a PKI do not use the same DN. At 
> > > > the same time, defense-in-depth is always a good strategy and in 
> > > > that light Santosh's algorithm does a good job of protecting 
> > > > against the risk that a PKI will
> > 
> > > > evolve in which two different CAs do use the same DN.
> > > 
> > > As I have just said before, I personally concur with your 
> > > analysis, but think that the proposed defence-in-depth is not 
> > > sufficient and that we need cryptographic binding.
> > > 
> > > Sincerely,
> > > 
> > > --
> > > Julien
> > > 
> > > > Julien Stern wrote:
> > > > 
> > > > >All,
> > > > >
> > > > >I believe X509 and PKIX are even much more flawed with respect 
> > > > >to CRL validation that underligned by Santosh. The flaw appear 
> > > > >as soon as it
> 
> > > > >valid to sign a certificate and a CRL with different keys.
> > > > >
> > > > >I think the flaw CANNOT be solved without modifying the 
> > > > >existing
> > > > >certificates or simply disallowing these different keys. Let me
> > > > >explain:
> > > > >
> > > > >We all agree that a CA is defined by name. However, if two CAs
> > > > >have the same name, one of them may be able to revoke the other 
> > > > >CA certificates. I believe we agree on this flaw of X509 and 
> > > > >RFC3280, but I think the algorithm proposed by Santosh does not 
> > > > >change the situation.
> > > > >
> > > > >The flaw is more severe and is due to the fact that, when a CA 
> > > > >is using two different certificates for signing certificate and 
> > > > >signing CRLs, they are unrelated. In order to solve the flaw, 
> > > > >we need to link these two certificates by an other mean that 
> > > > >the ancestors. Actually, we probably need to sign the CRL 
> > > > >signing certificate with the certificate signing certificate.
> > > > >
> > > > >More precisely, if a CA, _any_ CA, whose certificate validates
> > > > >with respect to one of your Trust Anchor, agrees to deliver me a 
> > > > >certificate whose DN is the same DN as Verisign, I will easily be 
> > > > >able to revoke all Verisign certificates.
> > > > >
> > > > >The simple attack goes as follow:
> > > > >
> > > > >1) Find any moderately honest CA who agrees to sign me a 
> > > > >certificate signing certificate and a CRL signing certificate 
> > > > >whose DNs match Verisign DN.
> > > > >
> > > > >2) For the certificate signing certificate, send a CSR whose
> > > > >public key matches the _real_ Verisign CA certificate.
> > > > >
> > > > >3) For the CRL signing certificate, send a CSR whose public key
> > > > >correspond to a private key I know.
> > > > >
> > > > >4) Finally, simply revoke any legitimate Verisign user by
> > > > >producing CRLs signed with this private key.
> > > > >
> > > > >A path building algorithm will have two choices to go up when
> > > > >validating a Verisign certificate, (that is, two certificate with 
> > > > >matching DN and key). It it chooses mine, then, the path building 
> > > > >chain will go up to the same TA as the chain coming from my CRL 
> > > > >and all the DNs will match.
> > > > >
> > > > >Conclusions:
> > > > >
> > > > >- The current CRL checking algorithm is flawed
> > > > >- Santosh proposal solves some problems but unfortunately, not
> > > > >all
> > > > >- A possible way to solve the problem would be:
> > > > >
> > > > >1) Simply disallow different keys for certificate and CRL 
> > > > >signing
> > > > >2) If different keys are allowed, then the CRL signing key MUST 
> > > > >be
> > > > >signed with the certificate signing key with an appropriate 
> > > > >delegation extension (aka ~ indirect CRLs)
> > > > >
> > > > 
> > > 
> > > 
> > 
> > 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8EMYNo066817; Mon, 8 Nov 2004 06:22:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8EMYPQ066816; Mon, 8 Nov 2004 06:22:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8EMW2W066764 for <[e-mail]>; Mon, 8 Nov 2004 06:22:33 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA82848; Mon, 8 Nov 2004 15:34:22 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110815221947:1854 ; Mon, 8 Nov 2004 15:22:19 +0100 
Message-ID: <[e-mail]>
Date: Mon, 08 Nov 2004 15:19:45 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Julien Stern <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <[e-mail]> <00b001c4c4f7$81d877b0$[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/11/2004 15:22:19, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/11/2004 15:22:20, Serialize complete at 08/11/2004 15:22:20
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

You are quite right. There is a major problem with Santosh's proposal.

Instead of trying to debug the proposed algorithm, it would be much better 
to describe first what the trust model is.

Leaving aside indirect CRLs, which may be supported by a trillion of all 
different and unrelated models, there are several questions to answer:

First question: What is a CRL Issuer ?

Hereafter is a strawman proposal:

CRL Issuer : an authority that issues and signs CRLs. When the CRL is not 
signed by the CA itself, the CRL shall be signed by a CRL Issuer identified 
in the CRL distribution point extension of the certificate.

Second question : How is the CRL Issuer identified in the CRL distribution 
point extension of the certificate ?

Hereafter a strawman response: it is identified using cRLIssuer.

         cRLIssuer               [2]     GeneralNames

Third question: which form of name shall be used ?

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {
      otherName                       [0]     AnotherName,
      rfc822Name                      [1]     IA5String,
      dNSName                         [2]     IA5String,
      x400Address                     [3]     ORAddress,
      directoryName                   [4]     Name,
      ediPartyName                    [5]     EDIPartyName,
      uniformResourceIdentifier       [6]     IA5String,
      iPAddress                       [7]     OCTET STRING,
      registeredID                    [8]     OBJECT IDENTIFIER }

RFC 3280 states: "the cRLIssuer MUST contain at least one an X.500 
distinguished name (DN)".

Fourth question: which CA shall certify that name ?

Neither RFC 3280 nor X.509 provides a response for that question.
Put in another way, who will nominate the CRL Issuer and thus will issue the 
CRL Issuer certificate ?

  ... and we are back with the two proposals I made (on which I got no 
response from Santosh):

Here it is again:

The CRL Issuer is *not* the CA. This CA is called CA 1.
CA 2 is a CA that has issued a CA certificate to CA 1.

  a) the CRL Issuer is nominated by CA 1 that has issued
     the end-user certificate. This case would make sense
     when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
     that role to one or more CRL Issuers. This means that
     a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.

  b) the CRL Issuer is nominated by CA 2 that has issued a CA
     certificate to CA 1. This case would make sense when CA 2
     has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
     certificate is issued by CA 2 to every CRL Issuer. CA 1 may
     then only choose a CRL Issuer that has been granted
     the authorization to issue CRLs by CA 2.

Other cases are the trillion cases of indirect CRLs.

Denis

>>Julien,
>>
>>In your example also, the rouge CA is not able to impact the behavior of the
>>certificate chain under the proper CA hierarchy.  There is no PKI security
>>to a certificate taken alone without a certification path starting at a
>>trust anchor.  If you trust the certificate chain starting with a rogue CA,
>>you are in trouble.
>>
>>The rogue CA can only revoke a certificate in its certification path.
> 
> 
> Santosh,
> 
> I just don't understand your reasoning any more.
> I though that the goal of your "path matching algorithm" was to prevent
> a Rogue CA from revoking certificates issued by an other unrelated CA.
> 
> I though this very stated fairly clearly in
> draft-ietf-pkix-certpathbuild-04.txt section 8.2 (although you are not
> listed as a co-author so it may not represent your view (?)).
> 
> If we assume that there is no rogue CA at all then, we do not need to
> check anything anyway. Now, if we assume there can indeed be a rogue CA,
> the example I gave you shows that a Rogue CA can _still_ revoke any
> certificate from any unrelated CA in spite of your proposal.
> 
> We seem to have a disagrement on the core security assumptions. I will
> attempt in the next days to write a small note to formalize my points,
> by precisely defining the security model I envision, then maybe we can
> find the source of our mutual un-understanding.
> 
> --
> Julien
> 
> 
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On
>>Behalf Of Julien Stern
>>Sent: Sunday, November 07, 2004 11:04 AM
>>To: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>
>>On Sat, Nov 06, 2004 at 08:22:04PM -0500, Santosh Chokhani wrote:
>>
>>>Julien,
>>>
>>>If you have certification path for the certificate ending at the rogue 
>>>root, all bets about 3280 not just CRL path matching are off.
>>>
>>>For example, all the rogue PKI hierarchy needs to do is issue the end 
>>>certificates (by certifying the legitimate EE public keys) using its 
>>>keys and then it can also issue CRLs even using a key that matches the 
>>>certificate signing keys.
>>
>>Santosh,
>>
>>As I said in my other email,
>>the fact that any CA ("rogue" or not) can issue a cert to any EE and revoke
>>this very cert is normal behavior. The problem I was underligning is that a
>>rogue CA can revoke an EE cert already issued by an _other_ unrelated CA.
>>
>>--
>>Julien
>>
>>
>>>-----Original Message-----
>>>From: [e-mail] 
>>>[mailto:[e-mail]] On Behalf Of Julien Stern
>>>Sent: Saturday, November 06, 2004 5:58 PM
>>>To: [e-mail]
>>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>>
>>>
>>>
>>>On Sat, Nov 06, 2004 at 12:02:20PM -0500, Santosh Chokhani wrote:
>>>
>>>>Julien,
>>>>
>>>>Even if a CA down in the chain had the same name as VeriSign, the
>>>>matching algorithm will work since all the CA DNs starting and 
>>>>including that of the trust anchor and up to the end of the CRL path 
>>>>(in case of direct CRL) must match those in the certificate 
>>>>certification path.  Thus, a downstream VeriSign can not masquerade an 
>>>>upstream VeriSign.
>>>>
>>>>The only way a CA can masquerade as another CA is if all the CASs in
>>>>their paths (including the trust anchor) have the same DN.  In order 
>>>>for that to happen, a CA at same level must certify two distinct 
>>>>authorities for the same DN.  X.509 does not permit. That.  If CA does 
>>>>this wrong, all bets are off.  For that matter, a CA could post its 
>>>>private key on the Internet.  We do not have defense against that.
>>>
>>>I disagree with the previous paragraph.
>>>What you describe is one way to masquerade as an other CA.
>>>My example is an other way to do so. You seem to assume that 
>>>certification paths from EE to TAs are unique. If a create a rogue 
>>>cert which matches a real CA DN and key, the path building algorithm 
>>>might pick my certificate.
>>>
>>>Consequently, your algorithm works if
>>>1) No CA issues two certificates to two entities with the same DN. AND
>>>2) No CA issues a certificate matching the DN and key of another CA.
>>>
>>>My example uses the second case, not the first one.
>>>
>>>
>>>>You are encouraged to carefully read, analyze, and understand the
>>>>algorithm.
>>>
>>>I read it very carefully, analyzed it, hopefully understood it, and 
>>>actually implemented it. It was during the implementation that what I 
>>>think is a the flaw was highlighted.
>>>
>>>If you also have a implementation, would you like me to produce a set 
>>>of certificates which highlight the problem I talking about ?
>>>
>>>--
>>>Julien
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>>[mailto:[e-mail]] On Behalf Of Julien Stern
>>>>Sent: Saturday, November 06, 2004 9:43 AM
>>>>To: [e-mail]
>>>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>>>
>>>>
>>>>
>>>>David,
>>>>
>>>>See response in-line.
>>>>
>>>>On Fri, Nov 05, 2004 at 04:37:52PM -0500, David A. Cooper wrote:
>>>>
>>>>>Julien,
>>>>>
>>>>>I don't believe that the scenario you described indicates a flaw 
>>>>>in
>>>>>X.509/RFC 3280. Your scenario begins with the assumption that your 
>>>>>were able to get a CA to issue you a CA certificate with a subject 
>>>>>DN of Verisign (you further assumed that were valid certification 
>>>>>paths from one or more trust anchors used by relying parties to this 
>>>>>CA).
>>>>>
>>>>>Once an attacker has been issued a valid CA certificate the system
>>>>>is compromised (until the certificate that has been issued to the 
>>>>>attacker has been revoked). In your scenario, you could just as 
>>>>>easily have obtained a CA certificate (with keyCertSign set) with a 
>>>>>public key corresponding to a private key that you knew. You would 
>>>>>then be able to issue bogus certificates, not just revoke legitimate 
>>>>>ones. If an attacker were issued a CA certificate from one of the 
>>>>>CAs in my PKI (such that my relying parties would validate 
>>>>>certificates issued by that CA), that CA's ability to revoke valid 
>>>>>certificates would be the least of my concerns since the CA could 
>>>>>also issue bogus certificates.
>>>>
>>>>I do not think that the issue you describe and the one I described 
>>>>are
>>>>situed at the same level.
>>>>
>>>>Let me explain:
>>>>Assume your configuration trusts exactly two TAs, say Verisign and
>>>>Thawte. Also assume that both of them have a complex hierarchy of CAs
>>>
>>>below them.
>>>
>>>>Now, all the CAs in these two hierarchies can produce "valid" EE
>>>>certs, that is, certs that will be validated by path verification 
>>>>algorithm.
>>>>
>>>>The fact that one of the CA low in the hierarchy would have the same
>>>>DN as Verisign does not change anything to the problem. And while this 
>>>>"should not happen", this does not endanger security as long as your 
>>>>TAs are legitimate. If a CA produces bogus certificates, (which cannot 
>>>>be theoretically prevented), its certificate should be revoked, but 
>>>>the DN is irrelevant.
>>>>
>>>>Now, in my (admitedly twisted, my possible) scenario,
>>>>the DN _is_ relevant for security. A dishonest CA with a normal 
>>>>unique DN cannot revoke all Verisign certificates, but a dishonest 
>>>>CA with the same
>>>
>>>DN
>>>
>>>>as Verisign could revoke all verisign certificates even if located 
>>>>low
>>>
>>>below
>>>
>>>>Thawte hierarchy.
>>>>
>>>>
>>>>>I would also like to point out that a PKI in which two different 
>>>>>CAs
>>>>>have the same name is invalid. The algorithm that Santosh has 
>>>>>proposed works to mitigate the damage that would result if two 
>>>>>different CAs in a PKI were using the same DN, but this is a 
>>>>>scenario that should never happen in the first place. From my point 
>>>>>of view, the main benefit of Santosh's proposal is that it improves 
>>>>>efficiency by reducing the number of paths that one needs to 
>>>>>consider during path discovery without putting undue restrictions on 
>>>>>the PKI architecture.
>>>>
>>>>I think Santosh algorithm is very nice, but as you said, it only
>>>>mitigates the risk, and I believe I proposed a scenario in which I can 
>>>>fool this algorithm.
>>>>
>>>>A also personally agree that a PKI in which two different entities
>>>>have the same DN is invalid (although the consensus on this does not 
>>>>seem to be general). However, we have to assume it could happen, 
>>>>possibly due to a dishonest participant. And, in fact, for pure 
>>>>certificate path verification, this possibly invalid situation does 
>>>>not adversely affect security. Hence, we also have to ensure that it 
>>>>does not affect security when processing CRLs. We all agree it 
>>>>currently does, and IMHO the issue is not entirely solved by Santosh 
>>>>algorithm. If a CRL signer key belongs to a given CA, I think it has 
>>>>to be cryptographically binded to the CA certificate signing key in 
>>>>some way.
>>>>
>>>>
>>>>>I know that Denis Pinkas has stated: "For X.509, I do *not* say
>>>>>X.500,
>>>>>a
>>>>>DN is only relative to the CA who has given it." Presumably he is 
>>>>>arguing that it is perfectly legitimate for two CAs in a PKI to have
>>>>
>>the
>>
>>>>>same name; the only requirement being that a CA can not issue two
>>>>>certificates with the same subject DN in which the subjects are 
>>>>>different entities. If this is the case though, I would like to know 
>>>>>where X.509 says this or even what text in X.509 implies that this is 
>>>>>the case. Section 7 of X.509 states "CAs are unambiguously defined by
>>>>
>>a 
>>
>>>>>distinguished name in the DIT", which seems to contradict Denis'
>>>>
>>claim.
>>
>>>>>In conclusion, in X.509 it is not legitimate for two different 
>>>>>entities to have the same DN and it is particularly important to 
>>>>>ensure that two different CAs in a PKI do not use the same DN. At 
>>>>>the same time, defense-in-depth is always a good strategy and in 
>>>>>that light Santosh's algorithm does a good job of protecting 
>>>>>against the risk that a PKI will
>>>>
>>>>>evolve in which two different CAs do use the same DN.
>>>>
>>>>As I have just said before, I personally concur with your analysis,
>>>>but think that the proposed defence-in-depth is not sufficient and 
>>>>that we need cryptographic binding.
>>>>
>>>>Sincerely,
>>>>
>>>>--
>>>>Julien
>>>>
>>>>
>>>>>Julien Stern wrote:
>>>>>
>>>>>
>>>>>>All,
>>>>>>
>>>>>>I believe X509 and PKIX are even much more flawed with respect to
>>>>>>CRL
>>>>>>validation that underligned by Santosh. The flaw appear as soon as it
>>>>>
>>>>>>valid to sign a certificate and a CRL with different keys.
>>>>>>
>>>>>>I think the flaw CANNOT be solved without modifying the existing 
>>>>>>certificates or simply disallowing these different keys. Let me
>>>>>>explain:
>>>>>>
>>>>>>We all agree that a CA is defined by name. However, if two CAs 
>>>>>>have the same name, one of them may be able to revoke the other 
>>>>>>CA certificates. I believe we agree on this flaw of X509 and 
>>>>>>RFC3280, but I think the algorithm proposed by Santosh does not 
>>>>>>change the situation.
>>>>>>
>>>>>>The flaw is more severe and is due to the fact that, when a CA is
>>>>>>using two different certificates for signing certificate and 
>>>>>>signing CRLs, they are unrelated. In order to solve the flaw, we 
>>>>>>need to link these two certificates by an other mean that the 
>>>>>>ancestors. Actually, we probably need to sign the CRL signing 
>>>>>>certificate with the certificate signing certificate.
>>>>>>
>>>>>>More precisely, if a CA, _any_ CA, whose certificate validates 
>>>>>>with respect to one of your Trust Anchor, agrees to deliver me a 
>>>>>>certificate whose DN is the same DN as Verisign, I will easily be 
>>>>>>able to revoke all Verisign certificates.
>>>>>>
>>>>>>The simple attack goes as follow:
>>>>>>
>>>>>>1) Find any moderately honest CA who agrees to sign me a
>>>>>>certificate
>>>>>>signing certificate and a CRL signing certificate whose DNs match 
>>>>>>Verisign DN.
>>>>>>
>>>>>>2) For the certificate signing certificate, send a CSR whose 
>>>>>>public key matches the _real_ Verisign CA certificate.
>>>>>>
>>>>>>3) For the CRL signing certificate, send a CSR whose public key 
>>>>>>correspond to a private key I know.
>>>>>>
>>>>>>4) Finally, simply revoke any legitimate Verisign user by 
>>>>>>producing CRLs signed with this private key.
>>>>>>
>>>>>>A path building algorithm will have two choices to go up when 
>>>>>>validating a Verisign certificate, (that is, two certificate with 
>>>>>>matching DN and key). It it chooses mine, then, the path building 
>>>>>>chain will go up to the same TA as the chain coming from my CRL 
>>>>>>and all the DNs will match.
>>>>>>
>>>>>>Conclusions:
>>>>>>
>>>>>>- The current CRL checking algorithm is flawed
>>>>>>- Santosh proposal solves some problems but unfortunately, not 
>>>>>>all
>>>>>>- A possible way to solve the problem would be:
>>>>>>
>>>>>>1) Simply disallow different keys for certificate and CRL signing
>>>>>>2) If different keys are allowed, then the CRL signing key MUST 
>>>>>>be
>>>>>>signed with the certificate signing key with an appropriate 
>>>>>>delegation extension (aka ~ indirect CRLs)
>>>>>>
>>>>>
>>>>
>>>
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8Cit49031067; Mon, 8 Nov 2004 04:44:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA8CitbJ031066; Mon, 8 Nov 2004 04:44:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA8CioNc030989 for <[e-mail]>; Mon, 8 Nov 2004 04:44:54 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 6946941D4B for <[e-mail]>; Mon,  8 Nov 2004 13:44:37 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id EFA38440E7 for <[e-mail]>; Mon,  8 Nov 2004 13:45:08 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16950-03 for <[e-mail]>; Mon, 8 Nov 2004 13:45:04 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id DF08A440AE for <[e-mail]>; Mon,  8 Nov 2004 13:45:04 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon,  8 Nov 2004 13:44:33 +0100
From: "Julien Stern" <[e-mail]>
Date: Mon, 8 Nov 2004 13:44:33 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <00b001c4c4f7$81d877b0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00b001c4c4f7$81d877b0$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, Nov 07, 2004 at 01:27:53PM -0500, Santosh Chokhani wrote:
> Julien,
> 
> In your example also, the rouge CA is not able to impact the behavior of the
> certificate chain under the proper CA hierarchy.  There is no PKI security
> to a certificate taken alone without a certification path starting at a
> trust anchor.  If you trust the certificate chain starting with a rogue CA,
> you are in trouble.
> 
> The rogue CA can only revoke a certificate in its certification path.

Santosh,

I just don't understand your reasoning any more.
I though that the goal of your "path matching algorithm" was to prevent
a Rogue CA from revoking certificates issued by an other unrelated CA.

I though this very stated fairly clearly in
draft-ietf-pkix-certpathbuild-04.txt section 8.2 (although you are not
listed as a co-author so it may not represent your view (?)).

If we assume that there is no rogue CA at all then, we do not need to
check anything anyway. Now, if we assume there can indeed be a rogue CA,
the example I gave you shows that a Rogue CA can _still_ revoke any
certificate from any unrelated CA in spite of your proposal.

We seem to have a disagrement on the core security assumptions. I will
attempt in the next days to write a small note to formalize my points,
by precisely defining the security model I envision, then maybe we can
find the source of our mutual un-understanding.

--
Julien

> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Julien Stern
> Sent: Sunday, November 07, 2004 11:04 AM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> On Sat, Nov 06, 2004 at 08:22:04PM -0500, Santosh Chokhani wrote:
> > 
> > Julien,
> > 
> > If you have certification path for the certificate ending at the rogue 
> > root, all bets about 3280 not just CRL path matching are off.
> > 
> > For example, all the rogue PKI hierarchy needs to do is issue the end 
> > certificates (by certifying the legitimate EE public keys) using its 
> > keys and then it can also issue CRLs even using a key that matches the 
> > certificate signing keys.
> 
> Santosh,
> 
> As I said in my other email,
> the fact that any CA ("rogue" or not) can issue a cert to any EE and revoke
> this very cert is normal behavior. The problem I was underligning is that a
> rogue CA can revoke an EE cert already issued by an _other_ unrelated CA.
> 
> --
> Julien
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Saturday, November 06, 2004 5:58 PM
> > To: [e-mail]
> > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > 
> > On Sat, Nov 06, 2004 at 12:02:20PM -0500, Santosh Chokhani wrote:
> > > 
> > > Julien,
> > > 
> > > Even if a CA down in the chain had the same name as VeriSign, the
> > > matching algorithm will work since all the CA DNs starting and 
> > > including that of the trust anchor and up to the end of the CRL path 
> > > (in case of direct CRL) must match those in the certificate 
> > > certification path.  Thus, a downstream VeriSign can not masquerade an 
> > > upstream VeriSign.
> > > 
> > > The only way a CA can masquerade as another CA is if all the CASs in
> > > their paths (including the trust anchor) have the same DN.  In order 
> > > for that to happen, a CA at same level must certify two distinct 
> > > authorities for the same DN.  X.509 does not permit. That.  If CA does 
> > > this wrong, all bets are off.  For that matter, a CA could post its 
> > > private key on the Internet.  We do not have defense against that.
> > 
> > I disagree with the previous paragraph.
> > What you describe is one way to masquerade as an other CA.
> > My example is an other way to do so. You seem to assume that 
> > certification paths from EE to TAs are unique. If a create a rogue 
> > cert which matches a real CA DN and key, the path building algorithm 
> > might pick my certificate.
> > 
> > Consequently, your algorithm works if
> > 1) No CA issues two certificates to two entities with the same DN. AND
> > 2) No CA issues a certificate matching the DN and key of another CA.
> > 
> > My example uses the second case, not the first one.
> > 
> > > You are encouraged to carefully read, analyze, and understand the
> > > algorithm.
> > 
> > I read it very carefully, analyzed it, hopefully understood it, and 
> > actually implemented it. It was during the implementation that what I 
> > think is a the flaw was highlighted.
> > 
> > If you also have a implementation, would you like me to produce a set 
> > of certificates which highlight the problem I talking about ?
> > 
> > --
> > Julien
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Julien Stern
> > > Sent: Saturday, November 06, 2004 9:43 AM
> > > To: [e-mail]
> > > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > > 
> > > 
> > > 
> > > David,
> > > 
> > > See response in-line.
> > > 
> > > On Fri, Nov 05, 2004 at 04:37:52PM -0500, David A. Cooper wrote:
> > > > Julien,
> > > > 
> > > > I don't believe that the scenario you described indicates a flaw 
> > > > in
> > > > X.509/RFC 3280. Your scenario begins with the assumption that your 
> > > > were able to get a CA to issue you a CA certificate with a subject 
> > > > DN of Verisign (you further assumed that were valid certification 
> > > > paths from one or more trust anchors used by relying parties to this 
> > > > CA).
> > > > 
> > > > Once an attacker has been issued a valid CA certificate the system
> > > > is compromised (until the certificate that has been issued to the 
> > > > attacker has been revoked). In your scenario, you could just as 
> > > > easily have obtained a CA certificate (with keyCertSign set) with a 
> > > > public key corresponding to a private key that you knew. You would 
> > > > then be able to issue bogus certificates, not just revoke legitimate 
> > > > ones. If an attacker were issued a CA certificate from one of the 
> > > > CAs in my PKI (such that my relying parties would validate 
> > > > certificates issued by that CA), that CA's ability to revoke valid 
> > > > certificates would be the least of my concerns since the CA could 
> > > > also issue bogus certificates.
> > > 
> > > I do not think that the issue you describe and the one I described 
> > > are
> > > situed at the same level.
> > > 
> > > Let me explain:
> > > Assume your configuration trusts exactly two TAs, say Verisign and
> > > Thawte. Also assume that both of them have a complex hierarchy of CAs
> > below them.
> > > 
> > > Now, all the CAs in these two hierarchies can produce "valid" EE
> > > certs, that is, certs that will be validated by path verification 
> > > algorithm.
> > > 
> > > The fact that one of the CA low in the hierarchy would have the same
> > > DN as Verisign does not change anything to the problem. And while this 
> > > "should not happen", this does not endanger security as long as your 
> > > TAs are legitimate. If a CA produces bogus certificates, (which cannot 
> > > be theoretically prevented), its certificate should be revoked, but 
> > > the DN is irrelevant.
> > > 
> > > Now, in my (admitedly twisted, my possible) scenario,
> > > the DN _is_ relevant for security. A dishonest CA with a normal 
> > > unique DN cannot revoke all Verisign certificates, but a dishonest 
> > > CA with the same
> > DN
> > > as Verisign could revoke all verisign certificates even if located 
> > > low
> > below
> > > Thawte hierarchy.
> > > 
> > > > I would also like to point out that a PKI in which two different 
> > > > CAs
> > > > have the same name is invalid. The algorithm that Santosh has 
> > > > proposed works to mitigate the damage that would result if two 
> > > > different CAs in a PKI were using the same DN, but this is a 
> > > > scenario that should never happen in the first place. From my point 
> > > > of view, the main benefit of Santosh's proposal is that it improves 
> > > > efficiency by reducing the number of paths that one needs to 
> > > > consider during path discovery without putting undue restrictions on 
> > > > the PKI architecture.
> > > 
> > > I think Santosh algorithm is very nice, but as you said, it only
> > > mitigates the risk, and I believe I proposed a scenario in which I can 
> > > fool this algorithm.
> > > 
> > > A also personally agree that a PKI in which two different entities
> > > have the same DN is invalid (although the consensus on this does not 
> > > seem to be general). However, we have to assume it could happen, 
> > > possibly due to a dishonest participant. And, in fact, for pure 
> > > certificate path verification, this possibly invalid situation does 
> > > not adversely affect security. Hence, we also have to ensure that it 
> > > does not affect security when processing CRLs. We all agree it 
> > > currently does, and IMHO the issue is not entirely solved by Santosh 
> > > algorithm. If a CRL signer key belongs to a given CA, I think it has 
> > > to be cryptographically binded to the CA certificate signing key in 
> > > some way.
> > > 
> > > > I know that Denis Pinkas has stated: "For X.509, I do *not* say
> > > > X.500,
> > > > a
> > > > DN is only relative to the CA who has given it." Presumably he is 
> > > > arguing that it is perfectly legitimate for two CAs in a PKI to have
> the
> > 
> > > > same name; the only requirement being that a CA can not issue two
> > > > certificates with the same subject DN in which the subjects are 
> > > > different entities. If this is the case though, I would like to know 
> > > > where X.509 says this or even what text in X.509 implies that this is 
> > > > the case. Section 7 of X.509 states "CAs are unambiguously defined by
> a 
> > > > distinguished name in the DIT", which seems to contradict Denis'
> claim.
> > > > 
> > > > In conclusion, in X.509 it is not legitimate for two different 
> > > > entities to have the same DN and it is particularly important to 
> > > > ensure that two different CAs in a PKI do not use the same DN. At 
> > > > the same time, defense-in-depth is always a good strategy and in 
> > > > that light Santosh's algorithm does a good job of protecting 
> > > > against the risk that a PKI will
> > 
> > > > evolve in which two different CAs do use the same DN.
> > > 
> > > As I have just said before, I personally concur with your analysis,
> > > but think that the proposed defence-in-depth is not sufficient and 
> > > that we need cryptographic binding.
> > > 
> > > Sincerely,
> > > 
> > > --
> > > Julien
> > > 
> > > > Julien Stern wrote:
> > > > 
> > > > >All,
> > > > >
> > > > >I believe X509 and PKIX are even much more flawed with respect to
> > > > >CRL
> > > > >validation that underligned by Santosh. The flaw appear as soon as it
> 
> > > > >valid to sign a certificate and a CRL with different keys.
> > > > >
> > > > >I think the flaw CANNOT be solved without modifying the existing 
> > > > >certificates or simply disallowing these different keys. Let me
> > > > >explain:
> > > > >
> > > > >We all agree that a CA is defined by name. However, if two CAs 
> > > > >have the same name, one of them may be able to revoke the other 
> > > > >CA certificates. I believe we agree on this flaw of X509 and 
> > > > >RFC3280, but I think the algorithm proposed by Santosh does not 
> > > > >change the situation.
> > > > >
> > > > >The flaw is more severe and is due to the fact that, when a CA is
> > > > >using two different certificates for signing certificate and 
> > > > >signing CRLs, they are unrelated. In order to solve the flaw, we 
> > > > >need to link these two certificates by an other mean that the 
> > > > >ancestors. Actually, we probably need to sign the CRL signing 
> > > > >certificate with the certificate signing certificate.
> > > > >
> > > > >More precisely, if a CA, _any_ CA, whose certificate validates 
> > > > >with respect to one of your Trust Anchor, agrees to deliver me a 
> > > > >certificate whose DN is the same DN as Verisign, I will easily be 
> > > > >able to revoke all Verisign certificates.
> > > > >
> > > > >The simple attack goes as follow:
> > > > >
> > > > >1) Find any moderately honest CA who agrees to sign me a
> > > > >certificate
> > > > >signing certificate and a CRL signing certificate whose DNs match 
> > > > >Verisign DN.
> > > > >
> > > > >2) For the certificate signing certificate, send a CSR whose 
> > > > >public key matches the _real_ Verisign CA certificate.
> > > > >
> > > > >3) For the CRL signing certificate, send a CSR whose public key 
> > > > >correspond to a private key I know.
> > > > >
> > > > >4) Finally, simply revoke any legitimate Verisign user by 
> > > > >producing CRLs signed with this private key.
> > > > >
> > > > >A path building algorithm will have two choices to go up when 
> > > > >validating a Verisign certificate, (that is, two certificate with 
> > > > >matching DN and key). It it chooses mine, then, the path building 
> > > > >chain will go up to the same TA as the chain coming from my CRL 
> > > > >and all the DNs will match.
> > > > >
> > > > >Conclusions:
> > > > >
> > > > >- The current CRL checking algorithm is flawed
> > > > >- Santosh proposal solves some problems but unfortunately, not 
> > > > >all
> > > > >- A possible way to solve the problem would be:
> > > > >
> > > > >1) Simply disallow different keys for certificate and CRL signing
> > > > >2) If different keys are allowed, then the CRL signing key MUST 
> > > > >be
> > > > >signed with the certificate signing key with an appropriate 
> > > > >delegation extension (aka ~ indirect CRLs)
> > > > >
> > > > 
> > > 
> > > 
> > 
> > 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7J3cQb096066; Sun, 7 Nov 2004 11:03:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA7J3cIM096065; Sun, 7 Nov 2004 11:03:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7J3UTh095948 for <[e-mail]>; Sun, 7 Nov 2004 11:03:31 -0800 (PST) (envelope-from [e-mail])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 7 Nov 2004 20:01:38 +0100
Received: from [10.193.106.36] ([10.193.106.36]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Sun, 7 Nov 2004 20:01:37 +0100
Message-ID: <[e-mail]>
Date: Sun, 07 Nov 2004 20:01:38 +0100
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom - Research & Development
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Simon Josefsson <[e-mail]>
CC: [e-mail]
Subject: Re: Please review X.509 part of RFC 2538bis
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Nov 2004 19:01:37.0940 (UTC) FILETIME=[355E6D40:01C4C4FC]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon,

Simon Josefsson wrote:
> 
> 2.3  X.509 OIDs
> 
>    OIDs have been defined in connection with the X.500 directory for
>    user certificates, certification authority certificates, revocations
>    of certification authority, and revocations of user certificates.
>    The following table lists the OIDs, their BER encoding, and their
>    length prefixed hex format for use in CERT RRs:
> 
>        id-at-userCertificate
>            = { joint-iso-ccitt(2) ds(5) at(4) 36 }
>               == 0x 03 55 04 24
>        id-at-cACertificate
>            = { joint-iso-ccitt(2) ds(5) at(4) 37 }
>               == 0x 03 55 04 25
>        id-at-authorityRevocationList
>            = { joint-iso-ccitt(2) ds(5) at(4) 38 }
>               == 0x 03 55 04 26
>        id-at-certificateRevocationList
>            = { joint-iso-ccitt(2) ds(5) at(4) 39 }
>               == 0x 03 55 04 27

According to the OID repository at http://oid.elibel.tm.fr these 4 OIDs 
are correct.
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7IaTYR086305; Sun, 7 Nov 2004 10:36:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA7IaTDR086304; Sun, 7 Nov 2004 10:36:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7IaSlU086298 for <[e-mail]>; Sun, 7 Nov 2004 10:36:28 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA7IaVRB028943 for <[e-mail]>; Sun, 7 Nov 2004 13:36:31 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Sun, 7 Nov 2004 13:36:25 -0500
Message-ID: <00b301c4c4f8$b3469f60$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA7IaTlU086299
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

X.509 and 3280 does not make any claim to security once you start trusting
rogue CAs.

The rogue CA behavior is limited to its tree.  Once, it creates a
certificate for another CA, the rest of the tree becomes part of its tree,

If you used the rule that the certificate and CRL must be signed by the same
key, that will not protect you since the rogue CA will move down the
hierarchy one step and issue the certificates to the relying parties
directly and revoke them, in effect achieving the same effect.

That is why I am saying that there is no secure way to provide security once
there is a rogue CA in the relying party trust chain.

The basic point is that in light of rogue CA, even the requirement that the
certificate and CRL be verified using the same public key does not protect
the relying party.  I assume you agree with that scenario.

Thus, all solutions are equally unsecure when the relying party ends up
trusting a rogue CA, which is what you expect.  That is why CAs need to be
trusted.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Sunday, November 07, 2004 11:01 AM
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



On Sat, Nov 06, 2004 at 08:31:25PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> The rogue PKI hierarchy can get around the certificate and CRL being 
> signed using the same key by simply re-issuing the legitimate end 
> entities certificates and then revoking or not revoking certificates.
> 
> EE legitimate key certified by CA3 (DN2/KEY2) -> CA3 (DN2/KEY2) -> 
> ROGUECA
> (DN3)
> 
> Now using DN2, KEY2 to sign CRL will provide crypto binding and still 
> fool you.

Santosh,

The ROGUE CA will indeed be able to issue a certificate to a user and revoke
this very certificate that it has issued, which is perfectly normal, because
it actually issued it. This behavior is not even "rogue": a EE certificate
can have two different CAs certifying him.

The unintended behavior I was underligning was that, in the context I
described, the rogue CA can revoke existing EE certificates issued by an
other CA.

> The basic point is if a relying party trusts a rogue trust anchor, PKI 
> security will go to hell.

I was not talking about a rogue TA, I was talking about a rogue CA possibly
low in the hierarchy that could impersonate (CRL wise) an other CA in a
totally unrelated hierarchy.

As soon as there is a Rogue CA, PKI security goes to hell. But this should
be limited to the tree under this Rogue CA, and not affect all the unrelated
hierarchies as it is the case now.

--
Julien

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Saturday, November 06, 2004 6:09 PM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> On Sat, Nov 06, 2004 at 12:12:36PM -0500, Santosh Chokhani wrote:
> > 
> > Julien,
> > 
> > One more thing.
> > 
> > Even in your example, only the certificates related to hierarchy
> > underneath the rouge CA will be screwed it.  Even if you relied on the 
> > rouge CA, the name matching algorithm will be robust with respect to 
> > the other PKI hierarchies.
> > 
> > The proposal does prevent the attack since DN1 and DN 3 are not the
> > same. Hence CRL certification path will not match that of the 
> > certificate certification path.  Please look at the check under the 
> > first bullet in slide 12.
> 
> Santosh,
> 
> I understand the name matching algorithm. However, you assume that the 
> path builder will pick the path EE -> CA2 (DN2/KEY1) -> CA1 (DN1)
> 
> whereas it could AS WELL pick the path
> EE -> CA3 (DN2/KEY1) -> ROGUECA (DN3)
> 
> which is as valid as the first one.
> In that case, the name matching algorithm will perfectly work,
> because the CRL path is
> FakeCRL -> CA3 (DN2/KEY2) -> ROGUECA (DN3)
> 
> The whole idea of the attack is that a rogue CA can produce a 
> certificate which matches the DN and KEY of an existing cert. Of 
> course, this certificate will be useless, because the private key will 
> not be known, but it may allow to fool the path building algorithm 
> into following an other path as the intended one. If it does, it can 
> leverage the fact that there is no cryptographic binding between the 
> cert and CRL key to produce a fake CRL. If the path algorithm indeed 
> follows my (valid!) but rogue path, then the CRL will match.
> 
> --
> Julien
> 
> > 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Saturday, November 06, 2004 11:56 AM
> > To: 'Julien Stern'; '[e-mail]'
> > Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > Julien,
> > 
> > A CA is not permitted to issue certificates to two distinct entities
> > with the same name.  Your example violates this constraint.
> > 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Saturday, November 06, 2004 8:38 AM
> > To: [e-mail]
> > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > 
> > Santosh,
> > 
> > See response in-line.
> > 
> > On Fri, Nov 05, 2004 at 04:07:08PM -0500, Santosh Chokhani wrote:
> > > 
> > > Julien,
> > > 
> > > The algorithm proposed specifically eliminates the risk.
> > > 
> > > The certificate certification path and the CRL certification path
> > > will not match because CRL certification path has the node VeriSign 
> > > CA in it and the certificate certification path has the node 
> > > real_VersiSign CA in it.
> > > 
> > > May be you mean that the two CAs have really the same DN.  Well, 
> > > in
> > > that case, the algorithm makes sure that all the DNs of the CAs in 
> > > the two paths match (one for one) starting with the DN of the trust 
> > > anchor.  So, in order for the attack to work, a CA in the system 
> > > must have certified two distinct CAs for the same subject DN.  If a 
> > > CA does that, all bets are off.
> > > 
> > > Please look at the algorithm closely.  It is match two different
> > > paths.
> > 
> > Well, I might be wrong, be I believe my scenario is NOT eliminated 
> > by
> > your proposal.
> > 
> > You say that your assumption is that a CA in the system must not
> > certify two distincts CAs for the same subject DN. Which would be:
> > 
> >      CA1
> >      DN1
> >     /   \
> >   CA2   CA3
> >   DN2   DN2
> > 
> > In the scenario I envisionned, the "graph" would be:
> > 
> >     CA1        ROGUECA
> >     DN1          DN3
> >      |          /   \
> >     CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
> >     DN2       DN2   DN2
> >     KEY1      KEY1  KEY2
> > 
> > 
> > Now, I have a legitime certificate EE issued by CA2, with DN2 and
> > KEY2. The path building algorithm has TWO choices to reconstruct the 
> > path (well unless specific helper extensions are used, but we should 
> > not rely on them for security), namely:
> > 
> >     CA1        ROGUECA
> >     DN1          DN3
> >      |          /   \
> >     CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
> >     DN2       DN2   DN2
> >     KEY1      KEY1  KEY2
> >        \      /      |
> >          \  /        |
> >           EE      Fake CRL
> > 
> > If it goes on the "left" side, you proposal prevents the attack. If 
> > it
> > goes on the "right" side, you proposal does not, because the CRL has a 
> > match for all the ancestors. Consequently, we are in a situation where 
> > the same certificate will be seen as revoked or not depending on the 
> > first path chosen by the path building algorithm, which is believe is 
> > bad.
> > 
> > > Also, look at the extension that cryptographically binds the CA's
> > > keys to the CRL.
> > > 
> > > BTW, Step 2 should not happen in a PKI.  A CA must not bind a 
> > > public
> > > key to a wrong subject (specially, when the subject is a CA).  This 
> > > is one of the reasons we require proof of possession of a private key.
> > > But, even with Step 2 that no CA would do, the algorithm will not let 
> > > another claim to be you.
> > 
> > I agree step 2 should not happen. I guess that if I could possibly
> > convince a CA to give a a CA cert with Verisign DN, I could also 
> > convince it to "forget" to verify the POP :)
> > 
> > But serioulsy, I believe that such a RogueCA can indeed publish fake
> > CRLs that would be validated even by your improved algorithm.
> > 
> > Please let me know if you believe I overlooked something
> > 
> > Sincerely,
> > 
> > --
> > Julien
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Julien Stern
> > > Sent: Friday, November 05, 2004 1:38 PM
> > > To: [e-mail]
> > > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > > 
> > > 
> > > 
> > > All,
> > > 
> > > I believe X509 and PKIX are even much more flawed with respect to
> > > CRL validation that underligned by Santosh. The flaw appear as soon 
> > > as it valid to sign a certificate and a CRL with different keys.
> > > 
> > > I think the flaw CANNOT be solved without modifying the existing
> > > certificates or simply disallowing these different keys. Let me
> > > explain:
> > > 
> > > We all agree that a CA is defined by name. However, if two CAs 
> > > have
> > > the same name, one of them may be able to revoke the other CA 
> > > certificates. I believe we agree on this flaw of X509 and RFC3280, 
> > > but I think the algorithm proposed by Santosh does not change the 
> > > situation.
> > > 
> > > The flaw is more severe and is due to the fact that, when a CA is 
> > > using two different certificates for signing certificate and 
> > > signing CRLs, they are unrelated. In order to solve the flaw, we 
> > > need to link these two certificates by an other mean that the 
> > > ancestors. Actually, we probably need to sign the CRL signing 
> > > certificate with the certificate signing certificate.
> > > 
> > > More precisely, if a CA, _any_ CA, whose certificate validates 
> > > with
> > > respect to one of your Trust Anchor, agrees to deliver me a 
> > > certificate whose DN is the same DN as Verisign, I will easily be 
> > > able to revoke all Verisign certificates.
> > > 
> > > The simple attack goes as follow:
> > > 
> > > 1) Find any moderately honest CA who agrees to sign me a 
> > > certificate
> > > signing certificate and a CRL signing certificate whose DNs match 
> > > Verisign DN.
> > > 
> > > 2) For the certificate signing certificate, send a CSR whose 
> > > public
> > > key matches the _real_ Verisign CA certificate.
> > > 
> > > 3) For the CRL signing certificate, send a CSR whose public key
> > > correspond to a private key I know.
> > > 
> > > 4) Finally, simply revoke any legitimate Verisign user by 
> > > producing
> > > CRLs signed with this private key.
> > > 
> > > A path building algorithm will have two choices to go up when
> > > validating a Verisign certificate, (that is, two certificate with 
> > > matching DN and key). It it chooses mine, then, the path building 
> > > chain will go up to the same TA as the chain coming from my CRL and 
> > > all the DNs will match.
> > > 
> > > Conclusions:
> > > 
> > > - The current CRL checking algorithm is flawed
> > > - Santosh proposal solves some problems but unfortunately, not all
> > > - A possible way to solve the problem would be:
> > > 
> > > 1) Simply disallow different keys for certificate and CRL signing
> > > 2) If different keys are allowed, then the CRL signing key MUST be 
> > > signed with the certificate signing key with an appropriate 
> > > delegation extension (aka ~ indirect CRLs)
> > > 
> > > 
> > 
> > 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7IRwxh082555; Sun, 7 Nov 2004 10:27:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA7IRwXZ082554; Sun, 7 Nov 2004 10:27:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7IRvAF082548 for <[e-mail]>; Sun, 7 Nov 2004 10:27:57 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA7IRxRB019312; Sun, 7 Nov 2004 13:27:59 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>, <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Sun, 7 Nov 2004 13:27:53 -0500
Message-ID: <00b001c4c4f7$81d877b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA7IRwAF082549
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

In your example also, the rouge CA is not able to impact the behavior of the
certificate chain under the proper CA hierarchy.  There is no PKI security
to a certificate taken alone without a certification path starting at a
trust anchor.  If you trust the certificate chain starting with a rogue CA,
you are in trouble.

The rogue CA can only revoke a certificate in its certification path.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Sunday, November 07, 2004 11:04 AM
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



On Sat, Nov 06, 2004 at 08:22:04PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> If you have certification path for the certificate ending at the rogue 
> root, all bets about 3280 not just CRL path matching are off.
> 
> For example, all the rogue PKI hierarchy needs to do is issue the end 
> certificates (by certifying the legitimate EE public keys) using its 
> keys and then it can also issue CRLs even using a key that matches the 
> certificate signing keys.

Santosh,

As I said in my other email,
the fact that any CA ("rogue" or not) can issue a cert to any EE and revoke
this very cert is normal behavior. The problem I was underligning is that a
rogue CA can revoke an EE cert already issued by an _other_ unrelated CA.

--
Julien

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Saturday, November 06, 2004 5:58 PM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> On Sat, Nov 06, 2004 at 12:02:20PM -0500, Santosh Chokhani wrote:
> > 
> > Julien,
> > 
> > Even if a CA down in the chain had the same name as VeriSign, the
> > matching algorithm will work since all the CA DNs starting and 
> > including that of the trust anchor and up to the end of the CRL path 
> > (in case of direct CRL) must match those in the certificate 
> > certification path.  Thus, a downstream VeriSign can not masquerade an 
> > upstream VeriSign.
> > 
> > The only way a CA can masquerade as another CA is if all the CASs in
> > their paths (including the trust anchor) have the same DN.  In order 
> > for that to happen, a CA at same level must certify two distinct 
> > authorities for the same DN.  X.509 does not permit. That.  If CA does 
> > this wrong, all bets are off.  For that matter, a CA could post its 
> > private key on the Internet.  We do not have defense against that.
> 
> I disagree with the previous paragraph.
> What you describe is one way to masquerade as an other CA.
> My example is an other way to do so. You seem to assume that 
> certification paths from EE to TAs are unique. If a create a rogue 
> cert which matches a real CA DN and key, the path building algorithm 
> might pick my certificate.
> 
> Consequently, your algorithm works if
> 1) No CA issues two certificates to two entities with the same DN. AND
> 2) No CA issues a certificate matching the DN and key of another CA.
> 
> My example uses the second case, not the first one.
> 
> > You are encouraged to carefully read, analyze, and understand the
> > algorithm.
> 
> I read it very carefully, analyzed it, hopefully understood it, and 
> actually implemented it. It was during the implementation that what I 
> think is a the flaw was highlighted.
> 
> If you also have a implementation, would you like me to produce a set 
> of certificates which highlight the problem I talking about ?
> 
> --
> Julien
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Saturday, November 06, 2004 9:43 AM
> > To: [e-mail]
> > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > 
> > David,
> > 
> > See response in-line.
> > 
> > On Fri, Nov 05, 2004 at 04:37:52PM -0500, David A. Cooper wrote:
> > > Julien,
> > > 
> > > I don't believe that the scenario you described indicates a flaw 
> > > in
> > > X.509/RFC 3280. Your scenario begins with the assumption that your 
> > > were able to get a CA to issue you a CA certificate with a subject 
> > > DN of Verisign (you further assumed that were valid certification 
> > > paths from one or more trust anchors used by relying parties to this 
> > > CA).
> > > 
> > > Once an attacker has been issued a valid CA certificate the system
> > > is compromised (until the certificate that has been issued to the 
> > > attacker has been revoked). In your scenario, you could just as 
> > > easily have obtained a CA certificate (with keyCertSign set) with a 
> > > public key corresponding to a private key that you knew. You would 
> > > then be able to issue bogus certificates, not just revoke legitimate 
> > > ones. If an attacker were issued a CA certificate from one of the 
> > > CAs in my PKI (such that my relying parties would validate 
> > > certificates issued by that CA), that CA's ability to revoke valid 
> > > certificates would be the least of my concerns since the CA could 
> > > also issue bogus certificates.
> > 
> > I do not think that the issue you describe and the one I described 
> > are
> > situed at the same level.
> > 
> > Let me explain:
> > Assume your configuration trusts exactly two TAs, say Verisign and
> > Thawte. Also assume that both of them have a complex hierarchy of CAs
> below them.
> > 
> > Now, all the CAs in these two hierarchies can produce "valid" EE
> > certs, that is, certs that will be validated by path verification 
> > algorithm.
> > 
> > The fact that one of the CA low in the hierarchy would have the same
> > DN as Verisign does not change anything to the problem. And while this 
> > "should not happen", this does not endanger security as long as your 
> > TAs are legitimate. If a CA produces bogus certificates, (which cannot 
> > be theoretically prevented), its certificate should be revoked, but 
> > the DN is irrelevant.
> > 
> > Now, in my (admitedly twisted, my possible) scenario,
> > the DN _is_ relevant for security. A dishonest CA with a normal 
> > unique DN cannot revoke all Verisign certificates, but a dishonest 
> > CA with the same
> DN
> > as Verisign could revoke all verisign certificates even if located 
> > low
> below
> > Thawte hierarchy.
> > 
> > > I would also like to point out that a PKI in which two different 
> > > CAs
> > > have the same name is invalid. The algorithm that Santosh has 
> > > proposed works to mitigate the damage that would result if two 
> > > different CAs in a PKI were using the same DN, but this is a 
> > > scenario that should never happen in the first place. From my point 
> > > of view, the main benefit of Santosh's proposal is that it improves 
> > > efficiency by reducing the number of paths that one needs to 
> > > consider during path discovery without putting undue restrictions on 
> > > the PKI architecture.
> > 
> > I think Santosh algorithm is very nice, but as you said, it only
> > mitigates the risk, and I believe I proposed a scenario in which I can 
> > fool this algorithm.
> > 
> > A also personally agree that a PKI in which two different entities
> > have the same DN is invalid (although the consensus on this does not 
> > seem to be general). However, we have to assume it could happen, 
> > possibly due to a dishonest participant. And, in fact, for pure 
> > certificate path verification, this possibly invalid situation does 
> > not adversely affect security. Hence, we also have to ensure that it 
> > does not affect security when processing CRLs. We all agree it 
> > currently does, and IMHO the issue is not entirely solved by Santosh 
> > algorithm. If a CRL signer key belongs to a given CA, I think it has 
> > to be cryptographically binded to the CA certificate signing key in 
> > some way.
> > 
> > > I know that Denis Pinkas has stated: "For X.509, I do *not* say
> > > X.500,
> > > a
> > > DN is only relative to the CA who has given it." Presumably he is 
> > > arguing that it is perfectly legitimate for two CAs in a PKI to have
the
> 
> > > same name; the only requirement being that a CA can not issue two
> > > certificates with the same subject DN in which the subjects are 
> > > different entities. If this is the case though, I would like to know 
> > > where X.509 says this or even what text in X.509 implies that this is 
> > > the case. Section 7 of X.509 states "CAs are unambiguously defined by
a 
> > > distinguished name in the DIT", which seems to contradict Denis'
claim.
> > > 
> > > In conclusion, in X.509 it is not legitimate for two different 
> > > entities to have the same DN and it is particularly important to 
> > > ensure that two different CAs in a PKI do not use the same DN. At 
> > > the same time, defense-in-depth is always a good strategy and in 
> > > that light Santosh's algorithm does a good job of protecting 
> > > against the risk that a PKI will
> 
> > > evolve in which two different CAs do use the same DN.
> > 
> > As I have just said before, I personally concur with your analysis,
> > but think that the proposed defence-in-depth is not sufficient and 
> > that we need cryptographic binding.
> > 
> > Sincerely,
> > 
> > --
> > Julien
> > 
> > > Julien Stern wrote:
> > > 
> > > >All,
> > > >
> > > >I believe X509 and PKIX are even much more flawed with respect to
> > > >CRL
> > > >validation that underligned by Santosh. The flaw appear as soon as it

> > > >valid to sign a certificate and a CRL with different keys.
> > > >
> > > >I think the flaw CANNOT be solved without modifying the existing 
> > > >certificates or simply disallowing these different keys. Let me
> > > >explain:
> > > >
> > > >We all agree that a CA is defined by name. However, if two CAs 
> > > >have the same name, one of them may be able to revoke the other 
> > > >CA certificates. I believe we agree on this flaw of X509 and 
> > > >RFC3280, but I think the algorithm proposed by Santosh does not 
> > > >change the situation.
> > > >
> > > >The flaw is more severe and is due to the fact that, when a CA is
> > > >using two different certificates for signing certificate and 
> > > >signing CRLs, they are unrelated. In order to solve the flaw, we 
> > > >need to link these two certificates by an other mean that the 
> > > >ancestors. Actually, we probably need to sign the CRL signing 
> > > >certificate with the certificate signing certificate.
> > > >
> > > >More precisely, if a CA, _any_ CA, whose certificate validates 
> > > >with respect to one of your Trust Anchor, agrees to deliver me a 
> > > >certificate whose DN is the same DN as Verisign, I will easily be 
> > > >able to revoke all Verisign certificates.
> > > >
> > > >The simple attack goes as follow:
> > > >
> > > >1) Find any moderately honest CA who agrees to sign me a
> > > >certificate
> > > >signing certificate and a CRL signing certificate whose DNs match 
> > > >Verisign DN.
> > > >
> > > >2) For the certificate signing certificate, send a CSR whose 
> > > >public key matches the _real_ Verisign CA certificate.
> > > >
> > > >3) For the CRL signing certificate, send a CSR whose public key 
> > > >correspond to a private key I know.
> > > >
> > > >4) Finally, simply revoke any legitimate Verisign user by 
> > > >producing CRLs signed with this private key.
> > > >
> > > >A path building algorithm will have two choices to go up when 
> > > >validating a Verisign certificate, (that is, two certificate with 
> > > >matching DN and key). It it chooses mine, then, the path building 
> > > >chain will go up to the same TA as the chain coming from my CRL 
> > > >and all the DNs will match.
> > > >
> > > >Conclusions:
> > > >
> > > >- The current CRL checking algorithm is flawed
> > > >- Santosh proposal solves some problems but unfortunately, not 
> > > >all
> > > >- A possible way to solve the problem would be:
> > > >
> > > >1) Simply disallow different keys for certificate and CRL signing
> > > >2) If different keys are allowed, then the CRL signing key MUST 
> > > >be
> > > >signed with the certificate signing key with an appropriate 
> > > >delegation extension (aka ~ indirect CRLs)
> > > >
> > > 
> > 
> > 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7G4Q8G020599; Sun, 7 Nov 2004 08:04:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA7G4Q6a020597; Sun, 7 Nov 2004 08:04:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-100-sunday.noc.nerim.net [62.4.17.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7G4PXT020537 for <[e-mail]>; Sun, 7 Nov 2004 08:04:25 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 1000162F6E for <[e-mail]>; Sun,  7 Nov 2004 17:04:17 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 339D5440E7 for <[e-mail]>; Sun,  7 Nov 2004 17:04:49 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13968-06 for <[e-mail]>; Sun, 7 Nov 2004 17:04:45 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 5E49E4400B for <[e-mail]>; Sun,  7 Nov 2004 17:04:45 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Sun,  7 Nov 2004 17:04:14 +0100
From: "Julien Stern" <[e-mail]>
Date: Sun, 7 Nov 2004 17:04:14 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <003401c4c468$3425ec80$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <003401c4c468$3425ec80$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, Nov 06, 2004 at 08:22:04PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> If you have certification path for the certificate ending at the rogue root,
> all bets about 3280 not just CRL path matching are off.
> 
> For example, all the rogue PKI hierarchy needs to do is issue the end
> certificates (by certifying the legitimate EE public keys) using its keys
> and then it can also issue CRLs even using a key that matches the
> certificate signing keys.

Santosh,

As I said in my other email,
the fact that any CA ("rogue" or not) can issue a cert to any EE and
revoke this very cert is normal behavior. The problem I was underligning
is that a rogue CA can revoke an EE cert already issued by an _other_
unrelated CA.

--
Julien

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Julien Stern
> Sent: Saturday, November 06, 2004 5:58 PM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> On Sat, Nov 06, 2004 at 12:02:20PM -0500, Santosh Chokhani wrote:
> > 
> > Julien,
> > 
> > Even if a CA down in the chain had the same name as VeriSign, the 
> > matching algorithm will work since all the CA DNs starting and 
> > including that of the trust anchor and up to the end of the CRL path 
> > (in case of direct CRL) must match those in the certificate 
> > certification path.  Thus, a downstream VeriSign can not masquerade an 
> > upstream VeriSign.
> > 
> > The only way a CA can masquerade as another CA is if all the CASs in 
> > their paths (including the trust anchor) have the same DN.  In order 
> > for that to happen, a CA at same level must certify two distinct 
> > authorities for the same DN.  X.509 does not permit. That.  If CA does 
> > this wrong, all bets are off.  For that matter, a CA could post its 
> > private key on the Internet.  We do not have defense against that.
> 
> I disagree with the previous paragraph.
> What you describe is one way to masquerade as an other CA.
> My example is an other way to do so. You seem to assume that certification
> paths from EE to TAs are unique. If a create a rogue cert which matches a
> real CA DN and key, the path building algorithm might pick my certificate.
> 
> Consequently, your algorithm works if
> 1) No CA issues two certificates to two entities with the same DN. AND
> 2) No CA issues a certificate matching the DN and key of another CA.
> 
> My example uses the second case, not the first one.
> 
> > You are encouraged to carefully read, analyze, and understand the 
> > algorithm.
> 
> I read it very carefully, analyzed it, hopefully understood it, and actually
> implemented it. It was during the implementation that what I think is a the
> flaw was highlighted.
> 
> If you also have a implementation, would you like me to produce a set of
> certificates which highlight the problem I talking about ?
> 
> --
> Julien
> 
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Saturday, November 06, 2004 9:43 AM
> > To: [e-mail]
> > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > 
> > David,
> > 
> > See response in-line.
> > 
> > On Fri, Nov 05, 2004 at 04:37:52PM -0500, David A. Cooper wrote:
> > > Julien,
> > > 
> > > I don't believe that the scenario you described indicates a flaw in 
> > > X.509/RFC 3280. Your scenario begins with the assumption that your 
> > > were able to get a CA to issue you a CA certificate with a subject 
> > > DN of Verisign (you further assumed that were valid certification 
> > > paths from one or more trust anchors used by relying parties to this 
> > > CA).
> > > 
> > > Once an attacker has been issued a valid CA certificate the system 
> > > is compromised (until the certificate that has been issued to the 
> > > attacker has been revoked). In your scenario, you could just as 
> > > easily have obtained a CA certificate (with keyCertSign set) with a 
> > > public key corresponding to a private key that you knew. You would 
> > > then be able to issue bogus certificates, not just revoke legitimate 
> > > ones. If an attacker were issued a CA certificate from one of the 
> > > CAs in my PKI (such that my relying parties would validate 
> > > certificates issued by that CA), that CA's ability to revoke valid 
> > > certificates would be the least of my concerns since the CA could 
> > > also issue bogus certificates.
> > 
> > I do not think that the issue you describe and the one I described are 
> > situed at the same level.
> > 
> > Let me explain:
> > Assume your configuration trusts exactly two TAs, say Verisign and 
> > Thawte. Also assume that both of them have a complex hierarchy of CAs
> below them.
> > 
> > Now, all the CAs in these two hierarchies can produce "valid" EE 
> > certs, that is, certs that will be validated by path verification 
> > algorithm.
> > 
> > The fact that one of the CA low in the hierarchy would have the same 
> > DN as Verisign does not change anything to the problem. And while this 
> > "should not happen", this does not endanger security as long as your 
> > TAs are legitimate. If a CA produces bogus certificates, (which cannot 
> > be theoretically prevented), its certificate should be revoked, but 
> > the DN is irrelevant.
> > 
> > Now, in my (admitedly twisted, my possible) scenario,
> > the DN _is_ relevant for security. A dishonest CA with a normal unique DN
> > cannot revoke all Verisign certificates, but a dishonest CA with the same
> DN
> > as Verisign could revoke all verisign certificates even if located low
> below
> > Thawte hierarchy.
> > 
> > > I would also like to point out that a PKI in which two different CAs 
> > > have the same name is invalid. The algorithm that Santosh has 
> > > proposed works to mitigate the damage that would result if two 
> > > different CAs in a PKI were using the same DN, but this is a 
> > > scenario that should never happen in the first place. From my point 
> > > of view, the main benefit of Santosh's proposal is that it improves 
> > > efficiency by reducing the number of paths that one needs to 
> > > consider during path discovery without putting undue restrictions on 
> > > the PKI architecture.
> > 
> > I think Santosh algorithm is very nice, but as you said, it only 
> > mitigates the risk, and I believe I proposed a scenario in which I can 
> > fool this algorithm.
> > 
> > A also personally agree that a PKI in which two different entities 
> > have the same DN is invalid (although the consensus on this does not 
> > seem to be general). However, we have to assume it could happen, 
> > possibly due to a dishonest participant. And, in fact, for pure 
> > certificate path verification, this possibly invalid situation does 
> > not adversely affect security. Hence, we also have to ensure that it 
> > does not affect security when processing CRLs. We all agree it 
> > currently does, and IMHO the issue is not entirely solved by Santosh 
> > algorithm. If a CRL signer key belongs to a given CA, I think it has 
> > to be cryptographically binded to the CA certificate signing key in 
> > some way.
> > 
> > > I know that Denis Pinkas has stated: "For X.509, I do *not* say 
> > > X.500,
> > > a
> > > DN is only relative to the CA who has given it." Presumably he is 
> > > arguing that it is perfectly legitimate for two CAs in a PKI to have the
> 
> > > same name; the only requirement being that a CA can not issue two 
> > > certificates with the same subject DN in which the subjects are 
> > > different entities. If this is the case though, I would like to know 
> > > where X.509 says this or even what text in X.509 implies that this is 
> > > the case. Section 7 of X.509 states "CAs are unambiguously defined by a 
> > > distinguished name in the DIT", which seems to contradict Denis' claim.
> > > 
> > > In conclusion, in X.509 it is not legitimate for two different
> > > entities
> > > to have the same DN and it is particularly important to ensure that two 
> > > different CAs in a PKI do not use the same DN. At the same time, 
> > > defense-in-depth is always a good strategy and in that light Santosh's 
> > > algorithm does a good job of protecting against the risk that a PKI will
> 
> > > evolve in which two different CAs do use the same DN.
> > 
> > As I have just said before, I personally concur with your analysis, 
> > but think that the proposed defence-in-depth is not sufficient and 
> > that we need cryptographic binding.
> > 
> > Sincerely,
> > 
> > --
> > Julien
> > 
> > > Julien Stern wrote:
> > > 
> > > >All,
> > > >
> > > >I believe X509 and PKIX are even much more flawed with respect to 
> > > >CRL
> > > >validation that underligned by Santosh. The flaw appear as soon as it 
> > > >valid to sign a certificate and a CRL with different keys.
> > > >
> > > >I think the flaw CANNOT be solved without modifying the existing
> > > >certificates or simply disallowing these different keys. Let me 
> > > >explain:
> > > >
> > > >We all agree that a CA is defined by name. However, if two CAs have
> > > >the same name, one of them may be able to revoke the other CA 
> > > >certificates. I believe we agree on this flaw of X509 and RFC3280, 
> > > >but I think the algorithm proposed by Santosh does not change the 
> > > >situation.
> > > >
> > > >The flaw is more severe and is due to the fact that, when a CA is 
> > > >using two different certificates for signing certificate and 
> > > >signing CRLs, they are unrelated. In order to solve the flaw, we 
> > > >need to link these two certificates by an other mean that the 
> > > >ancestors. Actually, we probably need to sign the CRL signing 
> > > >certificate with the certificate signing certificate.
> > > >
> > > >More precisely, if a CA, _any_ CA, whose certificate validates with
> > > >respect to one of your Trust Anchor, agrees to deliver me a 
> > > >certificate whose DN is the same DN as Verisign, I will easily be 
> > > >able to revoke all Verisign certificates.
> > > >
> > > >The simple attack goes as follow:
> > > >
> > > >1) Find any moderately honest CA who agrees to sign me a 
> > > >certificate
> > > >signing certificate and a CRL signing certificate whose DNs match 
> > > >Verisign DN.
> > > >
> > > >2) For the certificate signing certificate, send a CSR whose public
> > > >key matches the _real_ Verisign CA certificate.
> > > >
> > > >3) For the CRL signing certificate, send a CSR whose public key
> > > >correspond to a private key I know.
> > > >
> > > >4) Finally, simply revoke any legitimate Verisign user by producing
> > > >CRLs signed with this private key.
> > > >
> > > >A path building algorithm will have two choices to go up when
> > > >validating a Verisign certificate, (that is, two certificate with 
> > > >matching DN and key). It it chooses mine, then, the path building 
> > > >chain will go up to the same TA as the chain coming from my CRL and 
> > > >all the DNs will match.
> > > >
> > > >Conclusions:
> > > >
> > > >- The current CRL checking algorithm is flawed
> > > >- Santosh proposal solves some problems but unfortunately, not all
> > > >- A possible way to solve the problem would be:
> > > >
> > > >1) Simply disallow different keys for certificate and CRL signing
> > > >2) If different keys are allowed, then the CRL signing key MUST be 
> > > >signed with the certificate signing key with an appropriate 
> > > >delegation extension (aka ~ indirect CRLs)
> > > >
> > > 
> > 
> > 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7G0vEo018876; Sun, 7 Nov 2004 08:00:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA7G0uCJ018856; Sun, 7 Nov 2004 08:00:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-100-sunday.nerim.net [62.4.16.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA7G0ron018681 for <[e-mail]>; Sun, 7 Nov 2004 08:00:54 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 1126041BD0 for <[e-mail]>; Sun,  7 Nov 2004 17:00:50 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 493FD440E7 for <[e-mail]>; Sun,  7 Nov 2004 17:01:21 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13973-04 for <[e-mail]>; Sun, 7 Nov 2004 17:01:17 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 55EC54400B for <[e-mail]>; Sun,  7 Nov 2004 17:01:17 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Sun,  7 Nov 2004 17:00:46 +0100
From: "Julien Stern" <[e-mail]>
Date: Sun, 7 Nov 2004 17:00:46 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <003701c4c469$8257d160$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <003701c4c469$8257d160$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, Nov 06, 2004 at 08:31:25PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> The rogue PKI hierarchy can get around the certificate and CRL being signed
> using the same key by simply re-issuing the legitimate end entities
> certificates and then revoking or not revoking certificates.
> 
> EE legitimate key certified by CA3 (DN2/KEY2) -> CA3 (DN2/KEY2) -> ROGUECA
> (DN3)
> 
> Now using DN2, KEY2 to sign CRL will provide crypto binding and still fool
> you.

Santosh,

The ROGUE CA will indeed be able to issue a certificate to a user and
revoke this very certificate that it has issued, which is perfectly
normal, because it actually issued it.
This behavior is not even "rogue": a EE certificate can have two
different CAs certifying him.

The unintended behavior I was underligning was that, in the context I
described, the rogue CA can revoke existing EE certificates issued by
an other CA.

> The basic point is if a relying party trusts a rogue trust anchor, PKI
> security will go to hell.

I was not talking about a rogue TA, I was talking about a rogue CA
possibly low in the hierarchy that could impersonate (CRL wise) an other
CA in a totally unrelated hierarchy.

As soon as there is a Rogue CA, PKI security goes to hell. But this
should be limited to the tree under this Rogue CA, and not affect all
the unrelated hierarchies as it is the case now.

--
Julien

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Julien Stern
> Sent: Saturday, November 06, 2004 6:09 PM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> On Sat, Nov 06, 2004 at 12:12:36PM -0500, Santosh Chokhani wrote:
> > 
> > Julien,
> > 
> > One more thing.
> > 
> > Even in your example, only the certificates related to hierarchy 
> > underneath the rouge CA will be screwed it.  Even if you relied on the 
> > rouge CA, the name matching algorithm will be robust with respect to 
> > the other PKI hierarchies.
> > 
> > The proposal does prevent the attack since DN1 and DN 3 are not the 
> > same. Hence CRL certification path will not match that of the 
> > certificate certification path.  Please look at the check under the 
> > first bullet in slide 12.
> 
> Santosh,
> 
> I understand the name matching algorithm. However, you assume that the path
> builder will pick the path EE -> CA2 (DN2/KEY1) -> CA1 (DN1)
> 
> whereas it could AS WELL pick the path
> EE -> CA3 (DN2/KEY1) -> ROGUECA (DN3)
> 
> which is as valid as the first one.
> In that case, the name matching algorithm will perfectly work, 
> because the CRL path is
> FakeCRL -> CA3 (DN2/KEY2) -> ROGUECA (DN3)
> 
> The whole idea of the attack is that a rogue CA can produce a certificate
> which matches the DN and KEY of an existing cert. Of course, this
> certificate will be useless, because the private key will not be known, but
> it may allow to fool the path building algorithm into following an other
> path as the intended one. If it does, it can leverage the fact that there is
> no cryptographic binding between the cert and CRL key to produce a fake CRL.
> If the path algorithm indeed follows my (valid!) but rogue path, then the
> CRL will match.
> 
> --
> Julien
> 
> > 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Saturday, November 06, 2004 11:56 AM
> > To: 'Julien Stern'; '[e-mail]'
> > Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > Julien,
> > 
> > A CA is not permitted to issue certificates to two distinct entities 
> > with the same name.  Your example violates this constraint.
> > 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Saturday, November 06, 2004 8:38 AM
> > To: [e-mail]
> > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > 
> > Santosh,
> > 
> > See response in-line.
> > 
> > On Fri, Nov 05, 2004 at 04:07:08PM -0500, Santosh Chokhani wrote:
> > > 
> > > Julien,
> > > 
> > > The algorithm proposed specifically eliminates the risk.
> > > 
> > > The certificate certification path and the CRL certification path 
> > > will not match because CRL certification path has the node VeriSign 
> > > CA in it and the certificate certification path has the node 
> > > real_VersiSign CA in it.
> > > 
> > > May be you mean that the two CAs have really the same DN.  Well, in 
> > > that case, the algorithm makes sure that all the DNs of the CAs in 
> > > the two paths match (one for one) starting with the DN of the trust 
> > > anchor.  So, in order for the attack to work, a CA in the system 
> > > must have certified two distinct CAs for the same subject DN.  If a 
> > > CA does that, all bets are off.
> > > 
> > > Please look at the algorithm closely.  It is match two different 
> > > paths.
> > 
> > Well, I might be wrong, be I believe my scenario is NOT eliminated by 
> > your proposal.
> > 
> > You say that your assumption is that a CA in the system must not 
> > certify two distincts CAs for the same subject DN. Which would be:
> > 
> >      CA1
> >      DN1
> >     /   \
> >   CA2   CA3
> >   DN2   DN2
> > 
> > In the scenario I envisionned, the "graph" would be:
> > 
> >     CA1        ROGUECA
> >     DN1          DN3
> >      |          /   \
> >     CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
> >     DN2       DN2   DN2
> >     KEY1      KEY1  KEY2
> > 
> > 
> > Now, I have a legitime certificate EE issued by CA2, with DN2 and 
> > KEY2. The path building algorithm has TWO choices to reconstruct the 
> > path (well unless specific helper extensions are used, but we should 
> > not rely on them for security), namely:
> > 
> >     CA1        ROGUECA
> >     DN1          DN3
> >      |          /   \
> >     CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
> >     DN2       DN2   DN2
> >     KEY1      KEY1  KEY2
> >        \      /      |
> >          \  /        |
> >           EE      Fake CRL
> > 
> > If it goes on the "left" side, you proposal prevents the attack. If it 
> > goes on the "right" side, you proposal does not, because the CRL has a 
> > match for all the ancestors. Consequently, we are in a situation where 
> > the same certificate will be seen as revoked or not depending on the 
> > first path chosen by the path building algorithm, which is believe is 
> > bad.
> > 
> > > Also, look at the extension that cryptographically binds the CA's 
> > > keys to the CRL.
> > > 
> > > BTW, Step 2 should not happen in a PKI.  A CA must not bind a public 
> > > key to a wrong subject (specially, when the subject is a CA).  This 
> > > is one of the reasons we require proof of possession of a private key.
> > > But, even with Step 2 that no CA would do, the algorithm will not let 
> > > another claim to be you.
> > 
> > I agree step 2 should not happen. I guess that if I could possibly 
> > convince a CA to give a a CA cert with Verisign DN, I could also 
> > convince it to "forget" to verify the POP :)
> > 
> > But serioulsy, I believe that such a RogueCA can indeed publish fake 
> > CRLs that would be validated even by your improved algorithm.
> > 
> > Please let me know if you believe I overlooked something
> > 
> > Sincerely,
> > 
> > --
> > Julien
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of Julien Stern
> > > Sent: Friday, November 05, 2004 1:38 PM
> > > To: [e-mail]
> > > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > > 
> > > 
> > > 
> > > All,
> > > 
> > > I believe X509 and PKIX are even much more flawed with respect to 
> > > CRL validation that underligned by Santosh. The flaw appear as soon 
> > > as it valid to sign a certificate and a CRL with different keys.
> > > 
> > > I think the flaw CANNOT be solved without modifying the existing 
> > > certificates or simply disallowing these different keys. Let me
> > > explain:
> > > 
> > > We all agree that a CA is defined by name. However, if two CAs have 
> > > the same name, one of them may be able to revoke the other CA 
> > > certificates. I believe we agree on this flaw of X509 and RFC3280, 
> > > but I think the algorithm proposed by Santosh does not change the 
> > > situation.
> > > 
> > > The flaw is more severe and is due to the fact that, when
> > > a CA is using two different certificates for signing certificate and 
> > > signing CRLs, they are unrelated. In order to solve the flaw, we 
> > > need to link these two certificates by an other mean that the 
> > > ancestors. Actually, we probably need to sign the CRL signing 
> > > certificate with the certificate signing certificate.
> > > 
> > > More precisely, if a CA, _any_ CA, whose certificate validates with 
> > > respect to one of your Trust Anchor, agrees to deliver me a 
> > > certificate whose DN is the same DN as Verisign, I will easily be 
> > > able to revoke all Verisign certificates.
> > > 
> > > The simple attack goes as follow:
> > > 
> > > 1) Find any moderately honest CA who agrees to sign me a certificate 
> > > signing certificate and a CRL signing certificate whose DNs match 
> > > Verisign DN.
> > > 
> > > 2) For the certificate signing certificate, send a CSR whose public 
> > > key matches the _real_ Verisign CA certificate.
> > > 
> > > 3) For the CRL signing certificate, send a CSR whose public key 
> > > correspond to a private key I know.
> > > 
> > > 4) Finally, simply revoke any legitimate Verisign user by producing 
> > > CRLs signed with this private key.
> > > 
> > > A path building algorithm will have two choices to go up when 
> > > validating a Verisign certificate, (that is, two certificate with 
> > > matching DN and key). It it chooses mine, then, the path building 
> > > chain will go up to the same TA as the chain coming from my CRL and 
> > > all the DNs will match.
> > > 
> > > Conclusions:
> > > 
> > > - The current CRL checking algorithm is flawed
> > > - Santosh proposal solves some problems but unfortunately, not all
> > > - A possible way to solve the problem would be:
> > > 
> > > 1) Simply disallow different keys for certificate and CRL signing
> > > 2) If different keys are allowed, then the CRL signing key MUST be
> > > signed with the certificate signing key with an appropriate delegation 
> > > extension (aka ~ indirect CRLs)
> > > 
> > > 
> > 
> > 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA71VR96008348; Sat, 6 Nov 2004 17:31:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA71VRCU008347; Sat, 6 Nov 2004 17:31:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA71VQZ1008334 for <[e-mail]>; Sat, 6 Nov 2004 17:31:26 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA71VV89028106 for <[e-mail]>; Sat, 6 Nov 2004 20:31:31 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Sat, 6 Nov 2004 20:31:25 -0500
Message-ID: <003701c4c469$8257d160$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA71VQZ1008336
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

The rogue PKI hierarchy can get around the certificate and CRL being signed
using the same key by simply re-issuing the legitimate end entities
certificates and then revoking or not revoking certificates.

EE legitimate key certified by CA3 (DN2/KEY2) -> CA3 (DN2/KEY2) -> ROGUECA
(DN3)

Now using DN2, KEY2 to sign CRL will provide crypto binding and still fool
you.

The basic point is if a relying party trusts a rogue trust anchor, PKI
security will go to hell.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Saturday, November 06, 2004 6:09 PM
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



On Sat, Nov 06, 2004 at 12:12:36PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> One more thing.
> 
> Even in your example, only the certificates related to hierarchy 
> underneath the rouge CA will be screwed it.  Even if you relied on the 
> rouge CA, the name matching algorithm will be robust with respect to 
> the other PKI hierarchies.
> 
> The proposal does prevent the attack since DN1 and DN 3 are not the 
> same. Hence CRL certification path will not match that of the 
> certificate certification path.  Please look at the check under the 
> first bullet in slide 12.

Santosh,

I understand the name matching algorithm. However, you assume that the path
builder will pick the path EE -> CA2 (DN2/KEY1) -> CA1 (DN1)

whereas it could AS WELL pick the path
EE -> CA3 (DN2/KEY1) -> ROGUECA (DN3)

which is as valid as the first one.
In that case, the name matching algorithm will perfectly work, 
because the CRL path is
FakeCRL -> CA3 (DN2/KEY2) -> ROGUECA (DN3)

The whole idea of the attack is that a rogue CA can produce a certificate
which matches the DN and KEY of an existing cert. Of course, this
certificate will be useless, because the private key will not be known, but
it may allow to fool the path building algorithm into following an other
path as the intended one. If it does, it can leverage the fact that there is
no cryptographic binding between the cert and CRL key to produce a fake CRL.
If the path algorithm indeed follows my (valid!) but rogue path, then the
CRL will match.

--
Julien

> 
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Saturday, November 06, 2004 11:56 AM
> To: 'Julien Stern'; '[e-mail]'
> Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Julien,
> 
> A CA is not permitted to issue certificates to two distinct entities 
> with the same name.  Your example violates this constraint.
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Saturday, November 06, 2004 8:38 AM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> Santosh,
> 
> See response in-line.
> 
> On Fri, Nov 05, 2004 at 04:07:08PM -0500, Santosh Chokhani wrote:
> > 
> > Julien,
> > 
> > The algorithm proposed specifically eliminates the risk.
> > 
> > The certificate certification path and the CRL certification path 
> > will not match because CRL certification path has the node VeriSign 
> > CA in it and the certificate certification path has the node 
> > real_VersiSign CA in it.
> > 
> > May be you mean that the two CAs have really the same DN.  Well, in 
> > that case, the algorithm makes sure that all the DNs of the CAs in 
> > the two paths match (one for one) starting with the DN of the trust 
> > anchor.  So, in order for the attack to work, a CA in the system 
> > must have certified two distinct CAs for the same subject DN.  If a 
> > CA does that, all bets are off.
> > 
> > Please look at the algorithm closely.  It is match two different 
> > paths.
> 
> Well, I might be wrong, be I believe my scenario is NOT eliminated by 
> your proposal.
> 
> You say that your assumption is that a CA in the system must not 
> certify two distincts CAs for the same subject DN. Which would be:
> 
>      CA1
>      DN1
>     /   \
>   CA2   CA3
>   DN2   DN2
> 
> In the scenario I envisionned, the "graph" would be:
> 
>     CA1        ROGUECA
>     DN1          DN3
>      |          /   \
>     CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
>     DN2       DN2   DN2
>     KEY1      KEY1  KEY2
> 
> 
> Now, I have a legitime certificate EE issued by CA2, with DN2 and 
> KEY2. The path building algorithm has TWO choices to reconstruct the 
> path (well unless specific helper extensions are used, but we should 
> not rely on them for security), namely:
> 
>     CA1        ROGUECA
>     DN1          DN3
>      |          /   \
>     CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
>     DN2       DN2   DN2
>     KEY1      KEY1  KEY2
>        \      /      |
>          \  /        |
>           EE      Fake CRL
> 
> If it goes on the "left" side, you proposal prevents the attack. If it 
> goes on the "right" side, you proposal does not, because the CRL has a 
> match for all the ancestors. Consequently, we are in a situation where 
> the same certificate will be seen as revoked or not depending on the 
> first path chosen by the path building algorithm, which is believe is 
> bad.
> 
> > Also, look at the extension that cryptographically binds the CA's 
> > keys to the CRL.
> > 
> > BTW, Step 2 should not happen in a PKI.  A CA must not bind a public 
> > key to a wrong subject (specially, when the subject is a CA).  This 
> > is one of the reasons we require proof of possession of a private key.
> > But, even with Step 2 that no CA would do, the algorithm will not let 
> > another claim to be you.
> 
> I agree step 2 should not happen. I guess that if I could possibly 
> convince a CA to give a a CA cert with Verisign DN, I could also 
> convince it to "forget" to verify the POP :)
> 
> But serioulsy, I believe that such a RogueCA can indeed publish fake 
> CRLs that would be validated even by your improved algorithm.
> 
> Please let me know if you believe I overlooked something
> 
> Sincerely,
> 
> --
> Julien
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Friday, November 05, 2004 1:38 PM
> > To: [e-mail]
> > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > 
> > All,
> > 
> > I believe X509 and PKIX are even much more flawed with respect to 
> > CRL validation that underligned by Santosh. The flaw appear as soon 
> > as it valid to sign a certificate and a CRL with different keys.
> > 
> > I think the flaw CANNOT be solved without modifying the existing 
> > certificates or simply disallowing these different keys. Let me
> > explain:
> > 
> > We all agree that a CA is defined by name. However, if two CAs have 
> > the same name, one of them may be able to revoke the other CA 
> > certificates. I believe we agree on this flaw of X509 and RFC3280, 
> > but I think the algorithm proposed by Santosh does not change the 
> > situation.
> > 
> > The flaw is more severe and is due to the fact that, when
> > a CA is using two different certificates for signing certificate and 
> > signing CRLs, they are unrelated. In order to solve the flaw, we 
> > need to link these two certificates by an other mean that the 
> > ancestors. Actually, we probably need to sign the CRL signing 
> > certificate with the certificate signing certificate.
> > 
> > More precisely, if a CA, _any_ CA, whose certificate validates with 
> > respect to one of your Trust Anchor, agrees to deliver me a 
> > certificate whose DN is the same DN as Verisign, I will easily be 
> > able to revoke all Verisign certificates.
> > 
> > The simple attack goes as follow:
> > 
> > 1) Find any moderately honest CA who agrees to sign me a certificate 
> > signing certificate and a CRL signing certificate whose DNs match 
> > Verisign DN.
> > 
> > 2) For the certificate signing certificate, send a CSR whose public 
> > key matches the _real_ Verisign CA certificate.
> > 
> > 3) For the CRL signing certificate, send a CSR whose public key 
> > correspond to a private key I know.
> > 
> > 4) Finally, simply revoke any legitimate Verisign user by producing 
> > CRLs signed with this private key.
> > 
> > A path building algorithm will have two choices to go up when 
> > validating a Verisign certificate, (that is, two certificate with 
> > matching DN and key). It it chooses mine, then, the path building 
> > chain will go up to the same TA as the chain coming from my CRL and 
> > all the DNs will match.
> > 
> > Conclusions:
> > 
> > - The current CRL checking algorithm is flawed
> > - Santosh proposal solves some problems but unfortunately, not all
> > - A possible way to solve the problem would be:
> > 
> > 1) Simply disallow different keys for certificate and CRL signing
> > 2) If different keys are allowed, then the CRL signing key MUST be
> > signed with the certificate signing key with an appropriate delegation 
> > extension (aka ~ indirect CRLs)
> > 
> > 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA71M8oX006106; Sat, 6 Nov 2004 17:22:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA71M8R6006104; Sat, 6 Nov 2004 17:22:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA71M8CC006086 for <[e-mail]>; Sat, 6 Nov 2004 17:22:08 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA71MB89022388 for <[e-mail]>; Sat, 6 Nov 2004 20:22:11 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Sat, 6 Nov 2004 20:22:04 -0500
Message-ID: <003401c4c468$3425ec80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA71M8CC006098
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

If you have certification path for the certificate ending at the rogue root,
all bets about 3280 not just CRL path matching are off.

For example, all the rogue PKI hierarchy needs to do is issue the end
certificates (by certifying the legitimate EE public keys) using its keys
and then it can also issue CRLs even using a key that matches the
certificate signing keys.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Saturday, November 06, 2004 5:58 PM
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



On Sat, Nov 06, 2004 at 12:02:20PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> Even if a CA down in the chain had the same name as VeriSign, the 
> matching algorithm will work since all the CA DNs starting and 
> including that of the trust anchor and up to the end of the CRL path 
> (in case of direct CRL) must match those in the certificate 
> certification path.  Thus, a downstream VeriSign can not masquerade an 
> upstream VeriSign.
> 
> The only way a CA can masquerade as another CA is if all the CASs in 
> their paths (including the trust anchor) have the same DN.  In order 
> for that to happen, a CA at same level must certify two distinct 
> authorities for the same DN.  X.509 does not permit. That.  If CA does 
> this wrong, all bets are off.  For that matter, a CA could post its 
> private key on the Internet.  We do not have defense against that.

I disagree with the previous paragraph.
What you describe is one way to masquerade as an other CA.
My example is an other way to do so. You seem to assume that certification
paths from EE to TAs are unique. If a create a rogue cert which matches a
real CA DN and key, the path building algorithm might pick my certificate.

Consequently, your algorithm works if
1) No CA issues two certificates to two entities with the same DN. AND
2) No CA issues a certificate matching the DN and key of another CA.

My example uses the second case, not the first one.

> You are encouraged to carefully read, analyze, and understand the 
> algorithm.

I read it very carefully, analyzed it, hopefully understood it, and actually
implemented it. It was during the implementation that what I think is a the
flaw was highlighted.

If you also have a implementation, would you like me to produce a set of
certificates which highlight the problem I talking about ?

--
Julien


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Saturday, November 06, 2004 9:43 AM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> David,
> 
> See response in-line.
> 
> On Fri, Nov 05, 2004 at 04:37:52PM -0500, David A. Cooper wrote:
> > Julien,
> > 
> > I don't believe that the scenario you described indicates a flaw in 
> > X.509/RFC 3280. Your scenario begins with the assumption that your 
> > were able to get a CA to issue you a CA certificate with a subject 
> > DN of Verisign (you further assumed that were valid certification 
> > paths from one or more trust anchors used by relying parties to this 
> > CA).
> > 
> > Once an attacker has been issued a valid CA certificate the system 
> > is compromised (until the certificate that has been issued to the 
> > attacker has been revoked). In your scenario, you could just as 
> > easily have obtained a CA certificate (with keyCertSign set) with a 
> > public key corresponding to a private key that you knew. You would 
> > then be able to issue bogus certificates, not just revoke legitimate 
> > ones. If an attacker were issued a CA certificate from one of the 
> > CAs in my PKI (such that my relying parties would validate 
> > certificates issued by that CA), that CA's ability to revoke valid 
> > certificates would be the least of my concerns since the CA could 
> > also issue bogus certificates.
> 
> I do not think that the issue you describe and the one I described are 
> situed at the same level.
> 
> Let me explain:
> Assume your configuration trusts exactly two TAs, say Verisign and 
> Thawte. Also assume that both of them have a complex hierarchy of CAs
below them.
> 
> Now, all the CAs in these two hierarchies can produce "valid" EE 
> certs, that is, certs that will be validated by path verification 
> algorithm.
> 
> The fact that one of the CA low in the hierarchy would have the same 
> DN as Verisign does not change anything to the problem. And while this 
> "should not happen", this does not endanger security as long as your 
> TAs are legitimate. If a CA produces bogus certificates, (which cannot 
> be theoretically prevented), its certificate should be revoked, but 
> the DN is irrelevant.
> 
> Now, in my (admitedly twisted, my possible) scenario,
> the DN _is_ relevant for security. A dishonest CA with a normal unique DN
> cannot revoke all Verisign certificates, but a dishonest CA with the same
DN
> as Verisign could revoke all verisign certificates even if located low
below
> Thawte hierarchy.
> 
> > I would also like to point out that a PKI in which two different CAs 
> > have the same name is invalid. The algorithm that Santosh has 
> > proposed works to mitigate the damage that would result if two 
> > different CAs in a PKI were using the same DN, but this is a 
> > scenario that should never happen in the first place. From my point 
> > of view, the main benefit of Santosh's proposal is that it improves 
> > efficiency by reducing the number of paths that one needs to 
> > consider during path discovery without putting undue restrictions on 
> > the PKI architecture.
> 
> I think Santosh algorithm is very nice, but as you said, it only 
> mitigates the risk, and I believe I proposed a scenario in which I can 
> fool this algorithm.
> 
> A also personally agree that a PKI in which two different entities 
> have the same DN is invalid (although the consensus on this does not 
> seem to be general). However, we have to assume it could happen, 
> possibly due to a dishonest participant. And, in fact, for pure 
> certificate path verification, this possibly invalid situation does 
> not adversely affect security. Hence, we also have to ensure that it 
> does not affect security when processing CRLs. We all agree it 
> currently does, and IMHO the issue is not entirely solved by Santosh 
> algorithm. If a CRL signer key belongs to a given CA, I think it has 
> to be cryptographically binded to the CA certificate signing key in 
> some way.
> 
> > I know that Denis Pinkas has stated: "For X.509, I do *not* say 
> > X.500,
> > a
> > DN is only relative to the CA who has given it." Presumably he is 
> > arguing that it is perfectly legitimate for two CAs in a PKI to have the

> > same name; the only requirement being that a CA can not issue two 
> > certificates with the same subject DN in which the subjects are 
> > different entities. If this is the case though, I would like to know 
> > where X.509 says this or even what text in X.509 implies that this is 
> > the case. Section 7 of X.509 states "CAs are unambiguously defined by a 
> > distinguished name in the DIT", which seems to contradict Denis' claim.
> > 
> > In conclusion, in X.509 it is not legitimate for two different
> > entities
> > to have the same DN and it is particularly important to ensure that two 
> > different CAs in a PKI do not use the same DN. At the same time, 
> > defense-in-depth is always a good strategy and in that light Santosh's 
> > algorithm does a good job of protecting against the risk that a PKI will

> > evolve in which two different CAs do use the same DN.
> 
> As I have just said before, I personally concur with your analysis, 
> but think that the proposed defence-in-depth is not sufficient and 
> that we need cryptographic binding.
> 
> Sincerely,
> 
> --
> Julien
> 
> > Julien Stern wrote:
> > 
> > >All,
> > >
> > >I believe X509 and PKIX are even much more flawed with respect to 
> > >CRL
> > >validation that underligned by Santosh. The flaw appear as soon as it 
> > >valid to sign a certificate and a CRL with different keys.
> > >
> > >I think the flaw CANNOT be solved without modifying the existing
> > >certificates or simply disallowing these different keys. Let me 
> > >explain:
> > >
> > >We all agree that a CA is defined by name. However, if two CAs have
> > >the same name, one of them may be able to revoke the other CA 
> > >certificates. I believe we agree on this flaw of X509 and RFC3280, 
> > >but I think the algorithm proposed by Santosh does not change the 
> > >situation.
> > >
> > >The flaw is more severe and is due to the fact that, when a CA is 
> > >using two different certificates for signing certificate and 
> > >signing CRLs, they are unrelated. In order to solve the flaw, we 
> > >need to link these two certificates by an other mean that the 
> > >ancestors. Actually, we probably need to sign the CRL signing 
> > >certificate with the certificate signing certificate.
> > >
> > >More precisely, if a CA, _any_ CA, whose certificate validates with
> > >respect to one of your Trust Anchor, agrees to deliver me a 
> > >certificate whose DN is the same DN as Verisign, I will easily be 
> > >able to revoke all Verisign certificates.
> > >
> > >The simple attack goes as follow:
> > >
> > >1) Find any moderately honest CA who agrees to sign me a 
> > >certificate
> > >signing certificate and a CRL signing certificate whose DNs match 
> > >Verisign DN.
> > >
> > >2) For the certificate signing certificate, send a CSR whose public
> > >key matches the _real_ Verisign CA certificate.
> > >
> > >3) For the CRL signing certificate, send a CSR whose public key
> > >correspond to a private key I know.
> > >
> > >4) Finally, simply revoke any legitimate Verisign user by producing
> > >CRLs signed with this private key.
> > >
> > >A path building algorithm will have two choices to go up when
> > >validating a Verisign certificate, (that is, two certificate with 
> > >matching DN and key). It it chooses mine, then, the path building 
> > >chain will go up to the same TA as the chain coming from my CRL and 
> > >all the DNs will match.
> > >
> > >Conclusions:
> > >
> > >- The current CRL checking algorithm is flawed
> > >- Santosh proposal solves some problems but unfortunately, not all
> > >- A possible way to solve the problem would be:
> > >
> > >1) Simply disallow different keys for certificate and CRL signing
> > >2) If different keys are allowed, then the CRL signing key MUST be 
> > >signed with the certificate signing key with an appropriate 
> > >delegation extension (aka ~ indirect CRLs)
> > >
> > 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6N8XtS044709; Sat, 6 Nov 2004 15:08:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6N8XIP044708; Sat, 6 Nov 2004 15:08:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-106-saturday.noc.nerim.net [62.4.17.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6N8WTu044683 for <[e-mail]>; Sat, 6 Nov 2004 15:08:32 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id C7FC962D95 for <[e-mail]>; Sun,  7 Nov 2004 00:08:33 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id BE147440E7 for <[e-mail]>; Sun,  7 Nov 2004 00:09:06 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11927-01 for <[e-mail]>; Sun, 7 Nov 2004 00:09:02 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id D1348440AE for <[e-mail]>; Sun,  7 Nov 2004 00:09:02 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Sun,  7 Nov 2004 00:08:32 +0100
From: "Julien Stern" <[e-mail]>
Date: Sun, 7 Nov 2004 00:08:32 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <001301c4c423$d34e73d0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001301c4c423$d34e73d0$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, Nov 06, 2004 at 12:12:36PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> One more thing.
> 
> Even in your example, only the certificates related to hierarchy underneath
> the rouge CA will be screwed it.  Even if you relied on the rouge CA, the
> name matching algorithm will be robust with respect to the other PKI
> hierarchies.
> 
> The proposal does prevent the attack since DN1 and DN 3 are not the same.
> Hence CRL certification path will not match that of the certificate
> certification path.  Please look at the check under the first bullet in
> slide 12.

Santosh,

I understand the name matching algorithm. However, you assume that the
path builder will pick the path
EE -> CA2 (DN2/KEY1) -> CA1 (DN1)

whereas it could AS WELL pick the path
EE -> CA3 (DN2/KEY1) -> ROGUECA (DN3)

which is as valid as the first one.
In that case, the name matching algorithm will perfectly work, 
because the CRL path is
FakeCRL -> CA3 (DN2/KEY2) -> ROGUECA (DN3)

The whole idea of the attack is that a rogue CA can produce a
certificate which matches the DN and KEY of an existing cert.
Of course, this certificate will be useless, because the private
key will not be known, but it may allow to fool the path building
algorithm into following an other path as the intended one.
If it does, it can leverage the fact that there is no cryptographic
binding between the cert and CRL key to produce a fake CRL.
If the path algorithm indeed follows my (valid!) but rogue path,
then the CRL will match.

--
Julien

> 
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]] 
> Sent: Saturday, November 06, 2004 11:56 AM
> To: 'Julien Stern'; '[e-mail]'
> Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Julien,
> 
> A CA is not permitted to issue certificates to two distinct entities with
> the same name.  Your example violates this constraint.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Julien Stern
> Sent: Saturday, November 06, 2004 8:38 AM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> Santosh,
> 
> See response in-line.
> 
> On Fri, Nov 05, 2004 at 04:07:08PM -0500, Santosh Chokhani wrote:
> > 
> > Julien,
> > 
> > The algorithm proposed specifically eliminates the risk.
> > 
> > The certificate certification path and the CRL certification path will
> > not match because CRL certification path has the node VeriSign CA in 
> > it and the certificate certification path has the node real_VersiSign 
> > CA in it.
> > 
> > May be you mean that the two CAs have really the same DN.  Well, in
> > that case, the algorithm makes sure that all the DNs of the CAs in the 
> > two paths match (one for one) starting with the DN of the trust 
> > anchor.  So, in order for the attack to work, a CA in the system must 
> > have certified two distinct CAs for the same subject DN.  If a CA does 
> > that, all bets are off.
> > 
> > Please look at the algorithm closely.  It is match two different
> > paths.
> 
> Well, I might be wrong, be I believe my scenario is NOT eliminated by your
> proposal.
> 
> You say that your assumption is that a CA in the system must not certify two
> distincts CAs for the same subject DN. Which would be:
> 
>      CA1
>      DN1
>     /   \
>   CA2   CA3
>   DN2   DN2
> 
> In the scenario I envisionned, the "graph" would be:
> 
>     CA1        ROGUECA
>     DN1          DN3
>      |          /   \
>     CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
>     DN2       DN2   DN2
>     KEY1      KEY1  KEY2
> 
> 
> Now, I have a legitime certificate EE issued by CA2, with DN2 and KEY2. The
> path building algorithm has TWO choices to reconstruct the path (well unless
> specific helper extensions are used, but we should not rely on them for
> security), namely:
> 
>     CA1        ROGUECA
>     DN1          DN3
>      |          /   \
>     CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
>     DN2       DN2   DN2
>     KEY1      KEY1  KEY2
>        \      /      |
>          \  /        |
>           EE      Fake CRL
> 
> If it goes on the "left" side, you proposal prevents the attack. If it goes
> on the "right" side, you proposal does not, because the CRL has a match for
> all the ancestors. Consequently, we are in a situation where the same
> certificate will be seen as revoked or not depending on the first path
> chosen by the path building algorithm, which is believe is bad.
> 
> > Also, look at the extension that cryptographically binds the CA's keys
> > to the CRL.
> > 
> > BTW, Step 2 should not happen in a PKI.  A CA must not bind a public
> > key to a wrong subject (specially, when the subject is a CA).  This is 
> > one of the reasons we require proof of possession of a private key.  
> > But, even with Step 2 that no CA would do, the algorithm will not let 
> > another claim to be you.
> 
> I agree step 2 should not happen. I guess that if I could possibly convince
> a CA to give a a CA cert with Verisign DN, I could also convince it to
> "forget" to verify the POP :)
> 
> But serioulsy, I believe that such a RogueCA can indeed publish fake CRLs
> that would be validated even by your improved algorithm.
> 
> Please let me know if you believe I overlooked something
> 
> Sincerely,
> 
> --
> Julien
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Friday, November 05, 2004 1:38 PM
> > To: [e-mail]
> > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > 
> > All,
> > 
> > I believe X509 and PKIX are even much more flawed with respect to CRL
> > validation that underligned by Santosh. The flaw appear as soon as it 
> > valid to sign a certificate and a CRL with different keys.
> > 
> > I think the flaw CANNOT be solved without modifying the existing
> > certificates or simply disallowing these different keys. Let me 
> > explain:
> > 
> > We all agree that a CA is defined by name. However, if two CAs have
> > the same name, one of them may be able to revoke the other CA 
> > certificates. I believe we agree on this flaw of X509 and RFC3280, but 
> > I think the algorithm proposed by Santosh does not change the 
> > situation.
> > 
> > The flaw is more severe and is due to the fact that, when
> > a CA is using two different certificates for signing certificate and
> > signing CRLs, they are unrelated. In order to solve the flaw, we need 
> > to link these two certificates by an other mean that the ancestors. 
> > Actually, we probably need to sign the CRL signing certificate with 
> > the certificate signing certificate.
> > 
> > More precisely, if a CA, _any_ CA, whose certificate validates with
> > respect to one of your Trust Anchor, agrees to deliver me a 
> > certificate whose DN is the same DN as Verisign, I will easily be able 
> > to revoke all Verisign certificates.
> > 
> > The simple attack goes as follow:
> > 
> > 1) Find any moderately honest CA who agrees to sign me a certificate
> > signing certificate and a CRL signing certificate whose DNs match 
> > Verisign DN.
> > 
> > 2) For the certificate signing certificate, send a CSR whose public
> > key matches the _real_ Verisign CA certificate.
> > 
> > 3) For the CRL signing certificate, send a CSR whose public key
> > correspond to a private key I know.
> > 
> > 4) Finally, simply revoke any legitimate Verisign user by producing
> > CRLs signed with this private key.
> > 
> > A path building algorithm will have two choices to go up when
> > validating a Verisign certificate, (that is, two certificate with 
> > matching DN and key). It it chooses mine, then, the path building 
> > chain will go up to the same TA as the chain coming from my CRL and 
> > all the DNs will match.
> > 
> > Conclusions:
> > 
> > - The current CRL checking algorithm is flawed
> > - Santosh proposal solves some problems but unfortunately, not all
> > - A possible way to solve the problem would be:
> > 
> > 1) Simply disallow different keys for certificate and CRL signing
> > 2) If different keys are allowed, then the CRL signing key MUST be 
> > signed with the certificate signing key with an appropriate delegation 
> > extension (aka ~ indirect CRLs)
> > 
> > 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6Mw5rY039197; Sat, 6 Nov 2004 14:58:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6Mw53F039196; Sat, 6 Nov 2004 14:58:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-106-saturday.nerim.net [62.4.16.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6Mw4NJ039138 for <[e-mail]>; Sat, 6 Nov 2004 14:58:04 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id C20B641B74 for <[e-mail]>; Sat,  6 Nov 2004 23:57:58 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 56036440E7 for <[e-mail]>; Sat,  6 Nov 2004 23:58:30 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11709-08 for <[e-mail]>; Sat, 6 Nov 2004 23:58:26 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 861C6440AE for <[e-mail]>; Sat,  6 Nov 2004 23:58:26 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Sat,  6 Nov 2004 23:57:56 +0100
From: "Julien Stern" <[e-mail]>
Date: Sat, 6 Nov 2004 23:57:56 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <001201c4c422$63e34f30$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001201c4c422$63e34f30$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, Nov 06, 2004 at 12:02:20PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> Even if a CA down in the chain had the same name as VeriSign, the matching
> algorithm will work since all the CA DNs starting and including that of the
> trust anchor and up to the end of the CRL path (in case of direct CRL) must
> match those in the certificate certification path.  Thus, a downstream
> VeriSign can not masquerade an upstream VeriSign.
> 
> The only way a CA can masquerade as another CA is if all the CASs in their
> paths (including the trust anchor) have the same DN.  In order for that to
> happen, a CA at same level must certify two distinct authorities for the
> same DN.  X.509 does not permit. That.  If CA does this wrong, all bets are
> off.  For that matter, a CA could post its private key on the Internet.  We
> do not have defense against that.

I disagree with the previous paragraph.
What you describe is one way to masquerade as an other CA.
My example is an other way to do so. You seem to assume that
certification paths from EE to TAs are unique. If a create a rogue
cert which matches a real CA DN and key, the path building algorithm
might pick my certificate.

Consequently, your algorithm works if
1) No CA issues two certificates to two entities with the same DN.
AND
2) No CA issues a certificate matching the DN and key of another CA.

My example uses the second case, not the first one.

> You are encouraged to carefully read, analyze, and understand the algorithm.

I read it very carefully, analyzed it, hopefully understood it, and
actually implemented it. It was during the implementation that what I
think is a the flaw was highlighted.

If you also have a implementation, would you like me to produce a set of
certificates which highlight the problem I talking about ?

--
Julien


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Julien Stern
> Sent: Saturday, November 06, 2004 9:43 AM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> David,
> 
> See response in-line.
> 
> On Fri, Nov 05, 2004 at 04:37:52PM -0500, David A. Cooper wrote:
> > Julien,
> > 
> > I don't believe that the scenario you described indicates a flaw in
> > X.509/RFC 3280. Your scenario begins with the assumption that your were 
> > able to get a CA to issue you a CA certificate with a subject DN of 
> > Verisign (you further assumed that were valid certification paths from 
> > one or more trust anchors used by relying parties to this CA).
> > 
> > Once an attacker has been issued a valid CA certificate the system is
> > compromised (until the certificate that has been issued to the attacker 
> > has been revoked). In your scenario, you could just as easily have 
> > obtained a CA certificate (with keyCertSign set) with a public key 
> > corresponding to a private key that you knew. You would then be able to 
> > issue bogus certificates, not just revoke legitimate ones. If an 
> > attacker were issued a CA certificate from one of the CAs in my PKI 
> > (such that my relying parties would validate certificates issued by that 
> > CA), that CA's ability to revoke valid certificates would be the least 
> > of my concerns since the CA could also issue bogus certificates.
> 
> I do not think that the issue you describe and the one I described are
> situed at the same level.
> 
> Let me explain:
> Assume your configuration trusts exactly two TAs, say Verisign and Thawte.
> Also assume that both of them have a complex hierarchy of CAs below them.  
> 
> Now, all the CAs in these two hierarchies can produce "valid" EE certs, that
> is, certs that will be validated by path verification algorithm.
> 
> The fact that one of the CA low in the hierarchy would have the same DN as
> Verisign does not change anything to the problem. And while this "should not
> happen", this does not endanger security as long as your TAs are legitimate.
> If a CA produces bogus certificates, (which cannot be theoretically
> prevented), its certificate should be revoked, but the DN is irrelevant.
> 
> Now, in my (admitedly twisted, my possible) scenario, 
> the DN _is_ relevant for security. A dishonest CA with a normal unique DN
> cannot revoke all Verisign certificates, but a dishonest CA with the same DN
> as Verisign could revoke all verisign certificates even if located low below
> Thawte hierarchy.
> 
> > I would also like to point out that a PKI in which two different CAs
> > have the same name is invalid. The algorithm that Santosh has proposed 
> > works to mitigate the damage that would result if two different CAs in a 
> > PKI were using the same DN, but this is a scenario that should never 
> > happen in the first place. From my point of view, the main benefit of 
> > Santosh's proposal is that it improves efficiency by reducing the number 
> > of paths that one needs to consider during path discovery without 
> > putting undue restrictions on the PKI architecture.
> 
> I think Santosh algorithm is very nice, but as you said, it only mitigates
> the risk, and I believe I proposed a scenario in which I can fool this
> algorithm.
> 
> A also personally agree that a PKI in which two different entities have the
> same DN is invalid (although the consensus on this does not seem to be
> general). However, we have to assume it could happen, possibly due to a
> dishonest participant. And, in fact, for pure certificate path verification,
> this possibly invalid situation does not adversely affect security. Hence,
> we also have to ensure that it does not affect security when processing
> CRLs. We all agree it currently does, and IMHO the issue is not entirely
> solved by Santosh algorithm. If a CRL signer key belongs to a given CA, I
> think it has to be cryptographically binded to the CA certificate signing
> key in some way.
> 
> > I know that Denis Pinkas has stated: "For X.509, I do *not* say X.500, 
> > a
> > DN is only relative to the CA who has given it." Presumably he is 
> > arguing that it is perfectly legitimate for two CAs in a PKI to have the 
> > same name; the only requirement being that a CA can not issue two 
> > certificates with the same subject DN in which the subjects are 
> > different entities. If this is the case though, I would like to know 
> > where X.509 says this or even what text in X.509 implies that this is 
> > the case. Section 7 of X.509 states "CAs are unambiguously defined by a 
> > distinguished name in the DIT", which seems to contradict Denis' claim.
> > 
> > In conclusion, in X.509 it is not legitimate for two different 
> > entities
> > to have the same DN and it is particularly important to ensure that two 
> > different CAs in a PKI do not use the same DN. At the same time, 
> > defense-in-depth is always a good strategy and in that light Santosh's 
> > algorithm does a good job of protecting against the risk that a PKI will 
> > evolve in which two different CAs do use the same DN.
> 
> As I have just said before, I personally concur with your analysis, but
> think that the proposed defence-in-depth is not sufficient and that we need
> cryptographic binding.
> 
> Sincerely,
> 
> --
> Julien
> 
> > Julien Stern wrote:
> > 
> > >All,
> > >
> > >I believe X509 and PKIX are even much more flawed with respect to CRL 
> > >validation that underligned by Santosh. The flaw appear as soon as it 
> > >valid to sign a certificate and a CRL with different keys.
> > >
> > >I think the flaw CANNOT be solved without modifying the existing 
> > >certificates or simply disallowing these different keys. Let me 
> > >explain:
> > >
> > >We all agree that a CA is defined by name. However, if two CAs have 
> > >the same name, one of them may be able to revoke the other CA 
> > >certificates. I believe we agree on this flaw of X509 and RFC3280, 
> > >but I think the algorithm proposed by Santosh does not change the 
> > >situation.
> > >
> > >The flaw is more severe and is due to the fact that, when
> > >a CA is using two different certificates for signing certificate and 
> > >signing CRLs, they are unrelated. In order to solve the flaw, we need 
> > >to link these two certificates by an other mean that the ancestors. 
> > >Actually, we probably need to sign the CRL signing certificate with 
> > >the certificate signing certificate.
> > >
> > >More precisely, if a CA, _any_ CA, whose certificate validates with 
> > >respect to one of your Trust Anchor, agrees to deliver me a 
> > >certificate whose DN is the same DN as Verisign, I will easily be 
> > >able to revoke all Verisign certificates.
> > >
> > >The simple attack goes as follow:
> > >
> > >1) Find any moderately honest CA who agrees to sign me a certificate 
> > >signing certificate and a CRL signing certificate whose DNs match 
> > >Verisign DN.
> > >
> > >2) For the certificate signing certificate, send a CSR whose public 
> > >key matches the _real_ Verisign CA certificate.
> > >
> > >3) For the CRL signing certificate, send a CSR whose public key 
> > >correspond to a private key I know.
> > >
> > >4) Finally, simply revoke any legitimate Verisign user by producing 
> > >CRLs signed with this private key.
> > >
> > >A path building algorithm will have two choices to go up when 
> > >validating a Verisign certificate, (that is, two certificate with 
> > >matching DN and key). It it chooses mine, then, the path building 
> > >chain will go up to the same TA as the chain coming from my CRL and 
> > >all the DNs will match.
> > >
> > >Conclusions:
> > >
> > >- The current CRL checking algorithm is flawed
> > >- Santosh proposal solves some problems but unfortunately, not all
> > >- A possible way to solve the problem would be:
> > >
> > >1) Simply disallow different keys for certificate and CRL signing
> > >2) If different keys are allowed, then the CRL signing key MUST
> > >be signed with the certificate signing key with an appropriate
> > >delegation extension (aka ~ indirect CRLs)
> > >
> > 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6MnRjW035574; Sat, 6 Nov 2004 14:49:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6MnROi035573; Sat, 6 Nov 2004 14:49:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-106-saturday.noc.nerim.net [62.4.17.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6MnMQG035539 for <[e-mail]>; Sat, 6 Nov 2004 14:49:26 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 63D7562D47 for <[e-mail]>; Sat,  6 Nov 2004 23:49:23 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 3DB0A440E7 for <[e-mail]>; Sat,  6 Nov 2004 23:49:56 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11709-07 for <[e-mail]>; Sat, 6 Nov 2004 23:49:52 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 44337440AE for <[e-mail]>; Sat,  6 Nov 2004 23:49:52 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Sat,  6 Nov 2004 23:49:22 +0100
From: "Julien Stern" <[e-mail]>
Date: Sat, 6 Nov 2004 23:49:22 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <001101c4c421$83ec68d0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001101c4c421$83ec68d0$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, Nov 06, 2004 at 11:56:04AM -0500, Santosh Chokhani wrote:
> Julien,
> 
> A CA is not permitted to issue certificates to two distinct entities with
> the same name.  Your example violates this constraint.

Santosh,

As I have stated in my previous email, my example does not violates
this constraint. No CA ever issues certificates to two distincts
entities with the same name. I simply have two DIFFERENT CAs that issue
certificates to different entities with the same name.

Consequently , I still this my example is valid.

--
Julien

> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Julien Stern
> Sent: Saturday, November 06, 2004 8:38 AM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> Santosh,
> 
> See response in-line.
> 
> On Fri, Nov 05, 2004 at 04:07:08PM -0500, Santosh Chokhani wrote:
> > 
> > Julien,
> > 
> > The algorithm proposed specifically eliminates the risk.
> > 
> > The certificate certification path and the CRL certification path will 
> > not match because CRL certification path has the node VeriSign CA in 
> > it and the certificate certification path has the node real_VersiSign 
> > CA in it.
> > 
> > May be you mean that the two CAs have really the same DN.  Well, in 
> > that case, the algorithm makes sure that all the DNs of the CAs in the 
> > two paths match (one for one) starting with the DN of the trust 
> > anchor.  So, in order for the attack to work, a CA in the system must 
> > have certified two distinct CAs for the same subject DN.  If a CA does 
> > that, all bets are off.
> > 
> > Please look at the algorithm closely.  It is match two different 
> > paths.
> 
> Well, I might be wrong, be I believe my scenario is NOT eliminated by your
> proposal.
> 
> You say that your assumption is that a CA in the system must not certify two
> distincts CAs for the same subject DN. Which would be:
> 
>      CA1
>      DN1
>     /   \
>   CA2   CA3
>   DN2   DN2
> 
> In the scenario I envisionned, the "graph" would be:
> 
>     CA1        ROGUECA
>     DN1          DN3
>      |          /   \
>     CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
>     DN2       DN2   DN2
>     KEY1      KEY1  KEY2
> 
> 
> Now, I have a legitime certificate EE issued by CA2, with DN2 and KEY2. The
> path building algorithm has TWO choices to reconstruct the path (well unless
> specific helper extensions are used, but we should not rely on them for
> security), namely:
> 
>     CA1        ROGUECA
>     DN1          DN3
>      |          /   \
>     CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
>     DN2       DN2   DN2
>     KEY1      KEY1  KEY2
>        \      /      |
>          \  /        |
>           EE      Fake CRL
> 
> If it goes on the "left" side, you proposal prevents the attack. If it goes
> on the "right" side, you proposal does not, because the CRL has a match for
> all the ancestors. Consequently, we are in a situation where the same
> certificate will be seen as revoked or not depending on the first path
> chosen by the path building algorithm, which is believe is bad.
> 
> > Also, look at the extension that cryptographically binds the CA's keys 
> > to the CRL.
> > 
> > BTW, Step 2 should not happen in a PKI.  A CA must not bind a public 
> > key to a wrong subject (specially, when the subject is a CA).  This is 
> > one of the reasons we require proof of possession of a private key.  
> > But, even with Step 2 that no CA would do, the algorithm will not let 
> > another claim to be you.
> 
> I agree step 2 should not happen. I guess that if I could possibly convince
> a CA to give a a CA cert with Verisign DN, I could also convince it to
> "forget" to verify the POP :)
> 
> But serioulsy, I believe that such a RogueCA can indeed publish fake CRLs
> that would be validated even by your improved algorithm.
> 
> Please let me know if you believe I overlooked something
> 
> Sincerely,
> 
> --
> Julien
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Friday, November 05, 2004 1:38 PM
> > To: [e-mail]
> > Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > 
> > All,
> > 
> > I believe X509 and PKIX are even much more flawed with respect to CRL 
> > validation that underligned by Santosh. The flaw appear as soon as it 
> > valid to sign a certificate and a CRL with different keys.
> > 
> > I think the flaw CANNOT be solved without modifying the existing 
> > certificates or simply disallowing these different keys. Let me 
> > explain:
> > 
> > We all agree that a CA is defined by name. However, if two CAs have 
> > the same name, one of them may be able to revoke the other CA 
> > certificates. I believe we agree on this flaw of X509 and RFC3280, but 
> > I think the algorithm proposed by Santosh does not change the 
> > situation.
> > 
> > The flaw is more severe and is due to the fact that, when
> > a CA is using two different certificates for signing certificate and 
> > signing CRLs, they are unrelated. In order to solve the flaw, we need 
> > to link these two certificates by an other mean that the ancestors. 
> > Actually, we probably need to sign the CRL signing certificate with 
> > the certificate signing certificate.
> > 
> > More precisely, if a CA, _any_ CA, whose certificate validates with 
> > respect to one of your Trust Anchor, agrees to deliver me a 
> > certificate whose DN is the same DN as Verisign, I will easily be able 
> > to revoke all Verisign certificates.
> > 
> > The simple attack goes as follow:
> > 
> > 1) Find any moderately honest CA who agrees to sign me a certificate 
> > signing certificate and a CRL signing certificate whose DNs match 
> > Verisign DN.
> > 
> > 2) For the certificate signing certificate, send a CSR whose public 
> > key matches the _real_ Verisign CA certificate.
> > 
> > 3) For the CRL signing certificate, send a CSR whose public key 
> > correspond to a private key I know.
> > 
> > 4) Finally, simply revoke any legitimate Verisign user by producing 
> > CRLs signed with this private key.
> > 
> > A path building algorithm will have two choices to go up when 
> > validating a Verisign certificate, (that is, two certificate with 
> > matching DN and key). It it chooses mine, then, the path building 
> > chain will go up to the same TA as the chain coming from my CRL and 
> > all the DNs will match.
> > 
> > Conclusions:
> > 
> > - The current CRL checking algorithm is flawed
> > - Santosh proposal solves some problems but unfortunately, not all
> > - A possible way to solve the problem would be:
> > 
> > 1) Simply disallow different keys for certificate and CRL signing
> > 2) If different keys are allowed, then the CRL signing key MUST be signed
> > with the certificate signing key with an appropriate delegation extension
> > (aka ~ indirect CRLs)
> > 
> > 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6K9ppw057991; Sat, 6 Nov 2004 12:09:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6K9pkM057989; Sat, 6 Nov 2004 12:09:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com ([e-mail] [217.13.230.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6K9nst057950 for <[e-mail]>; Sat, 6 Nov 2004 12:09:50 -0800 (PST) (envelope-from [e-mail])
Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.1/8.13.1/Debian-15) with ESMTP id iA6K9oIE021986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for <[e-mail]>; Sat, 6 Nov 2004 21:09:51 +0100
To: [e-mail]
Subject: Please review X.509 part of RFC 2538bis
From: Simon Josefsson <[e-mail]>
X-Hashcash: 1:22:041106:[e-mail]::mZ8WtgaFipw1JMGg:00000000000000000000000000000000000000000000Cugr
Date: Sat, 06 Nov 2004 21:09:49 +0100
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on yxa-iv
X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on yxa-iv
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

RFC 2538, which specify how to store certificates in the Domain Name
System, is being revised.  If members of this WG has any feedback on
the X.509 part of the document, that would be appreciated.

So far there has been no changes to the X.509 part of the revised
document, mainly because of lack of feedback.  So if anyone here has
thoughts on whether the X.509 part of the specification is in a useful
state or not, that would be useful.

The revised document is available from:

http://www.ietf.org/internet-drafts/draft-josefsson-rfc2538bis-00.txt

To simplify review, I include the X.509 relevant parts of the document
below.  Are the OIDs correct?  Has anything changed that affect the
Subject/Issuer naming discussion?

If there are no proposed changes, the text will likely remain
unchanged.

If someone wishes to review all changes between RFC 2538 and the
revised document, there are some resources at:

http://josefsson.org/rfc2538bis/

This work is probably not within the PKIX WG charter, so please reply
to me off-list.  Of course, if you believe on-list discussion would be
useful, feel free to reply to the list.

Thanks,
Simon

...
   The PKIX type is reserved to indicate an X.509 certificate conforming
   to the profile being defined by the IETF PKIX working group.  The
   certificate section will start with a one byte unsigned OID length
   and then an X.500 OID indicating the nature of the remainder of the
   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
   not include their X.500 directory type designating OID as a prefix.)
...
2.3  X.509 OIDs

   OIDs have been defined in connection with the X.500 directory for
   user certificates, certification authority certificates, revocations
   of certification authority, and revocations of user certificates.
   The following table lists the OIDs, their BER encoding, and their
   length prefixed hex format for use in CERT RRs:

       id-at-userCertificate
           = { joint-iso-ccitt(2) ds(5) at(4) 36 }
              == 0x 03 55 04 24
       id-at-cACertificate
           = { joint-iso-ccitt(2) ds(5) at(4) 37 }
              == 0x 03 55 04 25
       id-at-authorityRevocationList
           = { joint-iso-ccitt(2) ds(5) at(4) 38 }
              == 0x 03 55 04 26
       id-at-certificateRevocationList
           = { joint-iso-ccitt(2) ds(5) at(4) 39 }
              == 0x 03 55 04 27


3.  Appropriate Owner Names for CERT RRs

   It is recommended that certificate CERT RRs be stored under a domain
   name related to their subject, i.e., the name of the entity intended
   to control the private key corresponding to the public key being
   certified.  It is recommended that certificate revocation list CERT
   RRs be stored under a domain name related to their issuer.

   Following some of the guidelines below may result in the use in DNS
   names of characters that require DNS quoting which is to use a
   backslash followed by the octal representation of the ASCII code for
   the character such as \000 for NULL.

3.1  X.509 CERT RR Names

   Some X.509 versions permit multiple names to be associated with
   subjects and issuers under "Subject Alternate Name" and "Issuer
   Alternate Name".  For example, x.509v3 has such Alternate Names with
   an ASN.1 specification as follows:

        GeneralName ::= CHOICE {
           otherName                  [0] INSTANCE OF OTHER-NAME,
           rfc822Name                 [1] IA5String,
           dNSName                    [2] IA5String,
           x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
           directoryName              [4] EXPLICIT Name,
           ediPartyName               [5] EDIPartyName,
           uniformResourceIdentifier  [6] IA5String,
           iPAddress                  [7] OCTET STRING,
           registeredID               [8] OBJECT IDENTIFIER
        }

   The recommended locations of CERT storage are as follows, in priority
   order:
   1.  If a domain name is included in the identification in the
       certificate or CRL, that should be used.
   2.  If a domain name is not included but an IP address is included,
       then the translation of that IP address into the appropriate
       inverse domain name should be used.
   3.  If neither of the above it used but a URI containing a domain
       name is present, that domain name should be used.
   4.  If none of the above is included but a character string name is
       included, then it should be treated as described for PGP names in
       3.2 below.
   5.  If none of the above apply, then the distinguished name (DN)
       should be mapped into a domain name as specified in [3].

   Example 1: Assume that an X.509v3 certificate is issued to /CN=John
   Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative
   names of (a) string "John (the Man) Doe", (b) domain name john-
   doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>.  Then
   the storage locations recommended, in priority order, would be
   1.  john-doe.com,
   2.  www.secure.john-doe.com, and
   3.  Doe.com.xy.

   Example 2: Assume that an X.509v3 certificate is issued to /CN=James
   Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
   of (a) domain name widget.foo.example, (b) IPv4 address
   10.251.13.201, and (c) string "James Hacker
   <[e-mail]>".  Then the storage locations
   recommended, in priority order, would be
   1.  widget.foo.example,
   2.  201.13.251.10.in-addr.arpa, and
   3.  hacker.mail.widget.foo.example.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6HCeiu077009; Sat, 6 Nov 2004 09:12:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6HCeZL077008; Sat, 6 Nov 2004 09:12:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6HCdBW077002 for <[e-mail]>; Sat, 6 Nov 2004 09:12:40 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA6HCg89021782 for <[e-mail]>; Sat, 6 Nov 2004 12:12:42 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Sat, 6 Nov 2004 12:12:36 -0500
Message-ID: <001301c4c423$d34e73d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA6HCeBW077003
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

One more thing.

Even in your example, only the certificates related to hierarchy underneath
the rouge CA will be screwed it.  Even if you relied on the rouge CA, the
name matching algorithm will be robust with respect to the other PKI
hierarchies.

The proposal does prevent the attack since DN1 and DN 3 are not the same.
Hence CRL certification path will not match that of the certificate
certification path.  Please look at the check under the first bullet in
slide 12.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Saturday, November 06, 2004 11:56 AM
To: 'Julien Stern'; '[e-mail]'
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting


Julien,

A CA is not permitted to issue certificates to two distinct entities with
the same name.  Your example violates this constraint.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Saturday, November 06, 2004 8:38 AM
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



Santosh,

See response in-line.

On Fri, Nov 05, 2004 at 04:07:08PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> The algorithm proposed specifically eliminates the risk.
> 
> The certificate certification path and the CRL certification path will
> not match because CRL certification path has the node VeriSign CA in 
> it and the certificate certification path has the node real_VersiSign 
> CA in it.
> 
> May be you mean that the two CAs have really the same DN.  Well, in
> that case, the algorithm makes sure that all the DNs of the CAs in the 
> two paths match (one for one) starting with the DN of the trust 
> anchor.  So, in order for the attack to work, a CA in the system must 
> have certified two distinct CAs for the same subject DN.  If a CA does 
> that, all bets are off.
> 
> Please look at the algorithm closely.  It is match two different
> paths.

Well, I might be wrong, be I believe my scenario is NOT eliminated by your
proposal.

You say that your assumption is that a CA in the system must not certify two
distincts CAs for the same subject DN. Which would be:

     CA1
     DN1
    /   \
  CA2   CA3
  DN2   DN2

In the scenario I envisionned, the "graph" would be:

    CA1        ROGUECA
    DN1          DN3
     |          /   \
    CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
    DN2       DN2   DN2
    KEY1      KEY1  KEY2


Now, I have a legitime certificate EE issued by CA2, with DN2 and KEY2. The
path building algorithm has TWO choices to reconstruct the path (well unless
specific helper extensions are used, but we should not rely on them for
security), namely:

    CA1        ROGUECA
    DN1          DN3
     |          /   \
    CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
    DN2       DN2   DN2
    KEY1      KEY1  KEY2
       \      /      |
         \  /        |
          EE      Fake CRL

If it goes on the "left" side, you proposal prevents the attack. If it goes
on the "right" side, you proposal does not, because the CRL has a match for
all the ancestors. Consequently, we are in a situation where the same
certificate will be seen as revoked or not depending on the first path
chosen by the path building algorithm, which is believe is bad.

> Also, look at the extension that cryptographically binds the CA's keys
> to the CRL.
> 
> BTW, Step 2 should not happen in a PKI.  A CA must not bind a public
> key to a wrong subject (specially, when the subject is a CA).  This is 
> one of the reasons we require proof of possession of a private key.  
> But, even with Step 2 that no CA would do, the algorithm will not let 
> another claim to be you.

I agree step 2 should not happen. I guess that if I could possibly convince
a CA to give a a CA cert with Verisign DN, I could also convince it to
"forget" to verify the POP :)

But serioulsy, I believe that such a RogueCA can indeed publish fake CRLs
that would be validated even by your improved algorithm.

Please let me know if you believe I overlooked something

Sincerely,

--
Julien

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Friday, November 05, 2004 1:38 PM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> All,
> 
> I believe X509 and PKIX are even much more flawed with respect to CRL
> validation that underligned by Santosh. The flaw appear as soon as it 
> valid to sign a certificate and a CRL with different keys.
> 
> I think the flaw CANNOT be solved without modifying the existing
> certificates or simply disallowing these different keys. Let me 
> explain:
> 
> We all agree that a CA is defined by name. However, if two CAs have
> the same name, one of them may be able to revoke the other CA 
> certificates. I believe we agree on this flaw of X509 and RFC3280, but 
> I think the algorithm proposed by Santosh does not change the 
> situation.
> 
> The flaw is more severe and is due to the fact that, when
> a CA is using two different certificates for signing certificate and
> signing CRLs, they are unrelated. In order to solve the flaw, we need 
> to link these two certificates by an other mean that the ancestors. 
> Actually, we probably need to sign the CRL signing certificate with 
> the certificate signing certificate.
> 
> More precisely, if a CA, _any_ CA, whose certificate validates with
> respect to one of your Trust Anchor, agrees to deliver me a 
> certificate whose DN is the same DN as Verisign, I will easily be able 
> to revoke all Verisign certificates.
> 
> The simple attack goes as follow:
> 
> 1) Find any moderately honest CA who agrees to sign me a certificate
> signing certificate and a CRL signing certificate whose DNs match 
> Verisign DN.
> 
> 2) For the certificate signing certificate, send a CSR whose public
> key matches the _real_ Verisign CA certificate.
> 
> 3) For the CRL signing certificate, send a CSR whose public key
> correspond to a private key I know.
> 
> 4) Finally, simply revoke any legitimate Verisign user by producing
> CRLs signed with this private key.
> 
> A path building algorithm will have two choices to go up when
> validating a Verisign certificate, (that is, two certificate with 
> matching DN and key). It it chooses mine, then, the path building 
> chain will go up to the same TA as the chain coming from my CRL and 
> all the DNs will match.
> 
> Conclusions:
> 
> - The current CRL checking algorithm is flawed
> - Santosh proposal solves some problems but unfortunately, not all
> - A possible way to solve the problem would be:
> 
> 1) Simply disallow different keys for certificate and CRL signing
> 2) If different keys are allowed, then the CRL signing key MUST be 
> signed with the certificate signing key with an appropriate delegation 
> extension (aka ~ indirect CRLs)
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6H2OTd072039; Sat, 6 Nov 2004 09:02:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6H2OCj072038; Sat, 6 Nov 2004 09:02:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6H2Nc8072028 for <[e-mail]>; Sat, 6 Nov 2004 09:02:23 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA6H2P89011486 for <[e-mail]>; Sat, 6 Nov 2004 12:02:26 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Sat, 6 Nov 2004 12:02:20 -0500
Message-ID: <001201c4c422$63e34f30$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA6H2Nc8072031
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

Even if a CA down in the chain had the same name as VeriSign, the matching
algorithm will work since all the CA DNs starting and including that of the
trust anchor and up to the end of the CRL path (in case of direct CRL) must
match those in the certificate certification path.  Thus, a downstream
VeriSign can not masquerade an upstream VeriSign.

The only way a CA can masquerade as another CA is if all the CASs in their
paths (including the trust anchor) have the same DN.  In order for that to
happen, a CA at same level must certify two distinct authorities for the
same DN.  X.509 does not permit. That.  If CA does this wrong, all bets are
off.  For that matter, a CA could post its private key on the Internet.  We
do not have defense against that.

You are encouraged to carefully read, analyze, and understand the algorithm.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Saturday, November 06, 2004 9:43 AM
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



David,

See response in-line.

On Fri, Nov 05, 2004 at 04:37:52PM -0500, David A. Cooper wrote:
> Julien,
> 
> I don't believe that the scenario you described indicates a flaw in
> X.509/RFC 3280. Your scenario begins with the assumption that your were 
> able to get a CA to issue you a CA certificate with a subject DN of 
> Verisign (you further assumed that were valid certification paths from 
> one or more trust anchors used by relying parties to this CA).
> 
> Once an attacker has been issued a valid CA certificate the system is
> compromised (until the certificate that has been issued to the attacker 
> has been revoked). In your scenario, you could just as easily have 
> obtained a CA certificate (with keyCertSign set) with a public key 
> corresponding to a private key that you knew. You would then be able to 
> issue bogus certificates, not just revoke legitimate ones. If an 
> attacker were issued a CA certificate from one of the CAs in my PKI 
> (such that my relying parties would validate certificates issued by that 
> CA), that CA's ability to revoke valid certificates would be the least 
> of my concerns since the CA could also issue bogus certificates.

I do not think that the issue you describe and the one I described are
situed at the same level.

Let me explain:
Assume your configuration trusts exactly two TAs, say Verisign and Thawte.
Also assume that both of them have a complex hierarchy of CAs below them.  

Now, all the CAs in these two hierarchies can produce "valid" EE certs, that
is, certs that will be validated by path verification algorithm.

The fact that one of the CA low in the hierarchy would have the same DN as
Verisign does not change anything to the problem. And while this "should not
happen", this does not endanger security as long as your TAs are legitimate.
If a CA produces bogus certificates, (which cannot be theoretically
prevented), its certificate should be revoked, but the DN is irrelevant.

Now, in my (admitedly twisted, my possible) scenario, 
the DN _is_ relevant for security. A dishonest CA with a normal unique DN
cannot revoke all Verisign certificates, but a dishonest CA with the same DN
as Verisign could revoke all verisign certificates even if located low below
Thawte hierarchy.

> I would also like to point out that a PKI in which two different CAs
> have the same name is invalid. The algorithm that Santosh has proposed 
> works to mitigate the damage that would result if two different CAs in a 
> PKI were using the same DN, but this is a scenario that should never 
> happen in the first place. From my point of view, the main benefit of 
> Santosh's proposal is that it improves efficiency by reducing the number 
> of paths that one needs to consider during path discovery without 
> putting undue restrictions on the PKI architecture.

I think Santosh algorithm is very nice, but as you said, it only mitigates
the risk, and I believe I proposed a scenario in which I can fool this
algorithm.

A also personally agree that a PKI in which two different entities have the
same DN is invalid (although the consensus on this does not seem to be
general). However, we have to assume it could happen, possibly due to a
dishonest participant. And, in fact, for pure certificate path verification,
this possibly invalid situation does not adversely affect security. Hence,
we also have to ensure that it does not affect security when processing
CRLs. We all agree it currently does, and IMHO the issue is not entirely
solved by Santosh algorithm. If a CRL signer key belongs to a given CA, I
think it has to be cryptographically binded to the CA certificate signing
key in some way.

> I know that Denis Pinkas has stated: "For X.509, I do *not* say X.500, 
> a
> DN is only relative to the CA who has given it." Presumably he is 
> arguing that it is perfectly legitimate for two CAs in a PKI to have the 
> same name; the only requirement being that a CA can not issue two 
> certificates with the same subject DN in which the subjects are 
> different entities. If this is the case though, I would like to know 
> where X.509 says this or even what text in X.509 implies that this is 
> the case. Section 7 of X.509 states "CAs are unambiguously defined by a 
> distinguished name in the DIT", which seems to contradict Denis' claim.
> 
> In conclusion, in X.509 it is not legitimate for two different 
> entities
> to have the same DN and it is particularly important to ensure that two 
> different CAs in a PKI do not use the same DN. At the same time, 
> defense-in-depth is always a good strategy and in that light Santosh's 
> algorithm does a good job of protecting against the risk that a PKI will 
> evolve in which two different CAs do use the same DN.

As I have just said before, I personally concur with your analysis, but
think that the proposed defence-in-depth is not sufficient and that we need
cryptographic binding.

Sincerely,

--
Julien

> Julien Stern wrote:
> 
> >All,
> >
> >I believe X509 and PKIX are even much more flawed with respect to CRL 
> >validation that underligned by Santosh. The flaw appear as soon as it 
> >valid to sign a certificate and a CRL with different keys.
> >
> >I think the flaw CANNOT be solved without modifying the existing 
> >certificates or simply disallowing these different keys. Let me 
> >explain:
> >
> >We all agree that a CA is defined by name. However, if two CAs have 
> >the same name, one of them may be able to revoke the other CA 
> >certificates. I believe we agree on this flaw of X509 and RFC3280, 
> >but I think the algorithm proposed by Santosh does not change the 
> >situation.
> >
> >The flaw is more severe and is due to the fact that, when
> >a CA is using two different certificates for signing certificate and 
> >signing CRLs, they are unrelated. In order to solve the flaw, we need 
> >to link these two certificates by an other mean that the ancestors. 
> >Actually, we probably need to sign the CRL signing certificate with 
> >the certificate signing certificate.
> >
> >More precisely, if a CA, _any_ CA, whose certificate validates with 
> >respect to one of your Trust Anchor, agrees to deliver me a 
> >certificate whose DN is the same DN as Verisign, I will easily be 
> >able to revoke all Verisign certificates.
> >
> >The simple attack goes as follow:
> >
> >1) Find any moderately honest CA who agrees to sign me a certificate 
> >signing certificate and a CRL signing certificate whose DNs match 
> >Verisign DN.
> >
> >2) For the certificate signing certificate, send a CSR whose public 
> >key matches the _real_ Verisign CA certificate.
> >
> >3) For the CRL signing certificate, send a CSR whose public key 
> >correspond to a private key I know.
> >
> >4) Finally, simply revoke any legitimate Verisign user by producing 
> >CRLs signed with this private key.
> >
> >A path building algorithm will have two choices to go up when 
> >validating a Verisign certificate, (that is, two certificate with 
> >matching DN and key). It it chooses mine, then, the path building 
> >chain will go up to the same TA as the chain coming from my CRL and 
> >all the DNs will match.
> >
> >Conclusions:
> >
> >- The current CRL checking algorithm is flawed
> >- Santosh proposal solves some problems but unfortunately, not all
> >- A possible way to solve the problem would be:
> >
> >1) Simply disallow different keys for certificate and CRL signing
> >2) If different keys are allowed, then the CRL signing key MUST
> >be signed with the certificate signing key with an appropriate
> >delegation extension (aka ~ indirect CRLs)
> >
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6GuDll068642; Sat, 6 Nov 2004 08:56:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6GuDv7068641; Sat, 6 Nov 2004 08:56:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6Gu8KU068624 for <[e-mail]>; Sat, 6 Nov 2004 08:56:13 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA6GuA89004964; Sat, 6 Nov 2004 11:56:10 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>, <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Sat, 6 Nov 2004 11:56:04 -0500
Message-ID: <001101c4c421$83ec68d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA6GuDKU068636
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

A CA is not permitted to issue certificates to two distinct entities with
the same name.  Your example violates this constraint.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Saturday, November 06, 2004 8:38 AM
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



Santosh,

See response in-line.

On Fri, Nov 05, 2004 at 04:07:08PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> The algorithm proposed specifically eliminates the risk.
> 
> The certificate certification path and the CRL certification path will 
> not match because CRL certification path has the node VeriSign CA in 
> it and the certificate certification path has the node real_VersiSign 
> CA in it.
> 
> May be you mean that the two CAs have really the same DN.  Well, in 
> that case, the algorithm makes sure that all the DNs of the CAs in the 
> two paths match (one for one) starting with the DN of the trust 
> anchor.  So, in order for the attack to work, a CA in the system must 
> have certified two distinct CAs for the same subject DN.  If a CA does 
> that, all bets are off.
> 
> Please look at the algorithm closely.  It is match two different 
> paths.

Well, I might be wrong, be I believe my scenario is NOT eliminated by your
proposal.

You say that your assumption is that a CA in the system must not certify two
distincts CAs for the same subject DN. Which would be:

     CA1
     DN1
    /   \
  CA2   CA3
  DN2   DN2

In the scenario I envisionned, the "graph" would be:

    CA1        ROGUECA
    DN1          DN3
     |          /   \
    CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
    DN2       DN2   DN2
    KEY1      KEY1  KEY2


Now, I have a legitime certificate EE issued by CA2, with DN2 and KEY2. The
path building algorithm has TWO choices to reconstruct the path (well unless
specific helper extensions are used, but we should not rely on them for
security), namely:

    CA1        ROGUECA
    DN1          DN3
     |          /   \
    CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
    DN2       DN2   DN2
    KEY1      KEY1  KEY2
       \      /      |
         \  /        |
          EE      Fake CRL

If it goes on the "left" side, you proposal prevents the attack. If it goes
on the "right" side, you proposal does not, because the CRL has a match for
all the ancestors. Consequently, we are in a situation where the same
certificate will be seen as revoked or not depending on the first path
chosen by the path building algorithm, which is believe is bad.

> Also, look at the extension that cryptographically binds the CA's keys 
> to the CRL.
> 
> BTW, Step 2 should not happen in a PKI.  A CA must not bind a public 
> key to a wrong subject (specially, when the subject is a CA).  This is 
> one of the reasons we require proof of possession of a private key.  
> But, even with Step 2 that no CA would do, the algorithm will not let 
> another claim to be you.

I agree step 2 should not happen. I guess that if I could possibly convince
a CA to give a a CA cert with Verisign DN, I could also convince it to
"forget" to verify the POP :)

But serioulsy, I believe that such a RogueCA can indeed publish fake CRLs
that would be validated even by your improved algorithm.

Please let me know if you believe I overlooked something

Sincerely,

--
Julien

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Friday, November 05, 2004 1:38 PM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> All,
> 
> I believe X509 and PKIX are even much more flawed with respect to CRL 
> validation that underligned by Santosh. The flaw appear as soon as it 
> valid to sign a certificate and a CRL with different keys.
> 
> I think the flaw CANNOT be solved without modifying the existing 
> certificates or simply disallowing these different keys. Let me 
> explain:
> 
> We all agree that a CA is defined by name. However, if two CAs have 
> the same name, one of them may be able to revoke the other CA 
> certificates. I believe we agree on this flaw of X509 and RFC3280, but 
> I think the algorithm proposed by Santosh does not change the 
> situation.
> 
> The flaw is more severe and is due to the fact that, when
> a CA is using two different certificates for signing certificate and 
> signing CRLs, they are unrelated. In order to solve the flaw, we need 
> to link these two certificates by an other mean that the ancestors. 
> Actually, we probably need to sign the CRL signing certificate with 
> the certificate signing certificate.
> 
> More precisely, if a CA, _any_ CA, whose certificate validates with 
> respect to one of your Trust Anchor, agrees to deliver me a 
> certificate whose DN is the same DN as Verisign, I will easily be able 
> to revoke all Verisign certificates.
> 
> The simple attack goes as follow:
> 
> 1) Find any moderately honest CA who agrees to sign me a certificate 
> signing certificate and a CRL signing certificate whose DNs match 
> Verisign DN.
> 
> 2) For the certificate signing certificate, send a CSR whose public 
> key matches the _real_ Verisign CA certificate.
> 
> 3) For the CRL signing certificate, send a CSR whose public key 
> correspond to a private key I know.
> 
> 4) Finally, simply revoke any legitimate Verisign user by producing 
> CRLs signed with this private key.
> 
> A path building algorithm will have two choices to go up when 
> validating a Verisign certificate, (that is, two certificate with 
> matching DN and key). It it chooses mine, then, the path building 
> chain will go up to the same TA as the chain coming from my CRL and 
> all the DNs will match.
> 
> Conclusions:
> 
> - The current CRL checking algorithm is flawed
> - Santosh proposal solves some problems but unfortunately, not all
> - A possible way to solve the problem would be:
> 
> 1) Simply disallow different keys for certificate and CRL signing
> 2) If different keys are allowed, then the CRL signing key MUST be signed
> with the certificate signing key with an appropriate delegation extension
> (aka ~ indirect CRLs)
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6EhPtG006298; Sat, 6 Nov 2004 06:43:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6EhPLJ006297; Sat, 6 Nov 2004 06:43:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-106-saturday.noc.nerim.net [62.4.17.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6EhNRj006280 for <[e-mail]>; Sat, 6 Nov 2004 06:43:24 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 01E2A62E95 for <[e-mail]>; Sat,  6 Nov 2004 15:43:24 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 34435440E7 for <[e-mail]>; Sat,  6 Nov 2004 15:43:55 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11067-01 for <[e-mail]>; Sat, 6 Nov 2004 15:43:50 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id CBB6D440AE for <[e-mail]>; Sat,  6 Nov 2004 15:43:50 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Sat,  6 Nov 2004 15:43:20 +0100
From: "Julien Stern" <[e-mail]>
Date: Sat, 6 Nov 2004 15:43:20 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <000b01c4c2b0$15166b80$[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

See response in-line.

On Fri, Nov 05, 2004 at 04:37:52PM -0500, David A. Cooper wrote:
> Julien,
> 
> I don't believe that the scenario you described indicates a flaw in 
> X.509/RFC 3280. Your scenario begins with the assumption that your were 
> able to get a CA to issue you a CA certificate with a subject DN of 
> Verisign (you further assumed that were valid certification paths from 
> one or more trust anchors used by relying parties to this CA).
> 
> Once an attacker has been issued a valid CA certificate the system is 
> compromised (until the certificate that has been issued to the attacker 
> has been revoked). In your scenario, you could just as easily have 
> obtained a CA certificate (with keyCertSign set) with a public key 
> corresponding to a private key that you knew. You would then be able to 
> issue bogus certificates, not just revoke legitimate ones. If an 
> attacker were issued a CA certificate from one of the CAs in my PKI 
> (such that my relying parties would validate certificates issued by that 
> CA), that CA's ability to revoke valid certificates would be the least 
> of my concerns since the CA could also issue bogus certificates.

I do not think that the issue you describe and the one I described
are situed at the same level.

Let me explain:
Assume your configuration trusts exactly two TAs, say Verisign
and Thawte. Also assume that both of them have a complex hierarchy
of CAs below them.  

Now, all the CAs in these two hierarchies can produce "valid" EE certs,
that is, certs that will be validated by path verification algorithm.

The fact that one of the CA low in the hierarchy would have the same
DN as Verisign does not change anything to the problem. And while this
"should not happen", this does not endanger security as long as your TAs
are legitimate. If a CA produces bogus certificates, (which cannot be
theoretically prevented), its certificate should be revoked, but the DN
is irrelevant.

Now, in my (admitedly twisted, my possible) scenario, 
the DN _is_ relevant for security. A dishonest CA with a normal unique
DN cannot revoke all Verisign certificates, but a dishonest CA with
the same DN as Verisign could revoke all verisign certificates even
if located low below Thawte hierarchy.

> I would also like to point out that a PKI in which two different CAs 
> have the same name is invalid. The algorithm that Santosh has proposed 
> works to mitigate the damage that would result if two different CAs in a 
> PKI were using the same DN, but this is a scenario that should never 
> happen in the first place. From my point of view, the main benefit of 
> Santosh's proposal is that it improves efficiency by reducing the number 
> of paths that one needs to consider during path discovery without 
> putting undue restrictions on the PKI architecture.

I think Santosh algorithm is very nice, but as you said, it only
mitigates the risk, and I believe I proposed a scenario in which
I can fool this algorithm.

A also personally agree that a PKI in which two different entities have
the same DN is invalid (although the consensus on this does not seem
to be general). However, we have to assume it could happen, possibly
due to a dishonest participant. And, in fact, for pure certificate path
verification, this possibly invalid situation does not adversely affect
security. Hence, we also have to ensure that it does not affect security
when processing CRLs. We all agree it currently does, and IMHO the issue
is not entirely solved by Santosh algorithm. If a CRL signer key belongs
to a given CA, I think it has to be cryptographically binded to the CA
certificate signing key in some way.

> I know that Denis Pinkas has stated: "For X.509, I do *not* say X.500, a 
> DN is only relative to the CA who has given it." Presumably he is 
> arguing that it is perfectly legitimate for two CAs in a PKI to have the 
> same name; the only requirement being that a CA can not issue two 
> certificates with the same subject DN in which the subjects are 
> different entities. If this is the case though, I would like to know 
> where X.509 says this or even what text in X.509 implies that this is 
> the case. Section 7 of X.509 states "CAs are unambiguously defined by a 
> distinguished name in the DIT", which seems to contradict Denis' claim.
> 
> In conclusion, in X.509 it is not legitimate for two different entities 
> to have the same DN and it is particularly important to ensure that two 
> different CAs in a PKI do not use the same DN. At the same time, 
> defense-in-depth is always a good strategy and in that light Santosh's 
> algorithm does a good job of protecting against the risk that a PKI will 
> evolve in which two different CAs do use the same DN.

As I have just said before, I personally concur with your analysis,
but think that the proposed defence-in-depth is not sufficient and that
we need cryptographic binding.

Sincerely,

--
Julien

> Julien Stern wrote:
> 
> >All,
> >
> >I believe X509 and PKIX are even much more flawed with respect to
> >CRL validation that underligned by Santosh. The flaw appear as soon
> >as it valid to sign a certificate and a CRL with different keys.
> >
> >I think the flaw CANNOT be solved without modifying the existing
> >certificates or simply disallowing these different keys.
> >Let me explain:
> >
> >We all agree that a CA is defined by name. However, if two CAs have the
> >same name, one of them may be able to revoke the other CA certificates.
> >I believe we agree on this flaw of X509 and RFC3280, but I think the
> >algorithm proposed by Santosh does not change the situation.
> >
> >The flaw is more severe and is due to the fact that, when
> >a CA is using two different certificates for signing certificate and
> >signing CRLs, they are unrelated. In order to solve the flaw, we need
> >to link these two certificates by an other mean that the ancestors.
> >Actually, we probably need to sign the CRL signing certificate with the
> >certificate signing certificate.
> >
> >More precisely, if a CA, _any_ CA, whose certificate validates with
> >respect to one of your Trust Anchor, agrees to deliver me a certificate
> >whose DN is the same DN as Verisign, I will easily be able to revoke
> >all Verisign certificates.
> >
> >The simple attack goes as follow:
> >
> >1) Find any moderately honest CA who agrees to sign me a
> >certificate signing certificate and a CRL signing certificate
> >whose DNs match Verisign DN.
> >
> >2) For the certificate signing certificate, send a CSR whose public
> >key matches the _real_ Verisign CA certificate.
> >
> >3) For the CRL signing certificate, send a CSR whose public key
> >correspond to a private key I know.
> >
> >4) Finally, simply revoke any legitimate Verisign user by producing
> >CRLs signed with this private key.
> >
> >A path building algorithm will have two choices to go up when validating
> >a Verisign certificate, (that is, two certificate with matching DN and
> >key). It it chooses mine, then, the path building chain will go up
> >to the same TA as the chain coming from my CRL and all the DNs will
> >match.
> >
> >Conclusions:
> >
> >- The current CRL checking algorithm is flawed
> >- Santosh proposal solves some problems but unfortunately, not all
> >- A possible way to solve the problem would be:
> >
> >1) Simply disallow different keys for certificate and CRL signing 
> >2) If different keys are allowed, then the CRL signing key MUST
> >be signed with the certificate signing key with an appropriate
> >delegation extension (aka ~ indirect CRLs)
> >
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6DcZbP080287; Sat, 6 Nov 2004 05:38:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA6DcZYf080286; Sat, 6 Nov 2004 05:38:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-106-saturday.noc.nerim.net [62.4.17.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA6DcYcL080263 for <[e-mail]>; Sat, 6 Nov 2004 05:38:34 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 1AD2162D39 for <[e-mail]>; Sat,  6 Nov 2004 14:38:26 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id EE619440E7 for <[e-mail]>; Sat,  6 Nov 2004 14:38:56 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10883-04 for <[e-mail]>; Sat, 6 Nov 2004 14:38:53 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 0D8D6440AE for <[e-mail]>; Sat,  6 Nov 2004 14:38:53 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Sat,  6 Nov 2004 14:38:23 +0100
From: "Julien Stern" <[e-mail]>
Date: Sat, 6 Nov 2004 14:38:23 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <004d01c4c37b$699654b0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <004d01c4c37b$699654b0$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

See response in-line.

On Fri, Nov 05, 2004 at 04:07:08PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> The algorithm proposed specifically eliminates the risk.
> 
> The certificate certification path and the CRL certification path will not
> match because CRL certification path has the node VeriSign CA in it and the
> certificate certification path has the node real_VersiSign CA in it.
> 
> May be you mean that the two CAs have really the same DN.  Well, in that
> case, the algorithm makes sure that all the DNs of the CAs in the two paths
> match (one for one) starting with the DN of the trust anchor.  So, in order
> for the attack to work, a CA in the system must have certified two distinct
> CAs for the same subject DN.  If a CA does that, all bets are off.
> 
> Please look at the algorithm closely.  It is match two different paths.

Well, I might be wrong, be I believe my scenario is NOT eliminated by
your proposal.

You say that your assumption is that a CA in the system must not certify
two distincts CAs for the same subject DN. Which would be:

     CA1
     DN1
    /   \
  CA2   CA3
  DN2   DN2

In the scenario I envisionned, the "graph" would be:

    CA1        ROGUECA
    DN1          DN3
     |          /   \
    CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
    DN2       DN2   DN2
    KEY1      KEY1  KEY2


Now, I have a legitime certificate EE issued by CA2, with DN2 and KEY2.
The path building algorithm has TWO choices to reconstruct the path
(well unless specific helper extensions are used, but we should not
rely on them for security), namely:

    CA1        ROGUECA
    DN1          DN3
     |          /   \
    CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
    DN2       DN2   DN2
    KEY1      KEY1  KEY2
       \      /      |
         \  /        |
          EE      Fake CRL

If it goes on the "left" side, you proposal prevents the attack.
If it goes on the "right" side, you proposal does not, because the CRL
has a match for all the ancestors.
Consequently, we are in a situation where the same certificate will
be seen as revoked or not depending on the first path chosen by the
path building algorithm, which is believe is bad.

> Also, look at the extension that cryptographically binds the CA's keys to
> the CRL.
> 
> BTW, Step 2 should not happen in a PKI.  A CA must not bind a public key to
> a wrong subject (specially, when the subject is a CA).  This is one of the
> reasons we require proof of possession of a private key.  But, even with
> Step 2 that no CA would do, the algorithm will not let another claim to be
> you.

I agree step 2 should not happen. I guess that if I could possibly
convince a CA to give a a CA cert with Verisign DN, I could also
convince it to "forget" to verify the POP :)

But serioulsy, I believe that such a RogueCA can indeed publish fake
CRLs that would be validated even by your improved algorithm.

Please let me know if you believe I overlooked something

Sincerely,

--
Julien

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Julien Stern
> Sent: Friday, November 05, 2004 1:38 PM
> To: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> All,
> 
> I believe X509 and PKIX are even much more flawed with respect to CRL
> validation that underligned by Santosh. The flaw appear as soon as it valid
> to sign a certificate and a CRL with different keys.
> 
> I think the flaw CANNOT be solved without modifying the existing
> certificates or simply disallowing these different keys. Let me explain:
> 
> We all agree that a CA is defined by name. However, if two CAs have the same
> name, one of them may be able to revoke the other CA certificates. I believe
> we agree on this flaw of X509 and RFC3280, but I think the algorithm
> proposed by Santosh does not change the situation.
> 
> The flaw is more severe and is due to the fact that, when
> a CA is using two different certificates for signing certificate and signing
> CRLs, they are unrelated. In order to solve the flaw, we need to link these
> two certificates by an other mean that the ancestors. Actually, we probably
> need to sign the CRL signing certificate with the certificate signing
> certificate.
> 
> More precisely, if a CA, _any_ CA, whose certificate validates with respect
> to one of your Trust Anchor, agrees to deliver me a certificate whose DN is
> the same DN as Verisign, I will easily be able to revoke all Verisign
> certificates.
> 
> The simple attack goes as follow:
> 
> 1) Find any moderately honest CA who agrees to sign me a certificate signing
> certificate and a CRL signing certificate whose DNs match Verisign DN.
> 
> 2) For the certificate signing certificate, send a CSR whose public key
> matches the _real_ Verisign CA certificate.
> 
> 3) For the CRL signing certificate, send a CSR whose public key correspond
> to a private key I know.
> 
> 4) Finally, simply revoke any legitimate Verisign user by producing CRLs
> signed with this private key.
> 
> A path building algorithm will have two choices to go up when validating a
> Verisign certificate, (that is, two certificate with matching DN and key).
> It it chooses mine, then, the path building chain will go up to the same TA
> as the chain coming from my CRL and all the DNs will match.
> 
> Conclusions:
> 
> - The current CRL checking algorithm is flawed
> - Santosh proposal solves some problems but unfortunately, not all
> - A possible way to solve the problem would be:
> 
> 1) Simply disallow different keys for certificate and CRL signing 
> 2) If different keys are allowed, then the CRL signing key MUST be signed
> with the certificate signing key with an appropriate delegation extension
> (aka ~ indirect CRLs)
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5LcFNM059074; Fri, 5 Nov 2004 13:38:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5LcFsX059073; Fri, 5 Nov 2004 13:38:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5LcFwK059059 for <[e-mail]>; Fri, 5 Nov 2004 13:38:15 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id iA5Lbw2x008451; Fri, 5 Nov 2004 16:37:58 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id iA5LbjYA012445; Fri, 5 Nov 2004 16:37:45 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 05 Nov 2004 16:37:52 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Julien Stern <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <[e-mail]> <000b01c4c2b0$15166b80$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

I don't believe that the scenario you described indicates a flaw in 
X.509/RFC 3280. Your scenario begins with the assumption that your were 
able to get a CA to issue you a CA certificate with a subject DN of 
Verisign (you further assumed that were valid certification paths from 
one or more trust anchors used by relying parties to this CA).

Once an attacker has been issued a valid CA certificate the system is 
compromised (until the certificate that has been issued to the attacker 
has been revoked). In your scenario, you could just as easily have 
obtained a CA certificate (with keyCertSign set) with a public key 
corresponding to a private key that you knew. You would then be able to 
issue bogus certificates, not just revoke legitimate ones. If an 
attacker were issued a CA certificate from one of the CAs in my PKI 
(such that my relying parties would validate certificates issued by that 
CA), that CA's ability to revoke valid certificates would be the least 
of my concerns since the CA could also issue bogus certificates.

I would also like to point out that a PKI in which two different CAs 
have the same name is invalid. The algorithm that Santosh has proposed 
works to mitigate the damage that would result if two different CAs in a 
PKI were using the same DN, but this is a scenario that should never 
happen in the first place. From my point of view, the main benefit of 
Santosh's proposal is that it improves efficiency by reducing the number 
of paths that one needs to consider during path discovery without 
putting undue restrictions on the PKI architecture.

I know that Denis Pinkas has stated: "For X.509, I do *not* say X.500, a 
DN is only relative to the CA who has given it." Presumably he is 
arguing that it is perfectly legitimate for two CAs in a PKI to have the 
same name; the only requirement being that a CA can not issue two 
certificates with the same subject DN in which the subjects are 
different entities. If this is the case though, I would like to know 
where X.509 says this or even what text in X.509 implies that this is 
the case. Section 7 of X.509 states "CAs are unambiguously defined by a 
distinguished name in the DIT", which seems to contradict Denis' claim.

In conclusion, in X.509 it is not legitimate for two different entities 
to have the same DN and it is particularly important to ensure that two 
different CAs in a PKI do not use the same DN. At the same time, 
defense-in-depth is always a good strategy and in that light Santosh's 
algorithm does a good job of protecting against the risk that a PKI will 
evolve in which two different CAs do use the same DN.

Dave


Julien Stern wrote:

>All,
>
>I believe X509 and PKIX are even much more flawed with respect to
>CRL validation that underligned by Santosh. The flaw appear as soon
>as it valid to sign a certificate and a CRL with different keys.
>
>I think the flaw CANNOT be solved without modifying the existing
>certificates or simply disallowing these different keys.
>Let me explain:
>
>We all agree that a CA is defined by name. However, if two CAs have the
>same name, one of them may be able to revoke the other CA certificates.
>I believe we agree on this flaw of X509 and RFC3280, but I think the
>algorithm proposed by Santosh does not change the situation.
>
>The flaw is more severe and is due to the fact that, when
>a CA is using two different certificates for signing certificate and
>signing CRLs, they are unrelated. In order to solve the flaw, we need
>to link these two certificates by an other mean that the ancestors.
>Actually, we probably need to sign the CRL signing certificate with the
>certificate signing certificate.
>
>More precisely, if a CA, _any_ CA, whose certificate validates with
>respect to one of your Trust Anchor, agrees to deliver me a certificate
>whose DN is the same DN as Verisign, I will easily be able to revoke
>all Verisign certificates.
>
>The simple attack goes as follow:
>
>1) Find any moderately honest CA who agrees to sign me a
>certificate signing certificate and a CRL signing certificate
>whose DNs match Verisign DN.
>
>2) For the certificate signing certificate, send a CSR whose public
>key matches the _real_ Verisign CA certificate.
>
>3) For the CRL signing certificate, send a CSR whose public key
>correspond to a private key I know.
>
>4) Finally, simply revoke any legitimate Verisign user by producing
>CRLs signed with this private key.
>
>A path building algorithm will have two choices to go up when validating
>a Verisign certificate, (that is, two certificate with matching DN and
>key). It it chooses mine, then, the path building chain will go up
>to the same TA as the chain coming from my CRL and all the DNs will
>match.
>
>Conclusions:
>
>- The current CRL checking algorithm is flawed
>- Santosh proposal solves some problems but unfortunately, not all
>- A possible way to solve the problem would be:
>
>1) Simply disallow different keys for certificate and CRL signing 
>2) If different keys are allowed, then the CRL signing key MUST
>be signed with the certificate signing key with an appropriate
>delegation extension (aka ~ indirect CRLs)
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5LDo5s048777; Fri, 5 Nov 2004 13:13:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5LDnje048776; Fri, 5 Nov 2004 13:13:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5LDn2s048766 for <[e-mail]>; Fri, 5 Nov 2004 13:13:49 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA5LDp89003319 for <[e-mail]>; Fri, 5 Nov 2004 16:13:51 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Fri, 5 Nov 2004 16:13:51 -0500
Message-ID: <005001c4c37c$5959e0c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA5LDn2s048771
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

See responses in-line in [SC:]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Friday, November 05, 2004 10:05 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting


Santosh,

> Denis,
> 
> See responses in-line in [SC:]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, November 04, 2004 12:40 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Santosh,
> 
> See responses in-line in [DP:]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, November 03, 2004 9:48 AM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> Santosh,
> 
>  > Denis,
> 
>  > The matching algorithm proposed checks/compares the ancestors.
> 
> The matching algorithm is missing to say "who" trusts "somebody" for
> "what". Unless this is clearly said, there is no trust possible and 
> thus no algorithm possible.
> 
> [SC: The two paths needs to be verified in accordance with 3280 in
> order to establish trust]
> 
> [DP: the certification path needs to be verified according to RFC
> 3280. The problem is that RFC 3280 does not tell how to verify that 
> the CRL comes from the right CRL Issuer. Your assumption that the "two 
> paths needs to be verified in accordance with 3280 in order to 
> establish trust" is thus incorrect].
> 
> [SC: When you augment 3280 with the algorithm I proposed, that takes
> care of it.  It goes without saying that 3280 needs to be augmented 
> with the algorithm]

This is exactly what I disagree with.

Let us talk about the key issue. The question is: how can a RP (relying 
party) know that, for a given end-user certificate, the CRL he got is indeed

issued by the right CRL Issuer ?

In the following discussion, I am only considering the case where the CRL 
Issuer is *not* the CA (this CA is called CA 1).

CA 2 is a CA that has issued a CA certificate to CA 1.

The text is currently so vague that different models are indeed 
theoritically possible. In particular:

  a) the CRL Issuer is nominated by CA 1 that has issued
     the end-user certificate. This case would make sense
     when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
     that role to one or more CRL Issuers. This means that
     a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.

  b) the CRL Issuer is nominated by CA 2 that has issued a CA
     certificate to CA 1. This case would make sense when CA 2
     has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
     certificate is issued by CA 2 to every CRL Issuer. CA 1 may
     then only choose a CRL Issuer that has been granted
     the authorization to issue CRLs by CA 2.

I wonder if I understand correctly the model you proposed, but (please 
correct if wrong) you have a set of trust points to verify the certification

chain, and another set of trust points to verify what you call a 
certification path for the CRL Issuer.

There would be many problems with such a model to define correctly 
validation policies, since the two chains would be unrelated and any CA from

that chain could nominate CRL Issuers used by any CA.

[SC: The DN of the trust anchor for the certificate certification path must
match with the DN of the trust anchors for the CRL certification path.  So,
I do not see what problem will occur]

In options a) and b) mentioned above, a single trust point is used to 
validate both the certification chain and the CRL Issuer.

In any case, we need to clarify this topic in 3280bis, whatever the 
clarification will be.

[SC: That is what I have done]

> This algorithm is nothing more than formalism of something you agreed 
> to in 2003 on this list.
> 
> I don't think so.
> 
> [SC: Go back to September 2003 archive of your response to my post and
> tell me what is not covered]
> 
> [DP: You would need to be more precise and provide me an extract of
> what you
> 
> refer to]
> 
> [SC: It was short string of e-mails on the subject matter in September
> 2003.

Hum !!! Hum !!!
Do not mention "free" assertions when you are not sure about.

[SC: I am sure about it that you agreed to it.  You need to see the archive
to see what you wrote.  Separately, in this e-mail thread, I do not see any
specific error or flaw that you have pointed out.]

Denis

> I am sure you can find it from the archives.  It may be overcome by
> events since your recent postings show that you agree with me]
> 
> Denis






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5L9uxn047380; Fri, 5 Nov 2004 13:09:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5L9ui8047379; Fri, 5 Nov 2004 13:09:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5L9tCD047372 for <[e-mail]>; Fri, 5 Nov 2004 13:09:55 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA5L9q89000393 for <[e-mail]>; Fri, 5 Nov 2004 16:09:53 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Fri, 5 Nov 2004 16:09:52 -0500
Message-ID: <004f01c4c37b$cb3505e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

The briefing proposes solutions and text.  If the 3280 editor accepts the
ideas and text, I will work with him on 3280 revision.

In the mean time, if you have something specific to add, let us know.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Friday, November 05, 2004 9:28 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs


Santosh,

> Denis,

> As I said, we are well ahead of you if you look at my and Stefan's and
> the Chinese gentleman's postings on the syntax of AIA.

Whether you are ahead or behind is not the matter.
The matter is to agree on text to be incorporated in 3280bis. AFAIK, I have
not seen a text proposal for 3280bis.

Denis

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Denis Pinkas
> Sent: Thursday, November 04, 2004 12:34 PM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> 
> Santosh,
> 
> See responses in-line in [DP:]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, November 03, 2004 9:58 AM
> To: Santosh Chokhani
> Cc: 'pkix'; David A. Cooper
> Subject: Re: Signer certificate discovery for CRLs
> 
> Santosh,
> 
>  > Denis,
>  >
>  > Just show us how SIA (wherever you want to put it) is more
> efficient  > than AIA for CRL signer.
> 
> The question is not whether it is better or not.
> 
> Walking on certification paths can be done bottom-up (using AIA
> extensions) or top-down (using SIA extensions).
> 
> [SC: Before we get into path, the purpose of this AIA is simply to get
> the end certificate which protocols such as CMS S/MIME provide]
> 
> It should be RECOMMENDED to place an SIA extension in every CA
> certificate, starting from every Trust Anchor (TA) when the TA is 
> expressed using a self-signed certificate.
> 
> As I already said, information is missing in RFC 3280: we need to say
> more about the formats implied by accessMethod.
> 
> There are four possible cases :
> 
>    1 - it allows to retrieve one single file,
>    2 - it allows to query for a single file in a repository,
>    3 - it allows to query for one or more files in a repository,
>    4 - it provides the address of a repository.
> 
> The current text should be clarified whether accessMethod is used in
> an AIA extension or in an SIA extension. Cases 3 and 4 apply to the 
> SIA extension.
> 
> [SC: For both AIA and SIA, at least an HTTP pointer to a p7 file
> containing one or more certificates and pointer to ldap attribute 
> should be permitted.]
> 
> [DP: At this time I do not care for the details, but I only want to
> point
> out to David Cooper that text is needed on that topic].
> 
> Denis
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5L8wUk047133; Fri, 5 Nov 2004 13:08:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5L8w1M047132; Fri, 5 Nov 2004 13:08:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5L8w59047126 for <[e-mail]>; Fri, 5 Nov 2004 13:08:58 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA5L8t89032248 for <[e-mail]>; Fri, 5 Nov 2004 16:08:55 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Fri, 5 Nov 2004 16:08:55 -0500
Message-ID: <004e01c4c37b$a925b170$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA5L8w59047127
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

The purpose of this whole thread is to beef up 3280 and X.509 based on what
has been discussed.

Everyone on this list understands that the text does not currently say that
and that is why we had the dialog and that is what the briefing explicitly
recommends.

Also, the briefing proposes specific language and algorithm to achieve this.
If the RFC editor accepts the recommendations, I will be glad to work with
him to revise 3280.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Friday, November 05, 2004 9:24 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Signer certificate discovery for CRLs


Santosh,

> Denis,
> 
> See responses in-line.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, November 04, 2004 12:41 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> See responses in-line in [DP: ]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, November 03, 2004 9:46 AM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> Santosh,
> 
>  > X.509 Annex B and 3280 do describe how to deal with various CRLs.
> 
> No. I disagree.
> 
> [SC: When you look at Annex B of X.509 and 3280 and what we have
> proposed here, what is missing in your analysis?]
> 
> X.509 Annex B only states:
> 
> "The relying party shall be able to obtain the public key of the
> issuer identified in the CRL using authenticated means;"
> 
> but does not say how this is done !
> 
> [SC: US comment along the lines of what has been the consensus on this
> thread has been made/included]
> 
> [DP: What do you mean by "US comment". There is no such a thing in the
> IETF
> procedures. Then, "included" in what ?!? ]
> 
> [SC: You asked a question of X.509 Annex B and so I responded how we
> are fixing X.509.  Everyone knows that IETF does not deal with these 
> things]
> 
> RFC 3280 is also lacking to provide any detail about this.
> 
> [SC: We are recommending the Editor include the consensus in the next
> round]
> 
> [DP: Fine, but there is no text at the present time, so no consensus
> yet at
> the present time].

> [SC: As I said, we have done some thinking and have proposed ideas for
> 3280 considerations.]

"Ideas" and "thinkings" are not text for 3280bis consideration.

Denis

> This is a major deficiency of both X.509 and RFC 3280.
> 
> Denis






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5L7Iq4046398; Fri, 5 Nov 2004 13:07:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5L7INq046397; Fri, 5 Nov 2004 13:07:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5L7HcH046307 for <[e-mail]>; Fri, 5 Nov 2004 13:07:18 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA5L7989030699 for <[e-mail]>; Fri, 5 Nov 2004 16:07:09 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Fri, 5 Nov 2004 16:07:08 -0500
Message-ID: <004d01c4c37b$699654b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA5L7IcH046392
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

The algorithm proposed specifically eliminates the risk.

The certificate certification path and the CRL certification path will not
match because CRL certification path has the node VeriSign CA in it and the
certificate certification path has the node real_VersiSign CA in it.

May be you mean that the two CAs have really the same DN.  Well, in that
case, the algorithm makes sure that all the DNs of the CAs in the two paths
match (one for one) starting with the DN of the trust anchor.  So, in order
for the attack to work, a CA in the system must have certified two distinct
CAs for the same subject DN.  If a CA does that, all bets are off.

Please look at the algorithm closely.  It is match two different paths.

Also, look at the extension that cryptographically binds the CA's keys to
the CRL.

BTW, Step 2 should not happen in a PKI.  A CA must not bind a public key to
a wrong subject (specially, when the subject is a CA).  This is one of the
reasons we require proof of possession of a private key.  But, even with
Step 2 that no CA would do, the algorithm will not let another claim to be
you.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Friday, November 05, 2004 1:38 PM
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



All,

I believe X509 and PKIX are even much more flawed with respect to CRL
validation that underligned by Santosh. The flaw appear as soon as it valid
to sign a certificate and a CRL with different keys.

I think the flaw CANNOT be solved without modifying the existing
certificates or simply disallowing these different keys. Let me explain:

We all agree that a CA is defined by name. However, if two CAs have the same
name, one of them may be able to revoke the other CA certificates. I believe
we agree on this flaw of X509 and RFC3280, but I think the algorithm
proposed by Santosh does not change the situation.

The flaw is more severe and is due to the fact that, when
a CA is using two different certificates for signing certificate and signing
CRLs, they are unrelated. In order to solve the flaw, we need to link these
two certificates by an other mean that the ancestors. Actually, we probably
need to sign the CRL signing certificate with the certificate signing
certificate.

More precisely, if a CA, _any_ CA, whose certificate validates with respect
to one of your Trust Anchor, agrees to deliver me a certificate whose DN is
the same DN as Verisign, I will easily be able to revoke all Verisign
certificates.

The simple attack goes as follow:

1) Find any moderately honest CA who agrees to sign me a certificate signing
certificate and a CRL signing certificate whose DNs match Verisign DN.

2) For the certificate signing certificate, send a CSR whose public key
matches the _real_ Verisign CA certificate.

3) For the CRL signing certificate, send a CSR whose public key correspond
to a private key I know.

4) Finally, simply revoke any legitimate Verisign user by producing CRLs
signed with this private key.

A path building algorithm will have two choices to go up when validating a
Verisign certificate, (that is, two certificate with matching DN and key).
It it chooses mine, then, the path building chain will go up to the same TA
as the chain coming from my CRL and all the DNs will match.

Conclusions:

- The current CRL checking algorithm is flawed
- Santosh proposal solves some problems but unfortunately, not all
- A possible way to solve the problem would be:

1) Simply disallow different keys for certificate and CRL signing 
2) If different keys are allowed, then the CRL signing key MUST be signed
with the certificate signing key with an appropriate delegation extension
(aka ~ indirect CRLs)




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5Iepdg080598; Fri, 5 Nov 2004 10:40:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5IepnH080597; Fri, 5 Nov 2004 10:40:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-105-friday.nerim.net [62.4.16.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5Iekno080400 for <[e-mail]>; Fri, 5 Nov 2004 10:40:51 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 491D5416BF for <[e-mail]>; Fri,  5 Nov 2004 19:37:50 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 99918440E7 for <[e-mail]>; Fri,  5 Nov 2004 19:38:20 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08275-09 for <[e-mail]>; Fri, 5 Nov 2004 19:38:17 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 128A0440C5 for <[e-mail]>; Fri,  5 Nov 2004 19:38:17 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Fri,  5 Nov 2004 19:37:47 +0100
From: "Julien Stern" <[e-mail]>
Date: Fri, 5 Nov 2004 19:37:47 +0100
To: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <000b01c4c2b0$15166b80$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000b01c4c2b0$15166b80$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I believe X509 and PKIX are even much more flawed with respect to
CRL validation that underligned by Santosh. The flaw appear as soon
as it valid to sign a certificate and a CRL with different keys.

I think the flaw CANNOT be solved without modifying the existing
certificates or simply disallowing these different keys.
Let me explain:

We all agree that a CA is defined by name. However, if two CAs have the
same name, one of them may be able to revoke the other CA certificates.
I believe we agree on this flaw of X509 and RFC3280, but I think the
algorithm proposed by Santosh does not change the situation.

The flaw is more severe and is due to the fact that, when
a CA is using two different certificates for signing certificate and
signing CRLs, they are unrelated. In order to solve the flaw, we need
to link these two certificates by an other mean that the ancestors.
Actually, we probably need to sign the CRL signing certificate with the
certificate signing certificate.

More precisely, if a CA, _any_ CA, whose certificate validates with
respect to one of your Trust Anchor, agrees to deliver me a certificate
whose DN is the same DN as Verisign, I will easily be able to revoke
all Verisign certificates.

The simple attack goes as follow:

1) Find any moderately honest CA who agrees to sign me a
certificate signing certificate and a CRL signing certificate
whose DNs match Verisign DN.

2) For the certificate signing certificate, send a CSR whose public
key matches the _real_ Verisign CA certificate.

3) For the CRL signing certificate, send a CSR whose public key
correspond to a private key I know.

4) Finally, simply revoke any legitimate Verisign user by producing
CRLs signed with this private key.

A path building algorithm will have two choices to go up when validating
a Verisign certificate, (that is, two certificate with matching DN and
key). It it chooses mine, then, the path building chain will go up
to the same TA as the chain coming from my CRL and all the DNs will
match.

Conclusions:

- The current CRL checking algorithm is flawed
- Santosh proposal solves some problems but unfortunately, not all
- A possible way to solve the problem would be:

1) Simply disallow different keys for certificate and CRL signing 
2) If different keys are allowed, then the CRL signing key MUST
be signed with the certificate signing key with an appropriate
delegation extension (aka ~ indirect CRLs)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5F4tcc098562; Fri, 5 Nov 2004 07:04:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5F4toJ098561; Fri, 5 Nov 2004 07:04:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5F4rxc098544 for <[e-mail]>; Fri, 5 Nov 2004 07:04:54 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA48140; Fri, 5 Nov 2004 16:16:43 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110516044318:1491 ; Fri, 5 Nov 2004 16:04:43 +0100 
Message-ID: <[e-mail]>
Date: Fri, 05 Nov 2004 16:04:41 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <000c01c4c2b0$157fdbb0$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 05/11/2004 16:04:43, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 05/11/2004 16:04:44, Serialize complete at 05/11/2004 16:04:44
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

> Denis,
> 
> See responses in-line in [SC:]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, November 04, 2004 12:40 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Santosh,
> 
> See responses in-line in [DP:]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, November 03, 2004 9:48 AM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> Santosh,
> 
>  > Denis,
> 
>  > The matching algorithm proposed checks/compares the ancestors.
> 
> The matching algorithm is missing to say "who" trusts "somebody" for "what".
> Unless this is clearly said, there is no trust possible and thus no
> algorithm possible.
> 
> [SC: The two paths needs to be verified in accordance with 3280 in order to
> establish trust]
> 
> [DP: the certification path needs to be verified according to RFC 3280. The
> problem is that RFC 3280 does not tell how to verify that the CRL comes 
> from the right CRL Issuer. Your assumption that the "two paths needs to be 
> verified in accordance with 3280 in order to establish trust" is thus 
> incorrect].
> 
> [SC: When you augment 3280 with the algorithm I proposed, that takes care of
> it.  It goes without saying that 3280 needs to be augmented with the
> algorithm]

This is exactly what I disagree with.

Let us talk about the key issue. The question is: how can a RP (relying 
party) know that, for a given end-user certificate, the CRL he got is indeed 
issued by the right CRL Issuer ?

In the following discussion, I am only considering the case where the CRL 
Issuer is *not* the CA (this CA is called CA 1).

CA 2 is a CA that has issued a CA certificate to CA 1.

The text is currently so vague that different models are indeed 
theoritically possible. In particular:

  a) the CRL Issuer is nominated by CA 1 that has issued
     the end-user certificate. This case would make sense
     when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
     that role to one or more CRL Issuers. This means that
     a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.

  b) the CRL Issuer is nominated by CA 2 that has issued a CA
     certificate to CA 1. This case would make sense when CA 2
     has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
     certificate is issued by CA 2 to every CRL Issuer. CA 1 may
     then only choose a CRL Issuer that has been granted
     the authorization to issue CRLs by CA 2.

I wonder if I understand correctly the model you proposed, but (please 
correct if wrong) you have a set of trust points to verify the certification 
chain, and another set of trust points to verify what you call a 
certification path for the CRL Issuer.

There would be many problems with such a model to define correctly 
validation policies, since the two chains would be unrelated and any CA from 
that chain could nominate CRL Issuers used by any CA.

In options a) and b) mentioned above, a single trust point is used to 
validate both the certification chain and the CRL Issuer.

In any case, we need to clarify this topic in 3280bis, whatever the 
clarification will be.

> This algorithm is nothing more than formalism of something you agreed  
> to in 2003 on this list.
> 
> I don't think so.
> 
> [SC: Go back to September 2003 archive of your response to my post and tell
> me what is not covered]
> 
> [DP: You would need to be more precise and provide me an extract of what you
> 
> refer to]
> 
> [SC: It was short string of e-mails on the subject matter in September 2003.

Hum !!! Hum !!!
Do not mention "free" assertions when you are not sure about.

Denis

> I am sure you can find it from the archives.  It may be overcome by events
> since your recent postings show that you agree with me]
> 
> Denis





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5ES1k3086615; Fri, 5 Nov 2004 06:28:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5ES1iG086613; Fri, 5 Nov 2004 06:28:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5ERwu3086534 for <[e-mail]>; Fri, 5 Nov 2004 06:27:59 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA66754; Fri, 5 Nov 2004 15:39:43 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110515274334:1461 ; Fri, 5 Nov 2004 15:27:43 +0100 
Message-ID: <[e-mail]>
Date: Fri, 05 Nov 2004 15:27:42 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'pkix'" <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <000901c4c2b0$14034dd0$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 05/11/2004 15:27:43, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 05/11/2004 15:27:44, Serialize complete at 05/11/2004 15:27:44
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

> Denis,

> As I said, we are well ahead of you if you look at my and Stefan's and the
> Chinese gentleman's postings on the syntax of AIA.

Whether you are ahead or behind is not the matter.
The matter is to agree on text to be incorporated in 3280bis.
AFAIK, I have not seen a text proposal for 3280bis.

Denis

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Denis Pinkas
> Sent: Thursday, November 04, 2004 12:34 PM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> 
> Santosh,
> 
> See responses in-line in [DP:]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, November 03, 2004 9:58 AM
> To: Santosh Chokhani
> Cc: 'pkix'; David A. Cooper
> Subject: Re: Signer certificate discovery for CRLs
> 
> Santosh,
> 
>  > Denis,
>  >
>  > Just show us how SIA (wherever you want to put it) is more efficient  >
> than AIA for CRL signer.
> 
> The question is not whether it is better or not.
> 
> Walking on certification paths can be done bottom-up (using AIA extensions)
> or top-down (using SIA extensions).
> 
> [SC: Before we get into path, the purpose of this AIA is simply to get the
> end certificate which protocols such as CMS S/MIME provide]
> 
> It should be RECOMMENDED to place an SIA extension in every CA certificate,
> starting from every Trust Anchor (TA) when the TA is expressed using a
> self-signed certificate.
> 
> As I already said, information is missing in RFC 3280: we need to say more
> about the formats implied by accessMethod.
> 
> There are four possible cases :
> 
>    1 - it allows to retrieve one single file,
>    2 - it allows to query for a single file in a repository,
>    3 - it allows to query for one or more files in a repository,
>    4 - it provides the address of a repository.
> 
> The current text should be clarified whether accessMethod is used in an AIA
> extension or in an SIA extension. Cases 3 and 4 apply to the SIA extension.
> 
> [SC: For both AIA and SIA, at least an HTTP pointer to a p7 file containing
> one or more certificates and pointer to ldap attribute should be permitted.]
> 
> [DP: At this time I do not care for the details, but I only want to point 
> out to David Cooper that text is needed on that topic].
> 
> Denis
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5EO8V9085285; Fri, 5 Nov 2004 06:24:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5EO7D4085284; Fri, 5 Nov 2004 06:24:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5EO1oC085172 for <[e-mail]>; Fri, 5 Nov 2004 06:24:02 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA20546; Fri, 5 Nov 2004 15:35:41 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110515234059:1458 ; Fri, 5 Nov 2004 15:23:40 +0100 
Message-ID: <[e-mail]>
Date: Fri, 05 Nov 2004 15:23:39 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Signer certificate discovery for CRLs
References: <000a01c4c2b0$146e44a0$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 05/11/2004 15:23:40, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 05/11/2004 15:23:42, Serialize complete at 05/11/2004 15:23:42
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

> Denis,
> 
> See responses in-line.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, November 04, 2004 12:41 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> See responses in-line in [DP: ]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, November 03, 2004 9:46 AM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> Santosh,
> 
>  > X.509 Annex B and 3280 do describe how to deal with various CRLs.
> 
> No. I disagree.
> 
> [SC: When you look at Annex B of X.509 and 3280 and what we have proposed
> here, what is missing in your analysis?]
> 
> X.509 Annex B only states:
> 
> "The relying party shall be able to obtain the public key of the issuer
> identified in the CRL using authenticated means;"
> 
> but does not say how this is done !
> 
> [SC: US comment along the lines of what has been the consensus on this
> thread has been made/included]
> 
> [DP: What do you mean by "US comment". There is no such a thing in the IETF 
> procedures. Then, "included" in what ?!? ]
> 
> [SC: You asked a question of X.509 Annex B and so I responded how we are
> fixing X.509.  Everyone knows that IETF does not deal with these things]
> 
> RFC 3280 is also lacking to provide any detail about this.
> 
> [SC: We are recommending the Editor include the consensus in the next round]
> 
> [DP: Fine, but there is no text at the present time, so no consensus yet at 
> the present time].

> [SC: As I said, we have done some thinking and have proposed ideas for 3280
> considerations.]

"Ideas" and "thinkings" are not text for 3280bis consideration.

Denis

> This is a major deficiency of both X.509 and RFC 3280.
> 
> Denis





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA582M9F050965; Fri, 5 Nov 2004 00:02:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA582MQf050963; Fri, 5 Nov 2004 00:02:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from miami.siteprotect.co.kr (miami.siteprotect.co.kr [66.232.137.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA582Gue050860 for <[e-mail]>; Fri, 5 Nov 2004 00:02:21 -0800 (PST) (envelope-from [e-mail])
Received: from bcqre.com ([211.54.4.60]) by miami.siteprotect.co.kr (8.11.6/8.11.6) with ESMTP id iA582A018727 for <[e-mail]>; Fri, 5 Nov 2004 17:02:11 +0900
Message-ID: <[e-mail]>
Date: Fri, 05 Nov 2004 17:02:13 +0900
From: ChungKil Kim <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: ko, en
MIME-Version: 1.0
To: [e-mail]
Subject: DVCS ASN.1 module definition error
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hi there.

i found asn.1 definition error.
see following definition(rfc3029 Page 15).


Data ::= CHOICE {
message OCTET STRING ,
messageImprint DigestInfo,
certs SEQUENCE SIZE (1..MAX) OF
TargetEtcChain
}

DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest
}

messageImprint and certs have same tag type. it can't be CHOICE. right?





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4NNNdi095477; Thu, 4 Nov 2004 15:23:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4NNNVQ095476; Thu, 4 Nov 2004 15:23:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4NNM34095440 for <[e-mail]>; Thu, 4 Nov 2004 15:23:22 -0800 (PST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: SCVP 16 VPResponse
Date: Thu, 4 Nov 2004 18:25:01 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 VPResponse
Thread-Index: AcTCxYHwQyotnGapTE+l8tE3M8qVQg==
From: "Seth Hitchings" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA4NNM34095469
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The validation policy response (VPResponse) defined by SCVP draft 16
allows an SCVP client to determine the validation policies supported by
an SCVP server by reference. It doesn't provide the client any way to
determine the definition of these policies except for the default
policy, which is fully defined using the ValidationPolValues type.

Why not return the full definition of each validation policy the
VPResponse? Wouldn't this be far more useful to the client? Without
knowing the definition, what is the value of knowing the policies
supported?

Thanks,
Seth



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4KpbUW037434; Thu, 4 Nov 2004 12:51:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4KpbQj037433; Thu, 4 Nov 2004 12:51:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4KpawY037423 for <[e-mail]>; Thu, 4 Nov 2004 12:51:36 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (ASQ2-127-187.usae.bah.com [156.80.127.187]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA4Kpa8D021792 for <[e-mail]>; Thu, 4 Nov 2004 15:51:40 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Thu, 4 Nov 2004 15:51:31 -0500
Message-ID: <000c01c4c2b0$157fdbb0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA4KpawY037425
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

See responses in-line in [SC:]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, November 04, 2004 12:40 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting


Santosh,

See responses in-line in [DP:]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, November 03, 2004 9:48 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

 > Denis,

 > The matching algorithm proposed checks/compares the ancestors.

The matching algorithm is missing to say "who" trusts "somebody" for "what".
Unless this is clearly said, there is no trust possible and thus no
algorithm possible.

[SC: The two paths needs to be verified in accordance with 3280 in order to
establish trust]

[DP: the certification path needs to be verified according to RFC 3280. The
problem is that RFC 3280 does not tell how to verify that the CRL comes 
from the right CRL Issuer. Your assumption that the "two paths needs to be 
verified in accordance with 3280 in order to establish trust" is thus 
incorrect].

[SC: When you augment 3280 with the algorithm I proposed, that takes care of
it.  It goes without saying that 3280 needs to be augmented with the
algorithm]

 > This algorithm is nothing more than formalism of something you agreed  >
to in 2003 on this list.

I don't think so.

[SC: Go back to September 2003 archive of your response to my post and tell
me what is not covered]

[DP: You would need to be more precise and provide me an extract of what you

refer to]

[SC: It was short string of e-mails on the subject matter in September 2003.
I am sure you can find it from the archives.  It may be overcome by events
since your recent postings show that you agree with me]

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4KpaDg037422; Thu, 4 Nov 2004 12:51:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4KpacA037421; Thu, 4 Nov 2004 12:51:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4KpZD1037405 for <[e-mail]>; Thu, 4 Nov 2004 12:51:35 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (ASQ2-127-187.usae.bah.com [156.80.127.187]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA4Kpa8C021792 for <[e-mail]>; Thu, 4 Nov 2004 15:51:39 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Thu, 4 Nov 2004 15:51:31 -0500
Message-ID: <000b01c4c2b0$15166b80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

See responses in-line.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, November 04, 2004 12:39 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting


Santosh,

See response in-line in [DP:]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, November 03, 2004 9:47 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

 > Denis,

 > The CA name is defined by DN.  Since multiple CAs could have the same  >
name, in order to disambiguate the CA, you should consider the ancestors.

So we both agree.

 > That is  what the algorithm does.

However, the above argument does not validate the algorithm in anyway.

[SC: Please identify what is wrong with the algorithm.]

[DP: Please correct first the algorithm to include CA names instead of CRL 
Issuer names]

[SC: As I said 1-2 weeks ago, CA variables were chosen to differentiate
between CAs in certificate certification path and CAs in the CRL
certification path,  I am sure most people on this list understand that
these are all CAs]

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4KpZ58037412; Thu, 4 Nov 2004 12:51:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4KpZ55037411; Thu, 4 Nov 2004 12:51:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4KpZ9c037404 for <[e-mail]>; Thu, 4 Nov 2004 12:51:35 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (ASQ2-127-187.usae.bah.com [156.80.127.187]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA4Kpa8B021792 for <[e-mail]>; Thu, 4 Nov 2004 15:51:38 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Thu, 4 Nov 2004 15:51:31 -0500
Message-ID: <000a01c4c2b0$146e44a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA4KpZ9c037406
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

See responses in-line.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, November 04, 2004 12:41 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Signer certificate discovery for CRLs


Santosh,

See responses in-line in [DP: ]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, November 03, 2004 9:46 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs

Santosh,

 > X.509 Annex B and 3280 do describe how to deal with various CRLs.

No. I disagree.

[SC: When you look at Annex B of X.509 and 3280 and what we have proposed
here, what is missing in your analysis?]

X.509 Annex B only states:

"The relying party shall be able to obtain the public key of the issuer
identified in the CRL using authenticated means;"

but does not say how this is done !

[SC: US comment along the lines of what has been the consensus on this
thread has been made/included]

[DP: What do you mean by "US comment". There is no such a thing in the IETF 
procedures. Then, "included" in what ?!? ]

[SC: You asked a question of X.509 Annex B and so I responded how we are
fixing X.509.  Everyone knows that IETF does not deal with these things]

RFC 3280 is also lacking to provide any detail about this.

[SC: We are recommending the Editor include the consensus in the next round]

[DP: Fine, but there is no text at the present time, so no consensus yet at 
the present time].

[SC: As I said, we have done some thinking and have proposed ideas for 3280
considerations.]

This is a major deficiency of both X.509 and RFC 3280.

Denis





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4KpYgo037402; Thu, 4 Nov 2004 12:51:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4KpYRS037401; Thu, 4 Nov 2004 12:51:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4KpXnL037392 for <[e-mail]>; Thu, 4 Nov 2004 12:51:34 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (ASQ2-127-187.usae.bah.com [156.80.127.187]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA4Kpa8A021792 for <[e-mail]>; Thu, 4 Nov 2004 15:51:37 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Thu, 4 Nov 2004 15:51:31 -0500
Message-ID: <000901c4c2b0$14034dd0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA4KpYnL037396
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

As I said, we are well ahead of you if you look at my and Stefan's and the
Chinese gentleman's postings on the syntax of AIA.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Thursday, November 04, 2004 12:34 PM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs



Santosh,

See responses in-line in [DP:]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, November 03, 2004 9:58 AM
To: Santosh Chokhani
Cc: 'pkix'; David A. Cooper
Subject: Re: Signer certificate discovery for CRLs

Santosh,

 > Denis,
 >
 > Just show us how SIA (wherever you want to put it) is more efficient  >
than AIA for CRL signer.

The question is not whether it is better or not.

Walking on certification paths can be done bottom-up (using AIA extensions)
or top-down (using SIA extensions).

[SC: Before we get into path, the purpose of this AIA is simply to get the
end certificate which protocols such as CMS S/MIME provide]

It should be RECOMMENDED to place an SIA extension in every CA certificate,
starting from every Trust Anchor (TA) when the TA is expressed using a
self-signed certificate.

As I already said, information is missing in RFC 3280: we need to say more
about the formats implied by accessMethod.

There are four possible cases :

   1 - it allows to retrieve one single file,
   2 - it allows to query for a single file in a repository,
   3 - it allows to query for one or more files in a repository,
   4 - it provides the address of a repository.

The current text should be clarified whether accessMethod is used in an AIA
extension or in an SIA extension. Cases 3 and 4 apply to the SIA extension.

[SC: For both AIA and SIA, at least an HTTP pointer to a p7 file containing
one or more certificates and pointer to ldap attribute should be permitted.]

[DP: At this time I do not care for the details, but I only want to point 
out to David Cooper that text is needed on that topic].

Denis





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HfCBu063453; Thu, 4 Nov 2004 09:41:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4HfCne063452; Thu, 4 Nov 2004 09:41:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HfBOF063399 for <[e-mail]>; Thu, 4 Nov 2004 09:41:11 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA08958; Thu, 4 Nov 2004 18:53:02 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110418410244:1235 ; Thu, 4 Nov 2004 18:41:02 +0100 
Message-ID: <[e-mail]>
Date: Thu, 04 Nov 2004 18:41:01 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Signer certificate discovery for CRLs
References: <001401c4c1b7$6571cfb0$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 04/11/2004 18:41:02, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 04/11/2004 18:41:04, Serialize complete at 04/11/2004 18:41:04
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

See responses in-line in [DP: ]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, November 03, 2004 9:46 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs

Santosh,

 > X.509 Annex B and 3280 do describe how to deal with various CRLs.

No. I disagree.

[SC: When you look at Annex B of X.509 and 3280 and what we have proposed
here, what is missing in your analysis?]

X.509 Annex B only states:

"The relying party shall be able to obtain the public key of the issuer
identified in the CRL using authenticated means;"

but does not say how this is done !

[SC: US comment along the lines of what has been the consensus on this
thread has been made/included]

[DP: What do you mean by "US comment". There is no such a thing in the IETF 
procedures. Then, "included" in what ?!? ]

RFC 3280 is also lacking to provide any detail about this.

[SC: We are recommending the Editor include the consensus in the next round]

[DP: Fine, but there is no text at the present time, so no consensus yet at 
the present time].

This is a major deficiency of both X.509 and RFC 3280.

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HePUP063078; Thu, 4 Nov 2004 09:40:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4HePdu063077; Thu, 4 Nov 2004 09:40:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HeNds062999 for <[e-mail]>; Thu, 4 Nov 2004 09:40:24 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA29146; Thu, 4 Nov 2004 18:52:14 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110418401467:1234 ; Thu, 4 Nov 2004 18:40:14 +0100 
Message-ID: <[e-mail]>
Date: Thu, 04 Nov 2004 18:40:13 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <001c01c4c1b8$7bfa4900$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 04/11/2004 18:40:14, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 04/11/2004 18:40:16, Serialize complete at 04/11/2004 18:40:16
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

See responses in-line in [DP:]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, November 03, 2004 9:48 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

 > Denis,

 > The matching algorithm proposed checks/compares the ancestors.

The matching algorithm is missing to say "who" trusts "somebody" for "what".
Unless this is clearly said, there is no trust possible and thus no
algorithm possible.

[SC: The two paths needs to be verified in accordance with 3280 in order to
establish trust]

[DP: the certification path needs to be verified according to RFC 3280.
The problem is that RFC 3280 does not tell how to verify that the CRL comes 
from the right CRL Issuer. Your assumption that the "two paths needs to be 
verified in accordance with 3280 in order to establish trust" is thus 
incorrect].

 > This algorithm is nothing more than formalism of something you agreed
 > to in 2003 on this list.

I don't think so.

[SC: Go back to September 2003 archive of your response to my post and tell
me what is not covered]

[DP: You would need to be more precise and provide me an extract of what you 
refer to]

Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HcrwN062444; Thu, 4 Nov 2004 09:38:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4Hcr5R062443; Thu, 4 Nov 2004 09:38:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HcqeU062381 for <[e-mail]>; Thu, 4 Nov 2004 09:38:52 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA35774; Thu, 4 Nov 2004 18:50:44 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110418384606:1233 ; Thu, 4 Nov 2004 18:38:46 +0100 
Message-ID: <[e-mail]>
Date: Thu, 04 Nov 2004 18:38:45 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <001b01c4c1b8$2d5a91b0$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 04/11/2004 18:38:46, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 04/11/2004 18:38:46, Serialize complete at 04/11/2004 18:38:46
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

See response in-line in [DP:]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, November 03, 2004 9:47 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

 > Denis,

 > The CA name is defined by DN.  Since multiple CAs could have the same
 > name, in order to disambiguate the CA, you should consider the ancestors.

So we both agree.

 > That is  what the algorithm does.

However, the above argument does not validate the algorithm in anyway.

[SC: Please identify what is wrong with the algorithm.]

[DP: Please correct first the algorithm to include CA names instead of CRL 
Issuer names]

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HYHtk060406; Thu, 4 Nov 2004 09:34:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4HYHGB060405; Thu, 4 Nov 2004 09:34:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HYFiu060310 for <[e-mail]>; Thu, 4 Nov 2004 09:34:16 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA29478; Thu, 4 Nov 2004 18:45:58 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110418335918:1228 ; Thu, 4 Nov 2004 18:33:59 +0100 
Message-ID: <[e-mail]>
Date: Thu, 04 Nov 2004 18:33:58 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'pkix'" <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <001d01c4c1b9$62174820$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 04/11/2004 18:33:59, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 04/11/2004 18:34:00, Serialize complete at 04/11/2004 18:34:00
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

See responses in-line in [DP:]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, November 03, 2004 9:58 AM
To: Santosh Chokhani
Cc: 'pkix'; David A. Cooper
Subject: Re: Signer certificate discovery for CRLs

Santosh,

 > Denis,
 >
 > Just show us how SIA (wherever you want to put it) is more efficient
 > than AIA for CRL signer.

The question is not whether it is better or not.

Walking on certification paths can be done bottom-up (using AIA extensions)
or top-down (using SIA extensions).

[SC: Before we get into path, the purpose of this AIA is simply to get the
end certificate which protocols such as CMS S/MIME provide]

It should be RECOMMENDED to place an SIA extension in every CA certificate,
starting from every Trust Anchor (TA) when the TA is expressed using a
self-signed certificate.

As I already said, information is missing in RFC 3280: we need to say more
about the formats implied by accessMethod.

There are four possible cases :

   1 - it allows to retrieve one single file,
   2 - it allows to query for a single file in a repository,
   3 - it allows to query for one or more files in a repository,
   4 - it provides the address of a repository.

The current text should be clarified whether accessMethod is used in an AIA
extension or in an SIA extension. Cases 3 and 4 apply to the SIA extension.

[SC: For both AIA and SIA, at least an HTTP pointer to a p7 file containing
one or more certificates and pointer to ldap attribute should be permitted.]

[DP: At this time I do not care for the details, but I only want to point 
out to David Cooper that text is needed on that topic].

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4CI4E6028529; Thu, 4 Nov 2004 04:18:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4CI4cS028528; Thu, 4 Nov 2004 04:18:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4CHxxq028435 for <[e-mail]>; Thu, 4 Nov 2004 04:18:03 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA4CHh89017676 for <[e-mail]>; Thu, 4 Nov 2004 07:17:57 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: Role of New Extension in CRL in OCSP Environments
Date: Thu, 4 Nov 2004 07:17:37 -0500
Message-ID: <007201c4c268$51a9b400$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01C4C23E.68D3AC00"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0073_01C4C23E.68D3AC00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,
=20
There is another benefit of the extension I have proposed for CRL =
(SEQUENCE
or SET of Key Hashes).
=20
When an OCSP Responder gets a CRL, it could save this extension with the
revocation state table for the CA.  When the Responder gets a request, =
the
key hash in the request can be matched to one of these values for the
specified CA.  If none matches, the Responder should return UNKNOWN.
=20
In summary, this extension will permit the Responder to associate the =
client
request with the CA.
=20

Santosh Chokhani=20
Orion Security Solutions, Inc.=20
1489 Chain Bridge Road, Suite 300=20
McLean, Virginia 22101=20
[phone]  Ext. 35 (voice)=20
[phone] (Fax)=20
[e-mail]=20
Visit our Web site=20
http://www.orionsec.com <http://www.orionsec.com/> =20

=20

------=_NextPart_000_0073_01C4C23E.68D3AC00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D685281212-04112004>All,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D685281212-04112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D685281212-04112004>There =
is another=20
benefit of the extension I have proposed for CRL (SEQUENCE or SET of Key =

Hashes).</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D685281212-04112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D685281212-04112004>When =
an OCSP=20
Responder gets a CRL, it could save this extension with the revocation =
state=20
table for the CA.&nbsp; When the Responder gets a request, the key hash =
in the=20
request can be matched to one of these values for the specified =
CA.&nbsp; If=20
none matches, the Responder should return UNKNOWN.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D685281212-04112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D685281212-04112004>In =
summary, this=20
extension will permit the Responder to associate the client request with =
the=20
CA.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV><!-- Converted from =
text/rtf format -->
<P><SPAN lang=3Den-us><FONT face=3DArial size=3D2>Santosh =
Chokhani</FONT></SPAN>=20
<BR><SPAN lang=3Den-us><FONT face=3DArial size=3D2>Orion Security =
Solutions,=20
Inc.</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3DArial =
size=3D2>1489 Chain=20
Bridge Road, Suite 300</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT =
face=3DArial=20
size=3D2>McLean, Virginia 22101</FONT></SPAN> <BR><SPAN =
lang=3Den-us><FONT=20
face=3DArial size=3D2>(703)</FONT> <FONT face=3DArial =
size=3D2>917</FONT><FONT=20
face=3DArial size=3D2>-</FONT><FONT face=3DArial =
size=3D2>0060</FONT><FONT face=3DArial=20
size=3D2></FONT>&nbsp;<FONT face=3DArial size=3D2> </FONT><FONT =
face=3DArial=20
color=3D#ff0000 size=3D2>Ext. 35</FONT> <FONT face=3DArial =
size=3D2>(</FONT><FONT=20
face=3DArial size=3D2>voice</FONT><FONT face=3DArial =
size=3D2>)</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2>(703)</FONT> <FONT face=3DArial =

size=3D2>917</FONT><FONT face=3DArial size=3D2>-</FONT><FONT =
face=3DArial=20
size=3D2>0260</FONT><FONT face=3DArial size=3D2> (Fax)</FONT></SPAN> =
<BR><SPAN=20
lang=3Den-us><FONT face=3DArial =
size=3D2>[e-mail]</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2>Visit our Web =
site</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2><A=20
href=3D"http://www.orionsec.com/">http://www.orionsec.com</A></FONT></SPA=
N> </P>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0073_01C4C23E.68D3AC00--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3IBA6r050388; Wed, 3 Nov 2004 10:11:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3IBADT050387; Wed, 3 Nov 2004 10:11:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3IB9Lb050378 for <[e-mail]>; Wed, 3 Nov 2004 10:11:09 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3IB9D12396; Wed, 3 Nov 2004 19:11:09 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 19:11:09 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3IB4628113; Wed, 3 Nov 2004 19:11:04 +0100 (MET)
Date: Wed, 3 Nov 2004 19:11:04 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Signer certificate discovery for CRLs
Cc: [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Santosh,
> 
> > Denis,
> > 
> > Just show us how SIA (wherever you want to put it) is more efficient than
> > AIA for CRL signer.
> 
> The question is not whether it is better or not.
> 
> Walking on certification paths can be done bottom-up (using AIA extensions) 
> or top-down (using SIA extensions).

Not only this way: You can also have a directory. Top-down may create a scaling
problem when you can only retrieve ALL certs (i.e. a pkcs7 cert list)

> 
> It should be RECOMMENDED to place an SIA extension in every CA certificate, 
> starting from every Trust Anchor (TA) when the TA is expressed using a 
> self-signed certificate.

That's starting from the wrong end, as long as you don't have a good
and workable operational protocol (as you seem to indicate below)
  
> 
> As I already said, information is missing in RFC 3280: we need to say more 
> about the formats implied by accessMethod.
>
But not necessarily in 3280bis, I tend to think that this could be in an update
of operational protocols, and 3280bis limited strictly to a snapshot and 
profile of X509. 
 
> There are four possible cases :
> 
>   1 - it allows to retrieve one single file,
>   2 - it allows to query for a single file in a repository,
>   3 - it allows to query for one or more files in a repository,
>   4 - it provides the address of a repository

Do you think that for (L)DAP and together with Peter Gutmann HTTP access
these cases are addressed in an appropriate way, i.e. we have 
http and (l)dap specs. 
 
> The current text should be clarified whether accessMethod is used in an AIA 
> extension or in an SIA extension. Cases 3 and 4 apply to the SIA extension.
???



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3I9EuK049681; Wed, 3 Nov 2004 10:09:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3I9EfO049676; Wed, 3 Nov 2004 10:09:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3I9CAe049655 for <[e-mail]>; Wed, 3 Nov 2004 10:09:13 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3I9ED12325; Wed, 3 Nov 2004 19:09:14 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 19:09:14 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3I9EU28087; Wed, 3 Nov 2004 19:09:14 +0100 (MET)
Date: Wed, 3 Nov 2004 19:09:14 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Peter,
> 
> Your assumption is wrong.
> 
> A CA with 2 keys is still just 1 entity and one CA. That has been
> determined through the discussions on this list.

Well, then to me the question remains: 

How do you determine *safely* that two keys associated to the same DN
belongs to one CA, and how can you be sure not assuming that you
have a case with two CAs. 

Is having two certs from the same superior CA the determining condition?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3HprFD044797; Wed, 3 Nov 2004 09:51:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3Hpr9b044796; Wed, 3 Nov 2004 09:51:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3HppmV044740 for <[e-mail]>; Wed, 3 Nov 2004 09:51:52 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Nov 2004 17:51:46 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Wed, 3 Nov 2004 17:51:41 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Thread-Index: AcTBzHCC42KZwo8aSCyrbmN9/tr+lgAAHcLA
From: "Stefan Santesson" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 03 Nov 2004 17:51:46.0509 (UTC) FILETIME=[C96DCFD0:01C4C1CD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA3HpqmV044791
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Your assumption is wrong.

A CA with 2 keys is still just 1 entity and one CA. That has been
determined through the discussions on this list.

I'm the first to admit though that this is not all too clearly and
explicitly spelled out in neither X.509 nor RFC 3280 in but it is
definitely defined in indirect terms.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: Peter Sylvester [mailto:[e-mail]]
> Sent: den 3 november 2004 18:42
> To: [e-mail]; Stefan Santesson
> Cc: [e-mail]
> Subject: RE: SV: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> >
> > Peter,
> >
> > The problem and the algorithm presented address the case where the
CA
> > and the CRL issuer are represented by different certificates. This
can
> > be the case both when the CA and the CRLissuer is the same entity
with
> > the same name, but using different keys, or when the CA and the
> > CRLissuer is separate entities. This is what I meant by CA or
CRLissuer
> > type.
> >
> >
> 
> I think we don't have a problem but I'd like to know whether
> the following is correct:
> 
> if we assume that PKI entity unicity is based on key+DN (or
practically
> just key), then we could have a situation that after rekeying a
> CA may have had issed a CRL with the old key which is still valid as
> well as a CRL with the new key. These CRL are assumed to come from
> two different entities, thus the availability of the new does not
> replace the older one. This is probably not worse than not being
> able to access to the new CRL.
> If one can detect a rekeying, this is not better than the effects
> of a good access to fresh CRLs?
> 
> A problem remaining is that if an RP does not detect a rekeying
> then trust configuations for the old CA cannot be carried over to
> the other.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3HfcGK040121; Wed, 3 Nov 2004 09:41:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3HfcBe040120; Wed, 3 Nov 2004 09:41:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3HfaMb040100 for <[e-mail]>; Wed, 3 Nov 2004 09:41:37 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3HfdD11977; Wed, 3 Nov 2004 18:41:39 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 18:41:39 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3HfcF28008; Wed, 3 Nov 2004 18:41:38 +0100 (MET)
Date: Wed, 3 Nov 2004 18:41:38 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Peter,
> 
> The problem and the algorithm presented address the case where the CA
> and the CRL issuer are represented by different certificates. This can
> be the case both when the CA and the CRLissuer is the same entity with
> the same name, but using different keys, or when the CA and the
> CRLissuer is separate entities. This is what I meant by CA or CRLissuer
> type.
> 
> 

I think we don't have a problem but I'd like to know whether
the following is correct:

if we assume that PKI entity unicity is based on key+DN (or practically
just key), then we could have a situation that after rekeying a
CA may have had issed a CRL with the old key which is still valid as
well as a CRL with the new key. These CRL are assumed to come from
two different entities, thus the availability of the new does not
replace the older one. This is probably not worse than not being 
able to access to the new CRL. 
If one can detect a rekeying, this is not better than the effects
of a good access to fresh CRLs?

A problem remaining is that if an RP does not detect a rekeying
then trust configuations for the old CA cannot be carried over to
the other. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FPfQs080652; Wed, 3 Nov 2004 07:25:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3FPemG080651; Wed, 3 Nov 2004 07:25:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FPeF4080639 for <[e-mail]>; Wed, 3 Nov 2004 07:25:40 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 ([66.208.27.185]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA3FPfn3022208 for <[e-mail]>; Wed, 3 Nov 2004 10:25:42 -0500
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Wed, 3 Nov 2004 10:25:42 -0500
Message-ID: <001d01c4c1b9$62174820$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA3FPeF4080643
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

See responses in-line in [SC:]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Wednesday, November 03, 2004 9:58 AM
To: Santosh Chokhani
Cc: 'pkix'; David A. Cooper
Subject: Re: Signer certificate discovery for CRLs


Santosh,

> Denis,
> 
> Just show us how SIA (wherever you want to put it) is more efficient 
> than AIA for CRL signer.

The question is not whether it is better or not.

Walking on certification paths can be done bottom-up (using AIA extensions) 
or top-down (using SIA extensions).

[SC: Before we get into path, the purpose of this AIA is simply to get the
end certificate which protocols such as CMS S/MIME provide]

It should be RECOMMENDED to place an SIA extension in every CA certificate, 
starting from every Trust Anchor (TA) when the TA is expressed using a 
self-signed certificate.

As I already said, information is missing in RFC 3280: we need to say more 
about the formats implied by accessMethod.

There are four possible cases :

  1 - it allows to retrieve one single file,
  2 - it allows to query for a single file in a repository,
  3 - it allows to query for one or more files in a repository,
  4 - it provides the address of a repository.

The current text should be clarified whether accessMethod is used in an AIA 
extension or in an SIA extension. Cases 3 and 4 apply to the SIA extension.

[SC: For both AIA and SIA, at least an HTTP pointer to a p7 file containing
one or more certificates and pointer to ldap attribute should be permitted.]

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, October 28, 2004 10:04 AM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> You wrote:
> 
> 
>>And, SIA for end certificate will add computational complexity.
> 
> 
> SIA, for this discussion, is not for end certificates, but for CA 
> certificates.
> 
> Denis
> 
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FJFju078339; Wed, 3 Nov 2004 07:19:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3FJF1I078338; Wed, 3 Nov 2004 07:19:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FJFBu078331 for <[e-mail]>; Wed, 3 Nov 2004 07:19:15 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 ([66.208.27.185]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA3FJGn3017951 for <[e-mail]>; Wed, 3 Nov 2004 10:19:16 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Wed, 3 Nov 2004 10:19:16 -0500
Message-ID: <001c01c4c1b8$7bfa4900$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA3FJFBu078333
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis.

See responses in-line in [SC:]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Wednesday, November 03, 2004 9:48 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting


Santosh,

> Denis,

> The matching algorithm proposed checks/compares the ancestors.

The matching algorithm is missing to say "who" trusts "somebody" for "what".
Unless this is clearly said, there is no trust possible and thus no 
algorithm possible.

[SC: The two paths needs to be verified in accordance with 3280 in order to
establish trust]

 > This algorithm is nothing more than formalism of something you agreed  >
to in 2003 on this list.

I don't think so.

[SC: Go back to September 2003 archive of your response to my post and tell
me what is not covered]

Denis


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, October 28, 2004 9:58 AM
> To: Santosh Chokhani
> Cc: [e-mail]; David A. Cooper
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Santosh
> 
> See responses inline in [DP:]
> 
> Santosh,
> 
>  > Denis:
> 
>  > The following URL is the location for the briefing you requested to 
> be  > posted.  >  > www.orionsec.com/crldp-idp-v3.ppt  > 
> <http://www.orionsec.com/crldp-idp-v3.ppt>
> 
> Many thanks. I browsed thru it.
> A minor point first. On slide 3, it is written:
> "A CA is defined by a name alone".
> This is contradicted 3 slides after when it is said:
> "There can be more than one CA with the same name".
> 
> [SC: There is no contradiction.  This concern is what the path 
> matching logic is all about.  When there are two or more "X", we are 
> trying to sure that we are talking about the same "X"]
> 
> Unless it is aid which CA provides the name of tha tCA, this is 
> meaningless. If we apply this recursively, then a CA name is composed 
> of a name given by another CA, whose name is given by another CA, 
> whose name is given by another CA, ..., whose name is given by a TA.
> 
> This could be what is meant in the last bullet point of slide 8 : 
> "Starting with a TA, the relying party can match the CA names in the 
> certificate and CRL certification paths", but this is far from crystal 
> clear.
> 
> [SC: Your suggestion that a CA name is disambiguated by ancestors is 
> what the algorithm does]
> 
> [DP: So you agree that name comparison alone is not sufficient since a 
> CA
> name MUST be disambiguated by ancestors].
> 
> Now the major points.
> 
> The same would apply to a CRL issuer name, UNLESS it is clear which CA 
> can nominate that CRL Issuer. Unfortunately, this point is also far 
> from crystal clear.
> 
> [SC: Since there could be two or more "X" as CRL issuers, that is why 
> we need the path matching algorithm].
> 
> [DP: Before knowing the algorithm, we need to know what are the trust
> conditions.]
> 
> Before diving into the details of algorithms for CRL path processing, 
> it is important to agree on which cases we will cover.
> 
> [SC: We cover all the cases]
> 
> [DP: This does not mean anything]
> 
> The case where the AC is the CRL Issuer is easy when it is the same 
> key.
> 
> [SC: What is AC?  If you mean CA, this case is covered]
> [DP: For sure, "AC" is the acronym of CA in French]
> 
> The case where the AC is the CRL Issuer but there has been a key 
> change is already more complex.
> 
> [SC: What is AC?  If you mean CA, this case is covered by the path 
> matching algorithm]
> 
> Now when the CRL Isssuer is not the CA we need to consider two cases:
> 
>     a) the CA got no right to issue CRLs (it only got a CA certificate
>        with the keyCertSign bit (bit 5),
> 
> [SC: We are not covering all the validation logic that is already in 
> 3280.
> 
> [DP: The problem is that RFC 3280 does not have any well described
> validation logic for a CRL Issuer diffrent from the CA.]
> 
> We are focusing on added rules for making sure we are dealing with the 
> correct "X"]
> 
>     b) the CA got the right to issue CRLs (it got a CA certificate with
both
>        bits sets, i.e. keyCertSign bit (bit 5) and cRLSign bit (bit 
> 6).
> 
> [SC: We are not covering all the validation logic that is already in 
> 3280.
> [DP: There is not such a logic in RFC 3280]
> 
> We are focusing on added rules for making sure we are dealing with the 
> correct "X"]
> 
> These two cases would need to be addressed in details.
> 
> Finally we would have to clarify what is an indirect CRL Issuer and 
> what kind of processing would be done in taht case.
> 
> [SC: Indirect CRL is defined in 3280.  The path matching algorithm 
> covers this]
> 
> [DP: What is the trust model ?]
> 
> Now, if we go just a litte bit under the details of some slides, there 
> is no notion of a certification path with CRL isssuer names.
> 
> [SC: All the certificates on slide 10 are issued by CAs with the 
> possible exception to the last one.  The node names are different, but 
> does not mean that the CAs are not issuing certificates]
> 
> A path may end up with a CRL Issuer name, but only CA names are 
> allowed in the certification path. So slide 10 is incorrect and by 
> implication subsequent slides 11 and 12 are incorrect too.
> 
> [SC: These are all CA names.  We can change the tags if that helps 
> you]
> [DP: That change will certainly help. Please do it and re-issue the
slides].
> 
> Denis
> 
> 
>  > Santosh Chokhani
>  > Orion Security Solutions, Inc.
>  > 1489 Chain Bridge Road, Suite 300
>  > McLean, Virginia 22101
>  > [phone]  Ext. 35 (voice)
>  > [phone] (Fax)
>  > [e-mail]
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FH3Yt077496; Wed, 3 Nov 2004 07:17:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3FH3oY077495; Wed, 3 Nov 2004 07:17:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FH215077488 for <[e-mail]>; Wed, 3 Nov 2004 07:17:02 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 ([66.208.27.185]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA3FH4n3016833 for <[e-mail]>; Wed, 3 Nov 2004 10:17:04 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Wed, 3 Nov 2004 10:17:04 -0500
Message-ID: <001b01c4c1b8$2d5a91b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

See response in-line in [SC:]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Wednesday, November 03, 2004 9:47 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting


Santosh,

> Denis,

> The CA name is defined by DN.  Since multiple CAs could have the same 
> name, in order to disambiguate the CA, you should consider the ancestors.

So we both agree.

> That is  what the algorithm does.

However, the above argument does not validate the algorithm in anyway.

[SC: Please identify what is wrong with the algorithm.]


Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, October 28, 2004 9:59 AM
> To: Santosh Chokhani
> Cc: 'Jean-Marc Desperrier'; [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Santosh,
> 
> 
>>Jean-Marc:
> 
> 
>>I agree that X.509 and 3280 define a CA by name.
> 
> 
> You disagree since you said: "a CA name is disambiguated by 
> ancestors", which is true.
> 
> Denis
> 
> 
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]] On Behalf Of Jean-Marc 
>>Desperrier
>>Sent: Wednesday, October 27, 2004 11:32 AM
>>To: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>
>>Denis Pinkas wrote:
>>
>>
>>
>>>Jean-Marc,
>>>
>>>
>>>
>>>>I'd say that the X509 rule is that a CA is defined by it's DN alone,
>>>>therefore one should never try to create two CA with the same DN in a 
>>>>properly managed hierarchy.
>>>
>>>For X.509, I do *not* say X.500, a DN is only relative to the CA who
>>>has given it.
>>
>>
>>I had no idea we had established that.
>>I only remember several messages asking why we would try to handle in 
>>PKIX the case of several CA with the same DN as it's invalid.
>>
>>In his presentation, to show that a CA is defined by name alone,
>>Santosh
>>refers specifically only to section 7 of X.509, and I think that must be 
>>in reference to the following sentence :
>>NOTE 1 - Although the CAs are unambiguously defined by a distinguished 
>>name in the DIT, this does not imply that there is any relationship 
>>between the organization of the CAs and the DIT
>>which I don't see as supporting what you say.
>>
>>I can see that you already said the same thing from this message
>>http://www.imc.org/ietf-pkix/mail-archive/msg03305.html
>>Quote :
>>"[Denis : a CA can never be defined by a name only. It is a name 
>>issued
>>by a given CA. It can also be a root key with a sequence of names. These 
>>are the only ways names can be unambiguous].
>>
>>[Santosh: I do not find support for anything other than Issuer being
>>identified by DN only in X.509 and 3280.]"
>>
>>But I can not find any message in which you gave additional info in
>>answer to Santosh's doubts.
>>
>>
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FEQGj076121; Wed, 3 Nov 2004 07:14:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3FEQFB076117; Wed, 3 Nov 2004 07:14:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FEPdT076027 for <[e-mail]>; Wed, 3 Nov 2004 07:14:25 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Nov 2004 15:14:13 +0000
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Wed, 3 Nov 2004 15:14:12 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Thread-Index: AcTA6hknOWyuqTUvSZySvDN5OYwA7gAzOZaw
From: "Stefan Santesson" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 03 Nov 2004 15:14:13.0572 (UTC) FILETIME=[C70A1840:01C4C1B7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA3FEPdT076100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

The problem and the algorithm presented address the case where the CA
and the CRL issuer are represented by different certificates. This can
be the case both when the CA and the CRLissuer is the same entity with
the same name, but using different keys, or when the CA and the
CRLissuer is separate entities. This is what I meant by CA or CRLissuer
type.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Peter Sylvester [mailto:[e-mail]]
> Sent: den 2 november 2004 15:41
> To: [e-mail]; Stefan Santesson
> Cc: [e-mail]
> Subject: RE: SV: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> > Yes and no.
> >
> > Validation software should start with the assumption that two
> > certificates (CA or CRLissuer type), carrying the same subject name,
> > represent different entities until it can determine that they are
> > offspring of the same ancestors according to the algorithm proposed
by
> > Santosh.
> 
> I am not sure what you say "(CA or CRLissuer type)":
> Does this include the case that two CA keys are certified by
> the same third entity, i.e. the fact having two certs from
> one CA for the "same entity"?
> 
> I think that indeed assuming different entities is robust and does
> not create more new problems.
> 
> >
> > This approach is much more attack resilient and reduce complexity in
> > path validation.
> >
> > I don't see how building a local database is neither generally
feasible
> > nor a valid alternative.
> 
> I don't meant a permanent storage, just the data structure that is
used
> to hold some "indexed" heap of certs,allowing a minimal number
> of signature tests., i.e. issuer/serial may point to several certs in
> this heap.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FBRqB075124; Wed, 3 Nov 2004 07:11:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3FBR3D075121; Wed, 3 Nov 2004 07:11:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FBQZa075115 for <[e-mail]>; Wed, 3 Nov 2004 07:11:27 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 ([66.208.27.185]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA3FBSn3012769 for <[e-mail]>; Wed, 3 Nov 2004 10:11:29 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Wed, 3 Nov 2004 10:11:29 -0500
Message-ID: <001401c4c1b7$6571cfb0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA3FBRZa075116
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

See responses in-line in [SC]

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Wednesday, November 03, 2004 9:46 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs


Santosh,

> X.509 Annex B and 3280 do describe how to deal with various CRLs.

No. I disagree.

[SC: When you look at Annex B of X.509 and 3280 and what we have proposed
here, what is missing in your analysis?]

X.509 Annex B only states:

"The relying party shall be able to obtain the public key of the issuer 
identified in the CRL using authenticated means;"

but does not say how this is done !

[SC: US comment along the lines of what has been the consensus on this
thread has been made/included]

RFC 3280 is also lacking to provide any detail about this.

[SC: We are recommending the Editor include the consensus in the next round]

This is a major deficiency of both X.509 and RFC 3280.

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, October 28, 2004 10:01 AM
> To: Santosh Chokhani
> Cc: 'pkix'; David A. Cooper
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> See responses in-line in [DP:]
> 
> (text deleted)
> 
> Before accepting AIA as a valid option for CRLs we have to say how and 
> when it would be used. The issue is MUCH MORE complicated than simply 
> adding AIA in CRLs, since we have to give the processing rules for 
> that extension.
> 
> [SC: The issue is simple and straightforward.  Just the way signed CMS 
> permits to carry signer's certificate, AIA in CRL simply points to the 
> signer certificate.  You can use that pointer and develop the path 
> whichever way you like]
> 
> Upon this aspect, we are far from an agreement and this is of course 
> strongly related to the (lack of a) CRL processing model.
> 
> [SC: What specifically do you disagree with and why?  There is a CRL 
> processing model.  It is well articulated in X.509 Annex B and well 
> summarized in 3280]
> 
> [DP: There is no CRL processing model. It is not summarized in 3280. 
> This is a major problem of 3280].
> 
> So we need first to say how we verify that a CRL Issuer is the right 
> CRL Issuer (see my e-mail fom this morning to Santosh). Once we will 
> have fixed that, then we will be able to explore the advantages and 
> disavantages of including or not AIA in CRLs.
> 
> [SC: We have done this in this thread and by the briefing.]
> 
> [DP: No. We still need to say how we verify that a CRL Issuer is the 
> right
> CRL Issuer]. I fear a myriad of different models.
> 
> Denis
> 
> PS: David, I copied this message to you since you are making a list of
> issues related to RFC 3280. This is certainly a major one: clarification
on 
> CRL processing when the CRL Issuer is not the CA that has issued the 
> certificate is needed.
> 
>  > /Stefan
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3F9Fas074671; Wed, 3 Nov 2004 07:09:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3F9FKV074670; Wed, 3 Nov 2004 07:09:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3F9EAe074628 for <[e-mail]>; Wed, 3 Nov 2004 07:09:15 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id BA6F762DAB for <[e-mail]>; Wed,  3 Nov 2004 16:09:06 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id D865B440C5 for <[e-mail]>; Wed,  3 Nov 2004 16:09:35 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28626-09 for <[e-mail]>; Wed, 3 Nov 2004 16:09:26 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 9F891440B2 for <[e-mail]>; Wed,  3 Nov 2004 16:09:26 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed,  3 Nov 2004 16:08:58 +0100
From: "Julien Stern" <[e-mail]>
Date: Wed, 3 Nov 2004 16:08:58 +0100
To: [e-mail]
Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

see responses in-line.

On Wed, Nov 03, 2004 at 03:44:40PM +0100, Denis Pinkas wrote:
> Julien,
> 
> >Greetings,
> 
> >the more posting about this issue and the more confused I am :)
> >I understood that
> 
> >1) Ideally, a DN should uniquely identify a entity.
> 
> Nothing is "ideal".

I cannot agree more ;)

> So this statement is not valid.
> 
> >2) If two Trust Anchors with the same DN are different entities, there
> >is a major (configuration) problem.
> 
> A trust anchor always includes a public key value. It is not possible to 
> have two TAs with the same public key value unless the corresponding 
> private key has been compromised.

I have never talked about two TAs with the same public key.
I can easily configure my local software to add a trust anchor whose
DN is, say, "C=US,O=Verisign" and whose corresponding private key is mine.
I was just trying to say that I'm assuming this is NOT the case, else
there is not much one can do.

> >3) If two certificates have the same DN but represent different entitities
> >that is a mistake (or an attack). That must be detected.
> 
> This is not a mistake. A DN is only local to the CA that has nominated the 
> subject.

Well, I understood ISO wanted DN to be unique, but ok, let us say it
may happen even if it is not a mistake.

> >4) The way to detect it is to check for the ancestors according to the
> >algorithm proposed by Santosh.
> 
> I don't know the "algorithm proposed by Santosh", but using all the 
> elements of the certification path, it is easy to make the difference 
> between two different entities from two different CAs that would have the 
> same DN.

I though it was the algorithm that was under discussions during this thread.
I also though that (one of) the main goal of this algorithm was to make
the difference between two different entities with the same DN.
I finally do not think that "it is easy" to make this difference, but if
you indeed have a trivial way to do so, I'd be more than interested.

Sincerely,

--
Julien



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3F0iso072933; Wed, 3 Nov 2004 07:00:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3F0iGr072932; Wed, 3 Nov 2004 07:00:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3F0dEN072854 for <[e-mail]>; Wed, 3 Nov 2004 07:00:41 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA22706; Wed, 3 Nov 2004 16:12:17 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110316001859:759 ; Wed, 3 Nov 2004 16:00:18 +0100 
Message-ID: <[e-mail]>
Date: Wed, 03 Nov 2004 15:57:54 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'pkix'" <[e-mail]>, "David A. Cooper" <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <006c01c4bd25$226bb460$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 16:00:18, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 16:00:21, Serialize complete at 03/11/2004 16:00:21
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

> Denis,
> 
> Just show us how SIA (wherever you want to put it) is more efficient than
> AIA for CRL signer.

The question is not whether it is better or not.

Walking on certification paths can be done bottom-up (using AIA extensions) 
or top-down (using SIA extensions).

It should be RECOMMENDED to place an SIA extension in every CA certificate, 
starting from every Trust Anchor (TA) when the TA is expressed using a 
self-signed certificate.

As I already said, information is missing in RFC 3280: we need to say more 
about the formats implied by accessMethod.

There are four possible cases :

  1 - it allows to retrieve one single file,
  2 - it allows to query for a single file in a repository,
  3 - it allows to query for one or more files in a repository,
  4 - it provides the address of a repository.

The current text should be clarified whether accessMethod is used in an AIA 
extension or in an SIA extension. Cases 3 and 4 apply to the SIA extension.

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, October 28, 2004 10:04 AM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> You wrote:
> 
> 
>>And, SIA for end certificate will add computational complexity.
> 
> 
> SIA, for this discussion, is not for end certificates, but for CA
> certificates.
> 
> Denis
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3Eohuj069616; Wed, 3 Nov 2004 06:50:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3Eohkh069615; Wed, 3 Nov 2004 06:50:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3Eod3n069536 for <[e-mail]>; Wed, 3 Nov 2004 06:50:41 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA67596; Wed, 3 Nov 2004 16:02:17 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110315501969:752 ; Wed, 3 Nov 2004 15:50:19 +0100 
Message-ID: <[e-mail]>
Date: Wed, 03 Nov 2004 15:47:56 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <006701c4bd24$95d1e650$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 15:50:19, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 15:50:20, Serialize complete at 03/11/2004 15:50:20
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

> Denis,

> The matching algorithm proposed checks/compares the ancestors.

The matching algorithm is missing to say "who" trusts "somebody" for "what".
Unless this is clearly said, there is no trust possible and thus no 
algorithm possible.

 > This algorithm is nothing more than formalism of something you agreed
 > to in 2003 on this list.

I don't think so.

Denis


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, October 28, 2004 9:58 AM
> To: Santosh Chokhani
> Cc: [e-mail]; David A. Cooper
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Santosh
> 
> See responses inline in [DP:]
> 
> Santosh,
> 
>  > Denis:
> 
>  > The following URL is the location for the briefing you requested to be  >
> posted.  >  > www.orionsec.com/crldp-idp-v3.ppt  >
> <http://www.orionsec.com/crldp-idp-v3.ppt>
> 
> Many thanks. I browsed thru it.
> A minor point first. On slide 3, it is written:
> "A CA is defined by a name alone".
> This is contradicted 3 slides after when it is said:
> "There can be more than one CA with the same name".
> 
> [SC: There is no contradiction.  This concern is what the path matching
> logic is all about.  When there are two or more "X", we are trying to sure
> that we are talking about the same "X"]
> 
> Unless it is aid which CA provides the name of tha tCA, this is meaningless.
> If we apply this recursively, then a CA name is composed of a name given by
> another CA, whose name is given by another CA, whose name is given by
> another CA, ..., whose name is given by a TA.
> 
> This could be what is meant in the last bullet point of slide 8 : "Starting
> with a TA, the relying party can match the CA names in the certificate and
> CRL certification paths", but this is far from crystal clear.
> 
> [SC: Your suggestion that a CA name is disambiguated by ancestors is what
> the algorithm does]
> 
> [DP: So you agree that name comparison alone is not sufficient since a CA 
> name MUST be disambiguated by ancestors].
> 
> Now the major points.
> 
> The same would apply to a CRL issuer name, UNLESS it is clear which CA can
> nominate that CRL Issuer. Unfortunately, this point is also far from crystal
> clear.
> 
> [SC: Since there could be two or more "X" as CRL issuers, that is why we
> need the path matching algorithm].
> 
> [DP: Before knowing the algorithm, we need to know what are the trust 
> conditions.]
> 
> Before diving into the details of algorithms for CRL path processing, it is
> important to agree on which cases we will cover.
> 
> [SC: We cover all the cases]
> 
> [DP: This does not mean anything]
> 
> The case where the AC is the CRL Issuer is easy when it is the same key.
> 
> [SC: What is AC?  If you mean CA, this case is covered]
> [DP: For sure, "AC" is the acronym of CA in French]
> 
> The case where the AC is the CRL Issuer but there has been a key change is
> already more complex.
> 
> [SC: What is AC?  If you mean CA, this case is covered by the path matching
> algorithm]
> 
> Now when the CRL Isssuer is not the CA we need to consider two cases:
> 
>     a) the CA got no right to issue CRLs (it only got a CA certificate
>        with the keyCertSign bit (bit 5),
> 
> [SC: We are not covering all the validation logic that is already in 3280.
> 
> [DP: The problem is that RFC 3280 does not have any well described 
> validation logic for a CRL Issuer diffrent from the CA.]
> 
> We are focusing on added rules for making sure we are dealing with the
> correct "X"]
> 
>     b) the CA got the right to issue CRLs (it got a CA certificate with both
>        bits sets, i.e. keyCertSign bit (bit 5) and cRLSign bit (bit 6).
> 
> [SC: We are not covering all the validation logic that is already in 3280.
> [DP: There is not such a logic in RFC 3280]
> 
> We are focusing on added rules for making sure we are dealing with the
> correct "X"]
> 
> These two cases would need to be addressed in details.
> 
> Finally we would have to clarify what is an indirect CRL Issuer and what
> kind of processing would be done in taht case.
> 
> [SC: Indirect CRL is defined in 3280.  The path matching algorithm covers
> this]
> 
> [DP: What is the trust model ?]
> 
> Now, if we go just a litte bit under the details of some slides, there is no
> notion of a certification path with CRL isssuer names.
> 
> [SC: All the certificates on slide 10 are issued by CAs with the possible
> exception to the last one.  The node names are different, but does not mean
> that the CAs are not issuing certificates]
> 
> A path may end up with a CRL Issuer name, but only CA names are allowed in
> the certification path. So slide 10 is incorrect and by implication
> subsequent slides 11 and 12 are incorrect too.
> 
> [SC: These are all CA names.  We can change the tags if that helps you]
> [DP: That change will certainly help. Please do it and re-issue the slides].
> 
> Denis
> 
> 
>  > Santosh Chokhani
>  > Orion Security Solutions, Inc.
>  > 1489 Chain Bridge Road, Suite 300
>  > McLean, Virginia 22101
>  > [phone]  Ext. 35 (voice)
>  > [phone] (Fax)
>  > [e-mail]
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3EnEJ4069067; Wed, 3 Nov 2004 06:49:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3EnEnZ069066; Wed, 3 Nov 2004 06:49:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3En97J068984 for <[e-mail]>; Wed, 3 Nov 2004 06:49:11 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA17930; Wed, 3 Nov 2004 16:00:52 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110315485405:751 ; Wed, 3 Nov 2004 15:48:54 +0100 
Message-ID: <[e-mail]>
Date: Wed, 03 Nov 2004 15:46:30 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <006a01c4bd24$d62e3000$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 15:48:54, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 15:48:55, Serialize complete at 03/11/2004 15:48:55
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

> Denis,

> The CA name is defined by DN.  Since multiple CAs could have the same name,
> in order to disambiguate the CA, you should consider the ancestors.  

So we both agree.

> That is  what the algorithm does.

However, the above argument does not validate the algorithm in anyway.

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, October 28, 2004 9:59 AM
> To: Santosh Chokhani
> Cc: 'Jean-Marc Desperrier'; [e-mail]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Santosh,
> 
> 
>>Jean-Marc:
> 
> 
>>I agree that X.509 and 3280 define a CA by name.
> 
> 
> You disagree since you said: "a CA name is disambiguated by ancestors",
> which is true.
> 
> Denis
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Jean-Marc 
>>Desperrier
>>Sent: Wednesday, October 27, 2004 11:32 AM
>>To: [e-mail]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>
>>Denis Pinkas wrote:
>>
>>
>>
>>>Jean-Marc,
>>>
>>>
>>>
>>>>I'd say that the X509 rule is that a CA is defined by it's DN alone, 
>>>>therefore one should never try to create two CA with the same DN in a 
>>>>properly managed hierarchy.
>>>
>>>For X.509, I do *not* say X.500, a DN is only relative to the CA who 
>>>has given it.
>>
>>
>>I had no idea we had established that.
>>I only remember several messages asking why we would try to handle in
>>PKIX the case of several CA with the same DN as it's invalid.
>>
>>In his presentation, to show that a CA is defined by name alone, 
>>Santosh
>>refers specifically only to section 7 of X.509, and I think that must be 
>>in reference to the following sentence :
>>NOTE 1 - Although the CAs are unambiguously defined by a distinguished 
>>name in the DIT, this does not imply that there is any relationship 
>>between the organization of the CAs and the DIT
>>which I don't see as supporting what you say.
>>
>>I can see that you already said the same thing from this message 
>>http://www.imc.org/ietf-pkix/mail-archive/msg03305.html
>>Quote :
>>"[Denis : a CA can never be defined by a name only. It is a name 
>>issued
>>by a given CA. It can also be a root key with a sequence of names. These 
>>are the only ways names can be unambiguous].
>>
>>[Santosh: I do not find support for anything other than Issuer being 
>>identified by DN only in X.509 and 3280.]"
>>
>>But I can not find any message in which you gave additional info in 
>>answer to Santosh's doubts.
>>
>>
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3Emj72068880; Wed, 3 Nov 2004 06:48:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3EmjWv068879; Wed, 3 Nov 2004 06:48:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3Emec9068808 for <[e-mail]>; Wed, 3 Nov 2004 06:48:42 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA46534; Wed, 3 Nov 2004 16:00:19 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110315482061:750 ; Wed, 3 Nov 2004 15:48:20 +0100 
Message-ID: <[e-mail]>
Date: Wed, 03 Nov 2004 15:45:56 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'pkix'" <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <006b01c4bd24$ff585d70$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 15:48:20, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 15:48:22, Serialize complete at 03/11/2004 15:48:22
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

> X.509 Annex B and 3280 do describe how to deal with various CRLs.

No. I disagree.

X.509 Annex B only states:

"The relying party shall be able to obtain the public key of the issuer 
identified in the CRL using authenticated means;"

but does not say how this is done !

RFC 3280 is also lacking to provide any detail about this.

This is a major deficiency of both X.509 and RFC 3280.

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, October 28, 2004 10:01 AM
> To: Santosh Chokhani
> Cc: 'pkix'; David A. Cooper
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> See responses in-line in [DP:]
> 
> (text deleted)
> 
> Before accepting AIA as a valid option for CRLs we have to say how and when
> it would be used. The issue is MUCH MORE complicated than simply adding AIA
> in CRLs, since we have to give the processing rules for that extension.
> 
> [SC: The issue is simple and straightforward.  Just the way signed CMS
> permits to carry signer's certificate, AIA in CRL simply points to the
> signer certificate.  You can use that pointer and develop the path whichever
> way you like]
> 
> Upon this aspect, we are far from an agreement and this is of course
> strongly related to the (lack of a) CRL processing model.
> 
> [SC: What specifically do you disagree with and why?  There is a CRL
> processing model.  It is well articulated in X.509 Annex B and well
> summarized in 3280]
> 
> [DP: There is no CRL processing model. It is not summarized in 3280. This is
> a major problem of 3280].
> 
> So we need first to say how we verify that a CRL Issuer is the right CRL
> Issuer (see my e-mail fom this morning to Santosh). Once we will have fixed
> that, then we will be able to explore the advantages and disavantages of
> including or not AIA in CRLs.
> 
> [SC: We have done this in this thread and by the briefing.]
> 
> [DP: No. We still need to say how we verify that a CRL Issuer is the right 
> CRL Issuer]. I fear a myriad of different models.
> 
> Denis
> 
> PS: David, I copied this message to you since you are making a list of 
> issues related to RFC 3280. This is certainly a major one: clarification on 
> CRL processing when the CRL Issuer is not the CA that has issued the 
> certificate is needed.
> 
>  > /Stefan
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3Elj5Q068435; Wed, 3 Nov 2004 06:47:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3EljE5068434; Wed, 3 Nov 2004 06:47:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3Ele3F068331 for <[e-mail]>; Wed, 3 Nov 2004 06:47:42 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA46514; Wed, 3 Nov 2004 15:59:12 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110315470394:748 ; Wed, 3 Nov 2004 15:47:03 +0100 
Message-ID: <[e-mail]>
Date: Wed, 03 Nov 2004 15:44:40 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Julien Stern <[e-mail]>
CC: [e-mail]
Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 15:47:04, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 15:47:17, Serialize complete at 03/11/2004 15:47:17
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

> Greetings,

> the more posting about this issue and the more confused I am :)
> I understood that

> 1) Ideally, a DN should uniquely identify a entity.

Nothing is "ideal". So this statement is not valid.

> 2) If two Trust Anchors with the same DN are different entities, there
> is a major (configuration) problem.

A trust anchor always includes a public key value. It is not possible to 
have two TAs with the same public key value unless the corresponding private 
key has been compromised.

> 3) If two certificates have the same DN but represent different entitities
> that is a mistake (or an attack). That must be detected.

This is not a mistake. A DN is only local to the CA that has nominated the 
subject.

> 4) The way to detect it is to check for the ancestors according to the
> algorithm proposed by Santosh.

I don't know the "algorithm proposed by Santosh", but using all the elements 
of the certification path, it is easy to make the difference between two 
different entities from two different CAs that would have the same DN.

Denis


> Is that correct ?
> Is there a consensus on this ?
> Shouldn't OCSP have a special treatment on that respect ?
> 
> Sincerely,
> 
> --
> Julien Stern
> 
> On Sat, Oct 30, 2004 at 03:59:23PM +0100, Stefan Santesson wrote:
> 
>>Peter,
>>
>>I assume that this encapsulates the issue:
>><snip>
>>
>>>Are you saying that in the presence of two CA certs with same name
>>
>>having
>>
>>>a different key, one general should
>>>first assume that they belong to different entities, and only if one
>>
>>finds
>>
>>>a cross certificate pair of
>>>one signing the other key and vice versa, you may conclude that you
>>
>>have
>>
>>>the same entity so you look for
>>>CRLs signed by *the same* CA but the other key.
>>
>>Yes and no.
>>
>>Validation software should start with the assumption that two
>>certificates (CA or CRLissuer type), carrying the same subject name,
>>represent different entities until it can determine that they are
>>offspring of the same ancestors according to the algorithm proposed by
>>Santosh.
>>
>>This approach is much more attack resilient and reduce complexity in
>>path validation. 
>>
>>I don't see how building a local database is neither generally feasible
>>nor a valid alternative.
>>
>>Stefan Santesson
>>Microsoft Security Center of Excellence (SCOE)
>> 
>>
>>>-----Original Message-----
>>>From: [e-mail]
>>
>>[mailto:[e-mail]]
>>
>>>On Behalf Of Peter Sylvester
>>>Sent: den 29 oktober 2004 18:06
>>>To: [e-mail]; Stefan Santesson
>>>Cc: [e-mail]
>>>Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
>>>
>>>
>>>
>>>>Peter,
>>>>
>>>>I disagree. I think it is very important to cover for the case where
>>>
>>2
>>
>>>CAs may have the same name.
>>>
>>>I am not against having someone to provide a specification how to
>>>construct
>>>a local database and a way to detect such a situation inside the
>>
>>potato
>>
>>>of cross certificates connected CA suppended by trust hooks.
>>>
>>>
>>>>In troducing indirect CRLs means that we introduce possible attack
>>>
>>>vectors and it is our responsibility to create rules that makes
>>>vulnerabilities as unlikely as possible, even in bad implementations
>>
>>(80%+
>>
>>>of all vulnerabilities are miconfiguration problems).
>>>
>>>>If you include trust in public roots, then It is virtually
>>>
>>impossible to
>>
>>>guarantee and check that there are not any CAs with name collisions
>>>anywhere.
>>>
>>>If the PKI "database" is just a set of otherwise isolated parts each
>>>of them hanging on one trusted root without cross certs amongs the
>>
>>parts,
>>
>>>then
>>>the situation is rather simple, i.e. you have different PKIs, if not,
>>
>>what
>>
>>>do you propose?
>>>
>>>The problem to me seems what you should assume when you find two keys
>>>attributes to the same CA name?
>>>probably whene you have a crosscert pair each key certifying the
>>
>>other?
>>
>>>>As writer of validation code, we must close every possible weaknes
>>>
>>for
>>
>>>an error, miconfiguration or attack.
>>>
>>>When you write a piece of software, It may be hard to predict in what
>>>context that software will be running. You can't say that this code is
>>>only for use in aninfrastructure with CAs without name collisions,
>>
>>unless
>>
>>>the code have some means of detecting such environment and refuse to
>>>operate in it. This is not the case however.
>>>
>>>Are you saying that in the presence of two CA certs with same name
>>
>>having
>>
>>>a different key, one general should
>>>first assume that they belong to different entities, and only if one
>>
>>finds
>>
>>>a cross certificate pair of
>>>one signing the other key and vice versa, you may conclude that you
>>
>>have
>>
>>>the same entity so you look for
>>>CRLs signed by *the same* CA but the other key.
>>>
>>>
>>>>The other aspect is complexity. Use of indirect CRLs without any
>>>
>>>limitations may lead to infinitely complex path validation where every
>>
>>new
>>
>>>path introduce more CRL paths and where each new CRL path introduce
>>
>>new
>>
>>>CRL paths which introduce new CRL paths etc.......  Denial of service
>>>attacks through complex paths isn't faar away.
>>>
>>>I don't understand why you say this here. What make this more
>>
>>difficult, a
>>
>>>requirement that CAs are unique or
>>>the contrary? Welcome in the real world. :-)
>>>
>>
>>
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2NXUrK037338; Tue, 2 Nov 2004 15:33:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2NXUNS037337; Tue, 2 Nov 2004 15:33:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2NXRXP037310 for <[e-mail]>; Tue, 2 Nov 2004 15:33:29 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA2NXTAU002011 for <[e-mail]>; Tue, 2 Nov 2004 18:33:29 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 2 Nov 2004 18:33:24 -0500
Message-ID: <008601c4c134$5c0bbdb0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

The scope of this thread and the proposed algorithm is limited to when you
have certification path for a certificate and a CRL which is signed using a
different key, how you find and match the certification path for the CRL.

This applies regardless of the end certificate you are validating: be it a
normal user whose signature is being validated on an e-mail, a time stamp
authority or an OCSP Responder.

The only special case for OCSP Responder when it does not apply is when the
Responder certificate has no-check, obviating the need for CRL.  Same goes
when the Responder is a trust anchor.

Note: Also, in all cases, when the revocation status is checked using an
OCSP Responder and not the CRL, this is not applicable.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Tuesday, November 02, 2004 8:14 AM
To: [e-mail]
Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting



Santosh,

thanks for your replies,

see one more question regarding OCSP in-line.

On Tue, Nov 02, 2004 at 06:14:16AM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> See responses in-line.
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Tuesday, November 02, 2004 4:30 AM
> To: [e-mail]
> Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> (snip)
>
> Shouldn't OCSP have a special treatment on that respect ? 
> [Certification path for any check is subject to this be it, end 
> entity, CRL signer, OCSP response signer)

This is where I'm confused.

OCSP defines three way to access the validity of a responder certificate.

If the OCSP certificate is the CA itself I do not see any problem. I
understand OCSP insists on the certificate to be the same as the CA anyway,
so there is no DN related problem.

If the OCSP certificate is a delegated one, it has to be signed by the CA
certificate itself. So again, no ambiguity, but I though a special case
would still be needed as the path will be one "step" too long otherwise. Or
maybe the same rules as indirect CRLs can be applied ?

(And if the OCSP certificate is "directly" trusted, I guess that X509
validation rules no do apply anyway...)

Sincerely,

--
Julien Stern

>  
> 
> Sincerely,
> 
> --
> Julien Stern
> 
> On Sat, Oct 30, 2004 at 03:59:23PM +0100, Stefan Santesson wrote:
> > 
> > Peter,
> > 
> > I assume that this encapsulates the issue:
> > <snip>
> > > Are you saying that in the presence of two CA certs with same name
> > having
> > > a different key, one general should
> > > first assume that they belong to different entities, and only if 
> > > one
> > finds
> > > a cross certificate pair of
> > > one signing the other key and vice versa, you may conclude that 
> > > you
> > have
> > > the same entity so you look for
> > > CRLs signed by *the same* CA but the other key.
> > 
> > Yes and no.
> > 
> > Validation software should start with the assumption that two
> > certificates (CA or CRLissuer type), carrying the same subject name, 
> > represent different entities until it can determine that they are 
> > offspring of the same ancestors according to the algorithm proposed by 
> > Santosh.
> > 
> > This approach is much more attack resilient and reduce complexity in
> > path validation.
> > 
> > I don't see how building a local database is neither generally
> > feasible nor a valid alternative.
> > 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >  
> > > -----Original Message-----
> > > From: [e-mail]
> > [mailto:[e-mail]]
> > > On Behalf Of Peter Sylvester
> > > Sent: den 29 oktober 2004 18:06
> > > To: [e-mail]; Stefan Santesson
> > > Cc: [e-mail]
> > > Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
> > > 
> > > 
> > > >
> > > > Peter,
> > > >
> > > > I disagree. I think it is very important to cover for the case
> > > > where
> > 2
> > > CAs may have the same name.
> > > >
> > > 
> > > I am not against having someone to provide a specification how to
> > > construct a local database and a way to detect such a situation 
> > > inside the
> > potato
> > > of cross certificates connected CA suppended by trust hooks.
> > > 
> > > > In troducing indirect CRLs means that we introduce possible 
> > > > attack
> > > vectors and it is our responsibility to create rules that makes
> > > vulnerabilities as unlikely as possible, even in bad implementations
> > (80%+
> > > of all vulnerabilities are miconfiguration problems).
> > > >
> > > > If you include trust in public roots, then It is virtually
> > impossible to
> > > guarantee and check that there are not any CAs with name 
> > > collisions
> > > anywhere.
> > > 
> > > If the PKI "database" is just a set of otherwise isolated parts 
> > > each
> > > of them hanging on one trusted root without cross certs amongs the
> > parts,
> > > then
> > > the situation is rather simple, i.e. you have different PKIs, if
> > > not,
> > what
> > > do you propose?
> > > 
> > > The problem to me seems what you should assume when you find two
> > > keys attributes to the same CA name? probably whene you have a 
> > > crosscert pair each key certifying the
> > other?
> > > 
> > > > As writer of validation code, we must close every possible 
> > > > weaknes
> > for
> > > an error, miconfiguration or attack.
> > > 
> > > When you write a piece of software, It may be hard to predict in
> > > what context that software will be running. You can't say that this 
> > > code is only for use in aninfrastructure with CAs without name 
> > > collisions,
> > unless
> > > the code have some means of detecting such environment and refuse 
> > > to
> > > operate in it. This is not the case however.
> > > >
> > > 
> > > Are you saying that in the presence of two CA certs with same name
> > having
> > > a different key, one general should
> > > first assume that they belong to different entities, and only if 
> > > one
> > finds
> > > a cross certificate pair of
> > > one signing the other key and vice versa, you may conclude that 
> > > you
> > have
> > > the same entity so you look for
> > > CRLs signed by *the same* CA but the other key.
> > > 
> > > > The other aspect is complexity. Use of indirect CRLs without any
> > > limitations may lead to infinitely complex path validation where
> > > every
> > new
> > > path introduce more CRL paths and where each new CRL path 
> > > introduce
> > new
> > > CRL paths which introduce new CRL paths etc.......  Denial of
> > > service attacks through complex paths isn't faar away.
> > > 
> > > I don't understand why you say this here. What make this more
> > difficult, a
> > > requirement that CAs are unique or
> > > the contrary? Welcome in the real world. :-)
> > > 
> > 
> > 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2EfReK047638; Tue, 2 Nov 2004 06:41:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2EfR4u047632; Tue, 2 Nov 2004 06:41:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2EfP9e047580 for <[e-mail]>; Tue, 2 Nov 2004 06:41:26 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA2EfDD19092; Tue, 2 Nov 2004 15:41:13 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 2 Nov 2004 15:41:14 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA2EfD722424; Tue, 2 Nov 2004 15:41:13 +0100 (MET)
Date: Tue, 2 Nov 2004 15:41:13 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Yes and no.
> 
> Validation software should start with the assumption that two
> certificates (CA or CRLissuer type), carrying the same subject name,
> represent different entities until it can determine that they are
> offspring of the same ancestors according to the algorithm proposed by
> Santosh.

I am not sure what you say "(CA or CRLissuer type)": 
Does this include the case that two CA keys are certified by
the same third entity, i.e. the fact having two certs from
one CA for the "same entity"? 

I think that indeed assuming different entities is robust and does
not create more new problems.  

> 
> This approach is much more attack resilient and reduce complexity in
> path validation.
> 
> I don't see how building a local database is neither generally feasible
> nor a valid alternative.

I don't meant a permanent storage, just the data structure that is used
to hold some "indexed" heap of certs,allowing a minimal number
of signature tests., i.e. issuer/serial may point to several certs in
this heap. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2DEYVf022030; Tue, 2 Nov 2004 05:14:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2DEYdm022029; Tue, 2 Nov 2004 05:14:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2DEX7t021960 for <[e-mail]>; Tue, 2 Nov 2004 05:14:33 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 7D1F441D51 for <[e-mail]>; Tue,  2 Nov 2004 14:14:25 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 48FAB440C5 for <[e-mail]>; Tue,  2 Nov 2004 14:14:53 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24426-02 for <[e-mail]>; Tue, 2 Nov 2004 14:14:49 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 6A9D1440AE for <[e-mail]>; Tue,  2 Nov 2004 14:14:49 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue,  2 Nov 2004 14:14:22 +0100
From: "Julien Stern" <[e-mail]>
Date: Tue, 2 Nov 2004 14:14:22 +0100
To: [e-mail]
Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <007f01c4c0cd$1a5281e0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <007f01c4c0cd$1a5281e0$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

thanks for your replies,

see one more question regarding OCSP in-line.

On Tue, Nov 02, 2004 at 06:14:16AM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> See responses in-line.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Julien Stern
> Sent: Tuesday, November 02, 2004 4:30 AM
> To: [e-mail]
> Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> (snip)
>
> Shouldn't OCSP have a special treatment on that respect ?
> [Certification path for any check is subject to this be it, end entity, CRL
> signer, OCSP response signer)

This is where I'm confused.

OCSP defines three way to access the validity of a responder
certificate.

If the OCSP certificate is the CA itself I do not see any problem.
I understand OCSP insists on the certificate to be the same as the CA
anyway, so there is no DN related problem.

If the OCSP certificate is a delegated one, it has to be signed by the
CA certificate itself. So again, no ambiguity, but I though a special
case would still be needed as the path will be one "step" too long
otherwise. Or maybe the same rules as indirect CRLs can be applied ?

(And if the OCSP certificate is "directly" trusted, I guess that X509
validation rules no do apply anyway...)

Sincerely,

--
Julien Stern

>  
> 
> Sincerely,
> 
> --
> Julien Stern
> 
> On Sat, Oct 30, 2004 at 03:59:23PM +0100, Stefan Santesson wrote:
> > 
> > Peter,
> > 
> > I assume that this encapsulates the issue:
> > <snip>
> > > Are you saying that in the presence of two CA certs with same name
> > having
> > > a different key, one general should
> > > first assume that they belong to different entities, and only if one
> > finds
> > > a cross certificate pair of
> > > one signing the other key and vice versa, you may conclude that you
> > have
> > > the same entity so you look for
> > > CRLs signed by *the same* CA but the other key.
> > 
> > Yes and no.
> > 
> > Validation software should start with the assumption that two 
> > certificates (CA or CRLissuer type), carrying the same subject name, 
> > represent different entities until it can determine that they are 
> > offspring of the same ancestors according to the algorithm proposed by 
> > Santosh.
> > 
> > This approach is much more attack resilient and reduce complexity in 
> > path validation.
> > 
> > I don't see how building a local database is neither generally 
> > feasible nor a valid alternative.
> > 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >  
> > > -----Original Message-----
> > > From: [e-mail]
> > [mailto:[e-mail]]
> > > On Behalf Of Peter Sylvester
> > > Sent: den 29 oktober 2004 18:06
> > > To: [e-mail]; Stefan Santesson
> > > Cc: [e-mail]
> > > Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
> > > 
> > > 
> > > >
> > > > Peter,
> > > >
> > > > I disagree. I think it is very important to cover for the case 
> > > > where
> > 2
> > > CAs may have the same name.
> > > >
> > > 
> > > I am not against having someone to provide a specification how to 
> > > construct a local database and a way to detect such a situation 
> > > inside the
> > potato
> > > of cross certificates connected CA suppended by trust hooks.
> > > 
> > > > In troducing indirect CRLs means that we introduce possible attack
> > > vectors and it is our responsibility to create rules that makes 
> > > vulnerabilities as unlikely as possible, even in bad implementations
> > (80%+
> > > of all vulnerabilities are miconfiguration problems).
> > > >
> > > > If you include trust in public roots, then It is virtually
> > impossible to
> > > guarantee and check that there are not any CAs with name collisions 
> > > anywhere.
> > > 
> > > If the PKI "database" is just a set of otherwise isolated parts each 
> > > of them hanging on one trusted root without cross certs amongs the
> > parts,
> > > then
> > > the situation is rather simple, i.e. you have different PKIs, if 
> > > not,
> > what
> > > do you propose?
> > > 
> > > The problem to me seems what you should assume when you find two 
> > > keys attributes to the same CA name? probably whene you have a 
> > > crosscert pair each key certifying the
> > other?
> > > 
> > > > As writer of validation code, we must close every possible weaknes
> > for
> > > an error, miconfiguration or attack.
> > > 
> > > When you write a piece of software, It may be hard to predict in 
> > > what context that software will be running. You can't say that this 
> > > code is only for use in aninfrastructure with CAs without name 
> > > collisions,
> > unless
> > > the code have some means of detecting such environment and refuse to 
> > > operate in it. This is not the case however.
> > > >
> > > 
> > > Are you saying that in the presence of two CA certs with same name
> > having
> > > a different key, one general should
> > > first assume that they belong to different entities, and only if one
> > finds
> > > a cross certificate pair of
> > > one signing the other key and vice versa, you may conclude that you
> > have
> > > the same entity so you look for
> > > CRLs signed by *the same* CA but the other key.
> > > 
> > > > The other aspect is complexity. Use of indirect CRLs without any
> > > limitations may lead to infinitely complex path validation where 
> > > every
> > new
> > > path introduce more CRL paths and where each new CRL path introduce
> > new
> > > CRL paths which introduce new CRL paths etc.......  Denial of 
> > > service attacks through complex paths isn't faar away.
> > > 
> > > I don't understand why you say this here. What make this more
> > difficult, a
> > > requirement that CAs are unique or
> > > the contrary? Welcome in the real world. :-)
> > > 
> > 
> > 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2BELF5071121; Tue, 2 Nov 2004 03:14:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2BELBN071120; Tue, 2 Nov 2004 03:14:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2BEKHl071105 for <[e-mail]>; Tue, 2 Nov 2004 03:14:20 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA2BELAU001312 for <[e-mail]>; Tue, 2 Nov 2004 06:14:21 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 2 Nov 2004 06:14:16 -0500
Message-ID: <007f01c4c0cd$1a5281e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA2BEKHl071109
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

See responses in-line.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Tuesday, November 02, 2004 4:30 AM
To: [e-mail]
Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting



Greetings,

the more posting about this issue and the more confused I am :) I understood
that

1) Ideally, a DN should uniquely identify a entity.

2) If two Trust Anchors with the same DN are different entities, there is a
major (configuration) problem.

[RP should never do this]

3) If two certificates have the same DN but represent different entitities
that is a mistake (or an attack). That must be detected.

[This is not necessarily a mistake or attack.  This can be due to
distributed nature of cross certified CAs and PKIs]

4) The way to detect it is to check for the ancestors according to the
algorithm proposed by Santosh.

[Right]

Is that correct ?
[Yes]
Is there a consensus on this ?
[Postings I have seen support this]
Shouldn't OCSP have a special treatment on that respect ?
[Certification path for any check is subject to this be it, end entity, CRL
signer, OCSP response signer)
 

Sincerely,

--
Julien Stern

On Sat, Oct 30, 2004 at 03:59:23PM +0100, Stefan Santesson wrote:
> 
> Peter,
> 
> I assume that this encapsulates the issue:
> <snip>
> > Are you saying that in the presence of two CA certs with same name
> having
> > a different key, one general should
> > first assume that they belong to different entities, and only if one
> finds
> > a cross certificate pair of
> > one signing the other key and vice versa, you may conclude that you
> have
> > the same entity so you look for
> > CRLs signed by *the same* CA but the other key.
> 
> Yes and no.
> 
> Validation software should start with the assumption that two 
> certificates (CA or CRLissuer type), carrying the same subject name, 
> represent different entities until it can determine that they are 
> offspring of the same ancestors according to the algorithm proposed by 
> Santosh.
> 
> This approach is much more attack resilient and reduce complexity in 
> path validation.
> 
> I don't see how building a local database is neither generally 
> feasible nor a valid alternative.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On Behalf Of Peter Sylvester
> > Sent: den 29 oktober 2004 18:06
> > To: [e-mail]; Stefan Santesson
> > Cc: [e-mail]
> > Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > >
> > > Peter,
> > >
> > > I disagree. I think it is very important to cover for the case 
> > > where
> 2
> > CAs may have the same name.
> > >
> > 
> > I am not against having someone to provide a specification how to 
> > construct a local database and a way to detect such a situation 
> > inside the
> potato
> > of cross certificates connected CA suppended by trust hooks.
> > 
> > > In troducing indirect CRLs means that we introduce possible attack
> > vectors and it is our responsibility to create rules that makes 
> > vulnerabilities as unlikely as possible, even in bad implementations
> (80%+
> > of all vulnerabilities are miconfiguration problems).
> > >
> > > If you include trust in public roots, then It is virtually
> impossible to
> > guarantee and check that there are not any CAs with name collisions 
> > anywhere.
> > 
> > If the PKI "database" is just a set of otherwise isolated parts each 
> > of them hanging on one trusted root without cross certs amongs the
> parts,
> > then
> > the situation is rather simple, i.e. you have different PKIs, if 
> > not,
> what
> > do you propose?
> > 
> > The problem to me seems what you should assume when you find two 
> > keys attributes to the same CA name? probably whene you have a 
> > crosscert pair each key certifying the
> other?
> > 
> > > As writer of validation code, we must close every possible weaknes
> for
> > an error, miconfiguration or attack.
> > 
> > When you write a piece of software, It may be hard to predict in 
> > what context that software will be running. You can't say that this 
> > code is only for use in aninfrastructure with CAs without name 
> > collisions,
> unless
> > the code have some means of detecting such environment and refuse to 
> > operate in it. This is not the case however.
> > >
> > 
> > Are you saying that in the presence of two CA certs with same name
> having
> > a different key, one general should
> > first assume that they belong to different entities, and only if one
> finds
> > a cross certificate pair of
> > one signing the other key and vice versa, you may conclude that you
> have
> > the same entity so you look for
> > CRLs signed by *the same* CA but the other key.
> > 
> > > The other aspect is complexity. Use of indirect CRLs without any
> > limitations may lead to infinitely complex path validation where 
> > every
> new
> > path introduce more CRL paths and where each new CRL path introduce
> new
> > CRL paths which introduce new CRL paths etc.......  Denial of 
> > service attacks through complex paths isn't faar away.
> > 
> > I don't understand why you say this here. What make this more
> difficult, a
> > requirement that CAs are unique or
> > the contrary? Welcome in the real world. :-)
> > 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2ALe1S038047; Tue, 2 Nov 2004 02:21:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2ALeMq038046; Tue, 2 Nov 2004 02:21:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2ALdmN037913 for <[e-mail]>; Tue, 2 Nov 2004 02:21:39 -0800 (PST) (envelope-from [e-mail])
Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id iA2ALNKp017766; Tue, 2 Nov 2004 11:21:24 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 2 Nov 2004 11:21:21 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Thread-Index: AcTAv261u+ee99RpT4CCK/HTKRJH5QAA9OAA
From: "Alberti Antoine" <[e-mail]>
To: "Julien Stern" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 02 Nov 2004 10:22:40.0578 (UTC) FILETIME=[E1FD4A20:01C4C0C5]
X-Scanned-By: MIMEDefang 2.38
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA2ALemN038040
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>From my point of view, identification has always been the main of PKI. Nothing guarantees that a DN is unique, as I have never seen the unique global LDAP directory, or the root of such a directory, managed like OIDs. And this is the reason why all these extensions and complicated fuzzy identifiers were born, making PKI so complicated that it takes centuries to be understood and spread out as a global solution.
Then, what should be done when a PKI server finds 2 entities with the same DN, coming from 2 different trusted sources ? Should we sew the one that comes last ? Or refuse anything that comes from any of the entities until they both agree on different DNs ? (And how is one supposed to warn these entities that they can not be used on a global scale when they have a local structure that works ?) Or make the products manage data models with no structure at all, in order to be compliant with any case that may be occur ? Or try to find a solution for uniquely identifying entities and certificates, making all these problems disappear in a few dozen years, which is almost nothing regarding PKI deployment ?
Regards.
AA.

> -----Message d'origine-----
> De : [e-mail]
> [mailto:[e-mail]]De la part de Julien Stern
> Envoyé : mardi 2 novembre 2004 10:30
> À : [e-mail]
> Objet : Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> Greetings,
> 
> the more posting about this issue and the more confused I am :)
> I understood that
> 
> 1) Ideally, a DN should uniquely identify a entity.
> 
> 2) If two Trust Anchors with the same DN are different entities, there
> is a major (configuration) problem.
> 
> 3) If two certificates have the same DN but represent 
> different entitities
> that is a mistake (or an attack). That must be detected.
> 
> 4) The way to detect it is to check for the ancestors according to the
> algorithm proposed by Santosh.
> 
> Is that correct ?
> Is there a consensus on this ?
> Shouldn't OCSP have a special treatment on that respect ?
> 
> Sincerely,
> 
> --
> Julien Stern
> 
> On Sat, Oct 30, 2004 at 03:59:23PM +0100, Stefan Santesson wrote:
> > 
> > Peter,
> > 
> > I assume that this encapsulates the issue:
> > <snip>
> > > Are you saying that in the presence of two CA certs with same name
> > having
> > > a different key, one general should
> > > first assume that they belong to different entities, and 
> only if one
> > finds
> > > a cross certificate pair of
> > > one signing the other key and vice versa, you may 
> conclude that you
> > have
> > > the same entity so you look for
> > > CRLs signed by *the same* CA but the other key.
> > 
> > Yes and no.
> > 
> > Validation software should start with the assumption that two
> > certificates (CA or CRLissuer type), carrying the same subject name,
> > represent different entities until it can determine that they are
> > offspring of the same ancestors according to the algorithm 
> proposed by
> > Santosh.
> > 
> > This approach is much more attack resilient and reduce complexity in
> > path validation. 
> > 
> > I don't see how building a local database is neither 
> generally feasible
> > nor a valid alternative.
> > 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >  
> > > -----Original Message-----
> > > From: [e-mail]
> > [mailto:[e-mail]]
> > > On Behalf Of Peter Sylvester
> > > Sent: den 29 oktober 2004 18:06
> > > To: [e-mail]; Stefan Santesson
> > > Cc: [e-mail]
> > > Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
> > > 
> > > 
> > > >
> > > > Peter,
> > > >
> > > > I disagree. I think it is very important to cover for 
> the case where
> > 2
> > > CAs may have the same name.
> > > >
> > > 
> > > I am not against having someone to provide a specification how to
> > > construct
> > > a local database and a way to detect such a situation inside the
> > potato
> > > of cross certificates connected CA suppended by trust hooks.
> > > 
> > > > In troducing indirect CRLs means that we introduce 
> possible attack
> > > vectors and it is our responsibility to create rules that makes
> > > vulnerabilities as unlikely as possible, even in bad 
> implementations
> > (80%+
> > > of all vulnerabilities are miconfiguration problems).
> > > >
> > > > If you include trust in public roots, then It is virtually
> > impossible to
> > > guarantee and check that there are not any CAs with name 
> collisions
> > > anywhere.
> > > 
> > > If the PKI "database" is just a set of otherwise isolated 
> parts each
> > > of them hanging on one trusted root without cross certs amongs the
> > parts,
> > > then
> > > the situation is rather simple, i.e. you have different 
> PKIs, if not,
> > what
> > > do you propose?
> > > 
> > > The problem to me seems what you should assume when you 
> find two keys
> > > attributes to the same CA name?
> > > probably whene you have a crosscert pair each key certifying the
> > other?
> > > 
> > > > As writer of validation code, we must close every 
> possible weaknes
> > for
> > > an error, miconfiguration or attack.
> > > 
> > > When you write a piece of software, It may be hard to 
> predict in what
> > > context that software will be running. You can't say that 
> this code is
> > > only for use in aninfrastructure with CAs without name collisions,
> > unless
> > > the code have some means of detecting such environment 
> and refuse to
> > > operate in it. This is not the case however.
> > > >
> > > 
> > > Are you saying that in the presence of two CA certs with same name
> > having
> > > a different key, one general should
> > > first assume that they belong to different entities, and 
> only if one
> > finds
> > > a cross certificate pair of
> > > one signing the other key and vice versa, you may 
> conclude that you
> > have
> > > the same entity so you look for
> > > CRLs signed by *the same* CA but the other key.
> > > 
> > > > The other aspect is complexity. Use of indirect CRLs without any
> > > limitations may lead to infinitely complex path 
> validation where every
> > new
> > > path introduce more CRL paths and where each new CRL path 
> introduce
> > new
> > > CRL paths which introduce new CRL paths etc.......  
> Denial of service
> > > attacks through complex paths isn't faar away.
> > > 
> > > I don't understand why you say this here. What make this more
> > difficult, a
> > > requirement that CAs are unique or
> > > the contrary? Welcome in the real world. :-)
> > > 
> > 
> > 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2A8CDY028724; Tue, 2 Nov 2004 02:08:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2A8CqP028723; Tue, 2 Nov 2004 02:08:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2A8BFd028710 for <[e-mail]>; Tue, 2 Nov 2004 02:08:11 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 0B62762E2F for <[e-mail]>; Tue,  2 Nov 2004 11:08:11 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id A093E440C5 for <[e-mail]>; Tue,  2 Nov 2004 11:08:38 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23413-09 for <[e-mail]>; Tue, 2 Nov 2004 11:08:35 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 235EF440AE for <[e-mail]>; Tue,  2 Nov 2004 11:08:35 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue,  2 Nov 2004 11:08:07 +0100
From: "Julien Stern" <[e-mail]>
Date: Tue, 2 Nov 2004 11:08:07 +0100
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]> <000101c4bee6$3b9f7d00$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000101c4bee6$3b9f7d00$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings,

I have a number of comments on the draft:

1) Section 1.2.3 states that the OCSP responder should reply with an
"unauthorized" reply code when it is not capable of replying
authoritatively.

I believe there are two problems with that:

First, it overrides the semantic of the "unauthorized" error code,
which originally means that the client is not, well, authorized :)
to access to service.

Second, because OCSP replies are unsigned, it allows for an easy
man-in-the-middle attack.


2) Regarding Nonces

This profile is obviously nonceless. No caching server in its sane
mind would ever implement nonce. So why imply that a server could
possibly send one ? If this is to cope with the case of a client that
does not know whether the server supports nonce or not, the extensive
discussions that occured on the list regarding this issue are not
solved. If this RFC is published as is, it will practically destroy
all nonced implementations of OCSP, because the client has no way to
know whether is it talking with a nonce-supporting server or not.
Hence, nonced implementations becomes useless, because replay attacks
always become possible, unless the client is pre-configured to know
that the server is indeed using nonces.
Several proposals have been suggested, including my proposal of forcing
nonce-supporting server to NOT include the nextUpdate field, as well as
other proposals using extra extensions.


3) Wouldn't it be a good idea to also specify the way a client should check
the OCSP responder signature ? RFC2560 authorizes three ways
i) CA itself
ii) directy signed by CA with the Im-an-ocsp-responder extension
iii) anything goes :)

How about restricting the lightweight profile to i) and ii),
or clarify iii) ?

Sincerely,

--
Julien Stern



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA29U8Tb001490; Tue, 2 Nov 2004 01:30:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA29U8LP001489; Tue, 2 Nov 2004 01:30:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA29U7CQ001399 for <[e-mail]>; Tue, 2 Nov 2004 01:30:07 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 610DC62D7B for <[e-mail]>; Tue,  2 Nov 2004 10:29:55 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id E1090440C5 for <[e-mail]>; Tue,  2 Nov 2004 10:30:22 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23413-05 for <[e-mail]>; Tue, 2 Nov 2004 10:30:18 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id 824EA440AE for <[e-mail]>; Tue,  2 Nov 2004 10:30:18 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue,  2 Nov 2004 10:29:50 +0100
From: "Julien Stern" <[e-mail]>
Date: Tue, 2 Nov 2004 10:29:50 +0100
To: [e-mail]
Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings,

the more posting about this issue and the more confused I am :)
I understood that

1) Ideally, a DN should uniquely identify a entity.

2) If two Trust Anchors with the same DN are different entities, there
is a major (configuration) problem.

3) If two certificates have the same DN but represent different entitities
that is a mistake (or an attack). That must be detected.

4) The way to detect it is to check for the ancestors according to the
algorithm proposed by Santosh.

Is that correct ?
Is there a consensus on this ?
Shouldn't OCSP have a special treatment on that respect ?

Sincerely,

--
Julien Stern

On Sat, Oct 30, 2004 at 03:59:23PM +0100, Stefan Santesson wrote:
> 
> Peter,
> 
> I assume that this encapsulates the issue:
> <snip>
> > Are you saying that in the presence of two CA certs with same name
> having
> > a different key, one general should
> > first assume that they belong to different entities, and only if one
> finds
> > a cross certificate pair of
> > one signing the other key and vice versa, you may conclude that you
> have
> > the same entity so you look for
> > CRLs signed by *the same* CA but the other key.
> 
> Yes and no.
> 
> Validation software should start with the assumption that two
> certificates (CA or CRLissuer type), carrying the same subject name,
> represent different entities until it can determine that they are
> offspring of the same ancestors according to the algorithm proposed by
> Santosh.
> 
> This approach is much more attack resilient and reduce complexity in
> path validation. 
> 
> I don't see how building a local database is neither generally feasible
> nor a valid alternative.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On Behalf Of Peter Sylvester
> > Sent: den 29 oktober 2004 18:06
> > To: [e-mail]; Stefan Santesson
> > Cc: [e-mail]
> > Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
> > 
> > 
> > >
> > > Peter,
> > >
> > > I disagree. I think it is very important to cover for the case where
> 2
> > CAs may have the same name.
> > >
> > 
> > I am not against having someone to provide a specification how to
> > construct
> > a local database and a way to detect such a situation inside the
> potato
> > of cross certificates connected CA suppended by trust hooks.
> > 
> > > In troducing indirect CRLs means that we introduce possible attack
> > vectors and it is our responsibility to create rules that makes
> > vulnerabilities as unlikely as possible, even in bad implementations
> (80%+
> > of all vulnerabilities are miconfiguration problems).
> > >
> > > If you include trust in public roots, then It is virtually
> impossible to
> > guarantee and check that there are not any CAs with name collisions
> > anywhere.
> > 
> > If the PKI "database" is just a set of otherwise isolated parts each
> > of them hanging on one trusted root without cross certs amongs the
> parts,
> > then
> > the situation is rather simple, i.e. you have different PKIs, if not,
> what
> > do you propose?
> > 
> > The problem to me seems what you should assume when you find two keys
> > attributes to the same CA name?
> > probably whene you have a crosscert pair each key certifying the
> other?
> > 
> > > As writer of validation code, we must close every possible weaknes
> for
> > an error, miconfiguration or attack.
> > 
> > When you write a piece of software, It may be hard to predict in what
> > context that software will be running. You can't say that this code is
> > only for use in aninfrastructure with CAs without name collisions,
> unless
> > the code have some means of detecting such environment and refuse to
> > operate in it. This is not the case however.
> > >
> > 
> > Are you saying that in the presence of two CA certs with same name
> having
> > a different key, one general should
> > first assume that they belong to different entities, and only if one
> finds
> > a cross certificate pair of
> > one signing the other key and vice versa, you may conclude that you
> have
> > the same entity so you look for
> > CRLs signed by *the same* CA but the other key.
> > 
> > > The other aspect is complexity. Use of indirect CRLs without any
> > limitations may lead to infinitely complex path validation where every
> new
> > path introduce more CRL paths and where each new CRL path introduce
> new
> > CRL paths which introduce new CRL paths etc.......  Denial of service
> > attacks through complex paths isn't faar away.
> > 
> > I don't understand why you say this here. What make this more
> difficult, a
> > requirement that CAs are unique or
> > the contrary? Welcome in the real world. :-)
> > 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA29NqNQ096929; Tue, 2 Nov 2004 01:23:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA29Nqtf096928; Tue, 2 Nov 2004 01:23:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpd.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA29NocP096892 for <[e-mail]>; Tue, 2 Nov 2004 01:23:51 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id B5327341B7; Tue,  2 Nov 2004 22:23:48 +1300 (NZDT)
Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24424-01; Tue,  2 Nov 2004 22:23:48 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 36DC63413A; Tue,  2 Nov 2004 22:23:47 +1300 (NZDT)
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 8C22137748; Tue,  2 Nov 2004 22:23:47 +1300 (NZDT)
Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1COutO-0008Qt-00; Tue, 02 Nov 2004 22:23:54 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: R: R: R: Digital Signature Implementation Interoperability
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <E1COutO-0008Qt-00@medusa01>
Date: Tue, 02 Nov 2004 22:23:54 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Santoni Adriano" <[e-mail]> writes:

>I do not know which italian Certification Authority is using your crypto
>toolkit, to date.

It's not one, it's (based on different email addresses that I've had requests
from) between half a dozen and a dozen organisations (since it's OSS and this
was over a period of years it's not really possible to accurately track all
this, and in particular recent versions have been modified to handle various
peculiarities so I'd be getting less mail about them).

>- there is definitely no "requirement to use Unicode (BMPString) for an
>attribute ";

All I can do is respond/react to requests as I get them.  To use this
particular one as an example:

  I have implemented all properties for testing Cryptlib and only one of this
  I could not have set easily, the <Description> property (2.5.4.13)
  [...]
  The property must be set with BMPString type...

(The problem here was that cryptlib used PrintableString since BMPString was
 unnecessary, so they had to change it to force use of a BMPString).

All I can report (for this and all the other stuff) is what users come to me
to ask for, and that's a long list of some variation of "Italian
regulations/guidelines require that we do X", where X is usually something
really strange.  Maybe it's just that all of them are doing strange things
that they've created themselves rather than being required to by any
specification, or are having to accomodate buggy software, but it does seem a
bit unusual that there's so much of that then concentrated in Italy, since
you'd expect to see it evenly distributed over all countries.  I'm not able to
speculate on the cause of this phenomenon, but something is *really* promoting
OSS crypto use there :-).

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA28WrPL061529; Tue, 2 Nov 2004 00:32:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA28WrjY061528; Tue, 2 Nov 2004 00:32:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from siamail.sia.it (mail.sia.it [193.203.230.133] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA28Wqpa061487 for <[e-mail]>; Tue, 2 Nov 2004 00:32:52 -0800 (PST) (envelope-from [e-mail])
Received: from ntexch06.office.corp.sia.it ([10.2.101.30]) by siamail.sia.it (8.12.11/8.12.11) with ESMTP id iA28WlEo007690; Tue, 2 Nov 2004 09:32:48 +0100 (MET)
Received: from NTEXCH00.office.corp.sia.it ([10.2.101.129]) by ntexch06.office.corp.sia.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Nov 2004 09:32:47 +0100
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
Content-class: urn:content-classes:message
Subject: R: R: R: Digital Signature Implementation Interoperability
Date: Tue, 2 Nov 2004 09:32:46 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: R: Digital Signature Implementation Interoperability
Importance: normal
Thread-Index: AcS9tCgavttNdAxrSAWEF/wlIInmeQAA2f5A
From: "Santoni Adriano" <[e-mail]>
To: "pgut001" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 02 Nov 2004 08:32:47.0092 (UTC) FILETIME=[87F72B40:01C4C0B6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA28Wrpa061522
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I do not know which italian Certification Authority is using your crypto toolkit, to date.  In any case, I can very confidently deny that the italian interoperability rules mandates such weird things as you describe below.  

In particular:
- there is definitely no "requirement to use Unicode (BMPString) for an attribute "; it is permitted to do so in the description RDN; and description has a DirectoryString syntax (from x.520), so it can take on a BMPString if needed; of course this proviso is now obsolete; in the next future we will use UTF8String....
- there is no proviso for "funny custom handling of basicConstraints";
- there is no proviso for "an altName consisting of a multi-line LDAP URL that points back ..."; it may have been someone's broken implementation;
- "multiple SignerInfos per SignedData " is a perfectly standard and useful PKCS#7 feature; only toy applications "will only display the first one".

Adriano

-----Messaggio originale-----
Da: pgut001 [mailto:[e-mail]] 
Inviato: venerdì 29 ottobre 2004 14.38
A: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Oggetto: Re: R: R: Digital Signature Implementation Interoperability


"Santoni Adriano" <[e-mail]> writes:

>I am not aware of any particular complication. Would you please
>describe the most unusual things that you had to comply with?

Oh dear, where should I even start?  This is just off the top of my head, but the list includes wierd custom attributes in DNs, some funny custom handling of basicConstraints (can't remember the exact details, but Italian users required a code patch to alter the behaviour from the standard one), a requirement to use Unicode (BMPString) for an attribute that, for some unfathomable reason, everyone else claims is an IA5String (that's the one where I joked that the people who created the requirement owned Microsoft stock, because seeing that string type would at the time crash Netscape browsers), an altName consisting of a multi-line LDAP URL that points back to the certificate that contains the altName (God knows what the semantics for being able to "process" that extension would be, I guess you'd be required to go into an endless loop), use of message formats that are *only* valid according to the somewhat more lax terminology in PKCS #7 but invalid under CMS, use of multiple SignerInfos per SignedData (many apps will only display the first one), really weird stuff involving timestamps that I've stopped trying to figure out (I've had to resort to "You've got the source code, feel free to implement what you need" because it just isn't worth the effort of accomodating a one-off special-case like this), and then about two or three times as many more strange bits and pieces that I'd have to go back through mail archives to dig up (every now and then I'll get some piece of mail that starts with "The Italian digital signature requirements require..." and my reaction will be "Oh no, what's it going to be this time?").  Now having said that I have to say that I *love* the Italian requirements, as the author of an open-source toolkit, I get to play in a market that no standard commercial toolkit (or at least none that hasn't had extensive customisation) can touch :-).

(I'm not just being facetious about this, I've heard this from a number of  users, they have to go with an OSS toolkit whose behaviour they can modify  themselves because no unmodified off-the-shelf one will work.  So in a way  this is strongly promoting OSS, although it probably wasn't intended that  way).

>The only "unusual thing" that I am aware of, regarding italian
>interoperability rules, is that we currently use commonName's 
>containing unusual stuff formatted in an unusual way. But that is not 
>against any standard.

Nor is putting an MPEG of a cat in the DN, but it hardly promotes interoperability, which is what you were talking about in your original message.

Peter.

*******************Internet Email Confidentiality Footer*******************


Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati.
Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 



Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of ACTALIS S.p.A. Besides, The contents of this message shall be understood as neither given nor endorsed by ACTALIS S.p.A.. 
ACTALIS S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.





Received: from 208.184.76.43 ([211.173.135.120]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA28M1C7053386; Tue, 2 Nov 2004 00:22:03 -0800 (PST) (envelope-from [e-mail])
Received: from  [129.45.120.128] by 208.184.76.43 with ESMTP id 68935628 for <[e-mail]>; Tue, 02 Nov 2004 02:22:59 -0600
Message-ID: <g$2-$z-k0$w32o-pe-$[e-mail]0>
From: "Administrator" <[e-mail]>
To: [e-mail]
Subject: ADV:      Staff Announcement
Date: Tue, 02 Nov 04 02:22:59 GMT
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="_61119_.B."

This is a multi-part message in MIME format.

--_61119_.B.
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Nonprofit Organizations: Members and Staff

You Must Respond By 5 P.M. Wednesday, November 3, 2004.

Through a special arrangement, Avtech Direct is offering a limited
allotment of BRAND NEW, top of-the-line, name-brand desktop computers
at more than 50% off MSRP to all Nonprofit Members and Staff
who respond to this message before 5 P.M., Wednesday, November 3, 2004

All desktop computers are brand-new packed in their original boxes,
and come with a full manufacturer's warranty plus
a 100% satisfaction guarantee.

These professional grade Desktops are fully equipped with 2005
next generation technology, making these the best performing
computers money can buy.

Avtech Direct is offering these feature rich, top performing
Desktops with the latest technology at an amazing price
to all who call:

    1-800-795-8466 by 5 P.M. Wednesday, November 3, 2004

The fast and powerful AT-3200 series Desktop features: 

      * IBM Processor for amazing speed and performance
      * 128MB DDR RAM,  -- Upgradeable to 1024
      * 20 GB UDMA Hard Drive, -- Upgradeable to 80 GB
      * 52X CD-Rom Drive, -- Upgradeable to DVD/CDRW
      * Next Generation 2005 Technology
      * Premium video and sound -- For enhanced colors and graphics
      * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0
      * Soft Touch Keyboard and scroll mouse
      * Internet Ready
      * Network Ready
      * 1 Year parts and labor warranty
      * Priority customer service and tech support

MSRP $499 ........................................ Your Cost $227

How to qualify:

  1. You must be a Member, Staff or Associate of a Nonprofit.
  2. All desktop computers will be available on a
     first come first serve basis.
  3. You must call 1-800-795-8466 by 5 P.M. Wednesday, November 3, 2004.
     and we will hold the desktops you request on will call. 
  4. You are not obligated in any way.
  5. 100% Satisfaction Guaranteed.
  6. Ask for Department C.
   
   
Call Avtech Direct
1-800-795-8466 before 5 P.M. Wednesday, November 3, 2004


Visit our website at http://www.avtechdirect-nonprofits.com


If you wish to unsubscribe from this list, please go to
http://www.computeradvice.org/unsubscribelink.asp



Avtech Direct
22647 Ventura Blvd. Suite 374
Woodland Hills, CA 91364
--_61119_.B.--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA27jlMA026742; Mon, 1 Nov 2004 23:45:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA27jlCv026738; Mon, 1 Nov 2004 23:45:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from siamail.sia.it (mail.sia.it [193.203.230.133] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA27jePX026562 for <[e-mail]>; Mon, 1 Nov 2004 23:45:40 -0800 (PST) (envelope-from [e-mail])
Received: from ntexch06.office.corp.sia.it ([10.2.101.30]) by siamail.sia.it (8.12.11/8.12.11) with ESMTP id iA27jWZd006995; Tue, 2 Nov 2004 08:45:32 +0100 (MET)
Received: from NTEXCH00.office.corp.sia.it ([10.2.101.129]) by ntexch06.office.corp.sia.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Nov 2004 08:45:32 +0100
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
Content-class: urn:content-classes:message
Subject: R: Digital Signature Implementation Interoperability
Date: Tue, 2 Nov 2004 08:45:32 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Digital Signature Implementation Interoperability
Importance: normal
Thread-Index: AcS98VTls6I4KJBkS4a/QrnTmc2HOACuz3ow
From: "Santoni Adriano" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "Mike Henry" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 02 Nov 2004 07:45:32.0506 (UTC) FILETIME=[EE6BABA0:01C4C0AF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA27jfPX026661
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

I was referring to PKCS#7 SignedData envelopes (Rfc 2315, not CMS), with both single and multiple signatures, EE-, CA- and timestamping certificates, and CRLs; they all have to obey the profiles set out in an official guideline issued by a governmental agency called CNIPA (www.cnipa.gov.it). 

The profile can be viewed at http://www.cnipa.gov.it/site/_contentfiles/00127900/127910_CR%2024_2000.pdf (italian language). That profile was issued in year 2000 so it is now quite old; in fact it is being revised, and a new guideline is due to be issued shortly. The few unusual things (like the internal structure of the commonName and description RDNs) will be dropped in favor of an ETSI-based qualified certificate profile. But our old Y2000 profile, nice or ugly as you may find it, helped a lot to promote digital signature interoperability, an asset you will hardly find in most other countries.

An account of the results of our interoperability testing is published on http://www.assocertificatori.org/interoperabilita.htm.

By the way, we also test each other's timestamp tokens, according to RFC 3161, and to date we observe a high degree of interoperability in that field as well.

Adriano


-----Messaggio originale-----
Da: Anders Rundgren [mailto:[e-mail]] 
Inviato: venerdì 29 ottobre 2004 21.56
A: [e-mail]; Santoni Adriano
Cc: Mike Henry
Oggetto: Re: Digital Signature Implementation Interoperability


Adriano,

I assume that your coordination is restricted to S/MIME and toolkits? Because if we talk web-signatures not even the word interoperability apply, as there by definition is nothing to be interoperable with.

This is a bit sad as web-sign is much more important thing than being able to sign in a dull, off-line e-mail client environment.

All e-governments over the globe buy truly proprietary stuff as they apparently have not realized that they actually are in the same boat.

Anders Rundgren
PKI technologist etc.

----- Original Message ----- 
From: "Santoni Adriano" <[e-mail]>
To: "Mike Henry" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, October 29, 2004 08:47
Subject: R: Digital Signature Implementation Interoperability



>One of the explicitly stated premises of this group is that "among all 
>the COTS digital signature implementations there are no two that 
>interoperate out of the box". Interoperate here is to be understood as 
>- a user of product A generates a digital signature over some data and 
>transmits it to a recipient using product B who is able to verify the 
>signature.(A and B not the same product.)

Among the several CSP's accredited in Italy (by www.cnipa.gov.it) under our national legislation on digital signatures and associated regulations, there is close to 100% interoperability as far as PKCS#7 signatures (RFC 2315) and associated qualified certificates are concerned.

I can state that, because I am the coordinator of the permanent working group that organizes the periodic cross-testing. The different digital signature products subject to our periodic interoperability testing are at least 6.

Rgds,
  Adriano

Adriano Santoni
Actalis S.p.A. (www.actalis.it)
Milano, IT


-----Messaggio originale-----
Da: [e-mail] [mailto:[e-mail]] Per conto di Mike Henry
Inviato: mercoledì 27 ottobre 2004 17.05
A: [e-mail]
Oggetto: Digital Signature Implementation Interoperability



All.

I  recently attended a session of a working group whose charter is to "develop a strategy to address interoperability and implementation challenges with digital signatures" across a large government enterprise

One of the explicitly stated premises of this group is that "among all the COTS digital signature implementations there are no two that interoperate out of the box". Interoperate here is to be understood as - a user of product A generates a digital signature over some data and transmits it to a recipient using product B who is able to verify the signature.(A and B not the same
product.)
This premise is frequently briefed to senior decision makers as an absolute "there are none". It is not briefed as, for example, "there are problems in interoperability one has to choose carefully" or some other more nuanced estimate of the situation.

This premise is an important one to this working group. If it were demonstrably not so in one or two  instances it would probably just require more precision in choice of words. If it were not so in a sufficient number of instances (i.e product A interoperates with B, C, D and another set E, F, G all interoperate quite nicely among themselves ......) then it would likely have a significant impact on planning and future decisions.

I was troubled by the fact that there was no evidence offered in support of this defining premise other than  reference to undocumented phone survey results to some sample of digital signature product vendors. It may very well be the case that as of Oct 2004 the implementations of the standards have not resulted in any interoperability, but I was not convinced by the evidence presented.

I would very much appreciate hearing from anyone who has some independent testing results or practical experience on this topic. If this is not an appropriate topic for this list then an e-mail response would be fine.

Mike Henry

Michael C. Henry
Senior Systems Engineer
MTC
In Support of USMC PK-E Initiative Office





*******************Internet Email Confidentiality Footer*******************


Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.



Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of ACTALIS S.p.A. Besides, The contents of this message shall be understood as neither given nor endorsed by ACTALIS S.p.A.. ACTALIS S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.



*******************Internet Email Confidentiality Footer*******************


Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati.
Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 



Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of ACTALIS S.p.A. Besides, The contents of this message shall be understood as neither given nor endorsed by ACTALIS S.p.A.. 
ACTALIS S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA27LKf5011457; Mon, 1 Nov 2004 23:21:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA27LKXs011453; Mon, 1 Nov 2004 23:21:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mh.pvt.cz (spider.pvt.cz [194.149.101.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA27LIYq011325 for <[e-mail]>; Mon, 1 Nov 2004 23:21:19 -0800 (PST) (envelope-from [e-mail])
Received: from PHAWEX01.pvt.cz (phaw01.pvt.cz [172.17.21.20]) by mh.pvt.cz (8.11.2/8.11.2) with ESMTP id iA27L6P13420 for <[e-mail]>; Tue, 2 Nov 2004 08:21:07 +0100
Received: from brnw00.pvt.cz ([172.17.41.10]) by PHAWEX01.pvt.cz with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Nov 2004 08:20:05 +0100
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C0AB.C2F09255"
Subject: Attribute certificate request message format
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Tue, 2 Nov 2004 08:15:41 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Attribute certificate request message format
Thread-Index: AcTAq8KJv54rLch4SBSJedCra90UMQ==
From: "Pinkava Jaroslav" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 02 Nov 2004 07:20:05.0286 (UTC) FILETIME=[60206460:01C4C0AC]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C0AB.C2F09255
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Hi,=20

=20

I am looking for the fate of  draft

draft-ietf-pkix-acrmf-01.txt.

=20

We are preparing an attribute authority and the status of standards

for attribute certificate request message format is unclear.

I understand - draft expired, but don=B4t exists some another solution?

=20

         Thank You in advance

=20

                                  Jaroslav

=20

=20

=20

=20

=20

Ing. Jaroslav Pinkava, CSc.,=20

Security Consultant

telefon: [phone]

mobil:  [phone]

fax:    [phone]

e-mail: [e-mail]

http://crypto-world.info/=20

=20

PVT  a.s.,=20

Veve=F8=ED 102=20

602 00, Brno

www.pvt.cz <file:///\\www.pvt.cz\>=20

Czech Republic


------_=_NextPart_001_01C4C0AB.C2F09255
Content-Type: text/html;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-2">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.StylZprvyElektronickPoty17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DCS link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi, </span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I am looking for the fate of =
=A0draft</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>draft-ietf-pkix-acrmf-01.txt.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We are preparing an attribute authority and the =
status of
standards</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>for attribute certificate request message format is =
unclear.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I understand - draft expired, but don=B4t exists some =
another solution?</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0 Thank You in =
advance</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Jaroslav</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>Ing.
Jaroslav Pinkava, CSc., </span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>Security
Consultant</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>telefon:
[phone]</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>mobil:&nbsp;
[phone]</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>fax:&nbsp;&nbsp;&nbsp;
[phone]</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>e-mail:
[e-mail]</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'><a
href=3D"http://crypto-world.info/">http://crypto-world.info/</a> =
</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><font size=3D3 =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>PVT&nbsp;
a.s., </span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>Veve=F8=ED
102 </span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>602 00,
Brno</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'><a
href=3D"file:///\\www.pvt.cz\">www.pvt.cz</a></span></font></i></p>

<p class=3DMsoNormal><i><font size=3D1 face=3D"Times New Roman"><span
style=3D'font-size:8.0pt;font-style:italic'>Czech =
Republic</span></font></i></p>

</div>

</body>

</html>

------_=_NextPart_001_01C4C0AB.C2F09255--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1LSZqT022000; Mon, 1 Nov 2004 13:28:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1LSZwi021999; Mon, 1 Nov 2004 13:28:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1LSW6N021937 for <[e-mail]>; Mon, 1 Nov 2004 13:28:34 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA1LSZph005138 for <[e-mail]>; Mon, 1 Nov 2004 16:28:35 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt
Date: Mon, 1 Nov 2004 16:28:35 -0500
Message-ID: <007401c4c059$bed503b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA1LSZ6N021992
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ryan,

This sounds fine.

If the purpose is to give the hint as to when check back, I suggest
renaming.

-----Original Message-----
From: Ryan Hurst [mailto:[e-mail]] 
Sent: Monday, November 01, 2004 4:18 PM
To: Santosh Chokhani; [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


No problem, as for the nextPublish extension I was noodling on what I could
do to make the text more clear, what if we say:

     Support for this extension is optional. This extension indicates the
     earliest time at which the server will be issuing new information about
     the status of the certificate. If present it can be used by the relying
     party to determine when it is acceptable to begin attempts for new 
     revocation information.  
 
     The time specified in the nextPublish extension SHOULD be before 
     the time specified in the nextUpdate field. 


So if nextUpdate indicates "The time at or before which newer information
will be available about the status of the certificate" then nextPublish
indicates "The time at or after newer information will be available about
the status of the certificate". Having both ends of the timeline allows for
the client to make intelligent decisions related to how to update its local
cache.

I am not apposed to re-naming the extension but am more concerned about the
description being clear. Does this new text alleviate your concerns?

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Monday, November 01, 2004 10:26 AM
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


Ryan,

Thanks.

I had some further thought on the nextPublish extension.  If this is purely
a hint for the client when to poll back and it does not further reduce the
revocation replay window, some other neutral name such as suggestedPollBack
may be more appropriate.

If this field can be used by the client to reduce the replay window, that
should be explained in terms of how to use this time in addition to polling
back.

-----Original Message-----
From: Ryan Hurst [mailto:[e-mail]] 
Sent: Monday, November 01, 2004 1:15 PM
To: Santosh Chokhani; [e-mail]
Cc: Deacon, Alex
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


Santosh - Thanks for your comments we will address these in the next
revision of the document...

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Saturday, October 30, 2004 6:09 PM
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


Alex,

I have a small number of comments on the revised draft.

1.  Section 1.2.2, There does not appear to be security benefit to the
Responder certificate validity period covering the response window.
Actually, this could cause deadlocks.  This requirement should be deleted.
May be the requirement should be for the responder to send its latest
certificate which contains the appropriate verification public key and whose
notBefore is at or before the current time.

2. Section 5.1, typo, replace "who's signature has" with "whose signature
has been"

3.  Section 5.1, type replace i.e. 48 hours with e.g., 48 hours.

4.  Appendix A, It is not clear how this extension differs from nextUpdate.
Is this something like "when new responses will be produced"?  Some further
clarification is required. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On
Behalf Of [e-mail]
Sent: Thursday, October 28, 2004 11:06 AM
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Public-Key Infrastructure
(X.509) Working Group of the IETF.

	Title		: Lightweight OCSP Profile  for High Volume
Environments
	Author(s)	: A. Deacon,  R. Hurst
	Filename	:
draft-ietf-pkix-lightweight-ocsp-profile-01.txt
	Pages		: 21
	Date		: 2004-10-27
	
This specification defines a profile of the Online Certificate
   Status Protocol (OCSP) that addresses the scalability issues
   inherent when using OCSP in large scale (high volume) PKI
   environments and/or PKI environments that require a lightweight
   solution to minimize bandwidth and client side processing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-pro
file
-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-ietf-pkix-lightweight-ocsp-profile-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE
/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.








Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1LIHkx016339; Mon, 1 Nov 2004 13:18:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1LIHWP016338; Mon, 1 Nov 2004 13:18:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1LIHnI016328 for <[e-mail]>; Mon, 1 Nov 2004 13:18:17 -0800 (PST) (envelope-from [e-mail])
Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 13:18:31 -0800
Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 13:17:56 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 13:18:30 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1110); Mon, 1 Nov 2004 13:18:26 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt
Date: Mon, 1 Nov 2004 13:18:19 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt
thread-index: AcTATwK3gGaotlrjRKOgw9qWTPYqxQACCvyQ
From: "Ryan Hurst" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 01 Nov 2004 21:18:26.0986 (UTC) FILETIME=[53DCF0A0:01C4C058]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA1LIHnI016331
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

No problem, as for the nextPublish extension I was noodling on what I
could do to make the text more clear, what if we say:

     Support for this extension is optional. This extension indicates
the
     earliest time at which the server will be issuing new information
about
     the status of the certificate. If present it can be used by the
relying
     party to determine when it is acceptable to begin attempts for new 
     revocation information.  
 
     The time specified in the nextPublish extension SHOULD be before 
     the time specified in the nextUpdate field. 


So if nextUpdate indicates "The time at or before which newer
information will be available about the status of the certificate" then
nextPublish indicates "The time at or after newer information will be
available about the status of the certificate". Having both ends of the
timeline allows for the client to make intelligent decisions related to
how to update its local cache.

I am not apposed to re-naming the extension but am more concerned about
the description being clear. Does this new text alleviate your concerns?

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Monday, November 01, 2004 10:26 AM
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


Ryan,

Thanks.

I had some further thought on the nextPublish extension.  If this is
purely
a hint for the client when to poll back and it does not further reduce
the
revocation replay window, some other neutral name such as
suggestedPollBack
may be more appropriate.

If this field can be used by the client to reduce the replay window,
that
should be explained in terms of how to use this time in addition to
polling
back.

-----Original Message-----
From: Ryan Hurst [mailto:[e-mail]] 
Sent: Monday, November 01, 2004 1:15 PM
To: Santosh Chokhani; [e-mail]
Cc: Deacon, Alex
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


Santosh - Thanks for your comments we will address these in the next
revision of the document...

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Saturday, October 30, 2004 6:09 PM
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


Alex,

I have a small number of comments on the revised draft.

1.  Section 1.2.2, There does not appear to be security benefit to the
Responder certificate validity period covering the response window.
Actually, this could cause deadlocks.  This requirement should be
deleted.
May be the requirement should be for the responder to send its latest
certificate which contains the appropriate verification public key and
whose
notBefore is at or before the current time.

2. Section 5.1, typo, replace "who's signature has" with "whose
signature
has been"

3.  Section 5.1, type replace i.e. 48 hours with e.g., 48 hours.

4.  Appendix A, It is not clear how this extension differs from
nextUpdate.
Is this something like "when new responses will be produced"?  Some
further
clarification is required. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On
Behalf Of [e-mail]
Sent: Thursday, October 28, 2004 11:06 AM
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Public-Key Infrastructure
(X.509) Working Group of the IETF.

	Title		: Lightweight OCSP Profile  for High Volume
Environments
	Author(s)	: A. Deacon,  R. Hurst
	Filename	:
draft-ietf-pkix-lightweight-ocsp-profile-01.txt
	Pages		: 21
	Date		: 2004-10-27
	
This specification defines a profile of the Online Certificate
   Status Protocol (OCSP) that addresses the scalability issues
   inherent when using OCSP in large scale (high volume) PKI
   environments and/or PKI environments that require a lightweight
   solution to minimize bandwidth and client side processing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-pro
file
-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of
the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type
"cd internet-drafts" and then
	"get draft-ietf-pkix-lightweight-ocsp-profile-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE
/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1IQaDk030333; Mon, 1 Nov 2004 10:26:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1IQaDd030332; Mon, 1 Nov 2004 10:26:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1IQaq8030248 for <[e-mail]>; Mon, 1 Nov 2004 10:26:36 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA1IQWph026528 for <[e-mail]>; Mon, 1 Nov 2004 13:26:32 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt
Date: Mon, 1 Nov 2004 13:26:29 -0500
Message-ID: <001f01c4c040$4fec1b50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA1IQaq8030327
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ryan,

Thanks.

I had some further thought on the nextPublish extension.  If this is purely
a hint for the client when to poll back and it does not further reduce the
revocation replay window, some other neutral name such as suggestedPollBack
may be more appropriate.

If this field can be used by the client to reduce the replay window, that
should be explained in terms of how to use this time in addition to polling
back.

-----Original Message-----
From: Ryan Hurst [mailto:[e-mail]] 
Sent: Monday, November 01, 2004 1:15 PM
To: Santosh Chokhani; [e-mail]
Cc: Deacon, Alex
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


Santosh - Thanks for your comments we will address these in the next
revision of the document...

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Saturday, October 30, 2004 6:09 PM
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


Alex,

I have a small number of comments on the revised draft.

1.  Section 1.2.2, There does not appear to be security benefit to the
Responder certificate validity period covering the response window.
Actually, this could cause deadlocks.  This requirement should be deleted.
May be the requirement should be for the responder to send its latest
certificate which contains the appropriate verification public key and whose
notBefore is at or before the current time.

2. Section 5.1, typo, replace "who's signature has" with "whose signature
has been"

3.  Section 5.1, type replace i.e. 48 hours with e.g., 48 hours.

4.  Appendix A, It is not clear how this extension differs from nextUpdate.
Is this something like "when new responses will be produced"?  Some further
clarification is required. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On
Behalf Of [e-mail]
Sent: Thursday, October 28, 2004 11:06 AM
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Public-Key Infrastructure
(X.509) Working Group of the IETF.

	Title		: Lightweight OCSP Profile  for High Volume
Environments
	Author(s)	: A. Deacon,  R. Hurst
	Filename	:
draft-ietf-pkix-lightweight-ocsp-profile-01.txt
	Pages		: 21
	Date		: 2004-10-27
	
This specification defines a profile of the Online Certificate
   Status Protocol (OCSP) that addresses the scalability issues
   inherent when using OCSP in large scale (high volume) PKI
   environments and/or PKI environments that require a lightweight
   solution to minimize bandwidth and client side processing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-pro
file
-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-ietf-pkix-lightweight-ocsp-profile-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE
/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1IFRdg024880; Mon, 1 Nov 2004 10:15:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1IFRik024878; Mon, 1 Nov 2004 10:15:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1IFMUR024815 for <[e-mail]>; Mon, 1 Nov 2004 10:15:22 -0800 (PST) (envelope-from [e-mail])
Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 10:15:20 -0800
Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 10:15:09 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Nov 2004 10:15:20 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1110); Mon, 1 Nov 2004 10:15:15 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt
Date: Mon, 1 Nov 2004 10:15:16 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt
thread-index: AcS/ANfmduMmfJB3TeuFshgZJ1/6aQBPc7Sg
From: "Ryan Hurst" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
Cc: "Deacon, Alex" <[e-mail]>
X-OriginalArrivalTime: 01 Nov 2004 18:15:15.0569 (UTC) FILETIME=[BC77CE10:01C4C03E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA1IFMUR024850
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh - Thanks for your comments we will address these in the next
revision of the document...

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Saturday, October 30, 2004 6:09 PM
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


Alex,

I have a small number of comments on the revised draft.

1.  Section 1.2.2, There does not appear to be security benefit to the
Responder certificate validity period covering the response window.
Actually, this could cause deadlocks.  This requirement should be
deleted.
May be the requirement should be for the responder to send its latest
certificate which contains the appropriate verification public key and
whose
notBefore is at or before the current time.

2. Section 5.1, typo, replace "who's signature has" with "whose
signature
has been"

3.  Section 5.1, type replace i.e. 48 hours with e.g., 48 hours.

4.  Appendix A, It is not clear how this extension differs from
nextUpdate.
Is this something like "when new responses will be produced"?  Some
further
clarification is required. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On
Behalf Of [e-mail]
Sent: Thursday, October 28, 2004 11:06 AM
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Public-Key Infrastructure
(X.509) Working Group of the IETF.

	Title		: Lightweight OCSP Profile  for High Volume
Environments
	Author(s)	: A. Deacon,  R. Hurst
	Filename	:
draft-ietf-pkix-lightweight-ocsp-profile-01.txt
	Pages		: 21
	Date		: 2004-10-27
	
This specification defines a profile of the Online Certificate
   Status Protocol (OCSP) that addresses the scalability issues
   inherent when using OCSP in large scale (high volume) PKI
   environments and/or PKI environments that require a lightweight
   solution to minimize bandwidth and client side processing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-pro
file
-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of
the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type
"cd internet-drafts" and then
	"get draft-ietf-pkix-lightweight-ocsp-profile-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE
/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.