RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt

["Santosh Chokhani" <[e-mail]>]

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-profile
-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 iA142Qf8082573; Sun, 31 Oct 2004 20:02:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA142Qbx082572; Sun, 31 Oct 2004 20:02:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from xiaoyq.net ([210.83.7.219]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA142OXT082537 for <[e-mail]>; Sun, 31 Oct 2004 20:02:25 -0800 (PST) (envelope-from [e-mail])
Date: Mon, 01 Nov 2004 12:02:26 +0800
To: "Ietf-pkix" <[e-mail]>
From: "Tytso" <[e-mail]>
Subject: Re: Thank you!
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------vkjmackbxrrvgdgklsap"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----------vkjmackbxrrvgdgklsap
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:)

<br>
</body></html>

----------vkjmackbxrrvgdgklsap
Content-Type: application/octet-stream; name="price.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="price.cpl"



----------vkjmackbxrrvgdgklsap--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9V19CYK017305; Sat, 30 Oct 2004 18:09:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9V19CK3017304; Sat, 30 Oct 2004 18:09:12 -0700 (PDT)
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 i9V197iF017286 for <[e-mail]>; Sat, 30 Oct 2004 18:09:11 -0700 (PDT) (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 i9V19DUt012733 for <[e-mail]>; Sat, 30 Oct 2004 21:09:13 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt
Date: Sat, 30 Oct 2004 21:09:06 -0400
Message-ID: <000101c4bee6$3b9f7d00$[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 i9V19CiF017299
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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-profile
-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 i9UExP3k094816; Sat, 30 Oct 2004 07:59:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9UExP9F094815; Sat, 30 Oct 2004 07:59:25 -0700 (PDT)
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 i9UExLjP094779 for <[e-mail]>; Sat, 30 Oct 2004 07:59:22 -0700 (PDT) (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); Sat, 30 Oct 2004 15:59:17 +0100
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: Sat, 30 Oct 2004 15:59:23 +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: AcS93WfCgpZCUqy0Rs20ErZ2feWy2AAsnFtQ
From: "Stefan Santesson" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 30 Oct 2004 14:59:17.0730 (UTC) FILETIME=[076C7420:01C4BE91]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9UExMjP094808
Sender: [e-mail]
Precedence: 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,

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 i9UCCKOg038269; Sat, 30 Oct 2004 05:12:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9UCCKM5038268; Sat, 30 Oct 2004 05:12:20 -0700 (PDT)
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 i9UCCJYC038208 for <[e-mail]>; Sat, 30 Oct 2004 05:12:20 -0700 (PDT) (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 i9UCCEUt005584 for <[e-mail]>; Sat, 30 Oct 2004 08:12:14 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Sat, 30 Oct 2004 08:12:08 -0400
Message-ID: <003501c4be79$b0f36d40$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9UCCKYC038262
Sender: [e-mail]
Precedence: 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,

I do not understand what you wrote very well.

The basic point is that if you have two CA certificates with different keys
in the directory and as a relying party you obtain those two certificates,
both may be valid for a certificate or CRL certification path.  If one is
used for the certificate certification path and the other one is used for
the CRL certification path, you determine if they are the same CA, by
checking all the ancestors.  That is a simple  way to describe the path
matching algorithm.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Sylvester
Sent: Friday, October 29, 2004 12:06 PM
To: [e-mail]; [e-mail]
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 i9TJuGHN070083; Fri, 29 Oct 2004 12:56:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TJuGnv070082; Fri, 29 Oct 2004 12:56:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-1-sn4.m-sp.skanova.net (av7-1-sn4.m-sp.skanova.net [81.228.10.110]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TJuFfe070002 for <[e-mail]>; Fri, 29 Oct 2004 12:56:16 -0700 (PDT) (envelope-from [e-mail])
Received: by av7-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 650BD381FE; Fri, 29 Oct 2004 21:56:02 +0200 (CEST)
Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av7-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 54B0E37E69; Fri, 29 Oct 2004 21:56:02 +0200 (CEST)
Received: from rsaedoscymkikx (t12o913p68.telia.com [213.64.28.188]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id A449437E4F; Fri, 29 Oct 2004 21:55:59 +0200 (CEST)
Message-ID: <008901c4bdf1$50362430$80c5a8c0@rsaedoscymkikx>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Santoni Adriano" <[e-mail]>
Cc: "Mike Henry" <[e-mail]>
References: <[e-mail]>
Subject: Re: Digital Signature Implementation Interoperability
Date: Fri, 29 Oct 2004 21:55:57 +0200
MIME-Version: 1.0
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.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>

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.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TJb8uq065378; Fri, 29 Oct 2004 12:37:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TJb8tE065377; Fri, 29 Oct 2004 12:37:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TJb7IO065370 for <[e-mail]>; Fri, 29 Oct 2004 12:37:08 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28875; Fri, 29 Oct 2004 15:37:09 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldap-crl-schema-03.txt
Date: Fri, 29 Oct 2004 15:37:09 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Internet X.509 Public Key Infrastructure LDAP Schema for X.509 CRLs
	Author(s)	: D. Chadwick, M. Sahalayev
	Filename	: draft-ietf-pkix-ldap-crl-schema-03.txt
	Pages		: 0
	Date		: 2004-10-29
	
This document describes an LDAP schema for X.509 CRLs. Each CRL is broken down into a set of attribute types. These attributes can then be stored in a CRL entry, or set of entries. Object classes are defined for these CRL entries. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-03.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-ldap-crl-schema-03.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-ldap-crl-schema-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ldap-crl-schema-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ldap-crl-schema-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TG6PUm045889; Fri, 29 Oct 2004 09:06:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TG6PWg045888; Fri, 29 Oct 2004 09:06:25 -0700 (PDT)
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 i9TG6N6Q045765 for <[e-mail]>; Fri, 29 Oct 2004 09:06:24 -0700 (PDT) (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 i9TG6ED19635; Fri, 29 Oct 2004 18:06:14 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 29 Oct 2004 18:06:14 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9TG6DE09949; Fri, 29 Oct 2004 18:06:13 +0200 (MEST)
Date: Fri, 29 Oct 2004 18:06:13 +0200 (MEST)
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,
>  
> 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 i9TD5CkA034288; Fri, 29 Oct 2004 06:05:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TD5Ca6034287; Fri, 29 Oct 2004 06:05:12 -0700 (PDT)
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 i9TD5BHS034249 for <[e-mail]>; Fri, 29 Oct 2004 06:05:11 -0700 (PDT) (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); Fri, 29 Oct 2004 14:05:05 +0100
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: SV: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Fri, 29 Oct 2004 14:05:09 +0100
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: AcS9rFkJFmvPHcBQSBGEC0dsS85PVAAB6JFT
From: "Stefan Santesson" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 29 Oct 2004 13:05:05.0897 (UTC) FILETIME=[E8FFF590:01C4BDB7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9TD5CHS034282
Sender: [e-mail]
Precedence: 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,
 
I disagree. I think it is very important to cover for the case where 2 CAs may have the same name.
 
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. 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.
 
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.
 
 
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

________________________________

Från: [e-mail] genom Peter Sylvester
Skickat: fr 10/29/2004 12:30
Till: [e-mail]; [e-mail]
Kopia: [e-mail]
Ämne: Re: Briefing on CRL Path for IETF PKIX WG Meeting




>
> Peter.Sylvester> At least you would probably agree that a CA cannot
> Peter.Sylvester> sign another CA having the same DN (because this
> Peter.Sylvester> would be considered as a self signed cert).

>
> I agree in a way, but the parenthesis makes me wonder if you're not
> mixing things up.  There is a difference between self-issued CA
> certificates (where two CA certificates have the same subject) and a
> self-signed CA certificate (where the public key in one certificate
> can be used to verify the signature in that same certificate).  The
> former is typically present as soon as you do a CA certificate roll-
> over.

I was indeed not correctly using the term  'self signed'. The
common point is something where the subject and isseur DN are the same
and a path determination logic concludes that it is the same
entity.

> But I agree that two different CAs (two different organizations, in
> other words) "cannot" have the same DN.  I write "cannot", because
> it's still technically possible, and whenever that happens, one can
> only expect a small appocalypse.

The message was that I don't think that it is worth
to provide PKI path determination technology that can work
with two CA entities having the same name.

If two PKIs join and have such a situation, then there may
also be a incompatibility in the certification policies. Or,
if not, maybe an inconsistency in 'joint' policy since the joint
naming schemme allows for that.

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 i9TCcDUB029694; Fri, 29 Oct 2004 05:38:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TCcDUT029693; Fri, 29 Oct 2004 05:38:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpc.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TCc7u9029657 for <[e-mail]>; Fri, 29 Oct 2004 05:38:08 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 7570B345DA; Sat, 30 Oct 2004 01:38:02 +1300 (NZDT)
Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27730-10; Sat, 30 Oct 2004 01:38:02 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 5CC26345D6; Sat, 30 Oct 2004 01:38:01 +1300 (NZDT)
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BC4203774D; Sat, 30 Oct 2004 01:38:01 +1300 (NZDT)
Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CNW1C-00041u-00; Sat, 30 Oct 2004 01:38:10 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: R: R: Digital Signature Implementation Interoperability
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <E1CNW1C-00041u-00@medusa01>
Date: Sat, 30 Oct 2004 01:38:10 +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 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.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TAUUu7005687; Fri, 29 Oct 2004 03:30:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TAUUXJ005685; Fri, 29 Oct 2004 03:30:30 -0700 (PDT)
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 i9TAURxP005674 for <[e-mail]>; Fri, 29 Oct 2004 03:30:29 -0700 (PDT) (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 i9TAURD14729; Fri, 29 Oct 2004 12:30:27 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 29 Oct 2004 12:30:27 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9TAUQ808873; Fri, 29 Oct 2004 12:30:26 +0200 (MEST)
Date: Fri, 29 Oct 2004 12:30:26 +0200 (MEST)
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>

> 
> Peter.Sylvester> At least you would probably agree that a CA cannot
> Peter.Sylvester> sign another CA having the same DN (because this
> Peter.Sylvester> would be considered as a self signed cert).

> 
> I agree in a way, but the parenthesis makes me wonder if you're not
> mixing things up.  There is a difference between self-issued CA
> certificates (where two CA certificates have the same subject) and a
> self-signed CA certificate (where the public key in one certificate
> can be used to verify the signature in that same certificate).  The
> former is typically present as soon as you do a CA certificate roll-
> over.

I was indeed not correctly using the term  'self signed'. The
common point is something where the subject and isseur DN are the same
and a path determination logic concludes that it is the same
entity. 

> But I agree that two different CAs (two different organizations, in
> other words) "cannot" have the same DN.  I write "cannot", because
> it's still technically possible, and whenever that happens, one can
> only expect a small appocalypse.

The message was that I don't think that it is worth
to provide PKI path determination technology that can work
with two CA entities having the same name. 

If two PKIs join and have such a situation, then there may
also be a incompatibility in the certification policies. Or,
if not, maybe an inconsistency in 'joint' policy since the joint
naming schemme allows for that. 

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 i9T8jbAM083268; Fri, 29 Oct 2004 01:45:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9T8jboA083267; Fri, 29 Oct 2004 01:45:37 -0700 (PDT)
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 i9T8jao3083259 for <[e-mail]>; Fri, 29 Oct 2004 01:45:36 -0700 (PDT) (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 i9T8jRp5002536; Fri, 29 Oct 2004 10:45:27 +0200 (METDST)
Received: from NTEXCH00.office.corp.sia.it ([10.2.101.129]) by ntexch06.office.corp.sia.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Oct 2004 10:45:27 +0200
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
Content-class: urn:content-classes:message
Subject: R: R: Digital Signature Implementation Interoperability
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Fri, 29 Oct 2004 10:45:26 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: Digital Signature Implementation Interoperability
Importance: normal
Thread-Index: AcS9jF9ou0uX8IjuSOGC/BPTTvuH3AABflzA
From: "Santoni Adriano" <[e-mail]>
To: "pgut001" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 29 Oct 2004 08:45:27.0052 (UTC) FILETIME=[A348DCC0:01C4BD93]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9T8jbo3083262
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> there are quite a number of extremely... unusual things in there that are used nowhere else on earth.  So this isn't really a valid sample

I am not aware of any particular complication. Would you please describe the most unusual things that you had to comply with?

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.

Adriano

-----Messaggio originale-----
Da: pgut001 [mailto:[e-mail]] 
Inviato: venerdì 29 ottobre 2004 9.53
A: [e-mail]; [e-mail]
Cc: [e-mail]
Oggetto: Re: R: Digital Signature Implementation Interoperability


"Santoni Adriano" <[e-mail]> writes:

>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.

As the provider of a security toolkit that has to comply with the Italian requirements, I should add that the it's a helluva lot of work to get that interoperability.  It's caused me more problems than any other signature law/requirements because there are quite a number of extremely... unusual things in there that are used nowhere else on earth.  So this isn't really a valid sample, it's like the joke about portability where someone claims that their code is portable because it runs on every VAX 11/750 running 4.3BSD Tahoe that they've tried it on.

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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T7rREB073020; Fri, 29 Oct 2004 00:53:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9T7rRGo073019; Fri, 29 Oct 2004 00:53:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpb.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T7rOhY072978 for <[e-mail]>; Fri, 29 Oct 2004 00:53:26 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 24BF43453A; Fri, 29 Oct 2004 20:52:06 +1300 (NZDT)
Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00329-03; Fri, 29 Oct 2004 20:52:06 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 95D8134527; Fri, 29 Oct 2004 20:52:05 +1300 (NZDT)
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 661E33774B; Fri, 29 Oct 2004 20:53:16 +1300 (NZDT)
Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CNRZb-0003ql-00; Fri, 29 Oct 2004 20:53:23 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: R: Digital Signature Implementation Interoperability
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <E1CNRZb-0003ql-00@medusa01>
Date: Fri, 29 Oct 2004 20:53:23 +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:

>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.

As the provider of a security toolkit that has to comply with the Italian
requirements, I should add that the it's a helluva lot of work to get that
interoperability.  It's caused me more problems than any other signature
law/requirements because there are quite a number of extremely... unusual
things in there that are used nowhere else on earth.  So this isn't really a
valid sample, it's like the joke about portability where someone claims that
their code is portable because it runs on every VAX 11/750 running 4.3BSD
Tahoe that they've tried it on.

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 i9T6m8Gj058614; Thu, 28 Oct 2004 23:48:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9T6m86v058613; Thu, 28 Oct 2004 23:48:08 -0700 (PDT)
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 i9T6m4gZ058600 for <[e-mail]>; Thu, 28 Oct 2004 23:48:08 -0700 (PDT) (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 i9T6lqAF000633; Fri, 29 Oct 2004 08:47:55 +0200 (METDST)
Received: from NTEXCH00.office.corp.sia.it ([10.2.101.129]) by ntexch06.office.corp.sia.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Oct 2004 08:47:51 +0200
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
Content-class: urn:content-classes:message
Subject: R: Digital Signature Implementation Interoperability
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Fri, 29 Oct 2004 08:47:50 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Digital Signature Implementation Interoperability
Importance: normal
Thread-Index: AcS8NxoeyomDw/4fS/W0t26ibzFYrwBSu4rA
From: "Santoni Adriano" <[e-mail]>
To: "Mike Henry" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 29 Oct 2004 06:47:51.0429 (UTC) FILETIME=[35CE3B50:01C4BD83]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9T6m8gZ058607
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>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.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T2lLlM017161; Thu, 28 Oct 2004 19:47:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9T2lLQi017160; Thu, 28 Oct 2004 19:47:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9T2lCvt017128 for <[e-mail]>; Thu, 28 Oct 2004 19:47:15 -0700 (PDT) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9T2kQCE597322; Thu, 28 Oct 2004 22:46:36 -0400
Received: from d01ml062.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 i9T2kFYd267620; Thu, 28 Oct 2004 22:46:15 -0400
In-Reply-To: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Subject: Re: AW: 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: Thu, 28 Oct 2004 22:46:04 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF1|October 13, 2004) at 10/28/2004 22:46:14, Serialize complete at 10/28/2004 22:46:14
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 i9T2lGvt017150
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Thomas:

        One comment below, clarifying the meaning of a "trust anchor"

                Tom Gindin






[e-mail]
Sent by: [e-mail]
10/27/2004 08:06 AM
 
        To:     [e-mail], [e-mail]
        cc: 
        Subject:        AW: Briefing on CRL Path for IETF PKIX WG Meeting



See below 


> -----Ursprüngliche Nachricht-----
> Von: Jean-Marc Desperrier [mailto:[e-mail]]
> Gesendet: Mittwoch, 27. Oktober 2004 13:18
> An: [e-mail]
> Betreff: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> Denis Pinkas wrote:
> 
> > 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".
> 
> 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.

Jean-Marc, what do you mean by "creating two CAs with the same DN"? What 
you
mean is to "create two certificates containing the same DN". And this 
means
both certificates belong to the same CA. This is IMHO useful e. g. for key
turnover. The fraud you mentioned below is only applicable on TAs. The
naming of subordinate CAs is within the responsibility of the certificate
issuing CA(TA). In the case of TAs you will ever have the problem, that
somebody may create a certificate with the TAs DN an publish it.

[TG] This isn't the problem, since the definition of a TA is required to 
include a public key as well as a DN, even though most displays of a 
certificate within a local store of anchors skip the key.  The danger is 
that a CA (either a TA or some other CA certified by a TA) can create a 
certificate which creates a fraudulent subordinate CA with the same DN as 
an existing CA, but a key under his own control.  That's a good example of 
why some of us have been advocating the assertion of constraints on TA's. 
This sort of false delegation would still be an issue even if the RP did 
not trust any legitimate path to a given CA.

Regards

Thomas Beckmann

> 
> But that the pkix Internet profile has to envision cases 
> where it's will 
> not be possible to absolutly garantee this will never happen and 
> therefore must protect itself against the security issues 
> raised by such 
> a situation and impose more stringent rules for certification 
> paths that 
> wil properly handle even that case.
> 
> One interesting question this raises is the following :
> If we don't consider the restriction we need for pkix, what 
> would be the 
> X509 compliant way to handle the case where you have two CA 
> certificates 
> with the same DN inside separate certification path ?
> I see two possible answer :
> - This is forbidden, and one or both of the certificates should be 
> handled as invalid when a client discovers such a case.
> - They validly cover the same CA, and validation may be made using 
> either path.
> 
> What is raised here is that the second solution is not acceptable for 
> pkix, because it makes it possible for anybody who was given the 
> autority to emit a CA certificate to impersonate any other CA in the 
> hirarchy.
> Several aspects of X509 make me believe it's not really intended for 
> X509 either.
> 






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SJuD9X028741; Thu, 28 Oct 2004 12:56:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SJuDxS028740; Thu, 28 Oct 2004 12:56:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SJuCDN028734 for <[e-mail]>; Thu, 28 Oct 2004 12:56:12 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28760; Thu, 28 Oct 2004 15:56:23 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldap-ac-schema-02.txt
Date: Thu, 28 Oct 2004 15:56:23 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Internet X.509 Public Key Infrastructure LDAP Schema for X.509 Attribute Certificates
	Author(s)	: D. Chadwick, M. Sahalayev
	Filename	: draft-ietf-pkix-ldap-ac-schema-02.txt
	Pages		: 0
	Date		: 2004-10-28
	
This document describes an LDAP schema for X.509 attribute certificates (ACs). Each AC is broken down into a set of attribute types. These attributes can then be stored in an AC entry. An object class is defined for this AC entry. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-02.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-ldap-ac-schema-02.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-ldap-ac-schema-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ldap-ac-schema-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ldap-ac-schema-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SJYEoH023017; Thu, 28 Oct 2004 12:34:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SJYEOD023015; Thu, 28 Oct 2004 12:34:14 -0700 (PDT)
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 i9SJYDw2023004 for <[e-mail]>; Thu, 28 Oct 2004 12:34:14 -0700 (PDT) (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 i9SJYPHK023419 for <[e-mail]>; Thu, 28 Oct 2004 15:34:25 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Thu, 28 Oct 2004 15:34:26 -0400
Message-ID: <006c01c4bd25$226bb460$[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
In-Reply-To: <[e-mail]>
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,

Just show us how SIA (wherever you want to put it) is more efficient than
AIA for CRL signer.

-----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 i9SJXF9Q022236; Thu, 28 Oct 2004 12:33:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SJXFUK022235; Thu, 28 Oct 2004 12:33:15 -0700 (PDT)
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 i9SJXFpa022228 for <[e-mail]>; Thu, 28 Oct 2004 12:33:15 -0700 (PDT) (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 i9SJXRHK023138 for <[e-mail]>; Thu, 28 Oct 2004 15:33:27 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Thu, 28 Oct 2004 15:33:27 -0400
Message-ID: <006b01c4bd24$ff585d70$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9SJXFpa022230
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

X.509 Annex B and 3280 do describe how to deal with various CRLs.

-----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 i9SJW7xO021853; Thu, 28 Oct 2004 12:32:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SJW70B021852; Thu, 28 Oct 2004 12:32:07 -0700 (PDT)
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 i9SJW6XI021836 for <[e-mail]>; Thu, 28 Oct 2004 12:32:06 -0700 (PDT) (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 i9SJWIHK022340 for <[e-mail]>; Thu, 28 Oct 2004 15:32:18 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Thu, 28 Oct 2004 15:32:18 -0400
Message-ID: <006a01c4bd24$d62e3000$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9SJW7XI021847
Sender: [e-mail]
Precedence: 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 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.  That is
what the algorithm does.

-----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 i9SJUJWl021256; Thu, 28 Oct 2004 12:30:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SJUJeG021255; Thu, 28 Oct 2004 12:30:19 -0700 (PDT)
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 i9SJUIuq021248 for <[e-mail]>; Thu, 28 Oct 2004 12:30:19 -0700 (PDT) (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 i9SJUUHK021475 for <[e-mail]>; Thu, 28 Oct 2004 15:30:30 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Thu, 28 Oct 2004 15:30:30 -0400
Message-ID: <006701c4bd24$95d1e650$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9SJUJuq021249
Sender: [e-mail]
Precedence: 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 matching algorithm proposed checks/compares the ancestors.  This
algorithm is nothing more than formalism of something you agreed to in 2003
on this list.

-----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 i9SHqoY8095564; Thu, 28 Oct 2004 10:52:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SHqoJY095563; Thu, 28 Oct 2004 10:52:50 -0700 (PDT)
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 i9SHqnRQ095524 for <[e-mail]>; Thu, 28 Oct 2004 10:52:49 -0700 (PDT) (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 i9SHqlZv072787; Thu, 28 Oct 2004 17:52:47 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041028104429.03327040@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Thu, 28 Oct 2004 10:53:10 -0700
To: Steve Hanna <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: [pki-tc] Definitive source for abbreviations used in certificate DN's
Cc: Arshad Noor <[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>

draft-ietf-ldapbis-dn, once approved for publication,
says that short names used in LDAP DN strings are the
same short names used elsewhere in LDAP to identify
the attribute type.  BCP 64 established a registry for
those short names at IANA:
   "Object Identifiers Descriptors" in
   http://www.iana.org/assignments/ldap-parameters

I note that short names, like OIDs they refer to, should
generally not be presented to the user.  Instead, some
localized string should be presented.

Kurt

At 08:32 AM 10/28/2004, Steve Hanna wrote:

>RFC 2253 is a good source for this. However,
>there is no exhaustive list. People make up
>their own abbreviations all too often, which
>causes interoperability problems. Really,
>they should use dotted decimal notation to
>give the OID, but that's not user-friendly.
>
>Thanks,
>
>Steve
>
>Arshad Noor wrote:
>
>>Can someone please point me to a definitive source document, that defines the official abbreviations used within X.509 digital certificate DN's?   For instance, which specific document specifies that the abbreviation S must be used for State, G (or is it GN?) must be used for GivenName, SN for Surname, etc.  
>>Thank you.
>>Arshad Noor
>>StrongAuth, Inc.
>>P.S.  I have looked at ITU-T's X.520 (02/2001) document and while it shows some abbreviations (CN, S, L, T, etc.) it does not elucidate all of them.
>>
>>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/leave_workgroup.php.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFX6pr066315; Thu, 28 Oct 2004 08:33:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SFX6bc066314; Thu, 28 Oct 2004 08:33:06 -0700 (PDT)
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 i9SFX5LY066298 for <[e-mail]>; Thu, 28 Oct 2004 08:33:05 -0700 (PDT) (envelope-from [e-mail])
Received: from [127.0.0.1] (hannaxp [192.168.21.6]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VP6GRSHN; Thu, 28 Oct 2004 11:33:15 -0400
Message-ID: <[e-mail]>
Date: Thu, 28 Oct 2004 11:32:55 -0400
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: Arshad Noor <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: [pki-tc] Definitive source for abbreviations used in certificate DN's
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>

RFC 2253 is a good source for this. However,
there is no exhaustive list. People make up
their own abbreviations all too often, which
causes interoperability problems. Really,
they should use dotted decimal notation to
give the OID, but that's not user-friendly.

Thanks,

Steve

Arshad Noor wrote:

> Can someone please point me to a definitive source document, 
> that defines the official abbreviations used within X.509 digital 
> certificate DN's?   For instance, which specific document 
> specifies that the abbreviation S must be used for State, G (or 
> is it GN?) must be used for GivenName, SN for Surname, etc.  
> Thank you.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> P.S.  I have looked at ITU-T's X.520 (02/2001) document and while 
> it shows some abbreviations (CN, S, L, T, etc.) it does not elucidate 
> all of them.
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/leave_workgroup.php.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SF68Yr062237; Thu, 28 Oct 2004 08:06:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SF68Ij062236; Thu, 28 Oct 2004 08:06:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SF66cX062230 for <[e-mail]>; Thu, 28 Oct 2004 08:06:07 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22424; Thu, 28 Oct 2004 11:06:15 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-01.txt
Date: Thu, 28 Oct 2004 11:06:15 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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-profile-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-lightweight-ocsp-profile-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SF5k9k062197; Thu, 28 Oct 2004 08:05:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SF5kgB062196; Thu, 28 Oct 2004 08:05:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SF5h89062181 for <[e-mail]>; Thu, 28 Oct 2004 08:05:44 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22379; Thu, 28 Oct 2004 11:05:51 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldap-pkc-schema-01.txt
Date: Thu, 28 Oct 2004 11:05:51 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Internet X.509 Public Key Infrastructure Lightweight 
			  Directory Access Protocol Schema for X.509 Certificates
	Author(s)	: P. Gietz, N. Klasen
	Filename	: draft-ietf-pkix-ldap-pkc-schema-01.txt
	Pages		: 32
	Date		: 2004-10-27
	
This document describes a Lightweight Directory Access Protocol
   schema which can be used to implement a certificate store for X.509
   certificates.  Specifically, two structural object classes for X.509
   user and CA certificates are defined.  Key fields of a certificate
   are stored in LDAP attributes so that applications can easily
   retrieve the certificates needed by using basic LDAP search filters.
   Multiple certificates for a single entity can be stored and
   retrieved.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-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-ldap-pkc-schema-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-ldap-pkc-schema-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ldap-pkc-schema-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SF1tHJ061669; Thu, 28 Oct 2004 08:01:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SF1t5o061668; Thu, 28 Oct 2004 08:01:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SF1smr061660 for <[e-mail]>; Thu, 28 Oct 2004 08:01:54 -0700 (PDT) (envelope-from [e-mail])
Received: from noorhome.net (localhost [127.0.0.1]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 28 Oct 2004 07:39:36 -0700 (PDT)
Received: from [12.18.36.40] by igw.noorhome.net (mshttpd); Thu, 28 Oct 2004 10:39:36 -0400
Date: Thu, 28 Oct 2004 10:39:36 -0400
From: Arshad Noor <[e-mail]>
Subject: Definitive source for abbreviations used in certificate DN's
To: [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 Patch 1 (built Aug 19 2002)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Can someone please point me to a definitive source document, 
that defines the official abbreviations used within X.509 digital 
certificate DN's?   For instance, which specific document 
specifies that the abbreviation S must be used for State, G (or 
is it GN?) must be used for GivenName, SN for Surname, etc.  
Thank you.

Arshad Noor
StrongAuth, Inc.

P.S.  I have looked at ITU-T's X.520 (02/2001) document and while 
it shows some abbreviations (CN, S, L, T, etc.) it does not elucidate 
all of them.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SE6EOh058048; Thu, 28 Oct 2004 07:06:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SE6ET2058047; Thu, 28 Oct 2004 07:06:14 -0700 (PDT)
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 i9SE6DMD058037 for <[e-mail]>; Thu, 28 Oct 2004 07:06:13 -0700 (PDT) (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 QAA09090; Thu, 28 Oct 2004 16:18:04 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102816061194:842 ; Thu, 28 Oct 2004 16:06:11 +0200 
Message-ID: <[e-mail]>
Date: Thu, 28 Oct 2004 16:04:03 +0200
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: <002301c4bc63$42b29300$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 16:06:11, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 16:06:13, Serialize complete at 28/10/2004 16:06:13
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,

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 i9SE3tFD057910; Thu, 28 Oct 2004 07:03:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SE3tek057909; Thu, 28 Oct 2004 07:03:55 -0700 (PDT)
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 i9SE3s3K057888 for <[e-mail]>; Thu, 28 Oct 2004 07:03:55 -0700 (PDT) (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 QAA25338; Thu, 28 Oct 2004 16:15:44 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102816030572:841 ; Thu, 28 Oct 2004 16:03:05 +0200 
Message-ID: <[e-mail]>
Date: Thu, 28 Oct 2004 16:00:57 +0200
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: <001801c4bc61$eab07920$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 16:03:05, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 16:03:53, Serialize complete at 28/10/2004 16:03:53
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:]

(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 i9SE0s12057678; Thu, 28 Oct 2004 07:00:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SE0sYG057677; Thu, 28 Oct 2004 07:00:54 -0700 (PDT)
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 i9SE0qcg057667 for <[e-mail]>; Thu, 28 Oct 2004 07:00:53 -0700 (PDT) (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 QAA43000; Thu, 28 Oct 2004 16:12:41 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102816004934:838 ; Thu, 28 Oct 2004 16:00:49 +0200 
Message-ID: <[e-mail]>
Date: Thu, 28 Oct 2004 15:58:40 +0200
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: "'Jean-Marc Desperrier'" <[e-mail]>, [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <004801c4bc6b$5cac6120$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 16:00:49, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 16:00:50, Serialize complete at 28/10/2004 16:00:50
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,

> 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 i9SE0ZNu057646; Thu, 28 Oct 2004 07:00:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SE0Zlb057645; Thu, 28 Oct 2004 07:00:35 -0700 (PDT)
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 i9SE0XXj057636 for <[e-mail]>; Thu, 28 Oct 2004 07:00:34 -0700 (PDT) (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 QAA25270; Thu, 28 Oct 2004 16:12:23 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102816003075:837 ; Thu, 28 Oct 2004 16:00:30 +0200 
Message-ID: <[e-mail]>
Date: Thu, 28 Oct 2004 15:58:22 +0200
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], "David A. Cooper" <[e-mail]>
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <00b701c4bc54$80280e40$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 16:00:30, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 16:00:32, Serialize complete at 28/10/2004 16:00: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

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 i9S5R481085492; Wed, 27 Oct 2004 22:27:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9S5R45Q085491; Wed, 27 Oct 2004 22:27:04 -0700 (PDT)
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 i9S5R2sr085377 for <[e-mail]>; Wed, 27 Oct 2004 22:27:03 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 28 Oct 2004 07:26:29 +0200
Date: Thu, 28 Oct 2004 07:26:31 +0200 (CEST)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
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, 27 Oct 2004 18:19:27 +0200 (MEST), Peter Sylvester <[e-mail]> said:

Peter.Sylvester> At least you would probably agree that a CA cannot
Peter.Sylvester> sign another CA having the same DN (because this
Peter.Sylvester> would be considered as a self signed cert).

I agree in a way, but the parenthesis makes me wonder if you're not
mixing things up.  There is a difference between self-issued CA
certificates (where two CA certificates have the same subject) and a
self-signed CA certificate (where the public key in one certificate
can be used to verify the signature in that same certificate).  The
former is typically present as soon as you do a CA certificate roll-
over.

But I agree that two different CAs (two different organizations, in
other words) "cannot" have the same DN.  I write "cannot", because
it's still technically possible, and whenever that happens, one can
only expect a small appocalypse.

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 i9S2GOKk032799; Wed, 27 Oct 2004 19:16:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9S2GOdq032798; Wed, 27 Oct 2004 19:16:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9S2GNAU032791 for <[e-mail]>; Wed, 27 Oct 2004 19:16:23 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 093CD33F3F; Thu, 28 Oct 2004 15:16:29 +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 01580-17; Thu, 28 Oct 2004 15:16:28 +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 DCC1033F1D; Thu, 28 Oct 2004 15:16:27 +1300 (NZDT)
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id B0E8E3774A; Thu, 28 Oct 2004 15:16:27 +1300 (NZDT)
Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CMzq3-0002VI-00; Thu, 28 Oct 2004 15:16:31 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <E1CMzq3-0002VI-00@medusa01>
Date: Thu, 28 Oct 2004 15:16:31 +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>

Peter Sylvester <[e-mail]> writes:

>At least you would probably agree that a CA cannot sign another CA 
>having the same DN (because this would be considered as a self signed 
>cert).

It can if it's a CA cert renewal (and what a cesspit that is, creating
huge and often highly surprising anomalies and holes in path processing 
big enough to drive a truck through).

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 i9S2EYuG032607; Wed, 27 Oct 2004 19:14:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9S2EYI0032606; Wed, 27 Oct 2004 19:14:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpc.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9S2ESqU032588 for <[e-mail]>; Wed, 27 Oct 2004 19:14:29 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id B94C633FA9; Thu, 28 Oct 2004 15:14:27 +1300 (NZDT)
Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07457-19; Thu, 28 Oct 2004 15:14:27 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 3327A33EAA; Thu, 28 Oct 2004 15:14:27 +1300 (NZDT)
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2CEF53774A; Thu, 28 Oct 2004 15:14:27 +1300 (NZDT)
Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CMzo7-0002V7-00; Thu, 28 Oct 2004 15:14:31 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Digital Signature Implementation Interoperability
In-Reply-To: <001501c4bc36$50e77b20$7801a8c0@AQUIA>
Message-Id: <E1CMzo7-0002V7-00@medusa01>
Date: Thu, 28 Oct 2004 15:14:31 +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>

"Mike Henry" <[e-mail]> writes:

>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.

It depends on how you define "interoperate".  If you mean "will verify a 
basic S/MIME signature with minimal (X.509v1-level) implicitly-trusted certs 
without any problems" then everything will do that pretty much out of the 
box.  OTOH if you want to do anything with any level of sophistication/
complexity then it's pretty much pot luck what'll happen.  So both points
of view are correct.

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 i9RLZPHK072114; Wed, 27 Oct 2004 14:35:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RLZPTb072113; Wed, 27 Oct 2004 14:35:25 -0700 (PDT)
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 i9RLZPAr072104 for <[e-mail]>; Wed, 27 Oct 2004 14:35:25 -0700 (PDT) (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 i9RLZT8J004352 for <[e-mail]>; Wed, 27 Oct 2004 17:35:29 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Wed, 27 Oct 2004 17:35:23 -0400
Message-ID: <004d01c4bc6c$e1269af0$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RLZPAr072107
Sender: [e-mail]
Precedence: 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,

While X.609 and 3280 most likely do not say this explicitly (I have not done
an exhaustive search), a CA must not issue certificates to multiple distinct
entities (be it a CA or EE) with the same DN.

The issue of two CAs with the same name comes when PKIs cross certify or
even in a homogeneous PKI, control is distributed and there is no mechanism
to ensure CA name uniqueness.  Thus, CA name collision in a homogeneous PKI
is very unlikely.  

Please note that in cross certified PKI, use of name constraints will not
solve the problem of two or more CAs with the same name I am trying to
solve.

A minor nit, when a CA certifies another CA with the same name (a no-no),
that is not self-signed certificate; it is self-issued certificate.
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Sylvester
Sent: Wednesday, October 27, 2004 12:19 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



I say it differently:

A CA is not a PKI. You say that according to X509 a DN is only attributed to
the same entity by one CA. That's in the text, but this does not mean that
in order to have a PKI working, you don't 
need more. 

At least you would probably agree that a CA cannot sign another CA having
the same DN (because this would be considered as a 
self signed cert). 

Now, a CA1 --> CA2 --> CA1  can legally occur as a pair of cross
certificates, how would you distinguish whether CA1 and CA1 are identical or
not (in case the same keys are used the situation is clear). otherwise in
rekeying you check CA1 self signed certs towards each other, if so, same
CA1, if you happen to find another CA creating a certificate for the two CA1
keys, again same CA1, ... etc, you can go recursively up and down through
all cross certs in your PKI (if you find them)

If you fail all these tests, i.e. all cases where by 
some direct application of the existing rules you must conclude that the two
CA1 are identical, then you say, ok, I assume that these two CA1s are
different but still valid candidates in my PKI, i.e. you have two sets of
CRLs (V1) ...

Anyway: If you allow this, you can never ensure that any CA in your PKI
cross certify any other CA, a feature that seems more 
interesting to have 

Of course you have a problem when cross certifying two 
existing PKIs, which still does not mean that one cannot consider this
situation as 'garbage in', it may happen that by chance of path building you
get a good path if you don't see the other CA, but the question was whether
one should try and accept two different entities with the 
same DN. 


> Peter,
> 
> > denis, would you assume that it is a desirable feature in
> > a PKI that any CA could issue cross certs to any other in
> > a PKI, and that a PKI should not prohibit this.
> 
> What is the trick behind this question ?
>    ... and why this question relates to the topic of that thread ?
> 
> Nevertheless, my answer is the following:
> 
> Nobody can prevent a CA to issue a cross certificate.
> 
> However, it is another matter whether that cross certificate will be
> accepted or not under the rules of the validation policy to build a valid 
> certification path.
> 
> 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 i9RLOZRi069572; Wed, 27 Oct 2004 14:24:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RLOZNm069571; Wed, 27 Oct 2004 14:24:35 -0700 (PDT)
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 i9RLOYn4069565 for <[e-mail]>; Wed, 27 Oct 2004 14:24:34 -0700 (PDT) (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 i9RLOb8J030347; Wed, 27 Oct 2004 17:24:37 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Jean-Marc Desperrier'" <[e-mail]>, <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Wed, 27 Oct 2004 17:24:32 -0400
Message-ID: <004801c4bc6b$5cac6120$[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
In-Reply-To: <[e-mail]>
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>

Jean-Marc:

I agree that X.509 and 3280 define a CA by name.

-----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 i9RKteTP062095; Wed, 27 Oct 2004 13:55:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RKteVR062094; Wed, 27 Oct 2004 13:55:40 -0700 (PDT)
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 i9RKtdPT062062 for <[e-mail]>; Wed, 27 Oct 2004 13:55:40 -0700 (PDT) (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 i9RKtb8J006927 for <[e-mail]>; Wed, 27 Oct 2004 16:55:38 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Wed, 27 Oct 2004 16:55:31 -0400
Message-ID: <002d01c4bc67$500bf1f0$[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
In-Reply-To: <[e-mail]>
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>

Peter,

The extensions you identified help when you have a directory or the client
can do LDAP or DAP.  AIA can be used when there is no directory or the
client does not have wherewithal to query LDAP attributes.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Sylvester
Sent: Wednesday, October 27, 2004 10:19 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: Signer certificate discovery for CRLs




SMIME seems to work with an information that just has
'issuername+serialnumber' to point to th certificate that is used for
signing. 

A similar information can be made available in the AuthorityKeyIdentifier,
i.e. point to a cert that has a key that has signed the cert or crl. 

What is missing here:

-  A generic way to map this value to some repository request? 
-  To indicate an explicit mapping (at a near place)?  

I also do not really remember that the id-ad-caRepository
SIA extension had been actually proposed in 2000, it simply appeared in
part1-new-03. 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RKQYON055703; Wed, 27 Oct 2004 13:26:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RKQYoS055702; Wed, 27 Oct 2004 13:26:34 -0700 (PDT)
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 i9RKQYIr055696 for <[e-mail]>; Wed, 27 Oct 2004 13:26:34 -0700 (PDT) (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 i9RKQV8J019395 for <[e-mail]>; Wed, 27 Oct 2004 16:26:36 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Wed, 27 Oct 2004 16:26:26 -0400
Message-ID: <002301c4bc63$42b29300$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RKQYIr055697
Sender: [e-mail]
Precedence: 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, SIA for end certificate will add computational complexity.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Wednesday, October 27, 2004 9:26 AM
To: Denis Pinkas
Cc: pkix
Subject: RE: Signer certificate discovery for CRLs



Short reply.

> Are you claiming that this is only needed for indirect CRLs ?

No this is not just for indirect CRLs but it is most needed and obvious
there.

> This has never been demonstrated, and before knowing the solution, it 
> would be nice to know what the problem is.

The issue has been explained at lest 4 or 5 times on this thread and it
would probably not do any good to do it yet another time. 
You have also demonstrated through your answers that you have understood it
quite well.

Short repetition of the stated pros and cons:

The SIA may work IF:
- You have a "repository" available through which you can find suitable
information or make a suitable query for certificates.
- You have enough defined rules and processing time and power to allow local
processing the information gathered to find and build the path to the CRL
issuer.
- The CRL signer is nominated through a certificate that is issued directly
by the certificate issuing CA (or it will be to complex to find the path to
the CRL issuer). 

The AIA may work IF:
- The client already supports AIA in certificates for path building and have
the capacity to extend this to use in CRLs
- The client support downloading and processing of a single certificate file
from the specified location.

The AIA have 2 main advantages over SIA.
1) You typically only get a single certificate response in a single file.
This is much lower complexity than a link to all certificates issued by a
CA.
2) SIA is constrained to nomination of CRL issuer through a certificate
issued by the certificate issuing CA. AIA is independent of how the path to
the CRL is built and thus more generic.




Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 27 oktober 2004 15:00
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> > I disagree,
>    So we disagree.
> 
> > The problem to determine that a CRL is the correct CRL for a
certificate
> > is a completely separate and independent problem to the issue to 
> > discover a factual certification path to a particular CRL in order
to
> > validate its signature.
> 
> No. The issue is who provide that extension and in which case or
case(s).
> Then what kind of use RPs are expected to do with it.
> 
> We already have too many extensions where different people have
different
> interpretations of their use and thenafter justify an architecture by
the
> presence of that extension ! or because "nothing prevents to make a
given
> interpretation" of the document.
> 
> > These can, and probably should, be solved independently.
> 
> > The task to allow AIA as a CRL extension in its current form does
not
> > have to be on hold in the meanwhile. There are strong reasons enough
to
> > see it through.
> 
> > This relates to real practical problems. In our efforts, as
implementer,
> > to work with indirect CRLs,
> 
> Are you claiming that this is only needed for indirect CRLs ?
> 
> (i.e. for CRLs which include certificates issued by authorities other
than
> the CRL issuer).
> 
> > we must in some cases rely on either AIA in CRLs or a similar,
currently
>  > non-standardized method.
> 
> > SIA doesn't solve our needs.
> 
> This has never been demonstrated, and before knowing the solution, it 
> would be nice to know what the problem is.
> 
> Denis
> 
>  > AIA does. It seems to me that other implementers have reached
> > the same conclusion.
> 
> 
> > /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 i9RKNCnM054971; Wed, 27 Oct 2004 13:23:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RKNCg3054970; Wed, 27 Oct 2004 13:23:12 -0700 (PDT)
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 i9RKNBbx054962 for <[e-mail]>; Wed, 27 Oct 2004 13:23:11 -0700 (PDT) (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 i9RKND8J018018 for <[e-mail]>; Wed, 27 Oct 2004 16:23:13 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Wed, 27 Oct 2004 16:23:07 -0400
Message-ID: <001a01c4bc62$c8c7a300$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RKNCbx054965
Sender: [e-mail]
Precedence: 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: Wednesday, October 27, 2004 9:00 AM
To: Stefan Santesson
Cc: pkix
Subject: Re: Signer certificate discovery for CRLs



Stefan,

> I disagree,
   So we disagree.

> The problem to determine that a CRL is the correct CRL for a 
> certificate is a completely separate and independent problem to the 
> issue to discover a factual certification path to a particular CRL in 
> order to validate its signature.

No. The issue is who provide that extension and in which case or case(s).
Then what kind of use RPs are expected to do with it.

[SC: Just like AIA in certificates, those who want to use it, will use it.
Others are welcome to use other means.]

We already have too many extensions where different people have different 
interpretations of their use and thenafter justify an architecture by the 
presence of that extension ! or because "nothing prevents to make a given 
interpretation" of the document.

[SC: We are not adding an extension.  We are permitting an existing
non-critical extension in the CRL for those who wish to use it.]

> These can, and probably should, be solved independently.

> The task to allow AIA as a CRL extension in its current form does not 
> have to be on hold in the meanwhile. There are strong reasons enough 
> to see it through.

> This relates to real practical problems. In our efforts, as 
> implementer, to work with indirect CRLs,

Are you claiming that this is only needed for indirect CRLs ?

[SC: It is useful for both and may be more useful in the case of indirect
CRL]

(i.e. for CRLs which include certificates issued by authorities other than 
the CRL issuer).

> we must in some cases rely on either AIA in CRLs or a similar, 
> currently
 > non-standardized method.

> SIA doesn't solve our needs.

This has never been demonstrated, and before knowing the solution, it would 
be nice to know what the problem is.

[SC: Lot of extensions such as AKID, SKID, etc., are for efficiency reasons.
Since, AIA provides efficiency, there is no particular reason to prove other
ways.  If you think other ways are more efficient, do prove it.]

Denis

 > AIA does. It seems to me that other implementers have reached
> the same conclusion.


> /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 i9RKILWK053941; Wed, 27 Oct 2004 13:18:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RKIL2X053940; Wed, 27 Oct 2004 13:18:21 -0700 (PDT)
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 i9RKIKmi053933 for <[e-mail]>; Wed, 27 Oct 2004 13:18:20 -0700 (PDT) (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 i9RKIO8J015827 for <[e-mail]>; Wed, 27 Oct 2004 16:18:24 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Wed, 27 Oct 2004 16:18:19 -0400
Message-ID: <001901c4bc62$1c912e30$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RKILmi053935
Sender: [e-mail]
Precedence: 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,

For most parts, I agree with you.

In the interest of efficiency one can use the path matching algorithm to
guide building the certification path for the CRL issuer

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Wednesday, October 27, 2004 8:44 AM
To: Denis Pinkas
Cc: pkix
Subject: RE: Signer certificate discovery for CRLs



I disagree,

The problem to determine that a CRL is the correct CRL for a certificate is
a completely separate and independent problem to the issue to discover a
factual certification path to a particular CRL in order to validate its
signature.

These can, and probably should, be solved independently.

The task to allow AIA as a CRL extension in its current form does not have
to be on hold in the meanwhile. There are strong reasons enough to see it
through.

This relates to real practical problems. In our efforts, as implementer, to
work with indirect CRLs, we must in some cases rely on either AIA in CRLs or
a similar, currently non-standardized method. SIA doesn't solve our needs.
AIA does. It seems to me that other implementers have reached the same
conclusion. 


/Stefan
 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 27 oktober 2004 14:24
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> > Denis,
> >
> > Yes, SIA could be an option in SOME cases, if properly implemented
and
> > if combined with an appropriate directory infrastructure.
> 
> You sentence is not correct.
> 
> "SIA could be an option in SOME cases, if properly implemented and if 
> combined with an appropriate *repository* infrastructure".
> 
> > It's just not as generic and cost effective as AIA in CRLs,
especially
> > not when building chains from bottom up, which is a common way to
build
> > paths.
> 
> Of course since SIA is used to build chain top down ! (which is a
common
> way
> to build paths).
> 
> > I'm not trying to pick on words here. But for the first time I got
the
> > impression that you accept AIA in CRLs as a valid option.
> 
> Not exactly. AIA in CRLs COULD be a valid option.
> 
> > Do you still claim that AIA in CRLs is an invalid option that should
NOT
> > be allowed?
> 
> I never claimed such a sentence, so I do not need to disclaim it. :-|
> 
> 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.
> 
> Upon this aspect, we are far from an agreement and this is of course 
> strongly related to the (lack of a) CRL processing model.
> 
> 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.
> 
> 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 i9RKH0cC053760; Wed, 27 Oct 2004 13:17:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RKH0CS053759; Wed, 27 Oct 2004 13:17:00 -0700 (PDT)
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 i9RKGxv5053753 for <[e-mail]>; Wed, 27 Oct 2004 13:16:59 -0700 (PDT) (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 i9RKH18J015087 for <[e-mail]>; Wed, 27 Oct 2004 16:17:01 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Wed, 27 Oct 2004 16:16:42 -0400
Message-ID: <001801c4bc61$eab07920$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RKH0v5053754
Sender: [e-mail]
Precedence: 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: Wednesday, October 27, 2004 8:24 AM
To: Stefan Santesson
Cc: pkix
Subject: Re: Signer certificate discovery for CRLs



> It's just not as generic and cost effective as AIA in CRLs, especially 
> not when building chains from bottom up, which is a common way to 
> build paths.

Of course since SIA is used to build chain top down ! (which is a common way

to build paths).

[SC: Says who?  Most folks build paths from subscriber certificate to RP
trust anchor.]

> I'm not trying to pick on words here. But for the first time I got the 
> impression that you accept AIA in CRLs as a valid option.

Not exactly. AIA in CRLs COULD be a valid option.

> Do you still claim that AIA in CRLs is an invalid option that should 
> NOT be allowed?

I never claimed such a sentence, so I do not need to disclaim it. :-|

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]

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.]

Denis

> /Stefan
>  
> 
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 27 oktober 2004 09:32
>>To: Stefan Santesson
>>Cc: pkix
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>
>>Stefan,
>>
>>
>>>Denis,
>>
>>><snip>
>>
>>>>Use of AIA in CRLs would be one way to do it, while the use of SIA 
>>>>in CA certificates is the other way.
>>>
>>>I'm pleased to read that you acknowledge AIA in CRLs as a valid
>>
> option.
> 
>>>That is all I ask for.
>>
>>I'm pleased to read that you noticed that AIA *would be an option*
> 
> since I
> 
>>used "would be" in the case of AIA and "is" in the case of SIA:
>>
>>Use of AIA in CRLs *would be* one way to do it, while the use of SIA 
>>in CA certificates *is* the other way.  :-)
>>
>>Denis
>>
>>
>>>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 i9RJB08r038162; Wed, 27 Oct 2004 12:11:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RJB0wq038161; Wed, 27 Oct 2004 12:11:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-2-sn1.fre.skanova.net (av1-2-sn1.fre.skanova.net [81.228.11.108]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RJAxC8038131 for <[e-mail]>; Wed, 27 Oct 2004 12:11:00 -0700 (PDT) (envelope-from [e-mail])
Received: by av1-2-sn1.fre.skanova.net (Postfix, from userid 502) id 05BAE37E8E; Wed, 27 Oct 2004 21:10:52 +0200 (CEST)
Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av1-2-sn1.fre.skanova.net (Postfix) with ESMTP id EABF837E45; Wed, 27 Oct 2004 21:10:51 +0200 (CEST)
Received: from rsaedoscymkikx (t12o913p27.telia.com [213.64.28.147]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id 3F23937E46; Wed, 27 Oct 2004 21:10:49 +0200 (CEST)
Message-ID: <00d401c4bc58$ac5349e0$80c5a8c0@rsaedoscymkikx>
From: "Anders Rundgren" <[e-mail]>
To: "Mike Henry" <[e-mail]>, <[e-mail]>
References: <001501c4bc36$50e77b20$7801a8c0@AQUIA>
Subject: Re: Digital Signature Implementation Interoperability
Date: Wed, 27 Oct 2004 21:10:48 +0200
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>

Hi Mike,

You should be aware of the fact that client signatures comes in
two flavors.  One is S/MIME (signed e-mail) which actually is
both standardized and interoperable.

However, most e-governments, banks and other advanced users of
IT have concluded that the web is the preferred method for distributing
and acquiring information including digital signatures.   In this area which
often is called "web-sign" there are no standards and no standards in
preparation either.  Most systems are currently using Java applets
to get some kind of limited cross-platform ability.

Regards
Anders Rundgren

----- Original Message ----- 
From: "Mike Henry" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, October 27, 2004 17:04
Subject: 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







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RIf2Nb031891; Wed, 27 Oct 2004 11:41:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RIf2JG031890; Wed, 27 Oct 2004 11:41:02 -0700 (PDT)
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 i9RIf1aA031875 for <[e-mail]>; Wed, 27 Oct 2004 11:41:01 -0700 (PDT) (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 i9RIer8J019391 for <[e-mail]>; Wed, 27 Oct 2004 14:40:59 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Wed, 27 Oct 2004 14:40:45 -0400
Message-ID: <00b701c4bc54$80280e40$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RIf1aA031884
Sender: [e-mail]
Precedence: 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 inline in [SC:]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Wednesday, October 27, 2004 5:29 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting



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]
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]

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]

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]

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.
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.
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]

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]

Denis

> Santosh Chokhani
> Orion Security Solutions, Inc.
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> [phone]  Ext. 35 (voice)
> [phone] (Fax)
> [e-mail]
> Visit our Web site
> http://www.orionsec.com <http://www.orionsec.com/>






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RHJDsk013524; Wed, 27 Oct 2004 10:19:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RHJDpa013523; Wed, 27 Oct 2004 10:19:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eevee.engine.ca (gate1.engine.ca [209.188.66.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RHJCPs013511 for <[e-mail]>; Wed, 27 Oct 2004 10:19:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from alicia@localhost) by eevee.engine.ca (8.11.3nb1/8.6.12) id i9RHJol04223 for [e-mail]; Wed, 27 Oct 2004 13:19:50 -0400 (EDT)
Received: (from alicia@localhost) by eevee.engine.ca (8.11.3nb1/8.6.12) id i9RHIrG04197; Wed, 27 Oct 2004 13:18:53 -0400 (EDT)
From: Alicia da Conceicao <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Digital Signature Implementation Interoperability
To: [e-mail] (Mike Henry)
Date: Wed, 27 Oct 2004 13:18:53 -0400 (EDT)
In-Reply-To: <001501c4bc36$50e77b20$7801a8c0@AQUIA> from "Mike Henry" at Oct 27, 2004 11:04:53 AM
X-Mailer: ELM [version 2.5 PL5]
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>

Dear Mike:

I disagree!  As someone who recently complete her own digital signature
product nearly two months ago, I cannot see why any other digital
signature products that also uses CMS signedData based signatures with
DER encoding won't interoperate with each other.
 
In other words, if I send you a DER encoded file of a CMS signedData
digital signature, then any CMS compliant software should be able to load
it up and validate it against the original document and signing certificate.
The original document and/or DER encoded signing certificate may or may
not be present in the signature, but any robust digital signature software
must also be able to load these from external binary files.

On a side note, does anyone know if there is an ISO standard yet for CMS
based digital signatures?  ISO-18014-2 was recently added for RFC-3161
based timestamps that are used in CMS, but I haven't come across any ISO
standard for generic CMS signedData.

If anyone else has any CMS signedData based digital signature software
that they would like to interop test, please let me know, since I would
be happy to test it against my own fully functional CMS software.  Prehaps
if a critical mass of CMS software providers are interested, we can even
have an interop test-fest where we all test our CMS software against each
other.

Alicia.


> 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




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RGJR8p098607; Wed, 27 Oct 2004 09:19:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RGJRFR098605; Wed, 27 Oct 2004 09:19:27 -0700 (PDT)
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 i9RGJPjD098588 for <[e-mail]>; Wed, 27 Oct 2004 09:19:26 -0700 (PDT) (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 i9RGJSD10701; Wed, 27 Oct 2004 18:19:28 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 27 Oct 2004 18:19:28 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9RGJRG00652; Wed, 27 Oct 2004 18:19:27 +0200 (MEST)
Date: Wed, 27 Oct 2004 18:19:27 +0200 (MEST)
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], [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>

I say it differently:

A CA is not a PKI. You say that according to X509 a DN is only
attributed to the same entity by one CA. That's in the text, but
this does not mean that in order to have a PKI working, you don't 
need more. 

At least you would probably agree that a CA cannot sign another
CA having the same DN (because this would be considered as a 
self signed cert). 

Now, a CA1 --> CA2 --> CA1  can legally occur as a pair of
cross certificates, how would you distinguish whether CA1
and CA1 are identical or not (in case the same keys are used
the situation is clear). otherwise in rekeying you check
CA1 self signed certs towards each other, if so, same CA1,
if you happen to find another CA creating a certificate
for the two CA1 keys, again same CA1, ... etc, you can go
recursively up and down through all cross certs in your PKI
(if you find them)

If you fail all these tests, i.e. all cases where by 
some direct application of the existing rules you must conclude
that the two CA1 are identical, then you say, ok, I assume that
these two CA1s are different but still valid candidates in my
PKI, i.e. you have two sets of CRLs (V1) ...

Anyway: If you allow this, you can never ensure that any CA in your PKI
cross certify any other CA, a feature that seems more 
interesting to have 

Of course you have a problem when cross certifying two 
existing PKIs, which still does not mean that one cannot
consider this situation as 'garbage in', it may happen that
by chance of path building you get a good path if you
don't see the other CA, but the question was whether one
should try and accept two different entities with the 
same DN. 


> Peter,
> 
> > denis, would you assume that it is a desirable feature in
> > a PKI that any CA could issue cross certs to any other in
> > a PKI, and that a PKI should not prohibit this.
> 
> What is the trick behind this question ?
>    ... and why this question relates to the topic of that thread ?
> 
> Nevertheless, my answer is the following:
> 
> Nobody can prevent a CA to issue a cross certificate.
> 
> However, it is another matter whether that cross certificate will be 
> accepted or not under the rules of the validation policy to build a valid 
> certification path.
> 
> 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 i9RFocil093075; Wed, 27 Oct 2004 08:50:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RFocV2093074; Wed, 27 Oct 2004 08:50:38 -0700 (PDT)
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 i9RFobmq093036 for <[e-mail]>; Wed, 27 Oct 2004 08:50:37 -0700 (PDT) (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 SAA57816; Wed, 27 Oct 2004 18:02:15 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102717502405:559 ; Wed, 27 Oct 2004 17:50:24 +0200 
Message-ID: <[e-mail]>
Date: Wed, 27 Oct 2004 17:51:14 +0200
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: Peter Sylvester <[e-mail]>
CC: [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 27/10/2004 17:50:24, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 17:50:26, Serialize complete at 27/10/2004 17:50:26
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,

> denis, would you assume that it is a desirable feature in
> a PKI that any CA could issue cross certs to any other in
> a PKI, and that a PKI should not prohibit this.

What is the trick behind this question ?
   ... and why this question relates to the topic of that thread ?

Nevertheless, my answer is the following:

Nobody can prevent a CA to issue a cross certificate.

However, it is another matter whether that cross certificate will be 
accepted or not under the rules of the validation policy to build a valid 
certification path.

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 i9RFWWR5088105; Wed, 27 Oct 2004 08:32:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RFWWwY088104; Wed, 27 Oct 2004 08:32:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RFWNkq088079 for <[e-mail]>; Wed, 27 Oct 2004 08:32:25 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.0.51] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft4.fr.colt.net with ESMTP id i9RFVva14934 for <[e-mail]>; Wed, 27 Oct 2004 17:31:58 +0200
Message-ID: <[e-mail]>
Date: Wed, 27 Oct 2004 17:31:57 +0200
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: Briefing on CRL Path for IETF PKIX WG Meeting
References: <00e901c4bb3e$becdeeb0$[e-mail]> <[e-mail]> <[e-mail]> <[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>

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 i9RF7BUs081712; Wed, 27 Oct 2004 08:07:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RF7BRh081711; Wed, 27 Oct 2004 08:07:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RF7Aqx081685 for <[e-mail]>; Wed, 27 Oct 2004 08:07:10 -0700 (PDT) (envelope-from [e-mail])
Received: from DLVAJHENRYMI ([68.70.171.132]) by mta13.adelphia.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with SMTP id <20041027150707.SZPK15118.mta13.adelphia.net@DLVAJHENRYMI> for <[e-mail]>; Wed, 27 Oct 2004 11:07:07 -0400
From: "Mike Henry" <[e-mail]>
To: <[e-mail]>
Subject: Digital Signature Implementation Interoperability
Date: Wed, 27 Oct 2004 11:04:53 -0400
Message-ID: <001501c4bc36$50e77b20$7801a8c0@AQUIA>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
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>

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







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RF4tHc081223; Wed, 27 Oct 2004 08:04:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RF4tuq081222; Wed, 27 Oct 2004 08:04:55 -0700 (PDT)
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 i9RF4sGo081216 for <[e-mail]>; Wed, 27 Oct 2004 08:04:54 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CMpIF-0004Yg-Ep; Wed, 27 Oct 2004 11:00:55 -0400
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: Protocol Action: 'Additional Algorithms and Identifiers for  RSA Cryptography for use in the Internet X.509 Public Key  Infrastructure Certificate and Certificate Revocation List (CRL)  Profile' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Wed, 27 Oct 2004 11:00:55 -0400
Sender: [e-mail]
Precedence: 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:

- 'Additional Algorithms and Identifiers for RSA Cryptography for use in the 
   Internet X.509 Public Key Infrastructure Certificate and Certificate 
   Revocation List (CRL) Profile '
   <draft-ietf-pkix-rsa-pkalgs-03.txt> as a Proposed Standard

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

The IESG contact persons are Steve Bellovin and Russ Housley.

Technical Summary
 
 This document supplements RFC 3279 to describe how to use some newer 
cryptographic algorithms.
 
Working Group Summary
 
 There were no major issues raised during the discussion.
 
Protocol Quality
 
 Steve Bellovin reviewed this document for the IESG.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RElDJB077006; Wed, 27 Oct 2004 07:47:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RElDBt077005; Wed, 27 Oct 2004 07:47:13 -0700 (PDT)
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 i9RElBkv076982 for <[e-mail]>; Wed, 27 Oct 2004 07:47:12 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06110406bda564ea5155@[10.20.30.249]>
Date: Wed, 27 Oct 2004 07:47:11 -0700
To: [e-mail]
From: Paul Hoffman / VPNC <[e-mail]>
Subject: Suggestion for revising RFC 3280
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>

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 i9REk4vL076660; Wed, 27 Oct 2004 07:46:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9REk4Qu076659; Wed, 27 Oct 2004 07:46:04 -0700 (PDT)
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 i9REk2bp076652 for <[e-mail]>; Wed, 27 Oct 2004 07:46:03 -0700 (PDT) (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 i9REk3D09347; Wed, 27 Oct 2004 16:46:04 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 27 Oct 2004 16:46:04 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9REk3000285; Wed, 27 Oct 2004 16:46:03 +0200 (MEST)
Date: Wed, 27 Oct 2004 16:46:03 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: AW: Signer certificate discovery for CRLs
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>

> with issuerSerial in the AKI extension you only identify the certificate to
> verify the signature of e. g. the CRL. But, as far as I understood the
> discussion, the question is where can I find this certificate.

That's why I said: 

> > 
> > What is missing here:
> > 
> > -  A generic way to map this value to some repository request? 
> > -  To indicate an explicit mapping (at a near place)?  

.. i.e. a mapping from URI to URL 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9REhxlw076198; Wed, 27 Oct 2004 07:43:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9REhxQ4076197; Wed, 27 Oct 2004 07:43:59 -0700 (PDT)
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 i9REhvHL076189 for <[e-mail]>; Wed, 27 Oct 2004 07:43:58 -0700 (PDT) (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 i9REhxD09336; Wed, 27 Oct 2004 16:43:59 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 27 Oct 2004 16:43:59 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9REhxG00282; Wed, 27 Oct 2004 16:43:59 +0200 (MEST)
Date: Wed, 27 Oct 2004 16:43:59 +0200 (MEST)
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>

denis, would you assume that it is a desirable feature in
a PKI that any CA could issue cross certs to any other in
a PKI, and that a PKI should not prohibit 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 i9REaR3M074630; Wed, 27 Oct 2004 07:36:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9REaRml074629; Wed, 27 Oct 2004 07:36:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mizar.origin-it.net (mail.de.atosorigin.com [194.8.96.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9REaPgG074594 for <[e-mail]>; Wed, 27 Oct 2004 07:36:26 -0700 (PDT) (envelope-from [e-mail])
Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68]) by mizar.origin-it.net (8.13.1/8.13.1/hmo30jul04) with ESMTP id i9REZgWd009903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2004 16:35:42 +0200 (CEST) (envelope-from [e-mail])
Received: from ascalon.mpn.de.int.atosorigin.com (ascalon.mpn.de.int.atosorigin.com [161.90.190.36]) by matar.hbg.de.int.atosorigin.com (8.13.1/8.13.1/hmo30jul04) with ESMTP id i9REZfDu034043; Wed, 27 Oct 2004 16:35:41 +0200 (CEST) (envelope-from [e-mail])
Received: by ascalon.mpn.de.int.atosorigin.com with Internet Mail Service (5.5.2653.19) id <VWR83YBH>; Wed, 27 Oct 2004 16:35:41 +0200
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
Subject: AW: Signer certificate discovery for CRLs
Date: Wed, 27 Oct 2004 16:35:39 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 i9REaQgG074623
Sender: [e-mail]
Precedence: 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,

with issuerSerial in the AKI extension you only identify the certificate to
verify the signature of e. g. the CRL. But, as far as I understood the
discussion, the question is where can I find this certificate.

Regards

Thomas

> -----Ursprüngliche Nachricht-----
> Von: Peter Sylvester [mailto:[e-mail]]
> Gesendet: Mittwoch, 27. Oktober 2004 16:19
> An: [e-mail]; [e-mail]
> Cc: [e-mail]
> Betreff: RE: Signer certificate discovery for CRLs
> 
> 
> 
> 
> SMIME seems to work with an information that just has
> 'issuername+serialnumber' to point to th certificate
> that is used for signing. 
> 
> A similar information can be made available in the
> AuthorityKeyIdentifier, i.e. point to a cert that
> has a key that has signed the cert or crl. 
> 
> What is missing here:
> 
> -  A generic way to map this value to some repository request? 
> -  To indicate an explicit mapping (at a near place)?  
> 
> I also do not really remember that the id-ad-caRepository
> SIA extension had been actually proposed in 2000, it simply
> appeared in part1-new-03. 
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9REJHDQ071509; Wed, 27 Oct 2004 07:19:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9REJHRZ071508; Wed, 27 Oct 2004 07:19:17 -0700 (PDT)
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 i9REJFh3071492 for <[e-mail]>; Wed, 27 Oct 2004 07:19:16 -0700 (PDT) (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 i9REJCD08867; Wed, 27 Oct 2004 16:19:12 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 27 Oct 2004 16:19:17 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9REJA000162; Wed, 27 Oct 2004 16:19:10 +0200 (MEST)
Date: Wed, 27 Oct 2004 16:19:10 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Signer certificate discovery for CRLs
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>

SMIME seems to work with an information that just has
'issuername+serialnumber' to point to th certificate
that is used for signing. 

A similar information can be made available in the
AuthorityKeyIdentifier, i.e. point to a cert that
has a key that has signed the cert or crl. 

What is missing here:

-  A generic way to map this value to some repository request? 
-  To indicate an explicit mapping (at a near place)?  

I also do not really remember that the id-ad-caRepository
SIA extension had been actually proposed in 2000, it simply
appeared in part1-new-03. 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RDZRGM062796; Wed, 27 Oct 2004 06:35:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RDZRbe062794; Wed, 27 Oct 2004 06:35:27 -0700 (PDT)
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 i9RDZQgR062784 for <[e-mail]>; Wed, 27 Oct 2004 06:35:27 -0700 (PDT) (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 i9RDZL8J011385 for <[e-mail]>; Wed, 27 Oct 2004 09:35:21 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: 3280 issue
Date: Wed, 27 Oct 2004 09:35:15 -0400
Message-ID: <002401c4bc29$ce9a5b80$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RDZRgR062789
Sender: [e-mail]
Precedence: 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,

This is not a 3280 issue.  This is how directories are deployed.  That is
why X.500 and LDAP can be run over TLS/SSL.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Sylvester
Sent: Wednesday, October 27, 2004 8:19 AM
To: [e-mail]
Subject: 3280 issue




In a directory which is protected by the same X509 hierarchy
it is sufficient that certificates and crls are the only 
objects (besides a trust anchor) that need to be protected using a signature
(authentoicity and integrity), since an absence of certificats always leads
to some error that can be attributed to the repository.

In a situation with multiple paths, the absence of a CA cert
in the directory is something cannot be detected, i.e., if
some MIM or wahtever modifies the content of the transfer from the
directory, an theoretically existing cert path can simply not be available
without the possibility of detecting whether this is intended or a failure
of the directory (directory = 
whatever repository).

It seems necessary that something like signing a  
list of certificates containing all crosscerts towards
and another from other CAs is necessary to have the
analogy of a single object, i.e; to determine completeness. 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RDQid5061101; Wed, 27 Oct 2004 06:26:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RDQi92061100; Wed, 27 Oct 2004 06:26:44 -0700 (PDT)
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 i9RDQgKD061057 for <[e-mail]>; Wed, 27 Oct 2004 06:26:43 -0700 (PDT) (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, 27 Oct 2004 14:26:33 +0100
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: Signer certificate discovery for CRLs
Date: Wed, 27 Oct 2004 14:26:29 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcS8JT0C+uSIYrsYSSeMYJkUxw8BEAAACllA
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 27 Oct 2004 13:26:33.0382 (UTC) FILETIME=[93931460:01C4BC28]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RDQhKD061094
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Short reply.

> Are you claiming that this is only needed for indirect CRLs ?

No this is not just for indirect CRLs but it is most needed and obvious
there.

> This has never been demonstrated, and before knowing the solution, it
> would
> be nice to know what the problem is.

The issue has been explained at lest 4 or 5 times on this thread and it
would probably not do any good to do it yet another time. 
You have also demonstrated through your answers that you have understood
it quite well.

Short repetition of the stated pros and cons:

The SIA may work IF:
- You have a "repository" available through which you can find suitable
information or make a suitable query for certificates.
- You have enough defined rules and processing time and power to allow
local processing the information gathered to find and build the path to
the CRL issuer.
- The CRL signer is nominated through a certificate that is issued
directly by the certificate issuing CA (or it will be to complex to find
the path to the CRL issuer). 

The AIA may work IF:
- The client already supports AIA in certificates for path building and
have the capacity to extend this to use in CRLs
- The client support downloading and processing of a single certificate
file from the specified location.

The AIA have 2 main advantages over SIA.
1) You typically only get a single certificate response in a single
file. This is much lower complexity than a link to all certificates
issued by a CA.
2) SIA is constrained to nomination of CRL issuer through a certificate
issued by the certificate issuing CA. AIA is independent of how the path
to the CRL is built and thus more generic.




Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 27 oktober 2004 15:00
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> > I disagree,
>    So we disagree.
> 
> > The problem to determine that a CRL is the correct CRL for a
certificate
> > is a completely separate and independent problem to the issue to
> > discover a factual certification path to a particular CRL in order
to
> > validate its signature.
> 
> No. The issue is who provide that extension and in which case or
case(s).
> Then what kind of use RPs are expected to do with it.
> 
> We already have too many extensions where different people have
different
> interpretations of their use and thenafter justify an architecture by
the
> presence of that extension ! or because "nothing prevents to make a
given
> interpretation" of the document.
> 
> > These can, and probably should, be solved independently.
> 
> > The task to allow AIA as a CRL extension in its current form does
not
> > have to be on hold in the meanwhile. There are strong reasons enough
to
> > see it through.
> 
> > This relates to real practical problems. In our efforts, as
implementer,
> > to work with indirect CRLs,
> 
> Are you claiming that this is only needed for indirect CRLs ?
> 
> (i.e. for CRLs which include certificates issued by authorities other
than
> the CRL issuer).
> 
> > we must in some cases rely on either AIA in CRLs or a similar,
currently
>  > non-standardized method.
> 
> > SIA doesn't solve our needs.
> 
> This has never been demonstrated, and before knowing the solution, it
> would
> be nice to know what the problem is.
> 
> Denis
> 
>  > AIA does. It seems to me that other implementers have reached
> > the same conclusion.
> 
> 
> > /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 i9RDPnEe060917; Wed, 27 Oct 2004 06:25:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RDPnWk060913; Wed, 27 Oct 2004 06:25:49 -0700 (PDT)
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 i9RDPlrx060898 for <[e-mail]>; Wed, 27 Oct 2004 06:25:48 -0700 (PDT) (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 i9RDPmD08027 for <[e-mail]>; Wed, 27 Oct 2004 15:25:49 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 27 Oct 2004 15:25:49 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9RDPmL29951 for [e-mail]; Wed, 27 Oct 2004 15:25:48 +0200 (MEST)
Date: Wed, 27 Oct 2004 15:25:48 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Signer certificate discovery for CRLs
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>

There is also the AuthorityKeyIdentifier extension in a CRL. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RD1uQl056456; Wed, 27 Oct 2004 06:01:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RD1unX056455; Wed, 27 Oct 2004 06:01:56 -0700 (PDT)
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 i9RD1sja056408 for <[e-mail]>; Wed, 27 Oct 2004 06:01:55 -0700 (PDT) (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 PAA24930; Wed, 27 Oct 2004 15:13:38 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102715014749:491 ; Wed, 27 Oct 2004 15:01:47 +0200 
Message-ID: <[e-mail]>
Date: Wed, 27 Oct 2004 14:59:42 +0200
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: pkix <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 15:01:47, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 15:01:48, Serialize complete at 27/10/2004 15:01: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>

Stefan,

> I disagree,
   So we disagree.

> The problem to determine that a CRL is the correct CRL for a certificate
> is a completely separate and independent problem to the issue to
> discover a factual certification path to a particular CRL in order to
> validate its signature.

No. The issue is who provide that extension and in which case or case(s).
Then what kind of use RPs are expected to do with it.

We already have too many extensions where different people have different 
interpretations of their use and thenafter justify an architecture by the 
presence of that extension ! or because "nothing prevents to make a given 
interpretation" of the document.

> These can, and probably should, be solved independently.

> The task to allow AIA as a CRL extension in its current form does not
> have to be on hold in the meanwhile. There are strong reasons enough to
> see it through.

> This relates to real practical problems. In our efforts, as implementer,
> to work with indirect CRLs, 

Are you claiming that this is only needed for indirect CRLs ?

(i.e. for CRLs which include certificates issued by authorities other than 
the CRL issuer).

> we must in some cases rely on either AIA in CRLs or a similar, currently 
 > non-standardized method.

> SIA doesn't solve our needs. 

This has never been demonstrated, and before knowing the solution, it would 
be nice to know what the problem is.

Denis

 > AIA does. It seems to me that other implementers have reached
> the same conclusion. 


> /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 i9RCiCTH052237; Wed, 27 Oct 2004 05:44:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RCiCg4052236; Wed, 27 Oct 2004 05:44:12 -0700 (PDT)
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 i9RCiBxV052225 for <[e-mail]>; Wed, 27 Oct 2004 05:44:11 -0700 (PDT) (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, 27 Oct 2004 13:44:12 +0100
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: Signer certificate discovery for CRLs
Date: Wed, 27 Oct 2004 13:44:06 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcS8ID/OezqyQjGIRKGbRkB9cS3h9QAAFXpg
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 27 Oct 2004 12:44:12.0278 (UTC) FILETIME=[A8F56160:01C4BC22]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RCiBxV052231
Sender: [e-mail]
Precedence: 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 disagree,

The problem to determine that a CRL is the correct CRL for a certificate
is a completely separate and independent problem to the issue to
discover a factual certification path to a particular CRL in order to
validate its signature.

These can, and probably should, be solved independently.

The task to allow AIA as a CRL extension in its current form does not
have to be on hold in the meanwhile. There are strong reasons enough to
see it through.

This relates to real practical problems. In our efforts, as implementer,
to work with indirect CRLs, we must in some cases rely on either AIA in
CRLs or a similar, currently non-standardized method. SIA doesn't solve
our needs. AIA does. It seems to me that other implementers have reached
the same conclusion. 


/Stefan
 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 27 oktober 2004 14:24
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> > Denis,
> >
> > Yes, SIA could be an option in SOME cases, if properly implemented
and
> > if combined with an appropriate directory infrastructure.
> 
> You sentence is not correct.
> 
> "SIA could be an option in SOME cases, if properly implemented and if
> combined with an appropriate *repository* infrastructure".
> 
> > It's just not as generic and cost effective as AIA in CRLs,
especially
> > not when building chains from bottom up, which is a common way to
build
> > paths.
> 
> Of course since SIA is used to build chain top down ! (which is a
common
> way
> to build paths).
> 
> > I'm not trying to pick on words here. But for the first time I got
the
> > impression that you accept AIA in CRLs as a valid option.
> 
> Not exactly. AIA in CRLs COULD be a valid option.
> 
> > Do you still claim that AIA in CRLs is an invalid option that should
NOT
> > be allowed?
> 
> I never claimed such a sentence, so I do not need to disclaim it. :-|
> 
> 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.
> 
> Upon this aspect, we are far from an agreement and this is of course
> strongly related to the (lack of a) CRL processing model.
> 
> 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.
> 
> 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 i9RCQT7w048560; Wed, 27 Oct 2004 05:26:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RCQTwN048559; Wed, 27 Oct 2004 05:26:29 -0700 (PDT)
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 i9RCQScn048546 for <[e-mail]>; Wed, 27 Oct 2004 05:26:28 -0700 (PDT) (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 OAA42362; Wed, 27 Oct 2004 14:38:13 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102714262190:475 ; Wed, 27 Oct 2004 14:26:21 +0200 
Message-ID: <[e-mail]>
Date: Wed, 27 Oct 2004 14:24:16 +0200
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: pkix <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 14:26:21, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 14:26:23, Serialize complete at 27/10/2004 14:26:23
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,

> Denis,
> 
> Yes, SIA could be an option in SOME cases, if properly implemented and
> if combined with an appropriate directory infrastructure.

You sentence is not correct.

"SIA could be an option in SOME cases, if properly implemented and if 
combined with an appropriate *repository* infrastructure".

> It's just not as generic and cost effective as AIA in CRLs, especially
> not when building chains from bottom up, which is a common way to build
> paths.

Of course since SIA is used to build chain top down ! (which is a common way 
to build paths).

> I'm not trying to pick on words here. But for the first time I got the
> impression that you accept AIA in CRLs as a valid option.

Not exactly. AIA in CRLs COULD be a valid option.

> Do you still claim that AIA in CRLs is an invalid option that should NOT
> be allowed?

I never claimed such a sentence, so I do not need to disclaim it. :-|

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.

Upon this aspect, we are far from an agreement and this is of course 
strongly related to the (lack of a) CRL processing model.

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.

Denis

> /Stefan
>  
> 
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 27 oktober 2004 09:32
>>To: Stefan Santesson
>>Cc: pkix
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>
>>Stefan,
>>
>>
>>>Denis,
>>
>>><snip>
>>
>>>>Use of AIA in CRLs would be one way to do it, while the use of SIA
>>>>in CA certificates is the other way.
>>>
>>>I'm pleased to read that you acknowledge AIA in CRLs as a valid
>>
> option.
> 
>>>That is all I ask for.
>>
>>I'm pleased to read that you noticed that AIA *would be an option*
> 
> since I
> 
>>used "would be" in the case of AIA and "is" in the case of SIA:
>>
>>Use of AIA in CRLs *would be* one way to do it, while the use of SIA
>>in CA certificates *is* the other way.  :-)
>>
>>Denis
>>
>>
>>>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 i9RCJTNx046988; Wed, 27 Oct 2004 05:19:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RCJTjg046987; Wed, 27 Oct 2004 05:19:29 -0700 (PDT)
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 i9RCJSd8046980 for <[e-mail]>; Wed, 27 Oct 2004 05:19:28 -0700 (PDT) (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 i9RCJTD07004 for <[e-mail]>; Wed, 27 Oct 2004 14:19:29 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 27 Oct 2004 14:19:29 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9RCJSD29583 for [e-mail]; Wed, 27 Oct 2004 14:19:28 +0200 (MEST)
Date: Wed, 27 Oct 2004 14:19:28 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: 3280 issue
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 a directory which is protected by the same X509 hierarchy
it is sufficient that certificates and crls are the only 
objects (besides a trust anchor) that need to be protected
using a signature (authentoicity and integrity), since an
absence of certificats always leads to some error that can
be attributed to the repository.

In a situation with multiple paths, the absence of a CA cert
in the directory is something cannot be detected, i.e., if
some MIM or wahtever modifies the content of the transfer from
the directory, an theoretically existing cert path can simply
not be available without the possibility of detecting whether
this is intended or a failure of the directory (directory = 
whatever repository).

It seems necessary that something like signing a  
list of certificates containing all crosscerts towards
and another from other CAs is necessary to have the
analogy of a single object, i.e; to determine completeness. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RCIsAZ046853; Wed, 27 Oct 2004 05:18:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RCIsQ8046852; Wed, 27 Oct 2004 05:18:54 -0700 (PDT)
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 i9RCIqeJ046817 for <[e-mail]>; Wed, 27 Oct 2004 05:18:52 -0700 (PDT) (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, 27 Oct 2004 13:18:49 +0100
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: 3280 open issues
Date: Wed, 27 Oct 2004 13:18:49 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3280 open issues
Thread-Index: AcS6m5l4zdZx6spxT2+yTbPxkU+cdgBgUEXA
From: "Stefan Santesson" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Oct 2004 12:18:49.0648 (UTC) FILETIME=[1D667B00:01C4BC1F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RCIreJ046832
Sender: [e-mail]
Precedence: 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,

We agree on the facts.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 25 oktober 2004 15:00
> To: [e-mail]
> Subject: RE: 3280 open issues
> 
> 
> I agree on criticality.
> 
> As to the qualifiers, they are output for use by the RP (client); they
> should be kept in order to comply with X.509
> 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On
> Behalf Of Stefan Santesson
> Sent: Monday, October 25, 2004 4:45 AM
> To: Peter Sylvester; [e-mail]
> Subject: RE: 3280 open issues
> 
> 
> 
> More so,
> 
> The qualifier set isn't used anywhere either.
> 
> Test for criticality is part of 3280 path validation, but as Peter
points
> out, it doesn't require use of the criticality indicator as part of
the
> process.
> 
> You could in fact create a compliant path validation algorithm by
> completely
> remove the qualifier set and criticality indicator from the policy
tree,
> which would make the algorithm more clean.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On Behalf Of Peter Sylvester
> > Sent: den 22 oktober 2004 17:47
> > To: [e-mail]
> > Subject: 3280 open issues
> >
> >
> >
> > To repeat it:
> >
> > The current validation algorith in 3280 contain a table
> >
> >               +----------------+
> >               |   anyPolicy    |   <---- valid_policy
> >               +----------------+
> >               |       {}       |   <---- qualifier_set
> >               +----------------+
> >               |     FALSE      |   <---- criticality_indicator
> >               +----------------+
> >               |  {anyPolicy}   |   <---- expected_policy_set
> >               +----------------+
> >
> > but it seems to me that nowhere the criticality_indicator
> > is used at all which is normal because treatment is independant of
> > that.
> >
> > There are several places to copy some value and to set it according
> > the criticality of policy mapping but still no usage.
> >
> > it seems that this is a left over from a treatment which had been
> > abandonned in order to be aligned with an X509 defect report
> resolution.
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RC7Mw3044396; Wed, 27 Oct 2004 05:07:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RC7Mko044395; Wed, 27 Oct 2004 05:07:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mizar.origin-it.net (mail.de.atosorigin.com [194.8.96.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RC7KaI044347 for <[e-mail]>; Wed, 27 Oct 2004 05:07:21 -0700 (PDT) (envelope-from [e-mail])
Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68]) by mizar.origin-it.net (8.13.1/8.13.1/hmo30jul04) with ESMTP id i9RC6whp082840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2004 14:07:01 +0200 (CEST) (envelope-from [e-mail])
Received: from ascalon.mpn.de.int.atosorigin.com (ascalon.mpn.de.int.atosorigin.com [161.90.190.36]) by matar.hbg.de.int.atosorigin.com (8.13.1/8.13.1/hmo30jul04) with ESMTP id i9RC6uso008623; Wed, 27 Oct 2004 14:06:56 +0200 (CEST) (envelope-from [e-mail])
Received: by ascalon.mpn.de.int.atosorigin.com with Internet Mail Service (5.5.2653.19) id <VWR83XV5>; Wed, 27 Oct 2004 14:06:56 +0200
Message-ID: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: AW: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Wed, 27 Oct 2004 14:06:55 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 i9RC7LaI044390
Sender: [e-mail]
Precedence: 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 below 


> -----Ursprüngliche Nachricht-----
> Von: Jean-Marc Desperrier [mailto:[e-mail]]
> Gesendet: Mittwoch, 27. Oktober 2004 13:18
> An: [e-mail]
> Betreff: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> Denis Pinkas wrote:
> 
> > 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".
> 
> 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.

Jean-Marc, what do you mean by "creating two CAs with the same DN"? What you
mean is to "create two certificates containing the same DN". And this means
both certificates belong to the same CA. This is IMHO useful e. g. for key
turnover. The fraud you mentioned below is only applicable on TAs. The
naming of subordinate CAs is within the responsibility of the certificate
issuing CA(TA). In the case of TAs you will ever have the problem, that
somebody may create a certificate with the TAs DN an publish it.

Regards

Thomas Beckmann

> 
> But that the pkix Internet profile has to envision cases 
> where it's will 
> not be possible to absolutly garantee this will never happen and 
> therefore must protect itself against the security issues 
> raised by such 
> a situation and impose more stringent rules for certification 
> paths that 
> wil properly handle even that case.
> 
> One interesting question this raises is the following :
> If we don't consider the restriction we need for pkix, what 
> would be the 
> X509 compliant way to handle the case where you have two CA 
> certificates 
> with the same DN inside separate certification path ?
> I see two possible answer :
> - This is forbidden, and one or both of the certificates should be 
> handled as invalid when a client discovers such a case.
> - They validly cover the same CA, and validation may be made using 
> either path.
> 
> What is raised here is that the second solution is not acceptable for 
> pkix, because it makes it possible for anybody who was given the 
> autority to emit a CA certificate to impersonate any other CA in the 
> hirarchy.
> Several aspects of X509 make me believe it's not really intended for 
> X509 either.
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RC2L6C043477; Wed, 27 Oct 2004 05:02:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RC2Lms043476; Wed, 27 Oct 2004 05:02:21 -0700 (PDT)
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 i9RC2KTm043434 for <[e-mail]>; Wed, 27 Oct 2004 05:02:20 -0700 (PDT) (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 i9RC2FBF509048; Wed, 27 Oct 2004 08:02:15 -0400
Received: from d01ml062.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 i9RC2EPe275610; Wed, 27 Oct 2004 08:02:15 -0400
In-Reply-To: <[e-mail]>
To: Tim Polk <[e-mail]>, [e-mail]
Cc: Denis Pinkas <[e-mail]>, [e-mail]
MIME-Version: 1.0
Subject: Re: Call for 3280 issues (was Re: PKIX agenda requests)
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 27 Oct 2004 08:01:46 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.5.3 HF1|October 13, 2004) at 10/27/2004 08:02:14, Serialize complete at 10/27/2004 08:02:14
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>

        Tim, David:

        Is the question of whether constraint values should be permitted 
in the "Initialization" step of standard path validation within scope for 
this effort?  I realize that to avoid declaring existing implementations 
non-conformant we would need to make support for this feature optional. 
There don't appear to be any serious compatibility issues, at least to me.

                Tom Gindin






Tim Polk <[e-mail]>
Sent by: [e-mail]
10/25/2004 11:30 AM
 
        To:     Denis Pinkas <[e-mail]>, [e-mail]
        cc:     [e-mail]
        Subject:        Call for 3280 issues (was Re: PKIX agenda 
requests)



Denis,

Thank you for raising this issue.  3280bis will certainly be on the agenda 

at the 61st IETF, but I had forgotten to post a call for issues.

Here is a preview of the 3280bis discussion:
(1) I have volunteered David Cooper as lead editor for 3280bis. ISO-PKIX 
consistency is a key issue, and David was a key contributor in both 
arenas.
(2) David is assembling an issues list from old PKIX mailing list traffic, 

as well as issues that had been pointed out to the 3280 editors.
(3) Steve and I have assembled a small design team to publish the -00 
draft.   The group includes product expertise as well as former ISO and 
PKIX editors.
(4) When the -00 draft is published, David will also post the list of 
issues and how they were resolved.  This will let the WG quickly identify 
modifications to the text, and the rationale.

We need all WG members to document and submit any issues that need to be 
addressed in RFC 3280.  Note that the scope of this effort is limited to 
clarification of existing features where required to achieve 
interoperability or maintain consistency with ISO X.509, and removal of 
features where two implementations did not exist.  New features would 
jeopardize the progression from Draft to Proposed.

Issues may be submitted to the list, but please CC David Cooper at 
[e-mail] on any issues lists!

Thanks,

Tim


At 04:26 PM 10/22/2004 +0200, Denis Pinkas wrote:
>Tim,
>
>Since you are listening and asking for agenda topics, revision of RFC 
3280 
>should be a top priority item on the list.
>
>It is time to start the writing of a draft document which summarizes all 
>the candidate changes which should be done to RFC 3280.
>
>Then would you also ask if there are co-editors volunteer to write 
>son-of-RFC 3280 ?
>
>Denis
>
>>Folks,
>>PKIX is scheduled for Wednesday November 10, 1 - 3:00 PM at the 60th 
IETF 
>>(in Washington).
>>I spaced on agenda requests, and the time for WG agenda submissions is 
>>winding down.  My apologies about the late notice, but I would like to 
>>submit a draft agenda next Monday by the noon deadline.
>>Please send me your agenda requests as soon as possible.  I will as 
>>always give preference to WG documents, but will try to fit in related 
>>personal drafts and liasion presentations.
>>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 i9RC1wGo043349; Wed, 27 Oct 2004 05:01:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RC1w7X043348; Wed, 27 Oct 2004 05:01:58 -0700 (PDT)
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 i9RC1uuP043336 for <[e-mail]>; Wed, 27 Oct 2004 05:01:57 -0700 (PDT) (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, 27 Oct 2004 13:01:53 +0100
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: Signer certificate discovery for CRLs
Date: Wed, 27 Oct 2004 13:01:52 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcS8AjmBlbQsMeh0S7CadBSfbRKNqgAGEuKg
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 27 Oct 2004 12:01:53.0761 (UTC) FILETIME=[BFE26D10:01C4BC1C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RC1vuP043343
Sender: [e-mail]
Precedence: 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,

Yes, SIA could be an option in SOME cases, if properly implemented and
if combined with an appropriate directory infrastructure.

It's just not as generic and cost effective as AIA in CRLs, especially
not when building chains from bottom up, which is a common way to build
paths.

I'm not trying to pick on words here. But for the first time I got the
impression that you accept AIA in CRLs as a valid option.

Do you still claim that AIA in CRLs is an invalid option that should NOT
be allowed?

/Stefan
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Denis Pinkas
> Sent: den 27 oktober 2004 09:32
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Stefan,
> 
> > Denis,
> 
> > <snip>
> 
> >>Use of AIA in CRLs would be one way to do it, while the use of SIA
> >>in CA certificates is the other way.
> 
> > I'm pleased to read that you acknowledge AIA in CRLs as a valid
option.
> > That is all I ask for.
> 
> I'm pleased to read that you noticed that AIA *would be an option*
since I
> used "would be" in the case of AIA and "is" in the case of SIA:
> 
> Use of AIA in CRLs *would be* one way to do it, while the use of SIA
> in CA certificates *is* the other way.  :-)
> 
> Denis
> 
> > 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 i9RC1rVi043334; Wed, 27 Oct 2004 05:01:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RC1rGe043333; Wed, 27 Oct 2004 05:01:53 -0700 (PDT)
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 i9RC1oRh043295 for <[e-mail]>; Wed, 27 Oct 2004 05:01:51 -0700 (PDT) (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 OAA39710; Wed, 27 Oct 2004 14:13:28 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102714013790:457 ; Wed, 27 Oct 2004 14:01:37 +0200 
Message-ID: <[e-mail]>
Date: Wed, 27 Oct 2004 13:59:32 +0200
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: Jean-Marc Desperrier <[e-mail]>
CC: [e-mail]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
References: <00e901c4bb3e$becdeeb0$[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 27/10/2004 14:01:37, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 14:01:38, Serialize complete at 27/10/2004 14:01:38
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>

Jean-Marc,

> Denis Pinkas wrote:

>> 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".

You cut the original message I sent and thus you missed the explanation.
See later down.

> 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.

> But that the pkix Internet profile has to envision cases where it's will 
> not be possible to absolutly garantee this will never happen and 
> therefore must protect itself against the security issues raised by such 
> a situation and impose more stringent rules for certification paths that 
> wil properly handle even that case.

> One interesting question this raises is the following :
> If we don't consider the restriction we need for pkix, what would be the 
> X509 compliant way to handle the case where you have two CA certificates 
> with the same DN inside separate certification path ?

It is perfectly allowed to have two CA certificates with the same CA DN 
inside which do not refer to the same CA (i.e.entity).

> I see two possible answer :
> - This is forbidden, and one or both of the certificates should be 
> handled as invalid when a client discovers such a case.

No, since this is allowed.

> - They validly cover the same CA, and validation may be made using 
> either path.

This is neither true.

The sentence you cut provides you with the explanation:

"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."

The single rule is: every CA MUST never assign the same DN to two different 
entities.

Denis

> What is raised here is that the second solution is not acceptable for 
> pkix, because it makes it possible for anybody who was given the 
> autority to emit a CA certificate to impersonate any other CA in the 
> hirarchy.
> Several aspects of X509 make me believe it's not really intended for 
> X509 either.
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RBIGYp029571; Wed, 27 Oct 2004 04:18:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RBIGEF029570; Wed, 27 Oct 2004 04:18:16 -0700 (PDT)
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 i9RBIEL4029493 for <[e-mail]>; Wed, 27 Oct 2004 04:18:15 -0700 (PDT) (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 i9RBI4F03820 for <[e-mail]>; Wed, 27 Oct 2004 13:18:09 +0200
Message-ID: <[e-mail]>
Date: Wed, 27 Oct 2004 13:18:04 +0200
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: Briefing on CRL Path for IETF PKIX WG Meeting
References: <00e901c4bb3e$becdeeb0$[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>

Denis Pinkas wrote:

> 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".

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.

But that the pkix Internet profile has to envision cases where it's will 
not be possible to absolutly garantee this will never happen and 
therefore must protect itself against the security issues raised by such 
a situation and impose more stringent rules for certification paths that 
wil properly handle even that case.

One interesting question this raises is the following :
If we don't consider the restriction we need for pkix, what would be the 
X509 compliant way to handle the case where you have two CA certificates 
with the same DN inside separate certification path ?
I see two possible answer :
- This is forbidden, and one or both of the certificates should be 
handled as invalid when a client discovers such a case.
- They validly cover the same CA, and validation may be made using 
either path.

What is raised here is that the second solution is not acceptable for 
pkix, because it makes it possible for anybody who was given the 
autority to emit a CA certificate to impersonate any other CA in the 
hirarchy.
Several aspects of X509 make me believe it's not really intended for 
X509 either.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R9Uwxo077657; Wed, 27 Oct 2004 02:30:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R9UwIg077656; Wed, 27 Oct 2004 02:30:58 -0700 (PDT)
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 i9R9Uu9J077589 for <[e-mail]>; Wed, 27 Oct 2004 02:30:57 -0700 (PDT) (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 LAA32636; Wed, 27 Oct 2004 11:42:33 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102711304292:399 ; Wed, 27 Oct 2004 11:30:42 +0200 
Message-ID: <[e-mail]>
Date: Wed, 27 Oct 2004 11:28:37 +0200
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: <00e901c4bb3e$becdeeb0$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 11:30:42, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 11:30:44, Serialize complete at 27/10/2004 11:30: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:

> 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".

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.

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.

Before diving into the details of algorithms for CRL path processing, it is 
important to agree on which cases we will cover.

The case where the AC is the CRL Issuer is easy when it is the same key.

The case where the AC is the CRL Issuer but there has been a key change is 
already more complex.

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),

   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).

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.

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.

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.

Denis

> Santosh Chokhani
> Orion Security Solutions, Inc.
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> [phone]  Ext. 35 (voice)
> [phone] (Fax)
> [e-mail]
> Visit our Web site
> http://www.orionsec.com <http://www.orionsec.com/>





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R7ufes033096; Wed, 27 Oct 2004 00:56:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R7uf5K033095; Wed, 27 Oct 2004 00:56:41 -0700 (PDT)
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 i9R7udbL033047 for <[e-mail]>; Wed, 27 Oct 2004 00:56:40 -0700 (PDT) (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 KAA21704; Wed, 27 Oct 2004 10:08:12 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102709562024:344 ; Wed, 27 Oct 2004 09:56:20 +0200 
Message-ID: <[e-mail]>
Date: Wed, 27 Oct 2004 09:54:14 +0200
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], [e-mail]
CC: Peter Sylvester <[e-mail]>, [e-mail]
Subject: Re: PKIX WG Agenda for 61st IETF
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 09:56:20, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 09:56:22, Serialize complete at 27/10/2004 09:56: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>

Tim and Steve,

I fully support Peter.

Starting to issue a -00 version for 3280bis would not be a good solution.

What we first need is the list of compiled issues and publish that list as 
an Internet Draft knowing that it will not be transformed into an RFC but 
will be used later on to build 3280bis-00.

Denis


>>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.)


> Tim, could you please tell a little bit more on the mailing list.
> The only information seen so far is in the presentation of San Diego
> which seems to list the same status *and* more, since it says that
> "list of issues compiled". 
> 
> waht is the probablity of success of "Draft -00 is expected late in 2004."
> compared to waht has been in the S.D. slides.
> 
> Since the list has been compiled, it could possible to show it somehow,
> and not just a digested version in a new draft for which it may be difficult
> to find where an issues has been treated (and ignored for whatever
> reason) or forgotten.  





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R7XlSF023208; Wed, 27 Oct 2004 00:33:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R7Xl2O023207; Wed, 27 Oct 2004 00:33:47 -0700 (PDT)
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 i9R7Xjht023155 for <[e-mail]>; Wed, 27 Oct 2004 00:33:46 -0700 (PDT) (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 JAA29328; Wed, 27 Oct 2004 09:45:27 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102709333608:330 ; Wed, 27 Oct 2004 09:33:36 +0200 
Message-ID: <[e-mail]>
Date: Wed, 27 Oct 2004 09:31:30 +0200
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: pkix <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 09:33:36, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 09:33:38, Serialize complete at 27/10/2004 09:33:38
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,

> Denis,

> <snip>

>>Use of AIA in CRLs would be one way to do it, while the use of SIA
>>in CA certificates is the other way.

> I'm pleased to read that you acknowledge AIA in CRLs as a valid option.
> That is all I ask for.

I'm pleased to read that you noticed that AIA *would be an option* since I 
used "would be" in the case of AIA and "is" in the case of SIA:

Use of AIA in CRLs *would be* one way to do it, while the use of SIA
in CA certificates *is* the other way.  :-)

Denis

> 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 i9R2DmiF005617; Tue, 26 Oct 2004 19:13:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R2Dmxr005613; Tue, 26 Oct 2004 19:13:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from usea-naimss1.unisys.com (usea-naimss1.unisys.com [192.61.61.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R2Dlkn005539 for <[e-mail]>; Tue, 26 Oct 2004 19:13:47 -0700 (PDT) (envelope-from [e-mail])
Received: from usea-nagw2.na.uis.unisys.com ([129.224.72.18]unverified) by usea-naimss1 with InterScan Messaging Security Suite; Tue, 26 Oct 2004 20:30:27 -0500
Received: from usea-nagw2.na.uis.unisys.com ([129.224.72.53]) by usea-nagw2.na.uis.unisys.com with Microsoft SMTPSVC(6.0.3790.47); Tue, 26 Oct 2004 20:20:34 -0500
Received: from mail pickup service by usea-nagw2.na.uis.unisys.com with Microsoft SMTPSVC; Tue, 26 Oct 2004 20:13:53 -0500
Received: from usea-naimss1.unisys.com ([192.61.61.103]) by usea-nagw2.na.uis.unisys.com with Microsoft SMTPSVC(6.0.3790.47); Tue, 26 Oct 2004 17:09:06 -0500
Received: from above.proper.com ([208.184.76.39]) by usea-naimss1 with InterScan Messaging Security Suite; Tue, 26 Oct 2004 16:54:44 -0500
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL0m6s034998; Tue, 26 Oct 2004 14:00:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QL0mbf034997; Tue, 26 Oct 2004 14:00:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL0kO8034979 for <[e-mail]>; Tue, 26 Oct 2004 14:00:47 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20522; Tue, 26 Oct 2004 17:00:48 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-16.txt
Date: Tue, 26 Oct 2004 17:00:48 -0400
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 26 Oct 2004 22:09:18.0222 (UTC) FILETIME=[70101AE0:01C4BBA8]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-16.txt
	Pages		: 73
	Date		: 2004-10-26
	
SCVP allows a client to offload certificate handling to a server.  
The server can provide the client with a variety of valuable 
information about the certificate, such as whether the certificate 
is valid, a certification path to a trust anchor, and revocation 
status.  SCVP has many purposes, including simplifying client 
implementations and allowing companies to centralize trust and 
policy management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-16.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-scvp-16.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-scvp-16.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-16.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-scvp-16.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL0m6s034998; Tue, 26 Oct 2004 14:00:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QL0mbf034997; Tue, 26 Oct 2004 14:00:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QL0kO8034979 for <[e-mail]>; Tue, 26 Oct 2004 14:00:47 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20522; Tue, 26 Oct 2004 17:00:48 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-16.txt
Date: Tue, 26 Oct 2004 17:00:48 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-16.txt
	Pages		: 73
	Date		: 2004-10-26
	
SCVP allows a client to offload certificate handling to a server.  
The server can provide the client with a variety of valuable 
information about the certificate, such as whether the certificate 
is valid, a certification path to a trust anchor, and revocation 
status.  SCVP has many purposes, including simplifying client 
implementations and allowing companies to centralize trust and 
policy management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-16.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-scvp-16.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-scvp-16.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-16.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-scvp-16.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9QBHk3d074016; Tue, 26 Oct 2004 04:17:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9QBHkBZ074015; Tue, 26 Oct 2004 04:17:46 -0700 (PDT)
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 i9QBHejv073939 for <[e-mail]>; Tue, 26 Oct 2004 04:17:41 -0700 (PDT) (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, 26 Oct 2004 12:17:34 +0100
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: Signer certificate discovery for CRLs
Date: Tue, 26 Oct 2004 12:17:30 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcS4RHmBBSYrIVvrRdyY5yeZCi416gDB9JFg
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Santosh Chokhani" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 26 Oct 2004 11:17:34.0996 (UTC) FILETIME=[64B95540:01C4BB4D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9QBHfjv073988
Sender: [e-mail]
Precedence: 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>
> Use of AIA in CRLs would be one way to do it, while the use of SIA
> in CA certificates is the other way.
>

I'm pleased to read that you acknowledge AIA in CRLs as a valid option.
That is all I ask for.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 22 oktober 2004 16:37
> To: Stefan Santesson; Santosh Chokhani
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan and Santosh,
> 
> > Denis,
> 
> > Thanks for the collection of relevant quotes.
> 
> > The case described may be odd but as far as I know, not violating
any
> > current text in RFC 3280 or X.509.
> 
> > A CA nominates a CRL by information in the CDP extension in the
cert,
> > not by issuing a cert to the CRL issuer. Where can you find that the
> > latter is a requirement? At least not in any of the sections you
quote.
> 
> > Regardless of this, the truth expressed by Santosh stands. Use of
AIA in
> > CRLs is more generic and provides less coding complexity.
> 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> 
> Conformity of CRL revocation checking to RFC 3280 through vagueness
> (your argument saying the content of the document does not violate
> any current text) is not the way to guaranty interoperability.
> 
> The description present in the document shall be sufficient to allow
> two different implementation to interoperate.
> 
> RFC 3280 is supposed to be a "standards track" document which means
> that it has also to conform with the draft standard requirements
> expressed in RFC 2026, which are:
> 
> 4.1.2  Draft Standard
> 
>     A specification from which at least two independent and
interoperable
>     implementations from different code bases have been developed, and
>     for which sufficient successful operational experience has been
>     obtained, may be elevated to the "Draft Standard" level.  For the
>     purposes of this section, "interoperable" means to be functionally
>     equivalent or interchangeable components of the system or process
in
>     which they are used.
> 
> (..)
> 
>     A Draft Standard must be well-understood and known to be quite
>     stable, both in its semantics and as a basis for developing an
>     implementation.
> 
> RFC 3280 is supposed to be a standards track document which means,
> according to RFC 2026, that :
> 
>     A Proposed Standard should have no known technical omissions with
>     respect to the requirements placed upon it.
> 
> However CRL processing has technical omissions which should be fixed.
> 
> Since Tim is listening and asking for agenda topics, revision of RFC
3280
> should be a top priority item on the list.
> 
> It is time to start the writing of a document which summarizes all
> the candidate changes which should be done to RFC 3280.
> 
> In addition, the "truth expressed by Santosh" does NOT stand.
> Use of AIA in CRLs would be one way to do it, while the use of SIA
> in CA certificates is the other way.
> 
> 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 i9Q9WkqS033694; Tue, 26 Oct 2004 02:32:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9Q9WkDg033693; Tue, 26 Oct 2004 02:32:46 -0700 (PDT)
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 i9Q9Wjf8033670 for <[e-mail]>; Tue, 26 Oct 2004 02:32:45 -0700 (PDT) (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 i9Q9WhHt024127 for <[e-mail]>; Tue, 26 Oct 2004 05:32:43 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: Briefing on CRL Path for IETF PKIX WG Meeting
Date: Tue, 26 Oct 2004 05:32:38 -0400
Message-ID: <00e901c4bb3e$becdeeb0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EA_01C4BB1D.37BC4EB0"
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_00EA_01C4BB1D.37BC4EB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Denis:
 
The following URL is the location for the briefing you requested to be
posted.
 
 <http://www.orionsec.com/crldp-idp-v3.ppt>
www.orionsec.com/crldp-idp-v3.ppt
 
Santosh Chokhani 
Orion Security Solutions, Inc. 
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101 
[phone]  Ext. 35 (voice) 
[phone] (Fax) 
[e-mail] 
Visit our Web site 
http://www.orionsec.com <http://www.orionsec.com/>  
 

------=_NextPart_000_00EA_01C4BB1D.37BC4EB0
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=3D045533009-26102004>Denis:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D045533009-26102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D045533009-26102004>The =
following URL is=20
the location for the briefing you requested to be =
posted.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><A href=3D"http://www.orionsec.com/crldp-idp-v3.ppt"><FONT =
face=3DArial=20
size=3D2>www.orionsec.com/crldp-idp-v3.ppt</FONT></A></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><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> </DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00EA_01C4BB1D.37BC4EB0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGiF7S068876; Mon, 25 Oct 2004 09:44:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PGiFQo068875; Mon, 25 Oct 2004 09:44:15 -0700 (PDT)
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 i9PGiDmP068815 for <[e-mail]>; Mon, 25 Oct 2004 09:44:13 -0700 (PDT) (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 i9PGi4D07408; Mon, 25 Oct 2004 18:44:04 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 25 Oct 2004 18:44:04 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9PGi3o22625; Mon, 25 Oct 2004 18:44:03 +0200 (MEST)
Date: Mon, 25 Oct 2004 18:44:03 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: PKIX WG Agenda for 61st IETF
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>

>> 
> 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.)
> 

Tim, could you please tell a little bit more on the mailing list.
The only information seen so far is in the presentation of San Diego
which seems to list the same status *and* more, since it says that
"list of issues compiled". 

waht is the probablity of success of "Draft -00 is expected late in 2004."
compared to waht has been in the S.D. slides.

Since the list has been compiled, it could possible to show it somehow,
and not just a digested version in a new draft for which it may be difficult
to find where an issues has been treated (and ignored for whatever
reason) or forgotten.  



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PFcfY2052754; Mon, 25 Oct 2004 08:38:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PFcfDx052753; Mon, 25 Oct 2004 08:38:41 -0700 (PDT)
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 i9PFcdvs052733 for <[e-mail]>; Mon, 25 Oct 2004 08:38:40 -0700 (PDT) (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 RAA36574; Mon, 25 Oct 2004 17:50:17 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102517382697:3225 ; Mon, 25 Oct 2004 17:38:26 +0200 
Message-ID: <[e-mail]>
Date: Mon, 25 Oct 2004 17:40:22 +0200
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: Tim Polk <[e-mail]>, [e-mail]
CC: [e-mail]
Subject: Re: PKIX WG Agenda for 61st IETF
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/10/2004 17:38:27, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/10/2004 17:38:28, Serialize complete at 25/10/2004 17:38:28
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>

Tim and Steve,

A few remarks:

Item 2.1: SCVP the draft is issued very late (we have still not received it 
at this time) so that we may reasonnably read it and raise issues. I would 
appreciate if Trevor could post his presentation before the meeting.

Item 2.2: 3280bis I would appreciate to be part of the design team.

Item 2.3: "Issues and Recommendations on CRL Processing Rules".
I would appreciate if Santosh could post his presentation before the meeting.

Item 2.4: "Discovering CRL Signer Certificates Using AIA" should be instead 
"Discovering CRL Signer Certificates Using AIA *and SIA*" and thus the draft 
should cover both AIA and SIA.

Denis

PS. Unfortunately I will not be able to attend the meeting.


> Please accept the draft agenda below for the PKIX WG at the 61st IETF 
> meeting.
> 
> Thanks,
> 
> Tim Polk
> 
> ---------------------------------------------
> 
> PKIX WG (pkix-wg)
> 
> 
> WEDNESDAY, November 10, 2004 1300-1500
> ======================================
> 
> CHAIR: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>
> 
> AGENDA:
> 
> 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-15.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 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.4 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.5 LDAP Schemas
>          David Chadwick (Univ. of Salford)
>          submitted new drafts; available soon at
>   
> 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 Algorithm IDs for Elliptic Curve Cryptography in PKIX
>         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
>         Jaehoo Yoon (KISA)
>         (new draft submitted; to be available at
>       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 i9PFRcUU050485; Mon, 25 Oct 2004 08:27:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PFRcCA050484; Mon, 25 Oct 2004 08:27:38 -0700 (PDT)
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 i9PFRaZI050477 for <[e-mail]>; Mon, 25 Oct 2004 08:27:37 -0700 (PDT) (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 i9PFQdQl004040; Mon, 25 Oct 2004 11:26:39 -0400
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 i9PFQCer003834; Mon, 25 Oct 2004 11:26:13 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 25 Oct 2004 11:30:41 -0400
To: Denis Pinkas <[e-mail]>, [e-mail]
From: Tim Polk <[e-mail]>
Subject: Call for 3280 issues (was Re: PKIX agenda requests)
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[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>

Denis,

Thank you for raising this issue.  3280bis will certainly be on the agenda 
at the 61st IETF, but I had forgotten to post a call for issues.

Here is a preview of the 3280bis discussion:
(1) I have volunteered David Cooper as lead editor for 3280bis. ISO-PKIX 
consistency is a key issue, and David was a key contributor in both arenas.
(2) David is assembling an issues list from old PKIX mailing list traffic, 
as well as issues that had been pointed out to the 3280 editors.
(3) Steve and I have assembled a small design team to publish the -00 
draft.   The group includes product expertise as well as former ISO and 
PKIX editors.
(4) When the -00 draft is published, David will also post the list of 
issues and how they were resolved.  This will let the WG quickly identify 
modifications to the text, and the rationale.

We need all WG members to document and submit any issues that need to be 
addressed in RFC 3280.  Note that the scope of this effort is limited to 
clarification of existing features where required to achieve 
interoperability or maintain consistency with ISO X.509, and removal of 
features where two implementations did not exist.  New features would 
jeopardize the progression from Draft to Proposed.

Issues may be submitted to the list, but please CC David Cooper at 
[e-mail] on any issues lists!

Thanks,

Tim


At 04:26 PM 10/22/2004 +0200, Denis Pinkas wrote:
>Tim,
>
>Since you are listening and asking for agenda topics, revision of RFC 3280 
>should be a top priority item on the list.
>
>It is time to start the writing of a draft document which summarizes all 
>the candidate changes which should be done to RFC 3280.
>
>Then would you also ask if there are co-editors volunteer to write 
>son-of-RFC 3280 ?
>
>Denis
>
>>Folks,
>>PKIX is scheduled for Wednesday November 10, 1 - 3:00 PM at the 60th IETF 
>>(in Washington).
>>I spaced on agenda requests, and the time for WG agenda submissions is 
>>winding down.  My apologies about the late notice, but I would like to 
>>submit a draft agenda next Monday by the noon deadline.
>>Please send me your agenda requests as soon as possible.  I will as 
>>always give preference to WG documents, but will try to fit in related 
>>personal drafts and liasion presentations.
>>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 i9PEtmR2046119; Mon, 25 Oct 2004 07:55:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PEtmm7046118; Mon, 25 Oct 2004 07:55:48 -0700 (PDT)
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 i9PEtk5Q046109 for <[e-mail]>; Mon, 25 Oct 2004 07:55:47 -0700 (PDT) (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 i9PEtRQl028173; Mon, 25 Oct 2004 10:55:27 -0400
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 i9PEswer008645; Mon, 25 Oct 2004 10:54:58 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 25 Oct 2004 10:59:27 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: PKIX WG Agenda for 61st IETF
Cc: [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>

Please accept the draft agenda below for the PKIX WG at the 61st IETF meeting.

Thanks,

Tim Polk

---------------------------------------------

PKIX WG (pkix-wg)


WEDNESDAY, November 10, 2004 1300-1500
======================================

CHAIR: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

AGENDA:

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-15.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 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.4 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.5 LDAP Schemas
          David Chadwick (Univ. of Salford)
          submitted new drafts; available soon at
   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 Algorithm IDs for Elliptic Curve Cryptography in PKIX
         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
         Jaehoo Yoon (KISA)
         (new draft submitted; to be available at
       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 i9PCxbp8035513; Mon, 25 Oct 2004 05:59:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PCxbXe035511; Mon, 25 Oct 2004 05:59:37 -0700 (PDT)
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 i9PCxb57035505 for <[e-mail]>; Mon, 25 Oct 2004 05:59:37 -0700 (PDT) (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 i9PCxcHt021937 for <[e-mail]>; Mon, 25 Oct 2004 08:59:38 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: 3280 open issues
Date: Mon, 25 Oct 2004 08:59:38 -0400
Message-ID: <000901c4ba92$7c885ec0$[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 i9PCxb57035506
Sender: [e-mail]
Precedence: 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 on criticality.

As to the qualifiers, they are output for use by the RP (client); they
should be kept in order to comply with X.509

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Monday, October 25, 2004 4:45 AM
To: Peter Sylvester; [e-mail]
Subject: RE: 3280 open issues



More so,

The qualifier set isn't used anywhere either.

Test for criticality is part of 3280 path validation, but as Peter points
out, it doesn't require use of the criticality indicator as part of the
process.

You could in fact create a compliant path validation algorithm by completely
remove the qualifier set and criticality indicator from the policy tree,
which would make the algorithm more clean.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Peter Sylvester
> Sent: den 22 oktober 2004 17:47
> To: [e-mail]
> Subject: 3280 open issues
> 
> 
> 
> To repeat it:
> 
> The current validation algorith in 3280 contain a table
> 
>               +----------------+
>               |   anyPolicy    |   <---- valid_policy
>               +----------------+
>               |       {}       |   <---- qualifier_set
>               +----------------+
>               |     FALSE      |   <---- criticality_indicator
>               +----------------+
>               |  {anyPolicy}   |   <---- expected_policy_set
>               +----------------+
> 
> but it seems to me that nowhere the criticality_indicator
> is used at all which is normal because treatment is independant of
> that.
> 
> There are several places to copy some value and to set it according
> the criticality of policy mapping but still no usage.
> 
> it seems that this is a left over from a treatment which had been
> abandonned in order to be aligned with an X509 defect report
resolution.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P9dHin083665; Mon, 25 Oct 2004 02:39:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P9dHGd083664; Mon, 25 Oct 2004 02:39:17 -0700 (PDT)
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 i9P9dGrs083600 for <[e-mail]>; Mon, 25 Oct 2004 02:39:17 -0700 (PDT) (envelope-from [e-mail])
Received: from IBMDD8FF125033 (cpc1-hudd3-5-0-cust65.hudd.cable.ntl.com [80.5.216.65]) by lon1-mail-2.visp.demon.net (MOS 3.4.6-GR) with ESMTP id BOE07990 (AUTH [e-mail]); Mon, 25 Oct 2004 10:38:51 +0100 (BST)
Message-Id: <[e-mail]>
From: "David W Chadwick" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: PKIX agenda requests
Date: Mon, 25 Oct 2004 10:38:46 +0100
Organization: University of Salford
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Thread-Index: AcS35Ug03Q7XcfdxTjyVFppGKUDtIgCkP69g
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim

I would like to present the LDAP schemas (for informational RFCs) for last
call as agreed at the last meeting. The final versions will be submitted to
the editor today

Regards

David


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: 22 October 2004 02:53
> To: [e-mail]
> Subject: PKIX agenda requests
> 
> 
> 
> 
> Folks,
> 
> PKIX is scheduled for Wednesday November 10, 1 - 3:00 PM at 
> the 60th IETF (in Washington).
> 
> I spaced on agenda requests, and the time for WG agenda 
> submissions is winding down.  My apologies about the late 
> notice, but I would like to submit a draft agenda next Monday 
> by the noon deadline.
> 
> Please send me your agenda requests as soon as possible.  I 
> will as always give preference to WG documents, but will try 
> to fit in related personal drafts and liasion presentations.
> 
> 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 i9P8jC42061907; Mon, 25 Oct 2004 01:45:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P8jCKW061905; Mon, 25 Oct 2004 01:45:12 -0700 (PDT)
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 i9P8jBYi061859 for <[e-mail]>; Mon, 25 Oct 2004 01:45:11 -0700 (PDT) (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); Mon, 25 Oct 2004 09:44:12 +0100
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: 3280 open issues
Date: Mon, 25 Oct 2004 09:45:00 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3280 open issues
Thread-Index: AcS4VxUX9J7r2s1lR3WxoZLdyykmHwCFy5rw
From: "Stefan Santesson" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 25 Oct 2004 08:44:12.0785 (UTC) FILETIME=[CD5D9E10:01C4BA6E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9P8jCYi061894
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

More so,

The qualifier set isn't used anywhere either.

Test for criticality is part of 3280 path validation, but as Peter
points out, it doesn't require use of the criticality indicator as part
of the process.

You could in fact create a compliant path validation algorithm by
completely remove the qualifier set and criticality indicator from the
policy tree, which would make the algorithm more clean.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Peter Sylvester
> Sent: den 22 oktober 2004 17:47
> To: [e-mail]
> Subject: 3280 open issues
> 
> 
> 
> To repeat it:
> 
> The current validation algorith in 3280 contain a table
> 
>               +----------------+
>               |   anyPolicy    |   <---- valid_policy
>               +----------------+
>               |       {}       |   <---- qualifier_set
>               +----------------+
>               |     FALSE      |   <---- criticality_indicator
>               +----------------+
>               |  {anyPolicy}   |   <---- expected_policy_set
>               +----------------+
> 
> but it seems to me that nowhere the criticality_indicator
> is used at all which is normal because treatment is independant
> of that.
> 
> There are several places to copy some value and to set it according
> the criticality of policy mapping but still no usage.
> 
> it seems that this is a left over from a treatment which had been
> abandonned in order to be aligned with an X509 defect report
resolution.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P7MeBX033007; Mon, 25 Oct 2004 00:22:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P7Meou033005; Mon, 25 Oct 2004 00:22:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from worldcall.net.pk (mail.worldcall.net.pk [203.81.192.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P7Mc7d032950 for <[e-mail]>; Mon, 25 Oct 2004 00:22:39 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.222.209]) by worldcall.net.pk (8.13.0/8.13.0) with SMTP id i9P7N0x0016037; Mon, 25 Oct 2004 12:23:06 +0500
Message-ID: <003e01c4ba63$3dae53a0$[e-mail]>
From: "Faisal Maqsood" <[e-mail]>
To: <[e-mail]>, "Trevor Freeman" <[e-mail]>
References: <[e-mail]>
Subject: Re: scvp 16 status
Date: Mon, 25 Oct 2004 12:21:20 +0500
Organization: Ascertia Ltd
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C4BA8D.225CF910"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Scanned-By: MIMEDefang 2.44
Sender: [e-mail]
Precedence: 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_003B_01C4BA8D.225CF910
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes please send me the marked up version.

Regards,
Faisal
  ----- Original Message -----=20
  From: Trevor Freeman=20
  To: [e-mail]=20
  Sent: Monday, October 25, 2004 11:45
  Subject: scvp 16 status


  SCVP 16 has been posted to the RFC editors.



  The volume of comments which were forthcoming following San Diego has =
generated a large number of edits to the document. If anyone is =
interested I have a marked up word version of the delta from SCVP 15. If =
you are interested in receiving that version just little r me.

  Thanks

  Trevor


------=_NextPart_000_003B_01C4BA8D.225CF910
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: Device Font 10cpi;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 0pt 201.0pt 0pt 0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Device Font 10cpi"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Device Font 10cpi"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Device Font 10cpi"
}
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
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Yes please send me the marked up=20
version.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Faisal</FONT></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 arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">Trevor Freeman</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, October 25, 2004=20
11:45</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> scvp 16 status</DIV>
  <DIV><BR></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">SCVP 16 has been posted =
to the RFC=20
  editors.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The volume of comments =
which were=20
  forthcoming following San Diego has generated a large number of edits =
to the=20
  document. If anyone is interested I have a marked up word version of =
the delta=20
  from SCVP 15. If you are interested in receiving that version just =
little r=20
  me.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thanks</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Trevor</SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_003B_01C4BA8D.225CF910--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P6jNUE020088; Sun, 24 Oct 2004 23:45:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P6jN9w020087; Sun, 24 Oct 2004 23:45:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.76.151] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P6jG0T020021 for <[e-mail]>; Sun, 24 Oct 2004 23:45:23 -0700 (PDT) (envelope-from [e-mail])
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Oct 2004 23:45:01 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Oct 2004 23:45:18 -0700
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_01C4BA5E.2B9B9849"
Subject: scvp 16 status
Date: Sun, 24 Oct 2004 23:45:09 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: scvp 16 status
thread-index: AcS6Xiuywu9+odH8S1aA/vxeAFXdkA==
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 25 Oct 2004 06:45:18.0175 (UTC) FILETIME=[30CE86F0:01C4BA5E]
Sender: [e-mail]
Precedence: 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_01C4BA5E.2B9B9849
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

SCVP 16 has been posted to the RFC editors.

=20

The volume of comments which were forthcoming following San Diego has
generated a large number of edits to the document. If anyone is
interested I have a marked up word version of the delta from SCVP 15. If
you are interested in receiving that version just little r me.

Thanks

Trevor


------_=_NextPart_001_01C4BA5E.2B9B9849
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:"Device Font 10cpi";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Device Font 10cpi";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:0pt 201.0pt 0pt 0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US 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'>SCVP 16 has been posted to the RFC =
editors.</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'>The volume of comments which were forthcoming =
following San Diego has generated a large number of edits to the =
document. If anyone is interested I
have a marked up word version of the delta from SCVP 15. If you are =
interested in
receiving that version just little r me.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Trevor</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C4BA5E.2B9B9849--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MFlOYo058218; Fri, 22 Oct 2004 08:47:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MFlOCw058217; Fri, 22 Oct 2004 08:47:24 -0700 (PDT)
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 i9MFlNHS058209 for <[e-mail]>; Fri, 22 Oct 2004 08:47:23 -0700 (PDT) (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 i9MFlPD24939 for <[e-mail]>; Fri, 22 Oct 2004 17:47:25 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 22 Oct 2004 17:47:25 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9MFlPL13526 for [e-mail]; Fri, 22 Oct 2004 17:47:25 +0200 (MEST)
Date: Fri, 22 Oct 2004 17:47:25 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: 3280 open issues
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>

To repeat it:

The current validation algorith in 3280 contain a table

              +----------------+
              |   anyPolicy    |   <---- valid_policy
              +----------------+
              |       {}       |   <---- qualifier_set
              +----------------+
              |     FALSE      |   <---- criticality_indicator
              +----------------+
              |  {anyPolicy}   |   <---- expected_policy_set
              +----------------+

but it seems to me that nowhere the criticality_indicator
is used at all which is normal because treatment is independant
of that. 

There are several places to copy some value and to set it according
the criticality of policy mapping but still no usage.

it seems that this is a left over from a treatment which had been
abandonned in order to be aligned with an X509 defect report resolution. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MFfu6D057730; Fri, 22 Oct 2004 08:41:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MFfusk057729; Fri, 22 Oct 2004 08:41:56 -0700 (PDT)
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 i9MFftWI057721 for <[e-mail]>; Fri, 22 Oct 2004 08:41:55 -0700 (PDT) (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 i9MFflj0019400 for <[e-mail]>; Fri, 22 Oct 2004 11:41:55 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Fri, 22 Oct 2004 11:41:47 -0400
Message-ID: <011501c4b84d$a8c8a1d0$[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 i9MFftWI057724
Sender: [e-mail]
Precedence: 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 I read 3280 and add the suggestions I and others have made, I find RFC
3280 compliant implementations to provides secure, interoperable, consistent
(i.e., adventitial results). 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Friday, October 22, 2004 10:37 AM
To: Stefan Santesson; Santosh Chokhani
Cc: pkix
Subject: Re: Signer certificate discovery for CRLs



Stefan and Santosh,

> Denis,

> Thanks for the collection of relevant quotes.

> The case described may be odd but as far as I know, not violating any 
> current text in RFC 3280 or X.509.

> A CA nominates a CRL by information in the CDP extension in the cert, 
> not by issuing a cert to the CRL issuer. Where can you find that the 
> latter is a requirement? At least not in any of the sections you 
> quote.

> Regardless of this, the truth expressed by Santosh stands. Use of AIA 
> in CRLs is more generic and provides less coding complexity.

> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)

Conformity of CRL revocation checking to RFC 3280 through vagueness (your
argument saying the content of the document does not violate any current
text) is not the way to guaranty interoperability.

The description present in the document shall be sufficient to allow two
different implementation to interoperate.

RFC 3280 is supposed to be a "standards track" document which means that it
has also to conform with the draft standard requirements expressed in RFC
2026, which are:

4.1.2  Draft Standard

    A specification from which at least two independent and interoperable
    implementations from different code bases have been developed, and
    for which sufficient successful operational experience has been
    obtained, may be elevated to the "Draft Standard" level.  For the
    purposes of this section, "interoperable" means to be functionally
    equivalent or interchangeable components of the system or process in
    which they are used.

(..)

    A Draft Standard must be well-understood and known to be quite
    stable, both in its semantics and as a basis for developing an
    implementation.

RFC 3280 is supposed to be a standards track document which means, according
to RFC 2026, that :

    A Proposed Standard should have no known technical omissions with
    respect to the requirements placed upon it.

However CRL processing has technical omissions which should be fixed.

Since Tim is listening and asking for agenda topics, revision of RFC 3280
should be a top priority item on the list.

It is time to start the writing of a document which summarizes all the
candidate changes which should be done to RFC 3280.

In addition, the "truth expressed by Santosh" does NOT stand. Use of AIA in
CRLs would be one way to do it, while the use of SIA in CA certificates is
the other way.

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 i9MEaFL3050445; Fri, 22 Oct 2004 07:36:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MEaFrK050444; Fri, 22 Oct 2004 07:36:15 -0700 (PDT)
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 i9MEaEJZ050424 for <[e-mail]>; Fri, 22 Oct 2004 07:36:14 -0700 (PDT) (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 QAB08368; Fri, 22 Oct 2004 16:47:50 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102216360386:1792 ; Fri, 22 Oct 2004 16:36:03 +0200 
Message-ID: <[e-mail]>
Date: Fri, 22 Oct 2004 16:36:58 +0200
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]>, Santosh Chokhani <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/10/2004 16:36:03, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/10/2004 16:36:07, Serialize complete at 22/10/2004 16:36:07
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 and Santosh,

> Denis,

> Thanks for the collection of relevant quotes.

> The case described may be odd but as far as I know, not violating any
> current text in RFC 3280 or X.509.

> A CA nominates a CRL by information in the CDP extension in the cert,
> not by issuing a cert to the CRL issuer. Where can you find that the
> latter is a requirement? At least not in any of the sections you quote.

> Regardless of this, the truth expressed by Santosh stands. Use of AIA in
> CRLs is more generic and provides less coding complexity.

> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)

Conformity of CRL revocation checking to RFC 3280 through vagueness
(your argument saying the content of the document does not violate
any current text) is not the way to guaranty interoperability.

The description present in the document shall be sufficient to allow
two different implementation to interoperate.

RFC 3280 is supposed to be a "standards track" document which means
that it has also to conform with the draft standard requirements
expressed in RFC 2026, which are:

4.1.2  Draft Standard

    A specification from which at least two independent and interoperable
    implementations from different code bases have been developed, and
    for which sufficient successful operational experience has been
    obtained, may be elevated to the "Draft Standard" level.  For the
    purposes of this section, "interoperable" means to be functionally
    equivalent or interchangeable components of the system or process in
    which they are used.

(..)

    A Draft Standard must be well-understood and known to be quite
    stable, both in its semantics and as a basis for developing an
    implementation.

RFC 3280 is supposed to be a standards track document which means,
according to RFC 2026, that :

    A Proposed Standard should have no known technical omissions with
    respect to the requirements placed upon it.

However CRL processing has technical omissions which should be fixed.

Since Tim is listening and asking for agenda topics, revision of RFC 3280
should be a top priority item on the list.

It is time to start the writing of a document which summarizes all
the candidate changes which should be done to RFC 3280.

In addition, the "truth expressed by Santosh" does NOT stand.
Use of AIA in CRLs would be one way to do it, while the use of SIA
in CA certificates is the other way.

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 i9MEXNFL050118; Fri, 22 Oct 2004 07:33:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MEXN9v050117; Fri, 22 Oct 2004 07:33:23 -0700 (PDT)
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 i9MEXJno050097 for <[e-mail]>; Fri, 22 Oct 2004 07:33:19 -0700 (PDT) (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 QAA19302; Fri, 22 Oct 2004 16:44:46 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102216325965:1786 ; Fri, 22 Oct 2004 16:32:59 +0200 
Message-ID: <[e-mail]>
Date: Fri, 22 Oct 2004 16:33:54 +0200
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: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Signer certificate discovery for CRLs
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/10/2004 16:32:59, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/10/2004 16:33:01, Serialize complete at 22/10/2004 16:33:01
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,

I support your position.

>>My suggestion is base on the curent practice I am aware of, not based
>>on any spec or standard.

>>I believe that currently there is no spec to tell us what kind of objects
>>an AIA caIssuers URI will point to. The current definition of AIA in
>>RFC 3280 is too vague. I think that Stefan's proposal of
>>expanding the scope of AIA is a chance to clarify this.

> I would second the idea to put this on the list of issues for an
> update of 3280, ooups, the San Diego meeting proceedings say
> 'list of open issues compiled'. 

We need a document to list all "agreed changes" and pending issues.

>>For MIME types, RFC 2585 and RFC 2633 already defined some
>>useful types for cert, crl, or CMS/PKCS#7 object. Unfortunately,
>>related HTTP or FTP URI pointers (such as those in an AIA or a CRLDP)
>>defined in RFC 3280 have no reference to MIME types defined in RFC 2585
>>and RFC 2633.

> i'd be careful to allow different mime type together with one access method OID. 
> 
>>>Also, Peter Gutmann's new http-certstore does something completely
>>>different AFAIS.

>>Please note that I am talking about AIA not SIA. For an HTTP
>>URI in a SIA, it should follow the spec in Peter Gutmann's new
>>http-certstore proposal. I suggest that http-certstore spec should
>>have a reference to MIME types defined in RFC 2585.

> The difference is not SIA vs AIA IMO, but the format implied by 
> accessMethod (which is the same definition for SIA and AIA). 

>   " The type and
>    format of the information is specified by the accessMethod field;" 

We need to say more about the formats implied by accessMethod.
There are four possible cases :

  - it allows to retrieve one single file,
  - it allows to query for a single file in a repository,
  - it allows to query for one or more files in a repository,
  - it provides the address of a repository.

The current text is not crystal clear.

Denis

>>Wen-Cheng Wang
>>
> 
> 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 i9MEPV0f048656; Fri, 22 Oct 2004 07:25:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MEPVVn048655; Fri, 22 Oct 2004 07:25:31 -0700 (PDT)
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 i9MEPUPu048640 for <[e-mail]>; Fri, 22 Oct 2004 07:25:30 -0700 (PDT) (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 QAA17042; Fri, 22 Oct 2004 16:37:10 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102216252362:1445 ; Fri, 22 Oct 2004 16:25:23 +0200 
Message-ID: <[e-mail]>
Date: Fri, 22 Oct 2004 16:26:18 +0200
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: [e-mail]
Subject: Re: PKIX agenda requests
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/10/2004 16:25:23, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/10/2004 16:25:25, Serialize complete at 22/10/2004 16:25: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>

Tim,

Since you are listening and asking for agenda topics, revision of RFC 3280 
should be a top priority item on the list.

It is time to start the writing of a draft document which summarizes all the 
candidate changes which should be done to RFC 3280.

Then would you also ask if there are co-editors volunteer to write 
son-of-RFC 3280 ?

Denis

> Folks,
> 
> PKIX is scheduled for Wednesday November 10, 1 - 3:00 PM at the 60th IETF (in 
> Washington).
> 
> I spaced on agenda requests, and the time for WG agenda submissions is winding 
> down.  My apologies about the late notice, but I would like to submit a draft 
> agenda next Monday by the noon deadline.
> 
> Please send me your agenda requests as soon as possible.  I will as always 
> give preference to WG documents, but will try to fit in related personal 
> drafts and liasion presentations.
> 
> 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 i9MEFBV2047014; Fri, 22 Oct 2004 07:15:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MEFB78047013; Fri, 22 Oct 2004 07:15:11 -0700 (PDT)
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 i9MEF95L046997 for <[e-mail]>; Fri, 22 Oct 2004 07:15:10 -0700 (PDT) (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 QAA30980 for <[e-mail]>; Fri, 22 Oct 2004 16:26:53 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102216150629:1401 ; Fri, 22 Oct 2004 16:15:06 +0200 
Message-ID: <[e-mail]>
Date: Fri, 22 Oct 2004 16:16:01 +0200
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: pkix <[e-mail]>
Subject: Re : Signer certificate discovery for CRLs
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/10/2004 16:15:06, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 22/10/2004 16:15:07, Serialize complete at 22/10/2004 16:15:07
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=UTF-8; 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>

This is a repost of the message sent to the list on October 20.
This message was too long and thus has not been broadcasted to the list.

Since Stefan was copied, he got the message and has already provided one 
answer to it.

=========================================================================

Stefan,

[Stefan]

To save you from excessive discussions on a topic you don't really care
about, I concentrate on the one major problem with SIA that you missed
my point on:

1) How can the RP know what certificate's SIA it would use to find
these CRL signer cert?

You just picked the right certificate in my example since I gave that
information in the example. But the RP don't know that path, it only knows 
the path of the EE cert and the name of the CRL issuer!

[Denis]

This is sufficient to find out the right certificate once you know
where the CA places the certificates that it has issued.

[Stefan]

So.. This is NOT the point.

I'll try to explain. Take again an example.

The following is known to the RP:
1) Cert path:  EE_Cert -> CA_1 -> Root_CA_1
2) CRL issued by CRL_Issuer_B

This is NOT known to the RP.
CRL path: CRL -> CRL_Issuer_B -> Intermediary_CA_X - Root_CA_Y

[Denis]

I do not agree with that case.

The question is "who can nominate a CRL issuer ?".

A given CA_X can issue a certificate to CA_Y either allowing it to :

  - only issue certificates (keyCertSign bit set),
  - or both issue certificates and CRLs (cRLSign bit set also set).

In the former case, the CA_X will nominate one or more CRL Issuers, and CA_Y 
will need to contract with one (or more) of them.

Going back to the example above this means that CRL_Issuer_B must have a 
certificate from CA_1. It cannot have a certificate from Intermediary_CA_X, 
unless specific and different relationships would apply to CRL Issuers and 
such details have never been detailed in RFC 3280 (some proprietary models 
have adopted some very specific rules, but they are not covered by RFC 3280).

This discussion highlights the fact that the determination of the CRL Issuer 
is not precise enough in RC 3280 and due to this lack of precision, it seems 
that some people are make their own interpretation, which will lead to a 
lack of interoperability.

RFC 3280 states on page 48:

    Whenever the CRL issuer is not the CA
    that issued the certificates, the CRL is referred to as an indirect
    CRL.

"CRL issuer" is defined as "an optional system to which a CA delegates the 
             publication of certificate revocation lists";

This is vague. How is the delegation really performed from a RP point of view ?

RFC 3280 States:

    If the certificate issuer is not the CRL
    issuer, then the cRLIssuer field MUST be present and contain the Name
    of the CRL issuer.

A name is ambiguous unless it relates to some CA, whose name can also be 
trusted up to a root key. The question is thus who can issue a certificate 
for that name ? RFC 3280 does not tell.

Section 6.3 from RFC 3280 states:

6.3.3  CRL Processing

    This algorithm begins by assuming the certificate is not revoked.
    The algorithm checks one or more CRLs until either the certificate
    status is determined to be revoked or sufficient CRLs have been
    checked to cover all reason codes.

    (...)

       (1)  If the DP includes cRLIssuer, then verify that the issuer
       field in the complete CRL matches cRLIssuer in the DP and that
       the complete CRL contains an issuing distribution point
       extension with the indrectCRL boolean asserted.

The text does not say explicitly how the match is obtained.

 From the above explanations, I am considering the case where a given CA_X 
has issued a certificate to CA_Y either allowing it to :

  - only issue certificates (keyCertSign bit set),
  - or both issue certificates and CRLs (cRLSign bit set also set).

This means that the CA which has nominated CA_Y is the only one allowed to 
nominate CRL Issuers that CA_Y can use. Any other case would imply a model 
that is not described (and thus not supported) in RFC 3280.

So the discussion is now taking quite a new dimension.

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 i9MC9SxQ017865; Fri, 22 Oct 2004 05:09:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MC9SXd017864; Fri, 22 Oct 2004 05:09:28 -0700 (PDT)
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 i9MC9Mnp017830 for <[e-mail]>; Fri, 22 Oct 2004 05:09:23 -0700 (PDT) (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 i9MC9ND22312; Fri, 22 Oct 2004 14:09:23 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 22 Oct 2004 14:09:23 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9MC9MD12633; Fri, 22 Oct 2004 14:09:22 +0200 (MEST)
Date: Fri, 22 Oct 2004 14:09:22 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Signer certificate discovery for CRLs
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>

> 
> My suggestion is base on the curent practice I am aware of, not based
> on any spec or standard.
> I believe that currently there is no spec to tell us what kind of objects
> an AIA caIssuers URI will point to. The current definition of AIA in
> RFC 3280 is too vague. I think that Stefan's proposal of
> expanding the scope of AIA is a chance to clarify this.

I would second the idea to put this on the list of issues for an
update of 3280, ooups, the San Diego meeting proceedings say
'list of open issues compiled'. 

> 
> For MIME types, RFC 2585 and RFC 2633 already defined some
> useful types for cert, crl, or CMS/PKCS#7 object. Unfortunately,
> related HTTP or FTP URI pointers (such as those in an AIA or a CRLDP)
> defined in RFC 3280 have no reference to MIME types defined in RFC 2585
> and RFC 2633.

i'd be careful to allow different mime type together with one access method OID. 

> > Also, Peter Gutmann's new http-certstore does something completely
> > different AFAIS.
> >
> Please note that I am talking about AIA not SIA. For an HTTP
> URI in a SIA, it should follow the spec in Peter Gutmann's new
> http-certstore proposal. I suggest that http-certstore spec should
> have a reference to MIME types defined in RFC 2585.

The difference is not SIA vs AIA IMO, but the format implied by 
accessMethod (which is the same definition for SIA and AIA). 

  " The type and
   format of the information is specified by the accessMethod field;" 

> 
> Wen-Cheng Wang
> 
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 i9M1qd4R064839; Thu, 21 Oct 2004 18:52:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9M1qdbG064838; Thu, 21 Oct 2004 18:52:39 -0700 (PDT)
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 i9M1qceh064830 for <[e-mail]>; Thu, 21 Oct 2004 18:52:38 -0700 (PDT) (envelope-from [e-mail])
Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i9M1qeNR021678 for <[e-mail]>; Thu, 21 Oct 2004 21:52:40 -0400
Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id i9M1qepI028200 for <[e-mail]>; Thu, 21 Oct 2004 21:52:40 -0400
Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id i9M1qexo028198 for [e-mail]; Thu, 21 Oct 2004 21:52:40 -0400
Received: from pool-138-88-237-89.res.east.verizon.net (pool-138-88-237-89.res.east.verizon.net [138.88.237.89])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Thu, 21 Oct 2004 21:52:40 -0400
Message-ID: <[e-mail]>
Date: Thu, 21 Oct 2004 21:52:40 -0400
From: [e-mail]
To: [e-mail]
Subject: PKIX agenda requests
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: 138.88.237.89
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,

PKIX is scheduled for Wednesday November 10, 1 - 3:00 PM at the 60th IETF (in 
Washington).

I spaced on agenda requests, and the time for WG agenda submissions is winding 
down.  My apologies about the late notice, but I would like to submit a draft 
agenda next Monday by the noon deadline.

Please send me your agenda requests as soon as possible.  I will as always 
give preference to WG documents, but will try to fit in related personal 
drafts and liasion presentations.

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 i9LM1hhG012907; Thu, 21 Oct 2004 15:01:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9LM1hjL012906; Thu, 21 Oct 2004 15:01:43 -0700 (PDT)
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 i9LM1gR1012875 for <[e-mail]>; Thu, 21 Oct 2004 15:01:42 -0700 (PDT) (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 i9LM1hZv012531; Thu, 21 Oct 2004 22:01:43 GMT (envelope-from [e-mail])
Message-Id: <6.1.2.0.0.20041021142725.02f75108@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Thu, 21 Oct 2004 15:02:21 -0700
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Fwd: I-D ACTION:draft-zeilenga-ldap-x509-00.txt
Cc: [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 IETF#60, I stated that I would submit an I-D providing
LDAP schema descriptions for the certificate related
elements covered in RFC 2252/2256 but not covered in
LDAPBIS syntax/schema I-Ds, with matching rule corrections.
Though a submitted later than I had hoped, this is that I-D.
This I-D assumes familiarity with X.509 and other normative
references.

In addition, to the these elements, this document provides
LDAP schema descriptions for the elements discussed in
RFC 2587, namely the X.509 pkiUser and pkiCA classes.
Additionally, a few additional X.509 certificate related
matching rules were included for completeness.

The introduction of these rules requires introduction of
new LDAP syntaxes for the assertion values.  With the
exception of one syntax, these LDAP syntaxes are GSER-based.
The exception, certificateExactAssertion, utilizes the
syntax suggested by RFC 3876.   In a sequence revision
of the I-D, ABNF grammars for each of the GSER-based
formats will be provided for informational purposes.

As noted at IETF#60, the intent of this I-D is to provide
an RFC 2252/RFC2256 compatible specification for these
X.500 schema elements.  Hence, unlike the latest revisions
of draft-ietf-pkix-ldap-pki, this I-D mandates the use of
the ;binary transfer option to request and transfer
certificate (and related) attribute values.

There are a few other differences between this I-D and
draft-ietf-pkix-ldap-pki.  For instance, this I-D doesn't
offer LDAP schema descriptions for 'cpCPS' and
'pkiCertPath' object classes and related attribute
types, matching rules, and syntaxes.

Lastly, I did not attempt to state an applicability
statement for use of LDAP in Public Key Infrastructures.
This, I believe, is better left to separate I-D, possibly
titled "Internet X.509 Public Key Infrastructure Operational
Protocols - LDAPv3".   I intend to leave that to others
authors.

Comments welcomed.

Also, if there is available PKIX session time at IETF#61, I
would be happy to present proposal(s) to reconcile any
issues with this I-D.

Enjoy! Kurt

>To: [e-mail]
>From: [e-mail]
>Date: Wed, 20 Oct 2004 10:36:40 -0400
>Subject: I-D ACTION:draft-zeilenga-ldap-x509-00.txt
>Reply-To: [e-mail]
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>        Title           : LDAP X.509 Certificate Schema
>        Author(s)       : K. Zeilenga
>        Filename        : draft-zeilenga-ldap-x509-00.txt
>        Pages           : 16
>        Date            : 2004-10-19
>        
>This document describes schema for representing X.509 certificates,
>  X.521 security information, and related elements in directories
>  accessible using the Lightweight Directory Access Protocol (LDAP).
>  The LDAP definitions for these X.509 and X.521 schema elements
>  replaces those provided in RFC 2252 and RFC 2256.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-x509-00.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-zeilenga-ldap-x509-00.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-zeilenga-ldap-x509-00.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.
>Content-Type: text/plain
>Content-ID: <[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-zeilenga-ldap-x509-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-zeilenga-ldap-x509-00.txt>
>_______________________________________________
>I-D-Announce mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/i-d-announce



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9L3HV4k026126; Wed, 20 Oct 2004 20:17:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9L3HVSj026125; Wed, 20 Oct 2004 20:17:31 -0700 (PDT)
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 i9L3HOie026114 for <[e-mail]>; Wed, 20 Oct 2004 20:17:29 -0700 (PDT) (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 i9L3HMA6021933; Thu, 21 Oct 2004 11:17:22 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id i9L3HGmK023211; Thu, 21 Oct 2004 11:17:16 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id i9L3HFZG023141; Thu, 21 Oct 2004 11:17:15 +0800
Message-ID: <00d401c4b71c$75936de0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
Date: Thu, 21 Oct 2004 11:17:12 +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="big5"
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>

> > More specifically, for a LDAP URI it could point to the
crossCertificatePair
> > attribute or the caCertificate attribute of a CA's directory entry; for
a
> > HTTP
> > URI or a FTP URI it could point to a cert-only CMS/PKCS#7 file (please
see
> > section 3.6 of RFC 2633).
> > Both a LDAP attribute and a CMS/PKCS#7 file can contains multiple
> > certificates.
>
> "it could point" but where is a spec? What kind of mime types
> should a client be prepared to get in case of an HTTP URI
> in some SIA or AIA?

My suggestion is base on the curent practice I am aware of, not based
on any spec or standard.
I believe that currently there is no spec to tell us what kind of objects
an AIA caIssuers URI will point to. The current definition of AIA in
RFC 3280 is too vague. I think that Stefan's proposal of
expanding the scope of AIA is a chance to clarify this.

For MIME types, RFC 2585 and RFC 2633 already defined some
useful types for cert, crl, or CMS/PKCS#7 object. Unfortunately,
related HTTP or FTP URI pointers (such as those in an AIA or a CRLDP)
defined in RFC 3280 have no reference to MIME types defined in RFC 2585
and RFC 2633.

>
> Also, Peter Gutmann's new http-certstore does something completely
> different AFAIS.
>
Please note that I am talking about AIA not SIA. For an HTTP
URI in a SIA, it should follow the spec in Peter Gutmann's new
http-certstore proposal. I suggest that http-certstore spec should
have a reference to MIME types defined in RFC 2585.

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 i9KBQ80e089845; Wed, 20 Oct 2004 04:26:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9KBQ8tf089844; Wed, 20 Oct 2004 04:26:08 -0700 (PDT)
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 i9KBQ21u089793 for <[e-mail]>; Wed, 20 Oct 2004 04:26:02 -0700 (PDT) (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 i9KBPpD12838; Wed, 20 Oct 2004 13:25:51 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 20 Oct 2004 13:25:51 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9KBPom03477; Wed, 20 Oct 2004 13:25:50 +0200 (MEST)
Date: Wed, 20 Oct 2004 13:25:50 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Signer certificate discovery for CRLs
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>

> From [e-mail] Tue Oct 19 04:13:28 2004
> Return-Path: <[e-mail]>
> Message-ID: <008301c4b581$32882b90$4f85900a@wcwang>
> From: "Wen-Cheng Wang" <[e-mail]>
> To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>,
>    "Peter Sylvester" <[e-mail]>
> References: <010a01c4b554$96d442f0$[e-mail]>
> Subject: Re: Signer certificate discovery for CRLs
> Date: Tue, 19 Oct 2004 10:13:16 +0800
> Organization: Chunghwa Telecom
> MIME-Version: 1.0
> X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
> More specifically, for a LDAP URI it could point to the crossCertificatePair
> attribute or the caCertificate attribute of a CA's directory entry; for a
> HTTP
> URI or a FTP URI it could point to a cert-only CMS/PKCS#7 file (please see
> section 3.6 of RFC 2633).
> Both a LDAP attribute and a CMS/PKCS#7 file can contains multiple
> certificates.

"it could point" but where is a spec? What kind of mime types
should a client be prepared to get in case of an HTTP URI
in some SIA or AIA? 

Also, Peter Gutmann's new http-certstore does something completely
different AFAIS.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JAKHQP020027; Tue, 19 Oct 2004 03:20:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JAKHaB020026; Tue, 19 Oct 2004 03:20:17 -0700 (PDT)
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 i9JAKHux019982 for <[e-mail]>; Tue, 19 Oct 2004 03:20:17 -0700 (PDT) (envelope-from [e-mail])
Received: from p4 (c-24-18-253-210.client.comcast.net[24.18.253.210]) by comcast.net (sccrmhc12) with SMTP id <2004101910201201200frh97e>; Tue, 19 Oct 2004 10:20:12 +0000
Message-Id: <3.0.5.32.20041019032010.01c46028@localhost>
X-Sender: cme@localhost (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 19 Oct 2004 03:20:10 -0700
To: [e-mail]
From: Carl Ellison <[e-mail]>
Subject: CFP 2005 PKI R&D Workshop - Deadline soon
Mime-Version: 1.0
Content-Type: text/enriched; 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>

<fontfamily><param>Courier New</param><bigger>4th Annual PKI R&D
Workshop: Multiple Paths to Trust

April 19-21, 2005

NIST -- Gaithersburg, MD

Papers and Proposals Due: October 29, 2004


Website:
<underline><color><param>0000,0000,ffff</param>http://middleware.internet2.edu/pki05/

</color></underline>Registration Fee: $125.00


This workshop considers the full range of public key technology used

for security decisions and supporting functionalities, including

authentication, authorization, identity (syndication, federation, and

aggregation), and trust.  This year, the workshop has a particular

interest in how PKI and emerging trust mechanisms will interact with

each other at technical, policy and user levels to support trust

models that lack a central authority.  This workshop has three goals:


1. Explore the current state of public key technology and

   emerging trust mechanisms in different domains including

   web services; grid technologies; authentication systems,

   et al., in academia, research, government, and industry.


2. Share & discuss lessons learned and scenarios from vendors

   and practitioners on current deployments.


3. Provide a forum for leading security researchers to explore

   the issues relevant to PKI space in areas of security

   management, identity, trust, policy, authentication, and

   authorization.


CALL FOR PAPERS


We solicit papers, case studies, panel proposals, and participation

from researchers, systems architects, vendor engineers, and users.

Submitted works should address one or more critical areas of inquiry.


Topics include (but are not limited to):


* Federated versus Non-Federated trust models

* Standards related to PKI and security decision systems such as

  x509, SDSI/SPKI, PGP, XKMS, XACML, XRML, XML signature, and SAML.

* Cryptographic and alternative methods for supporting security

  decisions, including the characterization and encoding of data

* Intersection of policy based systems and PKI

* Privacy protection and implications

* Scalability of security systems

* Security of the components of PKI systems

* Security Infrastructures for constrained environments

* Improved human factor designs for security-related interfaces

  including authorization and policy management, naming, use of

  multiple private keys, and selective disclosure

* New paradigms in PKI architectures

* Reports of real-world experience with the use and deployment of

  PKI, including future research directions


Deadlines for conference paper and panel submissions are:


* Papers and Proposals Due: October 29, 2004

* Authors Notified:         December 10, 2004

* Final Materials Due:      February 18, 2005


Submissions should be provided electronically, in PDF, for standard

US letter-size paper (8.5 x 11 inches). Paper submissions must not

exceed 15 pages (single space, two column format with 1" margins

using a 10 pt or larger font) and have no header or footer text

(e.g., no page numbers). Proposals for panels should be no longer

than five pages and include possible panelists and an indication of

which panelists have confirmed availability.


Please submit the following information to [e-mail]:


* Name, affiliation, email, phone, postal address for the primary

  contact author

* First name, last name, and affiliation of each co-author

* The finished paper in PDF format as an attachment


All submissions will be acknowledged.


Submissions of papers must not substantially duplicate work that any

of the authors have published elsewhere or have submitted in parallel

to any other conferences or journals.


Accepted papers will be published in a proceedings of the workshop.


REGISTRATION


The registration fee of $125 per person includes workshop materials,

coffee breaks, lunches, and a dinner.  There will be no on-site

registration. Please pre-register by April 12, 2005 at


 <underline><color><param>0000,0000,ffff</param>https://rproxy.nist.gov/CRS/conf_ext.cfm?conf_id=1065

</color></underline>

Teresa Vicente

NIST

Phone: [phone]

Fax: [phone]

email: [e-mail]


An agenda will be available in late December at

<underline><color><param>0000,0000,ffff</param>http://middleware.internet2.edu/pki05/

</color></underline>

ACCOMMODATIONS


A block of rooms has been reserved at the Gaithersburg Holiday Inn,

[phone], at a special rate of $99, single or double, plus 12%

tax. Reservations must be received by April 4, 2005, in order to

receive the special rate.  Please mention you are attending the

"NIST/PKI Workshop".


</bigger></fontfamily>



+------------------------------------------------------------------+

|Carl M. Ellison         [e-mail]      http://theworld.com/~cme |

|    PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71       |

+---Officer, arrest that man. He's whistling a copyrighted song.---+



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9J2Dc9L058878; Mon, 18 Oct 2004 19:13:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9J2DcfR058877; Mon, 18 Oct 2004 19:13:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9J2DWFY058821 for <[e-mail]>; Mon, 18 Oct 2004 19:13:37 -0700 (PDT) (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 i9J2DKOk031926; Tue, 19 Oct 2004 10:13:20 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id i9J2DKBm011040; Tue, 19 Oct 2004 10:13:20 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id i9J2DJZG010970; Tue, 19 Oct 2004 10:13:19 +0800
Message-ID: <008301c4b581$32882b90$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>, "Peter Sylvester" <[e-mail]>
References: <010a01c4b554$96d442f0$[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
Date: Tue, 19 Oct 2004 10:13:16 +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>

Peter,
>
> I think the pointer as a URI.  I could be LDAP, HTTP or FTP pointer to a
> file that contains one or more certificates.
>
More specifically, for a LDAP URI it could point to the crossCertificatePair
attribute or the caCertificate attribute of a CA's directory entry; for a
HTTP
URI or a FTP URI it could point to a cert-only CMS/PKCS#7 file (please see
section 3.6 of RFC 2633).
Both a LDAP attribute and a CMS/PKCS#7 file can contains multiple
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 i9IKrstj004271; Mon, 18 Oct 2004 13:53:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IKrsfJ004270; Mon, 18 Oct 2004 13:53:54 -0700 (PDT)
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 i9IKrrR3004264 for <[e-mail]>; Mon, 18 Oct 2004 13:53:54 -0700 (PDT) (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 i9IKrvCd025584 for <[e-mail]>; Mon, 18 Oct 2004 16:53:58 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Mon, 18 Oct 2004 16:53:57 -0400
Message-ID: <010a01c4b554$96d442f0$[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>

Peter:

I think the pointer as a URI.  I could be LDAP, HTTP or FTP pointer to a
file that contains one or more certificates.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Sylvester
Sent: Monday, October 18, 2004 3:29 PM
To: [e-mail]
Subject: Re: Signer certificate discovery for CRLs




As a side remark or a question:

Waht is supposed to be be returned for a value of the id-ad-caRepository or
id-ad-caIssuers in case the value starts with ftp or http?

As far as I understand, the values point to a repository.

of course, in some cases this may degenerate to a single cert. But what is
the information to be returned for a caIssuer if the ca cert has to higher
level (cross) certs. 

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 i9IJSr7j090341; Mon, 18 Oct 2004 12:28:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IJSr8U090339; Mon, 18 Oct 2004 12:28:53 -0700 (PDT)
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 i9IJSlm0090244 for <[e-mail]>; Mon, 18 Oct 2004 12:28:47 -0700 (PDT) (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 i9IJSoN23550 for <[e-mail]>; Mon, 18 Oct 2004 21:28:50 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 18 Oct 2004 21:28:50 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9IJSnf23290 for [e-mail]; Mon, 18 Oct 2004 21:28:49 +0200 (MEST)
Date: Mon, 18 Oct 2004 21:28:49 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Signer certificate discovery for CRLs
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>

As a side remark or a question:

Waht is supposed to be be returned for a value of the id-ad-caRepository
or id-ad-caIssuers in case the value starts with ftp or http?

As far as I understand, the values point to a repository.

of course, in some cases this may degenerate to a single cert.
But what is the information to be returned for a caIssuer if the
ca cert has to higher level (cross) certs. 

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 i9IJH2Q9088357; Mon, 18 Oct 2004 12:17:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IJH2uN088356; Mon, 18 Oct 2004 12:17:02 -0700 (PDT)
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 i9IJH1UZ088325 for <[e-mail]>; Mon, 18 Oct 2004 12:17:02 -0700 (PDT) (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 i9IJGsjl023851; Mon, 18 Oct 2004 15:16:58 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0611040ebd99c532f576@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 18 Oct 2004 15:10:47 -0400
To: Puneet kumar <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Effect of adding an attribute to CSR
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 4:26 AM -0700 10/14/04, Puneet kumar wrote:
>Dear all,
>       I need some assistance on a peculiar problem we are facing.
>
>       We are an organisation which acts as the TTP for all CA's 
>operating in our country ,ie, we are the Root CA. So whenverea new 
>CA comes up they send us a CSR (in PKCS#10) which we sign and give 
>back a X.509 base 64 Certificate.
>
>We recently received a CSR from a new CA.We added the attribute "cn" 
>to the dn of the CSR (as this is a requirement at our end) and then 
>issued the cert.Now the CA's software is not accpeting the cert and 
>they say that its because we added the cn attribute.We are using a 
>softwrae by Smarttrust (CM)and the CA has an Entrust s/w.
>
>Now I have the following queries
>
>1.Does adding an attribute to the CSR make any difference towards 
>the acceptability of the cert?
>
>2.What options do we have at our end..I mean do we need to revoke 
>the cert? Can we re-certify the cert? Actually I did'nt find the 
>term re-certify in any standardd..certs are either revoked or get 
>expired.Your Comments would be most welcome.
>
>3.Is their any setting changes that can be done in the Entrust CA 
>softwrae to allow this cert with the changed distinguished name to 
>be accepted?
>
>Request feedback from you guys..
>
>Thanks

The PKIX standards for cert request/response do not address this 
issue, in the general case.  However, a client (a CA in this case) 
might well compare the returned cert to the one submitted and reject 
the response because of the mismatch.  In your case the "right" 
solution is to have the client resubmit the request with the subject 
name in the form you procedurally require.

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 i9II08xx073074; Mon, 18 Oct 2004 11:00:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9II08XA073073; Mon, 18 Oct 2004 11:00:08 -0700 (PDT)
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 i9II03x0073027 for <[e-mail]>; Mon, 18 Oct 2004 11:00:04 -0700 (PDT) (envelope-from [e-mail])
Received: from [127.0.0.1] (hannaxp [192.168.21.6]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VB304QMV; Mon, 18 Oct 2004 13:59:48 -0400
Message-ID: <[e-mail]>
Date: Mon, 18 Oct 2004 13:59:54 -0400
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: Stefan Santesson <[e-mail]>
CC: Denis Pinkas <[e-mail]>, Santosh Chokhani <[e-mail]>, pkix <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
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>

This is a classic case of building cert paths forward
(from EE to trust anchor) vs. building reverse (from
trust anchor to EE). In a hierarchy, building forward
is usually best. In a more complex topology, building
reverse or meeting in the middle can be better. See
our paper in the NDSS 2001 proceedings.

The first step in a forward build is to find certificates
that have the EE as the subject. Then you build from there
toward the TA. AIA helps with that. The first step in a
reverse build is to find certificates that have the TA as
the issuer. Then you build toward the EE. SIA helps with that.
So both SIA and AIA are useful.

Given that most PKIs are hierarchies today, building
reverse will often be most useful. That's why you
should put an AIA in CRLs. It helps find the CRL issuer's
certificate(s). Even in complex topologies, it will often
be useful to have the AIA (to meet in the middle) and
I can't see how it would hurt.

Thanks,

Steve

Stefan Santesson wrote:

> To save you from excessive discussions on a topic you don't really care
> about, I concentrate on the one major problem with SIA that you missed
> my point on:
> 
> 
>>>1) How can the RP know what certificate's SIA it would use to find
> 
> the 
> 
>>>CRL signer cert?
> 
> 
>>>You just picked the right certificate in my example since I gave that
> 
> 
>>>information in the example. But the RP don't know that path, it only 
>>>knows the path of the EE cert and the name of the CRL issuer!
> 
> 
>>This is sufficient to find out the right certificate once you know
> 
> where >the CA places the certificates that it has issued.
> 
> So.. This is NOT the point.
> 
> I'll try to explain. Take again an example.
> 
> The following is known to the RP:
> 1) Cert path:  EE_Cert -> CA_1 -> Root_CA_1
> 2) CRL issued by CRL_Issuer_B
> 
> This is NOT known to the RP.
> CRL path: CRL -> CRL_Issuer_B -> Intermediary_CA_X - Root_CA_Y
> 
> To find the CRL Issuer cert, the RP need to look in the SIA of
> Intermediary_CA_X certificate, right?
> 
> But how can the RP do that when it doesn't know the CRL path. THE RP HAS
> NO KNOWLEDGE ABOUTH THE FACT THAT Intermediary_CA_X IS THE CA ABOVE THE
> CRL SIGNER CERT. In fact the RP has no means to find out, except through
> exhaustive search from all its trusted roots.
> 
> Here, AIA in the CRL solves the issue, SIA doesn't.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 18 oktober 2004 16:58
>>To: Santosh Chokhani; Stefan Santesson
>>Cc: 'pkix'
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>
>>Santosh and Stefan,
>>
>>Now we get to the point that there exists one solution, while the
> 
> thread
> 
>>started saying that there was no other solution.
>>
>>We can now start to discuss the advantages and disadvantages of the
> 
> two
> 
>>solutions.
>>
>>However, we have to provide a fair view.
>>
>>For the time being, you have only considered the disadvantages of the
>>*current* solution, i.e. using SIA. It would be fair that you also
>>consider
>>its advantages and that we take the time to have a fair comparison.
>>
>>
>>>The SIA can be used to find the certificate, but it leads to the
>>
>>exponential
>>
>>>growth in the search base in the case of indirect CRL.
>>
>>This is an argument about disadvantages. However this argument is
>>incorrect:
>>there is no exponential grow. A CA nominates an authority either as :
>>
>>  1 - "CA issuer + CRL issuer"
>>  2 - "CA issuer only", or
>>  3 - "CRL Issuer only"
>>
>>Once the path is constructed, if every CA certificate includes the SIA
>>extension, then this is straightforward.
>>
>>
>>>Also, I do not think SIA is that well supported.
>>
>>I could say that the new proposal is not "that well supported" but
> 
> this
> 
>>would be an argument leading nowhere. :-|
>>
>>The SIA extension is very useful and we should make our best efforts
> 
> so
> 
>>that
>>it will be more and more supported. Providing "yet another way" is not
>>going
>>to lead in that direction. :-(
>>
>>
>>>Thus, we need to consider the commercial realities and permit a
> 
> simple
> 
>>and
>>
>>>elegant approach of using AIA to prime the pump (so to speak) to
> 
> start
> 
>>the
>>
>>>CRL signer path development.
>>
>>SIA was not present in RFC 2459. It has been introduced in RFC 3280
> 
> and
> 
>>this
>>is a good point. It should be generalized in order to support
>>interoperability. Going down from trust points to leaf certificates
> 
> allow
> 
>>to
>>cover any case.
>>
>>The answers to Stefan follow:
>>
>>
>>>-----Original Message-----
>>>From: Stefan Santesson [mailto:[e-mail]]
>>>Sent: Monday, October 18, 2004 8:19 AM
>>>To: Denis Pinkas
>>>Cc: Santosh Chokhani; pkix
>>>Subject: RE: Signer certificate discovery for CRLs
>>>
>>>
>>>Thanks Denis,
>>>
>>>I now finally understand your SIA alternative.
>>>
>>>There are some major problems with it though.
>>
>>>1) How can the RP know what certificate's SIA it would use to find
> 
> the
> 
>>CRL
>>
>>>signer cert?
>>
>>>You just picked the right certificate in my example since I gave
> 
> that
> 
>>>information in the example. But the RP don't know that path, it only
>>
>>knows
>>
>>>the path of the EE cert and the name of the CRL issuer!
>>
>>This is sufficient to find out the right certificate once you know
> 
> where
> 
>>the
>>CA places the certificates that it has issued.
>>
>>
>>>2) And even if RP knew the path beforehand, finding THE one CRL
> 
> signer
> 
>>>certificate from a CRL AIA is much more direct and efficient than
>>
>>finding
>>
>>>among all issued certificates from a CA the 1 out of x issued
>>
>>certificates
>>
>>>that is the CRL Issuer cert.
>>
>>Usually a CA issues a small number of CA certificates and CRL
>>certificates.
>>So this is not a problem.
>>
>>
>>>3) Using SIA in the examples requires available directories and
>>
>>directory
>>
>>>enabled clients. How do you solve the problem if either of these is
> 
> not
> 
>>>available?
>>
>>It could work as well with HTTP using the recent draft that has been
>>proposed.
>>
>>
>>>Do you seriously suggest that use of SIA is a better and more
> 
> effective
> 
>>way
>>
>>>to address this problem or are you just pointing out the fact that
> 
> there
> 
>>are
>>
>>>SOME cases where use of SIA may work in theory?
>>
>>I rather believe that your question was:
>>
>>"Do you suggest that use of SIA is a better and more effective way to
>>address this problem or are you just pointing out the fact that there
> 
> are
> 
>>SOME cases where use of SIA may work ?
>>
>>SIA is certainly better and shoud be generalized to ease path
> 
> contruction,
> 
>>not only for CRL issuers but also for CAs.
>>
>>SIA may work in ALL cases, unless you provide an example where it
> 
> cannot.
> 
>>Now I have spent quite a lot of time on that topic (on which I am
>>personally
>>NOT interested), but since I have been asked by the Security Area
> 
> Director
> 
>>to provide details I needed to respond.
>>
>>I will not be able to sustain the same level of discussions in the
> 
> next
> 
>>coming days. In particular, I will not be in my office tomorrow. So
> 
> you
> 
>>have
>>plenty of time to consider pros and cons for both approaches and do
> 
> not
> 
>>take
>>silence as approval.
>>
>>Denis
>>
>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>Sent: den 18 oktober 2004 12:28
>>>>To: Stefan Santesson
>>>>Cc: Santosh Chokhani; pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>Stefan,
>>>>
>>>>
>>>>
>>>>>Denis,
>>>>
>>>>>If I get you right you mean that one can always successfully use
> 
> AIA
> 
>>>and
>>>
>>>
>>>>>SIA in certs to solve discovery of CRL signer cert.
>>>>>Others on this list (me included) don't understand how. It would
>>>>>therefore be useful if you told us.
>>>>>
>>>>>I'll try to explain the problem from my perspective one more time.
>>>>
>>>>Thanks.
>>>>
>>>>
>>>>
>>>>>Note: "->" in these examples means "issued by"
>>>>
>>>>Fine.
>>>>
>>>>
>>>>
>>>>>Case 1 - indirect CRL:
>>>>>
>>>>>Cert path is:  EE_Cert -> CA_1 -> Root-CA
>>>>>CRL path for EE_Cert is:  CRL -> CRL_Issuer_B -> Root-CA
>>>>
>>>>This means Root-CA has nominated CA_1 and a CRL_Issuer_B and that
> 
> CA_1
> 
>>>has
>>>
>>>
>>>>chosen to use CRL_Issuer_B for revocation checking for some
>>>
>>>certificates.
>>>
>>>
>>>>>Scenario:
>>>>>Relying party has access to the cert path, discovers the CRL
> 
> through
> 
>>>CDP
>>>
>>>
>>>>>in EE_Cert.
>>>>
>>>>If there is no attack on the objects stored at the CRL DP, the CRL
>>>
>>>Issuer
>>>
>>>>from that CRL is CRL_Issuer_B. Now the relying party needs to get
> 
> the
> 
>>>>certificate isued by Root-CA for CRL_Issuer_B. If Root-CA has
> 
> included
> 
>>>a
>>>
>>>
>>>>SIA
>>>>extension in his self-signed certificate, then using that extension
>>>
>>>allows
>>>
>>>
>>>>to get the CRL_Issuer_B certificate issued by the Root-CA.
>>>>
>>>>
>>>>>The RP searches the location specified in SIA through
>>>>
>>>>>id-ad-caRepository in the CA_1 cert but finds nothing useful since
>>>>>revocation is subordinated to another entity (CRL_Issuer_B)
>>>>
>>>>Correct, but looking in Root-CA allows to find something useful, if
>>>
>>>the
>>>
>>>
>>>>self-signed certificate includes a SIA extension.
>>>>
>>>>
>>>>
>>>>>In this case, the problem could be solved if an AIA in the CRL
>>>>
>>>indicated
>>>
>>>
>>>>>the access location of the CRL Issuer cert.
>>>>
>>>>This would be an *alternative* way.
>>>>
>>>>
>>>>
>>>>>Case 2 - re-keyed CA.
>>>>>
>>>>>Cert path is:  EE_Cert -> CA_1(old key) -> Root-CA
>>>>>CRL path for EE_Cert is:  CRL -> CA_1(new key) -> Root-CA
>>>>
>>>>This means that the EE_Cert chain has been created with CA_1(old
> 
> key)
> 
>>>and
>>>
>>>
>>>>that the CRL issuer that was originaly used when the EE_Cert was
>>>
>>>created
>>>
>>>
>>>>has
>>>>been changed and a new CRL Issuer got a certificate under CA_1(new
>>>
>>>key)
>>>
>>>
>>>>and
>>>>is now the legitimate CRL issuer for the CRL DP originally
> 
> mentionned
> 
>>>in
>>>
>>>
>>>>the
>>>>EE_Cert.
>>>>
>>>>
>>>>
>>>>>The 2 CA_1 certificates above (old key and new key) are issued to
>>>>>different subject keys belonging to the same CA (same name). The
>>>>>cert CA_1(old key) was issued before creation of cert CA_1(new
>>>>
>>>key)
>>>
>>>
>>>>>and have thus no reference to CA_1(new key) in its SIA
>>>>>
>>>>>Scenario:
>>>>>RP discovers the CRL for the EE_Cert through the CDP but doesn't
>>>>
>>>possess
>>>
>>>
>>>>>the CRL issuer cert. The RP client searches the SIA of the CA_1(old
>>>>
>>>key)
>>>
>>>
>>>>>but finds no direct reference to the CRL signer cert. Since the RP
>>>>>client has no access to a directory where the CRL signer cert could
>>>>
>>>be
>>>
>>>
>>>>>found through directory lookup, cert validation fails.
>>>>
>>>>Correct, but looking in Root-CA allows to find something useful, if
>>>
>>>the
>>>
>>>
>>>>self-signed certificate includes a SIA extension.
>>>>
>>>>
>>>>
>>>>>In this scenario the problem could be solved through an AIA in the
>>>>
>>>CRL.
>>>
>>>
>>>>This would be an *alternative* way.
>>>>
>>>>Denis
>>>>
>>>>
>>>>
>>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>>Sent: den 15 oktober 2004 17:30
>>>>>>To: Stefan Santesson
>>>>>>Cc: Santosh Chokhani; pkix
>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>
>>>>>>Stefan,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Denis,
>>>>>>
>>>>>>>Unfortunately I fail to understand your questions, issues and
>>>>>>
>>>>>requests.
>>>>>
>>>>>
>>>>>
>>>>>>The sentence below demonstrates that you understand the issue.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>It would be very useful if you could explain how current
> 
> mechanisms
> 
>>>>>can
>>>>>
>>>>>
>>>>>
>>>>>>>be used in a simple and straightforward manner to discover CRL
>>>>>>
>>>>>signer
>>>>>
>>>>>
>>>>>
>>>>>>>certificates in ALL the use cases discussed, mainly re-keyed CA
> 
> and
> 
>>>>>>>indirect CRLs.
>>>>>>
>>>>>>You are also reversing the question. Using your terms, my question
>>>>>
>>>>>would
>>>>>
>>>>>
>>>>>
>>>>>>be:
>>>>>>
>>>>>>"It would be very useful if you could explain how current
> 
> mechanisms
> 
>>>>>>CANNOT be used in a simple and straightforward manner to discover
>>>>>>CRL
>>>>>
>>>signer
>>>
>>>
>>>>>>certificates in ONE or MORE the use cases discussed, mainly
> 
> re-keyed
> 
>>>>>CA
>>>>>
>>>>>
>>>>>
>>>>>>and
>>>>>>indirect CRLs."
>>>>>>
>>>>>>Denis
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Stefan Santesson
>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: [e-mail]
>>>>>>>
>>>>>>>[mailto:[e-mail]]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>On Behalf Of Denis Pinkas
>>>>>>>>Sent: den 14 oktober 2004 17:13
>>>>>>>>To: Santosh Chokhani
>>>>>>>>Cc: 'pkix'
>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>
>>>>>>>>Santosh,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Denis:
>>>>>>>>
>>>>>>>>>With the three assumptions/constraints I provided, how would
> 
> you
> 
>>>>>>>locate
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>CRL issuer certificate for the two examples using 3280
> 
> extensions
> 
>>>>>>>and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>without putting AIA in the CRL?
>>>>>>>>
>>>>>>>>As far as I understand, the three assumptions are:
>>>>>>>>
>>>>>>>>1.  You are directory challenged; and
>>>>>>>>  [I do not understand what this means]
>>>>>>>>2.  You use AIA to develop the path; and
>>>>>>>>  [It does not matter]
>>>>>>>>3.  You develop the path from the end entity to trust anchor
>>>>>>>>  [Could also be the contrary].
>>>>>>>>
>>>>>>>>If this is not correct, thus please correct.
>>>>>>>>
>>>>>>>>Then my request is: "using ANY OF the current extensions that
> 
> are
> 
>>>>>>>defined
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>in
>>>>>>>>RFC 3280", which includes SIA.
>>>>>>>>
>>>>>>>>In your explanations  you said :
>>>>>>>>"if you do no deal with SIA et. al"
>>>>>>>>
>>>>>>>>This last assumption is neither part of the three assumptions
> 
> and
> 
>>>>>does
>>>>>
>>>>>
>>>>>
>>>>>>>not
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>conform to my request.
>>>>>>>>
>>>>>>>>Denis
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>That is my point.
>>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>>>>>Sent: Thursday, October 14, 2004 6:22 AM
>>>>>>>>>To: Santosh Chokhani
>>>>>>>>>Cc: 'pkix'
>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Santosh,
>>>>>>>>>
>>>>>>>>>You misread my request. I said:
>>>>>>>>>
>>>>>>>>>"For the time being, I would like that you provide an example
>>>>>>>>
>>>>>where,
>>>>>
>>>>>
>>>>>
>>>>>>>>when
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>using the current extensions that are defined in RFC 3280, it
>>>>>>>>
>>>will
>>>
>>>
>>>>>>>NOT
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>be
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>possible to locate a CRL Issuer certificate."
>>>>>>>>>
>>>>>>>>>Maybe I would have needed to be clearer and say :
>>>>>>>>>
>>>>>>>>>"For the time being, I would like that you provide an example
>>>>>>>>
>>>>>where,
>>>>>
>>>>>
>>>>>
>>>>>>>>when
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>using ANY OF the current extensions that are defined in RFC
> 
> 3280,
> 
>>>>>it
>>>>>
>>>>>
>>>>>
>>>>>>>>will
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>NOT be possible to locate a CRL Issuer certificate."
>>>>>>>>>
>>>>>>>>>The examples you provide below do not fulfil this request.
>>>>>>>>>
>>>>>>>>>The assumption is that there exists a path to be tested for
>>>>>>>>
>>>>>>>revocation
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>checking (and that it does not matter to know which way it has
>>>>>>>>
>>>been
>>>
>>>
>>>>>>>>>constructed).
>>>>>>>>>
>>>>>>>>>I am not saying that using AIA in CRL might not be useful, but
> 
> I
> 
>>>am
>>>
>>>
>>>>>>>>still
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>lacking the demonstration that there would be no other way.
>>>>>>>>>
>>>>>>>>>Denis
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Denis:
>>>>>>>>>>
>>>>>>>>>>Two examples are very simple: one for direct CRL Issuer and
> 
> one
> 
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>>>>>>Indirect CRL Issuer.
>>>>>>>>>>
>>>>>>>>>>Let us make the following assumptions that Stefan was making:
>>>>>>>>>>
>>>>>>>>>>1.  You are directory challenged; and
>>>>>>>>>>2.  You use AIA to develop the path; and
>>>>>>>>>>3.  You develop the path from the end entity to trust anchor.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>From what I know of MS CAPI, these are reasonable
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>assumptions/constraints.
>>>>>>>>>>
>>>>>>>>>>Now the examples.
>>>>>>>>>>
>>>>>>>>>>Example 1: Direct CRL Issuer
>>>>>>>>>>
>>>>>>>>>>The certificate trust path is:
>>>>>>>>>>Root --> CA1 --> CA 2, old key --> Denis
>>>>>>>>>>
>>>>>>>>>>The CRL trust path is:
>>>>>>>>>>Root --> CA1 --> CA 2, new key --> CRL
>>>>>>>>>>
>>>>>>>>>>(Note: We do not do self-issued certificate since there is no
>>>>>>>>>
>>>>>>>simple,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>secure way to check their revocation status).
>>>>>>>>>>
>>>>>>>>>>Now, with AIA in CRL, finding the CA2, new key certificate is
>>>>>>>>>>straightforward.  How would you find it if you do no deal with
>>>>>>>>>
>>>SIA
>>>
>>>
>>>>>>>et.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>al.
>>>>>>>>>>
>>>>>>>>>>Example 2: Indirect CRL Issuer
>>>>>>>>>>
>>>>>>>>>>The certificate trust path is:
>>>>>>>>>>Root --> CA1 --> CA 2 --> Denis
>>>>>>>>>>(Note: Denis's certificate points to CRL DP of an indirect CRL
>>>>>>>>>
>>>>>>>issued
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>by CAI.
>>>>>>>>>>
>>>>>>>>>>The CRL trust path is:
>>>>>>>>>>Root --> CAI --> CRL
>>>>>>>>>>
>>>>>>>>>>Now, with AIA in CRL, finding the CAI certificate is
>>>>>>>>>
>>>>>>>straightforward.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>How would you find it if you do no deal with SIA et. al.
>>>>>>>>>>
>>>>>>>>>>In addition to the need cited above, please note that the
>>>>>>>>>
>>>>>extension
>>>>>
>>>>>
>>>>>
>>>>>>>>>>semantics does not change, it does not hinder any
>>>>>>>>>
>>>>>interoperability,
>>>>>
>>>>>
>>>>>
>>>>>>>>>>and it does not break any backward compatibility.  So, what if
> 
> I
> 
>>>>>>>>>>wanted to use this extension in the CRL.  It does no harm to
>>>>>>>>>
>>>other
>>>
>>>
>>>>>>>>>>relying parties.
>>>>>>>>>>
>>>>>>>>>>-----Original Message-----
>>>>>>>>>>From: [e-mail]
>>>>>>>>>>[mailto:[e-mail]] On Behalf Of Denis
> 
> Pinkas
> 
>>>>>>>>>>Sent: Wednesday, October 13, 2004 11:01 AM
>>>>>>>>>>To: Stefan Santesson
>>>>>>>>>>Cc: Santosh Chokhani; pkix
>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Stefan,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Denis,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>I'm not sure what you mean.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>For the time being, I would like that you provide an example
>>>>>>>>>
>>>>>where,
>>>>>
>>>>>
>>>>>
>>>>>>>>>>when
>>>>>>>>>>using the current extensions that are defined in RFC 3280, it
>>>>>>>>>
>>>will
>>>
>>>
>>>>>>>NOT
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>be
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>possible to locate a CRL Issuer certificate.
>>>>>>>>>>
>>>>>>>>>>If you are able to provide that example, then it would justify
>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>>>>need for
>>>>>>>>>>an extension at least for one case. Then we can see what that
>>>>>>>>>
>>>case
>>>
>>>
>>>>>>>is.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>I am awaiting that example.
>>>>>>>>>>
>>>>>>>>>>Denis
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>I conclude that I agree with Santosh.
>>>>>>>>>>>
>>>>>>>>>>>The debate is still open... Feel free to express your
> 
> opinion.
> 
>>>>>>>>>>>Stefan Santesson
>>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>-----Original Message-----
>>>>>>>>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>>>>>>>>Sent: den 13 oktober 2004 16:34
>>>>>>>>>>>>To: Stefan Santesson
>>>>>>>>>>>>Cc: Santosh Chokhani; pkix
>>>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan,
>>>>>>>>>>>>
>>>>>>>>>>>>You are making a conclusion without letting me the time to
>>>>>>>>>>>
>>>>>>>respond. I
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>will need more time to look at the pictures (and understand
>>>>>>>>>>>
>>>>>them).
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>For the time being, I am still reluctant to accept
>>>>>>>>>>>
>>>>>>>>>>>"yet-another-method".
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>We already have too many.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>Santosh,
>>>>>>>>>>>>>
>>>>>>>>>>>>>I conclude that we are in complete and total agreement. The
>>>>>>>>>>>>>question is how to go about this.
>>>>>>>>>>>>
>>>>>>>>>>>>>Could we do this amendment to RFC 3280 in its next
> 
> revision?
> 
>>>It
>>>
>>>
>>>>>>>>>>>>>would hopefully just be a minor change.
>>>>>>>>>>>>
>>>>>>>>>>>>This is exactly what I feared.
>>>>>>>>>>>>
>>>>>>>>>>>>We usually end-up with a "minor change" in an extension
>>>>>>>>>>>
>>>without
>>>
>>>
>>>>>>>>>>>>saying cleary how and when it shall/should be used.
>>>>>>>>>>>>
>>>>>>>>>>>>I still have in mind that:
>>>>>>>>>>>>
>>>>>>>>>>>>1) a certification path must first be constructed,
>>>>>>>>>>>>2) then the revocation checking of that path must be done.
>>>>>>>>>>>>
>>>>>>>>>>>>This means that information about CRL issuers certificates
>>>>>>>>>>>
>>>>>>>locations
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>may
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>certainly be found in that chain. If not, I would like an
>>>>>>>>>>>
>>>>>example.
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>Denis
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>It would not change the definition of AIA just add that it
>>>>>>>>>>>>
>>>can
>>>
>>>
>>>>>be
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>used
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>also as CRL extension and list eventual restrictions and
>>>>>>>>>>>
>>>>>guidance
>>>>>
>>>>>
>>>>>
>>>>>>>for
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>use
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>with CRLs.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>Stefan Santesson
>>>>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>-----Original Message-----
>>>>>>>>>>>>>>From: [e-mail]
>>>>>>>>>>>>>
>>>>>>>>>>>[mailto:[e-mail]]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>On Behalf Of Santosh Chokhani
>>>>>>>>>>>>>>Sent: den 13 oktober 2004 04:33
>>>>>>>>>>>>>>To: 'pkix'
>>>>>>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Stefan:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>In terms of certificate discovery, your proposal for AIA
> 
> in
> 
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>>>is
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>more
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>robust.  The whole idea of self-issued key rollover
>>>>>>>>>>>>>
>>>>>certificates
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>and
>>>>>>>>>>>>>
>>>>>>>>>>>>then
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>using the new key to issue CRL is fraught with security
>>>>>>>>>>>>>
>>>>>>>problems.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>A secure solution would be one where the new key is
>>>>>>>>>>>>>
>>>certified
>>>
>>>
>>>>>by
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>the parent
>>>>>>>>>>>>>
>>>>>>>>>>>CA.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>In
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>that case to obtain the new certificate, you could use AIA
>>>>>>>>>>>>>
>>>in
>>>
>>>
>>>>>>>CRL.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL
> 
> DP
> 
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>certificate in question points to the indirect CRL.  You
> 
> get
> 
>>>>>>>that
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>CRL.  The AIA
>>>>>>>>>>>>>
>>>>>>>>>>>in
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>CRL
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>gets you started for the indirect CRL issuer certification
>>>>>>>>>>>>>
>>>>>path
>>>>>
>>>>>
>>>>>
>>>>>>>and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>you
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>are
>>>>>>>>>>>>>>in business.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>-----Original Message-----
>>>>>>>>>>>>>>From: [e-mail]
>>>>>>>>>>>>>
>>>>>>>>>>>[mailto:[e-mail]]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>On
>>>>>>>>>>>>>>Behalf Of Stefan Santesson
>>>>>>>>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>>>>>>>>>>To: David A. Cooper
>>>>>>>>>>>>>>Cc: pkix
>>>>>>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>David,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Thanks for the clarifications, they make sense.
>>>>>>>>>>>>>>I did misread your pictures.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>So can we conclude that for a re-keyed CA in accordance
> 
> with
> 
>>>>>RFC
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>3280,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>either the CRL issuer certificate itself, or the location
> 
> of
> 
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>CRL issuer certificate, will be clearly
> 
> identified/available
> 
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>the validating
>>>>>>>>>>>>>
>>>>>>>>>>>>party
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>in some cases, but not in others?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Can we also conclude that there is no real discovery
>>>>>>>>>>>>>
>>>solution
>>>
>>>
>>>>>>>for
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>indirect
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>CRLs?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Do you then agree then that it could be appropriate to
> 
> allow
> 
>>>>>AIA
>>>>>
>>>>>
>>>>>
>>>>>>>as
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>a
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>CRL
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>extension to facilitate discovery of CRL signer
> 
> certificate?
> 
>>>>>>>>>>>>>>Stefan Santesson
>>>>>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>________________________________________
>>>>>>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>>>>>>>Sent: den 12 oktober 2004 21:14
>>>>>>>>>>>>>>To: Stefan Santesson
>>>>>>>>>>>>>>Cc: pkix
>>>>>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Stefan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>I believe that you are misinterpreting the figures.  They
>>>>>>>>>>>>>
>>>>>really
>>>>>
>>>>>
>>>>>
>>>>>>>do
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>represent three different cases, not three different
>>>>>>>>>>>>>
>>>>>>>certification
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>paths
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>that have been constructed through the same PKI
>>>>>>>>>>>>>
>>>architecture.
>>>
>>>
>>>>>>>>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>>>>>>>>>>
>>>>>>>>>>>certificates.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>The
>>>>>>>>>>>>>>Root CA has issued a certificate to CA 1's new key, but
> 
> not
> 
>>>>>its
>>>>>
>>>>>
>>>>>
>>>>>>>old
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>key
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>(either the Root CA never issued a certificate to CA 1's
> 
> old
> 
>>>>>key
>>>>>
>>>>>
>>>>>
>>>>>>>or
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>that
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>certificate has expired).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>In figure 2, CA 2 has also generated self-issued key
>>>>>>>>>>>>>
>>>rollover
>>>
>>>
>>>>>>>>>>>>>>certificates. The Root CA has issued a certificate to CA
> 
> 2's
> 
>>>>>old
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>key, but not its
>>>>>>>>>>>>>
>>>>>>>>>>>new
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>key.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>In figure 3, when CA 3 performed key rollover, it
> 
> requested
> 
>>>a
>>>
>>>
>>>>>>>new
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>CA certificate from the Root CA.  CA 3 did not generated
>>>>>>>>>>>>>>self-issued
>>>>>>>>>>>>>
>>>>>>>>>>>key
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>rollover certificates.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Of course, another realistic scenario would be one in
> 
> which
> 
>>>a
>>>
>>>
>>>>>CA
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>generated
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>self-issued key rollover certificates upon key rollover
> 
> and
> 
>>>>>then
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>had
>>>>>>>>>>>>>
>>>>>>>>>>>the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>Root CA issue a CA certificate to its new key.  In this
>>>>>>>>>>>>>
>>>case,
>>>
>>>
>>>>>as
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>you suggest, any of the certification paths from figures
> 
> 1,
> 
>>>2,
>>>
>>>
>>>>>>>or 3
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>could be
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>constructed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>As for the contents of the AIA extension, here is what I
>>>>>>>>>>>>>
>>>have
>>>
>>>
>>>>>>>>>>>specified
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>in
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the
>>>>>>>>>>>>>
>>>>>Common
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>Policy":
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>The authorityInfoAccess extension uses URIs for two
>>>>>>>>>>>>>
>>>purposes.
>>>
>>>
>>>>>>>When
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>id-ad-caIssuers access method is used, the access location
>>>>>>>>>>>>>>specifies
>>>>>>>>>>>>>
>>>>>>>>>>>>where
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>certificates issued to the issuer of the certificate may
> 
> be
> 
>>>>>>>found.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>If
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>LDAP
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>is used, the URI must include the DN of the entry
> 
> containing
> 
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>relevant
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>certificates and specify the directory attribute in which
>>>>>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>>>>>>certificates
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>are located. If the directory in which the certificates
> 
> are
> 
>>>>>>>stored
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>expects
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>the "binary" option to be specified, then the attribute
> 
> type
> 
>>>>>>>must
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the
>>>>>>>>>>>>>
>>>URI
>>>
>>>
>>>>>>>must
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>point to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>a
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>file that has an extension of ".p7c" that contains a
>>>>>>>>>>>>>
>>>>>certs-only
>>>>>
>>>>>
>>>>>
>>>>>>>CMS
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>message (see RFC 2633). The CMS message should include all
>>>>>>>>>>>>>>certificates
>>>>>>>>>>>>>
>>>>>>>>>>>issued
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>the issuer of this certificate, but must at least contain
>>>>>>>>>>>>>
>>>all
>>>
>>>
>>>>>>>>>>>>certificates
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>issued to the issuer of this certificate in which the
>>>>>>>>>>>>>
>>>subject
>>>
>>>
>>>>>>>>>>>>>>public
>>>>>>>>>>>>>
>>>>>>>>>>>key
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>may
>>>>>>>>>>>>>>be used to verify the signature on this certificate. ....
>>>>>>>>>>>>>
>>>For
>>>
>>>
>>>>>a
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>certificate issued by "Good CA", some examples of URIs
> 
> that
> 
>>>>>may
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>appear as the
>>>>>>>>>>>>>
>>>>>>>>>>>access
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>location in an authorityInfoAccess extension when the
>>>>>>>>>>>>>
>>>>>>>>>>>id-ad-caIssuers
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>access
>>>>>>>>>>>>>>method is used are:
>>>>>>>>>>>>>
>>>>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?c
> 
> A
> 
>>>C
>>>
>>>
>>>>>e
>>>>>
>>>>>
>>>>>
>>>>>>>r
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>t
>>>>>>>>>>>>>i
>>>>>>>>>>>>
>>>>>>>>>>>fi
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>ca
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>te
>>>>>>>>>>>>>>,crossCertificatePair
>>>>>>>>>>>>>
>>>>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACer
> 
> t
> 
>>>i
>>>
>>>
>>>>>f
>>>>>
>>>>>
>>>>>
>>>>>>>i
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>c
>>>>>>>>>>>>>a
>>>>>>>>>>>>
>>>>>>>>>>>te
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>;b
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>in
>>>>>>>>>>>>>>ary,crossCertificatePair;binary
>>>>>>>>>>>>>
>>>>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certs
> 
> I
> 
>>>s
>>>
>>>
>>>>>s
>>>>>
>>>>>
>>>>>
>>>>>>>u
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>e
>>>>>>>>>>>>>d
>>>>>>>>>>>>
>>>>>>>>>>>To
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>Go
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>od
>>>>>>>>>>>>>>CA.p7c
>>>>>>>>>>>>>>For both LDAP and HTTP, the URI provides the exact
> 
> location
> 
>>>>>>>where
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>information is to be located, so there is no requirement
> 
> for
> 
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>relying
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>party to try to figure out where information is located.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>The HTTP URI points to a certs-only CMS message that
>>>>>>>>>>>>>
>>>includes
>>>
>>>
>>>>>>>all
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>certificates issued to the CA identified in the issuer
> 
> field
> 
>>>>>of
>>>>>
>>>>>
>>>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>certificate.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>The LDAP URI points to the cACertificate and
>>>>>>>>>>>>>
>>>>>>>crossCertificatePair
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>attributes of the directory entry of the CA identified in
>>>>>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>>>>>>>>issuer field of
>>>>>>>>>>>>>
>>>>>>>>>>>the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>certificate.  These two attributes together hold all of
> 
> the
> 
>>>>>>>>>>>certificates
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>issued to the CA:  the cACertificate attribute holds the
>>>>>>>>>>>>>
>>>CA's
>>>
>>>
>>>>>>>self-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>issued
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>certificates and the crossCertificatePair attribute holds
>>>>>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>>>>>>>>cross-certificates issued to the CA by other CAs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Dave
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Stefan Santesson wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>David,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>I have some comments and questions on this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>First of all we can conclude that in some scenarios
> 
> (figure
> 
>>>1)
>>>
>>>
>>>>>>>>>>>>>>where
>>>>>>>>>>>>>
>>>>>>>>>>>a
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>self
>>>>>>>>>>>>>>issued certificate is inserted into the path, you are
> 
> likely
> 
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>find
>>>>>>>>>>>>>
>>>>>>>>>>>the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>CRL
>>>>>>>>>>>>>>issuer cert in the path. (given that the new CA have a
>>>>>>>>>>>>>
>>>common
>>>
>>>
>>>>>>>key
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>and
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>certificate for cert signing and CRL signing).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Figure 1, 2 and 3 describe the same case. It is just
>>>>>>>>>>>>>
>>>>>describing
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>different
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>path building strategies. An application that has access
>>>>>>>>>>>>>
>>>>>locally
>>>>>
>>>>>
>>>>>
>>>>>>>to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>all
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>chaining options may however still choose path 2 for the
>>>>>>>>>>>>>
>>>certs
>>>
>>>
>>>>>>>and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>path
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>1
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>for the CRL independent of each other (which I think
> 
> figure
> 
>>>3
>>>
>>>
>>>>>>>tries
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>describe)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Another comment is the structure of AIA extensions. The
> 
> use
> 
>>>>>I'm
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>familiar
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>with doesn't use AIA to describe a directory entry where
> 
> it
> 
>>>is
>>>
>>>
>>>>>>>left
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>validation application logic to be intelligent enough to
>>>>>>>>>>>>>
>>>find
>>>
>>>
>>>>>>>>>>>>appropriate
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>certificate data from the directory. The model I'm
> 
> familiar
> 
>>>>>with
>>>>>
>>>>>
>>>>>
>>>>>>>is
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>when
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>the
>>>>>>>>>>>>>>AIA URL explicitly identifies the exact location of the
>>>>>>>>>>>>>
>>>>>>>appropriate
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>CA
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>certificate file, relieving the validation software from
>>>>>>>>>>>>>
>>>>>complex
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>information queries. If just location of explicit
>>>>>>>>>>>>>
>>>certificate
>>>
>>>
>>>>>>>files
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>are
>>>>>>>>>>>>>
>>>>>>>>>>>identified
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>through AIA, the presence of an AIA may not help finding
> 
> the
> 
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>signer
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>cert
>>>>>>>>>>>>>>if this is different from the CA certificate. This is also
>>>>>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>>>>>problem
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>with
>>>>>>>>>>>>>>Denis proposal.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>I think we share the basic conclusion that the ability to
>>>>>>>>>>>>>
>>>>>locate
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>the
>>>>>>>>>>>>>
>>>>>>>>>>>CRL
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>signer certificate directly through the CRL could be very
>>>>>>>>>>>>>
>>>>>>>useful.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>At
>>>>>>>>>>>>>
>>>>>>>>>>>>least
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>in the case of indirect CRL but it could also be proven
> 
> very
> 
>>>>>>>useful
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>in
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>CA
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>re-keying scenarios.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>The easiest solution would probably be to allow AIA to be
>>>>>>>>>>>>>
>>>used
>>>
>>>
>>>>>>>in
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>its
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>current shape and structure as a CRL extension (MUST NOT
> 
> be
> 
>>>>>>>>>>>critical).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>It
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>would present a very clear and uncomplicated logic to
>>>>>>>>>>>>>
>>>>>>>certificate
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>validating applications in many cases.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Stefan Santesson
>>>>>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>________________________________________
>>>>>>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>>>>>>>Sent: den 7 oktober 2004 18:35
>>>>>>>>>>>>>>To: Stefan Santesson
>>>>>>>>>>>>>>Cc: pkix
>>>>>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Stefan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>I think what you are proposing is a good idea.  In most
>>>>>>>>>>>>>
>>>cases,
>>>
>>>
>>>>>>>path
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>discovery algorithms assume that both the trust anchor (or
>>>>>>>>>>>>>
>>>>>trust
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>anchors)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>and the end entity certificate are provided as input.  In
>>>>>>>>>>>>>
>>>this
>>>
>>>
>>>>>>>>>>>>>>case,
>>>>>>>>>>>>>
>>>>>>>>>>>one
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>may
>>>>>>>>>>>>>>need to construct a certification path without a priori
>>>>>>>>>>>>>
>>>access
>>>
>>>
>>>>>>>to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>end
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>entity certificate (the one with the subject public key
>>>>>>>>>>>>>
>>>>>>>>>>>corresponding to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>the
>>>>>>>>>>>>>>CRL signing key).  Including an AIA extension (or some
> 
> other
> 
>>>>>>>>>>>pointer) in
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>the
>>>>>>>>>>>>>>CRL would provide the relying party with a simple way to
>>>>>>>>>>>>>
>>>>>obtain
>>>>>
>>>>>
>>>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>end
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>entity certificate for the CRL signing key's certification
>>>>>>>>>>>>>
>>>>>path.
>>>>>
>>>>>
>>>>>
>>>>>>>On
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>other hand, I believe that a relying party should be able
> 
> to
> 
>>>>>>>>>>>construct
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>certification path even without an AIA extension in the
> 
> CRL,
> 
>>>>>so
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>long
>>>>>>>>>>>>>
>>>>>>>>>>>as
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>it
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>is not an indirect CRL.  Attached is a drawing of the
> 
> three
> 
>>>>>>>basic
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>scenarios that I expect a relying party may encounter:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>In each of these scenarios, the CA has performed key
>>>>>>>>>>>>>
>>>rollover
>>>
>>>
>>>>>>>and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>is
>>>>>>>>>>>>>
>>>>>>>>>>>>only
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>signing CRLs with its new key.  The diagrams would look
>>>>>>>>>>>>>
>>>>>similar,
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>however,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>if
>>>>>>>>>>>>>>the CA simply choose to use different keys to sign
>>>>>>>>>>>>>
>>>>>certificates
>>>>>
>>>>>
>>>>>
>>>>>>>and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>CRLs
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>for
>>>>>>>>>>>>>>some other reason.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>If the PKI architecture resembled figure 1, then the
>>>>>>>>>>>>>
>>>>>>>certification
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>path
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>for
>>>>>>>>>>>>>>the CRL signing key would just be a subset of the
>>>>>>>>>>>>>
>>>>>certification
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>path
>>>>>>>>>>>>>
>>>>>>>>>>>for
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>the
>>>>>>>>>>>>>>EE certificate, so no addition path discovery would be
>>>>>>>>>>>>>
>>>needed.
>>>
>>>
>>>>>>>>>>>>>>If the PKI architecture resembled figure 1, then it would
> 
> be
> 
>>>>>>>>>>>necessary
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>obtain the new-signed-with-old self-issued certificate.
> 
> In
> 
>>>>>>>>>>>>>>building
>>>>>>>>>>>>>
>>>>>>>>>>>the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>certification path to the EE certificate, however, the
>>>>>>>>>>>>>
>>>relying
>>>
>>>
>>>>>>>>>>>>>>party
>>>>>>>>>>>>>
>>>>>>>>>>>>will
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>obtain the certificates pointed to by the AIA extension in
>>>>>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>EE
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>certificate.  This AIA extension will point to a location
>>>>>>>>>>>>>>containing
>>>>>>>>>>>>>
>>>>>>>>>>>all
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>certificates issued to CA 2, which would include both the
>>>>>>>>>>>>>
>>>>>>>>>>>certificate
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>issued
>>>>>>>>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.
> 
> So,
> 
>>>>>>>even
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>though
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>the
>>>>>>>>>>>>>>self-issued certificate would not be part of the
>>>>>>>>>>>>>
>>>certification
>>>
>>>
>>>>>>>path
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>EE certificate, it would be downloaded by the relying
> 
> party
> 
>>>>>>>during
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>construction of that certification path.  (Yes, there are
>>>>>>>>>>>>>
>>>>>>>circular
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>dependency issues in figure 2, but that is another issue.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>A similar situation would happen if the PKI architecture
>>>>>>>>>>>>>
>>>>>>>resembled
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>figure
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>3.  The AIA extension in the EE certificate would point to
> 
> a
> 
>>>>>>>>>>>location
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>containing certificates issued to CA 3.  When the relying
>>>>>>>>>>>>>
>>>>>party
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>downloaded
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>these certificates, it would obtain both of the
> 
> certificates
> 
>>>>>>>issued
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>by
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>Root to CA 3 and so again would have the certificate
> 
> needed
> 
>>>to
>>>
>>>
>>>>>>>>>>>validate
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>the
>>>>>>>>>>>>>>CRL signing key.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>In the case of an indirect CRL, things may not work as
> 
> well.
> 
>>>>>If
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>indirect
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>CRLs were used, and the PKI architecture resembled figures
> 
> 2
> 
>>>>>or
>>>>>
>>>>>
>>>>>
>>>>>>>3
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>(replacing "New Key" with a different CA), then the set of
>>>>>>>>>>>>>>certificates pointed
>>>>>>>>>>>>>
>>>>>>>>>>>to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>by
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>the AIA extension in the EE certificate would not include
>>>>>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>>>>>>certificate
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>of
>>>>>>>>>>>>>>the CRL signer.  One could find this certificate by
> 
> building
> 
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>reverse direction and using the SIA extension, but that
> 
> may
> 
>>>>>not
>>>>>
>>>>>
>>>>>
>>>>>>>be
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>the most convenient solution.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>So, when indirect CRLs are being used, it seems that it
>>>>>>>>>>>>>
>>>would
>>>
>>>
>>>>>be
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>very
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>useful
>>>>>>>>>>>>>>to have a pointer in the CRL to the CRL signing
> 
> certificate.
> 
>>>>>>>When
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>CRL
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>is not indirect, the need for this pointer does not seem
> 
> to
> 
>>>be
>>>
>>>
>>>>>>>as
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>clear,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>but
>>>>>>>>>>>>>>I can't see any harm in including it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Dave
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Stefan Santesson wrote:
>>>>>>>>>>>>>>All,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>I'm interested in the opinion from members on this list
>>>>>>>>>>>>>
>>>about
>>>
>>>
>>>>>>>>>>>discovery
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>of
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>CRL signer's certificate in non directory centric
>>>>>>>>>>>>>
>>>>>environments.
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>The problem is the following.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>The relying party (RP) needs to check validity of a
>>>>>>>>>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>
>>>>>>>and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>finds
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>a
>>>>>>>>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this
>>>>>>>>>>>>>
>>>CRL
>>>
>>>
>>>>>>>>>>>>>>which
>>>>>>>>>>>>>
>>>>>>>>>>>in
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>this
>>>>>>>>>>>>>>particular case is either signed by another key of the CA
>>>>>>>>>>>>>
>>>>>>>(re-keyed
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>CA)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>or
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>another entity (indirect CRL).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>In this case the relying party needs to obtain the
>>>>>>>>>>>>>
>>>certificate
>>>
>>>
>>>>>>>of
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>CRL
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>signer which may NOT be part of the original chain. In a
>>>>>>>>>>>>>
>>>>>>>directory
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>centric
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>solution this is retrieved from the directory, but what if
>>>>>>>>>>>>>
>>>>>such
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>directory
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>is
>>>>>>>>>>>>>>not available or accessible.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>The RP have thus no hint where to find the CRL issuers
>>>>>>>>>>>>>
>>>>>>>certificate
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>unless
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>the RP already have possession of it by some other means.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Is seems that CRLs would need an AIA extension with the
>>>>>>>>>>>>>
>>>option
>>>
>>>
>>>>>>>to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>point
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>the location of the signers certificate in the same manner
>>>>>>>>>>>>>
>>>as
>>>
>>>
>>>>>is
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>possible
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>for certificates.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Maybe AIA should be defined as both cert and CRL extension
>>>>>>>>>>>>>
>>>and
>>>
>>>
>>>>>>>not
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>only
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>certificate extension as today.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Thoughts and comments?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>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 i9IHIs78064987; Mon, 18 Oct 2004 10:18:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IHIs9Y064986; Mon, 18 Oct 2004 10:18:54 -0700 (PDT)
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 i9IHIp7T064977 for <[e-mail]>; Mon, 18 Oct 2004 10:18:53 -0700 (PDT) (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 i9IHIqCd009904 for <[e-mail]>; Mon, 18 Oct 2004 13:18:52 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Mon, 18 Oct 2004 13:18:52 -0400
Message-ID: <005001c4b536$8a6801f0$[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 i9IHIs7T064981
Sender: [e-mail]
Precedence: 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 AIA approach is simpler, has lower computational complexity, and is
well-supported by the commercial products.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Monday, October 18, 2004 10:58 AM
To: Santosh Chokhani; Stefan Santesson
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs


Santosh and Stefan,

Now we get to the point that there exists one solution, while the thread 
started saying that there was no other solution.

We can now start to discuss the advantages and disadvantages of the two 
solutions.

However, we have to provide a fair view.

For the time being, you have only considered the disadvantages of the 
*current* solution, i.e. using SIA. It would be fair that you also consider 
its advantages and that we take the time to have a fair comparison.

> The SIA can be used to find the certificate, but it leads to the 
> exponential growth in the search base in the case of indirect CRL.

This is an argument about disadvantages. However this argument is incorrect:

there is no exponential grow. A CA nominates an authority either as :

  1 - "CA issuer + CRL issuer"
  2 - "CA issuer only", or
  3 - "CRL Issuer only"

Once the path is constructed, if every CA certificate includes the SIA 
extension, then this is straightforward.

> Also, I do not think SIA is that well supported.

I could say that the new proposal is not "that well supported" but this 
would be an argument leading nowhere. :-|

The SIA extension is very useful and we should make our best efforts so that

it will be more and more supported. Providing "yet another way" is not going

to lead in that direction. :-(

> Thus, we need to consider the commercial realities and permit a simple 
> and elegant approach of using AIA to prime the pump (so to speak) to 
> start the CRL signer path development.

SIA was not present in RFC 2459. It has been introduced in RFC 3280 and this

is a good point. It should be generalized in order to support 
interoperability. Going down from trust points to leaf certificates allow to

cover any case.

The answers to Stefan follow:

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Monday, October 18, 2004 8:19 AM
> To: Denis Pinkas
> Cc: Santosh Chokhani; pkix
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> Thanks Denis,
> 
> I now finally understand your SIA alternative.
> 
> There are some major problems with it though.

> 1) How can the RP know what certificate's SIA it would use to find the 
> CRL signer cert?

> You just picked the right certificate in my example since I gave that 
> information in the example. But the RP don't know that path, it only 
> knows the path of the EE cert and the name of the CRL issuer!

This is sufficient to find out the right certificate once you know where the

CA places the certificates that it has issued.

> 2) And even if RP knew the path beforehand, finding THE one CRL signer 
> certificate from a CRL AIA is much more direct and efficient than 
> finding among all issued certificates from a CA the 1 out of x issued 
> certificates that is the CRL Issuer cert.

Usually a CA issues a small number of CA certificates and CRL certificates. 
So this is not a problem.

> 3) Using SIA in the examples requires available directories and 
> directory enabled clients. How do you solve the problem if either of 
> these is not available?

It could work as well with HTTP using the recent draft that has been
proposed.

> Do you seriously suggest that use of SIA is a better and more 
> effective way to address this problem or are you just pointing out the 
> fact that there are SOME cases where use of SIA may work in theory?

I rather believe that your question was:

"Do you suggest that use of SIA is a better and more effective way to 
address this problem or are you just pointing out the fact that there are 
SOME cases where use of SIA may work ?

SIA is certainly better and shoud be generalized to ease path contruction, 
not only for CRL issuers but also for CAs.

SIA may work in ALL cases, unless you provide an example where it cannot.

Now I have spent quite a lot of time on that topic (on which I am personally

NOT interested), but since I have been asked by the Security Area Director 
to provide details I needed to respond.

I will not be able to sustain the same level of discussions in the next 
coming days. In particular, I will not be in my office tomorrow. So you have

plenty of time to consider pros and cons for both approaches and do not take

silence as approval.

Denis

> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: den 18 oktober 2004 12:28
>>To: Stefan Santesson
>>Cc: Santosh Chokhani; pkix
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>Stefan,
>>
>>
>>>Denis,
>>
>>>If I get you right you mean that one can always successfully use AIA
>>
> and
> 
>>>SIA in certs to solve discovery of CRL signer cert.
>>>Others on this list (me included) don't understand how. It would
>>>therefore be useful if you told us.
>>>
>>>I'll try to explain the problem from my perspective one more time.
>>
>>Thanks.
>>
>>
>>>Note: "->" in these examples means "issued by"
>>
>>Fine.
>>
>>
>>>Case 1 - indirect CRL:
>>>
>>>Cert path is:  EE_Cert -> CA_1 -> Root-CA
>>>CRL path for EE_Cert is:  CRL -> CRL_Issuer_B -> Root-CA
>>
>>This means Root-CA has nominated CA_1 and a CRL_Issuer_B and that CA_1
> 
> has
> 
>>chosen to use CRL_Issuer_B for revocation checking for some
> 
> certificates.
> 
>>>Scenario:
>>>Relying party has access to the cert path, discovers the CRL through
>>
> CDP
> 
>>>in EE_Cert.
>>
>>If there is no attack on the objects stored at the CRL DP, the CRL
> 
> Issuer
> 
>>from that CRL is CRL_Issuer_B. Now the relying party needs to get the
>>certificate isued by Root-CA for CRL_Issuer_B. If Root-CA has included
> 
> a
> 
>>SIA
>>extension in his self-signed certificate, then using that extension
> 
> allows
> 
>>to get the CRL_Issuer_B certificate issued by the Root-CA.
>>
>> > The RP searches the location specified in SIA through
>>
>>>id-ad-caRepository in the CA_1 cert but finds nothing useful since
>>>revocation is subordinated to another entity (CRL_Issuer_B)
>>
>>Correct, but looking in Root-CA allows to find something useful, if
> 
> the
> 
>>self-signed certificate includes a SIA extension.
>>
>>
>>>In this case, the problem could be solved if an AIA in the CRL
>>
> indicated
> 
>>>the access location of the CRL Issuer cert.
>>
>>This would be an *alternative* way.
>>
>>
>>>Case 2 - re-keyed CA.
>>>
>>>Cert path is:  EE_Cert -> CA_1(old key) -> Root-CA
>>>CRL path for EE_Cert is:  CRL -> CA_1(new key) -> Root-CA
>>
>>This means that the EE_Cert chain has been created with CA_1(old key)
> 
> and
> 
>>that the CRL issuer that was originaly used when the EE_Cert was
> 
> created
> 
>>has
>>been changed and a new CRL Issuer got a certificate under CA_1(new
> 
> key)
> 
>>and
>>is now the legitimate CRL issuer for the CRL DP originally mentionned
> 
> in
> 
>>the
>>EE_Cert.
>>
>>
>>>The 2 CA_1 certificates above (old key and new key) are issued to
>>>different subject keys belonging to the same CA (same name). The 
>>>cert CA_1(old key) was issued before creation of cert CA_1(new
>>
> key)
> 
>>>and have thus no reference to CA_1(new key) in its SIA
>>>
>>>Scenario:
>>>RP discovers the CRL for the EE_Cert through the CDP but doesn't
>>
> possess
> 
>>>the CRL issuer cert. The RP client searches the SIA of the CA_1(old
>>
> key)
> 
>>>but finds no direct reference to the CRL signer cert. Since the RP
>>>client has no access to a directory where the CRL signer cert could
>>
> be
> 
>>>found through directory lookup, cert validation fails.
>>
>>Correct, but looking in Root-CA allows to find something useful, if
> 
> the
> 
>>self-signed certificate includes a SIA extension.
>>
>>
>>>In this scenario the problem could be solved through an AIA in the
>>
> CRL.
> 
>>This would be an *alternative* way.
>>
>>Denis
>>
>>
>>>
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>Sent: den 15 oktober 2004 17:30
>>>>To: Stefan Santesson
>>>>Cc: Santosh Chokhani; pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>Stefan,
>>>>
>>>>
>>>>
>>>>>Denis,
>>>>
>>>>>Unfortunately I fail to understand your questions, issues and
>>>>
>>>requests.
>>>
>>>
>>>>The sentence below demonstrates that you understand the issue.
>>>>
>>>>
>>>>
>>>>>It would be very useful if you could explain how current mechanisms
>>>>
>>>can
>>>
>>>
>>>>>be used in a simple and straightforward manner to discover CRL
>>>>
>>>signer
>>>
>>>
>>>>>certificates in ALL the use cases discussed, mainly re-keyed CA and
>>>>>indirect CRLs.
>>>>
>>>>You are also reversing the question. Using your terms, my question
>>>
>>>would
>>>
>>>
>>>>be:
>>>>
>>>>"It would be very useful if you could explain how current mechanisms
>>>>CANNOT be used in a simple and straightforward manner to discover 
>>>>CRL
>>>
> signer
> 
>>>>certificates in ONE or MORE the use cases discussed, mainly re-keyed
>>>
>>>CA
>>>
>>>
>>>>and
>>>>indirect CRLs."
>>>>
>>>>Denis
>>>>
>>>>
>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [e-mail]
>>>>>
>>>>>[mailto:[e-mail]]
>>>>>
>>>>>
>>>>>
>>>>>>On Behalf Of Denis Pinkas
>>>>>>Sent: den 14 oktober 2004 17:13
>>>>>>To: Santosh Chokhani
>>>>>>Cc: 'pkix'
>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>
>>>>>>
>>>>>>Santosh,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Denis:
>>>>>>
>>>>>>>With the three assumptions/constraints I provided, how would you
>>>>>>
>>>>>locate
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>>CRL issuer certificate for the two examples using 3280 extensions
>>>>>>
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>without putting AIA in the CRL?
>>>>>>
>>>>>>As far as I understand, the three assumptions are:
>>>>>>
>>>>>>1.  You are directory challenged; and
>>>>>>   [I do not understand what this means]
>>>>>>2.  You use AIA to develop the path; and
>>>>>>   [It does not matter]
>>>>>>3.  You develop the path from the end entity to trust anchor
>>>>>>   [Could also be the contrary].
>>>>>>
>>>>>>If this is not correct, thus please correct.
>>>>>>
>>>>>>Then my request is: "using ANY OF the current extensions that are
>>>>>
>>>>>defined
>>>>>
>>>>>
>>>>>
>>>>>>in
>>>>>>RFC 3280", which includes SIA.
>>>>>>
>>>>>>In your explanations  you said :
>>>>>>"if you do no deal with SIA et. al"
>>>>>>
>>>>>>This last assumption is neither part of the three assumptions and
>>>>>
>>>does
>>>
>>>
>>>>>not
>>>>>
>>>>>
>>>>>
>>>>>>conform to my request.
>>>>>>
>>>>>>Denis
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>That is my point.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>>>Sent: Thursday, October 14, 2004 6:22 AM
>>>>>>>To: Santosh Chokhani
>>>>>>>Cc: 'pkix'
>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>
>>>>>>>Santosh,
>>>>>>>
>>>>>>>You misread my request. I said:
>>>>>>>
>>>>>>>"For the time being, I would like that you provide an example
>>>>>>
>>>where,
>>>
>>>
>>>>>>when
>>>>>>
>>>>>>
>>>>>>
>>>>>>>using the current extensions that are defined in RFC 3280, it
>>>>>>
> will
> 
>>>>>NOT
>>>>>
>>>>>
>>>>>
>>>>>>be
>>>>>>
>>>>>>
>>>>>>
>>>>>>>possible to locate a CRL Issuer certificate."
>>>>>>>
>>>>>>>Maybe I would have needed to be clearer and say :
>>>>>>>
>>>>>>>"For the time being, I would like that you provide an example
>>>>>>
>>>where,
>>>
>>>
>>>>>>when
>>>>>>
>>>>>>
>>>>>>
>>>>>>>using ANY OF the current extensions that are defined in RFC 3280,
>>>>>>
>>>it
>>>
>>>
>>>>>>will
>>>>>>
>>>>>>
>>>>>>
>>>>>>>NOT be possible to locate a CRL Issuer certificate."
>>>>>>>
>>>>>>>The examples you provide below do not fulfil this request.
>>>>>>>
>>>>>>>The assumption is that there exists a path to be tested for
>>>>>>
>>>>>revocation
>>>>>
>>>>>
>>>>>
>>>>>>>checking (and that it does not matter to know which way it has
>>>>>>
> been
> 
>>>>>>>constructed).
>>>>>>>
>>>>>>>I am not saying that using AIA in CRL might not be useful, but I
>>>>>>
> am
> 
>>>>>>still
>>>>>>
>>>>>>
>>>>>>
>>>>>>>lacking the demonstration that there would be no other way.
>>>>>>>
>>>>>>>Denis
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Denis:
>>>>>>>>
>>>>>>>>Two examples are very simple: one for direct CRL Issuer and one
>>>>>>>
>>>for
>>>
>>>
>>>>>>>>Indirect CRL Issuer.
>>>>>>>>
>>>>>>>>Let us make the following assumptions that Stefan was making:
>>>>>>>>
>>>>>>>>1.  You are directory challenged; and
>>>>>>>>2.  You use AIA to develop the path; and
>>>>>>>>3.  You develop the path from the end entity to trust anchor.
>>>>>>>>
>>>>>>>
>>>>>>>>From what I know of MS CAPI, these are reasonable
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>assumptions/constraints.
>>>>>>>>
>>>>>>>>Now the examples.
>>>>>>>>
>>>>>>>>Example 1: Direct CRL Issuer
>>>>>>>>
>>>>>>>>The certificate trust path is:
>>>>>>>>Root --> CA1 --> CA 2, old key --> Denis
>>>>>>>>
>>>>>>>>The CRL trust path is:
>>>>>>>>Root --> CA1 --> CA 2, new key --> CRL
>>>>>>>>
>>>>>>>>(Note: We do not do self-issued certificate since there is no
>>>>>>>
>>>>>simple,
>>>>>
>>>>>
>>>>>
>>>>>>>>secure way to check their revocation status).
>>>>>>>>
>>>>>>>>Now, with AIA in CRL, finding the CA2, new key certificate is
>>>>>>>>straightforward.  How would you find it if you do no deal with
>>>>>>>
> SIA
> 
>>>>>et.
>>>>>
>>>>>
>>>>>
>>>>>>>>al.
>>>>>>>>
>>>>>>>>Example 2: Indirect CRL Issuer
>>>>>>>>
>>>>>>>>The certificate trust path is:
>>>>>>>>Root --> CA1 --> CA 2 --> Denis
>>>>>>>>(Note: Denis's certificate points to CRL DP of an indirect CRL
>>>>>>>
>>>>>issued
>>>>>
>>>>>
>>>>>
>>>>>>>>by CAI.
>>>>>>>>
>>>>>>>>The CRL trust path is:
>>>>>>>>Root --> CAI --> CRL
>>>>>>>>
>>>>>>>>Now, with AIA in CRL, finding the CAI certificate is
>>>>>>>
>>>>>straightforward.
>>>>>
>>>>>
>>>>>
>>>>>>>>How would you find it if you do no deal with SIA et. al.
>>>>>>>>
>>>>>>>>In addition to the need cited above, please note that the
>>>>>>>
>>>extension
>>>
>>>
>>>>>>>>semantics does not change, it does not hinder any
>>>>>>>
>>>interoperability,
>>>
>>>
>>>>>>>>and it does not break any backward compatibility.  So, what if I
>>>>>>>>wanted to use this extension in the CRL.  It does no harm to
>>>>>>>
> other
> 
>>>>>>>>relying parties.
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: [e-mail]
>>>>>>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>>>>>>>Sent: Wednesday, October 13, 2004 11:01 AM
>>>>>>>>To: Stefan Santesson
>>>>>>>>Cc: Santosh Chokhani; pkix
>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>Stefan,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Denis,
>>>>>>>>
>>>>>>>>
>>>>>>>>>I'm not sure what you mean.
>>>>>>>>
>>>>>>>>
>>>>>>>>For the time being, I would like that you provide an example
>>>>>>>
>>>where,
>>>
>>>
>>>>>>>>when
>>>>>>>>using the current extensions that are defined in RFC 3280, it
>>>>>>>
> will
> 
>>>>>NOT
>>>>>
>>>>>
>>>>>
>>>>>>be
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>possible to locate a CRL Issuer certificate.
>>>>>>>>
>>>>>>>>If you are able to provide that example, then it would justify
>>>>>>>
> the
> 
>>>>>>>>need for
>>>>>>>>an extension at least for one case. Then we can see what that
>>>>>>>
> case
> 
>>>>>is.
>>>>>
>>>>>
>>>>>
>>>>>>>>I am awaiting that example.
>>>>>>>>
>>>>>>>>Denis
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>I conclude that I agree with Santosh.
>>>>>>>>>
>>>>>>>>>The debate is still open... Feel free to express your opinion.
>>>>>>>>>
>>>>>>>>>Stefan Santesson
>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>-----Original Message-----
>>>>>>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>>>>>>Sent: den 13 oktober 2004 16:34
>>>>>>>>>>To: Stefan Santesson
>>>>>>>>>>Cc: Santosh Chokhani; pkix
>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>>
>>>>>>>>>>Stefan,
>>>>>>>>>>
>>>>>>>>>>You are making a conclusion without letting me the time to
>>>>>>>>>
>>>>>respond. I
>>>>>
>>>>>
>>>>>
>>>>>>>>>>will need more time to look at the pictures (and understand
>>>>>>>>>
>>>them).
>>>
>>>
>>>>>>>>>>For the time being, I am still reluctant to accept
>>>>>>>>>
>>>>>>>>>"yet-another-method".
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>We already have too many.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Santosh,
>>>>>>>>>>>
>>>>>>>>>>>I conclude that we are in complete and total agreement. The
>>>>>>>>>>>question is how to go about this.
>>>>>>>>>>
>>>>>>>>>>>Could we do this amendment to RFC 3280 in its next revision?
>>>>>>>>>>
> It
> 
>>>>>>>>>>>would hopefully just be a minor change.
>>>>>>>>>>
>>>>>>>>>>This is exactly what I feared.
>>>>>>>>>>
>>>>>>>>>>We usually end-up with a "minor change" in an extension
>>>>>>>>>
> without
> 
>>>>>>>>>>saying cleary how and when it shall/should be used.
>>>>>>>>>>
>>>>>>>>>>I still have in mind that:
>>>>>>>>>>
>>>>>>>>>>1) a certification path must first be constructed,
>>>>>>>>>>2) then the revocation checking of that path must be done.
>>>>>>>>>>
>>>>>>>>>>This means that information about CRL issuers certificates
>>>>>>>>>
>>>>>locations
>>>>>
>>>>>
>>>>>
>>>>>>>>>may
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>certainly be found in that chain. If not, I would like an
>>>>>>>>>
>>>example.
>>>
>>>
>>>>>>>>>>Denis
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>It would not change the definition of AIA just add that it
>>>>>>>>>>
> can
> 
>>>be
>>>
>>>
>>>>>>>>>used
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>also as CRL extension and list eventual restrictions and
>>>>>>>>>
>>>guidance
>>>
>>>
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>>>>>use
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>with CRLs.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Stefan Santesson
>>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>-----Original Message-----
>>>>>>>>>>>>From: [e-mail]
>>>>>>>>>>>
>>>>>>>>>[mailto:[e-mail]]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>On Behalf Of Santosh Chokhani
>>>>>>>>>>>>Sent: den 13 oktober 2004 04:33
>>>>>>>>>>>>To: 'pkix'
>>>>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan:
>>>>>>>>>>>>
>>>>>>>>>>>>In terms of certificate discovery, your proposal for AIA in
>>>>>>>>>>>
>>>CRL
>>>
>>>
>>>>>is
>>>>>
>>>>>
>>>>>
>>>>>>>>>more
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>robust.  The whole idea of self-issued key rollover
>>>>>>>>>>>
>>>certificates
>>>
>>>
>>>>>>>>>>>>and
>>>>>>>>>>>
>>>>>>>>>>then
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>using the new key to issue CRL is fraught with security
>>>>>>>>>>>
>>>>>problems.
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>A secure solution would be one where the new key is
>>>>>>>>>>>
> certified
> 
>>>by
>>>
>>>
>>>>>>>>>>>>the parent
>>>>>>>>>>>
>>>>>>>>>CA.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>In
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>that case to obtain the new certificate, you could use AIA
>>>>>>>>>>>
> in
> 
>>>>>CRL.
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP
>>>>>>>>>>>
>>>in
>>>
>>>
>>>>>>>>>>>>certificate in question points to the indirect CRL.  You get
>>>>>>>>>>>
>>>>>that
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>CRL.  The AIA
>>>>>>>>>>>
>>>>>>>>>in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>CRL
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>gets you started for the indirect CRL issuer certification
>>>>>>>>>>>
>>>path
>>>
>>>
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>>>you
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>are
>>>>>>>>>>>>in business.
>>>>>>>>>>>>
>>>>>>>>>>>>-----Original Message-----
>>>>>>>>>>>>From: [e-mail]
>>>>>>>>>>>
>>>>>>>>>[mailto:[e-mail]]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>On
>>>>>>>>>>>>Behalf Of Stefan Santesson
>>>>>>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>>>>>>>>To: David A. Cooper
>>>>>>>>>>>>Cc: pkix
>>>>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>David,
>>>>>>>>>>>>
>>>>>>>>>>>>Thanks for the clarifications, they make sense.
>>>>>>>>>>>>I did misread your pictures.
>>>>>>>>>>>>
>>>>>>>>>>>>So can we conclude that for a re-keyed CA in accordance with
>>>>>>>>>>>
>>>RFC
>>>
>>>
>>>>>>>>>3280,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>either the CRL issuer certificate itself, or the location of
>>>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>>>>>>CRL issuer certificate, will be clearly identified/available
>>>>>>>>>>>
>>>for
>>>
>>>
>>>>>>>>>>>>the validating
>>>>>>>>>>>
>>>>>>>>>>party
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>in some cases, but not in others?
>>>>>>>>>>>>
>>>>>>>>>>>>Can we also conclude that there is no real discovery
>>>>>>>>>>>
> solution
> 
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>>>>>>indirect
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>CRLs?
>>>>>>>>>>>>
>>>>>>>>>>>>Do you then agree then that it could be appropriate to allow
>>>>>>>>>>>
>>>AIA
>>>
>>>
>>>>>as
>>>>>
>>>>>
>>>>>
>>>>>>>>>a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>CRL
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan Santesson
>>>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>>>>
>>>>>>>>>>>>________________________________________
>>>>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>>>>>Sent: den 12 oktober 2004 21:14
>>>>>>>>>>>>To: Stefan Santesson
>>>>>>>>>>>>Cc: pkix
>>>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan,
>>>>>>>>>>>>
>>>>>>>>>>>>I believe that you are misinterpreting the figures.  They
>>>>>>>>>>>
>>>really
>>>
>>>
>>>>>do
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>represent three different cases, not three different
>>>>>>>>>>>
>>>>>certification
>>>>>
>>>>>
>>>>>
>>>>>>>>>paths
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>that have been constructed through the same PKI
>>>>>>>>>>>
> architecture.
> 
>>>>>>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>>>>>>>>
>>>>>>>>>certificates.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>The
>>>>>>>>>>>>Root CA has issued a certificate to CA 1's new key, but not
>>>>>>>>>>>
>>>its
>>>
>>>
>>>>>old
>>>>>
>>>>>
>>>>>
>>>>>>>>>key
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>(either the Root CA never issued a certificate to CA 1's old
>>>>>>>>>>>
>>>key
>>>
>>>
>>>>>or
>>>>>
>>>>>
>>>>>
>>>>>>>>>that
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certificate has expired).
>>>>>>>>>>>>
>>>>>>>>>>>>In figure 2, CA 2 has also generated self-issued key
>>>>>>>>>>>
> rollover
> 
>>>>>>>>>>>>certificates. The Root CA has issued a certificate to CA 2's
>>>>>>>>>>>
>>>old
>>>
>>>
>>>>>>>>>>>>key, but not its
>>>>>>>>>>>
>>>>>>>>>new
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>key.
>>>>>>>>>>>>
>>>>>>>>>>>>In figure 3, when CA 3 performed key rollover, it requested
>>>>>>>>>>>
> a
> 
>>>>>new
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>CA certificate from the Root CA.  CA 3 did not generated
>>>>>>>>>>>>self-issued
>>>>>>>>>>>
>>>>>>>>>key
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>rollover certificates.
>>>>>>>>>>>>
>>>>>>>>>>>>Of course, another realistic scenario would be one in which
>>>>>>>>>>>
> a
> 
>>>CA
>>>
>>>
>>>>>>>>>>generated
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>self-issued key rollover certificates upon key rollover and
>>>>>>>>>>>
>>>then
>>>
>>>
>>>>>>>>>>>>had
>>>>>>>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>Root CA issue a CA certificate to its new key.  In this
>>>>>>>>>>>
> case,
> 
>>>as
>>>
>>>
>>>>>>>>>>>>you suggest, any of the certification paths from figures 1,
>>>>>>>>>>>
> 2,
> 
>>>>>or 3
>>>>>
>>>>>
>>>>>
>>>>>>>>>could be
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>constructed.
>>>>>>>>>>>>
>>>>>>>>>>>>As for the contents of the AIA extension, here is what I
>>>>>>>>>>>
> have
> 
>>>>>>>>>specified
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>in
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the
>>>>>>>>>>>
>>>Common
>>>
>>>
>>>>>>>>>>Policy":
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>The authorityInfoAccess extension uses URIs for two
>>>>>>>>>>>
> purposes.
> 
>>>>>When
>>>>>
>>>>>
>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>id-ad-caIssuers access method is used, the access location
>>>>>>>>>>>>specifies
>>>>>>>>>>>
>>>>>>>>>>where
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>certificates issued to the issuer of the certificate may be
>>>>>>>>>>>
>>>>>found.
>>>>>
>>>>>
>>>>>
>>>>>>>>>If
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>LDAP
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>is used, the URI must include the DN of the entry containing
>>>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>>>>relevant
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>certificates and specify the directory attribute in which
>>>>>>>>>>>
> the
> 
>>>>>>>>>>certificates
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>are located. If the directory in which the certificates are
>>>>>>>>>>>
>>>>>stored
>>>>>
>>>>>
>>>>>
>>>>>>>>>>expects
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the "binary" option to be specified, then the attribute type
>>>>>>>>>>>
>>>>>must
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the
>>>>>>>>>>>
> URI
> 
>>>>>must
>>>>>
>>>>>
>>>>>
>>>>>>>>>point to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>file that has an extension of ".p7c" that contains a
>>>>>>>>>>>
>>>certs-only
>>>
>>>
>>>>>CMS
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>message (see RFC 2633). The CMS message should include all
>>>>>>>>>>>>certificates
>>>>>>>>>>>
>>>>>>>>>issued
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the issuer of this certificate, but must at least contain
>>>>>>>>>>>
> all
> 
>>>>>>>>>>certificates
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>issued to the issuer of this certificate in which the
>>>>>>>>>>>
> subject
> 
>>>>>>>>>>>>public
>>>>>>>>>>>
>>>>>>>>>key
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>may
>>>>>>>>>>>>be used to verify the signature on this certificate. ....
>>>>>>>>>>>
> For
> 
>>>a
>>>
>>>
>>>>>>>>>>>>certificate issued by "Good CA", some examples of URIs that
>>>>>>>>>>>
>>>may
>>>
>>>
>>>>>>>>>>>>appear as the
>>>>>>>>>>>
>>>>>>>>>access
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>location in an authorityInfoAccess extension when the
>>>>>>>>>>>
>>>>>>>>>id-ad-caIssuers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>access
>>>>>>>>>>>>method is used are:
>>>>>>>>>>>
>>>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?c
>>>>>>>>A
>>>>>>>
> C
> 
>>>e
>>>
>>>
>>>>>r
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>t
>>>>>>>>>>>i
>>>>>>>>>>
>>>>>>>>>fi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>ca
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>te
>>>>>>>>>>>>,crossCertificatePair
>>>>>>>>>>>
>>>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACer
>>>>>>>>t
>>>>>>>
> i
> 
>>>f
>>>
>>>
>>>>>i
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>c
>>>>>>>>>>>a
>>>>>>>>>>
>>>>>>>>>te
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>;b
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>in
>>>>>>>>>>>>ary,crossCertificatePair;binary
>>>>>>>>>>>
>>>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certs
>>>>>>>>I
>>>>>>>
> s
> 
>>>s
>>>
>>>
>>>>>u
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>e
>>>>>>>>>>>d
>>>>>>>>>>
>>>>>>>>>To
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Go
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>od
>>>>>>>>>>>>CA.p7c
>>>>>>>>>>>>For both LDAP and HTTP, the URI provides the exact location
>>>>>>>>>>>
>>>>>where
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>information is to be located, so there is no requirement for
>>>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>>>relying
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>party to try to figure out where information is located.
>>>>>>>>>>>>
>>>>>>>>>>>>The HTTP URI points to a certs-only CMS message that
>>>>>>>>>>>
> includes
> 
>>>>>all
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>certificates issued to the CA identified in the issuer field
>>>>>>>>>>>
>>>of
>>>
>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>certificate.
>>>>>>>>>>>>
>>>>>>>>>>>>The LDAP URI points to the cACertificate and
>>>>>>>>>>>
>>>>>crossCertificatePair
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>attributes of the directory entry of the CA identified in
>>>>>>>>>>>
> the
> 
>>>>>>>>>>>>issuer field of
>>>>>>>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certificate.  These two attributes together hold all of the
>>>>>>>>>>>
>>>>>>>>>certificates
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>issued to the CA:  the cACertificate attribute holds the
>>>>>>>>>>>
> CA's
> 
>>>>>self-
>>>>>
>>>>>
>>>>>
>>>>>>>>>>issued
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>certificates and the crossCertificatePair attribute holds
>>>>>>>>>>>
> the
> 
>>>>>>>>>>>>cross-certificates issued to the CA by other CAs.
>>>>>>>>>>>>
>>>>>>>>>>>>Dave
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan Santesson wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>David,
>>>>>>>>>>>>
>>>>>>>>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>>>>>>>>
>>>>>>>>>>>>I have some comments and questions on this.
>>>>>>>>>>>>
>>>>>>>>>>>>First of all we can conclude that in some scenarios (figure
>>>>>>>>>>>
> 1)
> 
>>>>>>>>>>>>where
>>>>>>>>>>>
>>>>>>>>>a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>self
>>>>>>>>>>>>issued certificate is inserted into the path, you are likely
>>>>>>>>>>>
>>>to
>>>
>>>
>>>>>>>>>>>>find
>>>>>>>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>CRL
>>>>>>>>>>>>issuer cert in the path. (given that the new CA have a
>>>>>>>>>>>
> common
> 
>>>>>key
>>>>>
>>>>>
>>>>>
>>>>>>>>>and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certificate for cert signing and CRL signing).
>>>>>>>>>>>>
>>>>>>>>>>>>Figure 1, 2 and 3 describe the same case. It is just
>>>>>>>>>>>
>>>describing
>>>
>>>
>>>>>>>>>>different
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>path building strategies. An application that has access
>>>>>>>>>>>
>>>locally
>>>
>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>>>>>all
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>chaining options may however still choose path 2 for the
>>>>>>>>>>>
> certs
> 
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>>>path
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>for the CRL independent of each other (which I think figure
>>>>>>>>>>>
> 3
> 
>>>>>tries
>>>>>
>>>>>
>>>>>
>>>>>>>>>to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>describe)
>>>>>>>>>>>>
>>>>>>>>>>>>Another comment is the structure of AIA extensions. The use
>>>>>>>>>>>
>>>I'm
>>>
>>>
>>>>>>>>>familiar
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>with doesn't use AIA to describe a directory entry where it
>>>>>>>>>>>
> is
> 
>>>>>left
>>>>>
>>>>>
>>>>>
>>>>>>>>>to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>validation application logic to be intelligent enough to
>>>>>>>>>>>
> find
> 
>>>>>>>>>>appropriate
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>certificate data from the directory. The model I'm familiar
>>>>>>>>>>>
>>>with
>>>
>>>
>>>>>is
>>>>>
>>>>>
>>>>>
>>>>>>>>>when
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>AIA URL explicitly identifies the exact location of the
>>>>>>>>>>>
>>>>>appropriate
>>>>>
>>>>>
>>>>>
>>>>>>>>>CA
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certificate file, relieving the validation software from
>>>>>>>>>>>
>>>complex
>>>
>>>
>>>>>>>>>>>>information queries. If just location of explicit
>>>>>>>>>>>
> certificate
> 
>>>>>files
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>are
>>>>>>>>>>>
>>>>>>>>>identified
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>through AIA, the presence of an AIA may not help finding the
>>>>>>>>>>>
>>>CRL
>>>
>>>
>>>>>>>>>signer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>cert
>>>>>>>>>>>>if this is different from the CA certificate. This is also
>>>>>>>>>>>
> the
> 
>>>>>>>>>problem
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>with
>>>>>>>>>>>>Denis proposal.
>>>>>>>>>>>>
>>>>>>>>>>>>I think we share the basic conclusion that the ability to
>>>>>>>>>>>
>>>locate
>>>
>>>
>>>>>>>>>>>>the
>>>>>>>>>>>
>>>>>>>>>CRL
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>signer certificate directly through the CRL could be very
>>>>>>>>>>>
>>>>>useful.
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>At
>>>>>>>>>>>
>>>>>>>>>>least
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>in the case of indirect CRL but it could also be proven very
>>>>>>>>>>>
>>>>>useful
>>>>>
>>>>>
>>>>>
>>>>>>>>>in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>CA
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>re-keying scenarios.
>>>>>>>>>>>>
>>>>>>>>>>>>The easiest solution would probably be to allow AIA to be
>>>>>>>>>>>
> used
> 
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>>>>>its
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>>>>>>>>
>>>>>>>>>critical).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>It
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>would present a very clear and uncomplicated logic to
>>>>>>>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>validating applications in many cases.
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan Santesson
>>>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>>>>
>>>>>>>>>>>>________________________________________
>>>>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>>>>>Sent: den 7 oktober 2004 18:35
>>>>>>>>>>>>To: Stefan Santesson
>>>>>>>>>>>>Cc: pkix
>>>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan,
>>>>>>>>>>>>
>>>>>>>>>>>>I think what you are proposing is a good idea.  In most
>>>>>>>>>>>
> cases,
> 
>>>>>path
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>discovery algorithms assume that both the trust anchor (or
>>>>>>>>>>>
>>>trust
>>>
>>>
>>>>>>>>>>anchors)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>and the end entity certificate are provided as input.  In
>>>>>>>>>>>
> this
> 
>>>>>>>>>>>>case,
>>>>>>>>>>>
>>>>>>>>>one
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>may
>>>>>>>>>>>>need to construct a certification path without a priori
>>>>>>>>>>>
> access
> 
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>end
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>entity certificate (the one with the subject public key
>>>>>>>>>>>
>>>>>>>>>corresponding to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>>>>>>>>
>>>>>>>>>pointer) in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>CRL would provide the relying party with a simple way to
>>>>>>>>>>>
>>>obtain
>>>
>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>end
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>entity certificate for the CRL signing key's certification
>>>>>>>>>>>
>>>path.
>>>
>>>
>>>>>On
>>>>>
>>>>>
>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>other hand, I believe that a relying party should be able to
>>>>>>>>>>>
>>>>>>>>>construct
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>certification path even without an AIA extension in the CRL,
>>>>>>>>>>>
>>>so
>>>
>>>
>>>>>>>>>>>>long
>>>>>>>>>>>
>>>>>>>>>as
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>it
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>is not an indirect CRL.  Attached is a drawing of the three
>>>>>>>>>>>
>>>>>basic
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>scenarios that I expect a relying party may encounter:
>>>>>>>>>>>>
>>>>>>>>>>>>In each of these scenarios, the CA has performed key
>>>>>>>>>>>
> rollover
> 
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>is
>>>>>>>>>>>
>>>>>>>>>>only
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>signing CRLs with its new key.  The diagrams would look
>>>>>>>>>>>
>>>similar,
>>>
>>>
>>>>>>>>>>however,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>if
>>>>>>>>>>>>the CA simply choose to use different keys to sign
>>>>>>>>>>>
>>>certificates
>>>
>>>
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>>>CRLs
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>for
>>>>>>>>>>>>some other reason.
>>>>>>>>>>>>
>>>>>>>>>>>>If the PKI architecture resembled figure 1, then the
>>>>>>>>>>>
>>>>>certification
>>>>>
>>>>>
>>>>>
>>>>>>>>>path
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>for
>>>>>>>>>>>>the CRL signing key would just be a subset of the
>>>>>>>>>>>
>>>certification
>>>
>>>
>>>>>>>>>>>>path
>>>>>>>>>>>
>>>>>>>>>for
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>EE certificate, so no addition path discovery would be
>>>>>>>>>>>
> needed.
> 
>>>>>>>>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>>>>>>>>
>>>>>>>>>necessary
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>obtain the new-signed-with-old self-issued certificate.  In
>>>>>>>>>>>>building
>>>>>>>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certification path to the EE certificate, however, the
>>>>>>>>>>>
> relying
> 
>>>>>>>>>>>>party
>>>>>>>>>>>
>>>>>>>>>>will
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>obtain the certificates pointed to by the AIA extension in
>>>>>>>>>>>
> the
> 
>>>>>EE
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>certificate.  This AIA extension will point to a location
>>>>>>>>>>>>containing
>>>>>>>>>>>
>>>>>>>>>all
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certificates issued to CA 2, which would include both the
>>>>>>>>>>>
>>>>>>>>>certificate
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>issued
>>>>>>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So,
>>>>>>>>>>>
>>>>>even
>>>>>
>>>>>
>>>>>
>>>>>>>>>though
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>self-issued certificate would not be part of the
>>>>>>>>>>>
> certification
> 
>>>>>path
>>>>>
>>>>>
>>>>>
>>>>>>>>>to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>EE certificate, it would be downloaded by the relying party
>>>>>>>>>>>
>>>>>during
>>>>>
>>>>>
>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>construction of that certification path.  (Yes, there are
>>>>>>>>>>>
>>>>>circular
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>dependency issues in figure 2, but that is another issue.)
>>>>>>>>>>>>
>>>>>>>>>>>>A similar situation would happen if the PKI architecture
>>>>>>>>>>>
>>>>>resembled
>>>>>
>>>>>
>>>>>
>>>>>>>>>>figure
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>>>>>>>>
>>>>>>>>>location
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>containing certificates issued to CA 3.  When the relying
>>>>>>>>>>>
>>>party
>>>
>>>
>>>>>>>>>>downloaded
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>these certificates, it would obtain both of the certificates
>>>>>>>>>>>
>>>>>issued
>>>>>
>>>>>
>>>>>
>>>>>>>>>by
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>Root to CA 3 and so again would have the certificate needed
>>>>>>>>>>>
> to
> 
>>>>>>>>>validate
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>CRL signing key.
>>>>>>>>>>>>
>>>>>>>>>>>>In the case of an indirect CRL, things may not work as well.
>>>>>>>>>>>
>>>If
>>>
>>>
>>>>>>>>>>indirect
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>CRLs were used, and the PKI architecture resembled figures 2
>>>>>>>>>>>
>>>or
>>>
>>>
>>>>>3
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>(replacing "New Key" with a different CA), then the set of
>>>>>>>>>>>>certificates pointed
>>>>>>>>>>>
>>>>>>>>>to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>by
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the AIA extension in the EE certificate would not include
>>>>>>>>>>>
> the
> 
>>>>>>>>>>certificate
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>of
>>>>>>>>>>>>the CRL signer.  One could find this certificate by building
>>>>>>>>>>>
>>>in
>>>
>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>reverse direction and using the SIA extension, but that may
>>>>>>>>>>>
>>>not
>>>
>>>
>>>>>be
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>the most convenient solution.
>>>>>>>>>>>>
>>>>>>>>>>>>So, when indirect CRLs are being used, it seems that it
>>>>>>>>>>>
> would
> 
>>>be
>>>
>>>
>>>>>>>>>very
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>useful
>>>>>>>>>>>>to have a pointer in the CRL to the CRL signing certificate.
>>>>>>>>>>>
>>>>>When
>>>>>
>>>>>
>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>CRL
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>is not indirect, the need for this pointer does not seem to
>>>>>>>>>>>
> be
> 
>>>>>as
>>>>>
>>>>>
>>>>>
>>>>>>>>>clear,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>but
>>>>>>>>>>>>I can't see any harm in including it.
>>>>>>>>>>>>
>>>>>>>>>>>>Dave
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan Santesson wrote:
>>>>>>>>>>>>All,
>>>>>>>>>>>>
>>>>>>>>>>>>I'm interested in the opinion from members on this list
>>>>>>>>>>>
> about
> 
>>>>>>>>>discovery
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>of
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>CRL signer's certificate in non directory centric
>>>>>>>>>>>
>>>environments.
>>>
>>>
>>>>>>>>>>>>The problem is the following.
>>>>>>>>>>>>
>>>>>>>>>>>>The relying party (RP) needs to check validity of a
>>>>>>>>>>>
>>>certificate
>>>
>>>
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>>>>finds
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>a
>>>>>>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this
>>>>>>>>>>>
> CRL
> 
>>>>>>>>>>>>which
>>>>>>>>>>>
>>>>>>>>>in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>this
>>>>>>>>>>>>particular case is either signed by another key of the CA
>>>>>>>>>>>
>>>>>(re-keyed
>>>>>
>>>>>
>>>>>
>>>>>>>>>CA)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>or
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>another entity (indirect CRL).
>>>>>>>>>>>>
>>>>>>>>>>>>In this case the relying party needs to obtain the
>>>>>>>>>>>
> certificate
> 
>>>>>of
>>>>>
>>>>>
>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>CRL
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>signer which may NOT be part of the original chain. In a
>>>>>>>>>>>
>>>>>directory
>>>>>
>>>>>
>>>>>
>>>>>>>>>>centric
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>solution this is retrieved from the directory, but what if
>>>>>>>>>>>
>>>such
>>>
>>>
>>>>>>>>>>directory
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>is
>>>>>>>>>>>>not available or accessible.
>>>>>>>>>>>>
>>>>>>>>>>>>The RP have thus no hint where to find the CRL issuers
>>>>>>>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>
>>>>>>>>>>unless
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the RP already have possession of it by some other means.
>>>>>>>>>>>>
>>>>>>>>>>>>Is seems that CRLs would need an AIA extension with the
>>>>>>>>>>>
> option
> 
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>>>>>point
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the location of the signers certificate in the same manner
>>>>>>>>>>>
> as
> 
>>>is
>>>
>>>
>>>>>>>>>>possible
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>for certificates.
>>>>>>>>>>>>
>>>>>>>>>>>>Maybe AIA should be defined as both cert and CRL extension
>>>>>>>>>>>
> and
> 
>>>>>not
>>>>>
>>>>>
>>>>>
>>>>>>>>>only
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certificate extension as today.
>>>>>>>>>>>>
>>>>>>>>>>>>Thoughts and comments?
>>>>>>>>>>>>
>>>>>>>>>>>>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 i9IGrrQF059388; Mon, 18 Oct 2004 09:53:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGrrhL059387; Mon, 18 Oct 2004 09:53:53 -0700 (PDT)
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 i9IGrpHR059367 for <[e-mail]>; Mon, 18 Oct 2004 09:53:51 -0700 (PDT) (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.0); Mon, 18 Oct 2004 17:54:08 +0100
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: Signer certificate discovery for CRLs
Date: Mon, 18 Oct 2004 17:53:37 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcS1Lm8/kKWxRhtzTTO3KYOSqg1rJwAAtTGA
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Santosh Chokhani" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 18 Oct 2004 16:54:08.0508 (UTC) FILETIME=[15B0BBC0:01C4B533]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9IGrqHR059382
Sender: [e-mail]
Precedence: 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 save you from excessive discussions on a topic you don't really care
about, I concentrate on the one major problem with SIA that you missed
my point on:

>> 1) How can the RP know what certificate's SIA it would use to find
the 
>> CRL signer cert?

>> You just picked the right certificate in my example since I gave that

>> information in the example. But the RP don't know that path, it only 
>> knows the path of the EE cert and the name of the CRL issuer!

>This is sufficient to find out the right certificate once you know
where >the CA places the certificates that it has issued.

So.. This is NOT the point.

I'll try to explain. Take again an example.

The following is known to the RP:
1) Cert path:  EE_Cert -> CA_1 -> Root_CA_1
2) CRL issued by CRL_Issuer_B

This is NOT known to the RP.
CRL path: CRL -> CRL_Issuer_B -> Intermediary_CA_X - Root_CA_Y

To find the CRL Issuer cert, the RP need to look in the SIA of
Intermediary_CA_X certificate, right?

But how can the RP do that when it doesn't know the CRL path. THE RP HAS
NO KNOWLEDGE ABOUTH THE FACT THAT Intermediary_CA_X IS THE CA ABOVE THE
CRL SIGNER CERT. In fact the RP has no means to find out, except through
exhaustive search from all its trusted roots.

Here, AIA in the CRL solves the issue, SIA doesn't.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Denis Pinkas
> Sent: den 18 oktober 2004 16:58
> To: Santosh Chokhani; Stefan Santesson
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh and Stefan,
> 
> Now we get to the point that there exists one solution, while the
thread
> started saying that there was no other solution.
> 
> We can now start to discuss the advantages and disadvantages of the
two
> solutions.
> 
> However, we have to provide a fair view.
> 
> For the time being, you have only considered the disadvantages of the
> *current* solution, i.e. using SIA. It would be fair that you also
> consider
> its advantages and that we take the time to have a fair comparison.
> 
> > The SIA can be used to find the certificate, but it leads to the
> exponential
> > growth in the search base in the case of indirect CRL.
> 
> This is an argument about disadvantages. However this argument is
> incorrect:
> there is no exponential grow. A CA nominates an authority either as :
> 
>   1 - "CA issuer + CRL issuer"
>   2 - "CA issuer only", or
>   3 - "CRL Issuer only"
> 
> Once the path is constructed, if every CA certificate includes the SIA
> extension, then this is straightforward.
> 
> > Also, I do not think SIA is that well supported.
> 
> I could say that the new proposal is not "that well supported" but
this
> would be an argument leading nowhere. :-|
> 
> The SIA extension is very useful and we should make our best efforts
so
> that
> it will be more and more supported. Providing "yet another way" is not
> going
> to lead in that direction. :-(
> 
> > Thus, we need to consider the commercial realities and permit a
simple
> and
> > elegant approach of using AIA to prime the pump (so to speak) to
start
> the
> > CRL signer path development.
> 
> SIA was not present in RFC 2459. It has been introduced in RFC 3280
and
> this
> is a good point. It should be generalized in order to support
> interoperability. Going down from trust points to leaf certificates
allow
> to
> cover any case.
> 
> The answers to Stefan follow:
> 
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[e-mail]]
> > Sent: Monday, October 18, 2004 8:19 AM
> > To: Denis Pinkas
> > Cc: Santosh Chokhani; pkix
> > Subject: RE: Signer certificate discovery for CRLs
> >
> >
> > Thanks Denis,
> >
> > I now finally understand your SIA alternative.
> >
> > There are some major problems with it though.
> 
> > 1) How can the RP know what certificate's SIA it would use to find
the
> CRL
> > signer cert?
> 
> > You just picked the right certificate in my example since I gave
that
> > information in the example. But the RP don't know that path, it only
> knows
> > the path of the EE cert and the name of the CRL issuer!
> 
> This is sufficient to find out the right certificate once you know
where
> the
> CA places the certificates that it has issued.
> 
> > 2) And even if RP knew the path beforehand, finding THE one CRL
signer
> > certificate from a CRL AIA is much more direct and efficient than
> finding
> > among all issued certificates from a CA the 1 out of x issued
> certificates
> > that is the CRL Issuer cert.
> 
> Usually a CA issues a small number of CA certificates and CRL
> certificates.
> So this is not a problem.
> 
> > 3) Using SIA in the examples requires available directories and
> directory
> > enabled clients. How do you solve the problem if either of these is
not
> > available?
> 
> It could work as well with HTTP using the recent draft that has been
> proposed.
> 
> > Do you seriously suggest that use of SIA is a better and more
effective
> way
> > to address this problem or are you just pointing out the fact that
there
> are
> > SOME cases where use of SIA may work in theory?
> 
> I rather believe that your question was:
> 
> "Do you suggest that use of SIA is a better and more effective way to
> address this problem or are you just pointing out the fact that there
are
> SOME cases where use of SIA may work ?
> 
> SIA is certainly better and shoud be generalized to ease path
contruction,
> not only for CRL issuers but also for CAs.
> 
> SIA may work in ALL cases, unless you provide an example where it
cannot.
> 
> Now I have spent quite a lot of time on that topic (on which I am
> personally
> NOT interested), but since I have been asked by the Security Area
Director
> to provide details I needed to respond.
> 
> I will not be able to sustain the same level of discussions in the
next
> coming days. In particular, I will not be in my office tomorrow. So
you
> have
> plenty of time to consider pros and cons for both approaches and do
not
> take
> silence as approval.
> 
> Denis
> 
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[e-mail]]
> >>Sent: den 18 oktober 2004 12:28
> >>To: Stefan Santesson
> >>Cc: Santosh Chokhani; pkix
> >>Subject: Re: Signer certificate discovery for CRLs
> >>
> >>Stefan,
> >>
> >>
> >>>Denis,
> >>
> >>>If I get you right you mean that one can always successfully use
AIA
> >>
> > and
> >
> >>>SIA in certs to solve discovery of CRL signer cert.
> >>>Others on this list (me included) don't understand how. It would
> >>>therefore be useful if you told us.
> >>>
> >>>I'll try to explain the problem from my perspective one more time.
> >>
> >>Thanks.
> >>
> >>
> >>>Note: "->" in these examples means "issued by"
> >>
> >>Fine.
> >>
> >>
> >>>Case 1 - indirect CRL:
> >>>
> >>>Cert path is:  EE_Cert -> CA_1 -> Root-CA
> >>>CRL path for EE_Cert is:  CRL -> CRL_Issuer_B -> Root-CA
> >>
> >>This means Root-CA has nominated CA_1 and a CRL_Issuer_B and that
CA_1
> >
> > has
> >
> >>chosen to use CRL_Issuer_B for revocation checking for some
> >
> > certificates.
> >
> >>>Scenario:
> >>>Relying party has access to the cert path, discovers the CRL
through
> >>
> > CDP
> >
> >>>in EE_Cert.
> >>
> >>If there is no attack on the objects stored at the CRL DP, the CRL
> >
> > Issuer
> >
> >>from that CRL is CRL_Issuer_B. Now the relying party needs to get
the
> >>certificate isued by Root-CA for CRL_Issuer_B. If Root-CA has
included
> >
> > a
> >
> >>SIA
> >>extension in his self-signed certificate, then using that extension
> >
> > allows
> >
> >>to get the CRL_Issuer_B certificate issued by the Root-CA.
> >>
> >> > The RP searches the location specified in SIA through
> >>
> >>>id-ad-caRepository in the CA_1 cert but finds nothing useful since
> >>>revocation is subordinated to another entity (CRL_Issuer_B)
> >>
> >>Correct, but looking in Root-CA allows to find something useful, if
> >
> > the
> >
> >>self-signed certificate includes a SIA extension.
> >>
> >>
> >>>In this case, the problem could be solved if an AIA in the CRL
> >>
> > indicated
> >
> >>>the access location of the CRL Issuer cert.
> >>
> >>This would be an *alternative* way.
> >>
> >>
> >>>Case 2 - re-keyed CA.
> >>>
> >>>Cert path is:  EE_Cert -> CA_1(old key) -> Root-CA
> >>>CRL path for EE_Cert is:  CRL -> CA_1(new key) -> Root-CA
> >>
> >>This means that the EE_Cert chain has been created with CA_1(old
key)
> >
> > and
> >
> >>that the CRL issuer that was originaly used when the EE_Cert was
> >
> > created
> >
> >>has
> >>been changed and a new CRL Issuer got a certificate under CA_1(new
> >
> > key)
> >
> >>and
> >>is now the legitimate CRL issuer for the CRL DP originally
mentionned
> >
> > in
> >
> >>the
> >>EE_Cert.
> >>
> >>
> >>>The 2 CA_1 certificates above (old key and new key) are issued to
> >>>different subject keys belonging to the same CA (same name). The
> >>>cert CA_1(old key) was issued before creation of cert CA_1(new
> >>
> > key)
> >
> >>>and have thus no reference to CA_1(new key) in its SIA
> >>>
> >>>Scenario:
> >>>RP discovers the CRL for the EE_Cert through the CDP but doesn't
> >>
> > possess
> >
> >>>the CRL issuer cert. The RP client searches the SIA of the CA_1(old
> >>
> > key)
> >
> >>>but finds no direct reference to the CRL signer cert. Since the RP
> >>>client has no access to a directory where the CRL signer cert could
> >>
> > be
> >
> >>>found through directory lookup, cert validation fails.
> >>
> >>Correct, but looking in Root-CA allows to find something useful, if
> >
> > the
> >
> >>self-signed certificate includes a SIA extension.
> >>
> >>
> >>>In this scenario the problem could be solved through an AIA in the
> >>
> > CRL.
> >
> >>This would be an *alternative* way.
> >>
> >>Denis
> >>
> >>
> >>>
> >>>
> >>>Stefan Santesson
> >>>Microsoft Security Center of Excellence (SCOE)
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Denis Pinkas [mailto:[e-mail]]
> >>>>Sent: den 15 oktober 2004 17:30
> >>>>To: Stefan Santesson
> >>>>Cc: Santosh Chokhani; pkix
> >>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>
> >>>>Stefan,
> >>>>
> >>>>
> >>>>
> >>>>>Denis,
> >>>>
> >>>>>Unfortunately I fail to understand your questions, issues and
> >>>>
> >>>requests.
> >>>
> >>>
> >>>>The sentence below demonstrates that you understand the issue.
> >>>>
> >>>>
> >>>>
> >>>>>It would be very useful if you could explain how current
mechanisms
> >>>>
> >>>can
> >>>
> >>>
> >>>>>be used in a simple and straightforward manner to discover CRL
> >>>>
> >>>signer
> >>>
> >>>
> >>>>>certificates in ALL the use cases discussed, mainly re-keyed CA
and
> >>>>>indirect CRLs.
> >>>>
> >>>>You are also reversing the question. Using your terms, my question
> >>>
> >>>would
> >>>
> >>>
> >>>>be:
> >>>>
> >>>>"It would be very useful if you could explain how current
mechanisms
> >>>>CANNOT be used in a simple and straightforward manner to discover
> >>>>CRL
> >>>
> > signer
> >
> >>>>certificates in ONE or MORE the use cases discussed, mainly
re-keyed
> >>>
> >>>CA
> >>>
> >>>
> >>>>and
> >>>>indirect CRLs."
> >>>>
> >>>>Denis
> >>>>
> >>>>
> >>>>
> >>>>>Stefan Santesson
> >>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: [e-mail]
> >>>>>
> >>>>>[mailto:[e-mail]]
> >>>>>
> >>>>>
> >>>>>
> >>>>>>On Behalf Of Denis Pinkas
> >>>>>>Sent: den 14 oktober 2004 17:13
> >>>>>>To: Santosh Chokhani
> >>>>>>Cc: 'pkix'
> >>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>
> >>>>>>
> >>>>>>Santosh,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Denis:
> >>>>>>
> >>>>>>>With the three assumptions/constraints I provided, how would
you
> >>>>>>
> >>>>>locate
> >>>>>
> >>>>>
> >>>>>
> >>>>>>the
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>CRL issuer certificate for the two examples using 3280
extensions
> >>>>>>
> >>>>>and
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>without putting AIA in the CRL?
> >>>>>>
> >>>>>>As far as I understand, the three assumptions are:
> >>>>>>
> >>>>>>1.  You are directory challenged; and
> >>>>>>   [I do not understand what this means]
> >>>>>>2.  You use AIA to develop the path; and
> >>>>>>   [It does not matter]
> >>>>>>3.  You develop the path from the end entity to trust anchor
> >>>>>>   [Could also be the contrary].
> >>>>>>
> >>>>>>If this is not correct, thus please correct.
> >>>>>>
> >>>>>>Then my request is: "using ANY OF the current extensions that
are
> >>>>>
> >>>>>defined
> >>>>>
> >>>>>
> >>>>>
> >>>>>>in
> >>>>>>RFC 3280", which includes SIA.
> >>>>>>
> >>>>>>In your explanations  you said :
> >>>>>>"if you do no deal with SIA et. al"
> >>>>>>
> >>>>>>This last assumption is neither part of the three assumptions
and
> >>>>>
> >>>does
> >>>
> >>>
> >>>>>not
> >>>>>
> >>>>>
> >>>>>
> >>>>>>conform to my request.
> >>>>>>
> >>>>>>Denis
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>That is my point.
> >>>>>>>
> >>>>>>>-----Original Message-----
> >>>>>>>From: Denis Pinkas [mailto:[e-mail]]
> >>>>>>>Sent: Thursday, October 14, 2004 6:22 AM
> >>>>>>>To: Santosh Chokhani
> >>>>>>>Cc: 'pkix'
> >>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>
> >>>>>>>
> >>>>>>>Santosh,
> >>>>>>>
> >>>>>>>You misread my request. I said:
> >>>>>>>
> >>>>>>>"For the time being, I would like that you provide an example
> >>>>>>
> >>>where,
> >>>
> >>>
> >>>>>>when
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>using the current extensions that are defined in RFC 3280, it
> >>>>>>
> > will
> >
> >>>>>NOT
> >>>>>
> >>>>>
> >>>>>
> >>>>>>be
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>possible to locate a CRL Issuer certificate."
> >>>>>>>
> >>>>>>>Maybe I would have needed to be clearer and say :
> >>>>>>>
> >>>>>>>"For the time being, I would like that you provide an example
> >>>>>>
> >>>where,
> >>>
> >>>
> >>>>>>when
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>using ANY OF the current extensions that are defined in RFC
3280,
> >>>>>>
> >>>it
> >>>
> >>>
> >>>>>>will
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>NOT be possible to locate a CRL Issuer certificate."
> >>>>>>>
> >>>>>>>The examples you provide below do not fulfil this request.
> >>>>>>>
> >>>>>>>The assumption is that there exists a path to be tested for
> >>>>>>
> >>>>>revocation
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>checking (and that it does not matter to know which way it has
> >>>>>>
> > been
> >
> >>>>>>>constructed).
> >>>>>>>
> >>>>>>>I am not saying that using AIA in CRL might not be useful, but
I
> >>>>>>
> > am
> >
> >>>>>>still
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>lacking the demonstration that there would be no other way.
> >>>>>>>
> >>>>>>>Denis
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Denis:
> >>>>>>>>
> >>>>>>>>Two examples are very simple: one for direct CRL Issuer and
one
> >>>>>>>
> >>>for
> >>>
> >>>
> >>>>>>>>Indirect CRL Issuer.
> >>>>>>>>
> >>>>>>>>Let us make the following assumptions that Stefan was making:
> >>>>>>>>
> >>>>>>>>1.  You are directory challenged; and
> >>>>>>>>2.  You use AIA to develop the path; and
> >>>>>>>>3.  You develop the path from the end entity to trust anchor.
> >>>>>>>>
> >>>>>>>
> >>>>>>>>From what I know of MS CAPI, these are reasonable
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>assumptions/constraints.
> >>>>>>>>
> >>>>>>>>Now the examples.
> >>>>>>>>
> >>>>>>>>Example 1: Direct CRL Issuer
> >>>>>>>>
> >>>>>>>>The certificate trust path is:
> >>>>>>>>Root --> CA1 --> CA 2, old key --> Denis
> >>>>>>>>
> >>>>>>>>The CRL trust path is:
> >>>>>>>>Root --> CA1 --> CA 2, new key --> CRL
> >>>>>>>>
> >>>>>>>>(Note: We do not do self-issued certificate since there is no
> >>>>>>>
> >>>>>simple,
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>secure way to check their revocation status).
> >>>>>>>>
> >>>>>>>>Now, with AIA in CRL, finding the CA2, new key certificate is
> >>>>>>>>straightforward.  How would you find it if you do no deal with
> >>>>>>>
> > SIA
> >
> >>>>>et.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>al.
> >>>>>>>>
> >>>>>>>>Example 2: Indirect CRL Issuer
> >>>>>>>>
> >>>>>>>>The certificate trust path is:
> >>>>>>>>Root --> CA1 --> CA 2 --> Denis
> >>>>>>>>(Note: Denis's certificate points to CRL DP of an indirect CRL
> >>>>>>>
> >>>>>issued
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>by CAI.
> >>>>>>>>
> >>>>>>>>The CRL trust path is:
> >>>>>>>>Root --> CAI --> CRL
> >>>>>>>>
> >>>>>>>>Now, with AIA in CRL, finding the CAI certificate is
> >>>>>>>
> >>>>>straightforward.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>How would you find it if you do no deal with SIA et. al.
> >>>>>>>>
> >>>>>>>>In addition to the need cited above, please note that the
> >>>>>>>
> >>>extension
> >>>
> >>>
> >>>>>>>>semantics does not change, it does not hinder any
> >>>>>>>
> >>>interoperability,
> >>>
> >>>
> >>>>>>>>and it does not break any backward compatibility.  So, what if
I
> >>>>>>>>wanted to use this extension in the CRL.  It does no harm to
> >>>>>>>
> > other
> >
> >>>>>>>>relying parties.
> >>>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: [e-mail]
> >>>>>>>>[mailto:[e-mail]] On Behalf Of Denis
Pinkas
> >>>>>>>>Sent: Wednesday, October 13, 2004 11:01 AM
> >>>>>>>>To: Stefan Santesson
> >>>>>>>>Cc: Santosh Chokhani; pkix
> >>>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>Stefan,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>Denis,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>I'm not sure what you mean.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>For the time being, I would like that you provide an example
> >>>>>>>
> >>>where,
> >>>
> >>>
> >>>>>>>>when
> >>>>>>>>using the current extensions that are defined in RFC 3280, it
> >>>>>>>
> > will
> >
> >>>>>NOT
> >>>>>
> >>>>>
> >>>>>
> >>>>>>be
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>possible to locate a CRL Issuer certificate.
> >>>>>>>>
> >>>>>>>>If you are able to provide that example, then it would justify
> >>>>>>>
> > the
> >
> >>>>>>>>need for
> >>>>>>>>an extension at least for one case. Then we can see what that
> >>>>>>>
> > case
> >
> >>>>>is.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>I am awaiting that example.
> >>>>>>>>
> >>>>>>>>Denis
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>I conclude that I agree with Santosh.
> >>>>>>>>>
> >>>>>>>>>The debate is still open... Feel free to express your
opinion.
> >>>>>>>>>
> >>>>>>>>>Stefan Santesson
> >>>>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>-----Original Message-----
> >>>>>>>>>>From: Denis Pinkas [mailto:[e-mail]]
> >>>>>>>>>>Sent: den 13 oktober 2004 16:34
> >>>>>>>>>>To: Stefan Santesson
> >>>>>>>>>>Cc: Santosh Chokhani; pkix
> >>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>>>>
> >>>>>>>>>>Stefan,
> >>>>>>>>>>
> >>>>>>>>>>You are making a conclusion without letting me the time to
> >>>>>>>>>
> >>>>>respond. I
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>will need more time to look at the pictures (and understand
> >>>>>>>>>
> >>>them).
> >>>
> >>>
> >>>>>>>>>>For the time being, I am still reluctant to accept
> >>>>>>>>>
> >>>>>>>>>"yet-another-method".
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>We already have too many.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>Santosh,
> >>>>>>>>>>>
> >>>>>>>>>>>I conclude that we are in complete and total agreement. The
> >>>>>>>>>>>question is how to go about this.
> >>>>>>>>>>
> >>>>>>>>>>>Could we do this amendment to RFC 3280 in its next
revision?
> >>>>>>>>>>
> > It
> >
> >>>>>>>>>>>would hopefully just be a minor change.
> >>>>>>>>>>
> >>>>>>>>>>This is exactly what I feared.
> >>>>>>>>>>
> >>>>>>>>>>We usually end-up with a "minor change" in an extension
> >>>>>>>>>
> > without
> >
> >>>>>>>>>>saying cleary how and when it shall/should be used.
> >>>>>>>>>>
> >>>>>>>>>>I still have in mind that:
> >>>>>>>>>>
> >>>>>>>>>>1) a certification path must first be constructed,
> >>>>>>>>>>2) then the revocation checking of that path must be done.
> >>>>>>>>>>
> >>>>>>>>>>This means that information about CRL issuers certificates
> >>>>>>>>>
> >>>>>locations
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>may
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>certainly be found in that chain. If not, I would like an
> >>>>>>>>>
> >>>example.
> >>>
> >>>
> >>>>>>>>>>Denis
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>It would not change the definition of AIA just add that it
> >>>>>>>>>>
> > can
> >
> >>>be
> >>>
> >>>
> >>>>>>>>>used
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>also as CRL extension and list eventual restrictions and
> >>>>>>>>>
> >>>guidance
> >>>
> >>>
> >>>>>for
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>use
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>with CRLs.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>Stefan Santesson
> >>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>-----Original Message-----
> >>>>>>>>>>>>From: [e-mail]
> >>>>>>>>>>>
> >>>>>>>>>[mailto:[e-mail]]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>On Behalf Of Santosh Chokhani
> >>>>>>>>>>>>Sent: den 13 oktober 2004 04:33
> >>>>>>>>>>>>To: 'pkix'
> >>>>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>Stefan:
> >>>>>>>>>>>>
> >>>>>>>>>>>>In terms of certificate discovery, your proposal for AIA
in
> >>>>>>>>>>>
> >>>CRL
> >>>
> >>>
> >>>>>is
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>more
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>robust.  The whole idea of self-issued key rollover
> >>>>>>>>>>>
> >>>certificates
> >>>
> >>>
> >>>>>>>>>>>>and
> >>>>>>>>>>>
> >>>>>>>>>>then
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>using the new key to issue CRL is fraught with security
> >>>>>>>>>>>
> >>>>>problems.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>A secure solution would be one where the new key is
> >>>>>>>>>>>
> > certified
> >
> >>>by
> >>>
> >>>
> >>>>>>>>>>>>the parent
> >>>>>>>>>>>
> >>>>>>>>>CA.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>In
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>that case to obtain the new certificate, you could use AIA
> >>>>>>>>>>>
> > in
> >
> >>>>>CRL.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL
DP
> >>>>>>>>>>>
> >>>in
> >>>
> >>>
> >>>>>>>>>>>>certificate in question points to the indirect CRL.  You
get
> >>>>>>>>>>>
> >>>>>that
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>CRL.  The AIA
> >>>>>>>>>>>
> >>>>>>>>>in
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>CRL
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>gets you started for the indirect CRL issuer certification
> >>>>>>>>>>>
> >>>path
> >>>
> >>>
> >>>>>and
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>you
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>are
> >>>>>>>>>>>>in business.
> >>>>>>>>>>>>
> >>>>>>>>>>>>-----Original Message-----
> >>>>>>>>>>>>From: [e-mail]
> >>>>>>>>>>>
> >>>>>>>>>[mailto:[e-mail]]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>On
> >>>>>>>>>>>>Behalf Of Stefan Santesson
> >>>>>>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
> >>>>>>>>>>>>To: David A. Cooper
> >>>>>>>>>>>>Cc: pkix
> >>>>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>David,
> >>>>>>>>>>>>
> >>>>>>>>>>>>Thanks for the clarifications, they make sense.
> >>>>>>>>>>>>I did misread your pictures.
> >>>>>>>>>>>>
> >>>>>>>>>>>>So can we conclude that for a re-keyed CA in accordance
with
> >>>>>>>>>>>
> >>>RFC
> >>>
> >>>
> >>>>>>>>>3280,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>either the CRL issuer certificate itself, or the location
of
> >>>>>>>>>>>
> >>>the
> >>>
> >>>
> >>>>>>>>>>>>CRL issuer certificate, will be clearly
identified/available
> >>>>>>>>>>>
> >>>for
> >>>
> >>>
> >>>>>>>>>>>>the validating
> >>>>>>>>>>>
> >>>>>>>>>>party
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>in some cases, but not in others?
> >>>>>>>>>>>>
> >>>>>>>>>>>>Can we also conclude that there is no real discovery
> >>>>>>>>>>>
> > solution
> >
> >>>>>for
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>indirect
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>CRLs?
> >>>>>>>>>>>>
> >>>>>>>>>>>>Do you then agree then that it could be appropriate to
allow
> >>>>>>>>>>>
> >>>AIA
> >>>
> >>>
> >>>>>as
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>a
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>CRL
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>extension to facilitate discovery of CRL signer
certificate?
> >>>>>>>>>>>>
> >>>>>>>>>>>>Stefan Santesson
> >>>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>>>>>>
> >>>>>>>>>>>>________________________________________
> >>>>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
> >>>>>>>>>>>>Sent: den 12 oktober 2004 21:14
> >>>>>>>>>>>>To: Stefan Santesson
> >>>>>>>>>>>>Cc: pkix
> >>>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>>>>>>
> >>>>>>>>>>>>Stefan,
> >>>>>>>>>>>>
> >>>>>>>>>>>>I believe that you are misinterpreting the figures.  They
> >>>>>>>>>>>
> >>>really
> >>>
> >>>
> >>>>>do
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>represent three different cases, not three different
> >>>>>>>>>>>
> >>>>>certification
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>paths
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>that have been constructed through the same PKI
> >>>>>>>>>>>
> > architecture.
> >
> >>>>>>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
> >>>>>>>>>>>
> >>>>>>>>>certificates.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>The
> >>>>>>>>>>>>Root CA has issued a certificate to CA 1's new key, but
not
> >>>>>>>>>>>
> >>>its
> >>>
> >>>
> >>>>>old
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>key
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>(either the Root CA never issued a certificate to CA 1's
old
> >>>>>>>>>>>
> >>>key
> >>>
> >>>
> >>>>>or
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>that
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>certificate has expired).
> >>>>>>>>>>>>
> >>>>>>>>>>>>In figure 2, CA 2 has also generated self-issued key
> >>>>>>>>>>>
> > rollover
> >
> >>>>>>>>>>>>certificates. The Root CA has issued a certificate to CA
2's
> >>>>>>>>>>>
> >>>old
> >>>
> >>>
> >>>>>>>>>>>>key, but not its
> >>>>>>>>>>>
> >>>>>>>>>new
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>key.
> >>>>>>>>>>>>
> >>>>>>>>>>>>In figure 3, when CA 3 performed key rollover, it
requested
> >>>>>>>>>>>
> > a
> >
> >>>>>new
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>CA certificate from the Root CA.  CA 3 did not generated
> >>>>>>>>>>>>self-issued
> >>>>>>>>>>>
> >>>>>>>>>key
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>rollover certificates.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Of course, another realistic scenario would be one in
which
> >>>>>>>>>>>
> > a
> >
> >>>CA
> >>>
> >>>
> >>>>>>>>>>generated
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>self-issued key rollover certificates upon key rollover
and
> >>>>>>>>>>>
> >>>then
> >>>
> >>>
> >>>>>>>>>>>>had
> >>>>>>>>>>>
> >>>>>>>>>the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>Root CA issue a CA certificate to its new key.  In this
> >>>>>>>>>>>
> > case,
> >
> >>>as
> >>>
> >>>
> >>>>>>>>>>>>you suggest, any of the certification paths from figures
1,
> >>>>>>>>>>>
> > 2,
> >
> >>>>>or 3
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>could be
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>constructed.
> >>>>>>>>>>>>
> >>>>>>>>>>>>As for the contents of the AIA extension, here is what I
> >>>>>>>>>>>
> > have
> >
> >>>>>>>>>specified
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>in
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the
> >>>>>>>>>>>
> >>>Common
> >>>
> >>>
> >>>>>>>>>>Policy":
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>The authorityInfoAccess extension uses URIs for two
> >>>>>>>>>>>
> > purposes.
> >
> >>>>>When
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>id-ad-caIssuers access method is used, the access location
> >>>>>>>>>>>>specifies
> >>>>>>>>>>>
> >>>>>>>>>>where
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>certificates issued to the issuer of the certificate may
be
> >>>>>>>>>>>
> >>>>>found.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>If
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>LDAP
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>is used, the URI must include the DN of the entry
containing
> >>>>>>>>>>>
> >>>the
> >>>
> >>>
> >>>>>>>>>>relevant
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>certificates and specify the directory attribute in which
> >>>>>>>>>>>
> > the
> >
> >>>>>>>>>>certificates
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>are located. If the directory in which the certificates
are
> >>>>>>>>>>>
> >>>>>stored
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>expects
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>the "binary" option to be specified, then the attribute
type
> >>>>>>>>>>>
> >>>>>must
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the
> >>>>>>>>>>>
> > URI
> >
> >>>>>must
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>point to
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>a
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>file that has an extension of ".p7c" that contains a
> >>>>>>>>>>>
> >>>certs-only
> >>>
> >>>
> >>>>>CMS
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>message (see RFC 2633). The CMS message should include all
> >>>>>>>>>>>>certificates
> >>>>>>>>>>>
> >>>>>>>>>issued
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>to
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>the issuer of this certificate, but must at least contain
> >>>>>>>>>>>
> > all
> >
> >>>>>>>>>>certificates
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>issued to the issuer of this certificate in which the
> >>>>>>>>>>>
> > subject
> >
> >>>>>>>>>>>>public
> >>>>>>>>>>>
> >>>>>>>>>key
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>may
> >>>>>>>>>>>>be used to verify the signature on this certificate. ....
> >>>>>>>>>>>
> > For
> >
> >>>a
> >>>
> >>>
> >>>>>>>>>>>>certificate issued by "Good CA", some examples of URIs
that
> >>>>>>>>>>>
> >>>may
> >>>
> >>>
> >>>>>>>>>>>>appear as the
> >>>>>>>>>>>
> >>>>>>>>>access
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>location in an authorityInfoAccess extension when the
> >>>>>>>>>>>
> >>>>>>>>>id-ad-caIssuers
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>access
> >>>>>>>>>>>>method is used are:
> >>>>>>>>>>>
>
>>>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?c
A
> >>>>>>>
> > C
> >
> >>>e
> >>>
> >>>
> >>>>>r
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>t
> >>>>>>>>>>>i
> >>>>>>>>>>
> >>>>>>>>>fi
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>ca
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>te
> >>>>>>>>>>>>,crossCertificatePair
> >>>>>>>>>>>
>
>>>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACer
t
> >>>>>>>
> > i
> >
> >>>f
> >>>
> >>>
> >>>>>i
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>c
> >>>>>>>>>>>a
> >>>>>>>>>>
> >>>>>>>>>te
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>;b
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>in
> >>>>>>>>>>>>ary,crossCertificatePair;binary
> >>>>>>>>>>>
>
>>>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certs
I
> >>>>>>>
> > s
> >
> >>>s
> >>>
> >>>
> >>>>>u
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>e
> >>>>>>>>>>>d
> >>>>>>>>>>
> >>>>>>>>>To
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>Go
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>od
> >>>>>>>>>>>>CA.p7c
> >>>>>>>>>>>>For both LDAP and HTTP, the URI provides the exact
location
> >>>>>>>>>>>
> >>>>>where
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>information is to be located, so there is no requirement
for
> >>>>>>>>>>>
> >>>the
> >>>
> >>>
> >>>>>>>>>relying
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>party to try to figure out where information is located.
> >>>>>>>>>>>>
> >>>>>>>>>>>>The HTTP URI points to a certs-only CMS message that
> >>>>>>>>>>>
> > includes
> >
> >>>>>all
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>certificates issued to the CA identified in the issuer
field
> >>>>>>>>>>>
> >>>of
> >>>
> >>>
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>certificate.
> >>>>>>>>>>>>
> >>>>>>>>>>>>The LDAP URI points to the cACertificate and
> >>>>>>>>>>>
> >>>>>crossCertificatePair
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>attributes of the directory entry of the CA identified in
> >>>>>>>>>>>
> > the
> >
> >>>>>>>>>>>>issuer field of
> >>>>>>>>>>>
> >>>>>>>>>the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>certificate.  These two attributes together hold all of
the
> >>>>>>>>>>>
> >>>>>>>>>certificates
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>issued to the CA:  the cACertificate attribute holds the
> >>>>>>>>>>>
> > CA's
> >
> >>>>>self-
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>issued
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>certificates and the crossCertificatePair attribute holds
> >>>>>>>>>>>
> > the
> >
> >>>>>>>>>>>>cross-certificates issued to the CA by other CAs.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Dave
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>Stefan Santesson wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>David,
> >>>>>>>>>>>>
> >>>>>>>>>>>>Thanks for these good thoughts and very useful scenarios.
> >>>>>>>>>>>>
> >>>>>>>>>>>>I have some comments and questions on this.
> >>>>>>>>>>>>
> >>>>>>>>>>>>First of all we can conclude that in some scenarios
(figure
> >>>>>>>>>>>
> > 1)
> >
> >>>>>>>>>>>>where
> >>>>>>>>>>>
> >>>>>>>>>a
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>self
> >>>>>>>>>>>>issued certificate is inserted into the path, you are
likely
> >>>>>>>>>>>
> >>>to
> >>>
> >>>
> >>>>>>>>>>>>find
> >>>>>>>>>>>
> >>>>>>>>>the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>CRL
> >>>>>>>>>>>>issuer cert in the path. (given that the new CA have a
> >>>>>>>>>>>
> > common
> >
> >>>>>key
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>and
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>certificate for cert signing and CRL signing).
> >>>>>>>>>>>>
> >>>>>>>>>>>>Figure 1, 2 and 3 describe the same case. It is just
> >>>>>>>>>>>
> >>>describing
> >>>
> >>>
> >>>>>>>>>>different
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>path building strategies. An application that has access
> >>>>>>>>>>>
> >>>locally
> >>>
> >>>
> >>>>>to
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>all
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>chaining options may however still choose path 2 for the
> >>>>>>>>>>>
> > certs
> >
> >>>>>and
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>path
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>1
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>for the CRL independent of each other (which I think
figure
> >>>>>>>>>>>
> > 3
> >
> >>>>>tries
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>to
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>describe)
> >>>>>>>>>>>>
> >>>>>>>>>>>>Another comment is the structure of AIA extensions. The
use
> >>>>>>>>>>>
> >>>I'm
> >>>
> >>>
> >>>>>>>>>familiar
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>with doesn't use AIA to describe a directory entry where
it
> >>>>>>>>>>>
> > is
> >
> >>>>>left
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>to
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>validation application logic to be intelligent enough to
> >>>>>>>>>>>
> > find
> >
> >>>>>>>>>>appropriate
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>certificate data from the directory. The model I'm
familiar
> >>>>>>>>>>>
> >>>with
> >>>
> >>>
> >>>>>is
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>when
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>the
> >>>>>>>>>>>>AIA URL explicitly identifies the exact location of the
> >>>>>>>>>>>
> >>>>>appropriate
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>CA
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>certificate file, relieving the validation software from
> >>>>>>>>>>>
> >>>complex
> >>>
> >>>
> >>>>>>>>>>>>information queries. If just location of explicit
> >>>>>>>>>>>
> > certificate
> >
> >>>>>files
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>are
> >>>>>>>>>>>
> >>>>>>>>>identified
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>through AIA, the presence of an AIA may not help finding
the
> >>>>>>>>>>>
> >>>CRL
> >>>
> >>>
> >>>>>>>>>signer
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>cert
> >>>>>>>>>>>>if this is different from the CA certificate. This is also
> >>>>>>>>>>>
> > the
> >
> >>>>>>>>>problem
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>with
> >>>>>>>>>>>>Denis proposal.
> >>>>>>>>>>>>
> >>>>>>>>>>>>I think we share the basic conclusion that the ability to
> >>>>>>>>>>>
> >>>locate
> >>>
> >>>
> >>>>>>>>>>>>the
> >>>>>>>>>>>
> >>>>>>>>>CRL
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>signer certificate directly through the CRL could be very
> >>>>>>>>>>>
> >>>>>useful.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>At
> >>>>>>>>>>>
> >>>>>>>>>>least
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>in the case of indirect CRL but it could also be proven
very
> >>>>>>>>>>>
> >>>>>useful
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>in
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>CA
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>re-keying scenarios.
> >>>>>>>>>>>>
> >>>>>>>>>>>>The easiest solution would probably be to allow AIA to be
> >>>>>>>>>>>
> > used
> >
> >>>>>in
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>its
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>current shape and structure as a CRL extension (MUST NOT
be
> >>>>>>>>>>>
> >>>>>>>>>critical).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>It
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>would present a very clear and uncomplicated logic to
> >>>>>>>>>>>
> >>>>>certificate
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>validating applications in many cases.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Stefan Santesson
> >>>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>>>>>>
> >>>>>>>>>>>>________________________________________
> >>>>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
> >>>>>>>>>>>>Sent: den 7 oktober 2004 18:35
> >>>>>>>>>>>>To: Stefan Santesson
> >>>>>>>>>>>>Cc: pkix
> >>>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>>>>>>
> >>>>>>>>>>>>Stefan,
> >>>>>>>>>>>>
> >>>>>>>>>>>>I think what you are proposing is a good idea.  In most
> >>>>>>>>>>>
> > cases,
> >
> >>>>>path
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>discovery algorithms assume that both the trust anchor (or
> >>>>>>>>>>>
> >>>trust
> >>>
> >>>
> >>>>>>>>>>anchors)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>and the end entity certificate are provided as input.  In
> >>>>>>>>>>>
> > this
> >
> >>>>>>>>>>>>case,
> >>>>>>>>>>>
> >>>>>>>>>one
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>may
> >>>>>>>>>>>>need to construct a certification path without a priori
> >>>>>>>>>>>
> > access
> >
> >>>>>to
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>end
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>entity certificate (the one with the subject public key
> >>>>>>>>>>>
> >>>>>>>>>corresponding to
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>the
> >>>>>>>>>>>>CRL signing key).  Including an AIA extension (or some
other
> >>>>>>>>>>>
> >>>>>>>>>pointer) in
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>the
> >>>>>>>>>>>>CRL would provide the relying party with a simple way to
> >>>>>>>>>>>
> >>>obtain
> >>>
> >>>
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>end
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>entity certificate for the CRL signing key's certification
> >>>>>>>>>>>
> >>>path.
> >>>
> >>>
> >>>>>On
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>other hand, I believe that a relying party should be able
to
> >>>>>>>>>>>
> >>>>>>>>>construct
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>certification path even without an AIA extension in the
CRL,
> >>>>>>>>>>>
> >>>so
> >>>
> >>>
> >>>>>>>>>>>>long
> >>>>>>>>>>>
> >>>>>>>>>as
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>it
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>is not an indirect CRL.  Attached is a drawing of the
three
> >>>>>>>>>>>
> >>>>>basic
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>scenarios that I expect a relying party may encounter:
> >>>>>>>>>>>>
> >>>>>>>>>>>>In each of these scenarios, the CA has performed key
> >>>>>>>>>>>
> > rollover
> >
> >>>>>and
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>is
> >>>>>>>>>>>
> >>>>>>>>>>only
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>signing CRLs with its new key.  The diagrams would look
> >>>>>>>>>>>
> >>>similar,
> >>>
> >>>
> >>>>>>>>>>however,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>if
> >>>>>>>>>>>>the CA simply choose to use different keys to sign
> >>>>>>>>>>>
> >>>certificates
> >>>
> >>>
> >>>>>and
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>CRLs
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>for
> >>>>>>>>>>>>some other reason.
> >>>>>>>>>>>>
> >>>>>>>>>>>>If the PKI architecture resembled figure 1, then the
> >>>>>>>>>>>
> >>>>>certification
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>path
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>for
> >>>>>>>>>>>>the CRL signing key would just be a subset of the
> >>>>>>>>>>>
> >>>certification
> >>>
> >>>
> >>>>>>>>>>>>path
> >>>>>>>>>>>
> >>>>>>>>>for
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>the
> >>>>>>>>>>>>EE certificate, so no addition path discovery would be
> >>>>>>>>>>>
> > needed.
> >
> >>>>>>>>>>>>If the PKI architecture resembled figure 1, then it would
be
> >>>>>>>>>>>
> >>>>>>>>>necessary
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>to
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>obtain the new-signed-with-old self-issued certificate.
In
> >>>>>>>>>>>>building
> >>>>>>>>>>>
> >>>>>>>>>the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>certification path to the EE certificate, however, the
> >>>>>>>>>>>
> > relying
> >
> >>>>>>>>>>>>party
> >>>>>>>>>>>
> >>>>>>>>>>will
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>obtain the certificates pointed to by the AIA extension in
> >>>>>>>>>>>
> > the
> >
> >>>>>EE
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>certificate.  This AIA extension will point to a location
> >>>>>>>>>>>>containing
> >>>>>>>>>>>
> >>>>>>>>>all
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>certificates issued to CA 2, which would include both the
> >>>>>>>>>>>
> >>>>>>>>>certificate
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>issued
> >>>>>>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.
So,
> >>>>>>>>>>>
> >>>>>even
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>though
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>the
> >>>>>>>>>>>>self-issued certificate would not be part of the
> >>>>>>>>>>>
> > certification
> >
> >>>>>path
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>to
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>EE certificate, it would be downloaded by the relying
party
> >>>>>>>>>>>
> >>>>>during
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>construction of that certification path.  (Yes, there are
> >>>>>>>>>>>
> >>>>>circular
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>dependency issues in figure 2, but that is another issue.)
> >>>>>>>>>>>>
> >>>>>>>>>>>>A similar situation would happen if the PKI architecture
> >>>>>>>>>>>
> >>>>>resembled
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>figure
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>3.  The AIA extension in the EE certificate would point to
a
> >>>>>>>>>>>
> >>>>>>>>>location
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>containing certificates issued to CA 3.  When the relying
> >>>>>>>>>>>
> >>>party
> >>>
> >>>
> >>>>>>>>>>downloaded
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>these certificates, it would obtain both of the
certificates
> >>>>>>>>>>>
> >>>>>issued
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>by
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>Root to CA 3 and so again would have the certificate
needed
> >>>>>>>>>>>
> > to
> >
> >>>>>>>>>validate
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>the
> >>>>>>>>>>>>CRL signing key.
> >>>>>>>>>>>>
> >>>>>>>>>>>>In the case of an indirect CRL, things may not work as
well.
> >>>>>>>>>>>
> >>>If
> >>>
> >>>
> >>>>>>>>>>indirect
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>CRLs were used, and the PKI architecture resembled figures
2
> >>>>>>>>>>>
> >>>or
> >>>
> >>>
> >>>>>3
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>(replacing "New Key" with a different CA), then the set of
> >>>>>>>>>>>>certificates pointed
> >>>>>>>>>>>
> >>>>>>>>>to
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>by
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>the AIA extension in the EE certificate would not include
> >>>>>>>>>>>
> > the
> >
> >>>>>>>>>>certificate
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>of
> >>>>>>>>>>>>the CRL signer.  One could find this certificate by
building
> >>>>>>>>>>>
> >>>in
> >>>
> >>>
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>reverse direction and using the SIA extension, but that
may
> >>>>>>>>>>>
> >>>not
> >>>
> >>>
> >>>>>be
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>the most convenient solution.
> >>>>>>>>>>>>
> >>>>>>>>>>>>So, when indirect CRLs are being used, it seems that it
> >>>>>>>>>>>
> > would
> >
> >>>be
> >>>
> >>>
> >>>>>>>>>very
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>useful
> >>>>>>>>>>>>to have a pointer in the CRL to the CRL signing
certificate.
> >>>>>>>>>>>
> >>>>>When
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>CRL
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>is not indirect, the need for this pointer does not seem
to
> >>>>>>>>>>>
> > be
> >
> >>>>>as
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>clear,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>but
> >>>>>>>>>>>>I can't see any harm in including it.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Dave
> >>>>>>>>>>>>
> >>>>>>>>>>>>Stefan Santesson wrote:
> >>>>>>>>>>>>All,
> >>>>>>>>>>>>
> >>>>>>>>>>>>I'm interested in the opinion from members on this list
> >>>>>>>>>>>
> > about
> >
> >>>>>>>>>discovery
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>of
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>CRL signer's certificate in non directory centric
> >>>>>>>>>>>
> >>>environments.
> >>>
> >>>
> >>>>>>>>>>>>The problem is the following.
> >>>>>>>>>>>>
> >>>>>>>>>>>>The relying party (RP) needs to check validity of a
> >>>>>>>>>>>
> >>>certificate
> >>>
> >>>
> >>>>>and
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>finds
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>a
> >>>>>>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this
> >>>>>>>>>>>
> > CRL
> >
> >>>>>>>>>>>>which
> >>>>>>>>>>>
> >>>>>>>>>in
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>this
> >>>>>>>>>>>>particular case is either signed by another key of the CA
> >>>>>>>>>>>
> >>>>>(re-keyed
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>CA)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>or
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>another entity (indirect CRL).
> >>>>>>>>>>>>
> >>>>>>>>>>>>In this case the relying party needs to obtain the
> >>>>>>>>>>>
> > certificate
> >
> >>>>>of
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>the
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>CRL
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>signer which may NOT be part of the original chain. In a
> >>>>>>>>>>>
> >>>>>directory
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>centric
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>solution this is retrieved from the directory, but what if
> >>>>>>>>>>>
> >>>such
> >>>
> >>>
> >>>>>>>>>>directory
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>is
> >>>>>>>>>>>>not available or accessible.
> >>>>>>>>>>>>
> >>>>>>>>>>>>The RP have thus no hint where to find the CRL issuers
> >>>>>>>>>>>
> >>>>>certificate
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>unless
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>the RP already have possession of it by some other means.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Is seems that CRLs would need an AIA extension with the
> >>>>>>>>>>>
> > option
> >
> >>>>>to
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>point
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>to
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>the location of the signers certificate in the same manner
> >>>>>>>>>>>
> > as
> >
> >>>is
> >>>
> >>>
> >>>>>>>>>>possible
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>for certificates.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Maybe AIA should be defined as both cert and CRL extension
> >>>>>>>>>>>
> > and
> >
> >>>>>not
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>only
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>certificate extension as today.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Thoughts and comments?
> >>>>>>>>>>>>
> >>>>>>>>>>>>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 i9IExalp035751; Mon, 18 Oct 2004 07:59:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IExaMO035750; Mon, 18 Oct 2004 07:59:36 -0700 (PDT)
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 i9IExYQ6035711 for <[e-mail]>; Mon, 18 Oct 2004 07:59:35 -0700 (PDT) (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 RAA40166; Mon, 18 Oct 2004 17:11:04 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101816591981:1848 ; Mon, 18 Oct 2004 16:59:19 +0200 
Message-ID: <[e-mail]>
Date: Mon, 18 Oct 2004 16:57:32 +0200
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]>, Stefan Santesson <[e-mail]>
CC: "'pkix'" <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <006001c4b512$34a7d6b0$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/10/2004 16:59:20, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/10/2004 16:59:22, Serialize complete at 18/10/2004 16:59: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 and Stefan,

Now we get to the point that there exists one solution, while the thread 
started saying that there was no other solution.

We can now start to discuss the advantages and disadvantages of the two 
solutions.

However, we have to provide a fair view.

For the time being, you have only considered the disadvantages of the 
*current* solution, i.e. using SIA. It would be fair that you also consider 
its advantages and that we take the time to have a fair comparison.

> The SIA can be used to find the certificate, but it leads to the exponential
> growth in the search base in the case of indirect CRL.

This is an argument about disadvantages. However this argument is incorrect: 
there is no exponential grow. A CA nominates an authority either as :

  1 - "CA issuer + CRL issuer"
  2 - "CA issuer only", or
  3 - "CRL Issuer only"

Once the path is constructed, if every CA certificate includes the SIA 
extension, then this is straightforward.

> Also, I do not think SIA is that well supported.

I could say that the new proposal is not "that well supported" but this 
would be an argument leading nowhere. :-|

The SIA extension is very useful and we should make our best efforts so that 
it will be more and more supported. Providing "yet another way" is not going 
to lead in that direction. :-(

> Thus, we need to consider the commercial realities and permit a simple and
> elegant approach of using AIA to prime the pump (so to speak) to start the
> CRL signer path development.

SIA was not present in RFC 2459. It has been introduced in RFC 3280 and this 
is a good point. It should be generalized in order to support 
interoperability. Going down from trust points to leaf certificates allow to 
cover any case.

The answers to Stefan follow:

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]] 
> Sent: Monday, October 18, 2004 8:19 AM
> To: Denis Pinkas
> Cc: Santosh Chokhani; pkix
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> Thanks Denis,
> 
> I now finally understand your SIA alternative.
> 
> There are some major problems with it though.

> 1) How can the RP know what certificate's SIA it would use to find the CRL
> signer cert?

> You just picked the right certificate in my example since I gave that
> information in the example. But the RP don't know that path, it only knows
> the path of the EE cert and the name of the CRL issuer!

This is sufficient to find out the right certificate once you know where the 
CA places the certificates that it has issued.

> 2) And even if RP knew the path beforehand, finding THE one CRL signer
> certificate from a CRL AIA is much more direct and efficient than finding
> among all issued certificates from a CA the 1 out of x issued certificates
> that is the CRL Issuer cert.

Usually a CA issues a small number of CA certificates and CRL certificates. 
So this is not a problem.

> 3) Using SIA in the examples requires available directories and directory
> enabled clients. How do you solve the problem if either of these is not
> available?

It could work as well with HTTP using the recent draft that has been proposed.

> Do you seriously suggest that use of SIA is a better and more effective way
> to address this problem or are you just pointing out the fact that there are
> SOME cases where use of SIA may work in theory?

I rather believe that your question was:

"Do you suggest that use of SIA is a better and more effective way to 
address this problem or are you just pointing out the fact that there are 
SOME cases where use of SIA may work ?

SIA is certainly better and shoud be generalized to ease path contruction, 
not only for CRL issuers but also for CAs.

SIA may work in ALL cases, unless you provide an example where it cannot.

Now I have spent quite a lot of time on that topic (on which I am personally 
NOT interested), but since I have been asked by the Security Area Director 
to provide details I needed to respond.

I will not be able to sustain the same level of discussions in the next 
coming days. In particular, I will not be in my office tomorrow. So you have 
plenty of time to consider pros and cons for both approaches and do not take 
silence as approval.

Denis

> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: den 18 oktober 2004 12:28
>>To: Stefan Santesson
>>Cc: Santosh Chokhani; pkix
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>Stefan,
>>
>>
>>>Denis,
>>
>>>If I get you right you mean that one can always successfully use AIA
>>
> and
> 
>>>SIA in certs to solve discovery of CRL signer cert.
>>>Others on this list (me included) don't understand how. It would 
>>>therefore be useful if you told us.
>>>
>>>I'll try to explain the problem from my perspective one more time.
>>
>>Thanks.
>>
>>
>>>Note: "->" in these examples means "issued by"
>>
>>Fine.
>>
>>
>>>Case 1 - indirect CRL:
>>>
>>>Cert path is:  EE_Cert -> CA_1 -> Root-CA
>>>CRL path for EE_Cert is:  CRL -> CRL_Issuer_B -> Root-CA
>>
>>This means Root-CA has nominated CA_1 and a CRL_Issuer_B and that CA_1
> 
> has
> 
>>chosen to use CRL_Issuer_B for revocation checking for some
> 
> certificates.
> 
>>>Scenario:
>>>Relying party has access to the cert path, discovers the CRL through
>>
> CDP
> 
>>>in EE_Cert.
>>
>>If there is no attack on the objects stored at the CRL DP, the CRL
> 
> Issuer
> 
>>from that CRL is CRL_Issuer_B. Now the relying party needs to get the 
>>certificate isued by Root-CA for CRL_Issuer_B. If Root-CA has included
> 
> a
> 
>>SIA
>>extension in his self-signed certificate, then using that extension
> 
> allows
> 
>>to get the CRL_Issuer_B certificate issued by the Root-CA.
>>
>> > The RP searches the location specified in SIA through
>>
>>>id-ad-caRepository in the CA_1 cert but finds nothing useful since 
>>>revocation is subordinated to another entity (CRL_Issuer_B)
>>
>>Correct, but looking in Root-CA allows to find something useful, if
> 
> the
> 
>>self-signed certificate includes a SIA extension.
>>
>>
>>>In this case, the problem could be solved if an AIA in the CRL
>>
> indicated
> 
>>>the access location of the CRL Issuer cert.
>>
>>This would be an *alternative* way.
>>
>>
>>>Case 2 - re-keyed CA.
>>>
>>>Cert path is:  EE_Cert -> CA_1(old key) -> Root-CA
>>>CRL path for EE_Cert is:  CRL -> CA_1(new key) -> Root-CA
>>
>>This means that the EE_Cert chain has been created with CA_1(old key)
> 
> and
> 
>>that the CRL issuer that was originaly used when the EE_Cert was
> 
> created
> 
>>has
>>been changed and a new CRL Issuer got a certificate under CA_1(new
> 
> key)
> 
>>and
>>is now the legitimate CRL issuer for the CRL DP originally mentionned
> 
> in
> 
>>the
>>EE_Cert.
>>
>>
>>>The 2 CA_1 certificates above (old key and new key) are issued to 
>>>different subject keys belonging to the same CA (same name). The 
>>>cert CA_1(old key) was issued before creation of cert CA_1(new
>>
> key)
> 
>>>and have thus no reference to CA_1(new key) in its SIA
>>>
>>>Scenario:
>>>RP discovers the CRL for the EE_Cert through the CDP but doesn't
>>
> possess
> 
>>>the CRL issuer cert. The RP client searches the SIA of the CA_1(old
>>
> key)
> 
>>>but finds no direct reference to the CRL signer cert. Since the RP 
>>>client has no access to a directory where the CRL signer cert could
>>
> be
> 
>>>found through directory lookup, cert validation fails.
>>
>>Correct, but looking in Root-CA allows to find something useful, if
> 
> the
> 
>>self-signed certificate includes a SIA extension.
>>
>>
>>>In this scenario the problem could be solved through an AIA in the
>>
> CRL.
> 
>>This would be an *alternative* way.
>>
>>Denis
>>
>>
>>>
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>Sent: den 15 oktober 2004 17:30
>>>>To: Stefan Santesson
>>>>Cc: Santosh Chokhani; pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>Stefan,
>>>>
>>>>
>>>>
>>>>>Denis,
>>>>
>>>>>Unfortunately I fail to understand your questions, issues and
>>>>
>>>requests.
>>>
>>>
>>>>The sentence below demonstrates that you understand the issue.
>>>>
>>>>
>>>>
>>>>>It would be very useful if you could explain how current mechanisms
>>>>
>>>can
>>>
>>>
>>>>>be used in a simple and straightforward manner to discover CRL
>>>>
>>>signer
>>>
>>>
>>>>>certificates in ALL the use cases discussed, mainly re-keyed CA and 
>>>>>indirect CRLs.
>>>>
>>>>You are also reversing the question. Using your terms, my question
>>>
>>>would
>>>
>>>
>>>>be:
>>>>
>>>>"It would be very useful if you could explain how current mechanisms 
>>>>CANNOT be used in a simple and straightforward manner to discover 
>>>>CRL
>>>
> signer
> 
>>>>certificates in ONE or MORE the use cases discussed, mainly re-keyed
>>>
>>>CA
>>>
>>>
>>>>and
>>>>indirect CRLs."
>>>>
>>>>Denis
>>>>
>>>>
>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [e-mail]
>>>>>
>>>>>[mailto:[e-mail]]
>>>>>
>>>>>
>>>>>
>>>>>>On Behalf Of Denis Pinkas
>>>>>>Sent: den 14 oktober 2004 17:13
>>>>>>To: Santosh Chokhani
>>>>>>Cc: 'pkix'
>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>
>>>>>>
>>>>>>Santosh,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Denis:
>>>>>>
>>>>>>>With the three assumptions/constraints I provided, how would you
>>>>>>
>>>>>locate
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>>CRL issuer certificate for the two examples using 3280 extensions
>>>>>>
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>without putting AIA in the CRL?
>>>>>>
>>>>>>As far as I understand, the three assumptions are:
>>>>>>
>>>>>>1.  You are directory challenged; and
>>>>>>   [I do not understand what this means]
>>>>>>2.  You use AIA to develop the path; and
>>>>>>   [It does not matter]
>>>>>>3.  You develop the path from the end entity to trust anchor
>>>>>>   [Could also be the contrary].
>>>>>>
>>>>>>If this is not correct, thus please correct.
>>>>>>
>>>>>>Then my request is: "using ANY OF the current extensions that are
>>>>>
>>>>>defined
>>>>>
>>>>>
>>>>>
>>>>>>in
>>>>>>RFC 3280", which includes SIA.
>>>>>>
>>>>>>In your explanations  you said :
>>>>>>"if you do no deal with SIA et. al"
>>>>>>
>>>>>>This last assumption is neither part of the three assumptions and
>>>>>
>>>does
>>>
>>>
>>>>>not
>>>>>
>>>>>
>>>>>
>>>>>>conform to my request.
>>>>>>
>>>>>>Denis
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>That is my point.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>>>Sent: Thursday, October 14, 2004 6:22 AM
>>>>>>>To: Santosh Chokhani
>>>>>>>Cc: 'pkix'
>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>
>>>>>>>Santosh,
>>>>>>>
>>>>>>>You misread my request. I said:
>>>>>>>
>>>>>>>"For the time being, I would like that you provide an example
>>>>>>
>>>where,
>>>
>>>
>>>>>>when
>>>>>>
>>>>>>
>>>>>>
>>>>>>>using the current extensions that are defined in RFC 3280, it
>>>>>>
> will
> 
>>>>>NOT
>>>>>
>>>>>
>>>>>
>>>>>>be
>>>>>>
>>>>>>
>>>>>>
>>>>>>>possible to locate a CRL Issuer certificate."
>>>>>>>
>>>>>>>Maybe I would have needed to be clearer and say :
>>>>>>>
>>>>>>>"For the time being, I would like that you provide an example
>>>>>>
>>>where,
>>>
>>>
>>>>>>when
>>>>>>
>>>>>>
>>>>>>
>>>>>>>using ANY OF the current extensions that are defined in RFC 3280,
>>>>>>
>>>it
>>>
>>>
>>>>>>will
>>>>>>
>>>>>>
>>>>>>
>>>>>>>NOT be possible to locate a CRL Issuer certificate."
>>>>>>>
>>>>>>>The examples you provide below do not fulfil this request.
>>>>>>>
>>>>>>>The assumption is that there exists a path to be tested for
>>>>>>
>>>>>revocation
>>>>>
>>>>>
>>>>>
>>>>>>>checking (and that it does not matter to know which way it has
>>>>>>
> been
> 
>>>>>>>constructed).
>>>>>>>
>>>>>>>I am not saying that using AIA in CRL might not be useful, but I
>>>>>>
> am
> 
>>>>>>still
>>>>>>
>>>>>>
>>>>>>
>>>>>>>lacking the demonstration that there would be no other way.
>>>>>>>
>>>>>>>Denis
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Denis:
>>>>>>>>
>>>>>>>>Two examples are very simple: one for direct CRL Issuer and one
>>>>>>>
>>>for
>>>
>>>
>>>>>>>>Indirect CRL Issuer.
>>>>>>>>
>>>>>>>>Let us make the following assumptions that Stefan was making:
>>>>>>>>
>>>>>>>>1.  You are directory challenged; and
>>>>>>>>2.  You use AIA to develop the path; and
>>>>>>>>3.  You develop the path from the end entity to trust anchor.
>>>>>>>>
>>>>>>>
>>>>>>>>From what I know of MS CAPI, these are reasonable
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>assumptions/constraints.
>>>>>>>>
>>>>>>>>Now the examples.
>>>>>>>>
>>>>>>>>Example 1: Direct CRL Issuer
>>>>>>>>
>>>>>>>>The certificate trust path is:
>>>>>>>>Root --> CA1 --> CA 2, old key --> Denis
>>>>>>>>
>>>>>>>>The CRL trust path is:
>>>>>>>>Root --> CA1 --> CA 2, new key --> CRL
>>>>>>>>
>>>>>>>>(Note: We do not do self-issued certificate since there is no
>>>>>>>
>>>>>simple,
>>>>>
>>>>>
>>>>>
>>>>>>>>secure way to check their revocation status).
>>>>>>>>
>>>>>>>>Now, with AIA in CRL, finding the CA2, new key certificate is 
>>>>>>>>straightforward.  How would you find it if you do no deal with
>>>>>>>
> SIA
> 
>>>>>et.
>>>>>
>>>>>
>>>>>
>>>>>>>>al.
>>>>>>>>
>>>>>>>>Example 2: Indirect CRL Issuer
>>>>>>>>
>>>>>>>>The certificate trust path is:
>>>>>>>>Root --> CA1 --> CA 2 --> Denis
>>>>>>>>(Note: Denis's certificate points to CRL DP of an indirect CRL
>>>>>>>
>>>>>issued
>>>>>
>>>>>
>>>>>
>>>>>>>>by CAI.
>>>>>>>>
>>>>>>>>The CRL trust path is:
>>>>>>>>Root --> CAI --> CRL
>>>>>>>>
>>>>>>>>Now, with AIA in CRL, finding the CAI certificate is
>>>>>>>
>>>>>straightforward.
>>>>>
>>>>>
>>>>>
>>>>>>>>How would you find it if you do no deal with SIA et. al.
>>>>>>>>
>>>>>>>>In addition to the need cited above, please note that the
>>>>>>>
>>>extension
>>>
>>>
>>>>>>>>semantics does not change, it does not hinder any
>>>>>>>
>>>interoperability,
>>>
>>>
>>>>>>>>and it does not break any backward compatibility.  So, what if I 
>>>>>>>>wanted to use this extension in the CRL.  It does no harm to
>>>>>>>
> other
> 
>>>>>>>>relying parties.
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: [e-mail] 
>>>>>>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>>>>>>>Sent: Wednesday, October 13, 2004 11:01 AM
>>>>>>>>To: Stefan Santesson
>>>>>>>>Cc: Santosh Chokhani; pkix
>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>Stefan,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Denis,
>>>>>>>>
>>>>>>>>
>>>>>>>>>I'm not sure what you mean.
>>>>>>>>
>>>>>>>>
>>>>>>>>For the time being, I would like that you provide an example
>>>>>>>
>>>where,
>>>
>>>
>>>>>>>>when
>>>>>>>>using the current extensions that are defined in RFC 3280, it
>>>>>>>
> will
> 
>>>>>NOT
>>>>>
>>>>>
>>>>>
>>>>>>be
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>possible to locate a CRL Issuer certificate.
>>>>>>>>
>>>>>>>>If you are able to provide that example, then it would justify
>>>>>>>
> the
> 
>>>>>>>>need for
>>>>>>>>an extension at least for one case. Then we can see what that
>>>>>>>
> case
> 
>>>>>is.
>>>>>
>>>>>
>>>>>
>>>>>>>>I am awaiting that example.
>>>>>>>>
>>>>>>>>Denis
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>I conclude that I agree with Santosh.
>>>>>>>>>
>>>>>>>>>The debate is still open... Feel free to express your opinion.
>>>>>>>>>
>>>>>>>>>Stefan Santesson
>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>-----Original Message-----
>>>>>>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>>>>>>Sent: den 13 oktober 2004 16:34
>>>>>>>>>>To: Stefan Santesson
>>>>>>>>>>Cc: Santosh Chokhani; pkix
>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>>
>>>>>>>>>>Stefan,
>>>>>>>>>>
>>>>>>>>>>You are making a conclusion without letting me the time to
>>>>>>>>>
>>>>>respond. I
>>>>>
>>>>>
>>>>>
>>>>>>>>>>will need more time to look at the pictures (and understand
>>>>>>>>>
>>>them).
>>>
>>>
>>>>>>>>>>For the time being, I am still reluctant to accept
>>>>>>>>>
>>>>>>>>>"yet-another-method".
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>We already have too many.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Santosh,
>>>>>>>>>>>
>>>>>>>>>>>I conclude that we are in complete and total agreement. The 
>>>>>>>>>>>question is how to go about this.
>>>>>>>>>>
>>>>>>>>>>>Could we do this amendment to RFC 3280 in its next revision?
>>>>>>>>>>
> It
> 
>>>>>>>>>>>would hopefully just be a minor change.
>>>>>>>>>>
>>>>>>>>>>This is exactly what I feared.
>>>>>>>>>>
>>>>>>>>>>We usually end-up with a "minor change" in an extension
>>>>>>>>>
> without
> 
>>>>>>>>>>saying cleary how and when it shall/should be used.
>>>>>>>>>>
>>>>>>>>>>I still have in mind that:
>>>>>>>>>>
>>>>>>>>>>1) a certification path must first be constructed,
>>>>>>>>>>2) then the revocation checking of that path must be done.
>>>>>>>>>>
>>>>>>>>>>This means that information about CRL issuers certificates
>>>>>>>>>
>>>>>locations
>>>>>
>>>>>
>>>>>
>>>>>>>>>may
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>certainly be found in that chain. If not, I would like an
>>>>>>>>>
>>>example.
>>>
>>>
>>>>>>>>>>Denis
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>It would not change the definition of AIA just add that it
>>>>>>>>>>
> can
> 
>>>be
>>>
>>>
>>>>>>>>>used
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>also as CRL extension and list eventual restrictions and
>>>>>>>>>
>>>guidance
>>>
>>>
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>>>>>use
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>with CRLs.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Stefan Santesson
>>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>-----Original Message-----
>>>>>>>>>>>>From: [e-mail]
>>>>>>>>>>>
>>>>>>>>>[mailto:[e-mail]]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>On Behalf Of Santosh Chokhani
>>>>>>>>>>>>Sent: den 13 oktober 2004 04:33
>>>>>>>>>>>>To: 'pkix'
>>>>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan:
>>>>>>>>>>>>
>>>>>>>>>>>>In terms of certificate discovery, your proposal for AIA in
>>>>>>>>>>>
>>>CRL
>>>
>>>
>>>>>is
>>>>>
>>>>>
>>>>>
>>>>>>>>>more
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>robust.  The whole idea of self-issued key rollover
>>>>>>>>>>>
>>>certificates
>>>
>>>
>>>>>>>>>>>>and
>>>>>>>>>>>
>>>>>>>>>>then
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>using the new key to issue CRL is fraught with security
>>>>>>>>>>>
>>>>>problems.
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>A secure solution would be one where the new key is
>>>>>>>>>>>
> certified
> 
>>>by
>>>
>>>
>>>>>>>>>>>>the parent
>>>>>>>>>>>
>>>>>>>>>CA.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>In
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>that case to obtain the new certificate, you could use AIA
>>>>>>>>>>>
> in
> 
>>>>>CRL.
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP
>>>>>>>>>>>
>>>in
>>>
>>>
>>>>>>>>>>>>certificate in question points to the indirect CRL.  You get
>>>>>>>>>>>
>>>>>that
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>CRL.  The AIA
>>>>>>>>>>>
>>>>>>>>>in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>CRL
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>gets you started for the indirect CRL issuer certification
>>>>>>>>>>>
>>>path
>>>
>>>
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>>>you
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>are
>>>>>>>>>>>>in business.
>>>>>>>>>>>>
>>>>>>>>>>>>-----Original Message-----
>>>>>>>>>>>>From: [e-mail]
>>>>>>>>>>>
>>>>>>>>>[mailto:[e-mail]]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>On
>>>>>>>>>>>>Behalf Of Stefan Santesson
>>>>>>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>>>>>>>>To: David A. Cooper
>>>>>>>>>>>>Cc: pkix
>>>>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>David,
>>>>>>>>>>>>
>>>>>>>>>>>>Thanks for the clarifications, they make sense.
>>>>>>>>>>>>I did misread your pictures.
>>>>>>>>>>>>
>>>>>>>>>>>>So can we conclude that for a re-keyed CA in accordance with
>>>>>>>>>>>
>>>RFC
>>>
>>>
>>>>>>>>>3280,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>either the CRL issuer certificate itself, or the location of
>>>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>>>>>>CRL issuer certificate, will be clearly identified/available
>>>>>>>>>>>
>>>for
>>>
>>>
>>>>>>>>>>>>the validating
>>>>>>>>>>>
>>>>>>>>>>party
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>in some cases, but not in others?
>>>>>>>>>>>>
>>>>>>>>>>>>Can we also conclude that there is no real discovery
>>>>>>>>>>>
> solution
> 
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>>>>>>indirect
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>CRLs?
>>>>>>>>>>>>
>>>>>>>>>>>>Do you then agree then that it could be appropriate to allow
>>>>>>>>>>>
>>>AIA
>>>
>>>
>>>>>as
>>>>>
>>>>>
>>>>>
>>>>>>>>>a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>CRL
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan Santesson
>>>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>>>>
>>>>>>>>>>>>________________________________________
>>>>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>>>>>Sent: den 12 oktober 2004 21:14
>>>>>>>>>>>>To: Stefan Santesson
>>>>>>>>>>>>Cc: pkix
>>>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan,
>>>>>>>>>>>>
>>>>>>>>>>>>I believe that you are misinterpreting the figures.  They
>>>>>>>>>>>
>>>really
>>>
>>>
>>>>>do
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>represent three different cases, not three different
>>>>>>>>>>>
>>>>>certification
>>>>>
>>>>>
>>>>>
>>>>>>>>>paths
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>that have been constructed through the same PKI
>>>>>>>>>>>
> architecture.
> 
>>>>>>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>>>>>>>>
>>>>>>>>>certificates.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>The
>>>>>>>>>>>>Root CA has issued a certificate to CA 1's new key, but not
>>>>>>>>>>>
>>>its
>>>
>>>
>>>>>old
>>>>>
>>>>>
>>>>>
>>>>>>>>>key
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>(either the Root CA never issued a certificate to CA 1's old
>>>>>>>>>>>
>>>key
>>>
>>>
>>>>>or
>>>>>
>>>>>
>>>>>
>>>>>>>>>that
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certificate has expired).
>>>>>>>>>>>>
>>>>>>>>>>>>In figure 2, CA 2 has also generated self-issued key
>>>>>>>>>>>
> rollover
> 
>>>>>>>>>>>>certificates. The Root CA has issued a certificate to CA 2's
>>>>>>>>>>>
>>>old
>>>
>>>
>>>>>>>>>>>>key, but not its
>>>>>>>>>>>
>>>>>>>>>new
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>key.
>>>>>>>>>>>>
>>>>>>>>>>>>In figure 3, when CA 3 performed key rollover, it requested
>>>>>>>>>>>
> a
> 
>>>>>new
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>CA certificate from the Root CA.  CA 3 did not generated 
>>>>>>>>>>>>self-issued
>>>>>>>>>>>
>>>>>>>>>key
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>rollover certificates.
>>>>>>>>>>>>
>>>>>>>>>>>>Of course, another realistic scenario would be one in which
>>>>>>>>>>>
> a
> 
>>>CA
>>>
>>>
>>>>>>>>>>generated
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>self-issued key rollover certificates upon key rollover and
>>>>>>>>>>>
>>>then
>>>
>>>
>>>>>>>>>>>>had
>>>>>>>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>Root CA issue a CA certificate to its new key.  In this
>>>>>>>>>>>
> case,
> 
>>>as
>>>
>>>
>>>>>>>>>>>>you suggest, any of the certification paths from figures 1,
>>>>>>>>>>>
> 2,
> 
>>>>>or 3
>>>>>
>>>>>
>>>>>
>>>>>>>>>could be
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>constructed.
>>>>>>>>>>>>
>>>>>>>>>>>>As for the contents of the AIA extension, here is what I
>>>>>>>>>>>
> have
> 
>>>>>>>>>specified
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>in
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the
>>>>>>>>>>>
>>>Common
>>>
>>>
>>>>>>>>>>Policy":
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>The authorityInfoAccess extension uses URIs for two
>>>>>>>>>>>
> purposes.
> 
>>>>>When
>>>>>
>>>>>
>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>id-ad-caIssuers access method is used, the access location 
>>>>>>>>>>>>specifies
>>>>>>>>>>>
>>>>>>>>>>where
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>certificates issued to the issuer of the certificate may be
>>>>>>>>>>>
>>>>>found.
>>>>>
>>>>>
>>>>>
>>>>>>>>>If
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>LDAP
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>is used, the URI must include the DN of the entry containing
>>>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>>>>relevant
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>certificates and specify the directory attribute in which
>>>>>>>>>>>
> the
> 
>>>>>>>>>>certificates
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>are located. If the directory in which the certificates are
>>>>>>>>>>>
>>>>>stored
>>>>>
>>>>>
>>>>>
>>>>>>>>>>expects
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the "binary" option to be specified, then the attribute type
>>>>>>>>>>>
>>>>>must
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the
>>>>>>>>>>>
> URI
> 
>>>>>must
>>>>>
>>>>>
>>>>>
>>>>>>>>>point to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>file that has an extension of ".p7c" that contains a
>>>>>>>>>>>
>>>certs-only
>>>
>>>
>>>>>CMS
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>message (see RFC 2633). The CMS message should include all 
>>>>>>>>>>>>certificates
>>>>>>>>>>>
>>>>>>>>>issued
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the issuer of this certificate, but must at least contain
>>>>>>>>>>>
> all
> 
>>>>>>>>>>certificates
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>issued to the issuer of this certificate in which the
>>>>>>>>>>>
> subject
> 
>>>>>>>>>>>>public
>>>>>>>>>>>
>>>>>>>>>key
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>may
>>>>>>>>>>>>be used to verify the signature on this certificate. ....
>>>>>>>>>>>
> For
> 
>>>a
>>>
>>>
>>>>>>>>>>>>certificate issued by "Good CA", some examples of URIs that
>>>>>>>>>>>
>>>may
>>>
>>>
>>>>>>>>>>>>appear as the
>>>>>>>>>>>
>>>>>>>>>access
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>location in an authorityInfoAccess extension when the
>>>>>>>>>>>
>>>>>>>>>id-ad-caIssuers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>access
>>>>>>>>>>>>method is used are:
>>>>>>>>>>>
>>>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cA
>>>>>>>
> C
> 
>>>e
>>>
>>>
>>>>>r
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>t
>>>>>>>>>>>i
>>>>>>>>>>
>>>>>>>>>fi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>ca
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>te
>>>>>>>>>>>>,crossCertificatePair
>>>>>>>>>>>
>>>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACert
>>>>>>>
> i
> 
>>>f
>>>
>>>
>>>>>i
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>c
>>>>>>>>>>>a
>>>>>>>>>>
>>>>>>>>>te
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>;b
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>in
>>>>>>>>>>>>ary,crossCertificatePair;binary
>>>>>>>>>>>
>>>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsI
>>>>>>>
> s
> 
>>>s
>>>
>>>
>>>>>u
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>e
>>>>>>>>>>>d
>>>>>>>>>>
>>>>>>>>>To
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Go
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>od
>>>>>>>>>>>>CA.p7c
>>>>>>>>>>>>For both LDAP and HTTP, the URI provides the exact location
>>>>>>>>>>>
>>>>>where
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>information is to be located, so there is no requirement for
>>>>>>>>>>>
>>>the
>>>
>>>
>>>>>>>>>relying
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>party to try to figure out where information is located.
>>>>>>>>>>>>
>>>>>>>>>>>>The HTTP URI points to a certs-only CMS message that
>>>>>>>>>>>
> includes
> 
>>>>>all
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>certificates issued to the CA identified in the issuer field
>>>>>>>>>>>
>>>of
>>>
>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>certificate.
>>>>>>>>>>>>
>>>>>>>>>>>>The LDAP URI points to the cACertificate and
>>>>>>>>>>>
>>>>>crossCertificatePair
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>attributes of the directory entry of the CA identified in
>>>>>>>>>>>
> the
> 
>>>>>>>>>>>>issuer field of
>>>>>>>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certificate.  These two attributes together hold all of the
>>>>>>>>>>>
>>>>>>>>>certificates
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>issued to the CA:  the cACertificate attribute holds the
>>>>>>>>>>>
> CA's
> 
>>>>>self-
>>>>>
>>>>>
>>>>>
>>>>>>>>>>issued
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>certificates and the crossCertificatePair attribute holds
>>>>>>>>>>>
> the
> 
>>>>>>>>>>>>cross-certificates issued to the CA by other CAs.
>>>>>>>>>>>>
>>>>>>>>>>>>Dave
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan Santesson wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>David,
>>>>>>>>>>>>
>>>>>>>>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>>>>>>>>
>>>>>>>>>>>>I have some comments and questions on this.
>>>>>>>>>>>>
>>>>>>>>>>>>First of all we can conclude that in some scenarios (figure
>>>>>>>>>>>
> 1)
> 
>>>>>>>>>>>>where
>>>>>>>>>>>
>>>>>>>>>a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>self
>>>>>>>>>>>>issued certificate is inserted into the path, you are likely
>>>>>>>>>>>
>>>to
>>>
>>>
>>>>>>>>>>>>find
>>>>>>>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>CRL
>>>>>>>>>>>>issuer cert in the path. (given that the new CA have a
>>>>>>>>>>>
> common
> 
>>>>>key
>>>>>
>>>>>
>>>>>
>>>>>>>>>and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certificate for cert signing and CRL signing).
>>>>>>>>>>>>
>>>>>>>>>>>>Figure 1, 2 and 3 describe the same case. It is just
>>>>>>>>>>>
>>>describing
>>>
>>>
>>>>>>>>>>different
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>path building strategies. An application that has access
>>>>>>>>>>>
>>>locally
>>>
>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>>>>>all
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>chaining options may however still choose path 2 for the
>>>>>>>>>>>
> certs
> 
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>>>path
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>for the CRL independent of each other (which I think figure
>>>>>>>>>>>
> 3
> 
>>>>>tries
>>>>>
>>>>>
>>>>>
>>>>>>>>>to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>describe)
>>>>>>>>>>>>
>>>>>>>>>>>>Another comment is the structure of AIA extensions. The use
>>>>>>>>>>>
>>>I'm
>>>
>>>
>>>>>>>>>familiar
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>with doesn't use AIA to describe a directory entry where it
>>>>>>>>>>>
> is
> 
>>>>>left
>>>>>
>>>>>
>>>>>
>>>>>>>>>to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>validation application logic to be intelligent enough to
>>>>>>>>>>>
> find
> 
>>>>>>>>>>appropriate
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>certificate data from the directory. The model I'm familiar
>>>>>>>>>>>
>>>with
>>>
>>>
>>>>>is
>>>>>
>>>>>
>>>>>
>>>>>>>>>when
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>AIA URL explicitly identifies the exact location of the
>>>>>>>>>>>
>>>>>appropriate
>>>>>
>>>>>
>>>>>
>>>>>>>>>CA
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certificate file, relieving the validation software from
>>>>>>>>>>>
>>>complex
>>>
>>>
>>>>>>>>>>>>information queries. If just location of explicit
>>>>>>>>>>>
> certificate
> 
>>>>>files
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>are
>>>>>>>>>>>
>>>>>>>>>identified
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>through AIA, the presence of an AIA may not help finding the
>>>>>>>>>>>
>>>CRL
>>>
>>>
>>>>>>>>>signer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>cert
>>>>>>>>>>>>if this is different from the CA certificate. This is also
>>>>>>>>>>>
> the
> 
>>>>>>>>>problem
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>with
>>>>>>>>>>>>Denis proposal.
>>>>>>>>>>>>
>>>>>>>>>>>>I think we share the basic conclusion that the ability to
>>>>>>>>>>>
>>>locate
>>>
>>>
>>>>>>>>>>>>the
>>>>>>>>>>>
>>>>>>>>>CRL
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>signer certificate directly through the CRL could be very
>>>>>>>>>>>
>>>>>useful.
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>At
>>>>>>>>>>>
>>>>>>>>>>least
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>in the case of indirect CRL but it could also be proven very
>>>>>>>>>>>
>>>>>useful
>>>>>
>>>>>
>>>>>
>>>>>>>>>in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>CA
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>re-keying scenarios.
>>>>>>>>>>>>
>>>>>>>>>>>>The easiest solution would probably be to allow AIA to be
>>>>>>>>>>>
> used
> 
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>>>>>its
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>>>>>>>>
>>>>>>>>>critical).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>It
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>would present a very clear and uncomplicated logic to
>>>>>>>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>validating applications in many cases.
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan Santesson
>>>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>>>>
>>>>>>>>>>>>________________________________________
>>>>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>>>>>Sent: den 7 oktober 2004 18:35
>>>>>>>>>>>>To: Stefan Santesson
>>>>>>>>>>>>Cc: pkix
>>>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan,
>>>>>>>>>>>>
>>>>>>>>>>>>I think what you are proposing is a good idea.  In most
>>>>>>>>>>>
> cases,
> 
>>>>>path
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>discovery algorithms assume that both the trust anchor (or
>>>>>>>>>>>
>>>trust
>>>
>>>
>>>>>>>>>>anchors)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>and the end entity certificate are provided as input.  In
>>>>>>>>>>>
> this
> 
>>>>>>>>>>>>case,
>>>>>>>>>>>
>>>>>>>>>one
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>may
>>>>>>>>>>>>need to construct a certification path without a priori
>>>>>>>>>>>
> access
> 
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>end
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>entity certificate (the one with the subject public key
>>>>>>>>>>>
>>>>>>>>>corresponding to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>>>>>>>>
>>>>>>>>>pointer) in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>CRL would provide the relying party with a simple way to
>>>>>>>>>>>
>>>obtain
>>>
>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>end
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>entity certificate for the CRL signing key's certification
>>>>>>>>>>>
>>>path.
>>>
>>>
>>>>>On
>>>>>
>>>>>
>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>other hand, I believe that a relying party should be able to
>>>>>>>>>>>
>>>>>>>>>construct
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>certification path even without an AIA extension in the CRL,
>>>>>>>>>>>
>>>so
>>>
>>>
>>>>>>>>>>>>long
>>>>>>>>>>>
>>>>>>>>>as
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>it
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>is not an indirect CRL.  Attached is a drawing of the three
>>>>>>>>>>>
>>>>>basic
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>scenarios that I expect a relying party may encounter:
>>>>>>>>>>>>
>>>>>>>>>>>>In each of these scenarios, the CA has performed key
>>>>>>>>>>>
> rollover
> 
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>is
>>>>>>>>>>>
>>>>>>>>>>only
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>signing CRLs with its new key.  The diagrams would look
>>>>>>>>>>>
>>>similar,
>>>
>>>
>>>>>>>>>>however,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>if
>>>>>>>>>>>>the CA simply choose to use different keys to sign
>>>>>>>>>>>
>>>certificates
>>>
>>>
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>>>CRLs
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>for
>>>>>>>>>>>>some other reason.
>>>>>>>>>>>>
>>>>>>>>>>>>If the PKI architecture resembled figure 1, then the
>>>>>>>>>>>
>>>>>certification
>>>>>
>>>>>
>>>>>
>>>>>>>>>path
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>for
>>>>>>>>>>>>the CRL signing key would just be a subset of the
>>>>>>>>>>>
>>>certification
>>>
>>>
>>>>>>>>>>>>path
>>>>>>>>>>>
>>>>>>>>>for
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>EE certificate, so no addition path discovery would be
>>>>>>>>>>>
> needed.
> 
>>>>>>>>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>>>>>>>>
>>>>>>>>>necessary
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>obtain the new-signed-with-old self-issued certificate.  In 
>>>>>>>>>>>>building
>>>>>>>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certification path to the EE certificate, however, the
>>>>>>>>>>>
> relying
> 
>>>>>>>>>>>>party
>>>>>>>>>>>
>>>>>>>>>>will
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>obtain the certificates pointed to by the AIA extension in
>>>>>>>>>>>
> the
> 
>>>>>EE
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>certificate.  This AIA extension will point to a location 
>>>>>>>>>>>>containing
>>>>>>>>>>>
>>>>>>>>>all
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certificates issued to CA 2, which would include both the
>>>>>>>>>>>
>>>>>>>>>certificate
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>issued
>>>>>>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So,
>>>>>>>>>>>
>>>>>even
>>>>>
>>>>>
>>>>>
>>>>>>>>>though
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>self-issued certificate would not be part of the
>>>>>>>>>>>
> certification
> 
>>>>>path
>>>>>
>>>>>
>>>>>
>>>>>>>>>to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>EE certificate, it would be downloaded by the relying party
>>>>>>>>>>>
>>>>>during
>>>>>
>>>>>
>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>construction of that certification path.  (Yes, there are
>>>>>>>>>>>
>>>>>circular
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>dependency issues in figure 2, but that is another issue.)
>>>>>>>>>>>>
>>>>>>>>>>>>A similar situation would happen if the PKI architecture
>>>>>>>>>>>
>>>>>resembled
>>>>>
>>>>>
>>>>>
>>>>>>>>>>figure
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>>>>>>>>
>>>>>>>>>location
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>containing certificates issued to CA 3.  When the relying
>>>>>>>>>>>
>>>party
>>>
>>>
>>>>>>>>>>downloaded
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>these certificates, it would obtain both of the certificates
>>>>>>>>>>>
>>>>>issued
>>>>>
>>>>>
>>>>>
>>>>>>>>>by
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>Root to CA 3 and so again would have the certificate needed
>>>>>>>>>>>
> to
> 
>>>>>>>>>validate
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>the
>>>>>>>>>>>>CRL signing key.
>>>>>>>>>>>>
>>>>>>>>>>>>In the case of an indirect CRL, things may not work as well.
>>>>>>>>>>>
>>>If
>>>
>>>
>>>>>>>>>>indirect
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>CRLs were used, and the PKI architecture resembled figures 2
>>>>>>>>>>>
>>>or
>>>
>>>
>>>>>3
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>(replacing "New Key" with a different CA), then the set of 
>>>>>>>>>>>>certificates pointed
>>>>>>>>>>>
>>>>>>>>>to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>by
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the AIA extension in the EE certificate would not include
>>>>>>>>>>>
> the
> 
>>>>>>>>>>certificate
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>of
>>>>>>>>>>>>the CRL signer.  One could find this certificate by building
>>>>>>>>>>>
>>>in
>>>
>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>reverse direction and using the SIA extension, but that may
>>>>>>>>>>>
>>>not
>>>
>>>
>>>>>be
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>the most convenient solution.
>>>>>>>>>>>>
>>>>>>>>>>>>So, when indirect CRLs are being used, it seems that it
>>>>>>>>>>>
> would
> 
>>>be
>>>
>>>
>>>>>>>>>very
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>useful
>>>>>>>>>>>>to have a pointer in the CRL to the CRL signing certificate.
>>>>>>>>>>>
>>>>>When
>>>>>
>>>>>
>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>CRL
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>is not indirect, the need for this pointer does not seem to
>>>>>>>>>>>
> be
> 
>>>>>as
>>>>>
>>>>>
>>>>>
>>>>>>>>>clear,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>but
>>>>>>>>>>>>I can't see any harm in including it.
>>>>>>>>>>>>
>>>>>>>>>>>>Dave
>>>>>>>>>>>>
>>>>>>>>>>>>Stefan Santesson wrote:
>>>>>>>>>>>>All,
>>>>>>>>>>>>
>>>>>>>>>>>>I'm interested in the opinion from members on this list
>>>>>>>>>>>
> about
> 
>>>>>>>>>discovery
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>of
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>CRL signer's certificate in non directory centric
>>>>>>>>>>>
>>>environments.
>>>
>>>
>>>>>>>>>>>>The problem is the following.
>>>>>>>>>>>>
>>>>>>>>>>>>The relying party (RP) needs to check validity of a
>>>>>>>>>>>
>>>certificate
>>>
>>>
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>>>>finds
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>a
>>>>>>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this
>>>>>>>>>>>
> CRL
> 
>>>>>>>>>>>>which
>>>>>>>>>>>
>>>>>>>>>in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>this
>>>>>>>>>>>>particular case is either signed by another key of the CA
>>>>>>>>>>>
>>>>>(re-keyed
>>>>>
>>>>>
>>>>>
>>>>>>>>>CA)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>or
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>another entity (indirect CRL).
>>>>>>>>>>>>
>>>>>>>>>>>>In this case the relying party needs to obtain the
>>>>>>>>>>>
> certificate
> 
>>>>>of
>>>>>
>>>>>
>>>>>
>>>>>>>>>the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>CRL
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>signer which may NOT be part of the original chain. In a
>>>>>>>>>>>
>>>>>directory
>>>>>
>>>>>
>>>>>
>>>>>>>>>>centric
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>solution this is retrieved from the directory, but what if
>>>>>>>>>>>
>>>such
>>>
>>>
>>>>>>>>>>directory
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>is
>>>>>>>>>>>>not available or accessible.
>>>>>>>>>>>>
>>>>>>>>>>>>The RP have thus no hint where to find the CRL issuers
>>>>>>>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>
>>>>>>>>>>unless
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the RP already have possession of it by some other means.
>>>>>>>>>>>>
>>>>>>>>>>>>Is seems that CRLs would need an AIA extension with the
>>>>>>>>>>>
> option
> 
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>>>>>point
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the location of the signers certificate in the same manner
>>>>>>>>>>>
> as
> 
>>>is
>>>
>>>
>>>>>>>>>>possible
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>for certificates.
>>>>>>>>>>>>
>>>>>>>>>>>>Maybe AIA should be defined as both cert and CRL extension
>>>>>>>>>>>
> and
> 
>>>>>not
>>>>>
>>>>>
>>>>>
>>>>>>>>>only
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>certificate extension as today.
>>>>>>>>>>>>
>>>>>>>>>>>>Thoughts and comments?
>>>>>>>>>>>>
>>>>>>>>>>>>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 i9ICwnIG013442; Mon, 18 Oct 2004 05:58:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ICwngx013441; Mon, 18 Oct 2004 05:58:49 -0700 (PDT)
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 i9ICwm5e013423 for <[e-mail]>; Mon, 18 Oct 2004 05:58:48 -0700 (PDT) (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 i9ICwk3o018458 for <[e-mail]>; Mon, 18 Oct 2004 08:58:46 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Mon, 18 Oct 2004 08:58:46 -0400
Message-ID: <006001c4b512$34a7d6b0$[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 i9ICwn5e013436
Sender: [e-mail]
Precedence: 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 SIA can be used to find the certificate, but it leads to the exponential
growth in the search base in the case of indirect CRL.

Also, I do not think SIA is that well supported.

Thus, we need to consider the commercial realities and permit a simple and
elegant approach of using AIA to prime the pump (so to speak) to start the
CRL signer path development.

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Monday, October 18, 2004 8:19 AM
To: Denis Pinkas
Cc: Santosh Chokhani; pkix
Subject: RE: Signer certificate discovery for CRLs


Thanks Denis,

I now finally understand your SIA alternative.

There are some major problems with it though.

1) How can the RP know what certificate's SIA it would use to find the CRL
signer cert?

You just picked the right certificate in my example since I gave that
information in the example. But the RP don't know that path, it only knows
the path of the EE cert and the name of the CRL issuer!

2) And even if RP knew the path beforehand, finding THE one CRL signer
certificate from a CRL AIA is much more direct and efficient than finding
among all issued certificates from a CA the 1 out of x issued certificates
that is the CRL Issuer cert.

3) Using SIA in the examples requires available directories and directory
enabled clients. How do you solve the problem if either of these is not
available?


Do you seriously suggest that use of SIA is a better and more effective way
to address this problem or are you just pointing out the fact that there are
SOME cases where use of SIA may work in theory?


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 18 oktober 2004 12:28
> To: Stefan Santesson
> Cc: Santosh Chokhani; pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> > Denis,
> 
> > If I get you right you mean that one can always successfully use AIA
and
> > SIA in certs to solve discovery of CRL signer cert.
> > Others on this list (me included) don't understand how. It would 
> > therefore be useful if you told us.
> >
> > I'll try to explain the problem from my perspective one more time.
> 
> Thanks.
> 
> > Note: "->" in these examples means "issued by"
> 
> Fine.
> 
> > Case 1 - indirect CRL:
> >
> > Cert path is:  EE_Cert -> CA_1 -> Root-CA
> > CRL path for EE_Cert is:  CRL -> CRL_Issuer_B -> Root-CA
> 
> This means Root-CA has nominated CA_1 and a CRL_Issuer_B and that CA_1
has
> chosen to use CRL_Issuer_B for revocation checking for some
certificates.
> 
> > Scenario:
> > Relying party has access to the cert path, discovers the CRL through
CDP
> > in EE_Cert.
> 
> If there is no attack on the objects stored at the CRL DP, the CRL
Issuer
> from that CRL is CRL_Issuer_B. Now the relying party needs to get the 
> certificate isued by Root-CA for CRL_Issuer_B. If Root-CA has included
a
> SIA
> extension in his self-signed certificate, then using that extension
allows
> to get the CRL_Issuer_B certificate issued by the Root-CA.
> 
>  > The RP searches the location specified in SIA through
> > id-ad-caRepository in the CA_1 cert but finds nothing useful since 
> > revocation is subordinated to another entity (CRL_Issuer_B)
> 
> Correct, but looking in Root-CA allows to find something useful, if
the
> self-signed certificate includes a SIA extension.
> 
> > In this case, the problem could be solved if an AIA in the CRL
indicated
> > the access location of the CRL Issuer cert.
> 
> This would be an *alternative* way.
> 
> > Case 2 - re-keyed CA.
> >
> > Cert path is:  EE_Cert -> CA_1(old key) -> Root-CA
> > CRL path for EE_Cert is:  CRL -> CA_1(new key) -> Root-CA
> 
> This means that the EE_Cert chain has been created with CA_1(old key)
and
> that the CRL issuer that was originaly used when the EE_Cert was
created
> has
> been changed and a new CRL Issuer got a certificate under CA_1(new
key)
> and
> is now the legitimate CRL issuer for the CRL DP originally mentionned
in
> the
> EE_Cert.
> 
> > The 2 CA_1 certificates above (old key and new key) are issued to 
> > different subject keys belonging to the same CA (same name). The 
> > cert CA_1(old key) was issued before creation of cert CA_1(new
key)
> > and have thus no reference to CA_1(new key) in its SIA
> >
> > Scenario:
> > RP discovers the CRL for the EE_Cert through the CDP but doesn't
possess
> > the CRL issuer cert. The RP client searches the SIA of the CA_1(old
key)
> > but finds no direct reference to the CRL signer cert. Since the RP 
> > client has no access to a directory where the CRL signer cert could
be
> > found through directory lookup, cert validation fails.
> 
> Correct, but looking in Root-CA allows to find something useful, if
the
> self-signed certificate includes a SIA extension.
> 
> > In this scenario the problem could be solved through an AIA in the
CRL.
> 
> This would be an *alternative* way.
> 
> Denis
> 
> >
> >
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[e-mail]]
> >>Sent: den 15 oktober 2004 17:30
> >>To: Stefan Santesson
> >>Cc: Santosh Chokhani; pkix
> >>Subject: Re: Signer certificate discovery for CRLs
> >>
> >>Stefan,
> >>
> >>
> >>>Denis,
> >>
> >>>Unfortunately I fail to understand your questions, issues and
> >>
> > requests.
> >
> >>The sentence below demonstrates that you understand the issue.
> >>
> >>
> >>>It would be very useful if you could explain how current mechanisms
> >>
> > can
> >
> >>>be used in a simple and straightforward manner to discover CRL
> >>
> > signer
> >
> >>>certificates in ALL the use cases discussed, mainly re-keyed CA and 
> >>>indirect CRLs.
> >>
> >>You are also reversing the question. Using your terms, my question
> >
> > would
> >
> >>be:
> >>
> >>"It would be very useful if you could explain how current mechanisms 
> >>CANNOT be used in a simple and straightforward manner to discover 
> >>CRL
signer
> >>certificates in ONE or MORE the use cases discussed, mainly re-keyed
> >
> > CA
> >
> >>and
> >>indirect CRLs."
> >>
> >>Denis
> >>
> >>
> >>>Stefan Santesson
> >>>Microsoft Security Center of Excellence (SCOE)
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: [e-mail]
> >>>
> >>>[mailto:[e-mail]]
> >>>
> >>>
> >>>>On Behalf Of Denis Pinkas
> >>>>Sent: den 14 oktober 2004 17:13
> >>>>To: Santosh Chokhani
> >>>>Cc: 'pkix'
> >>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>
> >>>>
> >>>>Santosh,
> >>>>
> >>>>
> >>>>
> >>>>>Denis:
> >>>>
> >>>>>With the three assumptions/constraints I provided, how would you
> >>>>
> >>>locate
> >>>
> >>>
> >>>>the
> >>>>
> >>>>
> >>>>>CRL issuer certificate for the two examples using 3280 extensions
> >>>>
> >>>and
> >>>
> >>>
> >>>>>without putting AIA in the CRL?
> >>>>
> >>>>As far as I understand, the three assumptions are:
> >>>>
> >>>>1.  You are directory challenged; and
> >>>>    [I do not understand what this means]
> >>>>2.  You use AIA to develop the path; and
> >>>>    [It does not matter]
> >>>>3.  You develop the path from the end entity to trust anchor
> >>>>    [Could also be the contrary].
> >>>>
> >>>>If this is not correct, thus please correct.
> >>>>
> >>>>Then my request is: "using ANY OF the current extensions that are
> >>>
> >>>defined
> >>>
> >>>
> >>>>in
> >>>>RFC 3280", which includes SIA.
> >>>>
> >>>>In your explanations  you said :
> >>>>"if you do no deal with SIA et. al"
> >>>>
> >>>>This last assumption is neither part of the three assumptions and
> >>>
> > does
> >
> >>>not
> >>>
> >>>
> >>>>conform to my request.
> >>>>
> >>>>Denis
> >>>>
> >>>>
> >>>>
> >>>>>That is my point.
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: Denis Pinkas [mailto:[e-mail]]
> >>>>>Sent: Thursday, October 14, 2004 6:22 AM
> >>>>>To: Santosh Chokhani
> >>>>>Cc: 'pkix'
> >>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>
> >>>>>
> >>>>>Santosh,
> >>>>>
> >>>>>You misread my request. I said:
> >>>>>
> >>>>>"For the time being, I would like that you provide an example
> >>>>
> > where,
> >
> >>>>when
> >>>>
> >>>>
> >>>>>using the current extensions that are defined in RFC 3280, it
will
> >>>>
> >>>NOT
> >>>
> >>>
> >>>>be
> >>>>
> >>>>
> >>>>>possible to locate a CRL Issuer certificate."
> >>>>>
> >>>>>Maybe I would have needed to be clearer and say :
> >>>>>
> >>>>>"For the time being, I would like that you provide an example
> >>>>
> > where,
> >
> >>>>when
> >>>>
> >>>>
> >>>>>using ANY OF the current extensions that are defined in RFC 3280,
> >>>>
> > it
> >
> >>>>will
> >>>>
> >>>>
> >>>>>NOT be possible to locate a CRL Issuer certificate."
> >>>>>
> >>>>>The examples you provide below do not fulfil this request.
> >>>>>
> >>>>>The assumption is that there exists a path to be tested for
> >>>>
> >>>revocation
> >>>
> >>>
> >>>>>checking (and that it does not matter to know which way it has
been
> >>>>>constructed).
> >>>>>
> >>>>>I am not saying that using AIA in CRL might not be useful, but I
am
> >>>>
> >>>>still
> >>>>
> >>>>
> >>>>>lacking the demonstration that there would be no other way.
> >>>>>
> >>>>>Denis
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Denis:
> >>>>>>
> >>>>>>Two examples are very simple: one for direct CRL Issuer and one
> >>>>>
> > for
> >
> >>>>>>Indirect CRL Issuer.
> >>>>>>
> >>>>>>Let us make the following assumptions that Stefan was making:
> >>>>>>
> >>>>>>1.  You are directory challenged; and
> >>>>>>2.  You use AIA to develop the path; and
> >>>>>>3.  You develop the path from the end entity to trust anchor.
> >>>>>>
> >>>>>
> >>>>>>From what I know of MS CAPI, these are reasonable
> >>>>>
> >>>>>
> >>>>>>assumptions/constraints.
> >>>>>>
> >>>>>>Now the examples.
> >>>>>>
> >>>>>>Example 1: Direct CRL Issuer
> >>>>>>
> >>>>>>The certificate trust path is:
> >>>>>>Root --> CA1 --> CA 2, old key --> Denis
> >>>>>>
> >>>>>>The CRL trust path is:
> >>>>>>Root --> CA1 --> CA 2, new key --> CRL
> >>>>>>
> >>>>>>(Note: We do not do self-issued certificate since there is no
> >>>>>
> >>>simple,
> >>>
> >>>
> >>>>>>secure way to check their revocation status).
> >>>>>>
> >>>>>>Now, with AIA in CRL, finding the CA2, new key certificate is 
> >>>>>>straightforward.  How would you find it if you do no deal with
SIA
> >>>>>
> >>>et.
> >>>
> >>>
> >>>>>>al.
> >>>>>>
> >>>>>>Example 2: Indirect CRL Issuer
> >>>>>>
> >>>>>>The certificate trust path is:
> >>>>>>Root --> CA1 --> CA 2 --> Denis
> >>>>>>(Note: Denis's certificate points to CRL DP of an indirect CRL
> >>>>>
> >>>issued
> >>>
> >>>
> >>>>>>by CAI.
> >>>>>>
> >>>>>>The CRL trust path is:
> >>>>>>Root --> CAI --> CRL
> >>>>>>
> >>>>>>Now, with AIA in CRL, finding the CAI certificate is
> >>>>>
> >>>straightforward.
> >>>
> >>>
> >>>>>>How would you find it if you do no deal with SIA et. al.
> >>>>>>
> >>>>>>In addition to the need cited above, please note that the
> >>>>>
> > extension
> >
> >>>>>>semantics does not change, it does not hinder any
> >>>>>
> > interoperability,
> >
> >>>>>>and it does not break any backward compatibility.  So, what if I 
> >>>>>>wanted to use this extension in the CRL.  It does no harm to
other
> >>>>>>relying parties.
> >>>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: [e-mail] 
> >>>>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
> >>>>>>Sent: Wednesday, October 13, 2004 11:01 AM
> >>>>>>To: Stefan Santesson
> >>>>>>Cc: Santosh Chokhani; pkix
> >>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Stefan,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Denis,
> >>>>>>
> >>>>>>
> >>>>>>>I'm not sure what you mean.
> >>>>>>
> >>>>>>
> >>>>>>For the time being, I would like that you provide an example
> >>>>>
> > where,
> >
> >>>>>>when
> >>>>>>using the current extensions that are defined in RFC 3280, it
will
> >>>>>
> >>>NOT
> >>>
> >>>
> >>>>be
> >>>>
> >>>>
> >>>>>>possible to locate a CRL Issuer certificate.
> >>>>>>
> >>>>>>If you are able to provide that example, then it would justify
the
> >>>>>>need for
> >>>>>>an extension at least for one case. Then we can see what that
case
> >>>>>
> >>>is.
> >>>
> >>>
> >>>>>>I am awaiting that example.
> >>>>>>
> >>>>>>Denis
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>I conclude that I agree with Santosh.
> >>>>>>>
> >>>>>>>The debate is still open... Feel free to express your opinion.
> >>>>>>>
> >>>>>>>Stefan Santesson
> >>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: Denis Pinkas [mailto:[e-mail]]
> >>>>>>>>Sent: den 13 oktober 2004 16:34
> >>>>>>>>To: Stefan Santesson
> >>>>>>>>Cc: Santosh Chokhani; pkix
> >>>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>>
> >>>>>>>>Stefan,
> >>>>>>>>
> >>>>>>>>You are making a conclusion without letting me the time to
> >>>>>>>
> >>>respond. I
> >>>
> >>>
> >>>>>>>>will need more time to look at the pictures (and understand
> >>>>>>>
> > them).
> >
> >>>>>>>>For the time being, I am still reluctant to accept
> >>>>>>>
> >>>>>>>"yet-another-method".
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>We already have too many.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>Santosh,
> >>>>>>>>>
> >>>>>>>>>I conclude that we are in complete and total agreement. The 
> >>>>>>>>>question is how to go about this.
> >>>>>>>>
> >>>>>>>>>Could we do this amendment to RFC 3280 in its next revision?
It
> >>>>>>>>>would hopefully just be a minor change.
> >>>>>>>>
> >>>>>>>>This is exactly what I feared.
> >>>>>>>>
> >>>>>>>>We usually end-up with a "minor change" in an extension
without
> >>>>>>>>saying cleary how and when it shall/should be used.
> >>>>>>>>
> >>>>>>>>I still have in mind that:
> >>>>>>>>
> >>>>>>>>1) a certification path must first be constructed,
> >>>>>>>>2) then the revocation checking of that path must be done.
> >>>>>>>>
> >>>>>>>>This means that information about CRL issuers certificates
> >>>>>>>
> >>>locations
> >>>
> >>>
> >>>>>>>may
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>certainly be found in that chain. If not, I would like an
> >>>>>>>
> > example.
> >
> >>>>>>>>Denis
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>It would not change the definition of AIA just add that it
can
> >>>>>>>>
> > be
> >
> >>>>>>>used
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>also as CRL extension and list eventual restrictions and
> >>>>>>>
> > guidance
> >
> >>>for
> >>>
> >>>
> >>>>>>>use
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>with CRLs.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>Stefan Santesson
> >>>>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>-----Original Message-----
> >>>>>>>>>>From: [e-mail]
> >>>>>>>>>
> >>>>>>>[mailto:[e-mail]]
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>On Behalf Of Santosh Chokhani
> >>>>>>>>>>Sent: den 13 oktober 2004 04:33
> >>>>>>>>>>To: 'pkix'
> >>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>Stefan:
> >>>>>>>>>>
> >>>>>>>>>>In terms of certificate discovery, your proposal for AIA in
> >>>>>>>>>
> > CRL
> >
> >>>is
> >>>
> >>>
> >>>>>>>more
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>robust.  The whole idea of self-issued key rollover
> >>>>>>>>>
> > certificates
> >
> >>>>>>>>>>and
> >>>>>>>>>
> >>>>>>>>then
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>using the new key to issue CRL is fraught with security
> >>>>>>>>>
> >>>problems.
> >>>
> >>>
> >>>>>>>>>>A secure solution would be one where the new key is
certified
> >>>>>>>>>
> > by
> >
> >>>>>>>>>>the parent
> >>>>>>>>>
> >>>>>>>CA.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>In
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>that case to obtain the new certificate, you could use AIA
in
> >>>>>>>>>
> >>>CRL.
> >>>
> >>>
> >>>>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP
> >>>>>>>>>
> > in
> >
> >>>>>>>>>>certificate in question points to the indirect CRL.  You get
> >>>>>>>>>
> >>>that
> >>>
> >>>
> >>>>>>>>>>CRL.  The AIA
> >>>>>>>>>
> >>>>>>>in
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>CRL
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>gets you started for the indirect CRL issuer certification
> >>>>>>>>>
> > path
> >
> >>>and
> >>>
> >>>
> >>>>>>>you
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>are
> >>>>>>>>>>in business.
> >>>>>>>>>>
> >>>>>>>>>>-----Original Message-----
> >>>>>>>>>>From: [e-mail]
> >>>>>>>>>
> >>>>>>>[mailto:[e-mail]]
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>On
> >>>>>>>>>>Behalf Of Stefan Santesson
> >>>>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
> >>>>>>>>>>To: David A. Cooper
> >>>>>>>>>>Cc: pkix
> >>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>David,
> >>>>>>>>>>
> >>>>>>>>>>Thanks for the clarifications, they make sense.
> >>>>>>>>>>I did misread your pictures.
> >>>>>>>>>>
> >>>>>>>>>>So can we conclude that for a re-keyed CA in accordance with
> >>>>>>>>>
> > RFC
> >
> >>>>>>>3280,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>either the CRL issuer certificate itself, or the location of
> >>>>>>>>>
> > the
> >
> >>>>>>>>>>CRL issuer certificate, will be clearly identified/available
> >>>>>>>>>
> > for
> >
> >>>>>>>>>>the validating
> >>>>>>>>>
> >>>>>>>>party
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>in some cases, but not in others?
> >>>>>>>>>>
> >>>>>>>>>>Can we also conclude that there is no real discovery
solution
> >>>>>>>>>
> >>>for
> >>>
> >>>
> >>>>>>>>indirect
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>CRLs?
> >>>>>>>>>>
> >>>>>>>>>>Do you then agree then that it could be appropriate to allow
> >>>>>>>>>
> > AIA
> >
> >>>as
> >>>
> >>>
> >>>>>>>a
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>CRL
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>extension to facilitate discovery of CRL signer certificate?
> >>>>>>>>>>
> >>>>>>>>>>Stefan Santesson
> >>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>>>>
> >>>>>>>>>>________________________________________
> >>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
> >>>>>>>>>>Sent: den 12 oktober 2004 21:14
> >>>>>>>>>>To: Stefan Santesson
> >>>>>>>>>>Cc: pkix
> >>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>>>>
> >>>>>>>>>>Stefan,
> >>>>>>>>>>
> >>>>>>>>>>I believe that you are misinterpreting the figures.  They
> >>>>>>>>>
> > really
> >
> >>>do
> >>>
> >>>
> >>>>>>>>>>represent three different cases, not three different
> >>>>>>>>>
> >>>certification
> >>>
> >>>
> >>>>>>>paths
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>that have been constructed through the same PKI
architecture.
> >>>>>>>>>>
> >>>>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
> >>>>>>>>>
> >>>>>>>certificates.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>The
> >>>>>>>>>>Root CA has issued a certificate to CA 1's new key, but not
> >>>>>>>>>
> > its
> >
> >>>old
> >>>
> >>>
> >>>>>>>key
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>(either the Root CA never issued a certificate to CA 1's old
> >>>>>>>>>
> > key
> >
> >>>or
> >>>
> >>>
> >>>>>>>that
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certificate has expired).
> >>>>>>>>>>
> >>>>>>>>>>In figure 2, CA 2 has also generated self-issued key
rollover
> >>>>>>>>>>certificates. The Root CA has issued a certificate to CA 2's
> >>>>>>>>>
> > old
> >
> >>>>>>>>>>key, but not its
> >>>>>>>>>
> >>>>>>>new
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>key.
> >>>>>>>>>>
> >>>>>>>>>>In figure 3, when CA 3 performed key rollover, it requested
a
> >>>>>>>>>
> >>>new
> >>>
> >>>
> >>>>>>>>>>CA certificate from the Root CA.  CA 3 did not generated 
> >>>>>>>>>>self-issued
> >>>>>>>>>
> >>>>>>>key
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>rollover certificates.
> >>>>>>>>>>
> >>>>>>>>>>Of course, another realistic scenario would be one in which
a
> >>>>>>>>>
> > CA
> >
> >>>>>>>>generated
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>self-issued key rollover certificates upon key rollover and
> >>>>>>>>>
> > then
> >
> >>>>>>>>>>had
> >>>>>>>>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>Root CA issue a CA certificate to its new key.  In this
case,
> >>>>>>>>>
> > as
> >
> >>>>>>>>>>you suggest, any of the certification paths from figures 1,
2,
> >>>>>>>>>
> >>>or 3
> >>>
> >>>
> >>>>>>>could be
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>constructed.
> >>>>>>>>>>
> >>>>>>>>>>As for the contents of the AIA extension, here is what I
have
> >>>>>>>>>
> >>>>>>>specified
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>in
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the
> >>>>>>>>>
> > Common
> >
> >>>>>>>>Policy":
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>The authorityInfoAccess extension uses URIs for two
purposes.
> >>>>>>>>>
> >>>When
> >>>
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>id-ad-caIssuers access method is used, the access location 
> >>>>>>>>>>specifies
> >>>>>>>>>
> >>>>>>>>where
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>certificates issued to the issuer of the certificate may be
> >>>>>>>>>
> >>>found.
> >>>
> >>>
> >>>>>>>If
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>LDAP
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>is used, the URI must include the DN of the entry containing
> >>>>>>>>>
> > the
> >
> >>>>>>>>relevant
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>certificates and specify the directory attribute in which
the
> >>>>>>>>>
> >>>>>>>>certificates
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>are located. If the directory in which the certificates are
> >>>>>>>>>
> >>>stored
> >>>
> >>>
> >>>>>>>>expects
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>the "binary" option to be specified, then the attribute type
> >>>>>>>>>
> >>>must
> >>>
> >>>
> >>>>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the
URI
> >>>>>>>>>
> >>>must
> >>>
> >>>
> >>>>>>>point to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>a
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>file that has an extension of ".p7c" that contains a
> >>>>>>>>>
> > certs-only
> >
> >>>CMS
> >>>
> >>>
> >>>>>>>>>>message (see RFC 2633). The CMS message should include all 
> >>>>>>>>>>certificates
> >>>>>>>>>
> >>>>>>>issued
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>to
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>the issuer of this certificate, but must at least contain
all
> >>>>>>>>>
> >>>>>>>>certificates
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>issued to the issuer of this certificate in which the
subject
> >>>>>>>>>>public
> >>>>>>>>>
> >>>>>>>key
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>may
> >>>>>>>>>>be used to verify the signature on this certificate. ....
For
> >>>>>>>>>
> > a
> >
> >>>>>>>>>>certificate issued by "Good CA", some examples of URIs that
> >>>>>>>>>
> > may
> >
> >>>>>>>>>>appear as the
> >>>>>>>>>
> >>>>>>>access
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>location in an authorityInfoAccess extension when the
> >>>>>>>>>
> >>>>>>>id-ad-caIssuers
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>access
> >>>>>>>>>>method is used are:
> >>>>>>>>>
>
>>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cA
C
> >>>>>>
> > e
> >
> >>>r
> >>>
> >>>
> >>>>>>>>>t
> >>>>>>>>>i
> >>>>>>>>
> >>>>>>>fi
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>ca
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>te
> >>>>>>>>>>,crossCertificatePair
> >>>>>>>>>
>
>>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACert
i
> >>>>>>
> > f
> >
> >>>i
> >>>
> >>>
> >>>>>>>>>c
> >>>>>>>>>a
> >>>>>>>>
> >>>>>>>te
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>;b
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>in
> >>>>>>>>>>ary,crossCertificatePair;binary
> >>>>>>>>>
>
>>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsI
s
> >>>>>>
> > s
> >
> >>>u
> >>>
> >>>
> >>>>>>>>>e
> >>>>>>>>>d
> >>>>>>>>
> >>>>>>>To
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Go
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>od
> >>>>>>>>>>CA.p7c
> >>>>>>>>>>For both LDAP and HTTP, the URI provides the exact location
> >>>>>>>>>
> >>>where
> >>>
> >>>
> >>>>>>>>>>information is to be located, so there is no requirement for
> >>>>>>>>>
> > the
> >
> >>>>>>>relying
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>party to try to figure out where information is located.
> >>>>>>>>>>
> >>>>>>>>>>The HTTP URI points to a certs-only CMS message that
includes
> >>>>>>>>>
> >>>all
> >>>
> >>>
> >>>>>>>>>>certificates issued to the CA identified in the issuer field
> >>>>>>>>>
> > of
> >
> >>>the
> >>>
> >>>
> >>>>>>>>>>certificate.
> >>>>>>>>>>
> >>>>>>>>>>The LDAP URI points to the cACertificate and
> >>>>>>>>>
> >>>crossCertificatePair
> >>>
> >>>
> >>>>>>>>>>attributes of the directory entry of the CA identified in
the
> >>>>>>>>>>issuer field of
> >>>>>>>>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certificate.  These two attributes together hold all of the
> >>>>>>>>>
> >>>>>>>certificates
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>issued to the CA:  the cACertificate attribute holds the
CA's
> >>>>>>>>>
> >>>self-
> >>>
> >>>
> >>>>>>>>issued
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>certificates and the crossCertificatePair attribute holds
the
> >>>>>>>>>>cross-certificates issued to the CA by other CAs.
> >>>>>>>>>>
> >>>>>>>>>>Dave
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>Stefan Santesson wrote:
> >>>>>>>>>>
> >>>>>>>>>>David,
> >>>>>>>>>>
> >>>>>>>>>>Thanks for these good thoughts and very useful scenarios.
> >>>>>>>>>>
> >>>>>>>>>>I have some comments and questions on this.
> >>>>>>>>>>
> >>>>>>>>>>First of all we can conclude that in some scenarios (figure
1)
> >>>>>>>>>>where
> >>>>>>>>>
> >>>>>>>a
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>self
> >>>>>>>>>>issued certificate is inserted into the path, you are likely
> >>>>>>>>>
> > to
> >
> >>>>>>>>>>find
> >>>>>>>>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>CRL
> >>>>>>>>>>issuer cert in the path. (given that the new CA have a
common
> >>>>>>>>>
> >>>key
> >>>
> >>>
> >>>>>>>and
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certificate for cert signing and CRL signing).
> >>>>>>>>>>
> >>>>>>>>>>Figure 1, 2 and 3 describe the same case. It is just
> >>>>>>>>>
> > describing
> >
> >>>>>>>>different
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>path building strategies. An application that has access
> >>>>>>>>>
> > locally
> >
> >>>to
> >>>
> >>>
> >>>>>>>all
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>chaining options may however still choose path 2 for the
certs
> >>>>>>>>>
> >>>and
> >>>
> >>>
> >>>>>>>path
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>1
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>for the CRL independent of each other (which I think figure
3
> >>>>>>>>>
> >>>tries
> >>>
> >>>
> >>>>>>>to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>describe)
> >>>>>>>>>>
> >>>>>>>>>>Another comment is the structure of AIA extensions. The use
> >>>>>>>>>
> > I'm
> >
> >>>>>>>familiar
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>with doesn't use AIA to describe a directory entry where it
is
> >>>>>>>>>
> >>>left
> >>>
> >>>
> >>>>>>>to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>validation application logic to be intelligent enough to
find
> >>>>>>>>>
> >>>>>>>>appropriate
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>certificate data from the directory. The model I'm familiar
> >>>>>>>>>
> > with
> >
> >>>is
> >>>
> >>>
> >>>>>>>when
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>AIA URL explicitly identifies the exact location of the
> >>>>>>>>>
> >>>appropriate
> >>>
> >>>
> >>>>>>>CA
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certificate file, relieving the validation software from
> >>>>>>>>>
> > complex
> >
> >>>>>>>>>>information queries. If just location of explicit
certificate
> >>>>>>>>>
> >>>files
> >>>
> >>>
> >>>>>>>>>>are
> >>>>>>>>>
> >>>>>>>identified
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>through AIA, the presence of an AIA may not help finding the
> >>>>>>>>>
> > CRL
> >
> >>>>>>>signer
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>cert
> >>>>>>>>>>if this is different from the CA certificate. This is also
the
> >>>>>>>>>
> >>>>>>>problem
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>with
> >>>>>>>>>>Denis proposal.
> >>>>>>>>>>
> >>>>>>>>>>I think we share the basic conclusion that the ability to
> >>>>>>>>>
> > locate
> >
> >>>>>>>>>>the
> >>>>>>>>>
> >>>>>>>CRL
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>signer certificate directly through the CRL could be very
> >>>>>>>>>
> >>>useful.
> >>>
> >>>
> >>>>>>>>>>At
> >>>>>>>>>
> >>>>>>>>least
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>in the case of indirect CRL but it could also be proven very
> >>>>>>>>>
> >>>useful
> >>>
> >>>
> >>>>>>>in
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>CA
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>re-keying scenarios.
> >>>>>>>>>>
> >>>>>>>>>>The easiest solution would probably be to allow AIA to be
used
> >>>>>>>>>
> >>>in
> >>>
> >>>
> >>>>>>>its
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>current shape and structure as a CRL extension (MUST NOT be
> >>>>>>>>>
> >>>>>>>critical).
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>It
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>would present a very clear and uncomplicated logic to
> >>>>>>>>>
> >>>certificate
> >>>
> >>>
> >>>>>>>>>>validating applications in many cases.
> >>>>>>>>>>
> >>>>>>>>>>Stefan Santesson
> >>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>>>>
> >>>>>>>>>>________________________________________
> >>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
> >>>>>>>>>>Sent: den 7 oktober 2004 18:35
> >>>>>>>>>>To: Stefan Santesson
> >>>>>>>>>>Cc: pkix
> >>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>>>>
> >>>>>>>>>>Stefan,
> >>>>>>>>>>
> >>>>>>>>>>I think what you are proposing is a good idea.  In most
cases,
> >>>>>>>>>
> >>>path
> >>>
> >>>
> >>>>>>>>>>discovery algorithms assume that both the trust anchor (or
> >>>>>>>>>
> > trust
> >
> >>>>>>>>anchors)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>and the end entity certificate are provided as input.  In
this
> >>>>>>>>>>case,
> >>>>>>>>>
> >>>>>>>one
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>may
> >>>>>>>>>>need to construct a certification path without a priori
access
> >>>>>>>>>
> >>>to
> >>>
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>end
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>entity certificate (the one with the subject public key
> >>>>>>>>>
> >>>>>>>corresponding to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>CRL signing key).  Including an AIA extension (or some other
> >>>>>>>>>
> >>>>>>>pointer) in
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>CRL would provide the relying party with a simple way to
> >>>>>>>>>
> > obtain
> >
> >>>the
> >>>
> >>>
> >>>>>>>end
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>entity certificate for the CRL signing key's certification
> >>>>>>>>>
> > path.
> >
> >>>On
> >>>
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>other hand, I believe that a relying party should be able to
> >>>>>>>>>
> >>>>>>>construct
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>certification path even without an AIA extension in the CRL,
> >>>>>>>>>
> > so
> >
> >>>>>>>>>>long
> >>>>>>>>>
> >>>>>>>as
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>it
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>is not an indirect CRL.  Attached is a drawing of the three
> >>>>>>>>>
> >>>basic
> >>>
> >>>
> >>>>>>>>>>scenarios that I expect a relying party may encounter:
> >>>>>>>>>>
> >>>>>>>>>>In each of these scenarios, the CA has performed key
rollover
> >>>>>>>>>
> >>>and
> >>>
> >>>
> >>>>>>>>>>is
> >>>>>>>>>
> >>>>>>>>only
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>signing CRLs with its new key.  The diagrams would look
> >>>>>>>>>
> > similar,
> >
> >>>>>>>>however,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>if
> >>>>>>>>>>the CA simply choose to use different keys to sign
> >>>>>>>>>
> > certificates
> >
> >>>and
> >>>
> >>>
> >>>>>>>CRLs
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>for
> >>>>>>>>>>some other reason.
> >>>>>>>>>>
> >>>>>>>>>>If the PKI architecture resembled figure 1, then the
> >>>>>>>>>
> >>>certification
> >>>
> >>>
> >>>>>>>path
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>for
> >>>>>>>>>>the CRL signing key would just be a subset of the
> >>>>>>>>>
> > certification
> >
> >>>>>>>>>>path
> >>>>>>>>>
> >>>>>>>for
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>EE certificate, so no addition path discovery would be
needed.
> >>>>>>>>>>
> >>>>>>>>>>If the PKI architecture resembled figure 1, then it would be
> >>>>>>>>>
> >>>>>>>necessary
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>to
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>obtain the new-signed-with-old self-issued certificate.  In 
> >>>>>>>>>>building
> >>>>>>>>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certification path to the EE certificate, however, the
relying
> >>>>>>>>>>party
> >>>>>>>>>
> >>>>>>>>will
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>obtain the certificates pointed to by the AIA extension in
the
> >>>>>>>>>
> >>>EE
> >>>
> >>>
> >>>>>>>>>>certificate.  This AIA extension will point to a location 
> >>>>>>>>>>containing
> >>>>>>>>>
> >>>>>>>all
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certificates issued to CA 2, which would include both the
> >>>>>>>>>
> >>>>>>>certificate
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>issued
> >>>>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So,
> >>>>>>>>>
> >>>even
> >>>
> >>>
> >>>>>>>though
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>self-issued certificate would not be part of the
certification
> >>>>>>>>>
> >>>path
> >>>
> >>>
> >>>>>>>to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>EE certificate, it would be downloaded by the relying party
> >>>>>>>>>
> >>>during
> >>>
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>construction of that certification path.  (Yes, there are
> >>>>>>>>>
> >>>circular
> >>>
> >>>
> >>>>>>>>>>dependency issues in figure 2, but that is another issue.)
> >>>>>>>>>>
> >>>>>>>>>>A similar situation would happen if the PKI architecture
> >>>>>>>>>
> >>>resembled
> >>>
> >>>
> >>>>>>>>figure
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>3.  The AIA extension in the EE certificate would point to a
> >>>>>>>>>
> >>>>>>>location
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>containing certificates issued to CA 3.  When the relying
> >>>>>>>>>
> > party
> >
> >>>>>>>>downloaded
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>these certificates, it would obtain both of the certificates
> >>>>>>>>>
> >>>issued
> >>>
> >>>
> >>>>>>>by
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>Root to CA 3 and so again would have the certificate needed
to
> >>>>>>>>>
> >>>>>>>validate
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>CRL signing key.
> >>>>>>>>>>
> >>>>>>>>>>In the case of an indirect CRL, things may not work as well.
> >>>>>>>>>
> > If
> >
> >>>>>>>>indirect
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>CRLs were used, and the PKI architecture resembled figures 2
> >>>>>>>>>
> > or
> >
> >>>3
> >>>
> >>>
> >>>>>>>>>>(replacing "New Key" with a different CA), then the set of 
> >>>>>>>>>>certificates pointed
> >>>>>>>>>
> >>>>>>>to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>by
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>the AIA extension in the EE certificate would not include
the
> >>>>>>>>>
> >>>>>>>>certificate
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>of
> >>>>>>>>>>the CRL signer.  One could find this certificate by building
> >>>>>>>>>
> > in
> >
> >>>the
> >>>
> >>>
> >>>>>>>>>>reverse direction and using the SIA extension, but that may
> >>>>>>>>>
> > not
> >
> >>>be
> >>>
> >>>
> >>>>>>>>>>the most convenient solution.
> >>>>>>>>>>
> >>>>>>>>>>So, when indirect CRLs are being used, it seems that it
would
> >>>>>>>>>
> > be
> >
> >>>>>>>very
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>useful
> >>>>>>>>>>to have a pointer in the CRL to the CRL signing certificate.
> >>>>>>>>>
> >>>When
> >>>
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>CRL
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>is not indirect, the need for this pointer does not seem to
be
> >>>>>>>>>
> >>>as
> >>>
> >>>
> >>>>>>>clear,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>but
> >>>>>>>>>>I can't see any harm in including it.
> >>>>>>>>>>
> >>>>>>>>>>Dave
> >>>>>>>>>>
> >>>>>>>>>>Stefan Santesson wrote:
> >>>>>>>>>>All,
> >>>>>>>>>>
> >>>>>>>>>>I'm interested in the opinion from members on this list
about
> >>>>>>>>>
> >>>>>>>discovery
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>of
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>CRL signer's certificate in non directory centric
> >>>>>>>>>
> > environments.
> >
> >>>>>>>>>>The problem is the following.
> >>>>>>>>>>
> >>>>>>>>>>The relying party (RP) needs to check validity of a
> >>>>>>>>>
> > certificate
> >
> >>>and
> >>>
> >>>
> >>>>>>>>finds
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>a
> >>>>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this
CRL
> >>>>>>>>>>which
> >>>>>>>>>
> >>>>>>>in
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>this
> >>>>>>>>>>particular case is either signed by another key of the CA
> >>>>>>>>>
> >>>(re-keyed
> >>>
> >>>
> >>>>>>>CA)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>or
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>another entity (indirect CRL).
> >>>>>>>>>>
> >>>>>>>>>>In this case the relying party needs to obtain the
certificate
> >>>>>>>>>
> >>>of
> >>>
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>CRL
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>signer which may NOT be part of the original chain. In a
> >>>>>>>>>
> >>>directory
> >>>
> >>>
> >>>>>>>>centric
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>solution this is retrieved from the directory, but what if
> >>>>>>>>>
> > such
> >
> >>>>>>>>directory
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>is
> >>>>>>>>>>not available or accessible.
> >>>>>>>>>>
> >>>>>>>>>>The RP have thus no hint where to find the CRL issuers
> >>>>>>>>>
> >>>certificate
> >>>
> >>>
> >>>>>>>>unless
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>the RP already have possession of it by some other means.
> >>>>>>>>>>
> >>>>>>>>>>Is seems that CRLs would need an AIA extension with the
option
> >>>>>>>>>
> >>>to
> >>>
> >>>
> >>>>>>>point
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>to
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>the location of the signers certificate in the same manner
as
> >>>>>>>>>
> > is
> >
> >>>>>>>>possible
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>for certificates.
> >>>>>>>>>>
> >>>>>>>>>>Maybe AIA should be defined as both cert and CRL extension
and
> >>>>>>>>>
> >>>not
> >>>
> >>>
> >>>>>>>only
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certificate extension as today.
> >>>>>>>>>>
> >>>>>>>>>>Thoughts and comments?
> >>>>>>>>>>
> >>>>>>>>>>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 i9ICJhZU005629; Mon, 18 Oct 2004 05:19:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ICJhHb005628; Mon, 18 Oct 2004 05:19:43 -0700 (PDT)
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 i9ICJfRS005601 for <[e-mail]>; Mon, 18 Oct 2004 05:19:42 -0700 (PDT) (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.0); Mon, 18 Oct 2004 13:19:30 +0100
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: Signer certificate discovery for CRLs
Date: Mon, 18 Oct 2004 13:19:27 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcS0/XTojw2qZj1iSPaZLFj2w1ClggAC99eQ
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Santosh Chokhani" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 18 Oct 2004 12:19:30.0074 (UTC) FILETIME=[B7C73FA0:01C4B50C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9ICJhRS005620
Sender: [e-mail]
Precedence: 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 Denis,

I now finally understand your SIA alternative.

There are some major problems with it though.

1) How can the RP know what certificate's SIA it would use to find the
CRL signer cert?

You just picked the right certificate in my example since I gave that
information in the example. But the RP don't know that path, it only
knows the path of the EE cert and the name of the CRL issuer!

2) And even if RP knew the path beforehand, finding THE one CRL signer
certificate from a CRL AIA is much more direct and efficient than
finding among all issued certificates from a CA the 1 out of x issued
certificates that is the CRL Issuer cert.

3) Using SIA in the examples requires available directories and
directory enabled clients. How do you solve the problem if either of
these is not available?


Do you seriously suggest that use of SIA is a better and more effective
way to address this problem or are you just pointing out the fact that
there are SOME cases where use of SIA may work in theory?


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 18 oktober 2004 12:28
> To: Stefan Santesson
> Cc: Santosh Chokhani; pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> > Denis,
> 
> > If I get you right you mean that one can always successfully use AIA
and
> > SIA in certs to solve discovery of CRL signer cert.
> > Others on this list (me included) don't understand how. It would
> > therefore be useful if you told us.
> >
> > I'll try to explain the problem from my perspective one more time.
> 
> Thanks.
> 
> > Note: "->" in these examples means "issued by"
> 
> Fine.
> 
> > Case 1 - indirect CRL:
> >
> > Cert path is:  EE_Cert -> CA_1 -> Root-CA
> > CRL path for EE_Cert is:  CRL -> CRL_Issuer_B -> Root-CA
> 
> This means Root-CA has nominated CA_1 and a CRL_Issuer_B and that CA_1
has
> chosen to use CRL_Issuer_B for revocation checking for some
certificates.
> 
> > Scenario:
> > Relying party has access to the cert path, discovers the CRL through
CDP
> > in EE_Cert.
> 
> If there is no attack on the objects stored at the CRL DP, the CRL
Issuer
> from that CRL is CRL_Issuer_B. Now the relying party needs to get the
> certificate isued by Root-CA for CRL_Issuer_B. If Root-CA has included
a
> SIA
> extension in his self-signed certificate, then using that extension
allows
> to get the CRL_Issuer_B certificate issued by the Root-CA.
> 
>  > The RP searches the location specified in SIA through
> > id-ad-caRepository in the CA_1 cert but finds nothing useful since
> > revocation is subordinated to another entity (CRL_Issuer_B)
> 
> Correct, but looking in Root-CA allows to find something useful, if
the
> self-signed certificate includes a SIA extension.
> 
> > In this case, the problem could be solved if an AIA in the CRL
indicated
> > the access location of the CRL Issuer cert.
> 
> This would be an *alternative* way.
> 
> > Case 2 - re-keyed CA.
> >
> > Cert path is:  EE_Cert -> CA_1(old key) -> Root-CA
> > CRL path for EE_Cert is:  CRL -> CA_1(new key) -> Root-CA
> 
> This means that the EE_Cert chain has been created with CA_1(old key)
and
> that the CRL issuer that was originaly used when the EE_Cert was
created
> has
> been changed and a new CRL Issuer got a certificate under CA_1(new
key)
> and
> is now the legitimate CRL issuer for the CRL DP originally mentionned
in
> the
> EE_Cert.
> 
> > The 2 CA_1 certificates above (old key and new key) are issued to
> > different subject keys belonging to the same CA (same name).
> > The cert CA_1(old key) was issued before creation of cert CA_1(new
key)
> > and have thus no reference to CA_1(new key) in its SIA
> >
> > Scenario:
> > RP discovers the CRL for the EE_Cert through the CDP but doesn't
possess
> > the CRL issuer cert. The RP client searches the SIA of the CA_1(old
key)
> > but finds no direct reference to the CRL signer cert. Since the RP
> > client has no access to a directory where the CRL signer cert could
be
> > found through directory lookup, cert validation fails.
> 
> Correct, but looking in Root-CA allows to find something useful, if
the
> self-signed certificate includes a SIA extension.
> 
> > In this scenario the problem could be solved through an AIA in the
CRL.
> 
> This would be an *alternative* way.
> 
> Denis
> 
> >
> >
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[e-mail]]
> >>Sent: den 15 oktober 2004 17:30
> >>To: Stefan Santesson
> >>Cc: Santosh Chokhani; pkix
> >>Subject: Re: Signer certificate discovery for CRLs
> >>
> >>Stefan,
> >>
> >>
> >>>Denis,
> >>
> >>>Unfortunately I fail to understand your questions, issues and
> >>
> > requests.
> >
> >>The sentence below demonstrates that you understand the issue.
> >>
> >>
> >>>It would be very useful if you could explain how current mechanisms
> >>
> > can
> >
> >>>be used in a simple and straightforward manner to discover CRL
> >>
> > signer
> >
> >>>certificates in ALL the use cases discussed, mainly re-keyed CA and
> >>>indirect CRLs.
> >>
> >>You are also reversing the question. Using your terms, my question
> >
> > would
> >
> >>be:
> >>
> >>"It would be very useful if you could explain how current mechanisms
> >>CANNOT
> >>be used in a simple and straightforward manner to discover CRL
signer
> >>certificates in ONE or MORE the use cases discussed, mainly re-keyed
> >
> > CA
> >
> >>and
> >>indirect CRLs."
> >>
> >>Denis
> >>
> >>
> >>>Stefan Santesson
> >>>Microsoft Security Center of Excellence (SCOE)
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: [e-mail]
> >>>
> >>>[mailto:[e-mail]]
> >>>
> >>>
> >>>>On Behalf Of Denis Pinkas
> >>>>Sent: den 14 oktober 2004 17:13
> >>>>To: Santosh Chokhani
> >>>>Cc: 'pkix'
> >>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>
> >>>>
> >>>>Santosh,
> >>>>
> >>>>
> >>>>
> >>>>>Denis:
> >>>>
> >>>>>With the three assumptions/constraints I provided, how would you
> >>>>
> >>>locate
> >>>
> >>>
> >>>>the
> >>>>
> >>>>
> >>>>>CRL issuer certificate for the two examples using 3280 extensions
> >>>>
> >>>and
> >>>
> >>>
> >>>>>without putting AIA in the CRL?
> >>>>
> >>>>As far as I understand, the three assumptions are:
> >>>>
> >>>>1.  You are directory challenged; and
> >>>>    [I do not understand what this means]
> >>>>2.  You use AIA to develop the path; and
> >>>>    [It does not matter]
> >>>>3.  You develop the path from the end entity to trust anchor
> >>>>    [Could also be the contrary].
> >>>>
> >>>>If this is not correct, thus please correct.
> >>>>
> >>>>Then my request is: "using ANY OF the current extensions that are
> >>>
> >>>defined
> >>>
> >>>
> >>>>in
> >>>>RFC 3280", which includes SIA.
> >>>>
> >>>>In your explanations  you said :
> >>>>"if you do no deal with SIA et. al"
> >>>>
> >>>>This last assumption is neither part of the three assumptions and
> >>>
> > does
> >
> >>>not
> >>>
> >>>
> >>>>conform to my request.
> >>>>
> >>>>Denis
> >>>>
> >>>>
> >>>>
> >>>>>That is my point.
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: Denis Pinkas [mailto:[e-mail]]
> >>>>>Sent: Thursday, October 14, 2004 6:22 AM
> >>>>>To: Santosh Chokhani
> >>>>>Cc: 'pkix'
> >>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>
> >>>>>
> >>>>>Santosh,
> >>>>>
> >>>>>You misread my request. I said:
> >>>>>
> >>>>>"For the time being, I would like that you provide an example
> >>>>
> > where,
> >
> >>>>when
> >>>>
> >>>>
> >>>>>using the current extensions that are defined in RFC 3280, it
will
> >>>>
> >>>NOT
> >>>
> >>>
> >>>>be
> >>>>
> >>>>
> >>>>>possible to locate a CRL Issuer certificate."
> >>>>>
> >>>>>Maybe I would have needed to be clearer and say :
> >>>>>
> >>>>>"For the time being, I would like that you provide an example
> >>>>
> > where,
> >
> >>>>when
> >>>>
> >>>>
> >>>>>using ANY OF the current extensions that are defined in RFC 3280,
> >>>>
> > it
> >
> >>>>will
> >>>>
> >>>>
> >>>>>NOT be possible to locate a CRL Issuer certificate."
> >>>>>
> >>>>>The examples you provide below do not fulfil this request.
> >>>>>
> >>>>>The assumption is that there exists a path to be tested for
> >>>>
> >>>revocation
> >>>
> >>>
> >>>>>checking (and that it does not matter to know which way it has
been
> >>>>>constructed).
> >>>>>
> >>>>>I am not saying that using AIA in CRL might not be useful, but I
am
> >>>>
> >>>>still
> >>>>
> >>>>
> >>>>>lacking the demonstration that there would be no other way.
> >>>>>
> >>>>>Denis
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Denis:
> >>>>>>
> >>>>>>Two examples are very simple: one for direct CRL Issuer and one
> >>>>>
> > for
> >
> >>>>>>Indirect CRL Issuer.
> >>>>>>
> >>>>>>Let us make the following assumptions that Stefan was making:
> >>>>>>
> >>>>>>1.  You are directory challenged; and
> >>>>>>2.  You use AIA to develop the path; and
> >>>>>>3.  You develop the path from the end entity to trust anchor.
> >>>>>>
> >>>>>
> >>>>>>From what I know of MS CAPI, these are reasonable
> >>>>>
> >>>>>
> >>>>>>assumptions/constraints.
> >>>>>>
> >>>>>>Now the examples.
> >>>>>>
> >>>>>>Example 1: Direct CRL Issuer
> >>>>>>
> >>>>>>The certificate trust path is:
> >>>>>>Root --> CA1 --> CA 2, old key --> Denis
> >>>>>>
> >>>>>>The CRL trust path is:
> >>>>>>Root --> CA1 --> CA 2, new key --> CRL
> >>>>>>
> >>>>>>(Note: We do not do self-issued certificate since there is no
> >>>>>
> >>>simple,
> >>>
> >>>
> >>>>>>secure way to check their revocation status).
> >>>>>>
> >>>>>>Now, with AIA in CRL, finding the CA2, new key certificate is
> >>>>>>straightforward.  How would you find it if you do no deal with
SIA
> >>>>>
> >>>et.
> >>>
> >>>
> >>>>>>al.
> >>>>>>
> >>>>>>Example 2: Indirect CRL Issuer
> >>>>>>
> >>>>>>The certificate trust path is:
> >>>>>>Root --> CA1 --> CA 2 --> Denis
> >>>>>>(Note: Denis's certificate points to CRL DP of an indirect CRL
> >>>>>
> >>>issued
> >>>
> >>>
> >>>>>>by CAI.
> >>>>>>
> >>>>>>The CRL trust path is:
> >>>>>>Root --> CAI --> CRL
> >>>>>>
> >>>>>>Now, with AIA in CRL, finding the CAI certificate is
> >>>>>
> >>>straightforward.
> >>>
> >>>
> >>>>>>How would you find it if you do no deal with SIA et. al.
> >>>>>>
> >>>>>>In addition to the need cited above, please note that the
> >>>>>
> > extension
> >
> >>>>>>semantics does not change, it does not hinder any
> >>>>>
> > interoperability,
> >
> >>>>>>and it does not break any backward compatibility.  So, what if I
> >>>>>>wanted to use this extension in the CRL.  It does no harm to
other
> >>>>>>relying parties.
> >>>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: [e-mail]
> >>>>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
> >>>>>>Sent: Wednesday, October 13, 2004 11:01 AM
> >>>>>>To: Stefan Santesson
> >>>>>>Cc: Santosh Chokhani; pkix
> >>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Stefan,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Denis,
> >>>>>>
> >>>>>>
> >>>>>>>I'm not sure what you mean.
> >>>>>>
> >>>>>>
> >>>>>>For the time being, I would like that you provide an example
> >>>>>
> > where,
> >
> >>>>>>when
> >>>>>>using the current extensions that are defined in RFC 3280, it
will
> >>>>>
> >>>NOT
> >>>
> >>>
> >>>>be
> >>>>
> >>>>
> >>>>>>possible to locate a CRL Issuer certificate.
> >>>>>>
> >>>>>>If you are able to provide that example, then it would justify
the
> >>>>>>need for
> >>>>>>an extension at least for one case. Then we can see what that
case
> >>>>>
> >>>is.
> >>>
> >>>
> >>>>>>I am awaiting that example.
> >>>>>>
> >>>>>>Denis
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>I conclude that I agree with Santosh.
> >>>>>>>
> >>>>>>>The debate is still open... Feel free to express your opinion.
> >>>>>>>
> >>>>>>>Stefan Santesson
> >>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: Denis Pinkas [mailto:[e-mail]]
> >>>>>>>>Sent: den 13 oktober 2004 16:34
> >>>>>>>>To: Stefan Santesson
> >>>>>>>>Cc: Santosh Chokhani; pkix
> >>>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>>
> >>>>>>>>Stefan,
> >>>>>>>>
> >>>>>>>>You are making a conclusion without letting me the time to
> >>>>>>>
> >>>respond. I
> >>>
> >>>
> >>>>>>>>will need more time to look at the pictures (and understand
> >>>>>>>
> > them).
> >
> >>>>>>>>For the time being, I am still reluctant to accept
> >>>>>>>
> >>>>>>>"yet-another-method".
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>We already have too many.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>Santosh,
> >>>>>>>>>
> >>>>>>>>>I conclude that we are in complete and total agreement.
> >>>>>>>>>The question is how to go about this.
> >>>>>>>>
> >>>>>>>>>Could we do this amendment to RFC 3280 in its next revision?
It
> >>>>>>>>>would hopefully just be a minor change.
> >>>>>>>>
> >>>>>>>>This is exactly what I feared.
> >>>>>>>>
> >>>>>>>>We usually end-up with a "minor change" in an extension
without
> >>>>>>>>saying cleary how and when it shall/should be used.
> >>>>>>>>
> >>>>>>>>I still have in mind that:
> >>>>>>>>
> >>>>>>>>1) a certification path must first be constructed,
> >>>>>>>>2) then the revocation checking of that path must be done.
> >>>>>>>>
> >>>>>>>>This means that information about CRL issuers certificates
> >>>>>>>
> >>>locations
> >>>
> >>>
> >>>>>>>may
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>certainly be found in that chain. If not, I would like an
> >>>>>>>
> > example.
> >
> >>>>>>>>Denis
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>It would not change the definition of AIA just add that it
can
> >>>>>>>>
> > be
> >
> >>>>>>>used
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>also as CRL extension and list eventual restrictions and
> >>>>>>>
> > guidance
> >
> >>>for
> >>>
> >>>
> >>>>>>>use
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>with CRLs.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>Stefan Santesson
> >>>>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>-----Original Message-----
> >>>>>>>>>>From: [e-mail]
> >>>>>>>>>
> >>>>>>>[mailto:[e-mail]]
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>On Behalf Of Santosh Chokhani
> >>>>>>>>>>Sent: den 13 oktober 2004 04:33
> >>>>>>>>>>To: 'pkix'
> >>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>Stefan:
> >>>>>>>>>>
> >>>>>>>>>>In terms of certificate discovery, your proposal for AIA in
> >>>>>>>>>
> > CRL
> >
> >>>is
> >>>
> >>>
> >>>>>>>more
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>robust.  The whole idea of self-issued key rollover
> >>>>>>>>>
> > certificates
> >
> >>>>>>>>>>and
> >>>>>>>>>
> >>>>>>>>then
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>using the new key to issue CRL is fraught with security
> >>>>>>>>>
> >>>problems.
> >>>
> >>>
> >>>>>>>>>>A secure solution would be one where the new key is
certified
> >>>>>>>>>
> > by
> >
> >>>>>>>>>>the parent
> >>>>>>>>>
> >>>>>>>CA.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>In
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>that case to obtain the new certificate, you could use AIA
in
> >>>>>>>>>
> >>>CRL.
> >>>
> >>>
> >>>>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP
> >>>>>>>>>
> > in
> >
> >>>>>>>>>>certificate in question points to the indirect CRL.  You get
> >>>>>>>>>
> >>>that
> >>>
> >>>
> >>>>>>>>>>CRL.  The AIA
> >>>>>>>>>
> >>>>>>>in
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>CRL
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>gets you started for the indirect CRL issuer certification
> >>>>>>>>>
> > path
> >
> >>>and
> >>>
> >>>
> >>>>>>>you
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>are
> >>>>>>>>>>in business.
> >>>>>>>>>>
> >>>>>>>>>>-----Original Message-----
> >>>>>>>>>>From: [e-mail]
> >>>>>>>>>
> >>>>>>>[mailto:[e-mail]]
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>On
> >>>>>>>>>>Behalf Of Stefan Santesson
> >>>>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
> >>>>>>>>>>To: David A. Cooper
> >>>>>>>>>>Cc: pkix
> >>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>David,
> >>>>>>>>>>
> >>>>>>>>>>Thanks for the clarifications, they make sense.
> >>>>>>>>>>I did misread your pictures.
> >>>>>>>>>>
> >>>>>>>>>>So can we conclude that for a re-keyed CA in accordance with
> >>>>>>>>>
> > RFC
> >
> >>>>>>>3280,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>either the CRL issuer certificate itself, or the location of
> >>>>>>>>>
> > the
> >
> >>>>>>>>>>CRL issuer certificate, will be clearly identified/available
> >>>>>>>>>
> > for
> >
> >>>>>>>>>>the validating
> >>>>>>>>>
> >>>>>>>>party
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>in some cases, but not in others?
> >>>>>>>>>>
> >>>>>>>>>>Can we also conclude that there is no real discovery
solution
> >>>>>>>>>
> >>>for
> >>>
> >>>
> >>>>>>>>indirect
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>CRLs?
> >>>>>>>>>>
> >>>>>>>>>>Do you then agree then that it could be appropriate to allow
> >>>>>>>>>
> > AIA
> >
> >>>as
> >>>
> >>>
> >>>>>>>a
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>CRL
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>extension to facilitate discovery of CRL signer certificate?
> >>>>>>>>>>
> >>>>>>>>>>Stefan Santesson
> >>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>>>>
> >>>>>>>>>>________________________________________
> >>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
> >>>>>>>>>>Sent: den 12 oktober 2004 21:14
> >>>>>>>>>>To: Stefan Santesson
> >>>>>>>>>>Cc: pkix
> >>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>>>>
> >>>>>>>>>>Stefan,
> >>>>>>>>>>
> >>>>>>>>>>I believe that you are misinterpreting the figures.  They
> >>>>>>>>>
> > really
> >
> >>>do
> >>>
> >>>
> >>>>>>>>>>represent three different cases, not three different
> >>>>>>>>>
> >>>certification
> >>>
> >>>
> >>>>>>>paths
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>that have been constructed through the same PKI
architecture.
> >>>>>>>>>>
> >>>>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
> >>>>>>>>>
> >>>>>>>certificates.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>The
> >>>>>>>>>>Root CA has issued a certificate to CA 1's new key, but not
> >>>>>>>>>
> > its
> >
> >>>old
> >>>
> >>>
> >>>>>>>key
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>(either the Root CA never issued a certificate to CA 1's old
> >>>>>>>>>
> > key
> >
> >>>or
> >>>
> >>>
> >>>>>>>that
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certificate has expired).
> >>>>>>>>>>
> >>>>>>>>>>In figure 2, CA 2 has also generated self-issued key
rollover
> >>>>>>>>>>certificates. The Root CA has issued a certificate to CA 2's
> >>>>>>>>>
> > old
> >
> >>>>>>>>>>key, but not its
> >>>>>>>>>
> >>>>>>>new
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>key.
> >>>>>>>>>>
> >>>>>>>>>>In figure 3, when CA 3 performed key rollover, it requested
a
> >>>>>>>>>
> >>>new
> >>>
> >>>
> >>>>>>>>>>CA certificate from the Root CA.  CA 3 did not generated
> >>>>>>>>>>self-issued
> >>>>>>>>>
> >>>>>>>key
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>rollover certificates.
> >>>>>>>>>>
> >>>>>>>>>>Of course, another realistic scenario would be one in which
a
> >>>>>>>>>
> > CA
> >
> >>>>>>>>generated
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>self-issued key rollover certificates upon key rollover and
> >>>>>>>>>
> > then
> >
> >>>>>>>>>>had
> >>>>>>>>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>Root CA issue a CA certificate to its new key.  In this
case,
> >>>>>>>>>
> > as
> >
> >>>>>>>>>>you suggest, any of the certification paths from figures 1,
2,
> >>>>>>>>>
> >>>or 3
> >>>
> >>>
> >>>>>>>could be
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>constructed.
> >>>>>>>>>>
> >>>>>>>>>>As for the contents of the AIA extension, here is what I
have
> >>>>>>>>>
> >>>>>>>specified
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>in
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the
> >>>>>>>>>
> > Common
> >
> >>>>>>>>Policy":
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>The authorityInfoAccess extension uses URIs for two
purposes.
> >>>>>>>>>
> >>>When
> >>>
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>id-ad-caIssuers access method is used, the access location
> >>>>>>>>>>specifies
> >>>>>>>>>
> >>>>>>>>where
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>certificates issued to the issuer of the certificate may be
> >>>>>>>>>
> >>>found.
> >>>
> >>>
> >>>>>>>If
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>LDAP
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>is used, the URI must include the DN of the entry containing
> >>>>>>>>>
> > the
> >
> >>>>>>>>relevant
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>certificates and specify the directory attribute in which
the
> >>>>>>>>>
> >>>>>>>>certificates
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>are located. If the directory in which the certificates are
> >>>>>>>>>
> >>>stored
> >>>
> >>>
> >>>>>>>>expects
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>the "binary" option to be specified, then the attribute type
> >>>>>>>>>
> >>>must
> >>>
> >>>
> >>>>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the
URI
> >>>>>>>>>
> >>>must
> >>>
> >>>
> >>>>>>>point to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>a
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>file that has an extension of ".p7c" that contains a
> >>>>>>>>>
> > certs-only
> >
> >>>CMS
> >>>
> >>>
> >>>>>>>>>>message (see RFC 2633). The CMS message should include all
> >>>>>>>>>>certificates
> >>>>>>>>>
> >>>>>>>issued
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>to
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>the issuer of this certificate, but must at least contain
all
> >>>>>>>>>
> >>>>>>>>certificates
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>issued to the issuer of this certificate in which the
subject
> >>>>>>>>>>public
> >>>>>>>>>
> >>>>>>>key
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>may
> >>>>>>>>>>be used to verify the signature on this certificate. ....
For
> >>>>>>>>>
> > a
> >
> >>>>>>>>>>certificate issued by "Good CA", some examples of URIs that
> >>>>>>>>>
> > may
> >
> >>>>>>>>>>appear as the
> >>>>>>>>>
> >>>>>>>access
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>location in an authorityInfoAccess extension when the
> >>>>>>>>>
> >>>>>>>id-ad-caIssuers
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>access
> >>>>>>>>>>method is used are:
> >>>>>>>>>
>
>>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cA
C
> >>>>>>
> > e
> >
> >>>r
> >>>
> >>>
> >>>>>>>>>t
> >>>>>>>>>i
> >>>>>>>>
> >>>>>>>fi
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>ca
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>te
> >>>>>>>>>>,crossCertificatePair
> >>>>>>>>>
>
>>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACert
i
> >>>>>>
> > f
> >
> >>>i
> >>>
> >>>
> >>>>>>>>>c
> >>>>>>>>>a
> >>>>>>>>
> >>>>>>>te
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>;b
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>in
> >>>>>>>>>>ary,crossCertificatePair;binary
> >>>>>>>>>
>
>>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsI
s
> >>>>>>
> > s
> >
> >>>u
> >>>
> >>>
> >>>>>>>>>e
> >>>>>>>>>d
> >>>>>>>>
> >>>>>>>To
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Go
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>od
> >>>>>>>>>>CA.p7c
> >>>>>>>>>>For both LDAP and HTTP, the URI provides the exact location
> >>>>>>>>>
> >>>where
> >>>
> >>>
> >>>>>>>>>>information is to be located, so there is no requirement for
> >>>>>>>>>
> > the
> >
> >>>>>>>relying
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>party to try to figure out where information is located.
> >>>>>>>>>>
> >>>>>>>>>>The HTTP URI points to a certs-only CMS message that
includes
> >>>>>>>>>
> >>>all
> >>>
> >>>
> >>>>>>>>>>certificates issued to the CA identified in the issuer field
> >>>>>>>>>
> > of
> >
> >>>the
> >>>
> >>>
> >>>>>>>>>>certificate.
> >>>>>>>>>>
> >>>>>>>>>>The LDAP URI points to the cACertificate and
> >>>>>>>>>
> >>>crossCertificatePair
> >>>
> >>>
> >>>>>>>>>>attributes of the directory entry of the CA identified in
the
> >>>>>>>>>>issuer field of
> >>>>>>>>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certificate.  These two attributes together hold all of the
> >>>>>>>>>
> >>>>>>>certificates
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>issued to the CA:  the cACertificate attribute holds the
CA's
> >>>>>>>>>
> >>>self-
> >>>
> >>>
> >>>>>>>>issued
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>certificates and the crossCertificatePair attribute holds
the
> >>>>>>>>>>cross-certificates issued to the CA by other CAs.
> >>>>>>>>>>
> >>>>>>>>>>Dave
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>Stefan Santesson wrote:
> >>>>>>>>>>
> >>>>>>>>>>David,
> >>>>>>>>>>
> >>>>>>>>>>Thanks for these good thoughts and very useful scenarios.
> >>>>>>>>>>
> >>>>>>>>>>I have some comments and questions on this.
> >>>>>>>>>>
> >>>>>>>>>>First of all we can conclude that in some scenarios (figure
1)
> >>>>>>>>>>where
> >>>>>>>>>
> >>>>>>>a
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>self
> >>>>>>>>>>issued certificate is inserted into the path, you are likely
> >>>>>>>>>
> > to
> >
> >>>>>>>>>>find
> >>>>>>>>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>CRL
> >>>>>>>>>>issuer cert in the path. (given that the new CA have a
common
> >>>>>>>>>
> >>>key
> >>>
> >>>
> >>>>>>>and
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certificate for cert signing and CRL signing).
> >>>>>>>>>>
> >>>>>>>>>>Figure 1, 2 and 3 describe the same case. It is just
> >>>>>>>>>
> > describing
> >
> >>>>>>>>different
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>path building strategies. An application that has access
> >>>>>>>>>
> > locally
> >
> >>>to
> >>>
> >>>
> >>>>>>>all
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>chaining options may however still choose path 2 for the
certs
> >>>>>>>>>
> >>>and
> >>>
> >>>
> >>>>>>>path
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>1
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>for the CRL independent of each other (which I think figure
3
> >>>>>>>>>
> >>>tries
> >>>
> >>>
> >>>>>>>to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>describe)
> >>>>>>>>>>
> >>>>>>>>>>Another comment is the structure of AIA extensions. The use
> >>>>>>>>>
> > I'm
> >
> >>>>>>>familiar
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>with doesn't use AIA to describe a directory entry where it
is
> >>>>>>>>>
> >>>left
> >>>
> >>>
> >>>>>>>to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>validation application logic to be intelligent enough to
find
> >>>>>>>>>
> >>>>>>>>appropriate
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>certificate data from the directory. The model I'm familiar
> >>>>>>>>>
> > with
> >
> >>>is
> >>>
> >>>
> >>>>>>>when
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>AIA URL explicitly identifies the exact location of the
> >>>>>>>>>
> >>>appropriate
> >>>
> >>>
> >>>>>>>CA
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certificate file, relieving the validation software from
> >>>>>>>>>
> > complex
> >
> >>>>>>>>>>information queries. If just location of explicit
certificate
> >>>>>>>>>
> >>>files
> >>>
> >>>
> >>>>>>>>>>are
> >>>>>>>>>
> >>>>>>>identified
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>through AIA, the presence of an AIA may not help finding the
> >>>>>>>>>
> > CRL
> >
> >>>>>>>signer
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>cert
> >>>>>>>>>>if this is different from the CA certificate. This is also
the
> >>>>>>>>>
> >>>>>>>problem
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>with
> >>>>>>>>>>Denis proposal.
> >>>>>>>>>>
> >>>>>>>>>>I think we share the basic conclusion that the ability to
> >>>>>>>>>
> > locate
> >
> >>>>>>>>>>the
> >>>>>>>>>
> >>>>>>>CRL
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>signer certificate directly through the CRL could be very
> >>>>>>>>>
> >>>useful.
> >>>
> >>>
> >>>>>>>>>>At
> >>>>>>>>>
> >>>>>>>>least
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>in the case of indirect CRL but it could also be proven very
> >>>>>>>>>
> >>>useful
> >>>
> >>>
> >>>>>>>in
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>CA
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>re-keying scenarios.
> >>>>>>>>>>
> >>>>>>>>>>The easiest solution would probably be to allow AIA to be
used
> >>>>>>>>>
> >>>in
> >>>
> >>>
> >>>>>>>its
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>current shape and structure as a CRL extension (MUST NOT be
> >>>>>>>>>
> >>>>>>>critical).
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>It
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>would present a very clear and uncomplicated logic to
> >>>>>>>>>
> >>>certificate
> >>>
> >>>
> >>>>>>>>>>validating applications in many cases.
> >>>>>>>>>>
> >>>>>>>>>>Stefan Santesson
> >>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>>>>
> >>>>>>>>>>________________________________________
> >>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
> >>>>>>>>>>Sent: den 7 oktober 2004 18:35
> >>>>>>>>>>To: Stefan Santesson
> >>>>>>>>>>Cc: pkix
> >>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>>>>
> >>>>>>>>>>Stefan,
> >>>>>>>>>>
> >>>>>>>>>>I think what you are proposing is a good idea.  In most
cases,
> >>>>>>>>>
> >>>path
> >>>
> >>>
> >>>>>>>>>>discovery algorithms assume that both the trust anchor (or
> >>>>>>>>>
> > trust
> >
> >>>>>>>>anchors)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>and the end entity certificate are provided as input.  In
this
> >>>>>>>>>>case,
> >>>>>>>>>
> >>>>>>>one
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>may
> >>>>>>>>>>need to construct a certification path without a priori
access
> >>>>>>>>>
> >>>to
> >>>
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>end
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>entity certificate (the one with the subject public key
> >>>>>>>>>
> >>>>>>>corresponding to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>CRL signing key).  Including an AIA extension (or some other
> >>>>>>>>>
> >>>>>>>pointer) in
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>CRL would provide the relying party with a simple way to
> >>>>>>>>>
> > obtain
> >
> >>>the
> >>>
> >>>
> >>>>>>>end
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>entity certificate for the CRL signing key's certification
> >>>>>>>>>
> > path.
> >
> >>>On
> >>>
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>other hand, I believe that a relying party should be able to
> >>>>>>>>>
> >>>>>>>construct
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>certification path even without an AIA extension in the CRL,
> >>>>>>>>>
> > so
> >
> >>>>>>>>>>long
> >>>>>>>>>
> >>>>>>>as
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>it
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>is not an indirect CRL.  Attached is a drawing of the three
> >>>>>>>>>
> >>>basic
> >>>
> >>>
> >>>>>>>>>>scenarios that I expect a relying party may encounter:
> >>>>>>>>>>
> >>>>>>>>>>In each of these scenarios, the CA has performed key
rollover
> >>>>>>>>>
> >>>and
> >>>
> >>>
> >>>>>>>>>>is
> >>>>>>>>>
> >>>>>>>>only
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>signing CRLs with its new key.  The diagrams would look
> >>>>>>>>>
> > similar,
> >
> >>>>>>>>however,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>if
> >>>>>>>>>>the CA simply choose to use different keys to sign
> >>>>>>>>>
> > certificates
> >
> >>>and
> >>>
> >>>
> >>>>>>>CRLs
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>for
> >>>>>>>>>>some other reason.
> >>>>>>>>>>
> >>>>>>>>>>If the PKI architecture resembled figure 1, then the
> >>>>>>>>>
> >>>certification
> >>>
> >>>
> >>>>>>>path
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>for
> >>>>>>>>>>the CRL signing key would just be a subset of the
> >>>>>>>>>
> > certification
> >
> >>>>>>>>>>path
> >>>>>>>>>
> >>>>>>>for
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>EE certificate, so no addition path discovery would be
needed.
> >>>>>>>>>>
> >>>>>>>>>>If the PKI architecture resembled figure 1, then it would be
> >>>>>>>>>
> >>>>>>>necessary
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>to
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>obtain the new-signed-with-old self-issued certificate.  In
> >>>>>>>>>>building
> >>>>>>>>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certification path to the EE certificate, however, the
relying
> >>>>>>>>>>party
> >>>>>>>>>
> >>>>>>>>will
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>obtain the certificates pointed to by the AIA extension in
the
> >>>>>>>>>
> >>>EE
> >>>
> >>>
> >>>>>>>>>>certificate.  This AIA extension will point to a location
> >>>>>>>>>>containing
> >>>>>>>>>
> >>>>>>>all
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certificates issued to CA 2, which would include both the
> >>>>>>>>>
> >>>>>>>certificate
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>issued
> >>>>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So,
> >>>>>>>>>
> >>>even
> >>>
> >>>
> >>>>>>>though
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>self-issued certificate would not be part of the
certification
> >>>>>>>>>
> >>>path
> >>>
> >>>
> >>>>>>>to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>EE certificate, it would be downloaded by the relying party
> >>>>>>>>>
> >>>during
> >>>
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>construction of that certification path.  (Yes, there are
> >>>>>>>>>
> >>>circular
> >>>
> >>>
> >>>>>>>>>>dependency issues in figure 2, but that is another issue.)
> >>>>>>>>>>
> >>>>>>>>>>A similar situation would happen if the PKI architecture
> >>>>>>>>>
> >>>resembled
> >>>
> >>>
> >>>>>>>>figure
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>3.  The AIA extension in the EE certificate would point to a
> >>>>>>>>>
> >>>>>>>location
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>containing certificates issued to CA 3.  When the relying
> >>>>>>>>>
> > party
> >
> >>>>>>>>downloaded
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>these certificates, it would obtain both of the certificates
> >>>>>>>>>
> >>>issued
> >>>
> >>>
> >>>>>>>by
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>Root to CA 3 and so again would have the certificate needed
to
> >>>>>>>>>
> >>>>>>>validate
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>the
> >>>>>>>>>>CRL signing key.
> >>>>>>>>>>
> >>>>>>>>>>In the case of an indirect CRL, things may not work as well.
> >>>>>>>>>
> > If
> >
> >>>>>>>>indirect
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>CRLs were used, and the PKI architecture resembled figures 2
> >>>>>>>>>
> > or
> >
> >>>3
> >>>
> >>>
> >>>>>>>>>>(replacing "New Key" with a different CA), then the set of
> >>>>>>>>>>certificates pointed
> >>>>>>>>>
> >>>>>>>to
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>by
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>the AIA extension in the EE certificate would not include
the
> >>>>>>>>>
> >>>>>>>>certificate
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>of
> >>>>>>>>>>the CRL signer.  One could find this certificate by building
> >>>>>>>>>
> > in
> >
> >>>the
> >>>
> >>>
> >>>>>>>>>>reverse direction and using the SIA extension, but that may
> >>>>>>>>>
> > not
> >
> >>>be
> >>>
> >>>
> >>>>>>>>>>the most convenient solution.
> >>>>>>>>>>
> >>>>>>>>>>So, when indirect CRLs are being used, it seems that it
would
> >>>>>>>>>
> > be
> >
> >>>>>>>very
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>useful
> >>>>>>>>>>to have a pointer in the CRL to the CRL signing certificate.
> >>>>>>>>>
> >>>When
> >>>
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>CRL
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>is not indirect, the need for this pointer does not seem to
be
> >>>>>>>>>
> >>>as
> >>>
> >>>
> >>>>>>>clear,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>but
> >>>>>>>>>>I can't see any harm in including it.
> >>>>>>>>>>
> >>>>>>>>>>Dave
> >>>>>>>>>>
> >>>>>>>>>>Stefan Santesson wrote:
> >>>>>>>>>>All,
> >>>>>>>>>>
> >>>>>>>>>>I'm interested in the opinion from members on this list
about
> >>>>>>>>>
> >>>>>>>discovery
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>of
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>CRL signer's certificate in non directory centric
> >>>>>>>>>
> > environments.
> >
> >>>>>>>>>>The problem is the following.
> >>>>>>>>>>
> >>>>>>>>>>The relying party (RP) needs to check validity of a
> >>>>>>>>>
> > certificate
> >
> >>>and
> >>>
> >>>
> >>>>>>>>finds
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>a
> >>>>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this
CRL
> >>>>>>>>>>which
> >>>>>>>>>
> >>>>>>>in
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>this
> >>>>>>>>>>particular case is either signed by another key of the CA
> >>>>>>>>>
> >>>(re-keyed
> >>>
> >>>
> >>>>>>>CA)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>or
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>another entity (indirect CRL).
> >>>>>>>>>>
> >>>>>>>>>>In this case the relying party needs to obtain the
certificate
> >>>>>>>>>
> >>>of
> >>>
> >>>
> >>>>>>>the
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>CRL
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>signer which may NOT be part of the original chain. In a
> >>>>>>>>>
> >>>directory
> >>>
> >>>
> >>>>>>>>centric
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>solution this is retrieved from the directory, but what if
> >>>>>>>>>
> > such
> >
> >>>>>>>>directory
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>is
> >>>>>>>>>>not available or accessible.
> >>>>>>>>>>
> >>>>>>>>>>The RP have thus no hint where to find the CRL issuers
> >>>>>>>>>
> >>>certificate
> >>>
> >>>
> >>>>>>>>unless
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>the RP already have possession of it by some other means.
> >>>>>>>>>>
> >>>>>>>>>>Is seems that CRLs would need an AIA extension with the
option
> >>>>>>>>>
> >>>to
> >>>
> >>>
> >>>>>>>point
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>to
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>the location of the signers certificate in the same manner
as
> >>>>>>>>>
> > is
> >
> >>>>>>>>possible
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>for certificates.
> >>>>>>>>>>
> >>>>>>>>>>Maybe AIA should be defined as both cert and CRL extension
and
> >>>>>>>>>
> >>>not
> >>>
> >>>
> >>>>>>>only
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>certificate extension as today.
> >>>>>>>>>>
> >>>>>>>>>>Thoughts and comments?
> >>>>>>>>>>
> >>>>>>>>>>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 i9IAUGI9075973; Mon, 18 Oct 2004 03:30:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IAUGgh075972; Mon, 18 Oct 2004 03:30:16 -0700 (PDT)
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 i9IAUDEx075910 for <[e-mail]>; Mon, 18 Oct 2004 03:30:14 -0700 (PDT) (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 MAA18654; Mon, 18 Oct 2004 12:41:38 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101812295493:1701 ; Mon, 18 Oct 2004 12:29:54 +0200 
Message-ID: <[e-mail]>
Date: Mon, 18 Oct 2004 12:28:09 +0200
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]>, pkix <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/10/2004 12:29:55, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/10/2004 12:29:56, Serialize complete at 18/10/2004 12:29:56
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,

> Denis, 

> If I get you right you mean that one can always successfully use AIA and
> SIA in certs to solve discovery of CRL signer cert.
> Others on this list (me included) don't understand how. It would
> therefore be useful if you told us.
> 
> I'll try to explain the problem from my perspective one more time.

Thanks.

> Note: "->" in these examples means "issued by"

Fine.

> Case 1 - indirect CRL:
> 
> Cert path is:  EE_Cert -> CA_1 -> Root-CA
> CRL path for EE_Cert is:  CRL -> CRL_Issuer_B -> Root-CA

This means Root-CA has nominated CA_1 and a CRL_Issuer_B and that CA_1 has 
chosen to use CRL_Issuer_B for revocation checking for some certificates.

> Scenario: 
> Relying party has access to the cert path, discovers the CRL through CDP
> in EE_Cert. 

If there is no attack on the objects stored at the CRL DP, the CRL Issuer 
from that CRL is CRL_Issuer_B. Now the relying party needs to get the 
certificate isued by Root-CA for CRL_Issuer_B. If Root-CA has included a SIA 
extension in his self-signed certificate, then using that extension allows 
to get the CRL_Issuer_B certificate issued by the Root-CA.

 > The RP searches the location specified in SIA through
> id-ad-caRepository in the CA_1 cert but finds nothing useful since
> revocation is subordinated to another entity (CRL_Issuer_B)

Correct, but looking in Root-CA allows to find something useful, if the 
self-signed certificate includes a SIA extension.

> In this case, the problem could be solved if an AIA in the CRL indicated
> the access location of the CRL Issuer cert.

This would be an *alternative* way.

> Case 2 - re-keyed CA.
> 
> Cert path is:  EE_Cert -> CA_1(old key) -> Root-CA
> CRL path for EE_Cert is:  CRL -> CA_1(new key) -> Root-CA

This means that the EE_Cert chain has been created with CA_1(old key) and 
that the CRL issuer that was originaly used when the EE_Cert was created has 
been changed and a new CRL Issuer got a certificate under CA_1(new key) and 
is now the legitimate CRL issuer for the CRL DP originally mentionned in the 
EE_Cert.

> The 2 CA_1 certificates above (old key and new key) are issued to
> different subject keys belonging to the same CA (same name).
> The cert CA_1(old key) was issued before creation of cert CA_1(new key)
> and have thus no reference to CA_1(new key) in its SIA
> 
> Scenario:
> RP discovers the CRL for the EE_Cert through the CDP but doesn't possess
> the CRL issuer cert. The RP client searches the SIA of the CA_1(old key)
> but finds no direct reference to the CRL signer cert. Since the RP
> client has no access to a directory where the CRL signer cert could be
> found through directory lookup, cert validation fails.

Correct, but looking in Root-CA allows to find something useful, if the 
self-signed certificate includes a SIA extension.

> In this scenario the problem could be solved through an AIA in the CRL.

This would be an *alternative* way.

Denis

>  
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: den 15 oktober 2004 17:30
>>To: Stefan Santesson
>>Cc: Santosh Chokhani; pkix
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>Stefan,
>>
>>
>>>Denis,
>>
>>>Unfortunately I fail to understand your questions, issues and
>>
> requests.
> 
>>The sentence below demonstrates that you understand the issue.
>>
>>
>>>It would be very useful if you could explain how current mechanisms
>>
> can
> 
>>>be used in a simple and straightforward manner to discover CRL
>>
> signer
> 
>>>certificates in ALL the use cases discussed, mainly re-keyed CA and
>>>indirect CRLs.
>>
>>You are also reversing the question. Using your terms, my question
> 
> would
> 
>>be:
>>
>>"It would be very useful if you could explain how current mechanisms
>>CANNOT
>>be used in a simple and straightforward manner to discover CRL signer
>>certificates in ONE or MORE the use cases discussed, mainly re-keyed
> 
> CA
> 
>>and
>>indirect CRLs."
>>
>>Denis
>>
>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>
>>>[mailto:[e-mail]]
>>>
>>>
>>>>On Behalf Of Denis Pinkas
>>>>Sent: den 14 oktober 2004 17:13
>>>>To: Santosh Chokhani
>>>>Cc: 'pkix'
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>
>>>>Santosh,
>>>>
>>>>
>>>>
>>>>>Denis:
>>>>
>>>>>With the three assumptions/constraints I provided, how would you
>>>>
>>>locate
>>>
>>>
>>>>the
>>>>
>>>>
>>>>>CRL issuer certificate for the two examples using 3280 extensions
>>>>
>>>and
>>>
>>>
>>>>>without putting AIA in the CRL?
>>>>
>>>>As far as I understand, the three assumptions are:
>>>>
>>>>1.  You are directory challenged; and
>>>>    [I do not understand what this means]
>>>>2.  You use AIA to develop the path; and
>>>>    [It does not matter]
>>>>3.  You develop the path from the end entity to trust anchor
>>>>    [Could also be the contrary].
>>>>
>>>>If this is not correct, thus please correct.
>>>>
>>>>Then my request is: "using ANY OF the current extensions that are
>>>
>>>defined
>>>
>>>
>>>>in
>>>>RFC 3280", which includes SIA.
>>>>
>>>>In your explanations  you said :
>>>>"if you do no deal with SIA et. al"
>>>>
>>>>This last assumption is neither part of the three assumptions and
>>>
> does
> 
>>>not
>>>
>>>
>>>>conform to my request.
>>>>
>>>>Denis
>>>>
>>>>
>>>>
>>>>>That is my point.
>>>>>
>>>>>-----Original Message-----
>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>Sent: Thursday, October 14, 2004 6:22 AM
>>>>>To: Santosh Chokhani
>>>>>Cc: 'pkix'
>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>
>>>>>
>>>>>Santosh,
>>>>>
>>>>>You misread my request. I said:
>>>>>
>>>>>"For the time being, I would like that you provide an example
>>>>
> where,
> 
>>>>when
>>>>
>>>>
>>>>>using the current extensions that are defined in RFC 3280, it will
>>>>
>>>NOT
>>>
>>>
>>>>be
>>>>
>>>>
>>>>>possible to locate a CRL Issuer certificate."
>>>>>
>>>>>Maybe I would have needed to be clearer and say :
>>>>>
>>>>>"For the time being, I would like that you provide an example
>>>>
> where,
> 
>>>>when
>>>>
>>>>
>>>>>using ANY OF the current extensions that are defined in RFC 3280,
>>>>
> it
> 
>>>>will
>>>>
>>>>
>>>>>NOT be possible to locate a CRL Issuer certificate."
>>>>>
>>>>>The examples you provide below do not fulfil this request.
>>>>>
>>>>>The assumption is that there exists a path to be tested for
>>>>
>>>revocation
>>>
>>>
>>>>>checking (and that it does not matter to know which way it has been
>>>>>constructed).
>>>>>
>>>>>I am not saying that using AIA in CRL might not be useful, but I am
>>>>
>>>>still
>>>>
>>>>
>>>>>lacking the demonstration that there would be no other way.
>>>>>
>>>>>Denis
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Denis:
>>>>>>
>>>>>>Two examples are very simple: one for direct CRL Issuer and one
>>>>>
> for
> 
>>>>>>Indirect CRL Issuer.
>>>>>>
>>>>>>Let us make the following assumptions that Stefan was making:
>>>>>>
>>>>>>1.  You are directory challenged; and
>>>>>>2.  You use AIA to develop the path; and
>>>>>>3.  You develop the path from the end entity to trust anchor.
>>>>>>
>>>>>
>>>>>>From what I know of MS CAPI, these are reasonable
>>>>>
>>>>>
>>>>>>assumptions/constraints.
>>>>>>
>>>>>>Now the examples.
>>>>>>
>>>>>>Example 1: Direct CRL Issuer
>>>>>>
>>>>>>The certificate trust path is:
>>>>>>Root --> CA1 --> CA 2, old key --> Denis
>>>>>>
>>>>>>The CRL trust path is:
>>>>>>Root --> CA1 --> CA 2, new key --> CRL
>>>>>>
>>>>>>(Note: We do not do self-issued certificate since there is no
>>>>>
>>>simple,
>>>
>>>
>>>>>>secure way to check their revocation status).
>>>>>>
>>>>>>Now, with AIA in CRL, finding the CA2, new key certificate is
>>>>>>straightforward.  How would you find it if you do no deal with SIA
>>>>>
>>>et.
>>>
>>>
>>>>>>al.
>>>>>>
>>>>>>Example 2: Indirect CRL Issuer
>>>>>>
>>>>>>The certificate trust path is:
>>>>>>Root --> CA1 --> CA 2 --> Denis
>>>>>>(Note: Denis's certificate points to CRL DP of an indirect CRL
>>>>>
>>>issued
>>>
>>>
>>>>>>by CAI.
>>>>>>
>>>>>>The CRL trust path is:
>>>>>>Root --> CAI --> CRL
>>>>>>
>>>>>>Now, with AIA in CRL, finding the CAI certificate is
>>>>>
>>>straightforward.
>>>
>>>
>>>>>>How would you find it if you do no deal with SIA et. al.
>>>>>>
>>>>>>In addition to the need cited above, please note that the
>>>>>
> extension
> 
>>>>>>semantics does not change, it does not hinder any
>>>>>
> interoperability,
> 
>>>>>>and it does not break any backward compatibility.  So, what if I
>>>>>>wanted to use this extension in the CRL.  It does no harm to other
>>>>>>relying parties.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [e-mail]
>>>>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>>>>>Sent: Wednesday, October 13, 2004 11:01 AM
>>>>>>To: Stefan Santesson
>>>>>>Cc: Santosh Chokhani; pkix
>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>
>>>>>>
>>>>>>
>>>>>>Stefan,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Denis,
>>>>>>
>>>>>>
>>>>>>>I'm not sure what you mean.
>>>>>>
>>>>>>
>>>>>>For the time being, I would like that you provide an example
>>>>>
> where,
> 
>>>>>>when
>>>>>>using the current extensions that are defined in RFC 3280, it will
>>>>>
>>>NOT
>>>
>>>
>>>>be
>>>>
>>>>
>>>>>>possible to locate a CRL Issuer certificate.
>>>>>>
>>>>>>If you are able to provide that example, then it would justify the
>>>>>>need for
>>>>>>an extension at least for one case. Then we can see what that case
>>>>>
>>>is.
>>>
>>>
>>>>>>I am awaiting that example.
>>>>>>
>>>>>>Denis
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I conclude that I agree with Santosh.
>>>>>>>
>>>>>>>The debate is still open... Feel free to express your opinion.
>>>>>>>
>>>>>>>Stefan Santesson
>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>>>>Sent: den 13 oktober 2004 16:34
>>>>>>>>To: Stefan Santesson
>>>>>>>>Cc: Santosh Chokhani; pkix
>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>Stefan,
>>>>>>>>
>>>>>>>>You are making a conclusion without letting me the time to
>>>>>>>
>>>respond. I
>>>
>>>
>>>>>>>>will need more time to look at the pictures (and understand
>>>>>>>
> them).
> 
>>>>>>>>For the time being, I am still reluctant to accept
>>>>>>>
>>>>>>>"yet-another-method".
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>We already have too many.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Santosh,
>>>>>>>>>
>>>>>>>>>I conclude that we are in complete and total agreement.
>>>>>>>>>The question is how to go about this.
>>>>>>>>
>>>>>>>>>Could we do this amendment to RFC 3280 in its next revision? It
>>>>>>>>>would hopefully just be a minor change.
>>>>>>>>
>>>>>>>>This is exactly what I feared.
>>>>>>>>
>>>>>>>>We usually end-up with a "minor change" in an extension without
>>>>>>>>saying cleary how and when it shall/should be used.
>>>>>>>>
>>>>>>>>I still have in mind that:
>>>>>>>>
>>>>>>>>1) a certification path must first be constructed,
>>>>>>>>2) then the revocation checking of that path must be done.
>>>>>>>>
>>>>>>>>This means that information about CRL issuers certificates
>>>>>>>
>>>locations
>>>
>>>
>>>>>>>may
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>certainly be found in that chain. If not, I would like an
>>>>>>>
> example.
> 
>>>>>>>>Denis
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>It would not change the definition of AIA just add that it can
>>>>>>>>
> be
> 
>>>>>>>used
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>also as CRL extension and list eventual restrictions and
>>>>>>>
> guidance
> 
>>>for
>>>
>>>
>>>>>>>use
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>with CRLs.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Stefan Santesson
>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>-----Original Message-----
>>>>>>>>>>From: [e-mail]
>>>>>>>>>
>>>>>>>[mailto:[e-mail]]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>On Behalf Of Santosh Chokhani
>>>>>>>>>>Sent: den 13 oktober 2004 04:33
>>>>>>>>>>To: 'pkix'
>>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Stefan:
>>>>>>>>>>
>>>>>>>>>>In terms of certificate discovery, your proposal for AIA in
>>>>>>>>>
> CRL
> 
>>>is
>>>
>>>
>>>>>>>more
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>robust.  The whole idea of self-issued key rollover
>>>>>>>>>
> certificates
> 
>>>>>>>>>>and
>>>>>>>>>
>>>>>>>>then
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>using the new key to issue CRL is fraught with security
>>>>>>>>>
>>>problems.
>>>
>>>
>>>>>>>>>>A secure solution would be one where the new key is certified
>>>>>>>>>
> by
> 
>>>>>>>>>>the parent
>>>>>>>>>
>>>>>>>CA.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>In
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>that case to obtain the new certificate, you could use AIA in
>>>>>>>>>
>>>CRL.
>>>
>>>
>>>>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP
>>>>>>>>>
> in
> 
>>>>>>>>>>certificate in question points to the indirect CRL.  You get
>>>>>>>>>
>>>that
>>>
>>>
>>>>>>>>>>CRL.  The AIA
>>>>>>>>>
>>>>>>>in
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>CRL
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>gets you started for the indirect CRL issuer certification
>>>>>>>>>
> path
> 
>>>and
>>>
>>>
>>>>>>>you
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>are
>>>>>>>>>>in business.
>>>>>>>>>>
>>>>>>>>>>-----Original Message-----
>>>>>>>>>>From: [e-mail]
>>>>>>>>>
>>>>>>>[mailto:[e-mail]]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>On
>>>>>>>>>>Behalf Of Stefan Santesson
>>>>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>>>>>>To: David A. Cooper
>>>>>>>>>>Cc: pkix
>>>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>David,
>>>>>>>>>>
>>>>>>>>>>Thanks for the clarifications, they make sense.
>>>>>>>>>>I did misread your pictures.
>>>>>>>>>>
>>>>>>>>>>So can we conclude that for a re-keyed CA in accordance with
>>>>>>>>>
> RFC
> 
>>>>>>>3280,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>either the CRL issuer certificate itself, or the location of
>>>>>>>>>
> the
> 
>>>>>>>>>>CRL issuer certificate, will be clearly identified/available
>>>>>>>>>
> for
> 
>>>>>>>>>>the validating
>>>>>>>>>
>>>>>>>>party
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>in some cases, but not in others?
>>>>>>>>>>
>>>>>>>>>>Can we also conclude that there is no real discovery solution
>>>>>>>>>
>>>for
>>>
>>>
>>>>>>>>indirect
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>CRLs?
>>>>>>>>>>
>>>>>>>>>>Do you then agree then that it could be appropriate to allow
>>>>>>>>>
> AIA
> 
>>>as
>>>
>>>
>>>>>>>a
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>CRL
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>>>>>>
>>>>>>>>>>Stefan Santesson
>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>>
>>>>>>>>>>________________________________________
>>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>>>Sent: den 12 oktober 2004 21:14
>>>>>>>>>>To: Stefan Santesson
>>>>>>>>>>Cc: pkix
>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>>
>>>>>>>>>>Stefan,
>>>>>>>>>>
>>>>>>>>>>I believe that you are misinterpreting the figures.  They
>>>>>>>>>
> really
> 
>>>do
>>>
>>>
>>>>>>>>>>represent three different cases, not three different
>>>>>>>>>
>>>certification
>>>
>>>
>>>>>>>paths
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>that have been constructed through the same PKI architecture.
>>>>>>>>>>
>>>>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>>>>>>
>>>>>>>certificates.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>The
>>>>>>>>>>Root CA has issued a certificate to CA 1's new key, but not
>>>>>>>>>
> its
> 
>>>old
>>>
>>>
>>>>>>>key
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>(either the Root CA never issued a certificate to CA 1's old
>>>>>>>>>
> key
> 
>>>or
>>>
>>>
>>>>>>>that
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>certificate has expired).
>>>>>>>>>>
>>>>>>>>>>In figure 2, CA 2 has also generated self-issued key rollover
>>>>>>>>>>certificates. The Root CA has issued a certificate to CA 2's
>>>>>>>>>
> old
> 
>>>>>>>>>>key, but not its
>>>>>>>>>
>>>>>>>new
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>key.
>>>>>>>>>>
>>>>>>>>>>In figure 3, when CA 3 performed key rollover, it requested a
>>>>>>>>>
>>>new
>>>
>>>
>>>>>>>>>>CA certificate from the Root CA.  CA 3 did not generated
>>>>>>>>>>self-issued
>>>>>>>>>
>>>>>>>key
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>rollover certificates.
>>>>>>>>>>
>>>>>>>>>>Of course, another realistic scenario would be one in which a
>>>>>>>>>
> CA
> 
>>>>>>>>generated
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>self-issued key rollover certificates upon key rollover and
>>>>>>>>>
> then
> 
>>>>>>>>>>had
>>>>>>>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>Root CA issue a CA certificate to its new key.  In this case,
>>>>>>>>>
> as
> 
>>>>>>>>>>you suggest, any of the certification paths from figures 1, 2,
>>>>>>>>>
>>>or 3
>>>
>>>
>>>>>>>could be
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>constructed.
>>>>>>>>>>
>>>>>>>>>>As for the contents of the AIA extension, here is what I have
>>>>>>>>>
>>>>>>>specified
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>in
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the
>>>>>>>>>
> Common
> 
>>>>>>>>Policy":
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>The authorityInfoAccess extension uses URIs for two purposes.
>>>>>>>>>
>>>When
>>>
>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>id-ad-caIssuers access method is used, the access location
>>>>>>>>>>specifies
>>>>>>>>>
>>>>>>>>where
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>certificates issued to the issuer of the certificate may be
>>>>>>>>>
>>>found.
>>>
>>>
>>>>>>>If
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>LDAP
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>is used, the URI must include the DN of the entry containing
>>>>>>>>>
> the
> 
>>>>>>>>relevant
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>certificates and specify the directory attribute in which the
>>>>>>>>>
>>>>>>>>certificates
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>are located. If the directory in which the certificates are
>>>>>>>>>
>>>stored
>>>
>>>
>>>>>>>>expects
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>the "binary" option to be specified, then the attribute type
>>>>>>>>>
>>>must
>>>
>>>
>>>>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the URI
>>>>>>>>>
>>>must
>>>
>>>
>>>>>>>point to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>a
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>file that has an extension of ".p7c" that contains a
>>>>>>>>>
> certs-only
> 
>>>CMS
>>>
>>>
>>>>>>>>>>message (see RFC 2633). The CMS message should include all
>>>>>>>>>>certificates
>>>>>>>>>
>>>>>>>issued
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>to
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>the issuer of this certificate, but must at least contain all
>>>>>>>>>
>>>>>>>>certificates
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>issued to the issuer of this certificate in which the subject
>>>>>>>>>>public
>>>>>>>>>
>>>>>>>key
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>may
>>>>>>>>>>be used to verify the signature on this certificate. .... For
>>>>>>>>>
> a
> 
>>>>>>>>>>certificate issued by "Good CA", some examples of URIs that
>>>>>>>>>
> may
> 
>>>>>>>>>>appear as the
>>>>>>>>>
>>>>>>>access
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>location in an authorityInfoAccess extension when the
>>>>>>>>>
>>>>>>>id-ad-caIssuers
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>access
>>>>>>>>>>method is used are:
>>>>>>>>>
>>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cAC
>>>>>>
> e
> 
>>>r
>>>
>>>
>>>>>>>>>t
>>>>>>>>>i
>>>>>>>>
>>>>>>>fi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>ca
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>te
>>>>>>>>>>,crossCertificatePair
>>>>>>>>>
>>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACerti
>>>>>>
> f
> 
>>>i
>>>
>>>
>>>>>>>>>c
>>>>>>>>>a
>>>>>>>>
>>>>>>>te
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>;b
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>in
>>>>>>>>>>ary,crossCertificatePair;binary
>>>>>>>>>
>>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIs
>>>>>>
> s
> 
>>>u
>>>
>>>
>>>>>>>>>e
>>>>>>>>>d
>>>>>>>>
>>>>>>>To
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Go
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>od
>>>>>>>>>>CA.p7c
>>>>>>>>>>For both LDAP and HTTP, the URI provides the exact location
>>>>>>>>>
>>>where
>>>
>>>
>>>>>>>>>>information is to be located, so there is no requirement for
>>>>>>>>>
> the
> 
>>>>>>>relying
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>party to try to figure out where information is located.
>>>>>>>>>>
>>>>>>>>>>The HTTP URI points to a certs-only CMS message that includes
>>>>>>>>>
>>>all
>>>
>>>
>>>>>>>>>>certificates issued to the CA identified in the issuer field
>>>>>>>>>
> of
> 
>>>the
>>>
>>>
>>>>>>>>>>certificate.
>>>>>>>>>>
>>>>>>>>>>The LDAP URI points to the cACertificate and
>>>>>>>>>
>>>crossCertificatePair
>>>
>>>
>>>>>>>>>>attributes of the directory entry of the CA identified in the
>>>>>>>>>>issuer field of
>>>>>>>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>certificate.  These two attributes together hold all of the
>>>>>>>>>
>>>>>>>certificates
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>issued to the CA:  the cACertificate attribute holds the CA's
>>>>>>>>>
>>>self-
>>>
>>>
>>>>>>>>issued
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>certificates and the crossCertificatePair attribute holds the
>>>>>>>>>>cross-certificates issued to the CA by other CAs.
>>>>>>>>>>
>>>>>>>>>>Dave
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Stefan Santesson wrote:
>>>>>>>>>>
>>>>>>>>>>David,
>>>>>>>>>>
>>>>>>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>>>>>>
>>>>>>>>>>I have some comments and questions on this.
>>>>>>>>>>
>>>>>>>>>>First of all we can conclude that in some scenarios (figure 1)
>>>>>>>>>>where
>>>>>>>>>
>>>>>>>a
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>self
>>>>>>>>>>issued certificate is inserted into the path, you are likely
>>>>>>>>>
> to
> 
>>>>>>>>>>find
>>>>>>>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>CRL
>>>>>>>>>>issuer cert in the path. (given that the new CA have a common
>>>>>>>>>
>>>key
>>>
>>>
>>>>>>>and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>certificate for cert signing and CRL signing).
>>>>>>>>>>
>>>>>>>>>>Figure 1, 2 and 3 describe the same case. It is just
>>>>>>>>>
> describing
> 
>>>>>>>>different
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>path building strategies. An application that has access
>>>>>>>>>
> locally
> 
>>>to
>>>
>>>
>>>>>>>all
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>chaining options may however still choose path 2 for the certs
>>>>>>>>>
>>>and
>>>
>>>
>>>>>>>path
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>for the CRL independent of each other (which I think figure 3
>>>>>>>>>
>>>tries
>>>
>>>
>>>>>>>to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>describe)
>>>>>>>>>>
>>>>>>>>>>Another comment is the structure of AIA extensions. The use
>>>>>>>>>
> I'm
> 
>>>>>>>familiar
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>with doesn't use AIA to describe a directory entry where it is
>>>>>>>>>
>>>left
>>>
>>>
>>>>>>>to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>validation application logic to be intelligent enough to find
>>>>>>>>>
>>>>>>>>appropriate
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>certificate data from the directory. The model I'm familiar
>>>>>>>>>
> with
> 
>>>is
>>>
>>>
>>>>>>>when
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>AIA URL explicitly identifies the exact location of the
>>>>>>>>>
>>>appropriate
>>>
>>>
>>>>>>>CA
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>certificate file, relieving the validation software from
>>>>>>>>>
> complex
> 
>>>>>>>>>>information queries. If just location of explicit certificate
>>>>>>>>>
>>>files
>>>
>>>
>>>>>>>>>>are
>>>>>>>>>
>>>>>>>identified
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>through AIA, the presence of an AIA may not help finding the
>>>>>>>>>
> CRL
> 
>>>>>>>signer
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>cert
>>>>>>>>>>if this is different from the CA certificate. This is also the
>>>>>>>>>
>>>>>>>problem
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>with
>>>>>>>>>>Denis proposal.
>>>>>>>>>>
>>>>>>>>>>I think we share the basic conclusion that the ability to
>>>>>>>>>
> locate
> 
>>>>>>>>>>the
>>>>>>>>>
>>>>>>>CRL
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>signer certificate directly through the CRL could be very
>>>>>>>>>
>>>useful.
>>>
>>>
>>>>>>>>>>At
>>>>>>>>>
>>>>>>>>least
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>in the case of indirect CRL but it could also be proven very
>>>>>>>>>
>>>useful
>>>
>>>
>>>>>>>in
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>CA
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>re-keying scenarios.
>>>>>>>>>>
>>>>>>>>>>The easiest solution would probably be to allow AIA to be used
>>>>>>>>>
>>>in
>>>
>>>
>>>>>>>its
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>>>>>>
>>>>>>>critical).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>It
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>would present a very clear and uncomplicated logic to
>>>>>>>>>
>>>certificate
>>>
>>>
>>>>>>>>>>validating applications in many cases.
>>>>>>>>>>
>>>>>>>>>>Stefan Santesson
>>>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>>>
>>>>>>>>>>________________________________________
>>>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>>>Sent: den 7 oktober 2004 18:35
>>>>>>>>>>To: Stefan Santesson
>>>>>>>>>>Cc: pkix
>>>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>>>
>>>>>>>>>>Stefan,
>>>>>>>>>>
>>>>>>>>>>I think what you are proposing is a good idea.  In most cases,
>>>>>>>>>
>>>path
>>>
>>>
>>>>>>>>>>discovery algorithms assume that both the trust anchor (or
>>>>>>>>>
> trust
> 
>>>>>>>>anchors)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>and the end entity certificate are provided as input.  In this
>>>>>>>>>>case,
>>>>>>>>>
>>>>>>>one
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>may
>>>>>>>>>>need to construct a certification path without a priori access
>>>>>>>>>
>>>to
>>>
>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>end
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>entity certificate (the one with the subject public key
>>>>>>>>>
>>>>>>>corresponding to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>>>>>>
>>>>>>>pointer) in
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>CRL would provide the relying party with a simple way to
>>>>>>>>>
> obtain
> 
>>>the
>>>
>>>
>>>>>>>end
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>entity certificate for the CRL signing key's certification
>>>>>>>>>
> path.
> 
>>>On
>>>
>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>other hand, I believe that a relying party should be able to
>>>>>>>>>
>>>>>>>construct
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>certification path even without an AIA extension in the CRL,
>>>>>>>>>
> so
> 
>>>>>>>>>>long
>>>>>>>>>
>>>>>>>as
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>it
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>is not an indirect CRL.  Attached is a drawing of the three
>>>>>>>>>
>>>basic
>>>
>>>
>>>>>>>>>>scenarios that I expect a relying party may encounter:
>>>>>>>>>>
>>>>>>>>>>In each of these scenarios, the CA has performed key rollover
>>>>>>>>>
>>>and
>>>
>>>
>>>>>>>>>>is
>>>>>>>>>
>>>>>>>>only
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>signing CRLs with its new key.  The diagrams would look
>>>>>>>>>
> similar,
> 
>>>>>>>>however,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>if
>>>>>>>>>>the CA simply choose to use different keys to sign
>>>>>>>>>
> certificates
> 
>>>and
>>>
>>>
>>>>>>>CRLs
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>for
>>>>>>>>>>some other reason.
>>>>>>>>>>
>>>>>>>>>>If the PKI architecture resembled figure 1, then the
>>>>>>>>>
>>>certification
>>>
>>>
>>>>>>>path
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>for
>>>>>>>>>>the CRL signing key would just be a subset of the
>>>>>>>>>
> certification
> 
>>>>>>>>>>path
>>>>>>>>>
>>>>>>>for
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>EE certificate, so no addition path discovery would be needed.
>>>>>>>>>>
>>>>>>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>>>>>>
>>>>>>>necessary
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>to
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>obtain the new-signed-with-old self-issued certificate.  In
>>>>>>>>>>building
>>>>>>>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>certification path to the EE certificate, however, the relying
>>>>>>>>>>party
>>>>>>>>>
>>>>>>>>will
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>obtain the certificates pointed to by the AIA extension in the
>>>>>>>>>
>>>EE
>>>
>>>
>>>>>>>>>>certificate.  This AIA extension will point to a location
>>>>>>>>>>containing
>>>>>>>>>
>>>>>>>all
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>certificates issued to CA 2, which would include both the
>>>>>>>>>
>>>>>>>certificate
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>issued
>>>>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So,
>>>>>>>>>
>>>even
>>>
>>>
>>>>>>>though
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>self-issued certificate would not be part of the certification
>>>>>>>>>
>>>path
>>>
>>>
>>>>>>>to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>EE certificate, it would be downloaded by the relying party
>>>>>>>>>
>>>during
>>>
>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>construction of that certification path.  (Yes, there are
>>>>>>>>>
>>>circular
>>>
>>>
>>>>>>>>>>dependency issues in figure 2, but that is another issue.)
>>>>>>>>>>
>>>>>>>>>>A similar situation would happen if the PKI architecture
>>>>>>>>>
>>>resembled
>>>
>>>
>>>>>>>>figure
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>>>>>>
>>>>>>>location
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>containing certificates issued to CA 3.  When the relying
>>>>>>>>>
> party
> 
>>>>>>>>downloaded
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>these certificates, it would obtain both of the certificates
>>>>>>>>>
>>>issued
>>>
>>>
>>>>>>>by
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>Root to CA 3 and so again would have the certificate needed to
>>>>>>>>>
>>>>>>>validate
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>CRL signing key.
>>>>>>>>>>
>>>>>>>>>>In the case of an indirect CRL, things may not work as well.
>>>>>>>>>
> If
> 
>>>>>>>>indirect
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>CRLs were used, and the PKI architecture resembled figures 2
>>>>>>>>>
> or
> 
>>>3
>>>
>>>
>>>>>>>>>>(replacing "New Key" with a different CA), then the set of
>>>>>>>>>>certificates pointed
>>>>>>>>>
>>>>>>>to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>by
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>the AIA extension in the EE certificate would not include the
>>>>>>>>>
>>>>>>>>certificate
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>of
>>>>>>>>>>the CRL signer.  One could find this certificate by building
>>>>>>>>>
> in
> 
>>>the
>>>
>>>
>>>>>>>>>>reverse direction and using the SIA extension, but that may
>>>>>>>>>
> not
> 
>>>be
>>>
>>>
>>>>>>>>>>the most convenient solution.
>>>>>>>>>>
>>>>>>>>>>So, when indirect CRLs are being used, it seems that it would
>>>>>>>>>
> be
> 
>>>>>>>very
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>useful
>>>>>>>>>>to have a pointer in the CRL to the CRL signing certificate.
>>>>>>>>>
>>>When
>>>
>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>CRL
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>is not indirect, the need for this pointer does not seem to be
>>>>>>>>>
>>>as
>>>
>>>
>>>>>>>clear,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>but
>>>>>>>>>>I can't see any harm in including it.
>>>>>>>>>>
>>>>>>>>>>Dave
>>>>>>>>>>
>>>>>>>>>>Stefan Santesson wrote:
>>>>>>>>>>All,
>>>>>>>>>>
>>>>>>>>>>I'm interested in the opinion from members on this list about
>>>>>>>>>
>>>>>>>discovery
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>of
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>CRL signer's certificate in non directory centric
>>>>>>>>>
> environments.
> 
>>>>>>>>>>The problem is the following.
>>>>>>>>>>
>>>>>>>>>>The relying party (RP) needs to check validity of a
>>>>>>>>>
> certificate
> 
>>>and
>>>
>>>
>>>>>>>>finds
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>a
>>>>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL
>>>>>>>>>>which
>>>>>>>>>
>>>>>>>in
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>this
>>>>>>>>>>particular case is either signed by another key of the CA
>>>>>>>>>
>>>(re-keyed
>>>
>>>
>>>>>>>CA)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>or
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>another entity (indirect CRL).
>>>>>>>>>>
>>>>>>>>>>In this case the relying party needs to obtain the certificate
>>>>>>>>>
>>>of
>>>
>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>CRL
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>signer which may NOT be part of the original chain. In a
>>>>>>>>>
>>>directory
>>>
>>>
>>>>>>>>centric
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>solution this is retrieved from the directory, but what if
>>>>>>>>>
> such
> 
>>>>>>>>directory
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>is
>>>>>>>>>>not available or accessible.
>>>>>>>>>>
>>>>>>>>>>The RP have thus no hint where to find the CRL issuers
>>>>>>>>>
>>>certificate
>>>
>>>
>>>>>>>>unless
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>the RP already have possession of it by some other means.
>>>>>>>>>>
>>>>>>>>>>Is seems that CRLs would need an AIA extension with the option
>>>>>>>>>
>>>to
>>>
>>>
>>>>>>>point
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>to
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>the location of the signers certificate in the same manner as
>>>>>>>>>
> is
> 
>>>>>>>>possible
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>for certificates.
>>>>>>>>>>
>>>>>>>>>>Maybe AIA should be defined as both cert and CRL extension and
>>>>>>>>>
>>>not
>>>
>>>
>>>>>>>only
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>certificate extension as today.
>>>>>>>>>>
>>>>>>>>>>Thoughts and comments?
>>>>>>>>>>
>>>>>>>>>>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 i9I8oVJU030744; Mon, 18 Oct 2004 01:50:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9I8oVpT030743; Mon, 18 Oct 2004 01:50:31 -0700 (PDT)
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 i9I8oTib030666 for <[e-mail]>; Mon, 18 Oct 2004 01:50:30 -0700 (PDT) (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.0); Mon, 18 Oct 2004 09:50:25 +0100
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: Signer certificate discovery for CRLs
Date: Mon, 18 Oct 2004 09:49:45 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcSyzCYWMjKp/h2IQY2PFH0AA4RwNQAiPPxQ
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Santosh Chokhani" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 18 Oct 2004 08:50:25.0057 (UTC) FILETIME=[825D9110:01C4B4EF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9I8oUib030735
Sender: [e-mail]
Precedence: 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, 

If I get you right you mean that one can always successfully use AIA and
SIA in certs to solve discovery of CRL signer cert.
Others on this list (me included) don't understand how. It would
therefore be useful if you told us.


I'll try to explain the problem from my perspective one more time.
Note: "->" in these examples means "issued by"


Case 1 - indirect CRL:

Cert path is:  EE_Cert -> CA_1 -> Root-CA
CRL path for EE_Cert is:  CRL -> CRL_Issuer_B -> Root-CA

Scenario: 
Relying party has access to the cert path, discovers the CRL through CDP
in EE_Cert. The RP searches the location specified in SIA through
id-ad-caRepository in the CA_1 cert but finds nothing useful since
revocation is subordinated to another entity (CRL_Issuer_B)

In this case, the problem could be solved if an AIA in the CRL indicated
the access location of the CRL Issuer cert.



Case 2 - re-keyed CA.

Cert path is:  EE_Cert -> CA_1(old key) -> Root-CA
CRL path for EE_Cert is:  CRL -> CA_1(new key) -> Root-CA

The 2 CA_1 certificates above (old key and new key) are issued to
different subject keys belonging to the same CA (same name).
The cert CA_1(old key) was issued before creation of cert CA_1(new key)
and have thus no reference to CA_1(new key) in its SIA

Scenario:
RP discovers the CRL for the EE_Cert through the CDP but doesn't possess
the CRL issuer cert. The RP client searches the SIA of the CA_1(old key)
but finds no direct reference to the CRL signer cert. Since the RP
client has no access to a directory where the CRL signer cert could be
found through directory lookup, cert validation fails.

In this scenario the problem could be solved through an AIA in the CRL.
 


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 15 oktober 2004 17:30
> To: Stefan Santesson
> Cc: Santosh Chokhani; pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> > Denis,
> 
> > Unfortunately I fail to understand your questions, issues and
requests.
> 
> The sentence below demonstrates that you understand the issue.
> 
> > It would be very useful if you could explain how current mechanisms
can
> > be used in a simple and straightforward manner to discover CRL
signer
> > certificates in ALL the use cases discussed, mainly re-keyed CA and
> > indirect CRLs.
> 
> You are also reversing the question. Using your terms, my question
would
> be:
> 
> "It would be very useful if you could explain how current mechanisms
> CANNOT
> be used in a simple and straightforward manner to discover CRL signer
> certificates in ONE or MORE the use cases discussed, mainly re-keyed
CA
> and
> indirect CRLs."
> 
> Denis
> 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >
> >>-----Original Message-----
> >>From: [e-mail]
> >
> > [mailto:[e-mail]]
> >
> >>On Behalf Of Denis Pinkas
> >>Sent: den 14 oktober 2004 17:13
> >>To: Santosh Chokhani
> >>Cc: 'pkix'
> >>Subject: Re: Signer certificate discovery for CRLs
> >>
> >>
> >>Santosh,
> >>
> >>
> >>>Denis:
> >>
> >>>With the three assumptions/constraints I provided, how would you
> >>
> > locate
> >
> >>the
> >>
> >>>CRL issuer certificate for the two examples using 3280 extensions
> >>
> > and
> >
> >>>without putting AIA in the CRL?
> >>
> >>As far as I understand, the three assumptions are:
> >>
> >>1.  You are directory challenged; and
> >>     [I do not understand what this means]
> >>2.  You use AIA to develop the path; and
> >>     [It does not matter]
> >>3.  You develop the path from the end entity to trust anchor
> >>     [Could also be the contrary].
> >>
> >>If this is not correct, thus please correct.
> >>
> >>Then my request is: "using ANY OF the current extensions that are
> >
> > defined
> >
> >>in
> >>RFC 3280", which includes SIA.
> >>
> >>In your explanations  you said :
> >>"if you do no deal with SIA et. al"
> >>
> >>This last assumption is neither part of the three assumptions and
does
> >
> > not
> >
> >>conform to my request.
> >>
> >>Denis
> >>
> >>
> >>>That is my point.
> >>>
> >>>-----Original Message-----
> >>>From: Denis Pinkas [mailto:[e-mail]]
> >>>Sent: Thursday, October 14, 2004 6:22 AM
> >>>To: Santosh Chokhani
> >>>Cc: 'pkix'
> >>>Subject: Re: Signer certificate discovery for CRLs
> >>>
> >>>
> >>>Santosh,
> >>>
> >>>You misread my request. I said:
> >>>
> >>>"For the time being, I would like that you provide an example
where,
> >>
> >>when
> >>
> >>>using the current extensions that are defined in RFC 3280, it will
> >>
> > NOT
> >
> >>be
> >>
> >>>possible to locate a CRL Issuer certificate."
> >>>
> >>>Maybe I would have needed to be clearer and say :
> >>>
> >>>"For the time being, I would like that you provide an example
where,
> >>
> >>when
> >>
> >>>using ANY OF the current extensions that are defined in RFC 3280,
it
> >>
> >>will
> >>
> >>>NOT be possible to locate a CRL Issuer certificate."
> >>>
> >>>The examples you provide below do not fulfil this request.
> >>>
> >>>The assumption is that there exists a path to be tested for
> >>
> > revocation
> >
> >>>checking (and that it does not matter to know which way it has been
> >>>constructed).
> >>>
> >>>I am not saying that using AIA in CRL might not be useful, but I am
> >>
> >>still
> >>
> >>>lacking the demonstration that there would be no other way.
> >>>
> >>>Denis
> >>>
> >>>
> >>>
> >>>
> >>>>Denis:
> >>>>
> >>>>Two examples are very simple: one for direct CRL Issuer and one
for
> >>>>Indirect CRL Issuer.
> >>>>
> >>>>Let us make the following assumptions that Stefan was making:
> >>>>
> >>>>1.  You are directory challenged; and
> >>>>2.  You use AIA to develop the path; and
> >>>>3.  You develop the path from the end entity to trust anchor.
> >>>>
> >>>
> >>>>From what I know of MS CAPI, these are reasonable
> >>>
> >>>>assumptions/constraints.
> >>>>
> >>>>Now the examples.
> >>>>
> >>>>Example 1: Direct CRL Issuer
> >>>>
> >>>>The certificate trust path is:
> >>>>Root --> CA1 --> CA 2, old key --> Denis
> >>>>
> >>>>The CRL trust path is:
> >>>>Root --> CA1 --> CA 2, new key --> CRL
> >>>>
> >>>>(Note: We do not do self-issued certificate since there is no
> >>>
> > simple,
> >
> >>>>secure way to check their revocation status).
> >>>>
> >>>>Now, with AIA in CRL, finding the CA2, new key certificate is
> >>>>straightforward.  How would you find it if you do no deal with SIA
> >>>
> > et.
> >
> >>>>al.
> >>>>
> >>>>Example 2: Indirect CRL Issuer
> >>>>
> >>>>The certificate trust path is:
> >>>>Root --> CA1 --> CA 2 --> Denis
> >>>>(Note: Denis's certificate points to CRL DP of an indirect CRL
> >>>
> > issued
> >
> >>>>by CAI.
> >>>>
> >>>>The CRL trust path is:
> >>>>Root --> CAI --> CRL
> >>>>
> >>>>Now, with AIA in CRL, finding the CAI certificate is
> >>>
> > straightforward.
> >
> >>>>How would you find it if you do no deal with SIA et. al.
> >>>>
> >>>>In addition to the need cited above, please note that the
extension
> >>>>semantics does not change, it does not hinder any
interoperability,
> >>>>and it does not break any backward compatibility.  So, what if I
> >>>>wanted to use this extension in the CRL.  It does no harm to other
> >>>>relying parties.
> >>>>
> >>>>-----Original Message-----
> >>>>From: [e-mail]
> >>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
> >>>>Sent: Wednesday, October 13, 2004 11:01 AM
> >>>>To: Stefan Santesson
> >>>>Cc: Santosh Chokhani; pkix
> >>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>
> >>>>
> >>>>
> >>>>Stefan,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Denis,
> >>>>
> >>>>
> >>>>>I'm not sure what you mean.
> >>>>
> >>>>
> >>>>For the time being, I would like that you provide an example
where,
> >>>>when
> >>>>using the current extensions that are defined in RFC 3280, it will
> >>>
> > NOT
> >
> >>be
> >>
> >>>>possible to locate a CRL Issuer certificate.
> >>>>
> >>>>If you are able to provide that example, then it would justify the
> >>>>need for
> >>>>an extension at least for one case. Then we can see what that case
> >>>
> > is.
> >
> >>>>I am awaiting that example.
> >>>>
> >>>>Denis
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>I conclude that I agree with Santosh.
> >>>>>
> >>>>>The debate is still open... Feel free to express your opinion.
> >>>>>
> >>>>>Stefan Santesson
> >>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: Denis Pinkas [mailto:[e-mail]]
> >>>>>>Sent: den 13 oktober 2004 16:34
> >>>>>>To: Stefan Santesson
> >>>>>>Cc: Santosh Chokhani; pkix
> >>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>
> >>>>>>Stefan,
> >>>>>>
> >>>>>>You are making a conclusion without letting me the time to
> >>>>>
> > respond. I
> >
> >>>>>>will need more time to look at the pictures (and understand
them).
> >>>>>>
> >>>>>>For the time being, I am still reluctant to accept
> >>>>>
> >>>>>"yet-another-method".
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>We already have too many.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Santosh,
> >>>>>>>
> >>>>>>>I conclude that we are in complete and total agreement.
> >>>>>>>The question is how to go about this.
> >>>>>>
> >>>>>>>Could we do this amendment to RFC 3280 in its next revision? It
> >>>>>>>would hopefully just be a minor change.
> >>>>>>
> >>>>>>This is exactly what I feared.
> >>>>>>
> >>>>>>We usually end-up with a "minor change" in an extension without
> >>>>>>saying cleary how and when it shall/should be used.
> >>>>>>
> >>>>>>I still have in mind that:
> >>>>>>
> >>>>>>1) a certification path must first be constructed,
> >>>>>>2) then the revocation checking of that path must be done.
> >>>>>>
> >>>>>>This means that information about CRL issuers certificates
> >>>>>
> > locations
> >
> >>>>>may
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>certainly be found in that chain. If not, I would like an
example.
> >>>>>>
> >>>>>>Denis
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>It would not change the definition of AIA just add that it can
be
> >>>>>>
> >>>>>used
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>also as CRL extension and list eventual restrictions and
guidance
> >>>>>
> > for
> >
> >>>>>use
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>with CRLs.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Stefan Santesson
> >>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: [e-mail]
> >>>>>>>
> >>>>>[mailto:[e-mail]]
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>On Behalf Of Santosh Chokhani
> >>>>>>>>Sent: den 13 oktober 2004 04:33
> >>>>>>>>To: 'pkix'
> >>>>>>>>Subject: RE: Signer certificate discovery for CRLs
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>Stefan:
> >>>>>>>>
> >>>>>>>>In terms of certificate discovery, your proposal for AIA in
CRL
> >>>>>>>
> > is
> >
> >>>>>more
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>robust.  The whole idea of self-issued key rollover
certificates
> >>>>>>>>and
> >>>>>>>
> >>>>>>then
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>using the new key to issue CRL is fraught with security
> >>>>>>>
> > problems.
> >
> >>>>>>>>A secure solution would be one where the new key is certified
by
> >>>>>>>>the parent
> >>>>>>>
> >>>>>CA.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>In
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>that case to obtain the new certificate, you could use AIA in
> >>>>>>>
> > CRL.
> >
> >>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP
in
> >>>>>>>>certificate in question points to the indirect CRL.  You get
> >>>>>>>
> > that
> >
> >>>>>>>>CRL.  The AIA
> >>>>>>>
> >>>>>in
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>CRL
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>gets you started for the indirect CRL issuer certification
path
> >>>>>>>
> > and
> >
> >>>>>you
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>are
> >>>>>>>>in business.
> >>>>>>>>
> >>>>>>>>-----Original Message-----
> >>>>>>>>From: [e-mail]
> >>>>>>>
> >>>>>[mailto:[e-mail]]
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>On
> >>>>>>>>Behalf Of Stefan Santesson
> >>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
> >>>>>>>>To: David A. Cooper
> >>>>>>>>Cc: pkix
> >>>>>>>>Subject: RE: Signer certificate discovery for CRLs
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>David,
> >>>>>>>>
> >>>>>>>>Thanks for the clarifications, they make sense.
> >>>>>>>>I did misread your pictures.
> >>>>>>>>
> >>>>>>>>So can we conclude that for a re-keyed CA in accordance with
RFC
> >>>>>>>
> >>>>>3280,
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>either the CRL issuer certificate itself, or the location of
the
> >>>>>>>>CRL issuer certificate, will be clearly identified/available
for
> >>>>>>>>the validating
> >>>>>>>
> >>>>>>party
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>in some cases, but not in others?
> >>>>>>>>
> >>>>>>>>Can we also conclude that there is no real discovery solution
> >>>>>>>
> > for
> >
> >>>>>>indirect
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>CRLs?
> >>>>>>>>
> >>>>>>>>Do you then agree then that it could be appropriate to allow
AIA
> >>>>>>>
> > as
> >
> >>>>>a
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>CRL
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>extension to facilitate discovery of CRL signer certificate?
> >>>>>>>>
> >>>>>>>>Stefan Santesson
> >>>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>>
> >>>>>>>>________________________________________
> >>>>>>>>From: David A. Cooper [mailto:[e-mail]]
> >>>>>>>>Sent: den 12 oktober 2004 21:14
> >>>>>>>>To: Stefan Santesson
> >>>>>>>>Cc: pkix
> >>>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>>
> >>>>>>>>Stefan,
> >>>>>>>>
> >>>>>>>>I believe that you are misinterpreting the figures.  They
really
> >>>>>>>
> > do
> >
> >>>>>>>>represent three different cases, not three different
> >>>>>>>
> > certification
> >
> >>>>>paths
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>that have been constructed through the same PKI architecture.
> >>>>>>>>
> >>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
> >>>>>>>
> >>>>>certificates.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>The
> >>>>>>>>Root CA has issued a certificate to CA 1's new key, but not
its
> >>>>>>>
> > old
> >
> >>>>>key
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>(either the Root CA never issued a certificate to CA 1's old
key
> >>>>>>>
> > or
> >
> >>>>>that
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>certificate has expired).
> >>>>>>>>
> >>>>>>>>In figure 2, CA 2 has also generated self-issued key rollover
> >>>>>>>>certificates. The Root CA has issued a certificate to CA 2's
old
> >>>>>>>>key, but not its
> >>>>>>>
> >>>>>new
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>key.
> >>>>>>>>
> >>>>>>>>In figure 3, when CA 3 performed key rollover, it requested a
> >>>>>>>
> > new
> >
> >>>>>>>>CA certificate from the Root CA.  CA 3 did not generated
> >>>>>>>>self-issued
> >>>>>>>
> >>>>>key
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>rollover certificates.
> >>>>>>>>
> >>>>>>>>Of course, another realistic scenario would be one in which a
CA
> >>>>>>>
> >>>>>>generated
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>self-issued key rollover certificates upon key rollover and
then
> >>>>>>>>had
> >>>>>>>
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>Root CA issue a CA certificate to its new key.  In this case,
as
> >>>>>>>>you suggest, any of the certification paths from figures 1, 2,
> >>>>>>>
> > or 3
> >
> >>>>>could be
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>constructed.
> >>>>>>>>
> >>>>>>>>As for the contents of the AIA extension, here is what I have
> >>>>>>>
> >>>>>specified
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>in
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the
Common
> >>>>>>>
> >>>>>>Policy":
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>The authorityInfoAccess extension uses URIs for two purposes.
> >>>>>>>
> > When
> >
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>id-ad-caIssuers access method is used, the access location
> >>>>>>>>specifies
> >>>>>>>
> >>>>>>where
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>certificates issued to the issuer of the certificate may be
> >>>>>>>
> > found.
> >
> >>>>>If
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>LDAP
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>is used, the URI must include the DN of the entry containing
the
> >>>>>>>
> >>>>>>relevant
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>certificates and specify the directory attribute in which the
> >>>>>>>
> >>>>>>certificates
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>are located. If the directory in which the certificates are
> >>>>>>>
> > stored
> >
> >>>>>>expects
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>the "binary" option to be specified, then the attribute type
> >>>>>>>
> > must
> >
> >>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the URI
> >>>>>>>
> > must
> >
> >>>>>point to
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>a
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>file that has an extension of ".p7c" that contains a
certs-only
> >>>>>>>
> > CMS
> >
> >>>>>>>>message (see RFC 2633). The CMS message should include all
> >>>>>>>>certificates
> >>>>>>>
> >>>>>issued
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>to
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>the issuer of this certificate, but must at least contain all
> >>>>>>>
> >>>>>>certificates
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>issued to the issuer of this certificate in which the subject
> >>>>>>>>public
> >>>>>>>
> >>>>>key
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>may
> >>>>>>>>be used to verify the signature on this certificate. .... For
a
> >>>>>>>>certificate issued by "Good CA", some examples of URIs that
may
> >>>>>>>>appear as the
> >>>>>>>
> >>>>>access
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>location in an authorityInfoAccess extension when the
> >>>>>>>
> >>>>>id-ad-caIssuers
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>access
> >>>>>>>>method is used are:
> >>>>>>>
>
>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cAC
e
> >>>>>
> > r
> >
> >>>>>>>t
> >>>>>>>i
> >>>>>>
> >>>>>fi
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>ca
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>te
> >>>>>>>>,crossCertificatePair
> >>>>>>>
>
>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACerti
f
> >>>>>
> > i
> >
> >>>>>>>c
> >>>>>>>a
> >>>>>>
> >>>>>te
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>;b
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>in
> >>>>>>>>ary,crossCertificatePair;binary
> >>>>>>>
>
>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIs
s
> >>>>>
> > u
> >
> >>>>>>>e
> >>>>>>>d
> >>>>>>
> >>>>>To
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Go
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>od
> >>>>>>>>CA.p7c
> >>>>>>>>For both LDAP and HTTP, the URI provides the exact location
> >>>>>>>
> > where
> >
> >>>>>>>>information is to be located, so there is no requirement for
the
> >>>>>>>
> >>>>>relying
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>party to try to figure out where information is located.
> >>>>>>>>
> >>>>>>>>The HTTP URI points to a certs-only CMS message that includes
> >>>>>>>
> > all
> >
> >>>>>>>>certificates issued to the CA identified in the issuer field
of
> >>>>>>>
> > the
> >
> >>>>>>>>certificate.
> >>>>>>>>
> >>>>>>>>The LDAP URI points to the cACertificate and
> >>>>>>>
> > crossCertificatePair
> >
> >>>>>>>>attributes of the directory entry of the CA identified in the
> >>>>>>>>issuer field of
> >>>>>>>
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>certificate.  These two attributes together hold all of the
> >>>>>>>
> >>>>>certificates
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>issued to the CA:  the cACertificate attribute holds the CA's
> >>>>>>>
> > self-
> >
> >>>>>>issued
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>certificates and the crossCertificatePair attribute holds the
> >>>>>>>>cross-certificates issued to the CA by other CAs.
> >>>>>>>>
> >>>>>>>>Dave
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>Stefan Santesson wrote:
> >>>>>>>>
> >>>>>>>>David,
> >>>>>>>>
> >>>>>>>>Thanks for these good thoughts and very useful scenarios.
> >>>>>>>>
> >>>>>>>>I have some comments and questions on this.
> >>>>>>>>
> >>>>>>>>First of all we can conclude that in some scenarios (figure 1)
> >>>>>>>>where
> >>>>>>>
> >>>>>a
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>self
> >>>>>>>>issued certificate is inserted into the path, you are likely
to
> >>>>>>>>find
> >>>>>>>
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>CRL
> >>>>>>>>issuer cert in the path. (given that the new CA have a common
> >>>>>>>
> > key
> >
> >>>>>and
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>certificate for cert signing and CRL signing).
> >>>>>>>>
> >>>>>>>>Figure 1, 2 and 3 describe the same case. It is just
describing
> >>>>>>>
> >>>>>>different
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>path building strategies. An application that has access
locally
> >>>>>>>
> > to
> >
> >>>>>all
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>chaining options may however still choose path 2 for the certs
> >>>>>>>
> > and
> >
> >>>>>path
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>1
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>for the CRL independent of each other (which I think figure 3
> >>>>>>>
> > tries
> >
> >>>>>to
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>describe)
> >>>>>>>>
> >>>>>>>>Another comment is the structure of AIA extensions. The use
I'm
> >>>>>>>
> >>>>>familiar
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>with doesn't use AIA to describe a directory entry where it is
> >>>>>>>
> > left
> >
> >>>>>to
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>the
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>validation application logic to be intelligent enough to find
> >>>>>>>
> >>>>>>appropriate
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>certificate data from the directory. The model I'm familiar
with
> >>>>>>>
> > is
> >
> >>>>>when
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>the
> >>>>>>>>AIA URL explicitly identifies the exact location of the
> >>>>>>>
> > appropriate
> >
> >>>>>CA
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>certificate file, relieving the validation software from
complex
> >>>>>>>>information queries. If just location of explicit certificate
> >>>>>>>
> > files
> >
> >>>>>>>>are
> >>>>>>>
> >>>>>identified
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>through AIA, the presence of an AIA may not help finding the
CRL
> >>>>>>>
> >>>>>signer
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>cert
> >>>>>>>>if this is different from the CA certificate. This is also the
> >>>>>>>
> >>>>>problem
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>with
> >>>>>>>>Denis proposal.
> >>>>>>>>
> >>>>>>>>I think we share the basic conclusion that the ability to
locate
> >>>>>>>>the
> >>>>>>>
> >>>>>CRL
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>signer certificate directly through the CRL could be very
> >>>>>>>
> > useful.
> >
> >>>>>>>>At
> >>>>>>>
> >>>>>>least
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>in the case of indirect CRL but it could also be proven very
> >>>>>>>
> > useful
> >
> >>>>>in
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>CA
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>re-keying scenarios.
> >>>>>>>>
> >>>>>>>>The easiest solution would probably be to allow AIA to be used
> >>>>>>>
> > in
> >
> >>>>>its
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>current shape and structure as a CRL extension (MUST NOT be
> >>>>>>>
> >>>>>critical).
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>It
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>would present a very clear and uncomplicated logic to
> >>>>>>>
> > certificate
> >
> >>>>>>>>validating applications in many cases.
> >>>>>>>>
> >>>>>>>>Stefan Santesson
> >>>>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>>>
> >>>>>>>>________________________________________
> >>>>>>>>From: David A. Cooper [mailto:[e-mail]]
> >>>>>>>>Sent: den 7 oktober 2004 18:35
> >>>>>>>>To: Stefan Santesson
> >>>>>>>>Cc: pkix
> >>>>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>>>
> >>>>>>>>Stefan,
> >>>>>>>>
> >>>>>>>>I think what you are proposing is a good idea.  In most cases,
> >>>>>>>
> > path
> >
> >>>>>>>>discovery algorithms assume that both the trust anchor (or
trust
> >>>>>>>
> >>>>>>anchors)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>and the end entity certificate are provided as input.  In this
> >>>>>>>>case,
> >>>>>>>
> >>>>>one
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>may
> >>>>>>>>need to construct a certification path without a priori access
> >>>>>>>
> > to
> >
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>end
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>entity certificate (the one with the subject public key
> >>>>>>>
> >>>>>corresponding to
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>the
> >>>>>>>>CRL signing key).  Including an AIA extension (or some other
> >>>>>>>
> >>>>>pointer) in
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>the
> >>>>>>>>CRL would provide the relying party with a simple way to
obtain
> >>>>>>>
> > the
> >
> >>>>>end
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>entity certificate for the CRL signing key's certification
path.
> >>>>>>>
> > On
> >
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>other hand, I believe that a relying party should be able to
> >>>>>>>
> >>>>>construct
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>the
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>certification path even without an AIA extension in the CRL,
so
> >>>>>>>>long
> >>>>>>>
> >>>>>as
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>it
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>is not an indirect CRL.  Attached is a drawing of the three
> >>>>>>>
> > basic
> >
> >>>>>>>>scenarios that I expect a relying party may encounter:
> >>>>>>>>
> >>>>>>>>In each of these scenarios, the CA has performed key rollover
> >>>>>>>
> > and
> >
> >>>>>>>>is
> >>>>>>>
> >>>>>>only
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>signing CRLs with its new key.  The diagrams would look
similar,
> >>>>>>>
> >>>>>>however,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>if
> >>>>>>>>the CA simply choose to use different keys to sign
certificates
> >>>>>>>
> > and
> >
> >>>>>CRLs
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>for
> >>>>>>>>some other reason.
> >>>>>>>>
> >>>>>>>>If the PKI architecture resembled figure 1, then the
> >>>>>>>
> > certification
> >
> >>>>>path
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>for
> >>>>>>>>the CRL signing key would just be a subset of the
certification
> >>>>>>>>path
> >>>>>>>
> >>>>>for
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>the
> >>>>>>>>EE certificate, so no addition path discovery would be needed.
> >>>>>>>>
> >>>>>>>>If the PKI architecture resembled figure 1, then it would be
> >>>>>>>
> >>>>>necessary
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>to
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>obtain the new-signed-with-old self-issued certificate.  In
> >>>>>>>>building
> >>>>>>>
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>certification path to the EE certificate, however, the relying
> >>>>>>>>party
> >>>>>>>
> >>>>>>will
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>obtain the certificates pointed to by the AIA extension in the
> >>>>>>>
> > EE
> >
> >>>>>>>>certificate.  This AIA extension will point to a location
> >>>>>>>>containing
> >>>>>>>
> >>>>>all
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>certificates issued to CA 2, which would include both the
> >>>>>>>
> >>>>>certificate
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>issued
> >>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So,
> >>>>>>>
> > even
> >
> >>>>>though
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>the
> >>>>>>>>self-issued certificate would not be part of the certification
> >>>>>>>
> > path
> >
> >>>>>to
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>the
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>EE certificate, it would be downloaded by the relying party
> >>>>>>>
> > during
> >
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>construction of that certification path.  (Yes, there are
> >>>>>>>
> > circular
> >
> >>>>>>>>dependency issues in figure 2, but that is another issue.)
> >>>>>>>>
> >>>>>>>>A similar situation would happen if the PKI architecture
> >>>>>>>
> > resembled
> >
> >>>>>>figure
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>3.  The AIA extension in the EE certificate would point to a
> >>>>>>>
> >>>>>location
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>containing certificates issued to CA 3.  When the relying
party
> >>>>>>>
> >>>>>>downloaded
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>these certificates, it would obtain both of the certificates
> >>>>>>>
> > issued
> >
> >>>>>by
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>the
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>Root to CA 3 and so again would have the certificate needed to
> >>>>>>>
> >>>>>validate
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>the
> >>>>>>>>CRL signing key.
> >>>>>>>>
> >>>>>>>>In the case of an indirect CRL, things may not work as well.
If
> >>>>>>>
> >>>>>>indirect
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>CRLs were used, and the PKI architecture resembled figures 2
or
> >>>>>>>
> > 3
> >
> >>>>>>>>(replacing "New Key" with a different CA), then the set of
> >>>>>>>>certificates pointed
> >>>>>>>
> >>>>>to
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>by
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>the AIA extension in the EE certificate would not include the
> >>>>>>>
> >>>>>>certificate
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>of
> >>>>>>>>the CRL signer.  One could find this certificate by building
in
> >>>>>>>
> > the
> >
> >>>>>>>>reverse direction and using the SIA extension, but that may
not
> >>>>>>>
> > be
> >
> >>>>>>>>the most convenient solution.
> >>>>>>>>
> >>>>>>>>So, when indirect CRLs are being used, it seems that it would
be
> >>>>>>>
> >>>>>very
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>useful
> >>>>>>>>to have a pointer in the CRL to the CRL signing certificate.
> >>>>>>>
> > When
> >
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>CRL
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>is not indirect, the need for this pointer does not seem to be
> >>>>>>>
> > as
> >
> >>>>>clear,
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>but
> >>>>>>>>I can't see any harm in including it.
> >>>>>>>>
> >>>>>>>>Dave
> >>>>>>>>
> >>>>>>>>Stefan Santesson wrote:
> >>>>>>>>All,
> >>>>>>>>
> >>>>>>>>I'm interested in the opinion from members on this list about
> >>>>>>>
> >>>>>discovery
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>of
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>CRL signer's certificate in non directory centric
environments.
> >>>>>>>>
> >>>>>>>>The problem is the following.
> >>>>>>>>
> >>>>>>>>The relying party (RP) needs to check validity of a
certificate
> >>>>>>>
> > and
> >
> >>>>>>finds
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>a
> >>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL
> >>>>>>>>which
> >>>>>>>
> >>>>>in
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>this
> >>>>>>>>particular case is either signed by another key of the CA
> >>>>>>>
> > (re-keyed
> >
> >>>>>CA)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>or
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>another entity (indirect CRL).
> >>>>>>>>
> >>>>>>>>In this case the relying party needs to obtain the certificate
> >>>>>>>
> > of
> >
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>CRL
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>signer which may NOT be part of the original chain. In a
> >>>>>>>
> > directory
> >
> >>>>>>centric
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>solution this is retrieved from the directory, but what if
such
> >>>>>>>
> >>>>>>directory
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>is
> >>>>>>>>not available or accessible.
> >>>>>>>>
> >>>>>>>>The RP have thus no hint where to find the CRL issuers
> >>>>>>>
> > certificate
> >
> >>>>>>unless
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>the RP already have possession of it by some other means.
> >>>>>>>>
> >>>>>>>>Is seems that CRLs would need an AIA extension with the option
> >>>>>>>
> > to
> >
> >>>>>point
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>to
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>the location of the signers certificate in the same manner as
is
> >>>>>>>
> >>>>>>possible
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>for certificates.
> >>>>>>>>
> >>>>>>>>Maybe AIA should be defined as both cert and CRL extension and
> >>>>>>>
> > not
> >
> >>>>>only
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>certificate extension as today.
> >>>>>>>>
> >>>>>>>>Thoughts and comments?
> >>>>>>>>
> >>>>>>>>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 i9I86jGU014607; Mon, 18 Oct 2004 01:06:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9I86j6u014606; Mon, 18 Oct 2004 01:06:45 -0700 (PDT)
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 i9I86fxe014549 for <[e-mail]>; Mon, 18 Oct 2004 01:06:43 -0700 (PDT) (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 KAA42612; Mon, 18 Oct 2004 10:18:02 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101810061836:1614 ; Mon, 18 Oct 2004 10:06:18 +0200 
Message-ID: <[e-mail]>
Date: Mon, 18 Oct 2004 10:04:33 +0200
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: Santosh Chokhani <[e-mail]>, [e-mail]
Subject: Re: Signer certificate discovery for CRLs
References: <000301c4b29a$f3450130$[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 18/10/2004 10:06:18, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/10/2004 10:06:21, Serialize complete at 18/10/2004 10:06: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>

Russ,

> Denis:
> 
>> I still wonder why you are making this restriction since LDAP is one 
>> of the only two methods that are supported in RFC 3280 to fetch 
>> certificates.
> 
> 
> This is simply not true.  When a GeneralName is used, the URI schemes 
> ftp, http, and ldap are explicitly discussed for fetching certificates.  
> When a GeneralName is rfc822name, email is discussed.  And, the 
> mailtoURI scheme is discussed for fetching CRLs.
> 
> The Directory Access Protocol (DAP) is also discussed.

OK. DAP and LDAP.

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 i9I86T1I014496; Mon, 18 Oct 2004 01:06:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9I86TW9014494; Mon, 18 Oct 2004 01:06:29 -0700 (PDT)
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 i9I86Q2S014442 for <[e-mail]>; Mon, 18 Oct 2004 01:06:27 -0700 (PDT) (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 KAA25516; Mon, 18 Oct 2004 10:17:56 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101810061348:1613 ; Mon, 18 Oct 2004 10:06:13 +0200 
Message-ID: <[e-mail]>
Date: Mon, 18 Oct 2004 10:04:28 +0200
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]
Subject: Re: Signer certificate discovery for CRLs
References: <000301c4b29a$f3450130$[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 18/10/2004 10:06:13, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/10/2004 10:06:15, Serialize complete at 18/10/2004 10:06: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>

Russ,

> Denis:

>> If I understand you correctly, for whatever reason (which one ?), you 
>> only want to use HTTP. Then I would think the solution would be to use 
>> the following draft: draft-ietf-pkix-certstore-http-08 and make sure 
>> that it will be usable with the current AIA and SIA extensions to 
>> fetch CRL issuers certificates.

> RFC 3280 specifies the inclusion of AIA and SIA in certificates.  It is 
> not specified for the inclusion in CRLs.  I believe that the proposal is 
> to write a specification for using AIA in CRLs.

> The problem has been stated, and a proposed solution has been stated.

> If you do not think the problem really exists, please explain why this 
> is the case.  If you have another way to solve the stated problem, 
> please share it.

One solution to the problem is to place an SIA extension in root 
certificates (i.e. self-signed certificates trusted under a validation 
policy) and in every CA certificate. This is also a very useful way to build 
a certification path "going down".

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 i9FKqj2I052188; Fri, 15 Oct 2004 13:52:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FKqjOd052187; Fri, 15 Oct 2004 13:52:45 -0700 (PDT)
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 i9FKqiHM052180 for <[e-mail]>; Fri, 15 Oct 2004 13:52:44 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (PPP-219.65.51.25.mum2.vsnl.net.in [219.65.51.25]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9FKqU3q005898 for <[e-mail]>; Fri, 15 Oct 2004 16:52:41 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Fri, 15 Oct 2004 16:52:24 -0400
Message-ID: <005401c4b2f8$eaaf7f60$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9FKqjHM052182
Sender: [e-mail]
Precedence: 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 my responses in-line in [SC].

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Friday, October 15, 2004 7:59 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs


Santosh,

> Denis:
> 
> 1.  This is a good mechanism to start building the path for CRL
> signer.

"There are none so deaf as those who will not hear".

This is not the point.

[SC: Please tell me how you would find the CRL signer path.]

> If you have a better alternative for directory challenged
> environments,

Your definition of "directory challenged environment" is:
"not use LDAP client or DAP or DSP to query for certificate"

I still wonder why you are making this restriction since LDAP is one of the 
only two methods that are supported in RFC 3280 to fetch certificates.

[It is common for some of the commercial environments to use local
certificate stores and caches and AIA and not use directories.  I am trying
to help meet their need.]

If I understand you correctly, for whatever reason (which one ?), you only 
want to use HTTP. Then I would think the solution would be to use the 
following draft: draft-ietf-pkix-certstore-http-08 and make sure that it 
will be usable with the current AIA and SIA extensions to fetch CRL issuers 
certificates.

[The basic point is not the transport protocol. The point is that the
relying party does not interface to a directory or repository.  That is why
certstore I-D is not applicable.]

> tell us.  Absent you showing that there is a mechanism for directory
> challenged environments that is as simple and that works, we can not 
> have a fruitful dialog.

Please, do not reverse the question.

[We have defined a mechanism that has all the properties IETF espouses.  If
you have an alternative state so.]

> 2.  Adding AIA to CRL does not impact interoperability, security or
> backward compatibility adversely.

It adds complexity with "still-another-extension" in CRLs and still another 
method for revocation checking.

[No, it does not.  If the client process AIA, it can also process this to
start the CRL signer path building.  It is optional, just like AIA in
certificates.  Compliant clients need not use this mechanism if they can
find the CRL signer certificate using other means]

> As to your argument, we could have used it few years back and not
> added AIA to the certificates either.

  ... but you didn't. This last argument does not make sense.

[It is basically saying "if the AIA can be offered an alternative to obtain
CA certificate, it can also be offered to obtain the CRL signer
certificate"]

Denis

> -----Original Message-----
> From: Denis Pinks [mailto:[e-mail]]
> Sent: Friday, October 15, 2004 2:45 AM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> You are still trying to avoid to respond to my request. So my
> temporary
> conclusion is that you have NOT demonstrated that your proposal is really 
> necessary and it is thus "yet-another-method".
> 
> 
>>Denis:
> 
> 
>>By directory challenged, I mean you do not use LDAP client or DAP or
>>DSP to query for certificate.
> 
> 
> RFC 3280. Page 46:
> 
>     The accessLocation
>     field is defined as a GeneralName, which can take several forms.
>     Where the information is available via http, ftp, or ldap,
>     accessLocation MUST be a uniformResourceIdentifier.  Where the
>     information is available via the Directory Access Protocol (DAP),
>     accessLocation MUST be a directoryName.
> 
> It is thus perfectly allowed and valid to use DAP or ldap.
> 
> 
>>The basic point is that if AIA or local store are the primary ways to
>>obtain certificates,
> 
> 
> No. Local store is of no use. AIA is one possibility, while the other
> one is
> 
> SIA.
> 
> 
>>since the CRL issuer certificate is not in any payload, AIA in CRL
>>helps obtain that certificate and start the path development process 
>>for the CRL certification path.
> 
> 
> No. You can use AIA or SIA in CA certificates, or AIA in leaf
> certificate.
> 
> Denis
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, October 14, 2004 11:13 AM
>>To: Santosh Chokhani
>>Cc: 'pkix'
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>
>>Santosh,
>>
>>
>>
>>>Denis:
>>
>>
>>>With the three assumptions/constraints I provided, how would you 
>>>locate the CRL issuer certificate for the two examples using 3280 
>>>extensions and without putting AIA in the CRL?
>>
>>
>>As far as I understand, the three assumptions are:
>>
>>1.  You are directory challenged; and
>>     [I do not understand what this means]
>>2.  You use AIA to develop the path; and
>>     [It does not matter]
>>3.  You develop the path from the end entity to trust anchor
>>     [Could also be the contrary].
>>
>>If this is not correct, thus please correct.
>>
>>Then my request is: "using ANY OF the current extensions that are
>>defined in
>>
>>RFC 3280", which includes SIA.
>>
>>In your explanations  you said :
>>"if you do no deal with SIA et. al"
>>
>>This last assumption is neither part of the three assumptions and does
>>not conform to my request.
>>
>>Denis
>>
>>
>>
>>>That is my point.
>>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[e-mail]]
>>>Sent: Thursday, October 14, 2004 6:22 AM
>>>To: Santosh Chokhani
>>>Cc: 'pkix'
>>>Subject: Re: Signer certificate discovery for CRLs
>>>
>>>
>>>Santosh,
>>>
>>>You misread my request. I said:
>>>
>>>"For the time being, I would like that you provide an example where, 
>>>when using the current extensions that are defined in RFC 3280, it 
>>>will NOT be possible to locate a CRL Issuer certificate."
>>>
>>>Maybe I would have needed to be clearer and say :
>>>
>>>"For the time being, I would like that you provide an example where, 
>>>when using ANY OF the current extensions that are defined in RFC 
>>>3280, it will NOT be possible to locate a CRL Issuer certificate."
>>>
>>>The examples you provide below do not fulfil this request.
>>>
>>>The assumption is that there exists a path to be tested for
>>>revocation checking (and that it does not matter to know which way it 
>>>has been constructed).
>>>
>>>I am not saying that using AIA in CRL might not be useful, but I am 
>>>still lacking the demonstration that there would be no other way.
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>
>>>>Denis:
>>>>
>>>>Two examples are very simple: one for direct CRL Issuer and one for
>>>>Indirect CRL Issuer.
>>>>
>>>>Let us make the following assumptions that Stefan was making:
>>>>
>>>>1.  You are directory challenged; and
>>>>2.  You use AIA to develop the path; and
>>>>3.  You develop the path from the end entity to trust anchor.
>>>>
>>>
>>>>From what I know of MS CAPI, these are reasonable
>>>
>>>
>>>>assumptions/constraints.
>>>>
>>>>Now the examples.
>>>>
>>>>Example 1: Direct CRL Issuer
>>>>
>>>>The certificate trust path is:
>>>>Root --> CA1 --> CA 2, old key --> Denis
>>>>
>>>>The CRL trust path is:
>>>>Root --> CA1 --> CA 2, new key --> CRL
>>>>
>>>>(Note: We do not do self-issued certificate since there is no
>>>>simple, secure way to check their revocation status).
>>>>
>>>>Now, with AIA in CRL, finding the CA2, new key certificate is
>>>>straightforward.  How would you find it if you do no deal with SIA 
>>>>et. al.
>>>>
>>>>Example 2: Indirect CRL Issuer
>>>>
>>>>The certificate trust path is:
>>>>Root --> CA1 --> CA 2 --> Denis
>>>>(Note: Denis's certificate points to CRL DP of an indirect CRL
>>>>issued by CAI.
>>>>
>>>>The CRL trust path is:
>>>>Root --> CAI --> CRL
>>>>
>>>>Now, with AIA in CRL, finding the CAI certificate is
>>>>straightforward. How would you find it if you do no deal with SIA 
>>>>et. al.
>>>>
>>>>In addition to the need cited above, please note that the extension
>>>>semantics does not change, it does not hinder any interoperability, 
>>>>and it does not break any backward compatibility.  So, what if I 
>>>>wanted to use this extension in the CRL.  It does no harm to other 
>>>>relying parties.
>>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>>>Sent: Wednesday, October 13, 2004 11:01 AM
>>>>To: Stefan Santesson
>>>>Cc: Santosh Chokhani; pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>
>>>>
>>>>Stefan,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Denis,
>>>>
>>>>
>>>>>I'm not sure what you mean.
>>>>
>>>>
>>>>For the time being, I would like that you provide an example where,
>>>>when using the current extensions that are defined in RFC 3280, it 
>>>>will NOT be possible to locate a CRL Issuer certificate.
>>>>
>>>>If you are able to provide that example, then it would justify the
>>>>need for an extension at least for one case. Then we can see what 
>>>>that case is.
>>>>
>>>>I am awaiting that example.
>>>>
>>>>Denis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I conclude that I agree with Santosh.
>>>>>
>>>>>The debate is still open... Feel free to express your opinion.
>>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>>Sent: den 13 oktober 2004 16:34
>>>>>>To: Stefan Santesson
>>>>>>Cc: Santosh Chokhani; pkix
>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>
>>>>>>Stefan,
>>>>>>
>>>>>>You are making a conclusion without letting me the time to
>>>>>>respond.
>>>>>>I will need more time to look at the pictures (and understand 
>>>>>>them).
>>>>>>
>>>>>>For the time being, I am still reluctant to accept
>>>>>
>>>>>"yet-another-method".
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>We already have too many.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Santosh,
>>>>>>>
>>>>>>>I conclude that we are in complete and total agreement. The 
>>>>>>>question is how to go about this.
>>>>>>
>>>>>>>Could we do this amendment to RFC 3280 in its next revision? It
>>>>>>>would hopefully just be a minor change.
>>>>>>
>>>>>>This is exactly what I feared.
>>>>>>
>>>>>>We usually end-up with a "minor change" in an extension without
>>>>>>saying cleary how and when it shall/should be used.
>>>>>>
>>>>>>I still have in mind that:
>>>>>>
>>>>>>1) a certification path must first be constructed,
>>>>>>2) then the revocation checking of that path must be done.
>>>>>>
>>>>>>This means that information about CRL issuers certificates
>>>>>>locations
>>>>>
>>>>>may
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>certainly be found in that chain. If not, I would like an example.
>>>>>>
>>>>>>Denis
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>It would not change the definition of AIA just add that it can be
>>>>>>
>>>>>used
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>also as CRL extension and list eventual restrictions and guidance 
>>>>>>for
>>>>>
>>>>>use
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>with CRLs.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Stefan Santesson
>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: [e-mail]
>>>>>>>
>>>>>[mailto:[e-mail]]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>On Behalf Of Santosh Chokhani
>>>>>>>>Sent: den 13 oktober 2004 04:33
>>>>>>>>To: 'pkix'
>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>
>>>>>>>>Stefan:
>>>>>>>>
>>>>>>>>In terms of certificate discovery, your proposal for AIA in CRL
>>>>>>>>is
>>>>>>>
>>>>>more
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>robust.  The whole idea of self-issued key rollover certificates
>>>>>>>>and
>>>>>>>
>>>>>>then
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>using the new key to issue CRL is fraught with security
>>>>>>>>problems. A secure solution would be one where the new key is 
>>>>>>>>certified by the parent
>>>>>>>
>>>>>CA.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>In
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>that case to obtain the new certificate, you could use AIA in
>>>>>>>>CRL.
>>>>>>>>
>>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
>>>>>>>>certificate in question points to the indirect CRL.  You get 
>>>>>>>>that CRL.  The AIA
>>>>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>gets you started for the indirect CRL issuer certification path 
>>>>>>>>and
>>>>>>>
>>>>>you
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>are
>>>>>>>>in business.
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: [e-mail]
>>>>>>>
>>>>>[mailto:[e-mail]]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>On
>>>>>>>>Behalf Of Stefan Santesson
>>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>>>>To: David A. Cooper
>>>>>>>>Cc: pkix
>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>David,
>>>>>>>>
>>>>>>>>Thanks for the clarifications, they make sense.
>>>>>>>>I did misread your pictures.
>>>>>>>>
>>>>>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>>>>>
>>>>>3280,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>either the CRL issuer certificate itself, or the location of the
>>>>>>>>CRL issuer certificate, will be clearly identified/available for 
>>>>>>>>the validating
>>>>>>>
>>>>>>party
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>in some cases, but not in others?
>>>>>>>>
>>>>>>>>Can we also conclude that there is no real discovery solution
>>>>>>>>for
>>>>>>>
>>>>>>indirect
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>CRLs?
>>>>>>>>
>>>>>>>>Do you then agree then that it could be appropriate to allow AIA 
>>>>>>>>as
>>>>>>>
>>>>>a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>>>>
>>>>>>>>Stefan Santesson
>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>
>>>>>>>>________________________________________
>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>Sent: den 12 oktober 2004 21:14
>>>>>>>>To: Stefan Santesson
>>>>>>>>Cc: pkix
>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>Stefan,
>>>>>>>>
>>>>>>>>I believe that you are misinterpreting the figures.  They really 
>>>>>>>>do represent three different cases, not three different 
>>>>>>>>certification
>>>>>>>
>>>>>paths
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>that have been constructed through the same PKI architecture.
>>>>>>>>
>>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>>>>
>>>>>certificates.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>The
>>>>>>>>Root CA has issued a certificate to CA 1's new key, but not its 
>>>>>>>>old
>>>>>>>
>>>>>key
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>(either the Root CA never issued a certificate to CA 1's old key 
>>>>>>>>or
>>>>>>>
>>>>>that
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate has expired).
>>>>>>>>
>>>>>>>>In figure 2, CA 2 has also generated self-issued key rollover
>>>>>>>>certificates. The Root CA has issued a certificate to CA 2's old 
>>>>>>>>key, but not its
>>>>>>>
>>>>>new
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>key.
>>>>>>>>
>>>>>>>>In figure 3, when CA 3 performed key rollover, it requested a
>>>>>>>>new CA certificate from the Root CA.  CA 3 did not generated 
>>>>>>>>self-issued
>>>>>>>
>>>>>key
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>rollover certificates.
>>>>>>>>
>>>>>>>>Of course, another realistic scenario would be one in which a CA
>>>>>>>
>>>>>>generated
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>self-issued key rollover certificates upon key rollover and then
>>>>>>>>had
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>Root CA issue a CA certificate to its new key.  In this case, as
>>>>>>>>you suggest, any of the certification paths from figures 1, 2, 
>>>>>>>>or 3
>>>>>>>
>>>>>could be
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>constructed.
>>>>>>>>
>>>>>>>>As for the contents of the AIA extension, here is what I have
>>>>>>>
>>>>>specified
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>in
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>>>>>
>>>>>>Policy":
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>The authorityInfoAccess extension uses URIs for two purposes.
>>>>>>>>When
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>id-ad-caIssuers access method is used, the access location
>>>>>>>>specifies
>>>>>>>
>>>>>>where
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificates issued to the issuer of the certificate may be
>>>>>>>>found.
>>>>>>>
>>>>>If
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>LDAP
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>is used, the URI must include the DN of the entry containing the
>>>>>>>
>>>>>>relevant
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificates and specify the directory attribute in which the
>>>>>>>
>>>>>>certificates
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>are located. If the directory in which the certificates are
>>>>>>>>stored
>>>>>>>
>>>>>>expects
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the "binary" option to be specified, then the attribute type
>>>>>>>>must be followed by ";binary" in the URI. If HTTP is used, the 
>>>>>>>>URI must
>>>>>>>
>>>>>point to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>a
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>file that has an extension of ".p7c" that contains a certs-only 
>>>>>>>>CMS message (see RFC 2633). The CMS message should include all 
>>>>>>>>certificates
>>>>>>>
>>>>>issued
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>to
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the issuer of this certificate, but must at least contain all
>>>>>>>
>>>>>>certificates
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>issued to the issuer of this certificate in which the subject
>>>>>>>>public
>>>>>>>
>>>>>key
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>may
>>>>>>>>be used to verify the signature on this certificate. .... For a
>>>>>>>>certificate issued by "Good CA", some examples of URIs that may 
>>>>>>>>appear as the
>>>>>>>
>>>>>access
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>location in an authorityInfoAccess extension when the
>>>>>>>
>>>>>id-ad-caIssuers
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>access
>>>>>>>>method is used are:
>>>>>>>
>>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cA
>>>>>>>C
>>>>>>>e
>>>>>>>r
>>>>>>>t
>>>>>>>i
>>>>>>
>>>>>fi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>ca
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>te
>>>>>>>>,crossCertificatePair
>>>>>>>
>>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACert
>>>>>>>i
>>>>>>>f
>>>>>>>i
>>>>>>>c
>>>>>>>a
>>>>>>
>>>>>te
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>;b
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>in
>>>>>>>>ary,crossCertificatePair;binary
>>>>>>>
>>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsI
>>>>>>>s
>>>>>>>s
>>>>>>>u
>>>>>>>e
>>>>>>>d
>>>>>>
>>>>>To
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Go
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>od
>>>>>>>>CA.p7c
>>>>>>>>For both LDAP and HTTP, the URI provides the exact location
>>>>>>>>where information is to be located, so there is no requirement 
>>>>>>>>for the
>>>>>>>
>>>>>relying
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>party to try to figure out where information is located.
>>>>>>>>
>>>>>>>>The HTTP URI points to a certs-only CMS message that includes
>>>>>>>>all certificates issued to the CA identified in the issuer field 
>>>>>>>>of the certificate.
>>>>>>>>
>>>>>>>>The LDAP URI points to the cACertificate and
>>>>>>>>crossCertificatePair attributes of the directory entry of the CA 
>>>>>>>>identified in the issuer field of
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate.  These two attributes together hold all of the
>>>>>>>
>>>>>certificates
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>issued to the CA:  the cACertificate attribute holds the CA's
>>>>>>>>self-
>>>>>>>
>>>>>>issued
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificates and the crossCertificatePair attribute holds the
>>>>>>>>cross-certificates issued to the CA by other CAs.
>>>>>>>>
>>>>>>>>Dave
>>>>>>>>
>>>>>>>>
>>>>>>>>Stefan Santesson wrote:
>>>>>>>>
>>>>>>>>David,
>>>>>>>>
>>>>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>>>>
>>>>>>>>I have some comments and questions on this.
>>>>>>>>
>>>>>>>>First of all we can conclude that in some scenarios (figure 1)
>>>>>>>>where
>>>>>>>
>>>>>a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>self
>>>>>>>>issued certificate is inserted into the path, you are likely to
>>>>>>>>find
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>CRL
>>>>>>>>issuer cert in the path. (given that the new CA have a common
>>>>>>>>key
>>>>>>>
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate for cert signing and CRL signing).
>>>>>>>>
>>>>>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>>>>>
>>>>>>different
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>path building strategies. An application that has access locally 
>>>>>>>>to
>>>>>>>
>>>>>all
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>chaining options may however still choose path 2 for the certs
>>>>>>>>and
>>>>>>>
>>>>>path
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>1
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>for the CRL independent of each other (which I think figure 3 
>>>>>>>>tries
>>>>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>describe)
>>>>>>>>
>>>>>>>>Another comment is the structure of AIA extensions. The use I'm
>>>>>>>
>>>>>familiar
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>with doesn't use AIA to describe a directory entry where it is 
>>>>>>>>left
>>>>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>validation application logic to be intelligent enough to find
>>>>>>>
>>>>>>appropriate
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificate data from the directory. The model I'm familiar with 
>>>>>>>>is
>>>>>>>
>>>>>when
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>AIA URL explicitly identifies the exact location of the 
>>>>>>>>appropriate
>>>>>>>
>>>>>CA
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate file, relieving the validation software from complex
>>>>>>>>information queries. If just location of explicit certificate 
>>>>>>>>files are
>>>>>>>
>>>>>identified
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>>>>>
>>>>>signer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>cert
>>>>>>>>if this is different from the CA certificate. This is also the
>>>>>>>
>>>>>problem
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>with
>>>>>>>>Denis proposal.
>>>>>>>>
>>>>>>>>I think we share the basic conclusion that the ability to locate
>>>>>>>>the
>>>>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>signer certificate directly through the CRL could be very
>>>>>>>>useful. At
>>>>>>>
>>>>>>least
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>in the case of indirect CRL but it could also be proven very 
>>>>>>>>useful
>>>>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CA
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>re-keying scenarios.
>>>>>>>>
>>>>>>>>The easiest solution would probably be to allow AIA to be used
>>>>>>>>in
>>>>>>>
>>>>>its
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>>>>
>>>>>critical).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>It
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>would present a very clear and uncomplicated logic to
>>>>>>>>certificate validating applications in many cases.
>>>>>>>>
>>>>>>>>Stefan Santesson
>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>
>>>>>>>>________________________________________
>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>Sent: den 7 oktober 2004 18:35
>>>>>>>>To: Stefan Santesson
>>>>>>>>Cc: pkix
>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>Stefan,
>>>>>>>>
>>>>>>>>I think what you are proposing is a good idea.  In most cases, 
>>>>>>>>path discovery algorithms assume that both the trust anchor (or 
>>>>>>>>trust
>>>>>>>
>>>>>>anchors)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>and the end entity certificate are provided as input.  In this
>>>>>>>>case,
>>>>>>>
>>>>>one
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>may
>>>>>>>>need to construct a certification path without a priori access
>>>>>>>>to
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>end
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>entity certificate (the one with the subject public key
>>>>>>>
>>>>>corresponding to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>>>>
>>>>>pointer) in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>CRL would provide the relying party with a simple way to obtain 
>>>>>>>>the
>>>>>>>
>>>>>end
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>entity certificate for the CRL signing key's certification path. 
>>>>>>>>On
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>other hand, I believe that a relying party should be able to
>>>>>>>
>>>>>construct
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certification path even without an AIA extension in the CRL, so
>>>>>>>>long
>>>>>>>
>>>>>as
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>it
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>is not an indirect CRL.  Attached is a drawing of the three
>>>>>>>>basic scenarios that I expect a relying party may encounter:
>>>>>>>>
>>>>>>>>In each of these scenarios, the CA has performed key rollover
>>>>>>>>and is
>>>>>>>
>>>>>>only
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>>>>>
>>>>>>however,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>if
>>>>>>>>the CA simply choose to use different keys to sign certificates 
>>>>>>>>and
>>>>>>>
>>>>>CRLs
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>for
>>>>>>>>some other reason.
>>>>>>>>
>>>>>>>>If the PKI architecture resembled figure 1, then the
>>>>>>>>certification
>>>>>>>
>>>>>path
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>for
>>>>>>>>the CRL signing key would just be a subset of the certification
>>>>>>>>path
>>>>>>>
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>EE certificate, so no addition path discovery would be needed.
>>>>>>>>
>>>>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>>>>
>>>>>necessary
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>to
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>obtain the new-signed-with-old self-issued certificate.  In
>>>>>>>>building
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certification path to the EE certificate, however, the relying
>>>>>>>>party
>>>>>>>
>>>>>>will
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>obtain the certificates pointed to by the AIA extension in the
>>>>>>>>EE certificate.  This AIA extension will point to a location 
>>>>>>>>containing
>>>>>>>
>>>>>all
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificates issued to CA 2, which would include both the
>>>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>issued
>>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So,
>>>>>>>>even
>>>>>>>
>>>>>though
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>self-issued certificate would not be part of the certification 
>>>>>>>>path
>>>>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>EE certificate, it would be downloaded by the relying party
>>>>>>>>during
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>construction of that certification path.  (Yes, there are
>>>>>>>>circular dependency issues in figure 2, but that is another
>>>>>>>>issue.)
>>>>>>>>
>>>>>>>>A similar situation would happen if the PKI architecture
>>>>>>>>resembled
>>>>>>>
>>>>>>figure
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>>>>
>>>>>location
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>containing certificates issued to CA 3.  When the relying party
>>>>>>>
>>>>>>downloaded
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>these certificates, it would obtain both of the certificates 
>>>>>>>>issued
>>>>>>>
>>>>>by
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>Root to CA 3 and so again would have the certificate needed to
>>>>>>>
>>>>>validate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>CRL signing key.
>>>>>>>>
>>>>>>>>In the case of an indirect CRL, things may not work as well.  If
>>>>>>>
>>>>>>indirect
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>CRLs were used, and the PKI architecture resembled figures 2 or
>>>>>>>>3 (replacing "New Key" with a different CA), then the set of 
>>>>>>>>certificates pointed
>>>>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>by
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the AIA extension in the EE certificate would not include the
>>>>>>>
>>>>>>certificate
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>of
>>>>>>>>the CRL signer.  One could find this certificate by building in 
>>>>>>>>the reverse direction and using the SIA extension, but that may 
>>>>>>>>not be the most convenient solution.
>>>>>>>>
>>>>>>>>So, when indirect CRLs are being used, it seems that it would be
>>>>>>>
>>>>>very
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>useful
>>>>>>>>to have a pointer in the CRL to the CRL signing certificate.
>>>>>>>>When
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>is not indirect, the need for this pointer does not seem to be
>>>>>>>>as
>>>>>>>
>>>>>clear,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>but
>>>>>>>>I can't see any harm in including it.
>>>>>>>>
>>>>>>>>Dave
>>>>>>>>
>>>>>>>>Stefan Santesson wrote:
>>>>>>>>All,
>>>>>>>>
>>>>>>>>I'm interested in the opinion from members on this list about
>>>>>>>
>>>>>discovery
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>of
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>CRL signer's certificate in non directory centric environments.
>>>>>>>>
>>>>>>>>The problem is the following.
>>>>>>>>
>>>>>>>>The relying party (RP) needs to check validity of a certificate 
>>>>>>>>and
>>>>>>>
>>>>>>finds
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>a
>>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL
>>>>>>>>which
>>>>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>this
>>>>>>>>particular case is either signed by another key of the CA 
>>>>>>>>(re-keyed
>>>>>>>
>>>>>CA)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>or
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>another entity (indirect CRL).
>>>>>>>>
>>>>>>>>In this case the relying party needs to obtain the certificate
>>>>>>>>of
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>signer which may NOT be part of the original chain. In a
>>>>>>>>directory
>>>>>>>
>>>>>>centric
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>solution this is retrieved from the directory, but what if such
>>>>>>>
>>>>>>directory
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>is
>>>>>>>>not available or accessible.
>>>>>>>>
>>>>>>>>The RP have thus no hint where to find the CRL issuers
>>>>>>>>certificate
>>>>>>>
>>>>>>unless
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the RP already have possession of it by some other means.
>>>>>>>>
>>>>>>>>Is seems that CRLs would need an AIA extension with the option
>>>>>>>>to
>>>>>>>
>>>>>point
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>to
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the location of the signers certificate in the same manner as is
>>>>>>>
>>>>>>possible
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>for certificates.
>>>>>>>>
>>>>>>>>Maybe AIA should be defined as both cert and CRL extension and
>>>>>>>>not
>>>>>>>
>>>>>only
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate extension as today.
>>>>>>>>
>>>>>>>>Thoughts and comments?
>>>>>>>>
>>>>>>>>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 i9FItFwa033473; Fri, 15 Oct 2004 11:55:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FItF2X033472; Fri, 15 Oct 2004 11:55:15 -0700 (PDT)
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 i9FItEsF033466 for <[e-mail]>; Fri, 15 Oct 2004 11:55:14 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 19674 invoked by uid 0); 15 Oct 2004 18:55:12 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.176.239) by woodstock.binhost.com with SMTP; 15 Oct 2004 18:55:12 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 15 Oct 2004 14:55:14 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <000301c4b29a$f3450130$[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:

>If I understand you correctly, for whatever reason (which one ?), you only 
>want to use HTTP. Then I would think the solution would be to use the 
>following draft: draft-ietf-pkix-certstore-http-08 and make sure that it 
>will be usable with the current AIA and SIA extensions to fetch CRL 
>issuers certificates.

RFC 3280 specifies the inclusion of AIA and SIA in certificates.  It is not 
specified for the inclusion in CRLs.  I believe that the proposal is to 
write a specification for using AIA in CRLs.

The problem has been stated, and a proposed solution has been stated.  If 
you do not think the problem really exists, please explain why this is the 
case.  If you have another way to solve the stated problem, please share it.

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 i9FIoUiB032627; Fri, 15 Oct 2004 11:50:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FIoUVn032626; Fri, 15 Oct 2004 11:50:30 -0700 (PDT)
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 i9FIoTQq032611 for <[e-mail]>; Fri, 15 Oct 2004 11:50:29 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 18588 invoked by uid 0); 15 Oct 2004 18:50:27 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.176.239) by woodstock.binhost.com with SMTP; 15 Oct 2004 18:50:27 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Fri, 15 Oct 2004 14:50:17 -0400
To: Denis Pinkas <[e-mail]>, Santosh Chokhani <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <000301c4b29a$f3450130$[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:

>I still wonder why you are making this restriction since LDAP is one of 
>the only two methods that are supported in RFC 3280 to fetch certificates.

This is simply not true.  When a GeneralName is used, the URI schemes ftp, 
http, and ldap are explicitly discussed for fetching certificates.  When a 
GeneralName is rfc822name, email is discussed.  And, the mailtoURI scheme 
is discussed for fetching CRLs.

The Directory Access Protocol (DAP) is also discussed.

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 i9FFWI1L005002; Fri, 15 Oct 2004 08:32:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FFWIt0005001; Fri, 15 Oct 2004 08:32:18 -0700 (PDT)
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 i9FFWGus004967 for <[e-mail]>; Fri, 15 Oct 2004 08:32:16 -0700 (PDT) (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 RAA22326; Fri, 15 Oct 2004 17:43:32 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101517315153:1490 ; Fri, 15 Oct 2004 17:31:51 +0200 
Message-ID: <[e-mail]>
Date: Fri, 15 Oct 2004 17:30:13 +0200
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]>, pkix <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/10/2004 17:31:51, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/10/2004 17:31:54, Serialize complete at 15/10/2004 17:31:54
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,

> Denis,

> Unfortunately I fail to understand your questions, issues and requests.

The sentence below demonstrates that you understand the issue.

> It would be very useful if you could explain how current mechanisms can
> be used in a simple and straightforward manner to discover CRL signer
> certificates in ALL the use cases discussed, mainly re-keyed CA and
> indirect CRLs.

You are also reversing the question. Using your terms, my question would be:

"It would be very useful if you could explain how current mechanisms CANNOT
be used in a simple and straightforward manner to discover CRL signer
certificates in ONE or MORE the use cases discussed, mainly re-keyed CA and
indirect CRLs."

Denis

> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 14 oktober 2004 17:13
>>To: Santosh Chokhani
>>Cc: 'pkix'
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>
>>Santosh,
>>
>>
>>>Denis:
>>
>>>With the three assumptions/constraints I provided, how would you
>>
> locate
> 
>>the
>>
>>>CRL issuer certificate for the two examples using 3280 extensions
>>
> and
> 
>>>without putting AIA in the CRL?
>>
>>As far as I understand, the three assumptions are:
>>
>>1.  You are directory challenged; and
>>     [I do not understand what this means]
>>2.  You use AIA to develop the path; and
>>     [It does not matter]
>>3.  You develop the path from the end entity to trust anchor
>>     [Could also be the contrary].
>>
>>If this is not correct, thus please correct.
>>
>>Then my request is: "using ANY OF the current extensions that are
> 
> defined
> 
>>in
>>RFC 3280", which includes SIA.
>>
>>In your explanations  you said :
>>"if you do no deal with SIA et. al"
>>
>>This last assumption is neither part of the three assumptions and does
> 
> not
> 
>>conform to my request.
>>
>>Denis
>>
>>
>>>That is my point.
>>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[e-mail]]
>>>Sent: Thursday, October 14, 2004 6:22 AM
>>>To: Santosh Chokhani
>>>Cc: 'pkix'
>>>Subject: Re: Signer certificate discovery for CRLs
>>>
>>>
>>>Santosh,
>>>
>>>You misread my request. I said:
>>>
>>>"For the time being, I would like that you provide an example where,
>>
>>when
>>
>>>using the current extensions that are defined in RFC 3280, it will
>>
> NOT
> 
>>be
>>
>>>possible to locate a CRL Issuer certificate."
>>>
>>>Maybe I would have needed to be clearer and say :
>>>
>>>"For the time being, I would like that you provide an example where,
>>
>>when
>>
>>>using ANY OF the current extensions that are defined in RFC 3280, it
>>
>>will
>>
>>>NOT be possible to locate a CRL Issuer certificate."
>>>
>>>The examples you provide below do not fulfil this request.
>>>
>>>The assumption is that there exists a path to be tested for
>>
> revocation
> 
>>>checking (and that it does not matter to know which way it has been
>>>constructed).
>>>
>>>I am not saying that using AIA in CRL might not be useful, but I am
>>
>>still
>>
>>>lacking the demonstration that there would be no other way.
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>>Denis:
>>>>
>>>>Two examples are very simple: one for direct CRL Issuer and one for
>>>>Indirect CRL Issuer.
>>>>
>>>>Let us make the following assumptions that Stefan was making:
>>>>
>>>>1.  You are directory challenged; and
>>>>2.  You use AIA to develop the path; and
>>>>3.  You develop the path from the end entity to trust anchor.
>>>>
>>>
>>>>From what I know of MS CAPI, these are reasonable
>>>
>>>>assumptions/constraints.
>>>>
>>>>Now the examples.
>>>>
>>>>Example 1: Direct CRL Issuer
>>>>
>>>>The certificate trust path is:
>>>>Root --> CA1 --> CA 2, old key --> Denis
>>>>
>>>>The CRL trust path is:
>>>>Root --> CA1 --> CA 2, new key --> CRL
>>>>
>>>>(Note: We do not do self-issued certificate since there is no
>>>
> simple,
> 
>>>>secure way to check their revocation status).
>>>>
>>>>Now, with AIA in CRL, finding the CA2, new key certificate is
>>>>straightforward.  How would you find it if you do no deal with SIA
>>>
> et.
> 
>>>>al.
>>>>
>>>>Example 2: Indirect CRL Issuer
>>>>
>>>>The certificate trust path is:
>>>>Root --> CA1 --> CA 2 --> Denis
>>>>(Note: Denis's certificate points to CRL DP of an indirect CRL
>>>
> issued
> 
>>>>by CAI.
>>>>
>>>>The CRL trust path is:
>>>>Root --> CAI --> CRL
>>>>
>>>>Now, with AIA in CRL, finding the CAI certificate is
>>>
> straightforward.
> 
>>>>How would you find it if you do no deal with SIA et. al.
>>>>
>>>>In addition to the need cited above, please note that the extension
>>>>semantics does not change, it does not hinder any interoperability,
>>>>and it does not break any backward compatibility.  So, what if I
>>>>wanted to use this extension in the CRL.  It does no harm to other
>>>>relying parties.
>>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>>>Sent: Wednesday, October 13, 2004 11:01 AM
>>>>To: Stefan Santesson
>>>>Cc: Santosh Chokhani; pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>
>>>>
>>>>Stefan,
>>>>
>>>>
>>>>
>>>>
>>>>>Denis,
>>>>
>>>>
>>>>>I'm not sure what you mean.
>>>>
>>>>
>>>>For the time being, I would like that you provide an example where,
>>>>when
>>>>using the current extensions that are defined in RFC 3280, it will
>>>
> NOT
> 
>>be
>>
>>>>possible to locate a CRL Issuer certificate.
>>>>
>>>>If you are able to provide that example, then it would justify the
>>>>need for
>>>>an extension at least for one case. Then we can see what that case
>>>
> is.
> 
>>>>I am awaiting that example.
>>>>
>>>>Denis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I conclude that I agree with Santosh.
>>>>>
>>>>>The debate is still open... Feel free to express your opinion.
>>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>>Sent: den 13 oktober 2004 16:34
>>>>>>To: Stefan Santesson
>>>>>>Cc: Santosh Chokhani; pkix
>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>
>>>>>>Stefan,
>>>>>>
>>>>>>You are making a conclusion without letting me the time to
>>>>>
> respond. I
> 
>>>>>>will need more time to look at the pictures (and understand them).
>>>>>>
>>>>>>For the time being, I am still reluctant to accept
>>>>>
>>>>>"yet-another-method".
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>We already have too many.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Santosh,
>>>>>>>
>>>>>>>I conclude that we are in complete and total agreement.
>>>>>>>The question is how to go about this.
>>>>>>
>>>>>>>Could we do this amendment to RFC 3280 in its next revision? It
>>>>>>>would hopefully just be a minor change.
>>>>>>
>>>>>>This is exactly what I feared.
>>>>>>
>>>>>>We usually end-up with a "minor change" in an extension without
>>>>>>saying cleary how and when it shall/should be used.
>>>>>>
>>>>>>I still have in mind that:
>>>>>>
>>>>>>1) a certification path must first be constructed,
>>>>>>2) then the revocation checking of that path must be done.
>>>>>>
>>>>>>This means that information about CRL issuers certificates
>>>>>
> locations
> 
>>>>>may
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>certainly be found in that chain. If not, I would like an example.
>>>>>>
>>>>>>Denis
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>It would not change the definition of AIA just add that it can be
>>>>>>
>>>>>used
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>also as CRL extension and list eventual restrictions and guidance
>>>>>
> for
> 
>>>>>use
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>with CRLs.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Stefan Santesson
>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: [e-mail]
>>>>>>>
>>>>>[mailto:[e-mail]]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>On Behalf Of Santosh Chokhani
>>>>>>>>Sent: den 13 oktober 2004 04:33
>>>>>>>>To: 'pkix'
>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>
>>>>>>>>Stefan:
>>>>>>>>
>>>>>>>>In terms of certificate discovery, your proposal for AIA in CRL
>>>>>>>
> is
> 
>>>>>more
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>robust.  The whole idea of self-issued key rollover certificates
>>>>>>>>and
>>>>>>>
>>>>>>then
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>using the new key to issue CRL is fraught with security
>>>>>>>
> problems.
> 
>>>>>>>>A secure solution would be one where the new key is certified by
>>>>>>>>the parent
>>>>>>>
>>>>>CA.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>In
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>that case to obtain the new certificate, you could use AIA in
>>>>>>>
> CRL.
> 
>>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
>>>>>>>>certificate in question points to the indirect CRL.  You get
>>>>>>>
> that
> 
>>>>>>>>CRL.  The AIA
>>>>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>gets you started for the indirect CRL issuer certification path
>>>>>>>
> and
> 
>>>>>you
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>are
>>>>>>>>in business.
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: [e-mail]
>>>>>>>
>>>>>[mailto:[e-mail]]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>On
>>>>>>>>Behalf Of Stefan Santesson
>>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>>>>To: David A. Cooper
>>>>>>>>Cc: pkix
>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>David,
>>>>>>>>
>>>>>>>>Thanks for the clarifications, they make sense.
>>>>>>>>I did misread your pictures.
>>>>>>>>
>>>>>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>>>>>
>>>>>3280,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>either the CRL issuer certificate itself, or the location of the
>>>>>>>>CRL issuer certificate, will be clearly identified/available for
>>>>>>>>the validating
>>>>>>>
>>>>>>party
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>in some cases, but not in others?
>>>>>>>>
>>>>>>>>Can we also conclude that there is no real discovery solution
>>>>>>>
> for
> 
>>>>>>indirect
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>CRLs?
>>>>>>>>
>>>>>>>>Do you then agree then that it could be appropriate to allow AIA
>>>>>>>
> as
> 
>>>>>a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>>>>
>>>>>>>>Stefan Santesson
>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>
>>>>>>>>________________________________________
>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>Sent: den 12 oktober 2004 21:14
>>>>>>>>To: Stefan Santesson
>>>>>>>>Cc: pkix
>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>Stefan,
>>>>>>>>
>>>>>>>>I believe that you are misinterpreting the figures.  They really
>>>>>>>
> do
> 
>>>>>>>>represent three different cases, not three different
>>>>>>>
> certification
> 
>>>>>paths
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>that have been constructed through the same PKI architecture.
>>>>>>>>
>>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>>>>
>>>>>certificates.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>The
>>>>>>>>Root CA has issued a certificate to CA 1's new key, but not its
>>>>>>>
> old
> 
>>>>>key
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>(either the Root CA never issued a certificate to CA 1's old key
>>>>>>>
> or
> 
>>>>>that
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate has expired).
>>>>>>>>
>>>>>>>>In figure 2, CA 2 has also generated self-issued key rollover
>>>>>>>>certificates. The Root CA has issued a certificate to CA 2's old
>>>>>>>>key, but not its
>>>>>>>
>>>>>new
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>key.
>>>>>>>>
>>>>>>>>In figure 3, when CA 3 performed key rollover, it requested a
>>>>>>>
> new
> 
>>>>>>>>CA certificate from the Root CA.  CA 3 did not generated
>>>>>>>>self-issued
>>>>>>>
>>>>>key
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>rollover certificates.
>>>>>>>>
>>>>>>>>Of course, another realistic scenario would be one in which a CA
>>>>>>>
>>>>>>generated
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>self-issued key rollover certificates upon key rollover and then
>>>>>>>>had
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>Root CA issue a CA certificate to its new key.  In this case, as
>>>>>>>>you suggest, any of the certification paths from figures 1, 2,
>>>>>>>
> or 3
> 
>>>>>could be
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>constructed.
>>>>>>>>
>>>>>>>>As for the contents of the AIA extension, here is what I have
>>>>>>>
>>>>>specified
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>in
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>>>>>
>>>>>>Policy":
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>The authorityInfoAccess extension uses URIs for two purposes.
>>>>>>>
> When
> 
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>id-ad-caIssuers access method is used, the access location
>>>>>>>>specifies
>>>>>>>
>>>>>>where
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificates issued to the issuer of the certificate may be
>>>>>>>
> found.
> 
>>>>>If
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>LDAP
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>is used, the URI must include the DN of the entry containing the
>>>>>>>
>>>>>>relevant
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificates and specify the directory attribute in which the
>>>>>>>
>>>>>>certificates
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>are located. If the directory in which the certificates are
>>>>>>>
> stored
> 
>>>>>>expects
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the "binary" option to be specified, then the attribute type
>>>>>>>
> must
> 
>>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the URI
>>>>>>>
> must
> 
>>>>>point to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>a
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>file that has an extension of ".p7c" that contains a certs-only
>>>>>>>
> CMS
> 
>>>>>>>>message (see RFC 2633). The CMS message should include all
>>>>>>>>certificates
>>>>>>>
>>>>>issued
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>to
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the issuer of this certificate, but must at least contain all
>>>>>>>
>>>>>>certificates
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>issued to the issuer of this certificate in which the subject
>>>>>>>>public
>>>>>>>
>>>>>key
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>may
>>>>>>>>be used to verify the signature on this certificate. .... For a
>>>>>>>>certificate issued by "Good CA", some examples of URIs that may
>>>>>>>>appear as the
>>>>>>>
>>>>>access
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>location in an authorityInfoAccess extension when the
>>>>>>>
>>>>>id-ad-caIssuers
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>access
>>>>>>>>method is used are:
>>>>>>>
>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACe
>>>>>
> r
> 
>>>>>>>t
>>>>>>>i
>>>>>>
>>>>>fi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>ca
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>te
>>>>>>>>,crossCertificatePair
>>>>>>>
>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertif
>>>>>
> i
> 
>>>>>>>c
>>>>>>>a
>>>>>>
>>>>>te
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>;b
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>in
>>>>>>>>ary,crossCertificatePair;binary
>>>>>>>
>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIss
>>>>>
> u
> 
>>>>>>>e
>>>>>>>d
>>>>>>
>>>>>To
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Go
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>od
>>>>>>>>CA.p7c
>>>>>>>>For both LDAP and HTTP, the URI provides the exact location
>>>>>>>
> where
> 
>>>>>>>>information is to be located, so there is no requirement for the
>>>>>>>
>>>>>relying
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>party to try to figure out where information is located.
>>>>>>>>
>>>>>>>>The HTTP URI points to a certs-only CMS message that includes
>>>>>>>
> all
> 
>>>>>>>>certificates issued to the CA identified in the issuer field of
>>>>>>>
> the
> 
>>>>>>>>certificate.
>>>>>>>>
>>>>>>>>The LDAP URI points to the cACertificate and
>>>>>>>
> crossCertificatePair
> 
>>>>>>>>attributes of the directory entry of the CA identified in the
>>>>>>>>issuer field of
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate.  These two attributes together hold all of the
>>>>>>>
>>>>>certificates
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>issued to the CA:  the cACertificate attribute holds the CA's
>>>>>>>
> self-
> 
>>>>>>issued
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificates and the crossCertificatePair attribute holds the
>>>>>>>>cross-certificates issued to the CA by other CAs.
>>>>>>>>
>>>>>>>>Dave
>>>>>>>>
>>>>>>>>
>>>>>>>>Stefan Santesson wrote:
>>>>>>>>
>>>>>>>>David,
>>>>>>>>
>>>>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>>>>
>>>>>>>>I have some comments and questions on this.
>>>>>>>>
>>>>>>>>First of all we can conclude that in some scenarios (figure 1)
>>>>>>>>where
>>>>>>>
>>>>>a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>self
>>>>>>>>issued certificate is inserted into the path, you are likely to
>>>>>>>>find
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>CRL
>>>>>>>>issuer cert in the path. (given that the new CA have a common
>>>>>>>
> key
> 
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate for cert signing and CRL signing).
>>>>>>>>
>>>>>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>>>>>
>>>>>>different
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>path building strategies. An application that has access locally
>>>>>>>
> to
> 
>>>>>all
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>chaining options may however still choose path 2 for the certs
>>>>>>>
> and
> 
>>>>>path
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>1
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>for the CRL independent of each other (which I think figure 3
>>>>>>>
> tries
> 
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>describe)
>>>>>>>>
>>>>>>>>Another comment is the structure of AIA extensions. The use I'm
>>>>>>>
>>>>>familiar
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>with doesn't use AIA to describe a directory entry where it is
>>>>>>>
> left
> 
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>validation application logic to be intelligent enough to find
>>>>>>>
>>>>>>appropriate
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificate data from the directory. The model I'm familiar with
>>>>>>>
> is
> 
>>>>>when
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>AIA URL explicitly identifies the exact location of the
>>>>>>>
> appropriate
> 
>>>>>CA
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate file, relieving the validation software from complex
>>>>>>>>information queries. If just location of explicit certificate
>>>>>>>
> files
> 
>>>>>>>>are
>>>>>>>
>>>>>identified
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>>>>>
>>>>>signer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>cert
>>>>>>>>if this is different from the CA certificate. This is also the
>>>>>>>
>>>>>problem
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>with
>>>>>>>>Denis proposal.
>>>>>>>>
>>>>>>>>I think we share the basic conclusion that the ability to locate
>>>>>>>>the
>>>>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>signer certificate directly through the CRL could be very
>>>>>>>
> useful.
> 
>>>>>>>>At
>>>>>>>
>>>>>>least
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>in the case of indirect CRL but it could also be proven very
>>>>>>>
> useful
> 
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CA
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>re-keying scenarios.
>>>>>>>>
>>>>>>>>The easiest solution would probably be to allow AIA to be used
>>>>>>>
> in
> 
>>>>>its
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>>>>
>>>>>critical).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>It
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>would present a very clear and uncomplicated logic to
>>>>>>>
> certificate
> 
>>>>>>>>validating applications in many cases.
>>>>>>>>
>>>>>>>>Stefan Santesson
>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>
>>>>>>>>________________________________________
>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>Sent: den 7 oktober 2004 18:35
>>>>>>>>To: Stefan Santesson
>>>>>>>>Cc: pkix
>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>Stefan,
>>>>>>>>
>>>>>>>>I think what you are proposing is a good idea.  In most cases,
>>>>>>>
> path
> 
>>>>>>>>discovery algorithms assume that both the trust anchor (or trust
>>>>>>>
>>>>>>anchors)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>and the end entity certificate are provided as input.  In this
>>>>>>>>case,
>>>>>>>
>>>>>one
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>may
>>>>>>>>need to construct a certification path without a priori access
>>>>>>>
> to
> 
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>end
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>entity certificate (the one with the subject public key
>>>>>>>
>>>>>corresponding to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>>>>
>>>>>pointer) in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>CRL would provide the relying party with a simple way to obtain
>>>>>>>
> the
> 
>>>>>end
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>entity certificate for the CRL signing key's certification path.
>>>>>>>
> On
> 
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>other hand, I believe that a relying party should be able to
>>>>>>>
>>>>>construct
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certification path even without an AIA extension in the CRL, so
>>>>>>>>long
>>>>>>>
>>>>>as
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>it
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>is not an indirect CRL.  Attached is a drawing of the three
>>>>>>>
> basic
> 
>>>>>>>>scenarios that I expect a relying party may encounter:
>>>>>>>>
>>>>>>>>In each of these scenarios, the CA has performed key rollover
>>>>>>>
> and
> 
>>>>>>>>is
>>>>>>>
>>>>>>only
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>>>>>
>>>>>>however,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>if
>>>>>>>>the CA simply choose to use different keys to sign certificates
>>>>>>>
> and
> 
>>>>>CRLs
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>for
>>>>>>>>some other reason.
>>>>>>>>
>>>>>>>>If the PKI architecture resembled figure 1, then the
>>>>>>>
> certification
> 
>>>>>path
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>for
>>>>>>>>the CRL signing key would just be a subset of the certification
>>>>>>>>path
>>>>>>>
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>EE certificate, so no addition path discovery would be needed.
>>>>>>>>
>>>>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>>>>
>>>>>necessary
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>to
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>obtain the new-signed-with-old self-issued certificate.  In
>>>>>>>>building
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certification path to the EE certificate, however, the relying
>>>>>>>>party
>>>>>>>
>>>>>>will
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>obtain the certificates pointed to by the AIA extension in the
>>>>>>>
> EE
> 
>>>>>>>>certificate.  This AIA extension will point to a location
>>>>>>>>containing
>>>>>>>
>>>>>all
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificates issued to CA 2, which would include both the
>>>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>issued
>>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So,
>>>>>>>
> even
> 
>>>>>though
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>self-issued certificate would not be part of the certification
>>>>>>>
> path
> 
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>EE certificate, it would be downloaded by the relying party
>>>>>>>
> during
> 
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>construction of that certification path.  (Yes, there are
>>>>>>>
> circular
> 
>>>>>>>>dependency issues in figure 2, but that is another issue.)
>>>>>>>>
>>>>>>>>A similar situation would happen if the PKI architecture
>>>>>>>
> resembled
> 
>>>>>>figure
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>>>>
>>>>>location
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>containing certificates issued to CA 3.  When the relying party
>>>>>>>
>>>>>>downloaded
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>these certificates, it would obtain both of the certificates
>>>>>>>
> issued
> 
>>>>>by
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>Root to CA 3 and so again would have the certificate needed to
>>>>>>>
>>>>>validate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>CRL signing key.
>>>>>>>>
>>>>>>>>In the case of an indirect CRL, things may not work as well.  If
>>>>>>>
>>>>>>indirect
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>CRLs were used, and the PKI architecture resembled figures 2 or
>>>>>>>
> 3
> 
>>>>>>>>(replacing "New Key" with a different CA), then the set of
>>>>>>>>certificates pointed
>>>>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>by
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the AIA extension in the EE certificate would not include the
>>>>>>>
>>>>>>certificate
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>of
>>>>>>>>the CRL signer.  One could find this certificate by building in
>>>>>>>
> the
> 
>>>>>>>>reverse direction and using the SIA extension, but that may not
>>>>>>>
> be
> 
>>>>>>>>the most convenient solution.
>>>>>>>>
>>>>>>>>So, when indirect CRLs are being used, it seems that it would be
>>>>>>>
>>>>>very
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>useful
>>>>>>>>to have a pointer in the CRL to the CRL signing certificate.
>>>>>>>
> When
> 
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>is not indirect, the need for this pointer does not seem to be
>>>>>>>
> as
> 
>>>>>clear,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>but
>>>>>>>>I can't see any harm in including it.
>>>>>>>>
>>>>>>>>Dave
>>>>>>>>
>>>>>>>>Stefan Santesson wrote:
>>>>>>>>All,
>>>>>>>>
>>>>>>>>I'm interested in the opinion from members on this list about
>>>>>>>
>>>>>discovery
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>of
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>CRL signer's certificate in non directory centric environments.
>>>>>>>>
>>>>>>>>The problem is the following.
>>>>>>>>
>>>>>>>>The relying party (RP) needs to check validity of a certificate
>>>>>>>
> and
> 
>>>>>>finds
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>a
>>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL
>>>>>>>>which
>>>>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>this
>>>>>>>>particular case is either signed by another key of the CA
>>>>>>>
> (re-keyed
> 
>>>>>CA)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>or
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>another entity (indirect CRL).
>>>>>>>>
>>>>>>>>In this case the relying party needs to obtain the certificate
>>>>>>>
> of
> 
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>signer which may NOT be part of the original chain. In a
>>>>>>>
> directory
> 
>>>>>>centric
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>solution this is retrieved from the directory, but what if such
>>>>>>>
>>>>>>directory
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>is
>>>>>>>>not available or accessible.
>>>>>>>>
>>>>>>>>The RP have thus no hint where to find the CRL issuers
>>>>>>>
> certificate
> 
>>>>>>unless
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the RP already have possession of it by some other means.
>>>>>>>>
>>>>>>>>Is seems that CRLs would need an AIA extension with the option
>>>>>>>
> to
> 
>>>>>point
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>to
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the location of the signers certificate in the same manner as is
>>>>>>>
>>>>>>possible
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>for certificates.
>>>>>>>>
>>>>>>>>Maybe AIA should be defined as both cert and CRL extension and
>>>>>>>
> not
> 
>>>>>only
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate extension as today.
>>>>>>>>
>>>>>>>>Thoughts and comments?
>>>>>>>>
>>>>>>>>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 i9FC1Blr085869; Fri, 15 Oct 2004 05:01:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FC1BYu085868; Fri, 15 Oct 2004 05:01:11 -0700 (PDT)
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 i9FC18EM085859 for <[e-mail]>; Fri, 15 Oct 2004 05:01:09 -0700 (PDT) (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 OAA36850; Fri, 15 Oct 2004 14:12:38 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101514005742:1324 ; Fri, 15 Oct 2004 14:00:57 +0200 
Message-ID: <[e-mail]>
Date: Fri, 15 Oct 2004 13:59:19 +0200
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: <000301c4b29a$f3450130$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/10/2004 14:00:57, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/10/2004 14:00:59, Serialize complete at 15/10/2004 14:00:59
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:
> 
> 1.  This is a good mechanism to start building the path for CRL signer. 

"There are none so deaf as those who will not hear".

This is not the point.

> If you have a better alternative for directory challenged environments, 

Your definition of "directory challenged environment" is:
"not use LDAP client or DAP or DSP to query for certificate"

I still wonder why you are making this restriction since LDAP is one of the 
only two methods that are supported in RFC 3280 to fetch certificates.

If I understand you correctly, for whatever reason (which one ?), you only 
want to use HTTP. Then I would think the solution would be to use the 
following draft: draft-ietf-pkix-certstore-http-08 and make sure that it 
will be usable with the current AIA and SIA extensions to fetch CRL issuers 
certificates.

> tell us.  Absent you showing that there is a mechanism for directory
> challenged environments that is as simple and that works, we can not have a
> fruitful dialog.

Please, do not reverse the question.

> 2.  Adding AIA to CRL does not impact interoperability, security or backward
> compatibility adversely.

It adds complexity with "still-another-extension" in CRLs and still another 
method for revocation checking.

> As to your argument, we could have used it few years back and not added AIA
> to the certificates either.

  ... but you didn't. This last argument does not make sense.

Denis

> -----Original Message-----
> From: Denis Pinks [mailto:[e-mail]] 
> Sent: Friday, October 15, 2004 2:45 AM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> You are still trying to avoid to respond to my request. So my temporary 
> conclusion is that you have NOT demonstrated that your proposal is really 
> necessary and it is thus "yet-another-method".
> 
> 
>>Denis:
> 
> 
>>By directory challenged, I mean you do not use LDAP client or DAP or
>>DSP to query for certificate.
> 
> 
> RFC 3280. Page 46:
> 
>     The accessLocation
>     field is defined as a GeneralName, which can take several forms.
>     Where the information is available via http, ftp, or ldap,
>     accessLocation MUST be a uniformResourceIdentifier.  Where the
>     information is available via the Directory Access Protocol (DAP),
>     accessLocation MUST be a directoryName.
> 
> It is thus perfectly allowed and valid to use DAP or ldap.
> 
> 
>>The basic point is that if AIA or local store are the primary ways to
>>obtain certificates,
> 
> 
> No. Local store is of no use. AIA is one possibility, while the other one is
> 
> SIA.
> 
> 
>>since the CRL issuer certificate is not in any payload, AIA in CRL
>>helps obtain that certificate and start the path development process 
>>for the CRL certification path.
> 
> 
> No. You can use AIA or SIA in CA certificates, or AIA in leaf certificate.
> 
> Denis
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, October 14, 2004 11:13 AM
>>To: Santosh Chokhani
>>Cc: 'pkix'
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>
>>Santosh,
>>
>>
>>
>>>Denis:
>>
>>
>>>With the three assumptions/constraints I provided, how would you 
>>>locate the CRL issuer certificate for the two examples using 3280 
>>>extensions and without putting AIA in the CRL?
>>
>>
>>As far as I understand, the three assumptions are:
>>
>>1.  You are directory challenged; and
>>     [I do not understand what this means]
>>2.  You use AIA to develop the path; and
>>     [It does not matter]
>>3.  You develop the path from the end entity to trust anchor
>>     [Could also be the contrary].
>>
>>If this is not correct, thus please correct.
>>
>>Then my request is: "using ANY OF the current extensions that are
>>defined in
>>
>>RFC 3280", which includes SIA.
>>
>>In your explanations  you said :
>>"if you do no deal with SIA et. al"
>>
>>This last assumption is neither part of the three assumptions and does
>>not
>>conform to my request.
>>
>>Denis
>>
>>
>>
>>>That is my point.
>>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[e-mail]]
>>>Sent: Thursday, October 14, 2004 6:22 AM
>>>To: Santosh Chokhani
>>>Cc: 'pkix'
>>>Subject: Re: Signer certificate discovery for CRLs
>>>
>>>
>>>Santosh,
>>>
>>>You misread my request. I said:
>>>
>>>"For the time being, I would like that you provide an example where, 
>>>when using the current extensions that are defined in RFC 3280, it 
>>>will NOT be possible to locate a CRL Issuer certificate."
>>>
>>>Maybe I would have needed to be clearer and say :
>>>
>>>"For the time being, I would like that you provide an example where, 
>>>when using ANY OF the current extensions that are defined in RFC 3280, 
>>>it will NOT be possible to locate a CRL Issuer certificate."
>>>
>>>The examples you provide below do not fulfil this request.
>>>
>>>The assumption is that there exists a path to be tested for revocation
>>>checking (and that it does not matter to know which way it has been 
>>>constructed).
>>>
>>>I am not saying that using AIA in CRL might not be useful, but I am 
>>>still lacking the demonstration that there would be no other way.
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>
>>>>Denis:
>>>>
>>>>Two examples are very simple: one for direct CRL Issuer and one for
>>>>Indirect CRL Issuer.
>>>>
>>>>Let us make the following assumptions that Stefan was making:
>>>>
>>>>1.  You are directory challenged; and
>>>>2.  You use AIA to develop the path; and
>>>>3.  You develop the path from the end entity to trust anchor.
>>>>
>>>
>>>>From what I know of MS CAPI, these are reasonable
>>>
>>>
>>>>assumptions/constraints.
>>>>
>>>>Now the examples.
>>>>
>>>>Example 1: Direct CRL Issuer
>>>>
>>>>The certificate trust path is:
>>>>Root --> CA1 --> CA 2, old key --> Denis
>>>>
>>>>The CRL trust path is:
>>>>Root --> CA1 --> CA 2, new key --> CRL
>>>>
>>>>(Note: We do not do self-issued certificate since there is no simple,
>>>>secure way to check their revocation status).
>>>>
>>>>Now, with AIA in CRL, finding the CA2, new key certificate is
>>>>straightforward.  How would you find it if you do no deal with SIA 
>>>>et. al.
>>>>
>>>>Example 2: Indirect CRL Issuer
>>>>
>>>>The certificate trust path is:
>>>>Root --> CA1 --> CA 2 --> Denis
>>>>(Note: Denis's certificate points to CRL DP of an indirect CRL issued
>>>>by CAI.
>>>>
>>>>The CRL trust path is:
>>>>Root --> CAI --> CRL
>>>>
>>>>Now, with AIA in CRL, finding the CAI certificate is straightforward.
>>>>How would you find it if you do no deal with SIA et. al.
>>>>
>>>>In addition to the need cited above, please note that the extension
>>>>semantics does not change, it does not hinder any interoperability, 
>>>>and it does not break any backward compatibility.  So, what if I 
>>>>wanted to use this extension in the CRL.  It does no harm to other 
>>>>relying parties.
>>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>>>Sent: Wednesday, October 13, 2004 11:01 AM
>>>>To: Stefan Santesson
>>>>Cc: Santosh Chokhani; pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>
>>>>
>>>>Stefan,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Denis,
>>>>
>>>>
>>>>>I'm not sure what you mean.
>>>>
>>>>
>>>>For the time being, I would like that you provide an example where,
>>>>when using the current extensions that are defined in RFC 3280, it 
>>>>will NOT be possible to locate a CRL Issuer certificate.
>>>>
>>>>If you are able to provide that example, then it would justify the
>>>>need for an extension at least for one case. Then we can see what 
>>>>that case is.
>>>>
>>>>I am awaiting that example.
>>>>
>>>>Denis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I conclude that I agree with Santosh.
>>>>>
>>>>>The debate is still open... Feel free to express your opinion.
>>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>>Sent: den 13 oktober 2004 16:34
>>>>>>To: Stefan Santesson
>>>>>>Cc: Santosh Chokhani; pkix
>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>
>>>>>>Stefan,
>>>>>>
>>>>>>You are making a conclusion without letting me the time to respond. 
>>>>>>I will need more time to look at the pictures (and understand 
>>>>>>them).
>>>>>>
>>>>>>For the time being, I am still reluctant to accept
>>>>>
>>>>>"yet-another-method".
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>We already have too many.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Santosh,
>>>>>>>
>>>>>>>I conclude that we are in complete and total agreement. The 
>>>>>>>question is how to go about this.
>>>>>>
>>>>>>>Could we do this amendment to RFC 3280 in its next revision? It
>>>>>>>would hopefully just be a minor change.
>>>>>>
>>>>>>This is exactly what I feared.
>>>>>>
>>>>>>We usually end-up with a "minor change" in an extension without
>>>>>>saying cleary how and when it shall/should be used.
>>>>>>
>>>>>>I still have in mind that:
>>>>>>
>>>>>>1) a certification path must first be constructed,
>>>>>>2) then the revocation checking of that path must be done.
>>>>>>
>>>>>>This means that information about CRL issuers certificates
>>>>>>locations
>>>>>
>>>>>may
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>certainly be found in that chain. If not, I would like an example.
>>>>>>
>>>>>>Denis
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>It would not change the definition of AIA just add that it can be
>>>>>>
>>>>>used
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>also as CRL extension and list eventual restrictions and guidance 
>>>>>>for
>>>>>
>>>>>use
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>with CRLs.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Stefan Santesson
>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: [e-mail]
>>>>>>>
>>>>>[mailto:[e-mail]]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>On Behalf Of Santosh Chokhani
>>>>>>>>Sent: den 13 oktober 2004 04:33
>>>>>>>>To: 'pkix'
>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>
>>>>>>>>Stefan:
>>>>>>>>
>>>>>>>>In terms of certificate discovery, your proposal for AIA in CRL
>>>>>>>>is
>>>>>>>
>>>>>more
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>robust.  The whole idea of self-issued key rollover certificates
>>>>>>>>and
>>>>>>>
>>>>>>then
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>using the new key to issue CRL is fraught with security problems.
>>>>>>>>A secure solution would be one where the new key is certified by 
>>>>>>>>the parent
>>>>>>>
>>>>>CA.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>In
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>that case to obtain the new certificate, you could use AIA in
>>>>>>>>CRL.
>>>>>>>>
>>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
>>>>>>>>certificate in question points to the indirect CRL.  You get that 
>>>>>>>>CRL.  The AIA
>>>>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>gets you started for the indirect CRL issuer certification path 
>>>>>>>>and
>>>>>>>
>>>>>you
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>are
>>>>>>>>in business.
>>>>>>>>
>>>>>>>>-----Original Message-----
>>>>>>>>From: [e-mail]
>>>>>>>
>>>>>[mailto:[e-mail]]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>On
>>>>>>>>Behalf Of Stefan Santesson
>>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>>>>To: David A. Cooper
>>>>>>>>Cc: pkix
>>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>David,
>>>>>>>>
>>>>>>>>Thanks for the clarifications, they make sense.
>>>>>>>>I did misread your pictures.
>>>>>>>>
>>>>>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>>>>>
>>>>>3280,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>either the CRL issuer certificate itself, or the location of the
>>>>>>>>CRL issuer certificate, will be clearly identified/available for 
>>>>>>>>the validating
>>>>>>>
>>>>>>party
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>in some cases, but not in others?
>>>>>>>>
>>>>>>>>Can we also conclude that there is no real discovery solution for
>>>>>>>
>>>>>>indirect
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>CRLs?
>>>>>>>>
>>>>>>>>Do you then agree then that it could be appropriate to allow AIA 
>>>>>>>>as
>>>>>>>
>>>>>a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>>>>
>>>>>>>>Stefan Santesson
>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>
>>>>>>>>________________________________________
>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>Sent: den 12 oktober 2004 21:14
>>>>>>>>To: Stefan Santesson
>>>>>>>>Cc: pkix
>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>Stefan,
>>>>>>>>
>>>>>>>>I believe that you are misinterpreting the figures.  They really 
>>>>>>>>do represent three different cases, not three different 
>>>>>>>>certification
>>>>>>>
>>>>>paths
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>that have been constructed through the same PKI architecture.
>>>>>>>>
>>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>>>>
>>>>>certificates.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>The
>>>>>>>>Root CA has issued a certificate to CA 1's new key, but not its 
>>>>>>>>old
>>>>>>>
>>>>>key
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>(either the Root CA never issued a certificate to CA 1's old key 
>>>>>>>>or
>>>>>>>
>>>>>that
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate has expired).
>>>>>>>>
>>>>>>>>In figure 2, CA 2 has also generated self-issued key rollover
>>>>>>>>certificates. The Root CA has issued a certificate to CA 2's old 
>>>>>>>>key, but not its
>>>>>>>
>>>>>new
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>key.
>>>>>>>>
>>>>>>>>In figure 3, when CA 3 performed key rollover, it requested a new
>>>>>>>>CA certificate from the Root CA.  CA 3 did not generated 
>>>>>>>>self-issued
>>>>>>>
>>>>>key
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>rollover certificates.
>>>>>>>>
>>>>>>>>Of course, another realistic scenario would be one in which a CA
>>>>>>>
>>>>>>generated
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>self-issued key rollover certificates upon key rollover and then
>>>>>>>>had
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>Root CA issue a CA certificate to its new key.  In this case, as
>>>>>>>>you suggest, any of the certification paths from figures 1, 2, or 
>>>>>>>>3
>>>>>>>
>>>>>could be
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>constructed.
>>>>>>>>
>>>>>>>>As for the contents of the AIA extension, here is what I have
>>>>>>>
>>>>>specified
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>in
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>>>>>
>>>>>>Policy":
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>The authorityInfoAccess extension uses URIs for two purposes.
>>>>>>>>When
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>id-ad-caIssuers access method is used, the access location
>>>>>>>>specifies
>>>>>>>
>>>>>>where
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificates issued to the issuer of the certificate may be
>>>>>>>>found.
>>>>>>>
>>>>>If
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>LDAP
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>is used, the URI must include the DN of the entry containing the
>>>>>>>
>>>>>>relevant
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificates and specify the directory attribute in which the
>>>>>>>
>>>>>>certificates
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>are located. If the directory in which the certificates are
>>>>>>>>stored
>>>>>>>
>>>>>>expects
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the "binary" option to be specified, then the attribute type must
>>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the URI 
>>>>>>>>must
>>>>>>>
>>>>>point to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>a
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>file that has an extension of ".p7c" that contains a certs-only 
>>>>>>>>CMS message (see RFC 2633). The CMS message should include all
>>>>>>>>certificates
>>>>>>>
>>>>>issued
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>to
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the issuer of this certificate, but must at least contain all
>>>>>>>
>>>>>>certificates
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>issued to the issuer of this certificate in which the subject
>>>>>>>>public
>>>>>>>
>>>>>key
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>may
>>>>>>>>be used to verify the signature on this certificate. .... For a
>>>>>>>>certificate issued by "Good CA", some examples of URIs that may 
>>>>>>>>appear as the
>>>>>>>
>>>>>access
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>location in an authorityInfoAccess extension when the
>>>>>>>
>>>>>id-ad-caIssuers
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>access
>>>>>>>>method is used are:
>>>>>>>
>>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cAC
>>>>>>>e
>>>>>>>r
>>>>>>>t
>>>>>>>i
>>>>>>
>>>>>fi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>ca
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>te
>>>>>>>>,crossCertificatePair
>>>>>>>
>>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACerti
>>>>>>>f
>>>>>>>i
>>>>>>>c
>>>>>>>a
>>>>>>
>>>>>te
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>;b
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>in
>>>>>>>>ary,crossCertificatePair;binary
>>>>>>>
>>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIs
>>>>>>>s
>>>>>>>u
>>>>>>>e
>>>>>>>d
>>>>>>
>>>>>To
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Go
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>od
>>>>>>>>CA.p7c
>>>>>>>>For both LDAP and HTTP, the URI provides the exact location where
>>>>>>>>information is to be located, so there is no requirement for the
>>>>>>>
>>>>>relying
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>party to try to figure out where information is located.
>>>>>>>>
>>>>>>>>The HTTP URI points to a certs-only CMS message that includes all
>>>>>>>>certificates issued to the CA identified in the issuer field of 
>>>>>>>>the certificate.
>>>>>>>>
>>>>>>>>The LDAP URI points to the cACertificate and crossCertificatePair
>>>>>>>>attributes of the directory entry of the CA identified in the 
>>>>>>>>issuer field of
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate.  These two attributes together hold all of the
>>>>>>>
>>>>>certificates
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>issued to the CA:  the cACertificate attribute holds the CA's
>>>>>>>>self-
>>>>>>>
>>>>>>issued
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificates and the crossCertificatePair attribute holds the
>>>>>>>>cross-certificates issued to the CA by other CAs.
>>>>>>>>
>>>>>>>>Dave
>>>>>>>>
>>>>>>>>
>>>>>>>>Stefan Santesson wrote:
>>>>>>>>
>>>>>>>>David,
>>>>>>>>
>>>>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>>>>
>>>>>>>>I have some comments and questions on this.
>>>>>>>>
>>>>>>>>First of all we can conclude that in some scenarios (figure 1)
>>>>>>>>where
>>>>>>>
>>>>>a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>self
>>>>>>>>issued certificate is inserted into the path, you are likely to
>>>>>>>>find
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>CRL
>>>>>>>>issuer cert in the path. (given that the new CA have a common key
>>>>>>>
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate for cert signing and CRL signing).
>>>>>>>>
>>>>>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>>>>>
>>>>>>different
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>path building strategies. An application that has access locally 
>>>>>>>>to
>>>>>>>
>>>>>all
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>chaining options may however still choose path 2 for the certs
>>>>>>>>and
>>>>>>>
>>>>>path
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>1
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>for the CRL independent of each other (which I think figure 3 
>>>>>>>>tries
>>>>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>describe)
>>>>>>>>
>>>>>>>>Another comment is the structure of AIA extensions. The use I'm
>>>>>>>
>>>>>familiar
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>with doesn't use AIA to describe a directory entry where it is 
>>>>>>>>left
>>>>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>validation application logic to be intelligent enough to find
>>>>>>>
>>>>>>appropriate
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certificate data from the directory. The model I'm familiar with 
>>>>>>>>is
>>>>>>>
>>>>>when
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>AIA URL explicitly identifies the exact location of the 
>>>>>>>>appropriate
>>>>>>>
>>>>>CA
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate file, relieving the validation software from complex
>>>>>>>>information queries. If just location of explicit certificate 
>>>>>>>>files are
>>>>>>>
>>>>>identified
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>>>>>
>>>>>signer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>cert
>>>>>>>>if this is different from the CA certificate. This is also the
>>>>>>>
>>>>>problem
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>with
>>>>>>>>Denis proposal.
>>>>>>>>
>>>>>>>>I think we share the basic conclusion that the ability to locate
>>>>>>>>the
>>>>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>signer certificate directly through the CRL could be very useful.
>>>>>>>>At
>>>>>>>
>>>>>>least
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>in the case of indirect CRL but it could also be proven very 
>>>>>>>>useful
>>>>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CA
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>re-keying scenarios.
>>>>>>>>
>>>>>>>>The easiest solution would probably be to allow AIA to be used in
>>>>>>>
>>>>>its
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>>>>
>>>>>critical).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>It
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>would present a very clear and uncomplicated logic to certificate
>>>>>>>>validating applications in many cases.
>>>>>>>>
>>>>>>>>Stefan Santesson
>>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>>
>>>>>>>>________________________________________
>>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>>Sent: den 7 oktober 2004 18:35
>>>>>>>>To: Stefan Santesson
>>>>>>>>Cc: pkix
>>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>>
>>>>>>>>Stefan,
>>>>>>>>
>>>>>>>>I think what you are proposing is a good idea.  In most cases, 
>>>>>>>>path discovery algorithms assume that both the trust anchor (or 
>>>>>>>>trust
>>>>>>>
>>>>>>anchors)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>and the end entity certificate are provided as input.  In this
>>>>>>>>case,
>>>>>>>
>>>>>one
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>may
>>>>>>>>need to construct a certification path without a priori access to
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>end
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>entity certificate (the one with the subject public key
>>>>>>>
>>>>>corresponding to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>>>>
>>>>>pointer) in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>CRL would provide the relying party with a simple way to obtain 
>>>>>>>>the
>>>>>>>
>>>>>end
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>entity certificate for the CRL signing key's certification path. 
>>>>>>>>On
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>other hand, I believe that a relying party should be able to
>>>>>>>
>>>>>construct
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>certification path even without an AIA extension in the CRL, so
>>>>>>>>long
>>>>>>>
>>>>>as
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>it
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>is not an indirect CRL.  Attached is a drawing of the three basic
>>>>>>>>scenarios that I expect a relying party may encounter:
>>>>>>>>
>>>>>>>>In each of these scenarios, the CA has performed key rollover and
>>>>>>>>is
>>>>>>>
>>>>>>only
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>>>>>
>>>>>>however,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>if
>>>>>>>>the CA simply choose to use different keys to sign certificates 
>>>>>>>>and
>>>>>>>
>>>>>CRLs
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>for
>>>>>>>>some other reason.
>>>>>>>>
>>>>>>>>If the PKI architecture resembled figure 1, then the
>>>>>>>>certification
>>>>>>>
>>>>>path
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>for
>>>>>>>>the CRL signing key would just be a subset of the certification
>>>>>>>>path
>>>>>>>
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>EE certificate, so no addition path discovery would be needed.
>>>>>>>>
>>>>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>>>>
>>>>>necessary
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>to
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>obtain the new-signed-with-old self-issued certificate.  In
>>>>>>>>building
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certification path to the EE certificate, however, the relying
>>>>>>>>party
>>>>>>>
>>>>>>will
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>obtain the certificates pointed to by the AIA extension in the EE
>>>>>>>>certificate.  This AIA extension will point to a location 
>>>>>>>>containing
>>>>>>>
>>>>>all
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificates issued to CA 2, which would include both the
>>>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>issued
>>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
>>>>>>>
>>>>>though
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>self-issued certificate would not be part of the certification 
>>>>>>>>path
>>>>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>EE certificate, it would be downloaded by the relying party
>>>>>>>>during
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>construction of that certification path.  (Yes, there are
>>>>>>>>circular dependency issues in figure 2, but that is another 
>>>>>>>>issue.)
>>>>>>>>
>>>>>>>>A similar situation would happen if the PKI architecture
>>>>>>>>resembled
>>>>>>>
>>>>>>figure
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>>>>
>>>>>location
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>containing certificates issued to CA 3.  When the relying party
>>>>>>>
>>>>>>downloaded
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>these certificates, it would obtain both of the certificates 
>>>>>>>>issued
>>>>>>>
>>>>>by
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>Root to CA 3 and so again would have the certificate needed to
>>>>>>>
>>>>>validate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>CRL signing key.
>>>>>>>>
>>>>>>>>In the case of an indirect CRL, things may not work as well.  If
>>>>>>>
>>>>>>indirect
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>CRLs were used, and the PKI architecture resembled figures 2 or 3
>>>>>>>>(replacing "New Key" with a different CA), then the set of 
>>>>>>>>certificates pointed
>>>>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>by
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the AIA extension in the EE certificate would not include the
>>>>>>>
>>>>>>certificate
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>of
>>>>>>>>the CRL signer.  One could find this certificate by building in 
>>>>>>>>the reverse direction and using the SIA extension, but that may 
>>>>>>>>not be the most convenient solution.
>>>>>>>>
>>>>>>>>So, when indirect CRLs are being used, it seems that it would be
>>>>>>>
>>>>>very
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>useful
>>>>>>>>to have a pointer in the CRL to the CRL signing certificate.
>>>>>>>>When
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>is not indirect, the need for this pointer does not seem to be as
>>>>>>>
>>>>>clear,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>but
>>>>>>>>I can't see any harm in including it.
>>>>>>>>
>>>>>>>>Dave
>>>>>>>>
>>>>>>>>Stefan Santesson wrote:
>>>>>>>>All,
>>>>>>>>
>>>>>>>>I'm interested in the opinion from members on this list about
>>>>>>>
>>>>>discovery
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>of
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>CRL signer's certificate in non directory centric environments.
>>>>>>>>
>>>>>>>>The problem is the following.
>>>>>>>>
>>>>>>>>The relying party (RP) needs to check validity of a certificate 
>>>>>>>>and
>>>>>>>
>>>>>>finds
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>a
>>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL
>>>>>>>>which
>>>>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>this
>>>>>>>>particular case is either signed by another key of the CA 
>>>>>>>>(re-keyed
>>>>>>>
>>>>>CA)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>or
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>another entity (indirect CRL).
>>>>>>>>
>>>>>>>>In this case the relying party needs to obtain the certificate of
>>>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>CRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>signer which may NOT be part of the original chain. In a
>>>>>>>>directory
>>>>>>>
>>>>>>centric
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>solution this is retrieved from the directory, but what if such
>>>>>>>
>>>>>>directory
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>is
>>>>>>>>not available or accessible.
>>>>>>>>
>>>>>>>>The RP have thus no hint where to find the CRL issuers
>>>>>>>>certificate
>>>>>>>
>>>>>>unless
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the RP already have possession of it by some other means.
>>>>>>>>
>>>>>>>>Is seems that CRLs would need an AIA extension with the option to
>>>>>>>
>>>>>point
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>to
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>the location of the signers certificate in the same manner as is
>>>>>>>
>>>>>>possible
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>for certificates.
>>>>>>>>
>>>>>>>>Maybe AIA should be defined as both cert and CRL extension and
>>>>>>>>not
>>>>>>>
>>>>>only
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>certificate extension as today.
>>>>>>>>
>>>>>>>>Thoughts and comments?
>>>>>>>>
>>>>>>>>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 i9FBAS3I078962; Fri, 15 Oct 2004 04:10:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FBASBx078961; Fri, 15 Oct 2004 04:10:28 -0700 (PDT)
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 i9FBAOL3078892 for <[e-mail]>; Fri, 15 Oct 2004 04:10:25 -0700 (PDT) (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.0); Fri, 15 Oct 2004 12:10:16 +0100
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: Signer certificate discovery for CRLs
Date: Fri, 15 Oct 2004 12:10:13 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcSyC2L0BmowgKG9SGKYMovSqsAkiAAmrfgA
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Santosh Chokhani" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 15 Oct 2004 11:10:16.0391 (UTC) FILETIME=[8CC04570:01C4B2A7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9FBAQL3078943
Sender: [e-mail]
Precedence: 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,

Unfortunately I fail to understand your questions, issues and requests.

It would be very useful if you could explain how current mechanisms can
be used in a simple and straightforward manner to discover CRL signer
certificates in ALL the use cases discussed, mainly re-keyed CA and
indirect CRLs.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Denis Pinkas
> Sent: den 14 oktober 2004 17:13
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> > Denis:
> 
> > With the three assumptions/constraints I provided, how would you
locate
> the
> > CRL issuer certificate for the two examples using 3280 extensions
and
> > without putting AIA in the CRL?
> 
> As far as I understand, the three assumptions are:
> 
> 1.  You are directory challenged; and
>      [I do not understand what this means]
> 2.  You use AIA to develop the path; and
>      [It does not matter]
> 3.  You develop the path from the end entity to trust anchor
>      [Could also be the contrary].
> 
> If this is not correct, thus please correct.
> 
> Then my request is: "using ANY OF the current extensions that are
defined
> in
> RFC 3280", which includes SIA.
> 
> In your explanations  you said :
> "if you do no deal with SIA et. al"
> 
> This last assumption is neither part of the three assumptions and does
not
> conform to my request.
> 
> Denis
> 
> > That is my point.
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, October 14, 2004 6:22 AM
> > To: Santosh Chokhani
> > Cc: 'pkix'
> > Subject: Re: Signer certificate discovery for CRLs
> >
> >
> > Santosh,
> >
> > You misread my request. I said:
> >
> > "For the time being, I would like that you provide an example where,
> when
> > using the current extensions that are defined in RFC 3280, it will
NOT
> be
> > possible to locate a CRL Issuer certificate."
> >
> > Maybe I would have needed to be clearer and say :
> >
> > "For the time being, I would like that you provide an example where,
> when
> > using ANY OF the current extensions that are defined in RFC 3280, it
> will
> > NOT be possible to locate a CRL Issuer certificate."
> >
> > The examples you provide below do not fulfil this request.
> >
> > The assumption is that there exists a path to be tested for
revocation
> > checking (and that it does not matter to know which way it has been
> > constructed).
> >
> > I am not saying that using AIA in CRL might not be useful, but I am
> still
> > lacking the demonstration that there would be no other way.
> >
> > Denis
> >
> >
> >
> >>Denis:
> >>
> >>Two examples are very simple: one for direct CRL Issuer and one for
> >>Indirect CRL Issuer.
> >>
> >>Let us make the following assumptions that Stefan was making:
> >>
> >>1.  You are directory challenged; and
> >>2.  You use AIA to develop the path; and
> >>3.  You develop the path from the end entity to trust anchor.
> >>
> >>From what I know of MS CAPI, these are reasonable
> >>assumptions/constraints.
> >>
> >>Now the examples.
> >>
> >>Example 1: Direct CRL Issuer
> >>
> >>The certificate trust path is:
> >>Root --> CA1 --> CA 2, old key --> Denis
> >>
> >>The CRL trust path is:
> >>Root --> CA1 --> CA 2, new key --> CRL
> >>
> >>(Note: We do not do self-issued certificate since there is no
simple,
> >>secure way to check their revocation status).
> >>
> >>Now, with AIA in CRL, finding the CA2, new key certificate is
> >>straightforward.  How would you find it if you do no deal with SIA
et.
> >>al.
> >>
> >>Example 2: Indirect CRL Issuer
> >>
> >>The certificate trust path is:
> >>Root --> CA1 --> CA 2 --> Denis
> >>(Note: Denis's certificate points to CRL DP of an indirect CRL
issued
> >>by CAI.
> >>
> >>The CRL trust path is:
> >>Root --> CAI --> CRL
> >>
> >>Now, with AIA in CRL, finding the CAI certificate is
straightforward.
> >>How would you find it if you do no deal with SIA et. al.
> >>
> >>In addition to the need cited above, please note that the extension
> >>semantics does not change, it does not hinder any interoperability,
> >>and it does not break any backward compatibility.  So, what if I
> >>wanted to use this extension in the CRL.  It does no harm to other
> >>relying parties.
> >>
> >>-----Original Message-----
> >>From: [e-mail]
> >>[mailto:[e-mail]] On Behalf Of Denis Pinkas
> >>Sent: Wednesday, October 13, 2004 11:01 AM
> >>To: Stefan Santesson
> >>Cc: Santosh Chokhani; pkix
> >>Subject: Re: Signer certificate discovery for CRLs
> >>
> >>
> >>
> >>Stefan,
> >>
> >>
> >>
> >>>Denis,
> >>
> >>
> >>>I'm not sure what you mean.
> >>
> >>
> >>For the time being, I would like that you provide an example where,
> >>when
> >>using the current extensions that are defined in RFC 3280, it will
NOT
> be
> >>possible to locate a CRL Issuer certificate.
> >>
> >>If you are able to provide that example, then it would justify the
> >>need for
> >>an extension at least for one case. Then we can see what that case
is.
> >>
> >>I am awaiting that example.
> >>
> >>Denis
> >>
> >>
> >>
> >>
> >>>I conclude that I agree with Santosh.
> >>>
> >>>The debate is still open... Feel free to express your opinion.
> >>>
> >>>Stefan Santesson
> >>>Microsoft Security Center of Excellence (SCOE)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Denis Pinkas [mailto:[e-mail]]
> >>>>Sent: den 13 oktober 2004 16:34
> >>>>To: Stefan Santesson
> >>>>Cc: Santosh Chokhani; pkix
> >>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>
> >>>>Stefan,
> >>>>
> >>>>You are making a conclusion without letting me the time to
respond. I
> >>>>will need more time to look at the pictures (and understand them).
> >>>>
> >>>>For the time being, I am still reluctant to accept
> >>>
> >>>"yet-another-method".
> >>>
> >>>
> >>>
> >>>>We already have too many.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Santosh,
> >>>>>
> >>>>>I conclude that we are in complete and total agreement.
> >>>>>The question is how to go about this.
> >>>>
> >>>>>Could we do this amendment to RFC 3280 in its next revision? It
> >>>>>would hopefully just be a minor change.
> >>>>
> >>>>This is exactly what I feared.
> >>>>
> >>>>We usually end-up with a "minor change" in an extension without
> >>>>saying cleary how and when it shall/should be used.
> >>>>
> >>>>I still have in mind that:
> >>>>
> >>>>1) a certification path must first be constructed,
> >>>>2) then the revocation checking of that path must be done.
> >>>>
> >>>>This means that information about CRL issuers certificates
locations
> >>>
> >>>may
> >>>
> >>>
> >>>
> >>>>certainly be found in that chain. If not, I would like an example.
> >>>>
> >>>>Denis
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>It would not change the definition of AIA just add that it can be
> >>>>
> >>>used
> >>>
> >>>
> >>>
> >>>>also as CRL extension and list eventual restrictions and guidance
for
> >>>
> >>>use
> >>>
> >>>
> >>>
> >>>>with CRLs.
> >>>>
> >>>>
> >>>>
> >>>>>Stefan Santesson
> >>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: [e-mail]
> >>>>>
> >>>[mailto:[e-mail]]
> >>>
> >>>
> >>>
> >>>>>>On Behalf Of Santosh Chokhani
> >>>>>>Sent: den 13 oktober 2004 04:33
> >>>>>>To: 'pkix'
> >>>>>>Subject: RE: Signer certificate discovery for CRLs
> >>>>>>
> >>>>>>
> >>>>>>Stefan:
> >>>>>>
> >>>>>>In terms of certificate discovery, your proposal for AIA in CRL
is
> >>>>>
> >>>more
> >>>
> >>>
> >>>
> >>>>>>robust.  The whole idea of self-issued key rollover certificates
> >>>>>>and
> >>>>>
> >>>>then
> >>>>
> >>>>
> >>>>
> >>>>>>using the new key to issue CRL is fraught with security
problems.
> >>>>>>A secure solution would be one where the new key is certified by
> >>>>>>the parent
> >>>>>
> >>>CA.
> >>>
> >>>
> >>>
> >>>>In
> >>>>
> >>>>
> >>>>
> >>>>>>that case to obtain the new certificate, you could use AIA in
CRL.
> >>>>>>
> >>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
> >>>>>>certificate in question points to the indirect CRL.  You get
that
> >>>>>>CRL.  The AIA
> >>>>>
> >>>in
> >>>
> >>>
> >>>
> >>>>CRL
> >>>>
> >>>>
> >>>>
> >>>>>>gets you started for the indirect CRL issuer certification path
and
> >>>>>
> >>>you
> >>>
> >>>
> >>>
> >>>>>>are
> >>>>>>in business.
> >>>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: [e-mail]
> >>>>>
> >>>[mailto:[e-mail]]
> >>>
> >>>
> >>>
> >>>>>>On
> >>>>>>Behalf Of Stefan Santesson
> >>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
> >>>>>>To: David A. Cooper
> >>>>>>Cc: pkix
> >>>>>>Subject: RE: Signer certificate discovery for CRLs
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>David,
> >>>>>>
> >>>>>>Thanks for the clarifications, they make sense.
> >>>>>>I did misread your pictures.
> >>>>>>
> >>>>>>So can we conclude that for a re-keyed CA in accordance with RFC
> >>>>>
> >>>3280,
> >>>
> >>>
> >>>
> >>>>>>either the CRL issuer certificate itself, or the location of the
> >>>>>>CRL issuer certificate, will be clearly identified/available for
> >>>>>>the validating
> >>>>>
> >>>>party
> >>>>
> >>>>
> >>>>
> >>>>>>in some cases, but not in others?
> >>>>>>
> >>>>>>Can we also conclude that there is no real discovery solution
for
> >>>>>
> >>>>indirect
> >>>>
> >>>>
> >>>>
> >>>>>>CRLs?
> >>>>>>
> >>>>>>Do you then agree then that it could be appropriate to allow AIA
as
> >>>>>
> >>>a
> >>>
> >>>
> >>>
> >>>>CRL
> >>>>
> >>>>
> >>>>
> >>>>>>extension to facilitate discovery of CRL signer certificate?
> >>>>>>
> >>>>>>Stefan Santesson
> >>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>
> >>>>>>________________________________________
> >>>>>>From: David A. Cooper [mailto:[e-mail]]
> >>>>>>Sent: den 12 oktober 2004 21:14
> >>>>>>To: Stefan Santesson
> >>>>>>Cc: pkix
> >>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>
> >>>>>>Stefan,
> >>>>>>
> >>>>>>I believe that you are misinterpreting the figures.  They really
do
> >>>>>>represent three different cases, not three different
certification
> >>>>>
> >>>paths
> >>>
> >>>
> >>>
> >>>>>>that have been constructed through the same PKI architecture.
> >>>>>>
> >>>>>>In figure 1, CA 1 has generated self-issued key rollover
> >>>>>
> >>>certificates.
> >>>
> >>>
> >>>
> >>>>>>The
> >>>>>>Root CA has issued a certificate to CA 1's new key, but not its
old
> >>>>>
> >>>key
> >>>
> >>>
> >>>
> >>>>>>(either the Root CA never issued a certificate to CA 1's old key
or
> >>>>>
> >>>that
> >>>
> >>>
> >>>
> >>>>>>certificate has expired).
> >>>>>>
> >>>>>>In figure 2, CA 2 has also generated self-issued key rollover
> >>>>>>certificates. The Root CA has issued a certificate to CA 2's old
> >>>>>>key, but not its
> >>>>>
> >>>new
> >>>
> >>>
> >>>
> >>>>>>key.
> >>>>>>
> >>>>>>In figure 3, when CA 3 performed key rollover, it requested a
new
> >>>>>>CA certificate from the Root CA.  CA 3 did not generated
> >>>>>>self-issued
> >>>>>
> >>>key
> >>>
> >>>
> >>>
> >>>>>>rollover certificates.
> >>>>>>
> >>>>>>Of course, another realistic scenario would be one in which a CA
> >>>>>
> >>>>generated
> >>>>
> >>>>
> >>>>
> >>>>>>self-issued key rollover certificates upon key rollover and then
> >>>>>>had
> >>>>>
> >>>the
> >>>
> >>>
> >>>
> >>>>>>Root CA issue a CA certificate to its new key.  In this case, as
> >>>>>>you suggest, any of the certification paths from figures 1, 2,
or 3
> >>>>>
> >>>could be
> >>>
> >>>
> >>>
> >>>>>>constructed.
> >>>>>>
> >>>>>>As for the contents of the AIA extension, here is what I have
> >>>>>
> >>>specified
> >>>
> >>>
> >>>
> >>>>in
> >>>>
> >>>>
> >>>>
> >>>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
> >>>>>
> >>>>Policy":
> >>>>
> >>>>
> >>>>
> >>>>>>The authorityInfoAccess extension uses URIs for two purposes.
When
> >>>>>
> >>>the
> >>>
> >>>
> >>>
> >>>>>>id-ad-caIssuers access method is used, the access location
> >>>>>>specifies
> >>>>>
> >>>>where
> >>>>
> >>>>
> >>>>
> >>>>>>certificates issued to the issuer of the certificate may be
found.
> >>>>>
> >>>If
> >>>
> >>>
> >>>
> >>>>LDAP
> >>>>
> >>>>
> >>>>
> >>>>>>is used, the URI must include the DN of the entry containing the
> >>>>>
> >>>>relevant
> >>>>
> >>>>
> >>>>
> >>>>>>certificates and specify the directory attribute in which the
> >>>>>
> >>>>certificates
> >>>>
> >>>>
> >>>>
> >>>>>>are located. If the directory in which the certificates are
stored
> >>>>>
> >>>>expects
> >>>>
> >>>>
> >>>>
> >>>>>>the "binary" option to be specified, then the attribute type
must
> >>>>>>be followed by ";binary" in the URI. If HTTP is used, the URI
must
> >>>>>
> >>>point to
> >>>
> >>>
> >>>
> >>>>a
> >>>>
> >>>>
> >>>>
> >>>>>>file that has an extension of ".p7c" that contains a certs-only
CMS
> >>>>>>message (see RFC 2633). The CMS message should include all
> >>>>>>certificates
> >>>>>
> >>>issued
> >>>
> >>>
> >>>
> >>>>to
> >>>>
> >>>>
> >>>>
> >>>>>>the issuer of this certificate, but must at least contain all
> >>>>>
> >>>>certificates
> >>>>
> >>>>
> >>>>
> >>>>>>issued to the issuer of this certificate in which the subject
> >>>>>>public
> >>>>>
> >>>key
> >>>
> >>>
> >>>
> >>>>>>may
> >>>>>>be used to verify the signature on this certificate. .... For a
> >>>>>>certificate issued by "Good CA", some examples of URIs that may
> >>>>>>appear as the
> >>>>>
> >>>access
> >>>
> >>>
> >>>
> >>>>>>location in an authorityInfoAccess extension when the
> >>>>>
> >>>id-ad-caIssuers
> >>>
> >>>
> >>>
> >>>>>>access
> >>>>>>method is used are:
> >>>>>
>
>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACe
r
> >>>>>t
> >>>>>i
> >>>>
> >>>fi
> >>>
> >>>
> >>>
> >>>>ca
> >>>>
> >>>>
> >>>>
> >>>>>>te
> >>>>>>,crossCertificatePair
> >>>>>
>
>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertif
i
> >>>>>c
> >>>>>a
> >>>>
> >>>te
> >>>
> >>>
> >>>
> >>>>;b
> >>>>
> >>>>
> >>>>
> >>>>>>in
> >>>>>>ary,crossCertificatePair;binary
> >>>>>
>
>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIss
u
> >>>>>e
> >>>>>d
> >>>>
> >>>To
> >>>
> >>>
> >>>
> >>>>Go
> >>>>
> >>>>
> >>>>
> >>>>>>od
> >>>>>>CA.p7c
> >>>>>>For both LDAP and HTTP, the URI provides the exact location
where
> >>>>>>information is to be located, so there is no requirement for the
> >>>>>
> >>>relying
> >>>
> >>>
> >>>
> >>>>>>party to try to figure out where information is located.
> >>>>>>
> >>>>>>The HTTP URI points to a certs-only CMS message that includes
all
> >>>>>>certificates issued to the CA identified in the issuer field of
the
> >>>>>>certificate.
> >>>>>>
> >>>>>>The LDAP URI points to the cACertificate and
crossCertificatePair
> >>>>>>attributes of the directory entry of the CA identified in the
> >>>>>>issuer field of
> >>>>>
> >>>the
> >>>
> >>>
> >>>
> >>>>>>certificate.  These two attributes together hold all of the
> >>>>>
> >>>certificates
> >>>
> >>>
> >>>
> >>>>>>issued to the CA:  the cACertificate attribute holds the CA's
self-
> >>>>>
> >>>>issued
> >>>>
> >>>>
> >>>>
> >>>>>>certificates and the crossCertificatePair attribute holds the
> >>>>>>cross-certificates issued to the CA by other CAs.
> >>>>>>
> >>>>>>Dave
> >>>>>>
> >>>>>>
> >>>>>>Stefan Santesson wrote:
> >>>>>>
> >>>>>>David,
> >>>>>>
> >>>>>>Thanks for these good thoughts and very useful scenarios.
> >>>>>>
> >>>>>>I have some comments and questions on this.
> >>>>>>
> >>>>>>First of all we can conclude that in some scenarios (figure 1)
> >>>>>>where
> >>>>>
> >>>a
> >>>
> >>>
> >>>
> >>>>>>self
> >>>>>>issued certificate is inserted into the path, you are likely to
> >>>>>>find
> >>>>>
> >>>the
> >>>
> >>>
> >>>
> >>>>>>CRL
> >>>>>>issuer cert in the path. (given that the new CA have a common
key
> >>>>>
> >>>and
> >>>
> >>>
> >>>
> >>>>>>certificate for cert signing and CRL signing).
> >>>>>>
> >>>>>>Figure 1, 2 and 3 describe the same case. It is just describing
> >>>>>
> >>>>different
> >>>>
> >>>>
> >>>>
> >>>>>>path building strategies. An application that has access locally
to
> >>>>>
> >>>all
> >>>
> >>>
> >>>
> >>>>>>chaining options may however still choose path 2 for the certs
and
> >>>>>
> >>>path
> >>>
> >>>
> >>>
> >>>>1
> >>>>
> >>>>
> >>>>
> >>>>>>for the CRL independent of each other (which I think figure 3
tries
> >>>>>
> >>>to
> >>>
> >>>
> >>>
> >>>>>>describe)
> >>>>>>
> >>>>>>Another comment is the structure of AIA extensions. The use I'm
> >>>>>
> >>>familiar
> >>>
> >>>
> >>>
> >>>>>>with doesn't use AIA to describe a directory entry where it is
left
> >>>>>
> >>>to
> >>>
> >>>
> >>>
> >>>>the
> >>>>
> >>>>
> >>>>
> >>>>>>validation application logic to be intelligent enough to find
> >>>>>
> >>>>appropriate
> >>>>
> >>>>
> >>>>
> >>>>>>certificate data from the directory. The model I'm familiar with
is
> >>>>>
> >>>when
> >>>
> >>>
> >>>
> >>>>>>the
> >>>>>>AIA URL explicitly identifies the exact location of the
appropriate
> >>>>>
> >>>CA
> >>>
> >>>
> >>>
> >>>>>>certificate file, relieving the validation software from complex
> >>>>>>information queries. If just location of explicit certificate
files
> >>>>>>are
> >>>>>
> >>>identified
> >>>
> >>>
> >>>
> >>>>>>through AIA, the presence of an AIA may not help finding the CRL
> >>>>>
> >>>signer
> >>>
> >>>
> >>>
> >>>>>>cert
> >>>>>>if this is different from the CA certificate. This is also the
> >>>>>
> >>>problem
> >>>
> >>>
> >>>
> >>>>>>with
> >>>>>>Denis proposal.
> >>>>>>
> >>>>>>I think we share the basic conclusion that the ability to locate
> >>>>>>the
> >>>>>
> >>>CRL
> >>>
> >>>
> >>>
> >>>>>>signer certificate directly through the CRL could be very
useful.
> >>>>>>At
> >>>>>
> >>>>least
> >>>>
> >>>>
> >>>>
> >>>>>>in the case of indirect CRL but it could also be proven very
useful
> >>>>>
> >>>in
> >>>
> >>>
> >>>
> >>>>CA
> >>>>
> >>>>
> >>>>
> >>>>>>re-keying scenarios.
> >>>>>>
> >>>>>>The easiest solution would probably be to allow AIA to be used
in
> >>>>>
> >>>its
> >>>
> >>>
> >>>
> >>>>>>current shape and structure as a CRL extension (MUST NOT be
> >>>>>
> >>>critical).
> >>>
> >>>
> >>>
> >>>>It
> >>>>
> >>>>
> >>>>
> >>>>>>would present a very clear and uncomplicated logic to
certificate
> >>>>>>validating applications in many cases.
> >>>>>>
> >>>>>>Stefan Santesson
> >>>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>>
> >>>>>>________________________________________
> >>>>>>From: David A. Cooper [mailto:[e-mail]]
> >>>>>>Sent: den 7 oktober 2004 18:35
> >>>>>>To: Stefan Santesson
> >>>>>>Cc: pkix
> >>>>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>>>
> >>>>>>Stefan,
> >>>>>>
> >>>>>>I think what you are proposing is a good idea.  In most cases,
path
> >>>>>>discovery algorithms assume that both the trust anchor (or trust
> >>>>>
> >>>>anchors)
> >>>>
> >>>>
> >>>>
> >>>>>>and the end entity certificate are provided as input.  In this
> >>>>>>case,
> >>>>>
> >>>one
> >>>
> >>>
> >>>
> >>>>>>may
> >>>>>>need to construct a certification path without a priori access
to
> >>>>>
> >>>the
> >>>
> >>>
> >>>
> >>>>end
> >>>>
> >>>>
> >>>>
> >>>>>>entity certificate (the one with the subject public key
> >>>>>
> >>>corresponding to
> >>>
> >>>
> >>>
> >>>>>>the
> >>>>>>CRL signing key).  Including an AIA extension (or some other
> >>>>>
> >>>pointer) in
> >>>
> >>>
> >>>
> >>>>>>the
> >>>>>>CRL would provide the relying party with a simple way to obtain
the
> >>>>>
> >>>end
> >>>
> >>>
> >>>
> >>>>>>entity certificate for the CRL signing key's certification path.
On
> >>>>>
> >>>the
> >>>
> >>>
> >>>
> >>>>>>other hand, I believe that a relying party should be able to
> >>>>>
> >>>construct
> >>>
> >>>
> >>>
> >>>>the
> >>>>
> >>>>
> >>>>
> >>>>>>certification path even without an AIA extension in the CRL, so
> >>>>>>long
> >>>>>
> >>>as
> >>>
> >>>
> >>>
> >>>>it
> >>>>
> >>>>
> >>>>
> >>>>>>is not an indirect CRL.  Attached is a drawing of the three
basic
> >>>>>>scenarios that I expect a relying party may encounter:
> >>>>>>
> >>>>>>In each of these scenarios, the CA has performed key rollover
and
> >>>>>>is
> >>>>>
> >>>>only
> >>>>
> >>>>
> >>>>
> >>>>>>signing CRLs with its new key.  The diagrams would look similar,
> >>>>>
> >>>>however,
> >>>>
> >>>>
> >>>>
> >>>>>>if
> >>>>>>the CA simply choose to use different keys to sign certificates
and
> >>>>>
> >>>CRLs
> >>>
> >>>
> >>>
> >>>>>>for
> >>>>>>some other reason.
> >>>>>>
> >>>>>>If the PKI architecture resembled figure 1, then the
certification
> >>>>>
> >>>path
> >>>
> >>>
> >>>
> >>>>>>for
> >>>>>>the CRL signing key would just be a subset of the certification
> >>>>>>path
> >>>>>
> >>>for
> >>>
> >>>
> >>>
> >>>>>>the
> >>>>>>EE certificate, so no addition path discovery would be needed.
> >>>>>>
> >>>>>>If the PKI architecture resembled figure 1, then it would be
> >>>>>
> >>>necessary
> >>>
> >>>
> >>>
> >>>>to
> >>>>
> >>>>
> >>>>
> >>>>>>obtain the new-signed-with-old self-issued certificate.  In
> >>>>>>building
> >>>>>
> >>>the
> >>>
> >>>
> >>>
> >>>>>>certification path to the EE certificate, however, the relying
> >>>>>>party
> >>>>>
> >>>>will
> >>>>
> >>>>
> >>>>
> >>>>>>obtain the certificates pointed to by the AIA extension in the
EE
> >>>>>>certificate.  This AIA extension will point to a location
> >>>>>>containing
> >>>>>
> >>>all
> >>>
> >>>
> >>>
> >>>>>>certificates issued to CA 2, which would include both the
> >>>>>
> >>>certificate
> >>>
> >>>
> >>>
> >>>>>>issued
> >>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So,
even
> >>>>>
> >>>though
> >>>
> >>>
> >>>
> >>>>>>the
> >>>>>>self-issued certificate would not be part of the certification
path
> >>>>>
> >>>to
> >>>
> >>>
> >>>
> >>>>the
> >>>>
> >>>>
> >>>>
> >>>>>>EE certificate, it would be downloaded by the relying party
during
> >>>>>
> >>>the
> >>>
> >>>
> >>>
> >>>>>>construction of that certification path.  (Yes, there are
circular
> >>>>>>dependency issues in figure 2, but that is another issue.)
> >>>>>>
> >>>>>>A similar situation would happen if the PKI architecture
resembled
> >>>>>
> >>>>figure
> >>>>
> >>>>
> >>>>
> >>>>>>3.  The AIA extension in the EE certificate would point to a
> >>>>>
> >>>location
> >>>
> >>>
> >>>
> >>>>>>containing certificates issued to CA 3.  When the relying party
> >>>>>
> >>>>downloaded
> >>>>
> >>>>
> >>>>
> >>>>>>these certificates, it would obtain both of the certificates
issued
> >>>>>
> >>>by
> >>>
> >>>
> >>>
> >>>>the
> >>>>
> >>>>
> >>>>
> >>>>>>Root to CA 3 and so again would have the certificate needed to
> >>>>>
> >>>validate
> >>>
> >>>
> >>>
> >>>>>>the
> >>>>>>CRL signing key.
> >>>>>>
> >>>>>>In the case of an indirect CRL, things may not work as well.  If
> >>>>>
> >>>>indirect
> >>>>
> >>>>
> >>>>
> >>>>>>CRLs were used, and the PKI architecture resembled figures 2 or
3
> >>>>>>(replacing "New Key" with a different CA), then the set of
> >>>>>>certificates pointed
> >>>>>
> >>>to
> >>>
> >>>
> >>>
> >>>>by
> >>>>
> >>>>
> >>>>
> >>>>>>the AIA extension in the EE certificate would not include the
> >>>>>
> >>>>certificate
> >>>>
> >>>>
> >>>>
> >>>>>>of
> >>>>>>the CRL signer.  One could find this certificate by building in
the
> >>>>>>reverse direction and using the SIA extension, but that may not
be
> >>>>>>the most convenient solution.
> >>>>>>
> >>>>>>So, when indirect CRLs are being used, it seems that it would be
> >>>>>
> >>>very
> >>>
> >>>
> >>>
> >>>>>>useful
> >>>>>>to have a pointer in the CRL to the CRL signing certificate.
When
> >>>>>
> >>>the
> >>>
> >>>
> >>>
> >>>>CRL
> >>>>
> >>>>
> >>>>
> >>>>>>is not indirect, the need for this pointer does not seem to be
as
> >>>>>
> >>>clear,
> >>>
> >>>
> >>>
> >>>>>>but
> >>>>>>I can't see any harm in including it.
> >>>>>>
> >>>>>>Dave
> >>>>>>
> >>>>>>Stefan Santesson wrote:
> >>>>>>All,
> >>>>>>
> >>>>>>I'm interested in the opinion from members on this list about
> >>>>>
> >>>discovery
> >>>
> >>>
> >>>
> >>>>of
> >>>>
> >>>>
> >>>>
> >>>>>>CRL signer's certificate in non directory centric environments.
> >>>>>>
> >>>>>>The problem is the following.
> >>>>>>
> >>>>>>The relying party (RP) needs to check validity of a certificate
and
> >>>>>
> >>>>finds
> >>>>
> >>>>
> >>>>
> >>>>>>a
> >>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL
> >>>>>>which
> >>>>>
> >>>in
> >>>
> >>>
> >>>
> >>>>>>this
> >>>>>>particular case is either signed by another key of the CA
(re-keyed
> >>>>>
> >>>CA)
> >>>
> >>>
> >>>
> >>>>or
> >>>>
> >>>>
> >>>>
> >>>>>>another entity (indirect CRL).
> >>>>>>
> >>>>>>In this case the relying party needs to obtain the certificate
of
> >>>>>
> >>>the
> >>>
> >>>
> >>>
> >>>>CRL
> >>>>
> >>>>
> >>>>
> >>>>>>signer which may NOT be part of the original chain. In a
directory
> >>>>>
> >>>>centric
> >>>>
> >>>>
> >>>>
> >>>>>>solution this is retrieved from the directory, but what if such
> >>>>>
> >>>>directory
> >>>>
> >>>>
> >>>>
> >>>>>>is
> >>>>>>not available or accessible.
> >>>>>>
> >>>>>>The RP have thus no hint where to find the CRL issuers
certificate
> >>>>>
> >>>>unless
> >>>>
> >>>>
> >>>>
> >>>>>>the RP already have possession of it by some other means.
> >>>>>>
> >>>>>>Is seems that CRLs would need an AIA extension with the option
to
> >>>>>
> >>>point
> >>>
> >>>
> >>>
> >>>>to
> >>>>
> >>>>
> >>>>
> >>>>>>the location of the signers certificate in the same manner as is
> >>>>>
> >>>>possible
> >>>>
> >>>>
> >>>>
> >>>>>>for certificates.
> >>>>>>
> >>>>>>Maybe AIA should be defined as both cert and CRL extension and
not
> >>>>>
> >>>only
> >>>
> >>>
> >>>
> >>>>>>certificate extension as today.
> >>>>>>
> >>>>>>Thoughts and comments?
> >>>>>>
> >>>>>>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 i9FALmC0061240; Fri, 15 Oct 2004 03:21:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FALmHl061239; Fri, 15 Oct 2004 03:21:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FALlLY061203 for <[e-mail]>; Fri, 15 Oct 2004 03:21:47 -0700 (PDT) (envelope-from [e-mail])
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 15 Oct 2004 03:30:58 -0700
X-BrightmailFiltered: true
Received: from mira-sjc5-e.cisco.com (IDENT:[e-mail] [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9FALdk2002829; Fri, 15 Oct 2004 03:21:40 -0700 (PDT)
Received: from [192.158.127.234] (sjc-vpn4-105.cisco.com [10.21.80.105]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATE04744; Fri, 15 Oct 2004 03:21:38 -0700 (PDT)
User-Agent: Microsoft-Entourage/11.0.0.040405
Date: Fri, 15 Oct 2004 11:47:19 +0200
Subject: questions about draft-ietf-pkix-certstore-http-08
From: Cullen Jennings <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
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>

First of all let me say, I really like this and have for a long time - I'm
really glad to see the IESG last call on it.

I'm not exactly sure if I understand what the uri attribute matches. I want
something that matches any one of the entries in the SubjectAltName list.

In section 2.2 when using the uri attribute, I assume that if a certificate
had a SubjectAltName with a two URI's of say im:[e-mail] and
xmpp:[e-mail], if I did a query (with appropriate escaping which I
did not do below) of

GET /search.cgi?uri=im:[e-mail] HTTP/1.1

that it would find this cert. Do I have this correct?

Thanks, Cullen




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9F9eAtZ043760; Fri, 15 Oct 2004 02:40:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F9eAZH043759; Fri, 15 Oct 2004 02:40:10 -0700 (PDT)
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 i9F9e9hL043748 for <[e-mail]>; Fri, 15 Oct 2004 02:40:09 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (PPP-219.65.51.10.mum2.vsnl.net.in [219.65.51.10]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9F9dm3r008859 for <[e-mail]>; Fri, 15 Oct 2004 05:40:03 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Fri, 15 Oct 2004 05:38:07 -0400
Message-ID: <000301c4b29a$f3450130$[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 i9F9eAhL043753
Sender: [e-mail]
Precedence: 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:

1.  This is a good mechanism to start building the path for CRL signer.  If
you have a better alternative for directory challenged environments, please
tell us.  Absent you showing that there is a mechanism for directory
challenged environments that is as simple and that works, we can not have a
fruitful dialog.

2.  Adding AIA to CRL does not impact interoperability, security or backward
compatibility adversely.

As to your argument, we could have used it few years back and not added AIA
to the certificates either.

-----Original Message-----
From: Denis Pinks [mailto:[e-mail]] 
Sent: Friday, October 15, 2004 2:45 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs


Santosh,

You are still trying to avoid to respond to my request. So my temporary 
conclusion is that you have NOT demonstrated that your proposal is really 
necessary and it is thus "yet-another-method".

> Denis:

> By directory challenged, I mean you do not use LDAP client or DAP or
> DSP to query for certificate.

RFC 3280. Page 46:

    The accessLocation
    field is defined as a GeneralName, which can take several forms.
    Where the information is available via http, ftp, or ldap,
    accessLocation MUST be a uniformResourceIdentifier.  Where the
    information is available via the Directory Access Protocol (DAP),
    accessLocation MUST be a directoryName.

It is thus perfectly allowed and valid to use DAP or ldap.

> The basic point is that if AIA or local store are the primary ways to
> obtain certificates,

No. Local store is of no use. AIA is one possibility, while the other one is

SIA.

> since the CRL issuer certificate is not in any payload, AIA in CRL
> helps obtain that certificate and start the path development process 
> for the CRL certification path.

No. You can use AIA or SIA in CA certificates, or AIA in leaf certificate.

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, October 14, 2004 11:13 AM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> 
>>Denis:
> 
> 
>>With the three assumptions/constraints I provided, how would you 
>>locate the CRL issuer certificate for the two examples using 3280 
>>extensions and without putting AIA in the CRL?
> 
> 
> As far as I understand, the three assumptions are:
> 
> 1.  You are directory challenged; and
>      [I do not understand what this means]
> 2.  You use AIA to develop the path; and
>      [It does not matter]
> 3.  You develop the path from the end entity to trust anchor
>      [Could also be the contrary].
> 
> If this is not correct, thus please correct.
> 
> Then my request is: "using ANY OF the current extensions that are
> defined in
> 
> RFC 3280", which includes SIA.
> 
> In your explanations  you said :
> "if you do no deal with SIA et. al"
> 
> This last assumption is neither part of the three assumptions and does
> not
> conform to my request.
> 
> Denis
> 
> 
>>That is my point.
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, October 14, 2004 6:22 AM
>>To: Santosh Chokhani
>>Cc: 'pkix'
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>
>>Santosh,
>>
>>You misread my request. I said:
>>
>>"For the time being, I would like that you provide an example where, 
>>when using the current extensions that are defined in RFC 3280, it 
>>will NOT be possible to locate a CRL Issuer certificate."
>>
>>Maybe I would have needed to be clearer and say :
>>
>>"For the time being, I would like that you provide an example where, 
>>when using ANY OF the current extensions that are defined in RFC 3280, 
>>it will NOT be possible to locate a CRL Issuer certificate."
>>
>>The examples you provide below do not fulfil this request.
>>
>>The assumption is that there exists a path to be tested for revocation
>>checking (and that it does not matter to know which way it has been 
>>constructed).
>>
>>I am not saying that using AIA in CRL might not be useful, but I am 
>>still lacking the demonstration that there would be no other way.
>>
>>Denis
>>
>>
>>
>>
>>>Denis:
>>>
>>>Two examples are very simple: one for direct CRL Issuer and one for
>>>Indirect CRL Issuer.
>>>
>>>Let us make the following assumptions that Stefan was making:
>>>
>>>1.  You are directory challenged; and
>>>2.  You use AIA to develop the path; and
>>>3.  You develop the path from the end entity to trust anchor.
>>>
>>
>>>From what I know of MS CAPI, these are reasonable
>>
>>>assumptions/constraints.
>>>
>>>Now the examples.
>>>
>>>Example 1: Direct CRL Issuer
>>>
>>>The certificate trust path is:
>>>Root --> CA1 --> CA 2, old key --> Denis
>>>
>>>The CRL trust path is:
>>>Root --> CA1 --> CA 2, new key --> CRL
>>>
>>>(Note: We do not do self-issued certificate since there is no simple,
>>>secure way to check their revocation status).
>>>
>>>Now, with AIA in CRL, finding the CA2, new key certificate is
>>>straightforward.  How would you find it if you do no deal with SIA 
>>>et. al.
>>>
>>>Example 2: Indirect CRL Issuer
>>>
>>>The certificate trust path is:
>>>Root --> CA1 --> CA 2 --> Denis
>>>(Note: Denis's certificate points to CRL DP of an indirect CRL issued
>>>by CAI.
>>>
>>>The CRL trust path is:
>>>Root --> CAI --> CRL
>>>
>>>Now, with AIA in CRL, finding the CAI certificate is straightforward.
>>>How would you find it if you do no deal with SIA et. al.
>>>
>>>In addition to the need cited above, please note that the extension
>>>semantics does not change, it does not hinder any interoperability, 
>>>and it does not break any backward compatibility.  So, what if I 
>>>wanted to use this extension in the CRL.  It does no harm to other 
>>>relying parties.
>>>
>>>-----Original Message-----
>>>From: [e-mail]
>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>>Sent: Wednesday, October 13, 2004 11:01 AM
>>>To: Stefan Santesson
>>>Cc: Santosh Chokhani; pkix
>>>Subject: Re: Signer certificate discovery for CRLs
>>>
>>>
>>>
>>>Stefan,
>>>
>>>
>>>
>>>
>>>>Denis,
>>>
>>>
>>>>I'm not sure what you mean.
>>>
>>>
>>>For the time being, I would like that you provide an example where,
>>>when using the current extensions that are defined in RFC 3280, it 
>>>will NOT be possible to locate a CRL Issuer certificate.
>>>
>>>If you are able to provide that example, then it would justify the
>>>need for an extension at least for one case. Then we can see what 
>>>that case is.
>>>
>>>I am awaiting that example.
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>
>>>>I conclude that I agree with Santosh.
>>>>
>>>>The debate is still open... Feel free to express your opinion.
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>Sent: den 13 oktober 2004 16:34
>>>>>To: Stefan Santesson
>>>>>Cc: Santosh Chokhani; pkix
>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>
>>>>>Stefan,
>>>>>
>>>>>You are making a conclusion without letting me the time to respond. 
>>>>>I will need more time to look at the pictures (and understand 
>>>>>them).
>>>>>
>>>>>For the time being, I am still reluctant to accept
>>>>
>>>>"yet-another-method".
>>>>
>>>>
>>>>
>>>>
>>>>>We already have too many.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Santosh,
>>>>>>
>>>>>>I conclude that we are in complete and total agreement. The 
>>>>>>question is how to go about this.
>>>>>
>>>>>>Could we do this amendment to RFC 3280 in its next revision? It
>>>>>>would hopefully just be a minor change.
>>>>>
>>>>>This is exactly what I feared.
>>>>>
>>>>>We usually end-up with a "minor change" in an extension without
>>>>>saying cleary how and when it shall/should be used.
>>>>>
>>>>>I still have in mind that:
>>>>>
>>>>>1) a certification path must first be constructed,
>>>>>2) then the revocation checking of that path must be done.
>>>>>
>>>>>This means that information about CRL issuers certificates
>>>>>locations
>>>>
>>>>may
>>>>
>>>>
>>>>
>>>>
>>>>>certainly be found in that chain. If not, I would like an example.
>>>>>
>>>>>Denis
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>It would not change the definition of AIA just add that it can be
>>>>>
>>>>used
>>>>
>>>>
>>>>
>>>>
>>>>>also as CRL extension and list eventual restrictions and guidance 
>>>>>for
>>>>
>>>>use
>>>>
>>>>
>>>>
>>>>
>>>>>with CRLs.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Stefan Santesson
>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: [e-mail]
>>>>>>
>>>>[mailto:[e-mail]]
>>>>
>>>>
>>>>
>>>>
>>>>>>>On Behalf Of Santosh Chokhani
>>>>>>>Sent: den 13 oktober 2004 04:33
>>>>>>>To: 'pkix'
>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>
>>>>>>>Stefan:
>>>>>>>
>>>>>>>In terms of certificate discovery, your proposal for AIA in CRL
>>>>>>>is
>>>>>>
>>>>more
>>>>
>>>>
>>>>
>>>>
>>>>>>>robust.  The whole idea of self-issued key rollover certificates
>>>>>>>and
>>>>>>
>>>>>then
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>using the new key to issue CRL is fraught with security problems.
>>>>>>>A secure solution would be one where the new key is certified by 
>>>>>>>the parent
>>>>>>
>>>>CA.
>>>>
>>>>
>>>>
>>>>
>>>>>In
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>that case to obtain the new certificate, you could use AIA in
>>>>>>>CRL.
>>>>>>>
>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
>>>>>>>certificate in question points to the indirect CRL.  You get that 
>>>>>>>CRL.  The AIA
>>>>>>
>>>>in
>>>>
>>>>
>>>>
>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>gets you started for the indirect CRL issuer certification path 
>>>>>>>and
>>>>>>
>>>>you
>>>>
>>>>
>>>>
>>>>
>>>>>>>are
>>>>>>>in business.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: [e-mail]
>>>>>>
>>>>[mailto:[e-mail]]
>>>>
>>>>
>>>>
>>>>
>>>>>>>On
>>>>>>>Behalf Of Stefan Santesson
>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>>>To: David A. Cooper
>>>>>>>Cc: pkix
>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>David,
>>>>>>>
>>>>>>>Thanks for the clarifications, they make sense.
>>>>>>>I did misread your pictures.
>>>>>>>
>>>>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>>>>
>>>>3280,
>>>>
>>>>
>>>>
>>>>
>>>>>>>either the CRL issuer certificate itself, or the location of the
>>>>>>>CRL issuer certificate, will be clearly identified/available for 
>>>>>>>the validating
>>>>>>
>>>>>party
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>in some cases, but not in others?
>>>>>>>
>>>>>>>Can we also conclude that there is no real discovery solution for
>>>>>>
>>>>>indirect
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>CRLs?
>>>>>>>
>>>>>>>Do you then agree then that it could be appropriate to allow AIA 
>>>>>>>as
>>>>>>
>>>>a
>>>>
>>>>
>>>>
>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>>>
>>>>>>>Stefan Santesson
>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>
>>>>>>>________________________________________
>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>Sent: den 12 oktober 2004 21:14
>>>>>>>To: Stefan Santesson
>>>>>>>Cc: pkix
>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>Stefan,
>>>>>>>
>>>>>>>I believe that you are misinterpreting the figures.  They really 
>>>>>>>do represent three different cases, not three different 
>>>>>>>certification
>>>>>>
>>>>paths
>>>>
>>>>
>>>>
>>>>
>>>>>>>that have been constructed through the same PKI architecture.
>>>>>>>
>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>>>
>>>>certificates.
>>>>
>>>>
>>>>
>>>>
>>>>>>>The
>>>>>>>Root CA has issued a certificate to CA 1's new key, but not its 
>>>>>>>old
>>>>>>
>>>>key
>>>>
>>>>
>>>>
>>>>
>>>>>>>(either the Root CA never issued a certificate to CA 1's old key 
>>>>>>>or
>>>>>>
>>>>that
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate has expired).
>>>>>>>
>>>>>>>In figure 2, CA 2 has also generated self-issued key rollover
>>>>>>>certificates. The Root CA has issued a certificate to CA 2's old 
>>>>>>>key, but not its
>>>>>>
>>>>new
>>>>
>>>>
>>>>
>>>>
>>>>>>>key.
>>>>>>>
>>>>>>>In figure 3, when CA 3 performed key rollover, it requested a new
>>>>>>>CA certificate from the Root CA.  CA 3 did not generated 
>>>>>>>self-issued
>>>>>>
>>>>key
>>>>
>>>>
>>>>
>>>>
>>>>>>>rollover certificates.
>>>>>>>
>>>>>>>Of course, another realistic scenario would be one in which a CA
>>>>>>
>>>>>generated
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>self-issued key rollover certificates upon key rollover and then
>>>>>>>had
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>Root CA issue a CA certificate to its new key.  In this case, as
>>>>>>>you suggest, any of the certification paths from figures 1, 2, or 
>>>>>>>3
>>>>>>
>>>>could be
>>>>
>>>>
>>>>
>>>>
>>>>>>>constructed.
>>>>>>>
>>>>>>>As for the contents of the AIA extension, here is what I have
>>>>>>
>>>>specified
>>>>
>>>>
>>>>
>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>>>>
>>>>>Policy":
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>The authorityInfoAccess extension uses URIs for two purposes.
>>>>>>>When
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>id-ad-caIssuers access method is used, the access location
>>>>>>>specifies
>>>>>>
>>>>>where
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certificates issued to the issuer of the certificate may be
>>>>>>>found.
>>>>>>
>>>>If
>>>>
>>>>
>>>>
>>>>
>>>>>LDAP
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>is used, the URI must include the DN of the entry containing the
>>>>>>
>>>>>relevant
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certificates and specify the directory attribute in which the
>>>>>>
>>>>>certificates
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>are located. If the directory in which the certificates are
>>>>>>>stored
>>>>>>
>>>>>expects
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the "binary" option to be specified, then the attribute type must
>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the URI 
>>>>>>>must
>>>>>>
>>>>point to
>>>>
>>>>
>>>>
>>>>
>>>>>a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>file that has an extension of ".p7c" that contains a certs-only 
>>>>>>>CMS message (see RFC 2633). The CMS message should include all
>>>>>>>certificates
>>>>>>
>>>>issued
>>>>
>>>>
>>>>
>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the issuer of this certificate, but must at least contain all
>>>>>>
>>>>>certificates
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>issued to the issuer of this certificate in which the subject
>>>>>>>public
>>>>>>
>>>>key
>>>>
>>>>
>>>>
>>>>
>>>>>>>may
>>>>>>>be used to verify the signature on this certificate. .... For a
>>>>>>>certificate issued by "Good CA", some examples of URIs that may 
>>>>>>>appear as the
>>>>>>
>>>>access
>>>>
>>>>
>>>>
>>>>
>>>>>>>location in an authorityInfoAccess extension when the
>>>>>>
>>>>id-ad-caIssuers
>>>>
>>>>
>>>>
>>>>
>>>>>>>access
>>>>>>>method is used are:
>>>>>>
>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cAC
>>>>>>e
>>>>>>r
>>>>>>t
>>>>>>i
>>>>>
>>>>fi
>>>>
>>>>
>>>>
>>>>
>>>>>ca
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>te
>>>>>>>,crossCertificatePair
>>>>>>
>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACerti
>>>>>>f
>>>>>>i
>>>>>>c
>>>>>>a
>>>>>
>>>>te
>>>>
>>>>
>>>>
>>>>
>>>>>;b
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>in
>>>>>>>ary,crossCertificatePair;binary
>>>>>>
>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIs
>>>>>>s
>>>>>>u
>>>>>>e
>>>>>>d
>>>>>
>>>>To
>>>>
>>>>
>>>>
>>>>
>>>>>Go
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>od
>>>>>>>CA.p7c
>>>>>>>For both LDAP and HTTP, the URI provides the exact location where
>>>>>>>information is to be located, so there is no requirement for the
>>>>>>
>>>>relying
>>>>
>>>>
>>>>
>>>>
>>>>>>>party to try to figure out where information is located.
>>>>>>>
>>>>>>>The HTTP URI points to a certs-only CMS message that includes all
>>>>>>>certificates issued to the CA identified in the issuer field of 
>>>>>>>the certificate.
>>>>>>>
>>>>>>>The LDAP URI points to the cACertificate and crossCertificatePair
>>>>>>>attributes of the directory entry of the CA identified in the 
>>>>>>>issuer field of
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate.  These two attributes together hold all of the
>>>>>>
>>>>certificates
>>>>
>>>>
>>>>
>>>>
>>>>>>>issued to the CA:  the cACertificate attribute holds the CA's
>>>>>>>self-
>>>>>>
>>>>>issued
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certificates and the crossCertificatePair attribute holds the
>>>>>>>cross-certificates issued to the CA by other CAs.
>>>>>>>
>>>>>>>Dave
>>>>>>>
>>>>>>>
>>>>>>>Stefan Santesson wrote:
>>>>>>>
>>>>>>>David,
>>>>>>>
>>>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>>>
>>>>>>>I have some comments and questions on this.
>>>>>>>
>>>>>>>First of all we can conclude that in some scenarios (figure 1)
>>>>>>>where
>>>>>>
>>>>a
>>>>
>>>>
>>>>
>>>>
>>>>>>>self
>>>>>>>issued certificate is inserted into the path, you are likely to
>>>>>>>find
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>CRL
>>>>>>>issuer cert in the path. (given that the new CA have a common key
>>>>>>
>>>>and
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate for cert signing and CRL signing).
>>>>>>>
>>>>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>>>>
>>>>>different
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>path building strategies. An application that has access locally 
>>>>>>>to
>>>>>>
>>>>all
>>>>
>>>>
>>>>
>>>>
>>>>>>>chaining options may however still choose path 2 for the certs
>>>>>>>and
>>>>>>
>>>>path
>>>>
>>>>
>>>>
>>>>
>>>>>1
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>for the CRL independent of each other (which I think figure 3 
>>>>>>>tries
>>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>>>describe)
>>>>>>>
>>>>>>>Another comment is the structure of AIA extensions. The use I'm
>>>>>>
>>>>familiar
>>>>
>>>>
>>>>
>>>>
>>>>>>>with doesn't use AIA to describe a directory entry where it is 
>>>>>>>left
>>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>validation application logic to be intelligent enough to find
>>>>>>
>>>>>appropriate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certificate data from the directory. The model I'm familiar with 
>>>>>>>is
>>>>>>
>>>>when
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>AIA URL explicitly identifies the exact location of the 
>>>>>>>appropriate
>>>>>>
>>>>CA
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate file, relieving the validation software from complex
>>>>>>>information queries. If just location of explicit certificate 
>>>>>>>files are
>>>>>>
>>>>identified
>>>>
>>>>
>>>>
>>>>
>>>>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>>>>
>>>>signer
>>>>
>>>>
>>>>
>>>>
>>>>>>>cert
>>>>>>>if this is different from the CA certificate. This is also the
>>>>>>
>>>>problem
>>>>
>>>>
>>>>
>>>>
>>>>>>>with
>>>>>>>Denis proposal.
>>>>>>>
>>>>>>>I think we share the basic conclusion that the ability to locate
>>>>>>>the
>>>>>>
>>>>CRL
>>>>
>>>>
>>>>
>>>>
>>>>>>>signer certificate directly through the CRL could be very useful.
>>>>>>>At
>>>>>>
>>>>>least
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>in the case of indirect CRL but it could also be proven very 
>>>>>>>useful
>>>>>>
>>>>in
>>>>
>>>>
>>>>
>>>>
>>>>>CA
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>re-keying scenarios.
>>>>>>>
>>>>>>>The easiest solution would probably be to allow AIA to be used in
>>>>>>
>>>>its
>>>>
>>>>
>>>>
>>>>
>>>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>>>
>>>>critical).
>>>>
>>>>
>>>>
>>>>
>>>>>It
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>would present a very clear and uncomplicated logic to certificate
>>>>>>>validating applications in many cases.
>>>>>>>
>>>>>>>Stefan Santesson
>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>
>>>>>>>________________________________________
>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>Sent: den 7 oktober 2004 18:35
>>>>>>>To: Stefan Santesson
>>>>>>>Cc: pkix
>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>Stefan,
>>>>>>>
>>>>>>>I think what you are proposing is a good idea.  In most cases, 
>>>>>>>path discovery algorithms assume that both the trust anchor (or 
>>>>>>>trust
>>>>>>
>>>>>anchors)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>and the end entity certificate are provided as input.  In this
>>>>>>>case,
>>>>>>
>>>>one
>>>>
>>>>
>>>>
>>>>
>>>>>>>may
>>>>>>>need to construct a certification path without a priori access to
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>end
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>entity certificate (the one with the subject public key
>>>>>>
>>>>corresponding to
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>>>
>>>>pointer) in
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>CRL would provide the relying party with a simple way to obtain 
>>>>>>>the
>>>>>>
>>>>end
>>>>
>>>>
>>>>
>>>>
>>>>>>>entity certificate for the CRL signing key's certification path. 
>>>>>>>On
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>other hand, I believe that a relying party should be able to
>>>>>>
>>>>construct
>>>>
>>>>
>>>>
>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certification path even without an AIA extension in the CRL, so
>>>>>>>long
>>>>>>
>>>>as
>>>>
>>>>
>>>>
>>>>
>>>>>it
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>is not an indirect CRL.  Attached is a drawing of the three basic
>>>>>>>scenarios that I expect a relying party may encounter:
>>>>>>>
>>>>>>>In each of these scenarios, the CA has performed key rollover and
>>>>>>>is
>>>>>>
>>>>>only
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>>>>
>>>>>however,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>if
>>>>>>>the CA simply choose to use different keys to sign certificates 
>>>>>>>and
>>>>>>
>>>>CRLs
>>>>
>>>>
>>>>
>>>>
>>>>>>>for
>>>>>>>some other reason.
>>>>>>>
>>>>>>>If the PKI architecture resembled figure 1, then the
>>>>>>>certification
>>>>>>
>>>>path
>>>>
>>>>
>>>>
>>>>
>>>>>>>for
>>>>>>>the CRL signing key would just be a subset of the certification
>>>>>>>path
>>>>>>
>>>>for
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>EE certificate, so no addition path discovery would be needed.
>>>>>>>
>>>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>>>
>>>>necessary
>>>>
>>>>
>>>>
>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>obtain the new-signed-with-old self-issued certificate.  In
>>>>>>>building
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>certification path to the EE certificate, however, the relying
>>>>>>>party
>>>>>>
>>>>>will
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>obtain the certificates pointed to by the AIA extension in the EE
>>>>>>>certificate.  This AIA extension will point to a location 
>>>>>>>containing
>>>>>>
>>>>all
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificates issued to CA 2, which would include both the
>>>>>>
>>>>certificate
>>>>
>>>>
>>>>
>>>>
>>>>>>>issued
>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
>>>>>>
>>>>though
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>self-issued certificate would not be part of the certification 
>>>>>>>path
>>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>EE certificate, it would be downloaded by the relying party
>>>>>>>during
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>construction of that certification path.  (Yes, there are
>>>>>>>circular dependency issues in figure 2, but that is another 
>>>>>>>issue.)
>>>>>>>
>>>>>>>A similar situation would happen if the PKI architecture
>>>>>>>resembled
>>>>>>
>>>>>figure
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>>>
>>>>location
>>>>
>>>>
>>>>
>>>>
>>>>>>>containing certificates issued to CA 3.  When the relying party
>>>>>>
>>>>>downloaded
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>these certificates, it would obtain both of the certificates 
>>>>>>>issued
>>>>>>
>>>>by
>>>>
>>>>
>>>>
>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>Root to CA 3 and so again would have the certificate needed to
>>>>>>
>>>>validate
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>CRL signing key.
>>>>>>>
>>>>>>>In the case of an indirect CRL, things may not work as well.  If
>>>>>>
>>>>>indirect
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>CRLs were used, and the PKI architecture resembled figures 2 or 3
>>>>>>>(replacing "New Key" with a different CA), then the set of 
>>>>>>>certificates pointed
>>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>by
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the AIA extension in the EE certificate would not include the
>>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>of
>>>>>>>the CRL signer.  One could find this certificate by building in 
>>>>>>>the reverse direction and using the SIA extension, but that may 
>>>>>>>not be the most convenient solution.
>>>>>>>
>>>>>>>So, when indirect CRLs are being used, it seems that it would be
>>>>>>
>>>>very
>>>>
>>>>
>>>>
>>>>
>>>>>>>useful
>>>>>>>to have a pointer in the CRL to the CRL signing certificate.
>>>>>>>When
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>is not indirect, the need for this pointer does not seem to be as
>>>>>>
>>>>clear,
>>>>
>>>>
>>>>
>>>>
>>>>>>>but
>>>>>>>I can't see any harm in including it.
>>>>>>>
>>>>>>>Dave
>>>>>>>
>>>>>>>Stefan Santesson wrote:
>>>>>>>All,
>>>>>>>
>>>>>>>I'm interested in the opinion from members on this list about
>>>>>>
>>>>discovery
>>>>
>>>>
>>>>
>>>>
>>>>>of
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>CRL signer's certificate in non directory centric environments.
>>>>>>>
>>>>>>>The problem is the following.
>>>>>>>
>>>>>>>The relying party (RP) needs to check validity of a certificate 
>>>>>>>and
>>>>>>
>>>>>finds
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>a
>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL
>>>>>>>which
>>>>>>
>>>>in
>>>>
>>>>
>>>>
>>>>
>>>>>>>this
>>>>>>>particular case is either signed by another key of the CA 
>>>>>>>(re-keyed
>>>>>>
>>>>CA)
>>>>
>>>>
>>>>
>>>>
>>>>>or
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>another entity (indirect CRL).
>>>>>>>
>>>>>>>In this case the relying party needs to obtain the certificate of
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>signer which may NOT be part of the original chain. In a
>>>>>>>directory
>>>>>>
>>>>>centric
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>solution this is retrieved from the directory, but what if such
>>>>>>
>>>>>directory
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>is
>>>>>>>not available or accessible.
>>>>>>>
>>>>>>>The RP have thus no hint where to find the CRL issuers
>>>>>>>certificate
>>>>>>
>>>>>unless
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the RP already have possession of it by some other means.
>>>>>>>
>>>>>>>Is seems that CRLs would need an AIA extension with the option to
>>>>>>
>>>>point
>>>>
>>>>
>>>>
>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the location of the signers certificate in the same manner as is
>>>>>>
>>>>>possible
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>for certificates.
>>>>>>>
>>>>>>>Maybe AIA should be defined as both cert and CRL extension and
>>>>>>>not
>>>>>>
>>>>only
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate extension as today.
>>>>>>>
>>>>>>>Thoughts and comments?
>>>>>>>
>>>>>>>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 i9F9dx5r043683; Fri, 15 Oct 2004 02:39:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F9dxbO043682; Fri, 15 Oct 2004 02:39:59 -0700 (PDT)
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 i9F9dwaH043660 for <[e-mail]>; Fri, 15 Oct 2004 02:39:58 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (PPP-219.65.51.10.mum2.vsnl.net.in [219.65.51.10]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9F9dm3o008859 for <[e-mail]>; Fri, 15 Oct 2004 05:39:50 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Fri, 15 Oct 2004 05:37:38 -0400
Message-ID: <000001c4b29a$eb29f640$[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 i9F9dwaH043676
Sender: [e-mail]
Precedence: 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:

1.  This is a good mechanism to start building the path for CRL signer.  If
you have a better alternative for directory challenged environments, please
tell us.  Absent you showing that there is a mechanism for directory
challenged environments that is as simple and that works, we can not have a
fruitful dialog.

2.  Adding AIA to CRL does not impact interoperability, security or backward
compatibility adversely.

As to your argument, we could have used it few years back and not added AIA
to the certificates either.

-----Original Message-----
From: Denis Pinks [mailto:[e-mail]] 
Sent: Friday, October 15, 2004 2:45 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs


Santosh,

You are still trying to avoid to respond to my request. So my temporary 
conclusion is that you have NOT demonstrated that your proposal is really 
necessary and it is thus "yet-another-method".

> Denis:

> By directory challenged, I mean you do not use LDAP client or DAP or
> DSP to query for certificate.

RFC 3280. Page 46:

    The accessLocation
    field is defined as a GeneralName, which can take several forms.
    Where the information is available via http, ftp, or ldap,
    accessLocation MUST be a uniformResourceIdentifier.  Where the
    information is available via the Directory Access Protocol (DAP),
    accessLocation MUST be a directoryName.

It is thus perfectly allowed and valid to use DAP or ldap.

> The basic point is that if AIA or local store are the primary ways to
> obtain certificates,

No. Local store is of no use. AIA is one possibility, while the other one is

SIA.

> since the CRL issuer certificate is not in any payload, AIA in CRL
> helps obtain that certificate and start the path development process 
> for the CRL certification path.

No. You can use AIA or SIA in CA certificates, or AIA in leaf certificate.

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, October 14, 2004 11:13 AM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> 
>>Denis:
> 
> 
>>With the three assumptions/constraints I provided, how would you 
>>locate the CRL issuer certificate for the two examples using 3280 
>>extensions and without putting AIA in the CRL?
> 
> 
> As far as I understand, the three assumptions are:
> 
> 1.  You are directory challenged; and
>      [I do not understand what this means]
> 2.  You use AIA to develop the path; and
>      [It does not matter]
> 3.  You develop the path from the end entity to trust anchor
>      [Could also be the contrary].
> 
> If this is not correct, thus please correct.
> 
> Then my request is: "using ANY OF the current extensions that are
> defined in
> 
> RFC 3280", which includes SIA.
> 
> In your explanations  you said :
> "if you do no deal with SIA et. al"
> 
> This last assumption is neither part of the three assumptions and does
> not
> conform to my request.
> 
> Denis
> 
> 
>>That is my point.
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, October 14, 2004 6:22 AM
>>To: Santosh Chokhani
>>Cc: 'pkix'
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>
>>Santosh,
>>
>>You misread my request. I said:
>>
>>"For the time being, I would like that you provide an example where, 
>>when using the current extensions that are defined in RFC 3280, it 
>>will NOT be possible to locate a CRL Issuer certificate."
>>
>>Maybe I would have needed to be clearer and say :
>>
>>"For the time being, I would like that you provide an example where, 
>>when using ANY OF the current extensions that are defined in RFC 3280, 
>>it will NOT be possible to locate a CRL Issuer certificate."
>>
>>The examples you provide below do not fulfil this request.
>>
>>The assumption is that there exists a path to be tested for revocation
>>checking (and that it does not matter to know which way it has been 
>>constructed).
>>
>>I am not saying that using AIA in CRL might not be useful, but I am 
>>still lacking the demonstration that there would be no other way.
>>
>>Denis
>>
>>
>>
>>
>>>Denis:
>>>
>>>Two examples are very simple: one for direct CRL Issuer and one for
>>>Indirect CRL Issuer.
>>>
>>>Let us make the following assumptions that Stefan was making:
>>>
>>>1.  You are directory challenged; and
>>>2.  You use AIA to develop the path; and
>>>3.  You develop the path from the end entity to trust anchor.
>>>
>>
>>>From what I know of MS CAPI, these are reasonable
>>
>>>assumptions/constraints.
>>>
>>>Now the examples.
>>>
>>>Example 1: Direct CRL Issuer
>>>
>>>The certificate trust path is:
>>>Root --> CA1 --> CA 2, old key --> Denis
>>>
>>>The CRL trust path is:
>>>Root --> CA1 --> CA 2, new key --> CRL
>>>
>>>(Note: We do not do self-issued certificate since there is no simple,
>>>secure way to check their revocation status).
>>>
>>>Now, with AIA in CRL, finding the CA2, new key certificate is
>>>straightforward.  How would you find it if you do no deal with SIA 
>>>et. al.
>>>
>>>Example 2: Indirect CRL Issuer
>>>
>>>The certificate trust path is:
>>>Root --> CA1 --> CA 2 --> Denis
>>>(Note: Denis's certificate points to CRL DP of an indirect CRL issued
>>>by CAI.
>>>
>>>The CRL trust path is:
>>>Root --> CAI --> CRL
>>>
>>>Now, with AIA in CRL, finding the CAI certificate is straightforward.
>>>How would you find it if you do no deal with SIA et. al.
>>>
>>>In addition to the need cited above, please note that the extension
>>>semantics does not change, it does not hinder any interoperability, 
>>>and it does not break any backward compatibility.  So, what if I 
>>>wanted to use this extension in the CRL.  It does no harm to other 
>>>relying parties.
>>>
>>>-----Original Message-----
>>>From: [e-mail]
>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>>Sent: Wednesday, October 13, 2004 11:01 AM
>>>To: Stefan Santesson
>>>Cc: Santosh Chokhani; pkix
>>>Subject: Re: Signer certificate discovery for CRLs
>>>
>>>
>>>
>>>Stefan,
>>>
>>>
>>>
>>>
>>>>Denis,
>>>
>>>
>>>>I'm not sure what you mean.
>>>
>>>
>>>For the time being, I would like that you provide an example where,
>>>when using the current extensions that are defined in RFC 3280, it 
>>>will NOT be possible to locate a CRL Issuer certificate.
>>>
>>>If you are able to provide that example, then it would justify the
>>>need for an extension at least for one case. Then we can see what 
>>>that case is.
>>>
>>>I am awaiting that example.
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>
>>>>I conclude that I agree with Santosh.
>>>>
>>>>The debate is still open... Feel free to express your opinion.
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>Sent: den 13 oktober 2004 16:34
>>>>>To: Stefan Santesson
>>>>>Cc: Santosh Chokhani; pkix
>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>
>>>>>Stefan,
>>>>>
>>>>>You are making a conclusion without letting me the time to respond. 
>>>>>I will need more time to look at the pictures (and understand 
>>>>>them).
>>>>>
>>>>>For the time being, I am still reluctant to accept
>>>>
>>>>"yet-another-method".
>>>>
>>>>
>>>>
>>>>
>>>>>We already have too many.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Santosh,
>>>>>>
>>>>>>I conclude that we are in complete and total agreement. The 
>>>>>>question is how to go about this.
>>>>>
>>>>>>Could we do this amendment to RFC 3280 in its next revision? It
>>>>>>would hopefully just be a minor change.
>>>>>
>>>>>This is exactly what I feared.
>>>>>
>>>>>We usually end-up with a "minor change" in an extension without
>>>>>saying cleary how and when it shall/should be used.
>>>>>
>>>>>I still have in mind that:
>>>>>
>>>>>1) a certification path must first be constructed,
>>>>>2) then the revocation checking of that path must be done.
>>>>>
>>>>>This means that information about CRL issuers certificates
>>>>>locations
>>>>
>>>>may
>>>>
>>>>
>>>>
>>>>
>>>>>certainly be found in that chain. If not, I would like an example.
>>>>>
>>>>>Denis
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>It would not change the definition of AIA just add that it can be
>>>>>
>>>>used
>>>>
>>>>
>>>>
>>>>
>>>>>also as CRL extension and list eventual restrictions and guidance 
>>>>>for
>>>>
>>>>use
>>>>
>>>>
>>>>
>>>>
>>>>>with CRLs.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Stefan Santesson
>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: [e-mail]
>>>>>>
>>>>[mailto:[e-mail]]
>>>>
>>>>
>>>>
>>>>
>>>>>>>On Behalf Of Santosh Chokhani
>>>>>>>Sent: den 13 oktober 2004 04:33
>>>>>>>To: 'pkix'
>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>
>>>>>>>Stefan:
>>>>>>>
>>>>>>>In terms of certificate discovery, your proposal for AIA in CRL
>>>>>>>is
>>>>>>
>>>>more
>>>>
>>>>
>>>>
>>>>
>>>>>>>robust.  The whole idea of self-issued key rollover certificates
>>>>>>>and
>>>>>>
>>>>>then
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>using the new key to issue CRL is fraught with security problems.
>>>>>>>A secure solution would be one where the new key is certified by 
>>>>>>>the parent
>>>>>>
>>>>CA.
>>>>
>>>>
>>>>
>>>>
>>>>>In
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>that case to obtain the new certificate, you could use AIA in
>>>>>>>CRL.
>>>>>>>
>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
>>>>>>>certificate in question points to the indirect CRL.  You get that 
>>>>>>>CRL.  The AIA
>>>>>>
>>>>in
>>>>
>>>>
>>>>
>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>gets you started for the indirect CRL issuer certification path 
>>>>>>>and
>>>>>>
>>>>you
>>>>
>>>>
>>>>
>>>>
>>>>>>>are
>>>>>>>in business.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: [e-mail]
>>>>>>
>>>>[mailto:[e-mail]]
>>>>
>>>>
>>>>
>>>>
>>>>>>>On
>>>>>>>Behalf Of Stefan Santesson
>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>>>To: David A. Cooper
>>>>>>>Cc: pkix
>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>David,
>>>>>>>
>>>>>>>Thanks for the clarifications, they make sense.
>>>>>>>I did misread your pictures.
>>>>>>>
>>>>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>>>>
>>>>3280,
>>>>
>>>>
>>>>
>>>>
>>>>>>>either the CRL issuer certificate itself, or the location of the
>>>>>>>CRL issuer certificate, will be clearly identified/available for 
>>>>>>>the validating
>>>>>>
>>>>>party
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>in some cases, but not in others?
>>>>>>>
>>>>>>>Can we also conclude that there is no real discovery solution for
>>>>>>
>>>>>indirect
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>CRLs?
>>>>>>>
>>>>>>>Do you then agree then that it could be appropriate to allow AIA 
>>>>>>>as
>>>>>>
>>>>a
>>>>
>>>>
>>>>
>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>>>
>>>>>>>Stefan Santesson
>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>
>>>>>>>________________________________________
>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>Sent: den 12 oktober 2004 21:14
>>>>>>>To: Stefan Santesson
>>>>>>>Cc: pkix
>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>Stefan,
>>>>>>>
>>>>>>>I believe that you are misinterpreting the figures.  They really 
>>>>>>>do represent three different cases, not three different 
>>>>>>>certification
>>>>>>
>>>>paths
>>>>
>>>>
>>>>
>>>>
>>>>>>>that have been constructed through the same PKI architecture.
>>>>>>>
>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>>>
>>>>certificates.
>>>>
>>>>
>>>>
>>>>
>>>>>>>The
>>>>>>>Root CA has issued a certificate to CA 1's new key, but not its 
>>>>>>>old
>>>>>>
>>>>key
>>>>
>>>>
>>>>
>>>>
>>>>>>>(either the Root CA never issued a certificate to CA 1's old key 
>>>>>>>or
>>>>>>
>>>>that
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate has expired).
>>>>>>>
>>>>>>>In figure 2, CA 2 has also generated self-issued key rollover
>>>>>>>certificates. The Root CA has issued a certificate to CA 2's old 
>>>>>>>key, but not its
>>>>>>
>>>>new
>>>>
>>>>
>>>>
>>>>
>>>>>>>key.
>>>>>>>
>>>>>>>In figure 3, when CA 3 performed key rollover, it requested a new
>>>>>>>CA certificate from the Root CA.  CA 3 did not generated 
>>>>>>>self-issued
>>>>>>
>>>>key
>>>>
>>>>
>>>>
>>>>
>>>>>>>rollover certificates.
>>>>>>>
>>>>>>>Of course, another realistic scenario would be one in which a CA
>>>>>>
>>>>>generated
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>self-issued key rollover certificates upon key rollover and then
>>>>>>>had
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>Root CA issue a CA certificate to its new key.  In this case, as
>>>>>>>you suggest, any of the certification paths from figures 1, 2, or 
>>>>>>>3
>>>>>>
>>>>could be
>>>>
>>>>
>>>>
>>>>
>>>>>>>constructed.
>>>>>>>
>>>>>>>As for the contents of the AIA extension, here is what I have
>>>>>>
>>>>specified
>>>>
>>>>
>>>>
>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>>>>
>>>>>Policy":
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>The authorityInfoAccess extension uses URIs for two purposes.
>>>>>>>When
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>id-ad-caIssuers access method is used, the access location
>>>>>>>specifies
>>>>>>
>>>>>where
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certificates issued to the issuer of the certificate may be
>>>>>>>found.
>>>>>>
>>>>If
>>>>
>>>>
>>>>
>>>>
>>>>>LDAP
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>is used, the URI must include the DN of the entry containing the
>>>>>>
>>>>>relevant
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certificates and specify the directory attribute in which the
>>>>>>
>>>>>certificates
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>are located. If the directory in which the certificates are
>>>>>>>stored
>>>>>>
>>>>>expects
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the "binary" option to be specified, then the attribute type must
>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the URI 
>>>>>>>must
>>>>>>
>>>>point to
>>>>
>>>>
>>>>
>>>>
>>>>>a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>file that has an extension of ".p7c" that contains a certs-only 
>>>>>>>CMS message (see RFC 2633). The CMS message should include all
>>>>>>>certificates
>>>>>>
>>>>issued
>>>>
>>>>
>>>>
>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the issuer of this certificate, but must at least contain all
>>>>>>
>>>>>certificates
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>issued to the issuer of this certificate in which the subject
>>>>>>>public
>>>>>>
>>>>key
>>>>
>>>>
>>>>
>>>>
>>>>>>>may
>>>>>>>be used to verify the signature on this certificate. .... For a
>>>>>>>certificate issued by "Good CA", some examples of URIs that may 
>>>>>>>appear as the
>>>>>>
>>>>access
>>>>
>>>>
>>>>
>>>>
>>>>>>>location in an authorityInfoAccess extension when the
>>>>>>
>>>>id-ad-caIssuers
>>>>
>>>>
>>>>
>>>>
>>>>>>>access
>>>>>>>method is used are:
>>>>>>
>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cAC
>>>>>>e
>>>>>>r
>>>>>>t
>>>>>>i
>>>>>
>>>>fi
>>>>
>>>>
>>>>
>>>>
>>>>>ca
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>te
>>>>>>>,crossCertificatePair
>>>>>>
>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACerti
>>>>>>f
>>>>>>i
>>>>>>c
>>>>>>a
>>>>>
>>>>te
>>>>
>>>>
>>>>
>>>>
>>>>>;b
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>in
>>>>>>>ary,crossCertificatePair;binary
>>>>>>
>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIs
>>>>>>s
>>>>>>u
>>>>>>e
>>>>>>d
>>>>>
>>>>To
>>>>
>>>>
>>>>
>>>>
>>>>>Go
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>od
>>>>>>>CA.p7c
>>>>>>>For both LDAP and HTTP, the URI provides the exact location where
>>>>>>>information is to be located, so there is no requirement for the
>>>>>>
>>>>relying
>>>>
>>>>
>>>>
>>>>
>>>>>>>party to try to figure out where information is located.
>>>>>>>
>>>>>>>The HTTP URI points to a certs-only CMS message that includes all
>>>>>>>certificates issued to the CA identified in the issuer field of 
>>>>>>>the certificate.
>>>>>>>
>>>>>>>The LDAP URI points to the cACertificate and crossCertificatePair
>>>>>>>attributes of the directory entry of the CA identified in the 
>>>>>>>issuer field of
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate.  These two attributes together hold all of the
>>>>>>
>>>>certificates
>>>>
>>>>
>>>>
>>>>
>>>>>>>issued to the CA:  the cACertificate attribute holds the CA's
>>>>>>>self-
>>>>>>
>>>>>issued
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certificates and the crossCertificatePair attribute holds the
>>>>>>>cross-certificates issued to the CA by other CAs.
>>>>>>>
>>>>>>>Dave
>>>>>>>
>>>>>>>
>>>>>>>Stefan Santesson wrote:
>>>>>>>
>>>>>>>David,
>>>>>>>
>>>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>>>
>>>>>>>I have some comments and questions on this.
>>>>>>>
>>>>>>>First of all we can conclude that in some scenarios (figure 1)
>>>>>>>where
>>>>>>
>>>>a
>>>>
>>>>
>>>>
>>>>
>>>>>>>self
>>>>>>>issued certificate is inserted into the path, you are likely to
>>>>>>>find
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>CRL
>>>>>>>issuer cert in the path. (given that the new CA have a common key
>>>>>>
>>>>and
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate for cert signing and CRL signing).
>>>>>>>
>>>>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>>>>
>>>>>different
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>path building strategies. An application that has access locally 
>>>>>>>to
>>>>>>
>>>>all
>>>>
>>>>
>>>>
>>>>
>>>>>>>chaining options may however still choose path 2 for the certs
>>>>>>>and
>>>>>>
>>>>path
>>>>
>>>>
>>>>
>>>>
>>>>>1
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>for the CRL independent of each other (which I think figure 3 
>>>>>>>tries
>>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>>>describe)
>>>>>>>
>>>>>>>Another comment is the structure of AIA extensions. The use I'm
>>>>>>
>>>>familiar
>>>>
>>>>
>>>>
>>>>
>>>>>>>with doesn't use AIA to describe a directory entry where it is 
>>>>>>>left
>>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>validation application logic to be intelligent enough to find
>>>>>>
>>>>>appropriate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certificate data from the directory. The model I'm familiar with 
>>>>>>>is
>>>>>>
>>>>when
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>AIA URL explicitly identifies the exact location of the 
>>>>>>>appropriate
>>>>>>
>>>>CA
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate file, relieving the validation software from complex
>>>>>>>information queries. If just location of explicit certificate 
>>>>>>>files are
>>>>>>
>>>>identified
>>>>
>>>>
>>>>
>>>>
>>>>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>>>>
>>>>signer
>>>>
>>>>
>>>>
>>>>
>>>>>>>cert
>>>>>>>if this is different from the CA certificate. This is also the
>>>>>>
>>>>problem
>>>>
>>>>
>>>>
>>>>
>>>>>>>with
>>>>>>>Denis proposal.
>>>>>>>
>>>>>>>I think we share the basic conclusion that the ability to locate
>>>>>>>the
>>>>>>
>>>>CRL
>>>>
>>>>
>>>>
>>>>
>>>>>>>signer certificate directly through the CRL could be very useful.
>>>>>>>At
>>>>>>
>>>>>least
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>in the case of indirect CRL but it could also be proven very 
>>>>>>>useful
>>>>>>
>>>>in
>>>>
>>>>
>>>>
>>>>
>>>>>CA
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>re-keying scenarios.
>>>>>>>
>>>>>>>The easiest solution would probably be to allow AIA to be used in
>>>>>>
>>>>its
>>>>
>>>>
>>>>
>>>>
>>>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>>>
>>>>critical).
>>>>
>>>>
>>>>
>>>>
>>>>>It
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>would present a very clear and uncomplicated logic to certificate
>>>>>>>validating applications in many cases.
>>>>>>>
>>>>>>>Stefan Santesson
>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>
>>>>>>>________________________________________
>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>Sent: den 7 oktober 2004 18:35
>>>>>>>To: Stefan Santesson
>>>>>>>Cc: pkix
>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>Stefan,
>>>>>>>
>>>>>>>I think what you are proposing is a good idea.  In most cases, 
>>>>>>>path discovery algorithms assume that both the trust anchor (or 
>>>>>>>trust
>>>>>>
>>>>>anchors)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>and the end entity certificate are provided as input.  In this
>>>>>>>case,
>>>>>>
>>>>one
>>>>
>>>>
>>>>
>>>>
>>>>>>>may
>>>>>>>need to construct a certification path without a priori access to
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>end
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>entity certificate (the one with the subject public key
>>>>>>
>>>>corresponding to
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>>>
>>>>pointer) in
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>CRL would provide the relying party with a simple way to obtain 
>>>>>>>the
>>>>>>
>>>>end
>>>>
>>>>
>>>>
>>>>
>>>>>>>entity certificate for the CRL signing key's certification path. 
>>>>>>>On
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>other hand, I believe that a relying party should be able to
>>>>>>
>>>>construct
>>>>
>>>>
>>>>
>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certification path even without an AIA extension in the CRL, so
>>>>>>>long
>>>>>>
>>>>as
>>>>
>>>>
>>>>
>>>>
>>>>>it
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>is not an indirect CRL.  Attached is a drawing of the three basic
>>>>>>>scenarios that I expect a relying party may encounter:
>>>>>>>
>>>>>>>In each of these scenarios, the CA has performed key rollover and
>>>>>>>is
>>>>>>
>>>>>only
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>>>>
>>>>>however,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>if
>>>>>>>the CA simply choose to use different keys to sign certificates 
>>>>>>>and
>>>>>>
>>>>CRLs
>>>>
>>>>
>>>>
>>>>
>>>>>>>for
>>>>>>>some other reason.
>>>>>>>
>>>>>>>If the PKI architecture resembled figure 1, then the
>>>>>>>certification
>>>>>>
>>>>path
>>>>
>>>>
>>>>
>>>>
>>>>>>>for
>>>>>>>the CRL signing key would just be a subset of the certification
>>>>>>>path
>>>>>>
>>>>for
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>EE certificate, so no addition path discovery would be needed.
>>>>>>>
>>>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>>>
>>>>necessary
>>>>
>>>>
>>>>
>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>obtain the new-signed-with-old self-issued certificate.  In
>>>>>>>building
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>certification path to the EE certificate, however, the relying
>>>>>>>party
>>>>>>
>>>>>will
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>obtain the certificates pointed to by the AIA extension in the EE
>>>>>>>certificate.  This AIA extension will point to a location 
>>>>>>>containing
>>>>>>
>>>>all
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificates issued to CA 2, which would include both the
>>>>>>
>>>>certificate
>>>>
>>>>
>>>>
>>>>
>>>>>>>issued
>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
>>>>>>
>>>>though
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>self-issued certificate would not be part of the certification 
>>>>>>>path
>>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>EE certificate, it would be downloaded by the relying party
>>>>>>>during
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>construction of that certification path.  (Yes, there are
>>>>>>>circular dependency issues in figure 2, but that is another 
>>>>>>>issue.)
>>>>>>>
>>>>>>>A similar situation would happen if the PKI architecture
>>>>>>>resembled
>>>>>>
>>>>>figure
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>>>
>>>>location
>>>>
>>>>
>>>>
>>>>
>>>>>>>containing certificates issued to CA 3.  When the relying party
>>>>>>
>>>>>downloaded
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>these certificates, it would obtain both of the certificates 
>>>>>>>issued
>>>>>>
>>>>by
>>>>
>>>>
>>>>
>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>Root to CA 3 and so again would have the certificate needed to
>>>>>>
>>>>validate
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>CRL signing key.
>>>>>>>
>>>>>>>In the case of an indirect CRL, things may not work as well.  If
>>>>>>
>>>>>indirect
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>CRLs were used, and the PKI architecture resembled figures 2 or 3
>>>>>>>(replacing "New Key" with a different CA), then the set of 
>>>>>>>certificates pointed
>>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>by
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the AIA extension in the EE certificate would not include the
>>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>of
>>>>>>>the CRL signer.  One could find this certificate by building in 
>>>>>>>the reverse direction and using the SIA extension, but that may 
>>>>>>>not be the most convenient solution.
>>>>>>>
>>>>>>>So, when indirect CRLs are being used, it seems that it would be
>>>>>>
>>>>very
>>>>
>>>>
>>>>
>>>>
>>>>>>>useful
>>>>>>>to have a pointer in the CRL to the CRL signing certificate.
>>>>>>>When
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>is not indirect, the need for this pointer does not seem to be as
>>>>>>
>>>>clear,
>>>>
>>>>
>>>>
>>>>
>>>>>>>but
>>>>>>>I can't see any harm in including it.
>>>>>>>
>>>>>>>Dave
>>>>>>>
>>>>>>>Stefan Santesson wrote:
>>>>>>>All,
>>>>>>>
>>>>>>>I'm interested in the opinion from members on this list about
>>>>>>
>>>>discovery
>>>>
>>>>
>>>>
>>>>
>>>>>of
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>CRL signer's certificate in non directory centric environments.
>>>>>>>
>>>>>>>The problem is the following.
>>>>>>>
>>>>>>>The relying party (RP) needs to check validity of a certificate 
>>>>>>>and
>>>>>>
>>>>>finds
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>a
>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL
>>>>>>>which
>>>>>>
>>>>in
>>>>
>>>>
>>>>
>>>>
>>>>>>>this
>>>>>>>particular case is either signed by another key of the CA 
>>>>>>>(re-keyed
>>>>>>
>>>>CA)
>>>>
>>>>
>>>>
>>>>
>>>>>or
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>another entity (indirect CRL).
>>>>>>>
>>>>>>>In this case the relying party needs to obtain the certificate of
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>signer which may NOT be part of the original chain. In a
>>>>>>>directory
>>>>>>
>>>>>centric
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>solution this is retrieved from the directory, but what if such
>>>>>>
>>>>>directory
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>is
>>>>>>>not available or accessible.
>>>>>>>
>>>>>>>The RP have thus no hint where to find the CRL issuers
>>>>>>>certificate
>>>>>>
>>>>>unless
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the RP already have possession of it by some other means.
>>>>>>>
>>>>>>>Is seems that CRLs would need an AIA extension with the option to
>>>>>>
>>>>point
>>>>
>>>>
>>>>
>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the location of the signers certificate in the same manner as is
>>>>>>
>>>>>possible
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>for certificates.
>>>>>>>
>>>>>>>Maybe AIA should be defined as both cert and CRL extension and
>>>>>>>not
>>>>>>
>>>>only
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate extension as today.
>>>>>>>
>>>>>>>Thoughts and comments?
>>>>>>>
>>>>>>>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 i9F6lYfv073309; Thu, 14 Oct 2004 23:47:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9F6lYlt073307; Thu, 14 Oct 2004 23:47:34 -0700 (PDT)
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 i9F6lUtU073236 for <[e-mail]>; Thu, 14 Oct 2004 23:47:32 -0700 (PDT) (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 IAA58434; Fri, 15 Oct 2004 08:58:47 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101508470634:1152 ; Fri, 15 Oct 2004 08:47:06 +0200 
Message-ID: <[e-mail]>
Date: Fri, 15 Oct 2004 08:45:27 +0200
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: <009701c4b22d$a1f5f5e0$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/10/2004 08:47:06, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/10/2004 08:47:09, Serialize complete at 15/10/2004 08:47: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>

Santosh,

You are still trying to avoid to respond to my request. So my temporary 
conclusion is that you have NOT demonstrated that your proposal is really 
necessary and it is thus "yet-another-method".

> Denis:

> By directory challenged, I mean you do not use LDAP client or DAP or DSP to
> query for certificate.

RFC 3280. Page 46:

    The accessLocation
    field is defined as a GeneralName, which can take several forms.
    Where the information is available via http, ftp, or ldap,
    accessLocation MUST be a uniformResourceIdentifier.  Where the
    information is available via the Directory Access Protocol (DAP),
    accessLocation MUST be a directoryName.

It is thus perfectly allowed and valid to use DAP or ldap.

> The basic point is that if AIA or local store are the primary ways to obtain
> certificates, 

No. Local store is of no use. AIA is one possibility, while the other one is 
SIA.

> since the CRL issuer certificate is not in any payload, AIA in
> CRL helps obtain that certificate and start the path development process for
> the CRL certification path.

No. You can use AIA or SIA in CA certificates, or AIA in leaf certificate.

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, October 14, 2004 11:13 AM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> 
>>Denis:
> 
> 
>>With the three assumptions/constraints I provided, how would you 
>>locate the CRL issuer certificate for the two examples using 3280 
>>extensions and without putting AIA in the CRL?
> 
> 
> As far as I understand, the three assumptions are:
> 
> 1.  You are directory challenged; and
>      [I do not understand what this means]
> 2.  You use AIA to develop the path; and
>      [It does not matter]
> 3.  You develop the path from the end entity to trust anchor
>      [Could also be the contrary].
> 
> If this is not correct, thus please correct.
> 
> Then my request is: "using ANY OF the current extensions that are defined in
> 
> RFC 3280", which includes SIA.
> 
> In your explanations  you said :
> "if you do no deal with SIA et. al"
> 
> This last assumption is neither part of the three assumptions and does not 
> conform to my request.
> 
> Denis
> 
> 
>>That is my point.
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, October 14, 2004 6:22 AM
>>To: Santosh Chokhani
>>Cc: 'pkix'
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>
>>Santosh,
>>
>>You misread my request. I said:
>>
>>"For the time being, I would like that you provide an example where, 
>>when using the current extensions that are defined in RFC 3280, it 
>>will NOT be possible to locate a CRL Issuer certificate."
>>
>>Maybe I would have needed to be clearer and say :
>>
>>"For the time being, I would like that you provide an example where, 
>>when using ANY OF the current extensions that are defined in RFC 3280, 
>>it will NOT be possible to locate a CRL Issuer certificate."
>>
>>The examples you provide below do not fulfil this request.
>>
>>The assumption is that there exists a path to be tested for revocation
>>checking (and that it does not matter to know which way it has been 
>>constructed).
>>
>>I am not saying that using AIA in CRL might not be useful, but I am 
>>still
>>lacking the demonstration that there would be no other way.
>>
>>Denis
>>
>>
>>
>>
>>>Denis:
>>>
>>>Two examples are very simple: one for direct CRL Issuer and one for
>>>Indirect CRL Issuer.
>>>
>>>Let us make the following assumptions that Stefan was making:
>>>
>>>1.  You are directory challenged; and
>>>2.  You use AIA to develop the path; and
>>>3.  You develop the path from the end entity to trust anchor.
>>>
>>
>>>From what I know of MS CAPI, these are reasonable
>>
>>>assumptions/constraints.
>>>
>>>Now the examples.
>>>
>>>Example 1: Direct CRL Issuer
>>>
>>>The certificate trust path is:
>>>Root --> CA1 --> CA 2, old key --> Denis
>>>
>>>The CRL trust path is:
>>>Root --> CA1 --> CA 2, new key --> CRL
>>>
>>>(Note: We do not do self-issued certificate since there is no simple,
>>>secure way to check their revocation status).
>>>
>>>Now, with AIA in CRL, finding the CA2, new key certificate is
>>>straightforward.  How would you find it if you do no deal with SIA et. 
>>>al.
>>>
>>>Example 2: Indirect CRL Issuer
>>>
>>>The certificate trust path is:
>>>Root --> CA1 --> CA 2 --> Denis
>>>(Note: Denis's certificate points to CRL DP of an indirect CRL issued
>>>by CAI.
>>>
>>>The CRL trust path is:
>>>Root --> CAI --> CRL
>>>
>>>Now, with AIA in CRL, finding the CAI certificate is straightforward.
>>>How would you find it if you do no deal with SIA et. al.
>>>
>>>In addition to the need cited above, please note that the extension
>>>semantics does not change, it does not hinder any interoperability, 
>>>and it does not break any backward compatibility.  So, what if I 
>>>wanted to use this extension in the CRL.  It does no harm to other 
>>>relying parties.
>>>
>>>-----Original Message-----
>>>From: [e-mail]
>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>>Sent: Wednesday, October 13, 2004 11:01 AM
>>>To: Stefan Santesson
>>>Cc: Santosh Chokhani; pkix
>>>Subject: Re: Signer certificate discovery for CRLs
>>>
>>>
>>>
>>>Stefan,
>>>
>>>
>>>
>>>
>>>>Denis,
>>>
>>>
>>>>I'm not sure what you mean.
>>>
>>>
>>>For the time being, I would like that you provide an example where,
>>>when
>>>using the current extensions that are defined in RFC 3280, it will NOT be 
>>>possible to locate a CRL Issuer certificate.
>>>
>>>If you are able to provide that example, then it would justify the
>>>need for
>>>an extension at least for one case. Then we can see what that case is.
>>>
>>>I am awaiting that example.
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>
>>>>I conclude that I agree with Santosh.
>>>>
>>>>The debate is still open... Feel free to express your opinion.
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>Sent: den 13 oktober 2004 16:34
>>>>>To: Stefan Santesson
>>>>>Cc: Santosh Chokhani; pkix
>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>
>>>>>Stefan,
>>>>>
>>>>>You are making a conclusion without letting me the time to respond. 
>>>>>I
>>>>>will need more time to look at the pictures (and understand them).
>>>>>
>>>>>For the time being, I am still reluctant to accept
>>>>
>>>>"yet-another-method".
>>>>
>>>>
>>>>
>>>>
>>>>>We already have too many.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Santosh,
>>>>>>
>>>>>>I conclude that we are in complete and total agreement. The 
>>>>>>question is how to go about this.
>>>>>
>>>>>>Could we do this amendment to RFC 3280 in its next revision? It
>>>>>>would hopefully just be a minor change.
>>>>>
>>>>>This is exactly what I feared.
>>>>>
>>>>>We usually end-up with a "minor change" in an extension without
>>>>>saying cleary how and when it shall/should be used.
>>>>>
>>>>>I still have in mind that:
>>>>>
>>>>>1) a certification path must first be constructed,
>>>>>2) then the revocation checking of that path must be done.
>>>>>
>>>>>This means that information about CRL issuers certificates locations
>>>>
>>>>may
>>>>
>>>>
>>>>
>>>>
>>>>>certainly be found in that chain. If not, I would like an example.
>>>>>
>>>>>Denis
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>It would not change the definition of AIA just add that it can be
>>>>>
>>>>used
>>>>
>>>>
>>>>
>>>>
>>>>>also as CRL extension and list eventual restrictions and guidance 
>>>>>for
>>>>
>>>>use
>>>>
>>>>
>>>>
>>>>
>>>>>with CRLs.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Stefan Santesson
>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: [e-mail]
>>>>>>
>>>>[mailto:[e-mail]]
>>>>
>>>>
>>>>
>>>>
>>>>>>>On Behalf Of Santosh Chokhani
>>>>>>>Sent: den 13 oktober 2004 04:33
>>>>>>>To: 'pkix'
>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>
>>>>>>>Stefan:
>>>>>>>
>>>>>>>In terms of certificate discovery, your proposal for AIA in CRL is
>>>>>>
>>>>more
>>>>
>>>>
>>>>
>>>>
>>>>>>>robust.  The whole idea of self-issued key rollover certificates
>>>>>>>and
>>>>>>
>>>>>then
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>using the new key to issue CRL is fraught with security problems.
>>>>>>>A secure solution would be one where the new key is certified by 
>>>>>>>the parent
>>>>>>
>>>>CA.
>>>>
>>>>
>>>>
>>>>
>>>>>In
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>that case to obtain the new certificate, you could use AIA in CRL.
>>>>>>>
>>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
>>>>>>>certificate in question points to the indirect CRL.  You get that 
>>>>>>>CRL.  The AIA
>>>>>>
>>>>in
>>>>
>>>>
>>>>
>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>gets you started for the indirect CRL issuer certification path 
>>>>>>>and
>>>>>>
>>>>you
>>>>
>>>>
>>>>
>>>>
>>>>>>>are
>>>>>>>in business.
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: [e-mail]
>>>>>>
>>>>[mailto:[e-mail]]
>>>>
>>>>
>>>>
>>>>
>>>>>>>On
>>>>>>>Behalf Of Stefan Santesson
>>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>>>To: David A. Cooper
>>>>>>>Cc: pkix
>>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>David,
>>>>>>>
>>>>>>>Thanks for the clarifications, they make sense.
>>>>>>>I did misread your pictures.
>>>>>>>
>>>>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>>>>
>>>>3280,
>>>>
>>>>
>>>>
>>>>
>>>>>>>either the CRL issuer certificate itself, or the location of the
>>>>>>>CRL issuer certificate, will be clearly identified/available for 
>>>>>>>the validating
>>>>>>
>>>>>party
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>in some cases, but not in others?
>>>>>>>
>>>>>>>Can we also conclude that there is no real discovery solution for
>>>>>>
>>>>>indirect
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>CRLs?
>>>>>>>
>>>>>>>Do you then agree then that it could be appropriate to allow AIA 
>>>>>>>as
>>>>>>
>>>>a
>>>>
>>>>
>>>>
>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>>>
>>>>>>>Stefan Santesson
>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>
>>>>>>>________________________________________
>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>Sent: den 12 oktober 2004 21:14
>>>>>>>To: Stefan Santesson
>>>>>>>Cc: pkix
>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>Stefan,
>>>>>>>
>>>>>>>I believe that you are misinterpreting the figures.  They really 
>>>>>>>do
>>>>>>>represent three different cases, not three different certification
>>>>>>
>>>>paths
>>>>
>>>>
>>>>
>>>>
>>>>>>>that have been constructed through the same PKI architecture.
>>>>>>>
>>>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>>>
>>>>certificates.
>>>>
>>>>
>>>>
>>>>
>>>>>>>The
>>>>>>>Root CA has issued a certificate to CA 1's new key, but not its 
>>>>>>>old
>>>>>>
>>>>key
>>>>
>>>>
>>>>
>>>>
>>>>>>>(either the Root CA never issued a certificate to CA 1's old key 
>>>>>>>or
>>>>>>
>>>>that
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate has expired).
>>>>>>>
>>>>>>>In figure 2, CA 2 has also generated self-issued key rollover
>>>>>>>certificates. The Root CA has issued a certificate to CA 2's old 
>>>>>>>key, but not its
>>>>>>
>>>>new
>>>>
>>>>
>>>>
>>>>
>>>>>>>key.
>>>>>>>
>>>>>>>In figure 3, when CA 3 performed key rollover, it requested a new
>>>>>>>CA certificate from the Root CA.  CA 3 did not generated 
>>>>>>>self-issued
>>>>>>
>>>>key
>>>>
>>>>
>>>>
>>>>
>>>>>>>rollover certificates.
>>>>>>>
>>>>>>>Of course, another realistic scenario would be one in which a CA
>>>>>>
>>>>>generated
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>self-issued key rollover certificates upon key rollover and then
>>>>>>>had
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>Root CA issue a CA certificate to its new key.  In this case, as
>>>>>>>you suggest, any of the certification paths from figures 1, 2, or 3
>>>>>>
>>>>could be
>>>>
>>>>
>>>>
>>>>
>>>>>>>constructed.
>>>>>>>
>>>>>>>As for the contents of the AIA extension, here is what I have
>>>>>>
>>>>specified
>>>>
>>>>
>>>>
>>>>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>>>>
>>>>>Policy":
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>The authorityInfoAccess extension uses URIs for two purposes. When
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>id-ad-caIssuers access method is used, the access location
>>>>>>>specifies
>>>>>>
>>>>>where
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certificates issued to the issuer of the certificate may be found.
>>>>>>
>>>>If
>>>>
>>>>
>>>>
>>>>
>>>>>LDAP
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>is used, the URI must include the DN of the entry containing the
>>>>>>
>>>>>relevant
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certificates and specify the directory attribute in which the
>>>>>>
>>>>>certificates
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>are located. If the directory in which the certificates are stored
>>>>>>
>>>>>expects
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the "binary" option to be specified, then the attribute type must
>>>>>>>be followed by ";binary" in the URI. If HTTP is used, the URI must
>>>>>>
>>>>point to
>>>>
>>>>
>>>>
>>>>
>>>>>a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>file that has an extension of ".p7c" that contains a certs-only 
>>>>>>>CMS
>>>>>>>message (see RFC 2633). The CMS message should include all 
>>>>>>>certificates
>>>>>>
>>>>issued
>>>>
>>>>
>>>>
>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the issuer of this certificate, but must at least contain all
>>>>>>
>>>>>certificates
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>issued to the issuer of this certificate in which the subject
>>>>>>>public
>>>>>>
>>>>key
>>>>
>>>>
>>>>
>>>>
>>>>>>>may
>>>>>>>be used to verify the signature on this certificate. .... For a
>>>>>>>certificate issued by "Good CA", some examples of URIs that may 
>>>>>>>appear as the
>>>>>>
>>>>access
>>>>
>>>>
>>>>
>>>>
>>>>>>>location in an authorityInfoAccess extension when the
>>>>>>
>>>>id-ad-caIssuers
>>>>
>>>>
>>>>
>>>>
>>>>>>>access
>>>>>>>method is used are:
>>>>>>
>>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACe
>>>>>>r
>>>>>>t
>>>>>>i
>>>>>
>>>>fi
>>>>
>>>>
>>>>
>>>>
>>>>>ca
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>te
>>>>>>>,crossCertificatePair
>>>>>>
>>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertif
>>>>>>i
>>>>>>c
>>>>>>a
>>>>>
>>>>te
>>>>
>>>>
>>>>
>>>>
>>>>>;b
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>in
>>>>>>>ary,crossCertificatePair;binary
>>>>>>
>>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIss
>>>>>>u
>>>>>>e
>>>>>>d
>>>>>
>>>>To
>>>>
>>>>
>>>>
>>>>
>>>>>Go
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>od
>>>>>>>CA.p7c
>>>>>>>For both LDAP and HTTP, the URI provides the exact location where
>>>>>>>information is to be located, so there is no requirement for the
>>>>>>
>>>>relying
>>>>
>>>>
>>>>
>>>>
>>>>>>>party to try to figure out where information is located.
>>>>>>>
>>>>>>>The HTTP URI points to a certs-only CMS message that includes all
>>>>>>>certificates issued to the CA identified in the issuer field of the 
>>>>>>>certificate.
>>>>>>>
>>>>>>>The LDAP URI points to the cACertificate and crossCertificatePair
>>>>>>>attributes of the directory entry of the CA identified in the 
>>>>>>>issuer field of
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate.  These two attributes together hold all of the
>>>>>>
>>>>certificates
>>>>
>>>>
>>>>
>>>>
>>>>>>>issued to the CA:  the cACertificate attribute holds the CA's 
>>>>>>>self-
>>>>>>
>>>>>issued
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certificates and the crossCertificatePair attribute holds the
>>>>>>>cross-certificates issued to the CA by other CAs.
>>>>>>>
>>>>>>>Dave
>>>>>>>
>>>>>>>
>>>>>>>Stefan Santesson wrote:
>>>>>>>
>>>>>>>David,
>>>>>>>
>>>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>>>
>>>>>>>I have some comments and questions on this.
>>>>>>>
>>>>>>>First of all we can conclude that in some scenarios (figure 1)
>>>>>>>where
>>>>>>
>>>>a
>>>>
>>>>
>>>>
>>>>
>>>>>>>self
>>>>>>>issued certificate is inserted into the path, you are likely to
>>>>>>>find
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>CRL
>>>>>>>issuer cert in the path. (given that the new CA have a common key
>>>>>>
>>>>and
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate for cert signing and CRL signing).
>>>>>>>
>>>>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>>>>
>>>>>different
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>path building strategies. An application that has access locally 
>>>>>>>to
>>>>>>
>>>>all
>>>>
>>>>
>>>>
>>>>
>>>>>>>chaining options may however still choose path 2 for the certs and
>>>>>>
>>>>path
>>>>
>>>>
>>>>
>>>>
>>>>>1
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>for the CRL independent of each other (which I think figure 3 
>>>>>>>tries
>>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>>>describe)
>>>>>>>
>>>>>>>Another comment is the structure of AIA extensions. The use I'm
>>>>>>
>>>>familiar
>>>>
>>>>
>>>>
>>>>
>>>>>>>with doesn't use AIA to describe a directory entry where it is 
>>>>>>>left
>>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>validation application logic to be intelligent enough to find
>>>>>>
>>>>>appropriate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certificate data from the directory. The model I'm familiar with 
>>>>>>>is
>>>>>>
>>>>when
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>AIA URL explicitly identifies the exact location of the 
>>>>>>>appropriate
>>>>>>
>>>>CA
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate file, relieving the validation software from complex
>>>>>>>information queries. If just location of explicit certificate files 
>>>>>>>are
>>>>>>
>>>>identified
>>>>
>>>>
>>>>
>>>>
>>>>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>>>>
>>>>signer
>>>>
>>>>
>>>>
>>>>
>>>>>>>cert
>>>>>>>if this is different from the CA certificate. This is also the
>>>>>>
>>>>problem
>>>>
>>>>
>>>>
>>>>
>>>>>>>with
>>>>>>>Denis proposal.
>>>>>>>
>>>>>>>I think we share the basic conclusion that the ability to locate
>>>>>>>the
>>>>>>
>>>>CRL
>>>>
>>>>
>>>>
>>>>
>>>>>>>signer certificate directly through the CRL could be very useful.
>>>>>>>At
>>>>>>
>>>>>least
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>in the case of indirect CRL but it could also be proven very 
>>>>>>>useful
>>>>>>
>>>>in
>>>>
>>>>
>>>>
>>>>
>>>>>CA
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>re-keying scenarios.
>>>>>>>
>>>>>>>The easiest solution would probably be to allow AIA to be used in
>>>>>>
>>>>its
>>>>
>>>>
>>>>
>>>>
>>>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>>>
>>>>critical).
>>>>
>>>>
>>>>
>>>>
>>>>>It
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>would present a very clear and uncomplicated logic to certificate
>>>>>>>validating applications in many cases.
>>>>>>>
>>>>>>>Stefan Santesson
>>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>>
>>>>>>>________________________________________
>>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>>Sent: den 7 oktober 2004 18:35
>>>>>>>To: Stefan Santesson
>>>>>>>Cc: pkix
>>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>>
>>>>>>>Stefan,
>>>>>>>
>>>>>>>I think what you are proposing is a good idea.  In most cases, 
>>>>>>>path
>>>>>>>discovery algorithms assume that both the trust anchor (or trust
>>>>>>
>>>>>anchors)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>and the end entity certificate are provided as input.  In this
>>>>>>>case,
>>>>>>
>>>>one
>>>>
>>>>
>>>>
>>>>
>>>>>>>may
>>>>>>>need to construct a certification path without a priori access to
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>end
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>entity certificate (the one with the subject public key
>>>>>>
>>>>corresponding to
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>>>
>>>>pointer) in
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>CRL would provide the relying party with a simple way to obtain 
>>>>>>>the
>>>>>>
>>>>end
>>>>
>>>>
>>>>
>>>>
>>>>>>>entity certificate for the CRL signing key's certification path. 
>>>>>>>On
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>other hand, I believe that a relying party should be able to
>>>>>>
>>>>construct
>>>>
>>>>
>>>>
>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>certification path even without an AIA extension in the CRL, so
>>>>>>>long
>>>>>>
>>>>as
>>>>
>>>>
>>>>
>>>>
>>>>>it
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>is not an indirect CRL.  Attached is a drawing of the three basic
>>>>>>>scenarios that I expect a relying party may encounter:
>>>>>>>
>>>>>>>In each of these scenarios, the CA has performed key rollover and
>>>>>>>is
>>>>>>
>>>>>only
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>>>>
>>>>>however,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>if
>>>>>>>the CA simply choose to use different keys to sign certificates 
>>>>>>>and
>>>>>>
>>>>CRLs
>>>>
>>>>
>>>>
>>>>
>>>>>>>for
>>>>>>>some other reason.
>>>>>>>
>>>>>>>If the PKI architecture resembled figure 1, then the certification
>>>>>>
>>>>path
>>>>
>>>>
>>>>
>>>>
>>>>>>>for
>>>>>>>the CRL signing key would just be a subset of the certification
>>>>>>>path
>>>>>>
>>>>for
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>EE certificate, so no addition path discovery would be needed.
>>>>>>>
>>>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>>>
>>>>necessary
>>>>
>>>>
>>>>
>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>obtain the new-signed-with-old self-issued certificate.  In
>>>>>>>building
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>certification path to the EE certificate, however, the relying
>>>>>>>party
>>>>>>
>>>>>will
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>obtain the certificates pointed to by the AIA extension in the EE
>>>>>>>certificate.  This AIA extension will point to a location 
>>>>>>>containing
>>>>>>
>>>>all
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificates issued to CA 2, which would include both the
>>>>>>
>>>>certificate
>>>>
>>>>
>>>>
>>>>
>>>>>>>issued
>>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
>>>>>>
>>>>though
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>self-issued certificate would not be part of the certification 
>>>>>>>path
>>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>EE certificate, it would be downloaded by the relying party during
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>>construction of that certification path.  (Yes, there are circular
>>>>>>>dependency issues in figure 2, but that is another issue.)
>>>>>>>
>>>>>>>A similar situation would happen if the PKI architecture resembled
>>>>>>
>>>>>figure
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>>>
>>>>location
>>>>
>>>>
>>>>
>>>>
>>>>>>>containing certificates issued to CA 3.  When the relying party
>>>>>>
>>>>>downloaded
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>these certificates, it would obtain both of the certificates 
>>>>>>>issued
>>>>>>
>>>>by
>>>>
>>>>
>>>>
>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>Root to CA 3 and so again would have the certificate needed to
>>>>>>
>>>>validate
>>>>
>>>>
>>>>
>>>>
>>>>>>>the
>>>>>>>CRL signing key.
>>>>>>>
>>>>>>>In the case of an indirect CRL, things may not work as well.  If
>>>>>>
>>>>>indirect
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>CRLs were used, and the PKI architecture resembled figures 2 or 3
>>>>>>>(replacing "New Key" with a different CA), then the set of 
>>>>>>>certificates pointed
>>>>>>
>>>>to
>>>>
>>>>
>>>>
>>>>
>>>>>by
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the AIA extension in the EE certificate would not include the
>>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>of
>>>>>>>the CRL signer.  One could find this certificate by building in 
>>>>>>>the
>>>>>>>reverse direction and using the SIA extension, but that may not be 
>>>>>>>the most convenient solution.
>>>>>>>
>>>>>>>So, when indirect CRLs are being used, it seems that it would be
>>>>>>
>>>>very
>>>>
>>>>
>>>>
>>>>
>>>>>>>useful
>>>>>>>to have a pointer in the CRL to the CRL signing certificate.  When
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>is not indirect, the need for this pointer does not seem to be as
>>>>>>
>>>>clear,
>>>>
>>>>
>>>>
>>>>
>>>>>>>but
>>>>>>>I can't see any harm in including it.
>>>>>>>
>>>>>>>Dave
>>>>>>>
>>>>>>>Stefan Santesson wrote:
>>>>>>>All,
>>>>>>>
>>>>>>>I'm interested in the opinion from members on this list about
>>>>>>
>>>>discovery
>>>>
>>>>
>>>>
>>>>
>>>>>of
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>CRL signer's certificate in non directory centric environments.
>>>>>>>
>>>>>>>The problem is the following.
>>>>>>>
>>>>>>>The relying party (RP) needs to check validity of a certificate 
>>>>>>>and
>>>>>>
>>>>>finds
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>a
>>>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL
>>>>>>>which
>>>>>>
>>>>in
>>>>
>>>>
>>>>
>>>>
>>>>>>>this
>>>>>>>particular case is either signed by another key of the CA 
>>>>>>>(re-keyed
>>>>>>
>>>>CA)
>>>>
>>>>
>>>>
>>>>
>>>>>or
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>another entity (indirect CRL).
>>>>>>>
>>>>>>>In this case the relying party needs to obtain the certificate of
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>signer which may NOT be part of the original chain. In a directory
>>>>>>
>>>>>centric
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>solution this is retrieved from the directory, but what if such
>>>>>>
>>>>>directory
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>is
>>>>>>>not available or accessible.
>>>>>>>
>>>>>>>The RP have thus no hint where to find the CRL issuers certificate
>>>>>>
>>>>>unless
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the RP already have possession of it by some other means.
>>>>>>>
>>>>>>>Is seems that CRLs would need an AIA extension with the option to
>>>>>>
>>>>point
>>>>
>>>>
>>>>
>>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>the location of the signers certificate in the same manner as is
>>>>>>
>>>>>possible
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>for certificates.
>>>>>>>
>>>>>>>Maybe AIA should be defined as both cert and CRL extension and not
>>>>>>
>>>>only
>>>>
>>>>
>>>>
>>>>
>>>>>>>certificate extension as today.
>>>>>>>
>>>>>>>Thoughts and comments?
>>>>>>>
>>>>>>>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 i9EKbYVM051401; Thu, 14 Oct 2004 13:37:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EKbYvJ051400; Thu, 14 Oct 2004 13:37:34 -0700 (PDT)
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 i9EKbXpq051394 for <[e-mail]>; Thu, 14 Oct 2004 13:37:33 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (PPP-219.65.51.83.mum2.vsnl.net.in [219.65.51.83]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9EKbI3p025074 for <[e-mail]>; Thu, 14 Oct 2004 16:37:32 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Thu, 14 Oct 2004 16:37:07 -0400
Message-ID: <009701c4b22d$a1f5f5e0$[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 i9EKbYpq051395
Sender: [e-mail]
Precedence: 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:

By directory challenged, I mean you do not use LDAP client or DAP or DSP to
query for certificate.

The basic point is that if AIA or local store are the primary ways to obtain
certificates, since the CRL issuer certificate is not in any payload, AIA in
CRL helps obtain that certificate and start the path development process for
the CRL certification path.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, October 14, 2004 11:13 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs


Santosh,

> Denis:

> With the three assumptions/constraints I provided, how would you 
> locate the CRL issuer certificate for the two examples using 3280 
> extensions and without putting AIA in the CRL?

As far as I understand, the three assumptions are:

1.  You are directory challenged; and
     [I do not understand what this means]
2.  You use AIA to develop the path; and
     [It does not matter]
3.  You develop the path from the end entity to trust anchor
     [Could also be the contrary].

If this is not correct, thus please correct.

Then my request is: "using ANY OF the current extensions that are defined in

RFC 3280", which includes SIA.

In your explanations  you said :
"if you do no deal with SIA et. al"

This last assumption is neither part of the three assumptions and does not 
conform to my request.

Denis

> That is my point.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, October 14, 2004 6:22 AM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> You misread my request. I said:
> 
> "For the time being, I would like that you provide an example where, 
> when using the current extensions that are defined in RFC 3280, it 
> will NOT be possible to locate a CRL Issuer certificate."
> 
> Maybe I would have needed to be clearer and say :
> 
> "For the time being, I would like that you provide an example where, 
> when using ANY OF the current extensions that are defined in RFC 3280, 
> it will NOT be possible to locate a CRL Issuer certificate."
> 
> The examples you provide below do not fulfil this request.
> 
> The assumption is that there exists a path to be tested for revocation
> checking (and that it does not matter to know which way it has been 
> constructed).
> 
> I am not saying that using AIA in CRL might not be useful, but I am 
> still
> lacking the demonstration that there would be no other way.
> 
> Denis
> 
> 
> 
>>Denis:
>>
>>Two examples are very simple: one for direct CRL Issuer and one for
>>Indirect CRL Issuer.
>>
>>Let us make the following assumptions that Stefan was making:
>>
>>1.  You are directory challenged; and
>>2.  You use AIA to develop the path; and
>>3.  You develop the path from the end entity to trust anchor.
>>
>>From what I know of MS CAPI, these are reasonable
>>assumptions/constraints.
>>
>>Now the examples.
>>
>>Example 1: Direct CRL Issuer
>>
>>The certificate trust path is:
>>Root --> CA1 --> CA 2, old key --> Denis
>>
>>The CRL trust path is:
>>Root --> CA1 --> CA 2, new key --> CRL
>>
>>(Note: We do not do self-issued certificate since there is no simple,
>>secure way to check their revocation status).
>>
>>Now, with AIA in CRL, finding the CA2, new key certificate is
>>straightforward.  How would you find it if you do no deal with SIA et. 
>>al.
>>
>>Example 2: Indirect CRL Issuer
>>
>>The certificate trust path is:
>>Root --> CA1 --> CA 2 --> Denis
>>(Note: Denis's certificate points to CRL DP of an indirect CRL issued
>>by CAI.
>>
>>The CRL trust path is:
>>Root --> CAI --> CRL
>>
>>Now, with AIA in CRL, finding the CAI certificate is straightforward.
>>How would you find it if you do no deal with SIA et. al.
>>
>>In addition to the need cited above, please note that the extension
>>semantics does not change, it does not hinder any interoperability, 
>>and it does not break any backward compatibility.  So, what if I 
>>wanted to use this extension in the CRL.  It does no harm to other 
>>relying parties.
>>
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>Sent: Wednesday, October 13, 2004 11:01 AM
>>To: Stefan Santesson
>>Cc: Santosh Chokhani; pkix
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>
>>
>>Stefan,
>>
>>
>>
>>>Denis,
>>
>>
>>>I'm not sure what you mean.
>>
>>
>>For the time being, I would like that you provide an example where,
>>when
>>using the current extensions that are defined in RFC 3280, it will NOT be 
>>possible to locate a CRL Issuer certificate.
>>
>>If you are able to provide that example, then it would justify the
>>need for
>>an extension at least for one case. Then we can see what that case is.
>>
>>I am awaiting that example.
>>
>>Denis
>>
>>
>>
>>
>>>I conclude that I agree with Santosh.
>>>
>>>The debate is still open... Feel free to express your opinion.
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>Sent: den 13 oktober 2004 16:34
>>>>To: Stefan Santesson
>>>>Cc: Santosh Chokhani; pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>Stefan,
>>>>
>>>>You are making a conclusion without letting me the time to respond. 
>>>>I
>>>>will need more time to look at the pictures (and understand them).
>>>>
>>>>For the time being, I am still reluctant to accept
>>>
>>>"yet-another-method".
>>>
>>>
>>>
>>>>We already have too many.
>>>>
>>>>
>>>>
>>>>
>>>>>Santosh,
>>>>>
>>>>>I conclude that we are in complete and total agreement. The 
>>>>>question is how to go about this.
>>>>
>>>>>Could we do this amendment to RFC 3280 in its next revision? It
>>>>>would hopefully just be a minor change.
>>>>
>>>>This is exactly what I feared.
>>>>
>>>>We usually end-up with a "minor change" in an extension without
>>>>saying cleary how and when it shall/should be used.
>>>>
>>>>I still have in mind that:
>>>>
>>>>1) a certification path must first be constructed,
>>>>2) then the revocation checking of that path must be done.
>>>>
>>>>This means that information about CRL issuers certificates locations
>>>
>>>may
>>>
>>>
>>>
>>>>certainly be found in that chain. If not, I would like an example.
>>>>
>>>>Denis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>It would not change the definition of AIA just add that it can be
>>>>
>>>used
>>>
>>>
>>>
>>>>also as CRL extension and list eventual restrictions and guidance 
>>>>for
>>>
>>>use
>>>
>>>
>>>
>>>>with CRLs.
>>>>
>>>>
>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [e-mail]
>>>>>
>>>[mailto:[e-mail]]
>>>
>>>
>>>
>>>>>>On Behalf Of Santosh Chokhani
>>>>>>Sent: den 13 oktober 2004 04:33
>>>>>>To: 'pkix'
>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>
>>>>>>
>>>>>>Stefan:
>>>>>>
>>>>>>In terms of certificate discovery, your proposal for AIA in CRL is
>>>>>
>>>more
>>>
>>>
>>>
>>>>>>robust.  The whole idea of self-issued key rollover certificates
>>>>>>and
>>>>>
>>>>then
>>>>
>>>>
>>>>
>>>>>>using the new key to issue CRL is fraught with security problems.
>>>>>>A secure solution would be one where the new key is certified by 
>>>>>>the parent
>>>>>
>>>CA.
>>>
>>>
>>>
>>>>In
>>>>
>>>>
>>>>
>>>>>>that case to obtain the new certificate, you could use AIA in CRL.
>>>>>>
>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
>>>>>>certificate in question points to the indirect CRL.  You get that 
>>>>>>CRL.  The AIA
>>>>>
>>>in
>>>
>>>
>>>
>>>>CRL
>>>>
>>>>
>>>>
>>>>>>gets you started for the indirect CRL issuer certification path 
>>>>>>and
>>>>>
>>>you
>>>
>>>
>>>
>>>>>>are
>>>>>>in business.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [e-mail]
>>>>>
>>>[mailto:[e-mail]]
>>>
>>>
>>>
>>>>>>On
>>>>>>Behalf Of Stefan Santesson
>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>>To: David A. Cooper
>>>>>>Cc: pkix
>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>
>>>>>>
>>>>>>
>>>>>>David,
>>>>>>
>>>>>>Thanks for the clarifications, they make sense.
>>>>>>I did misread your pictures.
>>>>>>
>>>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>>>
>>>3280,
>>>
>>>
>>>
>>>>>>either the CRL issuer certificate itself, or the location of the
>>>>>>CRL issuer certificate, will be clearly identified/available for 
>>>>>>the validating
>>>>>
>>>>party
>>>>
>>>>
>>>>
>>>>>>in some cases, but not in others?
>>>>>>
>>>>>>Can we also conclude that there is no real discovery solution for
>>>>>
>>>>indirect
>>>>
>>>>
>>>>
>>>>>>CRLs?
>>>>>>
>>>>>>Do you then agree then that it could be appropriate to allow AIA 
>>>>>>as
>>>>>
>>>a
>>>
>>>
>>>
>>>>CRL
>>>>
>>>>
>>>>
>>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>>
>>>>>>Stefan Santesson
>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>
>>>>>>________________________________________
>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>Sent: den 12 oktober 2004 21:14
>>>>>>To: Stefan Santesson
>>>>>>Cc: pkix
>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>
>>>>>>Stefan,
>>>>>>
>>>>>>I believe that you are misinterpreting the figures.  They really 
>>>>>>do
>>>>>>represent three different cases, not three different certification
>>>>>
>>>paths
>>>
>>>
>>>
>>>>>>that have been constructed through the same PKI architecture.
>>>>>>
>>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>>
>>>certificates.
>>>
>>>
>>>
>>>>>>The
>>>>>>Root CA has issued a certificate to CA 1's new key, but not its 
>>>>>>old
>>>>>
>>>key
>>>
>>>
>>>
>>>>>>(either the Root CA never issued a certificate to CA 1's old key 
>>>>>>or
>>>>>
>>>that
>>>
>>>
>>>
>>>>>>certificate has expired).
>>>>>>
>>>>>>In figure 2, CA 2 has also generated self-issued key rollover
>>>>>>certificates. The Root CA has issued a certificate to CA 2's old 
>>>>>>key, but not its
>>>>>
>>>new
>>>
>>>
>>>
>>>>>>key.
>>>>>>
>>>>>>In figure 3, when CA 3 performed key rollover, it requested a new
>>>>>>CA certificate from the Root CA.  CA 3 did not generated 
>>>>>>self-issued
>>>>>
>>>key
>>>
>>>
>>>
>>>>>>rollover certificates.
>>>>>>
>>>>>>Of course, another realistic scenario would be one in which a CA
>>>>>
>>>>generated
>>>>
>>>>
>>>>
>>>>>>self-issued key rollover certificates upon key rollover and then
>>>>>>had
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>Root CA issue a CA certificate to its new key.  In this case, as
>>>>>>you suggest, any of the certification paths from figures 1, 2, or 3
>>>>>
>>>could be
>>>
>>>
>>>
>>>>>>constructed.
>>>>>>
>>>>>>As for the contents of the AIA extension, here is what I have
>>>>>
>>>specified
>>>
>>>
>>>
>>>>in
>>>>
>>>>
>>>>
>>>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>>>
>>>>Policy":
>>>>
>>>>
>>>>
>>>>>>The authorityInfoAccess extension uses URIs for two purposes. When
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>id-ad-caIssuers access method is used, the access location
>>>>>>specifies
>>>>>
>>>>where
>>>>
>>>>
>>>>
>>>>>>certificates issued to the issuer of the certificate may be found.
>>>>>
>>>If
>>>
>>>
>>>
>>>>LDAP
>>>>
>>>>
>>>>
>>>>>>is used, the URI must include the DN of the entry containing the
>>>>>
>>>>relevant
>>>>
>>>>
>>>>
>>>>>>certificates and specify the directory attribute in which the
>>>>>
>>>>certificates
>>>>
>>>>
>>>>
>>>>>>are located. If the directory in which the certificates are stored
>>>>>
>>>>expects
>>>>
>>>>
>>>>
>>>>>>the "binary" option to be specified, then the attribute type must
>>>>>>be followed by ";binary" in the URI. If HTTP is used, the URI must
>>>>>
>>>point to
>>>
>>>
>>>
>>>>a
>>>>
>>>>
>>>>
>>>>>>file that has an extension of ".p7c" that contains a certs-only 
>>>>>>CMS
>>>>>>message (see RFC 2633). The CMS message should include all 
>>>>>>certificates
>>>>>
>>>issued
>>>
>>>
>>>
>>>>to
>>>>
>>>>
>>>>
>>>>>>the issuer of this certificate, but must at least contain all
>>>>>
>>>>certificates
>>>>
>>>>
>>>>
>>>>>>issued to the issuer of this certificate in which the subject
>>>>>>public
>>>>>
>>>key
>>>
>>>
>>>
>>>>>>may
>>>>>>be used to verify the signature on this certificate. .... For a
>>>>>>certificate issued by "Good CA", some examples of URIs that may 
>>>>>>appear as the
>>>>>
>>>access
>>>
>>>
>>>
>>>>>>location in an authorityInfoAccess extension when the
>>>>>
>>>id-ad-caIssuers
>>>
>>>
>>>
>>>>>>access
>>>>>>method is used are:
>>>>>
>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACe
>>>>>r
>>>>>t
>>>>>i
>>>>
>>>fi
>>>
>>>
>>>
>>>>ca
>>>>
>>>>
>>>>
>>>>>>te
>>>>>>,crossCertificatePair
>>>>>
>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertif
>>>>>i
>>>>>c
>>>>>a
>>>>
>>>te
>>>
>>>
>>>
>>>>;b
>>>>
>>>>
>>>>
>>>>>>in
>>>>>>ary,crossCertificatePair;binary
>>>>>
>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIss
>>>>>u
>>>>>e
>>>>>d
>>>>
>>>To
>>>
>>>
>>>
>>>>Go
>>>>
>>>>
>>>>
>>>>>>od
>>>>>>CA.p7c
>>>>>>For both LDAP and HTTP, the URI provides the exact location where
>>>>>>information is to be located, so there is no requirement for the
>>>>>
>>>relying
>>>
>>>
>>>
>>>>>>party to try to figure out where information is located.
>>>>>>
>>>>>>The HTTP URI points to a certs-only CMS message that includes all
>>>>>>certificates issued to the CA identified in the issuer field of the 
>>>>>>certificate.
>>>>>>
>>>>>>The LDAP URI points to the cACertificate and crossCertificatePair
>>>>>>attributes of the directory entry of the CA identified in the 
>>>>>>issuer field of
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>certificate.  These two attributes together hold all of the
>>>>>
>>>certificates
>>>
>>>
>>>
>>>>>>issued to the CA:  the cACertificate attribute holds the CA's 
>>>>>>self-
>>>>>
>>>>issued
>>>>
>>>>
>>>>
>>>>>>certificates and the crossCertificatePair attribute holds the
>>>>>>cross-certificates issued to the CA by other CAs.
>>>>>>
>>>>>>Dave
>>>>>>
>>>>>>
>>>>>>Stefan Santesson wrote:
>>>>>>
>>>>>>David,
>>>>>>
>>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>>
>>>>>>I have some comments and questions on this.
>>>>>>
>>>>>>First of all we can conclude that in some scenarios (figure 1)
>>>>>>where
>>>>>
>>>a
>>>
>>>
>>>
>>>>>>self
>>>>>>issued certificate is inserted into the path, you are likely to
>>>>>>find
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>CRL
>>>>>>issuer cert in the path. (given that the new CA have a common key
>>>>>
>>>and
>>>
>>>
>>>
>>>>>>certificate for cert signing and CRL signing).
>>>>>>
>>>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>>>
>>>>different
>>>>
>>>>
>>>>
>>>>>>path building strategies. An application that has access locally 
>>>>>>to
>>>>>
>>>all
>>>
>>>
>>>
>>>>>>chaining options may however still choose path 2 for the certs and
>>>>>
>>>path
>>>
>>>
>>>
>>>>1
>>>>
>>>>
>>>>
>>>>>>for the CRL independent of each other (which I think figure 3 
>>>>>>tries
>>>>>
>>>to
>>>
>>>
>>>
>>>>>>describe)
>>>>>>
>>>>>>Another comment is the structure of AIA extensions. The use I'm
>>>>>
>>>familiar
>>>
>>>
>>>
>>>>>>with doesn't use AIA to describe a directory entry where it is 
>>>>>>left
>>>>>
>>>to
>>>
>>>
>>>
>>>>the
>>>>
>>>>
>>>>
>>>>>>validation application logic to be intelligent enough to find
>>>>>
>>>>appropriate
>>>>
>>>>
>>>>
>>>>>>certificate data from the directory. The model I'm familiar with 
>>>>>>is
>>>>>
>>>when
>>>
>>>
>>>
>>>>>>the
>>>>>>AIA URL explicitly identifies the exact location of the 
>>>>>>appropriate
>>>>>
>>>CA
>>>
>>>
>>>
>>>>>>certificate file, relieving the validation software from complex
>>>>>>information queries. If just location of explicit certificate files 
>>>>>>are
>>>>>
>>>identified
>>>
>>>
>>>
>>>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>>>
>>>signer
>>>
>>>
>>>
>>>>>>cert
>>>>>>if this is different from the CA certificate. This is also the
>>>>>
>>>problem
>>>
>>>
>>>
>>>>>>with
>>>>>>Denis proposal.
>>>>>>
>>>>>>I think we share the basic conclusion that the ability to locate
>>>>>>the
>>>>>
>>>CRL
>>>
>>>
>>>
>>>>>>signer certificate directly through the CRL could be very useful.
>>>>>>At
>>>>>
>>>>least
>>>>
>>>>
>>>>
>>>>>>in the case of indirect CRL but it could also be proven very 
>>>>>>useful
>>>>>
>>>in
>>>
>>>
>>>
>>>>CA
>>>>
>>>>
>>>>
>>>>>>re-keying scenarios.
>>>>>>
>>>>>>The easiest solution would probably be to allow AIA to be used in
>>>>>
>>>its
>>>
>>>
>>>
>>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>>
>>>critical).
>>>
>>>
>>>
>>>>It
>>>>
>>>>
>>>>
>>>>>>would present a very clear and uncomplicated logic to certificate
>>>>>>validating applications in many cases.
>>>>>>
>>>>>>Stefan Santesson
>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>
>>>>>>________________________________________
>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>Sent: den 7 oktober 2004 18:35
>>>>>>To: Stefan Santesson
>>>>>>Cc: pkix
>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>
>>>>>>Stefan,
>>>>>>
>>>>>>I think what you are proposing is a good idea.  In most cases, 
>>>>>>path
>>>>>>discovery algorithms assume that both the trust anchor (or trust
>>>>>
>>>>anchors)
>>>>
>>>>
>>>>
>>>>>>and the end entity certificate are provided as input.  In this
>>>>>>case,
>>>>>
>>>one
>>>
>>>
>>>
>>>>>>may
>>>>>>need to construct a certification path without a priori access to
>>>>>
>>>the
>>>
>>>
>>>
>>>>end
>>>>
>>>>
>>>>
>>>>>>entity certificate (the one with the subject public key
>>>>>
>>>corresponding to
>>>
>>>
>>>
>>>>>>the
>>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>>
>>>pointer) in
>>>
>>>
>>>
>>>>>>the
>>>>>>CRL would provide the relying party with a simple way to obtain 
>>>>>>the
>>>>>
>>>end
>>>
>>>
>>>
>>>>>>entity certificate for the CRL signing key's certification path. 
>>>>>>On
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>other hand, I believe that a relying party should be able to
>>>>>
>>>construct
>>>
>>>
>>>
>>>>the
>>>>
>>>>
>>>>
>>>>>>certification path even without an AIA extension in the CRL, so
>>>>>>long
>>>>>
>>>as
>>>
>>>
>>>
>>>>it
>>>>
>>>>
>>>>
>>>>>>is not an indirect CRL.  Attached is a drawing of the three basic
>>>>>>scenarios that I expect a relying party may encounter:
>>>>>>
>>>>>>In each of these scenarios, the CA has performed key rollover and
>>>>>>is
>>>>>
>>>>only
>>>>
>>>>
>>>>
>>>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>>>
>>>>however,
>>>>
>>>>
>>>>
>>>>>>if
>>>>>>the CA simply choose to use different keys to sign certificates 
>>>>>>and
>>>>>
>>>CRLs
>>>
>>>
>>>
>>>>>>for
>>>>>>some other reason.
>>>>>>
>>>>>>If the PKI architecture resembled figure 1, then the certification
>>>>>
>>>path
>>>
>>>
>>>
>>>>>>for
>>>>>>the CRL signing key would just be a subset of the certification
>>>>>>path
>>>>>
>>>for
>>>
>>>
>>>
>>>>>>the
>>>>>>EE certificate, so no addition path discovery would be needed.
>>>>>>
>>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>>
>>>necessary
>>>
>>>
>>>
>>>>to
>>>>
>>>>
>>>>
>>>>>>obtain the new-signed-with-old self-issued certificate.  In
>>>>>>building
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>certification path to the EE certificate, however, the relying
>>>>>>party
>>>>>
>>>>will
>>>>
>>>>
>>>>
>>>>>>obtain the certificates pointed to by the AIA extension in the EE
>>>>>>certificate.  This AIA extension will point to a location 
>>>>>>containing
>>>>>
>>>all
>>>
>>>
>>>
>>>>>>certificates issued to CA 2, which would include both the
>>>>>
>>>certificate
>>>
>>>
>>>
>>>>>>issued
>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
>>>>>
>>>though
>>>
>>>
>>>
>>>>>>the
>>>>>>self-issued certificate would not be part of the certification 
>>>>>>path
>>>>>
>>>to
>>>
>>>
>>>
>>>>the
>>>>
>>>>
>>>>
>>>>>>EE certificate, it would be downloaded by the relying party during
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>construction of that certification path.  (Yes, there are circular
>>>>>>dependency issues in figure 2, but that is another issue.)
>>>>>>
>>>>>>A similar situation would happen if the PKI architecture resembled
>>>>>
>>>>figure
>>>>
>>>>
>>>>
>>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>>
>>>location
>>>
>>>
>>>
>>>>>>containing certificates issued to CA 3.  When the relying party
>>>>>
>>>>downloaded
>>>>
>>>>
>>>>
>>>>>>these certificates, it would obtain both of the certificates 
>>>>>>issued
>>>>>
>>>by
>>>
>>>
>>>
>>>>the
>>>>
>>>>
>>>>
>>>>>>Root to CA 3 and so again would have the certificate needed to
>>>>>
>>>validate
>>>
>>>
>>>
>>>>>>the
>>>>>>CRL signing key.
>>>>>>
>>>>>>In the case of an indirect CRL, things may not work as well.  If
>>>>>
>>>>indirect
>>>>
>>>>
>>>>
>>>>>>CRLs were used, and the PKI architecture resembled figures 2 or 3
>>>>>>(replacing "New Key" with a different CA), then the set of 
>>>>>>certificates pointed
>>>>>
>>>to
>>>
>>>
>>>
>>>>by
>>>>
>>>>
>>>>
>>>>>>the AIA extension in the EE certificate would not include the
>>>>>
>>>>certificate
>>>>
>>>>
>>>>
>>>>>>of
>>>>>>the CRL signer.  One could find this certificate by building in 
>>>>>>the
>>>>>>reverse direction and using the SIA extension, but that may not be 
>>>>>>the most convenient solution.
>>>>>>
>>>>>>So, when indirect CRLs are being used, it seems that it would be
>>>>>
>>>very
>>>
>>>
>>>
>>>>>>useful
>>>>>>to have a pointer in the CRL to the CRL signing certificate.  When
>>>>>
>>>the
>>>
>>>
>>>
>>>>CRL
>>>>
>>>>
>>>>
>>>>>>is not indirect, the need for this pointer does not seem to be as
>>>>>
>>>clear,
>>>
>>>
>>>
>>>>>>but
>>>>>>I can't see any harm in including it.
>>>>>>
>>>>>>Dave
>>>>>>
>>>>>>Stefan Santesson wrote:
>>>>>>All,
>>>>>>
>>>>>>I'm interested in the opinion from members on this list about
>>>>>
>>>discovery
>>>
>>>
>>>
>>>>of
>>>>
>>>>
>>>>
>>>>>>CRL signer's certificate in non directory centric environments.
>>>>>>
>>>>>>The problem is the following.
>>>>>>
>>>>>>The relying party (RP) needs to check validity of a certificate 
>>>>>>and
>>>>>
>>>>finds
>>>>
>>>>
>>>>
>>>>>>a
>>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL
>>>>>>which
>>>>>
>>>in
>>>
>>>
>>>
>>>>>>this
>>>>>>particular case is either signed by another key of the CA 
>>>>>>(re-keyed
>>>>>
>>>CA)
>>>
>>>
>>>
>>>>or
>>>>
>>>>
>>>>
>>>>>>another entity (indirect CRL).
>>>>>>
>>>>>>In this case the relying party needs to obtain the certificate of
>>>>>
>>>the
>>>
>>>
>>>
>>>>CRL
>>>>
>>>>
>>>>
>>>>>>signer which may NOT be part of the original chain. In a directory
>>>>>
>>>>centric
>>>>
>>>>
>>>>
>>>>>>solution this is retrieved from the directory, but what if such
>>>>>
>>>>directory
>>>>
>>>>
>>>>
>>>>>>is
>>>>>>not available or accessible.
>>>>>>
>>>>>>The RP have thus no hint where to find the CRL issuers certificate
>>>>>
>>>>unless
>>>>
>>>>
>>>>
>>>>>>the RP already have possession of it by some other means.
>>>>>>
>>>>>>Is seems that CRLs would need an AIA extension with the option to
>>>>>
>>>point
>>>
>>>
>>>
>>>>to
>>>>
>>>>
>>>>
>>>>>>the location of the signers certificate in the same manner as is
>>>>>
>>>>possible
>>>>
>>>>
>>>>
>>>>>>for certificates.
>>>>>>
>>>>>>Maybe AIA should be defined as both cert and CRL extension and not
>>>>>
>>>only
>>>
>>>
>>>
>>>>>>certificate extension as today.
>>>>>>
>>>>>>Thoughts and comments?
>>>>>>
>>>>>>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 i9EFBuH6005165; Thu, 14 Oct 2004 08:11:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EFBuGp005164; Thu, 14 Oct 2004 08:11:56 -0700 (PDT)
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 i9EFBrwu005149 for <[e-mail]>; Thu, 14 Oct 2004 08:11:54 -0700 (PDT) (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 RAA61736; Thu, 14 Oct 2004 17:23:09 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101417112941:1059 ; Thu, 14 Oct 2004 17:11:29 +0200 
Message-ID: <[e-mail]>
Date: Thu, 14 Oct 2004 17:12:38 +0200
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: <003601c4b1ef$2bb55260$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 14/10/2004 17:11:29, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 14/10/2004 17:11:31, Serialize complete at 14/10/2004 17:11:31
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:

> With the three assumptions/constraints I provided, how would you locate the
> CRL issuer certificate for the two examples using 3280 extensions and
> without putting AIA in the CRL?

As far as I understand, the three assumptions are:

1.  You are directory challenged; and
     [I do not understand what this means]
2.  You use AIA to develop the path; and
     [It does not matter]
3.  You develop the path from the end entity to trust anchor
     [Could also be the contrary].

If this is not correct, thus please correct.

Then my request is: "using ANY OF the current extensions that are defined in 
RFC 3280", which includes SIA.

In your explanations  you said :
"if you do no deal with SIA et. al"

This last assumption is neither part of the three assumptions and does not 
conform to my request.

Denis

> That is my point.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, October 14, 2004 6:22 AM
> To: Santosh Chokhani
> Cc: 'pkix'
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Santosh,
> 
> You misread my request. I said:
> 
> "For the time being, I would like that you provide an example where, when
> using the current extensions that are defined in RFC 3280, it will NOT be
> possible to locate a CRL Issuer certificate."
> 
> Maybe I would have needed to be clearer and say :
> 
> "For the time being, I would like that you provide an example where, when
> using ANY OF the current extensions that are defined in RFC 3280, it will 
> NOT be possible to locate a CRL Issuer certificate."
> 
> The examples you provide below do not fulfil this request.
> 
> The assumption is that there exists a path to be tested for revocation 
> checking (and that it does not matter to know which way it has been 
> constructed).
> 
> I am not saying that using AIA in CRL might not be useful, but I am still 
> lacking the demonstration that there would be no other way.
> 
> Denis
> 
> 
> 
>>Denis:
>>
>>Two examples are very simple: one for direct CRL Issuer and one for 
>>Indirect CRL Issuer.
>>
>>Let us make the following assumptions that Stefan was making:
>>
>>1.  You are directory challenged; and
>>2.  You use AIA to develop the path; and
>>3.  You develop the path from the end entity to trust anchor.
>>
>>From what I know of MS CAPI, these are reasonable 
>>assumptions/constraints.
>>
>>Now the examples.
>>
>>Example 1: Direct CRL Issuer
>>
>>The certificate trust path is:
>>Root --> CA1 --> CA 2, old key --> Denis
>>
>>The CRL trust path is:
>>Root --> CA1 --> CA 2, new key --> CRL
>>
>>(Note: We do not do self-issued certificate since there is no simple, 
>>secure way to check their revocation status).
>>
>>Now, with AIA in CRL, finding the CA2, new key certificate is 
>>straightforward.  How would you find it if you do no deal with SIA et. 
>>al.
>>
>>Example 2: Indirect CRL Issuer
>>
>>The certificate trust path is:
>>Root --> CA1 --> CA 2 --> Denis
>>(Note: Denis's certificate points to CRL DP of an indirect CRL issued 
>>by CAI.
>>
>>The CRL trust path is:
>>Root --> CAI --> CRL
>>
>>Now, with AIA in CRL, finding the CAI certificate is straightforward.  
>>How would you find it if you do no deal with SIA et. al.
>>
>>In addition to the need cited above, please note that the extension 
>>semantics does not change, it does not hinder any interoperability, 
>>and it does not break any backward compatibility.  So, what if I 
>>wanted to use this extension in the CRL.  It does no harm to other 
>>relying parties.
>>
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>Sent: Wednesday, October 13, 2004 11:01 AM
>>To: Stefan Santesson
>>Cc: Santosh Chokhani; pkix
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>
>>
>>Stefan,
>>
>>
>>
>>>Denis,
>>
>>
>>>I'm not sure what you mean.
>>
>>
>>For the time being, I would like that you provide an example where, 
>>when
>>using the current extensions that are defined in RFC 3280, it will NOT be 
>>possible to locate a CRL Issuer certificate.
>>
>>If you are able to provide that example, then it would justify the 
>>need for
>>an extension at least for one case. Then we can see what that case is.
>>
>>I am awaiting that example.
>>
>>Denis
>>
>>
>>
>>
>>>I conclude that I agree with Santosh.
>>>
>>>The debate is still open... Feel free to express your opinion.
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>Sent: den 13 oktober 2004 16:34
>>>>To: Stefan Santesson
>>>>Cc: Santosh Chokhani; pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>Stefan,
>>>>
>>>>You are making a conclusion without letting me the time to respond. I 
>>>>will need more time to look at the pictures (and understand them).
>>>>
>>>>For the time being, I am still reluctant to accept
>>>
>>>"yet-another-method".
>>>
>>>
>>>
>>>>We already have too many.
>>>>
>>>>
>>>>
>>>>
>>>>>Santosh,
>>>>>
>>>>>I conclude that we are in complete and total agreement.
>>>>>The question is how to go about this.
>>>>
>>>>>Could we do this amendment to RFC 3280 in its next revision? It 
>>>>>would hopefully just be a minor change.
>>>>
>>>>This is exactly what I feared.
>>>>
>>>>We usually end-up with a "minor change" in an extension without 
>>>>saying cleary how and when it shall/should be used.
>>>>
>>>>I still have in mind that:
>>>>
>>>>1) a certification path must first be constructed,
>>>>2) then the revocation checking of that path must be done.
>>>>
>>>>This means that information about CRL issuers certificates locations
>>>
>>>may
>>>
>>>
>>>
>>>>certainly be found in that chain. If not, I would like an example.
>>>>
>>>>Denis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>It would not change the definition of AIA just add that it can be
>>>>
>>>used
>>>
>>>
>>>
>>>>also as CRL extension and list eventual restrictions and guidance for
>>>
>>>use
>>>
>>>
>>>
>>>>with CRLs.
>>>>
>>>>
>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [e-mail]
>>>>>
>>>[mailto:[e-mail]]
>>>
>>>
>>>
>>>>>>On Behalf Of Santosh Chokhani
>>>>>>Sent: den 13 oktober 2004 04:33
>>>>>>To: 'pkix'
>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>
>>>>>>
>>>>>>Stefan:
>>>>>>
>>>>>>In terms of certificate discovery, your proposal for AIA in CRL is
>>>>>
>>>more
>>>
>>>
>>>
>>>>>>robust.  The whole idea of self-issued key rollover certificates 
>>>>>>and
>>>>>
>>>>then
>>>>
>>>>
>>>>
>>>>>>using the new key to issue CRL is fraught with security problems.  
>>>>>>A secure solution would be one where the new key is certified by 
>>>>>>the parent
>>>>>
>>>CA.
>>>
>>>
>>>
>>>>In
>>>>
>>>>
>>>>
>>>>>>that case to obtain the new certificate, you could use AIA in CRL.
>>>>>>
>>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in 
>>>>>>certificate in question points to the indirect CRL.  You get that 
>>>>>>CRL.  The AIA
>>>>>
>>>in
>>>
>>>
>>>
>>>>CRL
>>>>
>>>>
>>>>
>>>>>>gets you started for the indirect CRL issuer certification path and
>>>>>
>>>you
>>>
>>>
>>>
>>>>>>are
>>>>>>in business.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: [e-mail]
>>>>>
>>>[mailto:[e-mail]]
>>>
>>>
>>>
>>>>>>On
>>>>>>Behalf Of Stefan Santesson
>>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>>To: David A. Cooper
>>>>>>Cc: pkix
>>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>>
>>>>>>
>>>>>>
>>>>>>David,
>>>>>>
>>>>>>Thanks for the clarifications, they make sense.
>>>>>>I did misread your pictures.
>>>>>>
>>>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>>>
>>>3280,
>>>
>>>
>>>
>>>>>>either the CRL issuer certificate itself, or the location of the 
>>>>>>CRL issuer certificate, will be clearly identified/available for 
>>>>>>the validating
>>>>>
>>>>party
>>>>
>>>>
>>>>
>>>>>>in some cases, but not in others?
>>>>>>
>>>>>>Can we also conclude that there is no real discovery solution for
>>>>>
>>>>indirect
>>>>
>>>>
>>>>
>>>>>>CRLs?
>>>>>>
>>>>>>Do you then agree then that it could be appropriate to allow AIA as
>>>>>
>>>a
>>>
>>>
>>>
>>>>CRL
>>>>
>>>>
>>>>
>>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>>
>>>>>>Stefan Santesson
>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>
>>>>>>________________________________________
>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>Sent: den 12 oktober 2004 21:14
>>>>>>To: Stefan Santesson
>>>>>>Cc: pkix
>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>
>>>>>>Stefan,
>>>>>>
>>>>>>I believe that you are misinterpreting the figures.  They really do 
>>>>>>represent three different cases, not three different certification
>>>>>
>>>paths
>>>
>>>
>>>
>>>>>>that have been constructed through the same PKI architecture.
>>>>>>
>>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>>
>>>certificates.
>>>
>>>
>>>
>>>>>>The
>>>>>>Root CA has issued a certificate to CA 1's new key, but not its old
>>>>>
>>>key
>>>
>>>
>>>
>>>>>>(either the Root CA never issued a certificate to CA 1's old key or
>>>>>
>>>that
>>>
>>>
>>>
>>>>>>certificate has expired).
>>>>>>
>>>>>>In figure 2, CA 2 has also generated self-issued key rollover 
>>>>>>certificates. The Root CA has issued a certificate to CA 2's old 
>>>>>>key, but not its
>>>>>
>>>new
>>>
>>>
>>>
>>>>>>key.
>>>>>>
>>>>>>In figure 3, when CA 3 performed key rollover, it requested a new 
>>>>>>CA certificate from the Root CA.  CA 3 did not generated 
>>>>>>self-issued
>>>>>
>>>key
>>>
>>>
>>>
>>>>>>rollover certificates.
>>>>>>
>>>>>>Of course, another realistic scenario would be one in which a CA
>>>>>
>>>>generated
>>>>
>>>>
>>>>
>>>>>>self-issued key rollover certificates upon key rollover and then 
>>>>>>had
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>Root CA issue a CA certificate to its new key.  In this case, as 
>>>>>>you suggest, any of the certification paths from figures 1, 2, or 3
>>>>>
>>>could be
>>>
>>>
>>>
>>>>>>constructed.
>>>>>>
>>>>>>As for the contents of the AIA extension, here is what I have
>>>>>
>>>specified
>>>
>>>
>>>
>>>>in
>>>>
>>>>
>>>>
>>>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>>>
>>>>Policy":
>>>>
>>>>
>>>>
>>>>>>The authorityInfoAccess extension uses URIs for two purposes. When
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>id-ad-caIssuers access method is used, the access location 
>>>>>>specifies
>>>>>
>>>>where
>>>>
>>>>
>>>>
>>>>>>certificates issued to the issuer of the certificate may be found.
>>>>>
>>>If
>>>
>>>
>>>
>>>>LDAP
>>>>
>>>>
>>>>
>>>>>>is used, the URI must include the DN of the entry containing the
>>>>>
>>>>relevant
>>>>
>>>>
>>>>
>>>>>>certificates and specify the directory attribute in which the
>>>>>
>>>>certificates
>>>>
>>>>
>>>>
>>>>>>are located. If the directory in which the certificates are stored
>>>>>
>>>>expects
>>>>
>>>>
>>>>
>>>>>>the "binary" option to be specified, then the attribute type must 
>>>>>>be followed by ";binary" in the URI. If HTTP is used, the URI must
>>>>>
>>>point to
>>>
>>>
>>>
>>>>a
>>>>
>>>>
>>>>
>>>>>>file that has an extension of ".p7c" that contains a certs-only CMS 
>>>>>>message (see RFC 2633). The CMS message should include all 
>>>>>>certificates
>>>>>
>>>issued
>>>
>>>
>>>
>>>>to
>>>>
>>>>
>>>>
>>>>>>the issuer of this certificate, but must at least contain all
>>>>>
>>>>certificates
>>>>
>>>>
>>>>
>>>>>>issued to the issuer of this certificate in which the subject 
>>>>>>public
>>>>>
>>>key
>>>
>>>
>>>
>>>>>>may
>>>>>>be used to verify the signature on this certificate. .... For a 
>>>>>>certificate issued by "Good CA", some examples of URIs that may 
>>>>>>appear as the
>>>>>
>>>access
>>>
>>>
>>>
>>>>>>location in an authorityInfoAccess extension when the
>>>>>
>>>id-ad-caIssuers
>>>
>>>
>>>
>>>>>>access
>>>>>>method is used are:
>>>>>
>>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACer
>>>>>t
>>>>>i
>>>>
>>>fi
>>>
>>>
>>>
>>>>ca
>>>>
>>>>
>>>>
>>>>>>te
>>>>>>,crossCertificatePair
>>>>>
>>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifi
>>>>>c
>>>>>a
>>>>
>>>te
>>>
>>>
>>>
>>>>;b
>>>>
>>>>
>>>>
>>>>>>in
>>>>>>ary,crossCertificatePair;binary
>>>>>
>>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssu
>>>>>e
>>>>>d
>>>>
>>>To
>>>
>>>
>>>
>>>>Go
>>>>
>>>>
>>>>
>>>>>>od
>>>>>>CA.p7c
>>>>>>For both LDAP and HTTP, the URI provides the exact location where 
>>>>>>information is to be located, so there is no requirement for the
>>>>>
>>>relying
>>>
>>>
>>>
>>>>>>party to try to figure out where information is located.
>>>>>>
>>>>>>The HTTP URI points to a certs-only CMS message that includes all 
>>>>>>certificates issued to the CA identified in the issuer field of the 
>>>>>>certificate.
>>>>>>
>>>>>>The LDAP URI points to the cACertificate and crossCertificatePair 
>>>>>>attributes of the directory entry of the CA identified in the 
>>>>>>issuer field of
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>certificate.  These two attributes together hold all of the
>>>>>
>>>certificates
>>>
>>>
>>>
>>>>>>issued to the CA:  the cACertificate attribute holds the CA's self-
>>>>>
>>>>issued
>>>>
>>>>
>>>>
>>>>>>certificates and the crossCertificatePair attribute holds the 
>>>>>>cross-certificates issued to the CA by other CAs.
>>>>>>
>>>>>>Dave
>>>>>>
>>>>>>
>>>>>>Stefan Santesson wrote:
>>>>>>
>>>>>>David,
>>>>>>
>>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>>
>>>>>>I have some comments and questions on this.
>>>>>>
>>>>>>First of all we can conclude that in some scenarios (figure 1) 
>>>>>>where
>>>>>
>>>a
>>>
>>>
>>>
>>>>>>self
>>>>>>issued certificate is inserted into the path, you are likely to 
>>>>>>find
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>CRL
>>>>>>issuer cert in the path. (given that the new CA have a common key
>>>>>
>>>and
>>>
>>>
>>>
>>>>>>certificate for cert signing and CRL signing).
>>>>>>
>>>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>>>
>>>>different
>>>>
>>>>
>>>>
>>>>>>path building strategies. An application that has access locally to
>>>>>
>>>all
>>>
>>>
>>>
>>>>>>chaining options may however still choose path 2 for the certs and
>>>>>
>>>path
>>>
>>>
>>>
>>>>1
>>>>
>>>>
>>>>
>>>>>>for the CRL independent of each other (which I think figure 3 tries
>>>>>
>>>to
>>>
>>>
>>>
>>>>>>describe)
>>>>>>
>>>>>>Another comment is the structure of AIA extensions. The use I'm
>>>>>
>>>familiar
>>>
>>>
>>>
>>>>>>with doesn't use AIA to describe a directory entry where it is left
>>>>>
>>>to
>>>
>>>
>>>
>>>>the
>>>>
>>>>
>>>>
>>>>>>validation application logic to be intelligent enough to find
>>>>>
>>>>appropriate
>>>>
>>>>
>>>>
>>>>>>certificate data from the directory. The model I'm familiar with is
>>>>>
>>>when
>>>
>>>
>>>
>>>>>>the
>>>>>>AIA URL explicitly identifies the exact location of the appropriate
>>>>>
>>>CA
>>>
>>>
>>>
>>>>>>certificate file, relieving the validation software from complex 
>>>>>>information queries. If just location of explicit certificate files 
>>>>>>are
>>>>>
>>>identified
>>>
>>>
>>>
>>>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>>>
>>>signer
>>>
>>>
>>>
>>>>>>cert
>>>>>>if this is different from the CA certificate. This is also the
>>>>>
>>>problem
>>>
>>>
>>>
>>>>>>with
>>>>>>Denis proposal.
>>>>>>
>>>>>>I think we share the basic conclusion that the ability to locate 
>>>>>>the
>>>>>
>>>CRL
>>>
>>>
>>>
>>>>>>signer certificate directly through the CRL could be very useful. 
>>>>>>At
>>>>>
>>>>least
>>>>
>>>>
>>>>
>>>>>>in the case of indirect CRL but it could also be proven very useful
>>>>>
>>>in
>>>
>>>
>>>
>>>>CA
>>>>
>>>>
>>>>
>>>>>>re-keying scenarios.
>>>>>>
>>>>>>The easiest solution would probably be to allow AIA to be used in
>>>>>
>>>its
>>>
>>>
>>>
>>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>>
>>>critical).
>>>
>>>
>>>
>>>>It
>>>>
>>>>
>>>>
>>>>>>would present a very clear and uncomplicated logic to certificate 
>>>>>>validating applications in many cases.
>>>>>>
>>>>>>Stefan Santesson
>>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>>
>>>>>>________________________________________
>>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>>Sent: den 7 oktober 2004 18:35
>>>>>>To: Stefan Santesson
>>>>>>Cc: pkix
>>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>>
>>>>>>Stefan,
>>>>>>
>>>>>>I think what you are proposing is a good idea.  In most cases, path 
>>>>>>discovery algorithms assume that both the trust anchor (or trust
>>>>>
>>>>anchors)
>>>>
>>>>
>>>>
>>>>>>and the end entity certificate are provided as input.  In this 
>>>>>>case,
>>>>>
>>>one
>>>
>>>
>>>
>>>>>>may
>>>>>>need to construct a certification path without a priori access to
>>>>>
>>>the
>>>
>>>
>>>
>>>>end
>>>>
>>>>
>>>>
>>>>>>entity certificate (the one with the subject public key
>>>>>
>>>corresponding to
>>>
>>>
>>>
>>>>>>the
>>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>>
>>>pointer) in
>>>
>>>
>>>
>>>>>>the
>>>>>>CRL would provide the relying party with a simple way to obtain the
>>>>>
>>>end
>>>
>>>
>>>
>>>>>>entity certificate for the CRL signing key's certification path. On
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>other hand, I believe that a relying party should be able to
>>>>>
>>>construct
>>>
>>>
>>>
>>>>the
>>>>
>>>>
>>>>
>>>>>>certification path even without an AIA extension in the CRL, so 
>>>>>>long
>>>>>
>>>as
>>>
>>>
>>>
>>>>it
>>>>
>>>>
>>>>
>>>>>>is not an indirect CRL.  Attached is a drawing of the three basic 
>>>>>>scenarios that I expect a relying party may encounter:
>>>>>>
>>>>>>In each of these scenarios, the CA has performed key rollover and 
>>>>>>is
>>>>>
>>>>only
>>>>
>>>>
>>>>
>>>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>>>
>>>>however,
>>>>
>>>>
>>>>
>>>>>>if
>>>>>>the CA simply choose to use different keys to sign certificates and
>>>>>
>>>CRLs
>>>
>>>
>>>
>>>>>>for
>>>>>>some other reason.
>>>>>>
>>>>>>If the PKI architecture resembled figure 1, then the certification
>>>>>
>>>path
>>>
>>>
>>>
>>>>>>for
>>>>>>the CRL signing key would just be a subset of the certification 
>>>>>>path
>>>>>
>>>for
>>>
>>>
>>>
>>>>>>the
>>>>>>EE certificate, so no addition path discovery would be needed.
>>>>>>
>>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>>
>>>necessary
>>>
>>>
>>>
>>>>to
>>>>
>>>>
>>>>
>>>>>>obtain the new-signed-with-old self-issued certificate.  In 
>>>>>>building
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>certification path to the EE certificate, however, the relying 
>>>>>>party
>>>>>
>>>>will
>>>>
>>>>
>>>>
>>>>>>obtain the certificates pointed to by the AIA extension in the EE 
>>>>>>certificate.  This AIA extension will point to a location 
>>>>>>containing
>>>>>
>>>all
>>>
>>>
>>>
>>>>>>certificates issued to CA 2, which would include both the
>>>>>
>>>certificate
>>>
>>>
>>>
>>>>>>issued
>>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
>>>>>
>>>though
>>>
>>>
>>>
>>>>>>the
>>>>>>self-issued certificate would not be part of the certification path
>>>>>
>>>to
>>>
>>>
>>>
>>>>the
>>>>
>>>>
>>>>
>>>>>>EE certificate, it would be downloaded by the relying party during
>>>>>
>>>the
>>>
>>>
>>>
>>>>>>construction of that certification path.  (Yes, there are circular 
>>>>>>dependency issues in figure 2, but that is another issue.)
>>>>>>
>>>>>>A similar situation would happen if the PKI architecture resembled
>>>>>
>>>>figure
>>>>
>>>>
>>>>
>>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>>
>>>location
>>>
>>>
>>>
>>>>>>containing certificates issued to CA 3.  When the relying party
>>>>>
>>>>downloaded
>>>>
>>>>
>>>>
>>>>>>these certificates, it would obtain both of the certificates issued
>>>>>
>>>by
>>>
>>>
>>>
>>>>the
>>>>
>>>>
>>>>
>>>>>>Root to CA 3 and so again would have the certificate needed to
>>>>>
>>>validate
>>>
>>>
>>>
>>>>>>the
>>>>>>CRL signing key.
>>>>>>
>>>>>>In the case of an indirect CRL, things may not work as well.  If
>>>>>
>>>>indirect
>>>>
>>>>
>>>>
>>>>>>CRLs were used, and the PKI architecture resembled figures 2 or 3 
>>>>>>(replacing "New Key" with a different CA), then the set of 
>>>>>>certificates pointed
>>>>>
>>>to
>>>
>>>
>>>
>>>>by
>>>>
>>>>
>>>>
>>>>>>the AIA extension in the EE certificate would not include the
>>>>>
>>>>certificate
>>>>
>>>>
>>>>
>>>>>>of
>>>>>>the CRL signer.  One could find this certificate by building in the 
>>>>>>reverse direction and using the SIA extension, but that may not be 
>>>>>>the most convenient solution.
>>>>>>
>>>>>>So, when indirect CRLs are being used, it seems that it would be
>>>>>
>>>very
>>>
>>>
>>>
>>>>>>useful
>>>>>>to have a pointer in the CRL to the CRL signing certificate.  When
>>>>>
>>>the
>>>
>>>
>>>
>>>>CRL
>>>>
>>>>
>>>>
>>>>>>is not indirect, the need for this pointer does not seem to be as
>>>>>
>>>clear,
>>>
>>>
>>>
>>>>>>but
>>>>>>I can't see any harm in including it.
>>>>>>
>>>>>>Dave
>>>>>>
>>>>>>Stefan Santesson wrote:
>>>>>>All,
>>>>>>
>>>>>>I'm interested in the opinion from members on this list about
>>>>>
>>>discovery
>>>
>>>
>>>
>>>>of
>>>>
>>>>
>>>>
>>>>>>CRL signer's certificate in non directory centric environments.
>>>>>>
>>>>>>The problem is the following.
>>>>>>
>>>>>>The relying party (RP) needs to check validity of a certificate and
>>>>>
>>>>finds
>>>>
>>>>
>>>>
>>>>>>a
>>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL 
>>>>>>which
>>>>>
>>>in
>>>
>>>
>>>
>>>>>>this
>>>>>>particular case is either signed by another key of the CA (re-keyed
>>>>>
>>>CA)
>>>
>>>
>>>
>>>>or
>>>>
>>>>
>>>>
>>>>>>another entity (indirect CRL).
>>>>>>
>>>>>>In this case the relying party needs to obtain the certificate of
>>>>>
>>>the
>>>
>>>
>>>
>>>>CRL
>>>>
>>>>
>>>>
>>>>>>signer which may NOT be part of the original chain. In a directory
>>>>>
>>>>centric
>>>>
>>>>
>>>>
>>>>>>solution this is retrieved from the directory, but what if such
>>>>>
>>>>directory
>>>>
>>>>
>>>>
>>>>>>is
>>>>>>not available or accessible.
>>>>>>
>>>>>>The RP have thus no hint where to find the CRL issuers certificate
>>>>>
>>>>unless
>>>>
>>>>
>>>>
>>>>>>the RP already have possession of it by some other means.
>>>>>>
>>>>>>Is seems that CRLs would need an AIA extension with the option to
>>>>>
>>>point
>>>
>>>
>>>
>>>>to
>>>>
>>>>
>>>>
>>>>>>the location of the signers certificate in the same manner as is
>>>>>
>>>>possible
>>>>
>>>>
>>>>
>>>>>>for certificates.
>>>>>>
>>>>>>Maybe AIA should be defined as both cert and CRL extension and not
>>>>>
>>>only
>>>
>>>
>>>
>>>>>>certificate extension as today.
>>>>>>
>>>>>>Thoughts and comments?
>>>>>>
>>>>>>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 i9EDATAD081710; Thu, 14 Oct 2004 06:10:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EDAT5c081709; Thu, 14 Oct 2004 06:10:29 -0700 (PDT)
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 i9EDAS08081703 for <[e-mail]>; Thu, 14 Oct 2004 06:10:28 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (PPP-219.65.48.115.mum2.vsnl.net.in [219.65.48.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9EDAEfn022204 for <[e-mail]>; Thu, 14 Oct 2004 09:10:24 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Thu, 14 Oct 2004 09:10:09 -0400
Message-ID: <003601c4b1ef$2bb55260$[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 i9EDAT08081704
Sender: [e-mail]
Precedence: 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:

With the three assumptions/constraints I provided, how would you locate the
CRL issuer certificate for the two examples using 3280 extensions and
without putting AIA in the CRL?

That is my point.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, October 14, 2004 6:22 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs


Santosh,

You misread my request. I said:

"For the time being, I would like that you provide an example where, when
using the current extensions that are defined in RFC 3280, it will NOT be
possible to locate a CRL Issuer certificate."

Maybe I would have needed to be clearer and say :

"For the time being, I would like that you provide an example where, when
using ANY OF the current extensions that are defined in RFC 3280, it will 
NOT be possible to locate a CRL Issuer certificate."

The examples you provide below do not fulfil this request.

The assumption is that there exists a path to be tested for revocation 
checking (and that it does not matter to know which way it has been 
constructed).

I am not saying that using AIA in CRL might not be useful, but I am still 
lacking the demonstration that there would be no other way.

Denis


> Denis:
> 
> Two examples are very simple: one for direct CRL Issuer and one for 
> Indirect CRL Issuer.
> 
> Let us make the following assumptions that Stefan was making:
> 
> 1.  You are directory challenged; and
> 2.  You use AIA to develop the path; and
> 3.  You develop the path from the end entity to trust anchor.
> 
> From what I know of MS CAPI, these are reasonable 
> assumptions/constraints.
> 
> Now the examples.
> 
> Example 1: Direct CRL Issuer
> 
> The certificate trust path is:
> Root --> CA1 --> CA 2, old key --> Denis
> 
> The CRL trust path is:
> Root --> CA1 --> CA 2, new key --> CRL
> 
> (Note: We do not do self-issued certificate since there is no simple, 
> secure way to check their revocation status).
> 
> Now, with AIA in CRL, finding the CA2, new key certificate is 
> straightforward.  How would you find it if you do no deal with SIA et. 
> al.
> 
> Example 2: Indirect CRL Issuer
> 
> The certificate trust path is:
> Root --> CA1 --> CA 2 --> Denis
> (Note: Denis's certificate points to CRL DP of an indirect CRL issued 
> by CAI.
> 
> The CRL trust path is:
> Root --> CAI --> CRL
> 
> Now, with AIA in CRL, finding the CAI certificate is straightforward.  
> How would you find it if you do no deal with SIA et. al.
> 
> In addition to the need cited above, please note that the extension 
> semantics does not change, it does not hinder any interoperability, 
> and it does not break any backward compatibility.  So, what if I 
> wanted to use this extension in the CRL.  It does no harm to other 
> relying parties.
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Denis Pinkas
> Sent: Wednesday, October 13, 2004 11:01 AM
> To: Stefan Santesson
> Cc: Santosh Chokhani; pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> 
> Stefan,
> 
> 
>>Denis,
> 
> 
>>I'm not sure what you mean.
> 
> 
> For the time being, I would like that you provide an example where, 
> when
> using the current extensions that are defined in RFC 3280, it will NOT be 
> possible to locate a CRL Issuer certificate.
> 
> If you are able to provide that example, then it would justify the 
> need for
> an extension at least for one case. Then we can see what that case is.
> 
> I am awaiting that example.
> 
> Denis
> 
> 
> 
>>I conclude that I agree with Santosh.
>>
>>The debate is still open... Feel free to express your opinion.
>>
>>Stefan Santesson
>>Microsoft Security Center of Excellence (SCOE)
>> 
>>
>>
>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[e-mail]]
>>>Sent: den 13 oktober 2004 16:34
>>>To: Stefan Santesson
>>>Cc: Santosh Chokhani; pkix
>>>Subject: Re: Signer certificate discovery for CRLs
>>>
>>>Stefan,
>>>
>>>You are making a conclusion without letting me the time to respond. I 
>>>will need more time to look at the pictures (and understand them).
>>>
>>>For the time being, I am still reluctant to accept
>>
>>"yet-another-method".
>>
>>
>>>We already have too many.
>>>
>>>
>>>
>>>>Santosh,
>>>>
>>>>I conclude that we are in complete and total agreement.
>>>>The question is how to go about this.
>>>
>>>>Could we do this amendment to RFC 3280 in its next revision? It 
>>>>would hopefully just be a minor change.
>>>
>>>This is exactly what I feared.
>>>
>>>We usually end-up with a "minor change" in an extension without 
>>>saying cleary how and when it shall/should be used.
>>>
>>>I still have in mind that:
>>>
>>> 1) a certification path must first be constructed,
>>> 2) then the revocation checking of that path must be done.
>>>
>>>This means that information about CRL issuers certificates locations
>>
>>may
>>
>>
>>>certainly be found in that chain. If not, I would like an example.
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>>It would not change the definition of AIA just add that it can be
>>>
>>used
>>
>>
>>>also as CRL extension and list eventual restrictions and guidance for
>>
>>use
>>
>>
>>>with CRLs.
>>>
>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [e-mail]
>>>>
>>[mailto:[e-mail]]
>>
>>
>>>>>On Behalf Of Santosh Chokhani
>>>>>Sent: den 13 oktober 2004 04:33
>>>>>To: 'pkix'
>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>
>>>>>
>>>>>Stefan:
>>>>>
>>>>>In terms of certificate discovery, your proposal for AIA in CRL is
>>>>
>>more
>>
>>
>>>>>robust.  The whole idea of self-issued key rollover certificates 
>>>>>and
>>>>
>>>then
>>>
>>>
>>>>>using the new key to issue CRL is fraught with security problems.  
>>>>>A secure solution would be one where the new key is certified by 
>>>>>the parent
>>>>
>>CA.
>>
>>
>>>In
>>>
>>>
>>>>>that case to obtain the new certificate, you could use AIA in CRL.
>>>>>
>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in 
>>>>>certificate in question points to the indirect CRL.  You get that 
>>>>>CRL.  The AIA
>>>>
>>in
>>
>>
>>>CRL
>>>
>>>
>>>>>gets you started for the indirect CRL issuer certification path and
>>>>
>>you
>>
>>
>>>>>are
>>>>>in business.
>>>>>
>>>>>-----Original Message-----
>>>>>From: [e-mail]
>>>>
>>[mailto:[e-mail]]
>>
>>
>>>>>On
>>>>>Behalf Of Stefan Santesson
>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>To: David A. Cooper
>>>>>Cc: pkix
>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>
>>>>>
>>>>>
>>>>>David,
>>>>>
>>>>>Thanks for the clarifications, they make sense.
>>>>>I did misread your pictures.
>>>>>
>>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>>
>>3280,
>>
>>
>>>>>either the CRL issuer certificate itself, or the location of the 
>>>>>CRL issuer certificate, will be clearly identified/available for 
>>>>>the validating
>>>>
>>>party
>>>
>>>
>>>>>in some cases, but not in others?
>>>>>
>>>>>Can we also conclude that there is no real discovery solution for
>>>>
>>>indirect
>>>
>>>
>>>>>CRLs?
>>>>>
>>>>>Do you then agree then that it could be appropriate to allow AIA as
>>>>
>>a
>>
>>
>>>CRL
>>>
>>>
>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>________________________________________
>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>Sent: den 12 oktober 2004 21:14
>>>>>To: Stefan Santesson
>>>>>Cc: pkix
>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>
>>>>>Stefan,
>>>>>
>>>>>I believe that you are misinterpreting the figures.  They really do 
>>>>>represent three different cases, not three different certification
>>>>
>>paths
>>
>>
>>>>>that have been constructed through the same PKI architecture.
>>>>>
>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>
>>certificates.
>>
>>
>>>>>The
>>>>>Root CA has issued a certificate to CA 1's new key, but not its old
>>>>
>>key
>>
>>
>>>>>(either the Root CA never issued a certificate to CA 1's old key or
>>>>
>>that
>>
>>
>>>>>certificate has expired).
>>>>>
>>>>>In figure 2, CA 2 has also generated self-issued key rollover 
>>>>>certificates. The Root CA has issued a certificate to CA 2's old 
>>>>>key, but not its
>>>>
>>new
>>
>>
>>>>>key.
>>>>>
>>>>>In figure 3, when CA 3 performed key rollover, it requested a new 
>>>>>CA certificate from the Root CA.  CA 3 did not generated 
>>>>>self-issued
>>>>
>>key
>>
>>
>>>>>rollover certificates.
>>>>>
>>>>>Of course, another realistic scenario would be one in which a CA
>>>>
>>>generated
>>>
>>>
>>>>>self-issued key rollover certificates upon key rollover and then 
>>>>>had
>>>>
>>the
>>
>>
>>>>>Root CA issue a CA certificate to its new key.  In this case, as 
>>>>>you suggest, any of the certification paths from figures 1, 2, or 3
>>>>
>>could be
>>
>>
>>>>>constructed.
>>>>>
>>>>>As for the contents of the AIA extension, here is what I have
>>>>
>>specified
>>
>>
>>>in
>>>
>>>
>>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>>
>>>Policy":
>>>
>>>
>>>>>The authorityInfoAccess extension uses URIs for two purposes. When
>>>>
>>the
>>
>>
>>>>>id-ad-caIssuers access method is used, the access location 
>>>>>specifies
>>>>
>>>where
>>>
>>>
>>>>>certificates issued to the issuer of the certificate may be found.
>>>>
>>If
>>
>>
>>>LDAP
>>>
>>>
>>>>>is used, the URI must include the DN of the entry containing the
>>>>
>>>relevant
>>>
>>>
>>>>>certificates and specify the directory attribute in which the
>>>>
>>>certificates
>>>
>>>
>>>>>are located. If the directory in which the certificates are stored
>>>>
>>>expects
>>>
>>>
>>>>>the "binary" option to be specified, then the attribute type must 
>>>>>be followed by ";binary" in the URI. If HTTP is used, the URI must
>>>>
>>point to
>>
>>
>>>a
>>>
>>>
>>>>>file that has an extension of ".p7c" that contains a certs-only CMS 
>>>>>message (see RFC 2633). The CMS message should include all 
>>>>>certificates
>>>>
>>issued
>>
>>
>>>to
>>>
>>>
>>>>>the issuer of this certificate, but must at least contain all
>>>>
>>>certificates
>>>
>>>
>>>>>issued to the issuer of this certificate in which the subject 
>>>>>public
>>>>
>>key
>>
>>
>>>>>may
>>>>>be used to verify the signature on this certificate. .... For a 
>>>>>certificate issued by "Good CA", some examples of URIs that may 
>>>>>appear as the
>>>>
>>access
>>
>>
>>>>>location in an authorityInfoAccess extension when the
>>>>
>>id-ad-caIssuers
>>
>>
>>>>>access
>>>>>method is used are:
>>>>
>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACer
>>>>t
>>>>i
>>>
>>fi
>>
>>
>>>ca
>>>
>>>
>>>>>te
>>>>>,crossCertificatePair
>>>>
>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifi
>>>>c
>>>>a
>>>
>>te
>>
>>
>>>;b
>>>
>>>
>>>>>in
>>>>>ary,crossCertificatePair;binary
>>>>
>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssu
>>>>e
>>>>d
>>>
>>To
>>
>>
>>>Go
>>>
>>>
>>>>>od
>>>>>CA.p7c
>>>>>For both LDAP and HTTP, the URI provides the exact location where 
>>>>>information is to be located, so there is no requirement for the
>>>>
>>relying
>>
>>
>>>>>party to try to figure out where information is located.
>>>>>
>>>>>The HTTP URI points to a certs-only CMS message that includes all 
>>>>>certificates issued to the CA identified in the issuer field of the 
>>>>>certificate.
>>>>>
>>>>>The LDAP URI points to the cACertificate and crossCertificatePair 
>>>>>attributes of the directory entry of the CA identified in the 
>>>>>issuer field of
>>>>
>>the
>>
>>
>>>>>certificate.  These two attributes together hold all of the
>>>>
>>certificates
>>
>>
>>>>>issued to the CA:  the cACertificate attribute holds the CA's self-
>>>>
>>>issued
>>>
>>>
>>>>>certificates and the crossCertificatePair attribute holds the 
>>>>>cross-certificates issued to the CA by other CAs.
>>>>>
>>>>>Dave
>>>>>
>>>>>
>>>>>Stefan Santesson wrote:
>>>>>
>>>>>David,
>>>>>
>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>
>>>>>I have some comments and questions on this.
>>>>>
>>>>>First of all we can conclude that in some scenarios (figure 1) 
>>>>>where
>>>>
>>a
>>
>>
>>>>>self
>>>>>issued certificate is inserted into the path, you are likely to 
>>>>>find
>>>>
>>the
>>
>>
>>>>>CRL
>>>>>issuer cert in the path. (given that the new CA have a common key
>>>>
>>and
>>
>>
>>>>>certificate for cert signing and CRL signing).
>>>>>
>>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>>
>>>different
>>>
>>>
>>>>>path building strategies. An application that has access locally to
>>>>
>>all
>>
>>
>>>>>chaining options may however still choose path 2 for the certs and
>>>>
>>path
>>
>>
>>>1
>>>
>>>
>>>>>for the CRL independent of each other (which I think figure 3 tries
>>>>
>>to
>>
>>
>>>>>describe)
>>>>>
>>>>>Another comment is the structure of AIA extensions. The use I'm
>>>>
>>familiar
>>
>>
>>>>>with doesn't use AIA to describe a directory entry where it is left
>>>>
>>to
>>
>>
>>>the
>>>
>>>
>>>>>validation application logic to be intelligent enough to find
>>>>
>>>appropriate
>>>
>>>
>>>>>certificate data from the directory. The model I'm familiar with is
>>>>
>>when
>>
>>
>>>>>the
>>>>>AIA URL explicitly identifies the exact location of the appropriate
>>>>
>>CA
>>
>>
>>>>>certificate file, relieving the validation software from complex 
>>>>>information queries. If just location of explicit certificate files 
>>>>>are
>>>>
>>identified
>>
>>
>>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>>
>>signer
>>
>>
>>>>>cert
>>>>>if this is different from the CA certificate. This is also the
>>>>
>>problem
>>
>>
>>>>>with
>>>>>Denis proposal.
>>>>>
>>>>>I think we share the basic conclusion that the ability to locate 
>>>>>the
>>>>
>>CRL
>>
>>
>>>>>signer certificate directly through the CRL could be very useful. 
>>>>>At
>>>>
>>>least
>>>
>>>
>>>>>in the case of indirect CRL but it could also be proven very useful
>>>>
>>in
>>
>>
>>>CA
>>>
>>>
>>>>>re-keying scenarios.
>>>>>
>>>>>The easiest solution would probably be to allow AIA to be used in
>>>>
>>its
>>
>>
>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>
>>critical).
>>
>>
>>>It
>>>
>>>
>>>>>would present a very clear and uncomplicated logic to certificate 
>>>>>validating applications in many cases.
>>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>________________________________________
>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>Sent: den 7 oktober 2004 18:35
>>>>>To: Stefan Santesson
>>>>>Cc: pkix
>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>
>>>>>Stefan,
>>>>>
>>>>>I think what you are proposing is a good idea.  In most cases, path 
>>>>>discovery algorithms assume that both the trust anchor (or trust
>>>>
>>>anchors)
>>>
>>>
>>>>>and the end entity certificate are provided as input.  In this 
>>>>>case,
>>>>
>>one
>>
>>
>>>>>may
>>>>>need to construct a certification path without a priori access to
>>>>
>>the
>>
>>
>>>end
>>>
>>>
>>>>>entity certificate (the one with the subject public key
>>>>
>>corresponding to
>>
>>
>>>>>the
>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>
>>pointer) in
>>
>>
>>>>>the
>>>>>CRL would provide the relying party with a simple way to obtain the
>>>>
>>end
>>
>>
>>>>>entity certificate for the CRL signing key's certification path. On
>>>>
>>the
>>
>>
>>>>>other hand, I believe that a relying party should be able to
>>>>
>>construct
>>
>>
>>>the
>>>
>>>
>>>>>certification path even without an AIA extension in the CRL, so 
>>>>>long
>>>>
>>as
>>
>>
>>>it
>>>
>>>
>>>>>is not an indirect CRL.  Attached is a drawing of the three basic 
>>>>>scenarios that I expect a relying party may encounter:
>>>>>
>>>>>In each of these scenarios, the CA has performed key rollover and 
>>>>>is
>>>>
>>>only
>>>
>>>
>>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>>
>>>however,
>>>
>>>
>>>>>if
>>>>>the CA simply choose to use different keys to sign certificates and
>>>>
>>CRLs
>>
>>
>>>>>for
>>>>>some other reason.
>>>>>
>>>>>If the PKI architecture resembled figure 1, then the certification
>>>>
>>path
>>
>>
>>>>>for
>>>>>the CRL signing key would just be a subset of the certification 
>>>>>path
>>>>
>>for
>>
>>
>>>>>the
>>>>>EE certificate, so no addition path discovery would be needed.
>>>>>
>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>
>>necessary
>>
>>
>>>to
>>>
>>>
>>>>>obtain the new-signed-with-old self-issued certificate.  In 
>>>>>building
>>>>
>>the
>>
>>
>>>>>certification path to the EE certificate, however, the relying 
>>>>>party
>>>>
>>>will
>>>
>>>
>>>>>obtain the certificates pointed to by the AIA extension in the EE 
>>>>>certificate.  This AIA extension will point to a location 
>>>>>containing
>>>>
>>all
>>
>>
>>>>>certificates issued to CA 2, which would include both the
>>>>
>>certificate
>>
>>
>>>>>issued
>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
>>>>
>>though
>>
>>
>>>>>the
>>>>>self-issued certificate would not be part of the certification path
>>>>
>>to
>>
>>
>>>the
>>>
>>>
>>>>>EE certificate, it would be downloaded by the relying party during
>>>>
>>the
>>
>>
>>>>>construction of that certification path.  (Yes, there are circular 
>>>>>dependency issues in figure 2, but that is another issue.)
>>>>>
>>>>>A similar situation would happen if the PKI architecture resembled
>>>>
>>>figure
>>>
>>>
>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>
>>location
>>
>>
>>>>>containing certificates issued to CA 3.  When the relying party
>>>>
>>>downloaded
>>>
>>>
>>>>>these certificates, it would obtain both of the certificates issued
>>>>
>>by
>>
>>
>>>the
>>>
>>>
>>>>>Root to CA 3 and so again would have the certificate needed to
>>>>
>>validate
>>
>>
>>>>>the
>>>>>CRL signing key.
>>>>>
>>>>>In the case of an indirect CRL, things may not work as well.  If
>>>>
>>>indirect
>>>
>>>
>>>>>CRLs were used, and the PKI architecture resembled figures 2 or 3 
>>>>>(replacing "New Key" with a different CA), then the set of 
>>>>>certificates pointed
>>>>
>>to
>>
>>
>>>by
>>>
>>>
>>>>>the AIA extension in the EE certificate would not include the
>>>>
>>>certificate
>>>
>>>
>>>>>of
>>>>>the CRL signer.  One could find this certificate by building in the 
>>>>>reverse direction and using the SIA extension, but that may not be 
>>>>>the most convenient solution.
>>>>>
>>>>>So, when indirect CRLs are being used, it seems that it would be
>>>>
>>very
>>
>>
>>>>>useful
>>>>>to have a pointer in the CRL to the CRL signing certificate.  When
>>>>
>>the
>>
>>
>>>CRL
>>>
>>>
>>>>>is not indirect, the need for this pointer does not seem to be as
>>>>
>>clear,
>>
>>
>>>>>but
>>>>>I can't see any harm in including it.
>>>>>
>>>>>Dave
>>>>>
>>>>>Stefan Santesson wrote:
>>>>>All,
>>>>>
>>>>>I'm interested in the opinion from members on this list about
>>>>
>>discovery
>>
>>
>>>of
>>>
>>>
>>>>>CRL signer's certificate in non directory centric environments.
>>>>>
>>>>>The problem is the following.
>>>>>
>>>>>The relying party (RP) needs to check validity of a certificate and
>>>>
>>>finds
>>>
>>>
>>>>>a
>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL 
>>>>>which
>>>>
>>in
>>
>>
>>>>>this
>>>>>particular case is either signed by another key of the CA (re-keyed
>>>>
>>CA)
>>
>>
>>>or
>>>
>>>
>>>>>another entity (indirect CRL).
>>>>>
>>>>>In this case the relying party needs to obtain the certificate of
>>>>
>>the
>>
>>
>>>CRL
>>>
>>>
>>>>>signer which may NOT be part of the original chain. In a directory
>>>>
>>>centric
>>>
>>>
>>>>>solution this is retrieved from the directory, but what if such
>>>>
>>>directory
>>>
>>>
>>>>>is
>>>>>not available or accessible.
>>>>>
>>>>>The RP have thus no hint where to find the CRL issuers certificate
>>>>
>>>unless
>>>
>>>
>>>>>the RP already have possession of it by some other means.
>>>>>
>>>>>Is seems that CRLs would need an AIA extension with the option to
>>>>
>>point
>>
>>
>>>to
>>>
>>>
>>>>>the location of the signers certificate in the same manner as is
>>>>
>>>possible
>>>
>>>
>>>>>for certificates.
>>>>>
>>>>>Maybe AIA should be defined as both cert and CRL extension and not
>>>>
>>only
>>
>>
>>>>>certificate extension as today.
>>>>>
>>>>>Thoughts and comments?
>>>>>
>>>>>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 i9ED4bVI081028; Thu, 14 Oct 2004 06:04:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ED4bMO081027; Thu, 14 Oct 2004 06:04:37 -0700 (PDT)
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 i9ED4a2a081002 for <[e-mail]>; Thu, 14 Oct 2004 06:04:36 -0700 (PDT) (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 i9ED4TF10075 for <[e-mail]>; Thu, 14 Oct 2004 15:04:29 +0200
Message-ID: <[e-mail]>
Date: Thu, 14 Oct 2004 15:04:28 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040818
X-Accept-Language: fr, en-us, en, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Effect of adding an attribute to CSR
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>

Puneet kumar wrote:

> We recently received a CSR from a new CA.We added the attribute "cn" 
> to the dn of the CSR (as this is a requirement at our end) and then 
> issued the cert. [...]
>  
> 1.Does adding an attribute to the CSR make any difference towards the 
> acceptability of the cert?

I don't believe any of the IETF standards tries to cover this point, and 
to say explicitly what is the right thing to do in such a situation.
It can be considered a local decision.
This said the CMC RFC 2797 does describe a case where the request 
subject DN is null, and where the CA will generate the correct DN.

Generally talking the format for CSR request enables to requester to 
include many elements, and the CA will have security reasons to filter 
them and keep only what it considers valid.
CA definitively can not accept the elements in request directly, and 
have to either reject requests that don't conform or correct them.

They are many examples on the market of CA that will reformat the DN of 
request, or simply ignore it and use other source to generate the DN of 
the certificate.
They are good reasons for a CA to normalise the DN in input in order to 
avoid problems, some request generating softwares don't put the DN 
component in the normal order, or use invalid string type.
Also if the CA wants to conform fully to RFC3290, it should only emit 
certificate with UTF8String encoding since december 31, 2003.
That's another case where a CA may consider the best solution is to 
reencode in UTF8String format all request before emitting the cert.

> 2.What options do we have at our end..I mean do we need to revoke the 
> cert? Can we re-certify the cert? Actually I did'nt find the term 
> re-certify in any standardd..certs are either revoked or get 
> expired.Your Comments would be most welcome.

It seems to me the easiest solution is to revoke the cert, and ask the 
CA to submit you another request that conforms to your policy for CA's 
DN naming.
When they send you a request that includes a CN, you will not have to 
modify it before emitting the cert and everything will work correctly.

> 3.Is their any setting changes that can be done in the Entrust CA 
> softwrae to allow this cert with the changed distinguished name to be 
> accepted?

That is a question to ask to that specific vendor.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ECJ6jJ075143; Thu, 14 Oct 2004 05:19:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ECJ6Es075142; Thu, 14 Oct 2004 05:19:06 -0700 (PDT)
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 i9ECJ5IM075123 for <[e-mail]>; Thu, 14 Oct 2004 05:19:05 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 6652A3476B; Fri, 15 Oct 2004 01:19:04 +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 22310-11; Fri, 15 Oct 2004 01:19:04 +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 4EB773476A; Fri, 15 Oct 2004 01:19:04 +1300 (NZDT)
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 265AB37750; Fri, 15 Oct 2004 01:19:04 +1300 (NZDT)
Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CI4Zc-0004fC-00; Fri, 15 Oct 2004 01:19:12 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Effect of adding an attribute to CSR
In-Reply-To: <[e-mail]>
Message-Id: <E1CI4Zc-0004fC-00@medusa01>
Date: Fri, 15 Oct 2004 01:19:12 +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>

Puneet kumar <[e-mail]> writes:

>We recently received a CSR from a new CA.We added the attribute "cn" to the
>dn of the CSR (as this is a requirement at our end) and then issued the
>cert.Now the CA's software is not accpeting the cert and they say that its
>because we added the cn attribute.We are using a softwrae by Smarttrust (CM)
>and the CA has an Entrust s/w.
>
>Now I have the following queries
>
>1.Does adding an attribute to the CSR make any difference towards the
>acceptability of the cert?

You mean the CA adding an attribute to the cert that isn't in the PKCS #10?
No, not at all, in fact it's quite standard.

>2.What options do we have at our end..I mean do we need to revoke the cert?
>Can we re-certify the cert? 

If you're the CA, it's really up to you.  If it's been explicitly rejected by
the client, I'd revoke it.

>3.Is their any setting changes that can be done in the Entrust CA softwrae to
>allow this cert with the changed distinguished name to be accepted?

You'd have to ask Entrust that.

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 i9EBQixG067815; Thu, 14 Oct 2004 04:26:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EBQilZ067814; Thu, 14 Oct 2004 04:26:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from web50406.mail.yahoo.com (web50406.mail.yahoo.com [206.190.38.71]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9EBQiPX067796 for <[e-mail]>; Thu, 14 Oct 2004 04:26:44 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Received: from [203.200.100.193] by web50406.mail.yahoo.com via HTTP; Thu, 14 Oct 2004 04:26:40 PDT
Date: Thu, 14 Oct 2004 04:26:40 -0700 (PDT)
From: Puneet kumar <[e-mail]>
Subject: Effect of adding an attribute to CSR
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-164744117-1097753200=:22307"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0-164744117-1097753200=:22307
Content-Type: text/plain; charset=us-ascii

Dear all,
      I need some assistance on a peculiar problem we are facing. 
 
      We are an organisation which acts as the TTP for all CA's operating in our country ,ie, we are the Root CA. So whenverea new CA comes up they send us a CSR (in PKCS#10) which we sign and give back a X.509 base 64 Certificate.
 
We recently received a CSR from a new CA.We added the attribute "cn" to the dn of the CSR (as this is a requirement at our end) and then issued the cert.Now the CA's software is not accpeting the cert and they say that its because we added the cn attribute.We are using a softwrae by Smarttrust (CM)and the CA has an Entrust s/w.
 
Now I have the following queries
 
1.Does adding an attribute to the CSR make any difference towards the acceptability of the cert?
 
2.What options do we have at our end..I mean do we need to revoke the cert? Can we re-certify the cert? Actually I did'nt find the term re-certify in any standardd..certs are either revoked or get expired.Your Comments would be most welcome.
 
3.Is their any setting changes that can be done in the Entrust CA softwrae to allow this cert with the changed distinguished name to be accepted?
 
Request feedback from you guys..
 
Thanks
2.

		
---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!
--0-164744117-1097753200=:22307
Content-Type: text/html; charset=us-ascii

<DIV>Dear all,</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I need some assistance on a peculiar problem we are facing. </DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;We are an organisation which acts as the&nbsp;TTP for all CA's operating in our country&nbsp;,ie, we are the Root CA. So whenverea new CA comes up they send us a CSR (in PKCS#10) which we sign and give back a X.509 base 64 Certificate.</DIV>
<DIV>&nbsp;</DIV>
<DIV>We recently received a CSR from a new CA.We added the attribute "cn" to the dn of the CSR (as this is a requirement at our end)&nbsp;and then issued the cert.Now the CA's software is not accpeting the cert and they say that its because we added the cn attribute.We are using a softwrae by Smarttrust (CM)and the CA has an Entrust s/w.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Now I have the following queries</DIV>
<DIV>&nbsp;</DIV>
<DIV>1.Does adding an attribute to the CSR make any difference towards the acceptability of the cert?</DIV>
<DIV>&nbsp;</DIV>
<DIV>2.What options do we have at our end..I mean do we need to revoke the cert? Can we re-certify the cert? Actually I did'nt find the term re-certify in any standardd..certs are either revoked or get expired.Your Comments would be most welcome.</DIV>
<DIV>&nbsp;</DIV>
<DIV>3.Is their any setting changes that can be done in the Entrust CA softwrae to allow this cert with the changed&nbsp;distinguished name to be accepted?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Request feedback from you guys..</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks</DIV>
<DIV>2.</DIV><p>
		<hr size=1>Do you Yahoo!?<br><a
href="http://vote.yahoo.com">vote.yahoo.com</a> - Register online to vote today!
--0-164744117-1097753200=:22307--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EANi0Q044825; Thu, 14 Oct 2004 03:23:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EANiVf044824; Thu, 14 Oct 2004 03:23:44 -0700 (PDT)
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 i9EANgPK044774 for <[e-mail]>; Thu, 14 Oct 2004 03:23:43 -0700 (PDT) (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 MAA49262; Thu, 14 Oct 2004 12:35:02 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101412232115:874 ; Thu, 14 Oct 2004 12:23:21 +0200 
Message-ID: <[e-mail]>
Date: Thu, 14 Oct 2004 12:21:37 +0200
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: <00b601c4b16e$d2aeda90$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 14/10/2004 12:23:21, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 14/10/2004 12:23:23, Serialize complete at 14/10/2004 12:23:23
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,

You misread my request. I said:

"For the time being, I would like that you provide an example where, when
using the current extensions that are defined in RFC 3280, it will NOT be
possible to locate a CRL Issuer certificate."

Maybe I would have needed to be clearer and say :

"For the time being, I would like that you provide an example where, when
using ANY OF the current extensions that are defined in RFC 3280, it will 
NOT be possible to locate a CRL Issuer certificate."

The examples you provide below do not fulfil this request.

The assumption is that there exists a path to be tested for revocation 
checking (and that it does not matter to know which way it has been 
constructed).

I am not saying that using AIA in CRL might not be useful, but I am still 
lacking the demonstration that there would be no other way.

Denis


> Denis:
> 
> Two examples are very simple: one for direct CRL Issuer and one for Indirect
> CRL Issuer.
> 
> Let us make the following assumptions that Stefan was making:
> 
> 1.  You are directory challenged; and
> 2.  You use AIA to develop the path; and
> 3.  You develop the path from the end entity to trust anchor.
> 
> From what I know of MS CAPI, these are reasonable assumptions/constraints.
> 
> Now the examples.
> 
> Example 1: Direct CRL Issuer
> 
> The certificate trust path is:
> Root --> CA1 --> CA 2, old key --> Denis
> 
> The CRL trust path is:
> Root --> CA1 --> CA 2, new key --> CRL
> 
> (Note: We do not do self-issued certificate since there is no simple, secure
> way to check their revocation status).
> 
> Now, with AIA in CRL, finding the CA2, new key certificate is
> straightforward.  How would you find it if you do no deal with SIA et. al.
> 
> Example 2: Indirect CRL Issuer
> 
> The certificate trust path is:
> Root --> CA1 --> CA 2 --> Denis
> (Note: Denis's certificate points to CRL DP of an indirect CRL issued by
> CAI.
> 
> The CRL trust path is:
> Root --> CAI --> CRL
> 
> Now, with AIA in CRL, finding the CAI certificate is straightforward.  How
> would you find it if you do no deal with SIA et. al.
> 
> In addition to the need cited above, please note that the extension
> semantics does not change, it does not hinder any interoperability, and it
> does not break any backward compatibility.  So, what if I wanted to use this
> extension in the CRL.  It does no harm to other relying parties.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Denis Pinkas
> Sent: Wednesday, October 13, 2004 11:01 AM
> To: Stefan Santesson
> Cc: Santosh Chokhani; pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> 
> Stefan,
> 
> 
>>Denis,
> 
> 
>>I'm not sure what you mean.
> 
> 
> For the time being, I would like that you provide an example where, when 
> using the current extensions that are defined in RFC 3280, it will NOT be 
> possible to locate a CRL Issuer certificate.
> 
> If you are able to provide that example, then it would justify the need for 
> an extension at least for one case. Then we can see what that case is.
> 
> I am awaiting that example.
> 
> Denis
> 
> 
> 
>>I conclude that I agree with Santosh.
>>
>>The debate is still open... Feel free to express your opinion.
>>
>>Stefan Santesson
>>Microsoft Security Center of Excellence (SCOE)
>> 
>>
>>
>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[e-mail]]
>>>Sent: den 13 oktober 2004 16:34
>>>To: Stefan Santesson
>>>Cc: Santosh Chokhani; pkix
>>>Subject: Re: Signer certificate discovery for CRLs
>>>
>>>Stefan,
>>>
>>>You are making a conclusion without letting me the time to respond. I
>>>will need more time to look at the pictures (and understand them).
>>>
>>>For the time being, I am still reluctant to accept
>>
>>"yet-another-method".
>>
>>
>>>We already have too many.
>>>
>>>
>>>
>>>>Santosh,
>>>>
>>>>I conclude that we are in complete and total agreement.
>>>>The question is how to go about this.
>>>
>>>>Could we do this amendment to RFC 3280 in its next revision? It would
>>>>hopefully just be a minor change.
>>>
>>>This is exactly what I feared.
>>>
>>>We usually end-up with a "minor change" in an extension without saying
>>>cleary how and when it shall/should be used.
>>>
>>>I still have in mind that:
>>>
>>> 1) a certification path must first be constructed,
>>> 2) then the revocation checking of that path must be done.
>>>
>>>This means that information about CRL issuers certificates locations
>>
>>may
>>
>>
>>>certainly be found in that chain. If not, I would like an example.
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>>It would not change the definition of AIA just add that it can be
>>>
>>used
>>
>>
>>>also as CRL extension and list eventual restrictions and guidance for
>>
>>use
>>
>>
>>>with CRLs.
>>>
>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [e-mail]
>>>>
>>[mailto:[e-mail]]
>>
>>
>>>>>On Behalf Of Santosh Chokhani
>>>>>Sent: den 13 oktober 2004 04:33
>>>>>To: 'pkix'
>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>
>>>>>
>>>>>Stefan:
>>>>>
>>>>>In terms of certificate discovery, your proposal for AIA in CRL is
>>>>
>>more
>>
>>
>>>>>robust.  The whole idea of self-issued key rollover certificates and
>>>>
>>>then
>>>
>>>
>>>>>using the new key to issue CRL is fraught with security problems.  A
>>>>>secure solution would be one where the new key is certified by the 
>>>>>parent
>>>>
>>CA.
>>
>>
>>>In
>>>
>>>
>>>>>that case to obtain the new certificate, you could use AIA in CRL.
>>>>>
>>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
>>>>>certificate in question points to the indirect CRL.  You get that 
>>>>>CRL.  The AIA
>>>>
>>in
>>
>>
>>>CRL
>>>
>>>
>>>>>gets you started for the indirect CRL issuer certification path and
>>>>
>>you
>>
>>
>>>>>are
>>>>>in business.
>>>>>
>>>>>-----Original Message-----
>>>>>From: [e-mail]
>>>>
>>[mailto:[e-mail]]
>>
>>
>>>>>On
>>>>>Behalf Of Stefan Santesson
>>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>>To: David A. Cooper
>>>>>Cc: pkix
>>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>>
>>>>>
>>>>>
>>>>>David,
>>>>>
>>>>>Thanks for the clarifications, they make sense.
>>>>>I did misread your pictures.
>>>>>
>>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>>
>>3280,
>>
>>
>>>>>either the CRL issuer certificate itself, or the location of the CRL
>>>>>issuer certificate, will be clearly identified/available for the 
>>>>>validating
>>>>
>>>party
>>>
>>>
>>>>>in some cases, but not in others?
>>>>>
>>>>>Can we also conclude that there is no real discovery solution for
>>>>
>>>indirect
>>>
>>>
>>>>>CRLs?
>>>>>
>>>>>Do you then agree then that it could be appropriate to allow AIA as
>>>>
>>a
>>
>>
>>>CRL
>>>
>>>
>>>>>extension to facilitate discovery of CRL signer certificate?
>>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>________________________________________
>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>Sent: den 12 oktober 2004 21:14
>>>>>To: Stefan Santesson
>>>>>Cc: pkix
>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>
>>>>>Stefan,
>>>>>
>>>>>I believe that you are misinterpreting the figures.  They really do
>>>>>represent three different cases, not three different certification
>>>>
>>paths
>>
>>
>>>>>that have been constructed through the same PKI architecture.
>>>>>
>>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>>
>>certificates.
>>
>>
>>>>>The
>>>>>Root CA has issued a certificate to CA 1's new key, but not its old
>>>>
>>key
>>
>>
>>>>>(either the Root CA never issued a certificate to CA 1's old key or
>>>>
>>that
>>
>>
>>>>>certificate has expired).
>>>>>
>>>>>In figure 2, CA 2 has also generated self-issued key rollover
>>>>>certificates. The Root CA has issued a certificate to CA 2's old 
>>>>>key, but not its
>>>>
>>new
>>
>>
>>>>>key.
>>>>>
>>>>>In figure 3, when CA 3 performed key rollover, it requested a new CA
>>>>>certificate from the Root CA.  CA 3 did not generated self-issued
>>>>
>>key
>>
>>
>>>>>rollover certificates.
>>>>>
>>>>>Of course, another realistic scenario would be one in which a CA
>>>>
>>>generated
>>>
>>>
>>>>>self-issued key rollover certificates upon key rollover and then had
>>>>
>>the
>>
>>
>>>>>Root CA issue a CA certificate to its new key.  In this case, as you
>>>>>suggest, any of the certification paths from figures 1, 2, or 3
>>>>
>>could be
>>
>>
>>>>>constructed.
>>>>>
>>>>>As for the contents of the AIA extension, here is what I have
>>>>
>>specified
>>
>>
>>>in
>>>
>>>
>>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>>
>>>Policy":
>>>
>>>
>>>>>The authorityInfoAccess extension uses URIs for two purposes. When
>>>>
>>the
>>
>>
>>>>>id-ad-caIssuers access method is used, the access location specifies
>>>>
>>>where
>>>
>>>
>>>>>certificates issued to the issuer of the certificate may be found.
>>>>
>>If
>>
>>
>>>LDAP
>>>
>>>
>>>>>is used, the URI must include the DN of the entry containing the
>>>>
>>>relevant
>>>
>>>
>>>>>certificates and specify the directory attribute in which the
>>>>
>>>certificates
>>>
>>>
>>>>>are located. If the directory in which the certificates are stored
>>>>
>>>expects
>>>
>>>
>>>>>the "binary" option to be specified, then the attribute type must be
>>>>>followed by ";binary" in the URI. If HTTP is used, the URI must
>>>>
>>point to
>>
>>
>>>a
>>>
>>>
>>>>>file that has an extension of ".p7c" that contains a certs-only CMS
>>>>>message (see RFC 2633). The CMS message should include all 
>>>>>certificates
>>>>
>>issued
>>
>>
>>>to
>>>
>>>
>>>>>the issuer of this certificate, but must at least contain all
>>>>
>>>certificates
>>>
>>>
>>>>>issued to the issuer of this certificate in which the subject public
>>>>
>>key
>>
>>
>>>>>may
>>>>>be used to verify the signature on this certificate. .... For a
>>>>>certificate issued by "Good CA", some examples of URIs that may 
>>>>>appear as the
>>>>
>>access
>>
>>
>>>>>location in an authorityInfoAccess extension when the
>>>>
>>id-ad-caIssuers
>>
>>
>>>>>access
>>>>>method is used are:
>>>>
>>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACert
>>>>i
>>>
>>fi
>>
>>
>>>ca
>>>
>>>
>>>>>te
>>>>>,crossCertificatePair
>>>>
>>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertific
>>>>a
>>>
>>te
>>
>>
>>>;b
>>>
>>>
>>>>>in
>>>>>ary,crossCertificatePair;binary
>>>>
>>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssue
>>>>d
>>>
>>To
>>
>>
>>>Go
>>>
>>>
>>>>>od
>>>>>CA.p7c
>>>>>For both LDAP and HTTP, the URI provides the exact location where
>>>>>information is to be located, so there is no requirement for the
>>>>
>>relying
>>
>>
>>>>>party to try to figure out where information is located.
>>>>>
>>>>>The HTTP URI points to a certs-only CMS message that includes all
>>>>>certificates issued to the CA identified in the issuer field of the 
>>>>>certificate.
>>>>>
>>>>>The LDAP URI points to the cACertificate and crossCertificatePair
>>>>>attributes of the directory entry of the CA identified in the issuer 
>>>>>field of
>>>>
>>the
>>
>>
>>>>>certificate.  These two attributes together hold all of the
>>>>
>>certificates
>>
>>
>>>>>issued to the CA:  the cACertificate attribute holds the CA's self-
>>>>
>>>issued
>>>
>>>
>>>>>certificates and the crossCertificatePair attribute holds the
>>>>>cross-certificates issued to the CA by other CAs.
>>>>>
>>>>>Dave
>>>>>
>>>>>
>>>>>Stefan Santesson wrote:
>>>>>
>>>>>David,
>>>>>
>>>>>Thanks for these good thoughts and very useful scenarios.
>>>>>
>>>>>I have some comments and questions on this.
>>>>>
>>>>>First of all we can conclude that in some scenarios (figure 1) where
>>>>
>>a
>>
>>
>>>>>self
>>>>>issued certificate is inserted into the path, you are likely to find
>>>>
>>the
>>
>>
>>>>>CRL
>>>>>issuer cert in the path. (given that the new CA have a common key
>>>>
>>and
>>
>>
>>>>>certificate for cert signing and CRL signing).
>>>>>
>>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>>
>>>different
>>>
>>>
>>>>>path building strategies. An application that has access locally to
>>>>
>>all
>>
>>
>>>>>chaining options may however still choose path 2 for the certs and
>>>>
>>path
>>
>>
>>>1
>>>
>>>
>>>>>for the CRL independent of each other (which I think figure 3 tries
>>>>
>>to
>>
>>
>>>>>describe)
>>>>>
>>>>>Another comment is the structure of AIA extensions. The use I'm
>>>>
>>familiar
>>
>>
>>>>>with doesn't use AIA to describe a directory entry where it is left
>>>>
>>to
>>
>>
>>>the
>>>
>>>
>>>>>validation application logic to be intelligent enough to find
>>>>
>>>appropriate
>>>
>>>
>>>>>certificate data from the directory. The model I'm familiar with is
>>>>
>>when
>>
>>
>>>>>the
>>>>>AIA URL explicitly identifies the exact location of the appropriate
>>>>
>>CA
>>
>>
>>>>>certificate file, relieving the validation software from complex
>>>>>information queries. If just location of explicit certificate files 
>>>>>are
>>>>
>>identified
>>
>>
>>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>>
>>signer
>>
>>
>>>>>cert
>>>>>if this is different from the CA certificate. This is also the
>>>>
>>problem
>>
>>
>>>>>with
>>>>>Denis proposal.
>>>>>
>>>>>I think we share the basic conclusion that the ability to locate the
>>>>
>>CRL
>>
>>
>>>>>signer certificate directly through the CRL could be very useful. At
>>>>
>>>least
>>>
>>>
>>>>>in the case of indirect CRL but it could also be proven very useful
>>>>
>>in
>>
>>
>>>CA
>>>
>>>
>>>>>re-keying scenarios.
>>>>>
>>>>>The easiest solution would probably be to allow AIA to be used in
>>>>
>>its
>>
>>
>>>>>current shape and structure as a CRL extension (MUST NOT be
>>>>
>>critical).
>>
>>
>>>It
>>>
>>>
>>>>>would present a very clear and uncomplicated logic to certificate
>>>>>validating applications in many cases.
>>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>________________________________________
>>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>>Sent: den 7 oktober 2004 18:35
>>>>>To: Stefan Santesson
>>>>>Cc: pkix
>>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>>
>>>>>Stefan,
>>>>>
>>>>>I think what you are proposing is a good idea.  In most cases, path
>>>>>discovery algorithms assume that both the trust anchor (or trust
>>>>
>>>anchors)
>>>
>>>
>>>>>and the end entity certificate are provided as input.  In this case,
>>>>
>>one
>>
>>
>>>>>may
>>>>>need to construct a certification path without a priori access to
>>>>
>>the
>>
>>
>>>end
>>>
>>>
>>>>>entity certificate (the one with the subject public key
>>>>
>>corresponding to
>>
>>
>>>>>the
>>>>>CRL signing key).  Including an AIA extension (or some other
>>>>
>>pointer) in
>>
>>
>>>>>the
>>>>>CRL would provide the relying party with a simple way to obtain the
>>>>
>>end
>>
>>
>>>>>entity certificate for the CRL signing key's certification path. On
>>>>
>>the
>>
>>
>>>>>other hand, I believe that a relying party should be able to
>>>>
>>construct
>>
>>
>>>the
>>>
>>>
>>>>>certification path even without an AIA extension in the CRL, so long
>>>>
>>as
>>
>>
>>>it
>>>
>>>
>>>>>is not an indirect CRL.  Attached is a drawing of the three basic
>>>>>scenarios that I expect a relying party may encounter:
>>>>>
>>>>>In each of these scenarios, the CA has performed key rollover and is
>>>>
>>>only
>>>
>>>
>>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>>
>>>however,
>>>
>>>
>>>>>if
>>>>>the CA simply choose to use different keys to sign certificates and
>>>>
>>CRLs
>>
>>
>>>>>for
>>>>>some other reason.
>>>>>
>>>>>If the PKI architecture resembled figure 1, then the certification
>>>>
>>path
>>
>>
>>>>>for
>>>>>the CRL signing key would just be a subset of the certification path
>>>>
>>for
>>
>>
>>>>>the
>>>>>EE certificate, so no addition path discovery would be needed.
>>>>>
>>>>>If the PKI architecture resembled figure 1, then it would be
>>>>
>>necessary
>>
>>
>>>to
>>>
>>>
>>>>>obtain the new-signed-with-old self-issued certificate.  In building
>>>>
>>the
>>
>>
>>>>>certification path to the EE certificate, however, the relying party
>>>>
>>>will
>>>
>>>
>>>>>obtain the certificates pointed to by the AIA extension in the EE
>>>>>certificate.  This AIA extension will point to a location containing
>>>>
>>all
>>
>>
>>>>>certificates issued to CA 2, which would include both the
>>>>
>>certificate
>>
>>
>>>>>issued
>>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
>>>>
>>though
>>
>>
>>>>>the
>>>>>self-issued certificate would not be part of the certification path
>>>>
>>to
>>
>>
>>>the
>>>
>>>
>>>>>EE certificate, it would be downloaded by the relying party during
>>>>
>>the
>>
>>
>>>>>construction of that certification path.  (Yes, there are circular
>>>>>dependency issues in figure 2, but that is another issue.)
>>>>>
>>>>>A similar situation would happen if the PKI architecture resembled
>>>>
>>>figure
>>>
>>>
>>>>>3.  The AIA extension in the EE certificate would point to a
>>>>
>>location
>>
>>
>>>>>containing certificates issued to CA 3.  When the relying party
>>>>
>>>downloaded
>>>
>>>
>>>>>these certificates, it would obtain both of the certificates issued
>>>>
>>by
>>
>>
>>>the
>>>
>>>
>>>>>Root to CA 3 and so again would have the certificate needed to
>>>>
>>validate
>>
>>
>>>>>the
>>>>>CRL signing key.
>>>>>
>>>>>In the case of an indirect CRL, things may not work as well.  If
>>>>
>>>indirect
>>>
>>>
>>>>>CRLs were used, and the PKI architecture resembled figures 2 or 3
>>>>>(replacing "New Key" with a different CA), then the set of 
>>>>>certificates pointed
>>>>
>>to
>>
>>
>>>by
>>>
>>>
>>>>>the AIA extension in the EE certificate would not include the
>>>>
>>>certificate
>>>
>>>
>>>>>of
>>>>>the CRL signer.  One could find this certificate by building in the
>>>>>reverse direction and using the SIA extension, but that may not be 
>>>>>the most convenient solution.
>>>>>
>>>>>So, when indirect CRLs are being used, it seems that it would be
>>>>
>>very
>>
>>
>>>>>useful
>>>>>to have a pointer in the CRL to the CRL signing certificate.  When
>>>>
>>the
>>
>>
>>>CRL
>>>
>>>
>>>>>is not indirect, the need for this pointer does not seem to be as
>>>>
>>clear,
>>
>>
>>>>>but
>>>>>I can't see any harm in including it.
>>>>>
>>>>>Dave
>>>>>
>>>>>Stefan Santesson wrote:
>>>>>All,
>>>>>
>>>>>I'm interested in the opinion from members on this list about
>>>>
>>discovery
>>
>>
>>>of
>>>
>>>
>>>>>CRL signer's certificate in non directory centric environments.
>>>>>
>>>>>The problem is the following.
>>>>>
>>>>>The relying party (RP) needs to check validity of a certificate and
>>>>
>>>finds
>>>
>>>
>>>>>a
>>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL which
>>>>
>>in
>>
>>
>>>>>this
>>>>>particular case is either signed by another key of the CA (re-keyed
>>>>
>>CA)
>>
>>
>>>or
>>>
>>>
>>>>>another entity (indirect CRL).
>>>>>
>>>>>In this case the relying party needs to obtain the certificate of
>>>>
>>the
>>
>>
>>>CRL
>>>
>>>
>>>>>signer which may NOT be part of the original chain. In a directory
>>>>
>>>centric
>>>
>>>
>>>>>solution this is retrieved from the directory, but what if such
>>>>
>>>directory
>>>
>>>
>>>>>is
>>>>>not available or accessible.
>>>>>
>>>>>The RP have thus no hint where to find the CRL issuers certificate
>>>>
>>>unless
>>>
>>>
>>>>>the RP already have possession of it by some other means.
>>>>>
>>>>>Is seems that CRLs would need an AIA extension with the option to
>>>>
>>point
>>
>>
>>>to
>>>
>>>
>>>>>the location of the signers certificate in the same manner as is
>>>>
>>>possible
>>>
>>>
>>>>>for certificates.
>>>>>
>>>>>Maybe AIA should be defined as both cert and CRL extension and not
>>>>
>>only
>>
>>
>>>>>certificate extension as today.
>>>>>
>>>>>Thoughts and comments?
>>>>>
>>>>>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 i9E8FQNq091935; Thu, 14 Oct 2004 01:15:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9E8FQHg091934; Thu, 14 Oct 2004 01:15:26 -0700 (PDT)
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 i9E8FOiv091891 for <[e-mail]>; Thu, 14 Oct 2004 01:15:25 -0700 (PDT) (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.0); Thu, 14 Oct 2004 09:15:32 +0100
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: Signer certificate discovery for CRLs
Date: Thu, 14 Oct 2004 09:15:23 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcSxeIEz7TEFs9riT06QD28yf4WceAAS8Bkw
From: "Stefan Santesson" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 14 Oct 2004 08:15:32.0352 (UTC) FILETIME=[F95D2000:01C4B1C5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9E8FPiv091928
Sender: [e-mail]
Precedence: 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 agree to these examples. I only have 1 comment.

MS-CAPI is not constrained to use chain building from leaf to Root
through AIA but it has the capacity to do so. However MS-CAPI has
limited possibilities to find the CRL issuer cert unless it is the one
used to sign the cert checked for revocation, much because there is no
straightforward solution to this problem (as your examples illustrate).

I think this is generally true also for other products in the market
place. It would be interesting to hear other vendors view on this
though.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 13 oktober 2004 23:51
> To: 'pkix'
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> Denis:
> 
> Two examples are very simple: one for direct CRL Issuer and one for
> Indirect
> CRL Issuer.
> 
> Let us make the following assumptions that Stefan was making:
> 
> 1.  You are directory challenged; and
> 2.  You use AIA to develop the path; and
> 3.  You develop the path from the end entity to trust anchor.
> 
> From what I know of MS CAPI, these are reasonable
assumptions/constraints.
> 
> Now the examples.
> 
> Example 1: Direct CRL Issuer
> 
> The certificate trust path is:
> Root --> CA1 --> CA 2, old key --> Denis
> 
> The CRL trust path is:
> Root --> CA1 --> CA 2, new key --> CRL
> 
> (Note: We do not do self-issued certificate since there is no simple,
> secure
> way to check their revocation status).
> 
> Now, with AIA in CRL, finding the CA2, new key certificate is
> straightforward.  How would you find it if you do no deal with SIA et.
al.
> 
> Example 2: Indirect CRL Issuer
> 
> The certificate trust path is:
> Root --> CA1 --> CA 2 --> Denis
> (Note: Denis's certificate points to CRL DP of an indirect CRL issued
by
> CAI.
> 
> The CRL trust path is:
> Root --> CAI --> CRL
> 
> Now, with AIA in CRL, finding the CAI certificate is straightforward.
How
> would you find it if you do no deal with SIA et. al.
> 
> In addition to the need cited above, please note that the extension
> semantics does not change, it does not hinder any interoperability,
and it
> does not break any backward compatibility.  So, what if I wanted to
use
> this
> extension in the CRL.  It does no harm to other relying parties.
> 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On
> Behalf Of Denis Pinkas
> Sent: Wednesday, October 13, 2004 11:01 AM
> To: Stefan Santesson
> Cc: Santosh Chokhani; pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> 
> Stefan,
> 
> > Denis,
> 
> > I'm not sure what you mean.
> 
> For the time being, I would like that you provide an example where,
when
> using the current extensions that are defined in RFC 3280, it will NOT
be
> possible to locate a CRL Issuer certificate.
> 
> If you are able to provide that example, then it would justify the
need
> for
> an extension at least for one case. Then we can see what that case is.
> 
> I am awaiting that example.
> 
> Denis
> 
> 
> > I conclude that I agree with Santosh.
> >
> > The debate is still open... Feel free to express your opinion.
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[e-mail]]
> >>Sent: den 13 oktober 2004 16:34
> >>To: Stefan Santesson
> >>Cc: Santosh Chokhani; pkix
> >>Subject: Re: Signer certificate discovery for CRLs
> >>
> >>Stefan,
> >>
> >>You are making a conclusion without letting me the time to respond.
I
> >>will need more time to look at the pictures (and understand them).
> >>
> >>For the time being, I am still reluctant to accept
> >
> > "yet-another-method".
> >
> >>We already have too many.
> >>
> >>
> >>>Santosh,
> >>>
> >>>I conclude that we are in complete and total agreement.
> >>>The question is how to go about this.
> >>
> >>>Could we do this amendment to RFC 3280 in its next revision? It
would
> >>>hopefully just be a minor change.
> >>
> >>This is exactly what I feared.
> >>
> >>We usually end-up with a "minor change" in an extension without
saying
> >>cleary how and when it shall/should be used.
> >>
> >>I still have in mind that:
> >>
> >>  1) a certification path must first be constructed,
> >>  2) then the revocation checking of that path must be done.
> >>
> >>This means that information about CRL issuers certificates locations
> >
> > may
> >
> >>certainly be found in that chain. If not, I would like an example.
> >>
> >>Denis
> >>
> >>
> >>
> >>>It would not change the definition of AIA just add that it can be
> >>
> > used
> >
> >>also as CRL extension and list eventual restrictions and guidance
for
> >
> > use
> >
> >>with CRLs.
> >>
> >>>
> >>>Stefan Santesson
> >>>Microsoft Security Center of Excellence (SCOE)
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: [e-mail]
> >>>
> > [mailto:[e-mail]]
> >
> >>>>On Behalf Of Santosh Chokhani
> >>>>Sent: den 13 oktober 2004 04:33
> >>>>To: 'pkix'
> >>>>Subject: RE: Signer certificate discovery for CRLs
> >>>>
> >>>>
> >>>>Stefan:
> >>>>
> >>>>In terms of certificate discovery, your proposal for AIA in CRL is
> >>>
> > more
> >
> >>>>robust.  The whole idea of self-issued key rollover certificates
and
> >>>
> >>then
> >>
> >>>>using the new key to issue CRL is fraught with security problems.
A
> >>>>secure solution would be one where the new key is certified by the
> >>>>parent
> >>>
> > CA.
> >
> >>In
> >>
> >>>>that case to obtain the new certificate, you could use AIA in CRL.
> >>>>
> >>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
> >>>>certificate in question points to the indirect CRL.  You get that
> >>>>CRL.  The AIA
> >>>
> > in
> >
> >>CRL
> >>
> >>>>gets you started for the indirect CRL issuer certification path
and
> >>>
> > you
> >
> >>>>are
> >>>>in business.
> >>>>
> >>>>-----Original Message-----
> >>>>From: [e-mail]
> >>>
> > [mailto:[e-mail]]
> >
> >>>>On
> >>>>Behalf Of Stefan Santesson
> >>>>Sent: Tuesday, October 12, 2004 7:30 PM
> >>>>To: David A. Cooper
> >>>>Cc: pkix
> >>>>Subject: RE: Signer certificate discovery for CRLs
> >>>>
> >>>>
> >>>>
> >>>>David,
> >>>>
> >>>>Thanks for the clarifications, they make sense.
> >>>>I did misread your pictures.
> >>>>
> >>>>So can we conclude that for a re-keyed CA in accordance with RFC
> >>>
> > 3280,
> >
> >>>>either the CRL issuer certificate itself, or the location of the
CRL
> >>>>issuer certificate, will be clearly identified/available for the
> >>>>validating
> >>>
> >>party
> >>
> >>>>in some cases, but not in others?
> >>>>
> >>>>Can we also conclude that there is no real discovery solution for
> >>>
> >>indirect
> >>
> >>>>CRLs?
> >>>>
> >>>>Do you then agree then that it could be appropriate to allow AIA
as
> >>>
> > a
> >
> >>CRL
> >>
> >>>>extension to facilitate discovery of CRL signer certificate?
> >>>>
> >>>>Stefan Santesson
> >>>>Microsoft Security Center of Excellence (SCOE)
> >>>>
> >>>>________________________________________
> >>>>From: David A. Cooper [mailto:[e-mail]]
> >>>>Sent: den 12 oktober 2004 21:14
> >>>>To: Stefan Santesson
> >>>>Cc: pkix
> >>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>
> >>>>Stefan,
> >>>>
> >>>>I believe that you are misinterpreting the figures.  They really
do
> >>>>represent three different cases, not three different certification
> >>>
> > paths
> >
> >>>>that have been constructed through the same PKI architecture.
> >>>>
> >>>>In figure 1, CA 1 has generated self-issued key rollover
> >>>
> > certificates.
> >
> >>>>The
> >>>>Root CA has issued a certificate to CA 1's new key, but not its
old
> >>>
> > key
> >
> >>>>(either the Root CA never issued a certificate to CA 1's old key
or
> >>>
> > that
> >
> >>>>certificate has expired).
> >>>>
> >>>>In figure 2, CA 2 has also generated self-issued key rollover
> >>>>certificates. The Root CA has issued a certificate to CA 2's old
> >>>>key, but not its
> >>>
> > new
> >
> >>>>key.
> >>>>
> >>>>In figure 3, when CA 3 performed key rollover, it requested a new
CA
> >>>>certificate from the Root CA.  CA 3 did not generated self-issued
> >>>
> > key
> >
> >>>>rollover certificates.
> >>>>
> >>>>Of course, another realistic scenario would be one in which a CA
> >>>
> >>generated
> >>
> >>>>self-issued key rollover certificates upon key rollover and then
had
> >>>
> > the
> >
> >>>>Root CA issue a CA certificate to its new key.  In this case, as
you
> >>>>suggest, any of the certification paths from figures 1, 2, or 3
> >>>
> > could be
> >
> >>>>constructed.
> >>>>
> >>>>As for the contents of the AIA extension, here is what I have
> >>>
> > specified
> >
> >>in
> >>
> >>>>the "X.509 Certificate and CRL Extensions Profile for the Common
> >>>
> >>Policy":
> >>
> >>>>The authorityInfoAccess extension uses URIs for two purposes. When
> >>>
> > the
> >
> >>>>id-ad-caIssuers access method is used, the access location
specifies
> >>>
> >>where
> >>
> >>>>certificates issued to the issuer of the certificate may be found.
> >>>
> > If
> >
> >>LDAP
> >>
> >>>>is used, the URI must include the DN of the entry containing the
> >>>
> >>relevant
> >>
> >>>>certificates and specify the directory attribute in which the
> >>>
> >>certificates
> >>
> >>>>are located. If the directory in which the certificates are stored
> >>>
> >>expects
> >>
> >>>>the "binary" option to be specified, then the attribute type must
be
> >>>>followed by ";binary" in the URI. If HTTP is used, the URI must
> >>>
> > point to
> >
> >>a
> >>
> >>>>file that has an extension of ".p7c" that contains a certs-only
CMS
> >>>>message (see RFC 2633). The CMS message should include all
> >>>>certificates
> >>>
> > issued
> >
> >>to
> >>
> >>>>the issuer of this certificate, but must at least contain all
> >>>
> >>certificates
> >>
> >>>>issued to the issuer of this certificate in which the subject
public
> >>>
> > key
> >
> >>>>may
> >>>>be used to verify the signature on this certificate. .... For a
> >>>>certificate issued by "Good CA", some examples of URIs that may
> >>>>appear as the
> >>>
> > access
> >
> >>>>location in an authorityInfoAccess extension when the
> >>>
> > id-ad-caIssuers
> >
> >>>>access
> >>>>method is used are:
> >>>
>
>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACert
> >>>i
> >>
> > fi
> >
> >>ca
> >>
> >>>>te
> >>>>,crossCertificatePair
> >>>
>
>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertific
> >>>a
> >>
> > te
> >
> >>;b
> >>
> >>>>in
> >>>>ary,crossCertificatePair;binary
> >>>
>
>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssue
> >>>d
> >>
> > To
> >
> >>Go
> >>
> >>>>od
> >>>>CA.p7c
> >>>>For both LDAP and HTTP, the URI provides the exact location where
> >>>>information is to be located, so there is no requirement for the
> >>>
> > relying
> >
> >>>>party to try to figure out where information is located.
> >>>>
> >>>>The HTTP URI points to a certs-only CMS message that includes all
> >>>>certificates issued to the CA identified in the issuer field of
the
> >>>>certificate.
> >>>>
> >>>>The LDAP URI points to the cACertificate and crossCertificatePair
> >>>>attributes of the directory entry of the CA identified in the
issuer
> >>>>field of
> >>>
> > the
> >
> >>>>certificate.  These two attributes together hold all of the
> >>>
> > certificates
> >
> >>>>issued to the CA:  the cACertificate attribute holds the CA's
self-
> >>>
> >>issued
> >>
> >>>>certificates and the crossCertificatePair attribute holds the
> >>>>cross-certificates issued to the CA by other CAs.
> >>>>
> >>>>Dave
> >>>>
> >>>>
> >>>>Stefan Santesson wrote:
> >>>>
> >>>>David,
> >>>>
> >>>>Thanks for these good thoughts and very useful scenarios.
> >>>>
> >>>>I have some comments and questions on this.
> >>>>
> >>>>First of all we can conclude that in some scenarios (figure 1)
where
> >>>
> > a
> >
> >>>>self
> >>>>issued certificate is inserted into the path, you are likely to
find
> >>>
> > the
> >
> >>>>CRL
> >>>>issuer cert in the path. (given that the new CA have a common key
> >>>
> > and
> >
> >>>>certificate for cert signing and CRL signing).
> >>>>
> >>>>Figure 1, 2 and 3 describe the same case. It is just describing
> >>>
> >>different
> >>
> >>>>path building strategies. An application that has access locally
to
> >>>
> > all
> >
> >>>>chaining options may however still choose path 2 for the certs and
> >>>
> > path
> >
> >>1
> >>
> >>>>for the CRL independent of each other (which I think figure 3
tries
> >>>
> > to
> >
> >>>>describe)
> >>>>
> >>>>Another comment is the structure of AIA extensions. The use I'm
> >>>
> > familiar
> >
> >>>>with doesn't use AIA to describe a directory entry where it is
left
> >>>
> > to
> >
> >>the
> >>
> >>>>validation application logic to be intelligent enough to find
> >>>
> >>appropriate
> >>
> >>>>certificate data from the directory. The model I'm familiar with
is
> >>>
> > when
> >
> >>>>the
> >>>>AIA URL explicitly identifies the exact location of the
appropriate
> >>>
> > CA
> >
> >>>>certificate file, relieving the validation software from complex
> >>>>information queries. If just location of explicit certificate
files
> >>>>are
> >>>
> > identified
> >
> >>>>through AIA, the presence of an AIA may not help finding the CRL
> >>>
> > signer
> >
> >>>>cert
> >>>>if this is different from the CA certificate. This is also the
> >>>
> > problem
> >
> >>>>with
> >>>>Denis proposal.
> >>>>
> >>>>I think we share the basic conclusion that the ability to locate
the
> >>>
> > CRL
> >
> >>>>signer certificate directly through the CRL could be very useful.
At
> >>>
> >>least
> >>
> >>>>in the case of indirect CRL but it could also be proven very
useful
> >>>
> > in
> >
> >>CA
> >>
> >>>>re-keying scenarios.
> >>>>
> >>>>The easiest solution would probably be to allow AIA to be used in
> >>>
> > its
> >
> >>>>current shape and structure as a CRL extension (MUST NOT be
> >>>
> > critical).
> >
> >>It
> >>
> >>>>would present a very clear and uncomplicated logic to certificate
> >>>>validating applications in many cases.
> >>>>
> >>>>Stefan Santesson
> >>>>Microsoft Security Center of Excellence (SCOE)
> >>>>
> >>>>________________________________________
> >>>>From: David A. Cooper [mailto:[e-mail]]
> >>>>Sent: den 7 oktober 2004 18:35
> >>>>To: Stefan Santesson
> >>>>Cc: pkix
> >>>>Subject: Re: Signer certificate discovery for CRLs
> >>>>
> >>>>Stefan,
> >>>>
> >>>>I think what you are proposing is a good idea.  In most cases,
path
> >>>>discovery algorithms assume that both the trust anchor (or trust
> >>>
> >>anchors)
> >>
> >>>>and the end entity certificate are provided as input.  In this
case,
> >>>
> > one
> >
> >>>>may
> >>>>need to construct a certification path without a priori access to
> >>>
> > the
> >
> >>end
> >>
> >>>>entity certificate (the one with the subject public key
> >>>
> > corresponding to
> >
> >>>>the
> >>>>CRL signing key).  Including an AIA extension (or some other
> >>>
> > pointer) in
> >
> >>>>the
> >>>>CRL would provide the relying party with a simple way to obtain
the
> >>>
> > end
> >
> >>>>entity certificate for the CRL signing key's certification path.
On
> >>>
> > the
> >
> >>>>other hand, I believe that a relying party should be able to
> >>>
> > construct
> >
> >>the
> >>
> >>>>certification path even without an AIA extension in the CRL, so
long
> >>>
> > as
> >
> >>it
> >>
> >>>>is not an indirect CRL.  Attached is a drawing of the three basic
> >>>>scenarios that I expect a relying party may encounter:
> >>>>
> >>>>In each of these scenarios, the CA has performed key rollover and
is
> >>>
> >>only
> >>
> >>>>signing CRLs with its new key.  The diagrams would look similar,
> >>>
> >>however,
> >>
> >>>>if
> >>>>the CA simply choose to use different keys to sign certificates
and
> >>>
> > CRLs
> >
> >>>>for
> >>>>some other reason.
> >>>>
> >>>>If the PKI architecture resembled figure 1, then the certification
> >>>
> > path
> >
> >>>>for
> >>>>the CRL signing key would just be a subset of the certification
path
> >>>
> > for
> >
> >>>>the
> >>>>EE certificate, so no addition path discovery would be needed.
> >>>>
> >>>>If the PKI architecture resembled figure 1, then it would be
> >>>
> > necessary
> >
> >>to
> >>
> >>>>obtain the new-signed-with-old self-issued certificate.  In
building
> >>>
> > the
> >
> >>>>certification path to the EE certificate, however, the relying
party
> >>>
> >>will
> >>
> >>>>obtain the certificates pointed to by the AIA extension in the EE
> >>>>certificate.  This AIA extension will point to a location
containing
> >>>
> > all
> >
> >>>>certificates issued to CA 2, which would include both the
> >>>
> > certificate
> >
> >>>>issued
> >>>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
> >>>
> > though
> >
> >>>>the
> >>>>self-issued certificate would not be part of the certification
path
> >>>
> > to
> >
> >>the
> >>
> >>>>EE certificate, it would be downloaded by the relying party during
> >>>
> > the
> >
> >>>>construction of that certification path.  (Yes, there are circular
> >>>>dependency issues in figure 2, but that is another issue.)
> >>>>
> >>>>A similar situation would happen if the PKI architecture resembled
> >>>
> >>figure
> >>
> >>>>3.  The AIA extension in the EE certificate would point to a
> >>>
> > location
> >
> >>>>containing certificates issued to CA 3.  When the relying party
> >>>
> >>downloaded
> >>
> >>>>these certificates, it would obtain both of the certificates
issued
> >>>
> > by
> >
> >>the
> >>
> >>>>Root to CA 3 and so again would have the certificate needed to
> >>>
> > validate
> >
> >>>>the
> >>>>CRL signing key.
> >>>>
> >>>>In the case of an indirect CRL, things may not work as well.  If
> >>>
> >>indirect
> >>
> >>>>CRLs were used, and the PKI architecture resembled figures 2 or 3
> >>>>(replacing "New Key" with a different CA), then the set of
> >>>>certificates pointed
> >>>
> > to
> >
> >>by
> >>
> >>>>the AIA extension in the EE certificate would not include the
> >>>
> >>certificate
> >>
> >>>>of
> >>>>the CRL signer.  One could find this certificate by building in
the
> >>>>reverse direction and using the SIA extension, but that may not be
> >>>>the most convenient solution.
> >>>>
> >>>>So, when indirect CRLs are being used, it seems that it would be
> >>>
> > very
> >
> >>>>useful
> >>>>to have a pointer in the CRL to the CRL signing certificate.  When
> >>>
> > the
> >
> >>CRL
> >>
> >>>>is not indirect, the need for this pointer does not seem to be as
> >>>
> > clear,
> >
> >>>>but
> >>>>I can't see any harm in including it.
> >>>>
> >>>>Dave
> >>>>
> >>>>Stefan Santesson wrote:
> >>>>All,
> >>>>
> >>>>I'm interested in the opinion from members on this list about
> >>>
> > discovery
> >
> >>of
> >>
> >>>>CRL signer's certificate in non directory centric environments.
> >>>>
> >>>>The problem is the following.
> >>>>
> >>>>The relying party (RP) needs to check validity of a certificate
and
> >>>
> >>finds
> >>
> >>>>a
> >>>>CDP extension with a URL to the CRL. The RP retrieves this CRL
which
> >>>
> > in
> >
> >>>>this
> >>>>particular case is either signed by another key of the CA
(re-keyed
> >>>
> > CA)
> >
> >>or
> >>
> >>>>another entity (indirect CRL).
> >>>>
> >>>>In this case the relying party needs to obtain the certificate of
> >>>
> > the
> >
> >>CRL
> >>
> >>>>signer which may NOT be part of the original chain. In a directory
> >>>
> >>centric
> >>
> >>>>solution this is retrieved from the directory, but what if such
> >>>
> >>directory
> >>
> >>>>is
> >>>>not available or accessible.
> >>>>
> >>>>The RP have thus no hint where to find the CRL issuers certificate
> >>>
> >>unless
> >>
> >>>>the RP already have possession of it by some other means.
> >>>>
> >>>>Is seems that CRLs would need an AIA extension with the option to
> >>>
> > point
> >
> >>to
> >>
> >>>>the location of the signers certificate in the same manner as is
> >>>
> >>possible
> >>
> >>>>for certificates.
> >>>>
> >>>>Maybe AIA should be defined as both cert and CRL extension and not
> >>>
> > only
> >
> >>>>certificate extension as today.
> >>>>
> >>>>Thoughts and comments?
> >>>>
> >>>>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 i9E7rWSU083174; Thu, 14 Oct 2004 00:53:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9E7rWkM083173; Thu, 14 Oct 2004 00:53:32 -0700 (PDT)
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 i9E7rVI7083163 for <[e-mail]>; Thu, 14 Oct 2004 00:53:32 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (PPP-219.65.37.4.mum2.vsnl.net.in [219.65.37.4]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9E7rJfn028859 for <[e-mail]>; Thu, 14 Oct 2004 03:53:26 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Thu, 14 Oct 2004 03:53:13 -0400
Message-ID: <002401c4b1c2$e3cc8620$[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 i9E7rWI7083167
Sender: [e-mail]
Precedence: 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:

I agree that the change does not warrant change in OID and should not impact
others.

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Thursday, October 14, 2004 3:40 AM
To: Wen-Cheng Wang; Santosh Chokhani; pkix
Subject: RE: Signer certificate discovery for CRLs


Wen-Cheng,

Thanks for bringing this up. Yes, this has also crossed my mind and we will
have to find the appropriate course on this matter.

I'm personally divided but I kind of like to keep the current OID since we
have a lot of current code and logic that successfully use the
id-ad-caIssuers to retrieve certificates for chain-building, which is the
case both for certificate chains for certs and CRLs. So I see no major
change in the use of the OID, just a fractional expansion of scope.

So currently I lean towards adding the minor expansion of scope to the
current id-ad-caIssuers OID instead of creating a new one. But that is not
yet a mature opinion.

I think the time to deal with this problem is best after deciding whether we
want to do AIA for CRLs in the first place. I'm positive that we can find a
good solution.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Wen-Cheng Wang
> Sent: den 14 oktober 2004 04:09
> To: Stefan Santesson; Santosh Chokhani; pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Stefan,
> 
> I think it is a good idea to include AIA extension in CRL to aid RP in 
> finding CRL issuer certificates.
> 
> However, I am concerning about the accessMethod OID to be used. 
> Currently, RFC 3280 only define id-ad-caIssuers OID, which is intended 
> to aid RP in finding CA certificates. Since a CRL issuer might not be 
> a CA, the name and definition of the id-ad-caIssuers OID need to be 
> changed (or extended).
> 
> In addition, the definition of the id-ad-caIssuers accessMethod is 
> very vague. I think this is a chance to clarify it. I suggest that 
> when doing this amendment the following things should be
> clarified:
> 
>    1. What will be retrieved from the acceesLocation if it is an URI?
>            I believe that the current practice is that an issuer 
> certificate
>            or a list of issuer certificates (in PKCS#7 format) will be
>            retrieved if the acceesLocation is an HTTP or FTP URI.
>            But it is not clear what will be retrieved if the 
> acceesLocation
>            is an LDAP URI?
>    2. What will be the MIME type of the retrieved object?
> 
> Since id-ad-caIssuers is not a proper name for the the accessMethod 
> OID, I suggest that th name be changed to id-ad-issuerCertificates 
> (and of course the definition should also be changed).
> 
> Wen-Cheng Wang
> 
> 
> ----- Original Message -----
> From: "Stefan Santesson" <[e-mail]>
> To: "Santosh Chokhani" <[e-mail]>; "pkix"
<[e-mail]>
> Sent: Wednesday, October 13, 2004 9:44 PM
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> 
> Santosh,
> 
> I conclude that we are in complete and total agreement.
> The question is how to go about this.
> 
> Could we do this amendment to RFC 3280 in its next revision? It would 
> hopefully just be a minor change.
> 
> It would not change the definition of AIA just add that it can be used 
> also as CRL extension and list eventual restrictions and guidance for 
> use
with
> CRLs.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [e-mail]
[mailto:[e-mail]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 13 oktober 2004 04:33
> > To: 'pkix'
> > Subject: RE: Signer certificate discovery for CRLs
> >
> >
> > Stefan:
> >
> > In terms of certificate discovery, your proposal for AIA in CRL is
more
> > robust.  The whole idea of self-issued key rollover certificates and
> then
> > using the new key to issue CRL is fraught with security problems.  A 
> > secure solution would be one where the new key is certified by the 
> > parent
CA.
> In
> > that case to obtain the new certificate, you could use AIA in CRL.
> >
> > As to indirect CRL, your proposal is a good one.  The CRL DP in 
> > certificate in question points to the indirect CRL.  You get that 
> > CRL.  The AIA
in
> CRL
> > gets you started for the indirect CRL issuer certification path and
you
> > are
> > in business.
> >
> > -----Original Message-----
> > From: [e-mail]
[mailto:[e-mail]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Tuesday, October 12, 2004 7:30 PM
> > To: David A. Cooper
> > Cc: pkix
> > Subject: RE: Signer certificate discovery for CRLs
> >
> >
> >
> > David,
> >
> > Thanks for the clarifications, they make sense.
> > I did misread your pictures.
> >
> > So can we conclude that for a re-keyed CA in accordance with RFC
3280,
> > either the CRL issuer certificate itself, or the location of the CRL 
> > issuer certificate, will be clearly identified/available for the 
> > validating
> party
> > in some cases, but not in others?
> >
> > Can we also conclude that there is no real discovery solution for
> indirect
> > CRLs?
> >
> > Do you then agree then that it could be appropriate to allow AIA as
a
> CRL
> > extension to facilitate discovery of CRL signer certificate?
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> > ________________________________________
> > From: David A. Cooper [mailto:[e-mail]]
> > Sent: den 12 oktober 2004 21:14
> > To: Stefan Santesson
> > Cc: pkix
> > Subject: Re: Signer certificate discovery for CRLs
> >
> > Stefan,
> >
> > I believe that you are misinterpreting the figures. They really do 
> > represent three different cases, not three different certification
paths
> > that have been constructed through the same PKI architecture.
> >
> > In figure 1, CA 1 has generated self-issued key rollover
certificates.
> > The
> > Root CA has issued a certificate to CA 1's new key, but not its old
key
> > (either the Root CA never issued a certificate to CA 1's old key or
that
> > certificate has expired).
> >
> > In figure 2, CA 2 has also generated self-issued key rollover 
> > certificates. The Root CA has issued a certificate to CA 2's old 
> > key, but not its
new
> > key.
> >
> > In figure 3, when CA 3 performed key rollover, it requested a new CA 
> > certificate from the Root CA. CA 3 did not generated self-issued key 
> > rollover certificates.
> >
> > Of course, another realistic scenario would be one in which a CA
> generated
> > self-issued key rollover certificates upon key rollover and then had
the
> > Root CA issue a CA certificate to its new key. In this case, as you 
> > suggest, any of the certification paths from figures 1, 2, or 3
could be
> > constructed.
> >
> > As for the contents of the AIA extension, here is what I have
specified
> in
> > the "X.509 Certificate and CRL Extensions Profile for the Common
> Policy":
> >
> > The authorityInfoAccess extension uses URIs for two purposes. When
the
> > id-ad-caIssuers access method is used, the access location specifies
> where
> > certificates issued to the issuer of the certificate may be found.
If
> LDAP
> > is used, the URI must include the DN of the entry containing the
> relevant
> > certificates and specify the directory attribute in which the
> certificates
> > are located. If the directory in which the certificates are stored
> expects
> > the "binary" option to be specified, then the attribute type must be 
> > followed by ";binary" in the URI. If HTTP is used, the URI must
point to
> a
> > file that has an extension of ".p7c" that contains a certs-only CMS 
> > message (see RFC 2633). The CMS message should include all 
> > certificates
issued
> to
> > the issuer of this certificate, but must at least contain all
> certificates
> > issued to the issuer of this certificate in which the subject public
key
> > may
> > be used to verify the signature on this certificate. .... For a 
> > certificate issued by "Good CA", some examples of URIs that may 
> > appear as the
access
> > location in an authorityInfoAccess extension when the
id-ad-caIssuers
> > access
> > method is used are:
> >
>
ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifi
ca
> > te
> > ,crossCertificatePair
> >
>
ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertificate
;b
> > in
> > ary,crossCertificatePair;binary
> >
>
http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssuedTo
Go
> > od
> > CA.p7c
> > For both LDAP and HTTP, the URI provides the exact location where 
> > information is to be located, so there is no requirement for the
relying
> > party to try to figure out where information is located.
> >
> > The HTTP URI points to a certs-only CMS message that includes all 
> > certificates issued to the CA identified in the issuer field of the 
> > certificate.
> >
> > The LDAP URI points to the cACertificate and crossCertificatePair 
> > attributes of the directory entry of the CA identified in the issuer 
> > field of
the
> > certificate. These two attributes together hold all of the
certificates
> > issued to the CA: the cACertificate attribute holds the CA's
self-issued
> > certificates and the crossCertificatePair attribute holds the 
> > cross-certificates issued to the CA by other CAs.
> >
> > Dave
> >
> >
> > Stefan Santesson wrote:
> >
> > David,
> >
> > Thanks for these good thoughts and very useful scenarios.
> >
> > I have some comments and questions on this.
> >
> > First of all we can conclude that in some scenarios (figure 1) where
a
> > self
> > issued certificate is inserted into the path, you are likely to find
the
> > CRL
> > issuer cert in the path. (given that the new CA have a common key
and
> > certificate for cert signing and CRL signing).
> >
> > Figure 1, 2 and 3 describe the same case. It is just describing
> different
> > path building strategies. An application that has access locally to
all
> > chaining options may however still choose path 2 for the certs and
path
> 1
> > for the CRL independent of each other (which I think figure 3 tries
to
> > describe)
> >
> > Another comment is the structure of AIA extensions. The use I'm
familiar
> > with doesn't use AIA to describe a directory entry where it is left
to
> the
> > validation application logic to be intelligent enough to find
> appropriate
> > certificate data from the directory. The model I'm familiar with is
when
> > the
> > AIA URL explicitly identifies the exact location of the appropriate
CA
> > certificate file, relieving the validation software from complex 
> > information queries. If just location of explicit certificate files 
> > are
identified
> > through AIA, the presence of an AIA may not help finding the CRL
signer
> > cert
> > if this is different from the CA certificate. This is also the
problem
> > with
> > Denis proposal.
> >
> > I think we share the basic conclusion that the ability to locate the
CRL
> > signer certificate directly through the CRL could be very useful. At
> least
> > in the case of indirect CRL but it could also be proven very useful
in
> CA
> > re-keying scenarios.
> >
> > The easiest solution would probably be to allow AIA to be used in
its
> > current shape and structure as a CRL extension (MUST NOT be
critical).
> It
> > would present a very clear and uncomplicated logic to certificate 
> > validating applications in many cases.
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> > ________________________________________
> > From: David A. Cooper [mailto:[e-mail]]
> > Sent: den 7 oktober 2004 18:35
> > To: Stefan Santesson
> > Cc: pkix
> > Subject: Re: Signer certificate discovery for CRLs
> >
> > Stefan,
> >
> > I think what you are proposing is a good idea. In most cases, path 
> > discovery algorithms assume that both the trust anchor (or trust
> anchors)
> > and the end entity certificate are provided as input. In this case,
one
> > may
> > need to construct a certification path without a priori access to
the
> end
> > entity certificate (the one with the subject public key
corresponding to
> > the
> > CRL signing key). Including an AIA extension (or some other pointer)
in
> > the
> > CRL would provide the relying party with a simple way to obtain the
end
> > entity certificate for the CRL signing key's certification path. On
the
> > other hand, I believe that a relying party should be able to
construct
> the
> > certification path even without an AIA extension in the CRL, so long
as
> it
> > is not an indirect CRL. Attached is a drawing of the three basic 
> > scenarios that I expect a relying party may encounter:
> >
> > In each of these scenarios, the CA has performed key rollover and is
> only
> > signing CRLs with its new key. The diagrams would look similar,
however,
> > if
> > the CA simply choose to use different keys to sign certificates and
CRLs
> > for
> > some other reason.
> >
> > If the PKI architecture resembled figure 1, then the certification
path
> > for
> > the CRL signing key would just be a subset of the certification path
for
> > the
> > EE certificate, so no addition path discovery would be needed.
> >
> > If the PKI architecture resembled figure 1, then it would be
necessary
> to
> > obtain the new-signed-with-old self-issued certificate. In building
the
> > certification path to the EE certificate, however, the relying party
> will
> > obtain the certificates pointed to by the AIA extension in the EE 
> > certificate. This AIA extension will point to a location containing
all
> > certificates issued to CA 2, which would include both the
certificate
> > issued
> > by the Root to CA 2 and CA 2's self-issued certificate. So, even
though
> > the
> > self-issued certificate would not be part of the certification path
to
> the
> > EE certificate, it would be downloaded by the relying party during
the
> > construction of that certification path. (Yes, there are circular 
> > dependency issues in figure 2, but that is another issue.)
> >
> > A similar situation would happen if the PKI architecture resembled
> figure
> > 3. The AIA extension in the EE certificate would point to a location 
> > containing certificates issued to CA 3. When the relying party
> downloaded
> > these certificates, it would obtain both of the certificates issued
by
> the
> > Root to CA 3 and so again would have the certificate needed to
validate
> > the
> > CRL signing key.
> >
> > In the case of an indirect CRL, things may not work as well. If
indirect
> > CRLs were used, and the PKI architecture resembled figures 2 or 3 
> > (replacing "New Key" with a different CA), then the set of 
> > certificates pointed
to
> by
> > the AIA extension in the EE certificate would not include the
> certificate
> > of
> > the CRL signer. One could find this certificate by building in the 
> > reverse direction and using the SIA extension, but that may not be 
> > the most convenient solution.
> >
> > So, when indirect CRLs are being used, it seems that it would be
very
> > useful
> > to have a pointer in the CRL to the CRL signing certificate. When
the
> CRL
> > is not indirect, the need for this pointer does not seem to be as
clear,
> > but
> > I can't see any harm in including it.
> >
> > Dave
> >
> > Stefan Santesson wrote:
> > All,
> >
> > I'm interested in the opinion from members on this list about
discovery
> of
> > CRL signer's certificate in non directory centric environments.
> >
> > The problem is the following.
> >
> > The relying party (RP) needs to check validity of a certificate and
> finds
> > a
> > CDP extension with a URL to the CRL. The RP retrieves this CRL which
in
> > this
> > particular case is either signed by another key of the CA (re-keyed
CA)
> or
> > another entity (indirect CRL).
> >
> > In this case the relying party needs to obtain the certificate of
the
> CRL
> > signer which may NOT be part of the original chain. In a directory
> centric
> > solution this is retrieved from the directory, but what if such
> directory
> > is
> > not available or accessible.
> >
> > The RP have thus no hint where to find the CRL issuers certificate
> unless
> > the RP already have possession of it by some other means.
> >
> > Is seems that CRLs would need an AIA extension with the option to
point
> to
> > the location of the signers certificate in the same manner as is
> possible
> > for certificates.
> >
> > Maybe AIA should be defined as both cert and CRL extension and not
only
> > certificate extension as today.
> >
> > Thoughts and comments?
> >
> > 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 i9E7eFRS077891; Thu, 14 Oct 2004 00:40:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9E7eFFt077890; Thu, 14 Oct 2004 00:40:15 -0700 (PDT)
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 i9E7eEdP077806 for <[e-mail]>; Thu, 14 Oct 2004 00:40:14 -0700 (PDT) (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.0); Thu, 14 Oct 2004 08:40:15 +0100
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: Signer certificate discovery for CRLs
Date: Thu, 14 Oct 2004 08:39:43 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcSxnb9yY7uSp/yxTtGUPgw1sQnXRgAIbsrg
From: "Stefan Santesson" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 14 Oct 2004 07:40:15.0164 (UTC) FILETIME=[0B6BDFC0:01C4B1C1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9E7eFdP077882
Sender: [e-mail]
Precedence: 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,

Thanks for bringing this up. Yes, this has also crossed my mind and we
will have to find the appropriate course on this matter.

I'm personally divided but I kind of like to keep the current OID since
we have a lot of current code and logic that successfully use the
id-ad-caIssuers to retrieve certificates for chain-building, which is
the case both for certificate chains for certs and CRLs. So I see no
major change in the use of the OID, just a fractional expansion of
scope.

So currently I lean towards adding the minor expansion of scope to the
current id-ad-caIssuers OID instead of creating a new one. But that is
not yet a mature opinion.

I think the time to deal with this problem is best after deciding
whether we want to do AIA for CRLs in the first place. I'm positive that
we can find a good solution.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Wen-Cheng Wang
> Sent: den 14 oktober 2004 04:09
> To: Stefan Santesson; Santosh Chokhani; pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Stefan,
> 
> I think it is a good idea to include AIA extension in CRL to aid
> RP in finding CRL issuer certificates.
> 
> However, I am concerning about the accessMethod OID to be
> used. Currently, RFC 3280 only define id-ad-caIssuers OID,
> which is intended to aid RP in finding CA certificates.
> Since a CRL issuer might not be a CA, the name and definition
> of the id-ad-caIssuers OID need to be changed (or extended).
> 
> In addition, the definition of the id-ad-caIssuers accessMethod
> is very vague. I think this is a chance to clarify it. I suggest that
> when doing this amendment the following things should be
> clarified:
> 
>    1. What will be retrieved from the acceesLocation if it is an URI?
>            I believe that the current practice is that an issuer
> certificate
>            or a list of issuer certificates (in PKCS#7 format) will be
>            retrieved if the acceesLocation is an HTTP or FTP URI.
>            But it is not clear what will be retrieved if the
> acceesLocation
>            is an LDAP URI?
>    2. What will be the MIME type of the retrieved object?
> 
> Since id-ad-caIssuers is not a proper name for the the accessMethod
> OID, I suggest that th name be changed to id-ad-issuerCertificates
> (and of course the definition should also be changed).
> 
> Wen-Cheng Wang
> 
> 
> ----- Original Message -----
> From: "Stefan Santesson" <[e-mail]>
> To: "Santosh Chokhani" <[e-mail]>; "pkix"
<[e-mail]>
> Sent: Wednesday, October 13, 2004 9:44 PM
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> 
> Santosh,
> 
> I conclude that we are in complete and total agreement.
> The question is how to go about this.
> 
> Could we do this amendment to RFC 3280 in its next revision?
> It would hopefully just be a minor change.
> 
> It would not change the definition of AIA just add that it can be used
> also
> as CRL extension and list eventual restrictions and guidance for use
with
> CRLs.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [e-mail]
[mailto:[e-mail]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 13 oktober 2004 04:33
> > To: 'pkix'
> > Subject: RE: Signer certificate discovery for CRLs
> >
> >
> > Stefan:
> >
> > In terms of certificate discovery, your proposal for AIA in CRL is
more
> > robust.  The whole idea of self-issued key rollover certificates and
> then
> > using the new key to issue CRL is fraught with security problems.  A
> > secure
> > solution would be one where the new key is certified by the parent
CA.
> In
> > that case to obtain the new certificate, you could use AIA in CRL.
> >
> > As to indirect CRL, your proposal is a good one.  The CRL DP in
> > certificate
> > in question points to the indirect CRL.  You get that CRL.  The AIA
in
> CRL
> > gets you started for the indirect CRL issuer certification path and
you
> > are
> > in business.
> >
> > -----Original Message-----
> > From: [e-mail]
[mailto:[e-mail]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Tuesday, October 12, 2004 7:30 PM
> > To: David A. Cooper
> > Cc: pkix
> > Subject: RE: Signer certificate discovery for CRLs
> >
> >
> >
> > David,
> >
> > Thanks for the clarifications, they make sense.
> > I did misread your pictures.
> >
> > So can we conclude that for a re-keyed CA in accordance with RFC
3280,
> > either the CRL issuer certificate itself, or the location of the CRL
> > issuer
> > certificate, will be clearly identified/available for the validating
> party
> > in some cases, but not in others?
> >
> > Can we also conclude that there is no real discovery solution for
> indirect
> > CRLs?
> >
> > Do you then agree then that it could be appropriate to allow AIA as
a
> CRL
> > extension to facilitate discovery of CRL signer certificate?
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> > ________________________________________
> > From: David A. Cooper [mailto:[e-mail]]
> > Sent: den 12 oktober 2004 21:14
> > To: Stefan Santesson
> > Cc: pkix
> > Subject: Re: Signer certificate discovery for CRLs
> >
> > Stefan,
> >
> > I believe that you are misinterpreting the figures. They really do
> > represent three different cases, not three different certification
paths
> > that have been constructed through the same PKI architecture.
> >
> > In figure 1, CA 1 has generated self-issued key rollover
certificates.
> > The
> > Root CA has issued a certificate to CA 1's new key, but not its old
key
> > (either the Root CA never issued a certificate to CA 1's old key or
that
> > certificate has expired).
> >
> > In figure 2, CA 2 has also generated self-issued key rollover
> > certificates.
> > The Root CA has issued a certificate to CA 2's old key, but not its
new
> > key.
> >
> > In figure 3, when CA 3 performed key rollover, it requested a new CA
> > certificate from the Root CA. CA 3 did not generated self-issued key
> > rollover certificates.
> >
> > Of course, another realistic scenario would be one in which a CA
> generated
> > self-issued key rollover certificates upon key rollover and then had
the
> > Root CA issue a CA certificate to its new key. In this case, as you
> > suggest, any of the certification paths from figures 1, 2, or 3
could be
> > constructed.
> >
> > As for the contents of the AIA extension, here is what I have
specified
> in
> > the "X.509 Certificate and CRL Extensions Profile for the Common
> Policy":
> >
> > The authorityInfoAccess extension uses URIs for two purposes. When
the
> > id-ad-caIssuers access method is used, the access location specifies
> where
> > certificates issued to the issuer of the certificate may be found.
If
> LDAP
> > is used, the URI must include the DN of the entry containing the
> relevant
> > certificates and specify the directory attribute in which the
> certificates
> > are located. If the directory in which the certificates are stored
> expects
> > the "binary" option to be specified, then the attribute type must be
> > followed by ";binary" in the URI. If HTTP is used, the URI must
point to
> a
> > file that has an extension of ".p7c" that contains a certs-only CMS
> > message
> > (see RFC 2633). The CMS message should include all certificates
issued
> to
> > the issuer of this certificate, but must at least contain all
> certificates
> > issued to the issuer of this certificate in which the subject public
key
> > may
> > be used to verify the signature on this certificate. .... For a
> > certificate
> > issued by "Good CA", some examples of URIs that may appear as the
access
> > location in an authorityInfoAccess extension when the
id-ad-caIssuers
> > access
> > method is used are:
> >
>
ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifi
ca
> > te
> > ,crossCertificatePair
> >
>
ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertificate
;b
> > in
> > ary,crossCertificatePair;binary
> >
>
http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssuedTo
Go
> > od
> > CA.p7c
> > For both LDAP and HTTP, the URI provides the exact location where
> > information is to be located, so there is no requirement for the
relying
> > party to try to figure out where information is located.
> >
> > The HTTP URI points to a certs-only CMS message that includes all
> > certificates issued to the CA identified in the issuer field of the
> > certificate.
> >
> > The LDAP URI points to the cACertificate and crossCertificatePair
> > attributes
> > of the directory entry of the CA identified in the issuer field of
the
> > certificate. These two attributes together hold all of the
certificates
> > issued to the CA: the cACertificate attribute holds the CA's
self-issued
> > certificates and the crossCertificatePair attribute holds the
> > cross-certificates issued to the CA by other CAs.
> >
> > Dave
> >
> >
> > Stefan Santesson wrote:
> >
> > David,
> >
> > Thanks for these good thoughts and very useful scenarios.
> >
> > I have some comments and questions on this.
> >
> > First of all we can conclude that in some scenarios (figure 1) where
a
> > self
> > issued certificate is inserted into the path, you are likely to find
the
> > CRL
> > issuer cert in the path. (given that the new CA have a common key
and
> > certificate for cert signing and CRL signing).
> >
> > Figure 1, 2 and 3 describe the same case. It is just describing
> different
> > path building strategies. An application that has access locally to
all
> > chaining options may however still choose path 2 for the certs and
path
> 1
> > for the CRL independent of each other (which I think figure 3 tries
to
> > describe)
> >
> > Another comment is the structure of AIA extensions. The use I'm
familiar
> > with doesn't use AIA to describe a directory entry where it is left
to
> the
> > validation application logic to be intelligent enough to find
> appropriate
> > certificate data from the directory. The model I'm familiar with is
when
> > the
> > AIA URL explicitly identifies the exact location of the appropriate
CA
> > certificate file, relieving the validation software from complex
> > information
> > queries. If just location of explicit certificate files are
identified
> > through AIA, the presence of an AIA may not help finding the CRL
signer
> > cert
> > if this is different from the CA certificate. This is also the
problem
> > with
> > Denis proposal.
> >
> > I think we share the basic conclusion that the ability to locate the
CRL
> > signer certificate directly through the CRL could be very useful. At
> least
> > in the case of indirect CRL but it could also be proven very useful
in
> CA
> > re-keying scenarios.
> >
> > The easiest solution would probably be to allow AIA to be used in
its
> > current shape and structure as a CRL extension (MUST NOT be
critical).
> It
> > would present a very clear and uncomplicated logic to certificate
> > validating
> > applications in many cases.
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> > ________________________________________
> > From: David A. Cooper [mailto:[e-mail]]
> > Sent: den 7 oktober 2004 18:35
> > To: Stefan Santesson
> > Cc: pkix
> > Subject: Re: Signer certificate discovery for CRLs
> >
> > Stefan,
> >
> > I think what you are proposing is a good idea. In most cases, path
> > discovery algorithms assume that both the trust anchor (or trust
> anchors)
> > and the end entity certificate are provided as input. In this case,
one
> > may
> > need to construct a certification path without a priori access to
the
> end
> > entity certificate (the one with the subject public key
corresponding to
> > the
> > CRL signing key). Including an AIA extension (or some other pointer)
in
> > the
> > CRL would provide the relying party with a simple way to obtain the
end
> > entity certificate for the CRL signing key's certification path. On
the
> > other hand, I believe that a relying party should be able to
construct
> the
> > certification path even without an AIA extension in the CRL, so long
as
> it
> > is not an indirect CRL. Attached is a drawing of the three basic
> > scenarios
> > that I expect a relying party may encounter:
> >
> > In each of these scenarios, the CA has performed key rollover and is
> only
> > signing CRLs with its new key. The diagrams would look similar,
however,
> > if
> > the CA simply choose to use different keys to sign certificates and
CRLs
> > for
> > some other reason.
> >
> > If the PKI architecture resembled figure 1, then the certification
path
> > for
> > the CRL signing key would just be a subset of the certification path
for
> > the
> > EE certificate, so no addition path discovery would be needed.
> >
> > If the PKI architecture resembled figure 1, then it would be
necessary
> to
> > obtain the new-signed-with-old self-issued certificate. In building
the
> > certification path to the EE certificate, however, the relying party
> will
> > obtain the certificates pointed to by the AIA extension in the EE
> > certificate. This AIA extension will point to a location containing
all
> > certificates issued to CA 2, which would include both the
certificate
> > issued
> > by the Root to CA 2 and CA 2's self-issued certificate. So, even
though
> > the
> > self-issued certificate would not be part of the certification path
to
> the
> > EE certificate, it would be downloaded by the relying party during
the
> > construction of that certification path. (Yes, there are circular
> > dependency issues in figure 2, but that is another issue.)
> >
> > A similar situation would happen if the PKI architecture resembled
> figure
> > 3. The AIA extension in the EE certificate would point to a location
> > containing certificates issued to CA 3. When the relying party
> downloaded
> > these certificates, it would obtain both of the certificates issued
by
> the
> > Root to CA 3 and so again would have the certificate needed to
validate
> > the
> > CRL signing key.
> >
> > In the case of an indirect CRL, things may not work as well. If
indirect
> > CRLs were used, and the PKI architecture resembled figures 2 or 3
> > (replacing
> > "New Key" with a different CA), then the set of certificates pointed
to
> by
> > the AIA extension in the EE certificate would not include the
> certificate
> > of
> > the CRL signer. One could find this certificate by building in the
> > reverse
> > direction and using the SIA extension, but that may not be the most
> > convenient solution.
> >
> > So, when indirect CRLs are being used, it seems that it would be
very
> > useful
> > to have a pointer in the CRL to the CRL signing certificate. When
the
> CRL
> > is not indirect, the need for this pointer does not seem to be as
clear,
> > but
> > I can't see any harm in including it.
> >
> > Dave
> >
> > Stefan Santesson wrote:
> > All,
> >
> > I'm interested in the opinion from members on this list about
discovery
> of
> > CRL signer's certificate in non directory centric environments.
> >
> > The problem is the following.
> >
> > The relying party (RP) needs to check validity of a certificate and
> finds
> > a
> > CDP extension with a URL to the CRL. The RP retrieves this CRL which
in
> > this
> > particular case is either signed by another key of the CA (re-keyed
CA)
> or
> > another entity (indirect CRL).
> >
> > In this case the relying party needs to obtain the certificate of
the
> CRL
> > signer which may NOT be part of the original chain. In a directory
> centric
> > solution this is retrieved from the directory, but what if such
> directory
> > is
> > not available or accessible.
> >
> > The RP have thus no hint where to find the CRL issuers certificate
> unless
> > the RP already have possession of it by some other means.
> >
> > Is seems that CRLs would need an AIA extension with the option to
point
> to
> > the location of the signers certificate in the same manner as is
> possible
> > for certificates.
> >
> > Maybe AIA should be defined as both cert and CRL extension and not
only
> > certificate extension as today.
> >
> > Thoughts and comments?
> >
> > 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 i9E29Op9081831; Wed, 13 Oct 2004 19:09:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9E29OgF081830; Wed, 13 Oct 2004 19:09:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E29Lc5081807 for <[e-mail]>; Wed, 13 Oct 2004 19:09:22 -0700 (PDT) (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 i9E29Rpa029283; Thu, 14 Oct 2004 10:09:27 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id i9E29Rqe007401; Thu, 14 Oct 2004 10:09:27 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id i9E29QZG007331; Thu, 14 Oct 2004 10:09:26 +0800
Message-ID: <007101c4b192$d433e990$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "pkix" <[e-mail]>
References: <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
Date: Thu, 14 Oct 2004 10:09:24 +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>

Stefan,

I think it is a good idea to include AIA extension in CRL to aid
RP in finding CRL issuer certificates.

However, I am concerning about the accessMethod OID to be
used. Currently, RFC 3280 only define id-ad-caIssuers OID,
which is intended to aid RP in finding CA certificates.
Since a CRL issuer might not be a CA, the name and definition
of the id-ad-caIssuers OID need to be changed (or extended).

In addition, the definition of the id-ad-caIssuers accessMethod
is very vague. I think this is a chance to clarify it. I suggest that
when doing this amendment the following things should be
clarified:

   1. What will be retrieved from the acceesLocation if it is an URI?
           I believe that the current practice is that an issuer certificate
           or a list of issuer certificates (in PKCS#7 format) will be
           retrieved if the acceesLocation is an HTTP or FTP URI.
           But it is not clear what will be retrieved if the acceesLocation
           is an LDAP URI?
   2. What will be the MIME type of the retrieved object?

Since id-ad-caIssuers is not a proper name for the the accessMethod
OID, I suggest that th name be changed to id-ad-issuerCertificates
(and of course the definition should also be changed).

Wen-Cheng Wang


----- Original Message ----- 
From: "Stefan Santesson" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>; "pkix" <[e-mail]>
Sent: Wednesday, October 13, 2004 9:44 PM
Subject: RE: Signer certificate discovery for CRLs



Santosh,

I conclude that we are in complete and total agreement.
The question is how to go about this.

Could we do this amendment to RFC 3280 in its next revision?
It would hopefully just be a minor change.

It would not change the definition of AIA just add that it can be used also
as CRL extension and list eventual restrictions and guidance for use with
CRLs.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 13 oktober 2004 04:33
> To: 'pkix'
> Subject: RE: Signer certificate discovery for CRLs
>
>
> Stefan:
>
> In terms of certificate discovery, your proposal for AIA in CRL is more
> robust.  The whole idea of self-issued key rollover certificates and then
> using the new key to issue CRL is fraught with security problems.  A
> secure
> solution would be one where the new key is certified by the parent CA.  In
> that case to obtain the new certificate, you could use AIA in CRL.
>
> As to indirect CRL, your proposal is a good one.  The CRL DP in
> certificate
> in question points to the indirect CRL.  You get that CRL.  The AIA in CRL
> gets you started for the indirect CRL issuer certification path and you
> are
> in business.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, October 12, 2004 7:30 PM
> To: David A. Cooper
> Cc: pkix
> Subject: RE: Signer certificate discovery for CRLs
>
>
>
> David,
>
> Thanks for the clarifications, they make sense.
> I did misread your pictures.
>
> So can we conclude that for a re-keyed CA in accordance with RFC 3280,
> either the CRL issuer certificate itself, or the location of the CRL
> issuer
> certificate, will be clearly identified/available for the validating party
> in some cases, but not in others?
>
> Can we also conclude that there is no real discovery solution for indirect
> CRLs?
>
> Do you then agree then that it could be appropriate to allow AIA as a CRL
> extension to facilitate discovery of CRL signer certificate?
>
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>
> ________________________________________
> From: David A. Cooper [mailto:[e-mail]]
> Sent: den 12 oktober 2004 21:14
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
>
> Stefan,
>
> I believe that you are misinterpreting the figures. They really do
> represent three different cases, not three different certification paths
> that have been constructed through the same PKI architecture.
>
> In figure 1, CA 1 has generated self-issued key rollover certificates.
> The
> Root CA has issued a certificate to CA 1's new key, but not its old key
> (either the Root CA never issued a certificate to CA 1's old key or that
> certificate has expired).
>
> In figure 2, CA 2 has also generated self-issued key rollover
> certificates.
> The Root CA has issued a certificate to CA 2's old key, but not its new
> key.
>
> In figure 3, when CA 3 performed key rollover, it requested a new CA
> certificate from the Root CA. CA 3 did not generated self-issued key
> rollover certificates.
>
> Of course, another realistic scenario would be one in which a CA generated
> self-issued key rollover certificates upon key rollover and then had the
> Root CA issue a CA certificate to its new key. In this case, as you
> suggest, any of the certification paths from figures 1, 2, or 3 could be
> constructed.
>
> As for the contents of the AIA extension, here is what I have specified in
> the "X.509 Certificate and CRL Extensions Profile for the Common Policy":
>
> The authorityInfoAccess extension uses URIs for two purposes. When the
> id-ad-caIssuers access method is used, the access location specifies where
> certificates issued to the issuer of the certificate may be found. If LDAP
> is used, the URI must include the DN of the entry containing the relevant
> certificates and specify the directory attribute in which the certificates
> are located. If the directory in which the certificates are stored expects
> the "binary" option to be specified, then the attribute type must be
> followed by ";binary" in the URI. If HTTP is used, the URI must point to a
> file that has an extension of ".p7c" that contains a certs-only CMS
> message
> (see RFC 2633). The CMS message should include all certificates issued to
> the issuer of this certificate, but must at least contain all certificates
> issued to the issuer of this certificate in which the subject public key
> may
> be used to verify the signature on this certificate. .... For a
> certificate
> issued by "Good CA", some examples of URIs that may appear as the access
> location in an authorityInfoAccess extension when the id-ad-caIssuers
> access
> method is used are:
> ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifica
> te
> ,crossCertificatePair
> ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertificate;b
> in
> ary,crossCertificatePair;binary
> http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssuedToGo
> od
> CA.p7c
> For both LDAP and HTTP, the URI provides the exact location where
> information is to be located, so there is no requirement for the relying
> party to try to figure out where information is located.
>
> The HTTP URI points to a certs-only CMS message that includes all
> certificates issued to the CA identified in the issuer field of the
> certificate.
>
> The LDAP URI points to the cACertificate and crossCertificatePair
> attributes
> of the directory entry of the CA identified in the issuer field of the
> certificate. These two attributes together hold all of the certificates
> issued to the CA: the cACertificate attribute holds the CA's self-issued
> certificates and the crossCertificatePair attribute holds the
> cross-certificates issued to the CA by other CAs.
>
> Dave
>
>
> Stefan Santesson wrote:
>
> David,
>
> Thanks for these good thoughts and very useful scenarios.
>
> I have some comments and questions on this.
>
> First of all we can conclude that in some scenarios (figure 1) where a
> self
> issued certificate is inserted into the path, you are likely to find the
> CRL
> issuer cert in the path. (given that the new CA have a common key and
> certificate for cert signing and CRL signing).
>
> Figure 1, 2 and 3 describe the same case. It is just describing different
> path building strategies. An application that has access locally to all
> chaining options may however still choose path 2 for the certs and path 1
> for the CRL independent of each other (which I think figure 3 tries to
> describe)
>
> Another comment is the structure of AIA extensions. The use I'm familiar
> with doesn't use AIA to describe a directory entry where it is left to the
> validation application logic to be intelligent enough to find appropriate
> certificate data from the directory. The model I'm familiar with is when
> the
> AIA URL explicitly identifies the exact location of the appropriate CA
> certificate file, relieving the validation software from complex
> information
> queries. If just location of explicit certificate files are identified
> through AIA, the presence of an AIA may not help finding the CRL signer
> cert
> if this is different from the CA certificate. This is also the problem
> with
> Denis proposal.
>
> I think we share the basic conclusion that the ability to locate the CRL
> signer certificate directly through the CRL could be very useful. At least
> in the case of indirect CRL but it could also be proven very useful in CA
> re-keying scenarios.
>
> The easiest solution would probably be to allow AIA to be used in its
> current shape and structure as a CRL extension (MUST NOT be critical). It
> would present a very clear and uncomplicated logic to certificate
> validating
> applications in many cases.
>
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>
> ________________________________________
> From: David A. Cooper [mailto:[e-mail]]
> Sent: den 7 oktober 2004 18:35
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
>
> Stefan,
>
> I think what you are proposing is a good idea. In most cases, path
> discovery algorithms assume that both the trust anchor (or trust anchors)
> and the end entity certificate are provided as input. In this case, one
> may
> need to construct a certification path without a priori access to the end
> entity certificate (the one with the subject public key corresponding to
> the
> CRL signing key). Including an AIA extension (or some other pointer) in
> the
> CRL would provide the relying party with a simple way to obtain the end
> entity certificate for the CRL signing key's certification path. On the
> other hand, I believe that a relying party should be able to construct the
> certification path even without an AIA extension in the CRL, so long as it
> is not an indirect CRL. Attached is a drawing of the three basic
> scenarios
> that I expect a relying party may encounter:
>
> In each of these scenarios, the CA has performed key rollover and is only
> signing CRLs with its new key. The diagrams would look similar, however,
> if
> the CA simply choose to use different keys to sign certificates and CRLs
> for
> some other reason.
>
> If the PKI architecture resembled figure 1, then the certification path
> for
> the CRL signing key would just be a subset of the certification path for
> the
> EE certificate, so no addition path discovery would be needed.
>
> If the PKI architecture resembled figure 1, then it would be necessary to
> obtain the new-signed-with-old self-issued certificate. In building the
> certification path to the EE certificate, however, the relying party will
> obtain the certificates pointed to by the AIA extension in the EE
> certificate. This AIA extension will point to a location containing all
> certificates issued to CA 2, which would include both the certificate
> issued
> by the Root to CA 2 and CA 2's self-issued certificate. So, even though
> the
> self-issued certificate would not be part of the certification path to the
> EE certificate, it would be downloaded by the relying party during the
> construction of that certification path. (Yes, there are circular
> dependency issues in figure 2, but that is another issue.)
>
> A similar situation would happen if the PKI architecture resembled figure
> 3. The AIA extension in the EE certificate would point to a location
> containing certificates issued to CA 3. When the relying party downloaded
> these certificates, it would obtain both of the certificates issued by the
> Root to CA 3 and so again would have the certificate needed to validate
> the
> CRL signing key.
>
> In the case of an indirect CRL, things may not work as well. If indirect
> CRLs were used, and the PKI architecture resembled figures 2 or 3
> (replacing
> "New Key" with a different CA), then the set of certificates pointed to by
> the AIA extension in the EE certificate would not include the certificate
> of
> the CRL signer. One could find this certificate by building in the
> reverse
> direction and using the SIA extension, but that may not be the most
> convenient solution.
>
> So, when indirect CRLs are being used, it seems that it would be very
> useful
> to have a pointer in the CRL to the CRL signing certificate. When the CRL
> is not indirect, the need for this pointer does not seem to be as clear,
> but
> I can't see any harm in including it.
>
> Dave
>
> Stefan Santesson wrote:
> All,
>
> I'm interested in the opinion from members on this list about discovery of
> CRL signer's certificate in non directory centric environments.
>
> The problem is the following.
>
> The relying party (RP) needs to check validity of a certificate and finds
> a
> CDP extension with a URL to the CRL. The RP retrieves this CRL which in
> this
> particular case is either signed by another key of the CA (re-keyed CA) or
> another entity (indirect CRL).
>
> In this case the relying party needs to obtain the certificate of the CRL
> signer which may NOT be part of the original chain. In a directory centric
> solution this is retrieved from the directory, but what if such directory
> is
> not available or accessible.
>
> The RP have thus no hint where to find the CRL issuers certificate unless
> the RP already have possession of it by some other means.
>
> Is seems that CRLs would need an AIA extension with the option to point to
> the location of the signers certificate in the same manner as is possible
> for certificates.
>
> Maybe AIA should be defined as both cert and CRL extension and not only
> certificate extension as today.
>
> Thoughts and comments?
>
> 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 i9E0eN1P069520; Wed, 13 Oct 2004 17:40:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9E0eNIu069519; Wed, 13 Oct 2004 17:40:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9E0eM8Q069499 for <[e-mail]>; Wed, 13 Oct 2004 17:40:22 -0700 (PDT) (envelope-from [e-mail])
Received: from [172.0.0.1] ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Oct 2004 19:40:41 -0500
Received: from no.name.available by [172.0.0.1] via smtpd (for [200.57.34.107] [200.57.34.107]) with ESMTP; Wed, 13 Oct 2004 19:36:47 -0600
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: current version of CMP?
Date: Wed, 13 Oct 2004 19:36:25 -0500
Message-ID: <004c01c4b185$d633eb30$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C4B15B.ED5DE330"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Importance: Normal
X-OriginalArrivalTime: 14 Oct 2004 00:40:41.0718 (UTC) FILETIME=[6EE0D960:01C4B186]
Sender: [e-mail]
Precedence: 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_004D_01C4B15B.ED5DE330
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Is there a current version of the draft for CMP?
I mean both draft-ietf-pkix-rfc2510bis-09.txt and the one covering the
transports
 
thanks,
 
Miguel Rodriguez
SeguriData

------=_NextPart_000_004D_01C4B15B.ED5DE330
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.2800.1458" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D625103400-14102004>Is =
there=20
a&nbsp;current version of the draft for CMP?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D625103400-14102004>I mean =
both=20
draft-ietf-pkix-rfc2510bis-09.txt and the one covering the=20
transports</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D625103400-14102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D625103400-14102004>thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D625103400-14102004><FONT face=3DArial size=3D2>Miguel =

Rodriguez</FONT></SPAN></DIV>
<DIV><SPAN class=3D625103400-14102004><FONT face=3DArial=20
size=3D2>SeguriData</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_004D_01C4B15B.ED5DE330--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DLpRih047611; Wed, 13 Oct 2004 14:51:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DLpRje047610; Wed, 13 Oct 2004 14:51:27 -0700 (PDT)
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 i9DLpRUO047599 for <[e-mail]>; Wed, 13 Oct 2004 14:51:27 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (PPP-219.65.35.80.mum2.vsnl.net.in [219.65.35.80]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9DLpQfn005007 for <[e-mail]>; Wed, 13 Oct 2004 17:51:36 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Wed, 13 Oct 2004 17:51:21 -0400
Message-ID: <00b601c4b16e$d2aeda90$[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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9DLpRUO047604
Sender: [e-mail]
Precedence: 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:

Two examples are very simple: one for direct CRL Issuer and one for Indirect
CRL Issuer.

Let us make the following assumptions that Stefan was making:

1.  You are directory challenged; and
2.  You use AIA to develop the path; and
3.  You develop the path from the end entity to trust anchor.

>From what I know of MS CAPI, these are reasonable assumptions/constraints.

Now the examples.

Example 1: Direct CRL Issuer

The certificate trust path is:
Root --> CA1 --> CA 2, old key --> Denis

The CRL trust path is:
Root --> CA1 --> CA 2, new key --> CRL

(Note: We do not do self-issued certificate since there is no simple, secure
way to check their revocation status).

Now, with AIA in CRL, finding the CA2, new key certificate is
straightforward.  How would you find it if you do no deal with SIA et. al.

Example 2: Indirect CRL Issuer

The certificate trust path is:
Root --> CA1 --> CA 2 --> Denis
(Note: Denis's certificate points to CRL DP of an indirect CRL issued by
CAI.

The CRL trust path is:
Root --> CAI --> CRL

Now, with AIA in CRL, finding the CAI certificate is straightforward.  How
would you find it if you do no deal with SIA et. al.

In addition to the need cited above, please note that the extension
semantics does not change, it does not hinder any interoperability, and it
does not break any backward compatibility.  So, what if I wanted to use this
extension in the CRL.  It does no harm to other relying parties.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Wednesday, October 13, 2004 11:01 AM
To: Stefan Santesson
Cc: Santosh Chokhani; pkix
Subject: Re: Signer certificate discovery for CRLs



Stefan,

> Denis,

> I'm not sure what you mean.

For the time being, I would like that you provide an example where, when 
using the current extensions that are defined in RFC 3280, it will NOT be 
possible to locate a CRL Issuer certificate.

If you are able to provide that example, then it would justify the need for 
an extension at least for one case. Then we can see what that case is.

I am awaiting that example.

Denis


> I conclude that I agree with Santosh.
> 
> The debate is still open... Feel free to express your opinion.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: den 13 oktober 2004 16:34
>>To: Stefan Santesson
>>Cc: Santosh Chokhani; pkix
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>Stefan,
>>
>>You are making a conclusion without letting me the time to respond. I
>>will need more time to look at the pictures (and understand them).
>>
>>For the time being, I am still reluctant to accept
> 
> "yet-another-method".
> 
>>We already have too many.
>>
>>
>>>Santosh,
>>>
>>>I conclude that we are in complete and total agreement.
>>>The question is how to go about this.
>>
>>>Could we do this amendment to RFC 3280 in its next revision? It would
>>>hopefully just be a minor change.
>>
>>This is exactly what I feared.
>>
>>We usually end-up with a "minor change" in an extension without saying
>>cleary how and when it shall/should be used.
>>
>>I still have in mind that:
>>
>>  1) a certification path must first be constructed,
>>  2) then the revocation checking of that path must be done.
>>
>>This means that information about CRL issuers certificates locations
> 
> may
> 
>>certainly be found in that chain. If not, I would like an example.
>>
>>Denis
>>
>>
>>
>>>It would not change the definition of AIA just add that it can be
>>
> used
> 
>>also as CRL extension and list eventual restrictions and guidance for
> 
> use
> 
>>with CRLs.
>>
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>
> [mailto:[e-mail]]
> 
>>>>On Behalf Of Santosh Chokhani
>>>>Sent: den 13 oktober 2004 04:33
>>>>To: 'pkix'
>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>
>>>>
>>>>Stefan:
>>>>
>>>>In terms of certificate discovery, your proposal for AIA in CRL is
>>>
> more
> 
>>>>robust.  The whole idea of self-issued key rollover certificates and
>>>
>>then
>>
>>>>using the new key to issue CRL is fraught with security problems.  A
>>>>secure solution would be one where the new key is certified by the 
>>>>parent
>>>
> CA.
> 
>>In
>>
>>>>that case to obtain the new certificate, you could use AIA in CRL.
>>>>
>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
>>>>certificate in question points to the indirect CRL.  You get that 
>>>>CRL.  The AIA
>>>
> in
> 
>>CRL
>>
>>>>gets you started for the indirect CRL issuer certification path and
>>>
> you
> 
>>>>are
>>>>in business.
>>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>
> [mailto:[e-mail]]
> 
>>>>On
>>>>Behalf Of Stefan Santesson
>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>To: David A. Cooper
>>>>Cc: pkix
>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>
>>>>
>>>>
>>>>David,
>>>>
>>>>Thanks for the clarifications, they make sense.
>>>>I did misread your pictures.
>>>>
>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>
> 3280,
> 
>>>>either the CRL issuer certificate itself, or the location of the CRL
>>>>issuer certificate, will be clearly identified/available for the 
>>>>validating
>>>
>>party
>>
>>>>in some cases, but not in others?
>>>>
>>>>Can we also conclude that there is no real discovery solution for
>>>
>>indirect
>>
>>>>CRLs?
>>>>
>>>>Do you then agree then that it could be appropriate to allow AIA as
>>>
> a
> 
>>CRL
>>
>>>>extension to facilitate discovery of CRL signer certificate?
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>________________________________________
>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>Sent: den 12 oktober 2004 21:14
>>>>To: Stefan Santesson
>>>>Cc: pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>Stefan,
>>>>
>>>>I believe that you are misinterpreting the figures.  They really do
>>>>represent three different cases, not three different certification
>>>
> paths
> 
>>>>that have been constructed through the same PKI architecture.
>>>>
>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>
> certificates.
> 
>>>>The
>>>>Root CA has issued a certificate to CA 1's new key, but not its old
>>>
> key
> 
>>>>(either the Root CA never issued a certificate to CA 1's old key or
>>>
> that
> 
>>>>certificate has expired).
>>>>
>>>>In figure 2, CA 2 has also generated self-issued key rollover
>>>>certificates. The Root CA has issued a certificate to CA 2's old 
>>>>key, but not its
>>>
> new
> 
>>>>key.
>>>>
>>>>In figure 3, when CA 3 performed key rollover, it requested a new CA
>>>>certificate from the Root CA.  CA 3 did not generated self-issued
>>>
> key
> 
>>>>rollover certificates.
>>>>
>>>>Of course, another realistic scenario would be one in which a CA
>>>
>>generated
>>
>>>>self-issued key rollover certificates upon key rollover and then had
>>>
> the
> 
>>>>Root CA issue a CA certificate to its new key.  In this case, as you
>>>>suggest, any of the certification paths from figures 1, 2, or 3
>>>
> could be
> 
>>>>constructed.
>>>>
>>>>As for the contents of the AIA extension, here is what I have
>>>
> specified
> 
>>in
>>
>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>
>>Policy":
>>
>>>>The authorityInfoAccess extension uses URIs for two purposes. When
>>>
> the
> 
>>>>id-ad-caIssuers access method is used, the access location specifies
>>>
>>where
>>
>>>>certificates issued to the issuer of the certificate may be found.
>>>
> If
> 
>>LDAP
>>
>>>>is used, the URI must include the DN of the entry containing the
>>>
>>relevant
>>
>>>>certificates and specify the directory attribute in which the
>>>
>>certificates
>>
>>>>are located. If the directory in which the certificates are stored
>>>
>>expects
>>
>>>>the "binary" option to be specified, then the attribute type must be
>>>>followed by ";binary" in the URI. If HTTP is used, the URI must
>>>
> point to
> 
>>a
>>
>>>>file that has an extension of ".p7c" that contains a certs-only CMS
>>>>message (see RFC 2633). The CMS message should include all 
>>>>certificates
>>>
> issued
> 
>>to
>>
>>>>the issuer of this certificate, but must at least contain all
>>>
>>certificates
>>
>>>>issued to the issuer of this certificate in which the subject public
>>>
> key
> 
>>>>may
>>>>be used to verify the signature on this certificate. .... For a
>>>>certificate issued by "Good CA", some examples of URIs that may 
>>>>appear as the
>>>
> access
> 
>>>>location in an authorityInfoAccess extension when the
>>>
> id-ad-caIssuers
> 
>>>>access
>>>>method is used are:
>>>
>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACert
>>>i
>>
> fi
> 
>>ca
>>
>>>>te
>>>>,crossCertificatePair
>>>
>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertific
>>>a
>>
> te
> 
>>;b
>>
>>>>in
>>>>ary,crossCertificatePair;binary
>>>
>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssue
>>>d
>>
> To
> 
>>Go
>>
>>>>od
>>>>CA.p7c
>>>>For both LDAP and HTTP, the URI provides the exact location where
>>>>information is to be located, so there is no requirement for the
>>>
> relying
> 
>>>>party to try to figure out where information is located.
>>>>
>>>>The HTTP URI points to a certs-only CMS message that includes all
>>>>certificates issued to the CA identified in the issuer field of the 
>>>>certificate.
>>>>
>>>>The LDAP URI points to the cACertificate and crossCertificatePair
>>>>attributes of the directory entry of the CA identified in the issuer 
>>>>field of
>>>
> the
> 
>>>>certificate.  These two attributes together hold all of the
>>>
> certificates
> 
>>>>issued to the CA:  the cACertificate attribute holds the CA's self-
>>>
>>issued
>>
>>>>certificates and the crossCertificatePair attribute holds the
>>>>cross-certificates issued to the CA by other CAs.
>>>>
>>>>Dave
>>>>
>>>>
>>>>Stefan Santesson wrote:
>>>>
>>>>David,
>>>>
>>>>Thanks for these good thoughts and very useful scenarios.
>>>>
>>>>I have some comments and questions on this.
>>>>
>>>>First of all we can conclude that in some scenarios (figure 1) where
>>>
> a
> 
>>>>self
>>>>issued certificate is inserted into the path, you are likely to find
>>>
> the
> 
>>>>CRL
>>>>issuer cert in the path. (given that the new CA have a common key
>>>
> and
> 
>>>>certificate for cert signing and CRL signing).
>>>>
>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>
>>different
>>
>>>>path building strategies. An application that has access locally to
>>>
> all
> 
>>>>chaining options may however still choose path 2 for the certs and
>>>
> path
> 
>>1
>>
>>>>for the CRL independent of each other (which I think figure 3 tries
>>>
> to
> 
>>>>describe)
>>>>
>>>>Another comment is the structure of AIA extensions. The use I'm
>>>
> familiar
> 
>>>>with doesn't use AIA to describe a directory entry where it is left
>>>
> to
> 
>>the
>>
>>>>validation application logic to be intelligent enough to find
>>>
>>appropriate
>>
>>>>certificate data from the directory. The model I'm familiar with is
>>>
> when
> 
>>>>the
>>>>AIA URL explicitly identifies the exact location of the appropriate
>>>
> CA
> 
>>>>certificate file, relieving the validation software from complex
>>>>information queries. If just location of explicit certificate files 
>>>>are
>>>
> identified
> 
>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>
> signer
> 
>>>>cert
>>>>if this is different from the CA certificate. This is also the
>>>
> problem
> 
>>>>with
>>>>Denis proposal.
>>>>
>>>>I think we share the basic conclusion that the ability to locate the
>>>
> CRL
> 
>>>>signer certificate directly through the CRL could be very useful. At
>>>
>>least
>>
>>>>in the case of indirect CRL but it could also be proven very useful
>>>
> in
> 
>>CA
>>
>>>>re-keying scenarios.
>>>>
>>>>The easiest solution would probably be to allow AIA to be used in
>>>
> its
> 
>>>>current shape and structure as a CRL extension (MUST NOT be
>>>
> critical).
> 
>>It
>>
>>>>would present a very clear and uncomplicated logic to certificate
>>>>validating applications in many cases.
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>________________________________________
>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>Sent: den 7 oktober 2004 18:35
>>>>To: Stefan Santesson
>>>>Cc: pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>Stefan,
>>>>
>>>>I think what you are proposing is a good idea.  In most cases, path
>>>>discovery algorithms assume that both the trust anchor (or trust
>>>
>>anchors)
>>
>>>>and the end entity certificate are provided as input.  In this case,
>>>
> one
> 
>>>>may
>>>>need to construct a certification path without a priori access to
>>>
> the
> 
>>end
>>
>>>>entity certificate (the one with the subject public key
>>>
> corresponding to
> 
>>>>the
>>>>CRL signing key).  Including an AIA extension (or some other
>>>
> pointer) in
> 
>>>>the
>>>>CRL would provide the relying party with a simple way to obtain the
>>>
> end
> 
>>>>entity certificate for the CRL signing key's certification path. On
>>>
> the
> 
>>>>other hand, I believe that a relying party should be able to
>>>
> construct
> 
>>the
>>
>>>>certification path even without an AIA extension in the CRL, so long
>>>
> as
> 
>>it
>>
>>>>is not an indirect CRL.  Attached is a drawing of the three basic
>>>>scenarios that I expect a relying party may encounter:
>>>>
>>>>In each of these scenarios, the CA has performed key rollover and is
>>>
>>only
>>
>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>
>>however,
>>
>>>>if
>>>>the CA simply choose to use different keys to sign certificates and
>>>
> CRLs
> 
>>>>for
>>>>some other reason.
>>>>
>>>>If the PKI architecture resembled figure 1, then the certification
>>>
> path
> 
>>>>for
>>>>the CRL signing key would just be a subset of the certification path
>>>
> for
> 
>>>>the
>>>>EE certificate, so no addition path discovery would be needed.
>>>>
>>>>If the PKI architecture resembled figure 1, then it would be
>>>
> necessary
> 
>>to
>>
>>>>obtain the new-signed-with-old self-issued certificate.  In building
>>>
> the
> 
>>>>certification path to the EE certificate, however, the relying party
>>>
>>will
>>
>>>>obtain the certificates pointed to by the AIA extension in the EE
>>>>certificate.  This AIA extension will point to a location containing
>>>
> all
> 
>>>>certificates issued to CA 2, which would include both the
>>>
> certificate
> 
>>>>issued
>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
>>>
> though
> 
>>>>the
>>>>self-issued certificate would not be part of the certification path
>>>
> to
> 
>>the
>>
>>>>EE certificate, it would be downloaded by the relying party during
>>>
> the
> 
>>>>construction of that certification path.  (Yes, there are circular
>>>>dependency issues in figure 2, but that is another issue.)
>>>>
>>>>A similar situation would happen if the PKI architecture resembled
>>>
>>figure
>>
>>>>3.  The AIA extension in the EE certificate would point to a
>>>
> location
> 
>>>>containing certificates issued to CA 3.  When the relying party
>>>
>>downloaded
>>
>>>>these certificates, it would obtain both of the certificates issued
>>>
> by
> 
>>the
>>
>>>>Root to CA 3 and so again would have the certificate needed to
>>>
> validate
> 
>>>>the
>>>>CRL signing key.
>>>>
>>>>In the case of an indirect CRL, things may not work as well.  If
>>>
>>indirect
>>
>>>>CRLs were used, and the PKI architecture resembled figures 2 or 3
>>>>(replacing "New Key" with a different CA), then the set of 
>>>>certificates pointed
>>>
> to
> 
>>by
>>
>>>>the AIA extension in the EE certificate would not include the
>>>
>>certificate
>>
>>>>of
>>>>the CRL signer.  One could find this certificate by building in the
>>>>reverse direction and using the SIA extension, but that may not be 
>>>>the most convenient solution.
>>>>
>>>>So, when indirect CRLs are being used, it seems that it would be
>>>
> very
> 
>>>>useful
>>>>to have a pointer in the CRL to the CRL signing certificate.  When
>>>
> the
> 
>>CRL
>>
>>>>is not indirect, the need for this pointer does not seem to be as
>>>
> clear,
> 
>>>>but
>>>>I can't see any harm in including it.
>>>>
>>>>Dave
>>>>
>>>>Stefan Santesson wrote:
>>>>All,
>>>>
>>>>I'm interested in the opinion from members on this list about
>>>
> discovery
> 
>>of
>>
>>>>CRL signer's certificate in non directory centric environments.
>>>>
>>>>The problem is the following.
>>>>
>>>>The relying party (RP) needs to check validity of a certificate and
>>>
>>finds
>>
>>>>a
>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL which
>>>
> in
> 
>>>>this
>>>>particular case is either signed by another key of the CA (re-keyed
>>>
> CA)
> 
>>or
>>
>>>>another entity (indirect CRL).
>>>>
>>>>In this case the relying party needs to obtain the certificate of
>>>
> the
> 
>>CRL
>>
>>>>signer which may NOT be part of the original chain. In a directory
>>>
>>centric
>>
>>>>solution this is retrieved from the directory, but what if such
>>>
>>directory
>>
>>>>is
>>>>not available or accessible.
>>>>
>>>>The RP have thus no hint where to find the CRL issuers certificate
>>>
>>unless
>>
>>>>the RP already have possession of it by some other means.
>>>>
>>>>Is seems that CRLs would need an AIA extension with the option to
>>>
> point
> 
>>to
>>
>>>>the location of the signers certificate in the same manner as is
>>>
>>possible
>>
>>>>for certificates.
>>>>
>>>>Maybe AIA should be defined as both cert and CRL extension and not
>>>
> only
> 
>>>>certificate extension as today.
>>>>
>>>>Thoughts and comments?
>>>>
>>>>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 i9DHA1Vj007523; Wed, 13 Oct 2004 10:10:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DHA1IO007522; Wed, 13 Oct 2004 10:10:01 -0700 (PDT)
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 i9DH9wC4007489 for <[e-mail]>; Wed, 13 Oct 2004 10:09:59 -0700 (PDT) (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.0); Wed, 13 Oct 2004 18:10:15 +0100
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: Signer certificate discovery for CRLs
Date: Wed, 13 Oct 2004 18:07:05 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcSxNZFjjfYqtyNVQ0Cg72gmLfwAOwAEX+QX
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Santosh Chokhani" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 13 Oct 2004 17:10:15.0252 (UTC) FILETIME=[81D96940:01C4B147]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9DH9xC4007507
Sender: [e-mail]
Precedence: 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 think David Cooper has done a prime good job on that in his postings to the list.
 
I also think Santosh has made good effort to justify the need, especially for indirect CRLs.
 
Tell me what you miss and I'll try to fill in.
 
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

________________________________

From: Denis Pinkas [mailto:[e-mail]]
Sent: Wed 10/13/2004 5:01 PM
To: Stefan Santesson
Cc: Santosh Chokhani; pkix
Subject: Re: Signer certificate discovery for CRLs



Stefan,

> Denis,

> I'm not sure what you mean.

For the time being, I would like that you provide an example where, when
using the current extensions that are defined in RFC 3280, it will NOT be
possible to locate a CRL Issuer certificate.

If you are able to provide that example, then it would justify the need for
an extension at least for one case. Then we can see what that case is.

I am awaiting that example.

Denis


> I conclude that I agree with Santosh.
>
> The debate is still open... Feel free to express your opinion.
>
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
>
>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: den 13 oktober 2004 16:34
>>To: Stefan Santesson
>>Cc: Santosh Chokhani; pkix
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>Stefan,
>>
>>You are making a conclusion without letting me the time to respond.
>>I will need more time to look at the pictures (and understand them).
>>
>>For the time being, I am still reluctant to accept
>
> "yet-another-method".
>
>>We already have too many.
>>
>>
>>>Santosh,
>>>
>>>I conclude that we are in complete and total agreement.
>>>The question is how to go about this.
>>
>>>Could we do this amendment to RFC 3280 in its next revision?
>>>It would hopefully just be a minor change.
>>
>>This is exactly what I feared.
>>
>>We usually end-up with a "minor change" in an extension without saying
>>cleary how and when it shall/should be used.
>>
>>I still have in mind that:
>>
>>  1) a certification path must first be constructed,
>>  2) then the revocation checking of that path must be done.
>>
>>This means that information about CRL issuers certificates locations
>
> may
>
>>certainly be found in that chain. If not, I would like an example.
>>
>>Denis
>>
>>
>>
>>>It would not change the definition of AIA just add that it can be
>>
> used
>
>>also as CRL extension and list eventual restrictions and guidance for
>
> use
>
>>with CRLs.
>>
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>
> [mailto:[e-mail]]
>
>>>>On Behalf Of Santosh Chokhani
>>>>Sent: den 13 oktober 2004 04:33
>>>>To: 'pkix'
>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>
>>>>
>>>>Stefan:
>>>>
>>>>In terms of certificate discovery, your proposal for AIA in CRL is
>>>
> more
>
>>>>robust.  The whole idea of self-issued key rollover certificates and
>>>
>>then
>>
>>>>using the new key to issue CRL is fraught with security problems.  A
>>>>secure
>>>>solution would be one where the new key is certified by the parent
>>>
> CA.
>
>>In
>>
>>>>that case to obtain the new certificate, you could use AIA in CRL.
>>>>
>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
>>>>certificate
>>>>in question points to the indirect CRL.  You get that CRL.  The AIA
>>>
> in
>
>>CRL
>>
>>>>gets you started for the indirect CRL issuer certification path and
>>>
> you
>
>>>>are
>>>>in business.
>>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>
> [mailto:[e-mail]]
>
>>>>On
>>>>Behalf Of Stefan Santesson
>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>To: David A. Cooper
>>>>Cc: pkix
>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>
>>>>
>>>>
>>>>David,
>>>>
>>>>Thanks for the clarifications, they make sense.
>>>>I did misread your pictures.
>>>>
>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>
> 3280,
>
>>>>either the CRL issuer certificate itself, or the location of the CRL
>>>>issuer
>>>>certificate, will be clearly identified/available for the validating
>>>
>>party
>>
>>>>in some cases, but not in others?
>>>>
>>>>Can we also conclude that there is no real discovery solution for
>>>
>>indirect
>>
>>>>CRLs?
>>>>
>>>>Do you then agree then that it could be appropriate to allow AIA as
>>>
> a
>
>>CRL
>>
>>>>extension to facilitate discovery of CRL signer certificate?
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>________________________________________
>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>Sent: den 12 oktober 2004 21:14
>>>>To: Stefan Santesson
>>>>Cc: pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>Stefan,
>>>>
>>>>I believe that you are misinterpreting the figures.  They really do
>>>>represent three different cases, not three different certification
>>>
> paths
>
>>>>that have been constructed through the same PKI architecture.
>>>>
>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>
> certificates.
>
>>>>The
>>>>Root CA has issued a certificate to CA 1's new key, but not its old
>>>
> key
>
>>>>(either the Root CA never issued a certificate to CA 1's old key or
>>>
> that
>
>>>>certificate has expired).
>>>>
>>>>In figure 2, CA 2 has also generated self-issued key rollover
>>>>certificates.
>>>>The Root CA has issued a certificate to CA 2's old key, but not its
>>>
> new
>
>>>>key.
>>>>
>>>>In figure 3, when CA 3 performed key rollover, it requested a new CA
>>>>certificate from the Root CA.  CA 3 did not generated self-issued
>>>
> key
>
>>>>rollover certificates.
>>>>
>>>>Of course, another realistic scenario would be one in which a CA
>>>
>>generated
>>
>>>>self-issued key rollover certificates upon key rollover and then had
>>>
> the
>
>>>>Root CA issue a CA certificate to its new key.  In this case, as you
>>>>suggest, any of the certification paths from figures 1, 2, or 3
>>>
> could be
>
>>>>constructed.
>>>>
>>>>As for the contents of the AIA extension, here is what I have
>>>
> specified
>
>>in
>>
>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>
>>Policy":
>>
>>>>The authorityInfoAccess extension uses URIs for two purposes. When
>>>
> the
>
>>>>id-ad-caIssuers access method is used, the access location specifies
>>>
>>where
>>
>>>>certificates issued to the issuer of the certificate may be found.
>>>
> If
>
>>LDAP
>>
>>>>is used, the URI must include the DN of the entry containing the
>>>
>>relevant
>>
>>>>certificates and specify the directory attribute in which the
>>>
>>certificates
>>
>>>>are located. If the directory in which the certificates are stored
>>>
>>expects
>>
>>>>the "binary" option to be specified, then the attribute type must be
>>>>followed by ";binary" in the URI. If HTTP is used, the URI must
>>>
> point to
>
>>a
>>
>>>>file that has an extension of ".p7c" that contains a certs-only CMS
>>>>message
>>>>(see RFC 2633). The CMS message should include all certificates
>>>
> issued
>
>>to
>>
>>>>the issuer of this certificate, but must at least contain all
>>>
>>certificates
>>
>>>>issued to the issuer of this certificate in which the subject public
>>>
> key
>
>>>>may
>>>>be used to verify the signature on this certificate. .... For a
>>>>certificate
>>>>issued by "Good CA", some examples of URIs that may appear as the
>>>
> access
>
>>>>location in an authorityInfoAccess extension when the
>>>
> id-ad-caIssuers
>
>>>>access
>>>>method is used are:
>>>
>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACerti
>>
> fi
>
>>ca
>>
>>>>te
>>>>,crossCertificatePair
>>>
>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifica
>>
> te
>
>>;b
>>
>>>>in
>>>>ary,crossCertificatePair;binary
>>>
>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssued
>>
> To
>
>>Go
>>
>>>>od
>>>>CA.p7c
>>>>For both LDAP and HTTP, the URI provides the exact location where
>>>>information is to be located, so there is no requirement for the
>>>
> relying
>
>>>>party to try to figure out where information is located.
>>>>
>>>>The HTTP URI points to a certs-only CMS message that includes all
>>>>certificates issued to the CA identified in the issuer field of the
>>>>certificate.
>>>>
>>>>The LDAP URI points to the cACertificate and crossCertificatePair
>>>>attributes
>>>>of the directory entry of the CA identified in the issuer field of
>>>
> the
>
>>>>certificate.  These two attributes together hold all of the
>>>
> certificates
>
>>>>issued to the CA:  the cACertificate attribute holds the CA's self-
>>>
>>issued
>>
>>>>certificates and the crossCertificatePair attribute holds the
>>>>cross-certificates issued to the CA by other CAs.
>>>>
>>>>Dave
>>>>
>>>>
>>>>Stefan Santesson wrote:
>>>>
>>>>David,
>>>>
>>>>Thanks for these good thoughts and very useful scenarios.
>>>>
>>>>I have some comments and questions on this.
>>>>
>>>>First of all we can conclude that in some scenarios (figure 1) where
>>>
> a
>
>>>>self
>>>>issued certificate is inserted into the path, you are likely to find
>>>
> the
>
>>>>CRL
>>>>issuer cert in the path. (given that the new CA have a common key
>>>
> and
>
>>>>certificate for cert signing and CRL signing).
>>>>
>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>
>>different
>>
>>>>path building strategies. An application that has access locally to
>>>
> all
>
>>>>chaining options may however still choose path 2 for the certs and
>>>
> path
>
>>1
>>
>>>>for the CRL independent of each other (which I think figure 3 tries
>>>
> to
>
>>>>describe)
>>>>
>>>>Another comment is the structure of AIA extensions. The use I'm
>>>
> familiar
>
>>>>with doesn't use AIA to describe a directory entry where it is left
>>>
> to
>
>>the
>>
>>>>validation application logic to be intelligent enough to find
>>>
>>appropriate
>>
>>>>certificate data from the directory. The model I'm familiar with is
>>>
> when
>
>>>>the
>>>>AIA URL explicitly identifies the exact location of the appropriate
>>>
> CA
>
>>>>certificate file, relieving the validation software from complex
>>>>information
>>>>queries. If just location of explicit certificate files are
>>>
> identified
>
>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>
> signer
>
>>>>cert
>>>>if this is different from the CA certificate. This is also the
>>>
> problem
>
>>>>with
>>>>Denis proposal.
>>>>
>>>>I think we share the basic conclusion that the ability to locate the
>>>
> CRL
>
>>>>signer certificate directly through the CRL could be very useful. At
>>>
>>least
>>
>>>>in the case of indirect CRL but it could also be proven very useful
>>>
> in
>
>>CA
>>
>>>>re-keying scenarios.
>>>>
>>>>The easiest solution would probably be to allow AIA to be used in
>>>
> its
>
>>>>current shape and structure as a CRL extension (MUST NOT be
>>>
> critical).
>
>>It
>>
>>>>would present a very clear and uncomplicated logic to certificate
>>>>validating
>>>>applications in many cases.
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>________________________________________
>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>Sent: den 7 oktober 2004 18:35
>>>>To: Stefan Santesson
>>>>Cc: pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>Stefan,
>>>>
>>>>I think what you are proposing is a good idea.  In most cases, path
>>>>discovery algorithms assume that both the trust anchor (or trust
>>>
>>anchors)
>>
>>>>and the end entity certificate are provided as input.  In this case,
>>>
> one
>
>>>>may
>>>>need to construct a certification path without a priori access to
>>>
> the
>
>>end
>>
>>>>entity certificate (the one with the subject public key
>>>
> corresponding to
>
>>>>the
>>>>CRL signing key).  Including an AIA extension (or some other
>>>
> pointer) in
>
>>>>the
>>>>CRL would provide the relying party with a simple way to obtain the
>>>
> end
>
>>>>entity certificate for the CRL signing key's certification path. On
>>>
> the
>
>>>>other hand, I believe that a relying party should be able to
>>>
> construct
>
>>the
>>
>>>>certification path even without an AIA extension in the CRL, so long
>>>
> as
>
>>it
>>
>>>>is not an indirect CRL.  Attached is a drawing of the three basic
>>>>scenarios
>>>>that I expect a relying party may encounter:
>>>>
>>>>In each of these scenarios, the CA has performed key rollover and is
>>>
>>only
>>
>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>
>>however,
>>
>>>>if
>>>>the CA simply choose to use different keys to sign certificates and
>>>
> CRLs
>
>>>>for
>>>>some other reason.
>>>>
>>>>If the PKI architecture resembled figure 1, then the certification
>>>
> path
>
>>>>for
>>>>the CRL signing key would just be a subset of the certification path
>>>
> for
>
>>>>the
>>>>EE certificate, so no addition path discovery would be needed.
>>>>
>>>>If the PKI architecture resembled figure 1, then it would be
>>>
> necessary
>
>>to
>>
>>>>obtain the new-signed-with-old self-issued certificate.  In building
>>>
> the
>
>>>>certification path to the EE certificate, however, the relying party
>>>
>>will
>>
>>>>obtain the certificates pointed to by the AIA extension in the EE
>>>>certificate.  This AIA extension will point to a location containing
>>>
> all
>
>>>>certificates issued to CA 2, which would include both the
>>>
> certificate
>
>>>>issued
>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
>>>
> though
>
>>>>the
>>>>self-issued certificate would not be part of the certification path
>>>
> to
>
>>the
>>
>>>>EE certificate, it would be downloaded by the relying party during
>>>
> the
>
>>>>construction of that certification path.  (Yes, there are circular
>>>>dependency issues in figure 2, but that is another issue.)
>>>>
>>>>A similar situation would happen if the PKI architecture resembled
>>>
>>figure
>>
>>>>3.  The AIA extension in the EE certificate would point to a
>>>
> location
>
>>>>containing certificates issued to CA 3.  When the relying party
>>>
>>downloaded
>>
>>>>these certificates, it would obtain both of the certificates issued
>>>
> by
>
>>the
>>
>>>>Root to CA 3 and so again would have the certificate needed to
>>>
> validate
>
>>>>the
>>>>CRL signing key.
>>>>
>>>>In the case of an indirect CRL, things may not work as well.  If
>>>
>>indirect
>>
>>>>CRLs were used, and the PKI architecture resembled figures 2 or 3
>>>>(replacing
>>>>"New Key" with a different CA), then the set of certificates pointed
>>>
> to
>
>>by
>>
>>>>the AIA extension in the EE certificate would not include the
>>>
>>certificate
>>
>>>>of
>>>>the CRL signer.  One could find this certificate by building in the
>>>>reverse
>>>>direction and using the SIA extension, but that may not be the most
>>>>convenient solution.
>>>>
>>>>So, when indirect CRLs are being used, it seems that it would be
>>>
> very
>
>>>>useful
>>>>to have a pointer in the CRL to the CRL signing certificate.  When
>>>
> the
>
>>CRL
>>
>>>>is not indirect, the need for this pointer does not seem to be as
>>>
> clear,
>
>>>>but
>>>>I can't see any harm in including it.
>>>>
>>>>Dave
>>>>
>>>>Stefan Santesson wrote:
>>>>All,
>>>>
>>>>I'm interested in the opinion from members on this list about
>>>
> discovery
>
>>of
>>
>>>>CRL signer's certificate in non directory centric environments.
>>>>
>>>>The problem is the following.
>>>>
>>>>The relying party (RP) needs to check validity of a certificate and
>>>
>>finds
>>
>>>>a
>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL which
>>>
> in
>
>>>>this
>>>>particular case is either signed by another key of the CA (re-keyed
>>>
> CA)
>
>>or
>>
>>>>another entity (indirect CRL).
>>>>
>>>>In this case the relying party needs to obtain the certificate of
>>>
> the
>
>>CRL
>>
>>>>signer which may NOT be part of the original chain. In a directory
>>>
>>centric
>>
>>>>solution this is retrieved from the directory, but what if such
>>>
>>directory
>>
>>>>is
>>>>not available or accessible.
>>>>
>>>>The RP have thus no hint where to find the CRL issuers certificate
>>>
>>unless
>>
>>>>the RP already have possession of it by some other means.
>>>>
>>>>Is seems that CRLs would need an AIA extension with the option to
>>>
> point
>
>>to
>>
>>>>the location of the signers certificate in the same manner as is
>>>
>>possible
>>
>>>>for certificates.
>>>>
>>>>Maybe AIA should be defined as both cert and CRL extension and not
>>>
> only
>
>>>>certificate extension as today.
>>>>
>>>>Thoughts and comments?
>>>>
>>>>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 i9DF1C3B089168; Wed, 13 Oct 2004 08:01:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DF1CTf089167; Wed, 13 Oct 2004 08:01:12 -0700 (PDT)
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 i9DF1AcT089155 for <[e-mail]>; Wed, 13 Oct 2004 08:01:11 -0700 (PDT) (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 RAA78848; Wed, 13 Oct 2004 17:12:49 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101317011132:677 ; Wed, 13 Oct 2004 17:01:11 +0200 
Message-ID: <[e-mail]>
Date: Wed, 13 Oct 2004 17:01:10 +0200
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]>, pkix <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/10/2004 17:01:11, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/10/2004 17:01:12, Serialize complete at 13/10/2004 17:01:12
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,

> Denis,

> I'm not sure what you mean.

For the time being, I would like that you provide an example where, when 
using the current extensions that are defined in RFC 3280, it will NOT be 
possible to locate a CRL Issuer certificate.

If you are able to provide that example, then it would justify the need for 
an extension at least for one case. Then we can see what that case is.

I am awaiting that example.

Denis


> I conclude that I agree with Santosh.
> 
> The debate is still open... Feel free to express your opinion.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: den 13 oktober 2004 16:34
>>To: Stefan Santesson
>>Cc: Santosh Chokhani; pkix
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>Stefan,
>>
>>You are making a conclusion without letting me the time to respond.
>>I will need more time to look at the pictures (and understand them).
>>
>>For the time being, I am still reluctant to accept
> 
> "yet-another-method".
> 
>>We already have too many.
>>
>>
>>>Santosh,
>>>
>>>I conclude that we are in complete and total agreement.
>>>The question is how to go about this.
>>
>>>Could we do this amendment to RFC 3280 in its next revision?
>>>It would hopefully just be a minor change.
>>
>>This is exactly what I feared.
>>
>>We usually end-up with a "minor change" in an extension without saying
>>cleary how and when it shall/should be used.
>>
>>I still have in mind that:
>>
>>  1) a certification path must first be constructed,
>>  2) then the revocation checking of that path must be done.
>>
>>This means that information about CRL issuers certificates locations
> 
> may
> 
>>certainly be found in that chain. If not, I would like an example.
>>
>>Denis
>>
>>
>>
>>>It would not change the definition of AIA just add that it can be
>>
> used
> 
>>also as CRL extension and list eventual restrictions and guidance for
> 
> use
> 
>>with CRLs.
>>
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>
> [mailto:[e-mail]]
> 
>>>>On Behalf Of Santosh Chokhani
>>>>Sent: den 13 oktober 2004 04:33
>>>>To: 'pkix'
>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>
>>>>
>>>>Stefan:
>>>>
>>>>In terms of certificate discovery, your proposal for AIA in CRL is
>>>
> more
> 
>>>>robust.  The whole idea of self-issued key rollover certificates and
>>>
>>then
>>
>>>>using the new key to issue CRL is fraught with security problems.  A
>>>>secure
>>>>solution would be one where the new key is certified by the parent
>>>
> CA.
> 
>>In
>>
>>>>that case to obtain the new certificate, you could use AIA in CRL.
>>>>
>>>>As to indirect CRL, your proposal is a good one.  The CRL DP in
>>>>certificate
>>>>in question points to the indirect CRL.  You get that CRL.  The AIA
>>>
> in
> 
>>CRL
>>
>>>>gets you started for the indirect CRL issuer certification path and
>>>
> you
> 
>>>>are
>>>>in business.
>>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>
> [mailto:[e-mail]]
> 
>>>>On
>>>>Behalf Of Stefan Santesson
>>>>Sent: Tuesday, October 12, 2004 7:30 PM
>>>>To: David A. Cooper
>>>>Cc: pkix
>>>>Subject: RE: Signer certificate discovery for CRLs
>>>>
>>>>
>>>>
>>>>David,
>>>>
>>>>Thanks for the clarifications, they make sense.
>>>>I did misread your pictures.
>>>>
>>>>So can we conclude that for a re-keyed CA in accordance with RFC
>>>
> 3280,
> 
>>>>either the CRL issuer certificate itself, or the location of the CRL
>>>>issuer
>>>>certificate, will be clearly identified/available for the validating
>>>
>>party
>>
>>>>in some cases, but not in others?
>>>>
>>>>Can we also conclude that there is no real discovery solution for
>>>
>>indirect
>>
>>>>CRLs?
>>>>
>>>>Do you then agree then that it could be appropriate to allow AIA as
>>>
> a
> 
>>CRL
>>
>>>>extension to facilitate discovery of CRL signer certificate?
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>________________________________________
>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>Sent: den 12 oktober 2004 21:14
>>>>To: Stefan Santesson
>>>>Cc: pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>Stefan,
>>>>
>>>>I believe that you are misinterpreting the figures.  They really do
>>>>represent three different cases, not three different certification
>>>
> paths
> 
>>>>that have been constructed through the same PKI architecture.
>>>>
>>>>In figure 1, CA 1 has generated self-issued key rollover
>>>
> certificates.
> 
>>>>The
>>>>Root CA has issued a certificate to CA 1's new key, but not its old
>>>
> key
> 
>>>>(either the Root CA never issued a certificate to CA 1's old key or
>>>
> that
> 
>>>>certificate has expired).
>>>>
>>>>In figure 2, CA 2 has also generated self-issued key rollover
>>>>certificates.
>>>>The Root CA has issued a certificate to CA 2's old key, but not its
>>>
> new
> 
>>>>key.
>>>>
>>>>In figure 3, when CA 3 performed key rollover, it requested a new CA
>>>>certificate from the Root CA.  CA 3 did not generated self-issued
>>>
> key
> 
>>>>rollover certificates.
>>>>
>>>>Of course, another realistic scenario would be one in which a CA
>>>
>>generated
>>
>>>>self-issued key rollover certificates upon key rollover and then had
>>>
> the
> 
>>>>Root CA issue a CA certificate to its new key.  In this case, as you
>>>>suggest, any of the certification paths from figures 1, 2, or 3
>>>
> could be
> 
>>>>constructed.
>>>>
>>>>As for the contents of the AIA extension, here is what I have
>>>
> specified
> 
>>in
>>
>>>>the "X.509 Certificate and CRL Extensions Profile for the Common
>>>
>>Policy":
>>
>>>>The authorityInfoAccess extension uses URIs for two purposes. When
>>>
> the
> 
>>>>id-ad-caIssuers access method is used, the access location specifies
>>>
>>where
>>
>>>>certificates issued to the issuer of the certificate may be found.
>>>
> If
> 
>>LDAP
>>
>>>>is used, the URI must include the DN of the entry containing the
>>>
>>relevant
>>
>>>>certificates and specify the directory attribute in which the
>>>
>>certificates
>>
>>>>are located. If the directory in which the certificates are stored
>>>
>>expects
>>
>>>>the "binary" option to be specified, then the attribute type must be
>>>>followed by ";binary" in the URI. If HTTP is used, the URI must
>>>
> point to
> 
>>a
>>
>>>>file that has an extension of ".p7c" that contains a certs-only CMS
>>>>message
>>>>(see RFC 2633). The CMS message should include all certificates
>>>
> issued
> 
>>to
>>
>>>>the issuer of this certificate, but must at least contain all
>>>
>>certificates
>>
>>>>issued to the issuer of this certificate in which the subject public
>>>
> key
> 
>>>>may
>>>>be used to verify the signature on this certificate. .... For a
>>>>certificate
>>>>issued by "Good CA", some examples of URIs that may appear as the
>>>
> access
> 
>>>>location in an authorityInfoAccess extension when the
>>>
> id-ad-caIssuers
> 
>>>>access
>>>>method is used are:
>>>
>>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACerti
>>
> fi
> 
>>ca
>>
>>>>te
>>>>,crossCertificatePair
>>>
>>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifica
>>
> te
> 
>>;b
>>
>>>>in
>>>>ary,crossCertificatePair;binary
>>>
>>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssued
>>
> To
> 
>>Go
>>
>>>>od
>>>>CA.p7c
>>>>For both LDAP and HTTP, the URI provides the exact location where
>>>>information is to be located, so there is no requirement for the
>>>
> relying
> 
>>>>party to try to figure out where information is located.
>>>>
>>>>The HTTP URI points to a certs-only CMS message that includes all
>>>>certificates issued to the CA identified in the issuer field of the
>>>>certificate.
>>>>
>>>>The LDAP URI points to the cACertificate and crossCertificatePair
>>>>attributes
>>>>of the directory entry of the CA identified in the issuer field of
>>>
> the
> 
>>>>certificate.  These two attributes together hold all of the
>>>
> certificates
> 
>>>>issued to the CA:  the cACertificate attribute holds the CA's self-
>>>
>>issued
>>
>>>>certificates and the crossCertificatePair attribute holds the
>>>>cross-certificates issued to the CA by other CAs.
>>>>
>>>>Dave
>>>>
>>>>
>>>>Stefan Santesson wrote:
>>>>
>>>>David,
>>>>
>>>>Thanks for these good thoughts and very useful scenarios.
>>>>
>>>>I have some comments and questions on this.
>>>>
>>>>First of all we can conclude that in some scenarios (figure 1) where
>>>
> a
> 
>>>>self
>>>>issued certificate is inserted into the path, you are likely to find
>>>
> the
> 
>>>>CRL
>>>>issuer cert in the path. (given that the new CA have a common key
>>>
> and
> 
>>>>certificate for cert signing and CRL signing).
>>>>
>>>>Figure 1, 2 and 3 describe the same case. It is just describing
>>>
>>different
>>
>>>>path building strategies. An application that has access locally to
>>>
> all
> 
>>>>chaining options may however still choose path 2 for the certs and
>>>
> path
> 
>>1
>>
>>>>for the CRL independent of each other (which I think figure 3 tries
>>>
> to
> 
>>>>describe)
>>>>
>>>>Another comment is the structure of AIA extensions. The use I'm
>>>
> familiar
> 
>>>>with doesn't use AIA to describe a directory entry where it is left
>>>
> to
> 
>>the
>>
>>>>validation application logic to be intelligent enough to find
>>>
>>appropriate
>>
>>>>certificate data from the directory. The model I'm familiar with is
>>>
> when
> 
>>>>the
>>>>AIA URL explicitly identifies the exact location of the appropriate
>>>
> CA
> 
>>>>certificate file, relieving the validation software from complex
>>>>information
>>>>queries. If just location of explicit certificate files are
>>>
> identified
> 
>>>>through AIA, the presence of an AIA may not help finding the CRL
>>>
> signer
> 
>>>>cert
>>>>if this is different from the CA certificate. This is also the
>>>
> problem
> 
>>>>with
>>>>Denis proposal.
>>>>
>>>>I think we share the basic conclusion that the ability to locate the
>>>
> CRL
> 
>>>>signer certificate directly through the CRL could be very useful. At
>>>
>>least
>>
>>>>in the case of indirect CRL but it could also be proven very useful
>>>
> in
> 
>>CA
>>
>>>>re-keying scenarios.
>>>>
>>>>The easiest solution would probably be to allow AIA to be used in
>>>
> its
> 
>>>>current shape and structure as a CRL extension (MUST NOT be
>>>
> critical).
> 
>>It
>>
>>>>would present a very clear and uncomplicated logic to certificate
>>>>validating
>>>>applications in many cases.
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>________________________________________
>>>>From: David A. Cooper [mailto:[e-mail]]
>>>>Sent: den 7 oktober 2004 18:35
>>>>To: Stefan Santesson
>>>>Cc: pkix
>>>>Subject: Re: Signer certificate discovery for CRLs
>>>>
>>>>Stefan,
>>>>
>>>>I think what you are proposing is a good idea.  In most cases, path
>>>>discovery algorithms assume that both the trust anchor (or trust
>>>
>>anchors)
>>
>>>>and the end entity certificate are provided as input.  In this case,
>>>
> one
> 
>>>>may
>>>>need to construct a certification path without a priori access to
>>>
> the
> 
>>end
>>
>>>>entity certificate (the one with the subject public key
>>>
> corresponding to
> 
>>>>the
>>>>CRL signing key).  Including an AIA extension (or some other
>>>
> pointer) in
> 
>>>>the
>>>>CRL would provide the relying party with a simple way to obtain the
>>>
> end
> 
>>>>entity certificate for the CRL signing key's certification path. On
>>>
> the
> 
>>>>other hand, I believe that a relying party should be able to
>>>
> construct
> 
>>the
>>
>>>>certification path even without an AIA extension in the CRL, so long
>>>
> as
> 
>>it
>>
>>>>is not an indirect CRL.  Attached is a drawing of the three basic
>>>>scenarios
>>>>that I expect a relying party may encounter:
>>>>
>>>>In each of these scenarios, the CA has performed key rollover and is
>>>
>>only
>>
>>>>signing CRLs with its new key.  The diagrams would look similar,
>>>
>>however,
>>
>>>>if
>>>>the CA simply choose to use different keys to sign certificates and
>>>
> CRLs
> 
>>>>for
>>>>some other reason.
>>>>
>>>>If the PKI architecture resembled figure 1, then the certification
>>>
> path
> 
>>>>for
>>>>the CRL signing key would just be a subset of the certification path
>>>
> for
> 
>>>>the
>>>>EE certificate, so no addition path discovery would be needed.
>>>>
>>>>If the PKI architecture resembled figure 1, then it would be
>>>
> necessary
> 
>>to
>>
>>>>obtain the new-signed-with-old self-issued certificate.  In building
>>>
> the
> 
>>>>certification path to the EE certificate, however, the relying party
>>>
>>will
>>
>>>>obtain the certificates pointed to by the AIA extension in the EE
>>>>certificate.  This AIA extension will point to a location containing
>>>
> all
> 
>>>>certificates issued to CA 2, which would include both the
>>>
> certificate
> 
>>>>issued
>>>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
>>>
> though
> 
>>>>the
>>>>self-issued certificate would not be part of the certification path
>>>
> to
> 
>>the
>>
>>>>EE certificate, it would be downloaded by the relying party during
>>>
> the
> 
>>>>construction of that certification path.  (Yes, there are circular
>>>>dependency issues in figure 2, but that is another issue.)
>>>>
>>>>A similar situation would happen if the PKI architecture resembled
>>>
>>figure
>>
>>>>3.  The AIA extension in the EE certificate would point to a
>>>
> location
> 
>>>>containing certificates issued to CA 3.  When the relying party
>>>
>>downloaded
>>
>>>>these certificates, it would obtain both of the certificates issued
>>>
> by
> 
>>the
>>
>>>>Root to CA 3 and so again would have the certificate needed to
>>>
> validate
> 
>>>>the
>>>>CRL signing key.
>>>>
>>>>In the case of an indirect CRL, things may not work as well.  If
>>>
>>indirect
>>
>>>>CRLs were used, and the PKI architecture resembled figures 2 or 3
>>>>(replacing
>>>>"New Key" with a different CA), then the set of certificates pointed
>>>
> to
> 
>>by
>>
>>>>the AIA extension in the EE certificate would not include the
>>>
>>certificate
>>
>>>>of
>>>>the CRL signer.  One could find this certificate by building in the
>>>>reverse
>>>>direction and using the SIA extension, but that may not be the most
>>>>convenient solution.
>>>>
>>>>So, when indirect CRLs are being used, it seems that it would be
>>>
> very
> 
>>>>useful
>>>>to have a pointer in the CRL to the CRL signing certificate.  When
>>>
> the
> 
>>CRL
>>
>>>>is not indirect, the need for this pointer does not seem to be as
>>>
> clear,
> 
>>>>but
>>>>I can't see any harm in including it.
>>>>
>>>>Dave
>>>>
>>>>Stefan Santesson wrote:
>>>>All,
>>>>
>>>>I'm interested in the opinion from members on this list about
>>>
> discovery
> 
>>of
>>
>>>>CRL signer's certificate in non directory centric environments.
>>>>
>>>>The problem is the following.
>>>>
>>>>The relying party (RP) needs to check validity of a certificate and
>>>
>>finds
>>
>>>>a
>>>>CDP extension with a URL to the CRL. The RP retrieves this CRL which
>>>
> in
> 
>>>>this
>>>>particular case is either signed by another key of the CA (re-keyed
>>>
> CA)
> 
>>or
>>
>>>>another entity (indirect CRL).
>>>>
>>>>In this case the relying party needs to obtain the certificate of
>>>
> the
> 
>>CRL
>>
>>>>signer which may NOT be part of the original chain. In a directory
>>>
>>centric
>>
>>>>solution this is retrieved from the directory, but what if such
>>>
>>directory
>>
>>>>is
>>>>not available or accessible.
>>>>
>>>>The RP have thus no hint where to find the CRL issuers certificate
>>>
>>unless
>>
>>>>the RP already have possession of it by some other means.
>>>>
>>>>Is seems that CRLs would need an AIA extension with the option to
>>>
> point
> 
>>to
>>
>>>>the location of the signers certificate in the same manner as is
>>>
>>possible
>>
>>>>for certificates.
>>>>
>>>>Maybe AIA should be defined as both cert and CRL extension and not
>>>
> only
> 
>>>>certificate extension as today.
>>>>
>>>>Thoughts and comments?
>>>>
>>>>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 i9DEo8p1087915; Wed, 13 Oct 2004 07:50:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEo8Ea087914; Wed, 13 Oct 2004 07:50:08 -0700 (PDT)
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 i9DEo7KQ087881 for <[e-mail]>; Wed, 13 Oct 2004 07:50:07 -0700 (PDT) (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.0); Wed, 13 Oct 2004 15:50:23 +0100
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: Signer certificate discovery for CRLs
Date: Wed, 13 Oct 2004 15:50:35 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcSxMcaBU9SpU9I/RlSGMkvdDwkWtwAAfG7A
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Santosh Chokhani" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 13 Oct 2004 14:50:23.0967 (UTC) FILETIME=[F840EEF0:01C4B133]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9DEo8KQ087900
Sender: [e-mail]
Precedence: 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'm not sure what you mean.
I conclude that I agree with Santosh.

The debate is still open... Feel free to express your opinion.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 13 oktober 2004 16:34
> To: Stefan Santesson
> Cc: Santosh Chokhani; pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> You are making a conclusion without letting me the time to respond.
> I will need more time to look at the pictures (and understand them).
> 
> For the time being, I am still reluctant to accept
"yet-another-method".
> We already have too many.
> 
> > Santosh,
> >
> > I conclude that we are in complete and total agreement.
> > The question is how to go about this.
> 
> > Could we do this amendment to RFC 3280 in its next revision?
> > It would hopefully just be a minor change.
> 
> This is exactly what I feared.
> 
> We usually end-up with a "minor change" in an extension without saying
> cleary how and when it shall/should be used.
> 
> I still have in mind that:
> 
>   1) a certification path must first be constructed,
>   2) then the revocation checking of that path must be done.
> 
> This means that information about CRL issuers certificates locations
may
> certainly be found in that chain. If not, I would like an example.
> 
> Denis
> 
> 
> > It would not change the definition of AIA just add that it can be
used
> also as CRL extension and list eventual restrictions and guidance for
use
> with CRLs.
> >
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >
> >>-----Original Message-----
> >>From: [e-mail]
[mailto:[e-mail]]
> >>On Behalf Of Santosh Chokhani
> >>Sent: den 13 oktober 2004 04:33
> >>To: 'pkix'
> >>Subject: RE: Signer certificate discovery for CRLs
> >>
> >>
> >>Stefan:
> >>
> >>In terms of certificate discovery, your proposal for AIA in CRL is
more
> >>robust.  The whole idea of self-issued key rollover certificates and
> then
> >>using the new key to issue CRL is fraught with security problems.  A
> >>secure
> >>solution would be one where the new key is certified by the parent
CA.
> In
> >>that case to obtain the new certificate, you could use AIA in CRL.
> >>
> >>As to indirect CRL, your proposal is a good one.  The CRL DP in
> >>certificate
> >>in question points to the indirect CRL.  You get that CRL.  The AIA
in
> CRL
> >>gets you started for the indirect CRL issuer certification path and
you
> >>are
> >>in business.
> >>
> >>-----Original Message-----
> >>From: [e-mail]
[mailto:[e-mail]]
> >>On
> >>Behalf Of Stefan Santesson
> >>Sent: Tuesday, October 12, 2004 7:30 PM
> >>To: David A. Cooper
> >>Cc: pkix
> >>Subject: RE: Signer certificate discovery for CRLs
> >>
> >>
> >>
> >>David,
> >>
> >>Thanks for the clarifications, they make sense.
> >>I did misread your pictures.
> >>
> >>So can we conclude that for a re-keyed CA in accordance with RFC
3280,
> >>either the CRL issuer certificate itself, or the location of the CRL
> >>issuer
> >>certificate, will be clearly identified/available for the validating
> party
> >>in some cases, but not in others?
> >>
> >>Can we also conclude that there is no real discovery solution for
> indirect
> >>CRLs?
> >>
> >>Do you then agree then that it could be appropriate to allow AIA as
a
> CRL
> >>extension to facilitate discovery of CRL signer certificate?
> >>
> >>Stefan Santesson
> >>Microsoft Security Center of Excellence (SCOE)
> >>
> >>________________________________________
> >>From: David A. Cooper [mailto:[e-mail]]
> >>Sent: den 12 oktober 2004 21:14
> >>To: Stefan Santesson
> >>Cc: pkix
> >>Subject: Re: Signer certificate discovery for CRLs
> >>
> >>Stefan,
> >>
> >>I believe that you are misinterpreting the figures.  They really do
> >>represent three different cases, not three different certification
paths
> >>that have been constructed through the same PKI architecture.
> >>
> >>In figure 1, CA 1 has generated self-issued key rollover
certificates.
> >>The
> >>Root CA has issued a certificate to CA 1's new key, but not its old
key
> >>(either the Root CA never issued a certificate to CA 1's old key or
that
> >>certificate has expired).
> >>
> >>In figure 2, CA 2 has also generated self-issued key rollover
> >>certificates.
> >>The Root CA has issued a certificate to CA 2's old key, but not its
new
> >>key.
> >>
> >>In figure 3, when CA 3 performed key rollover, it requested a new CA
> >>certificate from the Root CA.  CA 3 did not generated self-issued
key
> >>rollover certificates.
> >>
> >>Of course, another realistic scenario would be one in which a CA
> generated
> >>self-issued key rollover certificates upon key rollover and then had
the
> >>Root CA issue a CA certificate to its new key.  In this case, as you
> >>suggest, any of the certification paths from figures 1, 2, or 3
could be
> >>constructed.
> >>
> >>As for the contents of the AIA extension, here is what I have
specified
> in
> >>the "X.509 Certificate and CRL Extensions Profile for the Common
> Policy":
> >>
> >>The authorityInfoAccess extension uses URIs for two purposes. When
the
> >>id-ad-caIssuers access method is used, the access location specifies
> where
> >>certificates issued to the issuer of the certificate may be found.
If
> LDAP
> >>is used, the URI must include the DN of the entry containing the
> relevant
> >>certificates and specify the directory attribute in which the
> certificates
> >>are located. If the directory in which the certificates are stored
> expects
> >>the "binary" option to be specified, then the attribute type must be
> >>followed by ";binary" in the URI. If HTTP is used, the URI must
point to
> a
> >>file that has an extension of ".p7c" that contains a certs-only CMS
> >>message
> >>(see RFC 2633). The CMS message should include all certificates
issued
> to
> >>the issuer of this certificate, but must at least contain all
> certificates
> >>issued to the issuer of this certificate in which the subject public
key
> >>may
> >>be used to verify the signature on this certificate. .... For a
> >>certificate
> >>issued by "Good CA", some examples of URIs that may appear as the
access
> >>location in an authorityInfoAccess extension when the
id-ad-caIssuers
> >>access
> >>method is used are:
>
>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACerti
fi
> ca
> >>te
> >>,crossCertificatePair
>
>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifica
te
> ;b
> >>in
> >>ary,crossCertificatePair;binary
>
>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssued
To
> Go
> >>od
> >>CA.p7c
> >>For both LDAP and HTTP, the URI provides the exact location where
> >>information is to be located, so there is no requirement for the
relying
> >>party to try to figure out where information is located.
> >>
> >>The HTTP URI points to a certs-only CMS message that includes all
> >>certificates issued to the CA identified in the issuer field of the
> >>certificate.
> >>
> >>The LDAP URI points to the cACertificate and crossCertificatePair
> >>attributes
> >>of the directory entry of the CA identified in the issuer field of
the
> >>certificate.  These two attributes together hold all of the
certificates
> >>issued to the CA:  the cACertificate attribute holds the CA's self-
> issued
> >>certificates and the crossCertificatePair attribute holds the
> >>cross-certificates issued to the CA by other CAs.
> >>
> >>Dave
> >>
> >>
> >>Stefan Santesson wrote:
> >>
> >>David,
> >>
> >>Thanks for these good thoughts and very useful scenarios.
> >>
> >>I have some comments and questions on this.
> >>
> >>First of all we can conclude that in some scenarios (figure 1) where
a
> >>self
> >>issued certificate is inserted into the path, you are likely to find
the
> >>CRL
> >>issuer cert in the path. (given that the new CA have a common key
and
> >>certificate for cert signing and CRL signing).
> >>
> >>Figure 1, 2 and 3 describe the same case. It is just describing
> different
> >>path building strategies. An application that has access locally to
all
> >>chaining options may however still choose path 2 for the certs and
path
> 1
> >>for the CRL independent of each other (which I think figure 3 tries
to
> >>describe)
> >>
> >>Another comment is the structure of AIA extensions. The use I'm
familiar
> >>with doesn't use AIA to describe a directory entry where it is left
to
> the
> >>validation application logic to be intelligent enough to find
> appropriate
> >>certificate data from the directory. The model I'm familiar with is
when
> >>the
> >>AIA URL explicitly identifies the exact location of the appropriate
CA
> >>certificate file, relieving the validation software from complex
> >>information
> >>queries. If just location of explicit certificate files are
identified
> >>through AIA, the presence of an AIA may not help finding the CRL
signer
> >>cert
> >>if this is different from the CA certificate. This is also the
problem
> >>with
> >>Denis proposal.
> >>
> >>I think we share the basic conclusion that the ability to locate the
CRL
> >>signer certificate directly through the CRL could be very useful. At
> least
> >>in the case of indirect CRL but it could also be proven very useful
in
> CA
> >>re-keying scenarios.
> >>
> >>The easiest solution would probably be to allow AIA to be used in
its
> >>current shape and structure as a CRL extension (MUST NOT be
critical).
> It
> >>would present a very clear and uncomplicated logic to certificate
> >>validating
> >>applications in many cases.
> >>
> >>Stefan Santesson
> >>Microsoft Security Center of Excellence (SCOE)
> >>
> >>________________________________________
> >>From: David A. Cooper [mailto:[e-mail]]
> >>Sent: den 7 oktober 2004 18:35
> >>To: Stefan Santesson
> >>Cc: pkix
> >>Subject: Re: Signer certificate discovery for CRLs
> >>
> >>Stefan,
> >>
> >>I think what you are proposing is a good idea.  In most cases, path
> >>discovery algorithms assume that both the trust anchor (or trust
> anchors)
> >>and the end entity certificate are provided as input.  In this case,
one
> >>may
> >>need to construct a certification path without a priori access to
the
> end
> >>entity certificate (the one with the subject public key
corresponding to
> >>the
> >>CRL signing key).  Including an AIA extension (or some other
pointer) in
> >>the
> >>CRL would provide the relying party with a simple way to obtain the
end
> >>entity certificate for the CRL signing key's certification path. On
the
> >>other hand, I believe that a relying party should be able to
construct
> the
> >>certification path even without an AIA extension in the CRL, so long
as
> it
> >>is not an indirect CRL.  Attached is a drawing of the three basic
> >>scenarios
> >>that I expect a relying party may encounter:
> >>
> >>In each of these scenarios, the CA has performed key rollover and is
> only
> >>signing CRLs with its new key.  The diagrams would look similar,
> however,
> >>if
> >>the CA simply choose to use different keys to sign certificates and
CRLs
> >>for
> >>some other reason.
> >>
> >>If the PKI architecture resembled figure 1, then the certification
path
> >>for
> >>the CRL signing key would just be a subset of the certification path
for
> >>the
> >>EE certificate, so no addition path discovery would be needed.
> >>
> >>If the PKI architecture resembled figure 1, then it would be
necessary
> to
> >>obtain the new-signed-with-old self-issued certificate.  In building
the
> >>certification path to the EE certificate, however, the relying party
> will
> >>obtain the certificates pointed to by the AIA extension in the EE
> >>certificate.  This AIA extension will point to a location containing
all
> >>certificates issued to CA 2, which would include both the
certificate
> >>issued
> >>by the Root to CA 2 and CA 2's self-issued certificate.  So, even
though
> >>the
> >>self-issued certificate would not be part of the certification path
to
> the
> >>EE certificate, it would be downloaded by the relying party during
the
> >>construction of that certification path.  (Yes, there are circular
> >>dependency issues in figure 2, but that is another issue.)
> >>
> >>A similar situation would happen if the PKI architecture resembled
> figure
> >>3.  The AIA extension in the EE certificate would point to a
location
> >>containing certificates issued to CA 3.  When the relying party
> downloaded
> >>these certificates, it would obtain both of the certificates issued
by
> the
> >>Root to CA 3 and so again would have the certificate needed to
validate
> >>the
> >>CRL signing key.
> >>
> >>In the case of an indirect CRL, things may not work as well.  If
> indirect
> >>CRLs were used, and the PKI architecture resembled figures 2 or 3
> >>(replacing
> >>"New Key" with a different CA), then the set of certificates pointed
to
> by
> >>the AIA extension in the EE certificate would not include the
> certificate
> >>of
> >>the CRL signer.  One could find this certificate by building in the
> >>reverse
> >>direction and using the SIA extension, but that may not be the most
> >>convenient solution.
> >>
> >>So, when indirect CRLs are being used, it seems that it would be
very
> >>useful
> >>to have a pointer in the CRL to the CRL signing certificate.  When
the
> CRL
> >>is not indirect, the need for this pointer does not seem to be as
clear,
> >>but
> >>I can't see any harm in including it.
> >>
> >>Dave
> >>
> >>Stefan Santesson wrote:
> >>All,
> >>
> >>I'm interested in the opinion from members on this list about
discovery
> of
> >>CRL signer's certificate in non directory centric environments.
> >>
> >>The problem is the following.
> >>
> >>The relying party (RP) needs to check validity of a certificate and
> finds
> >>a
> >>CDP extension with a URL to the CRL. The RP retrieves this CRL which
in
> >>this
> >>particular case is either signed by another key of the CA (re-keyed
CA)
> or
> >>another entity (indirect CRL).
> >>
> >>In this case the relying party needs to obtain the certificate of
the
> CRL
> >>signer which may NOT be part of the original chain. In a directory
> centric
> >>solution this is retrieved from the directory, but what if such
> directory
> >>is
> >>not available or accessible.
> >>
> >>The RP have thus no hint where to find the CRL issuers certificate
> unless
> >>the RP already have possession of it by some other means.
> >>
> >>Is seems that CRLs would need an AIA extension with the option to
point
> to
> >>the location of the signers certificate in the same manner as is
> possible
> >>for certificates.
> >>
> >>Maybe AIA should be defined as both cert and CRL extension and not
only
> >>certificate extension as today.
> >>
> >>Thoughts and comments?
> >>
> >>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 i9DEY3b2085710; Wed, 13 Oct 2004 07:34:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DEY3i7085709; Wed, 13 Oct 2004 07:34:03 -0700 (PDT)
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 i9DEY0fq085689 for <[e-mail]>; Wed, 13 Oct 2004 07:34:01 -0700 (PDT) (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 QAA39326; Wed, 13 Oct 2004 16:45:35 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101316335722:665 ; Wed, 13 Oct 2004 16:33:57 +0200 
Message-ID: <[e-mail]>
Date: Wed, 13 Oct 2004 16:33:56 +0200
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]>, pkix <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/10/2004 16:33:57, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/10/2004 16:33:59, Serialize complete at 13/10/2004 16:33:59
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,

You are making a conclusion without letting me the time to respond.
I will need more time to look at the pictures (and understand them).

For the time being, I am still reluctant to accept "yet-another-method".
We already have too many.

> Santosh,
> 
> I conclude that we are in complete and total agreement.
> The question is how to go about this.

> Could we do this amendment to RFC 3280 in its next revision?
> It would hopefully just be a minor change.

This is exactly what I feared.

We usually end-up with a "minor change" in an extension without saying 
cleary how and when it shall/should be used.

I still have in mind that:

  1) a certification path must first be constructed,
  2) then the revocation checking of that path must be done.

This means that information about CRL issuers certificates locations may 
certainly be found in that chain. If not, I would like an example.

Denis


> It would not change the definition of AIA just add that it can be used also as CRL extension and list eventual restrictions and guidance for use with CRLs.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]
>>On Behalf Of Santosh Chokhani
>>Sent: den 13 oktober 2004 04:33
>>To: 'pkix'
>>Subject: RE: Signer certificate discovery for CRLs
>>
>>
>>Stefan:
>>
>>In terms of certificate discovery, your proposal for AIA in CRL is more
>>robust.  The whole idea of self-issued key rollover certificates and then
>>using the new key to issue CRL is fraught with security problems.  A
>>secure
>>solution would be one where the new key is certified by the parent CA.  In
>>that case to obtain the new certificate, you could use AIA in CRL.
>>
>>As to indirect CRL, your proposal is a good one.  The CRL DP in
>>certificate
>>in question points to the indirect CRL.  You get that CRL.  The AIA in CRL
>>gets you started for the indirect CRL issuer certification path and you
>>are
>>in business.
>>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]
>>On
>>Behalf Of Stefan Santesson
>>Sent: Tuesday, October 12, 2004 7:30 PM
>>To: David A. Cooper
>>Cc: pkix
>>Subject: RE: Signer certificate discovery for CRLs
>>
>>
>>
>>David,
>>
>>Thanks for the clarifications, they make sense.
>>I did misread your pictures.
>>
>>So can we conclude that for a re-keyed CA in accordance with RFC 3280,
>>either the CRL issuer certificate itself, or the location of the CRL
>>issuer
>>certificate, will be clearly identified/available for the validating party
>>in some cases, but not in others?
>>
>>Can we also conclude that there is no real discovery solution for indirect
>>CRLs?
>>
>>Do you then agree then that it could be appropriate to allow AIA as a CRL
>>extension to facilitate discovery of CRL signer certificate?
>>
>>Stefan Santesson
>>Microsoft Security Center of Excellence (SCOE)
>>
>>________________________________________
>>From: David A. Cooper [mailto:[e-mail]]
>>Sent: den 12 oktober 2004 21:14
>>To: Stefan Santesson
>>Cc: pkix
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>Stefan,
>>
>>I believe that you are misinterpreting the figures.  They really do
>>represent three different cases, not three different certification paths
>>that have been constructed through the same PKI architecture.
>>
>>In figure 1, CA 1 has generated self-issued key rollover certificates.
>>The
>>Root CA has issued a certificate to CA 1's new key, but not its old key
>>(either the Root CA never issued a certificate to CA 1's old key or that
>>certificate has expired).
>>
>>In figure 2, CA 2 has also generated self-issued key rollover
>>certificates.
>>The Root CA has issued a certificate to CA 2's old key, but not its new
>>key.
>>
>>In figure 3, when CA 3 performed key rollover, it requested a new CA
>>certificate from the Root CA.  CA 3 did not generated self-issued key
>>rollover certificates.
>>
>>Of course, another realistic scenario would be one in which a CA generated
>>self-issued key rollover certificates upon key rollover and then had the
>>Root CA issue a CA certificate to its new key.  In this case, as you
>>suggest, any of the certification paths from figures 1, 2, or 3 could be
>>constructed.
>>
>>As for the contents of the AIA extension, here is what I have specified in
>>the "X.509 Certificate and CRL Extensions Profile for the Common Policy":
>>
>>The authorityInfoAccess extension uses URIs for two purposes. When the
>>id-ad-caIssuers access method is used, the access location specifies where
>>certificates issued to the issuer of the certificate may be found. If LDAP
>>is used, the URI must include the DN of the entry containing the relevant
>>certificates and specify the directory attribute in which the certificates
>>are located. If the directory in which the certificates are stored expects
>>the "binary" option to be specified, then the attribute type must be
>>followed by ";binary" in the URI. If HTTP is used, the URI must point to a
>>file that has an extension of ".p7c" that contains a certs-only CMS
>>message
>>(see RFC 2633). The CMS message should include all certificates issued to
>>the issuer of this certificate, but must at least contain all certificates
>>issued to the issuer of this certificate in which the subject public key
>>may
>>be used to verify the signature on this certificate. .... For a
>>certificate
>>issued by "Good CA", some examples of URIs that may appear as the access
>>location in an authorityInfoAccess extension when the id-ad-caIssuers
>>access
>>method is used are:
>>ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifica
>>te
>>,crossCertificatePair
>>ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertificate;b
>>in
>>ary,crossCertificatePair;binary
>>http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssuedToGo
>>od
>>CA.p7c
>>For both LDAP and HTTP, the URI provides the exact location where
>>information is to be located, so there is no requirement for the relying
>>party to try to figure out where information is located.
>>
>>The HTTP URI points to a certs-only CMS message that includes all
>>certificates issued to the CA identified in the issuer field of the
>>certificate.
>>
>>The LDAP URI points to the cACertificate and crossCertificatePair
>>attributes
>>of the directory entry of the CA identified in the issuer field of the
>>certificate.  These two attributes together hold all of the certificates
>>issued to the CA:  the cACertificate attribute holds the CA's self-issued
>>certificates and the crossCertificatePair attribute holds the
>>cross-certificates issued to the CA by other CAs.
>>
>>Dave
>>
>>
>>Stefan Santesson wrote:
>>
>>David,
>>
>>Thanks for these good thoughts and very useful scenarios.
>>
>>I have some comments and questions on this.
>>
>>First of all we can conclude that in some scenarios (figure 1) where a
>>self
>>issued certificate is inserted into the path, you are likely to find the
>>CRL
>>issuer cert in the path. (given that the new CA have a common key and
>>certificate for cert signing and CRL signing).
>>
>>Figure 1, 2 and 3 describe the same case. It is just describing different
>>path building strategies. An application that has access locally to all
>>chaining options may however still choose path 2 for the certs and path 1
>>for the CRL independent of each other (which I think figure 3 tries to
>>describe)
>>
>>Another comment is the structure of AIA extensions. The use I'm familiar
>>with doesn't use AIA to describe a directory entry where it is left to the
>>validation application logic to be intelligent enough to find appropriate
>>certificate data from the directory. The model I'm familiar with is when
>>the
>>AIA URL explicitly identifies the exact location of the appropriate CA
>>certificate file, relieving the validation software from complex
>>information
>>queries. If just location of explicit certificate files are identified
>>through AIA, the presence of an AIA may not help finding the CRL signer
>>cert
>>if this is different from the CA certificate. This is also the problem
>>with
>>Denis proposal.
>>
>>I think we share the basic conclusion that the ability to locate the CRL
>>signer certificate directly through the CRL could be very useful. At least
>>in the case of indirect CRL but it could also be proven very useful in CA
>>re-keying scenarios.
>>
>>The easiest solution would probably be to allow AIA to be used in its
>>current shape and structure as a CRL extension (MUST NOT be critical). It
>>would present a very clear and uncomplicated logic to certificate
>>validating
>>applications in many cases.
>>
>>Stefan Santesson
>>Microsoft Security Center of Excellence (SCOE)
>>
>>________________________________________
>>From: David A. Cooper [mailto:[e-mail]]
>>Sent: den 7 oktober 2004 18:35
>>To: Stefan Santesson
>>Cc: pkix
>>Subject: Re: Signer certificate discovery for CRLs
>>
>>Stefan,
>>
>>I think what you are proposing is a good idea.  In most cases, path
>>discovery algorithms assume that both the trust anchor (or trust anchors)
>>and the end entity certificate are provided as input.  In this case, one
>>may
>>need to construct a certification path without a priori access to the end
>>entity certificate (the one with the subject public key corresponding to
>>the
>>CRL signing key).  Including an AIA extension (or some other pointer) in
>>the
>>CRL would provide the relying party with a simple way to obtain the end
>>entity certificate for the CRL signing key's certification path. On the
>>other hand, I believe that a relying party should be able to construct the
>>certification path even without an AIA extension in the CRL, so long as it
>>is not an indirect CRL.  Attached is a drawing of the three basic
>>scenarios
>>that I expect a relying party may encounter:
>>
>>In each of these scenarios, the CA has performed key rollover and is only
>>signing CRLs with its new key.  The diagrams would look similar, however,
>>if
>>the CA simply choose to use different keys to sign certificates and CRLs
>>for
>>some other reason.
>>
>>If the PKI architecture resembled figure 1, then the certification path
>>for
>>the CRL signing key would just be a subset of the certification path for
>>the
>>EE certificate, so no addition path discovery would be needed.
>>
>>If the PKI architecture resembled figure 1, then it would be necessary to
>>obtain the new-signed-with-old self-issued certificate.  In building the
>>certification path to the EE certificate, however, the relying party will
>>obtain the certificates pointed to by the AIA extension in the EE
>>certificate.  This AIA extension will point to a location containing all
>>certificates issued to CA 2, which would include both the certificate
>>issued
>>by the Root to CA 2 and CA 2's self-issued certificate.  So, even though
>>the
>>self-issued certificate would not be part of the certification path to the
>>EE certificate, it would be downloaded by the relying party during the
>>construction of that certification path.  (Yes, there are circular
>>dependency issues in figure 2, but that is another issue.)
>>
>>A similar situation would happen if the PKI architecture resembled figure
>>3.  The AIA extension in the EE certificate would point to a location
>>containing certificates issued to CA 3.  When the relying party downloaded
>>these certificates, it would obtain both of the certificates issued by the
>>Root to CA 3 and so again would have the certificate needed to validate
>>the
>>CRL signing key.
>>
>>In the case of an indirect CRL, things may not work as well.  If indirect
>>CRLs were used, and the PKI architecture resembled figures 2 or 3
>>(replacing
>>"New Key" with a different CA), then the set of certificates pointed to by
>>the AIA extension in the EE certificate would not include the certificate
>>of
>>the CRL signer.  One could find this certificate by building in the
>>reverse
>>direction and using the SIA extension, but that may not be the most
>>convenient solution.
>>
>>So, when indirect CRLs are being used, it seems that it would be very
>>useful
>>to have a pointer in the CRL to the CRL signing certificate.  When the CRL
>>is not indirect, the need for this pointer does not seem to be as clear,
>>but
>>I can't see any harm in including it.
>>
>>Dave
>>
>>Stefan Santesson wrote:
>>All,
>>
>>I'm interested in the opinion from members on this list about discovery of
>>CRL signer's certificate in non directory centric environments.
>>
>>The problem is the following.
>>
>>The relying party (RP) needs to check validity of a certificate and finds
>>a
>>CDP extension with a URL to the CRL. The RP retrieves this CRL which in
>>this
>>particular case is either signed by another key of the CA (re-keyed CA) or
>>another entity (indirect CRL).
>>
>>In this case the relying party needs to obtain the certificate of the CRL
>>signer which may NOT be part of the original chain. In a directory centric
>>solution this is retrieved from the directory, but what if such directory
>>is
>>not available or accessible.
>>
>>The RP have thus no hint where to find the CRL issuers certificate unless
>>the RP already have possession of it by some other means.
>>
>>Is seems that CRLs would need an AIA extension with the option to point to
>>the location of the signers certificate in the same manner as is possible
>>for certificates.
>>
>>Maybe AIA should be defined as both cert and CRL extension and not only
>>certificate extension as today.
>>
>>Thoughts and comments?
>>
>>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 i9DELRs0084141; Wed, 13 Oct 2004 07:21:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DELRX4084140; Wed, 13 Oct 2004 07:21:27 -0700 (PDT)
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 i9DELQNF084134 for <[e-mail]>; Wed, 13 Oct 2004 07:21:26 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (PPP-219.65.51.64.mum2.vsnl.net.in [219.65.51.64]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9DELdfn001032 for <[e-mail]>; Wed, 13 Oct 2004 10:21:40 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Wed, 13 Oct 2004 10:21:33 -0400
Message-ID: <003801c4b12f$f5a97800$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9DELRNF084135
Sender: [e-mail]
Precedence: 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:

The change could be part of CRL related explanation (if the RFC Editor
wishes).

We could describe this as a mechanism to start the CRL issuer path
development process.

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Wednesday, October 13, 2004 9:45 AM
To: Santosh Chokhani; pkix
Subject: RE: Signer certificate discovery for CRLs


Santosh,

I conclude that we are in complete and total agreement.
The question is how to go about this.

Could we do this amendment to RFC 3280 in its next revision?
It would hopefully just be a minor change.

It would not change the definition of AIA just add that it can be used also
as CRL extension and list eventual restrictions and guidance for use with
CRLs.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 13 oktober 2004 04:33
> To: 'pkix'
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> Stefan:
> 
> In terms of certificate discovery, your proposal for AIA in CRL is 
> more robust.  The whole idea of self-issued key rollover certificates 
> and then using the new key to issue CRL is fraught with security 
> problems.  A secure solution would be one where the new key is 
> certified by the parent CA.  In that case to obtain the new 
> certificate, you could use AIA in CRL.
> 
> As to indirect CRL, your proposal is a good one.  The CRL DP in 
> certificate in question points to the indirect CRL.  You get that CRL.  
> The AIA in CRL gets you started for the indirect CRL issuer 
> certification path and you are
> in business.
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, October 12, 2004 7:30 PM
> To: David A. Cooper
> Cc: pkix
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> 
> David,
> 
> Thanks for the clarifications, they make sense.
> I did misread your pictures.
> 
> So can we conclude that for a re-keyed CA in accordance with RFC 3280, 
> either the CRL issuer certificate itself, or the location of the CRL 
> issuer certificate, will be clearly identified/available for the 
> validating party in some cases, but not in others?
> 
> Can we also conclude that there is no real discovery solution for 
> indirect CRLs?
> 
> Do you then agree then that it could be appropriate to allow AIA as a 
> CRL extension to facilitate discovery of CRL signer certificate?
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> ________________________________________
> From: David A. Cooper [mailto:[e-mail]]
> Sent: den 12 oktober 2004 21:14
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> I believe that you are misinterpreting the figures.  They really do 
> represent three different cases, not three different certification 
> paths that have been constructed through the same PKI architecture.
> 
> In figure 1, CA 1 has generated self-issued key rollover certificates. 
> The Root CA has issued a certificate to CA 1's new key, but not its 
> old key (either the Root CA never issued a certificate to CA 1's old 
> key or that certificate has expired).
> 
> In figure 2, CA 2 has also generated self-issued key rollover 
> certificates. The Root CA has issued a certificate to CA 2's old key, 
> but not its new key.
> 
> In figure 3, when CA 3 performed key rollover, it requested a new CA 
> certificate from the Root CA.  CA 3 did not generated self-issued key 
> rollover certificates.
> 
> Of course, another realistic scenario would be one in which a CA 
> generated self-issued key rollover certificates upon key rollover and 
> then had the Root CA issue a CA certificate to its new key.  In this 
> case, as you suggest, any of the certification paths from figures 1, 
> 2, or 3 could be constructed.
> 
> As for the contents of the AIA extension, here is what I have 
> specified in the "X.509 Certificate and CRL Extensions Profile for the 
> Common Policy":
> 
> The authorityInfoAccess extension uses URIs for two purposes. When the 
> id-ad-caIssuers access method is used, the access location specifies 
> where certificates issued to the issuer of the certificate may be 
> found. If LDAP is used, the URI must include the DN of the entry 
> containing the relevant certificates and specify the directory 
> attribute in which the certificates are located. If the directory in 
> which the certificates are stored expects the "binary" option to be 
> specified, then the attribute type must be followed by ";binary" in 
> the URI. If HTTP is used, the URI must point to a file that has an 
> extension of ".p7c" that contains a certs-only CMS message (see RFC 
> 2633). The CMS message should include all certificates issued to the 
> issuer of this certificate, but must at least contain all certificates 
> issued to the issuer of this certificate in which the subject public 
> key may be used to verify the signature on this certificate. .... For 
> a certificate
> issued by "Good CA", some examples of URIs that may appear as the access
> location in an authorityInfoAccess extension when the id-ad-caIssuers
> access
> method is used are:
> ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifica
> te
> ,crossCertificatePair
> ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertificate;b
> in
> ary,crossCertificatePair;binary
> http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssuedToGo
> od
> CA.p7c
> For both LDAP and HTTP, the URI provides the exact location where
> information is to be located, so there is no requirement for the relying
> party to try to figure out where information is located.
> 
> The HTTP URI points to a certs-only CMS message that includes all 
> certificates issued to the CA identified in the issuer field of the 
> certificate.
> 
> The LDAP URI points to the cACertificate and crossCertificatePair 
> attributes of the directory entry of the CA identified in the issuer 
> field of the certificate.  These two attributes together hold all of 
> the certificates issued to the CA:  the cACertificate attribute holds 
> the CA's self-issued certificates and the crossCertificatePair 
> attribute holds the cross-certificates issued to the CA by other CAs.
> 
> Dave
> 
> 
> Stefan Santesson wrote:
> 
> David,
> 
> Thanks for these good thoughts and very useful scenarios.
> 
> I have some comments and questions on this.
> 
> First of all we can conclude that in some scenarios (figure 1) where a 
> self issued certificate is inserted into the path, you are likely to 
> find the CRL
> issuer cert in the path. (given that the new CA have a common key and
> certificate for cert signing and CRL signing).
> 
> Figure 1, 2 and 3 describe the same case. It is just describing 
> different path building strategies. An application that has access 
> locally to all chaining options may however still choose path 2 for 
> the certs and path 1 for the CRL independent of each other (which I 
> think figure 3 tries to
> describe)
> 
> Another comment is the structure of AIA extensions. The use I'm 
> familiar with doesn't use AIA to describe a directory entry where it 
> is left to the validation application logic to be intelligent enough 
> to find appropriate certificate data from the directory. The model I'm 
> familiar with is when the AIA URL explicitly identifies the exact 
> location of the appropriate CA certificate file, relieving the 
> validation software from complex information
> queries. If just location of explicit certificate files are identified
> through AIA, the presence of an AIA may not help finding the CRL signer
> cert
> if this is different from the CA certificate. This is also the problem
> with
> Denis proposal.
> 
> I think we share the basic conclusion that the ability to locate the 
> CRL signer certificate directly through the CRL could be very useful. 
> At least in the case of indirect CRL but it could also be proven very 
> useful in CA re-keying scenarios.
> 
> The easiest solution would probably be to allow AIA to be used in its 
> current shape and structure as a CRL extension (MUST NOT be critical). 
> It would present a very clear and uncomplicated logic to certificate 
> validating applications in many cases.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> ________________________________________
> From: David A. Cooper [mailto:[e-mail]]
> Sent: den 7 oktober 2004 18:35
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> I think what you are proposing is a good idea.  In most cases, path 
> discovery algorithms assume that both the trust anchor (or trust 
> anchors) and the end entity certificate are provided as input.  In 
> this case, one may need to construct a certification path without a 
> priori access to the end entity certificate (the one with the subject 
> public key corresponding to the
> CRL signing key).  Including an AIA extension (or some other pointer) in
> the
> CRL would provide the relying party with a simple way to obtain the end
> entity certificate for the CRL signing key's certification path. On the
> other hand, I believe that a relying party should be able to construct the
> certification path even without an AIA extension in the CRL, so long as it
> is not an indirect CRL.  Attached is a drawing of the three basic
> scenarios
> that I expect a relying party may encounter:
> 
> In each of these scenarios, the CA has performed key rollover and is 
> only signing CRLs with its new key.  The diagrams would look similar, 
> however, if the CA simply choose to use different keys to sign 
> certificates and CRLs for
> some other reason.
> 
> If the PKI architecture resembled figure 1, then the certification 
> path for the CRL signing key would just be a subset of the 
> certification path for the
> EE certificate, so no addition path discovery would be needed.
> 
> If the PKI architecture resembled figure 1, then it would be necessary 
> to obtain the new-signed-with-old self-issued certificate.  In 
> building the certification path to the EE certificate, however, the 
> relying party will obtain the certificates pointed to by the AIA 
> extension in the EE certificate.  This AIA extension will point to a 
> location containing all certificates issued to CA 2, which would 
> include both the certificate issued by the Root to CA 2 and CA 2's 
> self-issued certificate.  So, even though the
> self-issued certificate would not be part of the certification path to the
> EE certificate, it would be downloaded by the relying party during the
> construction of that certification path.  (Yes, there are circular
> dependency issues in figure 2, but that is another issue.)
> 
> A similar situation would happen if the PKI architecture resembled 
> figure 3.  The AIA extension in the EE certificate would point to a 
> location containing certificates issued to CA 3.  When the relying 
> party downloaded these certificates, it would obtain both of the 
> certificates issued by the Root to CA 3 and so again would have the 
> certificate needed to validate the CRL signing key.
> 
> In the case of an indirect CRL, things may not work as well.  If 
> indirect CRLs were used, and the PKI architecture resembled figures 2 
> or 3 (replacing "New Key" with a different CA), then the set of 
> certificates pointed to by the AIA extension in the EE certificate 
> would not include the certificate of
> the CRL signer.  One could find this certificate by building in the
> reverse
> direction and using the SIA extension, but that may not be the most
> convenient solution.
> 
> So, when indirect CRLs are being used, it seems that it would be very 
> useful to have a pointer in the CRL to the CRL signing certificate.  
> When the CRL is not indirect, the need for this pointer does not seem 
> to be as clear, but
> I can't see any harm in including it.
> 
> Dave
> 
> Stefan Santesson wrote:
> All,
> 
> I'm interested in the opinion from members on this list about 
> discovery of CRL signer's certificate in non directory centric 
> environments.
> 
> The problem is the following.
> 
> The relying party (RP) needs to check validity of a certificate and 
> finds a CDP extension with a URL to the CRL. The RP retrieves this CRL 
> which in this
> particular case is either signed by another key of the CA (re-keyed CA) or
> another entity (indirect CRL).
> 
> In this case the relying party needs to obtain the certificate of the 
> CRL signer which may NOT be part of the original chain. In a directory 
> centric solution this is retrieved from the directory, but what if 
> such directory is not available or accessible.
> 
> The RP have thus no hint where to find the CRL issuers certificate 
> unless the RP already have possession of it by some other means.
> 
> Is seems that CRLs would need an AIA extension with the option to 
> point to the location of the signers certificate in the same manner as 
> is possible for certificates.
> 
> Maybe AIA should be defined as both cert and CRL extension and not 
> only certificate extension as today.
> 
> Thoughts and comments?
> 
> 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 i9DE03ug081709; Wed, 13 Oct 2004 07:00:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DE03GW081708; Wed, 13 Oct 2004 07:00:03 -0700 (PDT)
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 i9DE03ZB081700 for <[e-mail]>; Wed, 13 Oct 2004 07:00:03 -0700 (PDT) (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 i9DDxgNR017817 for <[e-mail]>; Wed, 13 Oct 2004 09:59:42 -0400
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 i9DDx6eq006938 for <[e-mail]>; Wed, 13 Oct 2004 09:59:07 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 13 Oct 2004 09:59:57 -0400
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: pkix <[e-mail]>
Subject: Re: Signer certificate discovery for CRLs
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------000200090809000605060109"
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 is a multi-part message in MIME format.
--------------000200090809000605060109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefan Santesson wrote:

>Re-sending since original html mail was too long with pictures from David Cooper.
>  
>

All,

It seems that my previous messages to the PKIX list have been rejected 
by the list server.  Stefan has successfully forwarded my messages to 
the list, but without the accompanying image.  I have attached a copy of 
the image to this message in one last attempt to provide it to the list.

Dave

--------------000200090809000605060109
Content-Type: application/pdf;
 name="CRLsign.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="CRLsign.pdf"

JVBERi0xLjIKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nL1b245uNw2+n6eYS0DiJ0cnuQRUbkAg2v0GnFQ0I1QOQrw9jr/P
Xlmze5q2qnox9Z/E8dmOl/cXz+mRn9P+j3//9Pr0xdMvPm3Pf/vXU36U5/8+5efPn3rLD3mW
0vef16ee5DE3WPTPy1MbZQMTQF22VYaeVjDNR1NwLAPrALiqblKwp42o5gywtL1aq21NyYDe
DG+ZSYGBS4rojU2paBto+6+02u2KUutjrwrBss9LW9ycNwbpNRkwNq1dQI2vrYmtOCk14U7g
VRh4cassgpuiUYpTOhqQkIsx6snhIDXkf2axKyidWbGZspsNsqNkpySX+ZRlG6mPOZphpbbm
ANY+BkCsSt56jbPSjEtglSHXfSPJRcuwv0HpkHRxMea2g+BxJvBICcxSDDTZzDovmc2eLnnO
bty5tKeqTy5dTDEOXVO+alrkSdewYXXt231uGaTE7YZ0uk2RC7c34xCWSN7dSk0ubsEmMbdu
ytJtn5J2z6Ae3GtuPvXy9NnTF8/ZPNH//On1+Vcf1BfXc26P1J4//PUJPpqfy3h0xaxHuzx/
eH36ye9/+uHvTznpden5w5+ffvKXDcsjO/zfN+vPG66PNgn/9hvO/2/Dn3x4/uNT7t1kX+pm
8lXhDIev0FRuc0OtEeomc2c6twKZCKSc6wJMCeZqGlbxDsJ2jcp+mJRyzVBaS8BfFrQmvK8M
U0Fddrr0ZbGgwKhyaYatdYerqaRN7K6Gq+eOu0o13+30h1if7TgrWXgzcCsy4sbdMhwGZSOR
E1I+ajv4Gn3d+B7zlMpMBXdRajNzN6XqzupSn42cmE5mhxu4xuDyrs8pxN2Xcc1V1Zxh9rPS
EUwcs0yLmXHzQAwNygbCZFA+BrgGX2PZ3cH1zOAaMpnmt5fEJqJlSHSTPA+Jz2Fch0Ymwin1
NYdxHdr0Vdc2T9MWiDsshXeHJZE22hnpDiskX2Gl5DqsmFIJK6fUwgso1fASSj28iFoJL6PO
wgdvPvrO2KKmuKOKKMOlWXD5w5vg8ILgoWIF/GcEiyXfP7gkszNJfTPyugWx+QL4QnCkRrGt
tnPHW/jafsO2xZAzM74p/XXDFoR7Gu7icPlOxfn6Kg7jPEwqI6H0gRSmsFUTvreYUVy4bNVV
5GeL3DHTHP/6s8h5dn7TWttJm3KT0va6kc0aXp+WbKtRECiXetHIFdSslG1r8/S6LW1kGtSs
AJm4ZsbmCacfcyMcJYG0YQxqPgcno+nJ0lkmlI1w7BJoJ8qNbtQE/5TVDawE50Y36shIlnNT
NlryvGqqbrRgXx3lOtkTCxrg7ZWlCW7tQhAU9UXiN7VitQj5EFoPudRwc0lAFmRN+QyaCaUH
1CFbjVoAt9xHg01QJ8OjDlU23CiS2cOxbrYUx3M2oQduNYJ5XZzVIS6qcjYeg2i1MBMaOMrF
ipNgV63ExAZZ5DK3MENMmp2MbpeiBoVDxGpUyXZTAwqb7KAeheys6y5WqVo/7ZoHbjcLv9mt
ximDSTnVbm/OlRuj8+y26jJxU4bE3M4hTXcCl7X7iOvCXch15f51d7+vj7LlFmK1EKybZb1u
WoT91CJkfwwPif+wH/Jjzq/64d8RNDUaPcsaO0ZodtshYk1Yy9ZtJPZR9oo7SbZIuSq9wtKz
gvBTi4GroTCF6ykIrsW0pj7HK2RvZQ0flCB+Wbwaeezzr6iUV/Pg1czdep/VYldpW4gEXxyc
MhhW9t+3oG++oXpntlMaNW91RQxN/HqLdT2q57JP38C/Owphu6/3NZBLagvohdCcXi7Yu+8j
OHbfcL03YWvsmMrC2hl18/DJpnHuFwJo/uSgGfcue71Y8a5KSYlUqQg3jShBkun5WlvbHHjS
KFZ616STdo0xCnmBufEs5Mje5Fyxsuk4d9JjVmOHj9eFoeJLVq3GCl89j5zYJoiaEFu3F3uY
CYLXtWplAM/u95cZ0RpwAcQ2BcuFaA0w33M51kwice5GkXGAw1ezhGDUYv6DBfFrPXmRwh+0
mrlW81g0DP9BkPMdZJ16rVd5nOfL7e6cxklbWvVOW7IS+1pnXXut6xv7WmUQuVbtNXKtp/u6
avtcP7T7reOn7EjZ60azDf43FhzrI3lw/BwVpjvt394Gz//wh+E7/rl/2DHgqFC1Ym1e4lpJ
2y8EecM/12dL3yl0R/P9668Zxh3rLw0e21+/Bo15ppqHPRGKFQKvu9u00DxAFNbCFCV9Zx+r
WDtHnwjsXeEtIIVdnlIyenQ0/pKn4auJATbvwF1LJtTM2ytjfsklnc/qkq3EkTrZGksTXbXM
29Ow9daIL7EnY6WHQqh1E6CGSrf6Xov1UTfH+mLjj6eV1QOzbj/ulel7QdfIzhfoHnXc+Bri
fILvMZ1Pscdqvclsstxymc4aDUKT+XQdUSdTeDt15q0216l34lznk6GktNRv6w0thjjfBI9r
x98WYL+/F+x3+npvB/V94HbnTswULt41RJmsXDb62EWDgrITSD5kK6A+ZK/3HpqRVUJnWiDY
S8Y1KmvdNO7rbhF2ltZCrLQk3hl2RprCDklz2Cl5Cjsmz2HnlEn4gUksfITyDB+ivMPHqI/w
QeorfJT6vHz49PH3tvw0HLHn19qP3PNTu2V/YSeNWq8M/aIQWtqlGVQslQSLtQhg6ybVUhHE
+GDWh4CFKBQDNbMDm9gNz9aCLbwnm1VL7YYpF3wdsGKz5gQ1L96aQG8rxJTQ62kdjlYTitg2
HRZBL8j3i/X95rnGBO9nxb9ZELc0h3G3vroeJ21alB90j1JvXI3mXFpjfaRDHoPvOUhrsk5w
WWolech5ulaohwkeqCPv4kGD6PC5bj2oaN0a3b/autzOtcnun2HtmeGGd3b2+kBRZ3BzerVE
Onixpwn53E57ykAEQdtlJJQwJCgLId/ly7dLyH9kdAlzwPhW4PrTt2Do1tfi+wvOhl0Qd9gN
7w67ImVhd6ScVkm+aLHGcVizSSMsnbIKT6Akw08oaXoRtRA+Ri3RA01/l3denvvel5HKJqMP
yHfFV/UBlf31thWYUv7eYUfFMVFt8jGwljj0AmikBkWZdu9Q7Lzj2WIoE4ruEzW4wpafIv8g
P1HAXE2C/8fJzBww99egzhZAQZ9bMxn24g0FY4s1UyLPjXLinMjU+oYoYzECvd6i0Sa9Ws+h
GdmGMjoQZTuUPu3tglHRDfRiYCTAjcl674wE3NHJGPy4ij7HYplgXZGSecfufaproqQQdF8E
KyavUTz5dmtajf1pA7vL7vo0Jks4nVYXAbMB6LvTTu3RRYp1cew439by4md3pIpDuLt33w3a
9G140C1eyhhP4h+QyfHuZlzSgKtfshL/oGySVBUcMh6hD+hgwBxMO97Zc90NGsfW6giDs4rP
11Y6OoIa2NEhBE60Xq4b1ypOTU0ZlPvH5tRA+fBP04KOZ0eem/OSQc3oorqEamYb1eSnWQs9
Vkq3bqMK2WvgQL9vOWypJTRXYXah2Vin5v28Wwawu9343W5VTplbnVMOmwRXsFbn1y3Z5QE7
d2nRB0yO4R+UMn2HGgjPMv3Q66i58Mjw1ve8b9UCd2dwNwj5ffd7NQgrOpyyEjpxFR1O2XRb
IXF75Wgt3K52X91159E41CIEncMoy3ZMXjlKOEtFK3vxY08bvam7KVTAOHvSZXGvJvRvMxs8
ij7tDd5/KDWzT2iP5GR506CXgKaIP3/YNbzD3H1gencpPrxpKG+6hlfa+/Tjn67eob4/Fvp9
6OKonKz7BPgl4Mm2DwuLj+DYf8P33kSv5tx2//AbmodVeUGzrkA3mF5RmJ5XVztIbFWOtYaW
7eKHNCX41purLYm3DIFnMRnWikYjVtBmpGne6IH57KPxTDE04zKdgk7dsIyPaQ4iLpj66NOH
huoieVid6BwiNNTBxiEDcmWbMV75wLU8UdVW7us1Xd3Ekypkfhw/GkGE+QXos+uXAh8JOMlt
PS80IAMeUf74L8Lyx+E2Q1j8pZ435PzRejrX0/QuZfwy+o2LJOkNF6nJjYtU7zSmPG5cpFTv
XLCZ/HrBofJvHW/1YEVDkW/rH7+jWKyjuMWzU7Ke+04NxRLe2jitUjo0oBFiXq2Jlv1djvze
shmlwtBwSwtTPZxIUPcETF/TXI0GYbKZv8SpHGv31MVWY2NwWtaPlyrmzwtzMpicqAsf3Ftm
OlnZ2ojM7Rr4d+uHmX9iqqJzlkRhlM3V1ycmPDg1EeucsvDz4qnLsEs/bxbUN6RqsK3kNA9+
o3SOhjBGkWNvpbk8Jisal5anWJemN+pc2t7Ic23M0A5f9wwh0KW3CV3T3kZsRW4Df63i4RGn
a2037BrAjrvrOilr6OEH5a1j0sg5a6PfOG/2yqdcWs83ubXOiR7Kte2qPKSuz1i87KmRtj8q
hbYUaqc2Wx8Yr6C2Y92HJ+2024rjdlvym93SnDK3Q6ccVgquYL/OsVu3SwS27/KiX5gsw2dM
zuFR1EJ4HLUUHkkthsfe/Pm9KV7TmT0i82N+r97h0IT+Te/4lD5+yvea2CVECdoL40nD57Zq
/8951UJJkFNVxW1msLNpXwagjN38hNjTPGY19dFefIyzJxS6tfvOYiPF/Dq4yZaWaLkoTKRV
FLINH6mkcVKtIbtLmwHjcZ8DxtO/+3muT8eP85pyD+zoXl+3y8gHbcIuE+gehcO+5MrHbcEx
OmuQhffcXFLekXM5ol/nUvZunmsBvT5oyPuArj10CV23Hk+6f+bg6jg6iB3Dt461VU4P8k7/
wAGKMNF70btf+Bc3uyHifHbQEzLo65SQYDw65CeYlgzpCie7Kf2OViJ1o5CcmusYNwzNxnp2
7DjtluHY3XL8drcsp84tD7SHVZKzsFnjmvZs8ghLp7TCD/zjxDglHT5EPYSPmZbCA/3jI7zz
5rvvjDx7NJ3ThFV+gC7idw1AbQxjGJ+y9XVgk+H+YdugkZgM+rDewls4dt9x2VjCMKXqQx8l
t8pe0Jiz/dIxT1eYBiVj3K4iFU1BY06YijpgzPnvrsre68m9c5CPatZ0NNCeiwS9IX6Sb62i
edeZ+ps91EeZnr5NtaNmT1GWq4Y+xwya1obB/1veGi150TDQfqt+kuueju1sWw4BL774X/f2
Xm90dRvycqqFg/rgSTwUk2Pp5ZCHDE/0kJcPwbk0Rzplvb8BXHoYoZfOQT4WAdTiMDdwHXsj
TusAudbmup2cpd4wTxvM8nsnRtpI07JZrIviZf/O4+JoST34XRxT9PCR0k1WmhxsNySpyWFe
Uu6pQcrUQkdDPLSkvlpPHXYYeOg41mkDfr4y2QA7bAc3u105VW53TnXYJbkKuyXPYdWUSVg9
ZRZeQYnSZyjt8Chqg/5GXYU3mh7pqTc/fs8TUkvE/VjcLbv0A8z0qQegkTYYUCpbZdPdLZ8V
fCuc3wOEoWVCFW+LVf01gI8hmPVTt7XZPtan2NmjXgVWAZ6TImtVaBGNzw+C7zOtDk4Vclgr
D5txAwt1WfeA8EvA00vyVr4U9v0ntncmoT15ugeGxPpa36Vh16uJbydr+/dvNh9l0EtAc0b+
vv0/dx0Y3ptD1V9XsQm/Jfcm3ZXqrj5d5xhKSlFr25Cf5/Z00Vo7h/x8DbWLD/31XWj05eHB
W1V8zyimBdgcHv+YgcNdG54Y9fPTN6owKAcE16PAEbLU2hY0o+G3WxjjNoPYir0j+xzMKqWj
ExfrjRN/g3BF527SokrhzB+L9pJvA2mtJM79GZQX+nZ++qAN7oDjV8fF4aib4pdChhzO5bae
OVIacEy2xi+CnlfAPUoR/6Wlc734DF78kvONyrTkDZVplhuVSd6s93qjEg+R2w5LNMeOnO5U
0jpeL3j6jm8feM1d1DjNa37U3t1RjNbL/ZJ0/8axQwXalotty55t9MI+FvVcEC8ZcDun03zy
Wh9sOItyH0ObsornVHylXnimJOtR6z3Ir/i3hv7h5KQJtnpLoK8bOT/FvG8Ss6kNFLOexxFY
v03H8ktlt//7P30m9vZlbmRzdHJlYW0KZW5kb2JqCjcgMCBvYmoKNDQ4MgplbmRvYmoKNSAw
IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFy
ZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUg
MTAgMCBSCi9Gb250IDExIDAgUgo+PgovQ29udGVudHMgNiAwIFIKPj4KZW5kb2JqCjMgMCBv
YmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNSAwIFIKXSAvQ291bnQgMQo+PgplbmRvYmoK
MSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUgo+PgplbmRvYmoKNCAwIG9i
ago8PC9UeXBlL0V4dEdTdGF0ZS9OYW1lL1I0L1RSL0lkZW50aXR5Pj4KZW5kb2JqCjEwIDAg
b2JqCjw8L1I0CjQgMCBSPj4KZW5kb2JqCjExIDAgb2JqCjw8L1I5CjkgMCBSPj4KZW5kb2Jq
CjggMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9UaW1lcy1Sb21hbj4+
CmVuZG9iago5IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvVGltZXMtUm9tYW4v
VHlwZS9Gb250L05hbWUvUjk+PgplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihFU1AgR2hv
c3RzY3JpcHQgNy4wNyk+PmVuZG9iagp4cmVmCjAgMTIKMDAwMDAwMDAwMCA2NTUzNSBmIAow
MDAwMDA0ODA2IDAwMDAwIG4gCjAwMDAwMDUxMDMgMDAwMDAgbiAKMDAwMDAwNDc0NyAwMDAw
MCBuIAowMDAwMDA0ODU0IDAwMDAwIG4gCjAwMDAwMDQ1ODcgMDAwMDAgbiAKMDAwMDAwMDAx
NSAwMDAwMCBuIAowMDAwMDA0NTY3IDAwMDAwIG4gCjAwMDAwMDQ5NjkgMDAwMDAgbiAKMDAw
MDAwNTAzMCAwMDAwMCBuIAowMDAwMDA0OTA5IDAwMDAwIG4gCjAwMDAwMDQ5MzkgMDAwMDAg
biAKdHJhaWxlcgo8PCAvU2l6ZSAxMiAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgo+PgpzdGFy
dHhyZWYKNTE1MwolJUVPRgo=
--------------000200090809000605060109--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DDiHx0079699; Wed, 13 Oct 2004 06:44:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DDiHHQ079697; Wed, 13 Oct 2004 06:44:17 -0700 (PDT)
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 i9DDiGUY079680 for <[e-mail]>; Wed, 13 Oct 2004 06:44:16 -0700 (PDT) (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.0); Wed, 13 Oct 2004 14:44:36 +0100
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: Signer certificate discovery for CRLs
Date: Wed, 13 Oct 2004 14:44:32 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcSw1m6WXnPOxTVlT7O3lWgM4PRBjQAUz2hA
From: "Stefan Santesson" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 13 Oct 2004 13:44:36.0554 (UTC) FILETIME=[C76982A0:01C4B12A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9DDiHUY079692
Sender: [e-mail]
Precedence: 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 conclude that we are in complete and total agreement.
The question is how to go about this.

Could we do this amendment to RFC 3280 in its next revision?
It would hopefully just be a minor change.

It would not change the definition of AIA just add that it can be used also as CRL extension and list eventual restrictions and guidance for use with CRLs.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 13 oktober 2004 04:33
> To: 'pkix'
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> Stefan:
> 
> In terms of certificate discovery, your proposal for AIA in CRL is more
> robust.  The whole idea of self-issued key rollover certificates and then
> using the new key to issue CRL is fraught with security problems.  A
> secure
> solution would be one where the new key is certified by the parent CA.  In
> that case to obtain the new certificate, you could use AIA in CRL.
> 
> As to indirect CRL, your proposal is a good one.  The CRL DP in
> certificate
> in question points to the indirect CRL.  You get that CRL.  The AIA in CRL
> gets you started for the indirect CRL issuer certification path and you
> are
> in business.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, October 12, 2004 7:30 PM
> To: David A. Cooper
> Cc: pkix
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> 
> David,
> 
> Thanks for the clarifications, they make sense.
> I did misread your pictures.
> 
> So can we conclude that for a re-keyed CA in accordance with RFC 3280,
> either the CRL issuer certificate itself, or the location of the CRL
> issuer
> certificate, will be clearly identified/available for the validating party
> in some cases, but not in others?
> 
> Can we also conclude that there is no real discovery solution for indirect
> CRLs?
> 
> Do you then agree then that it could be appropriate to allow AIA as a CRL
> extension to facilitate discovery of CRL signer certificate?
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> ________________________________________
> From: David A. Cooper [mailto:[e-mail]]
> Sent: den 12 oktober 2004 21:14
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> I believe that you are misinterpreting the figures.  They really do
> represent three different cases, not three different certification paths
> that have been constructed through the same PKI architecture.
> 
> In figure 1, CA 1 has generated self-issued key rollover certificates.
> The
> Root CA has issued a certificate to CA 1's new key, but not its old key
> (either the Root CA never issued a certificate to CA 1's old key or that
> certificate has expired).
> 
> In figure 2, CA 2 has also generated self-issued key rollover
> certificates.
> The Root CA has issued a certificate to CA 2's old key, but not its new
> key.
> 
> In figure 3, when CA 3 performed key rollover, it requested a new CA
> certificate from the Root CA.  CA 3 did not generated self-issued key
> rollover certificates.
> 
> Of course, another realistic scenario would be one in which a CA generated
> self-issued key rollover certificates upon key rollover and then had the
> Root CA issue a CA certificate to its new key.  In this case, as you
> suggest, any of the certification paths from figures 1, 2, or 3 could be
> constructed.
> 
> As for the contents of the AIA extension, here is what I have specified in
> the "X.509 Certificate and CRL Extensions Profile for the Common Policy":
> 
> The authorityInfoAccess extension uses URIs for two purposes. When the
> id-ad-caIssuers access method is used, the access location specifies where
> certificates issued to the issuer of the certificate may be found. If LDAP
> is used, the URI must include the DN of the entry containing the relevant
> certificates and specify the directory attribute in which the certificates
> are located. If the directory in which the certificates are stored expects
> the "binary" option to be specified, then the attribute type must be
> followed by ";binary" in the URI. If HTTP is used, the URI must point to a
> file that has an extension of ".p7c" that contains a certs-only CMS
> message
> (see RFC 2633). The CMS message should include all certificates issued to
> the issuer of this certificate, but must at least contain all certificates
> issued to the issuer of this certificate in which the subject public key
> may
> be used to verify the signature on this certificate. .... For a
> certificate
> issued by "Good CA", some examples of URIs that may appear as the access
> location in an authorityInfoAccess extension when the id-ad-caIssuers
> access
> method is used are:
> ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifica
> te
> ,crossCertificatePair
> ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertificate;b
> in
> ary,crossCertificatePair;binary
> http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssuedToGo
> od
> CA.p7c
> For both LDAP and HTTP, the URI provides the exact location where
> information is to be located, so there is no requirement for the relying
> party to try to figure out where information is located.
> 
> The HTTP URI points to a certs-only CMS message that includes all
> certificates issued to the CA identified in the issuer field of the
> certificate.
> 
> The LDAP URI points to the cACertificate and crossCertificatePair
> attributes
> of the directory entry of the CA identified in the issuer field of the
> certificate.  These two attributes together hold all of the certificates
> issued to the CA:  the cACertificate attribute holds the CA's self-issued
> certificates and the crossCertificatePair attribute holds the
> cross-certificates issued to the CA by other CAs.
> 
> Dave
> 
> 
> Stefan Santesson wrote:
> 
> David,
> 
> Thanks for these good thoughts and very useful scenarios.
> 
> I have some comments and questions on this.
> 
> First of all we can conclude that in some scenarios (figure 1) where a
> self
> issued certificate is inserted into the path, you are likely to find the
> CRL
> issuer cert in the path. (given that the new CA have a common key and
> certificate for cert signing and CRL signing).
> 
> Figure 1, 2 and 3 describe the same case. It is just describing different
> path building strategies. An application that has access locally to all
> chaining options may however still choose path 2 for the certs and path 1
> for the CRL independent of each other (which I think figure 3 tries to
> describe)
> 
> Another comment is the structure of AIA extensions. The use I'm familiar
> with doesn't use AIA to describe a directory entry where it is left to the
> validation application logic to be intelligent enough to find appropriate
> certificate data from the directory. The model I'm familiar with is when
> the
> AIA URL explicitly identifies the exact location of the appropriate CA
> certificate file, relieving the validation software from complex
> information
> queries. If just location of explicit certificate files are identified
> through AIA, the presence of an AIA may not help finding the CRL signer
> cert
> if this is different from the CA certificate. This is also the problem
> with
> Denis proposal.
> 
> I think we share the basic conclusion that the ability to locate the CRL
> signer certificate directly through the CRL could be very useful. At least
> in the case of indirect CRL but it could also be proven very useful in CA
> re-keying scenarios.
> 
> The easiest solution would probably be to allow AIA to be used in its
> current shape and structure as a CRL extension (MUST NOT be critical). It
> would present a very clear and uncomplicated logic to certificate
> validating
> applications in many cases.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> ________________________________________
> From: David A. Cooper [mailto:[e-mail]]
> Sent: den 7 oktober 2004 18:35
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> I think what you are proposing is a good idea.  In most cases, path
> discovery algorithms assume that both the trust anchor (or trust anchors)
> and the end entity certificate are provided as input.  In this case, one
> may
> need to construct a certification path without a priori access to the end
> entity certificate (the one with the subject public key corresponding to
> the
> CRL signing key).  Including an AIA extension (or some other pointer) in
> the
> CRL would provide the relying party with a simple way to obtain the end
> entity certificate for the CRL signing key's certification path. On the
> other hand, I believe that a relying party should be able to construct the
> certification path even without an AIA extension in the CRL, so long as it
> is not an indirect CRL.  Attached is a drawing of the three basic
> scenarios
> that I expect a relying party may encounter:
> 
> In each of these scenarios, the CA has performed key rollover and is only
> signing CRLs with its new key.  The diagrams would look similar, however,
> if
> the CA simply choose to use different keys to sign certificates and CRLs
> for
> some other reason.
> 
> If the PKI architecture resembled figure 1, then the certification path
> for
> the CRL signing key would just be a subset of the certification path for
> the
> EE certificate, so no addition path discovery would be needed.
> 
> If the PKI architecture resembled figure 1, then it would be necessary to
> obtain the new-signed-with-old self-issued certificate.  In building the
> certification path to the EE certificate, however, the relying party will
> obtain the certificates pointed to by the AIA extension in the EE
> certificate.  This AIA extension will point to a location containing all
> certificates issued to CA 2, which would include both the certificate
> issued
> by the Root to CA 2 and CA 2's self-issued certificate.  So, even though
> the
> self-issued certificate would not be part of the certification path to the
> EE certificate, it would be downloaded by the relying party during the
> construction of that certification path.  (Yes, there are circular
> dependency issues in figure 2, but that is another issue.)
> 
> A similar situation would happen if the PKI architecture resembled figure
> 3.  The AIA extension in the EE certificate would point to a location
> containing certificates issued to CA 3.  When the relying party downloaded
> these certificates, it would obtain both of the certificates issued by the
> Root to CA 3 and so again would have the certificate needed to validate
> the
> CRL signing key.
> 
> In the case of an indirect CRL, things may not work as well.  If indirect
> CRLs were used, and the PKI architecture resembled figures 2 or 3
> (replacing
> "New Key" with a different CA), then the set of certificates pointed to by
> the AIA extension in the EE certificate would not include the certificate
> of
> the CRL signer.  One could find this certificate by building in the
> reverse
> direction and using the SIA extension, but that may not be the most
> convenient solution.
> 
> So, when indirect CRLs are being used, it seems that it would be very
> useful
> to have a pointer in the CRL to the CRL signing certificate.  When the CRL
> is not indirect, the need for this pointer does not seem to be as clear,
> but
> I can't see any harm in including it.
> 
> Dave
> 
> Stefan Santesson wrote:
> All,
> 
> I'm interested in the opinion from members on this list about discovery of
> CRL signer's certificate in non directory centric environments.
> 
> The problem is the following.
> 
> The relying party (RP) needs to check validity of a certificate and finds
> a
> CDP extension with a URL to the CRL. The RP retrieves this CRL which in
> this
> particular case is either signed by another key of the CA (re-keyed CA) or
> another entity (indirect CRL).
> 
> In this case the relying party needs to obtain the certificate of the CRL
> signer which may NOT be part of the original chain. In a directory centric
> solution this is retrieved from the directory, but what if such directory
> is
> not available or accessible.
> 
> The RP have thus no hint where to find the CRL issuers certificate unless
> the RP already have possession of it by some other means.
> 
> Is seems that CRLs would need an AIA extension with the option to point to
> the location of the signers certificate in the same manner as is possible
> for certificates.
> 
> Maybe AIA should be defined as both cert and CRL extension and not only
> certificate extension as today.
> 
> Thoughts and comments?
> 
> 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 i9D2WQAU002133; Tue, 12 Oct 2004 19:32:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9D2WQr1002132; Tue, 12 Oct 2004 19:32:26 -0700 (PDT)
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 i9D2WQtG002126 for <[e-mail]>; Tue, 12 Oct 2004 19:32:26 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (PPP-219.65.47.154.mum2.vsnl.net.in [219.65.47.154]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9D2KR8B006458 for <[e-mail]>; Tue, 12 Oct 2004 22:32:36 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Tue, 12 Oct 2004 22:32:36 -0400
Message-ID: <002601c4b0cc$e7ce7220$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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
In-reply-to: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9D2WQtG002127
Sender: [e-mail]
Precedence: 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:

In terms of certificate discovery, your proposal for AIA in CRL is more
robust.  The whole idea of self-issued key rollover certificates and then
using the new key to issue CRL is fraught with security problems.  A secure
solution would be one where the new key is certified by the parent CA.  In
that case to obtain the new certificate, you could use AIA in CRL.

As to indirect CRL, your proposal is a good one.  The CRL DP in certificate
in question points to the indirect CRL.  You get that CRL.  The AIA in CRL
gets you started for the indirect CRL issuer certification path and you are
in business. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Tuesday, October 12, 2004 7:30 PM
To: David A. Cooper
Cc: pkix
Subject: RE: Signer certificate discovery for CRLs



David,

Thanks for the clarifications, they make sense.
I did misread your pictures.

So can we conclude that for a re-keyed CA in accordance with RFC 3280,
either the CRL issuer certificate itself, or the location of the CRL issuer
certificate, will be clearly identified/available for the validating party
in some cases, but not in others?

Can we also conclude that there is no real discovery solution for indirect
CRLs?

Do you then agree then that it could be appropriate to allow AIA as a CRL
extension to facilitate discovery of CRL signer certificate?

Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 
  
________________________________________
From: David A. Cooper [mailto:[e-mail]] 
Sent: den 12 oktober 2004 21:14
To: Stefan Santesson
Cc: pkix
Subject: Re: Signer certificate discovery for CRLs

Stefan,

I believe that you are misinterpreting the figures.  They really do
represent three different cases, not three different certification paths
that have been constructed through the same PKI architecture.

In figure 1, CA 1 has generated self-issued key rollover certificates.  The
Root CA has issued a certificate to CA 1's new key, but not its old key
(either the Root CA never issued a certificate to CA 1's old key or that
certificate has expired).

In figure 2, CA 2 has also generated self-issued key rollover certificates. 
The Root CA has issued a certificate to CA 2's old key, but not its new key.

In figure 3, when CA 3 performed key rollover, it requested a new CA
certificate from the Root CA.  CA 3 did not generated self-issued key
rollover certificates.

Of course, another realistic scenario would be one in which a CA generated
self-issued key rollover certificates upon key rollover and then had the
Root CA issue a CA certificate to its new key.  In this case, as you
suggest, any of the certification paths from figures 1, 2, or 3 could be
constructed.

As for the contents of the AIA extension, here is what I have specified in
the "X.509 Certificate and CRL Extensions Profile for the Common Policy":

The authorityInfoAccess extension uses URIs for two purposes. When the
id-ad-caIssuers access method is used, the access location specifies where
certificates issued to the issuer of the certificate may be found. If LDAP
is used, the URI must include the DN of the entry containing the relevant
certificates and specify the directory attribute in which the certificates
are located. If the directory in which the certificates are stored expects
the "binary" option to be specified, then the attribute type must be
followed by ";binary" in the URI. If HTTP is used, the URI must point to a
file that has an extension of ".p7c" that contains a certs-only CMS message
(see RFC 2633). The CMS message should include all certificates issued to
the issuer of this certificate, but must at least contain all certificates
issued to the issuer of this certificate in which the subject public key may
be used to verify the signature on this certificate. .... For a certificate
issued by "Good CA", some examples of URIs that may appear as the access
location in an authorityInfoAccess extension when the id-ad-caIssuers access
method is used are: 
ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACertificate
,crossCertificatePair
ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertificate;bin
ary,crossCertificatePair;binary
http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssuedToGood
CA.p7c
For both LDAP and HTTP, the URI provides the exact location where
information is to be located, so there is no requirement for the relying
party to try to figure out where information is located.

The HTTP URI points to a certs-only CMS message that includes all
certificates issued to the CA identified in the issuer field of the
certificate.

The LDAP URI points to the cACertificate and crossCertificatePair attributes
of the directory entry of the CA identified in the issuer field of the
certificate.  These two attributes together hold all of the certificates
issued to the CA:  the cACertificate attribute holds the CA's self-issued
certificates and the crossCertificatePair attribute holds the
cross-certificates issued to the CA by other CAs.

Dave


Stefan Santesson wrote:

David,
 
Thanks for these good thoughts and very useful scenarios.
 
I have some comments and questions on this.
 
First of all we can conclude that in some scenarios (figure 1) where a self
issued certificate is inserted into the path, you are likely to find the CRL
issuer cert in the path. (given that the new CA have a common key and
certificate for cert signing and CRL signing).
 
Figure 1, 2 and 3 describe the same case. It is just describing different
path building strategies. An application that has access locally to all
chaining options may however still choose path 2 for the certs and path 1
for the CRL independent of each other (which I think figure 3 tries to
describe)
 
Another comment is the structure of AIA extensions. The use I'm familiar
with doesn't use AIA to describe a directory entry where it is left to the
validation application logic to be intelligent enough to find appropriate
certificate data from the directory. The model I'm familiar with is when the
AIA URL explicitly identifies the exact location of the appropriate CA
certificate file, relieving the validation software from complex information
queries. If just location of explicit certificate files are identified
through AIA, the presence of an AIA may not help finding the CRL signer cert
if this is different from the CA certificate. This is also the problem with
Denis proposal.
 
I think we share the basic conclusion that the ability to locate the CRL
signer certificate directly through the CRL could be very useful. At least
in the case of indirect CRL but it could also be proven very useful in CA
re-keying scenarios.
 
The easiest solution would probably be to allow AIA to be used in its
current shape and structure as a CRL extension (MUST NOT be critical). It
would present a very clear and uncomplicated logic to certificate validating
applications in many cases.
 
Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 
  
________________________________________
From: David A. Cooper [mailto:[e-mail]] 
Sent: den 7 oktober 2004 18:35
To: Stefan Santesson
Cc: pkix
Subject: Re: Signer certificate discovery for CRLs
 
Stefan,

I think what you are proposing is a good idea.  In most cases, path
discovery algorithms assume that both the trust anchor (or trust anchors)
and the end entity certificate are provided as input.  In this case, one may
need to construct a certification path without a priori access to the end
entity certificate (the one with the subject public key corresponding to the
CRL signing key).  Including an AIA extension (or some other pointer) in the
CRL would provide the relying party with a simple way to obtain the end
entity certificate for the CRL signing key's certification path. On the
other hand, I believe that a relying party should be able to construct the
certification path even without an AIA extension in the CRL, so long as it
is not an indirect CRL.  Attached is a drawing of the three basic scenarios
that I expect a relying party may encounter:

In each of these scenarios, the CA has performed key rollover and is only
signing CRLs with its new key.  The diagrams would look similar, however, if
the CA simply choose to use different keys to sign certificates and CRLs for
some other reason.

If the PKI architecture resembled figure 1, then the certification path for
the CRL signing key would just be a subset of the certification path for the
EE certificate, so no addition path discovery would be needed.

If the PKI architecture resembled figure 1, then it would be necessary to
obtain the new-signed-with-old self-issued certificate.  In building the
certification path to the EE certificate, however, the relying party will
obtain the certificates pointed to by the AIA extension in the EE
certificate.  This AIA extension will point to a location containing all
certificates issued to CA 2, which would include both the certificate issued
by the Root to CA 2 and CA 2's self-issued certificate.  So, even though the
self-issued certificate would not be part of the certification path to the
EE certificate, it would be downloaded by the relying party during the
construction of that certification path.  (Yes, there are circular
dependency issues in figure 2, but that is another issue.)

A similar situation would happen if the PKI architecture resembled figure
3.  The AIA extension in the EE certificate would point to a location
containing certificates issued to CA 3.  When the relying party downloaded
these certificates, it would obtain both of the certificates issued by the
Root to CA 3 and so again would have the certificate needed to validate the
CRL signing key.

In the case of an indirect CRL, things may not work as well.  If indirect
CRLs were used, and the PKI architecture resembled figures 2 or 3 (replacing
"New Key" with a different CA), then the set of certificates pointed to by
the AIA extension in the EE certificate would not include the certificate of
the CRL signer.  One could find this certificate by building in the reverse
direction and using the SIA extension, but that may not be the most
convenient solution.

So, when indirect CRLs are being used, it seems that it would be very useful
to have a pointer in the CRL to the CRL signing certificate.  When the CRL
is not indirect, the need for this pointer does not seem to be as clear, but
I can't see any harm in including it.

Dave

Stefan Santesson wrote:
All,
 
I'm interested in the opinion from members on this list about discovery of
CRL signer's certificate in non directory centric environments.
 
The problem is the following.
 
The relying party (RP) needs to check validity of a certificate and finds a
CDP extension with a URL to the CRL. The RP retrieves this CRL which in this
particular case is either signed by another key of the CA (re-keyed CA) or
another entity (indirect CRL).
 
In this case the relying party needs to obtain the certificate of the CRL
signer which may NOT be part of the original chain. In a directory centric
solution this is retrieved from the directory, but what if such directory is
not available or accessible.
 
The RP have thus no hint where to find the CRL issuers certificate unless
the RP already have possession of it by some other means.
 
Is seems that CRLs would need an AIA extension with the option to point to
the location of the signers certificate in the same manner as is possible
for certificates.
 
Maybe AIA should be defined as both cert and CRL extension and not only
certificate extension as today.
 
Thoughts and comments?
 
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 i9D0cHRT091732; Tue, 12 Oct 2004 17:38:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9D0cHEk091731; Tue, 12 Oct 2004 17:38:17 -0700 (PDT)
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 i9D0cF47091719 for <[e-mail]>; Tue, 12 Oct 2004 17:38:16 -0700 (PDT) (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.0); Wed, 13 Oct 2004 01:38:32 +0100
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: Signer certificate discovery for CRLs
Date: Wed, 13 Oct 2004 01:38:36 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcSsh08aioLW2bfpTo2T7htnfVsOCAENO2pg
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 13 Oct 2004 00:38:32.0402 (UTC) FILETIME=[F7630B20:01C4B0BC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9D0cG47091724
Sender: [e-mail]
Precedence: 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 think my reply to David Cooper also cover your mail and need not to be
repeated.

I don't agree to your conclusion. Just because current available methods
(e.g. use of AIA in certificates) may provide sufficient functionality
in some cases does not make a good rationale for not applying a better
and simpler solution that actually works in all situations.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Denis Pinkas
> Sent: den 7 oktober 2004 16:42
> To: Stefan Santesson
> Cc: [e-mail]
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> Stefan,
> 
> > All,
> >
> > I'm interested in the opinion from members on this list about
discovery
> > of CRL signer's certificate in non directory centric environments.
> >
> > The problem is the following.
> >
> > The relying party (RP) needs to check validity of a certificate and
> > finds a CDP extension with a URL to the CRL.
> 
> > The RP retrieves this CRL which in this particular case is either
signed
> > by another key of the CA (re-keyed CA) or another entity (indirect
CRL).
> 
> > In this case the relying party needs to obtain the certificate of
the
> > CRL signer which may NOT be part of the original chain.
> 
> You mean: "In these cases ..." since there are two cases.  :-)
> 
>  > In a directory
> > centric solution this is retrieved from the directory, but what if
such
> > directory is not available or accessible.
> >
> > The RP have thus no hint where to find the CRL issuers certificate
> > unless the RP already have possession of it by some other means.
> >
> > Is seems that CRLs would need an AIA extension with the option to
point
> > to the location of the signers certificate in the same manner as is
> > possible for certificates.
> >
> > Maybe AIA should be defined as both cert and CRL extension and not
only
> > certificate extension as today.
> 
> I suppose that a candidate certification path has been successfully
built,
> but not yet validated as far as certificate revocation status is
> concerned.
> 
> In the first case (re-keyed CA), there may be multiple sub-cases, so
you
> would have to be more specific to explain the scenario you have in
mind.
> 
> In the second case (indirect CRL, no re-keyed CA), let us use a simple
> example.
> 
> A chain of certificates has been built with:
> leaf certificate / CA Cert 1 / CA Cert 2 / ...
> 
> In the chain of certificates, if CA Cert 1 (issued by CA 2) includes
an
> AIA
> extension with an AccessDescription id-ad-caIssuers, then the location
of
> a
> repository that may contain CRL issuer certificates may be known: if
CA 2
> postes the certificate designating the CRL issuer in that repository,
then
> the problem is solved.
> 
> " [FROM RFC 3280] The accessLocation field specifies the location of
the
> information. The retrieval mechanism may be implied by the
accessMethod or
> specified by accessLocation. When id-ad-caIssuers appears as
accessMethod,
> the accessLocation field describes the referenced description server
and
> the
> access protocol to obtain the referenced description."
> 
> In the chain of certificates, if CA Cert 2 (issued by CA 3) includes
an
> Subject Information Access (SIA) extension with an AccessDescription
> id-ad-caRepository, then the location of a repository that may contain
CRL
> issuer certificates may be known: if CA 2 postes the certificate
> designating
> the CRL issuer in that repository, then the problem is also solved.
> 
> Even if these extensions are scarcely (not yet ?) used for that
purpose,
> I do not think it would be desirable to introduce a third way.
> 
> Denis
> 
> 
> 
> > Thoughts and comments?
> >
> > 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 i9D0WuRK091449; Tue, 12 Oct 2004 17:32:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9D0WuA4091448; Tue, 12 Oct 2004 17:32:56 -0700 (PDT)
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 i9D0Wsff091441 for <[e-mail]>; Tue, 12 Oct 2004 17:32:55 -0700 (PDT) (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.0); Wed, 13 Oct 2004 01:33:05 +0100
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: Signer certificate discovery for CRLs
Date: Wed, 13 Oct 2004 01:33:13 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcSslYKIjR/Q47TkSvS4GPmtkYsGigEJMPcQ
From: "Stefan Santesson" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 13 Oct 2004 00:33:05.0071 (UTC) FILETIME=[34484BF0:01C4B0BC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9D0Wtff091442
Sender: [e-mail]
Precedence: 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,

It seams that we are in agreement regarding AIA in CRLs.

I agree that crypto binding between certificate issuer and CRL is a
useful and important feature for the purpose you mention. Just applying
name matching seems a bit week and could in worst case increase the
vulnerability for attacks thanks to poor implementations or miss
configuration errors.

It would actually be easier to process than path comparison rules but
have the drawback of introducing a new extension. Let's consider that
closer.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 7 oktober 2004 18:44
> To: [e-mail]
> Subject: RE: Signer certificate discovery for CRLs
> 
> 
> Stefan and Denis:
> 
> I have reviewed Denis's examples.  They do not seem clear to me.  But,
for
> both re-key and indirect case (there are several such as assigning a
sub
> CA
> or another CA in the PKI domain that is not in any certificate's
> certification path), what Stefan has suggested for CRL is a good idea.
> 
> I assume that we all realize that having an AIA is not crypto binding.
> 
> Separately, while preparing for PKIX, I have had this idea for crypto
> binding the certificate signer and CRL signer.  This could be in lieu
of
> certification path matching algorithm.  A CRL can contain a
non-critical
> extension which is a SEQUENCE or SET of key identifier (formed using
hash
> scheme recommended by 3280) of the CAs' certificate signing keys.  A
key
> identifier is included if the certificate signed using that key can be
> included in that CRL.  Now, the relying party only needs to match the
AKID
> of the certificate with one of the values in this extension.
> 
> Please note that this check is a substitute for path matching.  IDP
> discipline must still be observed in order to maintain security.
> 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On
> Behalf Of Denis Pinkas
> Sent: Thursday, October 07, 2004 10:42 AM
> To: Stefan Santesson
> Cc: [e-mail]
> Subject: Re: Signer certificate discovery for CRLs
> 
> 
> 
> Stefan,
> 
> > All,
> >
> > I'm interested in the opinion from members on this list about
> > discovery of CRL signer's certificate in non directory centric
> > environments.
> >
> > The problem is the following.
> >
> > The relying party (RP) needs to check validity of a certificate and
> > finds a CDP extension with a URL to the CRL.
> 
> > The RP retrieves this CRL which in this particular case is either
> > signed by another key of the CA (re-keyed CA) or another entity
> > (indirect CRL).
> 
> > In this case the relying party needs to obtain the certificate of
the
> > CRL signer which may NOT be part of the original chain.
> 
> You mean: "In these cases ..." since there are two cases.  :-)
> 
>  > In a directory
> > centric solution this is retrieved from the directory, but what if
> > such directory is not available or accessible.
> >
> > The RP have thus no hint where to find the CRL issuers certificate
> > unless the RP already have possession of it by some other means.
> >
> > Is seems that CRLs would need an AIA extension with the option to
> > point to the location of the signers certificate in the same manner
as
> > is possible for certificates.
> >
> > Maybe AIA should be defined as both cert and CRL extension and not
> > only certificate extension as today.
> 
> I suppose that a candidate certification path has been successfully
built,
> but not yet validated as far as certificate revocation status is
> concerned.
> 
> In the first case (re-keyed CA), there may be multiple sub-cases, so
you
> would have to be more specific to explain the scenario you have in
mind.
> 
> In the second case (indirect CRL, no re-keyed CA), let us use a simple
> example.
> 
> A chain of certificates has been built with:
> leaf certificate / CA Cert 1 / CA Cert 2 / ...
> 
> In the chain of certificates, if CA Cert 1 (issued by CA 2) includes
an
> AIA
> extension with an AccessDescription id-ad-caIssuers, then the location
of
> a
> repository that may contain CRL issuer certificates may be known: if
CA 2
> postes the certificate designating the CRL issuer in that repository,
then
> the problem is solved.
> 
> " [FROM RFC 3280] The accessLocation field specifies the location of
the
> information. The retrieval mechanism may be implied by the
accessMethod or
> specified by accessLocation. When id-ad-caIssuers appears as
accessMethod,
> the accessLocation field describes the referenced description server
and
> the
> 
> access protocol to obtain the referenced description."
> 
> In the chain of certificates, if CA Cert 2 (issued by CA 3) includes
an
> Subject Information Access (SIA) extension with an AccessDescription
> id-ad-caRepository, then the location of a repository that may contain
CRL
> issuer certificates may be known: if CA 2 postes the certificate
> designating
> 
> the CRL issuer in that repository, then the problem is also solved.
> 
> Even if these extensions are scarcely (not yet ?) used for that
purpose, I
> do not think it would be desirable to introduce a third way.
> 
> Denis
> 
> 
> 
> > Thoughts and comments?
> >
> > 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 i9CNTmEm086873; Tue, 12 Oct 2004 16:29:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CNTmIX086872; Tue, 12 Oct 2004 16:29:48 -0700 (PDT)
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 i9CNTkmD086865 for <[e-mail]>; Tue, 12 Oct 2004 16:29:46 -0700 (PDT) (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.0); Wed, 13 Oct 2004 00:29:56 +0100
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: Signer certificate discovery for CRLs
Date: Wed, 13 Oct 2004 00:29:46 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcSwj46XwTOCEHqsQ4mQqqS0kqn6UgAIfcKw
From: "Stefan Santesson" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 12 Oct 2004 23:29:56.0561 (UTC) FILETIME=[62278C10:01C4B0B3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9CNTlmD086867
Sender: [e-mail]
Precedence: 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 the clarifications, they make sense.
I did misread your pictures.

So can we conclude that for a re-keyed CA in accordance with RFC 3280, either the CRL issuer certificate itself, or the location of the CRL issuer certificate, will be clearly identified/available for the validating party in some cases, but not in others?

Can we also conclude that there is no real discovery solution for indirect CRLs?

Do you then agree then that it could be appropriate to allow AIA as a CRL extension to facilitate discovery of CRL signer certificate?

Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 
  
________________________________________
From: David A. Cooper [mailto:[e-mail]] 
Sent: den 12 oktober 2004 21:14
To: Stefan Santesson
Cc: pkix
Subject: Re: Signer certificate discovery for CRLs

Stefan,

I believe that you are misinterpreting the figures.  They really do represent three different cases, not three different certification paths that have been constructed through the same PKI architecture.

In figure 1, CA 1 has generated self-issued key rollover certificates.  The Root CA has issued a certificate to CA 1's new key, but not its old key (either the Root CA never issued a certificate to CA 1's old key or that certificate has expired).

In figure 2, CA 2 has also generated self-issued key rollover certificates.  The Root CA has issued a certificate to CA 2's old key, but not its new key.

In figure 3, when CA 3 performed key rollover, it requested a new CA certificate from the Root CA.  CA 3 did not generated self-issued key rollover certificates.

Of course, another realistic scenario would be one in which a CA generated self-issued key rollover certificates upon key rollover and then had the Root CA issue a CA certificate to its new key.  In this case, as you suggest, any of the certification paths from figures 1, 2, or 3 could be constructed.

As for the contents of the AIA extension, here is what I have specified in the "X.509 Certificate and CRL Extensions Profile for the Common Policy":

The authorityInfoAccess extension uses URIs for two purposes. When the id-ad-caIssuers access method is used, the access location specifies where certificates issued to the issuer of the certificate may be found. If LDAP is used, the URI must include the DN of the entry containing the relevant certificates and specify the directory attribute in which the certificates are located. If the directory in which the certificates are stored expects the "binary" option to be specified, then the attribute type must be followed by ";binary" in the URI. If HTTP is used, the URI must point to a file that has an extension of ".p7c" that contains a certs-only CMS message (see RFC 2633). The CMS message should include all certificates issued to the issuer of this certificate, but must at least contain all certificates issued to the issuer of this certificate in which the subject public key may be used to verify the signature on this certificate.
....
For a certificate issued by "Good CA", some examples of URIs that may appear as the access location in an authorityInfoAccess extension when the id-ad-caIssuers access method is used are: 
ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACertificate,crossCertificatePair
ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertificate;binary,crossCertificatePair;binary
http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssuedToGoodCA.p7c
For both LDAP and HTTP, the URI provides the exact location where information is to be located, so there is no requirement for the relying party to try to figure out where information is located.

The HTTP URI points to a certs-only CMS message that includes all certificates issued to the CA identified in the issuer field of the certificate.

The LDAP URI points to the cACertificate and crossCertificatePair attributes of the directory entry of the CA identified in the issuer field of the certificate.  These two attributes together hold all of the certificates issued to the CA:  the cACertificate attribute holds the CA's self-issued certificates and the crossCertificatePair attribute holds the cross-certificates issued to the CA by other CAs.

Dave


Stefan Santesson wrote:

David,
 
Thanks for these good thoughts and very useful scenarios.
 
I have some comments and questions on this.
 
First of all we can conclude that in some scenarios (figure 1) where a self issued certificate is inserted into the path, you are likely to find the CRL issuer cert in the path. (given that the new CA have a common key and certificate for cert signing and CRL signing).
 
Figure 1, 2 and 3 describe the same case. It is just describing different path building strategies. An application that has access locally to all chaining options may however still choose path 2 for the certs and path 1 for the CRL independent of each other (which I think figure 3 tries to describe)
 
Another comment is the structure of AIA extensions. The use I'm familiar with doesn't use AIA to describe a directory entry where it is left to the validation application logic to be intelligent enough to find appropriate certificate data from the directory. The model I'm familiar with is when the AIA URL explicitly identifies the exact location of the appropriate CA certificate file, relieving the validation software from complex information queries.
If just location of explicit certificate files are identified through AIA, the presence of an AIA may not help finding the CRL signer cert if this is different from the CA certificate.
This is also the problem with Denis proposal.
 
I think we share the basic conclusion that the ability to locate the CRL signer certificate directly through the CRL could be very useful. At least in the case of indirect CRL but it could also be proven very useful in CA re-keying scenarios.
 
The easiest solution would probably be to allow AIA to be used in its current shape and structure as a CRL extension (MUST NOT be critical).
It would present a very clear and uncomplicated logic to certificate validating applications in many cases.
 
Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 
  
________________________________________
From: David A. Cooper [mailto:[e-mail]] 
Sent: den 7 oktober 2004 18:35
To: Stefan Santesson
Cc: pkix
Subject: Re: Signer certificate discovery for CRLs
 
Stefan,

I think what you are proposing is a good idea.  In most cases, path discovery algorithms assume that both the trust anchor (or trust anchors) and the end entity certificate are provided as input.  In this case, one may need to construct a certification path without a priori access to the end entity certificate (the one with the subject public key corresponding to the CRL signing key).  Including an AIA extension (or some other pointer) in the CRL would provide the relying party with a simple way to obtain the end entity certificate for the CRL signing key's certification path.
On the other hand, I believe that a relying party should be able to construct the certification path even without an AIA extension in the CRL, so long as it is not an indirect CRL.  Attached is a drawing of the three basic scenarios that I expect a relying party may encounter:

In each of these scenarios, the CA has performed key rollover and is only signing CRLs with its new key.  The diagrams would look similar, however, if the CA simply choose to use different keys to sign certificates and CRLs for some other reason.

If the PKI architecture resembled figure 1, then the certification path for the CRL signing key would just be a subset of the certification path for the EE certificate, so no addition path discovery would be needed.

If the PKI architecture resembled figure 1, then it would be necessary to obtain the new-signed-with-old self-issued certificate.  In building the certification path to the EE certificate, however, the relying party will obtain the certificates pointed to by the AIA extension in the EE certificate.  This AIA extension will point to a location containing all certificates issued to CA 2, which would include both the certificate issued by the Root to CA 2 and CA 2's self-issued certificate.  So, even though the self-issued certificate would not be part of the certification path to the EE certificate, it would be downloaded by the relying party during the construction of that certification path.  (Yes, there are circular dependency issues in figure 2, but that is another issue.)

A similar situation would happen if the PKI architecture resembled figure 3.  The AIA extension in the EE certificate would point to a location containing certificates issued to CA 3.  When the relying party downloaded these certificates, it would obtain both of the certificates issued by the Root to CA 3 and so again would have the certificate needed to validate the CRL signing key.

In the case of an indirect CRL, things may not work as well.  If indirect CRLs were used, and the PKI architecture resembled figures 2 or 3 (replacing "New Key" with a different CA), then the set of certificates pointed to by the AIA extension in the EE certificate would not include the certificate of the CRL signer.  One could find this certificate by building in the reverse direction and using the SIA extension, but that may not be the most convenient solution.

So, when indirect CRLs are being used, it seems that it would be very useful to have a pointer in the CRL to the CRL signing certificate.  When the CRL is not indirect, the need for this pointer does not seem to be as clear, but I can't see any harm in including it.

Dave

Stefan Santesson wrote:
All,
 
I'm interested in the opinion from members on this list about discovery
of CRL signer's certificate in non directory centric environments.
 
The problem is the following.
 
The relying party (RP) needs to check validity of a certificate and
finds a CDP extension with a URL to the CRL.
The RP retrieves this CRL which in this particular case is either signed
by another key of the CA (re-keyed CA) or another entity (indirect CRL).
 
In this case the relying party needs to obtain the certificate of the
CRL signer which may NOT be part of the original chain. In a directory
centric solution this is retrieved from the directory, but what if such
directory is not available or accessible.
 
The RP have thus no hint where to find the CRL issuers certificate
unless the RP already have possession of it by some other means.
 
Is seems that CRLs would need an AIA extension with the option to point
to the location of the signers certificate in the same manner as is
possible for certificates.
 
Maybe AIA should be defined as both cert and CRL extension and not only
certificate extension as today.
 
Thoughts and comments?
 
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 i9CND0hm086024; Tue, 12 Oct 2004 16:13:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CND0IZ086023; Tue, 12 Oct 2004 16:13:00 -0700 (PDT)
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 i9CNCwBr086012 for <[e-mail]>; Tue, 12 Oct 2004 16:12:59 -0700 (PDT) (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.0); Wed, 13 Oct 2004 00:13:07 +0100
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: Signer certificate discovery for CRLs
Date: Wed, 13 Oct 2004 00:13:01 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcSsi59HNDaxgiOaSnmBsFvKoKsrwwD1u3yAABORzKA=
From: "Stefan Santesson" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 12 Oct 2004 23:13:07.0508 (UTC) FILETIME=[08B64740:01C4B0B1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9CNCxBr086018
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Re-sending since original html mail was too long with pictures from David Cooper.

Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 
  
________________________________________
From: Stefan Santesson 
Sent: den 12 oktober 2004 16:41
To: 'David A. Cooper'
Cc: pkix
Subject: RE: Signer certificate discovery for CRLs

David,
 
Thanks for these good thoughts and very useful scenarios.
 
I have some comments and questions on this.
 
First of all we can conclude that in some scenarios (figure 1) where a self issued certificate is inserted into the path, you are likely to find the CRL issuer cert in the path. (given that the new CA have a common key and certificate for cert signing and CRL signing).
 
Figure 1, 2 and 3 describe the same case. It is just describing different path building strategies. An application that has access locally to all chaining options may however still choose path 2 for the certs and path 1 for the CRL independent of each other (which I think figure 3 tries to describe)
 
Another comment is the structure of AIA extensions. The use I'm familiar with doesn't use AIA to describe a directory entry where it is left to the validation application logic to be intelligent enough to find appropriate certificate data from the directory. The model I'm familiar with is when the AIA URL explicitly identifies the exact location of the appropriate CA certificate file, relieving the validation software from complex information queries.
If just location of explicit certificate files are identified through AIA, the presence of an AIA may not help finding the CRL signer cert if this is different from the CA certificate.
This is also the problem with Denis proposal.
 
I think we share the basic conclusion that the ability to locate the CRL signer certificate directly through the CRL could be very useful. At least in the case of indirect CRL but it could also be proven very useful in CA re-keying scenarios.
 
The easiest solution would probably be to allow AIA to be used in its current shape and structure as a CRL extension (MUST NOT be critical).
It would present a very clear and uncomplicated logic to certificate validating applications in many cases.
 
Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 
  
________________________________________
From: David A. Cooper [mailto:[e-mail]] 
Sent: den 7 oktober 2004 18:35
To: Stefan Santesson
Cc: pkix
Subject: Re: Signer certificate discovery for CRLs
 
Stefan,

I think what you are proposing is a good idea.  In most cases, path discovery algorithms assume that both the trust anchor (or trust anchors) and the end entity certificate are provided as input.  In this case, one may need to construct a certification path without a priori access to the end entity certificate (the one with the subject public key corresponding to the CRL signing key).  Including an AIA extension (or some other pointer) in the CRL would provide the relying party with a simple way to obtain the end entity certificate for the CRL signing key's certification path.

On the other hand, I believe that a relying party should be able to construct the certification path even without an AIA extension in the CRL, so long as it is not an indirect CRL.  Below I have drawn the three basic scenarios that I expect a relying party may encounter:


In each of these scenarios, the CA has performed key rollover and is only signing CRLs with its new key.  The diagrams would look similar, however, if the CA simply choose to use different keys to sign certificates and CRLs for some other reason.

If the PKI architecture resembled figure 1, then the certification path for the CRL signing key would just be a subset of the certification path for the EE certificate, so no addition path discovery would be needed.

If the PKI architecture resembled figure 1, then it would be necessary to obtain the new-signed-with-old self-issued certificate.  In building the certification path to the EE certificate, however, the relying party will obtain the certificates pointed to by the AIA extension in the EE certificate.  This AIA extension will point to a location containing all certificates issued to CA 2, which would include both the certificate issued by the Root to CA 2 and CA 2's self-issued certificate.  So, even though the self-issued certificate would not be part of the certification path to the EE certificate, it would be downloaded by the relying party during the construction of that certification path.  (Yes, there are circular dependency issues in figure 2, but that is another issue.)

A similar situation would happen if the PKI architecture resembled figure 3.  The AIA extension in the EE certificate would point to a location containing certificates issued to CA 3.  When the relying party downloaded these certificates, it would obtain both of the certificates issued by the Root to CA 3 and so again would have the certificate needed to validate the CRL signing key.

In the case of an indirect CRL, things may not work as well.  If indirect CRLs were used, and the PKI architecture resembled figures 2 or 3 (replacing "New Key" with a different CA), then the set of certificates pointed to by the AIA extension in the EE certificate would not include the certificate of the CRL signer.  One could find this certificate by building in the reverse direction and using the SIA extension, but that may not be the most convenient solution.

So, when indirect CRLs are being used, it seems that it would be very useful to have a pointer in the CRL to the CRL signing certificate.  When the CRL is not indirect, the need for this pointer does not seem to be as clear, but I can't see any harm in including it.

Dave

Stefan Santesson wrote:
All,
 
I'm interested in the opinion from members on this list about discovery
of CRL signer's certificate in non directory centric environments.
 
The problem is the following.
 
The relying party (RP) needs to check validity of a certificate and
finds a CDP extension with a URL to the CRL.
The RP retrieves this CRL which in this particular case is either signed
by another key of the CA (re-keyed CA) or another entity (indirect CRL).
 
In this case the relying party needs to obtain the certificate of the
CRL signer which may NOT be part of the original chain. In a directory
centric solution this is retrieved from the directory, but what if such
directory is not available or accessible.
 
The RP have thus no hint where to find the CRL issuers certificate
unless the RP already have possession of it by some other means.
 
Is seems that CRLs would need an AIA extension with the option to point
to the location of the signers certificate in the same manner as is
possible for certificates.
 
Maybe AIA should be defined as both cert and CRL extension and not only
certificate extension as today.
 
Thoughts and comments?
 
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 i9BIOBa4024416; Mon, 11 Oct 2004 11:24:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9BIOBuM024415; Mon, 11 Oct 2004 11:24:11 -0700 (PDT)
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 i9BIO8fh024393 for <[e-mail]>; Mon, 11 Oct 2004 11:24:08 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CH4kl-0001EM-Rx; Mon, 11 Oct 2004 14:18:35 -0400
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: Protocol Action: 'Internet X.509 Public Key Infrastructure  Permanent Identifier' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Mon, 11 Oct 2004 14:18:35 -0400
Sender: [e-mail]
Precedence: 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 Permanent Identifier '
   <draft-ietf-pkix-pi-11.txt> as a Proposed Standard

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

The IESG contact persons are Russ Housley and Steve Bellovin.

Technical Summary

  This document define a new form of name, called permanent identifier,
  that may be included in the subjectAltName extension of an X.509
  version 3 public key certificate.  The permanent identifier is an
  optional feature that may be used by a Certification Authority (CA) to
  indicate that the certificate relates to the same entity even if the
  name or the affiliation of that entity stored in the subject or
  another name form in the subjectAltName extension has changed.  The
  subject name, carried in the subject field, is only unique for each
  subject entity certified by the one CA as identified by the issuer
  name field.  Also, the new name form can carry a name that is unique
  for each subject entity certified by a CA.

Working Group Summary

  The Working Group came to consensus on this document.

Protocol Quality

  This document was reviewed by Jeffrey I. Schiller and Russ Housley
  for the IESG.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98NqOaR088770; Fri, 8 Oct 2004 16:52:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i98NqOsW088769; Fri, 8 Oct 2004 16:52:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98NqO3A088763 for <[e-mail]>; Fri, 8 Oct 2004 16:52:24 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-bvi4-463.fastq.com [65.39.91.210]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i98NqCa35948; Fri, 8 Oct 2004 16:52:12 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Deacon, Alex" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, <[e-mail]>
Subject: RE: New Lightweight OCSP I-D
Date: Fri, 8 Oct 2004 16:50:29 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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>

Alex, Santosh:

A few thoughts embedded below.

Mike


>-----Original Message-----
>From: Deacon, Alex
>Sent: Tuesday, October 05, 2004
>
> . . .
>
> Moving some of the MUSTs to SHOULDs seems to water down
> what we are trying to accomplish.   

I concur.

> > 1.  Section 1.2.2, sha256WithRSAEncryption should be
> > added to the signature algorithms.

> Although I understand the reasoning behind adding this
> requirement, I think doing so is a little premature and
> would create a situation. Where this draft is no longer
> a strict profile of RFC2560.   I think 2560 has to move
> first on this point.  

My action, subject to chair guidance.

Mike



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98L8mrY076194; Fri, 8 Oct 2004 14:08:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i98L8mlu076193; Fri, 8 Oct 2004 14:08:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98L8mdC076187 for <[e-mail]>; Fri, 8 Oct 2004 14:08:48 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i98L8oJR009028; Fri, 8 Oct 2004 14:08:50 -0700 (PDT)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <SRFZGH0L>; Fri, 8 Oct 2004 14:08:50 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: New Lightweight OCSP I-D
Date: Fri, 8 Oct 2004 14:08:49 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: 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 again Santosh,

This gives me a better idea as to your concerns so I will go back and work
on a -01 version with your comments in mind.  Look for a new version
sometime next week.

Alex


> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]] 
> Sent: Tuesday, October 05, 2004 3:01 PM
> To: [e-mail]
> Subject: RE: New Lightweight OCSP I-D
> 
> 
> 
> Alex,
> 
> Thanks for your comments.  See my responses in-line using [SC:]
> 
> -----Original Message-----
> From: Deacon, Alex [mailto:[e-mail]] 
> Sent: Tuesday, October 05, 2004 3:00 PM
> To: 'Santosh Chokhani'; [e-mail]
> Subject: RE: New Lightweight OCSP I-D
> 
> 
> 
> Santosh,
> 
> Thanks for taking the time to review the draft.  Comments in line....
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Monday, October 04, 2004 6:54 AM
> > To: [e-mail]
> > Subject: New Lightweight OCSP I-D
> >
> > I have some concerns regarding the new RFC.  There are several items
> > in the I-D that are good engineering advice, but they go far beyond
> > what should be within the scope of the RFC and should be up to the
> > application and relying party.  These are listed as MUST in the RFC 
> > and should be changed to SHOULD or RECOMMENDED.  These items are 
> > included in the comments below.
> 
> Remember that the main motivation of this draft is to define 
> a profile of
> OCSP that ensures OCSP scalability (including bandwidth issues and
> client/server processing) when used in large PKI 
> environments.  Moving some
> of the MUSTs to SHOULDs seems to water down what we are
> trying to accomplish.   Also, our goal is to not make current client
> implementations non-conformant, but to define behavior when these
> clients find themselves in high volume environments.   We will make
> this clearer in the introduction for -01.  
> 
> [SC: I am aware of this.  Most of my comments are related to 
> client behavior
> and not to the bits on the wire.  The possible exception 
> being the mandatory
> caching of the responses.  There, I felt the client simplicity should
> drive.]
> 
> > 1.  Section 1.2.2, sha256WithRSAEncryption should be added to the 
> > signature algorithms.
> 
> Although I understand the reasoning behind adding this 
> requirement, I think
> doing so is a little premature and would create a situation
> Where this draft is no longer a strict profile of RFC2560.   I think
> 2560 has to move first on this point. 
> 
> [SC: 2560 does not limit the signing algorithm.  It imports 
> these.  3280
> also is not dependent.  They bring in the algorithm 
> identifiers from 3279 or
> successor.  I think this I-D should follow the same modular approach.
> Otherwise, we will need to revise it in another year] 
> 
> > 2.  Section 1.2.2, The term "validity window" for the response is
> > not clear or defined.  I suspect it is thisUpdate and nextUpdate for
> > the response.  It should be defined.  Furthermore, there is no 
> > reason for the Responder certificate validity period to envelope 
> > the response window.  For example, the Responder may have been 
> > issued a new certificate since thisUpdate or may get a new 
> > certificate before nextUpdate.  Thus, this requirement is excessive.
> > Also, it is not clear why this requirement is imposed from security 
> > viewpoint.
> 
> Well, from a security point of view its my opinion that a 
> properly behaved
> OCSP responder would always ensure that responses it creates 
> are enveloped
> within the validity period of the certificate it uses to sign 
> the responses.
> If one assumes that the OCSP responder certificate is a 
> license to issue
> responses a responder should not be entitled to issue a response that
> exceeds his license to make such statements.
> 
> [SC: The above text is not a security argument.  Actually, there is no
> security issue in this topic or a security reason to envelop 
> the validity
> period in a revocation entry with that of the Responder 
> certificate.  One
> could try to say that producedAt should fall within the 
> certificate validity
> period.  But, even that is not necessary.  Furthermore, since 
> you recommend
> short validity period for Responder, this may pose a problem. 
>  Imagine a CA
> issuing weekly or daily CRL and Responder renewing it 
> certificate monthly.
> You do not want to change thisUpdate or nextUpdate.  You may 
> not be able to
> use old or the new certificate.  Aside from being useless 
> from security
> viewpoint, you could be in a deadlock at worst and adding the 
> complexity to
> the Responder and the client that is not needed and 2560 does 
> not advocate
> it.]
> 
> >From a more practical point of view, there exist many widely deployed
> clients that will fail OCSP response validation if this 
> nesting does not
> occur.  Thus we were hoping to increase interop with the 
> existing client
> base with this requirement.  You will note that this draft is 
> currently
> specified as informational due in some part to the fact that 
> it defines
> existing and deployed implementations.  
> 
> [SC: If we defined PKI mantra using some of the widely 
> deployed products, we
> would have security holes the size of pacific ocean.  We do 
> not change the
> security principles and standards because commercial products 
> do it one way.
> As to informational RFC, may be you or some one can explain 
> to me what the
> term MUST means for informational.  My comments are oriented towards
> enhancing interoperability.]
> 
> Having said that, I agree clarification would be helpful.  Here is a
> proposed update to the 3rd paragraph of section 1.2.2 -      
> 
> 1.2.2 Signed OCSPResponses 
> 
> [...]
> 
>     The response validity period is the time interval during 
>     which the responder warrants that the response is accurate, 
>     it is represented as two dates: the date in which the 
>     response validity period begins (thisUpdate) and the date
>     in which the response validity period ends (nextUpdate). The 
>     response validity period SHOULD NOT exceed the validity period
>     of the responders certificate.  
>     
> [SC: See previous response]
> 
> > 3.  Section 1.2.3, It is not clear if the certificate has 
> expired and 
> > the Responder does not maintain revocation status of expired 
> > certificates, what the response should be.  May be 
> "unauthorized" is 
> > meant.  If so, this should be made clearer.
> 
> OK.  We will update the last paragraph of Section 1.2.3 as follows:
> 
>     The responder will return an OCSPResponseStatus of "unauthorized" 
>     when processing requests for which it is not capable of 
> responding 
>     authoritatively. This includes the scenario where a responder has 
>     removed the records of expired certificate from its database. 
> 
> [SC: Thanks] 
> 
> > 4.  Section 2.1, The recognition of AIA should be changed from MUST
> > to RECOMMENDED.  Using MUST means that clients and implementations 
> > that use OCSP Responder as trust anchor, will have an added 
> > requirement.
> 
> I think its important that if a CA includes an OCSP AIA 
> extension in the
> cert that all clients have the ability to recognize this 
> extension. The
> requirement does not mandate a client communicate with the 
> responder on the
> other side of the AIA URI...just that it has the option of 
> doing so (or not
> doing so) based on local policy. 
> 
> [SC: I am ok with AIA as MUST for an informational RFC]
> 
> > 5.  Section 2.1, The requirement to check OCSP before CRL 
> as a MUST is 
> > excessive.  This should be recommended.  It should be left 
> up to the 
> > implementation to determine whether to use CRL or OCSP.
> 
> Well...I think asking for a CRL that may be many megabytes when a
> simple/small OCSP request/response would do the trick is also 
> excessive :)
> If others feel the MUST here is excessive I'll change to a SHOULD. 
> 
> [SC: I think we should change it]
> 
> > 6.  Section 2.2, The order in which path is validated and when the 
> > OCSP response is requested, should be changed from MUST to 
> > RECOMMENDED.  This should be an application decision.
> 
> If a client is unable to validate a signature on a cert, why 
> would it bother
> to hit the wire to determine the certs status?Remember that 
> one goal of this
> ID is to limit clients hits to the server and thus we are 
> suggesting that
> applications using OCSP clients in these scenarios (not all 
> scenarios mind
> you) validate the cert first, before it hits the wire to ask for its
> revocation status.  What if we qualified this MUST as follows: 
> 
> 2.2 Sending an OCSP Request 
>      
>     To avoid needless network traffic, when applications are 
> operating 
>     as a lightweight OCSP client they MUST verify the signature of 
>     signed data before asking an OCSP client to check the status of 
>     certificates used to verify the data. If the signature is invalid 
>     or the application is not able to verify it, an OCSP check MUST
>     NOT be requested. 
> 
> [SC: My comments are based on giving the leeway to the 
> clients since these
> things do not impact interoperability or security.  That is 
> why this should
> be RECOMMENDED.]
> 
> > 7. Section 3, When nonce is not included in the request or 
> response, 
> > another way to check freshness are producedAt and thisUpdate.
> > These should be described in this section.
> 
> Agreed.  We mention this in section 3, but don't elaborate.
> 
> [SC: Thanks]
> 
> > 
> > 8.Section 3, The checks for nextUpdate that are MUST should 
> be changed 
> > to RECOMMENDED.  Basically, freshness check should be based on the 
> > local policy and this I-D should RECOMMEND items based on a 
> > combination of the three dates asserted in the response.
> 
> We are saying that when a client is configured (via local policy or
> otherwise) to work in a highvolume/lightweight mode it must make these
> checks.  We are not mandating that clients always operate in 
> this mode.
> Would qualifying this MUST such that it applies to OCSP 
> clients operating in
> a lightweight/highvolume environment (as suggested for #6
> above) do the trick?
> 
> [SC: Again, I do not see why lightweight high volume relates 
> to thus.  The
> client should be able to use any of the three mechanisms and 
> local policy to
> determine if a response is fresh enough.  This is another 
> case of having a
> more stringent requirement and creating extra bits on the 
> wire, when local
> policy or other two dates will help accept a response.]
> 
> >
> > 9.Section 5.1, Caching should be RECOMMEND and not MUST.
> 
> I disagree...especially when clients are operating in a
> lightweight/highvolume environment.  Caching on the client is key to
> ensuring server load and network bandwidth is kept to a 
> minimum. Again,
> would qualifying this MUST address your issue?  
> 
> [SC: May be qualifying here is the best compromise in the interest of
> bandwidth.]
> 
> > 10.  The I-D should explicitly require the Responders to 
> have access 
> > to accurate source of time in order to assert producedAt 
> and possibly 
> > thisUpdate and nextUpdate, depending on how the Responder asserts 
> > these two values.
> 
> Will add to section 3.  
> 
> [SC: Thanks.]
> 
> Thanks
> Alex
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98JfJhR070149; Fri, 8 Oct 2004 12:41:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i98JfIUv070148; Fri, 8 Oct 2004 12:41:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98JfI5M070138 for <[e-mail]>; Fri, 8 Oct 2004 12:41:18 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28958; Fri, 8 Oct 2004 15:41:19 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pi-11.txt
Date: Fri, 08 Oct 2004 15:41:19 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Internet X.509 Public Key Infrastructure Permanent Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-11.txt
	Pages		: 14
	Date		: 2004-10-8
	
This document define a new form of name, called permanent 
identifier, that may be included in the subjectAltName extension 
of a public key certificate issued to an entity.
The permanent identifier is an optional feature that may be used 
by a CA to indicate that the certificate relates to the same 
entity even if the name or the affiliation of that entity stored 
in the subject or another name form in the subjectAltName extension 
has changed.
The subject name, carried in the subject field, is only unique 
for each subject entity certified by the one CA as defined by the 
issuer name field. Also, the new name form can carry a 
name that is unique for each subject entity certified by a CA.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-11.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-pi-11.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-pi-11.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pi-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-pi-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97GiQWI007921; Thu, 7 Oct 2004 09:44:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i97GiQ5T007920; Thu, 7 Oct 2004 09:44:26 -0700 (PDT)
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 i97GiQgZ007913 for <[e-mail]>; Thu, 7 Oct 2004 09:44:26 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (dpvc-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 i97GiQuY020043 for <[e-mail]>; Thu, 7 Oct 2004 12:44:26 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Signer certificate discovery for CRLs
Date: Thu, 7 Oct 2004 12:44:26 -0400
Message-ID: <000501c4ac8c$e87b4c50$[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 i97GiQgZ007915
Sender: [e-mail]
Precedence: 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 and Denis:

I have reviewed Denis's examples.  They do not seem clear to me.  But, for
both re-key and indirect case (there are several such as assigning a sub CA
or another CA in the PKI domain that is not in any certificate's
certification path), what Stefan has suggested for CRL is a good idea.

I assume that we all realize that having an AIA is not crypto binding.

Separately, while preparing for PKIX, I have had this idea for crypto
binding the certificate signer and CRL signer.  This could be in lieu of
certification path matching algorithm.  A CRL can contain a non-critical
extension which is a SEQUENCE or SET of key identifier (formed using hash
scheme recommended by 3280) of the CAs' certificate signing keys.  A key
identifier is included if the certificate signed using that key can be
included in that CRL.  Now, the relying party only needs to match the AKID
of the certificate with one of the values in this extension.

Please note that this check is a substitute for path matching.  IDP
discipline must still be observed in order to maintain security.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Thursday, October 07, 2004 10:42 AM
To: Stefan Santesson
Cc: [e-mail]
Subject: Re: Signer certificate discovery for CRLs



Stefan,

> All,
> 
> I'm interested in the opinion from members on this list about 
> discovery of CRL signer's certificate in non directory centric 
> environments.
> 
> The problem is the following.
> 
> The relying party (RP) needs to check validity of a certificate and 
> finds a CDP extension with a URL to the CRL.

> The RP retrieves this CRL which in this particular case is either 
> signed by another key of the CA (re-keyed CA) or another entity 
> (indirect CRL).

> In this case the relying party needs to obtain the certificate of the 
> CRL signer which may NOT be part of the original chain.

You mean: "In these cases ..." since there are two cases.  :-)

 > In a directory
> centric solution this is retrieved from the directory, but what if 
> such directory is not available or accessible.
> 
> The RP have thus no hint where to find the CRL issuers certificate 
> unless the RP already have possession of it by some other means.
> 
> Is seems that CRLs would need an AIA extension with the option to 
> point to the location of the signers certificate in the same manner as 
> is possible for certificates.
> 
> Maybe AIA should be defined as both cert and CRL extension and not 
> only certificate extension as today.

I suppose that a candidate certification path has been successfully built, 
but not yet validated as far as certificate revocation status is concerned.

In the first case (re-keyed CA), there may be multiple sub-cases, so you 
would have to be more specific to explain the scenario you have in mind.

In the second case (indirect CRL, no re-keyed CA), let us use a simple
example.

A chain of certificates has been built with:
leaf certificate / CA Cert 1 / CA Cert 2 / ...

In the chain of certificates, if CA Cert 1 (issued by CA 2) includes an AIA 
extension with an AccessDescription id-ad-caIssuers, then the location of a 
repository that may contain CRL issuer certificates may be known: if CA 2 
postes the certificate designating the CRL issuer in that repository, then 
the problem is solved.

" [FROM RFC 3280] The accessLocation field specifies the location of the 
information. The retrieval mechanism may be implied by the accessMethod or 
specified by accessLocation. When id-ad-caIssuers appears as accessMethod, 
the accessLocation field describes the referenced description server and the

access protocol to obtain the referenced description."

In the chain of certificates, if CA Cert 2 (issued by CA 3) includes an 
Subject Information Access (SIA) extension with an AccessDescription 
id-ad-caRepository, then the location of a repository that may contain CRL 
issuer certificates may be known: if CA 2 postes the certificate designating

the CRL issuer in that repository, then the problem is also solved.

Even if these extensions are scarcely (not yet ?) used for that purpose, I
do not think it would be desirable to introduce a third way.

Denis



> Thoughts and comments?
> 
> 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 i97EfkSw097771; Thu, 7 Oct 2004 07:41:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i97EfkbQ097769; Thu, 7 Oct 2004 07:41:46 -0700 (PDT)
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 i97EfhOW097740 for <[e-mail]>; Thu, 7 Oct 2004 07:41:45 -0700 (PDT) (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 QAA15056; Thu, 7 Oct 2004 16:53:08 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004100716413513:230 ; Thu, 7 Oct 2004 16:41:35 +0200 
Message-ID: <[e-mail]>
Date: Thu, 07 Oct 2004 16:41:34 +0200
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: [e-mail]
Subject: Re: Signer certificate discovery for CRLs
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 07/10/2004 16:41:35, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 07/10/2004 16:41:37, Serialize complete at 07/10/2004 16:41:37
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,

> All,
> 
> I'm interested in the opinion from members on this list about discovery
> of CRL signer's certificate in non directory centric environments.
> 
> The problem is the following.
> 
> The relying party (RP) needs to check validity of a certificate and
> finds a CDP extension with a URL to the CRL.

> The RP retrieves this CRL which in this particular case is either signed
> by another key of the CA (re-keyed CA) or another entity (indirect CRL).

> In this case the relying party needs to obtain the certificate of the
> CRL signer which may NOT be part of the original chain. 

You mean: "In these cases ..." since there are two cases.  :-)

 > In a directory
> centric solution this is retrieved from the directory, but what if such
> directory is not available or accessible.
> 
> The RP have thus no hint where to find the CRL issuers certificate
> unless the RP already have possession of it by some other means.
> 
> Is seems that CRLs would need an AIA extension with the option to point
> to the location of the signers certificate in the same manner as is
> possible for certificates.
> 
> Maybe AIA should be defined as both cert and CRL extension and not only
> certificate extension as today.

I suppose that a candidate certification path has been successfully built, 
but not yet validated as far as certificate revocation status is concerned.

In the first case (re-keyed CA), there may be multiple sub-cases, so you 
would have to be more specific to explain the scenario you have in mind.

In the second case (indirect CRL, no re-keyed CA), let us use a simple example.

A chain of certificates has been built with:
leaf certificate / CA Cert 1 / CA Cert 2 / ...

In the chain of certificates, if CA Cert 1 (issued by CA 2) includes an AIA 
extension with an AccessDescription id-ad-caIssuers, then the location of a 
repository that may contain CRL issuer certificates may be known: if CA 2 
postes the certificate designating the CRL issuer in that repository, then 
the problem is solved.

" [FROM RFC 3280] The accessLocation field specifies the location of the 
information. The retrieval mechanism may be implied by the accessMethod or 
specified by accessLocation. When id-ad-caIssuers appears as accessMethod, 
the accessLocation field describes the referenced description server and the 
access protocol to obtain the referenced description."

In the chain of certificates, if CA Cert 2 (issued by CA 3) includes an 
Subject Information Access (SIA) extension with an AccessDescription 
id-ad-caRepository, then the location of a repository that may contain CRL 
issuer certificates may be known: if CA 2 postes the certificate designating 
the CRL issuer in that repository, then the problem is also solved.

Even if these extensions are scarcely (not yet ?) used for that purpose,
I do not think it would be desirable to introduce a third way.

Denis



> Thoughts and comments?
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 




Received: from c-66-41-173-116.mn.client2.attbi.com (c-66-41-173-116.mn.client2.attbi.com [66.41.173.116]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9759epD041189; Wed, 6 Oct 2004 22:10:01 -0700 (PDT) (envelope-from [e-mail])
Received: from agdcb.g287.net [4.246.134.185] by c-66-41-173-116.mn.client2.attbi.com id <5433484-51822>; Thu, 07 Oct 2004 12:10:36 +0600
Message-ID: <20r0n5zj074n-t5@j4y5iw7egfa>
From: "Administrator" <[e-mail]>
To: [e-mail]
Subject: ADV:      Staff Annoucement
Date: Thu, 07 Oct 04 12:10:36 GMT
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: QUALCOMM Windows Eudora Version 5.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="500.8A.__C"

This is a multi-part message in MIME format.

--500.8A.__C
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Nonprofit Organizations: Members and Staff

You Must Respond By 5 P.M. Friday, October 8, 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., Friday, October 8, 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. Friday, October 8, 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. Friday, October 8, 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. Friday, October 8, 2004


Visit our website at http://www.avtechdirectcomputers.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
--500.8A.__C--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96M7A1r008203; Wed, 6 Oct 2004 15:07:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96M7Aui008202; Wed, 6 Oct 2004 15:07:10 -0700 (PDT)
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 i96M782v008186 for <[e-mail]>; Wed, 6 Oct 2004 15:07:09 -0700 (PDT) (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.0); Wed, 6 Oct 2004 23:07:20 +0100
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: Signer certificate discovery for CRLs
Date: Wed, 6 Oct 2004 23:07:07 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signer certificate discovery for CRLs
Thread-Index: AcSlLfouKdNgeEA9TjSnjcEQLQf/dAGwRMUA
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 06 Oct 2004 22:07:20.0866 (UTC) FILETIME=[D9DA0020:01C4ABF0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i96M792v008197
Sender: [e-mail]
Precedence: 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'm interested in the opinion from members on this list about discovery
of CRL signer's certificate in non directory centric environments.

The problem is the following.

The relying party (RP) needs to check validity of a certificate and
finds a CDP extension with a URL to the CRL.
The RP retrieves this CRL which in this particular case is either signed
by another key of the CA (re-keyed CA) or another entity (indirect CRL).

In this case the relying party needs to obtain the certificate of the
CRL signer which may NOT be part of the original chain. In a directory
centric solution this is retrieved from the directory, but what if such
directory is not available or accessible.

The RP have thus no hint where to find the CRL issuers certificate
unless the RP already have possession of it by some other means.

Is seems that CRLs would need an AIA extension with the option to point
to the location of the signers certificate in the same manner as is
possible for certificates.

Maybe AIA should be defined as both cert and CRL extension and not only
certificate extension as today.

Thoughts and comments?

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 i95M1P0U062533; Tue, 5 Oct 2004 15:01:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95M1PTD062532; Tue, 5 Oct 2004 15:01:25 -0700 (PDT)
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 i95M1ODl062526 for <[e-mail]>; Tue, 5 Oct 2004 15:01:24 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (dpvc-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 i95M1Tql008585 for <[e-mail]>; Tue, 5 Oct 2004 18:01:29 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: New Lightweight OCSP I-D
Date: Tue, 5 Oct 2004 18:01:28 -0400
Message-ID: <001a01c4ab26$ddd07670$[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 i95M1PDl062527
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alex,

Thanks for your comments.  See my responses in-line using [SC:]

-----Original Message-----
From: Deacon, Alex [mailto:[e-mail]] 
Sent: Tuesday, October 05, 2004 3:00 PM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: New Lightweight OCSP I-D



Santosh,

Thanks for taking the time to review the draft.  Comments in line....

> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Monday, October 04, 2004 6:54 AM
> To: [e-mail]
> Subject: New Lightweight OCSP I-D
>
> I have some concerns regarding the new RFC.  There are several items
> in the I-D that are good engineering advice, but they go far beyond
> what should be within the scope of the RFC and should be up to the
> application and relying party.  These are listed as MUST in the RFC 
> and should be changed to SHOULD or RECOMMENDED.  These items are 
> included in the comments below.

Remember that the main motivation of this draft is to define a profile of
OCSP that ensures OCSP scalability (including bandwidth issues and
client/server processing) when used in large PKI environments.  Moving some
of the MUSTs to SHOULDs seems to water down what we are
trying to accomplish.   Also, our goal is to not make current client
implementations non-conformant, but to define behavior when these
clients find themselves in high volume environments.   We will make
this clearer in the introduction for -01.  

[SC: I am aware of this.  Most of my comments are related to client behavior
and not to the bits on the wire.  The possible exception being the mandatory
caching of the responses.  There, I felt the client simplicity should
drive.]

> 1.  Section 1.2.2, sha256WithRSAEncryption should be added to the 
> signature algorithms.

Although I understand the reasoning behind adding this requirement, I think
doing so is a little premature and would create a situation
Where this draft is no longer a strict profile of RFC2560.   I think
2560 has to move first on this point. 

[SC: 2560 does not limit the signing algorithm.  It imports these.  3280
also is not dependent.  They bring in the algorithm identifiers from 3279 or
successor.  I think this I-D should follow the same modular approach.
Otherwise, we will need to revise it in another year] 

> 2.  Section 1.2.2, The term "validity window" for the response is
> not clear or defined.  I suspect it is thisUpdate and nextUpdate for
> the response.  It should be defined.  Furthermore, there is no 
> reason for the Responder certificate validity period to envelope 
> the response window.  For example, the Responder may have been 
> issued a new certificate since thisUpdate or may get a new 
> certificate before nextUpdate.  Thus, this requirement is excessive.
> Also, it is not clear why this requirement is imposed from security 
> viewpoint.

Well, from a security point of view its my opinion that a properly behaved
OCSP responder would always ensure that responses it creates are enveloped
within the validity period of the certificate it uses to sign the responses.
If one assumes that the OCSP responder certificate is a license to issue
responses a responder should not be entitled to issue a response that
exceeds his license to make such statements.

[SC: The above text is not a security argument.  Actually, there is no
security issue in this topic or a security reason to envelop the validity
period in a revocation entry with that of the Responder certificate.  One
could try to say that producedAt should fall within the certificate validity
period.  But, even that is not necessary.  Furthermore, since you recommend
short validity period for Responder, this may pose a problem.  Imagine a CA
issuing weekly or daily CRL and Responder renewing it certificate monthly.
You do not want to change thisUpdate or nextUpdate.  You may not be able to
use old or the new certificate.  Aside from being useless from security
viewpoint, you could be in a deadlock at worst and adding the complexity to
the Responder and the client that is not needed and 2560 does not advocate
it.]

>From a more practical point of view, there exist many widely deployed
clients that will fail OCSP response validation if this nesting does not
occur.  Thus we were hoping to increase interop with the existing client
base with this requirement.  You will note that this draft is currently
specified as informational due in some part to the fact that it defines
existing and deployed implementations.  

[SC: If we defined PKI mantra using some of the widely deployed products, we
would have security holes the size of pacific ocean.  We do not change the
security principles and standards because commercial products do it one way.
As to informational RFC, may be you or some one can explain to me what the
term MUST means for informational.  My comments are oriented towards
enhancing interoperability.]

Having said that, I agree clarification would be helpful.  Here is a
proposed update to the 3rd paragraph of section 1.2.2 -      

1.2.2 Signed OCSPResponses 

[...]

    The response validity period is the time interval during 
    which the responder warrants that the response is accurate, 
    it is represented as two dates: the date in which the 
    response validity period begins (thisUpdate) and the date
    in which the response validity period ends (nextUpdate). The 
    response validity period SHOULD NOT exceed the validity period
    of the responders certificate.  
    
[SC: See previous response]

> 3.  Section 1.2.3, It is not clear if the certificate has expired and 
> the Responder does not maintain revocation status of expired 
> certificates, what the response should be.  May be "unauthorized" is 
> meant.  If so, this should be made clearer.

OK.  We will update the last paragraph of Section 1.2.3 as follows:

    The responder will return an OCSPResponseStatus of "unauthorized" 
    when processing requests for which it is not capable of responding 
    authoritatively. This includes the scenario where a responder has 
    removed the records of expired certificate from its database. 

[SC: Thanks] 

> 4.  Section 2.1, The recognition of AIA should be changed from MUST
> to RECOMMENDED.  Using MUST means that clients and implementations 
> that use OCSP Responder as trust anchor, will have an added 
> requirement.

I think its important that if a CA includes an OCSP AIA extension in the
cert that all clients have the ability to recognize this extension. The
requirement does not mandate a client communicate with the responder on the
other side of the AIA URI...just that it has the option of doing so (or not
doing so) based on local policy. 

[SC: I am ok with AIA as MUST for an informational RFC]

> 5.  Section 2.1, The requirement to check OCSP before CRL as a MUST is 
> excessive.  This should be recommended.  It should be left up to the 
> implementation to determine whether to use CRL or OCSP.

Well...I think asking for a CRL that may be many megabytes when a
simple/small OCSP request/response would do the trick is also excessive :)
If others feel the MUST here is excessive I'll change to a SHOULD. 

[SC: I think we should change it]

> 6.  Section 2.2, The order in which path is validated and when the 
> OCSP response is requested, should be changed from MUST to 
> RECOMMENDED.  This should be an application decision.

If a client is unable to validate a signature on a cert, why would it bother
to hit the wire to determine the certs status?Remember that one goal of this
ID is to limit clients hits to the server and thus we are suggesting that
applications using OCSP clients in these scenarios (not all scenarios mind
you) validate the cert first, before it hits the wire to ask for its
revocation status.  What if we qualified this MUST as follows: 

2.2 Sending an OCSP Request 
     
    To avoid needless network traffic, when applications are operating 
    as a lightweight OCSP client they MUST verify the signature of 
    signed data before asking an OCSP client to check the status of 
    certificates used to verify the data. If the signature is invalid 
    or the application is not able to verify it, an OCSP check MUST
    NOT be requested. 

[SC: My comments are based on giving the leeway to the clients since these
things do not impact interoperability or security.  That is why this should
be RECOMMENDED.]

> 7. Section 3, When nonce is not included in the request or response, 
> another way to check freshness are producedAt and thisUpdate.
> These should be described in this section.

Agreed.  We mention this in section 3, but don't elaborate.

[SC: Thanks]

> 
> 8.Section 3, The checks for nextUpdate that are MUST should be changed 
> to RECOMMENDED.  Basically, freshness check should be based on the 
> local policy and this I-D should RECOMMEND items based on a 
> combination of the three dates asserted in the response.

We are saying that when a client is configured (via local policy or
otherwise) to work in a highvolume/lightweight mode it must make these
checks.  We are not mandating that clients always operate in this mode.
Would qualifying this MUST such that it applies to OCSP clients operating in
a lightweight/highvolume environment (as suggested for #6
above) do the trick?

[SC: Again, I do not see why lightweight high volume relates to thus.  The
client should be able to use any of the three mechanisms and local policy to
determine if a response is fresh enough.  This is another case of having a
more stringent requirement and creating extra bits on the wire, when local
policy or other two dates will help accept a response.]

>
> 9.Section 5.1, Caching should be RECOMMEND and not MUST.

I disagree...especially when clients are operating in a
lightweight/highvolume environment.  Caching on the client is key to
ensuring server load and network bandwidth is kept to a minimum. Again,
would qualifying this MUST address your issue?  

[SC: May be qualifying here is the best compromise in the interest of
bandwidth.]

> 10.  The I-D should explicitly require the Responders to have access 
> to accurate source of time in order to assert producedAt and possibly 
> thisUpdate and nextUpdate, depending on how the Responder asserts 
> these two values.

Will add to section 3.  

[SC: Thanks.]

Thanks
Alex




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95IxiFK043142; Tue, 5 Oct 2004 11:59:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95Ixies043141; Tue, 5 Oct 2004 11:59:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95IxiGs043135 for <[e-mail]>; Tue, 5 Oct 2004 11:59:44 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i95IxmY6016845; Tue, 5 Oct 2004 11:59:48 -0700 (PDT)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <SRFZBF97>; Tue, 5 Oct 2004 11:59:47 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: New Lightweight OCSP I-D
Date: Tue, 5 Oct 2004 11:59:44 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: 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 taking the time to review the draft.  Comments in line....

> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]] 
> Sent: Monday, October 04, 2004 6:54 AM
> To: [e-mail]
> Subject: New Lightweight OCSP I-D
>
> I have some concerns regarding the new RFC.  There are several items 
> in the I-D that are good engineering advice, but they go far beyond
> what should be within the scope of the RFC and should be up to the
> application and relying party.  These are listed as MUST in the RFC 
> and should be changed to SHOULD or RECOMMENDED.  These items are 
> included in the comments below.

Remember that the main motivation of this draft is to define a profile
of OCSP that ensures OCSP scalability (including bandwidth issues and
client/server processing) when used in large PKI environments.  Moving
some of the MUSTs to SHOULDs seems to water down what we are
trying to accomplish.   Also, our goal is to not make current client
implementations non-conformant, but to define behavior when these
clients find themselves in high volume environments.   We will make
this clearer in the introduction for -01.  

> 1.  Section 1.2.2, sha256WithRSAEncryption should be added to the
> signature algorithms.

Although I understand the reasoning behind adding this requirement, I
think doing so is a little premature and would create a situation
Where this draft is no longer a strict profile of RFC2560.   I think
2560 has to move first on this point.  

> 2.  Section 1.2.2, The term "validity window" for the response is 
> not clear or defined.  I suspect it is thisUpdate and nextUpdate for
> the response.  It should be defined.  Furthermore, there is no 
> reason for the Responder certificate validity period to envelope 
> the response window.  For example, the Responder may have been 
> issued a new certificate since thisUpdate or may get a new 
> certificate before nextUpdate.  Thus, this requirement is excessive.
> Also, it is not clear why this requirement is imposed from security 
> viewpoint.

Well, from a security point of view its my opinion that a properly
behaved OCSP responder would always ensure that responses it creates
are enveloped within the validity period of the certificate it uses to
sign the responses.  If one assumes that the OCSP responder
certificate is a license to issue responses a responder should not be
entitled to issue a response that exceeds his license to make such
statements.

>From a more practical point of view, there exist many widely deployed
clients that will fail OCSP response validation if this nesting does
not occur.  Thus we were hoping to increase interop with the existing
client base with this requirement.  You will note that this draft is
currently specified as informational due in some part to the fact that
it defines existing and deployed implementations.  

Having said that, I agree clarification would be helpful.  Here is a
proposed update to the 3rd paragraph of section 1.2.2 -      

1.2.2 Signed OCSPResponses 

[...]

    The response validity period is the time interval during 
    which the responder warrants that the response is accurate, 
    it is represented as two dates: the date in which the 
    response validity period begins (thisUpdate) and the date
    in which the response validity period ends (nextUpdate). The 
    response validity period SHOULD NOT exceed the validity period
    of the responders certificate.  
    

> 3.  Section 1.2.3, It is not clear if the certificate has expired
> and the Responder does not maintain revocation status of expired 
> certificates, what the response should be.  May be "unauthorized" is
> meant.  If so, this should be made clearer.

OK.  We will update the last paragraph of Section 1.2.3 as follows:

    The responder will return an OCSPResponseStatus of "unauthorized" 
    when processing requests for which it is not capable of responding 
    authoritatively. This includes the scenario where a responder has 
    removed the records of expired certificate from its database.  

> 4.  Section 2.1, The recognition of AIA should be changed from MUST 
> to RECOMMENDED.  Using MUST means that clients and implementations 
> that use OCSP Responder as trust anchor, will have an added 
> requirement.

I think its important that if a CA includes an OCSP AIA extension in
the cert that all clients have the ability to recognize this extension. The
requirement does not mandate a client communicate with
the responder on the other side of the AIA URI...just that it has the
option of doing so (or not doing so) based on local policy. 

> 5.  Section 2.1, The requirement to check OCSP before CRL as a MUST
> is excessive.  This should be recommended.  It should be left up to
> the implementation to determine whether to use CRL or OCSP.

Well...I think asking for a CRL that may be many megabytes when a
simple/small OCSP request/response would do the trick is also excessive :)
If others feel the MUST here is excessive I'll change
to a SHOULD. 

> 6.  Section 2.2, The order in which path is validated and when the
> OCSP response is requested, should be changed from MUST to
> RECOMMENDED.  This should be an application decision.

If a client is unable to validate a signature on a cert, why would it
bother to hit the wire to determine the certs status?Remember that one
goal of this ID is to limit clients hits to the server and thus we are
suggesting that applications using OCSP clients in these scenarios
(not all scenarios mind you) validate the cert first, before it hits
the wire to ask for its revocation status.  What if we qualified this
MUST as follows: 

2.2 Sending an OCSP Request 
     
    To avoid needless network traffic, when applications are operating 
    as a lightweight OCSP client they MUST verify the signature of 
    signed data before asking an OCSP client to check the status of 
    certificates used to verify the data. If the signature is invalid 
    or the application is not able to verify it, an OCSP check MUST
    NOT be requested. 


> 7. Section 3, When nonce is not included in the request or response,
> another way to check freshness are producedAt and thisUpdate.  
> These should be described in this section.

Agreed.  We mention this in section 3, but don't elaborate.

> 
> 8.Section 3, The checks for nextUpdate that are MUST should be
> changed to RECOMMENDED.  Basically, freshness check should be based
> on the local policy and this I-D should RECOMMEND items based on a
> combination of the three dates asserted in the response.

We are saying that when a client is configured (via local policy or
otherwise) to work in a highvolume/lightweight mode it must make these
checks.  We are not mandating that clients always operate in this
mode.  Would qualifying this MUST such that it applies to OCSP clients
operating in a lightweight/highvolume environment (as suggested for #6
above) do the trick?

>
> 9.Section 5.1, Caching should be RECOMMEND and not MUST.

I disagree...especially when clients are operating in a
lightweight/highvolume environment.  Caching on the client is key to
ensuring server load and network bandwidth is kept to a minimum.
Again, would qualifying this MUST address your issue?  

> 10.  The I-D should explicitly require the Responders to have access
> to accurate source of time in order to assert producedAt and
> possibly thisUpdate and nextUpdate, depending on how the Responder
> asserts these two values.

Will add to section 3.  

Thanks
Alex



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94DsATR037323; Mon, 4 Oct 2004 06:54:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94DsApW037322; Mon, 4 Oct 2004 06:54:10 -0700 (PDT)
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 i94DsAuP037315 for <[e-mail]>; Mon, 4 Oct 2004 06:54:10 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (dpvc-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 i94Ds8ql023569 for <[e-mail]>; Mon, 4 Oct 2004 09:54:09 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: New Lightweight OCSP I-D
Date: Mon, 4 Oct 2004 09:54:08 -0400
Message-ID: <007f01c4aa19$9ef35cf0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01C4A9F8.17E1BCF0"
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_0080_01C4A9F8.17E1BCF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have some concerns regarding the new RFC.  There are several items in =
the
I-D that are good engineering advice, but they go far beyond what should =
be
within the scope of the RFC and should be up to the application and =
relying
party.  These are listed as MUST in the RFC and should be changed to =
SHOULD
or RECOMMENDED.  These items are included in the comments below.
=20
1.  Section 1.2.2, sha256WithRSAEncryption should be added to the =
signature
algorithms.
=20
2.  Section 1.2.2, The term "validity window" for the response is not =
clear
or defined.  I suspect it is thisUpdate and nextUpdate for the response. =
 It
should be defined.  Furthermore, there is no reason for the Responder
certificate validity period to envelope the response window.  For =
example,
the Responder may have been issued a new certificate since thisUpdate or =
may
get a new certificate before nextUpdate.  Thus, this requirement is
excessive.  Also, it is not clear why this requirement is imposed from
security viewpoint.
=20
3.  Section 1.2.3, It is not clear if the certificate has expired and =
the
Responder does not maintain revocation status of expired certificates, =
what
the response should be.  May be "unauthorized" is meant.  If so, this =
should
be made clearer.
=20
4.  Section 2.1, The recognition of AIA should be changed from MUST to
RECOMMENDED.  Using MUST means that clients and implementations that use
OCSP Responder as trust anchor, will have an added requirement.
=20
5.  Section 2.1, The requirement to check OCSP before CRL as a MUST is
excessive.  This should be recommended.  It should be left up to the
implementation to determine whether to use CRL or OCSP.
=20
6.  Section 2.2, The order in which path is validated and when the OCSP
response is requested, should be changed from MUST to RECOMMENDED.  This
should be an application decision.
=20
7.Section 3, When nonce is not included in the request or response, =
another
way to check freshness are producedAt and thisUpdate.  These should be
described in this section.
=20
8.Section 3, The checks for nextUpdate that are MUST should be changed =
to
RECOMMENDED.  Basically, freshness check should be based on the local =
policy
and this I-D should RECOMMEND items based on a combination of the three
dates asserted in the response.
=20
9.Section 5.1, Caching should be RECOMMEND and not MUST.
=20
10.  The I-D should explicitly require the Responders to have access to
accurate source of time in order to assert producedAt and possibly
thisUpdate and nextUpdate, depending on how the Responder asserts these =
two
values.
=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_0080_01C4A9F8.17E1BCF0
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.2180" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D429341400-04102004>I have =
some concerns=20
regarding the new RFC.&nbsp; There are several items in the I-D that are =
good=20
engineering advice, but they go far beyond what should be within the =
scope of=20
the RFC and should be up to the application and relying party.&nbsp; =
These are=20
listed as MUST in the RFC and should be changed to SHOULD or =
RECOMMENDED.&nbsp;=20
These items are included in the comments below.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D429341400-04102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D429341400-04102004>1.&nbsp; Section=20
1.2.2, sha256WithRSAEncryption should be added to the signature=20
algorithms.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D429341400-04102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D429341400-04102004>2.&nbsp; Section=20
1.2.2, The term "validity window" for the response is not clear or=20
defined.&nbsp; I suspect it is thisUpdate and nextUpdate for the =
response.&nbsp;=20
It should be defined.&nbsp; Furthermore, there is no reason for the =
Responder=20
certificate validity period to envelope the response window.&nbsp; For =
example,=20
the Responder may have been issued a new certificate since thisUpdate or =
may get=20
a new certificate before nextUpdate.&nbsp; Thus, this requirement is=20
excessive.&nbsp; Also, it is not clear why this requirement is imposed =
from=20
security viewpoint.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D429341400-04102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D429341400-04102004>3.&nbsp; Section=20
1.2.3, It is not clear if the certificate has expired and the Responder =
does not=20
maintain revocation status of expired certificates, what the response =
should=20
be.&nbsp; May be "unauthorized" is meant.&nbsp; If so, this should be =
made=20
clearer.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D429341400-04102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D429341400-04102004>4.&nbsp; Section=20
2.1, The recognition of AIA should be changed from MUST to =
RECOMMENDED.&nbsp;=20
Using MUST means that clients and implementations that use OCSP =
Responder as=20
trust anchor, will have an added requirement.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D429341400-04102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D429341400-04102004>5.&nbsp; Section=20
2.1, The requirement to check OCSP before CRL as a MUST is =
excessive.&nbsp; This=20
should be recommended.&nbsp; It should be left up to the implementation =
to=20
determine whether to use CRL or OCSP.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D429341400-04102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D429341400-04102004>6.&nbsp; Section=20
2.2, The order in which path is validated and when the OCSP response is=20
requested, should be changed from MUST to RECOMMENDED.&nbsp; This should =
be an=20
application decision.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D429341400-04102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D429341400-04102004>7.Section 3, When=20
nonce is not included in the request or response, another way to check=20
freshness&nbsp;are producedAt and thisUpdate.&nbsp; These should be =
described in=20
this section.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D429341400-04102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D429341400-04102004>8.Section 3, The=20
checks for nextUpdate that are MUST should be changed to =
RECOMMENDED.&nbsp;=20
Basically, freshness check should be based on the local policy and this =
I-D=20
should RECOMMEND items based on a combination of the three dates =
asserted in the=20
response.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D429341400-04102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D429341400-04102004>9.Section 5.1,=20
Caching should be RECOMMEND and not MUST.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D429341400-04102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D429341400-04102004>10.&nbsp; The I-D=20
should explicitly require the Responders to have access to accurate =
source of=20
time in order to assert producedAt and possibly thisUpdate and =
nextUpdate,=20
depending on how the Responder asserts these two =
values.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D429341400-04102004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D429341400-04102004></SPAN></FONT><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2>Santosh Chokhani</FONT></SPAN> =
<BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2>Orion Security Solutions, =
Inc.</FONT></SPAN>=20
<BR><SPAN lang=3Den-us><FONT face=3DArial size=3D2>1489 Chain Bridge =
Road, Suite=20
300</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3DArial =
size=3D2>McLean, Virginia=20
22101</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3DArial =
size=3D2>(703)</FONT>=20
<FONT face=3DArial size=3D2>917</FONT><FONT face=3DArial =
size=3D2>-</FONT><FONT=20
face=3DArial size=3D2>0060</FONT><FONT face=3DArial =
size=3D2></FONT>&nbsp;<FONT=20
face=3DArial size=3D2> </FONT><FONT face=3DArial color=3D#ff0000 =
size=3D2>Ext. 35</FONT>=20
<FONT face=3DArial size=3D2>(</FONT><FONT face=3DArial =
size=3D2>voice</FONT><FONT=20
face=3DArial size=3D2>)</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT =
face=3DArial=20
size=3D2>(703)</FONT> <FONT face=3DArial size=3D2>917</FONT><FONT =
face=3DArial=20
size=3D2>-</FONT><FONT face=3DArial size=3D2>0260</FONT><FONT =
face=3DArial size=3D2>=20
(Fax)</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3DArial=20
size=3D2>[e-mail]</FONT></SPAN> <BR><SPAN =
lang=3Den-us><FONT face=3DArial=20
size=3D2>Visit our Web site</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT =
face=3DArial=20
size=3D2><A=20
href=3D"http://www.orionsec.com/">http://www.orionsec.com</A></FONT></SPA=
N> </DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0080_01C4A9F8.17E1BCF0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91JpYDC053537; Fri, 1 Oct 2004 12:51:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91JpY8a053536; Fri, 1 Oct 2004 12:51:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91JpX1b053530 for <[e-mail]>; Fri, 1 Oct 2004 12:51:34 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11182; Fri, 1 Oct 2004 15:51:34 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-00.txt
Date: Fri, 01 Oct 2004 15:51:34 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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-00.txt
	Pages		: 20
	Date		: 2004-10-1
	
This document defines a lightweight profile of OCSP (RFC 2560) for 
use in very large PKI environments such as SSL/TLS, code signing 
and secure messaging.  In these environments there exists a large 
client base (in the 100's of millions) and thus the ability to 
scale OCSP request handling is very important.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-00.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-00.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-00.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-lightweight-ocsp-profile-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--