Subject: TSA Certificates?

From: Alec Emmons <[email-masked]>
Date: Mon, 27 Sep 2004 10:47:40 -0400 (EDT)

Hello All,

I am looking to purchase a TSA certificate for our time-stamper.  Is anyone
selling TSA certificates?

Cheers,

Alec

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 28 Sep 2004 18:28:38 +1200

>selling TSA certificates?

I'll sell you one.  How much were you expecting to pay?

Peter.

From: "Administrator" <[email-masked]>
To: [email-masked]
Subject: ADV:      Announcement To All Staff
Date: Thu, 30 Sep 04 04:58:11 GMT

This is a multi-part message in MIME format.

--C.2F797.87ECBA__._5E
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Nonprofit Organizations: Members, Staff and Associates:

You Must Respond By 5 P.M. Friday, October 1, 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 1, 2004.

All desktop 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 2004
next generation technology, making these the best performing
computers money can buy.

Avtech Direct is offering these feature rich, top performing
Desktop Computers with the latest Intel technology at an amazing price
to all who call:

    1-800-884-9510 by 5 P.M. Friday, October 1, 2004
    
The fast and powerful AT-2400 series Desktop features: 

      * Intel 2.0Ghz 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 
      * 1.44 Floppy disk drive
      * Next Generation Technology
      * ATI Premium video and sound
      * 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 $699 ........................................ Your Cost $297

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-884-9510 by 5 P.M. Friday, October 1, 2004
     and we will hold the desktops you request on will call. 
  4. You are not obligated in any way.
  5. 100% Satisfaction Guaranteed.

Call Avtech Direct 1-800-884-9510 before 5 P.M. Friday, October 1, 2004

Visit our website at http://www.avtechdirectcomputers.com

If you wish to unsubscribe from this list, please go to:
http://www.computeradvice.org/unsubscribe.asp

Avtech Direct
22647 Ventura Blvd., Suite 374
Woodland Hills, CA 91364
--C.2F797.87ECBA__._5E--

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: TSA Certificates?
Cc: [email-masked]
Date: Tue, 28 Sep 2004 18:28:38 +1200
Sender: [email-masked]

>selling TSA certificates?

I'll sell you one.  How much were you expecting to pay?

Peter.

Date: Mon, 27 Sep 2004 10:47:40 -0400 (EDT)
From: Alec Emmons <[email-masked]>
Reply-To: Alec Emmons <[email-masked]>
To: [email-masked]
Subject: TSA Certificates?
Sender: [email-masked]

Hello All,

Cheers,

Alec

Date: Thu, 23 Sep 2004 15:13:44 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Cc: [email-masked]
Sender: [email-masked]

At 6:11 PM +1200 9/23/04, Peter Gutmann wrote:
>Stephen Kent <[email-masked]> writes:
>
>>The "it just works" model is usually the starting point for a path
>>that leads to failures due to a lack of forethought.
>
>As opposed to the other approach, where you first need to produce
>2000 pages of specifications over a period of 10 years to get to the
>same point.  The main difference with the "it just works" model is
>that it just works for at least some (hopefully the large majority)
>of users, and by extension it does what most users want/expect it to
>do.
>
>Peter (OK, I held back for some time there, but I just had to say it :-).

if we got to the same point via a standards process your cynical 
observation would be valid, but since we don't get to the same point, 
it's merely an attempt at a humorous comment.

I can tell that you are an 80% solution kinda guy. I think such 
solutions are OK for some contexts, but not for security. I don't 
want to fly on an aircraft that has a fuel gage that, most of the 
time works well enough to allow safe passage to the destination, but 
some small fraction of the time reads a bit high and causes the plane 
to crash as it runs out of fuel. Since we develop security standards 
for use by a wide range of applications, we need to work hard to get 
it right for a very wide range of contexts, and allow different 
contexts to focus on the assurance with which the standards are 
implemented, to ensure an appropriate level of security.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 23 Sep 2004 11:19:33 -0400
Importance: Normal
Sender: [email-masked]

I have no objection to adding this to the IDP Section.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, September 23, 2004 11:10 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

> Denis:
> 
> When I read this, "If distribution point field is present.." applies 
> to DP in CRL DP.  My comment is on the DP in IDP.

If you read even more carefully, you will see that this note is to be part 
of the paragraph: "If the distributionPoint field is present ..." that is 
part of section 5.2.5 (on page 59) which only relates to the IDP. If you 
still have problems, please be more specific.

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, September 23, 2004 9:42 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> 
>>Denis:
>>
>>Your suggestion on the text to be added is incomplete and rather than
>>adding the text to the description of the extension, it is covered by 
>>the path validation logic.  The following is an example of 
>>incompleteness:
>>
>>When a DP is absent in the IDP, there us no need to match the DP from
>>the CRL DP.
> 
> 
> If you read more carefully, you will see that this note is to be part 
> of the
> 
> paragraph: If the distributionPoint field is present ...
> 
> Denis
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[email-masked]]
>>Sent: Thursday, September 23, 2004 8:29 AM
>>To: Santosh Chokhani
>>Cc: [email-masked]
>>Subject: Re: CA Rekey and CRL Validation
>>
>>
>>Santosh,
>>
>>I have been away so I could not respond immediately.
>>
>>(text deleted)
>>
>>
>>
>>>2) what kind of processing should a relying party make of it, when 
>>>this field is present ?
>>
>>
>>>[Santosh Says: The relying party should match the DP in CRL DP with 
>>>the DP in DP.  See the X.509 Annex B for further detail on 
>>>calculating the DP in CRL DP]
>>
>>
>>[Denis] Hum !!! I guess you did not meant "should", but "SHALL", and
>>also
>>"IDP" instead of "DP". The correct sentence would then be:
>>
>>"The relying party SHALL match the DP in CRL DP with the DP in IDP."
>>
>>In RFC 3280 we currently have:
>>
>>    If the distributionPoint field is present and contains a URI, the
>>    following semantics MUST be assumed: the object is a pointer to the
>>    most current CRL issued by this CRL issuer.  The URI schemes ftp,
>>    http, mailto [RFC1738] and ldap [RFC1778] are defined for this
>>    purpose.  The URI MUST be an absolute pathname, not a relative
>>    pathname, and MUST specify the host.
>>
>>A note should be added:
>>
>>    Note: For a given certificate that contains a cRLDistributionPoints
>>          extension with a distributionPoint field, in order to make
>>          sure that the right CRL is being accessed, a relying party
>>          SHALL match the distributionPoint field from the
>>          issuingDistributionPoint with the distributionPoint
>>          field from the cRLDistributionPoints extension.
>>
>>Denis
>>
>>
>>
>>>Denis
>>
>>
>>
> 
> 
> 

Date: Thu, 23 Sep 2004 17:09:49 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Santosh,

> Denis:
> 
> When I read this, "If distribution point field is present.." applies to DP
> in CRL DP.  My comment is on the DP in IDP.

If you read even more carefully, you will see that this note is to be part 
of the paragraph: "If the distributionPoint field is present ..." that is 
part of section 5.2.5 (on page 59) which only relates to the IDP. If you 
still have problems, please be more specific.

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Thursday, September 23, 2004 9:42 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> 
>>Denis:
>>
>>Your suggestion on the text to be added is incomplete and rather than 
>>adding the text to the description of the extension, it is covered by 
>>the path validation logic.  The following is an example of 
>>incompleteness:
>>
>>When a DP is absent in the IDP, there us no need to match the DP from 
>>the CRL DP.
> 
> 
> If you read more carefully, you will see that this note is to be part of the
> 
> paragraph: If the distributionPoint field is present ...
> 
> Denis
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[email-masked]]
>>Sent: Thursday, September 23, 2004 8:29 AM
>>To: Santosh Chokhani
>>Cc: [email-masked]
>>Subject: Re: CA Rekey and CRL Validation
>>
>>
>>Santosh,
>>
>>I have been away so I could not respond immediately.
>>
>>(text deleted)
>>
>>
>>
>>>2) what kind of processing should a relying party make of it, when
>>>this
>>>field is present ?
>>
>>
>>>[Santosh Says: The relying party should match the DP in CRL DP with
>>>the DP in DP.  See the X.509 Annex B for further detail on calculating 
>>>the DP in CRL DP]
>>
>>
>>[Denis] Hum !!! I guess you did not meant "should", but "SHALL", and 
>>also
>>"IDP" instead of "DP". The correct sentence would then be:
>>
>>"The relying party SHALL match the DP in CRL DP with the DP in IDP."
>>
>>In RFC 3280 we currently have:
>>
>>    If the distributionPoint field is present and contains a URI, the
>>    following semantics MUST be assumed: the object is a pointer to the
>>    most current CRL issued by this CRL issuer.  The URI schemes ftp,
>>    http, mailto [RFC1738] and ldap [RFC1778] are defined for this
>>    purpose.  The URI MUST be an absolute pathname, not a relative
>>    pathname, and MUST specify the host.
>>
>>A note should be added:
>>
>>    Note: For a given certificate that contains a cRLDistributionPoints
>>          extension with a distributionPoint field, in order to make
>>          sure that the right CRL is being accessed, a relying party
>>          SHALL match the distributionPoint field from the
>>          issuingDistributionPoint with the distributionPoint
>>          field from the cRLDistributionPoints extension.
>>
>>Denis
>>
>>
>>
>>>Denis
>>
>>
>>
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 23 Sep 2004 09:49:29 -0400
Importance: Normal
Sender: [email-masked]

Denis:

When I read this, "If distribution point field is present.." applies to DP
in CRL DP.  My comment is on the DP in IDP.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, September 23, 2004 9:42 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

> Denis:
> 
> Your suggestion on the text to be added is incomplete and rather than 
> adding the text to the description of the extension, it is covered by 
> the path validation logic.  The following is an example of 
> incompleteness:
> 
> When a DP is absent in the IDP, there us no need to match the DP from 
> the CRL DP.

If you read more carefully, you will see that this note is to be part of the

paragraph: If the distributionPoint field is present ...

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, September 23, 2004 8:29 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> I have been away so I could not respond immediately.
> 
> (text deleted)
> 
> 
>>2) what kind of processing should a relying party make of it, when
>>this
>>field is present ?
> 
> 
>>[Santosh Says: The relying party should match the DP in CRL DP with
>>the DP in DP.  See the X.509 Annex B for further detail on calculating 
>>the DP in CRL DP]
> 
> 
> [Denis] Hum !!! I guess you did not meant "should", but "SHALL", and 
> also
> "IDP" instead of "DP". The correct sentence would then be:
> 
> "The relying party SHALL match the DP in CRL DP with the DP in IDP."
> 
> In RFC 3280 we currently have:
> 
>     If the distributionPoint field is present and contains a URI, the
>     following semantics MUST be assumed: the object is a pointer to the
>     most current CRL issued by this CRL issuer.  The URI schemes ftp,
>     http, mailto [RFC1738] and ldap [RFC1778] are defined for this
>     purpose.  The URI MUST be an absolute pathname, not a relative
>     pathname, and MUST specify the host.
> 
> A note should be added:
> 
>     Note: For a given certificate that contains a cRLDistributionPoints
>           extension with a distributionPoint field, in order to make
>           sure that the right CRL is being accessed, a relying party
>           SHALL match the distributionPoint field from the
>           issuingDistributionPoint with the distributionPoint
>           field from the cRLDistributionPoints extension.
> 
> Denis
> 
> 
>>Denis
> 
> 
> 

Date: Thu, 23 Sep 2004 15:41:56 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Santosh,

> Denis:
> 
> Your suggestion on the text to be added is incomplete and rather than adding
> the text to the description of the extension, it is covered by the path
> validation logic.  The following is an example of incompleteness:
> 
> When a DP is absent in the IDP, there us no need to match the DP from the
> CRL DP.

If you read more carefully, you will see that this note is to be part of the 
paragraph: If the distributionPoint field is present ...

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Thursday, September 23, 2004 8:29 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> I have been away so I could not respond immediately.
> 
> (text deleted)
> 
> 
>>2) what kind of processing should a relying party make of it, when 
>>this
>>field is present ?
> 
> 
>>[Santosh Says: The relying party should match the DP in CRL DP with 
>>the DP in DP.  See the X.509 Annex B for further detail on calculating 
>>the DP in CRL DP]
> 
> 
> [Denis] Hum !!! I guess you did not meant "should", but "SHALL", and also 
> "IDP" instead of "DP". The correct sentence would then be:
> 
> "The relying party SHALL match the DP in CRL DP with the DP in IDP."
> 
> In RFC 3280 we currently have:
> 
>     If the distributionPoint field is present and contains a URI, the
>     following semantics MUST be assumed: the object is a pointer to the
>     most current CRL issued by this CRL issuer.  The URI schemes ftp,
>     http, mailto [RFC1738] and ldap [RFC1778] are defined for this
>     purpose.  The URI MUST be an absolute pathname, not a relative
>     pathname, and MUST specify the host.
> 
> A note should be added:
> 
>     Note: For a given certificate that contains a cRLDistributionPoints
>           extension with a distributionPoint field, in order to make
>           sure that the right CRL is being accessed, a relying party
>           SHALL match the distributionPoint field from the
>           issuingDistributionPoint with the distributionPoint
>           field from the cRLDistributionPoints extension.
> 
> Denis
> 
> 
>>Denis
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 23 Sep 2004 09:10:03 -0400
Importance: Normal
Sender: [email-masked]

Denis:

Your suggestion on the text to be added is incomplete and rather than adding
the text to the description of the extension, it is covered by the path
validation logic.  The following is an example of incompleteness:

When a DP is absent in the IDP, there us no need to match the DP from the
CRL DP.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, September 23, 2004 8:29 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

I have been away so I could not respond immediately.

(text deleted)

> 2) what kind of processing should a relying party make of it, when 
> this
> field is present ?

> [Santosh Says: The relying party should match the DP in CRL DP with 
> the DP in DP.  See the X.509 Annex B for further detail on calculating 
> the DP in CRL DP]

[Denis] Hum !!! I guess you did not meant "should", but "SHALL", and also 
"IDP" instead of "DP". The correct sentence would then be:

"The relying party SHALL match the DP in CRL DP with the DP in IDP."

In RFC 3280 we currently have:

    If the distributionPoint field is present and contains a URI, the
    following semantics MUST be assumed: the object is a pointer to the
    most current CRL issued by this CRL issuer.  The URI schemes ftp,
    http, mailto [RFC1738] and ldap [RFC1778] are defined for this
    purpose.  The URI MUST be an absolute pathname, not a relative
    pathname, and MUST specify the host.

A note should be added:

    Note: For a given certificate that contains a cRLDistributionPoints
          extension with a distributionPoint field, in order to make
          sure that the right CRL is being accessed, a relying party
          SHALL match the distributionPoint field from the
          issuingDistributionPoint with the distributionPoint
          field from the cRLDistributionPoints extension.

Denis

> Denis

Date: Thu, 23 Sep 2004 14:28:35 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Santosh,

I have been away so I could not respond immediately.

(text deleted)

> 2) what kind of processing should a relying party make of it, when this 
> field is present ?

> [Santosh Says: The relying party should match the DP in CRL DP with the DP
> in DP.  See the X.509 Annex B for further detail on calculating the DP in
> CRL DP]

[Denis] Hum !!! I guess you did not meant "should", but "SHALL", and also 
"IDP" instead of "DP". The correct sentence would then be:

"The relying party SHALL match the DP in CRL DP with the DP in IDP."

In RFC 3280 we currently have:

    If the distributionPoint field is present and contains a URI, the
    following semantics MUST be assumed: the object is a pointer to the
    most current CRL issued by this CRL issuer.  The URI schemes ftp,
    http, mailto [RFC1738] and ldap [RFC1778] are defined for this
    purpose.  The URI MUST be an absolute pathname, not a relative
    pathname, and MUST specify the host.

A note should be added:

    Note: For a given certificate that contains a cRLDistributionPoints
          extension with a distributionPoint field, in order to make
          sure that the right CRL is being accessed, a relying party
          SHALL match the distributionPoint field from the
          issuingDistributionPoint with the distributionPoint
          field from the cRLDistributionPoints extension.

Denis

> Denis

Date: Thu, 23 Sep 2004 10:02:52 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: Stefan Santesson <[email-masked]>
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

To the list,

It is time to work on a correction to correct the defective text of RFC 3280.

I took the opportunity to have a meeting where I met Stefan to work with him 
on a fix. Hereafter is the result.

Current wording in RFC 3280 (page 59):

    The CRL issuer MUST assert the indirectCRL boolean, if the scope of
    the CRL includes certificates issued by authorities other than the
    CRL issuer.

Proposed replacement:

    When the CRL issuer is a CA and the scope of the CRL includes
    certificates issued by other CAs, the indirectCRL boolean MUST asserted.

    When the CRL issuer is not a CA, the indirectCRL boolean MUST asserted.

Denis

> David,
> 
> You are correct, but there are two hats and that's why the text
> should be modified to:
> 
>    If the distributionPoint field is absent, the CRL MUST contain
>    entries for all revoked unexpired certificates *issued* by the
>    issuer CA, if any, within the scope of the CRL
> 
> Using the CRL issuer hat, there is no issued cert.
> 
> Cheers,
> Ed Gerck
> 
> David P. Kemp wrote:
> 
>>
>> Not only do other sections suggest that the CA can be a CRL issuer, the
>> text regarding "CRL issuer" on page 6 is *not* a definition of that 
>> term, it is
>> an item in the list of components in the PKIX architectural model.  That
>> model is shown in the accompanying diagram.
>>
>> Any reasonable reading of the phrase "CRL issuer" in an English language
>> sentence would hold that it means the issuer of a CRL.  There are two
>> components that issue CRLs in the PKIX architecture; one of these
>> components also issues certificates.
>>
>>
>>
>>
>> Stefan Santesson wrote:
>>
>>> Denis,
>>>
>>>  
>>>
>>>> On page 59, we have the following sentence:
>>>>
>>>>    If the distributionPoint field is absent, the CRL MUST contain
>>>>    entries for all revoked unexpired certificates *issued* by the CRL
>>>>    issuer, if any, within the scope of the CRL
>>>>
>>>> This sentence is either ambiguous or incorrect: a CRL issuer does not
>>>> *issue* certificates. On page 7, the definition of a CRL issuer is:
>>>> CRL issuer: an optional system to which a CA delegates the publication
>>>>   
>>>
>>>
>>> of
>>>  
>>>
>>>> certificate revocation lists.
>>>>   
>>>
>>>
>>>
>>> I agree that the definition is not consistent with the standard text in
>>> general. Other sections definitely suggest that the CA can be the CRL
>>> issuer also without delegation.
>>>
>>> From 4.2.1.14  CRL Distribution Points:
>>>
>>>   If the certificate issuer is not the CRL
>>>   issuer, then the cRLIssuer field MUST be present and contain the Name
>>>   of the CRL issuer.  If the certificate issuer is also the CRL issuer,
>>>   then the cRLIssuer field MUST be omitted and the distributionPoint
>>>   field MUST be present.
>>>
>>>
>>> Stefan Santesson
>>> Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>>  
>>>
>>
>>
>>
>>
> 
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: CA Rekey and CRL Validation
Cc: [email-masked]
Date: Thu, 23 Sep 2004 18:11:44 +1200
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>The "it just works" model is usually the starting point for a path
>that leads to failures due to a lack of forethought.

As opposed to the other approach, where you first need to produce 
2000 pages of specifications over a period of 10 years to get to the
same point.  The main difference with the "it just works" model is 
that it just works for at least some (hopefully the large majority) 
of users, and by extension it does what most users want/expect it to
do.

Peter (OK, I held back for some time there, but I just had to say it :-).

Date: Tue, 21 Sep 2004 16:30:50 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

David A. Cooper wrote:

> Here are a few quotes from X.509:
>
>   1.
>
>       Section 7: "NOTE 1 – Although the _CAs are unambiguously defined
>       by a distinguished name_
>
[...]

> However, these arguments always start with the assumption that one is 
> operating in a PKI in which there are multiple, independent CAs, all 
> of which are considered to be valid CAs in the infrastructure and all 
> of which have the same name. However, in a valid PKI, two different 
> CAs will not have the same name. [...]

I think it's not really a question that they have to be considered valid CA.

The point is in an internet environement, you take an active decision 
when you start accepting a new root, but then you are vulnerable to 
whatever that root does (you can decide to remove it, but it will happen 
only *after* you know it did something inadequate).

And in an open environement, just telling to a root to never emit a CA 
certificate whose distinguished name is not unambiguous with other 
independant CA is not an absolute garantee it will never happen. Even 
unintentionally.

So it may be OK for X.509, but pkix can not say "all CA will emit 
unambiguous distinguished name", and then go on opening security 
breaches if it ever occurs.

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 21 Sep 2004 14:54:41 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C49FE2.933C65BA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Santosh,

=20

Maybe we are not talking about the same problem then :-)

It certainly would have helped in the case discussed in Geneva this
spring but no need to dwell on this here.

The important thing is that the schema is OK.

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

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: den 21 september 2004 13:09
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

=20

Stefan:

=20

The circular problem discussed in last September X.509 meeting is not
related to this.  That one relates to pitfalls of self-issued
certificates.

=20

But, in general, revocation status of a certificate (call is X) must not
be checked using a CRL issuing authority or OCSP Responder whose
certification path validation requires X in the path.

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
	Sent: Tuesday, September 21, 2004 4:49 AM
	To: David A. Cooper; [email-masked]
	Subject: RE: CA Rekey and CRL Validation

	David,

	=20

	Thanks for the summary.

	Some corrections in line:

	=20

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

=09
________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of David A. Cooper
	Sent: den 20 september 2004 21:41
	To: [email-masked]
	Subject: Re: CA Rekey and CRL Validation

	=20

	All,
=09
	I have been on vacation for the past couple of weeks and have
just finished reading through the messages in this thread.  So, I would
now like to comment on some of the issues that have been raised.
=09
	First, as David Kemp noted, the text on page 7 is not a
definition of CRL issuer, it is simply describing one of the components
depicted in figure 1.  Paragraph 3 of section 5 (on page 48) clearly
states:
=09
	   CRL issuers issue CRLs.  In general, the CRL issuer is the
CA.  CAs
	   publish CRLs to provide status information about the
certificates
	   they issued.  However, a CA may delegate this responsibility
to
	   another trusted authority.  Whenever the CRL issuer is not
the CA
	   that issued the certificates, the CRL is referred to as an
indirect
	   CRL.
=09
	As to the main question on this thread, I believe that X.509 is
very clear that a CA is identified by name, not name+key.  Here are a
few quotes from X.509:

	1.  =20
	Section 7: "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." [DC:
If same DN but different keys meant different CAs, then CAs would not be
unambiguously defined by a DN.]

	2.   Section 7: "issuer identifies the entity that has signed
and issued the certificate." [DC: note that this says that the issuer
field of the certificate identifies the entity, not issuer field in
combination with key]

	3.   Section 7: "Self-issued certificate - This is a certificate
where the issuer and the subject are the same CA. A CA might use
self-issued certificates, for example, during a key rollover operation
to provide trust from the old key to the new key." [DC:  If CA were
defined as name+key, then one would not say that a key rollover
certificate had the same CA as both issuer and subject.]

	One is also required to ensure that two different entities are
not assigned the same name:

	1.	Section 8.3.2.1 (subject alternative name extension):
"For every name form used in the GeneralName type, there shall be a name
registration system that ensures that any name used unambiguously
identifies one entity to both certificate issuer and certificate users."

=09
	I realize that some will still argue that X.509 does not
explicitly state that same name =3D same CA even if it does imply that =
it
is the case.  However, if you are going to suggest that X.509 should be
interpreted based on the assumption that different keys means different
CAs, the question I would ask is where in X.509 (or RFC 3280) is there
anything that implies this is the case?

	[Stefan] I don't think anyone is suggesting this interpretation
of X.509. The issue was raised and resolved. There only remains a
suggestion that this should be more directly stated in the standards
(not only indirectly understood from the quotes above).

=09
	Some have argued that X.509 has a security vulnerability unless
the assumption is made that different keys means different CAs.
However, these arguments always start with the assumption that one is
operating in a PKI in which there are multiple, independent CAs, all of
which are considered to be valid CAs in the infrastructure and all of
which have the same name.  However, in a valid PKI, two different CAs
will not have the same name.  So, these people are simply noting that if
one operates a PKI in a manner that is contrary to the rules of X.509
(allowing two different CAs to share the same name), the PKI will not
provide the security assurances promised by X.509.  But, I don't see how
one can argue that this indicates a flaw in X.509.

	[Stefan] This is not correct. The argument was based on the
wrong assumption that it was allowed to issue a CRL covering
certificates issued under just 1 CA key, without having IDP present in
the CRL. It was clarified however that this is not supported practice.

=09
	Santosh has proposed a restricted path validation algorithm for
validating CRL signing keys (ensuring that the certification path for
the CRL signing keys is similar to the certification path for the
certificate being validated) that mitigates that damage that would
result from a PKI in which two CAs share the same name (i.e., it
provides an extra layer of protection). His proposal mitigates the
problem as well as if one required certificates and CRLs to be signed
with the same key.  The main reason I agree with Santosh's proposal,
however, is that I don't see any good reason not to impose the
restriction he proposes, while imposing the restriction makes path
validation more efficient since there are fewer possibilities that need
to be considered.

	[Stefan] I'm OK with this restrictions which also solves other
security issues discussed in ITU (Circular trust)

=09
=09
	Dave
=09
	Stefan Santesson wrote:

	Denis,
	 =20

		On page 59, we have the following sentence:
		=20
		    If the distributionPoint field is absent, the CRL
MUST contain
		    entries for all revoked unexpired certificates
*issued* by the CRL
		    issuer, if any, within the scope of the CRL
		=20
		This sentence is either ambiguous or incorrect: a CRL
issuer does not
		*issue* certificates. On page 7, the definition of a CRL
issuer is:
		CRL issuer: an optional system to which a CA delegates
the publication of
		   =20

		certificate revocation lists.
		   =20

	=20
	I agree that the definition is not consistent with the standard
text in
	general. Other sections definitely suggest that the CA can be
the CRL
	issuer also without delegation.
	=20
	From 4.2.1.14  CRL Distribution Points:
	=20
	   If the certificate issuer is not the CRL
	   issuer, then the cRLIssuer field MUST be present and contain
the Name
	   of the CRL issuer.  If the certificate issuer is also the CRL
issuer,
	   then the cRLIssuer field MUST be omitted and the
distributionPoint
	   field MUST be present.
	 =20

------_=_NextPart_001_01C49FE2.933C65BA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<title>Message</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0cm;
	margin-bottom:5.75pt;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
tt
	{font-family:"Courier New";}
span.emailstyle20
	{font-family:Arial;
	color:navy;}
span.EmailStyle22
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

<body bgcolor=3Dwhite lang=3DDA link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Maybe we are not =
talking
about the same problem then </span></font><font size=3D2 color=3Dnavy
face=3DWingdings><span =
style=3D'font-size:10.0pt;font-family:Wingdings;color:navy'>J</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>It certainly =
would have helped
in the case discussed in Geneva this spring but no need to dwell on this =
here.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>The important =
thing is
that the schema is OK.</span></font></p>

<div>

<p><b><font size=3D2 color=3Dolive face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive;font-weight:bold'>Stefan =
Santesson</span></font></b><span
lang=3DEN-GB> <br>
</span><font size=3D2 color=3Dolive face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive'>Microsoft Security Center of =
Excellence (SCOE)</span></font><span lang=3DEN-GB> <br>
</span><font face=3DArial><span lang=3DEN-GB =
style=3D'font-family:Arial'>&nbsp;</span></font><span
lang=3DEN-GB> </span></p>

</div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;
color:windowtext'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Tahoma;color:windowtext'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Santosh Chokhani<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 21 september =
2004 13:09<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: CA Rekey and =
CRL
Validation</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dgreen =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:green'>Stefan:</span></=
font></b></strong></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:windowtext'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dgreen =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:green'>The circular =
problem
discussed in last September X.509 meeting is not related to this.&nbsp; =
That
one relates to pitfalls of self-issued =
certificates.</span></font></b></strong></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:windowtext'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dgreen =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:green'>But, in =
general,
revocation status of a&nbsp;certificate&nbsp;(call is X) must not be =
checked
using a CRL issuing authority or OCSP Responder whose certification path
validation requires X in the path.</span></font></b></strong></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
color=3Dblack
face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, September =
21, 2004
4:49 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> David A. Cooper;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: CA Rekey and =
CRL
Validation</span></font></p>

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

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Thanks for the =
summary.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Some corrections =
in line:</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<div>

<p><b><font size=3D2 color=3Dolive face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive;font-weight:bold'>Stefan =
Santesson</span></font></b><span
lang=3DEN-GB> <br>
</span><font size=3D2 color=3Dolive face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive'>Microsoft Security Center of =
Excellence (SCOE)</span></font><span lang=3DEN-GB> <br>
</span><font face=3DArial><span lang=3DEN-GB =
style=3D'font-family:Arial'>&nbsp;</span></font><span
lang=3DEN-GB> </span></p>

</div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;
color:windowtext'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Tahoma;color:windowtext'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>David A. Cooper<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 20 september =
2004 21:41<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: CA Rekey and =
CRL
Validation</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>All,<br>
<br>
I have been on vacation for the past couple of weeks and have just =
finished
reading through the messages in this thread.&nbsp; So, I would now like =
to
comment on some of the issues that have been raised.<br>
<br>
First, as David Kemp noted, the text on page 7 is not a definition of =
CRL
issuer, it is simply describing one of the components depicted in figure
1.&nbsp; Paragraph 3 of section 5 (on page 48) clearly states:<br>
<br>
</span></font><tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;
CRL issuers issue CRLs.&nbsp; <u>In general, the CRL issuer is the =
CA.</u>&nbsp;
CAs</span></font></tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">&nbsp;&nbsp; publish CRLs to provide =
status
information about the certificates</font></tt><br>
<tt><font face=3D"Courier New">&nbsp;&nbsp; they issued.&nbsp; However, =
a CA may
delegate this responsibility to</font></tt><br>
<tt><font face=3D"Courier New">&nbsp;&nbsp; another trusted =
authority.&nbsp;
Whenever the CRL issuer is not the CA</font></tt><br>
<tt><font face=3D"Courier New">&nbsp;&nbsp; that issued the =
certificates, the CRL
is referred to as an indirect</font></tt><br>
<tt><font face=3D"Courier New">&nbsp;&nbsp; =
CRL.</font></tt></span></font><br>
<br>
As to the main question on this thread, I believe that X.509 is very =
clear that
a CA is identified by name, not name+key.&nbsp; Here are a few quotes =
from
X.509:</p>

<p style=3D'margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>1.</span></font><font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp; </span></font>
<meta content=3DSB name=3DAUTHOR>
<meta content=3D"20030703;10040000" name=3DCREATED>
<meta content=3DSB name=3DCHANGEDBY>
<meta content=3D"20030710;10030000" name=3DCHANGED>
<meta content=3D"SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS =
-"
name=3DCLASSIFICATION>
<meta
content=3D"Saisie  KJ&#13;&#10;Corr. BAT  17.4.01/KJ&#13;&#10;Corr. 2e =
BAT  4.5.01/KJ&#13;&#10;Ultimes   7.5.01/KJ&#13;&#10;Ultime mail Mme =
Zenobi (7.5)&#13;&#10;Corr. apr&egrave;s ultimes  22.5.01/KJ"
name=3DDESCRIPTION>
<meta content=3D"X.509,X,509" name=3DKEYWORDS>
Section 7: &quot;NOTE 1 &#8211; Although the <u>CAs are unambiguously =
defined
by a distinguished name</u> in the DIT, this does not imply that there =
is any
relationship between the&nbsp; organization of the CAs and the =
DIT.&quot;<font
color=3D"#3333ff"><span style=3D'color:#3333FF'> [DC: If same DN but =
different keys
meant different CAs, then CAs would not be unambiguously defined by a =
DN.]</span></font></p>

<p style=3D'margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>2.</span></font><font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp; =
</span></font>Section 7:
&quot;<b><font face=3DArial><span =
style=3D'font-family:Arial;font-weight:bold'>issuer</span></font></b>
identifies the entity that has signed and issued the certificate.&quot; =
<font
color=3D"#3333ff"><span style=3D'color:#3333FF'>[DC: note that this says =
that the </span></font><b><font
color=3D"#3333ff" face=3DArial><span =
style=3D'font-family:Arial;color:#3333FF;
font-weight:bold'>issuer</span></font></b><font color=3D"#3333ff"><span
style=3D'color:#3333FF'> field of the certificate identifies the entity, =
not
issuer field in combination with key]</span></font></p>

<p style=3D'margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>3.</span></font><font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp; =
</span></font>Section 7:
&quot;Self-issued certificate &#8211; <u>This is a certificate where the =
issuer
and the subject are the same CA</u>. A CA might use self-issued =
certificates,
for example, during a key rollover operation to provide trust from the =
old key
to the new key.&quot; <font color=3D"#3333ff"><span =
style=3D'color:#3333FF'>[DC:&nbsp;
If CA were defined as name+key, then one would not say that a key =
rollover certificate
had the same CA as both issuer and subject.]</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>One is also required to ensure that two =
different
entities are not assigned the same name:</span></font></p>

<ol style=3D'margin-top:0cm' start=3D1 type=3D1>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>Section 8.3.2.1 (subject alternative =
name
     extension): &quot;For every name form used in the =
</span></font><b><font
     face=3DArial><span =
style=3D'font-family:Arial;font-weight:bold'>GeneralName</span></font></b=
     type, there shall be a name registration system that ensures that =
any name
     used unambiguously identifies one entity to both certificate issuer =
and
     certificate users.&quot; </li>
</ol>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><br>
I realize that some will still argue that X.509 does not explicitly =
state that
same name =3D same CA even if it does imply that it is the case.&nbsp; =
However,
if you are going to suggest that X.509 should be interpreted based on =
the
assumption that different keys means different CAs, the question I would =
ask is
where in X.509 (or RFC 3280) is there anything that implies this is the =
case?</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Stefan] I don&#8217;t think anyone is suggesting =
this
interpretation of X.509. The issue was raised and resolved. There only =
remains
a suggestion that this should be more directly stated in the standards =
(not
only indirectly understood from the quotes =
above).</span></font></i></b></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'><br>
Some have argued that X.509 has a security vulnerability unless the =
assumption
is made that different keys means different CAs.&nbsp; </span>However, =
these
arguments always start with the assumption that one is operating in a =
PKI in which
there are multiple, independent CAs, all of which are considered to be =
valid
CAs in the infrastructure and all of which have the same name.&nbsp; =
However,
in a valid PKI, two different CAs will not have the same name.&nbsp; So, =
these
people are simply noting that if one operates a PKI in a manner that is
contrary to the rules of X.509 (allowing two different CAs to share the =
same
name), the PKI will not provide the security assurances promised by
X.509.&nbsp; But, I don't see how one can argue that this indicates a =
flaw in
X.509.</font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Stefan] This is not correct. The argument was based =
on the
wrong assumption that it was allowed to issue a CRL covering =
certificates
issued under just 1 CA key, without having IDP present in the CRL. It =
was
clarified however that this is not supported =
practice.</span></font></i></b></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'><br>
Santosh has proposed a restricted path validation algorithm for =
validating CRL
signing keys (ensuring that the certification path for the CRL signing =
keys is
similar to the certification path for the certificate being validated) =
that
mitigates that damage that would result from a PKI in which two CAs =
share the
same name (i.e., it provides an extra layer of protection). </span>His =
proposal
mitigates the problem as well as if one required certificates and CRLs =
to be
signed with the same key.&nbsp; The main reason I agree with Santosh's
proposal, however, is that I don't see any good reason not to impose the
restriction he proposes, while imposing the restriction makes path =
validation
more efficient since there are fewer possibilities that need to be =
considered.</font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Stefan] I&#8217;m OK with this restrictions which =
also
solves other security issues discussed in ITU (Circular =
trust)</span></font></i></b></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'><br>
<br>
</span>Dave<br>
<br>
Stefan Santesson wrote:</font></p>

<pre wrap=3D""><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Denis,</span></font></pre><pre><font size=3D2
color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp; </span></font></pre>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><pre wrap=3D""><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>On page 59, we have the following =
sentence:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; If the distributionPoint =
field is absent, the CRL MUST contain</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; entries for all revoked =
unexpired certificates *issued* by the CRL</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; issuer, if any, within the =
scope of the CRL</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>This sentence is either ambiguous or =
incorrect: a CRL issuer does not</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>*issue* certificates. On page 7, the =
definition of a CRL issuer is:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>CRL issuer: an optional system to which a CA =
delegates the publication of</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; =
</span></font></pre></blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><pre wrap=3D""><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>certificate revocation =
lists.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; =
</span></font></pre></blockquote>

<pre wrap=3D""><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font size=3D2
color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt'>I =
agree that the definition is not consistent with the standard text =
in</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>general. Other sections definitely suggest =
that the CA can be the CRL</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>issuer also without =
delegation.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>From 4.2.1.14&nbsp; CRL Distribution =
Points:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; If the certificate issuer is not =
the CRL</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; issuer, then the cRLIssuer field =
MUST be present and contain the Name</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; of the CRL issuer.&nbsp; If the =
certificate issuer is also the CRL issuer,</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; then the cRLIssuer field MUST be =
omitted and the distributionPoint</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; field MUST be =
present.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp; </span></font></pre></div>

</blockquote>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C49FE2.933C65BA--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 21 Sep 2004 07:08:51 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00FE_01C49FA9.DCA84080
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan:
=20
The circular problem discussed in last September X.509 meeting is not
related to this.  That one relates to pitfalls of self-issued =
certificates.
=20
But, in general, revocation status of a certificate (call is X) must not =
be
checked using a CRL issuing authority or OCSP Responder whose =
certification
path validation requires X in the path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Stefan Santesson
Sent: Tuesday, September 21, 2004 4:49 AM
To: David A. Cooper; [email-masked]
Subject: RE: CA Rekey and CRL Validation

David,

=20

Thanks for the summary.

Some corrections in line:

=20

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

  _____ =20

From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of David A. Cooper
Sent: den 20 september 2004 21:41
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation

=20

All,

I have been on vacation for the past couple of weeks and have just =
finished
reading through the messages in this thread.  So, I would now like to
comment on some of the issues that have been raised.

First, as David Kemp noted, the text on page 7 is not a definition of =
CRL
issuer, it is simply describing one of the components depicted in figure =
1.
Paragraph 3 of section 5 (on page 48) clearly states:

   CRL issuers issue CRLs.  In general, the CRL issuer is the CA.  CAs
   publish CRLs to provide status information about the certificates
   they issued.  However, a CA may delegate this responsibility to
   another trusted authority.  Whenever the CRL issuer is not the CA
   that issued the certificates, the CRL is referred to as an indirect
   CRL.

As to the main question on this thread, I believe that X.509 is very =
clear
that a CA is identified by name, not name+key.  Here are a few quotes =
from
X.509:

1.  =20

Section 7: "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." [DC: If =
same
DN but different keys meant different CAs, then CAs would not be
unambiguously defined by a DN.]

2.   Section 7: "issuer identifies the entity that has signed and issued =
the
certificate." [DC: note that this says that the issuer field of the
certificate identifies the entity, not issuer field in combination with =
key]

3.   Section 7: "Self-issued certificate - This is a certificate where =
the
issuer and the subject are the same CA. A CA might use self-issued
certificates, for example, during a key rollover operation to provide =
trust
from the old key to the new key." [DC:  If CA were defined as name+key, =
then
one would not say that a key rollover certificate had the same CA as =
both
issuer and subject.]

One is also required to ensure that two different entities are not =
assigned
the same name:

1.	Section 8.3.2.1 (subject alternative name extension): "For every
name form used in the GeneralName type, there shall be a name =
registration
system that ensures that any name used unambiguously identifies one =
entity
to both certificate issuer and certificate users."=20

I realize that some will still argue that X.509 does not explicitly =
state
that same name =3D same CA even if it does imply that it is the case.
However, if you are going to suggest that X.509 should be interpreted =
based
on the assumption that different keys means different CAs, the question =
I
would ask is where in X.509 (or RFC 3280) is there anything that implies
this is the case?

[Stefan] I don't think anyone is suggesting this interpretation of =
X.509.
The issue was raised and resolved. There only remains a suggestion that =
this
should be more directly stated in the standards (not only indirectly
understood from the quotes above).

Some have argued that X.509 has a security vulnerability unless the
assumption is made that different keys means different CAs.  However, =
these
arguments always start with the assumption that one is operating in a =
PKI in
which there are multiple, independent CAs, all of which are considered =
to be
valid CAs in the infrastructure and all of which have the same name.
However, in a valid PKI, two different CAs will not have the same name.  =
So,
these people are simply noting that if one operates a PKI in a manner =
that
is contrary to the rules of X.509 (allowing two different CAs to share =
the
same name), the PKI will not provide the security assurances promised by
X.509.  But, I don't see how one can argue that this indicates a flaw in
X.509.

[Stefan] This is not correct. The argument was based on the wrong =
assumption
that it was allowed to issue a CRL covering certificates issued under =
just 1
CA key, without having IDP present in the CRL. It was clarified however =
that
this is not supported practice.

Santosh has proposed a restricted path validation algorithm for =
validating
CRL signing keys (ensuring that the certification path for the CRL =
signing
keys is similar to the certification path for the certificate being
validated) that mitigates that damage that would result from a PKI in =
which
two CAs share the same name (i.e., it provides an extra layer of
protection). His proposal mitigates the problem as well as if one =
required
certificates and CRLs to be signed with the same key.  The main reason I
agree with Santosh's proposal, however, is that I don't see any good =
reason
not to impose the restriction he proposes, while imposing the =
restriction
makes path validation more efficient since there are fewer possibilities
that need to be considered.

[Stefan] I'm OK with this restrictions which also solves other security
issues discussed in ITU (Circular trust)

Dave

Stefan Santesson wrote:

Denis,
 =20

On page 59, we have the following sentence:
=20
    If the distributionPoint field is absent, the CRL MUST contain
    entries for all revoked unexpired certificates *issued* by the CRL
    issuer, if any, within the scope of the CRL
=20
This sentence is either ambiguous or incorrect: a CRL issuer does not
*issue* certificates. On page 7, the definition of a CRL issuer is:
CRL issuer: an optional system to which a CA delegates the publication =
of
   =20

certificate revocation lists.
   =20

=20
I agree that the definition is not consistent with the standard text in
general. Other sections definitely suggest that the CA can be the CRL
issuer also without delegation.
=20
>From 4.2.1.14  CRL Distribution Points:
=20
   If the certificate issuer is not the CRL
   issuer, then the cRLIssuer field MUST be present and contain the Name
   of the CRL issuer.  If the certificate issuer is also the CRL issuer,
   then the cRLIssuer field MUST be omitted and the distributionPoint
   field MUST be present.
 =20

------=_NextPart_000_00FE_01C49FA9.DCA84080
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>
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 3.0cm 2.0cm 3.0cm 2.0cm; =
}
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; COLOR: black; FONT-FAMILY: "Times =
New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; COLOR: black; FONT-FAMILY: "Times =
New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; COLOR: black; FONT-FAMILY: "Times =
New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-BOTTOM: 5.75pt; MARGIN-LEFT: 0cm; COLOR: black; =
MARGIN-RIGHT: 0cm; FONT-FAMILY: "Times New Roman"
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; COLOR: black; FONT-FAMILY: =
"Courier New"
}
TT {
	FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0cm
}
UL {
	MARGIN-BOTTOM: 0cm
}
</STYLE>
</HEAD>
<BODY lang=3DDA vLink=3Dpurple link=3Dblue bgColor=3Dwhite>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D046060611-21092004>Stefan:</SPAN></FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D046060611-21092004></SPAN></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D046060611-21092004>The circular problem discussed in last =
September X.509=20
meeting is not related to this.&nbsp; That one relates to pitfalls of=20
self-issued certificates.</SPAN></FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D046060611-21092004></SPAN></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D046060611-21092004>But, in general, revocation status of=20
a&nbsp;certificate&nbsp;(call is X) must not be checked using a CRL =
issuing=20
authority or OCSP Responder whose certification path validation requires =
X in=20
the path.</SPAN></FONT></STRONG></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Stefan Santesson<BR><B>Sent:</B> Tuesday, September 21, =
2004=20
  4:49 AM<BR><B>To:</B> David A. Cooper; =
[email-masked]<BR><B>Subject:</B>=20
  RE: CA Rekey and CRL Validation<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">David,</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thanks for =
the=20
  summary.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Some =
corrections in=20
  line:</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <DIV>
  <P><B><FONT face=3DArial color=3Dolive size=3D2><SPAN lang=3DEN-GB=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: olive; =
FONT-FAMILY: Arial">Stefan=20
  Santesson</SPAN></FONT></B><SPAN lang=3DEN-GB> <BR></SPAN><FONT =
face=3DArial=20
  color=3Dolive size=3D2><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: olive; FONT-FAMILY: Arial">Microsoft =
Security=20
  Center of Excellence (SCOE)</SPAN></FONT><SPAN lang=3DEN-GB> =
<BR></SPAN><FONT=20
  face=3DArial><SPAN lang=3DEN-GB=20
  style=3D"FONT-FAMILY: Arial">&nbsp;</SPAN></FONT><SPAN lang=3DEN-GB>=20
  </SPAN></P></DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" color=3Dblack size=3D3><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 12pt; COLOR: windowtext">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma color=3Dblack =
size=3D2><SPAN lang=3DEN-US=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: windowtext; =
FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma color=3Dblack size=3D2><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: Tahoma">=20
  [email-masked] [mailto:[email-masked]] =
<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>David A. =
Cooper<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> den 20 september 2004=20
  21:41<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
  [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B>=20
  Re: CA Rekey and CRL Validation</SPAN></FONT></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">All,<BR><BR>I have been on vacation for the =
past=20
  couple of weeks and have just finished reading through the messages in =
this=20
  thread.&nbsp; So, I would now like to comment on some of the issues =
that have=20
  been raised.<BR><BR>First, as David Kemp noted, the text on page 7 is =
not a=20
  definition of CRL issuer, it is simply describing one of the =
components=20
  depicted in figure 1.&nbsp; Paragraph 3 of section 5 (on page 48) =
clearly=20
  states:<BR><BR></SPAN></FONT><TT><FONT face=3D"Courier New" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; CRL issuers issue CRLs.&nbsp; =
<U>In=20
  general, the CRL issuer is the CA.</U>&nbsp; =
CAs</SPAN></FONT></TT><FONT=20
  face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><BR><TT><FONT=20
  face=3D"Courier New">&nbsp;&nbsp; publish CRLs to provide status =
information=20
  about the certificates</FONT></TT><BR><TT><FONT=20
  face=3D"Courier New">&nbsp;&nbsp; they issued.&nbsp; However, a CA may =
delegate=20
  this responsibility to</FONT></TT><BR><TT><FONT=20
  face=3D"Courier New">&nbsp;&nbsp; another trusted authority.&nbsp; =
Whenever the=20
  CRL issuer is not the CA</FONT></TT><BR><TT><FONT=20
  face=3D"Courier New">&nbsp;&nbsp; that issued the certificates, the =
CRL is=20
  referred to as an indirect</FONT></TT><BR><TT><FONT=20
  face=3D"Courier New">&nbsp;&nbsp; =
CRL.</FONT></TT></SPAN></FONT><BR><BR>As to=20
  the main question on this thread, I believe that X.509 is very clear =
that a CA=20
  is identified by name, not name+key.&nbsp; Here are a few quotes from=20
  X.509:</P>
  <P style=3D"MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt"><FONT face=3D"Times =
New Roman"=20
  color=3Dblack size=3D3><SPAN style=3D"FONT-SIZE: 12pt">1.<FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp; =
</SPAN></FONT></SPAN></FONT>
  <META content=3DSB name=3DAUTHOR>
  <META content=3D20030703;10040000 name=3DCREATED>
  <META content=3DSB name=3DCHANGEDBY>
  <META content=3D20030710;10030000 name=3DCHANGED>
  <META content=3D"SERIES X: DATA NETWORKS AND OPEN SYSTEM =
COMMUNICATIONS -"=20
  name=3DCLASSIFICATION>
  <META=20
  content=3D"Saisie  KJ&#13;&#10;Corr. BAT  17.4.01/KJ&#13;&#10;Corr. 2e =
BAT  4.5.01/KJ&#13;&#10;Ultimes   7.5.01/KJ&#13;&#10;Ultime mail Mme =
Zenobi (7.5)&#13;&#10;Corr. apr&egrave;s ultimes  22.5.01/KJ"=20
  name=3DDESCRIPTION>
  <META content=3DX.509,X,509 name=3DKEYWORDS>Section 7: "NOTE 1 &#8211; =
Although the=20
  <U>CAs are unambiguously defined by a distinguished name</U> in the =
DIT, this=20
  does not imply that there is any relationship between the&nbsp; =
organization=20
  of the CAs and the DIT."<FONT color=3D#3333ff><SPAN style=3D"COLOR: =
#3333ff"> [DC:=20
  If same DN but different keys meant different CAs, then CAs would not =
be=20
  unambiguously defined by a DN.]</SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt"><FONT face=3D"Times =
New Roman"=20
  color=3Dblack size=3D3><SPAN style=3D"FONT-SIZE: 12pt">2.<FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></FONT>Section 7: "<B><FONT face=3DArial><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-FAMILY: =
Arial">issuer</SPAN></FONT></B>=20
  identifies the entity that has signed and issued the certificate." =
<FONT=20
  color=3D#3333ff><SPAN style=3D"COLOR: #3333ff">[DC: note that this =
says that the=20
  </SPAN></FONT><B><FONT face=3DArial color=3D#3333ff><SPAN=20
  style=3D"FONT-WEIGHT: bold; COLOR: #3333ff; FONT-FAMILY: =
Arial">issuer</SPAN></FONT></B><FONT=20
  color=3D#3333ff><SPAN style=3D"COLOR: #3333ff"> field of the =
certificate=20
  identifies the entity, not issuer field in combination with=20
  key]</SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt"><FONT face=3D"Times =
New Roman"=20
  color=3Dblack size=3D3><SPAN style=3D"FONT-SIZE: 12pt">3.<FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></FONT>Section 7: "Self-issued certificate =
&#8211; <U>This is a=20
  certificate where the issuer and the subject are the same CA</U>. A CA =
might=20
  use self-issued certificates, for example, during a key rollover =
operation to=20
  provide trust from the old key to the new key." <FONT =
color=3D#3333ff><SPAN=20
  style=3D"COLOR: #3333ff">[DC:&nbsp; If CA were defined as name+key, =
then one=20
  would not say that a key rollover certificate had the same CA as both =
issuer=20
  and subject.]</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">One is also required to ensure that two =
different=20
  entities are not assigned the same name:</SPAN></FONT></P>
  <OL type=3D1>
    <LI class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">Section 8.3.2.1 (subject alternative name=20
    extension): "For every name form used in the </SPAN></FONT><B><FONT=20
    face=3DArial><SPAN=20
    style=3D"FONT-WEIGHT: bold; FONT-FAMILY: =
Arial">GeneralName</SPAN></FONT></B>=20
    type, there shall be a name registration system that ensures that =
any name=20
    used unambiguously identifies one entity to both certificate issuer =
and=20
    certificate users." </LI></OL>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><BR>I realize that some will still argue =
that X.509=20
  does not explicitly state that same name =3D same CA even if it does =
imply that=20
  it is the case.&nbsp; However, if you are going to suggest that X.509 =
should=20
  be interpreted based on the assumption that different keys means =
different=20
  CAs, the question I would ask is where in X.509 (or RFC 3280) is there =

  anything that implies this is the case?<BR><BR></SPAN></FONT></P>
  <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN lang=3DEN-GB=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: =
italic; FONT-FAMILY: Arial">[Stefan]=20
  I don&#8217;t think anyone is suggesting this interpretation of X.509. =
The issue was=20
  raised and resolved. There only remains a suggestion that this should =
be more=20
  directly stated in the standards (not only indirectly understood from =
the=20
  quotes above).</SPAN></FONT></I></B></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  lang=3DEN-GB style=3D"FONT-SIZE: 12pt"><BR>Some have argued that X.509 =
has a=20
  security vulnerability unless the assumption is made that different =
keys means=20
  different CAs.&nbsp; </SPAN>However, these arguments always start with =
the=20
  assumption that one is operating in a PKI in which there are multiple, =

  independent CAs, all of which are considered to be valid CAs in the=20
  infrastructure and all of which have the same name.&nbsp; However, in =
a valid=20
  PKI, two different CAs will not have the same name.&nbsp; So, these =
people are=20
  simply noting that if one operates a PKI in a manner that is contrary =
to the=20
  rules of X.509 (allowing two different CAs to share the same name), =
the PKI=20
  will not provide the security assurances promised by X.509.&nbsp; But, =
I don't=20
  see how one can argue that this indicates a flaw in =
X.509.<BR><BR></FONT></P>
  <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN lang=3DEN-GB=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: =
italic; FONT-FAMILY: Arial">[Stefan]=20
  This is not correct. The argument was based on the wrong assumption =
that it=20
  was allowed to issue a CRL covering certificates issued under just 1 =
CA key,=20
  without having IDP present in the CRL. It was clarified however that =
this is=20
  not supported practice.</SPAN></FONT></I></B></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  lang=3DEN-GB style=3D"FONT-SIZE: 12pt"><BR>Santosh has proposed a =
restricted path=20
  validation algorithm for validating CRL signing keys (ensuring that =
the=20
  certification path for the CRL signing keys is similar to the =
certification=20
  path for the certificate being validated) that mitigates that damage =
that=20
  would result from a PKI in which two CAs share the same name (i.e., it =

  provides an extra layer of protection). </SPAN>His proposal mitigates =
the=20
  problem as well as if one required certificates and CRLs to be signed =
with the=20
  same key.&nbsp; The main reason I agree with Santosh's proposal, =
however, is=20
  that I don't see any good reason not to impose the restriction he =
proposes,=20
  while imposing the restriction makes path validation more efficient =
since=20
  there are fewer possibilities that need to be =
considered.<BR><BR></FONT></P>
  <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN lang=3DEN-GB=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: =
italic; FONT-FAMILY: Arial">[Stefan]=20
  I&#8217;m OK with this restrictions which also solves other security =
issues=20
  discussed in ITU (Circular trust)</SPAN></FONT></I></B></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  lang=3DEN-GB style=3D"FONT-SIZE: =
12pt"><BR><BR></SPAN>Dave<BR><BR>Stefan Santesson=20
  wrote:<BR><BR></FONT></P><PRE wrap=3D""><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">Denis,</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp; =
</SPAN></FONT></PRE>
  <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite"><PRE wrap=3D""><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">On page 59, we have the =
following sentence:</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp; If the distributionPoint field is absent, the =
CRL MUST contain</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp; entries for all revoked unexpired certificates =
*issued* by the CRL</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp; issuer, if any, within the scope of the =
CRL</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">This sentence is =
either ambiguous or incorrect: a CRL issuer does =
not</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">*issue* certificates. On page =
7, the definition of a CRL issuer is:</SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">CRL issuer: an optional system to which a CA delegates the =
publication of</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp; </SPAN></FONT></PRE></BLOCKQUOTE>
  <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite"><PRE wrap=3D""><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">certificate revocation =
lists.</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp; =
</SPAN></FONT></PRE></BLOCKQUOTE><PRE wrap=3D""><FONT face=3D"Courier =
New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">I agree that the =
definition is not consistent with the standard text =
in</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">general. Other sections =
definitely suggest that the CA can be the =
CRL</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">issuer also without =
delegation.</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">From =
4.2.1.14&nbsp; CRL Distribution Points:</SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; If =
the certificate issuer is not the CRL</SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp; issuer, then the cRLIssuer field MUST be present and =
contain the Name</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; of =
the CRL issuer.&nbsp; If the certificate issuer is also the CRL =
issuer,</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" color=3Dblack =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; then the cRLIssuer =
field MUST be omitted and the =
distributionPoint</SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; =
field MUST be present.</SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp; =
</SPAN></FONT></PRE></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00FE_01C49FA9.DCA84080--

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 21 Sep 2004 09:48:49 +0100
From: "Stefan Santesson" <[email-masked]>
To: "David A. Cooper" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

David,

=20

Thanks for the summary.

Some corrections in line:

=20

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

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: den 20 september 2004 21:41
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation

=20

All,

I have been on vacation for the past couple of weeks and have just
finished reading through the messages in this thread.  So, I would now
like to comment on some of the issues that have been raised.

First, as David Kemp noted, the text on page 7 is not a definition of
CRL issuer, it is simply describing one of the components depicted in
figure 1.  Paragraph 3 of section 5 (on page 48) clearly states:

   CRL issuers issue CRLs.  In general, the CRL issuer is the CA.  CAs
   publish CRLs to provide status information about the certificates
   they issued.  However, a CA may delegate this responsibility to
   another trusted authority.  Whenever the CRL issuer is not the CA
   that issued the certificates, the CRL is referred to as an indirect
   CRL.

As to the main question on this thread, I believe that X.509 is very
clear that a CA is identified by name, not name+key.  Here are a few
quotes from X.509:

1.  =20
Section 7: "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." [DC: If
same DN but different keys meant different CAs, then CAs would not be
unambiguously defined by a DN.]

2.   Section 7: "issuer identifies the entity that has signed and issued
the certificate." [DC: note that this says that the issuer field of the
certificate identifies the entity, not issuer field in combination with
key]

3.   Section 7: "Self-issued certificate - This is a certificate where
the issuer and the subject are the same CA. A CA might use self-issued
certificates, for example, during a key rollover operation to provide
trust from the old key to the new key." [DC:  If CA were defined as
name+key, then one would not say that a key rollover certificate had the
same CA as both issuer and subject.]

One is also required to ensure that two different entities are not
assigned the same name:

1.	Section 8.3.2.1 (subject alternative name extension): "For every
name form used in the GeneralName type, there shall be a name
registration system that ensures that any name used unambiguously
identifies one entity to both certificate issuer and certificate users."

I realize that some will still argue that X.509 does not explicitly
state that same name =3D same CA even if it does imply that it is the
case.  However, if you are going to suggest that X.509 should be
interpreted based on the assumption that different keys means different
CAs, the question I would ask is where in X.509 (or RFC 3280) is there
anything that implies this is the case?

[Stefan] I don't think anyone is suggesting this interpretation of
X.509. The issue was raised and resolved. There only remains a
suggestion that this should be more directly stated in the standards
(not only indirectly understood from the quotes above).

Some have argued that X.509 has a security vulnerability unless the
assumption is made that different keys means different CAs.  However,
these arguments always start with the assumption that one is operating
in a PKI in which there are multiple, independent CAs, all of which are
considered to be valid CAs in the infrastructure and all of which have
the same name.  However, in a valid PKI, two different CAs will not have
the same name.  So, these people are simply noting that if one operates
a PKI in a manner that is contrary to the rules of X.509 (allowing two
different CAs to share the same name), the PKI will not provide the
security assurances promised by X.509.  But, I don't see how one can
argue that this indicates a flaw in X.509.

[Stefan] This is not correct. The argument was based on the wrong
assumption that it was allowed to issue a CRL covering certificates
issued under just 1 CA key, without having IDP present in the CRL. It
was clarified however that this is not supported practice.

Santosh has proposed a restricted path validation algorithm for
validating CRL signing keys (ensuring that the certification path for
the CRL signing keys is similar to the certification path for the
certificate being validated) that mitigates that damage that would
result from a PKI in which two CAs share the same name (i.e., it
provides an extra layer of protection). His proposal mitigates the
problem as well as if one required certificates and CRLs to be signed
with the same key.  The main reason I agree with Santosh's proposal,
however, is that I don't see any good reason not to impose the
restriction he proposes, while imposing the restriction makes path
validation more efficient since there are fewer possibilities that need
to be considered.

[Stefan] I'm OK with this restrictions which also solves other security
issues discussed in ITU (Circular trust)

Dave

Stefan Santesson wrote:

Denis,
 =20

	On page 59, we have the following sentence:
	=20
	    If the distributionPoint field is absent, the CRL MUST
contain
	    entries for all revoked unexpired certificates *issued* by
the CRL
	    issuer, if any, within the scope of the CRL
	=20
	This sentence is either ambiguous or incorrect: a CRL issuer
does not
	*issue* certificates. On page 7, the definition of a CRL issuer
is:
	CRL issuer: an optional system to which a CA delegates the
publication of
	   =20

	certificate revocation lists.
	   =20

=20
I agree that the definition is not consistent with the standard text in
general. Other sections definitely suggest that the CA can be the CRL
issuer also without delegation.
=20
>From 4.2.1.14  CRL Distribution Points:
=20
   If the certificate issuer is not the CRL
   issuer, then the cRLIssuer field MUST be present and contain the Name
   of the CRL issuer.  If the certificate issuer is also the CRL issuer,
   then the cRLIssuer field MUST be omitted and the distributionPoint
   field MUST be present.
 =20

------_=_NextPart_001_01C49FB7.CCDEAD21
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)">
<title>ITU-T Rec. X.509 (03/2000) Information technology &#8211; Open =
system</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0cm;
	margin-bottom:5.75pt;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
tt
	{font-family:"Courier New";}
span.EmailStyle20
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

<body bgcolor=3Dwhite lang=3DDA link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Thanks for the =
summary.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Some corrections =
in line:</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></p>

<div>

<p><b><font size=3D2 color=3Dolive face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive;font-weight:bold'>Stefan =
Santesson</span></font></b><span
lang=3DEN-GB> <br>
</span><font size=3D2 color=3Dolive face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive'>Microsoft Security Center of =
Excellence (SCOE)</span></font><span lang=3DEN-GB> <br>
</span><font face=3DArial><span lang=3DEN-GB =
style=3D'font-family:Arial'>&nbsp;</span></font><span
lang=3DEN-GB> </span></p>

</div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;
color:windowtext'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Tahoma;color:windowtext'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>David A. Cooper<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 20 september =
2004 21:41<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: CA Rekey and =
CRL
Validation</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>All,<br>
<br>
I have been on vacation for the past couple of weeks and have just =
finished
reading through the messages in this thread.&nbsp; So, I would now like =
to
comment on some of the issues that have been raised.<br>
<br>
First, as David Kemp noted, the text on page 7 is not a definition of =
CRL
issuer, it is simply describing one of the components depicted in figure
1.&nbsp; Paragraph 3 of section 5 (on page 48) clearly states:<br>
<br>
</span></font><tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;
CRL issuers issue CRLs.&nbsp; <u>In general, the CRL issuer is the =
CA.</u>&nbsp;
CAs</span></font></tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">&nbsp;&nbsp; publish CRLs to provide =
status
information about the certificates</font></tt><br>
<tt><font face=3D"Courier New">&nbsp;&nbsp; they issued.&nbsp; However, =
a CA may
delegate this responsibility to</font></tt><br>
<tt><font face=3D"Courier New">&nbsp;&nbsp; another trusted =
authority.&nbsp;
Whenever the CRL issuer is not the CA</font></tt><br>
<tt><font face=3D"Courier New">&nbsp;&nbsp; that issued the =
certificates, the CRL
is referred to as an indirect</font></tt><br>
<tt><font face=3D"Courier New">&nbsp;&nbsp; =
CRL.</font></tt></span></font><br>
<br>
As to the main question on this thread, I believe that X.509 is very =
clear that
a CA is identified by name, not name+key.&nbsp; Here are a few quotes =
from
X.509:</p>

<p style=3D'margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>1.<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp; </span></font></span></font>
<meta name=3DAUTHOR content=3DSB>
<meta name=3DCREATED content=3D"20030703;10040000">
<meta name=3DCHANGEDBY content=3DSB>
<meta name=3DCHANGED content=3D"20030710;10030000">
<meta name=3DCLASSIFICATION
content=3D"SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS -">
<meta name=3DDESCRIPTION
content=3D"Saisie  KJ&#13;&#10;Corr. BAT  17.4.01/KJ&#13;&#10;Corr. 2e =
BAT  4.5.01/KJ&#13;&#10;Ultimes   7.5.01/KJ&#13;&#10;Ultime mail Mme =
Zenobi (7.5)&#13;&#10;Corr. apr&egrave;s ultimes  22.5.01/KJ">
<meta name=3DKEYWORDS content=3D"X.509,X,509">
Section 7: &quot;NOTE 1 &#8211; Although the <u>CAs are unambiguously =
defined
by a distinguished name</u> in the DIT, this does not imply that there =
is any
relationship between the&nbsp; organization of the CAs and the =
DIT.&quot;<font
color=3D"#3333ff"><span style=3D'color:#3333FF'> [DC: If same DN but =
different keys
meant different CAs, then CAs would not be unambiguously defined by a =
DN.]</span></font></p>

<p style=3D'margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>2.<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp; </span></font></span></font>Section
7: &quot;<b><font face=3DArial><span =
style=3D'font-family:Arial;font-weight:bold'>issuer</span></font></b>
identifies the entity that has signed and issued the certificate.&quot; =
<font
color=3D"#3333ff"><span style=3D'color:#3333FF'>[DC: note that this says =
that the </span></font><b><font
color=3D"#3333ff" face=3DArial><span =
style=3D'font-family:Arial;color:#3333FF;
font-weight:bold'>issuer</span></font></b><font color=3D"#3333ff"><span
style=3D'color:#3333FF'> field of the certificate identifies the entity, =
not
issuer field in combination with key]</span></font></p>

<p style=3D'margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>3.<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp; </span></font></span></font>Section
7: &quot;Self-issued certificate &#8211; <u>This is a certificate where =
the issuer
and the subject are the same CA</u>. A CA might use self-issued =
certificates,
for example, during a key rollover operation to provide trust from the =
old key
to the new key.&quot; <font color=3D"#3333ff"><span =
style=3D'color:#3333FF'>[DC:&nbsp;
If CA were defined as name+key, then one would not say that a key =
rollover
certificate had the same CA as both issuer and =
subject.]</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>One is also required to ensure that two =
different
entities are not assigned the same name:</span></font></p>

<ol start=3D1 type=3D1>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>Section 8.3.2.1 (subject alternative =
name
     extension): &quot;For every name form used in the =
</span></font><b><font
     face=3DArial><span =
style=3D'font-family:Arial;font-weight:bold'>GeneralName</span></font></b=
     type, there shall be a name registration system that ensures that =
any name
     used unambiguously identifies one entity to both certificate issuer =
and
     certificate users.&quot;</li>
</ol>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><br>
I realize that some will still argue that X.509 does not explicitly =
state that
same name =3D same CA even if it does imply that it is the case.&nbsp; =
However,
if you are going to suggest that X.509 should be interpreted based on =
the
assumption that different keys means different CAs, the question I would =
ask is
where in X.509 (or RFC 3280) is there anything that implies this is the =
case?<br>
<br>
</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Stefan] I don&#8217;t think anyone is suggesting =
this
interpretation of X.509. The issue was raised and resolved. There only =
remains
a suggestion that this should be more directly stated in the standards =
(not
only indirectly understood from the quotes =
above).</span></font></i></b></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-GB style=3D'font-size:12.0pt'><br>
Some have argued that X.509 has a security vulnerability unless the =
assumption
is made that different keys means different CAs.&nbsp; </span>However, =
these
arguments always start with the assumption that one is operating in a =
PKI in
which there are multiple, independent CAs, all of which are considered =
to be
valid CAs in the infrastructure and all of which have the same =
name.&nbsp;
However, in a valid PKI, two different CAs will not have the same =
name.&nbsp;
So, these people are simply noting that if one operates a PKI in a =
manner that
is contrary to the rules of X.509 (allowing two different CAs to share =
the same
name), the PKI will not provide the security assurances promised by
X.509.&nbsp; But, I don't see how one can argue that this indicates a =
flaw in
X.509.<br>
<br>
</font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Stefan] This is not correct. The argument was based =
on the
wrong assumption that it was allowed to issue a CRL covering =
certificates
issued under just 1 CA key, without having IDP present in the CRL. It =
was
clarified however that this is not supported =
practice.</span></font></i></b></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-GB style=3D'font-size:12.0pt'><br>
Santosh has proposed a restricted path validation algorithm for =
validating CRL
signing keys (ensuring that the certification path for the CRL signing =
keys is
similar to the certification path for the certificate being validated) =
that
mitigates that damage that would result from a PKI in which two CAs =
share the
same name (i.e., it provides an extra layer of protection). </span>His =
proposal
mitigates the problem as well as if one required certificates and CRLs =
to be
signed with the same key.&nbsp; The main reason I agree with Santosh's
proposal, however, is that I don't see any good reason not to impose the
restriction he proposes, while imposing the restriction makes path =
validation
more efficient since there are fewer possibilities that need to be =
considered.<br>
<br>
</font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Stefan] I&#8217;m OK with this restrictions which =
also
solves other security issues discussed in ITU (Circular =
trust)</span></font></i></b></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-GB style=3D'font-size:12.0pt'><br>
<br>
</span>Dave<br>
<br>
Stefan Santesson wrote:<br>
<br>
</font></p>

<pre wrap=3D""><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Denis,</span></font></pre><pre><font size=3D2
color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp; </span></font></pre>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><pre wrap=3D""><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>On page 59, we have the following =
sentence:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; If the distributionPoint =
field is absent, the CRL MUST contain</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; entries for all revoked =
unexpired certificates *issued* by the CRL</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; issuer, if any, within the =
scope of the CRL</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>This sentence is either ambiguous or =
incorrect: a CRL issuer does not</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>*issue* certificates. On page 7, the =
definition of a CRL issuer is:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>CRL issuer: an optional system to which a CA =
delegates the publication of</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; =
</span></font></pre></blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><pre wrap=3D""><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>certificate revocation =
lists.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; =
</span></font></pre></blockquote>

<pre wrap=3D""><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font size=3D2
color=3Dblack face=3D"Courier New"><span style=3D'font-size:10.0pt'>I =
agree that the definition is not consistent with the standard text =
in</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>general. Other sections definitely suggest =
that the CA can be the CRL</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>issuer also without =
delegation.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>From 4.2.1.14&nbsp; CRL Distribution =
Points:</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; If the certificate issuer is not =
the CRL</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; issuer, then the cRLIssuer field =
MUST be present and contain the Name</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; of the CRL issuer.&nbsp; If the =
certificate issuer is also the CRL issuer,</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; then the cRLIssuer field MUST be =
omitted and the distributionPoint</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; field MUST be =
present.</span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp; </span></font></pre></div>

</div>

</body>

</html>

------_=_NextPart_001_01C49FB7.CCDEAD21--

From: "Admin" <[email-masked]>
To: [email-masked]
Subject: ADV:      Announcement To All Staff
Date: Mon, 20 Sep 04 19:47:00 GMT

This is a multi-part message in MIME format.

--8F.DD5DD96BEEF
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Nonprofit Organizations: Members, Staff and Associates: 

You Must Respond By 5 P.M. Wednesday, September 22, 2004.

Through a special arrangement, Avtech Direct is offering a limited
allotment of BRAND NEW, top of-the-line, name-brand desktop computers
at more than 50% off MSRP to all Nonprofit Members and Staff, 
who respond to this message before 5 P.M., Wednesday, September 22, 2004.

All desktop 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 2004
next generation technology, making these the best performing
computers money can buy.

Avtech Direct is offering these feature rich, top performing
Desktop Computers with the latest Intel technology at an amazing price
to all who call:

    1-800-884-9510 by 5 P.M. Wednesday, September 22, 2004
    
The fast and powerful AT-2400 series Desktop features: 

      * Intel 2.0Ghz 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 
      * 1.44 Floppy disk drive
      * Next Generation Technology
      * ATI Premium video and sound
      * 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 $699 ........................................ Your Cost $297

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-884-9510 by 5 P.M. Wednesday, September 22, 2004
     and we will hold the desktops you request on will call. 
  4. You are not obligated in any way.
  5. 100% Satisfaction Guaranteed.

Call Avtech Direct 1-800-884-9510 before 5 P.M. Wednesday, September 22, 2=
004

Visit our website at http://www.avtechdirectcomputers.com

If you wish to unsubscribe from this list, please go to:
http://www.computeradvice.org/unsubscribe.asp

Avtech Direct
22647 Ventura Blvd., Suite 374
Woodland Hills, CA 91364
--8F.DD5DD96BEEF--

Date: Mon, 20 Sep 2004 15:41:01 -0400
From: "David A. Cooper" <[email-masked]>
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
All,<br>
<br>
I have been on vacation for the past couple of weeks and have just
finished reading through the messages in this thread.&nbsp; So, I would now
like to comment on some of the issues that have been raised.<br>
<br>
First, as David Kemp noted, the text on page 7 is not a definition of
CRL issuer, it is simply describing one of the components depicted in
figure 1.&nbsp; Paragraph 3 of section 5 (on page 48) clearly states:<br>
<br>
<tt>&nbsp;&nbsp; CRL issuers issue CRLs.&nbsp; <u>In general, the CRL issuer is the
CA.</u>&nbsp; CAs<br>
&nbsp;&nbsp; publish CRLs to provide status information about the certificates<br>
&nbsp;&nbsp; they issued.&nbsp; However, a CA may delegate this responsibility to<br>
&nbsp;&nbsp; another trusted authority.&nbsp; Whenever the CRL issuer is not the CA<br>
&nbsp;&nbsp; that issued the certificates, the CRL is referred to as an indirect<br>
&nbsp;&nbsp; CRL.</tt><br>
<br>
As to the main question on this thread, I believe that X.509 is very
clear that a CA is identified by name, not name+key.&nbsp; Here are a few
quotes from X.509:<br>
<ol>
  <li>
    <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
    <title>ITU-T Rec. X.509 (03/2000) Information technology &#8211; Open
system</title>
    <meta name="GENERATOR" content="OpenOffice.org 1.1.2  (Linux)">
    <meta name="AUTHOR" content="SB">
    <meta name="CREATED" content="20030703;10040000">
    <meta name="CHANGEDBY" content="SB">
    <meta name="CHANGED" content="20030710;10030000">
    <meta name="CLASSIFICATION"
 content="SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS -">
    <meta name="DESCRIPTION"
 content="Saisie  KJ
Corr. BAT  17.4.01/KJ
Corr. 2e BAT  4.5.01/KJ
Ultimes   7.5.01/KJ
Ultime mail Mme Zenobi (7.5)
Corr. apr&egrave;s ultimes  22.5.01/KJ">
    <meta name="KEYWORDS" content="X.509,X,509">
    <style>
	<!--
		@page { size: 8.27in 11.69in; margin: 0.79in }
		P { margin-bottom: 0.08in }
	-->
	</style>
    <p>Section 7: "NOTE 1 &#8211; Although the <u>CAs are unambiguously
defined by a distinguished name</u> in the DIT, this does not imply
that there is any relationship between the&nbsp; organization of the CAs and
the DIT."<font color="#3333ff"> [DC: If same DN but different keys
meant different CAs, then CAs would not be unambiguously defined by a
DN.]</font><br>
    </p>
  </li>
  <li>
    <p>Section 7: "<font face="Arial"><b>issuer</b></font> identifies
the entity that has signed and issued the certificate." <font
 color="#3333ff">[DC: note that this says that the <b><font
 face="Arial">issuer</font></b> field of the certificate identifies the
entity, not issuer field in combination with key]</font></p>
  </li>
  <li>
    <p>Section 7: "Self-issued certificate &#8211; <u>This is a certificate
where the issuer and the subject are the same CA</u>. A CA might use
self-issued certificates, for example, during a key rollover operation
to provide trust from the old key to the new key." <font
 color="#3333ff">[DC:&nbsp; If CA were defined as name+key, then one would
not say that a key rollover certificate had the same CA as both issuer
and subject.]<br>
    </font></p>
  </li>
</ol>
One is also required to ensure that two different entities are not
assigned the same name:<br>
<ol>
  <li>Section 8.3.2.1 (subject alternative name extension): "For every
name form used in the <b><font face="Arial">GeneralName</font></b>
type, there shall be a name registration system that ensures that any
name used unambiguously identifies one entity to both certificate
issuer and certificate users."<br>
  </li>
</ol>
<br>
I realize that some will still argue that X.509 does not explicitly
state that same name = same CA even if it does imply that it is the
case.&nbsp; However, if you are going to suggest that X.509 should be
interpreted based on the assumption that different keys means different
CAs, the question I would ask is where in X.509 (or RFC 3280) is there
anything that implies this is the case?<br>
<br>
Some have argued that X.509 has a security vulnerability unless the
assumption is made that different keys means different CAs.&nbsp; However,
these arguments always start with the assumption that one is operating
in a PKI in which there are multiple, independent CAs, all of which are
considered to be valid CAs in the infrastructure and all of which have
the same name.&nbsp; However, in a valid PKI, two different CAs will not
have the same name.&nbsp; So, these people are simply noting that if one
operates a PKI in a manner that is contrary to the rules of X.509
(allowing two different CAs to share the same name), the PKI will not
provide the security assurances promised by X.509.&nbsp; But, I don't see
how one can argue that this indicates a flaw in X.509.<br>
<br>
Santosh has proposed a restricted path validation algorithm for
validating CRL signing keys (ensuring that the certification path for
the CRL signing keys is similar to the certification path for the
certificate being validated) that mitigates that damage that would
result from a PKI in which two CAs share the same name (i.e., it
provides an extra layer of protection). His proposal mitigates the
problem as well as if one required certificates and CRLs to be signed
with the same key.&nbsp; The main reason I agree with Santosh's proposal,
however, is that I don't see any good reason not to impose the
restriction he proposes, while imposing the restriction makes path
validation more efficient since there are fewer possibilities that need
to be considered.<br>
<br>
<br>
Dave<br>
<br>
Stefan Santesson wrote:<br>
<blockquote type="cite"
 cite="[email-masked]">
  <pre wrap="">Denis,
  </pre>
  <blockquote type="cite">
    <pre wrap="">On page 59, we have the following sentence:

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

This sentence is either ambiguous or incorrect: a CRL issuer does not
*issue* certificates. On page 7, the definition of a CRL issuer is:
CRL issuer: an optional system to which a CA delegates the publication of
    </pre>
  </blockquote>
  <blockquote type="cite">
    <pre wrap="">certificate revocation lists.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I agree that the definition is not consistent with the standard text in
general. Other sections definitely suggest that the CA can be the CRL
issuer also without delegation.

>From 4.2.1.14  CRL Distribution Points:

   If the certificate issuer is not the CRL
   issuer, then the cRLIssuer field MUST be present and contain the Name
   of the CRL issuer.  If the certificate issuer is also the CRL issuer,
   then the cRLIssuer field MUST be omitted and the distributionPoint
   field MUST be present.
  </pre>
</blockquote>
</body>
</html>

From: "Faisal Maqsood" <[email-masked]>
To: <[email-masked]>
Cc: "Trevor Freeman" <[email-masked]>
Subject: SCVP: CVResponse Tags Confliction
Date: Mon, 20 Sep 2004 16:00:33 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00A7_01C49F2A.F5C99C50
Content-Type: text/plain;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

H=00i=00,=00=0D=00=0A=
=00=0D=00=0A=
=00P=00l=00e=00a=00s=00e=00 =00s=00e=00e=00 =00t=00h=00e=00 =
=00'=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00'=00 =
=00A=00S=00N=00.=001=00 =00s=00t=00r=00u=00c=00t=00u=00r=00e=00,=00 =
=00h=00e=00r=00e=00 =00i=00s=00 =
=00'=00R=00e=00q=00u=00e=00s=00t=00R=00e=00f=00e=00r=00e=00n=00c=00e=00'=00=
 =00e=00l=00e=00m=00e=00n=00t=00 =00w=00h=00i=00c=00h=00 =00i=00s=00 =
=00n=00o=00t=00 =00O=00P=00T=00I=00O=00N=00A=00L=00 =00b=00u=00t=00 =
=00i=00s=00 =00C=00H=00O=00I=00C=00E=00 =00f=00r=00o=00m=00 =
=00t=00a=00g=00 =001=00 =00a=00n=00d=00 =00t=00a=00g=00 =002=00.=00 =
=00F=00u=00r=00t=00h=00e=00r=00 =00i=00n=00 =
=00'=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00'=00 =
=00t=00h=00e=00r=00e=00 =00a=00r=00e=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00 =00e=00l=00e=00m=00e=00n=00t=00s=00 =
=00w=00i=00t=00h=00 =00t=00a=00g=00s=00 =001=00 =00t=00o=00 =
=00t=00a=00g=00 =008=00.=00=0D=00=0A=
=00O=00n=00c=00e=00 =00y=00o=00u=00 =00g=00e=00n=00e=00r=00a=00t=00e=00 =
=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00i=00n=00c=00l=00u=00d=00i=00n=00g=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00 =00e=00l=00e=00m=00e=00n=00t=00s=00 =
=00o=00f=00 =00t=00a=00g=00s=00 =001=00 =00a=00n=00d=00 =002=00,=00 =
=00a=00n=00d=00 =00a=00n=00a=00l=00y=00z=00e=00 =00A=00S=00N=00.=001=00 =
=00i=00n=00 =00s=00o=00m=00e=00 =00A=00S=00N=00.=001=00 =
=00V=00e=00i=00w=00e=00r=00,=00 =00y=00o=00u=00 =00w=00i=00l=00l=00 =
=00f=00e=00e=00l=00 =00s=00o=00m=00e=00 =
=00c=00o=00n=00f=00l=00i=00c=00t=00i=00o=00n=00/=00c=00o=00n=00f=00u=00s=00=
i=00o=00n=00/=00m=00i=00s=00u=00n=00d=00e=00r=00s=00t=00a=00n=00d=00i=00n=
=00g=00 =00w=00h=00a=00t=00s=00o=00e=00v=00e=00r=00,=00 =00s=00o=00 =
=00I=00 =00r=00e=00q=00u=00e=00s=00t=00 =00t=00o=00 =
=00c=00h=00a=00n=00g=00e=00 =00t=00a=00g=00 =
=00n=00u=00m=00b=00e=00r=00s=00 =00o=00f=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00 =00e=00l=00e=00m=00e=00n=00t=00s=00 =
=00i=00n=00 =00C=00V=00R=00e=00q=00u=00e=00s=00t=00 =00a=00n=00d=00 =
=00s=00t=00a=00r=00t=00 =00t=00a=00g=00 =00n=00u=00m=00b=00e=00r=00 =
=00f=00r=00o=00m=00 =003=00 =00t=00o=00 =001=000=00 =
=00i=00n=00s=00t=00e=00a=00d=00 =001=00 =00t=00o=00 =008=00.=00=0D=00=0A=
=00=0D=00=0A=
=00I=00f=00 =00s=00o=00m=00e=00o=00n=00e=00 =00h=00a=00s=00 =
=00o=00b=00j=00e=00c=00t=00i=00o=00n=00 =00p=00l=00e=00a=00s=00e=00 =
=00a=00s=00k=00.=00=0D=00=0A=
=00=0D=00=0A=
=00R=00e=00g=00a=00r=00d=00s=00,=00=0D=00=0A=
=00F=00a=00i=00s=00a=00l=00=0D=00=0A=
=00
------=_NextPart_000_00A7_01C49F2A.F5C99C50
Content-Type: text/html;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

=FF=FE<=00!=00D=00O=00C=00T=00Y=00P=00E=00 =00H=00T=00M=00L=00 =
=00P=00U=00B=00L=00I=00C=00 =
=00"=00-=00/=00/=00W=003=00C=00/=00/=00D=00T=00D=00 =00H=00T=00M=00L=00 =
=004=00.=000=00 =
=00T=00r=00a=00n=00s=00i=00t=00i=00o=00n=00a=00l=00/=00/=00E=00N=00"=00>=00=
=0D=00=0A=
=00<=00H=00T=00M=00L=00 =00x=00m=00l=00n=00s=00:=00s=00t=001=00 =
=00=3D=00 =
=00"=00u=00r=00n=00:=00s=00c=00h=00e=00m=00a=00s=00-=00m=00i=00c=00r=00o=00=
s=00o=00f=00t=00-=00c=00o=00m=00:=00o=00f=00f=00i=00c=00e=00:=00s=00m=00a=
=00r=00t=00t=00a=00g=00s=00"=00 =00x=00m=00l=00n=00s=00:=00o=00 =
=00=3D=00 =00=0D=00=0A=
=00"=00u=00r=00n=00:=00s=00c=00h=00e=00m=00a=00s=00-=00m=00i=00c=00r=00o=00=
s=00o=00f=00t=00-=00c=00o=00m=00:=00o=00f=00f=00i=00c=00e=00:=00o=00f=00f=
=00i=00c=00e=00"=00>=00<=00H=00E=00A=00D=00>=00<=00B=00A=00S=00E=00 =
=00=0D=00=0A=
=00h=00r=00e=00f=00=3D=00"=00f=00i=00l=00e=00:=00/=00/=00F=00:=00\=00_=00=
B=00a=00c=00k=00U=00p=00-=00F=00M=00\=00E=00m=00a=00i=00l=00 =
=00S=00i=00g=00n=00a=00t=00u=00r=00e=00\=00"=00>=00=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00h=00t=00t=00p=00-=00e=00q=00u=00i=00v=00=3D=00C=00o=00n=00t=00e=00n=00=
t=00-=00T=00y=00p=00e=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00t=00e=00x=00t=00/=00h=00t=00m=00=
l=00;=00 =
=00c=00h=00a=00r=00s=00e=00t=00=3D=00u=00n=00i=00c=00o=00d=00e=00"=00>=00=
=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00M=00L=00 =
=005=00.=005=000=00.=004=001=003=004=00.=006=000=000=00"=00 =
=00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00<=00/=00=
H=00E=00A=00D=00>=00=0D=00=0A=
=00<=00B=00O=00D=00Y=00 =
=00b=00g=00C=00o=00l=00o=00r=00=3D=00#=00f=00f=00f=00f=00f=00f=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00H=00i=00,=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00P=00l=00e=00a=00s=00e=00 =00s=00e=00e=00 =
=00t=00h=00e=00 =00'=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00'=00 =
=00A=00S=00N=00.=001=00 =00s=00t=00r=00u=00c=00t=00u=00r=00e=00,=00 =
=00h=00e=00r=00e=00 =00i=00s=00 =
=00'=00R=00e=00q=00u=00e=00s=00t=00R=00e=00f=00e=00r=00e=00n=00c=00e=00'=00=
 =00=0D=00=0A=
=00e=00l=00e=00m=00e=00n=00t=00 =00w=00h=00i=00c=00h=00 =00i=00s=00 =
=00n=00o=00t=00 =00O=00P=00T=00I=00O=00N=00A=00L=00 =00b=00u=00t=00 =
=00i=00s=00 =00C=00H=00O=00I=00C=00E=00 =00f=00r=00o=00m=00 =
=00t=00a=00g=00 =001=00 =00a=00n=00d=00 =00t=00a=00g=00 =002=00.=00 =
=00F=00u=00r=00t=00h=00e=00r=00 =00i=00n=00 =00=0D=00=0A=
=00'=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00'=00 =
=00t=00h=00e=00r=00e=00 =00a=00r=00e=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00 =00e=00l=00e=00m=00e=00n=00t=00s=00 =
=00w=00i=00t=00h=00 =00t=00a=00g=00s=00 =001=00 =00t=00o=00 =
=00t=00a=00g=00 =008=00.=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00O=00n=00c=00e=00 =00y=00o=00u=00 =
=00g=00e=00n=00e=00r=00a=00t=00e=00 =
=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00i=00n=00c=00l=00u=00d=00i=00n=00g=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00 =00e=00l=00e=00m=00e=00n=00t=00s=00 =
=00o=00f=00 =00t=00a=00g=00s=00 =001=00 =00a=00n=00d=00 =00=0D=00=0A=
=002=00,=00&=00n=00b=00s=00p=00;=00a=00n=00d=00 =
=00a=00n=00a=00l=00y=00z=00e=00 =00A=00S=00N=00.=001=00 =00i=00n=00 =
=00s=00o=00m=00e=00 =00A=00S=00N=00.=001=00 =
=00V=00e=00i=00w=00e=00r=00,=00 =00y=00o=00u=00 =00w=00i=00l=00l=00 =
=00f=00e=00e=00l=00 =00s=00o=00m=00e=00 =00=0D=00=0A=
=00c=00o=00n=00f=00l=00i=00c=00t=00i=00o=00n=00/=00c=00o=00n=00f=00u=00s=00=
i=00o=00n=00/=00m=00i=00s=00u=00n=00d=00e=00r=00s=00t=00a=00n=00d=00i=00n=
=00g=00 =00w=00h=00a=00t=00s=00o=00e=00v=00e=00r=00,=00 =00s=00o=00 =
=00I=00 =00r=00e=00q=00u=00e=00s=00t=00 =00t=00o=00 =
=00c=00h=00a=00n=00g=00e=00 =00t=00a=00g=00 =00=0D=00=0A=
=00n=00u=00m=00b=00e=00r=00s=00 =00o=00f=00 =
=00O=00P=00T=00I=00O=00N=00A=00L=00 =00e=00l=00e=00m=00e=00n=00t=00s=00 =
=00i=00n=00 =00C=00V=00R=00e=00q=00u=00e=00s=00t=00 =00a=00n=00d=00 =
=00s=00t=00a=00r=00t=00 =00t=00a=00g=00 =00n=00u=00m=00b=00e=00r=00 =
=00f=00r=00o=00m=00 =003=00 =00t=00o=00 =001=000=00 =00=0D=00=0A=
=00i=00n=00s=00t=00e=00a=00d=00 =001=00 =00t=00o=00 =
=008=00.=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00I=00f=00 =00s=00o=00m=00e=00o=00n=00e=00 =
=00h=00a=00s=00 =00o=00b=00j=00e=00c=00t=00i=00o=00n=00 =
=00p=00l=00e=00a=00s=00e=00 =
=00a=00s=00k=00.=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00R=00e=00g=00a=00r=00d=00s=00,=00<=00/=00D=00I=00V=00=
>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00F=00a=00i=00s=00a=00l=00<=00/=00D=00I=00V=00>=00<=00=
/=00B=00O=00D=00Y=00>=00<=00/=00H=00T=00M=00L=00>=00=0D=00=0A=
=00
------=_NextPart_000_00A7_01C49F2A.F5C99C50--

Date: Sun, 19 Sep 2004 18:39:38 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Cc: [email-masked]
Sender: [email-masked]

At 10:23 PM +1200 9/17/04, Peter Gutmann wrote:
>Stephen Kent <[email-masked]> writes:
>
>>As I noted earlier in my messages, I think it would be appropriate to include
>>these extensions in path validation. In fact, I raised this issue over a year
>>ago in discussions with Sharon and Sanrtosh. But, X.509 does not 
>>allow this at
>>this time.
>
>If there's consensus that this is a good idea, why not just change it?  PKIX
>is bigger than X.509 (does anyone still work from X.509 rather than going
>straight to the PKIX sources)?  I know that PKIX was originally started to
>profile X.509 for Internet use, but it's been running (or at least shuffling)
>as a full parallel standards group for years since then.  PKIX is the dog,
>X.509 is its vestigial tail, why not wag it?
>
>(I'm not trying to pick a fight with the X.509 folks, it's just a pain having
>  two (more if you include ETSI and other groups) parallel standards bodies all
>  busy cutting&pasting each other's work as they play Chinese Whispers with the
>  spec, with sundry propagation delays, inconsistencies, and errors introduced
>  along the way).

Peter,

We have discussed the issue with Sharon, a while ago, and she is 
working to get the change into X.509.  We can then update 3280 and 
maintain sync.  PKIX has rarely diverged from X.509 in a way that 
caused compatibility problems, although it has happened on a coupe of 
occasions.  It was always painful and confusing to the larger 
community, so we try to avoid this problem.

Steve

Date: Sun, 19 Sep 2004 17:22:47 -0400
To: "Laudon Williams" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Cc: <[email-masked]>
Sender: [email-masked]

At 3:40 PM -0700 9/14/04, Laudon Williams wrote:
>So just to finalize this (feel free to rebut Steve)...
>
>When faced with CA expiration, you have two choices. You can either;
>- Rollover the key (same name, new key), or;
>- Rollover the CA (new name, new key).

the second case is not "rollover" because the CA name changed and, 
according to X.509 and PKIX, the new name represents a new CA. the 
term "key rollover" is used to refer to a key change where the name 
of the subject stays constant, whether the context is an EE or a CA.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: [email-masked]
Subject: Re: Conclusions: CA Rekey and CRL Validation
Date: Sat, 18 Sep 2004 18:18:47 -0400
Sender: [email-masked]

Luciano:

You can verify the CRL2.  The only reason to sign with the old key is to 
accommodate those PK enabled clients who reqire the certificate and CRL to 
be signed using the same key, e.g., MS CAPI.

On Sat, 18 Sep 2004 17:00:52 -0300, Luciano (Pessoal) wrote
> Not considering the "feature" implemented by MS. 
> 
>     We have the chain below for the end entity certificate "EE_X".
>        TA->CA1->CA2->EE_X (where TA is considered a trust anchor).
> 
>     CA2 is rekeyed and a new certificate, CA2', is generated for it with
> the same DN.
> 
>     After the rekey, CA2 issues a CRL "CRL2". The certification path 
> for this CRL is:       TA->CA1->CA2'->CRL2
> 
>     "CRL2" has revocation informations about all certificates issued 
> by "CA2" and " CA2' " certificates.
> 
>     "CRL2" doesn't have IDP extension.
> 
>     My doubts are:
> 
> 1) Following the algorithm
> (http://www.imc.org/ietf-pkix/mail-archive/msg03268.html) proposed by
> Santosh, Can I use the CRL "CRL2" to verify the certificate "EE_X"?  
> If no, why?
> 
> 2) If I can do the verification above, as I suppose, Why need I  
> issue CRLs using the old key (associated with CA2)?
> 
>     Thanks in advance.
> 
>     Luciano Coelho
>    
> Santosh Chokhani wrote:
> 
> >See responses in-line in [].
> >
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] 
On
> >Behalf Of Luciano (Pessoal)
> >Sent: Friday, September 17, 2004 10:59 AM
> >To: [email-masked]
> >Subject: Conclusions: CA Rekey and CRL Validation
> >
> >
> >
> >After all this discursion, it is correct affirm:
> >
> >1) To do a CA-Rekey it is not necessary change the CA's DN.
> >
> >[MS CAPI will require that a CRL be signed using all the keys that
> >certificates were issued with and have not expired]
> >
> >2) The "newer CA" can issue CRLs that contain revocation informations 
about
> >all the certificates issued using the new and the old key.
> >
> >[It is the same CA.  It is not a different CA.  So, the term "newer CA" 
does
> >not make sense]
> >
> >3) It is not necessary mantain the older CA key for issuing CRLs that
> >contain only revocation informations about certificates issued using the 
old
> >key (neither containing revocation info about certificates issued by the
> >"newer CA").
> >

> >[Again, newer CA does not make sense.  If you do this, MS CAPI will not
> >verify the paths for older certificates]
> >
> >4) A certificate issued by the "older CA" can be validated using the CRL
> >issued by the "newer CA", without be considered a security problem.
> >
> >[Again, the terms newer and older are inappropriate]
> >
> >5) For all the aspects of X509 and RFC 3280, the "newer CA" and the "older
> >CA" are considered the SAME CA.
> >
> >
> >Thank you,
> >
> >Luciano Coelho
> >
> >
> >
> >  
> >

Date: Sun, 19 Sep 2004 00:15:35 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: "Luciano (Pessoal)" <[email-masked]>
CC: [email-masked], Santosh Chokhani <[email-masked]>
Subject: Re: Conclusions: CA Rekey and CRL Validation
Sender: [email-masked]

Luciano (Pessoal) wrote:

>    Not considering the "feature" implemented by MS. 
>  
>
[...]

>2) If I can do the verification above, as I suppose, Why need I  issue
>CRLs using the old key (associated with CA2)?
>  
>
The only reason you need to issue CRL usign the old key is if you 
consider the "feature" implemented by MS, as has been described MS CAPI 
will not accept to match by name and not key if an IDP is not present.

But this kind of restriction was also implemented I think by many other 
implementers who were with reason wary of matching only by name because, 
without using the algorithm proposed by Santosh, it is dangerous.

Date: Sat, 18 Sep 2004 17:00:52 -0300
From: "Luciano (Pessoal)" <[email-masked]>
To: [email-masked]
CC: Santosh Chokhani <[email-masked]>
Subject: Re: Conclusions: CA Rekey and CRL Validation
Sender: [email-masked]

    Not considering the "feature" implemented by MS. 

    We have the chain below for the end entity certificate "EE_X".
       TA->CA1->CA2->EE_X (where TA is considered a trust anchor).

    CA2 is rekeyed and a new certificate, CA2', is generated for it with
the same DN.

    After the rekey, CA2 issues a CRL "CRL2". The certification path for
this CRL is:
       TA->CA1->CA2'->CRL2

    "CRL2" has revocation informations about all certificates issued by
"CA2" and " CA2' " certificates.

    "CRL2" doesn't have IDP extension.

    My doubts are:

1) Following the algorithm
(http://www.imc.org/ietf-pkix/mail-archive/msg03268.html) proposed by
Santosh, Can I use the CRL "CRL2" to verify the certificate "EE_X"?  If
no, why?

2) If I can do the verification above, as I suppose, Why need I  issue
CRLs using the old key (associated with CA2)?

    Thanks in advance.

    Luciano Coelho
   
Santosh Chokhani wrote:

>See responses in-line in [].
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Luciano (Pessoal)
>Sent: Friday, September 17, 2004 10:59 AM
>To: [email-masked]
>Subject: Conclusions: CA Rekey and CRL Validation
>
>
>
>After all this discursion, it is correct affirm:
>
>1) To do a CA-Rekey it is not necessary change the CA's DN.
>
>[MS CAPI will require that a CRL be signed using all the keys that
>certificates were issued with and have not expired]
>
>2) The "newer CA" can issue CRLs that contain revocation informations about
>all the certificates issued using the new and the old key.
>
>[It is the same CA.  It is not a different CA.  So, the term "newer CA" does
>not make sense]
>
>3) It is not necessary mantain the older CA key for issuing CRLs that
>contain only revocation informations about certificates issued using the old
>key (neither containing revocation info about certificates issued by the
>"newer CA").
>
>[Again, newer CA does not make sense.  If you do this, MS CAPI will not
>verify the paths for older certificates]
>
>4) A certificate issued by the "older CA" can be validated using the CRL
>issued by the "newer CA", without be considered a security problem.
>
>[Again, the terms newer and older are inappropriate]
>
>5) For all the aspects of X509 and RFC 3280, the "newer CA" and the "older
>CA" are considered the SAME CA.
>
>
>Thank you,
>
>Luciano Coelho
>
>
>
>  
>

From: "Faisal Maqsood" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, <[email-masked]>
Subject: Re: SCVP CertReply Status
Date: Sat, 18 Sep 2004 17:59:49 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0050_01C49DA9.4A712760
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

  ----- Original Message -----=20
  From: Trevor Freeman=20
  To: Faisal Maqsood ; [email-masked]=20
  Sent: Saturday, September 18, 2004 03:47
  Subject: RE: SCVP CertReply Status

  =

  Hi,

  SCVP draft 15, section 4.8 replyObjects, CertReply structure:

    1.. If server chooses replyStatus as MalformedPKC (3), MalformedAC =
(4), UnrecognizedCertPolicy (5) or UnrecognizedExtension (7), how is it =
possible to set ReplyChecks and/or ReplyWantBacks in this case?=20
  [TF] Since there are all errors, then there is no replycheks or =
wantbacks to retutn.

  [FM] Yes this is point, so ReplyWantBacks should be OPTIONAL and =
ReplyCheck 'status' should also be optional or there should be more =
INTEGER define for appropriate status

    2.. If server chooses replyStatus as UnrecognizedValPolicy (6), is =
it possible that server process the whole request? I think this status =
code should belong to CVResponse instead of CertReply=20
  [TF] Fixed in 16.

    3.. If server chooses replyStatus as CertPathNotValidNow (12) and =
reason is that server can not connect to OCSPResponder/LDAPServer and so =
have no revocation information for the time being then what should =
server put in ReplyWantBacks?=20
  [TF] 16 now defines If you get an error connecting to the server, then =
unavailable. If the server returns stale data, offline=20

  [FM] Fine, and ReplyWantBack should be OPTIONAL

  Can someone clarify?

  Regards,

  Faisal

------=_NextPart_000_0050_01C49DA9.4A712760
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:ns0 =3D "urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR><BASE=20
href=3Dfile:///F:\_BackUp-FM\Email%20Signature\>
<STYLE>@font-face {
	font-family: Lucida Sans Unicode;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 0pt 180.0pt 0pt 0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0pt
}
UL {
	MARGIN-BOTTOM: 0pt
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue bgColor=3Dwhite>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</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=[email-masked]=20
  href=3D"mailto:[email-masked]">Trevor Freeman</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Faisal Maqsood</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">[email-masked]</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, September 18, =
2004=20
  03:47</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: SCVP CertReply =
Status</DIV>
  <DIV><BR></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0pt; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0pt; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0pt; BORDER-BOTTOM: medium none">
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: =
12pt">=E4=90=BC=E5=99=89=E6=B0=A0=E6=B9=A1=E3=B5=A7=E6=B9=A5=E7=94=AD=E2=81=
=B3=E6=B1=A3=E7=8D=A1=E3=B5=B3=E7=95=8F=E6=B1=B4=E6=BD=AF=E4=B5=AB=E7=8D=A5=
=E6=85=B3=E6=95=A7=E6=95=88=E6=91=A1=E7=89=A5=E6=84=A0=E6=A5=AC=E6=B9=A7=E2=
=88=BD=E6=95=AC=E7=91=A6=E2=80=A2=E4=A5=84=E3=B5=92=E4=B0=A2=E5=89=94=E3=B8=
=A2=E3=B0=A0=E5=89=88=E7=90=A0=E6=89=A1=E6=B9=A9=E6=95=A4=E3=B5=B8=E2=B4=A2=
</SPAN></FONT><FONT=20
  face=3D"Lucida Sans Unicode"><SPAN=20
  style=3D"FONT-FAMILY: 'Lucida Sans =
Unicode'">=E2=88=B1</SPAN></FONT>=E2=80=BE=E4=98=BC=E4=B9=8F=E2=81=94=E6=85=
=86=E6=95=A3=E2=88=BD<FONT=20
  face=3D"Lucida Sans Unicode"><SPAN=20
  style=3D"FONT-FAMILY: 'Lucida Sans =
Unicode'">=E2=89=94</SPAN></FONT>=E5=8C=A0=E7=A9=A9=E3=B5=A5=E3=88=A2=E3=B8=
=A2=E3=B0=A0=E3=B9=82=E3=B1=86=E4=88=AF=E2=80=BE=E2=81=86=E2=81=9B=E4=88=BC=
=E3=B9=92=E3=B0=A0=E3=B9=82=E3=B1=93=E4=88=AF=E2=80=BE=E3=B1=97=E5=89=82=E2=
=80=BE=E4=88=BC=E5=90=BE=E2=BC=BC=E3=B9=82=E6=A4=A0=E4=88=BC=E3=B9=92=E2=80=
=A0=E4=88=BC=E5=8C=BE=E2=BC=BC=E3=B9=82=E5=8C=A0=E4=88=BC=E3=B9=92=E2=80=A0=
=E3=B0=A0=E4=98=AF=E4=B9=8F=E3=B9=94=E2=BC=BC=E4=A5=84=E3=B9=96=E4=90=BC=E5=
=99=89=E3=B0=BE=E5=89=82=E3=B0=BE=E4=90=AF=E5=99=89</P>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Hi,</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">SCVP draft 15, section 4.8 replyObjects, =
CertReply=20
  structure:</SPAN></FONT></P></DIV>
  <OL type=3D1>
    <LI class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">If server&nbsp;chooses replyStatus as =
MalformedPKC=20
    (3), MalformedAC (4), UnrecognizedCertPolicy (5) or =
UnrecognizedExtension=20
    (7), how is it possible to set ReplyChecks and/or ReplyWantBacks in =
this=20
    case?</SPAN></FONT> </LI></OL>
  <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: =
italic; FONT-FAMILY: Arial">[TF]=20
  Since there are all errors, then there is no replycheks or wantbacks =
to=20
  retutn.</SPAN></FONT></I></B></P>
  <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: =
italic; FONT-FAMILY: Arial">[FM]=20
  Yes this is point, so ReplyWantBacks should be OPTIONAL and ReplyCheck =

  'status' should also be optional or there should be more INTEGER =
define for=20
  appropriate status</SPAN></FONT></I></B></P>
  <OL type=3D1 start=3D2>
    <LI class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">If server&nbsp;chooses replyStatus as=20
    UnrecognizedValPolicy (6), is it possible that server process the =
whole=20
    request? I think this status code should belong to CVResponse =
instead of=20
    CertReply</SPAN></FONT> </LI></OL>
  <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: =
italic; FONT-FAMILY: Arial">[TF]=20
  Fixed in 16.</SPAN></FONT></I></B></P>
  <OL type=3D1 start=3D3>
    <LI class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">If server chooses replyStatus as =
CertPathNotValidNow=20
    (12) and reason is that server can not connect to =
OCSPResponder/LDAPServer=20
    and so have no revocation information for the time being then what =
should=20
    server put in ReplyWantBacks?</SPAN></FONT> </LI></OL>
  <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: =
italic; FONT-FAMILY: Arial">[TF]=20
  16 now defines If you get an error connecting to the server, then =
unavailable.=20
  If the server returns stale data, offline </SPAN></FONT></I></B></P>
  <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: =
italic; FONT-FAMILY: Arial">[FM]=20
  Fine, and ReplyWantBack should be OPTIONAL</SPAN></FONT></I></B></P>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Can someone clarify?</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Regards,</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Faisal</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: =
12pt"></SPAN></FONT>&nbsp;</P></DIV></DIV></DIV></BLOCKQUOTE></BODY></HTM=
L>

------=_NextPart_000_0050_01C49DA9.4A712760--

Content-class: urn:content-classes:message
Subject: RE: SCVP CertReply Status
Date: Fri, 17 Sep 2004 15:47:48 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPartTM-000-72f79a59-b65a-4a85-a74e-98ac62d6a14b
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C49D08.7281DBDE"

------_=_NextPart_001_01C49D08.7281DBDE
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C49D08.7281DBDE
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C49D08.7281DBDE--

------=_NextPartTM-000-72f79a59-b65a-4a85-a74e-98ac62d6a14b--

Content-class: urn:content-classes:message
Subject: RE: SCVP Validation OID
Date: Fri, 17 Sep 2004 15:48:27 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPartTM-000-f79a7b5b-6b4c-4774-b908-05598b5d6e3e
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C49D08.7271206A"

------_=_NextPart_001_01C49D08.7271206A
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi Faisal,

I did find some text left over from 14 where we did talk about using
validation alg to represent parameter but that has been removed from 16.
The only place to define parameters ( TA, policy etc) is the policy. The
algorithm represent how the parameters are evaluated.

=20

If the policy already defines an algorithm then passing the same
algorithm OID is benign and redundant. Passing a different algorithm OID
in the request is an error.

=20

Trevor

________________________________

From: Faisal Maqsood [mailto:[email-masked]]=20
Sent: Tuesday, September 14, 2004 11:25 PM
To: Trevor Freeman; [email-masked]
Subject: Re: SCVP Validation OID

=20

Hi Trevor,

=20

I am slightly confused with the answers given. What I have understood by
the answer of Question 2 is that Server can define customizable OIDs and
associate TrustAnchors, policy oid associated with each TA, revocation
information (CRLs, OCSP Responses) etc but in section 3.2.21 its stated
that "client and server can optionally agree a set of parameters which
may fully or partially define a validation policy". I believe that these
set of parameters are similar to the one defined by validationAlg (See
answer to Question 2 below). If I am correct then I don't think there is
a need for a seperate validationPolRef.

=20

In the answer to question 4, you have stated that "If the referenced
policy also defines an algorithm then the algorithm OID can be omitted
from the request". What do you mean by omitted ? Does this mean to
ignore it by server ?

=20

Can you please tell me what is expected date to publish draft 16 ?

=20

Regards,

Faisal

	----- Original Message -----=20

	From: Trevor Freeman <mailto:[email-masked]> =20

	To: Faisal Maqsood <mailto:[email-masked]>  ;
[email-masked]=20

	Sent: Tuesday, September 14, 2004 22:17

	Subject: RE: SCVP Validation OID

	=20

	=20

	=20

	Hi All,

	=20

	Question 1

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

	I need to know that if fullPolResponse is set to TRUE then what
values are set in valPolResponse and validaionPolRef in SCVP Response.
After reading the draft 15 doc, in my opinion, if fullPolResponse is
TRUE then valPolResponse is set and returned and validaionPolRef is not
set. If fullPolResponse is FALSE then validationPolRef is set and
valPolResponse is not set. Can some one clarify.

	[TF] If a policy has been specified it should always be used.
The only difference should be whether the actual values are include in
addition to the policy. This has been clarified in 16.

	=20

	Question 2

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

	Is validationAlg (defined in 3.2.12) is the same as explained in
section 1.3 ? i.e. The validationAlg in 3.2.12 will be used by server to
define default inputs to the certificate path processing.

	[TF] Yes they are the same.

	=20

	Question 3

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

	How would server behave if in a SCVP Request user has set both
validationAlg and validationPolRef  where validationAlg points to a
default validation algorithm?

	[TF] 3.2.21 states "If there are any conflicts between the
policy referenced in the request and any supplied values in the request
then the server MUST return an error."

	=20

	Question 4

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

	If server defines an OID and bound some configuration with this
OID, e.g. TrustAnchors, RevocationInfo, ValidationParameters etc then
will client either use this OID in ValidationAlg or in validationPolRef
?

	[TF] If the referenced policy also defines an algorithm then the
algorithm OID can be omitted from the request.

	=20

	Regards,

	Faisal

------_=_NextPart_001_01C49D08.7271206A
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:ns0=3D"urn:schemas-microsoft-com:office:smarttags">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<base href=3D"file:///F:\_BackUp-FM\Email%20Signature\">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.emailstyle17
	{font-family:Arial;
	color:navy;}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:0pt 180.0pt 0pt 0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Faisal,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I did find some text left over from =
14
where we did talk about using validation alg to represent parameter but =
that
has been removed from 16. The only place to define parameters ( TA, =
policy etc)
is the policy. The algorithm represent how the parameters are =
evaluated.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>If the policy already defines an =
algorithm
then passing the same algorithm OID is benign and redundant. Passing a =
different
algorithm OID in the request is an error.</span></font></p>

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

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

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt =
0pt 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Faisal Maqsood
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, September =
14, 2004
11:25 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Trevor Freeman; =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: SCVP =
Validation OID</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I am slightly confused with the answers
given.&nbsp;What&nbsp;I have understood by the&nbsp;answer of Question 2 =
is
that Server can define customizable OIDs and associate TrustAnchors, =
policy oid
associated with each TA, revocation information (CRLs, OCSP =
Responses)&nbsp;etc
but in section 3.2.21 its stated that &quot;client and server can =
optionally
agree a set of parameters which may fully or partially define a =
validation
policy&quot;. I believe that these set of parameters are similar to the =
one
defined by </span></font>validationAlg (See answer to Question 2 below).
If&nbsp;I am correct then I don't think there is a need for a seperate
validationPolRef.</p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>In the answer to&nbsp;question 4, you have stated =
that&nbsp;</span></font><font
size=3D2 color=3Dred face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:red'>&quot;If the referenced policy also defines an algorithm then =
the
algorithm OID can be omitted from the request&quot;. </span></font><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:black'>What do you mean by omitted ? Does this mean to ignore it =
by
server&nbsp;?</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Can you please tell me what is expected
date&nbsp;to&nbsp;publish draft 16 ?</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

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

</div>

<div>

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

</div>

<blockquote style=3D'border:none;border-left:solid black =
1.5pt;padding:0pt 0pt 0pt 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0pt;margin-bottom:5.0pt'=

<div>

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

</div>

<div style=3D'font-color:black'>

<p class=3DMsoNormal style=3D'background:#E4E4E4'><b><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;font-weight:bold'>From:</span=
></font></b><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> <a
href=3D"mailto:[email-masked]"
title=3D"[email-masked]">Trevor Freeman</a> =
</span></font></p>

</div>

<div>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>To:</span></font></b><font size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'> <a
href=3D"mailto:[email-masked]" =
title=3D"[email-masked]">Faisal
Maqsood</a> ; <a href=3D"mailto:[email-masked]" =
title=3D"[email-masked]">[email-masked]</a>
</span></font></p>

</div>

<div>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Sent:</span></font></b><font =
size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'> =
Tuesday, September
14, 2004 22:17</span></font></p>

</div>

<div>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Subject:</span></font></b><font =
size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'> RE: =
SCVP
Validation OID</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt =
0pt 4.0pt'>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Hi All,</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Question 1</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>--------------</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>I need to know that if fullPolResponse is set to&nbsp;TRUE then =
what
values are set in valPolResponse and validaionPolRef in SCVP Response. =
After
reading the draft 15 doc, in my opinion, if fullPolResponse is TRUE then
valPolResponse is set and returned and validaionPolRef is not set. If
fullPolResponse is FALSE then validationPolRef is set and valPolResponse =
is not
set. Can some one clarify.</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[TF] If a policy has been specified it should always =
be
used. The only difference should be whether the actual values are =
include in
addition to the policy. This has been clarified in =
16.</span></font></i></b></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Question 2</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>------------</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Is validationAlg (defined in&nbsp;3.2.12) is the same as =
explained in
section 1.3 ? i.e. The validationAlg&nbsp;in 3.2.12 will be used by =
server to
define default inputs to the certificate path =
processing.</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[TF] Yes they are the same.</span></font></i></b></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Question 3</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>-------------</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>How would server behave if in a SCVP Request user has set both
validationAlg and validationPolRef&nbsp; where validationAlg points to a
default validation algorithm?</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[TF] 3.2.21 states &#8220;If there are any conflicts =
between
the policy referenced in the request and any supplied values in the =
request
then the server MUST return an error.&#8221;</span></font></i></b></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Question 4</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>-------------</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>If server defines an OID and bound some configuration with this =
OID,
e.g. TrustAnchors, RevocationInfo, ValidationParameters etc then will =
client
either use this OID in ValidationAlg or in validationPolRef =
?</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[TF] If the referenced policy also defines an =
algorithm then
the algorithm OID can be omitted from the =
request.</span></font></i></b></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Regards,</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Faisal</span></font></p>

</div>

</div>

</blockquote>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C49D08.7271206A--

------=_NextPartTM-000-f79a7b5b-6b4c-4774-b908-05598b5d6e3e--

Content-class: urn:content-classes:message
Subject: RE: SCVP No error code found
Date: Fri, 17 Sep 2004 15:48:27 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPartTM-000-38986c69-03cc-4873-a897-950380b32137
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C49D08.727AB01A"

------_=_NextPart_001_01C49D08.727AB01A
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C49D08.727AB01A
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C49D08.727AB01A--

------=_NextPartTM-000-38986c69-03cc-4873-a897-950380b32137--

Date: Fri, 17 Sep 2004 15:05:10 -0700
From: Ed Gerck <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

David,

You are correct, but there are two hats and that's why the text
should be modified to:

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

Using the CRL issuer hat, there is no issued cert.

Cheers,
Ed Gerck

David P. Kemp wrote:

> 
> Not only do other sections suggest that the CA can be a CRL issuer, the
> text regarding "CRL issuer" on page 6 is *not* a definition of that 
> term, it is
> an item in the list of components in the PKIX architectural model.  That
> model is shown in the accompanying diagram.
> 
> Any reasonable reading of the phrase "CRL issuer" in an English language
> sentence would hold that it means the issuer of a CRL.  There are two
> components that issue CRLs in the PKIX architecture; one of these
> components also issues certificates.
> 
> 
> 
> 
> Stefan Santesson wrote:
> 
>> Denis,
>>
>>  
>>
>>> On page 59, we have the following sentence:
>>>
>>>    If the distributionPoint field is absent, the CRL MUST contain
>>>    entries for all revoked unexpired certificates *issued* by the CRL
>>>    issuer, if any, within the scope of the CRL
>>>
>>> This sentence is either ambiguous or incorrect: a CRL issuer does not
>>> *issue* certificates. On page 7, the definition of a CRL issuer is:
>>> CRL issuer: an optional system to which a CA delegates the publication
>>>   
>>
>> of
>>  
>>
>>> certificate revocation lists.
>>>   
>>
>>
>> I agree that the definition is not consistent with the standard text in
>> general. Other sections definitely suggest that the CA can be the CRL
>> issuer also without delegation.
>>
>> From 4.2.1.14  CRL Distribution Points:
>>
>>   If the certificate issuer is not the CRL
>>   issuer, then the cRLIssuer field MUST be present and contain the Name
>>   of the CRL issuer.  If the certificate issuer is also the CRL issuer,
>>   then the cRLIssuer field MUST be omitted and the distributionPoint
>>   field MUST be present.
>>
>>
>> Stefan Santesson
>> Microsoft Security Center of Excellence (SCOE)
>>
>>
>>
>>
>>  
>>
> 
> 
> 
> 

Date: Fri, 17 Sep 2004 15:43:53 -0400
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Not only do other sections suggest that the CA can be a CRL issuer, the
text regarding "CRL issuer" on page 6 is *not* a definition of that 
term, it is
an item in the list of components in the PKIX architectural model.  That
model is shown in the accompanying diagram.

Any reasonable reading of the phrase "CRL issuer" in an English language
sentence would hold that it means the issuer of a CRL.  There are two
components that issue CRLs in the PKIX architecture; one of these
components also issues certificates.

Stefan Santesson wrote:

>Denis,
>
>  
>
>>On page 59, we have the following sentence:
>>
>>    If the distributionPoint field is absent, the CRL MUST contain
>>    entries for all revoked unexpired certificates *issued* by the CRL
>>    issuer, if any, within the scope of the CRL
>>
>>This sentence is either ambiguous or incorrect: a CRL issuer does not
>>*issue* certificates. On page 7, the definition of a CRL issuer is:
>>CRL issuer: an optional system to which a CA delegates the publication
>>    
>>
>of
>  
>
>>certificate revocation lists.
>>    
>>
>
>I agree that the definition is not consistent with the standard text in
>general. Other sections definitely suggest that the CA can be the CRL
>issuer also without delegation.
>
>>From 4.2.1.14  CRL Distribution Points:
>
>   If the certificate issuer is not the CRL
>   issuer, then the cRLIssuer field MUST be present and contain the Name
>   of the CRL issuer.  If the certificate issuer is also the CRL issuer,
>   then the cRLIssuer field MUST be omitted and the distributionPoint
>   field MUST be present.
>
>
>Stefan Santesson
>Microsoft Security Center of Excellence (SCOE)
> 
>
>
>
>  
>

Date: Fri, 17 Sep 2004 19:52:26 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Conclusions: CA Rekey and CRL Validation
Sender: [email-masked]

Luciano (Pessoal) wrote:

>2) The "newer CA" can issue CRLs that contain revocation informations
>about all the certificates issued using the new and the old key.
>  
>
I don't like this 'can' :-)

It's ***MUST*** issue CRLs [...] about *ALL* the certificates issued 
using the new and the old key 

>3) It is not necessary mantain the older CA key for issuing CRLs that
>contain only revocation informations about certificates issued using the
>old key (neither containing revocation info about certificates issued by
>the "newer CA").
>  
>
It's not necessary, but you may need it for applications that do not 
support verification of CRL with a key different from the key that 
signed the certificate.

In which case : The older CA key ***MUST*** issue CRLs [...] about *ALL* 
the certificates issued using the new and the old key

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Conclusions: CA Rekey and CRL Validation
Date: Fri, 17 Sep 2004 13:28:15 -0400
Importance: Normal
Sender: [email-masked]

See responses in-line in [].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Luciano (Pessoal)
Sent: Friday, September 17, 2004 10:59 AM
To: [email-masked]
Subject: Conclusions: CA Rekey and CRL Validation

After all this discursion, it is correct affirm:

1) To do a CA-Rekey it is not necessary change the CA's DN.

[MS CAPI will require that a CRL be signed using all the keys that
certificates were issued with and have not expired]

2) The "newer CA" can issue CRLs that contain revocation informations about
all the certificates issued using the new and the old key.

[It is the same CA.  It is not a different CA.  So, the term "newer CA" does
not make sense]

3) It is not necessary mantain the older CA key for issuing CRLs that
contain only revocation informations about certificates issued using the old
key (neither containing revocation info about certificates issued by the
"newer CA").

[Again, newer CA does not make sense.  If you do this, MS CAPI will not
verify the paths for older certificates]

4) A certificate issued by the "older CA" can be validated using the CRL
issued by the "newer CA", without be considered a security problem.

[Again, the terms newer and older are inappropriate]

5) For all the aspects of X509 and RFC 3280, the "newer CA" and the "older
CA" are considered the SAME CA.

Thank you,

Luciano Coelho

content-class: urn:content-classes:message
Subject: RE: Conclusions: CA Rekey and CRL Validation
Date: Fri, 17 Sep 2004 17:21:53 +0200
From: "Alberti Antoine" <[email-masked]>
To: "Luciano \(Pessoal\)" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Because a CA MAY change DN when renewing its key ?

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]]De la part de Luciano (Pessoal)
> Envoyé : vendredi 17 septembre 2004 16:59
> À : [email-masked]
> Objet : Conclusions: CA Rekey and CRL Validation
> 
> 
> 
> After all this discursion, it is correct affirm:
> 
> 1) To do a CA-Rekey it is not necessary change the CA's DN.
> 
> 2) The "newer CA" can issue CRLs that contain revocation informations
> about all the certificates issued using the new and the old key.
> 
> 3) It is not necessary mantain the older CA key for issuing CRLs that
> contain only revocation informations about certificates 
> issued using the
> old key (neither containing revocation info about 
> certificates issued by
> the "newer CA").
> 
> 4) A certificate issued by the "older CA" can be validated 
> using the CRL
> issued by the "newer CA", without be considered a security problem.
> 
> 5) For all the aspects of X509 and RFC 3280, the "newer CA" and the
> "older CA" are considered the SAME CA.
> 
> 
> Thank you,
> 
> Luciano Coelho
> 
> 

Date: Fri, 17 Sep 2004 11:59:15 -0300
From: "Luciano (Pessoal)" <[email-masked]>
To: [email-masked]
Subject: Conclusions: CA Rekey and CRL Validation
Sender: [email-masked]

After all this discursion, it is correct affirm:

1) To do a CA-Rekey it is not necessary change the CA's DN.

2) The "newer CA" can issue CRLs that contain revocation informations
about all the certificates issued using the new and the old key.

3) It is not necessary mantain the older CA key for issuing CRLs that
contain only revocation informations about certificates issued using the
old key (neither containing revocation info about certificates issued by
the "newer CA").

4) A certificate issued by the "older CA" can be validated using the CRL
issued by the "newer CA", without be considered a security problem.

5) For all the aspects of X509 and RFC 3280, the "newer CA" and the
"older CA" are considered the SAME CA.

Thank you,

Luciano Coelho

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Fri, 17 Sep 2004 10:05:15 -0400
Importance: Normal
Sender: [email-masked]

Please read "DP in DP" as DP in CRL DP".  My apologies for the typo.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Friday, September 17, 2004 8:56 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Denis:

See responses in-line in [].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Friday, September 17, 2004 3:10 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

> Denis:

> In X.509, a CA when it issues a CRL is called CRL issuer.  Please look
> at the text of all the extensions descriptions related to CRL 
> issuance.

> Thus, saying a CA is not a CRL Issuer is incorrect in general.

I did not say this.

> In addition, if we assumed your interpretation that a CRL Issuer does
> not issue any certificates, the following sentence which began this 
> debate will be meaning less.
> 
> "If this field is absent, the CRL shall contain entries for all
> revoked unexpired certificates issued by the CRL issuer."

This sentence is not present in RFC 3280.

On page 59, we have the following sentence:

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

This sentence is either ambiguous or incorrect: a CRL issuer does not 
*issue* certificates. On page 7, the definition of a CRL issuer is: CRL
issuer: an optional system to which a CA delegates the publication of 
certificate revocation lists.

[Santosh Says: This sentence says that when the DP field is absent the CRL
must cover all reason codes, all certificates type asserted or implied by
the absence of those fields in the IDP.  Thus, when the IDP is entirely
absent, it means that all reason codes and all certificates (EE and CA) are
covered.]

Besides this "battle" around words, since I have not followed all the 
messages of this thread, a summary would be interresting to answer the two 
following questions:

[Santosh Says: For details, please see X.509 Annex B.  An abridged version
of these is also in 3280 CRL processing section.  I have provided a very
brief overview of this to give the high-level approach]

1) under which circumstances would the distributionPoint field within the 
issuing distribution point structure really useful for ?

[Santosh Says: The DP in IDP is useful when the CRL is split more or other
than reason code and certificate type.  This does not mean that the
compliant implementations can not assert it even when the CRL is complete
for the scope as specified by the presence and absence of onlySomeReasons
and entity type assertion fields in the IDP.] 

2) what kind of processing should a relying party make of it, when this 
field is present ?

[Santosh Says: The relying party should match the DP in CRL DP with the DP
in DP.  See the X.509 Annex B for further detail on calculating the DP in
CRL DP]

Denis

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Thursday, September 16, 2004 12:03 PM
> To: Carl Wallace
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> 
> Carl,
> 
> 
>>>>(including certificates issued by the CRL issuer).
>>>
>>>This is incorrect: a CRL issuer cannot issue certificates.
>>>
>>
> 
>>Why is that?  Given the limited use of the indirectCRL mechanism, most 
>>CRL issuers issue certificates.
> 
> 
> A CRL issuer only issues CRLs.
> A CA issues certificates and may also issue CRLs and/or OCSP
> responses.
> 
> Denis
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Fri, 17 Sep 2004 08:56:08 -0400
Importance: Normal
Sender: [email-masked]

Denis:

See responses in-line in [].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Friday, September 17, 2004 3:10 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

> Denis:

> In X.509, a CA when it issues a CRL is called CRL issuer.  Please look 
> at the text of all the extensions descriptions related to CRL 
> issuance.

> Thus, saying a CA is not a CRL Issuer is incorrect in general.

I did not say this.

> In addition, if we assumed your interpretation that a CRL Issuer does 
> not issue any certificates, the following sentence which began this 
> debate will be meaning less.
> 
> "If this field is absent, the CRL shall contain entries for all 
> revoked unexpired certificates issued by the CRL issuer."

This sentence is not present in RFC 3280.

On page 59, we have the following sentence:

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

This sentence is either ambiguous or incorrect: a CRL issuer does not 
*issue* certificates. On page 7, the definition of a CRL issuer is: CRL
issuer: an optional system to which a CA delegates the publication of 
certificate revocation lists.

[Santosh Says: This sentence says that when the DP field is absent the CRL
must cover all reason codes, all certificates type asserted or implied by
the absence of those fields in the IDP.  Thus, when the IDP is entirely
absent, it means that all reason codes and all certificates (EE and CA) are
covered.]

Besides this "battle" around words, since I have not followed all the 
messages of this thread, a summary would be interresting to answer the two 
following questions:

[Santosh Says: For details, please see X.509 Annex B.  An abridged version
of these is also in 3280 CRL processing section.  I have provided a very
brief overview of this to give the high-level approach]

1) under which circumstances would the distributionPoint field within the 
issuing distribution point structure really useful for ?

[Santosh Says: The DP in IDP is useful when the CRL is split more or other
than reason code and certificate type.  This does not mean that the
compliant implementations can not assert it even when the CRL is complete
for the scope as specified by the presence and absence of onlySomeReasons
and entity type assertion fields in the IDP.] 

2) what kind of processing should a relying party make of it, when this 
field is present ?

[Santosh Says: The relying party should match the DP in CRL DP with the DP
in DP.  See the X.509 Annex B for further detail on calculating the DP in
CRL DP]

Denis

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Thursday, September 16, 2004 12:03 PM
> To: Carl Wallace
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> 
> Carl,
> 
> 
>>>>(including certificates issued by the CRL issuer).
>>>
>>>This is incorrect: a CRL issuer cannot issue certificates.
>>>
>>
> 
>>Why is that?  Given the limited use of the indirectCRL mechanism, most
>>CRL issuers issue certificates.
> 
> 
> A CRL issuer only issues CRLs.
> A CA issues certificates and may also issue CRLs and/or OCSP 
> responses.
> 
> Denis
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Fri, 17 Sep 2004 08:40:38 -0400
Importance: Normal
Sender: [email-masked]

Thomas:

There may be several usage of indirect CRL such as:

1. It may be used for assigning a superior authority to issue revocation
status of a self-issued certificate.  

2.  It may be used by one, many or all CAs in an enterprise to point to an
authority that consolidates and publishes highly security critical
revocations frequently.  Examples of highly security critical revocations
are CA compromise and key compromise.  The approach has benefits of getting
a small CRL (hopefully highly security critical compromises are few) that
can be issued frequently and covers all certificates in an Enterprise
certification path.  Frequent issues reduces the CRL suppression and replay
attacks.

The above are two examples of the usage.  There may be many others.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, September 17, 2004 3:48 AM
To: [email-masked]
Subject: AW: CA Rekey and CRL Validation

Hi all,

there is an other point I am wondering about: For what purpose do I need
indierkt CRLs within the PEM valitity model (i. e. the validity of an
entities certificate lies between the notBefore an notAfter limits of the
issuing CAs certificate)?

Thomas

> -----Ursprüngliche Nachricht-----
> Von: Denis Pinkas [mailto:[email-masked]]
> Gesendet: Freitag, 17. September 2004 09:10
> An: Santosh Chokhani
> Cc: [email-masked]
> Betreff: Re: CA Rekey and CRL Validation
> 
> 
> 
> Santosh,
> 
> > Denis:
> 
> > In X.509, a CA when it issues a CRL is called CRL issuer.
> Please look at
> > the text of all the extensions descriptions related to CRL issuance.
> 
> > Thus, saying a CA is not a CRL Issuer is incorrect in general.
> 
> I did not say this.
> 
> > In addition, if we assumed your interpretation that a CRL
> Issuer does not
> > issue any certificates, the following sentence which began
> this debate will
> > be meaning less.
> > 
> > "If this field is absent, the CRL shall contain entries for
> all revoked
> > unexpired certificates issued by the CRL issuer."
> 
> This sentence is not present in RFC 3280.
> 
> On page 59, we have the following sentence:
> 
>     If the distributionPoint field is absent, the CRL MUST contain
>     entries for all revoked unexpired certificates *issued* by the CRL
>     issuer, if any, within the scope of the CRL
> 
> This sentence is either ambiguous or incorrect: a CRL issuer does not
> *issue* certificates. On page 7, the definition of a CRL issuer is:
> CRL issuer: an optional system to which a CA delegates the 
> publication of 
> certificate revocation lists.
> 
> Besides this "battle" around words, since I have not followed all the
> messages of this thread, a summary would be interresting to 
> answer the two 
> following questions:
> 
> 1) under which circumstances would the distributionPoint
> field within the 
> issuing distribution point structure really useful for ?
> 
> 2) what kind of processing should a relying party make of it,
> when this 
> field is present ?
> 
> Denis
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]] On
> > Behalf Of Denis Pinkas
> > Sent: Thursday, September 16, 2004 12:03 PM
> > To: Carl Wallace
> > Cc: [email-masked]
> > Subject: Re: CA Rekey and CRL Validation
> > 
> > 
> > 
> > Carl,
> > 
> > 
> >>>>(including certificates issued by the CRL issuer).
> >>>
> >>>This is incorrect: a CRL issuer cannot issue certificates.
> >>>
> >>
> > 
> >>Why is that?  Given the limited use of the indirectCRL
> mechanism, most
> >>CRL issuers issue certificates.
> > 
> > 
> > A CRL issuer only issues CRLs.
> > A CA issues certificates and may also issue CRLs and/or
> OCSP responses.
> > 
> > Denis
> > 
> > 
> > 
> > 
> 
> 

Date: Fri, 17 Sep 2004 22:13:15 +1000
From: ronnie sahlberg <[email-masked]>
Reply-To: ronnie sahlberg <[email-masked]>
To: [email-masked]
Subject: [OT] Help and example captures for Etehreal development of PKIX protocols requested.
Sender: [email-masked]

List
Sorry for the offtopic post.

I would like to add more PKIX protocols to Ethereal, aside from the
PKIX1..plicit
protocols used by PKINIT already semi-supported.

To start with I thought about rfc2510 and rfc2511.

In order to do this I request help from anyone interested, to provide
example network capture files to verify the dissection of such packets
agains as well as someone I can ask stupid questions.

If anyone is interested in getting Ethereal support for all the PKIX
related protocols  I am all game and willing to implement these
protocols, if I can get example capture files to verify with. (and
someone to ask questions when the asn1 definitions dont match what i
would expect them to match).

(If there are packets out there   crossing any kind of network   and
ethereal is not capable to decode them properly   then that is a bug
in ethereal    please help me fix these bugs in ethereal)

Best regards
   ronnie sahlberg

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Fri, 17 Sep 2004 08:07:07 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

It is the IDP definition you need to look at since IDP in CRL is the one
that limits the CRL scope and not the CRL DP in the certificate.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, September 17, 2004 6:17 AM
To: Denis Pinkas; Santosh Chokhani
Cc: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Denis,

> On page 59, we have the following sentence:
> 
>     If the distributionPoint field is absent, the CRL MUST contain
>     entries for all revoked unexpired certificates *issued* by the CRL
>     issuer, if any, within the scope of the CRL
> 
> This sentence is either ambiguous or incorrect: a CRL issuer does not
> *issue* certificates. On page 7, the definition of a CRL issuer is: 
> CRL issuer: an optional system to which a CA delegates the publication
of
> certificate revocation lists.

I agree that the definition is not consistent with the standard text in
general. Other sections definitely suggest that the CA can be the CRL issuer
also without delegation.

>From 4.2.1.14  CRL Distribution Points:

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

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
Cc: [email-masked]
Date: Fri, 17 Sep 2004 22:23:02 +1200
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>As I noted earlier in my messages, I think it would be appropriate to include
>these extensions in path validation. In fact, I raised this issue over a year
>ago in discussions with Sharon and Sanrtosh. But, X.509 does not allow this at
>this time.

If there's consensus that this is a good idea, why not just change it?  PKIX
is bigger than X.509 (does anyone still work from X.509 rather than going
straight to the PKIX sources)?  I know that PKIX was originally started to
profile X.509 for Internet use, but it's been running (or at least shuffling)
as a full parallel standards group for years since then.  PKIX is the dog,
X.509 is its vestigial tail, why not wag it?

(I'm not trying to pick a fight with the X.509 folks, it's just a pain having
 two (more if you include ETSI and other groups) parallel standards bodies all
 busy cutting&pasting each other's work as they play Chinese Whispers with the
 spec, with sundry propagation delays, inconsistencies, and errors introduced
 along the way).

Peter.

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Fri, 17 Sep 2004 11:19:33 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

You don't, those aspects are completely unrelated

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: den 17 september 2004 09:48
> To: [email-masked]
> Subject: AW: CA Rekey and CRL Validation
> 
> 
> Hi all,
> 
> there is an other point I am wondering about: For what purpose do I need
> indierkt CRLs within the PEM valitity model (i. e. the validity of an
> entities certificate lies between the notBefore an notAfter limits of the
> issuing CAs certificate)?
> 
> Thomas
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Denis Pinkas [mailto:[email-masked]]
> > Gesendet: Freitag, 17. September 2004 09:10
> > An: Santosh Chokhani
> > Cc: [email-masked]
> > Betreff: Re: CA Rekey and CRL Validation
> >
> >
> >
> > Santosh,
> >
> > > Denis:
> >
> > > In X.509, a CA when it issues a CRL is called CRL issuer.
> > Please look at
> > > the text of all the extensions descriptions related to CRL issuance.
> >
> > > Thus, saying a CA is not a CRL Issuer is incorrect in general.
> >
> > I did not say this.
> >
> > > In addition, if we assumed your interpretation that a CRL
> > Issuer does not
> > > issue any certificates, the following sentence which began
> > this debate will
> > > be meaning less.
> > >
> > > "If this field is absent, the CRL shall contain entries for
> > all revoked
> > > unexpired certificates issued by the CRL issuer."
> >
> > This sentence is not present in RFC 3280.
> >
> > On page 59, we have the following sentence:
> >
> >     If the distributionPoint field is absent, the CRL MUST contain
> >     entries for all revoked unexpired certificates *issued* by the CRL
> >     issuer, if any, within the scope of the CRL
> >
> > This sentence is either ambiguous or incorrect: a CRL issuer does not
> > *issue* certificates. On page 7, the definition of a CRL issuer is:
> > CRL issuer: an optional system to which a CA delegates the
> > publication of
> > certificate revocation lists.
> >
> > Besides this "battle" around words, since I have not followed all the
> > messages of this thread, a summary would be interresting to
> > answer the two
> > following questions:
> >
> > 1) under which circumstances would the distributionPoint
> > field within the
> > issuing distribution point structure really useful for ?
> >
> > 2) what kind of processing should a relying party make of it,
> > when this
> > field is present ?
> >
> > Denis
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]] On
> > > Behalf Of Denis Pinkas
> > > Sent: Thursday, September 16, 2004 12:03 PM
> > > To: Carl Wallace
> > > Cc: [email-masked]
> > > Subject: Re: CA Rekey and CRL Validation
> > >
> > >
> > >
> > > Carl,
> > >
> > >
> > >>>>(including certificates issued by the CRL issuer).
> > >>>
> > >>>This is incorrect: a CRL issuer cannot issue certificates.
> > >>>
> > >>
> > >
> > >>Why is that?  Given the limited use of the indirectCRL
> > mechanism, most
> > >>CRL issuers issue certificates.
> > >
> > >
> > > A CRL issuer only issues CRLs.
> > > A CA issues certificates and may also issue CRLs and/or
> > OCSP responses.
> > >
> > > Denis
> > >
> > >
> > >
> > >
> >
> >

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Fri, 17 Sep 2004 11:16:34 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Santosh Chokhani" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Denis,

> On page 59, we have the following sentence:
> 
>     If the distributionPoint field is absent, the CRL MUST contain
>     entries for all revoked unexpired certificates *issued* by the CRL
>     issuer, if any, within the scope of the CRL
> 
> This sentence is either ambiguous or incorrect: a CRL issuer does not
> *issue* certificates. On page 7, the definition of a CRL issuer is:
> CRL issuer: an optional system to which a CA delegates the publication
of
> certificate revocation lists.

I agree that the definition is not consistent with the standard text in
general. Other sections definitely suggest that the CA can be the CRL
issuer also without delegation.

>From 4.2.1.14  CRL Distribution Points:

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

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

From: [email-masked]
To: [email-masked]
Subject: AW: CA Rekey and CRL Validation
Date: Fri, 17 Sep 2004 09:47:47 +0200
Sender: [email-masked]

Hi all,

there is an other point I am wondering about: For what purpose do I need
indierkt CRLs within the PEM valitity model (i. e. the validity of an
entities certificate lies between the notBefore an notAfter limits of the
issuing CAs certificate)?

Thomas

> -----Ursprüngliche Nachricht-----
> Von: Denis Pinkas [mailto:[email-masked]]
> Gesendet: Freitag, 17. September 2004 09:10
> An: Santosh Chokhani
> Cc: [email-masked]
> Betreff: Re: CA Rekey and CRL Validation
> 
> 
> 
> Santosh,
> 
> > Denis:
> 
> > In X.509, a CA when it issues a CRL is called CRL issuer.  
> Please look at
> > the text of all the extensions descriptions related to CRL issuance.
> 
> > Thus, saying a CA is not a CRL Issuer is incorrect in general.
> 
> I did not say this.
> 
> > In addition, if we assumed your interpretation that a CRL 
> Issuer does not
> > issue any certificates, the following sentence which began 
> this debate will
> > be meaning less.
> > 
> > "If this field is absent, the CRL shall contain entries for 
> all revoked
> > unexpired certificates issued by the CRL issuer."
> 
> This sentence is not present in RFC 3280.
> 
> On page 59, we have the following sentence:
> 
>     If the distributionPoint field is absent, the CRL MUST contain
>     entries for all revoked unexpired certificates *issued* by the CRL
>     issuer, if any, within the scope of the CRL
> 
> This sentence is either ambiguous or incorrect: a CRL issuer does not 
> *issue* certificates. On page 7, the definition of a CRL issuer is:
> CRL issuer: an optional system to which a CA delegates the 
> publication of 
> certificate revocation lists.
> 
> Besides this "battle" around words, since I have not followed all the 
> messages of this thread, a summary would be interresting to 
> answer the two 
> following questions:
> 
> 1) under which circumstances would the distributionPoint 
> field within the 
> issuing distribution point structure really useful for ?
> 
> 2) what kind of processing should a relying party make of it, 
> when this 
> field is present ?
> 
> Denis
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On
> > Behalf Of Denis Pinkas
> > Sent: Thursday, September 16, 2004 12:03 PM
> > To: Carl Wallace
> > Cc: [email-masked]
> > Subject: Re: CA Rekey and CRL Validation
> > 
> > 
> > 
> > Carl,
> > 
> > 
> >>>>(including certificates issued by the CRL issuer).
> >>>
> >>>This is incorrect: a CRL issuer cannot issue certificates.
> >>>
> >>
> > 
> >>Why is that?  Given the limited use of the indirectCRL 
> mechanism, most 
> >>CRL issuers issue certificates.
> > 
> > 
> > A CRL issuer only issues CRLs.
> > A CA issues certificates and may also issue CRLs and/or 
> OCSP responses.
> > 
> > Denis
> > 
> > 
> > 
> > 
> 
> 

Date: Fri, 17 Sep 2004 09:10:25 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Santosh,

> Denis:

> In X.509, a CA when it issues a CRL is called CRL issuer.  Please look at
> the text of all the extensions descriptions related to CRL issuance.

> Thus, saying a CA is not a CRL Issuer is incorrect in general.

I did not say this.

> In addition, if we assumed your interpretation that a CRL Issuer does not
> issue any certificates, the following sentence which began this debate will
> be meaning less.
> 
> "If this field is absent, the CRL shall contain entries for all revoked
> unexpired certificates issued by the CRL issuer."

This sentence is not present in RFC 3280.

On page 59, we have the following sentence:

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

This sentence is either ambiguous or incorrect: a CRL issuer does not 
*issue* certificates. On page 7, the definition of a CRL issuer is:
CRL issuer: an optional system to which a CA delegates the publication of 
certificate revocation lists.

Besides this "battle" around words, since I have not followed all the 
messages of this thread, a summary would be interresting to answer the two 
following questions:

1) under which circumstances would the distributionPoint field within the 
issuing distribution point structure really useful for ?

2) what kind of processing should a relying party make of it, when this 
field is present ?

Denis

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Denis Pinkas
> Sent: Thursday, September 16, 2004 12:03 PM
> To: Carl Wallace
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> 
> Carl,
> 
> 
>>>>(including certificates issued by the CRL issuer).
>>>
>>>This is incorrect: a CRL issuer cannot issue certificates.
>>>
>>
> 
>>Why is that?  Given the limited use of the indirectCRL mechanism, most 
>>CRL issuers issue certificates.
> 
> 
> A CRL issuer only issues CRLs.
> A CA issues certificates and may also issue CRLs and/or OCSP responses.
> 
> Denis
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 13:11:45 -0400
Importance: Normal
Sender: [email-masked]

Denis:

In X.509, a CA when it issues a CRL is called CRL issuer.  Please look at
the text of all the extensions descriptions related to CRL issuance.

Thus, saying a CA is not a CRL Issuer is incorrect in general.

In addition, if we assumed your interpretation that a CRL Issuer does not
issue any certificates, the following sentence which began this debate will
be meaning less.

"If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the CRL issuer."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Thursday, September 16, 2004 12:03 PM
To: Carl Wallace
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Carl,

>>>(including certificates issued by the CRL issuer).
>>
>>This is incorrect: a CRL issuer cannot issue certificates.
>>

> Why is that?  Given the limited use of the indirectCRL mechanism, most 
> CRL issuers issue certificates.

A CRL issuer only issues CRLs.
A CA issues certificates and may also issue CRLs and/or OCSP responses.

Denis

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 12:52:49 -0400
Importance: Normal
Sender: [email-masked]

But, the point remains that the CRL is complete for the Issuing CA.

-----Original Message-----
From: Carl Wallace [mailto:[email-masked]] 
Sent: Thursday, September 16, 2004 12:49 PM
To: 'Denis Pinkas'; 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: CA Rekey and CRL Validation

> You are correct that absence of IDP does not necessarily mean that it 
> is a CRL is complete for the CA.  It means more.
> Absence of IDP means the CRL is complete for all certificates 
> issued by all CAs that identify the CRL issuer in their 
> public key certificates (including certificates issued by the 
> CRL issuer).  See X.509: "it is the responsibility of the CRL 
> issuer to ensure that the CRL is complete in that it contains 
> all revocation entries...from all authorities that identify 
> this CRL issuer in their certificates."  
 
Ack.  Without an IDP, the CRL can't be indirect.  I was still stuck in the
missing DP field mindset of a few days ago.  Kindly ignore my post:-)

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 12:52:19 -0400
Importance: Normal
Sender: [email-masked]

But, the point is the CRL is complete for the Issuing CA.

-----Original Message-----
From: Carl Wallace [mailto:[email-masked]] 
Sent: Thursday, September 16, 2004 12:49 PM
To: 'Denis Pinkas'; 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: CA Rekey and CRL Validation

> You are correct that absence of IDP does not necessarily mean
> that it is a CRL is complete for the CA.  It means more.  
> Absence of IDP means the CRL is complete for all certificates 
> issued by all CAs that identify the CRL issuer in their 
> public key certificates (including certificates issued by the 
> CRL issuer).  See X.509: "it is the responsibility of the CRL 
> issuer to ensure that the CRL is complete in that it contains 
> all revocation entries...from all authorities that identify 
> this CRL issuer in their certificates."  
 
Ack.  Without an IDP, the CRL can't be indirect.  I was still stuck in the
missing DP field mindset of a few days ago.  Kindly ignore my post:-)

From: "Carl Wallace" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 12:49:24 -0400
Sender: [email-masked]

> You are correct that absence of IDP does not necessarily mean 
> that it is a CRL is complete for the CA.  It means more.  
> Absence of IDP means the CRL is complete for all certificates 
> issued by all CAs that identify the CRL issuer in their 
> public key certificates (including certificates issued by the 
> CRL issuer).  See X.509: "it is the responsibility of the CRL 
> issuer to ensure that the CRL is complete in that it contains 
> all revocation entries...from all authorities that identify 
> this CRL issuer in their certificates."  
 
Ack.  Without an IDP, the CRL can't be indirect.  I was still stuck in the
missing DP field mindset of a few days ago.  Kindly ignore my post:-)

Date: Thu, 16 Sep 2004 18:02:41 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Carl Wallace <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Carl,

>>>(including certificates issued by the CRL issuer).  
>>
>>This is incorrect: a CRL issuer cannot issue certificates.
>>

> Why is that?  Given the limited use of the indirectCRL mechanism, most CRL
> issuers issue certificates.

A CRL issuer only issues CRLs.
A CA issues certificates and may also issue CRLs and/or OCSP responses.

Denis

Date: Thu, 16 Sep 2004 12:00:43 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Delta CRLs - Is there any final conclusion?
Cc: [email-masked]
Sender: [email-masked]

<html>
<body>
I think that it would be very good for David Cooper to lead an effort to
develop a document in this area.&nbsp; I am not sure that he has
time.<br><br>
Russ<br><br>
<br>
At 03:13 AM 9/16/2004, Yasir Khan wrote:<br>
<blockquote type=cite class=cite cite=""><font face="arial" size=2 color="#800080">Hi,<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#800080">I have been looking at IETF
archives and found many threads discussing the Delta-CRLs. Also I saw
David A. Cooper's paper &quot;<u>A More Efficient Use of
Delta-CRLs</u>&quot;&nbsp; and Russ, Tim and Cooper's
&quot;</font><a name="01505"></a><font face="Times New Roman, Times" color="#800080">Strawman
on 
Delta-CRLs</font><font face="arial" size=2 color="#800080">&quot;<br>
After going through many threads and papers, still I couldn't find any
final document/discussion describing the issuance/usage of Delta-CRLs. If
a standard way has been concluded for issuance/usage of Delta-CRLs then
please refer me to that information. Thanx<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#800080">Reagrds,<br>
Yasir</font></blockquote></body>
</html>

From: "Carl Wallace" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "'Santosh Chokhani'" <[email-masked]>, <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 11:42:06 -0400
Sender: [email-masked]

> > (including certificates issued by the CRL issuer).  
> 
> This is incorrect: a CRL issuer cannot issue certificates.
> 

Why is that?  Given the limited use of the indirectCRL mechanism, most CRL
issuers issue certificates.

Date: Thu, 16 Sep 2004 17:35:30 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Carl Wallace <[email-masked]>
CC: "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Carl,

(text deleted)

> You are correct that absence of IDP does not necessarily mean that it is a
> CRL is complete for the CA.  It means more.  Absence of IDP means the CRL is
> complete for all certificates issued by all CAs that identify the CRL issuer
> in their public key certificates 

Correct, .. and CAs can used different CRL Issuers.

> (including certificates issued by the CRL issuer).  

This is incorrect: a CRL issuer cannot issue certificates.

Denis

> See X.509: "it is the responsibility of the CRL issuer to ensure
> that the CRL is complete in that it contains all revocation entries...from
> all authorities that identify this CRL issuer in their certificates."  

From: "Carl Wallace" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 11:28:49 -0400
Sender: [email-masked]

> > [In this mail thread, we then determined that standards are 
> clear in 
> > that absence of IDP means a CRL is complete for the CA.]
> 
> [Denis : I have difficulties to agree with this. There is a 
> situation where this is not the case. If the certificate 
> includes a CRL DP extension with the field cRLIssuer present, 
> then it means that the CRL present at the distributionPoint 
> MUST be signed by that CRL Issuer. Then the relying party 
> MUST find a certificate issued by the CA that has delivered 
> that certificate which has the keyUsage bit 6 set (cRLSign) 
> and which includes the name of this CRL issuer as the subject 
> name. It MUST then verify that the CRL which has been found 
> is indeed signed by the key included in that certificate.
> 
> DistributionPoint is copied below:
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     
> DistributionPointName OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
> Absence of IDP does not necessarilly mean that it is a CRL is 
> complete for the CA.
> 
> Going back to RFC 3280, RFC 3280 is not sufficiently explicit 
> about the ways to find the right CRL, when the CRL issuer is 
> different from the CA. More text would be needed to cover this aspect.
> 
> /Denis ]

You are correct that absence of IDP does not necessarily mean that it is a
CRL is complete for the CA.  It means more.  Absence of IDP means the CRL is
complete for all certificates issued by all CAs that identify the CRL issuer
in their public key certificates (including certificates issued by the CRL
issuer).  See X.509: "it is the responsibility of the CRL issuer to ensure
that the CRL is complete in that it contains all revocation entries...from
all authorities that identify this CRL issuer in their certificates."  

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 10:59:10 -0400
Importance: Normal
Sender: [email-masked]

Denis:

What is the difference between "all the certificates issued by the CRL
Issuer" and CA if both are the same?

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, September 16, 2004 10:56 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

> Denis:
> 
> You should also see Section 8.6.2.2 of X.509 describing IDP.  Examine 
> the last sentence and I quote the section below.
> 
> Issuing distribution point extension
> This CRL extension field identifies the CRL distribution point for 
> this particular CRL, and indicates if the CRL is limited to 
> revocations for end-entity certificates only, for authority 
> certificates only, or for a limited set of reasons only. The CRL is 
> signed by the CRL issuer's key - CRL distribution points do not have 
> their own key pairs. However, for a CRL distributed via the Directory, 
> the CRL is stored in the entry of the CRL distribution point, which 
> may not be the directory entry of the CRL issuer. If this field is 
> absent, the CRL shall contain entries for all revoked unexpired 
> certificates issued by the CRL issuer.

The last sentence does NOT say:

"If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the *CA*".

You said:

"In this mail thread, we then determined that standards are clear in that
absence of IDP means a CRL is complete for the *CA*".

This makes a big difference.

Denis

> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Thursday, September 16, 2004 9:26 AM
> To: [email-masked]'
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Denis:
> 
> Please see responses with [Santosh:]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, September 16, 2004 8:25 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> See may response in-line with [Denis: ]
> 
> 
>>Stefan:
>>
>>See responses in-line.
>>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Stefan Santesson
>>Sent: Thursday, September 16, 2004 4:38 AM
>>To: Santosh Chokhani; [email-masked]
>>Subject: RE: CA Rekey and CRL Validation
>>
>>Yes I have noted that.
>>
>>Still I think we can conclude then that there are no place in RFC 3280 
>>or X.509 where this is explicitly stated.
>>
>>That is not what I call "crystal clear"
>>
>>[In this mail thread, we first determined that a CA is defined by name 
>>only and not be name+key.  We determined that both 3280 and X.509 are 
>>clear on that.  If you want add this sentence explicitly, I do not 
>>have objections.]
> 
> 
> [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.]
> 
> 
>>[In this mail thread, we then determined that standards are clear in 
>>that absence of IDP means a CRL is complete for the CA.]
> 
> 
> [Denis : I have difficulties to agree with this. There is a situation 
> where
> this is not the case. If the certificate includes a CRL DP extension with 
> the field cRLIssuer present, then it means that the CRL present at the 
> distributionPoint MUST be signed by that CRL Issuer. Then the relying
party 
> MUST find a certificate issued by the CA that has delivered that
certificate
> 
> which has the keyUsage bit 6 set (cRLSign) and which includes the name 
> of
> this CRL issuer as the subject name. It MUST then verify that the CRL
which 
> has been found is indeed signed by the key included in that certificate.
> 
> DistributionPoint is copied below:
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     DistributionPointName OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
> Absence of IDP does not necessarilly mean that it is a CRL is complete 
> for
> the CA.
> 
> [Santosh: We are talking about IDP in CRL and not CRL DP in 
> certificate. Please look at Carl Wallace posting pointing to a section 
> in 3280 in this thread and my posting pointing to Section B.5.1.1 of 
> X.509]
> 
> Going back to RFC 3280, RFC 3280 is not sufficiently explicit about 
> the ways
> 
> to find the right CRL, when the CRL issuer is different from the CA. 
> More
> text would be needed to cover this aspect.
> 
> [Santosh: We are not discussing how to find a CRL.  We are discussing 
> how to determine if the CRL you have is appropriate.]
> 
> /Denis ]
> 
> 
>>In the revision of RFC 3280 I would suggest adding a section that 
>>deals with the aspects of CA re-keying and how that explicitly affects 
>>the use of the standard and what it takes to achieve that. E.g. what 
>>certificates you need to cover in a "full" CRL, that a re-keyed CA 
>>instance don't re-use certificate serial numbers from certificates 
>>issued by previous CA instances etc.
>>
>>[If you are using the same name and then reusing the serial numbers 
>>when rekeying, you have a bigger problem than just revocation 
>>checking.  I hope no product is doing that.]
>>
>>CMP 4.4.1 tries to cover some of that ground but doesn't cover the 
>>aspects above and is neither normative for X.509 or RFC 3280
>>
>>Stefan Santesson
>>Microsoft Security Center of Excellence (SCOE)
>> 
>>
>>
>>
>>>-----Original Message-----
>>>From: [email-masked]
>>
>>[mailto:[email-masked]]
>>
>>
>>>On Behalf Of Santosh Chokhani
>>>Sent: den 15 september 2004 19:03
>>>To: [email-masked]
>>>Subject: RE: CA Rekey and CRL Validation
>>>
>>>
>>>Stefan:
>>>
>>>That knows lies in several posting here where we have concluded that 
>>>a
>>
>>CA
>>
>>
>>>=
>>>Issuer Name and a CA != Issuer Name + Key
>>>
>>>-----Original Message-----
>>>From: Stefan Santesson [mailto:[email-masked]]
>>>Sent: Wednesday, September 15, 2004 12:56 PM
>>>To: Santosh Chokhani; [email-masked]
>>>Subject: RE: CA Rekey and CRL Validation
>>>
>>>
>>>Santosh,
>>>
>>>Thanks.
>>>
>>>I must conclude though that the term "crystal clear" has completely
>>>different meaning in our vocabularies :-)
>>>
>>>All this is clear IF you understand that "complete" means not only
>>>certificate issued under one CA key, but all certificates issued under
>>
>>all
>>
>>
>>>keys of that CA.
>>>
>>>But where do you gain that knowledge?
>>>THAT is what interests me.
>>>
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [email-masked]
>>>
>>>[mailto:[email-masked]]
>>>
>>>
>>>>On Behalf Of Santosh Chokhani
>>>>Sent: den 15 september 2004 17:24
>>>>To: [email-masked]
>>>>Subject: RE: CA Rekey and CRL Validation
>>>>
>>>>
>>>>Stefan:
>>>>
>>>>See Section B.5.1.1 Complete CRL and I quote it below:
>>>>
>>>>"In order to determine that a CRL is a complete CRL for end-entity
>>>
>>and
>>
>>
>>>>CA-certificates, for all reason codes of interest, the following
>>>
>>shall
>>
>>
>>>be
>>>
>>>
>>>>true:
>>>>-	Delta CRL indicator extension shall be absent; and
>>>>-	Issuing distribution point extension may be present; and
>>>>-	Issuing distribution point extension shall not contain
>>>>distribution
>>>>point field; and
>>>>-	Issuing distribution point extension shall not contain
>>>>onlyContainsUserCerts field set to TRUE; and
>>>>-	Issuing distribution point extension shall not contain
>>>>onlyContainsAuthorityCerts field set to TRUE; and
>>>>-	Issuing distribution point extension shall not contain
>>>>onlyContainsAttributeCerts field set to TRUE; and
>>>>-	If the reasonCodes field is present in the issuing distribution
>>>>point extension, the reasons code field shall include all the
>>>
>>reasons
>>
>>
>>>of
>>>
>>>
>>>>interest to the application; and
>>>>-	Issuing distribution point extension may or may not contain
>>>>indirectCRL field (hence, this field need not be checked)."
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Stefan Santesson [mailto:[email-masked]]
>>>>Sent: Wednesday, September 15, 2004 11:01 AM
>>>>To: Santosh Chokhani; [email-masked]
>>>>Subject: RE: CA Rekey and CRL Validation
>>>>
>>>>
>>>>Santosh,
>>>>
>>>>
>>>>
>>>>>[Since I have been involved in crafting portions of X.509 and
>>>>
>>since
>>
>>
>>>>Annex
>>>>
>>>>
>>>>>B
>>>>>that is normative makes this abundantly clear, I beg to differ
>>>>
>>that
>>
>>
>>>it
>>>
>>>
>>>>is
>>>>
>>>>
>>>>>not clear enough or authors of the text did not have this in mind.
>>>>
>>>>Any
>>>>
>>>>
>>>>>suggestion to make it clearer in X.509 are welcome.]
>>>>
>>>>
>>>>Well, since I'm talking to the expert :-)
>>>>
>>>>I would be very grateful if you could point me to the section in
>>>
>>Annex
>>
>>
>>>B
>>>
>>>
>>>>that makes this "abundantly clear".
>>>>
>>>>In fact, I would be even more grateful, to find the section that
>>>
>>deals
>>
>>
>>>>with CA generation management where it is clearly stated what the
>>>>effect
>>>
>>>are
>>>
>>>
>>>>when
>>>>re-keying a CA with a new key but the same name. E.g. that this is
>>>
>>>still
>>>
>>>
>>>>part of the same CA and that all language that mention the concept
>>>
>>of
>>
>>
>>>a CA
>>>
>>>
>>>>or CRL issuer explicitly means all instances of that CA or CRL
>>>
>>issuer
>>
>>
>>>(for
>>>
>>>
>>>>all generations of issuing keys).
>>>>
>>>>All I have seen is text from which you can derive this truth. I have
>>>
>>>NOT
>>>
>>>
>>>>seen any text presented where this has been explicitly stated.
>>>>
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
> 
> 
> 

Date: Thu, 16 Sep 2004 16:55:35 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Santosh,

> Denis:
> 
> You should also see Section 8.6.2.2 of X.509 describing IDP.  Examine the
> last sentence and I quote the section below.
> 
> Issuing distribution point extension
> This CRL extension field identifies the CRL distribution point for this
> particular CRL, and indicates if the CRL is limited to revocations for
> end-entity certificates only, for authority certificates only, or for a
> limited set of reasons only. The CRL is signed by the CRL issuer's key - CRL
> distribution points do not have their own key pairs. However, for a CRL
> distributed via the Directory, the CRL is stored in the entry of the CRL
> distribution point, which may not be the directory entry of the CRL issuer.
> If this field is absent, the CRL shall contain entries for all revoked
> unexpired certificates issued by the CRL issuer.

The last sentence does NOT say:

"If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the *CA*".

You said:

"In this mail thread, we then determined that standards are clear in
that absence of IDP means a CRL is complete for the *CA*".

This makes a big difference.

Denis

> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]] 
> Sent: Thursday, September 16, 2004 9:26 AM
> To: [email-masked]'
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Denis:
> 
> Please see responses with [Santosh:]
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Thursday, September 16, 2004 8:25 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> See may response in-line with [Denis: ]
> 
> 
>>Stefan:
>>
>>See responses in-line.
>>
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]] On Behalf Of Stefan Santesson
>>Sent: Thursday, September 16, 2004 4:38 AM
>>To: Santosh Chokhani; [email-masked]
>>Subject: RE: CA Rekey and CRL Validation
>>
>>Yes I have noted that.
>>
>>Still I think we can conclude then that there are no place in RFC 3280
>>or X.509 where this is explicitly stated.
>>
>>That is not what I call "crystal clear"
>>
>>[In this mail thread, we first determined that a CA is defined by name
>>only and not be name+key.  We determined that both 3280 and X.509 are 
>>clear on that.  If you want add this sentence explicitly, I do not 
>>have objections.]
> 
> 
> [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.]
> 
> 
>>[In this mail thread, we then determined that standards are clear in
>>that absence of IDP means a CRL is complete for the CA.]
> 
> 
> [Denis : I have difficulties to agree with this. There is a situation where 
> this is not the case. If the certificate includes a CRL DP extension with 
> the field cRLIssuer present, then it means that the CRL present at the 
> distributionPoint MUST be signed by that CRL Issuer. Then the relying party 
> MUST find a certificate issued by the CA that has delivered that certificate
> 
> which has the keyUsage bit 6 set (cRLSign) and which includes the name of 
> this CRL issuer as the subject name. It MUST then verify that the CRL which 
> has been found is indeed signed by the key included in that certificate.
> 
> DistributionPoint is copied below:
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     DistributionPointName OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
> Absence of IDP does not necessarilly mean that it is a CRL is complete for 
> the CA.
> 
> [Santosh: We are talking about IDP in CRL and not CRL DP in certificate.
> Please look at Carl Wallace posting pointing to a section in 3280 in this
> thread and my posting pointing to Section B.5.1.1 of X.509]
> 
> Going back to RFC 3280, RFC 3280 is not sufficiently explicit about the ways
> 
> to find the right CRL, when the CRL issuer is different from the CA. More 
> text would be needed to cover this aspect.
> 
> [Santosh: We are not discussing how to find a CRL.  We are discussing how to
> determine if the CRL you have is appropriate.]
> 
> /Denis ]
> 
> 
>>In the revision of RFC 3280 I would suggest adding a section that
>>deals with the aspects of CA re-keying and how that explicitly affects 
>>the use of the standard and what it takes to achieve that. E.g. what 
>>certificates you need to cover in a "full" CRL, that a re-keyed CA 
>>instance don't re-use certificate serial numbers from certificates 
>>issued by previous CA instances etc.
>>
>>[If you are using the same name and then reusing the serial numbers
>>when rekeying, you have a bigger problem than just revocation 
>>checking.  I hope no product is doing that.]
>>
>>CMP 4.4.1 tries to cover some of that ground but doesn't cover the
>>aspects above and is neither normative for X.509 or RFC 3280
>>
>>Stefan Santesson
>>Microsoft Security Center of Excellence (SCOE)
>> 
>>
>>
>>
>>>-----Original Message-----
>>>From: [email-masked]
>>
>>[mailto:[email-masked]]
>>
>>
>>>On Behalf Of Santosh Chokhani
>>>Sent: den 15 september 2004 19:03
>>>To: [email-masked]
>>>Subject: RE: CA Rekey and CRL Validation
>>>
>>>
>>>Stefan:
>>>
>>>That knows lies in several posting here where we have concluded that a
>>
>>CA
>>
>>
>>>=
>>>Issuer Name and a CA != Issuer Name + Key
>>>
>>>-----Original Message-----
>>>From: Stefan Santesson [mailto:[email-masked]]
>>>Sent: Wednesday, September 15, 2004 12:56 PM
>>>To: Santosh Chokhani; [email-masked]
>>>Subject: RE: CA Rekey and CRL Validation
>>>
>>>
>>>Santosh,
>>>
>>>Thanks.
>>>
>>>I must conclude though that the term "crystal clear" has completely 
>>>different meaning in our vocabularies :-)
>>>
>>>All this is clear IF you understand that "complete" means not only 
>>>certificate issued under one CA key, but all certificates issued under
>>
>>all
>>
>>
>>>keys of that CA.
>>>
>>>But where do you gain that knowledge?
>>>THAT is what interests me.
>>>
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [email-masked]
>>>
>>>[mailto:[email-masked]]
>>>
>>>
>>>>On Behalf Of Santosh Chokhani
>>>>Sent: den 15 september 2004 17:24
>>>>To: [email-masked]
>>>>Subject: RE: CA Rekey and CRL Validation
>>>>
>>>>
>>>>Stefan:
>>>>
>>>>See Section B.5.1.1 Complete CRL and I quote it below:
>>>>
>>>>"In order to determine that a CRL is a complete CRL for end-entity
>>>
>>and
>>
>>
>>>>CA-certificates, for all reason codes of interest, the following
>>>
>>shall
>>
>>
>>>be
>>>
>>>
>>>>true:
>>>>-	Delta CRL indicator extension shall be absent; and
>>>>-	Issuing distribution point extension may be present; and
>>>>-	Issuing distribution point extension shall not contain
>>>>distribution
>>>>point field; and
>>>>-	Issuing distribution point extension shall not contain
>>>>onlyContainsUserCerts field set to TRUE; and
>>>>-	Issuing distribution point extension shall not contain
>>>>onlyContainsAuthorityCerts field set to TRUE; and
>>>>-	Issuing distribution point extension shall not contain
>>>>onlyContainsAttributeCerts field set to TRUE; and
>>>>-	If the reasonCodes field is present in the issuing distribution
>>>>point extension, the reasons code field shall include all the
>>>
>>reasons
>>
>>
>>>of
>>>
>>>
>>>>interest to the application; and
>>>>-	Issuing distribution point extension may or may not contain
>>>>indirectCRL field (hence, this field need not be checked)."
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Stefan Santesson [mailto:[email-masked]]
>>>>Sent: Wednesday, September 15, 2004 11:01 AM
>>>>To: Santosh Chokhani; [email-masked]
>>>>Subject: RE: CA Rekey and CRL Validation
>>>>
>>>>
>>>>Santosh,
>>>>
>>>>
>>>>
>>>>>[Since I have been involved in crafting portions of X.509 and
>>>>
>>since
>>
>>
>>>>Annex
>>>>
>>>>
>>>>>B
>>>>>that is normative makes this abundantly clear, I beg to differ
>>>>
>>that
>>
>>
>>>it
>>>
>>>
>>>>is
>>>>
>>>>
>>>>>not clear enough or authors of the text did not have this in mind.
>>>>
>>>>Any
>>>>
>>>>
>>>>>suggestion to make it clearer in X.509 are welcome.]
>>>>
>>>>
>>>>Well, since I'm talking to the expert :-)
>>>>
>>>>I would be very grateful if you could point me to the section in
>>>
>>Annex
>>
>>
>>>B
>>>
>>>
>>>>that makes this "abundantly clear".
>>>>
>>>>In fact, I would be even more grateful, to find the section that
>>>
>>deals
>>
>>
>>>>with CA generation management where it is clearly stated what the 
>>>>effect
>>>
>>>are
>>>
>>>
>>>>when
>>>>re-keying a CA with a new key but the same name. E.g. that this is
>>>
>>>still
>>>
>>>
>>>>part of the same CA and that all language that mention the concept
>>>
>>of
>>
>>
>>>a CA
>>>
>>>
>>>>or CRL issuer explicitly means all instances of that CA or CRL
>>>
>>issuer
>>
>>
>>>(for
>>>
>>>
>>>>all generations of issuing keys).
>>>>
>>>>All I have seen is text from which you can derive this truth. I have
>>>
>>>NOT
>>>
>>>
>>>>seen any text presented where this has been explicitly stated.
>>>>
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 10:50:13 -0400
Importance: Normal
Sender: [email-masked]

Thomas:

I agree with you.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, September 16, 2004 9:23 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: AW: CA Rekey and CRL Validation

Denis,

what do you mean with "a sequence of names" in case of a root CA?

What consequence will your remark have in case of a re-key of a CA? Is it
necessary to change the name or not?

In my understanding a CA has got a specific name, e. g. "Atos Origin
TrustCenter", and a coresponding DN, e. g. "C=DE, O= Atos Origin
TrustCenter". In my opinion it is no good idea of changing the name ervery
time I have a re-key.

Regards

Thomas Beckmann

> -----Ursprüngliche Nachricht-----
> Von: Denis Pinkas [mailto:[email-masked]]
> Gesendet: Donnerstag, 16. September 2004 14:25
> An: Santosh Chokhani
> Cc: [email-masked]
> Betreff: Re: CA Rekey and CRL Validation
> 
> 
> 
> Santosh,
> 
> See may response in-line with [Denis: ]
> 
> > Stefan:
> > 
> > See responses in-line.
> > 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]] On
> > Behalf Of Stefan Santesson
> > Sent: Thursday, September 16, 2004 4:38 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> > 
> > Yes I have noted that.
> > 
> > Still I think we can conclude then that there are no place
> in RFC 3280 or
> > X.509 where this is explicitly stated.
> > 
> > That is not what I call "crystal clear"
> > 
> > [In this mail thread, we first determined that a CA is
> defined by name only
> > and not be name+key.  We determined that both 3280 and
> X.509 are clear on
> > that.  If you want add this sentence explicitly, I do not
> have objections.]
> 
> [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].
> 
> > [In this mail thread, we then determined that standards are
> clear in that
> > absence of IDP means a CRL is complete for the CA.]
> 
> [Denis : I have difficulties to agree with this. There is a
> situation where 
> this is not the case. If the certificate includes a CRL DP 
> extension with 
> the field cRLIssuer present, then it means that the CRL 
> present at the 
> distributionPoint MUST be signed by that CRL Issuer. Then the 
> relying party 
> MUST find a certificate issued by the CA that has delivered 
> that certificate 
> which has the keyUsage bit 6 set (cRLSign) and which includes 
> the name of 
> this CRL issuer as the subject name. It MUST then verify that 
> the CRL which 
> has been found is indeed signed by the key included in that 
> certificate.
> 
> DistributionPoint is copied below:
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     
> DistributionPointName OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
> Absence of IDP does not necessarilly mean that it is a CRL is
> complete for 
> the CA.
> 
> Going back to RFC 3280, RFC 3280 is not sufficiently explicit
> about the ways 
> to find the right CRL, when the CRL issuer is different from 
> the CA. More 
> text would be needed to cover this aspect.
> 
> /Denis ]
> 
> > In the revision of RFC 3280 I would suggest adding a
> section that deals with
> > the aspects of CA re-keying and how that explicitly affects
> the use of the
> > standard and what it takes to achieve that. E.g. what
> certificates you need
> > to cover in a "full" CRL, that a re-keyed CA instance don't re-use 
> > certificate serial numbers from certificates issued by
> previous CA instances
> > etc.
> > 
> > [If you are using the same name and then reusing the serial
> numbers when
> > rekeying, you have a bigger problem than just revocation
> checking.  I hope
> > no product is doing that.]
> > 
> > CMP 4.4.1 tries to cover some of that ground but doesn't
> cover the aspects
> > above and is neither normative for X.509 or RFC 3280
> > 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >  
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked]
> > 
> > [mailto:[email-masked]]
> > 
> >>On Behalf Of Santosh Chokhani
> >>Sent: den 15 september 2004 19:03
> >>To: [email-masked]
> >>Subject: RE: CA Rekey and CRL Validation
> >>
> >>
> >>Stefan:
> >>
> >>That knows lies in several posting here where we have
> concluded that a
> > 
> > CA
> > 
> >>=
> >>Issuer Name and a CA != Issuer Name + Key
> >>
> >>-----Original Message-----
> >>From: Stefan Santesson [mailto:[email-masked]]
> >>Sent: Wednesday, September 15, 2004 12:56 PM
> >>To: Santosh Chokhani; [email-masked]
> >>Subject: RE: CA Rekey and CRL Validation
> >>
> >>
> >>Santosh,
> >>
> >>Thanks.
> >>
> >>I must conclude though that the term "crystal clear" has completely
> >>different meaning in our vocabularies :-)
> >>
> >>All this is clear IF you understand that "complete" means not only
> >>certificate issued under one CA key, but all certificates 
> issued under
> > 
> > all
> > 
> >>keys of that CA.
> >>
> >>But where do you gain that knowledge?
> >>THAT is what interests me.
> >>
> >>
> >>Stefan Santesson
> >>Microsoft Security Center of Excellence (SCOE)
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: [email-masked]
> >>
> >>[mailto:[email-masked]]
> >>
> >>>On Behalf Of Santosh Chokhani
> >>>Sent: den 15 september 2004 17:24
> >>>To: [email-masked]
> >>>Subject: RE: CA Rekey and CRL Validation
> >>>
> >>>
> >>>Stefan:
> >>>
> >>>See Section B.5.1.1 Complete CRL and I quote it below:
> >>>
> >>>"In order to determine that a CRL is a complete CRL for end-entity
> >>
> > and
> > 
> >>>CA-certificates, for all reason codes of interest, the following
> >>
> > shall
> > 
> >>be
> >>
> >>>true:
> >>>-	Delta CRL indicator extension shall be absent; and
> >>>-	Issuing distribution point extension may be present; and
> >>>-	Issuing distribution point extension shall not contain
> >>>distribution
> >>>point field; and
> >>>-	Issuing distribution point extension shall not contain
> >>>onlyContainsUserCerts field set to TRUE; and
> >>>-	Issuing distribution point extension shall not contain
> >>>onlyContainsAuthorityCerts field set to TRUE; and
> >>>-	Issuing distribution point extension shall not contain
> >>>onlyContainsAttributeCerts field set to TRUE; and
> >>>-	If the reasonCodes field is present in the issuing distribution
> >>>point extension, the reasons code field shall include all the
> >>
> > reasons
> > 
> >>of
> >>
> >>>interest to the application; and
> >>>-	Issuing distribution point extension may or may not contain
> >>>indirectCRL field (hence, this field need not be checked)."
> >>>
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Stefan Santesson [mailto:[email-masked]]
> >>>Sent: Wednesday, September 15, 2004 11:01 AM
> >>>To: Santosh Chokhani; [email-masked]
> >>>Subject: RE: CA Rekey and CRL Validation
> >>>
> >>>
> >>>Santosh,
> >>>
> >>>
> >>>>[Since I have been involved in crafting portions of X.509 and
> >>>
> > since
> > 
> >>>Annex
> >>>
> >>>>B
> >>>>that is normative makes this abundantly clear, I beg to differ
> >>>
> > that
> > 
> >>it
> >>
> >>>is
> >>>
> >>>>not clear enough or authors of the text did not have this in mind.
> >>>
> >>>Any
> >>>
> >>>>suggestion to make it clearer in X.509 are welcome.]
> >>>
> >>>
> >>>Well, since I'm talking to the expert :-)
> >>>
> >>>I would be very grateful if you could point me to the section in
> >>
> > Annex
> > 
> >>B
> >>
> >>>that makes this "abundantly clear".
> >>>
> >>>In fact, I would be even more grateful, to find the section that
> >>
> > deals
> > 
> >>>with CA generation management where it is clearly stated what the
> >>>effect
> >>
> >>are
> >>
> >>>when
> >>>re-keying a CA with a new key but the same name. E.g. that this is
> >>
> >>still
> >>
> >>>part of the same CA and that all language that mention the concept
> >>
> > of
> > 
> >>a CA
> >>
> >>>or CRL issuer explicitly means all instances of that CA or CRL
> >>
> > issuer
> > 
> >>(for
> >>
> >>>all generations of issuing keys).
> >>>
> >>>All I have seen is text from which you can derive this
> truth. I have
> >>
> >>NOT
> >>
> >>>seen any text presented where this has been explicitly stated.
> >>>
> >>>
> >>>Stefan Santesson
> >>>Microsoft Security Center of Excellence (SCOE)
> >>>
> >>>
> >>>
> >>>
> >>
> > 
> > 
> > 
> 
> 

From: "Laudon Williams" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 07:11:28 -0700
Sender: [email-masked]

Inline...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Thursday, September 16, 2004 4:04 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

[In this mail thread, we first determined that a CA is defined by name only
and not be name+key.  We determined that both 3280 and X.509 are clear on
that.  If you want add this sentence explicitly, I do not have objections.]

[LW] Actually, this was stated, but I'm not so sure everyone agrees to this
point. I think we can all agree that difference in opinion on this
fundamental can lead to significantly different interpretations of the
standards. I would say that something this critical to should be as explicit
as possible.

[In this mail thread, we then determined that standards are clear in that
absence of IDP means a CRL is complete for the CA.] 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: AW: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 10:09:29 -0400
Importance: Normal
Sender: [email-masked]

Denis:

With the rules for certificate and CRL certification paths match, we are
trying to ensure that uniqueness of the CA name along the lines you
suggested.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, September 16, 2004 9:40 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: AW: CA Rekey and CRL Validation

Thomas,

> Denis,

> what do you mean with "a sequence of names" in case of a root CA?

This is not what I wrote. I wrote: "a root key with a sequence of names".

The name "C=DE, O= Atos Origin TrustCenter" does not identify the ATos 
Origin Trust Center you are thinking of, unless you also provide all the 
upper CA names and the root key that has certified the first name of the 
certification chain.

> What consequence will your remark have in case of a re-key of a CA?

 > Is it necessary to change the name or not?

Unless your question is rephrased to be more specific, I am not sure I 
understand your question, since it is out of context.

> In my understanding a CA has got a specific name, e. g. "Atos Origin 
> TrustCenter", and a coresponding DN, e. g. "C=DE, O= Atos Origin 
> TrustCenter". In my opinion it is no good idea of changing the name 
> ervery time I have a re-key.

When there is a new key for a CA, it is not necessary to change the CA name.

However, when a root key changes, the story is more complicated and the 
scenario is not explained at all from a relying party point of view in RFC 
3280. Several pages, based on different trust assumptions, would be 
necessary to explain it.

Denis.

> Regards
> 
> Thomas Beckmann
> 
> 
>>-----Ursprüngliche Nachricht-----
>>Von: Denis Pinkas [mailto:[email-masked]]
>>Gesendet: Donnerstag, 16. September 2004 14:25
>>An: Santosh Chokhani
>>Cc: [email-masked]
>>Betreff: Re: CA Rekey and CRL Validation
>>
>>
>>
>>Santosh,
>>
>>See may response in-line with [Denis: ]
>>
>>
>>>Stefan:
>>>
>>>See responses in-line.
>>>
>>>-----Original Message-----
>>>From: [email-masked]
>>
>>[mailto:[email-masked]] On
>>
>>>Behalf Of Stefan Santesson
>>>Sent: Thursday, September 16, 2004 4:38 AM
>>>To: Santosh Chokhani; [email-masked]
>>>Subject: RE: CA Rekey and CRL Validation
>>>
>>>Yes I have noted that.
>>>
>>>Still I think we can conclude then that there are no place
>>
>>in RFC 3280 or
>>
>>>X.509 where this is explicitly stated.
>>>
>>>That is not what I call "crystal clear"
>>>
>>>[In this mail thread, we first determined that a CA is
>>
>>defined by name only
>>
>>>and not be name+key.  We determined that both 3280 and
>>
>>X.509 are clear on
>>
>>>that.  If you want add this sentence explicitly, I do not
>>
>>have objections.]
>>
>>[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].
>>
>>
>>>[In this mail thread, we then determined that standards are
>>
>>clear in that
>>
>>>absence of IDP means a CRL is complete for the CA.]
>>
>>[Denis : I have difficulties to agree with this. There is a
>>situation where 
>>this is not the case. If the certificate includes a CRL DP 
>>extension with 
>>the field cRLIssuer present, then it means that the CRL 
>>present at the 
>>distributionPoint MUST be signed by that CRL Issuer. Then the 
>>relying party 
>>MUST find a certificate issued by the CA that has delivered 
>>that certificate 
>>which has the keyUsage bit 6 set (cRLSign) and which includes 
>>the name of 
>>this CRL issuer as the subject name. It MUST then verify that 
>>the CRL which 
>>has been found is indeed signed by the key included in that 
>>certificate.
>>
>>DistributionPoint is copied below:
>>
>>    DistributionPoint ::= SEQUENCE {
>>         distributionPoint       [0]     
>>DistributionPointName OPTIONAL,
>>         reasons                 [1]     ReasonFlags OPTIONAL,
>>         cRLIssuer               [2]     GeneralNames OPTIONAL }
>>
>>Absence of IDP does not necessarilly mean that it is a CRL is
>>complete for 
>>the CA.
>>
>>Going back to RFC 3280, RFC 3280 is not sufficiently explicit
>>about the ways 
>>to find the right CRL, when the CRL issuer is different from 
>>the CA. More 
>>text would be needed to cover this aspect.
>>
>>/Denis ]
>>
>>
>>>In the revision of RFC 3280 I would suggest adding a
>>
>>section that deals with
>>
>>>the aspects of CA re-keying and how that explicitly affects
>>
>>the use of the
>>
>>>standard and what it takes to achieve that. E.g. what
>>
>>certificates you need
>>
>>>to cover in a "full" CRL, that a re-keyed CA instance don't re-use 
>>>certificate serial numbers from certificates issued by
>>
>>previous CA instances
>>
>>>etc.
>>>
>>>[If you are using the same name and then reusing the serial
>>
>>numbers when
>>
>>>rekeying, you have a bigger problem than just revocation
>>
>>checking.  I hope
>>
>>>no product is doing that.]
>>>
>>>CMP 4.4.1 tries to cover some of that ground but doesn't
>>
>>cover the aspects
>>
>>>above and is neither normative for X.509 or RFC 3280
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>> 
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [email-masked]
>>>
>>>[mailto:[email-masked]]
>>>
>>>
>>>>On Behalf Of Santosh Chokhani
>>>>Sent: den 15 september 2004 19:03
>>>>To: [email-masked]
>>>>Subject: RE: CA Rekey and CRL Validation
>>>>
>>>>
>>>>Stefan:
>>>>
>>>>That knows lies in several posting here where we have
>>>
>>concluded that a
>>
>>>CA
>>>
>>>
>>>>=
>>>>Issuer Name and a CA != Issuer Name + Key
>>>>
>>>>-----Original Message-----
>>>>From: Stefan Santesson [mailto:[email-masked]]
>>>>Sent: Wednesday, September 15, 2004 12:56 PM
>>>>To: Santosh Chokhani; [email-masked]
>>>>Subject: RE: CA Rekey and CRL Validation
>>>>
>>>>
>>>>Santosh,
>>>>
>>>>Thanks.
>>>>
>>>>I must conclude though that the term "crystal clear" has completely
>>>>different meaning in our vocabularies :-)
>>>>
>>>>All this is clear IF you understand that "complete" means not only
>>>>certificate issued under one CA key, but all certificates 
>>>
>>issued under
>>
>>>all
>>>
>>>
>>>>keys of that CA.
>>>>
>>>>But where do you gain that knowledge?
>>>>THAT is what interests me.
>>>>
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [email-masked]
>>>>
>>>>[mailto:[email-masked]]
>>>>
>>>>
>>>>>On Behalf Of Santosh Chokhani
>>>>>Sent: den 15 september 2004 17:24
>>>>>To: [email-masked]
>>>>>Subject: RE: CA Rekey and CRL Validation
>>>>>
>>>>>
>>>>>Stefan:
>>>>>
>>>>>See Section B.5.1.1 Complete CRL and I quote it below:
>>>>>
>>>>>"In order to determine that a CRL is a complete CRL for end-entity
>>>>
>>>and
>>>
>>>
>>>>>CA-certificates, for all reason codes of interest, the following
>>>>
>>>shall
>>>
>>>
>>>>be
>>>>
>>>>
>>>>>true:
>>>>>-	Delta CRL indicator extension shall be absent; and
>>>>>-	Issuing distribution point extension may be present; and
>>>>>-	Issuing distribution point extension shall not contain
>>>>>distribution
>>>>>point field; and
>>>>>-	Issuing distribution point extension shall not contain
>>>>>onlyContainsUserCerts field set to TRUE; and
>>>>>-	Issuing distribution point extension shall not contain
>>>>>onlyContainsAuthorityCerts field set to TRUE; and
>>>>>-	Issuing distribution point extension shall not contain
>>>>>onlyContainsAttributeCerts field set to TRUE; and
>>>>>-	If the reasonCodes field is present in the issuing distribution
>>>>>point extension, the reasons code field shall include all the
>>>>
>>>reasons
>>>
>>>
>>>>of
>>>>
>>>>
>>>>>interest to the application; and
>>>>>-	Issuing distribution point extension may or may not contain
>>>>>indirectCRL field (hence, this field need not be checked)."
>>>>>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: Stefan Santesson [mailto:[email-masked]]
>>>>>Sent: Wednesday, September 15, 2004 11:01 AM
>>>>>To: Santosh Chokhani; [email-masked]
>>>>>Subject: RE: CA Rekey and CRL Validation
>>>>>
>>>>>
>>>>>Santosh,
>>>>>
>>>>>
>>>>>
>>>>>>[Since I have been involved in crafting portions of X.509 and
>>>>>
>>>since
>>>
>>>
>>>>>Annex
>>>>>
>>>>>
>>>>>>B
>>>>>>that is normative makes this abundantly clear, I beg to differ
>>>>>
>>>that
>>>
>>>
>>>>it
>>>>
>>>>
>>>>>is
>>>>>
>>>>>
>>>>>>not clear enough or authors of the text did not have this in mind.
>>>>>
>>>>>Any
>>>>>
>>>>>
>>>>>>suggestion to make it clearer in X.509 are welcome.]
>>>>>
>>>>>
>>>>>Well, since I'm talking to the expert :-)
>>>>>
>>>>>I would be very grateful if you could point me to the section in
>>>>
>>>Annex
>>>
>>>
>>>>B
>>>>
>>>>
>>>>>that makes this "abundantly clear".
>>>>>
>>>>>In fact, I would be even more grateful, to find the section that
>>>>
>>>deals
>>>
>>>
>>>>>with CA generation management where it is clearly stated what the
>>>>>effect
>>>>
>>>>are
>>>>
>>>>
>>>>>when
>>>>>re-keying a CA with a new key but the same name. E.g. that this is
>>>>
>>>>still
>>>>
>>>>
>>>>>part of the same CA and that all language that mention the concept
>>>>
>>>of
>>>
>>>
>>>>a CA
>>>>
>>>>
>>>>>or CRL issuer explicitly means all instances of that CA or CRL
>>>>
>>>issuer
>>>
>>>
>>>>(for
>>>>
>>>>
>>>>>all generations of issuing keys).
>>>>>
>>>>>All I have seen is text from which you can derive this
>>>>
>>truth. I have
>>
>>>>NOT
>>>>
>>>>
>>>>>seen any text presented where this has been explicitly stated.
>>>>>
>>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 09:49:00 -0400
Importance: Normal
Sender: [email-masked]

Denis:

You should also see Section 8.6.2.2 of X.509 describing IDP.  Examine the
last sentence and I quote the section below.

Issuing distribution point extension
This CRL extension field identifies the CRL distribution point for this
particular CRL, and indicates if the CRL is limited to revocations for
end-entity certificates only, for authority certificates only, or for a
limited set of reasons only. The CRL is signed by the CRL issuer's key - CRL
distribution points do not have their own key pairs. However, for a CRL
distributed via the Directory, the CRL is stored in the entry of the CRL
distribution point, which may not be the directory entry of the CRL issuer.
If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the CRL issuer.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Thursday, September 16, 2004 9:26 AM
To: [email-masked]'
Subject: RE: CA Rekey and CRL Validation

Denis:

Please see responses with [Santosh:]

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, September 16, 2004 8:25 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

See may response in-line with [Denis: ]

> Stefan:
> 
> See responses in-line.
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: Thursday, September 16, 2004 4:38 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> Yes I have noted that.
> 
> Still I think we can conclude then that there are no place in RFC 3280
> or X.509 where this is explicitly stated.
> 
> That is not what I call "crystal clear"
> 
> [In this mail thread, we first determined that a CA is defined by name
> only and not be name+key.  We determined that both 3280 and X.509 are 
> clear on that.  If you want add this sentence explicitly, I do not 
> have objections.]

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

> [In this mail thread, we then determined that standards are clear in
> that absence of IDP means a CRL is complete for the CA.]

[Denis : I have difficulties to agree with this. There is a situation where 
this is not the case. If the certificate includes a CRL DP extension with 
the field cRLIssuer present, then it means that the CRL present at the 
distributionPoint MUST be signed by that CRL Issuer. Then the relying party 
MUST find a certificate issued by the CA that has delivered that certificate

which has the keyUsage bit 6 set (cRLSign) and which includes the name of 
this CRL issuer as the subject name. It MUST then verify that the CRL which 
has been found is indeed signed by the key included in that certificate.

DistributionPoint is copied below:

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

Absence of IDP does not necessarilly mean that it is a CRL is complete for 
the CA.

[Santosh: We are talking about IDP in CRL and not CRL DP in certificate.
Please look at Carl Wallace posting pointing to a section in 3280 in this
thread and my posting pointing to Section B.5.1.1 of X.509]

Going back to RFC 3280, RFC 3280 is not sufficiently explicit about the ways

to find the right CRL, when the CRL issuer is different from the CA. More 
text would be needed to cover this aspect.

[Santosh: We are not discussing how to find a CRL.  We are discussing how to
determine if the CRL you have is appropriate.]

/Denis ]

> In the revision of RFC 3280 I would suggest adding a section that
> deals with the aspects of CA re-keying and how that explicitly affects 
> the use of the standard and what it takes to achieve that. E.g. what 
> certificates you need to cover in a "full" CRL, that a re-keyed CA 
> instance don't re-use certificate serial numbers from certificates 
> issued by previous CA instances etc.
> 
> [If you are using the same name and then reusing the serial numbers
> when rekeying, you have a bigger problem than just revocation 
> checking.  I hope no product is doing that.]
> 
> CMP 4.4.1 tries to cover some of that ground but doesn't cover the
> aspects above and is neither normative for X.509 or RFC 3280
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Santosh Chokhani
>>Sent: den 15 september 2004 19:03
>>To: [email-masked]
>>Subject: RE: CA Rekey and CRL Validation
>>
>>
>>Stefan:
>>
>>That knows lies in several posting here where we have concluded that a
> 
> CA
> 
>>=
>>Issuer Name and a CA != Issuer Name + Key
>>
>>-----Original Message-----
>>From: Stefan Santesson [mailto:[email-masked]]
>>Sent: Wednesday, September 15, 2004 12:56 PM
>>To: Santosh Chokhani; [email-masked]
>>Subject: RE: CA Rekey and CRL Validation
>>
>>
>>Santosh,
>>
>>Thanks.
>>
>>I must conclude though that the term "crystal clear" has completely 
>>different meaning in our vocabularies :-)
>>
>>All this is clear IF you understand that "complete" means not only 
>>certificate issued under one CA key, but all certificates issued under
> 
> all
> 
>>keys of that CA.
>>
>>But where do you gain that knowledge?
>>THAT is what interests me.
>>
>>
>>Stefan Santesson
>>Microsoft Security Center of Excellence (SCOE)
>>
>>
>>
>>>-----Original Message-----
>>>From: [email-masked]
>>
>>[mailto:[email-masked]]
>>
>>>On Behalf Of Santosh Chokhani
>>>Sent: den 15 september 2004 17:24
>>>To: [email-masked]
>>>Subject: RE: CA Rekey and CRL Validation
>>>
>>>
>>>Stefan:
>>>
>>>See Section B.5.1.1 Complete CRL and I quote it below:
>>>
>>>"In order to determine that a CRL is a complete CRL for end-entity
>>
> and
> 
>>>CA-certificates, for all reason codes of interest, the following
>>
> shall
> 
>>be
>>
>>>true:
>>>-	Delta CRL indicator extension shall be absent; and
>>>-	Issuing distribution point extension may be present; and
>>>-	Issuing distribution point extension shall not contain
>>>distribution
>>>point field; and
>>>-	Issuing distribution point extension shall not contain
>>>onlyContainsUserCerts field set to TRUE; and
>>>-	Issuing distribution point extension shall not contain
>>>onlyContainsAuthorityCerts field set to TRUE; and
>>>-	Issuing distribution point extension shall not contain
>>>onlyContainsAttributeCerts field set to TRUE; and
>>>-	If the reasonCodes field is present in the issuing distribution
>>>point extension, the reasons code field shall include all the
>>
> reasons
> 
>>of
>>
>>>interest to the application; and
>>>-	Issuing distribution point extension may or may not contain
>>>indirectCRL field (hence, this field need not be checked)."
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Stefan Santesson [mailto:[email-masked]]
>>>Sent: Wednesday, September 15, 2004 11:01 AM
>>>To: Santosh Chokhani; [email-masked]
>>>Subject: RE: CA Rekey and CRL Validation
>>>
>>>
>>>Santosh,
>>>
>>>
>>>>[Since I have been involved in crafting portions of X.509 and
>>>
> since
> 
>>>Annex
>>>
>>>>B
>>>>that is normative makes this abundantly clear, I beg to differ
>>>
> that
> 
>>it
>>
>>>is
>>>
>>>>not clear enough or authors of the text did not have this in mind.
>>>
>>>Any
>>>
>>>>suggestion to make it clearer in X.509 are welcome.]
>>>
>>>
>>>Well, since I'm talking to the expert :-)
>>>
>>>I would be very grateful if you could point me to the section in
>>
> Annex
> 
>>B
>>
>>>that makes this "abundantly clear".
>>>
>>>In fact, I would be even more grateful, to find the section that
>>
> deals
> 
>>>with CA generation management where it is clearly stated what the 
>>>effect
>>
>>are
>>
>>>when
>>>re-keying a CA with a new key but the same name. E.g. that this is
>>
>>still
>>
>>>part of the same CA and that all language that mention the concept
>>
> of
> 
>>a CA
>>
>>>or CRL issuer explicitly means all instances of that CA or CRL
>>
> issuer
> 
>>(for
>>
>>>all generations of issuing keys).
>>>
>>>All I have seen is text from which you can derive this truth. I have
>>
>>NOT
>>
>>>seen any text presented where this has been explicitly stated.
>>>
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>
> 
> 
> 

Date: Thu, 16 Sep 2004 15:40:29 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: AW: CA Rekey and CRL Validation
Sender: [email-masked]

Thomas,

> Denis,

> what do you mean with "a sequence of names" in case of a root CA?

This is not what I wrote. I wrote: "a root key with a sequence of names".

The name "C=DE, O= Atos Origin TrustCenter" does not identify the ATos 
Origin Trust Center you are thinking of, unless you also provide all the 
upper CA names and the root key that has certified the first name of the 
certification chain.

> What consequence will your remark have in case of a re-key of a CA? 

 > Is it necessary to change the name or not?

Unless your question is rephrased to be more specific, I am not sure I 
understand your question, since it is out of context.

> In my understanding a CA has got a specific name, e. g. "Atos Origin
> TrustCenter", and a coresponding DN, e. g. "C=DE, O= Atos Origin
> TrustCenter". In my opinion it is no good idea of changing the name ervery
> time I have a re-key.

When there is a new key for a CA, it is not necessary to change the CA name. 
However, when a root key changes, the story is more complicated and the 
scenario is not explained at all from a relying party point of view in RFC 
3280. Several pages, based on different trust assumptions, would be 
necessary to explain it.

Denis.

> Regards
> 
> Thomas Beckmann
> 
> 
>>-----Ursprüngliche Nachricht-----
>>Von: Denis Pinkas [mailto:[email-masked]]
>>Gesendet: Donnerstag, 16. September 2004 14:25
>>An: Santosh Chokhani
>>Cc: [email-masked]
>>Betreff: Re: CA Rekey and CRL Validation
>>
>>
>>
>>Santosh,
>>
>>See may response in-line with [Denis: ]
>>
>>
>>>Stefan:
>>>
>>>See responses in-line.
>>>
>>>-----Original Message-----
>>>From: [email-masked] 
>>
>>[mailto:[email-masked]] On
>>
>>>Behalf Of Stefan Santesson
>>>Sent: Thursday, September 16, 2004 4:38 AM
>>>To: Santosh Chokhani; [email-masked]
>>>Subject: RE: CA Rekey and CRL Validation
>>>
>>>Yes I have noted that.
>>>
>>>Still I think we can conclude then that there are no place 
>>
>>in RFC 3280 or
>>
>>>X.509 where this is explicitly stated.
>>>
>>>That is not what I call "crystal clear"
>>>
>>>[In this mail thread, we first determined that a CA is 
>>
>>defined by name only
>>
>>>and not be name+key.  We determined that both 3280 and 
>>
>>X.509 are clear on
>>
>>>that.  If you want add this sentence explicitly, I do not 
>>
>>have objections.]
>>
>>[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].
>>
>>
>>>[In this mail thread, we then determined that standards are 
>>
>>clear in that
>>
>>>absence of IDP means a CRL is complete for the CA.] 
>>
>>[Denis : I have difficulties to agree with this. There is a 
>>situation where 
>>this is not the case. If the certificate includes a CRL DP 
>>extension with 
>>the field cRLIssuer present, then it means that the CRL 
>>present at the 
>>distributionPoint MUST be signed by that CRL Issuer. Then the 
>>relying party 
>>MUST find a certificate issued by the CA that has delivered 
>>that certificate 
>>which has the keyUsage bit 6 set (cRLSign) and which includes 
>>the name of 
>>this CRL issuer as the subject name. It MUST then verify that 
>>the CRL which 
>>has been found is indeed signed by the key included in that 
>>certificate.
>>
>>DistributionPoint is copied below:
>>
>>    DistributionPoint ::= SEQUENCE {
>>         distributionPoint       [0]     
>>DistributionPointName OPTIONAL,
>>         reasons                 [1]     ReasonFlags OPTIONAL,
>>         cRLIssuer               [2]     GeneralNames OPTIONAL }
>>
>>Absence of IDP does not necessarilly mean that it is a CRL is 
>>complete for 
>>the CA.
>>
>>Going back to RFC 3280, RFC 3280 is not sufficiently explicit 
>>about the ways 
>>to find the right CRL, when the CRL issuer is different from 
>>the CA. More 
>>text would be needed to cover this aspect.
>>
>>/Denis ]
>>
>>
>>>In the revision of RFC 3280 I would suggest adding a 
>>
>>section that deals with
>>
>>>the aspects of CA re-keying and how that explicitly affects 
>>
>>the use of the
>>
>>>standard and what it takes to achieve that. E.g. what 
>>
>>certificates you need
>>
>>>to cover in a "full" CRL, that a re-keyed CA instance don't re-use
>>>certificate serial numbers from certificates issued by 
>>
>>previous CA instances
>>
>>>etc.
>>>
>>>[If you are using the same name and then reusing the serial 
>>
>>numbers when
>>
>>>rekeying, you have a bigger problem than just revocation 
>>
>>checking.  I hope
>>
>>>no product is doing that.]
>>>
>>>CMP 4.4.1 tries to cover some of that ground but doesn't 
>>
>>cover the aspects
>>
>>>above and is neither normative for X.509 or RFC 3280
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>> 
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [email-masked]
>>>
>>>[mailto:[email-masked]]
>>>
>>>
>>>>On Behalf Of Santosh Chokhani
>>>>Sent: den 15 september 2004 19:03
>>>>To: [email-masked]
>>>>Subject: RE: CA Rekey and CRL Validation
>>>>
>>>>
>>>>Stefan:
>>>>
>>>>That knows lies in several posting here where we have 
>>>
>>concluded that a
>>
>>>CA
>>>
>>>
>>>>=
>>>>Issuer Name and a CA != Issuer Name + Key
>>>>
>>>>-----Original Message-----
>>>>From: Stefan Santesson [mailto:[email-masked]]
>>>>Sent: Wednesday, September 15, 2004 12:56 PM
>>>>To: Santosh Chokhani; [email-masked]
>>>>Subject: RE: CA Rekey and CRL Validation
>>>>
>>>>
>>>>Santosh,
>>>>
>>>>Thanks.
>>>>
>>>>I must conclude though that the term "crystal clear" has completely 
>>>>different meaning in our vocabularies :-)
>>>>
>>>>All this is clear IF you understand that "complete" means not only 
>>>>certificate issued under one CA key, but all certificates 
>>>
>>issued under
>>
>>>all
>>>
>>>
>>>>keys of that CA.
>>>>
>>>>But where do you gain that knowledge?
>>>>THAT is what interests me.
>>>>
>>>>
>>>>Stefan Santesson
>>>>Microsoft Security Center of Excellence (SCOE)
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: [email-masked]
>>>>
>>>>[mailto:[email-masked]]
>>>>
>>>>
>>>>>On Behalf Of Santosh Chokhani
>>>>>Sent: den 15 september 2004 17:24
>>>>>To: [email-masked]
>>>>>Subject: RE: CA Rekey and CRL Validation
>>>>>
>>>>>
>>>>>Stefan:
>>>>>
>>>>>See Section B.5.1.1 Complete CRL and I quote it below:
>>>>>
>>>>>"In order to determine that a CRL is a complete CRL for end-entity
>>>>
>>>and
>>>
>>>
>>>>>CA-certificates, for all reason codes of interest, the following
>>>>
>>>shall
>>>
>>>
>>>>be
>>>>
>>>>
>>>>>true:
>>>>>-	Delta CRL indicator extension shall be absent; and
>>>>>-	Issuing distribution point extension may be present; and
>>>>>-	Issuing distribution point extension shall not contain
>>>>>distribution
>>>>>point field; and
>>>>>-	Issuing distribution point extension shall not contain
>>>>>onlyContainsUserCerts field set to TRUE; and
>>>>>-	Issuing distribution point extension shall not contain
>>>>>onlyContainsAuthorityCerts field set to TRUE; and
>>>>>-	Issuing distribution point extension shall not contain
>>>>>onlyContainsAttributeCerts field set to TRUE; and
>>>>>-	If the reasonCodes field is present in the issuing distribution
>>>>>point extension, the reasons code field shall include all the
>>>>
>>>reasons
>>>
>>>
>>>>of
>>>>
>>>>
>>>>>interest to the application; and
>>>>>-	Issuing distribution point extension may or may not contain
>>>>>indirectCRL field (hence, this field need not be checked)."
>>>>>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: Stefan Santesson [mailto:[email-masked]]
>>>>>Sent: Wednesday, September 15, 2004 11:01 AM
>>>>>To: Santosh Chokhani; [email-masked]
>>>>>Subject: RE: CA Rekey and CRL Validation
>>>>>
>>>>>
>>>>>Santosh,
>>>>>
>>>>>
>>>>>
>>>>>>[Since I have been involved in crafting portions of X.509 and
>>>>>
>>>since
>>>
>>>
>>>>>Annex
>>>>>
>>>>>
>>>>>>B
>>>>>>that is normative makes this abundantly clear, I beg to differ
>>>>>
>>>that
>>>
>>>
>>>>it
>>>>
>>>>
>>>>>is
>>>>>
>>>>>
>>>>>>not clear enough or authors of the text did not have this in mind.
>>>>>
>>>>>Any
>>>>>
>>>>>
>>>>>>suggestion to make it clearer in X.509 are welcome.]
>>>>>
>>>>>
>>>>>Well, since I'm talking to the expert :-)
>>>>>
>>>>>I would be very grateful if you could point me to the section in
>>>>
>>>Annex
>>>
>>>
>>>>B
>>>>
>>>>
>>>>>that makes this "abundantly clear".
>>>>>
>>>>>In fact, I would be even more grateful, to find the section that
>>>>
>>>deals
>>>
>>>
>>>>>with CA generation management where it is clearly stated what the 
>>>>>effect
>>>>
>>>>are
>>>>
>>>>
>>>>>when
>>>>>re-keying a CA with a new key but the same name. E.g. that this is
>>>>
>>>>still
>>>>
>>>>
>>>>>part of the same CA and that all language that mention the concept
>>>>
>>>of
>>>
>>>
>>>>a CA
>>>>
>>>>
>>>>>or CRL issuer explicitly means all instances of that CA or CRL
>>>>
>>>issuer
>>>
>>>
>>>>(for
>>>>
>>>>
>>>>>all generations of issuing keys).
>>>>>
>>>>>All I have seen is text from which you can derive this 
>>>>
>>truth. I have
>>
>>>>NOT
>>>>
>>>>
>>>>>seen any text presented where this has been explicitly stated.
>>>>>
>>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 09:26:13 -0400
Importance: Normal
Sender: [email-masked]

Denis:

Please see responses with [Santosh:]

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, September 16, 2004 8:25 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

See may response in-line with [Denis: ]

> Stefan:
> 
> See responses in-line.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: Thursday, September 16, 2004 4:38 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> Yes I have noted that.
> 
> Still I think we can conclude then that there are no place in RFC 3280 
> or X.509 where this is explicitly stated.
> 
> That is not what I call "crystal clear"
> 
> [In this mail thread, we first determined that a CA is defined by name 
> only and not be name+key.  We determined that both 3280 and X.509 are 
> clear on that.  If you want add this sentence explicitly, I do not 
> have objections.]

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

> [In this mail thread, we then determined that standards are clear in 
> that absence of IDP means a CRL is complete for the CA.]

[Denis : I have difficulties to agree with this. There is a situation where 
this is not the case. If the certificate includes a CRL DP extension with 
the field cRLIssuer present, then it means that the CRL present at the 
distributionPoint MUST be signed by that CRL Issuer. Then the relying party 
MUST find a certificate issued by the CA that has delivered that certificate

which has the keyUsage bit 6 set (cRLSign) and which includes the name of 
this CRL issuer as the subject name. It MUST then verify that the CRL which 
has been found is indeed signed by the key included in that certificate.

DistributionPoint is copied below:

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

Absence of IDP does not necessarilly mean that it is a CRL is complete for 
the CA.

[Santosh: We are talking about IDP in CRL and not CRL DP in certificate.
Please look at Carl Wallace posting pointing to a section in 3280 in this
thread and my posting pointing to Section B.5.1.1 of X.509]

Going back to RFC 3280, RFC 3280 is not sufficiently explicit about the ways

to find the right CRL, when the CRL issuer is different from the CA. More 
text would be needed to cover this aspect.

[Santosh: We are not discussing how to find a CRL.  We are discussing how to
determine if the CRL you have is appropriate.]

/Denis ]

> In the revision of RFC 3280 I would suggest adding a section that 
> deals with the aspects of CA re-keying and how that explicitly affects 
> the use of the standard and what it takes to achieve that. E.g. what 
> certificates you need to cover in a "full" CRL, that a re-keyed CA 
> instance don't re-use certificate serial numbers from certificates 
> issued by previous CA instances etc.
> 
> [If you are using the same name and then reusing the serial numbers 
> when rekeying, you have a bigger problem than just revocation 
> checking.  I hope no product is doing that.]
> 
> CMP 4.4.1 tries to cover some of that ground but doesn't cover the 
> aspects above and is neither normative for X.509 or RFC 3280
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Santosh Chokhani
>>Sent: den 15 september 2004 19:03
>>To: [email-masked]
>>Subject: RE: CA Rekey and CRL Validation
>>
>>
>>Stefan:
>>
>>That knows lies in several posting here where we have concluded that a
> 
> CA
> 
>>=
>>Issuer Name and a CA != Issuer Name + Key
>>
>>-----Original Message-----
>>From: Stefan Santesson [mailto:[email-masked]]
>>Sent: Wednesday, September 15, 2004 12:56 PM
>>To: Santosh Chokhani; [email-masked]
>>Subject: RE: CA Rekey and CRL Validation
>>
>>
>>Santosh,
>>
>>Thanks.
>>
>>I must conclude though that the term "crystal clear" has completely
>>different meaning in our vocabularies :-)
>>
>>All this is clear IF you understand that "complete" means not only
>>certificate issued under one CA key, but all certificates issued under
> 
> all
> 
>>keys of that CA.
>>
>>But where do you gain that knowledge?
>>THAT is what interests me.
>>
>>
>>Stefan Santesson
>>Microsoft Security Center of Excellence (SCOE)
>>
>>
>>
>>>-----Original Message-----
>>>From: [email-masked]
>>
>>[mailto:[email-masked]]
>>
>>>On Behalf Of Santosh Chokhani
>>>Sent: den 15 september 2004 17:24
>>>To: [email-masked]
>>>Subject: RE: CA Rekey and CRL Validation
>>>
>>>
>>>Stefan:
>>>
>>>See Section B.5.1.1 Complete CRL and I quote it below:
>>>
>>>"In order to determine that a CRL is a complete CRL for end-entity
>>
> and
> 
>>>CA-certificates, for all reason codes of interest, the following
>>
> shall
> 
>>be
>>
>>>true:
>>>-	Delta CRL indicator extension shall be absent; and
>>>-	Issuing distribution point extension may be present; and
>>>-	Issuing distribution point extension shall not contain
>>>distribution
>>>point field; and
>>>-	Issuing distribution point extension shall not contain
>>>onlyContainsUserCerts field set to TRUE; and
>>>-	Issuing distribution point extension shall not contain
>>>onlyContainsAuthorityCerts field set to TRUE; and
>>>-	Issuing distribution point extension shall not contain
>>>onlyContainsAttributeCerts field set to TRUE; and
>>>-	If the reasonCodes field is present in the issuing distribution
>>>point extension, the reasons code field shall include all the
>>
> reasons
> 
>>of
>>
>>>interest to the application; and
>>>-	Issuing distribution point extension may or may not contain
>>>indirectCRL field (hence, this field need not be checked)."
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Stefan Santesson [mailto:[email-masked]]
>>>Sent: Wednesday, September 15, 2004 11:01 AM
>>>To: Santosh Chokhani; [email-masked]
>>>Subject: RE: CA Rekey and CRL Validation
>>>
>>>
>>>Santosh,
>>>
>>>
>>>>[Since I have been involved in crafting portions of X.509 and
>>>
> since
> 
>>>Annex
>>>
>>>>B
>>>>that is normative makes this abundantly clear, I beg to differ
>>>
> that
> 
>>it
>>
>>>is
>>>
>>>>not clear enough or authors of the text did not have this in mind.
>>>
>>>Any
>>>
>>>>suggestion to make it clearer in X.509 are welcome.]
>>>
>>>
>>>Well, since I'm talking to the expert :-)
>>>
>>>I would be very grateful if you could point me to the section in
>>
> Annex
> 
>>B
>>
>>>that makes this "abundantly clear".
>>>
>>>In fact, I would be even more grateful, to find the section that
>>
> deals
> 
>>>with CA generation management where it is clearly stated what the
>>>effect
>>
>>are
>>
>>>when
>>>re-keying a CA with a new key but the same name. E.g. that this is
>>
>>still
>>
>>>part of the same CA and that all language that mention the concept
>>
> of
> 
>>a CA
>>
>>>or CRL issuer explicitly means all instances of that CA or CRL
>>
> issuer
> 
>>(for
>>
>>>all generations of issuing keys).
>>>
>>>All I have seen is text from which you can derive this truth. I have
>>
>>NOT
>>
>>>seen any text presented where this has been explicitly stated.
>>>
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>
> 
> 
> 

From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: AW: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 15:22:44 +0200
Sender: [email-masked]

Denis,

what do you mean with "a sequence of names" in case of a root CA?

What consequence will your remark have in case of a re-key of a CA? Is it
necessary to change the name or not?

In my understanding a CA has got a specific name, e. g. "Atos Origin
TrustCenter", and a coresponding DN, e. g. "C=DE, O= Atos Origin
TrustCenter". In my opinion it is no good idea of changing the name ervery
time I have a re-key.

Regards

Thomas Beckmann

> -----Ursprüngliche Nachricht-----
> Von: Denis Pinkas [mailto:[email-masked]]
> Gesendet: Donnerstag, 16. September 2004 14:25
> An: Santosh Chokhani
> Cc: [email-masked]
> Betreff: Re: CA Rekey and CRL Validation
> 
> 
> 
> Santosh,
> 
> See may response in-line with [Denis: ]
> 
> > Stefan:
> > 
> > See responses in-line.
> > 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On
> > Behalf Of Stefan Santesson
> > Sent: Thursday, September 16, 2004 4:38 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> > 
> > Yes I have noted that.
> > 
> > Still I think we can conclude then that there are no place 
> in RFC 3280 or
> > X.509 where this is explicitly stated.
> > 
> > That is not what I call "crystal clear"
> > 
> > [In this mail thread, we first determined that a CA is 
> defined by name only
> > and not be name+key.  We determined that both 3280 and 
> X.509 are clear on
> > that.  If you want add this sentence explicitly, I do not 
> have objections.]
> 
> [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].
> 
> > [In this mail thread, we then determined that standards are 
> clear in that
> > absence of IDP means a CRL is complete for the CA.] 
> 
> [Denis : I have difficulties to agree with this. There is a 
> situation where 
> this is not the case. If the certificate includes a CRL DP 
> extension with 
> the field cRLIssuer present, then it means that the CRL 
> present at the 
> distributionPoint MUST be signed by that CRL Issuer. Then the 
> relying party 
> MUST find a certificate issued by the CA that has delivered 
> that certificate 
> which has the keyUsage bit 6 set (cRLSign) and which includes 
> the name of 
> this CRL issuer as the subject name. It MUST then verify that 
> the CRL which 
> has been found is indeed signed by the key included in that 
> certificate.
> 
> DistributionPoint is copied below:
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     
> DistributionPointName OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
> Absence of IDP does not necessarilly mean that it is a CRL is 
> complete for 
> the CA.
> 
> Going back to RFC 3280, RFC 3280 is not sufficiently explicit 
> about the ways 
> to find the right CRL, when the CRL issuer is different from 
> the CA. More 
> text would be needed to cover this aspect.
> 
> /Denis ]
> 
> > In the revision of RFC 3280 I would suggest adding a 
> section that deals with
> > the aspects of CA re-keying and how that explicitly affects 
> the use of the
> > standard and what it takes to achieve that. E.g. what 
> certificates you need
> > to cover in a "full" CRL, that a re-keyed CA instance don't re-use
> > certificate serial numbers from certificates issued by 
> previous CA instances
> > etc.
> > 
> > [If you are using the same name and then reusing the serial 
> numbers when
> > rekeying, you have a bigger problem than just revocation 
> checking.  I hope
> > no product is doing that.]
> > 
> > CMP 4.4.1 tries to cover some of that ground but doesn't 
> cover the aspects
> > above and is neither normative for X.509 or RFC 3280
> > 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >  
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked]
> > 
> > [mailto:[email-masked]]
> > 
> >>On Behalf Of Santosh Chokhani
> >>Sent: den 15 september 2004 19:03
> >>To: [email-masked]
> >>Subject: RE: CA Rekey and CRL Validation
> >>
> >>
> >>Stefan:
> >>
> >>That knows lies in several posting here where we have 
> concluded that a
> > 
> > CA
> > 
> >>=
> >>Issuer Name and a CA != Issuer Name + Key
> >>
> >>-----Original Message-----
> >>From: Stefan Santesson [mailto:[email-masked]]
> >>Sent: Wednesday, September 15, 2004 12:56 PM
> >>To: Santosh Chokhani; [email-masked]
> >>Subject: RE: CA Rekey and CRL Validation
> >>
> >>
> >>Santosh,
> >>
> >>Thanks.
> >>
> >>I must conclude though that the term "crystal clear" has completely 
> >>different meaning in our vocabularies :-)
> >>
> >>All this is clear IF you understand that "complete" means not only 
> >>certificate issued under one CA key, but all certificates 
> issued under
> > 
> > all
> > 
> >>keys of that CA.
> >>
> >>But where do you gain that knowledge?
> >>THAT is what interests me.
> >>
> >>
> >>Stefan Santesson
> >>Microsoft Security Center of Excellence (SCOE)
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: [email-masked]
> >>
> >>[mailto:[email-masked]]
> >>
> >>>On Behalf Of Santosh Chokhani
> >>>Sent: den 15 september 2004 17:24
> >>>To: [email-masked]
> >>>Subject: RE: CA Rekey and CRL Validation
> >>>
> >>>
> >>>Stefan:
> >>>
> >>>See Section B.5.1.1 Complete CRL and I quote it below:
> >>>
> >>>"In order to determine that a CRL is a complete CRL for end-entity
> >>
> > and
> > 
> >>>CA-certificates, for all reason codes of interest, the following
> >>
> > shall
> > 
> >>be
> >>
> >>>true:
> >>>-	Delta CRL indicator extension shall be absent; and
> >>>-	Issuing distribution point extension may be present; and
> >>>-	Issuing distribution point extension shall not contain
> >>>distribution
> >>>point field; and
> >>>-	Issuing distribution point extension shall not contain
> >>>onlyContainsUserCerts field set to TRUE; and
> >>>-	Issuing distribution point extension shall not contain
> >>>onlyContainsAuthorityCerts field set to TRUE; and
> >>>-	Issuing distribution point extension shall not contain
> >>>onlyContainsAttributeCerts field set to TRUE; and
> >>>-	If the reasonCodes field is present in the issuing distribution
> >>>point extension, the reasons code field shall include all the
> >>
> > reasons
> > 
> >>of
> >>
> >>>interest to the application; and
> >>>-	Issuing distribution point extension may or may not contain
> >>>indirectCRL field (hence, this field need not be checked)."
> >>>
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Stefan Santesson [mailto:[email-masked]]
> >>>Sent: Wednesday, September 15, 2004 11:01 AM
> >>>To: Santosh Chokhani; [email-masked]
> >>>Subject: RE: CA Rekey and CRL Validation
> >>>
> >>>
> >>>Santosh,
> >>>
> >>>
> >>>>[Since I have been involved in crafting portions of X.509 and
> >>>
> > since
> > 
> >>>Annex
> >>>
> >>>>B
> >>>>that is normative makes this abundantly clear, I beg to differ
> >>>
> > that
> > 
> >>it
> >>
> >>>is
> >>>
> >>>>not clear enough or authors of the text did not have this in mind.
> >>>
> >>>Any
> >>>
> >>>>suggestion to make it clearer in X.509 are welcome.]
> >>>
> >>>
> >>>Well, since I'm talking to the expert :-)
> >>>
> >>>I would be very grateful if you could point me to the section in
> >>
> > Annex
> > 
> >>B
> >>
> >>>that makes this "abundantly clear".
> >>>
> >>>In fact, I would be even more grateful, to find the section that
> >>
> > deals
> > 
> >>>with CA generation management where it is clearly stated what the 
> >>>effect
> >>
> >>are
> >>
> >>>when
> >>>re-keying a CA with a new key but the same name. E.g. that this is
> >>
> >>still
> >>
> >>>part of the same CA and that all language that mention the concept
> >>
> > of
> > 
> >>a CA
> >>
> >>>or CRL issuer explicitly means all instances of that CA or CRL
> >>
> > issuer
> > 
> >>(for
> >>
> >>>all generations of issuing keys).
> >>>
> >>>All I have seen is text from which you can derive this 
> truth. I have
> >>
> >>NOT
> >>
> >>>seen any text presented where this has been explicitly stated.
> >>>
> >>>
> >>>Stefan Santesson
> >>>Microsoft Security Center of Excellence (SCOE)
> >>>
> >>>
> >>>
> >>>
> >>
> > 
> > 
> > 
> 
> 

Date: Thu, 16 Sep 2004 14:25:19 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Santosh,

See may response in-line with [Denis: ]

> Stefan:
> 
> See responses in-line.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stefan Santesson
> Sent: Thursday, September 16, 2004 4:38 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> Yes I have noted that.
> 
> Still I think we can conclude then that there are no place in RFC 3280 or
> X.509 where this is explicitly stated.
> 
> That is not what I call "crystal clear"
> 
> [In this mail thread, we first determined that a CA is defined by name only
> and not be name+key.  We determined that both 3280 and X.509 are clear on
> that.  If you want add this sentence explicitly, I do not have objections.]

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

> [In this mail thread, we then determined that standards are clear in that
> absence of IDP means a CRL is complete for the CA.] 

[Denis : I have difficulties to agree with this. There is a situation where 
this is not the case. If the certificate includes a CRL DP extension with 
the field cRLIssuer present, then it means that the CRL present at the 
distributionPoint MUST be signed by that CRL Issuer. Then the relying party 
MUST find a certificate issued by the CA that has delivered that certificate 
which has the keyUsage bit 6 set (cRLSign) and which includes the name of 
this CRL issuer as the subject name. It MUST then verify that the CRL which 
has been found is indeed signed by the key included in that certificate.

DistributionPoint is copied below:

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

Absence of IDP does not necessarilly mean that it is a CRL is complete for 
the CA.

Going back to RFC 3280, RFC 3280 is not sufficiently explicit about the ways 
to find the right CRL, when the CRL issuer is different from the CA. More 
text would be needed to cover this aspect.

/Denis ]

> In the revision of RFC 3280 I would suggest adding a section that deals with
> the aspects of CA re-keying and how that explicitly affects the use of the
> standard and what it takes to achieve that. E.g. what certificates you need
> to cover in a "full" CRL, that a re-keyed CA instance don't re-use
> certificate serial numbers from certificates issued by previous CA instances
> etc.
> 
> [If you are using the same name and then reusing the serial numbers when
> rekeying, you have a bigger problem than just revocation checking.  I hope
> no product is doing that.]
> 
> CMP 4.4.1 tries to cover some of that ground but doesn't cover the aspects
> above and is neither normative for X.509 or RFC 3280
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Santosh Chokhani
>>Sent: den 15 september 2004 19:03
>>To: [email-masked]
>>Subject: RE: CA Rekey and CRL Validation
>>
>>
>>Stefan:
>>
>>That knows lies in several posting here where we have concluded that a
> 
> CA
> 
>>=
>>Issuer Name and a CA != Issuer Name + Key
>>
>>-----Original Message-----
>>From: Stefan Santesson [mailto:[email-masked]]
>>Sent: Wednesday, September 15, 2004 12:56 PM
>>To: Santosh Chokhani; [email-masked]
>>Subject: RE: CA Rekey and CRL Validation
>>
>>
>>Santosh,
>>
>>Thanks.
>>
>>I must conclude though that the term "crystal clear" has completely 
>>different meaning in our vocabularies :-)
>>
>>All this is clear IF you understand that "complete" means not only 
>>certificate issued under one CA key, but all certificates issued under
> 
> all
> 
>>keys of that CA.
>>
>>But where do you gain that knowledge?
>>THAT is what interests me.
>>
>>
>>Stefan Santesson
>>Microsoft Security Center of Excellence (SCOE)
>>
>>
>>
>>>-----Original Message-----
>>>From: [email-masked]
>>
>>[mailto:[email-masked]]
>>
>>>On Behalf Of Santosh Chokhani
>>>Sent: den 15 september 2004 17:24
>>>To: [email-masked]
>>>Subject: RE: CA Rekey and CRL Validation
>>>
>>>
>>>Stefan:
>>>
>>>See Section B.5.1.1 Complete CRL and I quote it below:
>>>
>>>"In order to determine that a CRL is a complete CRL for end-entity
>>
> and
> 
>>>CA-certificates, for all reason codes of interest, the following
>>
> shall
> 
>>be
>>
>>>true:
>>>-	Delta CRL indicator extension shall be absent; and
>>>-	Issuing distribution point extension may be present; and
>>>-	Issuing distribution point extension shall not contain
>>>distribution
>>>point field; and
>>>-	Issuing distribution point extension shall not contain
>>>onlyContainsUserCerts field set to TRUE; and
>>>-	Issuing distribution point extension shall not contain
>>>onlyContainsAuthorityCerts field set to TRUE; and
>>>-	Issuing distribution point extension shall not contain
>>>onlyContainsAttributeCerts field set to TRUE; and
>>>-	If the reasonCodes field is present in the issuing distribution
>>>point extension, the reasons code field shall include all the
>>
> reasons
> 
>>of
>>
>>>interest to the application; and
>>>-	Issuing distribution point extension may or may not contain
>>>indirectCRL field (hence, this field need not be checked)."
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Stefan Santesson [mailto:[email-masked]]
>>>Sent: Wednesday, September 15, 2004 11:01 AM
>>>To: Santosh Chokhani; [email-masked]
>>>Subject: RE: CA Rekey and CRL Validation
>>>
>>>
>>>Santosh,
>>>
>>>
>>>>[Since I have been involved in crafting portions of X.509 and
>>>
> since
> 
>>>Annex
>>>
>>>>B
>>>>that is normative makes this abundantly clear, I beg to differ
>>>
> that
> 
>>it
>>
>>>is
>>>
>>>>not clear enough or authors of the text did not have this in mind.
>>>
>>>Any
>>>
>>>>suggestion to make it clearer in X.509 are welcome.]
>>>
>>>
>>>Well, since I'm talking to the expert :-)
>>>
>>>I would be very grateful if you could point me to the section in
>>
> Annex
> 
>>B
>>
>>>that makes this "abundantly clear".
>>>
>>>In fact, I would be even more grateful, to find the section that
>>
> deals
> 
>>>with CA generation management where it is clearly stated what the 
>>>effect
>>
>>are
>>
>>>when
>>>re-keying a CA with a new key but the same name. E.g. that this is
>>
>>still
>>
>>>part of the same CA and that all language that mention the concept
>>
> of
> 
>>a CA
>>
>>>or CRL issuer explicitly means all instances of that CA or CRL
>>
> issuer
> 
>>(for
>>
>>>all generations of issuing keys).
>>>
>>>All I have seen is text from which you can derive this truth. I have
>>
>>NOT
>>
>>>seen any text presented where this has been explicitly stated.
>>>
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 07:17:47 -0400
Importance: Normal
Sender: [email-masked]

Wen-Cheng:

The actual DN matching algorithm needs to be a bit more robust.  See the
prior e-mails in this thread.  We need to ensure that the names match at all
levels ignoring self-issued certificates in both paths.

Also, the last certificate in both paths is not relevant.

For indirect CRL, the way to accommodate the name matching is to terminate
the name comparison at n-1 where n(min n1, n2) and n1 and n2 are the two
paths.  This requires the assumption that a CA has nominated another CA for
indirect CRL issuer who is in its trust hierarchy (above or below).  That
seems to be a safe, practical assumption.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of wcwang
Sent: Wednesday, September 15, 2004 9:23 PM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Basically, I agree that a CA should be identified by its DN and there is no
need to change its DN when it rekey. However, there are security issues if
the RP blindly trust the CRL issuer's DN. See the following example.

Suppose EE1 is the target of which certificate is to be validated by the RP.

CA2, CA2', and CA2'' are three CAs with the same DN but with different keys.

CRL1, CRL2, and CRL3 and three CRLs, and the signature of each one of them
can be verified with the puiblic key of each CA (CA2, CA2', and CA2'')
respectively and their issuer name matched.

Suppose the RP discover the following cert path:

TA->CA1->CA2->EE1

and the RP want to check if EE1's certificate is revoked.

To check the status of EE1's certificate, the RP has to construct a
acceptable "CRL path" (I mean valid cert path + CRL).

The question is what kind of "CRL path" is acceptable?
What are the criteria for an acceptable "CRL path"?

Let's consider the following "CRL paths":

CRL Path 1: TA->CA1->CA2->CRL

CRL Path 2: TA->CA1->CA2'->CRL

CRL path 3: TA->CA1->CA2->CA2'->CRL

CRL Path 4: TA->CA3->CA4->CA2''->CRL

Obviously, CRL Path 1 is acceptable since the target certificate and the CRL
are issued by the same CA with the same key. However, in the situation where
CA2 perform a key rollover and no longer use its old key to issue CRL. In
such situation, it is not possible to construct CRL Path 1, and therefore
the RP needs to find another CRL path. Suppose the RP find CRP path 2, CRL
path 3, and CRL path 4. Are all of them accptable?

I think CRL path 2 is acceptable under the condition where CA1 guarantees
that it have never and will never issue cross-certificate with the same
subject DN to two different CAs. Under such condition, the RP is safely to
assume the CA2' and CA2 are the same CA and CA2' is the one with the new
key. CRL path 2 represents the situation where a CA performed its rekey and
applied to it parent CA for a new cross-certificate.

I think CRL path 3 is also acceptable. CRL path 3 is the situation where a
CA performed its rekey and issued a self-issued certificate (key-rollover
certificate).

However, I think it is dangerous if the RP accpets CRL path 4. Since CA2''
is not issued by CA1, and there is no way to guarantee the name uniqueness,
therefore CA2'' might simply be anothor CA which happened to have the same
DN. Even worse, CA2'' might be a fake CA, which is intend to create fake
CRLs to fool the RP.

My conclusion is that the criteria to accept a CRL path are:

1. The last non-self-issued CA-certificate in the CRL path and
   the last non-self-issued CA-certificate in the target cert path
   must be issued by the same CA. 

   (As you can see, the the last non-self-issued CA-certificate in
    CRL path 1, 2, and 3 are all issued by the same CA, CA1.) 2. The issuer
CA of the last non-self-issued CA-certificate must
   guarantee (maybe in its CP or CPS) that it have never and will
   never issue cross-certificate with the same subject DN to two
   different CAs.

In addition, although I did not discuss the indirect-CRL above, I believe
that the same rule also apply to the indirect-CRL situation.

I think the X.509 standard and RFC 3280 (or other PKIX RFC) should clarify
the criteria for an acceptable "CRL path" and highlight the security
consideration behind.

Wen-Cheng Wang
Chunghwa Telecom

-----Original Message-----
From: Santosh Chokhani <[email-masked]>
To: [email-masked]
Date: Wed, 15 Sep 2004 13:03:11 -0400
Subject: RE: CA Rekey and CRL Validation

Stefan:

That knows lies in several posting here where we have concluded that a CA =
Issuer Name and a CA != Issuer Name + Key

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2004 12:56 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

Thanks.

I must conclude though that the term "crystal clear" has completely
different meaning in our vocabularies :-)

All this is clear IF you understand that "complete" means not only
certificate issued under one CA key, but all certificates issued under all
keys of that CA.

But where do you gain that knowledge?
THAT is what interests me.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 15 september 2004 17:24
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> See Section B.5.1.1 Complete CRL and I quote it below:
> 
> "In order to determine that a CRL is a complete CRL for end-entity and
> CA-certificates, for all reason codes of interest, the following shall
be
> true:
> -	Delta CRL indicator extension shall be absent; and
> -	Issuing distribution point extension may be present; and
> -	Issuing distribution point extension shall not contain
> distribution
> point field; and
> -	Issuing distribution point extension shall not contain
> onlyContainsUserCerts field set to TRUE; and
> -	Issuing distribution point extension shall not contain
> onlyContainsAuthorityCerts field set to TRUE; and
> -	Issuing distribution point extension shall not contain
> onlyContainsAttributeCerts field set to TRUE; and
> -	If the reasonCodes field is present in the issuing distribution
> point extension, the reasons code field shall include all the reasons
of
> interest to the application; and
> -	Issuing distribution point extension may or may not contain
> indirectCRL field (hence, this field need not be checked)."
> 
> 
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Wednesday, September 15, 2004 11:01 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> > [Since I have been involved in crafting portions of X.509 and since
> Annex
> > B
> > that is normative makes this abundantly clear, I beg to differ that
it
> is
> > not clear enough or authors of the text did not have this in mind.
> Any
> > suggestion to make it clearer in X.509 are welcome.]
> 
> 
> Well, since I'm talking to the expert :-)
> 
> I would be very grateful if you could point me to the section in Annex
B
> that makes this "abundantly clear".
> 
> In fact, I would be even more grateful, to find the section that deals
> with CA generation management where it is clearly stated what the 
> effect
are
> when
> re-keying a CA with a new key but the same name. E.g. that this is
still
> part of the same CA and that all language that mention the concept of
a CA
> or CRL issuer explicitly means all instances of that CA or CRL issuer
(for
> all generations of issuing keys).
> 
> All I have seen is text from which you can derive this truth. I have
NOT
> seen any text presented where this has been explicitly stated.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 07:03:39 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

See responses in-line.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Thursday, September 16, 2004 4:38 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Yes I have noted that.

Still I think we can conclude then that there are no place in RFC 3280 or
X.509 where this is explicitly stated.

That is not what I call "crystal clear"

[In this mail thread, we first determined that a CA is defined by name only
and not be name+key.  We determined that both 3280 and X.509 are clear on
that.  If you want add this sentence explicitly, I do not have objections.]

[In this mail thread, we then determined that standards are clear in that
absence of IDP means a CRL is complete for the CA.] 

In the revision of RFC 3280 I would suggest adding a section that deals with
the aspects of CA re-keying and how that explicitly affects the use of the
standard and what it takes to achieve that. E.g. what certificates you need
to cover in a "full" CRL, that a re-keyed CA instance don't re-use
certificate serial numbers from certificates issued by previous CA instances
etc.

[If you are using the same name and then reusing the serial numbers when
rekeying, you have a bigger problem than just revocation checking.  I hope
no product is doing that.]

CMP 4.4.1 tries to cover some of that ground but doesn't cover the aspects
above and is neither normative for X.509 or RFC 3280

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 15 september 2004 19:03
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> That knows lies in several posting here where we have concluded that a
CA
> =
> Issuer Name and a CA != Issuer Name + Key
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Wednesday, September 15, 2004 12:56 PM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> Thanks.
> 
> I must conclude though that the term "crystal clear" has completely 
> different meaning in our vocabularies :-)
> 
> All this is clear IF you understand that "complete" means not only 
> certificate issued under one CA key, but all certificates issued under
all
> keys of that CA.
> 
> But where do you gain that knowledge?
> THAT is what interests me.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 15 september 2004 17:24
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Stefan:
> >
> > See Section B.5.1.1 Complete CRL and I quote it below:
> >
> > "In order to determine that a CRL is a complete CRL for end-entity
and
> > CA-certificates, for all reason codes of interest, the following
shall
> be
> > true:
> > -	Delta CRL indicator extension shall be absent; and
> > -	Issuing distribution point extension may be present; and
> > -	Issuing distribution point extension shall not contain
> > distribution
> > point field; and
> > -	Issuing distribution point extension shall not contain
> > onlyContainsUserCerts field set to TRUE; and
> > -	Issuing distribution point extension shall not contain
> > onlyContainsAuthorityCerts field set to TRUE; and
> > -	Issuing distribution point extension shall not contain
> > onlyContainsAttributeCerts field set to TRUE; and
> > -	If the reasonCodes field is present in the issuing distribution
> > point extension, the reasons code field shall include all the
reasons
> of
> > interest to the application; and
> > -	Issuing distribution point extension may or may not contain
> > indirectCRL field (hence, this field need not be checked)."
> >
> >
> >
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[email-masked]]
> > Sent: Wednesday, September 15, 2004 11:01 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Santosh,
> >
> > > [Since I have been involved in crafting portions of X.509 and
since
> > Annex
> > > B
> > > that is normative makes this abundantly clear, I beg to differ
that
> it
> > is
> > > not clear enough or authors of the text did not have this in mind.
> > Any
> > > suggestion to make it clearer in X.509 are welcome.]
> >
> >
> > Well, since I'm talking to the expert :-)
> >
> > I would be very grateful if you could point me to the section in
Annex
> B
> > that makes this "abundantly clear".
> >
> > In fact, I would be even more grateful, to find the section that
deals
> > with CA generation management where it is clearly stated what the 
> > effect
> are
> > when
> > re-keying a CA with a new key but the same name. E.g. that this is
> still
> > part of the same CA and that all language that mention the concept
of
> a CA
> > or CRL issuer explicitly means all instances of that CA or CRL
issuer
> (for
> > all generations of issuing keys).
> >
> > All I have seen is text from which you can derive this truth. I have
> NOT
> > seen any text presented where this has been explicitly stated.
> >
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >
> >
> 

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 09:38:11 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Yes I have noted that.

Still I think we can conclude then that there are no place in RFC 3280
or X.509 where this is explicitly stated.

That is not what I call "crystal clear"

In the revision of RFC 3280 I would suggest adding a section that deals
with the aspects of CA re-keying and how that explicitly affects the use
of the standard and what it takes to achieve that. E.g. what
certificates you need to cover in a "full" CRL, that a re-keyed CA
instance don't re-use certificate serial numbers from certificates
issued by previous CA instances etc.

CMP 4.4.1 tries to cover some of that ground but doesn't cover the
aspects above and is neither normative for X.509 or RFC 3280

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 15 september 2004 19:03
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> That knows lies in several posting here where we have concluded that a
CA
> =
> Issuer Name and a CA != Issuer Name + Key
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Wednesday, September 15, 2004 12:56 PM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> Thanks.
> 
> I must conclude though that the term "crystal clear" has completely
> different meaning in our vocabularies :-)
> 
> All this is clear IF you understand that "complete" means not only
> certificate issued under one CA key, but all certificates issued under
all
> keys of that CA.
> 
> But where do you gain that knowledge?
> THAT is what interests me.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 15 september 2004 17:24
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Stefan:
> >
> > See Section B.5.1.1 Complete CRL and I quote it below:
> >
> > "In order to determine that a CRL is a complete CRL for end-entity
and
> > CA-certificates, for all reason codes of interest, the following
shall
> be
> > true:
> > -	Delta CRL indicator extension shall be absent; and
> > -	Issuing distribution point extension may be present; and
> > -	Issuing distribution point extension shall not contain
> > distribution
> > point field; and
> > -	Issuing distribution point extension shall not contain
> > onlyContainsUserCerts field set to TRUE; and
> > -	Issuing distribution point extension shall not contain
> > onlyContainsAuthorityCerts field set to TRUE; and
> > -	Issuing distribution point extension shall not contain
> > onlyContainsAttributeCerts field set to TRUE; and
> > -	If the reasonCodes field is present in the issuing distribution
> > point extension, the reasons code field shall include all the
reasons
> of
> > interest to the application; and
> > -	Issuing distribution point extension may or may not contain
> > indirectCRL field (hence, this field need not be checked)."
> >
> >
> >
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[email-masked]]
> > Sent: Wednesday, September 15, 2004 11:01 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Santosh,
> >
> > > [Since I have been involved in crafting portions of X.509 and
since
> > Annex
> > > B
> > > that is normative makes this abundantly clear, I beg to differ
that
> it
> > is
> > > not clear enough or authors of the text did not have this in mind.
> > Any
> > > suggestion to make it clearer in X.509 are welcome.]
> >
> >
> > Well, since I'm talking to the expert :-)
> >
> > I would be very grateful if you could point me to the section in
Annex
> B
> > that makes this "abundantly clear".
> >
> > In fact, I would be even more grateful, to find the section that
deals
> > with CA generation management where it is clearly stated what the
> > effect
> are
> > when
> > re-keying a CA with a new key but the same name. E.g. that this is
> still
> > part of the same CA and that all language that mention the concept
of
> a CA
> > or CRL issuer explicitly means all instances of that CA or CRL
issuer
> (for
> > all generations of issuing keys).
> >
> > All I have seen is text from which you can derive this truth. I have
> NOT
> > seen any text presented where this has been explicitly stated.
> >
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >
> >
> 

From: "Yasir Khan" <[email-masked]>
To: <[email-masked]>
Subject: Delta CRLs - Is there any final conclusion?
Date: Thu, 16 Sep 2004 12:13:19 +0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0052_01C49BE6.8EB7CC90
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0053_01C49BE6.8EB7CC90"

------=_NextPart_001_0053_01C49BE6.8EB7CC90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I have been looking at IETF archives and found many threads discussing =
the Delta-CRLs. Also I saw David A. Cooper's paper "A More Efficient Use =
of Delta-CRLs"  and Russ, Tim and Cooper's "Strawman on Delta-CRLs"
After going through many threads and papers, still I couldn't find any =
final document/discussion describing the issuance/usage of Delta-CRLs. =
If a standard way has been concluded for issuance/usage of Delta-CRLs =
then please refer me to that information. Thanx

Reagrds,
Yasir

------=_NextPart_001_0053_01C49BE6.8EB7CC90
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 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>I have been looking at =
IETF archives=20
and found many threads discussing the Delta-CRLs. Also =
I&nbsp;saw&nbsp;David A.=20
Cooper's paper "<U>A More Efficient Use of Delta-CRLs</U>"&nbsp; and =
Russ, Tim=20
and Cooper's "<A=20
href=3D"http://www.imc.org/ietf-pkix/old-archive-01/msg01505.html"=20
name=3D01505><FONT face=3D"Times New Roman" size=3D3>Strawman on=20
Delta-CRLs</FONT></A>"</FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>After going through =
many threads and=20
papers,&nbsp;still I couldn't find any final document/discussion =
describing the=20
issuance/usage of Delta-CRLs. If&nbsp;a standard way&nbsp;has been =
concluded for=20
issuance/usage of Delta-CRLs then please refer me to that information.=20
Thanx</FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>Reagrds,</FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 =
size=3D2>Yasir</FONT></DIV></BODY></HTML>

------=_NextPart_001_0053_01C49BE6.8EB7CC90--

------=_NextPart_000_0052_01C49BE6.8EB7CC90
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0052_01C49BE6.8EB7CC90--

From: [email-masked]
To: [email-masked], [email-masked]
Subject: AW: CA Rekey and CRL Validation
Date: Thu, 16 Sep 2004 09:15:31 +0200
Sender: [email-masked]

Santosh, Stefan,

following the diskussion a couple of days, my opinion is, that this is the
point of misunderstandings. That people have a different view of what a CA
is. Is it the technical entity that signs the certifictes, i. e. the key, or
is it the body that issues the certificates, i. e. the organisation (the
name)?
If we do not clearify what exactly we are talking about and what is written
in the standards it seems to me like comparing apples to pears.

Regards
Thomas Beckmann

> -----Ursprüngliche Nachricht-----
> Von: Santosh Chokhani [mailto:[email-masked]]
> Gesendet: Mittwoch, 15. September 2004 19:03
> An: [email-masked]
> Betreff: RE: CA Rekey and CRL Validation
> 
> 
> 
> Stefan:
> 
> That knows lies in several posting here where we have 
> concluded that a CA =
> Issuer Name and a CA != Issuer Name + Key
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Wednesday, September 15, 2004 12:56 PM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> Thanks.
> 
> I must conclude though that the term "crystal clear" has completely
> different meaning in our vocabularies :-)
> 
> All this is clear IF you understand that "complete" means not only
> certificate issued under one CA key, but all certificates 
> issued under all
> keys of that CA.
> 
> But where do you gain that knowledge?
> THAT is what interests me.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 15 september 2004 17:24
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> > 
> > 
> > Stefan:
> > 
> > See Section B.5.1.1 Complete CRL and I quote it below:
> > 
> > "In order to determine that a CRL is a complete CRL for 
> end-entity and 
> > CA-certificates, for all reason codes of interest, the 
> following shall
> be
> > true:
> > -	Delta CRL indicator extension shall be absent; and
> > -	Issuing distribution point extension may be present; and
> > -	Issuing distribution point extension shall not contain
> > distribution
> > point field; and
> > -	Issuing distribution point extension shall not contain
> > onlyContainsUserCerts field set to TRUE; and
> > -	Issuing distribution point extension shall not contain
> > onlyContainsAuthorityCerts field set to TRUE; and
> > -	Issuing distribution point extension shall not contain
> > onlyContainsAttributeCerts field set to TRUE; and
> > -	If the reasonCodes field is present in the issuing distribution
> > point extension, the reasons code field shall include all 
> the reasons
> of
> > interest to the application; and
> > -	Issuing distribution point extension may or may not contain
> > indirectCRL field (hence, this field need not be checked)."
> > 
> > 
> > 
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[email-masked]]
> > Sent: Wednesday, September 15, 2004 11:01 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> > 
> > 
> > Santosh,
> > 
> > > [Since I have been involved in crafting portions of X.509 
> and since
> > Annex
> > > B
> > > that is normative makes this abundantly clear, I beg to 
> differ that
> it
> > is
> > > not clear enough or authors of the text did not have this in mind.
> > Any
> > > suggestion to make it clearer in X.509 are welcome.]
> > 
> > 
> > Well, since I'm talking to the expert :-)
> > 
> > I would be very grateful if you could point me to the 
> section in Annex
> B
> > that makes this "abundantly clear".
> > 
> > In fact, I would be even more grateful, to find the section 
> that deals 
> > with CA generation management where it is clearly stated what the 
> > effect
> are
> > when
> > re-keying a CA with a new key but the same name. E.g. that this is
> still
> > part of the same CA and that all language that mention the 
> concept of
> a CA
> > or CRL issuer explicitly means all instances of that CA or 
> CRL issuer
> (for
> > all generations of issuing keys).
> > 
> > All I have seen is text from which you can derive this truth. I have
> NOT
> > seen any text presented where this has been explicitly stated.
> > 
> > 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> > 
> > 
> > 
> > 
> 
> 

From: "wcwang" <[email-masked]>
Reply-To: [email-masked]
Subject: RE: CA Rekey and CRL Validation
To: [email-masked]
Date: Thu, 16 Sep 2004 09:23:19 +0800 (CST)
Sender: [email-masked]

Basically, I agree that a CA should be identified by its DN and
there is no need to change its DN when it rekey. However, there
are security issues if the RP blindly trust the CRL issuer's DN.
See the following example.

Suppose EE1 is the target of which certificate is to be validated
by the RP.

CA2, CA2', and CA2'' are three CAs with the same DN but with
different keys.

CRL1, CRL2, and CRL3 and three CRLs, and the signature of each one
of them can be verified with the puiblic key of each CA (CA2, CA2',
and CA2'') respectively and their issuer name matched.

Suppose the RP discover the following cert path:

TA->CA1->CA2->EE1

and the RP want to check if EE1's certificate is revoked.

To check the status of EE1's certificate, the RP has to
construct a acceptable "CRL path" (I mean valid cert path + CRL).

The question is what kind of "CRL path" is acceptable?
What are the criteria for an acceptable "CRL path"?

Let's consider the following "CRL paths":

CRL Path 1: TA->CA1->CA2->CRL

CRL Path 2: TA->CA1->CA2'->CRL

CRL path 3: TA->CA1->CA2->CA2'->CRL

CRL Path 4: TA->CA3->CA4->CA2''->CRL

Obviously, CRL Path 1 is acceptable since the target certificate and
the CRL are issued by the same CA with the same key. However, in the
situation where CA2 perform a key rollover and no longer use its old
key to issue CRL. In such situation, it is not possible to construct
CRL Path 1, and therefore the RP needs to find another CRL path.
Suppose the RP find CRP path 2, CRL path 3, and CRL path 4. Are
all of them accptable?

I think CRL path 2 is acceptable under the condition where CA1 guarantees
that it have never and will never issue cross-certificate with the same
subject DN to two different CAs. Under such condition, the RP is safely
to assume the CA2' and CA2 are the same CA and CA2' is the one with the
new key. CRL path 2 represents the situation where a CA performed its rekey
and applied to it parent CA for a new cross-certificate.

I think CRL path 3 is also acceptable. CRL path 3 is the situation where
a CA performed its rekey and issued a self-issued certificate (key-rollover
certificate).

However, I think it is dangerous if the RP accpets CRL path 4. Since
CA2'' is not issued by CA1, and there is no way to guarantee the name
uniqueness, therefore CA2'' might simply be anothor CA which happened
to have the same DN. Even worse, CA2'' might be a fake CA, which is
intend to create fake CRLs to fool the RP.

My conclusion is that the criteria to accept a CRL path are:

1. The last non-self-issued CA-certificate in the CRL path and
   the last non-self-issued CA-certificate in the target cert path
   must be issued by the same CA. 

   (As you can see, the the last non-self-issued CA-certificate in
    CRL path 1, 2, and 3 are all issued by the same CA, CA1.)
2. The issuer CA of the last non-self-issued CA-certificate must
   guarantee (maybe in its CP or CPS) that it have never and will
   never issue cross-certificate with the same subject DN to two
   different CAs.

In addition, although I did not discuss the indirect-CRL above, I believe
that the same rule also apply to the indirect-CRL situation.

I think the X.509 standard and RFC 3280 (or other PKIX RFC) should
clarify the criteria for an acceptable "CRL path" and highlight the
security consideration behind.

Wen-Cheng Wang
Chunghwa Telecom

-----Original Message-----
From: Santosh Chokhani <[email-masked]>
To: [email-masked]
Date: Wed, 15 Sep 2004 13:03:11 -0400
Subject: RE: CA Rekey and CRL Validation

Stefan:

That knows lies in several posting here where we have concluded that a CA =
Issuer Name and a CA != Issuer Name + Key

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2004 12:56 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

Thanks.

I must conclude though that the term "crystal clear" has completely
different meaning in our vocabularies :-)

All this is clear IF you understand that "complete" means not only
certificate issued under one CA key, but all certificates issued under all
keys of that CA.

But where do you gain that knowledge?
THAT is what interests me.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 15 september 2004 17:24
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> See Section B.5.1.1 Complete CRL and I quote it below:
> 
> "In order to determine that a CRL is a complete CRL for end-entity and 
> CA-certificates, for all reason codes of interest, the following shall
be
> true:
> -	Delta CRL indicator extension shall be absent; and
> -	Issuing distribution point extension may be present; and
> -	Issuing distribution point extension shall not contain
> distribution
> point field; and
> -	Issuing distribution point extension shall not contain
> onlyContainsUserCerts field set to TRUE; and
> -	Issuing distribution point extension shall not contain
> onlyContainsAuthorityCerts field set to TRUE; and
> -	Issuing distribution point extension shall not contain
> onlyContainsAttributeCerts field set to TRUE; and
> -	If the reasonCodes field is present in the issuing distribution
> point extension, the reasons code field shall include all the reasons
of
> interest to the application; and
> -	Issuing distribution point extension may or may not contain
> indirectCRL field (hence, this field need not be checked)."
> 
> 
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Wednesday, September 15, 2004 11:01 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> > [Since I have been involved in crafting portions of X.509 and since
> Annex
> > B
> > that is normative makes this abundantly clear, I beg to differ that
it
> is
> > not clear enough or authors of the text did not have this in mind.
> Any
> > suggestion to make it clearer in X.509 are welcome.]
> 
> 
> Well, since I'm talking to the expert :-)
> 
> I would be very grateful if you could point me to the section in Annex
B
> that makes this "abundantly clear".
> 
> In fact, I would be even more grateful, to find the section that deals 
> with CA generation management where it is clearly stated what the 
> effect
are
> when
> re-keying a CA with a new key but the same name. E.g. that this is
still
> part of the same CA and that all language that mention the concept of
a CA
> or CRL issuer explicitly means all instances of that CA or CRL issuer
(for
> all generations of issuing keys).
> 
> All I have seen is text from which you can derive this truth. I have
NOT
> seen any text presented where this has been explicitly stated.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> 
> 

Date: Wed, 15 Sep 2004 14:03:50 -0700
From: Julien Pierre <[email-masked]>
Subject: Re: CA Rekey and CRL Validation
To: Stefan Santesson <[email-masked]>
Cc: Santosh Chokhani <[email-masked]>, [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040903050907090604080906
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stefan Santesson wrote:

>Santosh,
>
>Thanks for this interesting dialogue.
>
>I finally got what I needed to get the picture complete.
>
>That is that the standards actually REQUIRE that a CRL without IDP MUST
>contain revocation information for all certificates for all instances of
>a CA representing all issuing keys. That aspect, if so, was not clear to
>me.
>
>I think the standards are in a need for some serious clarifications
>around this issue. I'm prety convinced that the writers didn't have this
>in mind when writing the text.
>  
>
I think it probably was implicit to the authors, because CRLs before the 
v2 extensions such as IDP were created were always covering the full 
scope of that CA.

--------------ms040903050907090604080906
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040903050907090604080906--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 13:03:11 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

That knows lies in several posting here where we have concluded that a CA =
Issuer Name and a CA != Issuer Name + Key

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2004 12:56 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

Thanks.

I must conclude though that the term "crystal clear" has completely
different meaning in our vocabularies :-)

All this is clear IF you understand that "complete" means not only
certificate issued under one CA key, but all certificates issued under all
keys of that CA.

But where do you gain that knowledge?
THAT is what interests me.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 15 september 2004 17:24
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> See Section B.5.1.1 Complete CRL and I quote it below:
> 
> "In order to determine that a CRL is a complete CRL for end-entity and 
> CA-certificates, for all reason codes of interest, the following shall
be
> true:
> -	Delta CRL indicator extension shall be absent; and
> -	Issuing distribution point extension may be present; and
> -	Issuing distribution point extension shall not contain
> distribution
> point field; and
> -	Issuing distribution point extension shall not contain
> onlyContainsUserCerts field set to TRUE; and
> -	Issuing distribution point extension shall not contain
> onlyContainsAuthorityCerts field set to TRUE; and
> -	Issuing distribution point extension shall not contain
> onlyContainsAttributeCerts field set to TRUE; and
> -	If the reasonCodes field is present in the issuing distribution
> point extension, the reasons code field shall include all the reasons
of
> interest to the application; and
> -	Issuing distribution point extension may or may not contain
> indirectCRL field (hence, this field need not be checked)."
> 
> 
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Wednesday, September 15, 2004 11:01 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> > [Since I have been involved in crafting portions of X.509 and since
> Annex
> > B
> > that is normative makes this abundantly clear, I beg to differ that
it
> is
> > not clear enough or authors of the text did not have this in mind.
> Any
> > suggestion to make it clearer in X.509 are welcome.]
> 
> 
> Well, since I'm talking to the expert :-)
> 
> I would be very grateful if you could point me to the section in Annex
B
> that makes this "abundantly clear".
> 
> In fact, I would be even more grateful, to find the section that deals 
> with CA generation management where it is clearly stated what the 
> effect
are
> when
> re-keying a CA with a new key but the same name. E.g. that this is
still
> part of the same CA and that all language that mention the concept of
a CA
> or CRL issuer explicitly means all instances of that CA or CRL issuer
(for
> all generations of issuing keys).
> 
> All I have seen is text from which you can derive this truth. I have
NOT
> seen any text presented where this has been explicitly stated.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 17:55:48 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

Thanks.

I must conclude though that the term "crystal clear" has completely
different meaning in our vocabularies :-)

All this is clear IF you understand that "complete" means not only
certificate issued under one CA key, but all certificates issued under
all keys of that CA.

But where do you gain that knowledge?
THAT is what interests me.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 15 september 2004 17:24
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> See Section B.5.1.1 Complete CRL and I quote it below:
> 
> "In order to determine that a CRL is a complete CRL for end-entity and
> CA-certificates, for all reason codes of interest, the following shall
be
> true:
> -	Delta CRL indicator extension shall be absent; and
> -	Issuing distribution point extension may be present; and
> -	Issuing distribution point extension shall not contain
> distribution
> point field; and
> -	Issuing distribution point extension shall not contain
> onlyContainsUserCerts field set to TRUE; and
> -	Issuing distribution point extension shall not contain
> onlyContainsAuthorityCerts field set to TRUE; and
> -	Issuing distribution point extension shall not contain
> onlyContainsAttributeCerts field set to TRUE; and
> -	If the reasonCodes field is present in the issuing distribution
> point extension, the reasons code field shall include all the reasons
of
> interest to the application; and
> -	Issuing distribution point extension may or may not contain
> indirectCRL field (hence, this field need not be checked)."
> 
> 
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Wednesday, September 15, 2004 11:01 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> > [Since I have been involved in crafting portions of X.509 and since
> Annex
> > B
> > that is normative makes this abundantly clear, I beg to differ that
it
> is
> > not clear enough or authors of the text did not have this in mind.
> Any
> > suggestion to make it clearer in X.509 are welcome.]
> 
> 
> Well, since I'm talking to the expert :-)
> 
> I would be very grateful if you could point me to the section in Annex
B
> that makes this "abundantly clear".
> 
> In fact, I would be even more grateful, to find the section that deals
> with
> CA generation management where it is clearly stated what the effect
are
> when
> re-keying a CA with a new key but the same name. E.g. that this is
still
> part of the same CA and that all language that mention the concept of
a CA
> or CRL issuer explicitly means all instances of that CA or CRL issuer
(for
> all generations of issuing keys).
> 
> All I have seen is text from which you can derive this truth. I have
NOT
> seen any text presented where this has been explicitly stated.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 11:23:57 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

See Section B.5.1.1 Complete CRL and I quote it below:

"In order to determine that a CRL is a complete CRL for end-entity and
CA-certificates, for all reason codes of interest, the following shall be
true:
-	Delta CRL indicator extension shall be absent; and
-	Issuing distribution point extension may be present; and
-	Issuing distribution point extension shall not contain distribution
point field; and
-	Issuing distribution point extension shall not contain
onlyContainsUserCerts field set to TRUE; and
-	Issuing distribution point extension shall not contain
onlyContainsAuthorityCerts field set to TRUE; and
-	Issuing distribution point extension shall not contain
onlyContainsAttributeCerts field set to TRUE; and
-	If the reasonCodes field is present in the issuing distribution
point extension, the reasons code field shall include all the reasons of
interest to the application; and
-	Issuing distribution point extension may or may not contain
indirectCRL field (hence, this field need not be checked)."

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2004 11:01 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

> [Since I have been involved in crafting portions of X.509 and since
Annex
> B
> that is normative makes this abundantly clear, I beg to differ that it
is
> not clear enough or authors of the text did not have this in mind.
Any
> suggestion to make it clearer in X.509 are welcome.]

Well, since I'm talking to the expert :-)

I would be very grateful if you could point me to the section in Annex B
that makes this "abundantly clear".

In fact, I would be even more grateful, to find the section that deals with
CA generation management where it is clearly stated what the effect are when
re-keying a CA with a new key but the same name. E.g. that this is still
part of the same CA and that all language that mention the concept of a CA
or CRL issuer explicitly means all instances of that CA or CRL issuer (for
all generations of issuing keys).

All I have seen is text from which you can derive this truth. I have NOT
seen any text presented where this has been explicitly stated.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 16:01:13 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

> [Since I have been involved in crafting portions of X.509 and since
Annex
> B
> that is normative makes this abundantly clear, I beg to differ that it
is
> not clear enough or authors of the text did not have this in mind.
Any
> suggestion to make it clearer in X.509 are welcome.]

Well, since I'm talking to the expert :-)

I would be very grateful if you could point me to the section in Annex B
that makes this "abundantly clear".

In fact, I would be even more grateful, to find the section that deals
with CA generation management where it is clearly stated what the effect
are when re-keying a CA with a new key but the same name. E.g. that this
is still part of the same CA and that all language that mention the
concept of a CA or CRL issuer explicitly means all instances of that CA
or CRL issuer (for all generations of issuing keys).

All I have seen is text from which you can derive this truth. I have NOT
seen any text presented where this has been explicitly stated.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 11:00:41 -0400
Importance: Normal
Sender: [email-masked]

Sharon:

Please see responses in-line in [].

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2004 10:00 AM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh I'm not sure what you are asking for comment on.

[I am not asking to comment on anything.]

However, I do not want to see a change made that would invalidate currently
conformant implmentations that behave along the following lines:

- CA key rollover is handled with self-issued certificates (new key signed
with old and old key signed with new). Where this involves a full and
complete CRL for the CA, and there is no IDP present in the CRL, then the
CRL continues to list all revoked and unexpired certificates issued by that
CA, regardless of the key that had been originally used to sign the
certificate. 

[You have to be careful in using self-issued certificates approach.  There
is no simple way to promulgate their revocation status unless both keys are
used to issue two CRLs]

Also I would not support any change that invalidated use of that same
technique (self issued certs) along with the use of CRLDP and IDP to handle
partitioned CRL environments. In this case again the partitioned CRLs can
continue to list all revoked unexpired certificates that point to that CRL
in their CRLDP regardless of the key that was used to sign that certificate
(either the old or new key). 

Yes there are implementations that behave this way if that is what you are
asking.

Cheers,
Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Wednesday, September 15, 2004 9:11 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Stefan:

I am not saying IDP only limits scope.  I am saying the only way to limit
scope (Since 3280 does not use CRL Scope extension) is to use IDP.  IDP
absent means (delta not withstanding) the CRL is complete for the Issuer,
and does not contain any revocation information about certificates issued by
other CAs and hence must not contain Certificate Issuer extension in any of
the CRL entries.

(BTW, when an IDP is asserted in a CRL, it does not mean the CRL is not
complete.  It is that relying party does not know whether it is complete or
not.  I would encourage you to read X.509 Annex B for further details.)

I would let the vendors respond if they do key rollover right.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2004 8:17 AM
To: Carl Wallace; Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Carl,

Thanks for some good technical arguments.

Your arguments of the scope if CRLs without IDP makes sense in the reading
of a CRL issuer as all instances of a CA (representing all issuing keys).

I must say though that this isn't very clearly stated in the standards
documents and hence it is easily misunderstood by implementers. 

So I don't disagree, but I wander if there is any CA implementation doing
re-keying that has got that "right". Probably a reason why the practice
described by Laudon is the only thing that really works in open
environments.

I do however disagree that IDP only limit scope. IDP may e.g. have an
indirectCRL indicator which is a clear expansion of scope for the CRL.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Carl Wallace [mailto:[email-masked]]
> Sent: den 15 september 2004 13:28
> To: Stefan Santesson; 'Santosh Chokhani'; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> Inline...
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Stefan Santesson
> > Sent: Wednesday, September 15, 2004 5:22 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> > Santosh,
> >
> > You miss my point.
> >
> > I was expressing this generally but of course, in practice we only 
> > discuss the case where a CA is re-keyed without changing its name.
> >
> > The security vulnerability is then exposed if those 2 CA's keep 
> > issuing CRL's without IDP with scope limited to their respective 
> > issued certificates.
> 
> IDP is the means of limiting scope.  From 3280, "the issuing
distribution
> point is a critical CRL extension that identifies the CRL distribution 
> point and scope for a particular CRL."  If IDP is missing, how are the 
> CAs limiting scope?  Who is aware of this scope limitation?
> 
> > You showed this yourself in one of your examples before!
> >
> > I'm not aware of any section in RFC 3280 or X.509 that declare this 
> > practice invalid.
> 
> The following text from section 5.2.5 of 3280 declares this practice
> invalid: "if the distributionPoint field is absent, the CRL MUST
contain
> entries for all revoked unexpired certificates issued by the CRL
issuer,
> if
> any, within the scope of the CRL."  If an IDP is missing, so too is
the
> distributionPoint field.  Thus, "the CRL MUST contain entries for all 
> revoked, unexpired certificates issued by the CRL issuer".  An
instance
> where a CA issues CRLs that covers only certificates issued using a 
> particular key but does not include an IDP is broken.  The 3280 text
is
> broken too because the CRL issuer need not be the issuer of the 
> certificates just because there is no distributionPoint field.
> 
> > The RP software that doesn't enforce key match in this instance may 
> > now validate a certificate using the wrong CRL and come to the wrong 
> > conclusion.
> 
> While this is true, the problem begins with the CA limiting scope by
means
> other than IDP.
> 
> > If a CA and an RP deploys standards compliant configurations and the 
> > RP end up accepting a revoked certificate, this is a vulnerability.
> >
> > Now, another FACT is that if validation of CRL without IDP requires 
> > key match, then that would solve this vulnerability.
> 
> The fact is that without an IDP the CRL must be complete for all 
> certificates issued by the CRL issuer.  This leads back to the name 
> problem that is addressed elsewhere in this thread.
> 
> > Do we want to fix this problem in this way? That is another question 
> > open for debate...
> 
> I'd vote no to fixing this with key match.  If you want key match, use
a
> different IDP for each key.
> 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >

From: Sharon Boeyen <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 10:00:27 -0400
Sender: [email-masked]

Santosh I'm not sure what you are asking for comment on.

However, I do not want to see a change made that would invalidate currently
conformant implmentations that behave along the following lines:

- CA key rollover is handled with self-issued certificates (new key signed
with old and old key signed with new). Where this involves a full and
complete CRL for the CA, and there is no IDP present in the CRL, then the
CRL continues to list all revoked and unexpired certificates issued by that
CA, regardless of the key that had been originally used to sign the
certificate. 

Also I would not support any change that invalidated use of that same
technique (self issued certs) along with the use of CRLDP and IDP to handle
partitioned CRL environments. In this case again the partitioned CRLs can
continue to list all revoked unexpired certificates that point to that CRL
in their CRLDP regardless of the key that was used to sign that certificate
(either the old or new key). 

Yes there are implementations that behave this way if that is what you are
asking.

Cheers,
Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Wednesday, September 15, 2004 9:11 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Stefan:

I am not saying IDP only limits scope.  I am saying the only way to limit
scope (Since 3280 does not use CRL Scope extension) is to use IDP.  IDP
absent means (delta not withstanding) the CRL is complete for the Issuer,
and does not contain any revocation information about certificates issued by
other CAs and hence must not contain Certificate Issuer extension in any of
the CRL entries.

(BTW, when an IDP is asserted in a CRL, it does not mean the CRL is not
complete.  It is that relying party does not know whether it is complete or
not.  I would encourage you to read X.509 Annex B for further details.)

I would let the vendors respond if they do key rollover right.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2004 8:17 AM
To: Carl Wallace; Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Carl,

Thanks for some good technical arguments.

Your arguments of the scope if CRLs without IDP makes sense in the reading
of a CRL issuer as all instances of a CA (representing all issuing keys).

I must say though that this isn't very clearly stated in the standards
documents and hence it is easily misunderstood by implementers. 

So I don't disagree, but I wander if there is any CA implementation doing
re-keying that has got that "right". Probably a reason why the practice
described by Laudon is the only thing that really works in open
environments.

I do however disagree that IDP only limit scope. IDP may e.g. have an
indirectCRL indicator which is a clear expansion of scope for the CRL.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Carl Wallace [mailto:[email-masked]]
> Sent: den 15 september 2004 13:28
> To: Stefan Santesson; 'Santosh Chokhani'; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> Inline...
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stefan Santesson
> > Sent: Wednesday, September 15, 2004 5:22 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> > Santosh,
> >
> > You miss my point.
> >
> > I was expressing this generally but of course, in practice we only
> > discuss the case where a CA is re-keyed without changing its name.
> >
> > The security vulnerability is then exposed if those 2 CA's keep
> > issuing CRL's without IDP with scope limited to their respective 
> > issued certificates.
> 
> IDP is the means of limiting scope.  From 3280, "the issuing
distribution
> point is a critical CRL extension that identifies the CRL distribution
> point and scope for a particular CRL."  If IDP is missing, how are the 
> CAs limiting scope?  Who is aware of this scope limitation?
> 
> > You showed this yourself in one of your examples before!
> >
> > I'm not aware of any section in RFC 3280 or X.509 that declare this
> > practice invalid.
> 
> The following text from section 5.2.5 of 3280 declares this practice
> invalid: "if the distributionPoint field is absent, the CRL MUST
contain
> entries for all revoked unexpired certificates issued by the CRL
issuer,
> if
> any, within the scope of the CRL."  If an IDP is missing, so too is
the
> distributionPoint field.  Thus, "the CRL MUST contain entries for all
> revoked, unexpired certificates issued by the CRL issuer".  An
instance
> where a CA issues CRLs that covers only certificates issued using a
> particular key but does not include an IDP is broken.  The 3280 text
is
> broken too because the CRL issuer need not be the issuer of the
> certificates just because there is no distributionPoint field.
> 
> > The RP software that doesn't enforce key match in this instance may
> > now validate a certificate using the wrong CRL and come to the wrong 
> > conclusion.
> 
> While this is true, the problem begins with the CA limiting scope by
means
> other than IDP.
> 
> > If a CA and an RP deploys standards compliant configurations and the
> > RP end up accepting a revoked certificate, this is a vulnerability.
> >
> > Now, another FACT is that if validation of CRL without IDP requires
> > key match, then that would solve this vulnerability.
> 
> The fact is that without an IDP the CRL must be complete for all
> certificates issued by the CRL issuer.  This leads back to the name 
> problem that is addressed elsewhere in this thread.
> 
> > Do we want to fix this problem in this way? That is another question
> > open for debate...
> 
> I'd vote no to fixing this with key match.  If you want key match, use
a
> different IDP for each key.
> 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 09:16:08 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

See responses in-line.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2004 9:02 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

Thanks for this interesting dialogue.

I finally got what I needed to get the picture complete.

That is that the standards actually REQUIRE that a CRL without IDP MUST
contain revocation information for all certificates for all instances of a
CA representing all issuing keys. That aspect, if so, was not clear to me.

I think the standards are in a need for some serious clarifications around
this issue. I'm prety convinced that the writers didn't have this in mind
when writing the text.

[Since I have been involved in crafting portions of X.509 and since Annex B
that is normative makes this abundantly clear, I beg to differ that it is
not clear enough or authors of the text did not have this in mind.  Any
suggestion to make it clearer in X.509 are welcome.]

This discussion has also revealed that we have practical security and
interoperability issues in installed based of products.

[I agree.  I have been saying this since September 2002 when I found out
about it.  My only solution is to change the name when you rekey]

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 15 september 2004 13:33
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> I think you are missing the point.  When the relying party matches the
DNs
> one for (ignoring self-issued certificates), then it know even if the
CRL
> is
> signed by different keys, it is a CRL from the same CA.  Of course,
the
> relying party must enforce an IDP if asserted in the CRL.  But, now,
the
> rekeyed CA can issue non-IDP CRL and the relying party knows that the
CRL
> is
> from the same CA, obviating the need for using the same key.
Essentially,
> key match is being replaced by this algorithm.
> 
> See specific responses in-line.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Wednesday, September 15, 2004 5:22 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> Santosh,
> 
> You miss my point.
> 
> I was expressing this generally but of course, in practice we only
discuss
> the case where a CA is re-keyed without changing its name.
> 
> [This is the case (no name change) for which we need the algorithm]
> 
> The security vulnerability is then exposed if those 2 CA's keep
issuing
> CRL's without IDP with scope limited to their respective issued 
> certificates.
> 
> [Right.  That is what I have been saying all along.  Each of the two
keys
> should be used to sign the full CRL for the scope of all certificates 
> issued by that CA under all keys.  Furthermore, the same revoked 
> certificate
list
> (empty or not) should be signed with all active keys.  Active keys are 
> defined as those CA private keys whose companion public keys can still
be
> used to verify signatures on the certificates]
> 
> You showed this yourself in one of your examples before!
> 
> I'm not aware of any section in RFC 3280 or X.509 that declare this 
> practice invalid.
> 
> [Which practice you are talking about?  Both RFC 3280 and X.509 states
it.
> X.509 clearly define that absence of IDP means it is a complete for
that
> CA.
> (again delta is an orthogonal issue)  3280 may not state it clearly,
but
> look at section 6.3.3.b.2 in general and 6.3.3.b.2.i in particular.
You
> will reach the same conclusion.]
> 
> The RP software that doesn't enforce key match in this instance may
now
> validate a certificate using the wrong CRL and come to the wrong 
> conclusion.
> 
> [This is because the CA generated a partial CRL and did not tell the 
> relying party.  I think it is inappropriate to argue that when the CA 
> violates
the
> standard and client follows the standard and security breaks, let us 
> design a client that also does not follow the standard.]
> 
> If a CA and an RP deploys standards compliant configurations and the
RP
> end
> up accepting a revoked certificate, this is a vulnerability.
> 
> [If the CA employed standard compliant configuration, it will either 
> assert an IDP or cover all certificates (e.g., 1-200 in the example I 
> gave
few
> days
> back), the relying party will not have a problem.  That is what I have 
> been saying all along.  The DN matching is simply to tighten up the
situation
> if
> the relying party trusts two CAs with the same name some place in its 
> trust hierarchy.]
> 
> Now, another FACT is that if validation of CRL without IDP requires
key
> match, then that would solve this vulnerability.
> 
> [IDP and key match are not related.  MS CA requires that since it does
not
> follow the standards]
> 
> Do we want to fix this problem in this way? That is another question
open
> for debate...
> 
> [As I have said, I do not mind fixing the problem either the way I
propose
> or the MS does.  I do not have a dog in the fight except to get it
right
> for
> my customers.  If we use MS ways, it will break backward
compatibility,
> make
> other vendors change, will require a change in the standard, and will 
> remove a feature regarding signing CRL with different key.  In that 
> case, we might
> as well get rid of cRLSign bit.  Also, we will need to deprecate
indirect
> CRL or using the logic I proposed or something akin or require local 
> policy o ensure that the indirect issuer is the one certificate issuer
> recommended.
> This is due to the fact that name binding does not ensure you are
getting
> the object (namely CRL) from the correct name since there may be name 
> collisions when you have multiple trust anchors or when name
uniqueness of
> the CAs is not guaranteed in a trust graph (e.g., across multiple
tiers of
> a
> trust hierarchy]
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 14 september 2004 20:58
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Stefan:
> >
> > If the relying party has two CA's with the same name X, but really 
> > represent different real entities, the relying party is going to
have
> > bigger
> problem
> > of disambiguation than correct CRL.
> >
> > Similarly, if the relying party has two intermediate CAs named Y,
> under
> > the
> > same certification path, you have bigger problem of disambiguation
> than
> > correct CRL.  Also, no CA I know will certify the two different CAs
> with
> > the
> > same name.  That has to happen for this to occur.
> >
> > So, I will assume that neither of these two is the case.
> >
> > Then, the problem boils down of matching the certification path for
> the
> > certificate and the certification path for the CRL used to check the 
> > revocation status of the certificate.
> >
> > The following rules should be used to ensure that you have the CRL
> from
> > the
> > appropriate CA:
> >
> > 1.  The DN of the root in both cases must match.
> >
> > 2.  Set I = 1.  N1 = number of certificates in the "certificate 
> > certification path", ignoring self-issued certificates.  Set N2 =
> number
> > of
> > certificates in the "CRL certification path", ignoring self-issued 
> > certificates.
> >
> > 3.  If I = N1 or I = N2 exit with success
> >
> > 4.  Verify that the issuer DN in certificate I in the "certificate 
> > certification path" matches the issuer DN in certificate I in the
"CRL
> > certification path", ignoring self-issued certificates.
> >
> > 5.  Verify that the subject DN in  certificate I in the "certificate 
> > certification path" matches the subject DN in certificate I in the
> "CRL
> > certification path", ignoring self-issued certificates.
> >
> > 6.  I = I + 1.  Go to step 3
> >
> > {BTW, this has been explored and explained on this mail list couple
of
> > times)
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Tuesday, September 14, 2004 9:52 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> >
> > Santosh.
> >
> > CA1 and CA1(bis) have the same name but different keys.
> >
> > They are both valid in the RPs trust configuration.
> >
> > Both CAs issue CRLs without IDP (which is RFC 3280 and X.509
compliant
> > practice).
> >
> > Result: The RP can't determine what CRL and what CA belongs together 
> > resulting in false acceptance of revoked certificates.
> >
> > You can call it what you want.
> > I call that a security vulnerability.
> >
> > /Stefan
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Santosh Chokhani
> > > Sent: den 14 september 2004 14:36
> > > To: [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > > Stefan:
> > >
> > > There is no security problem in building a certification path for
> the
> > CRL
> > > Issuer when the same CA issues the CRL, but signs the CRL using a 
> > > different key (i.e., different from the one used to sign the 
> > > certificate being validated).
> > >
> > > You can build a path.  You do need to do name matching as I have
> said
> > in
> > > several previous postings.
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On
> > > Behalf Of Stefan Santesson
> > > Sent: Tuesday, September 14, 2004 7:09 AM
> > > To: Manger, James H; [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > >
> > > James,
> > >
> > > I don't agree with your examples.
> > >
> > > The "simple" structure that dominates deployment today is 1 CA = 1
> key
> > > which has the consequences you mention.
> > >
> > > However, the stanards define also indirect CRLs which can be used
to
> > solve
> > > all your issues below EVEN if you stick with the definition 1 CA =
1
> > key.
> > >
> > > The issue at hand, previously stated to Santosh is whether a CRL
> > without
> > > IDP
> > > can be validated with another key than the one used to validate 
> > > certificates issued by the CA.
> > >
> > > If that is allowed, then we have identified a security problem
that
> > ought
> > > to
> > > be fixed.
> > >
> > > /Stefan
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > > On Behalf Of Manger, James H
> > > > Sent: den 14 september 2004 06:36
> > > > To: [email-masked]
> > > > Subject: RE: CA Rekey and CRL Validation
> > > >
> > > >
> > > > Same name, different key = SAME CA.
> > > >
> > > > Without this, if a CA's private key is destroyed no CRLs can
ever
> be
> > > > issued again for the certs it has issued so that CA's whole PKI
> > > crumbles
> > > > in an instant.
> > > > Without this, every CA needs to keep operating (issuing CRLs)
> after
> > it
> > > has
> > > > issued its last cert for the lifetime it was putting in certs
(eg
> 2,
> > > 5, 10
> > > > years?).
> > > > Without this, every certifier wanting to periodically change
keys
> > > (which
> > > > is good practice) needs to run multiple CAs.
> > > >
> > > >
> > > >
> > > >
> > > > P.S. There are ways to ensure name uniqueness for CAs -- either 
> > > > concatenate issuer names from a trust anchor to the CA of
interest
> > to
> > > get
> > > > that CA's "name", or just use the issuer field for that CA and
> rely
> > on
> > > > your configured trusted anchors to name CAs in a way that avoids
> > > ambiguity
> > > > (which is, in fact, the primary reason for a PKI in the first
> > place).
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Stefan Santesson [mailto:[email-masked]]
> > > > Sent: Tuesday, 14 September 2004 8:53 AM
> > > > To: Santosh Chokhani; [email-masked]
> > > > Subject: RE: CA Rekey and CRL Validation
> > > >
> > > >
> > > >
> > > > Santosh,
> > > >
> > > > I realize that the standard is not crystal clear on this issue
and
> I
> > > > suggest that you either have the wrong interpretation, or at
least
> > use
> > > > an interpretation that ought to be wrong.
> > > >
> > > > The core issue is whether two CAs having the same name but
> different
> > > > private issuing keys, are regarded as 1 CA or 2 separate CAs.
> > > >
> > > > I suggest (and hope) that these are NOT defined anywhere as
being
> > the
> > > > same CA. This is also supported by the reality fact that there
is
> no
> > > way
> > > > that you can ensure name uniqueness between CAs and therefore,
> > > key-match
> > > > should be a requirement.
> > > >
> > > > From this perspective standards states the following:
> > > >
> > > > X.509 Annex B states:
> > > >
> > > >    If the cRLIssuer field is absent from the CRL distribution
> point
> > > > extension of the certificate, the CRL shall be signed by the
same
> CA
> > > > that signed the certificate; and
> > > >    If the cRLIssuer field is present in the CRL distribution
point
> > > > extension of the certificate, the CRL shall be signed by the CRL
> > > Issuer
> > > > identified in the CRL distribution point extension of the
> > certificate
> > > > and the CRL shall contain the indirectCRL field in the issuing 
> > > > distribution point extension.
> > > >
> > > > RFC 3280 5.2.5 states:
> > > >
> > > >    The CRL issuer MUST assert the indirectCRL boolean, if the
> scope
> > of
> > > >    the CRL includes certificates issued by authorities other
than
> > the
> > > >    CRL issuer.
> > > >
> > > >
> > > > So IF different signing keys means that CA(old) and CA(new) are 
> > > > different CAs (despite identical names), then in order to allow
> > > CRL(new)
> > > > from CA(new) to be used to validate certificates from CA(old),
> then
> > > > CRL(new) need to contain an IDP with indirectCRL asserted,
> > > certificates
> > > > from CA(old) must also contain a CDP with cRLIssuer field.
> > > >
> > > > I suggest therefore that a CRL without IDP with indirectCRL is
> > > required
> > > > to be signed with the same key that was used to sign the
> certificate
> > > > being validated.
> > > >
> > > > If that is not clear by today's standard text, then I suggest
that
> > it
> > > > should.
> > > >
> > > >
> > > > Stefan Santesson
> > > > Microsoft Security Center of Excellence (SCOE)
> > >
> > >
> >
> >
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 09:10:55 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

I am not saying IDP only limits scope.  I am saying the only way to limit
scope (Since 3280 does not use CRL Scope extension) is to use IDP.  IDP
absent means (delta not withstanding) the CRL is complete for the Issuer,
and does not contain any revocation information about certificates issued by
other CAs and hence must not contain Certificate Issuer extension in any of
the CRL entries.

(BTW, when an IDP is asserted in a CRL, it does not mean the CRL is not
complete.  It is that relying party does not know whether it is complete or
not.  I would encourage you to read X.509 Annex B for further details.)

I would let the vendors respond if they do key rollover right.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2004 8:17 AM
To: Carl Wallace; Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Carl,

Thanks for some good technical arguments.

Your arguments of the scope if CRLs without IDP makes sense in the reading
of a CRL issuer as all instances of a CA (representing all issuing keys).

I must say though that this isn't very clearly stated in the standards
documents and hence it is easily misunderstood by implementers. 

So I don't disagree, but I wander if there is any CA implementation doing
re-keying that has got that "right". Probably a reason why the practice
described by Laudon is the only thing that really works in open
environments.

I do however disagree that IDP only limit scope. IDP may e.g. have an
indirectCRL indicator which is a clear expansion of scope for the CRL.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Carl Wallace [mailto:[email-masked]]
> Sent: den 15 september 2004 13:28
> To: Stefan Santesson; 'Santosh Chokhani'; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> Inline...
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Stefan Santesson
> > Sent: Wednesday, September 15, 2004 5:22 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> > Santosh,
> >
> > You miss my point.
> >
> > I was expressing this generally but of course, in practice we only 
> > discuss the case where a CA is re-keyed without changing its name.
> >
> > The security vulnerability is then exposed if those 2 CA's keep 
> > issuing CRL's without IDP with scope limited to their respective 
> > issued certificates.
> 
> IDP is the means of limiting scope.  From 3280, "the issuing
distribution
> point is a critical CRL extension that identifies the CRL distribution 
> point and scope for a particular CRL."  If IDP is missing, how are the 
> CAs limiting scope?  Who is aware of this scope limitation?
> 
> > You showed this yourself in one of your examples before!
> >
> > I'm not aware of any section in RFC 3280 or X.509 that declare this 
> > practice invalid.
> 
> The following text from section 5.2.5 of 3280 declares this practice
> invalid: "if the distributionPoint field is absent, the CRL MUST
contain
> entries for all revoked unexpired certificates issued by the CRL
issuer,
> if
> any, within the scope of the CRL."  If an IDP is missing, so too is
the
> distributionPoint field.  Thus, "the CRL MUST contain entries for all 
> revoked, unexpired certificates issued by the CRL issuer".  An
instance
> where a CA issues CRLs that covers only certificates issued using a 
> particular key but does not include an IDP is broken.  The 3280 text
is
> broken too because the CRL issuer need not be the issuer of the 
> certificates just because there is no distributionPoint field.
> 
> > The RP software that doesn't enforce key match in this instance may 
> > now validate a certificate using the wrong CRL and come to the wrong 
> > conclusion.
> 
> While this is true, the problem begins with the CA limiting scope by
means
> other than IDP.
> 
> > If a CA and an RP deploys standards compliant configurations and the 
> > RP end up accepting a revoked certificate, this is a vulnerability.
> >
> > Now, another FACT is that if validation of CRL without IDP requires 
> > key match, then that would solve this vulnerability.
> 
> The fact is that without an IDP the CRL must be complete for all 
> certificates issued by the CRL issuer.  This leads back to the name 
> problem that is addressed elsewhere in this thread.
> 
> > Do we want to fix this problem in this way? That is another question 
> > open for debate...
> 
> I'd vote no to fixing this with key match.  If you want key match, use
a
> different IDP for each key.
> 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 14:02:04 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

Thanks for this interesting dialogue.

I finally got what I needed to get the picture complete.

That is that the standards actually REQUIRE that a CRL without IDP MUST
contain revocation information for all certificates for all instances of
a CA representing all issuing keys. That aspect, if so, was not clear to
me.

I think the standards are in a need for some serious clarifications
around this issue. I'm prety convinced that the writers didn't have this
in mind when writing the text.

This discussion has also revealed that we have practical security and
interoperability issues in installed based of products.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 15 september 2004 13:33
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> I think you are missing the point.  When the relying party matches the
DNs
> one for (ignoring self-issued certificates), then it know even if the
CRL
> is
> signed by different keys, it is a CRL from the same CA.  Of course,
the
> relying party must enforce an IDP if asserted in the CRL.  But, now,
the
> rekeyed CA can issue non-IDP CRL and the relying party knows that the
CRL
> is
> from the same CA, obviating the need for using the same key.
Essentially,
> key match is being replaced by this algorithm.
> 
> See specific responses in-line.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Wednesday, September 15, 2004 5:22 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> Santosh,
> 
> You miss my point.
> 
> I was expressing this generally but of course, in practice we only
discuss
> the case where a CA is re-keyed without changing its name.
> 
> [This is the case (no name change) for which we need the algorithm]
> 
> The security vulnerability is then exposed if those 2 CA's keep
issuing
> CRL's without IDP with scope limited to their respective issued
> certificates.
> 
> [Right.  That is what I have been saying all along.  Each of the two
keys
> should be used to sign the full CRL for the scope of all certificates
> issued
> by that CA under all keys.  Furthermore, the same revoked certificate
list
> (empty or not) should be signed with all active keys.  Active keys are
> defined as those CA private keys whose companion public keys can still
be
> used to verify signatures on the certificates]
> 
> You showed this yourself in one of your examples before!
> 
> I'm not aware of any section in RFC 3280 or X.509 that declare this
> practice
> invalid.
> 
> [Which practice you are talking about?  Both RFC 3280 and X.509 states
it.
> X.509 clearly define that absence of IDP means it is a complete for
that
> CA.
> (again delta is an orthogonal issue)  3280 may not state it clearly,
but
> look at section 6.3.3.b.2 in general and 6.3.3.b.2.i in particular.
You
> will reach the same conclusion.]
> 
> The RP software that doesn't enforce key match in this instance may
now
> validate a certificate using the wrong CRL and come to the wrong
> conclusion.
> 
> [This is because the CA generated a partial CRL and did not tell the
> relying
> party.  I think it is inappropriate to argue that when the CA violates
the
> standard and client follows the standard and security breaks, let us
> design
> a client that also does not follow the standard.]
> 
> If a CA and an RP deploys standards compliant configurations and the
RP
> end
> up accepting a revoked certificate, this is a vulnerability.
> 
> [If the CA employed standard compliant configuration, it will either
> assert
> an IDP or cover all certificates (e.g., 1-200 in the example I gave
few
> days
> back), the relying party will not have a problem.  That is what I have
> been
> saying all along.  The DN matching is simply to tighten up the
situation
> if
> the relying party trusts two CAs with the same name some place in its
> trust
> hierarchy.]
> 
> Now, another FACT is that if validation of CRL without IDP requires
key
> match, then that would solve this vulnerability.
> 
> [IDP and key match are not related.  MS CA requires that since it does
not
> follow the standards]
> 
> Do we want to fix this problem in this way? That is another question
open
> for debate...
> 
> [As I have said, I do not mind fixing the problem either the way I
propose
> or the MS does.  I do not have a dog in the fight except to get it
right
> for
> my customers.  If we use MS ways, it will break backward
compatibility,
> make
> other vendors change, will require a change in the standard, and will
> remove
> a feature regarding signing CRL with different key.  In that case, we
> might
> as well get rid of cRLSign bit.  Also, we will need to deprecate
indirect
> CRL or using the logic I proposed or something akin or require local
> policy
> o ensure that the indirect issuer is the one certificate issuer
> recommended.
> This is due to the fact that name binding does not ensure you are
getting
> the object (namely CRL) from the correct name since there may be name
> collisions when you have multiple trust anchors or when name
uniqueness of
> the CAs is not guaranteed in a trust graph (e.g., across multiple
tiers of
> a
> trust hierarchy]
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 14 september 2004 20:58
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Stefan:
> >
> > If the relying party has two CA's with the same name X, but really
> > represent different real entities, the relying party is going to
have
> > bigger
> problem
> > of disambiguation than correct CRL.
> >
> > Similarly, if the relying party has two intermediate CAs named Y,
> under
> > the
> > same certification path, you have bigger problem of disambiguation
> than
> > correct CRL.  Also, no CA I know will certify the two different CAs
> with
> > the
> > same name.  That has to happen for this to occur.
> >
> > So, I will assume that neither of these two is the case.
> >
> > Then, the problem boils down of matching the certification path for
> the
> > certificate and the certification path for the CRL used to check the
> > revocation status of the certificate.
> >
> > The following rules should be used to ensure that you have the CRL
> from
> > the
> > appropriate CA:
> >
> > 1.  The DN of the root in both cases must match.
> >
> > 2.  Set I = 1.  N1 = number of certificates in the "certificate
> > certification path", ignoring self-issued certificates.  Set N2 =
> number
> > of
> > certificates in the "CRL certification path", ignoring self-issued
> > certificates.
> >
> > 3.  If I = N1 or I = N2 exit with success
> >
> > 4.  Verify that the issuer DN in certificate I in the "certificate
> > certification path" matches the issuer DN in certificate I in the
"CRL
> > certification path", ignoring self-issued certificates.
> >
> > 5.  Verify that the subject DN in  certificate I in the "certificate
> > certification path" matches the subject DN in certificate I in the
> "CRL
> > certification path", ignoring self-issued certificates.
> >
> > 6.  I = I + 1.  Go to step 3
> >
> > {BTW, this has been explored and explained on this mail list couple
of
> > times)
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Tuesday, September 14, 2004 9:52 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> >
> > Santosh.
> >
> > CA1 and CA1(bis) have the same name but different keys.
> >
> > They are both valid in the RPs trust configuration.
> >
> > Both CAs issue CRLs without IDP (which is RFC 3280 and X.509
compliant
> > practice).
> >
> > Result: The RP can't determine what CRL and what CA belongs together
> > resulting in false acceptance of revoked certificates.
> >
> > You can call it what you want.
> > I call that a security vulnerability.
> >
> > /Stefan
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Santosh Chokhani
> > > Sent: den 14 september 2004 14:36
> > > To: [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > > Stefan:
> > >
> > > There is no security problem in building a certification path for
> the
> > CRL
> > > Issuer when the same CA issues the CRL, but signs the CRL using a
> > > different key (i.e., different from the one used to sign the
> > > certificate being validated).
> > >
> > > You can build a path.  You do need to do name matching as I have
> said
> > in
> > > several previous postings.
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On
> > > Behalf Of Stefan Santesson
> > > Sent: Tuesday, September 14, 2004 7:09 AM
> > > To: Manger, James H; [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > >
> > > James,
> > >
> > > I don't agree with your examples.
> > >
> > > The "simple" structure that dominates deployment today is 1 CA = 1
> key
> > > which has the consequences you mention.
> > >
> > > However, the stanards define also indirect CRLs which can be used
to
> > solve
> > > all your issues below EVEN if you stick with the definition 1 CA =
1
> > key.
> > >
> > > The issue at hand, previously stated to Santosh is whether a CRL
> > without
> > > IDP
> > > can be validated with another key than the one used to validate
> > > certificates issued by the CA.
> > >
> > > If that is allowed, then we have identified a security problem
that
> > ought
> > > to
> > > be fixed.
> > >
> > > /Stefan
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > > On Behalf Of Manger, James H
> > > > Sent: den 14 september 2004 06:36
> > > > To: [email-masked]
> > > > Subject: RE: CA Rekey and CRL Validation
> > > >
> > > >
> > > > Same name, different key = SAME CA.
> > > >
> > > > Without this, if a CA's private key is destroyed no CRLs can
ever
> be
> > > > issued again for the certs it has issued so that CA's whole PKI
> > > crumbles
> > > > in an instant.
> > > > Without this, every CA needs to keep operating (issuing CRLs)
> after
> > it
> > > has
> > > > issued its last cert for the lifetime it was putting in certs
(eg
> 2,
> > > 5, 10
> > > > years?).
> > > > Without this, every certifier wanting to periodically change
keys
> > > (which
> > > > is good practice) needs to run multiple CAs.
> > > >
> > > >
> > > >
> > > >
> > > > P.S. There are ways to ensure name uniqueness for CAs -- either
> > > > concatenate issuer names from a trust anchor to the CA of
interest
> > to
> > > get
> > > > that CA's "name", or just use the issuer field for that CA and
> rely
> > on
> > > > your configured trusted anchors to name CAs in a way that avoids
> > > ambiguity
> > > > (which is, in fact, the primary reason for a PKI in the first
> > place).
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Stefan Santesson [mailto:[email-masked]]
> > > > Sent: Tuesday, 14 September 2004 8:53 AM
> > > > To: Santosh Chokhani; [email-masked]
> > > > Subject: RE: CA Rekey and CRL Validation
> > > >
> > > >
> > > >
> > > > Santosh,
> > > >
> > > > I realize that the standard is not crystal clear on this issue
and
> I
> > > > suggest that you either have the wrong interpretation, or at
least
> > use
> > > > an interpretation that ought to be wrong.
> > > >
> > > > The core issue is whether two CAs having the same name but
> different
> > > > private issuing keys, are regarded as 1 CA or 2 separate CAs.
> > > >
> > > > I suggest (and hope) that these are NOT defined anywhere as
being
> > the
> > > > same CA. This is also supported by the reality fact that there
is
> no
> > > way
> > > > that you can ensure name uniqueness between CAs and therefore,
> > > key-match
> > > > should be a requirement.
> > > >
> > > > From this perspective standards states the following:
> > > >
> > > > X.509 Annex B states:
> > > >
> > > >    If the cRLIssuer field is absent from the CRL distribution
> point
> > > > extension of the certificate, the CRL shall be signed by the
same
> CA
> > > > that signed the certificate; and
> > > >    If the cRLIssuer field is present in the CRL distribution
point
> > > > extension of the certificate, the CRL shall be signed by the CRL
> > > Issuer
> > > > identified in the CRL distribution point extension of the
> > certificate
> > > > and the CRL shall contain the indirectCRL field in the issuing
> > > > distribution point extension.
> > > >
> > > > RFC 3280 5.2.5 states:
> > > >
> > > >    The CRL issuer MUST assert the indirectCRL boolean, if the
> scope
> > of
> > > >    the CRL includes certificates issued by authorities other
than
> > the
> > > >    CRL issuer.
> > > >
> > > >
> > > > So IF different signing keys means that CA(old) and CA(new) are
> > > > different CAs (despite identical names), then in order to allow
> > > CRL(new)
> > > > from CA(new) to be used to validate certificates from CA(old),
> then
> > > > CRL(new) need to contain an IDP with indirectCRL asserted,
> > > certificates
> > > > from CA(old) must also contain a CDP with cRLIssuer field.
> > > >
> > > > I suggest therefore that a CRL without IDP with indirectCRL is
> > > required
> > > > to be signed with the same key that was used to sign the
> certificate
> > > > being validated.
> > > >
> > > > If that is not clear by today's standard text, then I suggest
that
> > it
> > > > should.
> > > >
> > > >
> > > > Stefan Santesson
> > > > Microsoft Security Center of Excellence (SCOE)
> > >
> > >
> >
> >
> 
> 

From: "Faisal Maqsood" <[email-masked]>
To: <[email-masked]>, "Trevor Freeman" <[email-masked]>
Subject: SCVP CertReply Status
Date: Wed, 15 Sep 2004 17:32:05 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_015B_01C49B49.EB2F9AE0
Content-Type: text/plain;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

H=00i=00,=00=0D=00=0A=
=00=0D=00=0A=
=00S=00C=00V=00P=00 =00d=00r=00a=00f=00t=00 =001=005=00,=00 =
=00s=00e=00c=00t=00i=00o=00n=00 =004=00.=008=00 =
=00r=00e=00p=00l=00y=00O=00b=00j=00e=00c=00t=00s=00,=00 =
=00C=00e=00r=00t=00R=00e=00p=00l=00y=00 =
=00s=00t=00r=00u=00c=00t=00u=00r=00e=00:=00=0D=00=0A=
=00 =00 =001=00.=00.=00 =00I=00f=00 =00s=00e=00r=00v=00e=00r=00 =
=00c=00h=00o=00o=00s=00e=00s=00 =
=00r=00e=00p=00l=00y=00S=00t=00a=00t=00u=00s=00 =00a=00s=00 =
=00M=00a=00l=00f=00o=00r=00m=00e=00d=00P=00K=00C=00 =00(=003=00)=00,=00 =
=00M=00a=00l=00f=00o=00r=00m=00e=00d=00A=00C=00 =00(=004=00)=00,=00 =
=00U=00n=00r=00e=00c=00o=00g=00n=00i=00z=00e=00d=00C=00e=00r=00t=00P=00o=00=
l=00i=00c=00y=00 =00(=005=00)=00 =00o=00r=00 =
=00U=00n=00r=00e=00c=00o=00g=00n=00i=00z=00e=00d=00E=00x=00t=00e=00n=00s=00=
i=00o=00n=00 =00(=007=00)=00,=00 =00h=00o=00w=00 =00i=00s=00 =00i=00t=00 =
=00p=00o=00s=00s=00i=00b=00l=00e=00 =00t=00o=00 =00s=00e=00t=00 =
=00R=00e=00p=00l=00y=00C=00h=00e=00c=00k=00s=00 =
=00a=00n=00d=00/=00o=00r=00 =
=00R=00e=00p=00l=00y=00W=00a=00n=00t=00B=00a=00c=00k=00s=00 =00i=00n=00 =
=00t=00h=00i=00s=00 =00c=00a=00s=00e=00?=00=0D=00=0A=
=00 =00 =002=00.=00.=00 =00I=00f=00 =00s=00e=00r=00v=00e=00r=00 =
=00c=00h=00o=00o=00s=00e=00s=00 =
=00r=00e=00p=00l=00y=00S=00t=00a=00t=00u=00s=00 =00a=00s=00 =
=00U=00n=00r=00e=00c=00o=00g=00n=00i=00z=00e=00d=00V=00a=00l=00P=00o=00l=00=
i=00c=00y=00 =00(=006=00)=00,=00 =00i=00s=00 =00i=00t=00 =
=00p=00o=00s=00s=00i=00b=00l=00e=00 =00t=00h=00a=00t=00 =
=00s=00e=00r=00v=00e=00r=00 =00p=00r=00o=00c=00e=00s=00s=00 =
=00t=00h=00e=00 =00w=00h=00o=00l=00e=00 =
=00r=00e=00q=00u=00e=00s=00t=00?=00 =00I=00 =00t=00h=00i=00n=00k=00 =
=00t=00h=00i=00s=00 =00s=00t=00a=00t=00u=00s=00 =00c=00o=00d=00e=00 =
=00s=00h=00o=00u=00l=00d=00 =00b=00e=00l=00o=00n=00g=00 =00t=00o=00 =
=00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00i=00n=00s=00t=00e=00a=00d=00 =00o=00f=00 =
=00C=00e=00r=00t=00R=00e=00p=00l=00y=00=0D=00=0A=
=00 =00 =003=00.=00.=00 =00I=00f=00 =00s=00e=00r=00v=00e=00r=00 =
=00c=00h=00o=00o=00s=00e=00s=00 =
=00r=00e=00p=00l=00y=00S=00t=00a=00t=00u=00s=00 =00a=00s=00 =
=00C=00e=00r=00t=00P=00a=00t=00h=00N=00o=00t=00V=00a=00l=00i=00d=00N=00o=00=
w=00 =00(=001=002=00)=00 =00a=00n=00d=00 =00r=00e=00a=00s=00o=00n=00 =
=00i=00s=00 =00t=00h=00a=00t=00 =00s=00e=00r=00v=00e=00r=00 =
=00c=00a=00n=00 =00n=00o=00t=00 =00c=00o=00n=00n=00e=00c=00t=00 =
=00t=00o=00 =
=00O=00C=00S=00P=00R=00e=00s=00p=00o=00n=00d=00e=00r=00/=00L=00D=00A=00P=00=
S=00e=00r=00v=00e=00r=00 =00a=00n=00d=00 =00s=00o=00 =00h=00a=00v=00e=00 =
=00n=00o=00 =00r=00e=00v=00o=00c=00a=00t=00i=00o=00n=00 =
=00i=00n=00f=00o=00r=00m=00a=00t=00i=00o=00n=00 =00f=00o=00r=00 =
=00t=00h=00e=00 =00t=00i=00m=00e=00 =00b=00e=00i=00n=00g=00 =
=00t=00h=00e=00n=00 =00w=00h=00a=00t=00 =00s=00h=00o=00u=00l=00d=00 =
=00s=00e=00r=00v=00e=00r=00 =00p=00u=00t=00 =00i=00n=00 =
=00R=00e=00p=00l=00y=00W=00a=00n=00t=00B=00a=00c=00k=00s=00?=00=0D=00=0A=
=00C=00a=00n=00 =00s=00o=00m=00e=00o=00n=00e=00 =
=00c=00l=00a=00r=00i=00f=00y=00?=00=0D=00=0A=
=00=0D=00=0A=
=00R=00e=00g=00a=00r=00d=00s=00,=00=0D=00=0A=
=00F=00a=00i=00s=00a=00l=00=0D=00=0A=
=00=0D=00=0A=
=00
------=_NextPart_000_015B_01C49B49.EB2F9AE0
Content-Type: text/html;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

=FF=FE<=00!=00D=00O=00C=00T=00Y=00P=00E=00 =00H=00T=00M=00L=00 =
=00P=00U=00B=00L=00I=00C=00 =
=00"=00-=00/=00/=00W=003=00C=00/=00/=00D=00T=00D=00 =00H=00T=00M=00L=00 =
=004=00.=000=00 =
=00T=00r=00a=00n=00s=00i=00t=00i=00o=00n=00a=00l=00/=00/=00E=00N=00"=00>=00=
=0D=00=0A=
=00<=00H=00T=00M=00L=00 =00x=00m=00l=00n=00s=00:=00s=00t=001=00 =
=00=3D=00 =
=00"=00u=00r=00n=00:=00s=00c=00h=00e=00m=00a=00s=00-=00m=00i=00c=00r=00o=00=
s=00o=00f=00t=00-=00c=00o=00m=00:=00o=00f=00f=00i=00c=00e=00:=00s=00m=00a=
=00r=00t=00t=00a=00g=00s=00"=00 =00x=00m=00l=00n=00s=00:=00o=00 =
=00=3D=00 =00=0D=00=0A=
=00"=00u=00r=00n=00:=00s=00c=00h=00e=00m=00a=00s=00-=00m=00i=00c=00r=00o=00=
s=00o=00f=00t=00-=00c=00o=00m=00:=00o=00f=00f=00i=00c=00e=00:=00o=00f=00f=
=00i=00c=00e=00"=00>=00<=00H=00E=00A=00D=00>=00<=00B=00A=00S=00E=00 =
=00=0D=00=0A=
=00h=00r=00e=00f=00=3D=00"=00f=00i=00l=00e=00:=00/=00/=00F=00:=00\=00_=00=
B=00a=00c=00k=00U=00p=00-=00F=00M=00\=00E=00m=00a=00i=00l=00 =
=00S=00i=00g=00n=00a=00t=00u=00r=00e=00\=00"=00>=00=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00h=00t=00t=00p=00-=00e=00q=00u=00i=00v=00=3D=00C=00o=00n=00t=00e=00n=00=
t=00-=00T=00y=00p=00e=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00t=00e=00x=00t=00/=00h=00t=00m=00=
l=00;=00 =
=00c=00h=00a=00r=00s=00e=00t=00=3D=00u=00n=00i=00c=00o=00d=00e=00"=00>=00=
=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00M=00L=00 =
=005=00.=005=000=00.=004=001=003=004=00.=006=000=000=00"=00 =
=00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00<=00/=00=
H=00E=00A=00D=00>=00=0D=00=0A=
=00<=00B=00O=00D=00Y=00 =00d=00i=00r=00=3D=00l=00t=00r=00 =
=00b=00g=00C=00o=00l=00o=00r=00=3D=00#=00f=00f=00f=00f=00f=00f=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00H=00i=00,=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00S=00C=00V=00P=00 =00d=00r=00a=00f=00t=00 =
=001=005=00,=00 =00s=00e=00c=00t=00i=00o=00n=00 =004=00.=008=00 =
=00r=00e=00p=00l=00y=00O=00b=00j=00e=00c=00t=00s=00,=00 =
=00C=00e=00r=00t=00R=00e=00p=00l=00y=00 =
=00s=00t=00r=00u=00c=00t=00u=00r=00e=00:=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00O=00L=00>=00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00I=00f=00 =
=00s=00e=00r=00v=00e=00r=00&=00n=00b=00s=00p=00;=00c=00h=00o=00o=00s=00e=00=
s=00 =00r=00e=00p=00l=00y=00S=00t=00a=00t=00u=00s=00 =00a=00s=00 =
=00M=00a=00l=00f=00o=00r=00m=00e=00d=00P=00K=00C=00 =00(=003=00)=00,=00 =
=00M=00a=00l=00f=00o=00r=00m=00e=00d=00A=00C=00 =00(=004=00)=00,=00 =
=00=0D=00=0A=
=00 =00 =
=00U=00n=00r=00e=00c=00o=00g=00n=00i=00z=00e=00d=00C=00e=00r=00t=00P=00o=00=
l=00i=00c=00y=00 =00(=005=00)=00 =00o=00r=00 =
=00U=00n=00r=00e=00c=00o=00g=00n=00i=00z=00e=00d=00E=00x=00t=00e=00n=00s=00=
i=00o=00n=00 =00(=007=00)=00,=00 =00h=00o=00w=00 =00i=00s=00 =00i=00t=00 =
=00p=00o=00s=00s=00i=00b=00l=00e=00 =00t=00o=00 =00=0D=00=0A=
=00 =00 =00s=00e=00t=00 =00R=00e=00p=00l=00y=00C=00h=00e=00c=00k=00s=00 =
=00a=00n=00d=00/=00o=00r=00 =
=00R=00e=00p=00l=00y=00W=00a=00n=00t=00B=00a=00c=00k=00s=00 =00i=00n=00 =
=00t=00h=00i=00s=00 =00c=00a=00s=00e=00?=00<=00/=00L=00I=00>=00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00I=00f=00 =
=00s=00e=00r=00v=00e=00r=00&=00n=00b=00s=00p=00;=00c=00h=00o=00o=00s=00e=00=
s=00 =00r=00e=00p=00l=00y=00S=00t=00a=00t=00u=00s=00 =00a=00s=00 =
=00U=00n=00r=00e=00c=00o=00g=00n=00i=00z=00e=00d=00V=00a=00l=00P=00o=00l=00=
i=00c=00y=00 =00(=006=00)=00,=00 =00i=00s=00 =00i=00t=00 =00=0D=00=0A=
=00 =00 =00p=00o=00s=00s=00i=00b=00l=00e=00 =00t=00h=00a=00t=00 =
=00s=00e=00r=00v=00e=00r=00 =00p=00r=00o=00c=00e=00s=00s=00 =
=00t=00h=00e=00 =00w=00h=00o=00l=00e=00 =
=00r=00e=00q=00u=00e=00s=00t=00?=00 =00I=00 =00t=00h=00i=00n=00k=00 =
=00t=00h=00i=00s=00 =00s=00t=00a=00t=00u=00s=00 =00c=00o=00d=00e=00 =
=00=0D=00=0A=
=00 =00 =00s=00h=00o=00u=00l=00d=00 =00b=00e=00l=00o=00n=00g=00 =
=00t=00o=00 =00C=00V=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00i=00n=00s=00t=00e=00a=00d=00 =00o=00f=00 =
=00C=00e=00r=00t=00R=00e=00p=00l=00y=00<=00/=00L=00I=00>=00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00I=00f=00 =00s=00e=00r=00v=00e=00r=00 =
=00c=00h=00o=00o=00s=00e=00s=00 =
=00r=00e=00p=00l=00y=00S=00t=00a=00t=00u=00s=00 =00a=00s=00 =
=00C=00e=00r=00t=00P=00a=00t=00h=00N=00o=00t=00V=00a=00l=00i=00d=00N=00o=00=
w=00 =00(=001=002=00)=00 =00a=00n=00d=00 =00r=00e=00a=00s=00o=00n=00 =
=00i=00s=00 =00=0D=00=0A=
=00 =00 =00t=00h=00a=00t=00 =00s=00e=00r=00v=00e=00r=00 =00c=00a=00n=00 =
=00n=00o=00t=00 =00c=00o=00n=00n=00e=00c=00t=00 =00t=00o=00 =
=00O=00C=00S=00P=00R=00e=00s=00p=00o=00n=00d=00e=00r=00/=00L=00D=00A=00P=00=
S=00e=00r=00v=00e=00r=00 =00a=00n=00d=00 =00s=00o=00 =00h=00a=00v=00e=00 =
=00n=00o=00 =00=0D=00=0A=
=00 =00 =00r=00e=00v=00o=00c=00a=00t=00i=00o=00n=00 =
=00i=00n=00f=00o=00r=00m=00a=00t=00i=00o=00n=00 =00f=00o=00r=00 =
=00t=00h=00e=00 =00t=00i=00m=00e=00 =00b=00e=00i=00n=00g=00 =
=00t=00h=00e=00n=00 =00w=00h=00a=00t=00 =00s=00h=00o=00u=00l=00d=00 =
=00s=00e=00r=00v=00e=00r=00 =00p=00u=00t=00 =00i=00n=00 =00=0D=00=0A=
=00 =00 =
=00R=00e=00p=00l=00y=00W=00a=00n=00t=00B=00a=00c=00k=00s=00?=00<=00/=00L=00=
I=00>=00<=00/=00O=00L=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00C=00a=00n=00 =00s=00o=00m=00e=00o=00n=00e=00 =
=00c=00l=00a=00r=00i=00f=00y=00?=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00R=00e=00g=00a=00r=00d=00s=00,=00<=00/=00D=00I=00V=00=
>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00F=00a=00i=00s=00a=00l=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00<=00=
/=00B=00O=00D=00Y=00>=00<=00/=00H=00T=00M=00L=00>=00=0D=00=0A=
=00
------=_NextPart_000_015B_01C49B49.EB2F9AE0--

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 13:16:33 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Carl Wallace" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Carl,

Thanks for some good technical arguments.

Your arguments of the scope if CRLs without IDP makes sense in the
reading of a CRL issuer as all instances of a CA (representing all
issuing keys).

I must say though that this isn't very clearly stated in the standards
documents and hence it is easily misunderstood by implementers. 

So I don't disagree, but I wander if there is any CA implementation
doing re-keying that has got that "right". Probably a reason why the
practice described by Laudon is the only thing that really works in open
environments.

I do however disagree that IDP only limit scope. IDP may e.g. have an
indirectCRL indicator which is a clear expansion of scope for the CRL.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Carl Wallace [mailto:[email-masked]]
> Sent: den 15 september 2004 13:28
> To: Stefan Santesson; 'Santosh Chokhani'; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> Inline...
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stefan Santesson
> > Sent: Wednesday, September 15, 2004 5:22 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> > Santosh,
> >
> > You miss my point.
> >
> > I was expressing this generally but of course, in practice we
> > only discuss the case where a CA is re-keyed without changing
> > its name.
> >
> > The security vulnerability is then exposed if those 2 CA's
> > keep issuing CRL's without IDP with scope limited to their
> > respective issued certificates.
> 
> IDP is the means of limiting scope.  From 3280, "the issuing
distribution
> point is a critical CRL extension that identifies the CRL distribution
> point
> and scope for a particular CRL."  If IDP is missing, how are the CAs
> limiting scope?  Who is aware of this scope limitation?
> 
> > You showed this yourself in one of your examples before!
> >
> > I'm not aware of any section in RFC 3280 or X.509 that
> > declare this practice invalid.
> 
> The following text from section 5.2.5 of 3280 declares this practice
> invalid: "if the distributionPoint field is absent, the CRL MUST
contain
> entries for all revoked unexpired certificates issued by the CRL
issuer,
> if
> any, within the scope of the CRL."  If an IDP is missing, so too is
the
> distributionPoint field.  Thus, "the CRL MUST contain entries for all
> revoked, unexpired certificates issued by the CRL issuer".  An
instance
> where a CA issues CRLs that covers only certificates issued using a
> particular key but does not include an IDP is broken.  The 3280 text
is
> broken too because the CRL issuer need not be the issuer of the
> certificates
> just because there is no distributionPoint field.
> 
> > The RP software that doesn't enforce key match in this
> > instance may now validate a certificate using the wrong CRL
> > and come to the wrong conclusion.
> 
> While this is true, the problem begins with the CA limiting scope by
means
> other than IDP.
> 
> > If a CA and an RP deploys standards compliant configurations
> > and the RP end up accepting a revoked certificate, this is a
> > vulnerability.
> >
> > Now, another FACT is that if validation of CRL without IDP
> > requires key match, then that would solve this vulnerability.
> 
> The fact is that without an IDP the CRL must be complete for all
> certificates issued by the CRL issuer.  This leads back to the name
> problem
> that is addressed elsewhere in this thread.
> 
> > Do we want to fix this problem in this way? That is another
> > question open for debate...
> 
> I'd vote no to fixing this with key match.  If you want key match, use
a
> different IDP for each key.
> 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 07:32:58 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

I think you are missing the point.  When the relying party matches the DNs
one for (ignoring self-issued certificates), then it know even if the CRL is
signed by different keys, it is a CRL from the same CA.  Of course, the
relying party must enforce an IDP if asserted in the CRL.  But, now, the
rekeyed CA can issue non-IDP CRL and the relying party knows that the CRL is
from the same CA, obviating the need for using the same key.  Essentially,
key match is being replaced by this algorithm.

See specific responses in-line.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Wednesday, September 15, 2004 5:22 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

You miss my point.

I was expressing this generally but of course, in practice we only discuss
the case where a CA is re-keyed without changing its name.

[This is the case (no name change) for which we need the algorithm]

The security vulnerability is then exposed if those 2 CA's keep issuing
CRL's without IDP with scope limited to their respective issued
certificates.

[Right.  That is what I have been saying all along.  Each of the two keys
should be used to sign the full CRL for the scope of all certificates issued
by that CA under all keys.  Furthermore, the same revoked certificate list
(empty or not) should be signed with all active keys.  Active keys are
defined as those CA private keys whose companion public keys can still be
used to verify signatures on the certificates]

You showed this yourself in one of your examples before!

I'm not aware of any section in RFC 3280 or X.509 that declare this practice
invalid.

[Which practice you are talking about?  Both RFC 3280 and X.509 states it.
X.509 clearly define that absence of IDP means it is a complete for that CA.
(again delta is an orthogonal issue)  3280 may not state it clearly, but
look at section 6.3.3.b.2 in general and 6.3.3.b.2.i in particular.  You
will reach the same conclusion.]

The RP software that doesn't enforce key match in this instance may now
validate a certificate using the wrong CRL and come to the wrong conclusion.

[This is because the CA generated a partial CRL and did not tell the relying
party.  I think it is inappropriate to argue that when the CA violates the
standard and client follows the standard and security breaks, let us design
a client that also does not follow the standard.]

If a CA and an RP deploys standards compliant configurations and the RP end
up accepting a revoked certificate, this is a vulnerability. 

[If the CA employed standard compliant configuration, it will either assert
an IDP or cover all certificates (e.g., 1-200 in the example I gave few days
back), the relying party will not have a problem.  That is what I have been
saying all along.  The DN matching is simply to tighten up the situation if
the relying party trusts two CAs with the same name some place in its trust
hierarchy.]

Now, another FACT is that if validation of CRL without IDP requires key
match, then that would solve this vulnerability.

[IDP and key match are not related.  MS CA requires that since it does not
follow the standards]

Do we want to fix this problem in this way? That is another question open
for debate...

[As I have said, I do not mind fixing the problem either the way I propose
or the MS does.  I do not have a dog in the fight except to get it right for
my customers.  If we use MS ways, it will break backward compatibility, make
other vendors change, will require a change in the standard, and will remove
a feature regarding signing CRL with different key.  In that case, we might
as well get rid of cRLSign bit.  Also, we will need to deprecate indirect
CRL or using the logic I proposed or something akin or require local policy
o ensure that the indirect issuer is the one certificate issuer recommended.
This is due to the fact that name binding does not ensure you are getting
the object (namely CRL) from the correct name since there may be name
collisions when you have multiple trust anchors or when name uniqueness of
the CAs is not guaranteed in a trust graph (e.g., across multiple tiers of a
trust hierarchy]

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 20:58
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> If the relying party has two CA's with the same name X, but really
> represent different real entities, the relying party is going to have 
> bigger
problem
> of disambiguation than correct CRL.
> 
> Similarly, if the relying party has two intermediate CAs named Y,
under
> the
> same certification path, you have bigger problem of disambiguation
than
> correct CRL.  Also, no CA I know will certify the two different CAs
with
> the
> same name.  That has to happen for this to occur.
> 
> So, I will assume that neither of these two is the case.
> 
> Then, the problem boils down of matching the certification path for
the
> certificate and the certification path for the CRL used to check the
> revocation status of the certificate.
> 
> The following rules should be used to ensure that you have the CRL
from
> the
> appropriate CA:
> 
> 1.  The DN of the root in both cases must match.
> 
> 2.  Set I = 1.  N1 = number of certificates in the "certificate
> certification path", ignoring self-issued certificates.  Set N2 =
number
> of
> certificates in the "CRL certification path", ignoring self-issued
> certificates.
> 
> 3.  If I = N1 or I = N2 exit with success
> 
> 4.  Verify that the issuer DN in certificate I in the "certificate
> certification path" matches the issuer DN in certificate I in the "CRL 
> certification path", ignoring self-issued certificates.
> 
> 5.  Verify that the subject DN in  certificate I in the "certificate
> certification path" matches the subject DN in certificate I in the
"CRL
> certification path", ignoring self-issued certificates.
> 
> 6.  I = I + 1.  Go to step 3
> 
> {BTW, this has been explored and explained on this mail list couple of
> times)
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, September 14, 2004 9:52 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> Santosh.
> 
> CA1 and CA1(bis) have the same name but different keys.
> 
> They are both valid in the RPs trust configuration.
> 
> Both CAs issue CRLs without IDP (which is RFC 3280 and X.509 compliant
> practice).
> 
> Result: The RP can't determine what CRL and what CA belongs together
> resulting in false acceptance of revoked certificates.
> 
> You can call it what you want.
> I call that a security vulnerability.
> 
> /Stefan
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 14 september 2004 14:36
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Stefan:
> >
> > There is no security problem in building a certification path for
the
> CRL
> > Issuer when the same CA issues the CRL, but signs the CRL using a
> > different key (i.e., different from the one used to sign the 
> > certificate being validated).
> >
> > You can build a path.  You do need to do name matching as I have
said
> in
> > several previous postings.
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Tuesday, September 14, 2004 7:09 AM
> > To: Manger, James H; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> >
> > James,
> >
> > I don't agree with your examples.
> >
> > The "simple" structure that dominates deployment today is 1 CA = 1
key
> > which has the consequences you mention.
> >
> > However, the stanards define also indirect CRLs which can be used to
> solve
> > all your issues below EVEN if you stick with the definition 1 CA = 1
> key.
> >
> > The issue at hand, previously stated to Santosh is whether a CRL
> without
> > IDP
> > can be validated with another key than the one used to validate
> > certificates issued by the CA.
> >
> > If that is allowed, then we have identified a security problem that
> ought
> > to
> > be fixed.
> >
> > /Stefan
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Manger, James H
> > > Sent: den 14 september 2004 06:36
> > > To: [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > > Same name, different key = SAME CA.
> > >
> > > Without this, if a CA's private key is destroyed no CRLs can ever
be
> > > issued again for the certs it has issued so that CA's whole PKI
> > crumbles
> > > in an instant.
> > > Without this, every CA needs to keep operating (issuing CRLs)
after
> it
> > has
> > > issued its last cert for the lifetime it was putting in certs (eg
2,
> > 5, 10
> > > years?).
> > > Without this, every certifier wanting to periodically change keys
> > (which
> > > is good practice) needs to run multiple CAs.
> > >
> > >
> > >
> > >
> > > P.S. There are ways to ensure name uniqueness for CAs -- either
> > > concatenate issuer names from a trust anchor to the CA of interest
> to
> > get
> > > that CA's "name", or just use the issuer field for that CA and
rely
> on
> > > your configured trusted anchors to name CAs in a way that avoids
> > ambiguity
> > > (which is, in fact, the primary reason for a PKI in the first
> place).
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Stefan Santesson [mailto:[email-masked]]
> > > Sent: Tuesday, 14 September 2004 8:53 AM
> > > To: Santosh Chokhani; [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > >
> > > Santosh,
> > >
> > > I realize that the standard is not crystal clear on this issue and
I
> > > suggest that you either have the wrong interpretation, or at least
> use
> > > an interpretation that ought to be wrong.
> > >
> > > The core issue is whether two CAs having the same name but
different
> > > private issuing keys, are regarded as 1 CA or 2 separate CAs.
> > >
> > > I suggest (and hope) that these are NOT defined anywhere as being
> the
> > > same CA. This is also supported by the reality fact that there is
no
> > way
> > > that you can ensure name uniqueness between CAs and therefore,
> > key-match
> > > should be a requirement.
> > >
> > > From this perspective standards states the following:
> > >
> > > X.509 Annex B states:
> > >
> > >    If the cRLIssuer field is absent from the CRL distribution
point
> > > extension of the certificate, the CRL shall be signed by the same
CA
> > > that signed the certificate; and
> > >    If the cRLIssuer field is present in the CRL distribution point
> > > extension of the certificate, the CRL shall be signed by the CRL
> > Issuer
> > > identified in the CRL distribution point extension of the
> certificate
> > > and the CRL shall contain the indirectCRL field in the issuing
> > > distribution point extension.
> > >
> > > RFC 3280 5.2.5 states:
> > >
> > >    The CRL issuer MUST assert the indirectCRL boolean, if the
scope
> of
> > >    the CRL includes certificates issued by authorities other than
> the
> > >    CRL issuer.
> > >
> > >
> > > So IF different signing keys means that CA(old) and CA(new) are
> > > different CAs (despite identical names), then in order to allow
> > CRL(new)
> > > from CA(new) to be used to validate certificates from CA(old),
then
> > > CRL(new) need to contain an IDP with indirectCRL asserted,
> > certificates
> > > from CA(old) must also contain a CDP with cRLIssuer field.
> > >
> > > I suggest therefore that a CRL without IDP with indirectCRL is
> > required
> > > to be signed with the same key that was used to sign the
certificate
> > > being validated.
> > >
> > > If that is not clear by today's standard text, then I suggest that
> it
> > > should.
> > >
> > >
> > > Stefan Santesson
> > > Microsoft Security Center of Excellence (SCOE)
> >
> >
> 
> 

From: "Carl Wallace" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 07:27:33 -0400
Sender: [email-masked]

Inline... 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: Wednesday, September 15, 2004 5:22 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
>
> Santosh,
> 
> You miss my point.
> 
> I was expressing this generally but of course, in practice we 
> only discuss the case where a CA is re-keyed without changing 
> its name.
> 
> The security vulnerability is then exposed if those 2 CA's 
> keep issuing CRL's without IDP with scope limited to their 
> respective issued certificates.

IDP is the means of limiting scope.  From 3280, "the issuing distribution
point is a critical CRL extension that identifies the CRL distribution point
and scope for a particular CRL."  If IDP is missing, how are the CAs
limiting scope?  Who is aware of this scope limitation?
 
> You showed this yourself in one of your examples before!
> 
> I'm not aware of any section in RFC 3280 or X.509 that 
> declare this practice invalid.

The following text from section 5.2.5 of 3280 declares this practice
invalid: "if the distributionPoint field is absent, the CRL MUST contain
entries for all revoked unexpired certificates issued by the CRL issuer, if
any, within the scope of the CRL."  If an IDP is missing, so too is the
distributionPoint field.  Thus, "the CRL MUST contain entries for all
revoked, unexpired certificates issued by the CRL issuer".  An instance
where a CA issues CRLs that covers only certificates issued using a
particular key but does not include an IDP is broken.  The 3280 text is
broken too because the CRL issuer need not be the issuer of the certificates
just because there is no distributionPoint field.
 
> The RP software that doesn't enforce key match in this 
> instance may now validate a certificate using the wrong CRL 
> and come to the wrong conclusion.

While this is true, the problem begins with the CA limiting scope by means
other than IDP.
 
> If a CA and an RP deploys standards compliant configurations 
> and the RP end up accepting a revoked certificate, this is a 
> vulnerability. 
> 
> Now, another FACT is that if validation of CRL without IDP 
> requires key match, then that would solve this vulnerability.

The fact is that without an IDP the CRL must be complete for all
certificates issued by the CRL issuer.  This leads back to the name problem
that is addressed elsewhere in this thread.
 
> Do we want to fix this problem in this way? That is another 
> question open for debate...

I'd vote no to fixing this with key match.  If you want key match, use a
different IDP for each key.

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

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cert and CRL chainbuilding  RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 07:15:06 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

I have already drafted the text for X.509.

In addition, I got an agreement on this on this list and with RFC 3280
authors (specifically, Tim Polk and Russ Housley).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Wednesday, September 15, 2004 5:30 AM
To: Santosh Chokhani; [email-masked]
Subject: Cert and CRL chainbuilding RE: CA Rekey and CRL Validation

Santosh,

Just for curiosity (not as part of our CRL/IDP debate)

Could help point out the section in RFC 3280 and/or X.509 where it is stated
that beyond name match of the cert and CRL issuer, the RP client must
enforce identical trust paths. 

Or is this en expression of you proposal to X.509?

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 20:58
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> If the relying party has two CA's with the same name X, but really 
> represent different real entities, the relying party is going to have 
> bigger
problem
> of disambiguation than correct CRL.
> 
> Similarly, if the relying party has two intermediate CAs named Y,
under
> the
> same certification path, you have bigger problem of disambiguation
than
> correct CRL.  Also, no CA I know will certify the two different CAs
with
> the
> same name.  That has to happen for this to occur.
> 
> So, I will assume that neither of these two is the case.
> 
> Then, the problem boils down of matching the certification path for
the
> certificate and the certification path for the CRL used to check the 
> revocation status of the certificate.
> 
> The following rules should be used to ensure that you have the CRL
from
> the
> appropriate CA:
> 
> 1.  The DN of the root in both cases must match.
> 
> 2.  Set I = 1.  N1 = number of certificates in the "certificate 
> certification path", ignoring self-issued certificates.  Set N2 =
number
> of
> certificates in the "CRL certification path", ignoring self-issued 
> certificates.
> 
> 3.  If I = N1 or I = N2 exit with success
> 
> 4.  Verify that the issuer DN in certificate I in the "certificate 
> certification path" matches the issuer DN in certificate I in the "CRL 
> certification path", ignoring self-issued certificates.
> 
> 5.  Verify that the subject DN in  certificate I in the "certificate 
> certification path" matches the subject DN in certificate I in the
"CRL
> certification path", ignoring self-issued certificates.
> 
> 6.  I = I + 1.  Go to step 3
> 
> {BTW, this has been explored and explained on this mail list couple of
> times)
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, September 14, 2004 9:52 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> Santosh.
> 
> CA1 and CA1(bis) have the same name but different keys.
> 
> They are both valid in the RPs trust configuration.
> 
> Both CAs issue CRLs without IDP (which is RFC 3280 and X.509 compliant 
> practice).
> 
> Result: The RP can't determine what CRL and what CA belongs together 
> resulting in false acceptance of revoked certificates.
> 
> You can call it what you want.
> I call that a security vulnerability.
> 
> /Stefan
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 14 september 2004 14:36
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Stefan:
> >
> > There is no security problem in building a certification path for
the
> CRL
> > Issuer when the same CA issues the CRL, but signs the CRL using a 
> > different key (i.e., different from the one used to sign the 
> > certificate being validated).
> >
> > You can build a path.  You do need to do name matching as I have
said
> in
> > several previous postings.
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Tuesday, September 14, 2004 7:09 AM
> > To: Manger, James H; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> >
> > James,
> >
> > I don't agree with your examples.
> >
> > The "simple" structure that dominates deployment today is 1 CA = 1
key
> > which has the consequences you mention.
> >
> > However, the stanards define also indirect CRLs which can be used to
> solve
> > all your issues below EVEN if you stick with the definition 1 CA = 1
> key.
> >
> > The issue at hand, previously stated to Santosh is whether a CRL
> without
> > IDP
> > can be validated with another key than the one used to validate 
> > certificates issued by the CA.
> >
> > If that is allowed, then we have identified a security problem that
> ought
> > to
> > be fixed.
> >
> > /Stefan
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Manger, James H
> > > Sent: den 14 september 2004 06:36
> > > To: [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > > Same name, different key = SAME CA.
> > >
> > > Without this, if a CA's private key is destroyed no CRLs can ever
be
> > > issued again for the certs it has issued so that CA's whole PKI
> > crumbles
> > > in an instant.
> > > Without this, every CA needs to keep operating (issuing CRLs)
after
> it
> > has
> > > issued its last cert for the lifetime it was putting in certs (eg
2,
> > 5, 10
> > > years?).
> > > Without this, every certifier wanting to periodically change keys
> > (which
> > > is good practice) needs to run multiple CAs.
> > >
> > >
> > >
> > >
> > > P.S. There are ways to ensure name uniqueness for CAs -- either 
> > > concatenate issuer names from a trust anchor to the CA of interest
> to
> > get
> > > that CA's "name", or just use the issuer field for that CA and
rely
> on
> > > your configured trusted anchors to name CAs in a way that avoids
> > ambiguity
> > > (which is, in fact, the primary reason for a PKI in the first
> place).
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Stefan Santesson [mailto:[email-masked]]
> > > Sent: Tuesday, 14 September 2004 8:53 AM
> > > To: Santosh Chokhani; [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > >
> > > Santosh,
> > >
> > > I realize that the standard is not crystal clear on this issue and
I
> > > suggest that you either have the wrong interpretation, or at least
> use
> > > an interpretation that ought to be wrong.
> > >
> > > The core issue is whether two CAs having the same name but
different
> > > private issuing keys, are regarded as 1 CA or 2 separate CAs.
> > >
> > > I suggest (and hope) that these are NOT defined anywhere as being
> the
> > > same CA. This is also supported by the reality fact that there is
no
> > way
> > > that you can ensure name uniqueness between CAs and therefore,
> > key-match
> > > should be a requirement.
> > >
> > > From this perspective standards states the following:
> > >
> > > X.509 Annex B states:
> > >
> > >    If the cRLIssuer field is absent from the CRL distribution
point
> > > extension of the certificate, the CRL shall be signed by the same
CA
> > > that signed the certificate; and
> > >    If the cRLIssuer field is present in the CRL distribution point 
> > > extension of the certificate, the CRL shall be signed by the CRL
> > Issuer
> > > identified in the CRL distribution point extension of the
> certificate
> > > and the CRL shall contain the indirectCRL field in the issuing 
> > > distribution point extension.
> > >
> > > RFC 3280 5.2.5 states:
> > >
> > >    The CRL issuer MUST assert the indirectCRL boolean, if the
scope
> of
> > >    the CRL includes certificates issued by authorities other than
> the
> > >    CRL issuer.
> > >
> > >
> > > So IF different signing keys means that CA(old) and CA(new) are 
> > > different CAs (despite identical names), then in order to allow
> > CRL(new)
> > > from CA(new) to be used to validate certificates from CA(old),
then
> > > CRL(new) need to contain an IDP with indirectCRL asserted,
> > certificates
> > > from CA(old) must also contain a CDP with cRLIssuer field.
> > >
> > > I suggest therefore that a CRL without IDP with indirectCRL is
> > required
> > > to be signed with the same key that was used to sign the
certificate
> > > being validated.
> > >
> > > If that is not clear by today's standard text, then I suggest that
> it
> > > should.
> > >
> > >
> > > Stefan Santesson
> > > Microsoft Security Center of Excellence (SCOE)
> >
> >
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 07:13:44 -0400
Importance: Normal
Sender: [email-masked]

Folks:

You are misunderstanding the IDP and name matching.  IDP declares the scope
of CRL.  If you do not include IDP and only provide revocation status for a
subset of certificates (e.g., those certificates signed with a specific
key), you are fooling the relying party in thinking that this a full CRL for
the CA.

The certification path DN matching algorithm (which needs slight refinement
between I, N1, and N2) is a substitute for ensuring that you have a CRL from
the same CA when the certificate and CRL are signed with different keys.

Both rules need to be adhered to.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean-Marc Desperrier
Sent: Wednesday, September 15, 2004 6:00 AM
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Laudon Williams wrote:

>Key rollover *may* work in closed systems, but as evidenced by the 
>original discussion on this thread, is not consistently implemented. 
>YMMV. If a mechanism for this is standardized, it may work more 
>consistently at some point in the future.
>  
>
It sounds like we are very near that mechanism.
The first thing needed is that the implementers of CRL verifiers, in the 
absence of an IDP, always do a fully-qualified names to a common trust 
anchor match between the crl signer and the certificate issuer. The other
thing needed is that CA implementers fully realize that when 
they do a key rollover, it's still the same CA, so in the absence of an 
IDP the CRL *MUST* continue to cover the same set of certificates. Also 
serial number uniqueness must be preserved.

IIUC this is what is missing in the standard now and should be added 
(even if the second point is only a clarification).

Date: Wed, 15 Sep 2004 13:06:12 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Stefan Santesson wrote:

>I was expressing this generally but of course, in practice we only
>discuss the case where a CA is re-keyed without changing its name.
>
>The security vulnerability is then exposed if those 2 CA's keep issuing
>CRL's without IDP with scope limited to their respective issued
>certificates.
>  
>
I think the previous discussion made it clear that if they have the same 
name, it's not two CA, it's the same CA, and the rekeyed version must in 
the CRL it issues include the certificates that were issued before the 
rekey, whenever applicable.

Likewise, I understand that the matching mechanims Santosh describes is 
a proposed extension to the current standard (maybe more a default 
correction proposition), but one that he has already discussed quite a 
while ago on this list and maybe elsewhere, and that might already have 
achieved some stage of the process of incorporation in the standard.
And that it should be considered Best Practice right now (anyone 
disagrees with that ?).

Also sorry if you saw my previous "Microsoft employees" comment as 
attacking you in any way, it wasn't the intent, I intendend this to be 
in a lightly humorous vein.

Date: Wed, 15 Sep 2004 11:59:31 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Laudon Williams wrote:

>Key rollover *may* work in closed systems, but as evidenced by the original
>discussion on this thread, is not consistently implemented. YMMV. If a
>mechanism for this is standardized, it may work more consistently at some
>point in the future.
>  
>
It sounds like we are very near that mechanism.
The first thing needed is that the implementers of CRL verifiers, in the 
absence of an IDP, always do a fully-qualified names to a common trust 
anchor match between the crl signer and the certificate issuer.
The other thing needed is that CA implementers fully realize that when 
they do a key rollover, it's still the same CA, so in the absence of an 
IDP the CRL *MUST* continue to cover the same set of certificates. Also 
serial number uniqueness must be preserved.

IIUC this is what is missing in the standard now and should be added 
(even if the second point is only a clarification).

Content-class: urn:content-classes:message
Subject: Cert and CRL chainbuilding  RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 10:29:43 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

Just for curiosity (not as part of our CRL/IDP debate)

Could help point out the section in RFC 3280 and/or X.509 where it is
stated that beyond name match of the cert and CRL issuer, the RP client
must enforce identical trust paths. 

Or is this en expression of you proposal to X.509?

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 20:58
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> If the relying party has two CA's with the same name X, but really
> represent
> different real entities, the relying party is going to have bigger
problem
> of disambiguation than correct CRL.
> 
> Similarly, if the relying party has two intermediate CAs named Y,
under
> the
> same certification path, you have bigger problem of disambiguation
than
> correct CRL.  Also, no CA I know will certify the two different CAs
with
> the
> same name.  That has to happen for this to occur.
> 
> So, I will assume that neither of these two is the case.
> 
> Then, the problem boils down of matching the certification path for
the
> certificate and the certification path for the CRL used to check the
> revocation status of the certificate.
> 
> The following rules should be used to ensure that you have the CRL
from
> the
> appropriate CA:
> 
> 1.  The DN of the root in both cases must match.
> 
> 2.  Set I = 1.  N1 = number of certificates in the "certificate
> certification path", ignoring self-issued certificates.  Set N2 =
number
> of
> certificates in the "CRL certification path", ignoring self-issued
> certificates.
> 
> 3.  If I = N1 or I = N2 exit with success
> 
> 4.  Verify that the issuer DN in certificate I in the "certificate
> certification path" matches the issuer DN in certificate I in the "CRL
> certification path", ignoring self-issued certificates.
> 
> 5.  Verify that the subject DN in  certificate I in the "certificate
> certification path" matches the subject DN in certificate I in the
"CRL
> certification path", ignoring self-issued certificates.
> 
> 6.  I = I + 1.  Go to step 3
> 
> {BTW, this has been explored and explained on this mail list couple of
> times)
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, September 14, 2004 9:52 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> Santosh.
> 
> CA1 and CA1(bis) have the same name but different keys.
> 
> They are both valid in the RPs trust configuration.
> 
> Both CAs issue CRLs without IDP (which is RFC 3280 and X.509 compliant
> practice).
> 
> Result: The RP can't determine what CRL and what CA belongs together
> resulting in false acceptance of revoked certificates.
> 
> You can call it what you want.
> I call that a security vulnerability.
> 
> /Stefan
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 14 september 2004 14:36
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Stefan:
> >
> > There is no security problem in building a certification path for
the
> CRL
> > Issuer when the same CA issues the CRL, but signs the CRL using a
> > different key (i.e., different from the one used to sign the
> > certificate being validated).
> >
> > You can build a path.  You do need to do name matching as I have
said
> in
> > several previous postings.
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Tuesday, September 14, 2004 7:09 AM
> > To: Manger, James H; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> >
> > James,
> >
> > I don't agree with your examples.
> >
> > The "simple" structure that dominates deployment today is 1 CA = 1
key
> > which has the consequences you mention.
> >
> > However, the stanards define also indirect CRLs which can be used to
> solve
> > all your issues below EVEN if you stick with the definition 1 CA = 1
> key.
> >
> > The issue at hand, previously stated to Santosh is whether a CRL
> without
> > IDP
> > can be validated with another key than the one used to validate
> > certificates issued by the CA.
> >
> > If that is allowed, then we have identified a security problem that
> ought
> > to
> > be fixed.
> >
> > /Stefan
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Manger, James H
> > > Sent: den 14 september 2004 06:36
> > > To: [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > > Same name, different key = SAME CA.
> > >
> > > Without this, if a CA's private key is destroyed no CRLs can ever
be
> > > issued again for the certs it has issued so that CA's whole PKI
> > crumbles
> > > in an instant.
> > > Without this, every CA needs to keep operating (issuing CRLs)
after
> it
> > has
> > > issued its last cert for the lifetime it was putting in certs (eg
2,
> > 5, 10
> > > years?).
> > > Without this, every certifier wanting to periodically change keys
> > (which
> > > is good practice) needs to run multiple CAs.
> > >
> > >
> > >
> > >
> > > P.S. There are ways to ensure name uniqueness for CAs -- either
> > > concatenate issuer names from a trust anchor to the CA of interest
> to
> > get
> > > that CA's "name", or just use the issuer field for that CA and
rely
> on
> > > your configured trusted anchors to name CAs in a way that avoids
> > ambiguity
> > > (which is, in fact, the primary reason for a PKI in the first
> place).
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Stefan Santesson [mailto:[email-masked]]
> > > Sent: Tuesday, 14 September 2004 8:53 AM
> > > To: Santosh Chokhani; [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > >
> > > Santosh,
> > >
> > > I realize that the standard is not crystal clear on this issue and
I
> > > suggest that you either have the wrong interpretation, or at least
> use
> > > an interpretation that ought to be wrong.
> > >
> > > The core issue is whether two CAs having the same name but
different
> > > private issuing keys, are regarded as 1 CA or 2 separate CAs.
> > >
> > > I suggest (and hope) that these are NOT defined anywhere as being
> the
> > > same CA. This is also supported by the reality fact that there is
no
> > way
> > > that you can ensure name uniqueness between CAs and therefore,
> > key-match
> > > should be a requirement.
> > >
> > > From this perspective standards states the following:
> > >
> > > X.509 Annex B states:
> > >
> > >    If the cRLIssuer field is absent from the CRL distribution
point
> > > extension of the certificate, the CRL shall be signed by the same
CA
> > > that signed the certificate; and
> > >    If the cRLIssuer field is present in the CRL distribution point
> > > extension of the certificate, the CRL shall be signed by the CRL
> > Issuer
> > > identified in the CRL distribution point extension of the
> certificate
> > > and the CRL shall contain the indirectCRL field in the issuing
> > > distribution point extension.
> > >
> > > RFC 3280 5.2.5 states:
> > >
> > >    The CRL issuer MUST assert the indirectCRL boolean, if the
scope
> of
> > >    the CRL includes certificates issued by authorities other than
> the
> > >    CRL issuer.
> > >
> > >
> > > So IF different signing keys means that CA(old) and CA(new) are
> > > different CAs (despite identical names), then in order to allow
> > CRL(new)
> > > from CA(new) to be used to validate certificates from CA(old),
then
> > > CRL(new) need to contain an IDP with indirectCRL asserted,
> > certificates
> > > from CA(old) must also contain a CDP with cRLIssuer field.
> > >
> > > I suggest therefore that a CRL without IDP with indirectCRL is
> > required
> > > to be signed with the same key that was used to sign the
certificate
> > > being validated.
> > >
> > > If that is not clear by today's standard text, then I suggest that
> it
> > > should.
> > >
> > >
> > > Stefan Santesson
> > > Microsoft Security Center of Excellence (SCOE)
> >
> >
> 
> 

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Wed, 15 Sep 2004 10:21:40 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

You miss my point.

I was expressing this generally but of course, in practice we only
discuss the case where a CA is re-keyed without changing its name.

The security vulnerability is then exposed if those 2 CA's keep issuing
CRL's without IDP with scope limited to their respective issued
certificates.

You showed this yourself in one of your examples before!

I'm not aware of any section in RFC 3280 or X.509 that declare this
practice invalid.

The RP software that doesn't enforce key match in this instance may now
validate a certificate using the wrong CRL and come to the wrong
conclusion.

If a CA and an RP deploys standards compliant configurations and the RP
end up accepting a revoked certificate, this is a vulnerability. 

Now, another FACT is that if validation of CRL without IDP requires key
match, then that would solve this vulnerability.

Do we want to fix this problem in this way? That is another question
open for debate...

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 20:58
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> If the relying party has two CA's with the same name X, but really
> represent
> different real entities, the relying party is going to have bigger
problem
> of disambiguation than correct CRL.
> 
> Similarly, if the relying party has two intermediate CAs named Y,
under
> the
> same certification path, you have bigger problem of disambiguation
than
> correct CRL.  Also, no CA I know will certify the two different CAs
with
> the
> same name.  That has to happen for this to occur.
> 
> So, I will assume that neither of these two is the case.
> 
> Then, the problem boils down of matching the certification path for
the
> certificate and the certification path for the CRL used to check the
> revocation status of the certificate.
> 
> The following rules should be used to ensure that you have the CRL
from
> the
> appropriate CA:
> 
> 1.  The DN of the root in both cases must match.
> 
> 2.  Set I = 1.  N1 = number of certificates in the "certificate
> certification path", ignoring self-issued certificates.  Set N2 =
number
> of
> certificates in the "CRL certification path", ignoring self-issued
> certificates.
> 
> 3.  If I = N1 or I = N2 exit with success
> 
> 4.  Verify that the issuer DN in certificate I in the "certificate
> certification path" matches the issuer DN in certificate I in the "CRL
> certification path", ignoring self-issued certificates.
> 
> 5.  Verify that the subject DN in  certificate I in the "certificate
> certification path" matches the subject DN in certificate I in the
"CRL
> certification path", ignoring self-issued certificates.
> 
> 6.  I = I + 1.  Go to step 3
> 
> {BTW, this has been explored and explained on this mail list couple of
> times)
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, September 14, 2004 9:52 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> Santosh.
> 
> CA1 and CA1(bis) have the same name but different keys.
> 
> They are both valid in the RPs trust configuration.
> 
> Both CAs issue CRLs without IDP (which is RFC 3280 and X.509 compliant
> practice).
> 
> Result: The RP can't determine what CRL and what CA belongs together
> resulting in false acceptance of revoked certificates.
> 
> You can call it what you want.
> I call that a security vulnerability.
> 
> /Stefan
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 14 september 2004 14:36
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Stefan:
> >
> > There is no security problem in building a certification path for
the
> CRL
> > Issuer when the same CA issues the CRL, but signs the CRL using a
> > different key (i.e., different from the one used to sign the
> > certificate being validated).
> >
> > You can build a path.  You do need to do name matching as I have
said
> in
> > several previous postings.
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Tuesday, September 14, 2004 7:09 AM
> > To: Manger, James H; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> >
> > James,
> >
> > I don't agree with your examples.
> >
> > The "simple" structure that dominates deployment today is 1 CA = 1
key
> > which has the consequences you mention.
> >
> > However, the stanards define also indirect CRLs which can be used to
> solve
> > all your issues below EVEN if you stick with the definition 1 CA = 1
> key.
> >
> > The issue at hand, previously stated to Santosh is whether a CRL
> without
> > IDP
> > can be validated with another key than the one used to validate
> > certificates issued by the CA.
> >
> > If that is allowed, then we have identified a security problem that
> ought
> > to
> > be fixed.
> >
> > /Stefan
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Manger, James H
> > > Sent: den 14 september 2004 06:36
> > > To: [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > > Same name, different key = SAME CA.
> > >
> > > Without this, if a CA's private key is destroyed no CRLs can ever
be
> > > issued again for the certs it has issued so that CA's whole PKI
> > crumbles
> > > in an instant.
> > > Without this, every CA needs to keep operating (issuing CRLs)
after
> it
> > has
> > > issued its last cert for the lifetime it was putting in certs (eg
2,
> > 5, 10
> > > years?).
> > > Without this, every certifier wanting to periodically change keys
> > (which
> > > is good practice) needs to run multiple CAs.
> > >
> > >
> > >
> > >
> > > P.S. There are ways to ensure name uniqueness for CAs -- either
> > > concatenate issuer names from a trust anchor to the CA of interest
> to
> > get
> > > that CA's "name", or just use the issuer field for that CA and
rely
> on
> > > your configured trusted anchors to name CAs in a way that avoids
> > ambiguity
> > > (which is, in fact, the primary reason for a PKI in the first
> place).
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Stefan Santesson [mailto:[email-masked]]
> > > Sent: Tuesday, 14 September 2004 8:53 AM
> > > To: Santosh Chokhani; [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > >
> > > Santosh,
> > >
> > > I realize that the standard is not crystal clear on this issue and
I
> > > suggest that you either have the wrong interpretation, or at least
> use
> > > an interpretation that ought to be wrong.
> > >
> > > The core issue is whether two CAs having the same name but
different
> > > private issuing keys, are regarded as 1 CA or 2 separate CAs.
> > >
> > > I suggest (and hope) that these are NOT defined anywhere as being
> the
> > > same CA. This is also supported by the reality fact that there is
no
> > way
> > > that you can ensure name uniqueness between CAs and therefore,
> > key-match
> > > should be a requirement.
> > >
> > > From this perspective standards states the following:
> > >
> > > X.509 Annex B states:
> > >
> > >    If the cRLIssuer field is absent from the CRL distribution
point
> > > extension of the certificate, the CRL shall be signed by the same
CA
> > > that signed the certificate; and
> > >    If the cRLIssuer field is present in the CRL distribution point
> > > extension of the certificate, the CRL shall be signed by the CRL
> > Issuer
> > > identified in the CRL distribution point extension of the
> certificate
> > > and the CRL shall contain the indirectCRL field in the issuing
> > > distribution point extension.
> > >
> > > RFC 3280 5.2.5 states:
> > >
> > >    The CRL issuer MUST assert the indirectCRL boolean, if the
scope
> of
> > >    the CRL includes certificates issued by authorities other than
> the
> > >    CRL issuer.
> > >
> > >
> > > So IF different signing keys means that CA(old) and CA(new) are
> > > different CAs (despite identical names), then in order to allow
> > CRL(new)
> > > from CA(new) to be used to validate certificates from CA(old),
then
> > > CRL(new) need to contain an IDP with indirectCRL asserted,
> > certificates
> > > from CA(old) must also contain a CDP with cRLIssuer field.
> > >
> > > I suggest therefore that a CRL without IDP with indirectCRL is
> > required
> > > to be signed with the same key that was used to sign the
certificate
> > > being validated.
> > >
> > > If that is not clear by today's standard text, then I suggest that
> it
> > > should.
> > >
> > >
> > > Stefan Santesson
> > > Microsoft Security Center of Excellence (SCOE)
> >
> >
> 
> 

From: "Faisal Maqsood" <[email-masked]>
To: <[email-masked]>, "Trevor Freeman" <[email-masked]>
Subject: SCVP No error code found
Date: Wed, 15 Sep 2004 12:01:23 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00D0_01C49B1B.B888ECA0
Content-Type: text/plain;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

H=00i=00 =00T=00r=00e=00v=00o=00r=00,=00=0D=00=0A=
=00=0D=00=0A=
=00B=00y=00 =00r=00e=00a=00d=00i=00n=00g=00 =00t=00h=00e=00 =
=00S=00C=00V=00P=00 =00d=00r=00a=00f=00t=00 =001=005=00,=00 =00I=00 =
=00u=00n=00d=00e=00r=00s=00t=00a=00n=00d=00 =00t=00h=00a=00t=00 =
=00i=00f=00 =00r=00e=00q=00u=00e=00s=00t=00o=00r=00 =00p=00u=00t=00s=00 =
=00s=00o=00m=00e=00 =00K=00e=00y=00U=00s=00a=00g=00e=00 =
=00b=00i=00t=00s=00 =00i=00n=00 =00q=00u=00e=00r=00y=00 =
=00(=00s=00e=00c=00t=00i=00o=00n=00 =003=00.=002=00.=001=007=00)=00,=00 =
=00t=00h=00e=00n=00 =00s=00e=00r=00v=00e=00r=00 =00h=00a=00v=00e=00 =
=00t=00o=00 =00c=00h=00e=00c=00k=00 =00w=00h=00e=00t=00h=00e=00r=00 =
=00s=00p=00e=00c=00i=00f=00i=00e=00d=00 =
=00K=00e=00y=00U=00s=00a=00g=00e=00 =00b=00i=00t=00(=00s=00)=00 =
=00a=00r=00e=00 =00p=00r=00e=00s=00e=00n=00t=00 =00i=00n=00 =
=00e=00a=00c=00h=00 =00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00.=00 =00I=00f=00 =
=00s=00e=00r=00v=00e=00r=00 =00f=00o=00u=00n=00d=00 =00t=00h=00a=00t=00 =
=00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =00d=00o=00e=00s=00 =
=00n=00o=00t=00 =00c=00o=00n=00t=00a=00i=00n=00 =
=00r=00e=00q=00u=00i=00r=00e=00d=00 =00K=00e=00y=00U=00s=00a=00g=00e=00 =
=00b=00i=00t=00(=00s=00)=00 =00s=00e=00r=00v=00e=00r=00 =
=00w=00i=00l=00l=00 =00n=00o=00t=00 =00p=00r=00o=00c=00e=00s=00s=00 =
=00t=00h=00e=00 =00r=00e=00q=00u=00e=00s=00t=00.=00=0D=00=0A=
=00=0D=00=0A=
=00A=00b=00o=00v=00e=00 =00c=00a=00s=00e=00 =00a=00r=00i=00s=00e=00s=00 =
=00t=00w=00o=00 =00q=00u=00e=00s=00t=00i=00o=00n=00s=00:=00=0D=00=0A=
=00 =00 =001=00.=00.=00 =00W=00h=00a=00t=00 =00e=00r=00r=00o=00r=00 =
=00c=00o=00d=00e=00 =00w=00i=00l=00l=00 =00b=00e=00 =
=00r=00e=00t=00u=00r=00n=00e=00d=00 =00s=00o=00 =00t=00h=00a=00t=00 =
=00r=00e=00q=00u=00e=00s=00t=00o=00r=00 =00c=00a=00n=00 =
=00u=00n=00d=00e=00r=00s=00t=00a=00n=00d=00 =00t=00h=00e=00 =
=00f=00a=00i=00l=00u=00r=00e=00 =00r=00e=00a=00s=00o=00n=00?=00=0D=00=0A=
=00 =00 =002=00.=00.=00 =00I=00f=00 =00t=00h=00e=00r=00e=00 =
=00a=00r=00e=00 =00t=00w=00o=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00s=00 =00i=00n=00 =
=00q=00u=00e=00r=00y=00 =00a=00n=00d=00 =
=00K=00e=00y=00U=00s=00a=00g=00e=00 =00r=00e=00q=00u=00i=00r=00e=00d=00 =
=00i=00s=00 =
=00d=00i=00g=00i=00t=00a=00l=00s=00i=00g=00n=00a=00t=00u=00r=00e=00 =
=00i=00n=00 =00e=00a=00c=00h=00 =00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =00b=00u=00t=00 =
=00i=00n=00 =00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00 =
=00s=00e=00r=00v=00e=00r=00 =00f=00o=00u=00n=00d=00 =00t=00h=00a=00t=00 =
=00o=00n=00e=00 =00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =
=00h=00a=00s=00 =
=00d=00i=00g=00i=00t=00a=00l=00s=00i=00g=00n=00a=00t=00u=00r=00e=00 =
=00w=00h=00i=00l=00e=00 =00o=00t=00h=00e=00r=00 =00n=00o=00t=00.=00 =
=00I=00n=00 =00t=00h=00i=00s=00 =00c=00a=00s=00e=00 =
=00s=00e=00r=00v=00e=00r=00 =00s=00h=00o=00u=00l=00d=00 =00n=00o=00t=00 =
=00r=00e=00t=00u=00r=00n=00 =00e=00r=00r=00o=00r=00 =00c=00o=00d=00e=00 =
=00f=00o=00r=00 =00s=00c=00v=00p=00r=00e=00s=00p=00o=00n=00s=00e=00 =
=00b=00u=00t=00 =00s=00h=00o=00u=00l=00d=00 =00r=00e=00t=00u=00r=00n=00 =
=00e=00r=00r=00o=00r=00 =00c=00o=00d=00e=00 =00f=00o=00r=00 =
=00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00,=00 =00s=00o=00 =
=00b=00y=00 =00t=00h=00i=00s=00 =00c=00a=00s=00e=00 =
=00r=00e=00p=00l=00y=00O=00b=00j=00e=00c=00t=00 =
=00s=00t=00r=00u=00c=00t=00u=00r=00e=00 =00s=00h=00o=00u=00l=00d=00 =
=00h=00a=00v=00e=00 =
=00c=00o=00r=00r=00e=00s=00p=00o=00n=00d=00i=00n=00g=00 =
=00e=00r=00r=00o=00r=00 =00c=00o=00d=00e=00.=00=0D=00=0A=
=00 =00 =00T=00h=00e=00r=00e=00 =00m=00a=00y=00 =00b=00e=00 =
=00o=00n=00e=00 =00o=00f=00 =00t=00w=00o=00 =
=00r=00e=00a=00s=00o=00n=00s=00 =00t=00h=00a=00t=00 =
=00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =00h=00a=00s=00 =
=00n=00o=00t=00 =00r=00e=00q=00u=00i=00r=00e=00d=00 =
=00b=00i=00t=00(=00s=00)=00:=00=0D=00=0A=
=00 =00 =00-=00 =00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =00i=00s=00 =
=00v=00e=00r=00s=00i=00o=00n=00 =001=00=0D=00=0A=
=00 =00 =00-=00 =00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =00i=00s=00 =
=00v=00e=00r=00s=00i=00o=00n=00 =003=00 =00b=00u=00t=00 =00h=00a=00s=00 =
=00n=00o=00t=00 =00r=00e=00q=00u=00i=00r=00e=00d=00 =
=00b=00i=00t=00(=00s=00)=00=0D=00=0A=
=00 =00 =00*=00 =00I=00 =00a=00s=00s=00u=00m=00e=00 =00t=00h=00a=00t=00 =
=00i=00n=00 =00c=00a=00s=00e=00 =00o=00f=00 =
=00v=00e=00r=00s=00i=00o=00n=00 =001=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00,=00 =00w=00e=00 =
=00w=00i=00l=00l=00 =00c=00o=00n=00t=00i=00n=00u=00e=00 =
=00p=00r=00o=00c=00e=00s=00s=00i=00n=00g=00 =00w=00h=00i=00l=00e=00 =
=00f=00o=00r=00 =00v=00e=00r=00s=00i=00o=00n=00 =003=00 =00w=00e=00 =
=00w=00i=00l=00l=00 =00g=00e=00n=00e=00r=00a=00t=00e=00 =
=00s=00o=00m=00e=00 =00e=00r=00r=00o=00r=00.=00=0D=00=0A=
=00S=00a=00m=00e=00 =00c=00a=00s=00e=00 =00a=00s=00 =
=00d=00i=00s=00c=00u=00s=00s=00e=00d=00 =00a=00b=00o=00v=00e=00 =
=00c=00a=00n=00 =00o=00c=00c=00u=00r=00 =00f=00o=00r=00 =
=00E=00x=00t=00e=00n=00d=00e=00d=00K=00e=00y=00U=00s=00a=00g=00e=00 =
=00O=00I=00D=00(=00s=00)=00.=00.=00.=00.=00=0D=00=0A=
=00=0D=00=0A=
=00D=00o=00 =00y=00o=00u=00 =00h=00a=00v=00e=00 =00a=00n=00y=00 =
=00i=00d=00e=00a=00 =00o=00r=00 =00I=00 =00a=00m=00 =
=00m=00i=00s=00s=00i=00n=00g=00 =00s=00o=00m=00e=00 =
=00t=00h=00i=00n=00g=00 =00f=00r=00o=00m=00 =
=00p=00r=00o=00t=00o=00c=00o=00l=00 =00?=00=0D=00=0A=
=00=0D=00=0A=
=00R=00e=00g=00a=00r=00d=00s=00,=00=0D=00=0A=
=00F=00a=00i=00s=00a=00l=00=0D=00=0A=
=00=0D=00=0A=
=00
------=_NextPart_000_00D0_01C49B1B.B888ECA0
Content-Type: text/html;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

=FF=FE<=00!=00D=00O=00C=00T=00Y=00P=00E=00 =00H=00T=00M=00L=00 =
=00P=00U=00B=00L=00I=00C=00 =
=00"=00-=00/=00/=00W=003=00C=00/=00/=00D=00T=00D=00 =00H=00T=00M=00L=00 =
=004=00.=000=00 =
=00T=00r=00a=00n=00s=00i=00t=00i=00o=00n=00a=00l=00/=00/=00E=00N=00"=00>=00=
=0D=00=0A=
=00<=00H=00T=00M=00L=00 =00x=00m=00l=00n=00s=00:=00s=00t=001=00 =
=00=3D=00 =
=00"=00u=00r=00n=00:=00s=00c=00h=00e=00m=00a=00s=00-=00m=00i=00c=00r=00o=00=
s=00o=00f=00t=00-=00c=00o=00m=00:=00o=00f=00f=00i=00c=00e=00:=00s=00m=00a=
=00r=00t=00t=00a=00g=00s=00"=00 =00x=00m=00l=00n=00s=00:=00o=00 =
=00=3D=00 =00=0D=00=0A=
=00"=00u=00r=00n=00:=00s=00c=00h=00e=00m=00a=00s=00-=00m=00i=00c=00r=00o=00=
s=00o=00f=00t=00-=00c=00o=00m=00:=00o=00f=00f=00i=00c=00e=00:=00o=00f=00f=
=00i=00c=00e=00"=00>=00<=00H=00E=00A=00D=00>=00<=00B=00A=00S=00E=00 =
=00=0D=00=0A=
=00h=00r=00e=00f=00=3D=00"=00f=00i=00l=00e=00:=00/=00/=00F=00:=00\=00_=00=
B=00a=00c=00k=00U=00p=00-=00F=00M=00\=00E=00m=00a=00i=00l=00 =
=00S=00i=00g=00n=00a=00t=00u=00r=00e=00\=00"=00>=00=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00h=00t=00t=00p=00-=00e=00q=00u=00i=00v=00=3D=00C=00o=00n=00t=00e=00n=00=
t=00-=00T=00y=00p=00e=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00t=00e=00x=00t=00/=00h=00t=00m=00=
l=00;=00 =
=00c=00h=00a=00r=00s=00e=00t=00=3D=00u=00n=00i=00c=00o=00d=00e=00"=00>=00=
=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00M=00L=00 =
=005=00.=005=000=00.=004=001=003=004=00.=006=000=000=00"=00 =
=00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00<=00/=00=
H=00E=00A=00D=00>=00=0D=00=0A=
=00<=00B=00O=00D=00Y=00 =
=00b=00g=00C=00o=00l=00o=00r=00=3D=00#=00f=00f=00f=00f=00f=00f=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00H=00i=00 =
=00T=00r=00e=00v=00o=00r=00,=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00<=00F=00O=00N=00T=00 =
=00f=00a=00c=00e=00=3D=00"=00T=00i=00m=00e=00s=00 =00N=00e=00w=00 =
=00R=00o=00m=00a=00n=00"=00 =
=00s=00i=00z=00e=00=3D=003=00>=00<=00S=00P=00A=00N=00 =
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =001=002=00p=00t=00"=00>=00B=00y=00 =00=0D=00=0A=
=00r=00e=00a=00d=00i=00n=00g=00 =00t=00h=00e=00 =00S=00C=00V=00P=00 =
=00d=00r=00a=00f=00t=00 =001=005=00,=00 =00I=00 =
=00u=00n=00d=00e=00r=00s=00t=00a=00n=00d=00 =00t=00h=00a=00t=00 =
=00i=00f=00 =00r=00e=00q=00u=00e=00s=00t=00o=00r=00 =00p=00u=00t=00s=00 =
=00s=00o=00m=00e=00 =00K=00e=00y=00U=00s=00a=00g=00e=00 =00=0D=00=0A=
=00b=00i=00t=00s=00 =00i=00n=00 =00q=00u=00e=00r=00y=00 =
=00(=00s=00e=00c=00t=00i=00o=00n=00 =003=00.=002=00.=001=007=00)=00,=00 =
=00t=00h=00e=00n=00 =00s=00e=00r=00v=00e=00r=00 =00h=00a=00v=00e=00 =
=00t=00o=00 =00c=00h=00e=00c=00k=00 =00w=00h=00e=00t=00h=00e=00r=00 =
=00s=00p=00e=00c=00i=00f=00i=00e=00d=00 =00=0D=00=0A=
=00K=00e=00y=00U=00s=00a=00g=00e=00 =00b=00i=00t=00(=00s=00)=00 =
=00a=00r=00e=00 =00p=00r=00e=00s=00e=00n=00t=00 =00i=00n=00 =
=00e=00a=00c=00h=00 =00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00.=00 =00I=00f=00 =
=00s=00e=00r=00v=00e=00r=00 =00f=00o=00u=00n=00d=00 =00t=00h=00a=00t=00 =
=00=0D=00=0A=
=00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =00d=00o=00e=00s=00 =
=00n=00o=00t=00 =00c=00o=00n=00t=00a=00i=00n=00 =
=00r=00e=00q=00u=00i=00r=00e=00d=00 =00K=00e=00y=00U=00s=00a=00g=00e=00 =
=00b=00i=00t=00(=00s=00)=00 =00s=00e=00r=00v=00e=00r=00 =
=00w=00i=00l=00l=00 =00n=00o=00t=00 =00=0D=00=0A=
=00p=00r=00o=00c=00e=00s=00s=00 =00t=00h=00e=00 =
=00r=00e=00q=00u=00e=00s=00t=00.=00<=00/=00S=00P=00A=00N=00>=00<=00/=00F=00=
O=00N=00T=00>=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00<=00F=00O=00N=00T=00 =
=00f=00a=00c=00e=00=3D=00"=00T=00i=00m=00e=00s=00 =00N=00e=00w=00 =
=00R=00o=00m=00a=00n=00"=00 =
=00s=00i=00z=00e=00=3D=003=00>=00<=00S=00P=00A=00N=00 =00=0D=00=0A=
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =
=001=002=00p=00t=00"=00>=00<=00/=00S=00P=00A=00N=00>=00<=00/=00F=00O=00N=00=
T=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00<=00F=00O=00N=00T=00 =
=00f=00a=00c=00e=00=3D=00"=00T=00i=00m=00e=00s=00 =00N=00e=00w=00 =
=00R=00o=00m=00a=00n=00"=00 =
=00s=00i=00z=00e=00=3D=003=00>=00<=00S=00P=00A=00N=00 =00=0D=00=0A=
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =
=001=002=00p=00t=00"=00>=00<=00/=00S=00P=00A=00N=00>=00<=00/=00F=00O=00N=00=
T=00>=00<=00F=00O=00N=00T=00 =
=00f=00a=00c=00e=00=3D=00"=00T=00i=00m=00e=00s=00 =00N=00e=00w=00 =
=00R=00o=00m=00a=00n=00"=00 =
=00s=00i=00z=00e=00=3D=003=00>=00<=00S=00P=00A=00N=00 =00=0D=00=0A=
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =001=002=00p=00t=00"=00>=00A=00b=00o=00v=00e=00 =00c=00a=00s=00e=00 =
=00a=00r=00i=00s=00e=00s=00 =00t=00w=00o=00 =00=0D=00=0A=
=00q=00u=00e=00s=00t=00i=00o=00n=00s=00:=00<=00o=00:=00p=00>=00<=00/=00o=00=
:=00p=00>=00<=00/=00S=00P=00A=00N=00>=00<=00/=00F=00O=00N=00T=00>=00<=00/=
=00D=00I=00V=00>=00=0D=00=0A=
=00<=00O=00L=00 =00t=00y=00p=00e=00=3D=001=00>=00=0D=00=0A=
=00 =00 =00<=00L=00I=00 =
=00c=00l=00a=00s=00s=00=3D=00M=00s=00o=00N=00o=00r=00m=00a=00l=00 =00=0D=00=0A=
=00 =00 =
=00s=00t=00y=00l=00e=00=3D=00"=00m=00s=00o=00-=00m=00a=00r=00g=00i=00n=00=
-=00t=00o=00p=00-=00a=00l=00t=00:=00 =00a=00u=00t=00o=00;=00 =
=00m=00s=00o=00-=00m=00a=00r=00g=00i=00n=00-=00b=00o=00t=00t=00o=00m=00-=00=
a=00l=00t=00:=00 =00a=00u=00t=00o=00;=00 =
=00m=00s=00o=00-=00l=00i=00s=00t=00:=00 =00l=000=00 =
=00l=00e=00v=00e=00l=001=00 =00l=00f=00o=001=00;=00 =
=00t=00a=00b=00-=00s=00t=00o=00p=00s=00:=00 =00l=00i=00s=00t=00 =
=003=006=00.=000=00p=00t=00"=00>=00<=00F=00O=00N=00T=00 =00=0D=00=0A=
=00 =00 =00f=00a=00c=00e=00=3D=00"=00T=00i=00m=00e=00s=00 =
=00N=00e=00w=00 =00R=00o=00m=00a=00n=00"=00 =
=00s=00i=00z=00e=00=3D=003=00>=00<=00S=00P=00A=00N=00 =
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =001=002=00p=00t=00"=00>=00W=00h=00a=00t=00 =00e=00r=00r=00o=00r=00 =
=00c=00o=00d=00e=00 =00=0D=00=0A=
=00 =00 =00w=00i=00l=00l=00 =00b=00e=00 =
=00r=00e=00t=00u=00r=00n=00e=00d=00 =00s=00o=00 =00t=00h=00a=00t=00 =
=00r=00e=00q=00u=00e=00s=00t=00o=00r=00 =00c=00a=00n=00 =
=00u=00n=00d=00e=00r=00s=00t=00a=00n=00d=00 =00t=00h=00e=00 =
=00f=00a=00i=00l=00u=00r=00e=00 =00=0D=00=0A=
=00 =00 =
=00r=00e=00a=00s=00o=00n=00?=00<=00/=00S=00P=00A=00N=00>=00<=00/=00F=00O=00=
N=00T=00>=00=0D=00=0A=
=00 =00 =00<=00L=00I=00 =
=00c=00l=00a=00s=00s=00=3D=00M=00s=00o=00N=00o=00r=00m=00a=00l=00 =00=0D=00=0A=
=00 =00 =
=00s=00t=00y=00l=00e=00=3D=00"=00m=00s=00o=00-=00m=00a=00r=00g=00i=00n=00=
-=00t=00o=00p=00-=00a=00l=00t=00:=00 =00a=00u=00t=00o=00;=00 =
=00m=00s=00o=00-=00m=00a=00r=00g=00i=00n=00-=00b=00o=00t=00t=00o=00m=00-=00=
a=00l=00t=00:=00 =00a=00u=00t=00o=00;=00 =
=00m=00s=00o=00-=00l=00i=00s=00t=00:=00 =00l=000=00 =
=00l=00e=00v=00e=00l=001=00 =00l=00f=00o=001=00;=00 =
=00t=00a=00b=00-=00s=00t=00o=00p=00s=00:=00 =00l=00i=00s=00t=00 =
=003=006=00.=000=00p=00t=00"=00>=00<=00F=00O=00N=00T=00 =00=0D=00=0A=
=00 =00 =00f=00a=00c=00e=00=3D=00"=00T=00i=00m=00e=00s=00 =
=00N=00e=00w=00 =00R=00o=00m=00a=00n=00"=00 =
=00s=00i=00z=00e=00=3D=003=00>=00<=00S=00P=00A=00N=00 =
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =001=002=00p=00t=00"=00>=00I=00f=00 =00t=00h=00e=00r=00e=00 =
=00a=00r=00e=00 =00t=00w=00o=00 =00=0D=00=0A=
=00 =00 =00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00s=00 =00i=00n=00 =
=00q=00u=00e=00r=00y=00 =00a=00n=00d=00 =
=00K=00e=00y=00U=00s=00a=00g=00e=00 =00r=00e=00q=00u=00i=00r=00e=00d=00 =
=00i=00s=00 =
=00d=00i=00g=00i=00t=00a=00l=00s=00i=00g=00n=00a=00t=00u=00r=00e=00 =
=00i=00n=00 =00e=00a=00c=00h=00 =00=0D=00=0A=
=00 =00 =00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =00b=00u=00t=00 =
=00i=00n=00 =00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00 =
=00s=00e=00r=00v=00e=00r=00 =00f=00o=00u=00n=00d=00 =00t=00h=00a=00t=00 =
=00o=00n=00e=00 =00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =
=00h=00a=00s=00 =00=0D=00=0A=
=00 =00 =
=00d=00i=00g=00i=00t=00a=00l=00s=00i=00g=00n=00a=00t=00u=00r=00e=00 =
=00w=00h=00i=00l=00e=00 =00o=00t=00h=00e=00r=00 =00n=00o=00t=00.=00 =
=00I=00n=00 =00t=00h=00i=00s=00 =00c=00a=00s=00e=00 =
=00s=00e=00r=00v=00e=00r=00 =00s=00h=00o=00u=00l=00d=00 =00n=00o=00t=00 =
=00r=00e=00t=00u=00r=00n=00 =00e=00r=00r=00o=00r=00 =00=0D=00=0A=
=00 =00 =00c=00o=00d=00e=00 =00f=00o=00r=00 =
=00s=00c=00v=00p=00r=00e=00s=00p=00o=00n=00s=00e=00 =00b=00u=00t=00 =
=00s=00h=00o=00u=00l=00d=00 =00r=00e=00t=00u=00r=00n=00 =
=00e=00r=00r=00o=00r=00 =00c=00o=00d=00e=00 =00f=00o=00r=00 =
=00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00,=00 =00s=00o=00 =00=0D=00=0A=
=00 =00 =00b=00y=00 =00t=00h=00i=00s=00 =00c=00a=00s=00e=00 =
=00r=00e=00p=00l=00y=00O=00b=00j=00e=00c=00t=00 =
=00s=00t=00r=00u=00c=00t=00u=00r=00e=00 =00s=00h=00o=00u=00l=00d=00 =
=00h=00a=00v=00e=00 =
=00c=00o=00r=00r=00e=00s=00p=00o=00n=00d=00i=00n=00g=00 =
=00e=00r=00r=00o=00r=00 =00=0D=00=0A=
=00 =00 =00c=00o=00d=00e=00.=00<=00B=00R=00>=00T=00h=00e=00r=00e=00 =
=00m=00a=00y=00 =00b=00e=00 =00o=00n=00e=00 =00o=00f=00 =00t=00w=00o=00 =
=00r=00e=00a=00s=00o=00n=00s=00 =00t=00h=00a=00t=00 =
=00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =00h=00a=00s=00 =
=00n=00o=00t=00 =00=0D=00=0A=
=00 =00 =00r=00e=00q=00u=00i=00r=00e=00d=00 =
=00b=00i=00t=00(=00s=00)=00:=00<=00B=00R=00>=00-=00 =
=00q=00u=00e=00r=00i=00e=00d=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =00i=00s=00 =
=00v=00e=00r=00s=00i=00o=00n=00 =001=00<=00B=00R=00>=00-=00 =
=00q=00u=00e=00r=00i=00e=00d=00 =00=0D=00=0A=
=00 =00 =00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =00i=00s=00 =
=00v=00e=00r=00s=00i=00o=00n=00 =003=00 =00b=00u=00t=00 =00h=00a=00s=00 =
=00n=00o=00t=00 =00r=00e=00q=00u=00i=00r=00e=00d=00 =
=00b=00i=00t=00(=00s=00)=00<=00B=00R=00>=00*=00 =00I=00 =
=00a=00s=00s=00u=00m=00e=00 =00t=00h=00a=00t=00 =00i=00n=00 =00=0D=00=0A=
=00 =00 =00c=00a=00s=00e=00 =00o=00f=00 =00v=00e=00r=00s=00i=00o=00n=00 =
=001=00 =00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00,=00 =00w=00e=00 =
=00w=00i=00l=00l=00 =00c=00o=00n=00t=00i=00n=00u=00e=00 =
=00p=00r=00o=00c=00e=00s=00s=00i=00n=00g=00 =00w=00h=00i=00l=00e=00 =
=00f=00o=00r=00 =00v=00e=00r=00s=00i=00o=00n=00 =003=00 =00=0D=00=0A=
=00 =00 =00w=00e=00 =00w=00i=00l=00l=00 =
=00g=00e=00n=00e=00r=00a=00t=00e=00 =00s=00o=00m=00e=00 =
=00e=00r=00r=00o=00r=00.=00<=00/=00S=00P=00A=00N=00>=00<=00/=00F=00O=00N=00=
T=00>=00<=00/=00L=00I=00>=00<=00/=00O=00L=00>=00<=00F=00O=00N=00T=00 =
=00f=00a=00c=00e=00=3D=00"=00T=00i=00m=00e=00s=00 =00N=00e=00w=00 =
=00R=00o=00m=00a=00n=00"=00 =00=0D=00=0A=
=00s=00i=00z=00e=00=3D=003=00>=00<=00S=00P=00A=00N=00 =
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =001=002=00p=00t=00"=00>=00=0D=00=0A=
=00<=00D=00I=00V=00 =
=00c=00l=00a=00s=00s=00=3D=00M=00s=00o=00N=00o=00r=00m=00a=00l=00 =00=0D=00=0A=
=00s=00t=00y=00l=00e=00=3D=00"=00m=00s=00o=00-=00m=00a=00r=00g=00i=00n=00=
-=00t=00o=00p=00-=00a=00l=00t=00:=00 =00a=00u=00t=00o=00;=00 =
=00m=00s=00o=00-=00m=00a=00r=00g=00i=00n=00-=00b=00o=00t=00t=00o=00m=00-=00=
a=00l=00t=00:=00 =00a=00u=00t=00o=00;=00 =
=00m=00s=00o=00-=00l=00i=00s=00t=00:=00 =00l=000=00 =
=00l=00e=00v=00e=00l=001=00 =00l=00f=00o=001=00;=00 =
=00t=00a=00b=00-=00s=00t=00o=00p=00s=00:=00 =00l=00i=00s=00t=00 =
=003=006=00.=000=00p=00t=00"=00>=00<=00/=00S=00P=00A=00N=00>=00<=00/=00F=00=
O=00N=00T=00>=00<=00F=00O=00N=00T=00 =00=0D=00=0A=
=00f=00a=00c=00e=00=3D=00"=00T=00i=00m=00e=00s=00 =00N=00e=00w=00 =
=00R=00o=00m=00a=00n=00"=00 =
=00s=00i=00z=00e=00=3D=003=00>=00<=00S=00P=00A=00N=00 =
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =001=002=00p=00t=00"=00>=00S=00a=00m=00e=00 =00c=00a=00s=00e=00 =
=00a=00s=00 =00=0D=00=0A=
=00d=00i=00s=00c=00u=00s=00s=00e=00d=00 =00a=00b=00o=00v=00e=00 =
=00c=00a=00n=00 =00o=00c=00c=00u=00r=00 =00f=00o=00r=00 =
=00E=00x=00t=00e=00n=00d=00e=00d=00K=00e=00y=00U=00s=00a=00g=00e=00 =
=00=0D=00=0A=
=00O=00I=00D=00(=00s=00)=00.=00.=00.=00.=00<=00o=00:=00p=00>=00<=00/=00o=00=
:=00p=00>=00<=00/=00S=00P=00A=00N=00>=00<=00/=00F=00O=00N=00T=00>=00<=00/=
=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00=0D=00=0A=
=00<=00P=00 =
=00c=00l=00a=00s=00s=00=3D=00M=00s=00o=00N=00o=00r=00m=00a=00l=00>=00<=00=
F=00O=00N=00T=00 =00f=00a=00c=00e=00=3D=00"=00T=00i=00m=00e=00s=00 =
=00N=00e=00w=00 =00R=00o=00m=00a=00n=00"=00 =
=00s=00i=00z=00e=00=3D=003=00>=00<=00S=00P=00A=00N=00 =00=0D=00=0A=
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =
=001=002=00p=00t=00"=00>=00<=00o=00:=00p=00>=00<=00/=00o=00:=00p=00>=00<=00=
/=00S=00P=00A=00N=00>=00<=00/=00F=00O=00N=00T=00>=00<=00/=00P=00>=00<=00/=
=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00=0D=00=0A=
=00<=00P=00 =
=00c=00l=00a=00s=00s=00=3D=00M=00s=00o=00N=00o=00r=00m=00a=00l=00>=00<=00=
F=00O=00N=00T=00 =00f=00a=00c=00e=00=3D=00"=00T=00i=00m=00e=00s=00 =
=00N=00e=00w=00 =00R=00o=00m=00a=00n=00"=00 =
=00s=00i=00z=00e=00=3D=003=00>=00<=00S=00P=00A=00N=00 =00=0D=00=0A=
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =001=002=00p=00t=00"=00>=00D=00o=00 =00y=00o=00u=00 =00h=00a=00v=00e=00 =
=00a=00n=00y=00 =00i=00d=00e=00a=00 =00o=00r=00 =00I=00 =00a=00m=00 =
=00m=00i=00s=00s=00i=00n=00g=00 =00s=00o=00m=00e=00 =
=00t=00h=00i=00n=00g=00 =00f=00r=00o=00m=00 =00=0D=00=0A=
=00p=00r=00o=00t=00o=00c=00o=00l=00 =
=00?=00<=00o=00:=00p=00>=00<=00/=00o=00:=00p=00>=00<=00/=00S=00P=00A=00N=00=
>=00<=00/=00F=00O=00N=00T=00>=00<=00/=00P=00>=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00=0D=00=0A=
=00<=00P=00 =
=00c=00l=00a=00s=00s=00=3D=00M=00s=00o=00N=00o=00r=00m=00a=00l=00>=00<=00=
F=00O=00N=00T=00 =00f=00a=00c=00e=00=3D=00"=00T=00i=00m=00e=00s=00 =
=00N=00e=00w=00 =00R=00o=00m=00a=00n=00"=00 =
=00s=00i=00z=00e=00=3D=003=00>=00<=00S=00P=00A=00N=00 =00=0D=00=0A=
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =
=001=002=00p=00t=00"=00>=00<=00/=00S=00P=00A=00N=00>=00<=00/=00F=00O=00N=00=
T=00>=00<=00F=00O=00N=00T=00 =
=00f=00a=00c=00e=00=3D=00"=00T=00i=00m=00e=00s=00 =00N=00e=00w=00 =
=00R=00o=00m=00a=00n=00"=00 =
=00s=00i=00z=00e=00=3D=003=00>=00<=00S=00P=00A=00N=00 =00=0D=00=0A=
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00-=00S=00I=00Z=00E=00:=00=
 =
=001=002=00p=00t=00"=00>=00R=00e=00g=00a=00r=00d=00s=00,=00<=00B=00R=00>=00=
F=00a=00i=00s=00a=00l=00<=00/=00S=00P=00A=00N=00>=00<=00/=00F=00O=00N=00T=
=00>=00<=00/=00P=00>=00<=00/=00D=00I=00V=00>=00<=00/=00B=00O=00D=00Y=00>=00=
<=00/=00H=00T=00M=00L=00>=00=0D=00=0A=
=00
------=_NextPart_000_00D0_01C49B1B.B888ECA0--

From: "Faisal Maqsood" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, <[email-masked]>
Subject: Re: SCVP Validation OID
Date: Wed, 15 Sep 2004 11:24:56 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_006A_01C49B16.A10965F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Trevor,

I am slightly confused with the answers given. What I have understood by =
the answer of Question 2 is that Server can define customizable OIDs and =
associate TrustAnchors, policy oid associated with each TA, revocation =
information (CRLs, OCSP Responses) etc but in section 3.2.21 its stated =
that "client and server can optionally agree a set of parameters which =
may fully or partially define a validation policy". I believe that these =
set of parameters are similar to the one defined by validationAlg (See =
answer to Question 2 below). If I am correct then I don't think there is =
a need for a seperate validationPolRef.

In the answer to question 4, you have stated that "If the referenced =
policy also defines an algorithm then the algorithm OID can be omitted =
from the request". What do you mean by omitted ? Does this mean to =
ignore it by server ?

Can you please tell me what is expected date to publish draft 16 ?

Regards,
Faisal
  ----- Original Message -----=20
  From: Trevor Freeman=20
  To: Faisal Maqsood ; [email-masked]=20
  Sent: Tuesday, September 14, 2004 22:17
  Subject: RE: SCVP Validation OID

  Hi All,

  Question 1

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

  I need to know that if fullPolResponse is set to TRUE then what values =
are set in valPolResponse and validaionPolRef in SCVP Response. After =
reading the draft 15 doc, in my opinion, if fullPolResponse is TRUE then =
valPolResponse is set and returned and validaionPolRef is not set. If =
fullPolResponse is FALSE then validationPolRef is set and valPolResponse =
is not set. Can some one clarify.

  [TF] If a policy has been specified it should always be used. The only =
difference should be whether the actual values are include in addition =
to the policy. This has been clarified in 16.

  Question 2

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

  Is validationAlg (defined in 3.2.12) is the same as explained in =
section 1.3 ? i.e. The validationAlg in 3.2.12 will be used by server to =
define default inputs to the certificate path processing.

  [TF] Yes they are the same.

  Question 3

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

  How would server behave if in a SCVP Request user has set both =
validationAlg and validationPolRef  where validationAlg points to a =
default validation algorithm?

  [TF] 3.2.21 states "If there are any conflicts between the policy =
referenced in the request and any supplied values in the request then =
the server MUST return an error."

  Question 4

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

  If server defines an OID and bound some configuration with this OID, =
e.g. TrustAnchors, RevocationInfo, ValidationParameters etc then will =
client either use this OID in ValidationAlg or in validationPolRef ?

  [TF] If the referenced policy also defines an algorithm then the =
algorithm OID can be omitted from the request.

  Regards,

  Faisal

------=_NextPart_000_006A_01C49B16.A10965F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:ns0 =3D "urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR><BASE=20
href=3Dfile:///F:\_BackUp-FM\Email%20Signature\>
<STYLE>@font-face {
	font-family: Device Font 10cpi;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 0pt 180.0pt 0pt 0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue bgColor=3Dwhite>
<DIV><FONT face=3DArial size=3D2>Hi Trevor,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I am slightly confused with the answers =

given.&nbsp;What&nbsp;I have understood by the&nbsp;answer of Question 2 =
is that=20
Server can define customizable OIDs and associate TrustAnchors, policy =
oid=20
associated with each TA, revocation information (CRLs, OCSP =
Responses)&nbsp;etc=20
but in section 3.2.21 its stated that "client and server can optionally =
agree a=20
set of parameters which may fully or partially define a validation =
policy". I=20
believe that these set of parameters are similar to the one defined by =
<FONT=20
face=3D"Times New Roman" size=3D3>validationAlg (See answer to Question =
2 below).=20
If&nbsp;I am correct then I don't think there is a need for a seperate=20
validationPolRef.</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>In the answer to&nbsp;question 4, you have stated that&nbsp;<FONT=20
face=3DArial><FONT color=3D#ff0000 size=3D2>"If the referenced policy =
also defines an=20
algorithm then the algorithm OID can be omitted from the request". <FONT =

color=3D#000000>What do you mean by omitted ? Does this mean to ignore =
it by=20
server&nbsp;?</FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Can you please tell me what is expected =

date&nbsp;to&nbsp;publish draft 16 ?</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=[email-masked]=20
  href=3D"mailto:[email-masked]">Trevor Freeman</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Faisal Maqsood</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">[email-masked]</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, September 14, =
2004=20
  22:17</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: SCVP Validation =
OID</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
  face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
  size=3D2></FONT><FONT face=3DArial size=3D2></FONT><BR></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0pt; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0pt; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0pt; BORDER-BOTTOM: medium none">
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Hi All,</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Question 1</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">--------------</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">I need to know that if fullPolResponse is =
set=20
  to&nbsp;TRUE then what values are set in valPolResponse and =
validaionPolRef in=20
  SCVP Response. After reading the draft 15 doc, in my opinion, if=20
  fullPolResponse is TRUE then valPolResponse is set and returned and=20
  validaionPolRef is not set. If fullPolResponse is FALSE then =
validationPolRef=20
  is set and valPolResponse is not set. Can some one =
clarify.</SPAN></FONT></P>
  <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: =
italic; FONT-FAMILY: Arial">[TF]=20
  If a policy has been specified it should always be used. The only =
difference=20
  should be whether the actual values are include in addition to the =
policy.=20
  This has been clarified in 16.</SPAN></FONT></I></B></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Question 2</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">------------</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Is validationAlg (defined in&nbsp;3.2.12) is =
the same=20
  as explained in section 1.3 ? i.e. The validationAlg&nbsp;in 3.2.12 =
will be=20
  used by server to define default inputs to the certificate path=20
  processing.</SPAN></FONT></P>
  <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: =
italic; FONT-FAMILY: Arial">[TF]=20
  Yes they are the same.</SPAN></FONT></I></B></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Question 3</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">-------------</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">How would server behave if in a SCVP Request =
user has=20
  set both validationAlg and validationPolRef&nbsp; where validationAlg =
points=20
  to a default validation algorithm?</SPAN></FONT></P>
  <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: =
italic; FONT-FAMILY: Arial">[TF]=20
  3.2.21 states &#8220;If there are any conflicts between the policy =
referenced in the=20
  request and any supplied values in the request then the server MUST =
return an=20
  error.&#8221;</SPAN></FONT></I></B></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P></DIV>
  <DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Question 4</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">-------------</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">If server defines an OID and bound some =
configuration=20
  with this OID, e.g. TrustAnchors, RevocationInfo, ValidationParameters =
etc=20
  then will client either use this OID in ValidationAlg or in =
validationPolRef=20
  ?</SPAN></FONT></P>
  <P class=3DMsoNormal><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; FONT-STYLE: =
italic; FONT-FAMILY: Arial">[TF]=20
  If the referenced policy also defines an algorithm then the algorithm =
OID can=20
  be omitted from the request.</SPAN></FONT></I></B></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Regards,</SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: =
12pt">Faisal</SPAN></FONT></P></DIV></DIV></DIV></BLOCKQUOTE></BODY></HTM=
L>

------=_NextPart_000_006A_01C49B16.A10965F0--

To: [email-masked]
Subject: RFC 3874 on A 224-bit One-way Hash Function: SHA-224
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Tue, 14 Sep 2004 17:31:43 -0700
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3874

        Title:      A 224-bit One-way Hash Function: SHA-224
        Author(s):  R. Housley
        Status:     Informational
        Date:       September 2004
        Mailbox:    [email-masked]
        Pages:      6
        Characters: 11600
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-sha224-01.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3874.txt

This document specifies a 224-bit one-way hash function, called
SHA-224.  SHA-224 is based on SHA-256, but it uses a different
initial value and the result is truncated to 224 bits.

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

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc3874

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3874.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

To: [email-masked]
Subject: RFC 3874 on A 224-bit One-way Hash Function: SHA-224
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Tue, 14 Sep 2004 17:31:42 -0700
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3874

        Title:      A 224-bit One-way Hash Function: SHA-224
        Author(s):  R. Housley
        Status:     Informational
        Date:       September 2004
        Mailbox:    [email-masked]
        Pages:      6
        Characters: 11600
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-sha224-01.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3874.txt

This document specifies a 224-bit one-way hash function, called
SHA-224.  SHA-224 is based on SHA-256, but it uses a different
initial value and the result is truncated to 224 bits.

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

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc3874

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3874.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

From: "Laudon Williams" <[email-masked]>
To: <[email-masked]>
Cc: "'Stephen Kent'" <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 15:40:08 -0700
Sender: [email-masked]

So just to finalize this (feel free to rebut Steve)...

When faced with CA expiration, you have two choices. You can either;
- Rollover the key (same name, new key), or;
- Rollover the CA (new name, new key).

Key rollover *may* work in closed systems, but as evidenced by the original
discussion on this thread, is not consistently implemented. YMMV. If a
mechanism for this is standardized, it may work more consistently at some
point in the future.

CA rollover *does* work with the large majority of relying party software in
the world today. It violates no standards, and is highly compatible. For the
majority of PKIs deployed today, it should be the preferred solution.

I would ask that if CA expiration is addressed in 3280bis, we ensure that
both mechanisms receive adequate coverage.

Regards,

-Laudon 

Date: Tue, 14 Sep 2004 17:21:13 -0400
From: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Validation of a CRL without IDP should require only a name match, using 
fully-qualified
names to a common trust anchor as described by Santosh's algorithm.

DNS works properly in the face of hostname and name component duplications.
The requirement to compare only FQDNs is so obvious as to not even require
discussion.   It would be nice if every CA in the universe partcipated 
in the
global Directory Information Tree and every DN uniquely identified a node
in that tree.  But since actual CAs practice only local naming consistency,
a full certification name path is necessary and sufficient.  Key matching is
not necessary.

----------

On a totally separate issue, I agree with Laudon Williams that changing CA
names when rekeying is a useful practice to work around application 
limitations,
just as having a single certifying organization operate hundreds or 
thousands
of CA names/keys is useful to allow CRL partitioning in the face of 
applications
that don't grok IDP.  Standards-compliant applications would be better,
but "making things work" with non-compliant apps is OK as long as CAs
don't become non-compliant as a result.

Dave

Stephen Kent wrote:

> At 8:13 PM +0100 9/14/04, Stefan Santesson wrote:
>
>> ... What I ask this group to consider is
>> whether validation of a CRL without IDP should require both name AND key
>> match.
>
> ...
> So, yes, the issue before us is whether we need to change the criteria 
> for CRL validation, as noted. I think we are still debating this issue.

Date: Tue, 14 Sep 2004 15:37:28 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Cc: "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 8:13 PM +0100 9/14/04, Stefan Santesson wrote:
>I think this requires for some kind of response.
>
>>  And anyway, the solution Microsoft employees favor is to use IDP
>>  everytime the CRL is not signed with the same key as the CA.
>
>Participation on this list is done by individuals contributing to
>development of good public standards.
>
>In doing so some of us share open facts and experiences from the
>products we work with.
>That is NOT intended as a public declaration of best practices.
>
>And your conclusion is wrong. What I ask this group to consider is
>whether validation of a CRL without IDP should require both name AND key
>match.

Stefan,

I respect your ability to maintain the employer/individual 
perspective that you stated. Your comments have shown this to be the 
case over time.

So, yes, the issue before us is whether we need to change the 
criteria for CRL validation, as noted. I think we are still debating 
this issue.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 15:30:33 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

There was a minor error in step 2. N1 should be reduced by 1 since the end
entity certificate does not play a role in name matching.  (Of course both
standard and X.509 already require that for direct CRL Issuer field in end
certificate = Issuer field in CRL)

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2004 2:58 PM
To: [email-masked]'
Subject: RE: CA Rekey and CRL Validation

Stefan:

If the relying party has two CA's with the same name X, but really represent
different real entities, the relying party is going to have bigger problem
of disambiguation than correct CRL.

Similarly, if the relying party has two intermediate CAs named Y, under the
same certification path, you have bigger problem of disambiguation than
correct CRL.  Also, no CA I know will certify the two different CAs with the
same name.  That has to happen for this to occur.

So, I will assume that neither of these two is the case.

Then, the problem boils down of matching the certification path for the
certificate and the certification path for the CRL used to check the
revocation status of the certificate.

The following rules should be used to ensure that you have the CRL from the
appropriate CA:

1.  The DN of the root in both cases must match.

2.  Set I = 1.  N1 = number of certificates in the "certificate
certification path" - 1, ignoring self-issued certificates.  Set N2 = number
of certificates in the "CRL certification path", ignoring self-issued
certificates. 

3.  If I = N1 or I = N2 exit with success

4.  Verify that the issuer DN in certificate I in the "certificate
certification path" matches the issuer DN in certificate I in the "CRL
certification path", ignoring self-issued certificates.

5.  Verify that the subject DN in  certificate I in the "certificate
certification path" matches the subject DN in certificate I in the "CRL
certification path", ignoring self-issued certificates.

6.  I = I + 1.  Go to step 3

{BTW, this has been explored and explained on this mail list couple of
times)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, September 14, 2004 9:52 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh.

CA1 and CA1(bis) have the same name but different keys.

They are both valid in the RPs trust configuration.

Both CAs issue CRLs without IDP (which is RFC 3280 and X.509 compliant
practice).

Result: The RP can't determine what CRL and what CA belongs together
resulting in false acceptance of revoked certificates.

You can call it what you want. 
I call that a security vulnerability. 

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 14:36
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> There is no security problem in building a certification path for the
CRL
> Issuer when the same CA issues the CRL, but signs the CRL using a 
> different key (i.e., different from the one used to sign the 
> certificate being validated).
> 
> You can build a path.  You do need to do name matching as I have said
in
> several previous postings.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, September 14, 2004 7:09 AM
> To: Manger, James H; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> James,
> 
> I don't agree with your examples.
> 
> The "simple" structure that dominates deployment today is 1 CA = 1 key 
> which has the consequences you mention.
> 
> However, the stanards define also indirect CRLs which can be used to
solve
> all your issues below EVEN if you stick with the definition 1 CA = 1
key.
> 
> The issue at hand, previously stated to Santosh is whether a CRL
without
> IDP
> can be validated with another key than the one used to validate 
> certificates issued by the CA.
> 
> If that is allowed, then we have identified a security problem that
ought
> to
> be fixed.
> 
> /Stefan
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Manger, James H
> > Sent: den 14 september 2004 06:36
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Same name, different key = SAME CA.
> >
> > Without this, if a CA's private key is destroyed no CRLs can ever be 
> > issued again for the certs it has issued so that CA's whole PKI
> crumbles
> > in an instant.
> > Without this, every CA needs to keep operating (issuing CRLs) after
it
> has
> > issued its last cert for the lifetime it was putting in certs (eg 2,
> 5, 10
> > years?).
> > Without this, every certifier wanting to periodically change keys
> (which
> > is good practice) needs to run multiple CAs.
> >
> >
> >
> >
> > P.S. There are ways to ensure name uniqueness for CAs -- either 
> > concatenate issuer names from a trust anchor to the CA of interest
to
> get
> > that CA's "name", or just use the issuer field for that CA and rely
on
> > your configured trusted anchors to name CAs in a way that avoids
> ambiguity
> > (which is, in fact, the primary reason for a PKI in the first
place).
> >
> >
> >
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[email-masked]]
> > Sent: Tuesday, 14 September 2004 8:53 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> >
> > Santosh,
> >
> > I realize that the standard is not crystal clear on this issue and I 
> > suggest that you either have the wrong interpretation, or at least
use
> > an interpretation that ought to be wrong.
> >
> > The core issue is whether two CAs having the same name but different 
> > private issuing keys, are regarded as 1 CA or 2 separate CAs.
> >
> > I suggest (and hope) that these are NOT defined anywhere as being
the
> > same CA. This is also supported by the reality fact that there is no
> way
> > that you can ensure name uniqueness between CAs and therefore,
> key-match
> > should be a requirement.
> >
> > From this perspective standards states the following:
> >
> > X.509 Annex B states:
> >
> >    If the cRLIssuer field is absent from the CRL distribution point 
> > extension of the certificate, the CRL shall be signed by the same CA 
> > that signed the certificate; and
> >    If the cRLIssuer field is present in the CRL distribution point
> > extension of the certificate, the CRL shall be signed by the CRL
> Issuer
> > identified in the CRL distribution point extension of the
certificate
> > and the CRL shall contain the indirectCRL field in the issuing 
> > distribution point extension.
> >
> > RFC 3280 5.2.5 states:
> >
> >    The CRL issuer MUST assert the indirectCRL boolean, if the scope
of
> >    the CRL includes certificates issued by authorities other than
the
> >    CRL issuer.
> >
> >
> > So IF different signing keys means that CA(old) and CA(new) are 
> > different CAs (despite identical names), then in order to allow
> CRL(new)
> > from CA(new) to be used to validate certificates from CA(old), then
> > CRL(new) need to contain an IDP with indirectCRL asserted,
> certificates
> > from CA(old) must also contain a CDP with cRLIssuer field.
> >
> > I suggest therefore that a CRL without IDP with indirectCRL is
> required
> > to be signed with the same key that was used to sign the certificate 
> > being validated.
> >
> > If that is not clear by today's standard text, then I suggest that
it
> > should.
> >
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> 
> 

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 20:13:03 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I think this requires for some kind of response.

> And anyway, the solution Microsoft employees favor is to use IDP
> everytime the CRL is not signed with the same key as the CA.

Participation on this list is done by individuals contributing to
development of good public standards.

In doing so some of us share open facts and experiences from the
products we work with.
That is NOT intended as a public declaration of best practices.

And your conclusion is wrong. What I ask this group to consider is
whether validation of a CRL without IDP should require both name AND key
match.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Jean-Marc Desperrier
> Sent: den 14 september 2004 19:42
> To: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> Laudon Williams wrote:
> 
> >Who is not employed by Microsoft, no matter how much Steve wants to
make
> >this political :-)
> >
> >
> And anyway, the solution Microsoft employees favor is to use IDP
> everytime the CRL is not signed with the same key as the CA.
> 
> What you present us is what I would call the Verisign way of solving
the
> problem by avoiding it all fully ...
> 
> I agree it's the only method that would work with currently deployed
> software, but a perfectly clearly defined way to correctly rekey for a
> future generation of products would be useful. And does not have to be
> that complex ...

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 14:58:11 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

If the relying party has two CA's with the same name X, but really represent
different real entities, the relying party is going to have bigger problem
of disambiguation than correct CRL.

Similarly, if the relying party has two intermediate CAs named Y, under the
same certification path, you have bigger problem of disambiguation than
correct CRL.  Also, no CA I know will certify the two different CAs with the
same name.  That has to happen for this to occur.

So, I will assume that neither of these two is the case.

Then, the problem boils down of matching the certification path for the
certificate and the certification path for the CRL used to check the
revocation status of the certificate.

The following rules should be used to ensure that you have the CRL from the
appropriate CA:

1.  The DN of the root in both cases must match.

2.  Set I = 1.  N1 = number of certificates in the "certificate
certification path", ignoring self-issued certificates.  Set N2 = number of
certificates in the "CRL certification path", ignoring self-issued
certificates. 

3.  If I = N1 or I = N2 exit with success

4.  Verify that the issuer DN in certificate I in the "certificate
certification path" matches the issuer DN in certificate I in the "CRL
certification path", ignoring self-issued certificates.

5.  Verify that the subject DN in  certificate I in the "certificate
certification path" matches the subject DN in certificate I in the "CRL
certification path", ignoring self-issued certificates.

6.  I = I + 1.  Go to step 3

{BTW, this has been explored and explained on this mail list couple of
times)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, September 14, 2004 9:52 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh.

CA1 and CA1(bis) have the same name but different keys.

They are both valid in the RPs trust configuration.

Both CAs issue CRLs without IDP (which is RFC 3280 and X.509 compliant
practice).

Result: The RP can't determine what CRL and what CA belongs together
resulting in false acceptance of revoked certificates.

You can call it what you want. 
I call that a security vulnerability. 

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 14:36
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> There is no security problem in building a certification path for the
CRL
> Issuer when the same CA issues the CRL, but signs the CRL using a
> different key (i.e., different from the one used to sign the 
> certificate being validated).
> 
> You can build a path.  You do need to do name matching as I have said
in
> several previous postings.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, September 14, 2004 7:09 AM
> To: Manger, James H; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> James,
> 
> I don't agree with your examples.
> 
> The "simple" structure that dominates deployment today is 1 CA = 1 key
> which has the consequences you mention.
> 
> However, the stanards define also indirect CRLs which can be used to
solve
> all your issues below EVEN if you stick with the definition 1 CA = 1
key.
> 
> The issue at hand, previously stated to Santosh is whether a CRL
without
> IDP
> can be validated with another key than the one used to validate
> certificates issued by the CA.
> 
> If that is allowed, then we have identified a security problem that
ought
> to
> be fixed.
> 
> /Stefan
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Manger, James H
> > Sent: den 14 september 2004 06:36
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Same name, different key = SAME CA.
> >
> > Without this, if a CA's private key is destroyed no CRLs can ever be
> > issued again for the certs it has issued so that CA's whole PKI
> crumbles
> > in an instant.
> > Without this, every CA needs to keep operating (issuing CRLs) after
it
> has
> > issued its last cert for the lifetime it was putting in certs (eg 2,
> 5, 10
> > years?).
> > Without this, every certifier wanting to periodically change keys
> (which
> > is good practice) needs to run multiple CAs.
> >
> >
> >
> >
> > P.S. There are ways to ensure name uniqueness for CAs -- either
> > concatenate issuer names from a trust anchor to the CA of interest
to
> get
> > that CA's "name", or just use the issuer field for that CA and rely
on
> > your configured trusted anchors to name CAs in a way that avoids
> ambiguity
> > (which is, in fact, the primary reason for a PKI in the first
place).
> >
> >
> >
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[email-masked]]
> > Sent: Tuesday, 14 September 2004 8:53 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> >
> > Santosh,
> >
> > I realize that the standard is not crystal clear on this issue and I
> > suggest that you either have the wrong interpretation, or at least
use
> > an interpretation that ought to be wrong.
> >
> > The core issue is whether two CAs having the same name but different
> > private issuing keys, are regarded as 1 CA or 2 separate CAs.
> >
> > I suggest (and hope) that these are NOT defined anywhere as being
the
> > same CA. This is also supported by the reality fact that there is no
> way
> > that you can ensure name uniqueness between CAs and therefore,
> key-match
> > should be a requirement.
> >
> > From this perspective standards states the following:
> >
> > X.509 Annex B states:
> >
> >    If the cRLIssuer field is absent from the CRL distribution point
> > extension of the certificate, the CRL shall be signed by the same CA 
> > that signed the certificate; and
> >    If the cRLIssuer field is present in the CRL distribution point 
> > extension of the certificate, the CRL shall be signed by the CRL
> Issuer
> > identified in the CRL distribution point extension of the
certificate
> > and the CRL shall contain the indirectCRL field in the issuing
> > distribution point extension.
> >
> > RFC 3280 5.2.5 states:
> >
> >    The CRL issuer MUST assert the indirectCRL boolean, if the scope
of
> >    the CRL includes certificates issued by authorities other than
the
> >    CRL issuer.
> >
> >
> > So IF different signing keys means that CA(old) and CA(new) are
> > different CAs (despite identical names), then in order to allow
> CRL(new)
> > from CA(new) to be used to validate certificates from CA(old), then
> > CRL(new) need to contain an IDP with indirectCRL asserted,
> certificates
> > from CA(old) must also contain a CDP with cRLIssuer field.
> >
> > I suggest therefore that a CRL without IDP with indirectCRL is
> required
> > to be signed with the same key that was used to sign the certificate
> > being validated.
> >
> > If that is not clear by today's standard text, then I suggest that
it
> > should.
> >
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> 
> 

Date: Tue, 14 Sep 2004 13:35:29 -0400
To: "Laudon Williams" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Cc: <[email-masked]>
Sender: [email-masked]

At 9:21 AM -0700 9/14/04, Laudon Williams wrote:
>The "solution" you cite (changing the name of the CA using a naming
>convention analogous to serial numbering) is NOT standards compliant
>unless we change the definition of a CA, and does not work
>automatically with software.
>
>[LW] I don't think you've really made that case. You said it was the same
>CA. I never did. I just said rollover. You jumped to a bunch of conclusions.
>You keep trying to make it the same CA. I keep saying it is a different CA
>(new name and key). It just operates under the same policies and practices
>as the old one.

Sorry if I jumped to that conclusion.  I think the other folks 
discussing this topic have focused on that aspect of the issue, based 
on the exchanges that Santosh and Stefan have had, for example.

if the new CA is not assumed to be elated to the old one, but it 
"happens" to share the same policies, then it may be very similar, 
maybe even equivalent. but, that says nothing about it's legitimacy 
to issue certs for any set of users. So, if one made a value 
judgement about accepting the old CA as an issuer for a set of users, 
one has to go back and make the same judgement for the new CA. As I 
noted, this is not an automated process, and it imposes a burden on 
users, unless we assume that the users will just ignore these details 
and hope for the best :-)

In the case of browsers, the trust anchor model is seriously broken 
anyway, so that does not provide a suitable basis for determining the 
suitability of this sort of CA rollover in general.

>
>BTW, are you the same Laudon Williams who is a Microsoft program
>manager dealing with PKI? If so, then it might be more appropriate to
>use your corporate  e-mail address in these discussions, so that list
>participants are aware of potential corporate biases that may arise
>in these discussions.
>
>[LW] I've posted under this alias when I worked for CyberSafe, RSA Security,
>and Microsoft because it represents my opinion, not that of my employer. In
>the one case where I've posted to this list with an "official" response, I
>made it clear who I was.  But, as it stands, I no longer work for Microsoft.
>I'm back in the field trying to make this stuff work for the average
>company. And yes Steve, I have a bias to making things work given the
>current operating environment. I don't have a bias towards a particular
>vendor implementation.

I too have biases, though they are not based on vendor affiliation, 
since BBN is not a product vendor.  My bias is against "making things 
work" based on non-compliant implementations. Doing so encourages 
vendors to not follow standards, i.e., it sends the wrong message.

Steve

Date: Tue, 14 Sep 2004 19:42:28 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Laudon Williams wrote:

>Who is not employed by Microsoft, no matter how much Steve wants to make
>this political :-)
>  
>
And anyway, the solution Microsoft employees favor is to use IDP 
everytime the CRL is not signed with the same key as the CA.

What you present us is what I would call the Verisign way of solving the 
problem by avoiding it all fully ...

I agree it's the only method that would work with currently deployed 
software, but a perfectly clearly defined way to correctly rekey for a 
future generation of products would be useful. And does not have to be 
that complex ...

Content-class: urn:content-classes:message
Subject: RE: SCVP Validation OID
Date: Tue, 14 Sep 2004 10:17:43 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPartTM-000-43afa6a8-c843-4129-809b-5be9df929df6
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C49A7E.C1EB422E"

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

=20

=20

Hi All,

=20

Question 1

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

I need to know that if fullPolResponse is set to TRUE then what values
are set in valPolResponse and validaionPolRef in SCVP Response. After
reading the draft 15 doc, in my opinion, if fullPolResponse is TRUE then
valPolResponse is set and returned and validaionPolRef is not set. If
fullPolResponse is FALSE then validationPolRef is set and valPolResponse
is not set. Can some one clarify.

[TF] If a policy has been specified it should always be used. The only
difference should be whether the actual values are include in addition
to the policy. This has been clarified in 16.

=20

Question 2

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

Is validationAlg (defined in 3.2.12) is the same as explained in section
1.3 ? i.e. The validationAlg in 3.2.12 will be used by server to define
default inputs to the certificate path processing.

[TF] Yes they are the same.

=20

Question 3

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

How would server behave if in a SCVP Request user has set both
validationAlg and validationPolRef  where validationAlg points to a
default validation algorithm?

[TF] 3.2.21 states "If there are any conflicts between the policy
referenced in the request and any supplied values in the request then
the server MUST return an error."

=20

Question 4

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

If server defines an OID and bound some configuration with this OID,
e.g. TrustAnchors, RevocationInfo, ValidationParameters etc then will
client either use this OID in ValidationAlg or in validationPolRef ?

[TF] If the referenced policy also defines an algorithm then the
algorithm OID can be omitted from the request.

=20

Regards,

Faisal

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

<html xmlns:ns0=3D"urn:schemas-microsoft-com:office:smarttags">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<base href=3D"file:///F:\_BackUp-FM\Email%20Signature\">
<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:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:0pt 180.0pt 0pt 0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

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

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

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt =
0pt 4.0pt'>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Hi All,</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Question 1</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>--------------</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>I need to know that if fullPolResponse is set to&nbsp;TRUE then =
what
values are set in valPolResponse and validaionPolRef in SCVP Response. =
After
reading the draft 15 doc, in my opinion, if fullPolResponse is TRUE then
valPolResponse is set and returned and validaionPolRef is not set. If
fullPolResponse is FALSE then validationPolRef is set and valPolResponse =
is not
set. Can some one clarify.</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[TF] If a policy has been specified it should always =
be
used. The only difference should be whether the actual values are =
include in addition
to the policy. This has been clarified in 16.</span></font></i></b></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Question 2</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>------------</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Is validationAlg (defined in&nbsp;3.2.12) is the same as =
explained in
section 1.3 ? i.e. The validationAlg&nbsp;in 3.2.12 will be used by =
server to
define default inputs to the certificate path =
processing.</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[TF] Yes they are the same.</span></font></i></b></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Question 3</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>-------------</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>How would server behave if in a SCVP Request user has set both
validationAlg and validationPolRef&nbsp; where validationAlg points to a
default validation algorithm?</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[TF] 3.2.21 states &#8220;If there are any conflicts =
between
the policy referenced in the request and any supplied values in the =
request then
the server MUST return an error.&#8221;</span></font></i></b></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Question 4</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>-------------</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>If server defines an OID and bound some configuration with this =
OID,
e.g. TrustAnchors, RevocationInfo, ValidationParameters etc then will =
client
either use this OID in ValidationAlg or in validationPolRef =
?</span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[TF] If the referenced policy also defines an =
algorithm then
the algorithm OID can be omitted from the =
request.</span></font></i></b></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Regards,</span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Faisal</span></font></p>

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C49A7E.C1EB422E--

------=_NextPartTM-000-43afa6a8-c843-4129-809b-5be9df929df6--

From: "Laudon Williams" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 09:21:26 -0700
Sender: [email-masked]

The "solution" you cite (changing the name of the CA using a naming 
convention analogous to serial numbering) is NOT standards compliant 
unless we change the definition of a CA, and does not work 
automatically with software.

[LW] I don't think you've really made that case. You said it was the same
CA. I never did. I just said rollover. You jumped to a bunch of conclusions.
You keep trying to make it the same CA. I keep saying it is a different CA
(new name and key). It just operates under the same policies and practices
as the old one.

BTW, are you the same Laudon Williams who is a Microsoft program 
manager dealing with PKI? If so, then it might be more appropriate to 
use your corporate  e-mail address in these discussions, so that list 
participants are aware of potential corporate biases that may arise 
in these discussions.

[LW] I've posted under this alias when I worked for CyberSafe, RSA Security,
and Microsoft because it represents my opinion, not that of my employer. In
the one case where I've posted to this list with an "official" response, I
made it clear who I was.  But, as it stands, I no longer work for Microsoft.
I'm back in the field trying to make this stuff work for the average
company. And yes Steve, I have a bias to making things work given the
current operating environment. I don't have a bias towards a particular
vendor implementation.

-Laudon

Who is not employed by Microsoft, no matter how much Steve wants to make
this political :-)

Date: Tue, 14 Sep 2004 11:39:51 -0400
To: "Laudon Williams" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Cc: <[email-masked]>
Sender: [email-masked]

At 8:03 AM -0700 9/14/04, Laudon Williams wrote:
>Inline...
>
>-----Original Message-----
>From: Stephen Kent [mailto:[email-masked]]
>Sent: Tuesday, September 14, 2004 6:04 AM
>To: Laudon Williams
>Cc: [email-masked]
>Subject: RE: CA Rekey and CRL Validation
>
>At 3:38 PM -0700 9/13/04, Laudon Williams wrote:
>>Steve,
>>
>>Thanks you for your well thought-out post.
>>
>>I would disagree with your statement of "overkill". Right now, today, in
>>2004, if you have a deployed PKI and you want to do a CA rollover, a new
>key
>>and name is 100% compatible with Microsoft OSes, RSA and Baltimore
>>certificate toolkits, netscape/firefox browsers, all major CAs, etc. It
>just
>>works.
>
>The "it just works" model is usually the starting point for a path
>that leads to failures due to a lack of forethought.
>
>[LW] Just as the "let's make this really complex" model often leads to a
>path of, well, the state of PKI today. Yet you have not articulated a reason
>why (1) this doesn't work, or (2) it is incompatible with the standards as
>written.

We don't try to make complex standards; we try to make standards that 
accommodate a wide range of requirements, and that sometimes leads to 
complexity.

The standards define a CA in terms of its name.  So your suggestion 
to just move on to a new name when a CA key changes is NOT compatible 
with the standards.

	<SNIP>

>Names are NOT a matter of local policy in X.509.  Maybe you're
>thinking of SPKI certs. Moreover, since your comments emphasize
>"practicality" phishing is a concern primarily because it relies on
>the trust people place in names of organizations.  CAs represent
>organizations, hence the names are important, except in monopolistic
>contexts.
>
>[LW] I disagree. Not that names are important, because meaningful names are,
>but that they are as important as you make them out to be. Please explain to
>me how the following CAs are different from a trust or "software"
>perspective.
>
>CA 1:
>- Chains to trust anchor A
>- Issues under CP x.x.x.x (and CPS "foo")
>- Issues end entity certificates x, y, and z to group "bar"
>
>CA 2:
>- Chains to trust anchor A
>- Issues under CP x.x.x.x (and CPS "foo")
>- Issues end entity certificates x, y, and z to group "bar"
>
>Oh, CA 1 is named "Alice" and issued from 2000-2002. CA 2 is named "Bob" and
>issued from 2002-2004.

Then they are different CAs, since there is no syntactic way for ME 
or my software to know that they are the same. BTW, there is no 
issuance of certs to a "group" so I'm not sure what you meant in your 
example in that regard.

>I'm not seeing the difference in trust here. Or how applications get broken.
>Or, how names are particularly relevant. Roots are a bit more complex, but
>that is why I personally like the version convention. "Version" is very
>human readable. Most people can understand the convention.

I work for a company that used to be named "Bolt Beranek and Newman" 
and then was named "BBN" then "BBN Systems and Technologies" and now 
"BBN Technologies."  You might think these are all the same 
organization, and in some ways they were, but in other legal ways 
they were not. How about an organization named "BB&N?"  Sounds like 
the same organization as the series noted above, its located in 
Cambridge, MA like the ones noted above, but, its a school 
(Buckingham, Browne and Nichols).  So, when names change the safe 
assumption is that the entity being represented by the name is 
different, until we establish otherwise. How do we establish that the 
different names map to the same entity? Not via a syntactic check 
performed by our software!

>  >So really, to beat the dead horse a bit, there is a standards compliant way
>>to do roll over that is pretty much compatible with all the
>>currently-deployed software that does path processing. I'm just trying to
>>make sure that the people who actually care about making sure that PKI
>works
>>are aware of it.
>>
>>The "making stuff work today" point of view gets lost much to often in the
>  >PKIX minutia.
>
>The  "making stuff work today" point of view is fine so long as it is
>consistent with the standards. Unfortunately, all too often, that
>point of view is short sighted.
>
>[LW] Steve, really, this is absolutely nothing personal. Really.

I don't take it personally. I just view it as a bad idea.

>The parent
>thread is about to embark on a long, drawn out argument on CA rollover that
>is going to lead to a very complex, yet standards-compliant solution. The
>solution will (1) not be usable given the currently deployed software base,
>(2) lead to implementation arguments, and god forbid (3) lead to the new
>method being the *preferred* method of CA rollover, since it was discussed
>in the group.
>
>I see these as all bad outcomes because it really doesn't do much for the
>people out there today with deployed PKI. Especially given the fact that
>there is a solution that is compliant and works today.
>
>Let's not fall into the same trap NIST always does and instead choose
>something that works.

The "solution" you cite (changing the name of the CA using a naming 
convention analogous to serial numbering) is NOT standards compliant 
unless we change the definition of a CA, and does not work 
automatically with software.

BTW, are you the same Laudon Williams who is a Microsoft program 
manager dealing with PKI? If so, then it might be more appropriate to 
use your corporate  e-mail address in these discussions, so that list 
participants are aware of potential corporate biases that may arise 
in these discussions.

Steve

From: "Laudon Williams" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 08:03:34 -0700
Sender: [email-masked]

Inline...

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2004 6:04 AM
To: Laudon Williams
Cc: [email-masked]
Subject: RE: CA Rekey and CRL Validation

At 3:38 PM -0700 9/13/04, Laudon Williams wrote:
>Steve,
>
>Thanks you for your well thought-out post.
>
>I would disagree with your statement of "overkill". Right now, today, in
>2004, if you have a deployed PKI and you want to do a CA rollover, a new
key
>and name is 100% compatible with Microsoft OSes, RSA and Baltimore
>certificate toolkits, netscape/firefox browsers, all major CAs, etc. It
just
>works.

The "it just works" model is usually the starting point for a path 
that leads to failures due to a lack of forethought.

[LW] Just as the "let's make this really complex" model often leads to a
path of, well, the state of PKI today. Yet you have not articulated a reason
why (1) this doesn't work, or (2) it is incompatible with the standards as
written. 

>Now there are lots of interesting academic arguments and, of course, finger
>pointing arguments that can go on as to why other standards-compatible
>methods don't work. But really, I don't think the people trying to be
>successful with their PKI deployment really care about that.

And to the extent that these folks do not care about standards 
compliance, expect to use in their marketing literature, their 
behavior is not useful grits for a standards committee mailing list 
:-)

>On your last point, as long as the new CA issues certificates under the
same
>policy and practices, who cares what its name is? Name is really a factor
of
>local policy. If I want to name one CA "Alice" and the next version of the
>CA "Bob", who cares? Why does software need to know anything more about
them
>other than that they both issue under the same CP?

Names are NOT a matter of local policy in X.509.  Maybe you're 
thinking of SPKI certs. Moreover, since your comments emphasize 
"practicality" phishing is a concern primarily because it relies on 
the trust people place in names of organizations.  CAs represent 
organizations, hence the names are important, except in monopolistic 
contexts.

[LW] I disagree. Not that names are important, because meaningful names are,
but that they are as important as you make them out to be. Please explain to
me how the following CAs are different from a trust or "software"
perspective.

CA 1:
- Chains to trust anchor A
- Issues under CP x.x.x.x (and CPS "foo")
- Issues end entity certificates x, y, and z to group "bar"

CA 2:
- Chains to trust anchor A
- Issues under CP x.x.x.x (and CPS "foo")
- Issues end entity certificates x, y, and z to group "bar"

Oh, CA 1 is named "Alice" and issued from 2000-2002. CA 2 is named "Bob" and
issued from 2002-2004. 

I'm not seeing the difference in trust here. Or how applications get broken.
Or, how names are particularly relevant. Roots are a bit more complex, but
that is why I personally like the version convention. "Version" is very
human readable. Most people can understand the convention.

>So really, to beat the dead horse a bit, there is a standards compliant way
>to do roll over that is pretty much compatible with all the
>currently-deployed software that does path processing. I'm just trying to
>make sure that the people who actually care about making sure that PKI
works
>are aware of it.
>
>The "making stuff work today" point of view gets lost much to often in the
>PKIX minutia.

The  "making stuff work today" point of view is fine so long as it is 
consistent with the standards. Unfortunately, all too often, that 
point of view is short sighted.

[LW] Steve, really, this is absolutely nothing personal. Really. The parent
thread is about to embark on a long, drawn out argument on CA rollover that
is going to lead to a very complex, yet standards-compliant solution. The
solution will (1) not be usable given the currently deployed software base,
(2) lead to implementation arguments, and god forbid (3) lead to the new
method being the *preferred* method of CA rollover, since it was discussed
in the group.

I see these as all bad outcomes because it really doesn't do much for the
people out there today with deployed PKI. Especially given the fact that
there is a solution that is compliant and works today.

Let's not fall into the same trap NIST always does and instead choose
something that works.

Regards,

-Laudon

From: "Laudon Williams" <[email-masked]>
To: "'Jean-Marc Desperrier'" <[email-masked]>, <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 07:40:50 -0700
Sender: [email-masked]

Actually, it works the exact same with a root CA. No easier or harder.

Let me be a bit more specific.

Given a CA, at lifetime - (longestLifetimeOfIssuedCerts + pad), the CA
ceases it certificate issuance function and continues issuing only CRLs for
the rest of its life. At the same time, NewCA (new name and key) begins
issuing certificates and CRLs.

Works regardless of point in the hierarchy. There may be a difference in how
many certificates you have to issue immediately after rollover though.

Regards,

-Laudon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean-Marc Desperrier
Sent: Tuesday, September 14, 2004 4:43 AM
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Laudon Williams wrote:

>[...]. Right now, today, in
>2004, if you have a deployed PKI and you want to do a CA rollover, a new
key
>and name is 100% compatible with Microsoft OSes, RSA and Baltimore
>certificate toolkits, netscape/firefox browsers, all major CAs, etc. It
just
>works.
>
>[...] as long as the new CA issues certificates under the same
>policy and practices, who cares what its name is? Name is really a factor
of
>local policy. If I want to name one CA "Alice" and the next version of the
>CA "Bob", who cares? Why does software need to know anything more about
them
>other than that they both issue under the same CP?
>  
>
This solution becomes quite less convenient when you have a CA hierarchy 
and need to rekey a CA that itself has issued other CA certificates.
Opposite to usual practice, it probably is better then to have them all 
expire at the same time.

And it doesn't solve the problem if you ever need to rekey the root CA.

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 14:52:05 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh.

CA1 and CA1(bis) have the same name but different keys.

They are both valid in the RPs trust configuration.

Both CAs issue CRLs without IDP (which is RFC 3280 and X.509 compliant
practice).

Result: The RP can't determine what CRL and what CA belongs together
resulting in false acceptance of revoked certificates.

You can call it what you want. 
I call that a security vulnerability. 

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 14:36
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> There is no security problem in building a certification path for the
CRL
> Issuer when the same CA issues the CRL, but signs the CRL using a
> different
> key (i.e., different from the one used to sign the certificate being
> validated).
> 
> You can build a path.  You do need to do name matching as I have said
in
> several previous postings.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, September 14, 2004 7:09 AM
> To: Manger, James H; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> James,
> 
> I don't agree with your examples.
> 
> The "simple" structure that dominates deployment today is 1 CA = 1 key
> which
> has the consequences you mention.
> 
> However, the stanards define also indirect CRLs which can be used to
solve
> all your issues below EVEN if you stick with the definition 1 CA = 1
key.
> 
> The issue at hand, previously stated to Santosh is whether a CRL
without
> IDP
> can be validated with another key than the one used to validate
> certificates
> issued by the CA.
> 
> If that is allowed, then we have identified a security problem that
ought
> to
> be fixed.
> 
> /Stefan
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Manger, James H
> > Sent: den 14 september 2004 06:36
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Same name, different key = SAME CA.
> >
> > Without this, if a CA's private key is destroyed no CRLs can ever be
> > issued again for the certs it has issued so that CA's whole PKI
> crumbles
> > in an instant.
> > Without this, every CA needs to keep operating (issuing CRLs) after
it
> has
> > issued its last cert for the lifetime it was putting in certs (eg 2,
> 5, 10
> > years?).
> > Without this, every certifier wanting to periodically change keys
> (which
> > is good practice) needs to run multiple CAs.
> >
> >
> >
> >
> > P.S. There are ways to ensure name uniqueness for CAs -- either
> > concatenate issuer names from a trust anchor to the CA of interest
to
> get
> > that CA's "name", or just use the issuer field for that CA and rely
on
> > your configured trusted anchors to name CAs in a way that avoids
> ambiguity
> > (which is, in fact, the primary reason for a PKI in the first
place).
> >
> >
> >
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[email-masked]]
> > Sent: Tuesday, 14 September 2004 8:53 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> >
> > Santosh,
> >
> > I realize that the standard is not crystal clear on this issue and I
> > suggest that you either have the wrong interpretation, or at least
use
> > an interpretation that ought to be wrong.
> >
> > The core issue is whether two CAs having the same name but different
> > private issuing keys, are regarded as 1 CA or 2 separate CAs.
> >
> > I suggest (and hope) that these are NOT defined anywhere as being
the
> > same CA. This is also supported by the reality fact that there is no
> way
> > that you can ensure name uniqueness between CAs and therefore,
> key-match
> > should be a requirement.
> >
> > From this perspective standards states the following:
> >
> > X.509 Annex B states:
> >
> >    If the cRLIssuer field is absent from the CRL distribution point
> > extension of the certificate, the CRL shall be signed by the same CA
> > that signed the certificate; and
> >    If the cRLIssuer field is present in the CRL distribution point
> > extension of the certificate, the CRL shall be signed by the CRL
> Issuer
> > identified in the CRL distribution point extension of the
certificate
> > and the CRL shall contain the indirectCRL field in the issuing
> > distribution point extension.
> >
> > RFC 3280 5.2.5 states:
> >
> >    The CRL issuer MUST assert the indirectCRL boolean, if the scope
of
> >    the CRL includes certificates issued by authorities other than
the
> >    CRL issuer.
> >
> >
> > So IF different signing keys means that CA(old) and CA(new) are
> > different CAs (despite identical names), then in order to allow
> CRL(new)
> > from CA(new) to be used to validate certificates from CA(old), then
> > CRL(new) need to contain an IDP with indirectCRL asserted,
> certificates
> > from CA(old) must also contain a CDP with cRLIssuer field.
> >
> > I suggest therefore that a CRL without IDP with indirectCRL is
> required
> > to be signed with the same key that was used to sign the certificate
> > being validated.
> >
> > If that is not clear by today's standard text, then I suggest that
it
> > should.
> >
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> 
> 

Date: Tue, 14 Sep 2004 09:03:42 -0400
To: "Laudon Williams" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Cc: <[email-masked]>
Sender: [email-masked]

At 3:38 PM -0700 9/13/04, Laudon Williams wrote:
>Steve,
>
>Thanks you for your well thought-out post.
>
>I would disagree with your statement of "overkill". Right now, today, in
>2004, if you have a deployed PKI and you want to do a CA rollover, a new key
>and name is 100% compatible with Microsoft OSes, RSA and Baltimore
>certificate toolkits, netscape/firefox browsers, all major CAs, etc. It just
>works.

The "it just works" model is usually the starting point for a path 
that leads to failures due to a lack of forethought.

>Now there are lots of interesting academic arguments and, of course, finger
>pointing arguments that can go on as to why other standards-compatible
>methods don't work. But really, I don't think the people trying to be
>successful with their PKI deployment really care about that.

And to the extent that these folks do not care about standards 
compliance, expect to use in their marketing literature, their 
behavior is not useful grits for a standards committee mailing list 
:-)

>On your last point, as long as the new CA issues certificates under the same
>policy and practices, who cares what its name is? Name is really a factor of
>local policy. If I want to name one CA "Alice" and the next version of the
>CA "Bob", who cares? Why does software need to know anything more about them
>other than that they both issue under the same CP?

Names are NOT a matter of local policy in X.509.  Maybe you're 
thinking of SPKI certs. Moreover, since your comments emphasize 
"practicality" phishing is a concern primarily because it relies on 
the trust people place in names of organizations.  CAs represent 
organizations, hence the names are important, except in monopolistic 
contexts.

>So really, to beat the dead horse a bit, there is a standards compliant way
>to do roll over that is pretty much compatible with all the
>currently-deployed software that does path processing. I'm just trying to
>make sure that the people who actually care about making sure that PKI works
>are aware of it.
>
>The "making stuff work today" point of view gets lost much to often in the
>PKIX minutia.

The  "making stuff work today" point of view is fine so long as it is 
consistent with the standards. Unfortunately, all too often, that 
point of view is short sighted.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 09:08:05 -0400
Importance: Normal
Sender: [email-masked]

Jean-Marc:

You can always start a new CA anywhere in the hierarchy and issue
certificates to the existing sub CAs or create new Sub CAs.

As to the Root, you can have a new name for the Root such as My Enterprise
Root Generation X where X = 0, 1, 2 ....  This is no more of a problem than
having multiple roots with the same name in the relying party client.

I agree with Steve Kent, that it assumes CAs are re-keyed manually and not
automatically.  But, my proposal is to et around the features of MS CA and
MS CAPI and still be standard compliant and be secure.  Isn't it great that
for once we can use COTS, be secure, and be standard compliant.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean-Marc Desperrier
Sent: Tuesday, September 14, 2004 7:43 AM
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Laudon Williams wrote:

>[...]. Right now, today, in
>2004, if you have a deployed PKI and you want to do a CA rollover, a 
>new key and name is 100% compatible with Microsoft OSes, RSA and 
>Baltimore certificate toolkits, netscape/firefox browsers, all major 
>CAs, etc. It just works.
>
>[...] as long as the new CA issues certificates under the same policy 
>and practices, who cares what its name is? Name is really a factor of 
>local policy. If I want to name one CA "Alice" and the next version of 
>the CA "Bob", who cares? Why does software need to know anything more 
>about them other than that they both issue under the same CP?
>  
>
This solution becomes quite less convenient when you have a CA hierarchy 
and need to rekey a CA that itself has issued other CA certificates.
Opposite to usual practice, it probably is better then to have them all 
expire at the same time.

And it doesn't solve the problem if you ever need to rekey the root CA.

From: "Faisal Maqsood" <[email-masked]>
To: <[email-masked]>
Subject: SCVP Validation OID
Date: Tue, 14 Sep 2004 17:37:10 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_010C_01C49A81.76E47980
Content-Type: text/plain;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

H=00i=00 =00A=00l=00l=00,=00=0D=00=0A=
=00=0D=00=0A=
=00Q=00u=00e=00s=00t=00i=00o=00n=00 =001=00=0D=00=0A=
=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00=0D=00=0A=
=00I=00 =00n=00e=00e=00d=00 =00t=00o=00 =00k=00n=00o=00w=00 =
=00t=00h=00a=00t=00 =00i=00f=00 =
=00f=00u=00l=00l=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00i=00s=00 =00s=00e=00t=00 =00t=00o=00 =00T=00R=00U=00E=00 =
=00t=00h=00e=00n=00 =00w=00h=00a=00t=00 =00v=00a=00l=00u=00e=00s=00 =
=00a=00r=00e=00 =00s=00e=00t=00 =00i=00n=00 =
=00v=00a=00l=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00a=00n=00d=00 =
=00v=00a=00l=00i=00d=00a=00i=00o=00n=00P=00o=00l=00R=00e=00f=00 =
=00i=00n=00 =00S=00C=00V=00P=00 =00R=00e=00s=00p=00o=00n=00s=00e=00.=00 =
=00A=00f=00t=00e=00r=00 =00r=00e=00a=00d=00i=00n=00g=00 =00t=00h=00e=00 =
=00d=00r=00a=00f=00t=00 =001=005=00 =00d=00o=00c=00,=00 =00i=00n=00 =
=00m=00y=00 =00o=00p=00i=00n=00i=00o=00n=00,=00 =00i=00f=00 =
=00f=00u=00l=00l=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00i=00s=00 =00T=00R=00U=00E=00 =00t=00h=00e=00n=00 =
=00v=00a=00l=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00 =00i=00s=00 =
=00s=00e=00t=00 =00a=00n=00d=00 =00r=00e=00t=00u=00r=00n=00e=00d=00 =
=00a=00n=00d=00 =
=00v=00a=00l=00i=00d=00a=00i=00o=00n=00P=00o=00l=00R=00e=00f=00 =
=00i=00s=00 =00n=00o=00t=00 =00s=00e=00t=00.=00 =00I=00f=00 =
=00f=00u=00l=00l=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00i=00s=00 =00F=00A=00L=00S=00E=00 =00t=00h=00e=00n=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00P=00o=00l=00R=00e=00f=00 =
=00i=00s=00 =00s=00e=00t=00 =00a=00n=00d=00 =
=00v=00a=00l=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00 =00i=00s=00 =
=00n=00o=00t=00 =00s=00e=00t=00.=00 =00C=00a=00n=00 =00s=00o=00m=00e=00 =
=00o=00n=00e=00 =00c=00l=00a=00r=00i=00f=00y=00.=00=0D=00=0A=
=00=0D=00=0A=
=00Q=00u=00e=00s=00t=00i=00o=00n=00 =002=00=0D=00=0A=
=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00=0D=00=0A=
=00I=00s=00 =00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00A=00l=00g=00 =
=00(=00d=00e=00f=00i=00n=00e=00d=00 =00i=00n=00 =
=003=00.=002=00.=001=002=00)=00 =00i=00s=00 =00t=00h=00e=00 =
=00s=00a=00m=00e=00 =00a=00s=00 =00e=00x=00p=00l=00a=00i=00n=00e=00d=00 =
=00i=00n=00 =00s=00e=00c=00t=00i=00o=00n=00 =001=00.=003=00 =00?=00 =
=00i=00.=00e=00.=00 =00T=00h=00e=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00A=00l=00g=00 =00i=00n=00 =
=003=00.=002=00.=001=002=00 =00w=00i=00l=00l=00 =00b=00e=00 =
=00u=00s=00e=00d=00 =00b=00y=00 =00s=00e=00r=00v=00e=00r=00 =00t=00o=00 =
=00d=00e=00f=00i=00n=00e=00 =00d=00e=00f=00a=00u=00l=00t=00 =
=00i=00n=00p=00u=00t=00s=00 =00t=00o=00 =00t=00h=00e=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =00p=00a=00t=00h=00 =
=00p=00r=00o=00c=00e=00s=00s=00i=00n=00g=00.=00=0D=00=0A=
=00=0D=00=0A=
=00Q=00u=00e=00s=00t=00i=00o=00n=00 =003=00=0D=00=0A=
=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00=0D=00=0A=
=00H=00o=00w=00 =00w=00o=00u=00l=00d=00 =00s=00e=00r=00v=00e=00r=00 =
=00b=00e=00h=00a=00v=00e=00 =00i=00f=00 =00i=00n=00 =00a=00 =
=00S=00C=00V=00P=00 =00R=00e=00q=00u=00e=00s=00t=00 =00u=00s=00e=00r=00 =
=00h=00a=00s=00 =00s=00e=00t=00 =00b=00o=00t=00h=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00A=00l=00g=00 =00a=00n=00d=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00P=00o=00l=00R=00e=00f=00 =00 =
=00w=00h=00e=00r=00e=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00A=00l=00g=00 =
=00p=00o=00i=00n=00t=00s=00 =00t=00o=00 =00a=00 =
=00d=00e=00f=00a=00u=00l=00t=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00 =
=00a=00l=00g=00o=00r=00i=00t=00h=00m=00?=00=0D=00=0A=
=00=0D=00=0A=
=00Q=00u=00e=00s=00t=00i=00o=00n=00 =004=00=0D=00=0A=
=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00=0D=00=0A=
=00I=00f=00 =00s=00e=00r=00v=00e=00r=00 =00d=00e=00f=00i=00n=00e=00s=00 =
=00a=00n=00 =00O=00I=00D=00 =00a=00n=00d=00 =00b=00o=00u=00n=00d=00 =
=00s=00o=00m=00e=00 =
=00c=00o=00n=00f=00i=00g=00u=00r=00a=00t=00i=00o=00n=00 =
=00w=00i=00t=00h=00 =00t=00h=00i=00s=00 =00O=00I=00D=00,=00 =
=00e=00.=00g=00.=00 =
=00T=00r=00u=00s=00t=00A=00n=00c=00h=00o=00r=00s=00,=00 =
=00R=00e=00v=00o=00c=00a=00t=00i=00o=00n=00I=00n=00f=00o=00,=00 =
=00V=00a=00l=00i=00d=00a=00t=00i=00o=00n=00P=00a=00r=00a=00m=00e=00t=00e=00=
r=00s=00 =00e=00t=00c=00 =00t=00h=00e=00n=00 =00w=00i=00l=00l=00 =
=00c=00l=00i=00e=00n=00t=00 =00e=00i=00t=00h=00e=00r=00 =00u=00s=00e=00 =
=00t=00h=00i=00s=00 =00O=00I=00D=00 =00i=00n=00 =
=00V=00a=00l=00i=00d=00a=00t=00i=00o=00n=00A=00l=00g=00 =00o=00r=00 =
=00i=00n=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00P=00o=00l=00R=00e=00f=00 =
=00?=00=0D=00=0A=
=00=0D=00=0A=
=00R=00e=00g=00a=00r=00d=00s=00,=00=0D=00=0A=
=00F=00a=00i=00s=00a=00l=00=0D=00=0A=
=00
------=_NextPart_000_010C_01C49A81.76E47980
Content-Type: text/html;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

=FF=FE<=00!=00D=00O=00C=00T=00Y=00P=00E=00 =00H=00T=00M=00L=00 =
=00P=00U=00B=00L=00I=00C=00 =
=00"=00-=00/=00/=00W=003=00C=00/=00/=00D=00T=00D=00 =00H=00T=00M=00L=00 =
=004=00.=000=00 =
=00T=00r=00a=00n=00s=00i=00t=00i=00o=00n=00a=00l=00/=00/=00E=00N=00"=00>=00=
=0D=00=0A=
=00<=00H=00T=00M=00L=00 =00x=00m=00l=00n=00s=00:=00s=00t=001=00 =
=00=3D=00 =
=00"=00u=00r=00n=00:=00s=00c=00h=00e=00m=00a=00s=00-=00m=00i=00c=00r=00o=00=
s=00o=00f=00t=00-=00c=00o=00m=00:=00o=00f=00f=00i=00c=00e=00:=00s=00m=00a=
=00r=00t=00t=00a=00g=00s=00"=00 =00x=00m=00l=00n=00s=00:=00o=00 =
=00=3D=00 =00=0D=00=0A=
=00"=00u=00r=00n=00:=00s=00c=00h=00e=00m=00a=00s=00-=00m=00i=00c=00r=00o=00=
s=00o=00f=00t=00-=00c=00o=00m=00:=00o=00f=00f=00i=00c=00e=00:=00o=00f=00f=
=00i=00c=00e=00"=00>=00<=00H=00E=00A=00D=00>=00<=00B=00A=00S=00E=00 =
=00=0D=00=0A=
=00h=00r=00e=00f=00=3D=00"=00f=00i=00l=00e=00:=00/=00/=00F=00:=00\=00_=00=
B=00a=00c=00k=00U=00p=00-=00F=00M=00\=00E=00m=00a=00i=00l=00 =
=00S=00i=00g=00n=00a=00t=00u=00r=00e=00\=00"=00>=00=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00h=00t=00t=00p=00-=00e=00q=00u=00i=00v=00=3D=00C=00o=00n=00t=00e=00n=00=
t=00-=00T=00y=00p=00e=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00t=00e=00x=00t=00/=00h=00t=00m=00=
l=00;=00 =
=00c=00h=00a=00r=00s=00e=00t=00=3D=00u=00n=00i=00c=00o=00d=00e=00"=00>=00=
=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00M=00L=00 =
=005=00.=005=000=00.=004=001=003=004=00.=006=000=000=00"=00 =
=00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00<=00/=00=
H=00E=00A=00D=00>=00=0D=00=0A=
=00<=00B=00O=00D=00Y=00 =
=00b=00g=00C=00o=00l=00o=00r=00=3D=00#=00f=00f=00f=00f=00f=00f=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00H=00i=00 =
=00A=00l=00l=00,=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00Q=00u=00e=00s=00t=00i=00o=00n=00 =
=001=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00=
-=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00I=00 =00n=00e=00e=00d=00 =00t=00o=00 =
=00k=00n=00o=00w=00 =00t=00h=00a=00t=00 =00i=00f=00 =
=00f=00u=00l=00l=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00i=00s=00 =00s=00e=00t=00 =
=00t=00o=00&=00n=00b=00s=00p=00;=00T=00R=00U=00E=00 =00t=00h=00e=00n=00 =
=00w=00h=00a=00t=00 =00v=00a=00l=00u=00e=00s=00 =00=0D=00=0A=
=00a=00r=00e=00 =00s=00e=00t=00 =00i=00n=00 =
=00v=00a=00l=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00a=00n=00d=00 =
=00v=00a=00l=00i=00d=00a=00i=00o=00n=00P=00o=00l=00R=00e=00f=00 =
=00i=00n=00 =00S=00C=00V=00P=00 =00R=00e=00s=00p=00o=00n=00s=00e=00.=00 =
=00A=00f=00t=00e=00r=00 =00r=00e=00a=00d=00i=00n=00g=00 =00=0D=00=0A=
=00t=00h=00e=00 =00d=00r=00a=00f=00t=00 =001=005=00 =00d=00o=00c=00,=00 =
=00i=00n=00 =00m=00y=00 =00o=00p=00i=00n=00i=00o=00n=00,=00 =00i=00f=00 =
=00f=00u=00l=00l=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00i=00s=00 =00T=00R=00U=00E=00 =00t=00h=00e=00n=00 =
=00v=00a=00l=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00 =00=0D=00=0A=
=00i=00s=00 =00s=00e=00t=00 =00a=00n=00d=00 =
=00r=00e=00t=00u=00r=00n=00e=00d=00 =00a=00n=00d=00 =
=00v=00a=00l=00i=00d=00a=00i=00o=00n=00P=00o=00l=00R=00e=00f=00 =
=00i=00s=00 =00n=00o=00t=00 =00s=00e=00t=00.=00 =00I=00f=00 =
=00f=00u=00l=00l=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00 =
=00i=00s=00 =00F=00A=00L=00S=00E=00 =00=0D=00=0A=
=00t=00h=00e=00n=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00P=00o=00l=00R=00e=00f=00 =
=00i=00s=00 =00s=00e=00t=00 =00a=00n=00d=00 =
=00v=00a=00l=00P=00o=00l=00R=00e=00s=00p=00o=00n=00s=00e=00 =00i=00s=00 =
=00n=00o=00t=00 =00s=00e=00t=00.=00 =00C=00a=00n=00 =00s=00o=00m=00e=00 =
=00o=00n=00e=00 =00=0D=00=0A=
=00c=00l=00a=00r=00i=00f=00y=00.=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00Q=00u=00e=00s=00t=00i=00o=00n=00 =
=002=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00<=00=
/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00I=00s=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00A=00l=00g=00 =
=00(=00d=00e=00f=00i=00n=00e=00d=00 =
=00i=00n=00&=00n=00b=00s=00p=00;=003=00.=002=00.=001=002=00)=00 =
=00i=00s=00 =00t=00h=00e=00 =00s=00a=00m=00e=00 =00a=00s=00 =
=00e=00x=00p=00l=00a=00i=00n=00e=00d=00 =00i=00n=00 =00=0D=00=0A=
=00s=00e=00c=00t=00i=00o=00n=00 =001=00.=003=00 =00?=00 =
=00i=00.=00e=00.=00 =00T=00h=00e=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00A=00l=00g=00&=00n=00b=00s=00p=00=
;=00i=00n=00 =003=00.=002=00.=001=002=00 =00w=00i=00l=00l=00 =00b=00e=00 =
=00u=00s=00e=00d=00 =00b=00y=00 =00s=00e=00r=00v=00e=00r=00 =00t=00o=00 =
=00=0D=00=0A=
=00d=00e=00f=00i=00n=00e=00 =00d=00e=00f=00a=00u=00l=00t=00 =
=00i=00n=00p=00u=00t=00s=00 =00t=00o=00 =00t=00h=00e=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00 =00p=00a=00t=00h=00 =
=00p=00r=00o=00c=00e=00s=00s=00i=00n=00g=00.=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00Q=00u=00e=00s=00t=00i=00o=00n=00 =
=003=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00=
<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00H=00o=00w=00 =00w=00o=00u=00l=00d=00 =
=00s=00e=00r=00v=00e=00r=00 =00b=00e=00h=00a=00v=00e=00 =00i=00f=00 =
=00i=00n=00 =00a=00 =00S=00C=00V=00P=00 =00R=00e=00q=00u=00e=00s=00t=00 =
=00u=00s=00e=00r=00 =00h=00a=00s=00 =00s=00e=00t=00 =00b=00o=00t=00h=00 =
=00=0D=00=0A=
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00A=00l=00g=00 =00a=00n=00d=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00P=00o=00l=00R=00e=00f=00&=00n=00=
b=00s=00p=00;=00 =00w=00h=00e=00r=00e=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00A=00l=00g=00 =
=00p=00o=00i=00n=00t=00s=00 =00t=00o=00 =00a=00 =
=00d=00e=00f=00a=00u=00l=00t=00 =00=0D=00=0A=
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00 =
=00a=00l=00g=00o=00r=00i=00t=00h=00m=00?=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00Q=00u=00e=00s=00t=00i=00o=00n=00 =
=004=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00-=00=
<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00I=00f=00 =00s=00e=00r=00v=00e=00r=00 =
=00d=00e=00f=00i=00n=00e=00s=00 =00a=00n=00 =00O=00I=00D=00 =
=00a=00n=00d=00 =00b=00o=00u=00n=00d=00 =00s=00o=00m=00e=00 =
=00c=00o=00n=00f=00i=00g=00u=00r=00a=00t=00i=00o=00n=00 =
=00w=00i=00t=00h=00 =00t=00h=00i=00s=00 =00O=00I=00D=00,=00 =
=00e=00.=00g=00.=00 =00=0D=00=0A=
=00T=00r=00u=00s=00t=00A=00n=00c=00h=00o=00r=00s=00,=00 =
=00R=00e=00v=00o=00c=00a=00t=00i=00o=00n=00I=00n=00f=00o=00,=00 =
=00V=00a=00l=00i=00d=00a=00t=00i=00o=00n=00P=00a=00r=00a=00m=00e=00t=00e=00=
r=00s=00 =00e=00t=00c=00 =00t=00h=00e=00n=00 =00w=00i=00l=00l=00 =
=00c=00l=00i=00e=00n=00t=00 =00e=00i=00t=00h=00e=00r=00 =00=0D=00=0A=
=00u=00s=00e=00 =00t=00h=00i=00s=00 =00O=00I=00D=00 =00i=00n=00 =
=00V=00a=00l=00i=00d=00a=00t=00i=00o=00n=00A=00l=00g=00 =00o=00r=00 =
=00i=00n=00 =
=00v=00a=00l=00i=00d=00a=00t=00i=00o=00n=00P=00o=00l=00R=00e=00f=00 =
=00?=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00R=00=
e=00g=00a=00r=00d=00s=00,=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00F=00a=00i=00s=00a=00l=00<=00/=00D=00I=00V=00>=00<=00=
/=00B=00O=00D=00Y=00>=00<=00/=00H=00T=00M=00L=00>=00=0D=00=0A=
=00
------=_NextPart_000_010C_01C49A81.76E47980--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 08:36:24 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

There is no security problem in building a certification path for the CRL
Issuer when the same CA issues the CRL, but signs the CRL using a different
key (i.e., different from the one used to sign the certificate being
validated).

You can build a path.  You do need to do name matching as I have said in
several previous postings.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, September 14, 2004 7:09 AM
To: Manger, James H; [email-masked]
Subject: RE: CA Rekey and CRL Validation

James,

I don't agree with your examples.

The "simple" structure that dominates deployment today is 1 CA = 1 key which
has the consequences you mention.

However, the stanards define also indirect CRLs which can be used to solve
all your issues below EVEN if you stick with the definition 1 CA = 1 key.

The issue at hand, previously stated to Santosh is whether a CRL without IDP
can be validated with another key than the one used to validate certificates
issued by the CA.

If that is allowed, then we have identified a security problem that ought to
be fixed.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Manger, James H
> Sent: den 14 september 2004 06:36
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Same name, different key = SAME CA.
> 
> Without this, if a CA's private key is destroyed no CRLs can ever be 
> issued again for the certs it has issued so that CA's whole PKI
crumbles
> in an instant.
> Without this, every CA needs to keep operating (issuing CRLs) after it
has
> issued its last cert for the lifetime it was putting in certs (eg 2,
5, 10
> years?).
> Without this, every certifier wanting to periodically change keys
(which
> is good practice) needs to run multiple CAs.
> 
> 
> 
> 
> P.S. There are ways to ensure name uniqueness for CAs -- either 
> concatenate issuer names from a trust anchor to the CA of interest to
get
> that CA's "name", or just use the issuer field for that CA and rely on 
> your configured trusted anchors to name CAs in a way that avoids
ambiguity
> (which is, in fact, the primary reason for a PKI in the first place).
> 
> 
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Tuesday, 14 September 2004 8:53 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> Santosh,
> 
> I realize that the standard is not crystal clear on this issue and I 
> suggest that you either have the wrong interpretation, or at least use 
> an interpretation that ought to be wrong.
> 
> The core issue is whether two CAs having the same name but different 
> private issuing keys, are regarded as 1 CA or 2 separate CAs.
> 
> I suggest (and hope) that these are NOT defined anywhere as being the 
> same CA. This is also supported by the reality fact that there is no
way
> that you can ensure name uniqueness between CAs and therefore,
key-match
> should be a requirement.
> 
> From this perspective standards states the following:
> 
> X.509 Annex B states:
> 
>    If the cRLIssuer field is absent from the CRL distribution point 
> extension of the certificate, the CRL shall be signed by the same CA 
> that signed the certificate; and
>    If the cRLIssuer field is present in the CRL distribution point 
> extension of the certificate, the CRL shall be signed by the CRL
Issuer
> identified in the CRL distribution point extension of the certificate 
> and the CRL shall contain the indirectCRL field in the issuing 
> distribution point extension.
> 
> RFC 3280 5.2.5 states:
> 
>    The CRL issuer MUST assert the indirectCRL boolean, if the scope of
>    the CRL includes certificates issued by authorities other than the
>    CRL issuer.
> 
> 
> So IF different signing keys means that CA(old) and CA(new) are 
> different CAs (despite identical names), then in order to allow
CRL(new)
> from CA(new) to be used to validate certificates from CA(old), then
> CRL(new) need to contain an IDP with indirectCRL asserted,
certificates
> from CA(old) must also contain a CDP with cRLIssuer field.
> 
> I suggest therefore that a CRL without IDP with indirectCRL is
required
> to be signed with the same key that was used to sign the certificate 
> being validated.
> 
> If that is not clear by today's standard text, then I suggest that it 
> should.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 07:58:00 -0400
Importance: Normal
Sender: [email-masked]

Jean-Marc:

I read your posting as supporting my position.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean-Marc Desperrier
Sent: Tuesday, September 14, 2004 5:37 AM
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh Chokhani wrote:

>If you think applications will not understand IDP, the appropriate, 
>secure, and standard compliant way to do this is as follows:
>  
>
IDP is a critical extension. Application can be unable to understand it, 
but are very strongly broken if they ignore it ...

>Issue multiple CRLs covering all certiifcates (regardless of the key 
>used to sign them) issued by the same DN.  None of these CRLs need to 
>(neither they
>should) assert IDP.
>  
>
As the standard says that a CA is defined by it's name, isn't this 
naturally the one and only correct thing to do ?

If it *is* the same CA, then it *has* to both respect the serial number 
uniqueness and to continue to cover all certificate it issued that are 
still in their validity period ...

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 07:56:28 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

See responses in-line in [].

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2004 6:42 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

Let's not go too far in this :)

Yes, X.509 has language that implies that one CA is still one CA even if the
key change. But I haven't been able to find anywhere where it is explicitly
stated.

[The reason standard does not have the explicit statement is that X.509 is
very clear in this area and no one even thought that there is an ambiguity
in this area.]

But lets focus on the issue.. The issue at hand however is mainly the case
when you process a CRL without an IDP.

I think we can conclude from your own example that a CRL without IDP is a
security vulnerability UNLESS it MUST be validated with the same key used to
validate the certificate checked for revocation.

[There is no IDP related vulnerability in the CRL.  My example just says and
X.509 is very clear that when you do not assert IDP, the CRL covers all
certificates issued by the name asserted in the Issuer field of the CRL.]

Because otherwise if you have a name match but no key match, there is no way
to determine if you hold the appropriate CRL.

[No IDP means CRL is complete in scope.  Read X.509 and Annex B which is
normative]

My take on this is that it AT LEAST should be stated that a CRL without IDP
must be validated with the same public key used to validate the certificate
being checked for revocation.

[No IDP means CRL is complete in scope.  Read X.509 and Annex B which is
normative].

[Thus, the CA needs to make sure that when it does not assert IDP, the CRL
is full and complete. (We need not complicate this with Delta CRL since that
does not impact this thread).]

I was seeking support for this in the standard and I found so far that you
could argue that this is already supported by the standard (by defining any
CRL not issued with the certificate signing key as an indirect CRL). 

[The standard does not say that a CRL signed by a key other than certificate
signing key is an indirect CRL.]

If the conclusion is that it is NOT supported, then we have a security
defect (CRL without IDP) to deal with.

[There is no security defect in the standard from my analysis.  Standard
needs to clarify how to match the certificate certification path and the CRL
certification path]

I'm curious. Is there any implementation out there that will accept a CRL
without IDP on name matching only (no key match)?

[I think Entrust will and any toolkit that passes NIST PKITS 4.5.6.  Also,
why do not you answer the question about separate cRLSign bit and discourse
on self-issued certificates in X.509 and their role, both of which are
specifically for using different keys for certificate and CRL signing]

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 05:36
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> The standard is very clear in this area.  A CA is defined by the name. 
> There is no requirement for a CA to use the same key to sign
certificates
> and CRL.  That is why we have a separate cRLSign bit.
> 
> Take a closer look at discussion of self-issued certificates and tell
me
> that a CA is not defined by name.
> 
> Also, read Annex B of X.509, which is normative.
> 
> Feel like those Watergate days when folks kept on asking where the
smoking
> gun is and we say the room is full of smoke.  It is written all over
X.509
> and 3280 that a CA is defined by name and can use different keys to
sign
> certificates and CRLs.
> 
> I would give you this much.  If I were to write the standard today, I 
> would use what MS uses or something similar (in order to provide 
> strong and simple
> crypto binding between the certificate signer and CRL signer).  But,
to do
> that today, we have to deal with the following:
> 
> 1.  Backward compatibility issues; and
> 2.  Other vendors; and
> 3.  Change the standards
> 
> Without all those, we atheists say that the Earth Remains Round.  Feel 
> free to excommunicate us and declare the Earth flat.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Monday, September 13, 2004 6:53 PM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> Santosh,
> 
> I realize that the standard is not crystal clear on this issue and I 
> suggest that you either have the wrong interpretation, or at least use 
> an interpretation that ought to be wrong.
> 
> The core issue is whether two CAs having the same name but different 
> private issuing keys, are regarded as 1 CA or 2 separate CAs.
> 
> I suggest (and hope) that these are NOT defined anywhere as being the
same
> CA. This is also supported by the reality fact that there is no way
that
> you
> can ensure name uniqueness between CAs and therefore, key-match should
be
> a
> requirement.
> 
> >From this perspective standards states the following:
> 
> X.509 Annex B states:
> 
>    If the cRLIssuer field is absent from the CRL distribution point 
> extension of the certificate, the CRL shall be signed by the same CA
that
> signed the certificate; and
>    If the cRLIssuer field is present in the CRL distribution point 
> extension of the certificate, the CRL shall be signed by the CRL 
> Issuer
identified
> in
> the CRL distribution point extension of the certificate and the CRL
shall
> contain the indirectCRL field in the issuing distribution point
extension.
> 
> RFC 3280 5.2.5 states:
> 
>    The CRL issuer MUST assert the indirectCRL boolean, if the scope of
>    the CRL includes certificates issued by authorities other than the
>    CRL issuer.
> 
> 
> So IF different signing keys means that CA(old) and CA(new) are
different
> CAs (despite identical names), then in order to allow CRL(new) from
> CA(new)
> to be used to validate certificates from CA(old), then
> CRL(new) need to contain an IDP with indirectCRL asserted,
certificates
> from
> CA(old) must also contain a CDP with cRLIssuer field.
> 
> I suggest therefore that a CRL without IDP with indirectCRL is
required to
> be signed with the same key that was used to sign the certificate
being
> validated.
> 
> If that is not clear by today's standard text, then I suggest that it 
> should.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 13 september 2004 16:37
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Denis:
> >
> > In terms of Security Problem:
> >
> > Let us say certificates 1-100 were issued by the CA using key1 and
> CRL1
> > contains their status with no IDP.
> >
> > Let us say certificates 101-200 ere issued by the CA using key2 and
> CRL2
> > contains their status with no IDP.
> >
> > Now when a relying party validates CRL1 or CRL2, it can build a path
> to
> > the
> > CRL and think that it has a full CRL for the CA, but it does not.
> More
> > specifically, let us, it want to check the status of certificate 10.
> It
> > gets a CRL which happens to be CRL2.  It can build a path to CRL2 
> > signature key and validate it and will always get good status since 
> > CRL2 will
> never
> > contain certificate 10.
> >
> > The way to solve the problem is as follows:
> >
> > Put CRL DP = FIRST CRL in certificates 1-100
> > Put CRL DP = SECOND CRL in certificates 101-200
> >
> > Populate the IDP of CRL1 with DP = FIRST CRL
> > Populate the IDP of CRL1 with DP = SECOND CRL
> >
> > For further details on CRL processing, see Annex B of X.509, which
is
> > normative.
> >
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Monday, September 13, 2004 10:18 AM
> > To: Santosh Chokhani
> > Cc: [email-masked]
> > Subject: Re: CA Rekey and CRL Validation
> >
> >
> > Santosh,
> >
> > I have some difficulties to understand what you believe is insecure
> (since
> > the two CRLs do not cover the same set of certificates); and then
how
> IDP
> > would solve the issue. How would you use IDP (copied below ?) :
> >
> >     issuingDistributionPoint ::= SEQUENCE {
> >          distributionPoint          [0] DistributionPointName
> OPTIONAL,
> >          onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
> >          onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
> >          onlySomeReasons            [3] ReasonFlags OPTIONAL,
> >          indirectCRL                [4] BOOLEAN DEFAULT FALSE,
> >          onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
> >
> > Denis
> >
> > > Stefan,
> > >
> > > What is insecure is the following:
> > >
> > > 1 Rekey and no name changes; and
> > > 2 Issuance of different CRLs covering the different sets of 
> > > certificates under the same Issuer DN without asserting IDP.
> > >
> > > What I have proposed here are some of the ways to close that
> security
> > > hole.
> > >
> > > -----Original Message-----
> > > From: Stefan Santesson [mailto:[email-masked]]
> > > Sent: Monday, September 13, 2004 9:05 AM
> > > To: Santosh Chokhani; [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > > Santosh,
> > >
> > > This is not necessarily true.
> > > The decision to do a name change or not is more dependent on the 
> > > combination of CA software, its configuration and cryptographic 
> > > library for clients.
> > >
> > > MS-CAPI is well capable of many usage scenarios where the CA is 
> > > re-keyed under the same name. E.g. MS-CAPI is does enforce IDP,
CDP
> > > match.
> > >
> > > /Stefan
> > >
> > >
> > >>-----Original Message-----
> > >>From: [email-masked]
> > >
> > > [mailto:[email-masked]]
> > >
> > >>On Behalf Of Santosh Chokhani
> > >>Sent: den 11 september 2004 14:43
> > >>To: [email-masked]
> > >>Subject: RE: CA Rekey and CRL Validation
> > >>
> > >>
> > >>If your relying parties plan to use MS CAPI, when you re-key a CA,
> > >
> > > change
> > >
> > >>its name.
> > >>
> > >>If you plan to use other toolkits, make sure that they build the
> path
> > >
> > > to
> > >
> > >>CRL
> > >>and match DNs one for one and in sequence (of the certification
path
> > >
> > > to
> > >
> > >>the
> > >>certificate and certification path to the CRL signer) ignoring
> > >
> > > self-issued
> > >
> > >>certificates, but including the DN of the two trust anchors for
the
> > >
> > > two
> > >
> > >>paths.
> > >>
> > >>-----Original Message-----
> > >>From: [email-masked]
> > >
> > > [mailto:[email-masked]]
> > >
> > >>On
> > >>Behalf Of Luciano (Pessoal)
> > >>Sent: Friday, September 10, 2004 4:30 PM
> > >>To: [email-masked]
> > >>Subject: CA Rekey and CRL Validation
> > >>
> > >>
> > >>
> > >>Hi All,
> > >>
> > >>	I have found the following sentence in a Microsoft's paper 
> > >>(Troubleshooting Certificate Status and Revocation) and I suppose
> that
> > >
> > > it
> > >
> > >>is
> > >>about the use of cRLIssuer on CRLs and certificates.
> > >>
> > >>"... Important: The Windows operating system family can only
verify
> a
> > >
> > > CRL
> > >
> > >>that was signed by the same private key used to sign the issued 
> > >>certificate. The Windows operating system does not support CRLs
> signed
> > >>by an entity other than the CA that signed the issued certificate. 
> > >>...."
> > >>
> > >>    My doubt is: What would happen  in the case of a CA Rekey?
> > >>
> > >>    I know by the item "5.1.1.3" from RFC 3280 that a CRL can be
> > >
> > > signed by
> > >
> > >>a
> > >>different key used to sign certificates.
> > >>
> > >>    But, I'm not sure how does this topic fit in the case of CA
> Rekey
> > >>where a CRL is signed with the newer key and the certificates
being
> > >>verified
> > >
> > > was
> > >
> > >>signed with the older.
> > >>
> > >>    In the item "5.1.1.3" we have the text ".....Applications that
> > >
> > > perform
> > >
> > >>CRL checking MUST support certification path validation when
> > >
> > > certificates
> > >
> > >>and CRLs are digitally signed with the same CA private key.  These 
> > >>applications SHOULD support certification path validation when 
> > >>certificates and CRLs are digitally signed with different CA
private
> > >>keys."
> > >>
> > >>    I think Microsoft is ok considering the validation of
> certificates
> > >
> > > and
> > >
> > >>CRLS signed with different CA private keys is an OPTIONAL feature
> > >
> > > (because
> > >
> > >>of SHOULD). Once, I ask you: What about CA Rekey?
> > >>
> > >>
> > >>    Thanks in advance,
> > >>
> > >>    Luciano Coelho
> > >>
> > >>PS: I'm not concerned about this possible "limitation" on
> Microsoft's
> > >
> > > CRL
> > >
> > >>validation process. I'm interested about how a CA REKEY can
> interfere
> > >
> > > with
> > >
> > >>CRL check/validation.
> > >>
> > >
> > >
> > >
> > >
> >
> 
> 

Date: Tue, 14 Sep 2004 13:42:51 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Laudon Williams wrote:

>[...]. Right now, today, in
>2004, if you have a deployed PKI and you want to do a CA rollover, a new key
>and name is 100% compatible with Microsoft OSes, RSA and Baltimore
>certificate toolkits, netscape/firefox browsers, all major CAs, etc. It just
>works.
>
>[...] as long as the new CA issues certificates under the same
>policy and practices, who cares what its name is? Name is really a factor of
>local policy. If I want to name one CA "Alice" and the next version of the
>CA "Bob", who cares? Why does software need to know anything more about them
>other than that they both issue under the same CP?
>  
>
This solution becomes quite less convenient when you have a CA hierarchy 
and need to rekey a CA that itself has issued other CA certificates.
Opposite to usual practice, it probably is better then to have them all 
expire at the same time.

And it doesn't solve the problem if you ever need to rekey the root CA.

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 12:09:29 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Manger, James H" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

James,

I don't agree with your examples.

The "simple" structure that dominates deployment today is 1 CA = 1 key
which has the consequences you mention.

However, the stanards define also indirect CRLs which can be used to
solve all your issues below EVEN if you stick with the definition 1 CA =
1 key.

The issue at hand, previously stated to Santosh is whether a CRL without
IDP can be validated with another key than the one used to validate
certificates issued by the CA.

If that is allowed, then we have identified a security problem that
ought to be fixed.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Manger, James H
> Sent: den 14 september 2004 06:36
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Same name, different key = SAME CA.
> 
> Without this, if a CA's private key is destroyed no CRLs can ever be
> issued again for the certs it has issued so that CA's whole PKI
crumbles
> in an instant.
> Without this, every CA needs to keep operating (issuing CRLs) after it
has
> issued its last cert for the lifetime it was putting in certs (eg 2,
5, 10
> years?).
> Without this, every certifier wanting to periodically change keys
(which
> is good practice) needs to run multiple CAs.
> 
> 
> 
> 
> P.S. There are ways to ensure name uniqueness for CAs -- either
> concatenate issuer names from a trust anchor to the CA of interest to
get
> that CA's "name", or just use the issuer field for that CA and rely on
> your configured trusted anchors to name CAs in a way that avoids
ambiguity
> (which is, in fact, the primary reason for a PKI in the first place).
> 
> 
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Tuesday, 14 September 2004 8:53 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> Santosh,
> 
> I realize that the standard is not crystal clear on this issue and I
> suggest that you either have the wrong interpretation, or at least use
> an interpretation that ought to be wrong.
> 
> The core issue is whether two CAs having the same name but different
> private issuing keys, are regarded as 1 CA or 2 separate CAs.
> 
> I suggest (and hope) that these are NOT defined anywhere as being the
> same CA. This is also supported by the reality fact that there is no
way
> that you can ensure name uniqueness between CAs and therefore,
key-match
> should be a requirement.
> 
> From this perspective standards states the following:
> 
> X.509 Annex B states:
> 
>    If the cRLIssuer field is absent from the CRL distribution point
> extension of the certificate, the CRL shall be signed by the same CA
> that signed the certificate; and
>    If the cRLIssuer field is present in the CRL distribution point
> extension of the certificate, the CRL shall be signed by the CRL
Issuer
> identified in the CRL distribution point extension of the certificate
> and the CRL shall contain the indirectCRL field in the issuing
> distribution point extension.
> 
> RFC 3280 5.2.5 states:
> 
>    The CRL issuer MUST assert the indirectCRL boolean, if the scope of
>    the CRL includes certificates issued by authorities other than the
>    CRL issuer.
> 
> 
> So IF different signing keys means that CA(old) and CA(new) are
> different CAs (despite identical names), then in order to allow
CRL(new)
> from CA(new) to be used to validate certificates from CA(old), then
> CRL(new) need to contain an IDP with indirectCRL asserted,
certificates
> from CA(old) must also contain a CDP with cRLIssuer field.
> 
> I suggest therefore that a CRL without IDP with indirectCRL is
required
> to be signed with the same key that was used to sign the certificate
> being validated.
> 
> If that is not clear by today's standard text, then I suggest that it
> should.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 11:41:44 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

Let's not go too far in this :)

Yes, X.509 has language that implies that one CA is still one CA even if
the key change. But I haven't been able to find anywhere where it is
explicitly stated.

But lets focus on the issue.. The issue at hand however is mainly the
case when you process a CRL without an IDP.

I think we can conclude from your own example that a CRL without IDP is
a security vulnerability UNLESS it MUST be validated with the same key
used to validate the certificate checked for revocation.

Because otherwise if you have a name match but no key match, there is no
way to determine if you hold the appropriate CRL.

My take on this is that it AT LEAST should be stated that a CRL without
IDP must be validated with the same public key used to validate the
certificate being checked for revocation.

I was seeking support for this in the standard and I found so far that
you could argue that this is already supported by the standard (by
defining any CRL not issued with the certificate signing key as an
indirect CRL). 

If the conclusion is that it is NOT supported, then we have a security
defect (CRL without IDP) to deal with.

I'm curious. Is there any implementation out there that will accept a
CRL without IDP on name matching only (no key match)?

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 05:36
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> The standard is very clear in this area.  A CA is defined by the name.
> There is no requirement for a CA to use the same key to sign
certificates
> and CRL.  That is why we have a separate cRLSign bit.
> 
> Take a closer look at discussion of self-issued certificates and tell
me
> that a CA is not defined by name.
> 
> Also, read Annex B of X.509, which is normative.
> 
> Feel like those Watergate days when folks kept on asking where the
smoking
> gun is and we say the room is full of smoke.  It is written all over
X.509
> and 3280 that a CA is defined by name and can use different keys to
sign
> certificates and CRLs.
> 
> I would give you this much.  If I were to write the standard today, I
> would
> use what MS uses or something similar (in order to provide strong and
> simple
> crypto binding between the certificate signer and CRL signer).  But,
to do
> that today, we have to deal with the following:
> 
> 1.  Backward compatibility issues; and
> 2.  Other vendors; and
> 3.  Change the standards
> 
> Without all those, we atheists say that the Earth Remains Round.  Feel
> free
> to excommunicate us and declare the Earth flat.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Monday, September 13, 2004 6:53 PM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 
> Santosh,
> 
> I realize that the standard is not crystal clear on this issue and I
> suggest
> that you either have the wrong interpretation, or at least use an
> interpretation that ought to be wrong.
> 
> The core issue is whether two CAs having the same name but different
> private
> issuing keys, are regarded as 1 CA or 2 separate CAs.
> 
> I suggest (and hope) that these are NOT defined anywhere as being the
same
> CA. This is also supported by the reality fact that there is no way
that
> you
> can ensure name uniqueness between CAs and therefore, key-match should
be
> a
> requirement.
> 
> >From this perspective standards states the following:
> 
> X.509 Annex B states:
> 
>    If the cRLIssuer field is absent from the CRL distribution point
> extension of the certificate, the CRL shall be signed by the same CA
that
> signed the certificate; and
>    If the cRLIssuer field is present in the CRL distribution point
> extension
> of the certificate, the CRL shall be signed by the CRL Issuer
identified
> in
> the CRL distribution point extension of the certificate and the CRL
shall
> contain the indirectCRL field in the issuing distribution point
extension.
> 
> RFC 3280 5.2.5 states:
> 
>    The CRL issuer MUST assert the indirectCRL boolean, if the scope of
>    the CRL includes certificates issued by authorities other than the
>    CRL issuer.
> 
> 
> So IF different signing keys means that CA(old) and CA(new) are
different
> CAs (despite identical names), then in order to allow CRL(new) from
> CA(new)
> to be used to validate certificates from CA(old), then
> CRL(new) need to contain an IDP with indirectCRL asserted,
certificates
> from
> CA(old) must also contain a CDP with cRLIssuer field.
> 
> I suggest therefore that a CRL without IDP with indirectCRL is
required to
> be signed with the same key that was used to sign the certificate
being
> validated.
> 
> If that is not clear by today's standard text, then I suggest that it
> should.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 13 september 2004 16:37
> > To: [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Denis:
> >
> > In terms of Security Problem:
> >
> > Let us say certificates 1-100 were issued by the CA using key1 and
> CRL1
> > contains their status with no IDP.
> >
> > Let us say certificates 101-200 ere issued by the CA using key2 and
> CRL2
> > contains their status with no IDP.
> >
> > Now when a relying party validates CRL1 or CRL2, it can build a path
> to
> > the
> > CRL and think that it has a full CRL for the CA, but it does not.
> More
> > specifically, let us, it want to check the status of certificate 10.
> It
> > gets a CRL which happens to be CRL2.  It can build a path to CRL2
> > signature key and validate it and will always get good status since
> > CRL2 will
> never
> > contain certificate 10.
> >
> > The way to solve the problem is as follows:
> >
> > Put CRL DP = FIRST CRL in certificates 1-100
> > Put CRL DP = SECOND CRL in certificates 101-200
> >
> > Populate the IDP of CRL1 with DP = FIRST CRL
> > Populate the IDP of CRL1 with DP = SECOND CRL
> >
> > For further details on CRL processing, see Annex B of X.509, which
is
> > normative.
> >
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Monday, September 13, 2004 10:18 AM
> > To: Santosh Chokhani
> > Cc: [email-masked]
> > Subject: Re: CA Rekey and CRL Validation
> >
> >
> > Santosh,
> >
> > I have some difficulties to understand what you believe is insecure
> (since
> > the two CRLs do not cover the same set of certificates); and then
how
> IDP
> > would solve the issue. How would you use IDP (copied below ?) :
> >
> >     issuingDistributionPoint ::= SEQUENCE {
> >          distributionPoint          [0] DistributionPointName
> OPTIONAL,
> >          onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
> >          onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
> >          onlySomeReasons            [3] ReasonFlags OPTIONAL,
> >          indirectCRL                [4] BOOLEAN DEFAULT FALSE,
> >          onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
> >
> > Denis
> >
> > > Stefan,
> > >
> > > What is insecure is the following:
> > >
> > > 1 Rekey and no name changes; and
> > > 2 Issuance of different CRLs covering the different sets of
> > > certificates under the same Issuer DN without asserting IDP.
> > >
> > > What I have proposed here are some of the ways to close that
> security
> > > hole.
> > >
> > > -----Original Message-----
> > > From: Stefan Santesson [mailto:[email-masked]]
> > > Sent: Monday, September 13, 2004 9:05 AM
> > > To: Santosh Chokhani; [email-masked]
> > > Subject: RE: CA Rekey and CRL Validation
> > >
> > >
> > > Santosh,
> > >
> > > This is not necessarily true.
> > > The decision to do a name change or not is more dependent on the
> > > combination of CA software, its configuration and cryptographic
> > > library for clients.
> > >
> > > MS-CAPI is well capable of many usage scenarios where the CA is
> > > re-keyed under the same name. E.g. MS-CAPI is does enforce IDP,
CDP
> > > match.
> > >
> > > /Stefan
> > >
> > >
> > >>-----Original Message-----
> > >>From: [email-masked]
> > >
> > > [mailto:[email-masked]]
> > >
> > >>On Behalf Of Santosh Chokhani
> > >>Sent: den 11 september 2004 14:43
> > >>To: [email-masked]
> > >>Subject: RE: CA Rekey and CRL Validation
> > >>
> > >>
> > >>If your relying parties plan to use MS CAPI, when you re-key a CA,
> > >
> > > change
> > >
> > >>its name.
> > >>
> > >>If you plan to use other toolkits, make sure that they build the
> path
> > >
> > > to
> > >
> > >>CRL
> > >>and match DNs one for one and in sequence (of the certification
path
> > >
> > > to
> > >
> > >>the
> > >>certificate and certification path to the CRL signer) ignoring
> > >
> > > self-issued
> > >
> > >>certificates, but including the DN of the two trust anchors for
the
> > >
> > > two
> > >
> > >>paths.
> > >>
> > >>-----Original Message-----
> > >>From: [email-masked]
> > >
> > > [mailto:[email-masked]]
> > >
> > >>On
> > >>Behalf Of Luciano (Pessoal)
> > >>Sent: Friday, September 10, 2004 4:30 PM
> > >>To: [email-masked]
> > >>Subject: CA Rekey and CRL Validation
> > >>
> > >>
> > >>
> > >>Hi All,
> > >>
> > >>	I have found the following sentence in a Microsoft's paper
> > >>(Troubleshooting Certificate Status and Revocation) and I suppose
> that
> > >
> > > it
> > >
> > >>is
> > >>about the use of cRLIssuer on CRLs and certificates.
> > >>
> > >>"... Important: The Windows operating system family can only
verify
> a
> > >
> > > CRL
> > >
> > >>that was signed by the same private key used to sign the issued
> > >>certificate. The Windows operating system does not support CRLs
> signed
> > >>by an entity other than the CA that signed the issued certificate.
> > >>...."
> > >>
> > >>    My doubt is: What would happen  in the case of a CA Rekey?
> > >>
> > >>    I know by the item "5.1.1.3" from RFC 3280 that a CRL can be
> > >
> > > signed by
> > >
> > >>a
> > >>different key used to sign certificates.
> > >>
> > >>    But, I'm not sure how does this topic fit in the case of CA
> Rekey
> > >>where a CRL is signed with the newer key and the certificates
being
> > >>verified
> > >
> > > was
> > >
> > >>signed with the older.
> > >>
> > >>    In the item "5.1.1.3" we have the text ".....Applications that
> > >
> > > perform
> > >
> > >>CRL checking MUST support certification path validation when
> > >
> > > certificates
> > >
> > >>and CRLs are digitally signed with the same CA private key.  These
> > >>applications SHOULD support certification path validation when
> > >>certificates and CRLs are digitally signed with different CA
private
> > >>keys."
> > >>
> > >>    I think Microsoft is ok considering the validation of
> certificates
> > >
> > > and
> > >
> > >>CRLS signed with different CA private keys is an OPTIONAL feature
> > >
> > > (because
> > >
> > >>of SHOULD). Once, I ask you: What about CA Rekey?
> > >>
> > >>
> > >>    Thanks in advance,
> > >>
> > >>    Luciano Coelho
> > >>
> > >>PS: I'm not concerned about this possible "limitation" on
> Microsoft's
> > >
> > > CRL
> > >
> > >>validation process. I'm interested about how a CA REKEY can
> interfere
> > >
> > > with
> > >
> > >>CRL check/validation.
> > >>
> > >
> > >
> > >
> > >
> >
> 
> 

Date: Tue, 14 Sep 2004 11:36:41 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Santosh Chokhani wrote:

>If you think applications will not understand IDP, the appropriate, secure,
>and standard compliant way to do this is as follows:
>  
>
IDP is a critical extension. Application can be unable to understand it, 
but are very strongly broken if they ignore it ...

>Issue multiple CRLs covering all certiifcates (regardless of the key used to
>sign them) issued by the same DN.  None of these CRLs need to (neither they
>should) assert IDP.
>  
>
As the standard says that a CA is defined by it's name, isn't this 
naturally the one and only correct thing to do ?

If it *is* the same CA, then it *has* to both respect the serial number 
uniqueness and to continue to cover all certificate it issued that are 
still in their validity period ...

content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Tue, 14 Sep 2004 14:36:26 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Same name, different key = SAME CA.

Without this, if a CA's private key is destroyed no CRLs can ever be issued again for the certs it has issued so that CA's whole PKI crumbles in an instant.
Without this, every CA needs to keep operating (issuing CRLs) after it has issued its last cert for the lifetime it was putting in certs (eg 2, 5, 10 years?).
Without this, every certifier wanting to periodically change keys (which is good practice) needs to run multiple CAs.

P.S. There are ways to ensure name uniqueness for CAs -- either concatenate issuer names from a trust anchor to the CA of interest to get that CA's "name", or just use the issuer field for that CA and rely on your configured trusted anchors to name CAs in a way that avoids ambiguity (which is, in fact, the primary reason for a PKI in the first place).

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Tuesday, 14 September 2004 8:53 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

I realize that the standard is not crystal clear on this issue and I
suggest that you either have the wrong interpretation, or at least use
an interpretation that ought to be wrong.

The core issue is whether two CAs having the same name but different
private issuing keys, are regarded as 1 CA or 2 separate CAs.

I suggest (and hope) that these are NOT defined anywhere as being the
same CA. This is also supported by the reality fact that there is no way
that you can ensure name uniqueness between CAs and therefore, key-match
should be a requirement.

>From this perspective standards states the following:

X.509 Annex B states:

   If the cRLIssuer field is absent from the CRL distribution point
extension of the certificate, the CRL shall be signed by the same CA
that signed the certificate; and
   If the cRLIssuer field is present in the CRL distribution point
extension of the certificate, the CRL shall be signed by the CRL Issuer
identified in the CRL distribution point extension of the certificate
and the CRL shall contain the indirectCRL field in the issuing
distribution point extension.

RFC 3280 5.2.5 states:

   The CRL issuer MUST assert the indirectCRL boolean, if the scope of
   the CRL includes certificates issued by authorities other than the
   CRL issuer.  

So IF different signing keys means that CA(old) and CA(new) are
different CAs (despite identical names), then in order to allow CRL(new)
from CA(new) to be used to validate certificates from CA(old), then
CRL(new) need to contain an IDP with indirectCRL asserted, certificates
from CA(old) must also contain a CDP with cRLIssuer field.

I suggest therefore that a CRL without IDP with indirectCRL is required
to be signed with the same key that was used to sign the certificate
being validated.

If that is not clear by today's standard text, then I suggest that it
should.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 23:36:00 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

The standard is very clear in this area.  A CA is defined by the name.
There is no requirement for a CA to use the same key to sign certificates
and CRL.  That is why we have a separate cRLSign bit.

Take a closer look at discussion of self-issued certificates and tell me
that a CA is not defined by name.

Also, read Annex B of X.509, which is normative.

Feel like those Watergate days when folks kept on asking where the smoking
gun is and we say the room is full of smoke.  It is written all over X.509
and 3280 that a CA is defined by name and can use different keys to sign
certificates and CRLs.

I would give you this much.  If I were to write the standard today, I would
use what MS uses or something similar (in order to provide strong and simple
crypto binding between the certificate signer and CRL signer).  But, to do
that today, we have to deal with the following:

1.  Backward compatibility issues; and
2.  Other vendors; and
3.  Change the standards

Without all those, we atheists say that the Earth Remains Round.  Feel free
to excommunicate us and declare the Earth flat.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Monday, September 13, 2004 6:53 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

I realize that the standard is not crystal clear on this issue and I suggest
that you either have the wrong interpretation, or at least use an
interpretation that ought to be wrong.

The core issue is whether two CAs having the same name but different private
issuing keys, are regarded as 1 CA or 2 separate CAs.

I suggest (and hope) that these are NOT defined anywhere as being the same
CA. This is also supported by the reality fact that there is no way that you
can ensure name uniqueness between CAs and therefore, key-match should be a
requirement.

>From this perspective standards states the following:

X.509 Annex B states:

   If the cRLIssuer field is absent from the CRL distribution point
extension of the certificate, the CRL shall be signed by the same CA that
signed the certificate; and
   If the cRLIssuer field is present in the CRL distribution point extension
of the certificate, the CRL shall be signed by the CRL Issuer identified in
the CRL distribution point extension of the certificate and the CRL shall
contain the indirectCRL field in the issuing distribution point extension.

RFC 3280 5.2.5 states:

   The CRL issuer MUST assert the indirectCRL boolean, if the scope of
   the CRL includes certificates issued by authorities other than the
   CRL issuer.  

So IF different signing keys means that CA(old) and CA(new) are different
CAs (despite identical names), then in order to allow CRL(new) from CA(new)
to be used to validate certificates from CA(old), then
CRL(new) need to contain an IDP with indirectCRL asserted, certificates from
CA(old) must also contain a CDP with cRLIssuer field.

I suggest therefore that a CRL without IDP with indirectCRL is required to
be signed with the same key that was used to sign the certificate being
validated.

If that is not clear by today's standard text, then I suggest that it
should.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 13 september 2004 16:37
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Denis:
> 
> In terms of Security Problem:
> 
> Let us say certificates 1-100 were issued by the CA using key1 and
CRL1
> contains their status with no IDP.
> 
> Let us say certificates 101-200 ere issued by the CA using key2 and
CRL2
> contains their status with no IDP.
> 
> Now when a relying party validates CRL1 or CRL2, it can build a path
to
> the
> CRL and think that it has a full CRL for the CA, but it does not.
More
> specifically, let us, it want to check the status of certificate 10.
It
> gets a CRL which happens to be CRL2.  It can build a path to CRL2 
> signature key and validate it and will always get good status since 
> CRL2 will
never
> contain certificate 10.
> 
> The way to solve the problem is as follows:
> 
> Put CRL DP = FIRST CRL in certificates 1-100
> Put CRL DP = SECOND CRL in certificates 101-200
> 
> Populate the IDP of CRL1 with DP = FIRST CRL
> Populate the IDP of CRL1 with DP = SECOND CRL
> 
> For further details on CRL processing, see Annex B of X.509, which is 
> normative.
> 
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Monday, September 13, 2004 10:18 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> I have some difficulties to understand what you believe is insecure
(since
> the two CRLs do not cover the same set of certificates); and then how
IDP
> would solve the issue. How would you use IDP (copied below ?) :
> 
>     issuingDistributionPoint ::= SEQUENCE {
>          distributionPoint          [0] DistributionPointName
OPTIONAL,
>          onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
>          onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
>          onlySomeReasons            [3] ReasonFlags OPTIONAL,
>          indirectCRL                [4] BOOLEAN DEFAULT FALSE,
>          onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
> 
> Denis
> 
> > Stefan,
> >
> > What is insecure is the following:
> >
> > 1 Rekey and no name changes; and
> > 2 Issuance of different CRLs covering the different sets of 
> > certificates under the same Issuer DN without asserting IDP.
> >
> > What I have proposed here are some of the ways to close that
security
> > hole.
> >
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[email-masked]]
> > Sent: Monday, September 13, 2004 9:05 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Santosh,
> >
> > This is not necessarily true.
> > The decision to do a name change or not is more dependent on the 
> > combination of CA software, its configuration and cryptographic 
> > library for clients.
> >
> > MS-CAPI is well capable of many usage scenarios where the CA is 
> > re-keyed under the same name. E.g. MS-CAPI is does enforce IDP, CDP 
> > match.
> >
> > /Stefan
> >
> >
> >>-----Original Message-----
> >>From: [email-masked]
> >
> > [mailto:[email-masked]]
> >
> >>On Behalf Of Santosh Chokhani
> >>Sent: den 11 september 2004 14:43
> >>To: [email-masked]
> >>Subject: RE: CA Rekey and CRL Validation
> >>
> >>
> >>If your relying parties plan to use MS CAPI, when you re-key a CA,
> >
> > change
> >
> >>its name.
> >>
> >>If you plan to use other toolkits, make sure that they build the
path
> >
> > to
> >
> >>CRL
> >>and match DNs one for one and in sequence (of the certification path
> >
> > to
> >
> >>the
> >>certificate and certification path to the CRL signer) ignoring
> >
> > self-issued
> >
> >>certificates, but including the DN of the two trust anchors for the
> >
> > two
> >
> >>paths.
> >>
> >>-----Original Message-----
> >>From: [email-masked]
> >
> > [mailto:[email-masked]]
> >
> >>On
> >>Behalf Of Luciano (Pessoal)
> >>Sent: Friday, September 10, 2004 4:30 PM
> >>To: [email-masked]
> >>Subject: CA Rekey and CRL Validation
> >>
> >>
> >>
> >>Hi All,
> >>
> >>	I have found the following sentence in a Microsoft's paper 
> >>(Troubleshooting Certificate Status and Revocation) and I suppose
that
> >
> > it
> >
> >>is
> >>about the use of cRLIssuer on CRLs and certificates.
> >>
> >>"... Important: The Windows operating system family can only verify
a
> >
> > CRL
> >
> >>that was signed by the same private key used to sign the issued 
> >>certificate. The Windows operating system does not support CRLs
signed
> >>by an entity other than the CA that signed the issued certificate. 
> >>...."
> >>
> >>    My doubt is: What would happen  in the case of a CA Rekey?
> >>
> >>    I know by the item "5.1.1.3" from RFC 3280 that a CRL can be
> >
> > signed by
> >
> >>a
> >>different key used to sign certificates.
> >>
> >>    But, I'm not sure how does this topic fit in the case of CA
Rekey
> >>where a CRL is signed with the newer key and the certificates being 
> >>verified
> >
> > was
> >
> >>signed with the older.
> >>
> >>    In the item "5.1.1.3" we have the text ".....Applications that
> >
> > perform
> >
> >>CRL checking MUST support certification path validation when
> >
> > certificates
> >
> >>and CRLs are digitally signed with the same CA private key.  These 
> >>applications SHOULD support certification path validation when 
> >>certificates and CRLs are digitally signed with different CA private 
> >>keys."
> >>
> >>    I think Microsoft is ok considering the validation of
certificates
> >
> > and
> >
> >>CRLS signed with different CA private keys is an OPTIONAL feature
> >
> > (because
> >
> >>of SHOULD). Once, I ask you: What about CA Rekey?
> >>
> >>
> >>    Thanks in advance,
> >>
> >>    Luciano Coelho
> >>
> >>PS: I'm not concerned about this possible "limitation" on
Microsoft's
> >
> > CRL
> >
> >>validation process. I'm interested about how a CA REKEY can
interfere
> > with
> >>CRL check/validation.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 23:24:50 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00EC_01C499E8.DB56FCB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

David:

Asserting IDP does not mean it is an indirect CRL.

Also, you are reading too much in 3280 about CRL Issuer.  All it is saying
is that generally you match the CRL Issuer and Certificate Issuer, bit
when certificate has CRL Issuer field asserted in CRL DP, you match the
value with the Issuer field in the CRL.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Engberg
Sent: Monday, September 13, 2004 7:56 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh Chokhani wrote:
> My question:  from the perspective of a relying party application, how
> is "the same CA" defined for X.509?  Obviously, two CA certs with the
> same name and public keys represent the same CA, but where is the
> procedure for a client to determine whether two certs with the same
> name and different public keys are the "same CA"?  Obviously, I need
> to reject a CRL signed by a random imposter using the same subjectName
> as your CA.
>
> [A CA is defined by the name.  That is why we have a separate cRLSign
> bit in key usage.  If the same key was used to sign both the
> certificate and CRL, you will not need the cRLSign key usage bit or
> have self-issued certificates to sign CRL.  Also, Section 5.1.1.3 of
> 3280 is very clear and I quote "Applications that perform CRL
>    checking MUST support certification path validation when certificates
>    and CRLs are digitally signed with the same CA private key.  These
>    applications SHOULD support certification path validation when
>    certificates and CRLs are digitally signed with different CA private
>    keys."
>
> As to your question about how do you know the CA is not bogus, I have
> explained on the list at least on three occasions that you match the
> subject DN in certificate and CRL certification path, ignoring
> self-issued certificates, but including trust anchor]

I agree that your interpretation is the common one.  Basically, "any
uninterrupted chain of 'CA=true' certs with the same subjectName but
different keys represent the same CA."  Unfortunately, this definition
of "same CA" does not seem to be spelled out in X.509.  Just like the
phrase "verify that the CRL issuer matches the certificate issuer" from
RFC3280 does not come with a formal definition of "matches", since a
simple subjectName match would obviously be insecure alone.

I agree with Stefan that life would be much easier if a CA was
identified as a particular unique combination of name + public key.
This exactly matches the relying party's view of the world, where all
this "CA rekey" stuff feels like a painful kludge to a straightforward
idea:  entity = name + key.

> Ideally, relying parties would always reject a CRL signed with a
> different key the target certificate, unless that CRL has a IDP
> extension with indirectCRL=TRUE.  I think this is the defacto state of
> affairs with most PKI software, and it would be nice if the spec
> supported this behavior.
>
> [Most toolkits I am familiar with are faithful to the standard in this
> area.  They build and validate the path to the CRL if the CRL is
> signed using a different key]

I sent my email after previous folks indicated that both Microsoft CAPI
and Netscape/Mozilla do not correctly discover or handle indirect CRL
signers and/or IDP extensions.  By "most PKI software", I meant the
majority of cert-enabled application copies, rather than available
toolkit libraries.

------=_NextPart_000_00EC_01C499E8.DB56FCB0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00EC_01C499E8.DB56FCB0--

Date: Mon, 13 Sep 2004 19:56:03 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000609070009060102060309
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Santosh Chokhani wrote:
> My question:  from the perspective of a relying party application, how is
> "the same CA" defined for X.509?  Obviously, two CA certs with the same
> name and public keys represent the same CA, but where is the procedure for
> a client to determine whether two certs with the same name and different
> public keys are the "same CA"?  Obviously, I need to reject a CRL signed
> by a random imposter using the same subjectName as your CA.
> 
> [A CA is defined by the name.  That is why we have a separate cRLSign bit
> in key usage.  If the same key was used to sign both the certificate and
> CRL, you will not need the cRLSign key usage bit or have self-issued
> certificates to sign CRL.  Also, Section 5.1.1.3 of 3280 is very clear and
> I quote "Applications that perform CRL
>    checking MUST support certification path validation when certificates
>    and CRLs are digitally signed with the same CA private key.  These
>    applications SHOULD support certification path validation when
>    certificates and CRLs are digitally signed with different CA private
>    keys."
> 
> As to your question about how do you know the CA is not bogus, I have
> explained on the list at least on three occasions that you match the
> subject DN in certificate and CRL certification path, ignoring self-issued
> certificates, but including trust anchor]

I agree that your interpretation is the common one.  Basically, "any 
uninterrupted chain of 'CA=true' certs with the same subjectName but 
different keys represent the same CA."  Unfortunately, this definition 
of "same CA" does not seem to be spelled out in X.509.  Just like the 
phrase "verify that the CRL issuer matches the certificate issuer" from 
RFC3280 does not come with a formal definition of "matches", since a 
simple subjectName match would obviously be insecure alone.

I agree with Stefan that life would be much easier if a CA was 
identified as a particular unique combination of name + public key. 
This exactly matches the relying party's view of the world, where all 
this "CA rekey" stuff feels like a painful kludge to a straightforward 
idea:  entity = name + key.

> Ideally, relying parties would always reject a CRL signed with a different
> key the target certificate, unless that CRL has a IDP extension with
> indirectCRL=TRUE.  I think this is the defacto state of affairs with most
> PKI software, and it would be nice if the spec supported this behavior.
> 
> [Most toolkits I am familiar with are faithful to the standard in this
> area.  They build and validate the path to the CRL if the CRL is signed
> using a different key]

I sent my email after previous folks indicated that both Microsoft CAPI 
and Netscape/Mozilla do not correctly discover or handle indirect CRL 
signers and/or IDP extensions.  By "most PKI software", I meant the 
majority of cert-enabled application copies, rather than available 
toolkit libraries.

--------------ms000609070009060102060309
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000609070009060102060309--

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 23:53:22 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

I realize that the standard is not crystal clear on this issue and I
suggest that you either have the wrong interpretation, or at least use
an interpretation that ought to be wrong.

The core issue is whether two CAs having the same name but different
private issuing keys, are regarded as 1 CA or 2 separate CAs.

I suggest (and hope) that these are NOT defined anywhere as being the
same CA. This is also supported by the reality fact that there is no way
that you can ensure name uniqueness between CAs and therefore, key-match
should be a requirement.

>From this perspective standards states the following:

X.509 Annex B states:

   If the cRLIssuer field is absent from the CRL distribution point
extension of the certificate, the CRL shall be signed by the same CA
that signed the certificate; and
   If the cRLIssuer field is present in the CRL distribution point
extension of the certificate, the CRL shall be signed by the CRL Issuer
identified in the CRL distribution point extension of the certificate
and the CRL shall contain the indirectCRL field in the issuing
distribution point extension.

RFC 3280 5.2.5 states:

   The CRL issuer MUST assert the indirectCRL boolean, if the scope of
   the CRL includes certificates issued by authorities other than the
   CRL issuer.  

So IF different signing keys means that CA(old) and CA(new) are
different CAs (despite identical names), then in order to allow CRL(new)
from CA(new) to be used to validate certificates from CA(old), then
CRL(new) need to contain an IDP with indirectCRL asserted, certificates
from CA(old) must also contain a CDP with cRLIssuer field.

I suggest therefore that a CRL without IDP with indirectCRL is required
to be signed with the same key that was used to sign the certificate
being validated.

If that is not clear by today's standard text, then I suggest that it
should.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 13 september 2004 16:37
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Denis:
> 
> In terms of Security Problem:
> 
> Let us say certificates 1-100 were issued by the CA using key1 and
CRL1
> contains their status with no IDP.
> 
> Let us say certificates 101-200 ere issued by the CA using key2 and
CRL2
> contains their status with no IDP.
> 
> Now when a relying party validates CRL1 or CRL2, it can build a path
to
> the
> CRL and think that it has a full CRL for the CA, but it does not.
More
> specifically, let us, it want to check the status of certificate 10.
It
> gets a CRL which happens to be CRL2.  It can build a path to CRL2
> signature
> key and validate it and will always get good status since CRL2 will
never
> contain certificate 10.
> 
> The way to solve the problem is as follows:
> 
> Put CRL DP = FIRST CRL in certificates 1-100
> Put CRL DP = SECOND CRL in certificates 101-200
> 
> Populate the IDP of CRL1 with DP = FIRST CRL
> Populate the IDP of CRL1 with DP = SECOND CRL
> 
> For further details on CRL processing, see Annex B of X.509, which is
> normative.
> 
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Monday, September 13, 2004 10:18 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> I have some difficulties to understand what you believe is insecure
(since
> the two CRLs do not cover the same set of certificates); and then how
IDP
> would solve the issue. How would you use IDP (copied below ?) :
> 
>     issuingDistributionPoint ::= SEQUENCE {
>          distributionPoint          [0] DistributionPointName
OPTIONAL,
>          onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
>          onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
>          onlySomeReasons            [3] ReasonFlags OPTIONAL,
>          indirectCRL                [4] BOOLEAN DEFAULT FALSE,
>          onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
> 
> Denis
> 
> > Stefan,
> >
> > What is insecure is the following:
> >
> > 1 Rekey and no name changes; and
> > 2 Issuance of different CRLs covering the different sets of
> > certificates under the same Issuer DN without asserting IDP.
> >
> > What I have proposed here are some of the ways to close that
security
> > hole.
> >
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[email-masked]]
> > Sent: Monday, September 13, 2004 9:05 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Santosh,
> >
> > This is not necessarily true.
> > The decision to do a name change or not is more dependent on the
> > combination of CA software, its configuration and cryptographic
> > library for clients.
> >
> > MS-CAPI is well capable of many usage scenarios where the CA is
> > re-keyed under the same name. E.g. MS-CAPI is does enforce IDP, CDP
> > match.
> >
> > /Stefan
> >
> >
> >>-----Original Message-----
> >>From: [email-masked]
> >
> > [mailto:[email-masked]]
> >
> >>On Behalf Of Santosh Chokhani
> >>Sent: den 11 september 2004 14:43
> >>To: [email-masked]
> >>Subject: RE: CA Rekey and CRL Validation
> >>
> >>
> >>If your relying parties plan to use MS CAPI, when you re-key a CA,
> >
> > change
> >
> >>its name.
> >>
> >>If you plan to use other toolkits, make sure that they build the
path
> >
> > to
> >
> >>CRL
> >>and match DNs one for one and in sequence (of the certification path
> >
> > to
> >
> >>the
> >>certificate and certification path to the CRL signer) ignoring
> >
> > self-issued
> >
> >>certificates, but including the DN of the two trust anchors for the
> >
> > two
> >
> >>paths.
> >>
> >>-----Original Message-----
> >>From: [email-masked]
> >
> > [mailto:[email-masked]]
> >
> >>On
> >>Behalf Of Luciano (Pessoal)
> >>Sent: Friday, September 10, 2004 4:30 PM
> >>To: [email-masked]
> >>Subject: CA Rekey and CRL Validation
> >>
> >>
> >>
> >>Hi All,
> >>
> >>	I have found the following sentence in a Microsoft's paper
> >>(Troubleshooting Certificate Status and Revocation) and I suppose
that
> >
> > it
> >
> >>is
> >>about the use of cRLIssuer on CRLs and certificates.
> >>
> >>"... Important: The Windows operating system family can only verify
a
> >
> > CRL
> >
> >>that was signed by the same private key used to sign the issued
> >>certificate. The Windows operating system does not support CRLs
signed
> >>by an entity other than the CA that signed the issued certificate.
> >>...."
> >>
> >>    My doubt is: What would happen  in the case of a CA Rekey?
> >>
> >>    I know by the item "5.1.1.3" from RFC 3280 that a CRL can be
> >
> > signed by
> >
> >>a
> >>different key used to sign certificates.
> >>
> >>    But, I'm not sure how does this topic fit in the case of CA
Rekey
> >>where a CRL is signed with the newer key and the certificates being
> >>verified
> >
> > was
> >
> >>signed with the older.
> >>
> >>    In the item "5.1.1.3" we have the text ".....Applications that
> >
> > perform
> >
> >>CRL checking MUST support certification path validation when
> >
> > certificates
> >
> >>and CRLs are digitally signed with the same CA private key.  These
> >>applications SHOULD support certification path validation when
> >>certificates and CRLs are digitally signed with different CA private
> >>keys."
> >>
> >>    I think Microsoft is ok considering the validation of
certificates
> >
> > and
> >
> >>CRLS signed with different CA private keys is an OPTIONAL feature
> >
> > (because
> >
> >>of SHOULD). Once, I ask you: What about CA Rekey?
> >>
> >>
> >>    Thanks in advance,
> >>
> >>    Luciano Coelho
> >>
> >>PS: I'm not concerned about this possible "limitation" on
Microsoft's
> >
> > CRL
> >
> >>validation process. I'm interested about how a CA REKEY can
interfere
> > with
> >>CRL check/validation.

From: "Laudon Williams" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 15:38:48 -0700
Sender: [email-masked]

Steve,

Thanks you for your well thought-out post.

I would disagree with your statement of "overkill". Right now, today, in
2004, if you have a deployed PKI and you want to do a CA rollover, a new key
and name is 100% compatible with Microsoft OSes, RSA and Baltimore
certificate toolkits, netscape/firefox browsers, all major CAs, etc. It just
works.

Now there are lots of interesting academic arguments and, of course, finger
pointing arguments that can go on as to why other standards-compatible
methods don't work. But really, I don't think the people trying to be
successful with their PKI deployment really care about that.

On your last point, as long as the new CA issues certificates under the same
policy and practices, who cares what its name is? Name is really a factor of
local policy. If I want to name one CA "Alice" and the next version of the
CA "Bob", who cares? Why does software need to know anything more about them
other than that they both issue under the same CP?

So really, to beat the dead horse a bit, there is a standards compliant way
to do roll over that is pretty much compatible with all the
currently-deployed software that does path processing. I'm just trying to
make sure that the people who actually care about making sure that PKI works
are aware of it.

The "making stuff work today" point of view gets lost much to often in the
PKIX minutia.

-Laudon

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, September 13, 2004 2:02 PM
To: Laudon Williams
Cc: [email-masked]
Subject: RE: CA Rekey and CRL Validation

At 12:09 PM -0700 9/13/04, Laudon Williams wrote:
>Now that brings us back to the question of is a CA just a key, or is a CA a
>specific name-key binding? If it is a name-key binding, does the name have
>to be unique? It doesn't in end entities certificates, but maybe it should
>be in CA certificates.

A CA is identified by a name, not a key. CA keys change over time, so 
the name-key binding is not forever, but it does identify an instance 
of a CA at a point in time.

>Actually, the main reason I wanted to chime in is this:
>While there are many "standard's compliant" ways to do CA rollover, there
is
>only one, 100% compatible way to do CA rollover. Create and new CA key and
>CA name. This removes all ambiguity. I'm personally a fan of VeriSign's use
>of version at the end of the common name.

This is overkill, and unless one adopts the rather restrictive (and 
not in the spirit of what a common name should be) naming approach 
with which you seem to be enamored, it is not an approach that yields 
the sort of continuity that most CAs would want.  Also, the 
convention you cite only works when a human is in the loop to make 
the connection between the old version and the next one.  Software 
will see it as two unreleated names.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 17:47:53 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00BD_01C499B9.CAE65A30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

David Engberg:

See responses in-line in [].

-----Original Message-----
From: Dave Engberg [mailto:[email-masked]]
Sent: Monday, September 13, 2004 1:03 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh -

I have a question from your scenario.

Assume the following rekey without a name change:

1) Certs 1-100 (signed by name1 + key1) have one CRL DP URL (e.g.
http://myca/old.crl)

2) Certs 101-200 (signed by name1 + key2) have a different CRL DP URL
(e.g.
http://myca/new.crl)

3) Neither CRL DP contains the cRLIssuer extension

4) Key1 signs CRL1 for certs 1-100.  CRL1 has no IDP extension.

5) Key2 signs CRL2 for certs 101-200.  CRL2 has no IDP extension.

6) CA cross-certs exist between the old (name1 + key1) and the new (name1
+
key2)

I think you are saying that this is not secure, since a relying party
inspecting revoked cert #10 could be convinced to accept it based on CRL2,
which will never contain information about #10.

Ideally, the relying party would reject CRL2 for cert #10 because that CRL
was not signed by the "same CA" as the one that signed the cert.  The
language in both the RFC and X.509 is a little fuzzy here.

>From X.509 B.5.1.4:

   If the cRLIssuer field is absent from the CRL distribution
   point extension of the certificate, the CRL must be signed by
   the same CA that signed the certificate;

>From RFC3280 6.3.3:

   (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.  Otherwise,
   verify that the CRL issuer matches the certificate issuer.

[In all of the above cases, the only match done is issuer and not issuer
and key.  Thus, relying party does not have a way to distinguish between
CRL1 and CRL2]

My question:  from the perspective of a relying party application, how is
"the same CA" defined for X.509?  Obviously, two CA certs with the same
name and public keys represent the same CA, but where is the procedure for
a client to determine whether two certs with the same name and different
public keys are the "same CA"?  Obviously, I need to reject a CRL signed
by a random imposter using the same subjectName as your CA.

[A CA is defined by the name.  That is why we have a separate cRLSign bit
in key usage.  If the same key was used to sign both the certificate and
CRL, you will not need the cRLSign key usage bit or have self-issued
certificates to sign CRL.  Also, Section 5.1.1.3 of 3280 is very clear and
I quote "Applications that perform CRL
   checking MUST support certification path validation when certificates
   and CRLs are digitally signed with the same CA private key.  These
   applications SHOULD support certification path validation when
   certificates and CRLs are digitally signed with different CA private
   keys."

As to your question about how do you know the CA is not bogus, I have
explained on the list at least on three occasions that you match the
subject DN in certificate and CRL certification path, ignoring self-issued
certificates, but including trust anchor]

Ideally, relying parties would always reject a CRL signed with a different
key the target certificate, unless that CRL has a IDP extension with
indirectCRL=TRUE.  I think this is the defacto state of affairs with most
PKI software, and it would be nice if the spec supported this behavior.

[Most toolkits I am familiar with are faithful to the standard in this
area.  They build and validate the path to the CRL if the CRL is signed
using a different key]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Monday, September 13, 2004 10:37 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Denis:

In terms of Security Problem:

Let us say certificates 1-100 were issued by the CA using key1 and CRL1
contains their status with no IDP.

Let us say certificates 101-200 ere issued by the CA using key2 and CRL2
contains their status with no IDP.

Now when a relying party validates CRL1 or CRL2, it can build a path to
the CRL and think that it has a full CRL for the CA, but it does not.
More specifically, let us, it want to check the status of certificate 10.
It gets a CRL which happens to be CRL2.  It can build a path to CRL2
signature key and validate it and will always get good status since CRL2
will never contain certificate 10.

The way to solve the problem is as follows:

Put CRL DP = FIRST CRL in certificates 1-100 Put CRL DP = SECOND CRL in
certificates 101-200

Populate the IDP of CRL1 with DP = FIRST CRL Populate the IDP of CRL1 with
DP = SECOND CRL

For further details on CRL processing, see Annex B of X.509, which is
normative.

------=_NextPart_000_00BD_01C499B9.CAE65A30
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00BD_01C499B9.CAE65A30--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 17:13:11 -0400
Importance: Normal
Sender: [email-masked]

Laudon:

I agree that the easiest way to deal with this mess is to change the CA DN
when you decides to use a new key for whatever reason.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Laudon Williams
Sent: Monday, September 13, 2004 3:09 PM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Now that brings us back to the question of is a CA just a key, or is a CA a
specific name-key binding? If it is a name-key binding, does the name have
to be unique? It doesn't in end entities certificates, but maybe it should
be in CA certificates.

Actually, the main reason I wanted to chime in is this:
While there are many "standard's compliant" ways to do CA rollover, there is
only one, 100% compatible way to do CA rollover. Create and new CA key and
CA name. This removes all ambiguity. I'm personally a fan of VeriSign's use
of version at the end of the common name.

I'll now return you to the theoretical argument already in progress....

-Laudon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dave Engberg
Sent: Monday, September 13, 2004 10:03 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh -

I have a question from your scenario.

Assume the following rekey without a name change:

1) Certs 1-100 (signed by name1 + key1) have one CRL DP URL (e.g.
http://myca/old.crl)

2) Certs 101-200 (signed by name1 + key2) have a different CRL DP URL (e.g.
http://myca/new.crl)

3) Neither CRL DP contains the cRLIssuer extension

4) Key1 signs CRL1 for certs 1-100.  CRL1 has no IDP extension.

5) Key2 signs CRL2 for certs 101-200.  CRL2 has no IDP extension.

6) CA cross-certs exist between the old (name1 + key1) and the new (name1 +
key2)

I think you are saying that this is not secure, since a relying party
inspecting revoked cert #10 could be convinced to accept it based on CRL2,
which will never contain information about #10.

Ideally, the relying party would reject CRL2 for cert #10 because that CRL
was not signed by the "same CA" as the one that signed the cert.  The
language in both the RFC and X.509 is a little fuzzy here.

>From X.509 B.5.1.4:

   If the cRLIssuer field is absent from the CRL distribution
   point extension of the certificate, the CRL must be signed by
   the same CA that signed the certificate;

>From RFC3280 6.3.3:

   (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.  Otherwise,
   verify that the CRL issuer matches the certificate issuer.

My question:  from the perspective of a relying party application, how is
"the same CA" defined for X.509?  Obviously, two CA certs with the same name
and public keys represent the same CA, but where is the procedure for a
client to determine whether two certs with the same name and different
public keys are the "same CA"?  Obviously, I need to reject a CRL signed by
a random imposter using the same subjectName as your CA.

Ideally, relying parties would always reject a CRL signed with a different
key the target certificate, unless that CRL has a IDP extension with
indirectCRL=TRUE.  I think this is the defacto state of affairs with most
PKI software, and it would be nice if the spec supported this behavior.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Monday, September 13, 2004 10:37 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Denis:

In terms of Security Problem:

Let us say certificates 1-100 were issued by the CA using key1 and CRL1
contains their status with no IDP.

Let us say certificates 101-200 ere issued by the CA using key2 and CRL2
contains their status with no IDP.

Now when a relying party validates CRL1 or CRL2, it can build a path to the
CRL and think that it has a full CRL for the CA, but it does not.  More
specifically, let us, it want to check the status of certificate 10.  It
gets a CRL which happens to be CRL2.  It can build a path to CRL2 signature
key and validate it and will always get good status since CRL2 will never
contain certificate 10.

The way to solve the problem is as follows:

Put CRL DP = FIRST CRL in certificates 1-100 Put CRL DP = SECOND CRL in
certificates 101-200

Populate the IDP of CRL1 with DP = FIRST CRL Populate the IDP of CRL1 with
DP = SECOND CRL

For further details on CRL processing, see Annex B of X.509, which is
normative.

Date: Mon, 13 Sep 2004 17:01:37 -0400
To: "Laudon Williams" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Cc: <[email-masked]>
Sender: [email-masked]

At 12:09 PM -0700 9/13/04, Laudon Williams wrote:
>Now that brings us back to the question of is a CA just a key, or is a CA a
>specific name-key binding? If it is a name-key binding, does the name have
>to be unique? It doesn't in end entities certificates, but maybe it should
>be in CA certificates.

A CA is identified by a name, not a key. CA keys change over time, so 
the name-key binding is not forever, but it does identify an instance 
of a CA at a point in time.

>Actually, the main reason I wanted to chime in is this:
>While there are many "standard's compliant" ways to do CA rollover, there is
>only one, 100% compatible way to do CA rollover. Create and new CA key and
>CA name. This removes all ambiguity. I'm personally a fan of VeriSign's use
>of version at the end of the common name.

This is overkill, and unless one adopts the rather restrictive (and 
not in the spirit of what a common name should be) naming approach 
with which you seem to be enamored, it is not an approach that yields 
the sort of continuity that most CAs would want.  Also, the 
convention you cite only works when a human is in the loop to make 
the connection between the old version and the next one.  Software 
will see it as two unreleated names.

Steve

From: "Laudon Williams" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 12:09:06 -0700
Sender: [email-masked]

Now that brings us back to the question of is a CA just a key, or is a CA a
specific name-key binding? If it is a name-key binding, does the name have
to be unique? It doesn't in end entities certificates, but maybe it should
be in CA certificates.

Actually, the main reason I wanted to chime in is this:
While there are many "standard's compliant" ways to do CA rollover, there is
only one, 100% compatible way to do CA rollover. Create and new CA key and
CA name. This removes all ambiguity. I'm personally a fan of VeriSign's use
of version at the end of the common name.

I'll now return you to the theoretical argument already in progress....

-Laudon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dave Engberg
Sent: Monday, September 13, 2004 10:03 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh -

I have a question from your scenario.

Assume the following rekey without a name change:

1) Certs 1-100 (signed by name1 + key1) have one CRL DP URL (e.g.
http://myca/old.crl)

2) Certs 101-200 (signed by name1 + key2) have a different CRL DP URL (e.g.
http://myca/new.crl)

3) Neither CRL DP contains the cRLIssuer extension

4) Key1 signs CRL1 for certs 1-100.  CRL1 has no IDP extension.

5) Key2 signs CRL2 for certs 101-200.  CRL2 has no IDP extension.

6) CA cross-certs exist between the old (name1 + key1) and the new (name1 +
key2)

I think you are saying that this is not secure, since a relying party
inspecting revoked cert #10 could be convinced to accept it based on CRL2,
which will never contain information about #10.

Ideally, the relying party would reject CRL2 for cert #10 because that CRL
was not signed by the "same CA" as the one that signed the cert.  The
language in both the RFC and X.509 is a little fuzzy here.

>From X.509 B.5.1.4:

   If the cRLIssuer field is absent from the CRL distribution
   point extension of the certificate, the CRL must be signed by
   the same CA that signed the certificate;

>From RFC3280 6.3.3:

   (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.  Otherwise,
   verify that the CRL issuer matches the certificate issuer.

My question:  from the perspective of a relying party application, how is
"the same CA" defined for X.509?  Obviously, two CA certs with the same name
and public keys represent the same CA, but where is the procedure for a
client to determine whether two certs with the same name and different
public keys are the "same CA"?  Obviously, I need to reject a CRL signed by
a random imposter using the same subjectName as your CA.

Ideally, relying parties would always reject a CRL signed with a different
key the target certificate, unless that CRL has a IDP extension with
indirectCRL=TRUE.  I think this is the defacto state of affairs with most
PKI software, and it would be nice if the spec supported this behavior.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Monday, September 13, 2004 10:37 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Denis:

In terms of Security Problem:

Let us say certificates 1-100 were issued by the CA using key1 and CRL1
contains their status with no IDP.

Let us say certificates 101-200 ere issued by the CA using key2 and CRL2
contains their status with no IDP.

Now when a relying party validates CRL1 or CRL2, it can build a path to the
CRL and think that it has a full CRL for the CA, but it does not.  More
specifically, let us, it want to check the status of certificate 10.  It
gets a CRL which happens to be CRL2.  It can build a path to CRL2 signature
key and validate it and will always get good status since CRL2 will never
contain certificate 10.

The way to solve the problem is as follows:

Put CRL DP = FIRST CRL in certificates 1-100 Put CRL DP = SECOND CRL in
certificates 101-200

Populate the IDP of CRL1 with DP = FIRST CRL Populate the IDP of CRL1 with
DP = SECOND CRL

For further details on CRL processing, see Annex B of X.509, which is
normative.

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 13:02:47 -0400
From: "Dave Engberg" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0056_01C49991.D02FFCD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Santosh -

I have a question from your scenario.

Assume the following rekey without a name change:

1) Certs 1-100 (signed by name1 + key1) have one CRL DP URL (e.g.
http://myca/old.crl)

2) Certs 101-200 (signed by name1 + key2) have a different CRL DP URL (e.g.
http://myca/new.crl)

3) Neither CRL DP contains the cRLIssuer extension

4) Key1 signs CRL1 for certs 1-100.  CRL1 has no IDP extension.

5) Key2 signs CRL2 for certs 101-200.  CRL2 has no IDP extension.

6) CA cross-certs exist between the old (name1 + key1) and the new (name1 +
key2)

I think you are saying that this is not secure, since a relying party
inspecting revoked cert #10 could be convinced to accept it based on CRL2,
which will never contain information about #10.

Ideally, the relying party would reject CRL2 for cert #10 because that CRL
was not signed by the "same CA" as the one that signed the cert.  The
language in both the RFC and X.509 is a little fuzzy here.

>From X.509 B.5.1.4:

   If the cRLIssuer field is absent from the CRL distribution
   point extension of the certificate, the CRL must be signed by
   the same CA that signed the certificate;

>From RFC3280 6.3.3:

   (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.  Otherwise,
   verify that the CRL issuer matches the certificate issuer.

My question:  from the perspective of a relying party application, how is
"the same CA" defined for X.509?  Obviously, two CA certs with the same name
and public keys represent the same CA, but where is the procedure for a
client to determine whether two certs with the same name and different
public keys are the "same CA"?  Obviously, I need to reject a CRL signed by
a random imposter using the same subjectName as your CA.

Ideally, relying parties would always reject a CRL signed with a different
key the target certificate, unless that CRL has a IDP extension with
indirectCRL=TRUE.  I think this is the defacto state of affairs with most
PKI software, and it would be nice if the spec supported this behavior.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Monday, September 13, 2004 10:37 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Denis:

In terms of Security Problem:

Let us say certificates 1-100 were issued by the CA using key1 and CRL1
contains their status with no IDP.

Let us say certificates 101-200 ere issued by the CA using key2 and CRL2
contains their status with no IDP.

Now when a relying party validates CRL1 or CRL2, it can build a path to the
CRL and think that it has a full CRL for the CA, but it does not.  More
specifically, let us, it want to check the status of certificate 10.  It
gets a CRL which happens to be CRL2.  It can build a path to CRL2 signature
key and validate it and will always get good status since CRL2 will never
contain certificate 10.

The way to solve the problem is as follows:

Put CRL DP = FIRST CRL in certificates 1-100 Put CRL DP = SECOND CRL in
certificates 101-200

Populate the IDP of CRL1 with DP = FIRST CRL Populate the IDP of CRL1 with
DP = SECOND CRL

For further details on CRL processing, see Annex B of X.509, which is
normative.

------=_NextPart_000_0056_01C49991.D02FFCD0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0056_01C49991.D02FFCD0--

Date: Mon, 13 Sep 2004 11:24:33 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Cc: [email-masked]
Sender: [email-masked]

Peter,

As I noted earlier in my messages, I think it would be appropriate to 
include these extensions in path validation. In fact, I raised this 
issue over a year ago in discussions with Sharon and Sanrtosh. But, 
X.509 does not allow this at this time. So, PKIX was trying to 
maintain compatibility with X.509 in this regard. So your ire is more 
appropriately directed toward X.509, not PKIX.  When X.509 is 
changed, I expect we can update 3280 as well.

Steve

Reply-To: <[email-masked]>
From: "Enrique Velasco" <[email-masked]>
To: <[email-masked]>
Subject: CA root revokation
Date: Mon, 13 Sep 2004 11:30:24 -0400
Importance: Normal
Sender: [email-masked]

Hi All,

	Is there any way to revoke a root CA? (by means of CRL, OCSP or such).

	We have working on a scheme having the root CA off-line, using indirect CRL
for the Intermediate CAs.

	This seems odd to me, but, can we use an intermediate CA to sign a CRL
issued for the root CA?

	Thanks

Enrique Velasco - [email-masked]
Jefe de Proyecto - (56 2) 688-6499
www.acepta.com - Autoridad certificadora de firma electrónica para Chile

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 10:36:56 -0400
Importance: Normal
Sender: [email-masked]

Denis:

In terms of Security Problem:

Let us say certificates 1-100 were issued by the CA using key1 and CRL1
contains their status with no IDP.

Let us say certificates 101-200 ere issued by the CA using key2 and CRL2
contains their status with no IDP.

Now when a relying party validates CRL1 or CRL2, it can build a path to the
CRL and think that it has a full CRL for the CA, but it does not.  More
specifically, let us, it want to check the status of certificate 10.  It
gets a CRL which happens to be CRL2.  It can build a path to CRL2 signature
key and validate it and will always get good status since CRL2 will never
contain certificate 10.

The way to solve the problem is as follows:

Put CRL DP = FIRST CRL in certificates 1-100
Put CRL DP = SECOND CRL in certificates 101-200

Populate the IDP of CRL1 with DP = FIRST CRL 
Populate the IDP of CRL1 with DP = SECOND CRL

For further details on CRL processing, see Annex B of X.509, which is
normative.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Monday, September 13, 2004 10:18 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

I have some difficulties to understand what you believe is insecure (since 
the two CRLs do not cover the same set of certificates); and then how IDP 
would solve the issue. How would you use IDP (copied below ?) :

    issuingDistributionPoint ::= SEQUENCE {
         distributionPoint          [0] DistributionPointName OPTIONAL,
         onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
         onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
         onlySomeReasons            [3] ReasonFlags OPTIONAL,
         indirectCRL                [4] BOOLEAN DEFAULT FALSE,
         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }

Denis

> Stefan,
> 
> What is insecure is the following:
> 
> 1 Rekey and no name changes; and
> 2 Issuance of different CRLs covering the different sets of
> certificates under the same Issuer DN without asserting IDP.
> 
> What I have proposed here are some of the ways to close that security
> hole.
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Monday, September 13, 2004 9:05 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> This is not necessarily true.
> The decision to do a name change or not is more dependent on the
> combination of CA software, its configuration and cryptographic 
> library for clients.
> 
> MS-CAPI is well capable of many usage scenarios where the CA is
> re-keyed under the same name. E.g. MS-CAPI is does enforce IDP, CDP 
> match.
> 
> /Stefan
> 
> 
>>-----Original Message-----
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Santosh Chokhani
>>Sent: den 11 september 2004 14:43
>>To: [email-masked]
>>Subject: RE: CA Rekey and CRL Validation
>>
>>
>>If your relying parties plan to use MS CAPI, when you re-key a CA,
> 
> change
> 
>>its name.
>>
>>If you plan to use other toolkits, make sure that they build the path
> 
> to
> 
>>CRL
>>and match DNs one for one and in sequence (of the certification path
> 
> to
> 
>>the
>>certificate and certification path to the CRL signer) ignoring
> 
> self-issued
> 
>>certificates, but including the DN of the two trust anchors for the
> 
> two
> 
>>paths.
>>
>>-----Original Message-----
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On
>>Behalf Of Luciano (Pessoal)
>>Sent: Friday, September 10, 2004 4:30 PM
>>To: [email-masked]
>>Subject: CA Rekey and CRL Validation
>>
>>
>>
>>Hi All,
>>
>>	I have found the following sentence in a Microsoft's paper 
>>(Troubleshooting Certificate Status and Revocation) and I suppose that
> 
> it
> 
>>is
>>about the use of cRLIssuer on CRLs and certificates.
>>
>>"... Important: The Windows operating system family can only verify a
> 
> CRL
> 
>>that was signed by the same private key used to sign the issued 
>>certificate. The Windows operating system does not support CRLs signed 
>>by an entity other than the CA that signed the issued certificate. 
>>...."
>>
>>    My doubt is: What would happen  in the case of a CA Rekey?
>>
>>    I know by the item "5.1.1.3" from RFC 3280 that a CRL can be
> 
> signed by
> 
>>a
>>different key used to sign certificates.
>>
>>    But, I'm not sure how does this topic fit in the case of CA Rekey 
>>where a CRL is signed with the newer key and the certificates being 
>>verified
> 
> was
> 
>>signed with the older.
>>
>>    In the item "5.1.1.3" we have the text ".....Applications that
> 
> perform
> 
>>CRL checking MUST support certification path validation when
> 
> certificates
> 
>>and CRLs are digitally signed with the same CA private key.  These 
>>applications SHOULD support certification path validation when 
>>certificates and CRLs are digitally signed with different CA private 
>>keys."
>>
>>    I think Microsoft is ok considering the validation of certificates
> 
> and
> 
>>CRLS signed with different CA private keys is an OPTIONAL feature
> 
> (because
> 
>>of SHOULD). Once, I ask you: What about CA Rekey?
>>
>>
>>    Thanks in advance,
>>
>>    Luciano Coelho
>>
>>PS: I'm not concerned about this possible "limitation" on Microsoft's
> 
> CRL
> 
>>validation process. I'm interested about how a CA REKEY can interfere
> 
> with
> 
>>CRL check/validation.
>>
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 10:22:11 -0400
Importance: Normal
Sender: [email-masked]

David Cross:

If you think applications will not understand IDP, the appropriate, secure,
and standard compliant way to do this is as follows:

Issue multiple CRLs covering all certiifcates (regardless of the key used to
sign them) issued by the same DN.  None of these CRLs need to (neither they
should) assert IDP.

Optionally, if you want to reduce CRL size, each set of certificates and
CRLs can have the appropriate CRL DP and IDP respectively.

-----Original Message-----
From: David Cross [mailto:[email-masked]] 
Sent: Monday, September 13, 2004 9:57 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh:

I agree that the standard is not adequate to address all scenarios and that
in many cases IDP would be useful and a secure solution to ensure the CRL
scope is complete.  Unfortunately, IDP is still not understood by a large
percentage of the deployed base and therefore not viable yet as an
ubiquitous practical solution.

Regards,

David B. Cross 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Monday, September 13, 2004 3:26 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

David Cross:

In order to require the relying parties to match the keys also, will require
a change to the standard and will require all vendors and implementers to
remove a feature namely a CA key is not longer available, you can re-key and
continue to operate.

The secure hole in signing two CRLs for the same Issuer DN without asserting
(and hence qualifying) the CRL scope using IDP can lead the standard
compliant, secure toolkits to assume that the CRL is a full and complete CRL
for the CA.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Cross
Sent: Sunday, September 12, 2004 11:06 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh:

I completely disagree and I know you and I have disagreed on this in the
past. If a CA has two signing certs with different keys that are each used
to respectfully sign a CRL, it would be considered insecure for a relying
party to match on name alone without making a cryptographic key match as
well.  Client software that matches on name alone with no key validation is
INSECURE, standards compliant or not. I do, however, agree that having
unique CRL DP is very desireable to avoid ambiguity in CRL discovery by
relying parties.

Regards,
 
David B. Cross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Sunday, September 12, 2004 5:34 PM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

And that is INSECURE unless both CRLs cover all the certificates issued by
the CA or the certificates and CRLs are properly qualified with CRL DP and
IDP respectively.

Date: Mon, 13 Sep 2004 16:17:38 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

Santosh,

I have some difficulties to understand what you believe is insecure (since 
the two CRLs do not cover the same set of certificates); and then how IDP 
would solve the issue. How would you use IDP (copied below ?) :

    issuingDistributionPoint ::= SEQUENCE {
         distributionPoint          [0] DistributionPointName OPTIONAL,
         onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
         onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
         onlySomeReasons            [3] ReasonFlags OPTIONAL,
         indirectCRL                [4] BOOLEAN DEFAULT FALSE,
         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }

Denis

> Stefan,
> 
> What is insecure is the following:
> 
> 1 Rekey and no name changes; and
> 2 Issuance of different CRLs covering the different sets of certificates
> under the same Issuer DN without asserting IDP.
> 
> What I have proposed here are some of the ways to close that security hole. 
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Monday, September 13, 2004 9:05 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> This is not necessarily true.
> The decision to do a name change or not is more dependent on the combination
> of CA software, its configuration and cryptographic library for clients.
> 
> MS-CAPI is well capable of many usage scenarios where the CA is re-keyed
> under the same name. E.g. MS-CAPI is does enforce IDP, CDP match.
> 
> /Stefan
> 
> 
>>-----Original Message-----
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Santosh Chokhani
>>Sent: den 11 september 2004 14:43
>>To: [email-masked]
>>Subject: RE: CA Rekey and CRL Validation
>>
>>
>>If your relying parties plan to use MS CAPI, when you re-key a CA,
> 
> change
> 
>>its name.
>>
>>If you plan to use other toolkits, make sure that they build the path
> 
> to
> 
>>CRL
>>and match DNs one for one and in sequence (of the certification path
> 
> to
> 
>>the
>>certificate and certification path to the CRL signer) ignoring
> 
> self-issued
> 
>>certificates, but including the DN of the two trust anchors for the
> 
> two
> 
>>paths.
>>
>>-----Original Message-----
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On
>>Behalf Of Luciano (Pessoal)
>>Sent: Friday, September 10, 2004 4:30 PM
>>To: [email-masked]
>>Subject: CA Rekey and CRL Validation
>>
>>
>>
>>Hi All,
>>
>>	I have found the following sentence in a Microsoft's paper 
>>(Troubleshooting Certificate Status and Revocation) and I suppose that
> 
> it
> 
>>is
>>about the use of cRLIssuer on CRLs and certificates.
>>
>>"... Important: The Windows operating system family can only verify a
> 
> CRL
> 
>>that was signed by the same private key used to sign the issued 
>>certificate. The Windows operating system does not support CRLs signed 
>>by an entity other
>>than the CA that signed the issued certificate. ...."
>>
>>    My doubt is: What would happen  in the case of a CA Rekey?
>>
>>    I know by the item "5.1.1.3" from RFC 3280 that a CRL can be
> 
> signed by
> 
>>a
>>different key used to sign certificates.
>>
>>    But, I'm not sure how does this topic fit in the case of CA Rekey 
>>where a CRL is signed with the newer key and the certificates being 
>>verified
> 
> was
> 
>>signed with the older.
>>
>>    In the item "5.1.1.3" we have the text ".....Applications that
> 
> perform
> 
>>CRL checking MUST support certification path validation when
> 
> certificates
> 
>>and CRLs are digitally signed with the same CA private key.  These 
>>applications SHOULD support certification path validation when 
>>certificates and CRLs are digitally signed with different CA private 
>>keys."
>>
>>    I think Microsoft is ok considering the validation of certificates
> 
> and
> 
>>CRLS signed with different CA private keys is an OPTIONAL feature
> 
> (because
> 
>>of SHOULD). Once, I ask you: What about CA Rekey?
>>
>>
>>    Thanks in advance,
>>
>>    Luciano Coelho
>>
>>PS: I'm not concerned about this possible "limitation" on Microsoft's
> 
> CRL
> 
>>validation process. I'm interested about how a CA REKEY can interfere
> 
> with
> 
>>CRL check/validation.
>>
> 
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 06:56:48 -0700
From: "David Cross" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh:

I agree that the standard is not adequate to address all scenarios and
that in many cases IDP would be useful and a secure solution to ensure
the CRL scope is complete.  Unfortunately, IDP is still not understood
by a large percentage of the deployed base and therefore not viable yet
as an ubiquitous practical solution.

Regards,

David B. Cross 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Monday, September 13, 2004 3:26 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

David Cross:

In order to require the relying parties to match the keys also, will
require a change to the standard and will require all vendors and
implementers to remove a feature namely a CA key is not longer
available, you can re-key and continue to operate.

The secure hole in signing two CRLs for the same Issuer DN without
asserting (and hence qualifying) the CRL scope using IDP can lead the
standard compliant, secure toolkits to assume that the CRL is a full and
complete CRL for the CA.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Cross
Sent: Sunday, September 12, 2004 11:06 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh:

I completely disagree and I know you and I have disagreed on this in the
past. If a CA has two signing certs with different keys that are each
used to respectfully sign a CRL, it would be considered insecure for a
relying party to match on name alone without making a cryptographic key
match as well.  Client software that matches on name alone with no key
validation is INSECURE, standards compliant or not. I do, however, agree
that having unique CRL DP is very desireable to avoid ambiguity in CRL
discovery by relying parties.

Regards,
 
David B. Cross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Sunday, September 12, 2004 5:34 PM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

And that is INSECURE unless both CRLs cover all the certificates issued
by the CA or the certificates and CRLs are properly qualified with CRL
DP and IDP respectively.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 09:33:40 -0400
Importance: Normal
Sender: [email-masked]

Stefan,

What is insecure is the following:

1 Rekey and no name changes; and
2 Issuance of different CRLs covering the different sets of certificates
under the same Issuer DN without asserting IDP.

What I have proposed here are some of the ways to close that security hole. 

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Monday, September 13, 2004 9:05 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

This is not necessarily true.
The decision to do a name change or not is more dependent on the combination
of CA software, its configuration and cryptographic library for clients.

MS-CAPI is well capable of many usage scenarios where the CA is re-keyed
under the same name. E.g. MS-CAPI is does enforce IDP, CDP match.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 11 september 2004 14:43
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> If your relying parties plan to use MS CAPI, when you re-key a CA,
change
> its name.
> 
> If you plan to use other toolkits, make sure that they build the path
to
> CRL
> and match DNs one for one and in sequence (of the certification path
to
> the
> certificate and certification path to the CRL signer) ignoring
self-issued
> certificates, but including the DN of the two trust anchors for the
two
> paths.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Luciano (Pessoal)
> Sent: Friday, September 10, 2004 4:30 PM
> To: [email-masked]
> Subject: CA Rekey and CRL Validation
> 
> 
> 
> Hi All,
> 
> 	I have found the following sentence in a Microsoft's paper 
> (Troubleshooting Certificate Status and Revocation) and I suppose that
it
> is
> about the use of cRLIssuer on CRLs and certificates.
> 
> "... Important: The Windows operating system family can only verify a
CRL
> that was signed by the same private key used to sign the issued 
> certificate. The Windows operating system does not support CRLs signed 
> by an entity other
> than the CA that signed the issued certificate. ...."
> 
>     My doubt is: What would happen  in the case of a CA Rekey?
> 
>     I know by the item "5.1.1.3" from RFC 3280 that a CRL can be
signed by
> a
> different key used to sign certificates.
> 
>     But, I'm not sure how does this topic fit in the case of CA Rekey 
> where a CRL is signed with the newer key and the certificates being 
> verified
was
> signed with the older.
> 
>     In the item "5.1.1.3" we have the text ".....Applications that
perform
> CRL checking MUST support certification path validation when
certificates
> and CRLs are digitally signed with the same CA private key.  These 
> applications SHOULD support certification path validation when 
> certificates and CRLs are digitally signed with different CA private 
> keys."
> 
>     I think Microsoft is ok considering the validation of certificates
and
> CRLS signed with different CA private keys is an OPTIONAL feature
(because
> of SHOULD). Once, I ask you: What about CA Rekey?
> 
> 
>     Thanks in advance,
> 
>     Luciano Coelho
> 
> PS: I'm not concerned about this possible "limitation" on Microsoft's
CRL
> validation process. I'm interested about how a CA REKEY can interfere
with
> CRL check/validation.

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 14:05:09 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

This is not necessarily true.
The decision to do a name change or not is more dependent on the
combination of CA software, its configuration and cryptographic library
for clients.

MS-CAPI is well capable of many usage scenarios where the CA is re-keyed
under the same name. E.g. MS-CAPI is does enforce IDP, CDP match.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 11 september 2004 14:43
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> If your relying parties plan to use MS CAPI, when you re-key a CA,
change
> its name.
> 
> If you plan to use other toolkits, make sure that they build the path
to
> CRL
> and match DNs one for one and in sequence (of the certification path
to
> the
> certificate and certification path to the CRL signer) ignoring
self-issued
> certificates, but including the DN of the two trust anchors for the
two
> paths.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Luciano (Pessoal)
> Sent: Friday, September 10, 2004 4:30 PM
> To: [email-masked]
> Subject: CA Rekey and CRL Validation
> 
> 
> 
> Hi All,
> 
> 	I have found the following sentence in a Microsoft's paper
> (Troubleshooting Certificate Status and Revocation) and I suppose that
it
> is
> about the use of cRLIssuer on CRLs and certificates.
> 
> "... Important: The Windows operating system family can only verify a
CRL
> that was signed by the same private key used to sign the issued
> certificate.
> The Windows operating system does not support CRLs signed by an entity
> other
> than the CA that signed the issued certificate. ...."
> 
>     My doubt is: What would happen  in the case of a CA Rekey?
> 
>     I know by the item "5.1.1.3" from RFC 3280 that a CRL can be
signed by
> a
> different key used to sign certificates.
> 
>     But, I'm not sure how does this topic fit in the case of CA Rekey
> where
> a CRL is signed with the newer key and the certificates being verified
was
> signed with the older.
> 
>     In the item "5.1.1.3" we have the text ".....Applications that
perform
> CRL checking MUST support certification path validation when
certificates
> and CRLs are digitally signed with the same CA private key.  These
> applications SHOULD support certification path validation when
> certificates
> and CRLs are digitally signed with different CA private keys."
> 
>     I think Microsoft is ok considering the validation of certificates
and
> CRLS signed with different CA private keys is an OPTIONAL feature
(because
> of SHOULD). Once, I ask you: What about CA Rekey?
> 
> 
>     Thanks in advance,
> 
>     Luciano Coelho
> 
> PS: I'm not concerned about this possible "limitation" on Microsoft's
CRL
> validation process. I'm interested about how a CA REKEY can interfere
with
> CRL check/validation.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Mon, 13 Sep 2004 06:25:33 -0400
Importance: Normal
Sender: [email-masked]

David Cross:

In order to require the relying parties to match the keys also, will require
a change to the standard and will require all vendors and implementers to
remove a feature namely a CA key is not longer available, you can re-key and
continue to operate.

The secure hole in signing two CRLs for the same Issuer DN without asserting
(and hence qualifying) the CRL scope using IDP can lead the standard
compliant, secure toolkits to assume that the CRL is a full and complete CRL
for the CA.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Cross
Sent: Sunday, September 12, 2004 11:06 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh:

I completely disagree and I know you and I have disagreed on this in the
past. If a CA has two signing certs with different keys that are each used
to respectfully sign a CRL, it would be considered insecure for a relying
party to match on name alone without making a cryptographic key match as
well.  Client software that matches on name alone with no key validation is
INSECURE, standards compliant or not. I do, however, agree that having
unique CRL DP is very desireable to avoid ambiguity in CRL discovery by
relying parties.

Regards,
 
David B. Cross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Sunday, September 12, 2004 5:34 PM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

And that is INSECURE unless both CRLs cover all the certificates issued by
the CA or the certificates and CRLs are properly qualified with CRL DP and
IDP respectively.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Joel S. Kazin
Sent: Sunday, September 12, 2004 6:54 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Provided you have nested your certificate lifetimes properly, the
last/longest lived certificate issued by the CA using the old signing key
will reach its notAfter date before the signers key expires, you can have
more than one CRLs being concurrently issued by the same CA. Specifically,
when re-keying, a Windows 2003 CAs that is not the root CA it will continue
to issue CRLs and delta CRLs for the old key which has stopped signing
certificates.  The new private key will sign certificates, CRLs, and delta
CRLs.  Yes, the signers DN does not change only the signers certificate and
keys. We have one client who has been pushing out two CRLs and two delta
CRLs for over 7 months, alI signed by the same CA but with two different
keys. They have at least 30,000 certificates outstanding.  By the way the
Microsoft 2003 CA will not issue a certificate where the signers notAfter
date is less than that of that of the certificate it signs. In other words
if your CA's signing certificate expires in 6 months but you as for an
end-entity certificate expiring in two years you get an end entity
certificate that expires in 6 months.

Content-class: urn:content-classes:message
Subject: RE: CA Rekey and CRL Validation
Date: Sun, 12 Sep 2004 20:06:04 -0700
From: "David Cross" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh:

I completely disagree and I know you and I have disagreed on this in the
past. If a CA has two signing certs with different keys that are each
used to respectfully sign a CRL, it would be considered insecure for a
relying party to match on name alone without making a cryptographic key
match as well.  Client software that matches on name alone with no key
validation is INSECURE, standards compliant or not. I do, however, agree
that having unique CRL DP is very desireable to avoid ambiguity in CRL
discovery by relying parties.

Regards,
 
David B. Cross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Sunday, September 12, 2004 5:34 PM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

And that is INSECURE unless both CRLs cover all the certificates issued
by the CA or the certificates and CRLs are properly qualified with CRL
DP and IDP respectively.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Joel S. Kazin
Sent: Sunday, September 12, 2004 6:54 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Provided you have nested your certificate lifetimes properly, the
last/longest lived certificate issued by the CA using the old signing
key will reach its notAfter date before the signers key expires, you can
have more than one CRLs being concurrently issued by the same CA.
Specifically, when re-keying, a Windows 2003 CAs that is not the root CA
it will continue to issue CRLs and delta CRLs for the old key which has
stopped signing certificates.  The new private key will sign
certificates, CRLs, and delta CRLs.  Yes, the signers DN does not change
only the signers certificate and keys. We have one client who has been
pushing out two CRLs and two delta CRLs for over 7 months, alI signed by
the same CA but with two different keys. They have at least 30,000
certificates outstanding.  By the way the Microsoft 2003 CA will not
issue a certificate where the signers notAfter date is less than that of
that of the certificate it signs. In other words if your CA's signing
certificate expires in 6 months but you as for an end-entity certificate
expiring in two years you get an end entity certificate that expires in
6 months.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Sun, 12 Sep 2004 20:34:05 -0400
Importance: Normal
Sender: [email-masked]

And that is INSECURE unless both CRLs cover all the certificates issued by
the CA or the certificates and CRLs are properly qualified with CRL DP and
IDP respectively.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joel S. Kazin
Sent: Sunday, September 12, 2004 6:54 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Provided you have nested your certificate lifetimes properly, the 
last/longest lived certificate issued by the CA using the old signing key 
will reach its notAfter date before the signers key expires, you can have 
more than one CRLs being concurrently issued by the same CA.  Specifically, 
when re-keying, a Windows 2003 CAs that is not the root CA it will continue 
to issue CRLs and delta CRLs for the old key which has stopped signing 
certificates.  The new private key will sign certificates, CRLs, and delta 
CRLs.  Yes, the signers DN does not change only the signers certificate and 
keys. We have one client who has been pushing out two CRLs and two delta 
CRLs for over 7 months, alI signed by the same CA but with two different 
keys. They have at least 30,000 certificates outstanding.  By the way the 
Microsoft 2003 CA will not issue a certificate where the signers notAfter 
date is less than that of that of the certificate it signs. In other words 
if your CA's signing certificate expires in 6 months but you as for an 
end-entity certificate expiring in two years you get an end entity 
certificate that expires in 6 months.

At 07:54 AM 9/12/2004 -0400, Santosh Chokhani wrote:

>Julien:
>
>I have not said that you violate any standard if you do not use the 
>same key to sign the certificate and CRL.  It is MS CAPI that will not 
>verify the path.
>
>Now, if you use different keys, you lose crypto binding.  Neither X.509 
>nor 3280 deal with how to close the security gap created by the lack of 
>crypto binding.  On two different occasions, I have carried out this 
>discussion on the PKIX.  The authors of 3280 seem to agree with my 
>proposed solution of DN matching in the two paths.
>
>I have also drafted the text for X.509 (as US comment) to fix the 
>problem.
>
>Rest of your posting about SKID and AKID do not seem to be related to 
>matter at hand and are likely to be in error in terms of their intent 
>and role in certification and CRL path validation.
>
>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Julien Pierre
>Sent: Saturday, September 11, 2004 10:29 PM
>To: Santosh Chokhani
>Cc: [email-masked]
>Subject: Re: CA Rekey and CRL Validation
>
>
>Santosh,
>
>Santosh Chokhani wrote:
>
> >David Engberg:
> >
> >I do not know if you meant it or not, but the CA name must change, 
> >else the two sets of certificates and two CRLs must be issued using 
> >appropriate CRL DP and IDP respectively.  Otherwise, you will break 
> >the security and be not compliant with the standards.
> >
> >
>What part of the standards would you exactly violate by using different 
>keys for certs and CRLs ? I haven't seen anything that says this is 
>disallowed.
>
>It seems to me RFC3280 allows SubjectKeyId / AuthorityKeyID to be used 
>with both certs and CRLs. Therefore the cert issuer does not have to be 
>the CRL issuer. The issuer cert of the CRL can be a cert with the same 
>subject as the issuer cert for the end entity certs, but with a 
>different private key and key usage . The NIST test suite checks that 
>this is supported by the toolkit. Currently, Mozilla's NSS doesn't 
>support this - the key is assumed to be the same -, but it is clearly a 
>bug, which has been opened for a while and will eventually be fixed. If 
>MS CAPI doesn't support this, then it is also broken in similar 
>fashion.

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com

Date: Sun, 12 Sep 2004 18:54:02 -0400
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: "Joel S. Kazin" <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Sender: [email-masked]

Provided you have nested your certificate lifetimes properly, the 
last/longest lived certificate issued by the CA using the old signing key 
will reach its notAfter date before the signers key expires, you can have 
more than one CRLs being concurrently issued by the same CA.  Specifically, 
when re-keying, a Windows 2003 CAs that is not the root CA it will continue 
to issue CRLs and delta CRLs for the old key which has stopped signing 
certificates.  The new private key will sign certificates, CRLs, and delta 
CRLs.  Yes, the signers DN does not change only the signers certificate and 
keys. We have one client who has been pushing out two CRLs and two delta 
CRLs for over 7 months, alI signed by the same CA but with two different 
keys. They have at least 30,000 certificates outstanding.  By the way the 
Microsoft 2003 CA will not issue a certificate where the signers notAfter 
date is less than that of that of the certificate it signs. In other words 
if your CA's signing certificate expires in 6 months but you as for an 
end-entity certificate expiring in two years you get an end entity 
certificate that expires in 6 months.

At 07:54 AM 9/12/2004 -0400, Santosh Chokhani wrote:

>Julien:
>
>I have not said that you violate any standard if you do not use the same key
>to sign the certificate and CRL.  It is MS CAPI that will not verify the
>path.
>
>Now, if you use different keys, you lose crypto binding.  Neither X.509 nor
>3280 deal with how to close the security gap created by the lack of crypto
>binding.  On two different occasions, I have carried out this discussion on
>the PKIX.  The authors of 3280 seem to agree with my proposed solution of DN
>matching in the two paths.
>
>I have also drafted the text for X.509 (as US comment) to fix the problem.
>
>Rest of your posting about SKID and AKID do not seem to be related to matter
>at hand and are likely to be in error in terms of their intent and role in
>certification and CRL path validation.
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Julien Pierre
>Sent: Saturday, September 11, 2004 10:29 PM
>To: Santosh Chokhani
>Cc: [email-masked]
>Subject: Re: CA Rekey and CRL Validation
>
>
>Santosh,
>
>Santosh Chokhani wrote:
>
> >David Engberg:
> >
> >I do not know if you meant it or not, but the CA name must change, else
> >the two sets of certificates and two CRLs must be issued using
> >appropriate CRL DP and IDP respectively.  Otherwise, you will break the
> >security and be not compliant with the standards.
> >
> >
>What part of the standards would you exactly violate by using different
>keys for certs and CRLs ? I haven't seen anything that says this is
>disallowed.
>
>It seems to me RFC3280 allows SubjectKeyId / AuthorityKeyID to be used
>with both certs and CRLs. Therefore the cert issuer does not have to be
>the CRL issuer. The issuer cert of the CRL can be a cert with the same
>subject as the issuer cert for the end entity certs, but with a
>different private key and key usage .
>The NIST test suite checks that this is supported by the toolkit.
>Currently, Mozilla's NSS doesn't support this - the key is assumed to be
>the same -, but it is clearly a bug, which has been opened for a while
>and will eventually be fixed. If MS CAPI doesn't support this, then it
>is also broken in similar fashion.

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Sun, 12 Sep 2004 07:54:39 -0400
Importance: Normal
Sender: [email-masked]

Julien:

I have not said that you violate any standard if you do not use the same key
to sign the certificate and CRL.  It is MS CAPI that will not verify the
path.

Now, if you use different keys, you lose crypto binding.  Neither X.509 nor
3280 deal with how to close the security gap created by the lack of crypto
binding.  On two different occasions, I have carried out this discussion on
the PKIX.  The authors of 3280 seem to agree with my proposed solution of DN
matching in the two paths.

I have also drafted the text for X.509 (as US comment) to fix the problem.

Rest of your posting about SKID and AKID do not seem to be related to matter
at hand and are likely to be in error in terms of their intent and role in
certification and CRL path validation.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Pierre
Sent: Saturday, September 11, 2004 10:29 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

Santosh Chokhani wrote:

>David Engberg:
>
>I do not know if you meant it or not, but the CA name must change, else 
>the two sets of certificates and two CRLs must be issued using 
>appropriate CRL DP and IDP respectively.  Otherwise, you will break the 
>security and be not compliant with the standards.
>  
>
What part of the standards would you exactly violate by using different 
keys for certs and CRLs ? I haven't seen anything that says this is 
disallowed.

It seems to me RFC3280 allows SubjectKeyId / AuthorityKeyID to be used 
with both certs and CRLs. Therefore the cert issuer does not have to be 
the CRL issuer. The issuer cert of the CRL can be a cert with the same 
subject as the issuer cert for the end entity certs, but with a 
different private key and key usage .
The NIST test suite checks that this is supported by the toolkit. 
Currently, Mozilla's NSS doesn't support this - the key is assumed to be 
the same -, but it is clearly a bug, which has been opened for a while 
and will eventually be fixed. If MS CAPI doesn't support this, then it 
is also broken in similar fashion.

Date: Sat, 11 Sep 2004 19:29:27 -0700
From: Julien Pierre <[email-masked]>
Subject: Re: CA Rekey and CRL Validation
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010807030804060502090307
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Santosh,

Santosh Chokhani wrote:

>David Engberg:
>
>I do not know if you meant it or not, but the CA name must change, else
>the two sets of certificates and two CRLs must be issued using appropriate
>CRL DP and IDP respectively.  Otherwise, you will break the security and
>be not compliant with the standards.
>  
>
What part of the standards would you exactly violate by using different 
keys for certs and CRLs ? I haven't seen anything that says this is 
disallowed.

It seems to me RFC3280 allows SubjectKeyId / AuthorityKeyID to be used 
with both certs and CRLs. Therefore the cert issuer does not have to be 
the CRL issuer. The issuer cert of the CRL can be a cert with the same 
subject as the issuer cert for the end entity certs, but with a 
different private key and key usage .
The NIST test suite checks that this is supported by the toolkit. 
Currently, Mozilla's NSS doesn't support this - the key is assumed to be 
the same -, but it is clearly a bug, which has been opened for a while 
and will eventually be fixed. If MS CAPI doesn't support this, then it 
is also broken in similar fashion.

--------------ms010807030804060502090307
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010807030804060502090307--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Sat, 11 Sep 2004 12:51:46 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_008D_01C497FE.18309160
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dave:

You can keep the old CA name, if you do one of the following (there may be
other options also).

1.  Assert different CRL DP and put the matching IDP in the CRL of the two
sets of certificates; or

2.  Put all the certificates on the revoked list, but issue two CRLs, one
signed with the old key and the other one signed with the new key.  Both
CRLs will have the same and complete list of revoked certificates.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Engberg
Sent: Saturday, September 11, 2004 9:47 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Right ... that's what I meant by "with a new CRLdp", but I should have
spelled it out more explicitly.

One clarification from your other email:  if I use a different CRL DP in
the new certs, I may keep the same CA subject name for the new CA
certificate, correct?

Santosh Chokhani wrote:
> David Engberg:
>
> I do not know if you meant it or not, but the CA name must change,
> else the two sets of certificates and two CRLs must be issued using
> appropriate CRL DP and IDP respectively.  Otherwise, you will break
> the security and be not compliant with the standards.
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> On Behalf Of David Engberg
> Sent: Friday, September 10, 2004 11:23 PM
> To: Luciano (Pessoal)
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
>
>
>
> I would bet that most certificate-enabled software will not properly
> discover or process a separate CRL-signing certificate.  Section
> 5.1.1.3 specifically warns that this practice "imposes a burden on
> applications, and it might limit interoperability."
>
> Interoperability is easiest if you treat a "rekey" as an issuance of a
> separate cross-trusted CA.  Continue to issue a CRL for the old certs
> using the old key until all old certs have expired.  Issue a separate
> CRL for new certs (with a new CRLdp) using the new key.  This
> generates two CRLs instead of one, but the total size is the basically
> the same.
>
> This means, of course, that you have to keep the old key around for a
> little while until its old issued certs expire.
>
>
> Luciano (Pessoal) wrote:
>
>>"... Important: The Windows operating system family can only verify a
>>CRL that was signed by the same private key used to sign the issued
>>certificate. The Windows operating system does not support CRLs signed
>>by an entity other than the CA that signed the issued certificate.
>>...."
>
> ...
>
>
>>    I think Microsoft is ok considering the validation of certificates
>>and CRLS signed with different CA private keys is an OPTIONAL feature
>>(because of SHOULD). Once, I ask you: What about CA Rekey?

------=_NextPart_000_008D_01C497FE.18309160
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_008D_01C497FE.18309160--

Date: Sat, 11 Sep 2004 09:46:43 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030104050609080301060202
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Right ... that's what I meant by "with a new CRLdp", but I should have 
spelled it out more explicitly.

One clarification from your other email:  if I use a different CRL DP in 
the new certs, I may keep the same CA subject name for the new CA 
certificate, correct?

Santosh Chokhani wrote:
> David Engberg:
> 
> I do not know if you meant it or not, but the CA name must change, else
> the two sets of certificates and two CRLs must be issued using appropriate
> CRL DP and IDP respectively.  Otherwise, you will break the security and
> be not compliant with the standards.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of David Engberg
> Sent: Friday, September 10, 2004 11:23 PM
> To: Luciano (Pessoal)
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> 
> I would bet that most certificate-enabled software will not properly
> discover or process a separate CRL-signing certificate.  Section 5.1.1.3
> specifically warns that this practice "imposes a burden on applications,
> and it might limit interoperability."
> 
> Interoperability is easiest if you treat a "rekey" as an issuance of a
> separate cross-trusted CA.  Continue to issue a CRL for the old certs
> using the old key until all old certs have expired.  Issue a separate
> CRL for new certs (with a new CRLdp) using the new key.  This generates
> two CRLs instead of one, but the total size is the basically the same.
> 
> This means, of course, that you have to keep the old key around for a
> little while until its old issued certs expire.
> 
> 
> Luciano (Pessoal) wrote:
> 
>>"... Important: The Windows operating system family can only verify a
>>CRL that was signed by the same private key used to sign the issued
>>certificate. The Windows operating system does not support CRLs signed
>>by an entity other than the CA that signed the issued certificate.
>>...."
> 
> ...
> 
> 
>>    I think Microsoft is ok considering the validation of certificates
>>and CRLS signed with different CA private keys is an OPTIONAL feature
>>(because of SHOULD). Once, I ask you: What about CA Rekey?

--------------ms030104050609080301060202
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030104050609080301060202--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Sat, 11 Sep 2004 08:46:24 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0046_01C497DB.CF2A3BA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

David Engberg:

I do not know if you meant it or not, but the CA name must change, else
the two sets of certificates and two CRLs must be issued using appropriate
CRL DP and IDP respectively.  Otherwise, you will break the security and
be not compliant with the standards.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Engberg
Sent: Friday, September 10, 2004 11:23 PM
To: Luciano (Pessoal)
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

I would bet that most certificate-enabled software will not properly
discover or process a separate CRL-signing certificate.  Section 5.1.1.3
specifically warns that this practice "imposes a burden on applications,
and it might limit interoperability."

Interoperability is easiest if you treat a "rekey" as an issuance of a
separate cross-trusted CA.  Continue to issue a CRL for the old certs
using the old key until all old certs have expired.  Issue a separate
CRL for new certs (with a new CRLdp) using the new key.  This generates
two CRLs instead of one, but the total size is the basically the same.

This means, of course, that you have to keep the old key around for a
little while until its old issued certs expire.

Luciano (Pessoal) wrote:
> "... Important: The Windows operating system family can only verify a
> CRL that was signed by the same private key used to sign the issued
> certificate. The Windows operating system does not support CRLs signed
> by an entity other than the CA that signed the issued certificate.
> ...."
...

>     I think Microsoft is ok considering the validation of certificates
> and CRLS signed with different CA private keys is an OPTIONAL feature
> (because of SHOULD). Once, I ask you: What about CA Rekey?

------=_NextPart_000_0046_01C497DB.CF2A3BA0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0046_01C497DB.CF2A3BA0--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CA Rekey and CRL Validation
Date: Sat, 11 Sep 2004 08:42:55 -0400
Importance: Normal
Sender: [email-masked]

If your relying parties plan to use MS CAPI, when you re-key a CA, change
its name.

If you plan to use other toolkits, make sure that they build the path to CRL
and match DNs one for one and in sequence (of the certification path to the
certificate and certification path to the CRL signer) ignoring self-issued
certificates, but including the DN of the two trust anchors for the two
paths.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Luciano (Pessoal)
Sent: Friday, September 10, 2004 4:30 PM
To: [email-masked]
Subject: CA Rekey and CRL Validation

Hi All,

	I have found the following sentence in a Microsoft's paper
(Troubleshooting Certificate Status and Revocation) and I suppose that it is
about the use of cRLIssuer on CRLs and certificates.

"... Important: The Windows operating system family can only verify a CRL
that was signed by the same private key used to sign the issued certificate.
The Windows operating system does not support CRLs signed by an entity other
than the CA that signed the issued certificate. ...."

    My doubt is: What would happen  in the case of a CA Rekey?

    I know by the item "5.1.1.3" from RFC 3280 that a CRL can be signed by a
different key used to sign certificates.
   
    But, I'm not sure how does this topic fit in the case of CA Rekey where
a CRL is signed with the newer key and the certificates being verified was
signed with the older.

    In the item "5.1.1.3" we have the text ".....Applications that perform
CRL checking MUST support certification path validation when certificates
and CRLs are digitally signed with the same CA private key.  These
applications SHOULD support certification path validation when certificates
and CRLs are digitally signed with different CA private keys."

    I think Microsoft is ok considering the validation of certificates and
CRLS signed with different CA private keys is an OPTIONAL feature (because
of SHOULD). Once, I ask you: What about CA Rekey?

    Thanks in advance,

    Luciano Coelho

PS: I'm not concerned about this possible "limitation" on Microsoft's CRL
validation process. I'm interested about how a CA REKEY can interfere with
CRL check/validation.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
Cc: [email-masked]
Date: Sat, 11 Sep 2004 15:32:39 +1200
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>Well, this suggests that the NIST test suite needs to be more comprehensive.

Either that or the folks who created the test suite knew what sort of snake-
pit they were getting into by adding checks for this :-).

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
Cc: [email-masked]
Date: Sat, 11 Sep 2004 15:30:51 +1200
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>So, are you saying that MSCAPI pays attention to all extensions in a TA cert
>is when performing path validation?  if so, then it is non-compliant with the
>current X.509 and RFC 3280 (and RFC 2459) specs, because those specs say to
>NOT pay attention to name constraints in a TA.  Personally I would rather
>have cert processing pay attention to these extensions,

cryplib does this as well, and a number of other implementations (whom I
probably can't speak for, but in case anyone involved with them is still
reading this list they may want to speak out) do as well.

A while back I performed an informal survey of users to see what they'd do if
my code ignored extensions in root certs/trust anchors/whatever.  100% of
respondents said they'd file bug reports against cryptlib if the code did
that.  Now admittedly it wasn't a very large survey, everyone I asked regarded
software that did this as faulty so I stopped asking after awhile since it
didn't look like the answer would change.

>all of these specs say the opposite (in terms of this extension) and that has
>been true for some time.

This seems to be another instance of the PKIX disconnect-from-reality effect
at work.

Peter (who is now in the novel position of defending MS's non-compliance with
       standards... OTOH we seem to be in good company with this).

Date: Fri, 10 Sep 2004 23:22:55 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: "Luciano (Pessoal)" <[email-masked]>
CC: [email-masked]
Subject: Re: CA Rekey and CRL Validation
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040902070803050104090400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I would bet that most certificate-enabled software will not properly 
discover or process a separate CRL-signing certificate.  Section 5.1.1.3 
specifically warns that this practice "imposes a burden on applications, 
and it might limit interoperability."

Interoperability is easiest if you treat a "rekey" as an issuance of a 
separate cross-trusted CA.  Continue to issue a CRL for the old certs 
using the old key until all old certs have expired.  Issue a separate 
CRL for new certs (with a new CRLdp) using the new key.  This generates 
two CRLs instead of one, but the total size is the basically the same.

This means, of course, that you have to keep the old key around for a 
little while until its old issued certs expire.

Luciano (Pessoal) wrote:
> "... Important: The Windows operating system family can only verify a CRL
> that was signed by the same private key used to sign the issued
> certificate. The Windows operating system does not support CRLs signed
> by an entity other than the CA that signed the issued certificate. ...."
...

>     I think Microsoft is ok considering the validation of certificates
> and CRLS signed with different CA private keys is an OPTIONAL feature
> (because of SHOULD). Once, I ask you: What about CA Rekey?

--------------ms040902070803050104090400
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040902070803050104090400--

Date: Fri, 10 Sep 2004 17:29:44 -0300
From: "Luciano (Pessoal)" <[email-masked]>
To: [email-masked]
Subject: CA Rekey and CRL Validation
Sender: [email-masked]

Hi All,

	I have found the following sentence in a Microsoft's paper
(Troubleshooting Certificate Status and Revocation) and I suppose that
it is about the use of cRLIssuer on CRLs and certificates.

"... Important: The Windows operating system family can only verify a CRL
that was signed by the same private key used to sign the issued
certificate. The Windows operating system does not support CRLs signed
by an entity other than the CA that signed the issued certificate. ...."

    My doubt is: What would happen  in the case of a CA Rekey?

    I know by the item "5.1.1.3" from RFC 3280 that a CRL can be signed
by a different key used to sign certificates.
   
    But, I'm not sure how does this topic fit in the case of CA Rekey
where a CRL is signed with the newer key and the certificates being
verified was signed with the older.

    In the item "5.1.1.3" we have the text ".....Applications that
perform CRL checking MUST support certification path validation when
certificates and CRLs are digitally signed with the same CA private
key.  These applications SHOULD support certification path validation
when certificates and CRLs are digitally signed with different CA
private keys."

    I think Microsoft is ok considering the validation of certificates
and CRLS signed with different CA private keys is an OPTIONAL feature
(because of SHOULD). Once, I ask you: What about CA Rekey?

    Thanks in advance,

    Luciano Coelho

PS: I'm not concerned about this possible "limitation" on Microsoft's
CRL validation process. I'm interested about how a CA REKEY can
interfere with CRL check/validation.

Date: Fri, 10 Sep 2004 11:53:11 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: RP vs. user, was Re: On cross-certificates and pathLenConstraint
Sender: [email-masked]

The last sentence of the last paragraph should have been (from an
updated version):

    When merely "using" a
    certificate in this sense, the user will normally be ignoring any or
    all the RP conditions defined by the authority, when processing a
    chain of certificates and using an EE certificate issued by a CA.

Sorry for the confusion.

Cheers,
Ed Gerck

Ed Gerck wrote:

> 
> Stephen Kent wrote:
> 
>> Having just completed a review of your I-D, I know how you distinguish 
>> between a user as an RP vs. just "using" a cert.  I don't agree with 
>> the terminology. 
> 
> 
> What terminology would you suggest? For the benefit of the discussion,
> I copy below what I wrote about RPs, which is a qualified user (not any
> user). This text comes from a work-in-progress.
> 
> 2. Relying Party, RP Reliance and Reliance Limitations
> 
>    A relying party (RP) is a user who processes a certificate chain, and
>    then acts in reliance on the end-entity (EE) certificate issued by a
>    CA (the issuer CA) and any associated revocation information.
> 
>    RP reliance is a technical term in PKIX. The concept of RP reliance
>    is needed in PKIX/X.509 because not every aspect of certificate
>    management can be fully verified by an RP. In short, RP reliance is
>    that which can break the RP's security policy.
> 
>    For example, a user verifying a certificate's revocation status
>    (e.g., using mechanisms such as querying a repository or receiving
>    notices delivered via a message service) will depend on the
>    conforming administration and management of that status by one or
>    more authoritative entities -- i.e., the user becomes a relying party
>    to these entities.
> 
>    More generally, a user who depends on values provided by an entity
>    (e.g., CA) that seem reasonable on their face value to the user but
>    are especially hard to check by the user is an RP to that entity.
> 
>    What does the RP rely on? The RP relies on entities (e.g., the CA)
>    following PKIX recommendations that the RP CANNOT verify. For
>    example, an RP does not rely on the CA for certificate path
>    processing (because the RP CAN verify it) but must rely on the CA for
>    ensuring that the CA's signing key is properly secure and not
>    compromised. The latter cannot be verified by the RP and becomes,
>    thus, a limitation for reliance.
> 
>    RP reliance limitations are objectively defined in PKIX, without
>    reference to domain policies, user security policy, jurisdiction-
>    based rules of laws and contracts or anything else that needs to be
>    locally defined.
> 
>    As a literal value, RP reliance on the revocation status of a
>    certificate is defined by a conforming certificate path procedure
>    leading to a bit value -- "revoked" or "not revoked". The literal bit
>    value depends both on processes that the RP CAN verify and processes
>    that the RP CANNOT verify. The latter defines the limitations of RP
>    reliance. The lesser the limitations of RP reliance, the lesser the
>    risk faced by the RP that RP reliance might be broken by factors
>    outside RP control.
> 
>    The literal bit value has no associated semantics outside the scope
>    of PKIX. In other words, RP reliance is syntactic, not semantic. Any
>    semantic value (e.g., legal reliance, contractual obligations
>    concerning use, public policy, etc.) MUST lie outside the scope of
>    PKIX and is, for example, regulated by terms in the CA's CPS.
> 
> ...
> 
> 3.5 Reliance vs. Use
> 
>    An important distinction exists between "reliance" and "use". The
>    PKIX standards define the limitations for certificate reliance by an
>    RP in terms of a certificate user complying with the issuance and
>    revocation conditions for a certificate. Furthermore, PKIX requires
>    that compliance must occur through execution of the standardized
>    certificate path processing algorithm.
> 
>    However, there is no act of non-compliance if an RP simply decides to
>    act independently of the authority, with a "use" of the certificate,
>    rather than a "reliance upon" the certificate, its revocation
>    conditions and its revocation status.  When merely "using" a
>    certificate in this sense, the user will normally be ignoring any or
>    all the compliance requirements defined in PKIX and/or the authority,
>    when processing a chain of certificates and using an EE certificate
>    issued by a CA.
> 
> Comments are welcome. I will wait with my comments on accepting or not
> user input in cert path evaluation.
> 
> Cheers,
> Ed Gerck
> 

Date: Fri, 10 Sep 2004 11:29:20 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: RP vs. user, was Re: On cross-certificates and pathLenConstraint
Sender: [email-masked]

Stephen Kent wrote:
> Having just completed a review of your I-D, I know how you distinguish 
> between a user as an RP vs. just "using" a cert.  I don't agree with the 
> terminology. 

What terminology would you suggest? For the benefit of the discussion,
I copy below what I wrote about RPs, which is a qualified user (not any
user). This text comes from a work-in-progress.

2. Relying Party, RP Reliance and Reliance Limitations

    A relying party (RP) is a user who processes a certificate chain, and
    then acts in reliance on the end-entity (EE) certificate issued by a
    CA (the issuer CA) and any associated revocation information.

    RP reliance is a technical term in PKIX. The concept of RP reliance
    is needed in PKIX/X.509 because not every aspect of certificate
    management can be fully verified by an RP. In short, RP reliance is
    that which can break the RP's security policy.

    For example, a user verifying a certificate's revocation status
    (e.g., using mechanisms such as querying a repository or receiving
    notices delivered via a message service) will depend on the
    conforming administration and management of that status by one or
    more authoritative entities -- i.e., the user becomes a relying party
    to these entities.

    More generally, a user who depends on values provided by an entity
    (e.g., CA) that seem reasonable on their face value to the user but
    are especially hard to check by the user is an RP to that entity.

    What does the RP rely on? The RP relies on entities (e.g., the CA)
    following PKIX recommendations that the RP CANNOT verify. For
    example, an RP does not rely on the CA for certificate path
    processing (because the RP CAN verify it) but must rely on the CA for
    ensuring that the CA's signing key is properly secure and not
    compromised. The latter cannot be verified by the RP and becomes,
    thus, a limitation for reliance.

    RP reliance limitations are objectively defined in PKIX, without
    reference to domain policies, user security policy, jurisdiction-
    based rules of laws and contracts or anything else that needs to be
    locally defined.

    As a literal value, RP reliance on the revocation status of a
    certificate is defined by a conforming certificate path procedure
    leading to a bit value -- "revoked" or "not revoked". The literal bit
    value depends both on processes that the RP CAN verify and processes
    that the RP CANNOT verify. The latter defines the limitations of RP
    reliance. The lesser the limitations of RP reliance, the lesser the
    risk faced by the RP that RP reliance might be broken by factors
    outside RP control.

    The literal bit value has no associated semantics outside the scope
    of PKIX. In other words, RP reliance is syntactic, not semantic. Any
    semantic value (e.g., legal reliance, contractual obligations
    concerning use, public policy, etc.) MUST lie outside the scope of
    PKIX and is, for example, regulated by terms in the CA's CPS.

...

3.5 Reliance vs. Use

    An important distinction exists between "reliance" and "use". The
    PKIX standards define the limitations for certificate reliance by an
    RP in terms of a certificate user complying with the issuance and
    revocation conditions for a certificate. Furthermore, PKIX requires
    that compliance must occur through execution of the standardized
    certificate path processing algorithm.

    However, there is no act of non-compliance if an RP simply decides to
    act independently of the authority, with a "use" of the certificate,
    rather than a "reliance upon" the certificate, its revocation
    conditions and its revocation status.  When merely "using" a
    certificate in this sense, the user will normally be ignoring any or
    all the compliance requirements defined in PKIX and/or the authority,
    when processing a chain of certificates and using an EE certificate
    issued by a CA.

Comments are welcome. I will wait with my comments on accepting or not
user input in cert path evaluation.

Cheers,
Ed Gerck

Date: Fri, 10 Sep 2004 13:37:22 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: On cross-certificates and pathLenConstraint
Cc: [email-masked]
Sender: [email-masked]

At 12:41 PM -0700 9/9/04, Ed Gerck wrote:
>Stephen Kent wrote:
>
>>At 4:43 PM -0700 9/8/04, Ed Gerck wrote:
>>>
>>>What I'm saying is that if the user chooses not to be an RP for a cert,
>>>the user should be able to freely choose that cert's status (perhaps
>>>from a different service, but that's for the user to choose and implement).
>>>In doing so, when the user is compelled to override the result, why should
>>>the user consider himself to be "well informed" by that same result he is
>>>discarding?
>>
>>
>>I assumed, perhaps in error, that the goal was to allow a user to 
>>make an informed choice re overriding the cert evaluation 
>>procedure. If you are suggesting that a user should be free to 
>>accept anything that someone else says is a cert, which may or may 
>>not conform to standard syntax and which may or may not be valid 
>>using standard cert evaluation rules, then this is not a topic for 
>>this standards group to address.
>
>Thanks. As usual, you defined the boundary well. The goal is _not_ to allow
>a user to accept anything except that which is PKIX compliant. I am just
>suggesting we extend a mechanism that already exists, as I explain below.
>
>So, what happens with a cert evaluation procedure when a user decides _not_
>to be an RP [1] for the revocation status of a cert in the path, as defined
>by that cert's issuer CA or CRL issuer?

Having just completed a review of your I-D, I know how you 
distinguish between a user as an RP vs. just "using" a cert.  I don't 
agree with the terminology. But, more to the point, any discussion we 
have on this list about a user processing a cert he has received 
should take place in the context of the standards we develop. Once 
you move outside that realm, this WG has no say in what happens, and 
frankly it is not a good use of the list members' time to explore 
such contexts.

>
>This is the same question facing OCSP and has the same solution:
>
>    the cert evaluation process will ask the user for the status (revoked,
>    good, or unknown).
>
>I.e., when the user decides _not_ to follow the conditions defined by the
>issuer CA to be an RP for that cert, PKIX can still define an automated,
>secure, compliant procedure providing the final result -- as it does 
>with OCSP.

USe of OCSP is part of the cert evaluation process, as an alternative 
to use of CRLs. When SCVP becomes a standard, it will provide another 
standard mechanism for cert evaluation, one that can relieve the 
client of some or all of the burden. But, all of these are STANDARD 
ways of performing cert evaluation.

>In doing so, the user is not discarding any information provided by the cert
>evaluation process. As in OCSP, in allowing a user to provide an input about
>a cert's status, that input can also be the single input defining whether the
>cert is revoked or not.

When a user employs OCSP, it is not the user who provides the OCSP 
response, but rather a server. The server may be operated by the CA 
that issued the cert, making it authoritative, or it may be operated 
by (or on behalf of) the enterprise that provides the user's PKI 
context. In the latter case, a policy on how to acquire cert 
revocation status info has been imposed on the user in his 
enterprise, but it is still not the user's choice.  Now, another 
possible scenario is a user employing an OCSP server as a public 
service, but that seems to be rare, and I think it generally ill 
advised.

The bottom line is that managing cert evaluation is complex, even if 
one is just trying to follow the standard procedures. We find it hard 
to involve the user in a meaningful way, given the complexity of the 
process, and users seem to not want to get involved, in general.

Steve

Date: Thu, 09 Sep 2004 19:07:25 -0400
From: Sal Mangiapane <[email-masked]>
Reply-To: [email-masked]
Organization: Servant Technology, Inc.
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: SCVP and TRUST
Sender: [email-masked]

Stephen Kent wrote:
> At 2:31 PM -0400 9/9/04, Sal Mangiapane wrote:
> 
>> I propose a similar solution to both:
>>   A) IP address and network MASK limitations can be implemented so 
>> "computer-A" knows that "computer-B" is on the local lan or 
>> "computer-A" has been configured with the IP address of "computer-B".
> 
> 
> this is a seriously limited "security" mechanism and I don't think we 
> should consider suggesting it as an effective way for the client to know 
> that the SCVP server is "local."
> 
>>   B) "computer-A" and "computer-B" have a shared secret key for mutual 
>> authentication.
>>
>>
>> Okay, if you are willing to accept that SCVP will be able to provide 
>> bi-directional mutual authentication using the solutions I provided or 
>> any other solutions.  Then, TRUST can be removed from the wording in 
>> SCVP.
> 
> 
> "A" is not a viable solution. Were you suggesting that A and B be used 
> together or were they both options?

Either.  With "A", I was thinking about NATed computers behind a firewall.

> 
>> WHY?
>>
>> Let me build my case....  by example.... remember the early days of 
>> the internet when all naming was handled in HOST files?  And now, how 
>> DNS has revolutionized naming with on-line real-time name queries?  
>> DNS naming is ubiquitous.
>>
>> SCVP can be the same thing for PKI!  SCVP can move public keys from 
>> static files to on-line real-time queries!
> 
> 
> SCVP addresses the problem of verifying certs, especially EE certs. but 
> it does not address the problem of making these certs available to uses, 
> so the analogy is not quite accurate.

Okay, comparing DNS to SCVP is a stretch. On a very simplistic basis 
they both respond to a question.  DNS answers "What is the IP address" 
and SCVP answers the "Is this cert valid".

I would suggest that the DNS response is only a tool that the client 
must make valuable for it's own use.  The client's application has to 
provide information in order to use the response.

> 
>> As the use of public key technology increases, there will be more 
>> pressure on private keys and revocation lists.  Moving from regular 
>> updates to real time will only strengthen this technology.
> 
> 
> There is no implication that the revocation status data available to an 
> SCVP server will be any more timely than what is available from use of 
> CRLs or OCSP, so I do not see the rationale here.

Okay.

> 
>> Also, the accepted role of a CA will need to change.  The "monolithic 
>> CA providers" of today cannot provide the mutual authentication that I 
>> propose here.  CA servers would need to conform to a standard 
>> hierarchy.  The most obvious would be DNS naming.  Each domain owner 
>> would provide their own SCVP server.  I would see the role of 
>> "monolithic CA providers" changing from CA sources to service 
>> providers hosting SCVP servers and CA servers for the domain owners.
> 
> 
> One can imagine aligning CAs with the DNS hierarchy, but the 
> availability of SCVP is independent of this alignment.

I agree completely.  SCVP has to be independent of DNS but SCVP can 
truly benefit with a parallel implementation.  The DNS independence is 
why I might eventually suggest manual IP address entry of an SCVP server 
as a required entry for IP configurations.

> 
>> As the DNS has many roots, SCVP would have many roots and would use 
>> the same bi-directional mutual authentication to provide bridge 
>> arrangements to cross between top level domains.  On a side note, a 
>> TLD would provide the final authority for validating other TLD 
>> certificates.  So, one ccTLD can expressly reject certificates from 
>> another ccTLD.
> 
> 
> The DNS has a set of replicated, equivalent root servers. There is no 
> requirement in SCVP for SCVP servers to be arranged in a hierarchy.

Agreed, SCVP would replace the equivalent root servers with a bridge 
authentication mechanism between TLDs.

> 
>> I would also expect a change to the IP stack that would require the IP 
>> entry for it's SCVP server similar to DNS server entries.  I would 
>> expect the IP stack change would only occur if SCVP became widely 
>> accepted.
> 
> 
> When you suggest changes to the Ip stack I think it fair to say that you 
> have gone rather far beyond the charter of this WG :-)

"stack" may not have been the correct phrase but I understand your point.

> 
>> Now, what do the changes really give us?
>>
>> Today, everyone expects DNS to be available and usable.  Because of 
>> that, it is widely used.  I believe SCVP will provide the framework, a 
>> universal hook, for other applications and protocols to easily and 
>> securely implement certificates and PKI.  Because of SCVP, PKI would 
>> become widely used.  I see immediate benefits for e-mail, VOIP, 
>> routing and DNS.  There are tremendous benefits with non-repudiation 
>> and IP spoofing prevention.  But, I'm preaching to the choir.....
> 
> 
> DNS is widely used because it is essential to accessing web sites, 
> sending e-mail, etc. PKI is not necessary; it is an enhancement that 
> enables security services, and these services are attractive to some, 
> but not essential to all. Again, I think the analogy falls short.

DNS was not necessary when it began -- something was needed.  It was 
well defined and good at it's designed task.  It was accepted and simple 
to use.

I believe that SCVP can be good enough at verifying certs that it too 
will become widely used.  I believe that the internet needs something to 
enable security services and PKI can really fill that need.  With SCVP, 
using certs will be simple, secure, consistent and readily available to 
any application.

I agree with you, this would not be essential but maybe email would use 
PKI and SCVP services to reduce SPAM.  Maybe VOIP (with ISP support) 
would use it for non-repudiated call origination.  The application would 
need to make it an essential service.  Rather than re-inventing the 
wheel applications and other WGs etc would begin adopting PKI and SCVP 
for internal and external benefits.

I do believe that the security for validating certs needs to go the last 
mile and include shared secret keys (or something) to the clients so the 
clients don't have to TRUST that the cert was validated by the proper 
authorities.

Sal

Content-class: urn:content-classes:message
Subject: RE: RFC 3280 test cases -- Was: On cross-certificates and pathLenConstraint
Date: Thu, 9 Sep 2004 23:24:21 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

I can inform that Microsoft is fully aware about the deviations between
MS CAPI and RFC 3280. 
Your list is however not entirely correct but I'm not sure this is the
forum for the details.

I don't sell PKITS short. I just recognize the fact that it doesn't
catch all deviations. It would however be totally unrealistic to achieve
that.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 9 september 2004 22:35
> To: [email-masked]
> Subject: RE: RFC 3280 test cases -- Was: On cross-certificates and
> pathLenConstraint
> 
> 
> Stefan and Steve Kent:
> 
> I would not sell NIST test suite short.  From what I know about it, it
may
> not be testing that aspect.
> 
> MS needs to know that MS CAPI continues to fail several of the NIST
PKITS
> tests, independent of trust anchor issues, in the areas such as:
> 
> 	Name Constraints
> 	Policy related constraints (inhibit policy mapping, require
> explicit
> policy, inhibit any policy)
> 	Unknown critical extension (MS CAPI merrily process
> certificates
> with unknown critical extensions)
> 
> There are other areas where it does not provide support.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Thursday, September 09, 2004 2:28 PM
> To: Stephen Kent
> Cc: [email-masked]
> Subject: RFC 3280 test cases -- Was: On cross-certificates and
> pathLenConstraint
> 
> 
> 
> Steve,
> 
> You are absolutely right in your observation. The fact is that only a
> minor
> part (I would guess about 20%) of the deviations we have discovered
can be
> found through the NIST tests.
> 
> But I'm truly divided on what the best course of action is.
> The RFC 3280 logic, when you really dig into it, is so enormously
complex
> that a test constructed to catch all deviations would be huge and also
> extremely costly to perform.
> 
> I wouldn't rule out though that it might be possible to make the tests
a
> bit
> more effective without major increase of complexity.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: Stephen Kent [mailto:[email-masked]]
> > Sent: den 9 september 2004 19:32
> > To: Stefan Santesson
> > Cc: [email-masked]
> > Subject: RE: On cross-certificates and pathLenConstraint
> >
> > At 6:17 PM +0100 9/9/04, Stefan Santesson wrote:
> > >Yes,
> > >That is what I'm saying.
> > >The NIST test doesn't catch that though.
> > >
> > >You can say that MSCAPI is almost faithful to RFC 3280 (with all
the
> > >best intentions) but there are other minor deviations as well that
we
> > >have on our list.
> > >
> > >/Stefan
> >
> > Well, this suggests that the NIST test suite needs to be more
> > comprehensive. Our discussion shows that non-compliance  can be
> > determined independent of a test suite, whereas successful execution
> > of a test suite only increases confidence in compliance :-)  The
usual
> > partial testing vs. counter-example issue.
> >
> > Steve
> 

Date: Thu, 9 Sep 2004 17:19:18 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: SCVP and TRUST
Cc: [email-masked]
Sender: [email-masked]

At 2:31 PM -0400 9/9/04, Sal Mangiapane wrote:
>All,
>
>This is a request to remove TRUST from SCVP and replace it with 
>alternate mechanism(s) for server validation.
>
>If you are willing to accept this idea and hear me out, then I 
>believe I can provide the reasons to justify altering SCVP.
>
>Two examples of trust mentioned in SCVP:
>  1) end-user "client" device TRUSTing "SCVP server" (1.1 and 9.).
>  2) "SCVP server" dealing with TRUST anchors (3.2.14 and 6.5).
>
>As applied to the following solution:
>   For example 1) computer-A would be "client" and computer-B would 
>be "SCVP server".
>   For example 2) computer-A would be an "SCVP server" and computer-B 
>would be EITHER a "SCVP server" or a "CA server".
>
>I propose a similar solution to both:
>   A) IP address and network MASK limitations can be implemented so 
>"computer-A" knows that "computer-B" is on the local lan or 
>"computer-A" has been configured with the IP address of "computer-B".

this is a seriously limited "security" mechanism and I don't think we 
should consider suggesting it as an effective way for the client to 
know that the SCVP server is "local."

>   B) "computer-A" and "computer-B" have a shared secret key for 
>mutual authentication.
>
>
>Okay, if you are willing to accept that SCVP will be able to provide 
>bi-directional mutual authentication using the solutions I provided 
>or any other solutions.  Then, TRUST can be removed from the wording 
>in SCVP.

"A" is not a viable solution. Were you suggesting that A and B be 
used together or were they both options?

>WHY?
>
>Let me build my case....  by example.... remember the early days of 
>the internet when all naming was handled in HOST files?  And now, 
>how DNS has revolutionized naming with on-line real-time name 
>queries?  DNS naming is ubiquitous.
>
>SCVP can be the same thing for PKI!  SCVP can move public keys from 
>static files to on-line real-time queries!

SCVP addresses the problem of verifying certs, especially EE certs. 
but it does not address the problem of making these certs available 
to uses, so the analogy is not quite accurate.

>As the use of public key technology increases, there will be more 
>pressure on private keys and revocation lists.  Moving from regular 
>updates to real time will only strengthen this technology.

There is no implication that the revocation status data available to 
an SCVP server will be any more timely than what is available from 
use of CRLs or OCSP, so I do not see the rationale here.

>Also, the accepted role of a CA will need to change.  The 
>"monolithic CA providers" of today cannot provide the mutual 
>authentication that I propose here.  CA servers would need to 
>conform to a standard hierarchy.  The most obvious would be DNS 
>naming.  Each domain owner would provide their own SCVP server.  I 
>would see the role of "monolithic CA providers" changing from CA 
>sources to service providers hosting SCVP servers and CA servers for 
>the domain owners.

One can imagine aligning CAs with the DNS hierarchy, but the 
availability of SCVP is independent of this alignment.

>As the DNS has many roots, SCVP would have many roots and would use 
>the same bi-directional mutual authentication to provide bridge 
>arrangements to cross between top level domains.  On a side note, a 
>TLD would provide the final authority for validating other TLD 
>certificates.  So, one ccTLD can expressly reject certificates from 
>another ccTLD.

The DNS has a set of replicated, equivalent root servers. There is no 
requirement in SCVP for SCVP servers to be arranged in a hierarchy.

>I would also expect a change to the IP stack that would require the 
>IP entry for it's SCVP server similar to DNS server entries.  I 
>would expect the IP stack change would only occur if SCVP became 
>widely accepted.

When you suggest changes to the Ip stack I think it fair to say that 
you have gone rather far beyond the charter of this WG :-)

>Now, what do the changes really give us?
>
>Today, everyone expects DNS to be available and usable.  Because of 
>that, it is widely used.  I believe SCVP will provide the framework, 
>a universal hook, for other applications and protocols to easily and 
>securely implement certificates and PKI.  Because of SCVP, PKI would 
>become widely used.  I see immediate benefits for e-mail, VOIP, 
>routing and DNS.  There are tremendous benefits with non-repudiation 
>and IP spoofing prevention.  But, I'm preaching to the choir.....

DNS is widely used because it is essential to accessing web sites, 
sending e-mail, etc. PKI is not necessary; it is an enhancement that 
enables security services, and these services are attractive to some, 
but not essential to all. Again, I think the analogy falls short.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC 3280 test cases -- Was: On cross-certificates and pathLenConstraint
Date: Thu, 9 Sep 2004 16:35:28 -0400
Importance: Normal
Sender: [email-masked]

Stefan and Steve Kent:

I would not sell NIST test suite short.  From what I know about it, it may
not be testing that aspect.

MS needs to know that MS CAPI continues to fail several of the NIST PKITS
tests, independent of trust anchor issues, in the areas such as:

	Name Constraints
	Policy related constraints (inhibit policy mapping, require explicit
policy, inhibit any policy)
	Unknown critical extension (MS CAPI merrily process certificates
with unknown critical extensions)

There are other areas where it does not provide support. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Thursday, September 09, 2004 2:28 PM
To: Stephen Kent
Cc: [email-masked]
Subject: RFC 3280 test cases -- Was: On cross-certificates and
pathLenConstraint

Steve,

You are absolutely right in your observation. The fact is that only a minor
part (I would guess about 20%) of the deviations we have discovered can be
found through the NIST tests.

But I'm truly divided on what the best course of action is.
The RFC 3280 logic, when you really dig into it, is so enormously complex
that a test constructed to catch all deviations would be huge and also
extremely costly to perform.

I wouldn't rule out though that it might be possible to make the tests a bit
more effective without major increase of complexity.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: den 9 september 2004 19:32
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> At 6:17 PM +0100 9/9/04, Stefan Santesson wrote:
> >Yes,
> >That is what I'm saying.
> >The NIST test doesn't catch that though.
> >
> >You can say that MSCAPI is almost faithful to RFC 3280 (with all the 
> >best intentions) but there are other minor deviations as well that we 
> >have on our list.
> >
> >/Stefan
> 
> Well, this suggests that the NIST test suite needs to be more 
> comprehensive. Our discussion shows that non-compliance  can be 
> determined independent of a test suite, whereas successful execution 
> of a test suite only increases confidence in compliance :-)  The usual 
> partial testing vs. counter-example issue.
> 
> Steve

Date: Thu, 09 Sep 2004 12:41:36 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: On cross-certificates and pathLenConstraint
Sender: [email-masked]

Stephen Kent wrote:

> At 4:43 PM -0700 9/8/04, Ed Gerck wrote:
>>
>> What I'm saying is that if the user chooses not to be an RP for a cert,
>> the user should be able to freely choose that cert's status (perhaps
>> from a different service, but that's for the user to choose and 
>> implement).
>> In doing so, when the user is compelled to override the result, why 
>> should
>> the user consider himself to be "well informed" by that same result he is
>> discarding?
> 
> 
> I assumed, perhaps in error, that the goal was to allow a user to make 
> an informed choice re overriding the cert evaluation procedure. If you 
> are suggesting that a user should be free to accept anything that 
> someone else says is a cert, which may or may not conform to standard 
> syntax and which may or may not be valid using standard cert evaluation 
> rules, then this is not a topic for this standards group to address.

Thanks. As usual, you defined the boundary well. The goal is _not_ to allow
a user to accept anything except that which is PKIX compliant. I am just
suggesting we extend a mechanism that already exists, as I explain below.

So, what happens with a cert evaluation procedure when a user decides _not_
to be an RP [1] for the revocation status of a cert in the path, as defined
by that cert's issuer CA or CRL issuer?

This is the same question facing OCSP and has the same solution:

    the cert evaluation process will ask the user for the status (revoked,
    good, or unknown).

I.e., when the user decides _not_ to follow the conditions defined by the
issuer CA to be an RP for that cert, PKIX can still define an automated,
secure, compliant procedure providing the final result -- as it does with OCSP.

In doing so, the user is not discarding any information provided by the cert
evaluation process. As in OCSP, in allowing a user to provide an input about
a cert's status, that input can also be the single input defining whether the
cert is revoked or not.

What would this input do? The input signals to the cert evaluation procedure
whether the user: (1) wants to use the cert status defined by the cert
evaluation procedure (and be an RP for that cert), OR (2) simply use the cert.
In case of option (2), as in OCSP, the user must choose the cert status from a
list of all possible status accepted by the cert evaluation procedure.

What would be the constraints on applying this user input? PKIX as usual. The
cert must be PKIX compliant, the path validation follows PKIX, etc.

> Simplistic, yes, simple, no.
> 
> Experience with user interfaces would suggest that the sort of process 
> you describe would hardly ever be used, because it would take too much 
> effort by a user and would be too complicated for the vast majority of 
> users to understand.

You are right on the face of doing it by hand, but a user-defined cert status
service could handle this automatically. An enterprise-wide policy file could
also be used to provide bars on the choices each user is allowed to.

> Your example makes it pretty clear how unrealistic 
> this would be.

OCSP?

Finally, it seems to me that if the user cannot _choose_ to be an RP, if that
choice is mandated to him for all certs by some software (not by the enterprise),
it could be realistically said that the user is not an RP. What is unrealistic,
IMHO, is to mandate an user to be an RP by force for all certs in the path when
we already have a mechanism (OCSP) that could be extended to accept the user's
input as well.

Cheers,
Ed Gerck

[1] I note that PKIX does _not_ mandate users to be RPs of certs and PKIX does
_not_ limit users to seek revocation status of a cert only from the cert's
issuer CA or CRL issuer. PKIX users can use any revocation status information
source they please and be an RP to them. PKIX users may also just "use" a cert,
being an RP to no one, and still be 100% PKIX compliant.

Date: Thu, 09 Sep 2004 14:31:54 -0400
From: Sal Mangiapane <[email-masked]>
Reply-To: [email-masked]
Organization: Servant Technology, Inc.
To: [email-masked]
Subject: SCVP and TRUST
Sender: [email-masked]

All,

This is a request to remove TRUST from SCVP and replace it with 
alternate mechanism(s) for server validation.

If you are willing to accept this idea and hear me out, then I believe I 
can provide the reasons to justify altering SCVP.

Two examples of trust mentioned in SCVP:
  1) end-user "client" device TRUSTing "SCVP server" (1.1 and 9.).
  2) "SCVP server" dealing with TRUST anchors (3.2.14 and 6.5).

As applied to the following solution:
   For example 1) computer-A would be "client" and computer-B would be 
"SCVP server".
   For example 2) computer-A would be an "SCVP server" and computer-B 
would be EITHER a "SCVP server" or a "CA server".

I propose a similar solution to both:
   A) IP address and network MASK limitations can be implemented so 
"computer-A" knows that "computer-B" is on the local lan or "computer-A" 
has been configured with the IP address of "computer-B".
   B) "computer-A" and "computer-B" have a shared secret key for mutual 
authentication.

Okay, if you are willing to accept that SCVP will be able to provide 
bi-directional mutual authentication using the solutions I provided or 
any other solutions.  Then, TRUST can be removed from the wording in SCVP.

WHY?

Let me build my case....  by example.... remember the early days of the 
internet when all naming was handled in HOST files?  And now, how DNS 
has revolutionized naming with on-line real-time name queries?  DNS 
naming is ubiquitous.

SCVP can be the same thing for PKI!  SCVP can move public keys from 
static files to on-line real-time queries!

As the use of public key technology increases, there will be more 
pressure on private keys and revocation lists.  Moving from regular 
updates to real time will only strengthen this technology.

Also, the accepted role of a CA will need to change.  The "monolithic CA 
providers" of today cannot provide the mutual authentication that I 
propose here.  CA servers would need to conform to a standard hierarchy. 
  The most obvious would be DNS naming.  Each domain owner would provide 
their own SCVP server.  I would see the role of "monolithic CA 
providers" changing from CA sources to service providers hosting SCVP 
servers and CA servers for the domain owners.

As the DNS has many roots, SCVP would have many roots and would use the 
same bi-directional mutual authentication to provide bridge arrangements 
to cross between top level domains.  On a side note, a TLD would provide 
the final authority for validating other TLD certificates.  So, one 
ccTLD can expressly reject certificates from another ccTLD.

I would also expect a change to the IP stack that would require the IP 
entry for it's SCVP server similar to DNS server entries.  I would 
expect the IP stack change would only occur if SCVP became widely accepted.

Now, what do the changes really give us?

Today, everyone expects DNS to be available and usable.  Because of 
that, it is widely used.  I believe SCVP will provide the framework, a 
universal hook, for other applications and protocols to easily and 
securely implement certificates and PKI.  Because of SCVP, PKI would 
become widely used.  I see immediate benefits for e-mail, VOIP, routing 
and DNS.  There are tremendous benefits with non-repudiation and IP 
spoofing prevention.  But, I'm preaching to the choir.....

Please respond,

Sal

Content-class: urn:content-classes:message
Subject: RFC 3280 test cases -- Was: On cross-certificates and pathLenConstraint
Date: Thu, 9 Sep 2004 19:27:41 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Steve,

You are absolutely right in your observation. The fact is that only a
minor part (I would guess about 20%) of the deviations we have
discovered can be found through the NIST tests.

But I'm truly divided on what the best course of action is.
The RFC 3280 logic, when you really dig into it, is so enormously
complex that a test constructed to catch all deviations would be huge
and also extremely costly to perform.

I wouldn't rule out though that it might be possible to make the tests a
bit more effective without major increase of complexity.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: den 9 september 2004 19:32
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> At 6:17 PM +0100 9/9/04, Stefan Santesson wrote:
> >Yes,
> >That is what I'm saying.
> >The NIST test doesn't catch that though.
> >
> >You can say that MSCAPI is almost faithful to RFC 3280 (with all the
> >best intentions) but there are other minor deviations as well that we
> >have on our list.
> >
> >/Stefan
> 
> Well, this suggests that the NIST test suite needs to be more
> comprehensive. Our discussion shows that non-compliance  can be
> determined independent of a test suite, whereas successful execution
> of a test suite only increases confidence in compliance :-)  The
> usual partial testing vs. counter-example issue.
> 
> Steve

Date: Thu, 9 Sep 2004 14:19:13 -0400
To: Tom Gindin <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Cc: [email-masked]
Sender: [email-masked]

At 7:31 AM -0400 9/8/04, Tom Gindin wrote:
>         Santosh:
>
>         I thought that you were also saying that setting such parameters
>was non-compliant with RFC 3280, or at least not interoperable with
>compliant implementations.  If you believe that setting such parameters is
>permissible and sometimes (not always) appropriate, then we certainly
>agree.
>         On a separate point, my views on constraints in anchor definitions
>are different than Steve K.'s, but I don't think we're that far apart.  I
>don't think that it's any worse to have a vendor set a name constraint on
>a CA than for that same vendor to decide whether or not to include it in a
>default set of anchors in the first place.   I do believe that it is
>desirable for RP's to be able to edit anchor constraints (especially ones
>coming from the software vendor), just as it is for RP's to be able to add
>or delete anchor definitions.

I am unhappy with vendors including default TAs in a product, so we 
are in agreement to some extent :-)

steve

Date: Thu, 9 Sep 2004 13:31:42 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Cc: <[email-masked]>
Sender: [email-masked]

At 6:17 PM +0100 9/9/04, Stefan Santesson wrote:
>Yes,
>That is what I'm saying.
>The NIST test doesn't catch that though.
>
>You can say that MSCAPI is almost faithful to RFC 3280 (with all the
>best intentions) but there are other minor deviations as well that we
>have on our list.
>
>/Stefan

Well, this suggests that the NIST test suite needs to be more 
comprehensive. Our discussion shows that non-compliance  can be 
determined independent of a test suite, whereas successful execution 
of a test suite only increases confidence in compliance :-)  The 
usual partial testing vs. counter-example issue.

Steve

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Thu, 9 Sep 2004 18:17:32 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Yes, 
That is what I'm saying.
The NIST test doesn't catch that though.

You can say that MSCAPI is almost faithful to RFC 3280 (with all the
best intentions) but there are other minor deviations as well that we
have on our list.

/Stefan

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: den 9 september 2004 18:45
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> At 4:38 PM +0100 9/9/04, Stefan Santesson wrote:
> >No I'm not saying that.
> >MS CAPI will process the root extensions and you can't turn that off.
> >
> 
> Stefan,
> 
> So, are you saying that MSCAPI pays attention to all extensions in a
> TA cert is when performing path validation?  if so, then it is
> non-compliant with the current X.509 and RFC 3280 (and RFC 2459)
> specs, because those specs say to NOT pay attention to name
> constraints in a TA.  Personally I would rather have cert processing
> pay attention to these extensions, but all of these specs say the
> opposite (in terms of this extension) and that has been true for some
> time.
> 
> Steve

Date: Thu, 9 Sep 2004 12:44:56 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Cc: <[email-masked]>
Sender: [email-masked]

At 4:38 PM +0100 9/9/04, Stefan Santesson wrote:
>No I'm not saying that.
>MS CAPI will process the root extensions and you can't turn that off.
>

Stefan,

So, are you saying that MSCAPI pays attention to all extensions in a 
TA cert is when performing path validation?  if so, then it is 
non-compliant with the current X.509 and RFC 3280 (and RFC 2459) 
specs, because those specs say to NOT pay attention to name 
constraints in a TA.  Personally I would rather have cert processing 
pay attention to these extensions, but all of these specs say the 
opposite (in terms of this extension) and that has been true for some 
time.

Steve

Date: Thu, 9 Sep 2004 09:52:49 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: On cross-certificates and pathLenConstraint
Cc: [email-masked]
Sender: [email-masked]

At 4:43 PM -0700 9/8/04, Ed Gerck wrote:
>Stephen Kent wrote:
>>...
>>The user probably wants to know what the evaluation process found 
>>out about the cert, so that the user is well informed if he choose 
>>to override the outcome.
>
>What I'm saying is that if the user chooses not to be an RP for a cert,
>the user should be able to freely choose that cert's status (perhaps
>from a different service, but that's for the user to choose and implement).
>In doing so, when the user is compelled to override the result, why should
>the user consider himself to be "well informed" by that same result he is
>discarding?

I assumed, perhaps in error, that the goal was to allow a user to 
make an informed choice re overriding the cert evaluation procedure. 
If you are suggesting that a user should be free to accept anything 
that someone else says is a cert, which may or may not conform to 
standard syntax and which may or may not be valid using standard cert 
evaluation rules, then this is not a topic for this standards group 
to address.

>>But, we have no standards for what a cert evaluation engine would 
>>display to help a user in this regard. So, I'm afraid the problem 
>>of letting an RP override the output of the cert evaluation process 
>>is more complex that your message suggests.
>
>Again, if the user decides to override, such decision must come from 
>a parallel
>decision channel -- not from that same evaluation process which is being
>discarded. For example, if a user receives something as simple as an
>encrypted message, the user should be able to decrypt and read that message
>even though the cert evaluation engine reports that the cert's status is
>revoked -- after all, the sender might have revoked the cert _after_ the
>message was sent. Therefore, any information that a compliant evaluation
>process could provide (and here might be an opportunity for 
>additional standards
>work) is indeed informative but is not so absolutely relevant to that user as
>it may seem at first sight.
>
>So, if we do decide that it is desirable (from the very definition of what
>an RP must be able to do in order to be an RP at all) to let an RP 
>override the
>output of the cert evaluation process, how simple can this be?
>
>Very simple. Let the user manually select from a list of available choices any
>of the possible PKIX outcomes at each step, where the cert evaluation engine
>may suggest the outcome if the user chooses to be an RP for that cert.

Simplistic, yes, simple, no.

Experience with user interfaces would suggest that the sort of 
process you describe would hardly ever be used, because it would take 
too much effort by a user and would be too complicated for the vast 
majority of users to understand. Your example makes it pretty clear 
how unrealistic this would be.

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Thu, 9 Sep 2004 16:38:33 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

No I'm not saying that.
MS CAPI will process the root extensions and you can't turn that off.

/Stefan
 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 9 september 2004 13:50
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> Are you saying that if we had constraints in a trust anchor MS CAPI
can be
> configured or invoked to ignore those?
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Thursday, September 09, 2004 3:22 AM
> To: Stephen Kent
> Cc: Santosh Chokhani; [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Stephen Kent [mailto:[email-masked]]
> >
> > I think it fair to say that if a product's default configuration
> > passes the standards interoperability tests, it is compliant.
> >
> > Steve
> 
> [Stefan] I have no problem with that.
> Unfortunately however, which I pointed out to Santosh before, the NIST
PKI
> test suite doesn't provide any compliance test regarding root
extension
> processing since it doesn't make use of any root certificates with
> constraints or policies.
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Thu, 9 Sep 2004 07:49:33 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

Are you saying that if we had constraints in a trust anchor MS CAPI can be
configured or invoked to ignore those?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Thursday, September 09, 2004 3:22 AM
To: Stephen Kent
Cc: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> 
> I think it fair to say that if a product's default configuration 
> passes the standards interoperability tests, it is compliant.
> 
> Steve

[Stefan] I have no problem with that.
Unfortunately however, which I pointed out to Santosh before, the NIST PKI
test suite doesn't provide any compliance test regarding root extension
processing since it doesn't make use of any root certificates with
constraints or policies.

From: Alicia da Conceicao <[email-masked]>
Subject: RE: howto combine a client signature with a timestamp?
To: [email-masked], [email-masked]
Date: Thu, 9 Sep 2004 07:38:02 -0400 (EDT)
Sender: [email-masked]

Miguel A Rodriguez wrote:
> Take a look at RFC 3126, it extends CMS to include rfc3161 timestamps.

Hi Miguel:

I have looked in detail at RFC-3126, RFC-3161, & RFC-3369 and I am
still unclear how to generate a single complete example of my own CMS
"ES-T" (Electronic Signature with Timestamp).

I would be most greatly if ANYONE had ANY valid examples of a DER encoded
"ES-T", so that I can clarify exactly how it is done.  If anyone managed
to generate just a single example, please e-mail me the entire DER encoded
binary as an attachment, or inline as UUENCODE or BASE64.

On a side note, after giving it a lot of thought, I still think it would
be much better (and much more practical) to simply include a copy of a
client's original CMS signature as an unsigned/unauthenticated object
within the TSA's signerInfo, inside a RFC-3161 timestamp of that client's
signature.  So that the TSTInfo in the timestamp would contain a digest
hash of the client's digital signature, and one can independently
validate both the timestamp of the signature and the signature of the
original message, all from a single timestamp token.

I realize that this is backwards to the approach suggested in RFC-3126, in
that the orignal signature is appended to the timestamp token, instead of
appending the timestamp to the original signature.  But this approach has
a number of advantages.  One key advantage is for a TSA (TimeStamp
Authority) that must store timestamps for legacy clients, especially legacy
clients in banking that do not have the ability to properly store and
achive timestamps themselves for financial transactions.  By simply putting
the original client's digital signature within the timestamp that is
subsequently signed again by the TSA, the TSA can easily store both in a
single timestamp token with minimal effort, and that single token can be
used by a validator to validate both the original digital signature of a
message and the timestamp of that digital signature.

Comments???  Or has something similar already been proposed and is part
of an existing standard?

Thank you in advance.
Alicia.

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Thu, 9 Sep 2004 08:21:55 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> 
> I think it fair to say that if a product's default configuration
> passes the standards interoperability tests, it is compliant.
> 
> Steve

[Stefan] I have no problem with that.
Unfortunately however, which I pointed out to Santosh before, the NIST
PKI test suite doesn't provide any compliance test regarding root
extension processing since it doesn't make use of any root certificates
with constraints or policies.

Date: Wed, 08 Sep 2004 16:43:18 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: On cross-certificates and pathLenConstraint
Sender: [email-masked]

Stephen Kent wrote:
> ...
> The user probably wants to know what the 
> evaluation process found out about the cert, so that the user is well 
> informed if he choose to override the outcome. 

What I'm saying is that if the user chooses not to be an RP for a cert,
the user should be able to freely choose that cert's status (perhaps
from a different service, but that's for the user to choose and implement).
In doing so, when the user is compelled to override the result, why should
the user consider himself to be "well informed" by that same result he is
discarding?

> But, we have no standards 
> for what a cert evaluation engine would display to help a user in this 
> regard. So, I'm afraid the problem of letting an RP override the output 
> of the cert evaluation process is more complex that your message suggests.

Again, if the user decides to override, such decision must come from a parallel
decision channel -- not from that same evaluation process which is being
discarded. For example, if a user receives something as simple as an
encrypted message, the user should be able to decrypt and read that message
even though the cert evaluation engine reports that the cert's status is
revoked -- after all, the sender might have revoked the cert _after_ the
message was sent. Therefore, any information that a compliant evaluation
process could provide (and here might be an opportunity for additional standards
work) is indeed informative but is not so absolutely relevant to that user as
it may seem at first sight.

So, if we do decide that it is desirable (from the very definition of what
an RP must be able to do in order to be an RP at all) to let an RP override the
output of the cert evaluation process, how simple can this be?

Very simple. Let the user manually select from a list of available choices any
of the possible PKIX outcomes at each step, where the cert evaluation engine
may suggest the outcome if the user chooses to be an RP for that cert.

This can be further automated, for example:

1. If the user selects "MANUAL" processing, at every step of the cert path
validation process then the user should be able to override the result, whatever
that result is, before the process continues to the last cert. The overriding
options available to the user should be the same as the compliant options that the
process could provide at each step. This allows the RP to decide, for every cert,
to be or not to be an RP.

2. If the user selects "AUTOMATIC" processing, the cert evaluation engine makes
all decisions as if the user is an RP to each and every cert and presents the final
result to the user. However, even in this case, the user should be able to
override the final result and manually select any of the possible outcomes.
This allows the RP to decide to be or not to be an RP for the entire cert
evaluation process.

The above has nothing to do with implementing or standardizing user choices. The
user does not define the logic; the user chooses the available truth-conditions
for the compliant logic to use at each step. After the user runs such a compliant
evaluation software for a cert, the result reflects the PKIX rules based on the
user-defined RP status for each cert.

Cheers,
Ed Gerck

Date: Wed, 8 Sep 2004 16:54:43 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: On cross-certificates and pathLenConstraint
Cc: [email-masked]
Sender: [email-masked]

At 3:18 PM -0700 9/7/04, Ed Gerck wrote:
>Stephen Kent wrote:
>>again, a human being making a value judgement is one thing, but 
>>developers trying to provide software that evaluates a cert path 
>>and accepts or rejects a cert do have to worry about what controls 
>>are offered to a user to affect the evaluation process.
>
>An RP should not have to argue with the software, or his computer,
>in order to accept or reject a cert.
>
>The software must allow the RP to authoritatively, even against the
>software's findings, rely or not rely on any cert. In short, the
>software MUST allow any RP to independently rely on or not rely on
>any certificate.
>
>You said the same yourself:  "The user as RP should be able to make
>these decisions, or his management may do so based on corporate policy.
>But if an application embodies these extra-standard decisions [eg, asking
>the RP for "reasons"], and the app is not enterprise-specific, then we
>have a problem because the application vendor is not the RP and is no
>longer representing the wishes of the RP."
>
>Developers trying to provide software that evaluates a cert path
>have, thus, a simple task: to implement an "override" control for
>the RP. What's difficult with that?

What may be difficult is knowing whether the user invoked the 
override, or some possibly malicious software did so :-)

But, if all you want is an override facility, you are probably not 
helping the user enough.  The user probably wants to know what the 
evaluation process found out about the cert, so that the user is well 
informed if he choose to override the outcome. But, we have no 
standards for what a cert evaluation engine would display to help a 
user in this regard. So, I'm afraid the problem of letting an RP 
override the output of the cert evaluation process is more complex 
that your message suggests.

Steve

Date: Wed, 8 Sep 2004 16:46:12 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Cc: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 10:23 PM +0100 9/7/04, Stefan Santesson wrote:
>Steve,
>
>You dress it so nicely :-)
>
>I was not trying to make the point the way you fear. I just wanted to
>point out that a certain application may be configured to implement a
>certain policy and that configuration may be imposed by management. Not
>necessarily by the vendor.
>
>OK?

In that light, yes, OK.

>
>Now, the essence of this discussion is what it takes to claim
>compliance. I'm not making any claims about any future behaviour of any
>product delivered by the company I work for :-)

I think it fair to say that if a product's default configuration 
passes the standards interoperability tests, it is compliant.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Wed, 8 Sep 2004 08:47:39 -0400
Importance: Normal
Sender: [email-masked]

Tom:

See responses in-line in [].

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Wednesday, September 08, 2004 7:32 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

        Santosh:

        I thought that you were also saying that setting such parameters 
was non-compliant with RFC 3280, or at least not interoperable with 
compliant implementations.  If you believe that setting such parameters is 
permissible and sometimes (not always) appropriate, then we certainly 
agree.

[X.509 does not permit setting of some of the parameters today, but as
Sharon pointed out X.509 is in the revision process to permit setting these.
3280 should be interpreted as saying that the relying party can do some pre
or post processing, but there must be a path validation engine that complies
with the logic provided in Section 6.1.]

        On a separate point, my views on constraints in anchor definitions 
are different than Steve K.'s, but I don't think we're that far apart.  I 
don't think that it's any worse to have a vendor set a name constraint on 
a CA than for that same vendor to decide whether or not to include it in a 
default set of anchors in the first place.   I do believe that it is 
desirable for RP's to be able to edit anchor constraints (especially ones 
coming from the software vendor), just as it is for RP's to be able to add 
or delete anchor definitions.

[My position is that it is desirable to use the constraints from the trust
anchor and then further constraint them.  (Of course, this is all change in
X.509 and 3280.)  For example if a trust anchor wants to constrain trust
emanating from it to a name space, the RP should honor that and can further
constrain the name space.  Same for path length.]

        Lastly, IMHO an interchange format for anchor definitions should 
be defined, so that users can import those of other users (or corporate 
admins, or whoever they choose).  However, I doubt that it's this group's 
role to specify such a format.  If others think that it's in scope for 
PKIX, I won't complain.  Obviously, if such a format is supported for both 
export and import by most programs, and can be edited with standard tools, 
concerns about vendors over-controlling the RP's set of anchors would be 
greatly mitigated.

[I think this is in the scope of PKIX.  From practical viewpoint, due to
installed base, that format happens to be a certificate, self-signed or
otherwise.  So, I am not sure anything not accommodating certificates will
fly.]

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

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
09/06/2004 02:13 PM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: On cross-certificates and pathLenConstraint

Tom:

Are you really saying something different from what I am saying?

I am saying that;

1 If there is a capability to set the initialization variables beyond 
those
specified in the standard, the capability should be configurable; and

2.  When you set the values per standard, you should get the results per 
the
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Monday, September 06, 2004 10:13 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

        Santosh:

        If an algorithm accepts all paths which are recommended by RFC 
3280 section 6.1, in what sense could it be considered an "augmented" 
algorithm?  An augmented algorithm, in the natural sense of the term, does 

more processing than is done by the base algorithm.  If it is required to 
come to identical results in all cases, that extra processing is 
fruitless.
        For example, if an RP associates a permitted-subtree with a 
particular trust anchor in such a way that certificates whose subject DN 
contains a "C" attribute are not permitted to come from that anchor unless 

C's value matches the one in the anchor's DN, how does this violate RFC 
3280?  It directly follows a suggestion in RFC 3280 6.2.  I do not mean, 
of course, that that particular rule (no certification between anchors 
from one country and subjects from another) is one which any product 
should enforce unless the RP chooses it or the certificate the RP uses to 
represent an anchor contains it.
        What is required for interoperability is that when the RP does not 

choose any augmented conditions (either manually or by using a 
cross-certificate containing them) the software comes to the same results 
as RFC 3280.  The issue is not "does an RP decide to reject a certificate" 

but "may the RP place extra conditions on certificates he accepts through 
a given anchor, and reject those which fail"?
        In practice IMHO, many RP's will import anchor definitions from 
third parties with more expertise than the average user - corporate 
administrators, trusted agencies, or even software manufacturers. 
Constraints of the sort that I have been advocating could often come with 
the anchor definition.  Whether they are imported as part of a certificate 

or as separate fields (probably tagged as such in an XML or .ini format) 
is of secondary importance.
 
                Tom Gindin
P.S. -  The opinions in this posting are mine, and not necesarily those of 

my employer.

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
09/03/2004 08:50 AM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: On cross-certificates and pathLenConstraint

Stefan:

I would note two things.  They seem to be repeat of the themes from me in
this thread.

1.  For interoperability reasons, it is not sufficient to reject paths
considered bad by 3280.  Paths considered good by 3280 should also be
accepted.

2.  The key is the RP user to be able to set the path validation engine
initialization variables as opposed to the engine/API making that
determination for the entire consumer/RP community. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Stefan Santesson
Sent: Friday, September 03, 2004 4:05 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santosh,

That is not at all what I try to say.

First of all. If you have the ability to augment the standard algorithm,
does not mean that you necessarily don't have a default mode that you can
use for standard compliance testing.

Secondly, even if you run in some augmented mode, you can still make tests
to make sure that a bad path, actually is rejected (i.e. no valid
augmentation allows a bad path to pass). Even in this mode you can make 
many
valid standards compliance claims.

Finally you are right about the tricky part to test compliance and interop
regarding variable initialization. This is because the algorithm specified
in RFC 3280 is one example of a compliant algorithm, and even if it were 
THE
algorithm, different implementations of it would still have different APIs
with different ways and methods to handle these variables. 

Example. 
Implementation 1 has a certain way to initialize a variable in the API
request and delivers a distinct result.

Implementation 2 does not provide any possibility to initialize this
variable but does instead deliver a response that can be masked for the
proper mode of operation (=different variable settings).

As long as we don't standardize the APIs we will have hard time making 
these
tests effectively.

I agree that it is a bit confusing that RFC 3280 define the ability to
initialize some variables while it at the same time has a language that
opens for adding any other type of constraints to the process.

So I do believe that the only thing you can successfully test widely is 
the
default algorithm with default parameter settings, which is exactly what
NIST PKITS is doing.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 3 september 2004 01:14
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> An advantage of what Steve Kent is saying is that the validation
engine's
> compliance to 3280 can be conformance tested for the current standard
as
> well as for revised standard that contained features for the RP to 
> initialize the various state variables.
> 
> If you use your argument, we can not make any standard compliance
claims.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stephen Kent
> Sent: Thursday, September 02, 2004 4:18 PM
> To: Stefan Santesson
> Cc: Peter Hesse; Santosh Chokhani; Steve Hanna; [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
> >Applying local trust policies is not a matter of interoperability. It 
> >is just a matter of local policy.
> >
> >An application may be configured, in accordance with local policy to 
> >reject a certificate based on any reason it chooses.
> >
> >We are not arguing about how RFC 3280 path validation works. RFC 3280 
> >path validation ignores TA extensions. Period.
> >
> >But if an application chooses to accept any restrictions set in the
TA
> >certificate, it is entitled to do so at its own discretion.
> 
> I was in agreement up to this point. The path validation process 
> divides has fixed aspects, and a user-settable aspects. In terms of 
> initialization, the standards (X.509 and RFC 3280) don't provide a 
> means to initialize some of the variables that we would like, e.g., 
> name constraints. So, I think that an application is over stepping the 
> bounds of the standard if it initializes variables for which the 
> standards make no such provision.
> 
> 
> >It is not up
> >to any standard to say that it can't. This is then of course no
longer
> >basic RFC 3280 validation, but some form of augmented RFC 3280 path 
> >validation (I.e RFC 3280 path validation + some locally defined 
> >additional constraints).
> 
> i.e., it's non-standard :-)
> 
> >The only interoperability issue at hand is to make sure that all 
> >applications 1) who choose just basic RFC 3280 path validation use
the
> >same rules and optionally 2) that those who choose to honour TA 
> >extensions may do so in a uniform manner thanks to clearly defined 
> >rules.
> 
> well, I'm generally opposed to having a CA issue a self-signed cert 
> that is used as a TA, given that the TA parameters should be 
> controlled by an RP, not the CA. BUT, the reality is that many folks 
> DO take such certs and use them as TAs, then the problem with your 
> suggestion is that the same cert use as a TA by different RPs will 
> have different effects, which is not what the CA would anticipate 
> under the standard path validation algorithm. So, if what you said was 
> that the USER could augment the path validation algorithm by 
> initializing parameter values that the standards don't allow, I'd be 
> sympathetic since the intent is to allow the user, as an RP, to do 
> what he should be able to do. But, you refer to an application doing 
> this, not a user, and for that I am less sympathetic, because it 
> sounds like a vendor of an application making a decision for everyone, 
> and that is not in the spirit of allowing the RPs to exercise control 
> over the validation process.
> 
> So, which do you mean?
> 
> Steve

To: "Santosh Chokhani" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
From: Tom Gindin <[email-masked]>
Date: Wed, 8 Sep 2004 07:31:37 -0400
Sender: [email-masked]

        Santosh:

        I thought that you were also saying that setting such parameters 
was non-compliant with RFC 3280, or at least not interoperable with 
compliant implementations.  If you believe that setting such parameters is 
permissible and sometimes (not always) appropriate, then we certainly 
agree.
        On a separate point, my views on constraints in anchor definitions 
are different than Steve K.'s, but I don't think we're that far apart.  I 
don't think that it's any worse to have a vendor set a name constraint on 
a CA than for that same vendor to decide whether or not to include it in a 
default set of anchors in the first place.   I do believe that it is 
desirable for RP's to be able to edit anchor constraints (especially ones 
coming from the software vendor), just as it is for RP's to be able to add 
or delete anchor definitions.
        Lastly, IMHO an interchange format for anchor definitions should 
be defined, so that users can import those of other users (or corporate 
admins, or whoever they choose).  However, I doubt that it's this group's 
role to specify such a format.  If others think that it's in scope for 
PKIX, I won't complain.  Obviously, if such a format is supported for both 
export and import by most programs, and can be edited with standard tools, 
concerns about vendors over-controlling the RP's set of anchors would be 
greatly mitigated.

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

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
09/06/2004 02:13 PM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: On cross-certificates and pathLenConstraint

Tom:

Are you really saying something different from what I am saying?

I am saying that;

1 If there is a capability to set the initialization variables beyond 
those
specified in the standard, the capability should be configurable; and

2.  When you set the values per standard, you should get the results per 
the
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Monday, September 06, 2004 10:13 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

        Santosh:

        If an algorithm accepts all paths which are recommended by RFC 
3280 section 6.1, in what sense could it be considered an "augmented" 
algorithm?  An augmented algorithm, in the natural sense of the term, does 

more processing than is done by the base algorithm.  If it is required to 
come to identical results in all cases, that extra processing is 
fruitless.
        For example, if an RP associates a permitted-subtree with a 
particular trust anchor in such a way that certificates whose subject DN 
contains a "C" attribute are not permitted to come from that anchor unless 

C's value matches the one in the anchor's DN, how does this violate RFC 
3280?  It directly follows a suggestion in RFC 3280 6.2.  I do not mean, 
of course, that that particular rule (no certification between anchors 
from one country and subjects from another) is one which any product 
should enforce unless the RP chooses it or the certificate the RP uses to 
represent an anchor contains it.
        What is required for interoperability is that when the RP does not 

choose any augmented conditions (either manually or by using a 
cross-certificate containing them) the software comes to the same results 
as RFC 3280.  The issue is not "does an RP decide to reject a certificate" 

but "may the RP place extra conditions on certificates he accepts through 
a given anchor, and reject those which fail"?
        In practice IMHO, many RP's will import anchor definitions from 
third parties with more expertise than the average user - corporate 
administrators, trusted agencies, or even software manufacturers. 
Constraints of the sort that I have been advocating could often come with 
the anchor definition.  Whether they are imported as part of a certificate 

or as separate fields (probably tagged as such in an XML or .ini format) 
is of secondary importance.
 
                Tom Gindin
P.S. -  The opinions in this posting are mine, and not necesarily those of 

my employer.

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
09/03/2004 08:50 AM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: On cross-certificates and pathLenConstraint

Stefan:

I would note two things.  They seem to be repeat of the themes from me in
this thread.

1.  For interoperability reasons, it is not sufficient to reject paths
considered bad by 3280.  Paths considered good by 3280 should also be
accepted.

2.  The key is the RP user to be able to set the path validation engine
initialization variables as opposed to the engine/API making that
determination for the entire consumer/RP community. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Stefan Santesson
Sent: Friday, September 03, 2004 4:05 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santosh,

That is not at all what I try to say.

First of all. If you have the ability to augment the standard algorithm,
does not mean that you necessarily don't have a default mode that you can
use for standard compliance testing.

Secondly, even if you run in some augmented mode, you can still make tests
to make sure that a bad path, actually is rejected (i.e. no valid
augmentation allows a bad path to pass). Even in this mode you can make 
many
valid standards compliance claims.

Finally you are right about the tricky part to test compliance and interop
regarding variable initialization. This is because the algorithm specified
in RFC 3280 is one example of a compliant algorithm, and even if it were 
THE
algorithm, different implementations of it would still have different APIs
with different ways and methods to handle these variables. 

Example. 
Implementation 1 has a certain way to initialize a variable in the API
request and delivers a distinct result.

Implementation 2 does not provide any possibility to initialize this
variable but does instead deliver a response that can be masked for the
proper mode of operation (=different variable settings).

As long as we don't standardize the APIs we will have hard time making 
these
tests effectively.

I agree that it is a bit confusing that RFC 3280 define the ability to
initialize some variables while it at the same time has a language that
opens for adding any other type of constraints to the process.

So I do believe that the only thing you can successfully test widely is 
the
default algorithm with default parameter settings, which is exactly what
NIST PKITS is doing.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 3 september 2004 01:14
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> An advantage of what Steve Kent is saying is that the validation
engine's
> compliance to 3280 can be conformance tested for the current standard
as
> well as for revised standard that contained features for the RP to
> initialize the various state variables.
> 
> If you use your argument, we can not make any standard compliance
claims.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stephen Kent
> Sent: Thursday, September 02, 2004 4:18 PM
> To: Stefan Santesson
> Cc: Peter Hesse; Santosh Chokhani; Steve Hanna; [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
> >Applying local trust policies is not a matter of interoperability. It
> >is just a matter of local policy.
> >
> >An application may be configured, in accordance with local policy to
> >reject a certificate based on any reason it chooses.
> >
> >We are not arguing about how RFC 3280 path validation works. RFC 3280
> >path validation ignores TA extensions. Period.
> >
> >But if an application chooses to accept any restrictions set in the
TA
> >certificate, it is entitled to do so at its own discretion.
> 
> I was in agreement up to this point. The path validation process
> divides has fixed aspects, and a user-settable aspects. In terms of 
> initialization, the standards (X.509 and RFC 3280) don't provide a 
> means to initialize some of the variables that we would like, e.g., 
> name constraints. So, I think that an application is over stepping the 
> bounds of the standard if it initializes variables for which the 
> standards make no such provision.
> 
> 
> >It is not up
> >to any standard to say that it can't. This is then of course no
longer
> >basic RFC 3280 validation, but some form of augmented RFC 3280 path
> >validation (I.e RFC 3280 path validation + some locally defined 
> >additional constraints).
> 
> i.e., it's non-standard :-)
> 
> >The only interoperability issue at hand is to make sure that all
> >applications 1) who choose just basic RFC 3280 path validation use
the
> >same rules and optionally 2) that those who choose to honour TA
> >extensions may do so in a uniform manner thanks to clearly defined 
> >rules.
> 
> well, I'm generally opposed to having a CA issue a self-signed cert
> that is used as a TA, given that the TA parameters should be 
> controlled by an RP, not the CA. BUT, the reality is that many folks 
> DO take such certs and use them as TAs, then the problem with your 
> suggestion is that the same cert use as a TA by different RPs will 
> have different effects, which is not what the CA would anticipate 
> under the standard path validation algorithm. So, if what you said was 
> that the USER could augment the path validation algorithm by 
> initializing parameter values that the standards don't allow, I'd be 
> sympathetic since the intent is to allow the user, as an RP, to do 
> what he should be able to do. But, you refer to an application doing 
> this, not a user, and for that I am less sympathetic, because it 
> sounds like a vendor of an application making a decision for everyone, 
> and that is not in the spirit of allowing the RPs to exercise control 
> over the validation process.
> 
> So, which do you mean?
> 
> Steve

Date: Tue, 07 Sep 2004 15:18:45 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: On cross-certificates and pathLenConstraint
Sender: [email-masked]

Stephen Kent wrote:
> again, a human being making a value judgement is one thing, but 
> developers trying to provide software that evaluates a cert path and 
> accepts or rejects a cert do have to worry about what controls are 
> offered to a user to affect the evaluation process.

An RP should not have to argue with the software, or his computer,
in order to accept or reject a cert.

The software must allow the RP to authoritatively, even against the
software's findings, rely or not rely on any cert. In short, the
software MUST allow any RP to independently rely on or not rely on
any certificate.

You said the same yourself:  "The user as RP should be able to make
these decisions, or his management may do so based on corporate policy.
But if an application embodies these extra-standard decisions [eg, asking
the RP for "reasons"], and the app is not enterprise-specific, then we
have a problem because the application vendor is not the RP and is no
longer representing the wishes of the RP."

Developers trying to provide software that evaluates a cert path
have, thus, a simple task: to implement an "override" control for
the RP. What's difficult with that?

Cheers,
Ed Gerck

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 7 Sep 2004 22:23:55 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Steve,

You dress it so nicely :-)

I was not trying to make the point the way you fear. I just wanted to
point out that a certain application may be configured to implement a
certain policy and that configuration may be imposed by management. Not
necessarily by the vendor.

OK?

Now, the essence of this discussion is what it takes to claim
compliance. I'm not making any claims about any future behaviour of any
product delivered by the company I work for :-)

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 7 september 2004 16:33
> To: Stefan Santesson
> Cc: Santosh Chokhani; [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> At 3:28 PM +0100 9/3/04, Stefan Santesson wrote:
> >Santosh.
> >
> >Short in-line
> >
> >
> >>  -----Original Message-----
> >>  From: [email-masked]
> >[mailto:[email-masked]]
> >>  On Behalf Of Santosh Chokhani
> >>  Sent: den 3 september 2004 14:50
> >>  To: [email-masked]
> >>  Subject: RE: On cross-certificates and pathLenConstraint
> >>
> >>
> >>  Stefan:
> >>
> >>  I would note two things.  They seem to be repeat of the themes
from me
> >in
> >>  this thread.
> >>
> >>  1.  For interoperability reasons, it is not sufficient to reject
paths
> >>  considered bad by 3280.  Paths considered good by 3280 should also
be
> >>  accepted.
> >>
> >[Stefan] Agreed. I never meant to say anything else.
> >
> >>  2.  The key is the RP user to be able to set the path validation
> >engine
> >>  initialization variables as opposed to the engine/API making that
> >>  determination for the entire consumer/RP community.
> >
> >[Stefan] Agreed. I never meant to say anything else. However the
> >decision may not be taken by the user, it could be taken by his
> >application, his manager, his It department or whatever.
> 
> It's your mention of "his application" that causes concern.  The user
> as RP should be able to make these decisions, or his management may
> do so based on corporate policy.  But if an application embodies
> these extra-standard decisions, and the app is not
> enterprise-specific, then we have a problem because the application
> vendor is not the RP and is no longer representing the wishes of the
> RP.
> 
> Steve

Date: Tue, 7 Sep 2004 12:59:20 -0400
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: On cross-certificates and pathLenConstraint
Cc: [email-masked]
Sender: [email-masked]

At 2:45 PM -0700 9/3/04, Ed Gerck wrote:
>Stephen Kent wrote:
>
>>
>>At 9:55 PM +0100 9/2/04, Stefan Santesson wrote:
>>
>>>Steve,
>>>
>>>I've learned that in discussions like this you have to make small steps
>>>and agree on the fundamental basics before you can dig into details.
>>>
>>>So I just try to establish the simple truth that RP's have the right to
>>>deny trust in any certificate for any reason. And I mean literally ANY
>>>reason. No exception what so ever.
>>
>>
>>First, the term "trust" is one I try to avoid, so we're off to a bad start.
>
>I guess that's why you always use "TA" rather than "Trust Anchor" ;-)

exactly!

>If what you mean to say is that an RP can choose to reject any cert 
>for arbitrary reasons, I agree.

good.

>This paragraph motivates me to reply. An RP is obviously authoritative
>for the sources of information that that relying party trusts.

agreed, when we talk about people. But, we create standards for 
algorithmic execution, and it may be unrealistic to expect software 
implementing these standards to be able to accommodate any arbitrary 
reason for rejecting a cert.

>Now, do RP reasons really matter for PKIX standard developers? No.
>An RP should be able to reject any cert and is 100% authoritative do
>so. Period. An RP can also decide to just _use_ the cert, without
>any desire to rely (as an RP) on any representations by the cert's
>issuer.

again, a human being making a value judgement is one thing, but 
developers trying to provide software that evaluates a cert path and 
accepts or rejects a cert do have to worry about what controls are 
offered to a user to affect the evaluation process.

>Different RPs will say different things. And this is fine, because
>PKIX cannot tell RPs what to say, trust or even what to believe.

True, but that is not what we are debating.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 7 Sep 2004 10:43:05 -0400
Importance: Normal
Sender: [email-masked]

For the benefit of both Stefan and Tom:

I agree with Steve Kent.  His articulation is much clearer than mine and is
unambiguous.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, September 07, 2004 10:33 AM
To: Stefan Santesson
Cc: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

At 3:28 PM +0100 9/3/04, Stefan Santesson wrote:
>Santosh.
>
>Short in-line
>
>
>>  -----Original Message-----
>>  From: [email-masked]
>[mailto:[email-masked]]
>>  On Behalf Of Santosh Chokhani
>>  Sent: den 3 september 2004 14:50
>>  To: [email-masked]
>>  Subject: RE: On cross-certificates and pathLenConstraint
>>
>>
>>  Stefan:
>>
>>  I would note two things.  They seem to be repeat of the themes from 
>> me
>in
>>  this thread.
>>
>>  1.  For interoperability reasons, it is not sufficient to reject 
>> paths  considered bad by 3280.  Paths considered good by 3280 should 
>> also be  accepted.
>>
>[Stefan] Agreed. I never meant to say anything else.
>
>>  2.  The key is the RP user to be able to set the path validation
>engine
>>  initialization variables as opposed to the engine/API making that  
>> determination for the entire consumer/RP community.
>
>[Stefan] Agreed. I never meant to say anything else. However the 
>decision may not be taken by the user, it could be taken by his 
>application, his manager, his It department or whatever.

It's your mention of "his application" that causes concern.  The user 
as RP should be able to make these decisions, or his management may 
do so based on corporate policy.  But if an application embodies 
these extra-standard decisions, and the app is not 
enterprise-specific, then we have a problem because the application 
vendor is not the RP and is no longer representing the wishes of the 
RP.

Steve

Date: Tue, 7 Sep 2004 10:33:08 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Cc: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 3:28 PM +0100 9/3/04, Stefan Santesson wrote:
>Santosh.
>
>Short in-line
>
>
>>  -----Original Message-----
>>  From: [email-masked]
>[mailto:[email-masked]]
>>  On Behalf Of Santosh Chokhani
>>  Sent: den 3 september 2004 14:50
>>  To: [email-masked]
>>  Subject: RE: On cross-certificates and pathLenConstraint
>>
>>
>>  Stefan:
>>
>>  I would note two things.  They seem to be repeat of the themes from me
>in
>>  this thread.
>>
>>  1.  For interoperability reasons, it is not sufficient to reject paths
>>  considered bad by 3280.  Paths considered good by 3280 should also be
>>  accepted.
>>
>[Stefan] Agreed. I never meant to say anything else.
>
>>  2.  The key is the RP user to be able to set the path validation
>engine
>>  initialization variables as opposed to the engine/API making that
>>  determination for the entire consumer/RP community.
>
>[Stefan] Agreed. I never meant to say anything else. However the
>decision may not be taken by the user, it could be taken by his
>application, his manager, his It department or whatever.

It's your mention of "his application" that causes concern.  The user 
as RP should be able to make these decisions, or his management may 
do so based on corporate policy.  But if an application embodies 
these extra-standard decisions, and the app is not 
enterprise-specific, then we have a problem because the application 
vendor is not the RP and is no longer representing the wishes of the 
RP.

Steve

Date: Tue, 7 Sep 2004 10:33:08 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Cc: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 3:28 PM +0100 9/3/04, Stefan Santesson wrote:
>Santosh.
>
>Short in-line
>
>
>>  -----Original Message-----
>>  From: [email-masked]
>[mailto:[email-masked]]
>>  On Behalf Of Santosh Chokhani
>>  Sent: den 3 september 2004 14:50
>>  To: [email-masked]
>>  Subject: RE: On cross-certificates and pathLenConstraint
>>
>>
>>  Stefan:
>>
>>  I would note two things.  They seem to be repeat of the themes from me
>in
>>  this thread.
>>
>>  1.  For interoperability reasons, it is not sufficient to reject paths
>>  considered bad by 3280.  Paths considered good by 3280 should also be
>>  accepted.
>>
>[Stefan] Agreed. I never meant to say anything else.
>
>>  2.  The key is the RP user to be able to set the path validation
>engine
>>  initialization variables as opposed to the engine/API making that
>>  determination for the entire consumer/RP community.
>
>[Stefan] Agreed. I never meant to say anything else. However the
>decision may not be taken by the user, it could be taken by his
>application, his manager, his It department or whatever.

It's your mention of "his application" that causes concern.  The user 
as RP should be able to make these decisions, or his management may 
do so based on corporate policy.  But if an application embodies 
these extra-standard decisions, and the app is not 
enterprise-specific, then we have a problem because the application 
vendor is not the RP and is no longer representing the wishes of the 
RP.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Mon, 6 Sep 2004 14:13:20 -0400
Importance: Normal
Sender: [email-masked]

Tom:

Are you really saying something different from what I am saying?

I am saying that;

1 If there is a capability to set the initialization variables beyond those
specified in the standard, the capability should be configurable; and

2.  When you set the values per standard, you should get the results per the
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Monday, September 06, 2004 10:13 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

        Santosh:

        If an algorithm accepts all paths which are recommended by RFC 
3280 section 6.1, in what sense could it be considered an "augmented" 
algorithm?  An augmented algorithm, in the natural sense of the term, does 
more processing than is done by the base algorithm.  If it is required to 
come to identical results in all cases, that extra processing is 
fruitless.
        For example, if an RP associates a permitted-subtree with a 
particular trust anchor in such a way that certificates whose subject DN 
contains a "C" attribute are not permitted to come from that anchor unless 
C's value matches the one in the anchor's DN, how does this violate RFC 
3280?  It directly follows a suggestion in RFC 3280 6.2.  I do not mean, 
of course, that that particular rule (no certification between anchors 
from one country and subjects from another) is one which any product 
should enforce unless the RP chooses it or the certificate the RP uses to 
represent an anchor contains it.
        What is required for interoperability is that when the RP does not 
choose any augmented conditions (either manually or by using a 
cross-certificate containing them) the software comes to the same results 
as RFC 3280.  The issue is not "does an RP decide to reject a certificate" 
but "may the RP place extra conditions on certificates he accepts through 
a given anchor, and reject those which fail"?
        In practice IMHO, many RP's will import anchor definitions from 
third parties with more expertise than the average user - corporate 
administrators, trusted agencies, or even software manufacturers. 
Constraints of the sort that I have been advocating could often come with 
the anchor definition.  Whether they are imported as part of a certificate 
or as separate fields (probably tagged as such in an XML or .ini format) 
is of secondary importance.
 
                Tom Gindin
P.S. -  The opinions in this posting are mine, and not necesarily those of 
my employer.

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
09/03/2004 08:50 AM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: On cross-certificates and pathLenConstraint

Stefan:

I would note two things.  They seem to be repeat of the themes from me in
this thread.

1.  For interoperability reasons, it is not sufficient to reject paths
considered bad by 3280.  Paths considered good by 3280 should also be
accepted.

2.  The key is the RP user to be able to set the path validation engine
initialization variables as opposed to the engine/API making that
determination for the entire consumer/RP community. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Stefan Santesson
Sent: Friday, September 03, 2004 4:05 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santosh,

That is not at all what I try to say.

First of all. If you have the ability to augment the standard algorithm,
does not mean that you necessarily don't have a default mode that you can
use for standard compliance testing.

Secondly, even if you run in some augmented mode, you can still make tests
to make sure that a bad path, actually is rejected (i.e. no valid
augmentation allows a bad path to pass). Even in this mode you can make 
many
valid standards compliance claims.

Finally you are right about the tricky part to test compliance and interop
regarding variable initialization. This is because the algorithm specified
in RFC 3280 is one example of a compliant algorithm, and even if it were 
THE
algorithm, different implementations of it would still have different APIs
with different ways and methods to handle these variables. 

Example. 
Implementation 1 has a certain way to initialize a variable in the API
request and delivers a distinct result.

Implementation 2 does not provide any possibility to initialize this
variable but does instead deliver a response that can be masked for the
proper mode of operation (=different variable settings).

As long as we don't standardize the APIs we will have hard time making 
these
tests effectively.

I agree that it is a bit confusing that RFC 3280 define the ability to
initialize some variables while it at the same time has a language that
opens for adding any other type of constraints to the process.

So I do believe that the only thing you can successfully test widely is 
the
default algorithm with default parameter settings, which is exactly what
NIST PKITS is doing.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 3 september 2004 01:14
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> An advantage of what Steve Kent is saying is that the validation
engine's
> compliance to 3280 can be conformance tested for the current standard
as
> well as for revised standard that contained features for the RP to
> initialize the various state variables.
> 
> If you use your argument, we can not make any standard compliance
claims.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stephen Kent
> Sent: Thursday, September 02, 2004 4:18 PM
> To: Stefan Santesson
> Cc: Peter Hesse; Santosh Chokhani; Steve Hanna; [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
> >Applying local trust policies is not a matter of interoperability. It
> >is just a matter of local policy.
> >
> >An application may be configured, in accordance with local policy to
> >reject a certificate based on any reason it chooses.
> >
> >We are not arguing about how RFC 3280 path validation works. RFC 3280
> >path validation ignores TA extensions. Period.
> >
> >But if an application chooses to accept any restrictions set in the
TA
> >certificate, it is entitled to do so at its own discretion.
> 
> I was in agreement up to this point. The path validation process
> divides has fixed aspects, and a user-settable aspects. In terms of 
> initialization, the standards (X.509 and RFC 3280) don't provide a 
> means to initialize some of the variables that we would like, e.g., 
> name constraints. So, I think that an application is over stepping the 
> bounds of the standard if it initializes variables for which the 
> standards make no such provision.
> 
> 
> >It is not up
> >to any standard to say that it can't. This is then of course no
longer
> >basic RFC 3280 validation, but some form of augmented RFC 3280 path
> >validation (I.e RFC 3280 path validation + some locally defined 
> >additional constraints).
> 
> i.e., it's non-standard :-)
> 
> >The only interoperability issue at hand is to make sure that all
> >applications 1) who choose just basic RFC 3280 path validation use
the
> >same rules and optionally 2) that those who choose to honour TA
> >extensions may do so in a uniform manner thanks to clearly defined 
> >rules.
> 
> well, I'm generally opposed to having a CA issue a self-signed cert
> that is used as a TA, given that the TA parameters should be 
> controlled by an RP, not the CA. BUT, the reality is that many folks 
> DO take such certs and use them as TAs, then the problem with your 
> suggestion is that the same cert use as a TA by different RPs will 
> have different effects, which is not what the CA would anticipate 
> under the standard path validation algorithm. So, if what you said was 
> that the USER could augment the path validation algorithm by 
> initializing parameter values that the standards don't allow, I'd be 
> sympathetic since the intent is to allow the user, as an RP, to do 
> what he should be able to do. But, you refer to an application doing 
> this, not a user, and for that I am less sympathetic, because it 
> sounds like a vendor of an application making a decision for everyone, 
> and that is not in the spirit of allowing the RPs to exercise control 
> over the validation process.
> 
> So, which do you mean?
> 
> Steve

To: "Santosh Chokhani" <[email-masked]>
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
From: Tom Gindin <[email-masked]>
Date: Mon, 6 Sep 2004 10:13:19 -0400
Sender: [email-masked]

        Santosh:

        If an algorithm accepts all paths which are recommended by RFC 
3280 section 6.1, in what sense could it be considered an "augmented" 
algorithm?  An augmented algorithm, in the natural sense of the term, does 
more processing than is done by the base algorithm.  If it is required to 
come to identical results in all cases, that extra processing is 
fruitless.
        For example, if an RP associates a permitted-subtree with a 
particular trust anchor in such a way that certificates whose subject DN 
contains a "C" attribute are not permitted to come from that anchor unless 
C's value matches the one in the anchor's DN, how does this violate RFC 
3280?  It directly follows a suggestion in RFC 3280 6.2.  I do not mean, 
of course, that that particular rule (no certification between anchors 
from one country and subjects from another) is one which any product 
should enforce unless the RP chooses it or the certificate the RP uses to 
represent an anchor contains it.
        What is required for interoperability is that when the RP does not 
choose any augmented conditions (either manually or by using a 
cross-certificate containing them) the software comes to the same results 
as RFC 3280.  The issue is not "does an RP decide to reject a certificate" 
but "may the RP place extra conditions on certificates he accepts through 
a given anchor, and reject those which fail"?
        In practice IMHO, many RP's will import anchor definitions from 
third parties with more expertise than the average user - corporate 
administrators, trusted agencies, or even software manufacturers. 
Constraints of the sort that I have been advocating could often come with 
the anchor definition.  Whether they are imported as part of a certificate 
or as separate fields (probably tagged as such in an XML or .ini format) 
is of secondary importance.
 
                Tom Gindin
P.S. -  The opinions in this posting are mine, and not necesarily those of 
my employer.

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
09/03/2004 08:50 AM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: On cross-certificates and pathLenConstraint

Stefan:

I would note two things.  They seem to be repeat of the themes from me in
this thread.

1.  For interoperability reasons, it is not sufficient to reject paths
considered bad by 3280.  Paths considered good by 3280 should also be
accepted.

2.  The key is the RP user to be able to set the path validation engine
initialization variables as opposed to the engine/API making that
determination for the entire consumer/RP community. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Stefan Santesson
Sent: Friday, September 03, 2004 4:05 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santosh,

That is not at all what I try to say.

First of all. If you have the ability to augment the standard algorithm,
does not mean that you necessarily don't have a default mode that you can
use for standard compliance testing.

Secondly, even if you run in some augmented mode, you can still make tests
to make sure that a bad path, actually is rejected (i.e. no valid
augmentation allows a bad path to pass). Even in this mode you can make 
many
valid standards compliance claims.

Finally you are right about the tricky part to test compliance and interop
regarding variable initialization. This is because the algorithm specified
in RFC 3280 is one example of a compliant algorithm, and even if it were 
THE
algorithm, different implementations of it would still have different APIs
with different ways and methods to handle these variables. 

Example. 
Implementation 1 has a certain way to initialize a variable in the API
request and delivers a distinct result.

Implementation 2 does not provide any possibility to initialize this
variable but does instead deliver a response that can be masked for the
proper mode of operation (=different variable settings).

As long as we don't standardize the APIs we will have hard time making 
these
tests effectively.

I agree that it is a bit confusing that RFC 3280 define the ability to
initialize some variables while it at the same time has a language that
opens for adding any other type of constraints to the process.

So I do believe that the only thing you can successfully test widely is 
the
default algorithm with default parameter settings, which is exactly what
NIST PKITS is doing.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 3 september 2004 01:14
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> An advantage of what Steve Kent is saying is that the validation
engine's
> compliance to 3280 can be conformance tested for the current standard
as
> well as for revised standard that contained features for the RP to 
> initialize the various state variables.
> 
> If you use your argument, we can not make any standard compliance
claims.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stephen Kent
> Sent: Thursday, September 02, 2004 4:18 PM
> To: Stefan Santesson
> Cc: Peter Hesse; Santosh Chokhani; Steve Hanna; [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
> >Applying local trust policies is not a matter of interoperability. It 
> >is just a matter of local policy.
> >
> >An application may be configured, in accordance with local policy to 
> >reject a certificate based on any reason it chooses.
> >
> >We are not arguing about how RFC 3280 path validation works. RFC 3280 
> >path validation ignores TA extensions. Period.
> >
> >But if an application chooses to accept any restrictions set in the
TA
> >certificate, it is entitled to do so at its own discretion.
> 
> I was in agreement up to this point. The path validation process 
> divides has fixed aspects, and a user-settable aspects. In terms of 
> initialization, the standards (X.509 and RFC 3280) don't provide a 
> means to initialize some of the variables that we would like, e.g., 
> name constraints. So, I think that an application is over stepping the 
> bounds of the standard if it initializes variables for which the 
> standards make no such provision.
> 
> 
> >It is not up
> >to any standard to say that it can't. This is then of course no
longer
> >basic RFC 3280 validation, but some form of augmented RFC 3280 path 
> >validation (I.e RFC 3280 path validation + some locally defined 
> >additional constraints).
> 
> i.e., it's non-standard :-)
> 
> >The only interoperability issue at hand is to make sure that all 
> >applications 1) who choose just basic RFC 3280 path validation use
the
> >same rules and optionally 2) that those who choose to honour TA 
> >extensions may do so in a uniform manner thanks to clearly defined 
> >rules.
> 
> well, I'm generally opposed to having a CA issue a self-signed cert 
> that is used as a TA, given that the TA parameters should be 
> controlled by an RP, not the CA. BUT, the reality is that many folks 
> DO take such certs and use them as TAs, then the problem with your 
> suggestion is that the same cert use as a TA by different RPs will 
> have different effects, which is not what the CA would anticipate 
> under the standard path validation algorithm. So, if what you said was 
> that the USER could augment the path validation algorithm by 
> initializing parameter values that the standards don't allow, I'd be 
> sympathetic since the intent is to allow the user, as an RP, to do 
> what he should be able to do. But, you refer to an application doing 
> this, not a user, and for that I am less sympathetic, because it 
> sounds like a vendor of an application making a decision for everyone, 
> and that is not in the spirit of allowing the RPs to exercise control 
> over the validation process.
> 
> So, which do you mean?
> 
> Steve

From: "Miguel Rodriguez" <[email-masked]>
To: "'Alicia da Conceicao'" <[email-masked]>, <[email-masked]>
Subject: RE: howto combine a client signature with a timestamp?
Date: Sun, 5 Sep 2004 13:42:08 -0500
Importance: Normal
Sender: [email-masked]

Take a look at RFC 3126, it extends CMS to include rfc3161 timestamps.

Regards,

Miguel A Rodriguez
SeguriData
Mexico

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alicia da Conceicao
> Sent: Saturday, September 04, 2004 4:46 AM
> To: [email-masked]
> Subject: howto combine a client signature with a timestamp?
> 
> 
> 
> Greetings:
> 
> A while back I developed my own TCP based RFC-3161 complient 
> timestamping
> client and servers.  Currently I have a pressing need to also 
> timestamp
> CMS digital signatures (RFC-3369) as well and archive them 
> with the TSA.
>  
> Rather then store separate files for the a client's digital 
> signature and 
> the TSA timestamp of that signature, it would be ideal to 
> store them both 
> in single file.                  
>  
> Unfortunately, I cannot find any examples on this.  RFC-3161 
> does recommend
> that one place the TSA issued timestamp token inside a 
> client's CMS digital
> signature (signed-data) as an 
> unsigned/unauthenticated-attribute within the
> client's signer info, using the OID "1.2.840.113549.1.9.16.2.14".
> 
> However, if the timestamp is issued for the a client's CMS 
> digital signature
> (signed-data) structure, then the timestamp will contain a 
> hash of that
> structure without the timestamp token.  So if the timestamp 
> token is appended
> to the CMS structure, the CMS structure hash would change and 
> the timestamp
> would no longer correspond to it.  It is true that someone 
> with this type of
> ugly CMS structure could extract the timestamp, then change 
> many of the DER
> lengths in the CMS structure to get the original signature, 
> then compare it
> with the extracted timestamp, but this would be a very 
> horrible method.  It
> would also be ugly to use BER encoding with arbitary lengths, with CMS
> structures that are typically always DER encoded.
>  
> Is there a better way to do this?  I looked at combining a client's
> signerInfo after the TSA signerInfo within the same 
> timestamp, but that might
> break a few PKIX standards.      
>  
> Since timestamping is primarily suited for digital 
> signatures, to prove that
> a client's signature was signed at a specified time, someone 
> (hopefully on
> this mailing list) must have a generated at least one example.
> 
> Does anyone have any DER encoded examples of a combined 
> client's digital
> signature with a TSA issued timestamp of that signature, 
> using RSA-SHA1.
> If it helps, you can pretend that I have some arbitary Excel 
> spreadsheet
> with a SHA1 digest hash of
> 
>         01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67
> 
> and e-mail a combined DER encoded structure with both the 
> client's digital
> signature and TSA issued timestamp of that signature.
> 
> Thank you very much in advance for any assistance you can provide.
> Alicia.
> 

From: Alicia da Conceicao <[email-masked]>
Subject: howto combine a client signature with a timestamp?
To: [email-masked]
Date: Sat, 4 Sep 2004 05:46:29 -0400 (EDT)
Sender: [email-masked]

Greetings:

A while back I developed my own TCP based RFC-3161 complient timestamping
client and servers.  Currently I have a pressing need to also timestamp
CMS digital signatures (RFC-3369) as well and archive them with the TSA.
 
Rather then store separate files for the a client's digital signature and 
the TSA timestamp of that signature, it would be ideal to store them both 
in single file.                  
 
Unfortunately, I cannot find any examples on this.  RFC-3161 does recommend
that one place the TSA issued timestamp token inside a client's CMS digital
signature (signed-data) as an unsigned/unauthenticated-attribute within the
client's signer info, using the OID "1.2.840.113549.1.9.16.2.14".

However, if the timestamp is issued for the a client's CMS digital signature
(signed-data) structure, then the timestamp will contain a hash of that
structure without the timestamp token.  So if the timestamp token is appended
to the CMS structure, the CMS structure hash would change and the timestamp
would no longer correspond to it.  It is true that someone with this type of
ugly CMS structure could extract the timestamp, then change many of the DER
lengths in the CMS structure to get the original signature, then compare it
with the extracted timestamp, but this would be a very horrible method.  It
would also be ugly to use BER encoding with arbitary lengths, with CMS
structures that are typically always DER encoded.
 
Is there a better way to do this?  I looked at combining a client's
signerInfo after the TSA signerInfo within the same timestamp, but that might
break a few PKIX standards.      
 
Since timestamping is primarily suited for digital signatures, to prove that
a client's signature was signed at a specified time, someone (hopefully on
this mailing list) must have a generated at least one example.

Does anyone have any DER encoded examples of a combined client's digital
signature with a TSA issued timestamp of that signature, using RSA-SHA1.
If it helps, you can pretend that I have some arbitary Excel spreadsheet
with a SHA1 digest hash of

        01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67

and e-mail a combined DER encoded structure with both the client's digital
signature and TSA issued timestamp of that signature.

Thank you very much in advance for any assistance you can provide.
Alicia.

Date: Fri, 03 Sep 2004 14:45:17 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Stefan Santesson <[email-masked]>, Peter Hesse <[email-masked]>, Santosh Chokhani <[email-masked]>, Steve Hanna <[email-masked]>, [email-masked]
Subject: Re: On cross-certificates and pathLenConstraint
Sender: [email-masked]

Stephen Kent wrote:

> 
> At 9:55 PM +0100 9/2/04, Stefan Santesson wrote:
> 
>> Steve,
>>
>> I've learned that in discussions like this you have to make small steps
>> and agree on the fundamental basics before you can dig into details.
>>
>> So I just try to establish the simple truth that RP's have the right to
>> deny trust in any certificate for any reason. And I mean literally ANY
>> reason. No exception what so ever.
> 
> 
> First, the term "trust" is one I try to avoid, so we're off to a bad 
> start. 

I guess that's why you always use "TA" rather than "Trust Anchor" ;-)

> If what you mean to say is that an RP can choose to reject any 
> cert for arbitrary reasons, I agree. 

This paragraph motivates me to reply. An RP is obviously authoritative
for the sources of information that that relying party trusts.

Now, do RP reasons really matter for PKIX standard developers? No.
An RP should be able to reject any cert and is 100% authoritative do
so. Period. An RP can also decide to just _use_ the cert, without
any desire to rely (as an RP) on any representations by the cert's
issuer.

Different RPs will say different things. And this is fine, because
PKIX cannot tell RPs what to say, trust or even what to believe.

Cheers,
Ed Gerck

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Fri, 3 Sep 2004 15:28:34 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh.

Short in-line

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 3 september 2004 14:50
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> I would note two things.  They seem to be repeat of the themes from me
in
> this thread.
> 
> 1.  For interoperability reasons, it is not sufficient to reject paths
> considered bad by 3280.  Paths considered good by 3280 should also be
> accepted.
> 
[Stefan] Agreed. I never meant to say anything else.

> 2.  The key is the RP user to be able to set the path validation
engine
> initialization variables as opposed to the engine/API making that
> determination for the entire consumer/RP community.

[Stefan] Agreed. I never meant to say anything else. However the
decision may not be taken by the user, it could be taken by his
application, his manager, his It department or whatever.

> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Friday, September 03, 2004 4:05 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> Santosh,
> 
> That is not at all what I try to say.
> 
> First of all. If you have the ability to augment the standard
algorithm,
> does not mean that you necessarily don't have a default mode that you
can
> use for standard compliance testing.
> 
> Secondly, even if you run in some augmented mode, you can still make
tests
> to make sure that a bad path, actually is rejected (i.e. no valid
> augmentation allows a bad path to pass). Even in this mode you can
make
> many
> valid standards compliance claims.
> 
> Finally you are right about the tricky part to test compliance and
interop
> regarding variable initialization. This is because the algorithm
specified
> in RFC 3280 is one example of a compliant algorithm, and even if it
were
> THE
> algorithm, different implementations of it would still have different
APIs
> with different ways and methods to handle these variables.
> 
> Example.
> Implementation 1 has a certain way to initialize a variable in the API
> request and delivers a distinct result.
> 
> Implementation 2 does not provide any possibility to initialize this
> variable but does instead deliver a response that can be masked for
the
> proper mode of operation (=different variable settings).
> 
> As long as we don't standardize the APIs we will have hard time making
> these
> tests effectively.
> 
> I agree that it is a bit confusing that RFC 3280 define the ability to
> initialize some variables while it at the same time has a language
that
> opens for adding any other type of constraints to the process.
> 
> So I do believe that the only thing you can successfully test widely
is
> the
> default algorithm with default parameter settings, which is exactly
what
> NIST PKITS is doing.
> 
> /Stefan
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 3 september 2004 01:14
> > To: [email-masked]
> > Subject: RE: On cross-certificates and pathLenConstraint
> >
> >
> > Stefan:
> >
> > An advantage of what Steve Kent is saying is that the validation
> engine's
> > compliance to 3280 can be conformance tested for the current
standard
> as
> > well as for revised standard that contained features for the RP to
> > initialize the various state variables.
> >
> > If you use your argument, we can not make any standard compliance
> claims.
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On
> > Behalf Of Stephen Kent
> > Sent: Thursday, September 02, 2004 4:18 PM
> > To: Stefan Santesson
> > Cc: Peter Hesse; Santosh Chokhani; Steve Hanna; [email-masked]
> > Subject: RE: On cross-certificates and pathLenConstraint
> >
> >
> >
> > At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
> > >Applying local trust policies is not a matter of interoperability.
It
> > >is just a matter of local policy.
> > >
> > >An application may be configured, in accordance with local policy
to
> > >reject a certificate based on any reason it chooses.
> > >
> > >We are not arguing about how RFC 3280 path validation works. RFC
3280
> > >path validation ignores TA extensions. Period.
> > >
> > >But if an application chooses to accept any restrictions set in the
> TA
> > >certificate, it is entitled to do so at its own discretion.
> >
> > I was in agreement up to this point. The path validation process
> > divides has fixed aspects, and a user-settable aspects. In terms of
> > initialization, the standards (X.509 and RFC 3280) don't provide a
> > means to initialize some of the variables that we would like, e.g.,
> > name constraints. So, I think that an application is over stepping
the
> > bounds of the standard if it initializes variables for which the
> > standards make no such provision.
> >
> >
> > >It is not up
> > >to any standard to say that it can't. This is then of course no
> longer
> > >basic RFC 3280 validation, but some form of augmented RFC 3280 path
> > >validation (I.e RFC 3280 path validation + some locally defined
> > >additional constraints).
> >
> > i.e., it's non-standard :-)
> >
> > >The only interoperability issue at hand is to make sure that all
> > >applications 1) who choose just basic RFC 3280 path validation use
> the
> > >same rules and optionally 2) that those who choose to honour TA
> > >extensions may do so in a uniform manner thanks to clearly defined
> > >rules.
> >
> > well, I'm generally opposed to having a CA issue a self-signed cert
> > that is used as a TA, given that the TA parameters should be
> > controlled by an RP, not the CA. BUT, the reality is that many folks
> > DO take such certs and use them as TAs, then the problem with your
> > suggestion is that the same cert use as a TA by different RPs will
> > have different effects, which is not what the CA would anticipate
> > under the standard path validation algorithm. So, if what you said
was
> > that the USER could augment the path validation algorithm by
> > initializing parameter values that the standards don't allow, I'd be
> > sympathetic since the intent is to allow the user, as an RP, to do
> > what he should be able to do. But, you refer to an application doing
> > this, not a user, and for that I am less sympathetic, because it
> > sounds like a vendor of an application making a decision for
everyone,
> > and that is not in the spirit of allowing the RPs to exercise
control
> > over the validation process.
> >
> > So, which do you mean?
> >
> > Steve
> 
> 

Date: Fri, 3 Sep 2004 12:51:09 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Cc: "Peter Hesse" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "Steve Hanna" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 9:55 PM +0100 9/2/04, Stefan Santesson wrote:
>Steve,
>
>I've learned that in discussions like this you have to make small steps
>and agree on the fundamental basics before you can dig into details.
>
>So I just try to establish the simple truth that RP's have the right to
>deny trust in any certificate for any reason. And I mean literally ANY
>reason. No exception what so ever.

First, the term "trust" is one I try to avoid, so we're off to a bad 
start. If what you mean to say is that an RP can choose to reject any 
cert for arbitrary reasons, I agree. We're talking about a person, 
and people make value judgements for arbitrary reasons, so this makes 
sense.  Unfortunately, people can't perform cert path validation 
without the assistance of software. One of our jobs as standards 
developers is to provide a uniform means of performing path 
validation so that users can configure the process to get predictable 
results irrespective of the vendor of the path processing software. A 
problem arises when we try to satisfy the notion of rejecting certs 
for arbitrary reasons and the notion of automated path processing, 
presumably with a reasonable level of user control.

What I hear you saying above is that a vendor is free to "augment" 
path processing to enable a user to cause the algorithm to reject any 
cert for any reason. That seems very broad, and probably not viable. 
After all, "any reason"  is so vague that it seems unlikely that we 
can provide an algorithm or an API that will accommodate it. Instead, 
what I sense is a desire to justify a vendor's parochial choice of 
what ways a user can specify some (not any) reasons for rejecting a 
cert, and that conflicts with the standards motivation I cited above.

So, I am not sure that we agree on the basics, given the way you have 
described them.

Steve

Date: Fri, 3 Sep 2004 10:30:39 -0400
To: David Engberg <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: On cross-certificates and pathLenConstraint
Cc: [email-masked]
Sender: [email-masked]

At 7:05 PM -0400 9/2/04, David Engberg wrote:
>Steve -
>
>Would you mind expanding on this thought a little?:
>
>>Well, I'm generally opposed to having a CA issue a self-signed cert
>>that is used as a TA, given that the TA parameters should be
>>controlled by an RP, not the CA.
>
>From a security standpoint, I can see how a Trust Anchor is really 
>just a Distinguished Name plus a public key.  A self-signed cert 
>seems like a harmless way to package these two into a single file.

harmless, yes, but also functionally limiting to whatever extent we 
use extensions from the TA to influence path validation.

>Some of the other fields in the self-signed cert file may even serve 
>as metadata annotations (e.g. validity.notAfter) which may be useful 
>to an RP.  Obviously, any adoption of these additional fields into 
>the RP's local policy is outside the bounds of RFC 3280.

which creates uncertainly for users on terms of what their software 
really does, if they rely on it to give a yea/nay decision re use of 
a cert. that's not a good situation.

>Do you have a preferred alternate representation for disseminating 
>TA information without using self-signed certs?

There are several "better" ways to represent TA info, some of which 
also help to disseminate it to end users. For example, in an 
enterprise context, the CA for the enterprise can act as the only TA 
for each user. It can issue cross certs to the other CAs that it 
wants to enable for path validation. The keys for these CAs may have 
been acquired from self-signed certs by the enterprise CA, but it can 
strip out the key and name and use only the parameters (extensions) 
from the self-signed cert that it wants, and it can insert other, 
appropriate extensions to effect appropriate path processing controls 
consistent with the enterprise policies.  This technique even avoids 
the need to change the specs to make use of extensions from TAs in 
path processing, since all of the cross certs that the enterprise CA 
issues are now processed as non-TAs.

An individual user can do the same thing, acting as his own, sole TA 
and issuing cross certs to all the CAs that he would have otherwise 
installed as TAs.

Steve

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Fri, 3 Sep 2004 15:28:34 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh.

Short in-line

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 3 september 2004 14:50
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> I would note two things.  They seem to be repeat of the themes from me
in
> this thread.
> 
> 1.  For interoperability reasons, it is not sufficient to reject paths
> considered bad by 3280.  Paths considered good by 3280 should also be
> accepted.
> 
[Stefan] Agreed. I never meant to say anything else.

> 2.  The key is the RP user to be able to set the path validation
engine
> initialization variables as opposed to the engine/API making that
> determination for the entire consumer/RP community.

[Stefan] Agreed. I never meant to say anything else. However the
decision may not be taken by the user, it could be taken by his
application, his manager, his It department or whatever.

> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Friday, September 03, 2004 4:05 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> Santosh,
> 
> That is not at all what I try to say.
> 
> First of all. If you have the ability to augment the standard
algorithm,
> does not mean that you necessarily don't have a default mode that you
can
> use for standard compliance testing.
> 
> Secondly, even if you run in some augmented mode, you can still make
tests
> to make sure that a bad path, actually is rejected (i.e. no valid
> augmentation allows a bad path to pass). Even in this mode you can
make
> many
> valid standards compliance claims.
> 
> Finally you are right about the tricky part to test compliance and
interop
> regarding variable initialization. This is because the algorithm
specified
> in RFC 3280 is one example of a compliant algorithm, and even if it
were
> THE
> algorithm, different implementations of it would still have different
APIs
> with different ways and methods to handle these variables.
> 
> Example.
> Implementation 1 has a certain way to initialize a variable in the API
> request and delivers a distinct result.
> 
> Implementation 2 does not provide any possibility to initialize this
> variable but does instead deliver a response that can be masked for
the
> proper mode of operation (=different variable settings).
> 
> As long as we don't standardize the APIs we will have hard time making
> these
> tests effectively.
> 
> I agree that it is a bit confusing that RFC 3280 define the ability to
> initialize some variables while it at the same time has a language
that
> opens for adding any other type of constraints to the process.
> 
> So I do believe that the only thing you can successfully test widely
is
> the
> default algorithm with default parameter settings, which is exactly
what
> NIST PKITS is doing.
> 
> /Stefan
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: den 3 september 2004 01:14
> > To: [email-masked]
> > Subject: RE: On cross-certificates and pathLenConstraint
> >
> >
> > Stefan:
> >
> > An advantage of what Steve Kent is saying is that the validation
> engine's
> > compliance to 3280 can be conformance tested for the current
standard
> as
> > well as for revised standard that contained features for the RP to
> > initialize the various state variables.
> >
> > If you use your argument, we can not make any standard compliance
> claims.
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On
> > Behalf Of Stephen Kent
> > Sent: Thursday, September 02, 2004 4:18 PM
> > To: Stefan Santesson
> > Cc: Peter Hesse; Santosh Chokhani; Steve Hanna; [email-masked]
> > Subject: RE: On cross-certificates and pathLenConstraint
> >
> >
> >
> > At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
> > >Applying local trust policies is not a matter of interoperability.
It
> > >is just a matter of local policy.
> > >
> > >An application may be configured, in accordance with local policy
to
> > >reject a certificate based on any reason it chooses.
> > >
> > >We are not arguing about how RFC 3280 path validation works. RFC
3280
> > >path validation ignores TA extensions. Period.
> > >
> > >But if an application chooses to accept any restrictions set in the
> TA
> > >certificate, it is entitled to do so at its own discretion.
> >
> > I was in agreement up to this point. The path validation process
> > divides has fixed aspects, and a user-settable aspects. In terms of
> > initialization, the standards (X.509 and RFC 3280) don't provide a
> > means to initialize some of the variables that we would like, e.g.,
> > name constraints. So, I think that an application is over stepping
the
> > bounds of the standard if it initializes variables for which the
> > standards make no such provision.
> >
> >
> > >It is not up
> > >to any standard to say that it can't. This is then of course no
> longer
> > >basic RFC 3280 validation, but some form of augmented RFC 3280 path
> > >validation (I.e RFC 3280 path validation + some locally defined
> > >additional constraints).
> >
> > i.e., it's non-standard :-)
> >
> > >The only interoperability issue at hand is to make sure that all
> > >applications 1) who choose just basic RFC 3280 path validation use
> the
> > >same rules and optionally 2) that those who choose to honour TA
> > >extensions may do so in a uniform manner thanks to clearly defined
> > >rules.
> >
> > well, I'm generally opposed to having a CA issue a self-signed cert
> > that is used as a TA, given that the TA parameters should be
> > controlled by an RP, not the CA. BUT, the reality is that many folks
> > DO take such certs and use them as TAs, then the problem with your
> > suggestion is that the same cert use as a TA by different RPs will
> > have different effects, which is not what the CA would anticipate
> > under the standard path validation algorithm. So, if what you said
was
> > that the USER could augment the path validation algorithm by
> > initializing parameter values that the standards don't allow, I'd be
> > sympathetic since the intent is to allow the user, as an RP, to do
> > what he should be able to do. But, you refer to an application doing
> > this, not a user, and for that I am less sympathetic, because it
> > sounds like a vendor of an application making a decision for
everyone,
> > and that is not in the spirit of allowing the RPs to exercise
control
> > over the validation process.
> >
> > So, which do you mean?
> >
> > Steve
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Fri, 3 Sep 2004 08:50:13 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

I would note two things.  They seem to be repeat of the themes from me in
this thread.

1.  For interoperability reasons, it is not sufficient to reject paths
considered bad by 3280.  Paths considered good by 3280 should also be
accepted.

2.  The key is the RP user to be able to set the path validation engine
initialization variables as opposed to the engine/API making that
determination for the entire consumer/RP community. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Friday, September 03, 2004 4:05 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santosh,

That is not at all what I try to say.

First of all. If you have the ability to augment the standard algorithm,
does not mean that you necessarily don't have a default mode that you can
use for standard compliance testing.

Secondly, even if you run in some augmented mode, you can still make tests
to make sure that a bad path, actually is rejected (i.e. no valid
augmentation allows a bad path to pass). Even in this mode you can make many
valid standards compliance claims.

Finally you are right about the tricky part to test compliance and interop
regarding variable initialization. This is because the algorithm specified
in RFC 3280 is one example of a compliant algorithm, and even if it were THE
algorithm, different implementations of it would still have different APIs
with different ways and methods to handle these variables. 

Example. 
Implementation 1 has a certain way to initialize a variable in the API
request and delivers a distinct result.

Implementation 2 does not provide any possibility to initialize this
variable but does instead deliver a response that can be masked for the
proper mode of operation (=different variable settings).

As long as we don't standardize the APIs we will have hard time making these
tests effectively.

I agree that it is a bit confusing that RFC 3280 define the ability to
initialize some variables while it at the same time has a language that
opens for adding any other type of constraints to the process.

So I do believe that the only thing you can successfully test widely is the
default algorithm with default parameter settings, which is exactly what
NIST PKITS is doing.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 3 september 2004 01:14
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> An advantage of what Steve Kent is saying is that the validation
engine's
> compliance to 3280 can be conformance tested for the current standard
as
> well as for revised standard that contained features for the RP to 
> initialize the various state variables.
> 
> If you use your argument, we can not make any standard compliance
claims.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stephen Kent
> Sent: Thursday, September 02, 2004 4:18 PM
> To: Stefan Santesson
> Cc: Peter Hesse; Santosh Chokhani; Steve Hanna; [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
> >Applying local trust policies is not a matter of interoperability. It 
> >is just a matter of local policy.
> >
> >An application may be configured, in accordance with local policy to 
> >reject a certificate based on any reason it chooses.
> >
> >We are not arguing about how RFC 3280 path validation works. RFC 3280 
> >path validation ignores TA extensions. Period.
> >
> >But if an application chooses to accept any restrictions set in the
TA
> >certificate, it is entitled to do so at its own discretion.
> 
> I was in agreement up to this point. The path validation process 
> divides has fixed aspects, and a user-settable aspects. In terms of 
> initialization, the standards (X.509 and RFC 3280) don't provide a 
> means to initialize some of the variables that we would like, e.g., 
> name constraints. So, I think that an application is over stepping the 
> bounds of the standard if it initializes variables for which the 
> standards make no such provision.
> 
> 
> >It is not up
> >to any standard to say that it can't. This is then of course no
longer
> >basic RFC 3280 validation, but some form of augmented RFC 3280 path 
> >validation (I.e RFC 3280 path validation + some locally defined 
> >additional constraints).
> 
> i.e., it's non-standard :-)
> 
> >The only interoperability issue at hand is to make sure that all 
> >applications 1) who choose just basic RFC 3280 path validation use
the
> >same rules and optionally 2) that those who choose to honour TA 
> >extensions may do so in a uniform manner thanks to clearly defined 
> >rules.
> 
> well, I'm generally opposed to having a CA issue a self-signed cert 
> that is used as a TA, given that the TA parameters should be 
> controlled by an RP, not the CA. BUT, the reality is that many folks 
> DO take such certs and use them as TAs, then the problem with your 
> suggestion is that the same cert use as a TA by different RPs will 
> have different effects, which is not what the CA would anticipate 
> under the standard path validation algorithm. So, if what you said was 
> that the USER could augment the path validation algorithm by 
> initializing parameter values that the standards don't allow, I'd be 
> sympathetic since the intent is to allow the user, as an RP, to do 
> what he should be able to do. But, you refer to an application doing 
> this, not a user, and for that I am less sympathetic, because it 
> sounds like a vendor of an application making a decision for everyone, 
> and that is not in the spirit of allowing the RPs to exercise control 
> over the validation process.
> 
> So, which do you mean?
> 
> Steve

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Fri, 3 Sep 2004 09:04:47 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

That is not at all what I try to say.

First of all. If you have the ability to augment the standard algorithm,
does not mean that you necessarily don't have a default mode that you
can use for standard compliance testing.

Secondly, even if you run in some augmented mode, you can still make
tests to make sure that a bad path, actually is rejected (i.e. no valid
augmentation allows a bad path to pass). Even in this mode you can make
many valid standards compliance claims.

Finally you are right about the tricky part to test compliance and
interop regarding variable initialization. This is because the algorithm
specified in RFC 3280 is one example of a compliant algorithm, and even
if it were THE algorithm, different implementations of it would still
have different APIs with different ways and methods to handle these
variables. 

Example. 
Implementation 1 has a certain way to initialize a variable in the API
request and delivers a distinct result.

Implementation 2 does not provide any possibility to initialize this
variable but does instead deliver a response that can be masked for the
proper mode of operation (=different variable settings).

As long as we don't standardize the APIs we will have hard time making
these tests effectively.

I agree that it is a bit confusing that RFC 3280 define the ability to
initialize some variables while it at the same time has a language that
opens for adding any other type of constraints to the process.

So I do believe that the only thing you can successfully test widely is
the default algorithm with default parameter settings, which is exactly
what NIST PKITS is doing.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 3 september 2004 01:14
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> An advantage of what Steve Kent is saying is that the validation
engine's
> compliance to 3280 can be conformance tested for the current standard
as
> well as for revised standard that contained features for the RP to
> initialize the various state variables.
> 
> If you use your argument, we can not make any standard compliance
claims.
> 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On
> Behalf Of Stephen Kent
> Sent: Thursday, September 02, 2004 4:18 PM
> To: Stefan Santesson
> Cc: Peter Hesse; Santosh Chokhani; Steve Hanna; [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
> >Applying local trust policies is not a matter of interoperability. It
> >is just a matter of local policy.
> >
> >An application may be configured, in accordance with local policy to
> >reject a certificate based on any reason it chooses.
> >
> >We are not arguing about how RFC 3280 path validation works. RFC 3280
> >path validation ignores TA extensions. Period.
> >
> >But if an application chooses to accept any restrictions set in the
TA
> >certificate, it is entitled to do so at its own discretion.
> 
> I was in agreement up to this point. The path validation process
> divides has fixed aspects, and a user-settable aspects. In terms of
> initialization, the standards (X.509 and RFC 3280) don't provide a
> means to initialize some of the variables that we would like, e.g.,
> name constraints. So, I think that an application is over stepping
> the bounds of the standard if it initializes variables for which the
> standards make no such provision.
> 
> 
> >It is not up
> >to any standard to say that it can't. This is then of course no
longer
> >basic RFC 3280 validation, but some form of augmented RFC 3280 path
> >validation (I.e RFC 3280 path validation + some locally defined
> >additional constraints).
> 
> i.e., it's non-standard :-)
> 
> >The only interoperability issue at hand is to make sure that all
> >applications 1) who choose just basic RFC 3280 path validation use
the
> >same rules and optionally 2) that those who choose to honour TA
> >extensions may do so in a uniform manner thanks to clearly defined
> >rules.
> 
> well, I'm generally opposed to having a CA issue a self-signed cert
> that is used as a TA, given that the TA parameters should be
> controlled by an RP, not the CA. BUT, the reality is that many folks
> DO take such certs and use them as TAs, then the problem with your
> suggestion is that the same cert use as a TA by different RPs will
> have different effects, which is not what the CA would anticipate
> under the standard path validation algorithm. So, if what you said
> was that the USER could augment the path validation algorithm by
> initializing parameter values that the standards don't allow, I'd be
> sympathetic since the intent is to allow the user, as an RP, to do
> what he should be able to do. But, you refer to an application doing
> this, not a user, and for that I am less sympathetic, because it
> sounds like a vendor of an application making a decision for
> everyone, and that is not in the spirit of allowing the RPs to
> exercise control over the validation process.
> 
> So, which do you mean?
> 
> Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Thu, 2 Sep 2004 19:13:58 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

An advantage of what Steve Kent is saying is that the validation engine's
compliance to 3280 can be conformance tested for the current standard as
well as for revised standard that contained features for the RP to
initialize the various state variables.

If you use your argument, we can not make any standard compliance claims.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Thursday, September 02, 2004 4:18 PM
To: Stefan Santesson
Cc: Peter Hesse; Santosh Chokhani; Steve Hanna; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
>Applying local trust policies is not a matter of interoperability. It 
>is just a matter of local policy.
>
>An application may be configured, in accordance with local policy to 
>reject a certificate based on any reason it chooses.
>
>We are not arguing about how RFC 3280 path validation works. RFC 3280 
>path validation ignores TA extensions. Period.
>
>But if an application chooses to accept any restrictions set in the TA 
>certificate, it is entitled to do so at its own discretion.

I was in agreement up to this point. The path validation process 
divides has fixed aspects, and a user-settable aspects. In terms of 
initialization, the standards (X.509 and RFC 3280) don't provide a 
means to initialize some of the variables that we would like, e.g., 
name constraints. So, I think that an application is over stepping 
the bounds of the standard if it initializes variables for which the 
standards make no such provision.

>It is not up
>to any standard to say that it can't. This is then of course no longer 
>basic RFC 3280 validation, but some form of augmented RFC 3280 path 
>validation (I.e RFC 3280 path validation + some locally defined 
>additional constraints).

i.e., it's non-standard :-)

>The only interoperability issue at hand is to make sure that all 
>applications 1) who choose just basic RFC 3280 path validation use the 
>same rules and optionally 2) that those who choose to honour TA 
>extensions may do so in a uniform manner thanks to clearly defined 
>rules.

well, I'm generally opposed to having a CA issue a self-signed cert 
that is used as a TA, given that the TA parameters should be 
controlled by an RP, not the CA. BUT, the reality is that many folks 
DO take such certs and use them as TAs, then the problem with your 
suggestion is that the same cert use as a TA by different RPs will 
have different effects, which is not what the CA would anticipate 
under the standard path validation algorithm. So, if what you said 
was that the USER could augment the path validation algorithm by 
initializing parameter values that the standards don't allow, I'd be 
sympathetic since the intent is to allow the user, as an RP, to do 
what he should be able to do. But, you refer to an application doing 
this, not a user, and for that I am less sympathetic, because it 
sounds like a vendor of an application making a decision for 
everyone, and that is not in the spirit of allowing the RPs to 
exercise control over the validation process.

So, which do you mean?

Steve

Date: Thu, 02 Sep 2004 19:05:35 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: On cross-certificates and pathLenConstraint
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090107080104050608070201
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Steve -

Would you mind expanding on this thought a little?:

> Well, I'm generally opposed to having a CA issue a self-signed cert
> that is used as a TA, given that the TA parameters should be
> controlled by an RP, not the CA.

 From a security standpoint, I can see how a Trust Anchor is really just 
a Distinguished Name plus a public key.  A self-signed cert seems like a 
harmless way to package these two into a single file.

Some of the other fields in the self-signed cert file may even serve as 
metadata annotations (e.g. validity.notAfter) which may be useful to an 
RP.  Obviously, any adoption of these additional fields into the RP's 
local policy is outside the bounds of RFC 3280.

Do you have a preferred alternate representation for disseminating TA 
information without using self-signed certs?

Thanks

--------------ms090107080104050608070201
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090107080104050608070201--

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Thu, 2 Sep 2004 21:55:10 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: "Peter Hesse" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "Steve Hanna" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Steve,

I've learned that in discussions like this you have to make small steps
and agree on the fundamental basics before you can dig into details.

So I just try to establish the simple truth that RP's have the right to
deny trust in any certificate for any reason. And I mean literally ANY
reason. No exception what so ever.

The right to augment path validation for this purpose is also clearly
supported by RFC 3280. No limitation to this right is indicated or
suggested.

I have not gone into the technical details yet but I can say so much
that I can see many ways to do obtain this RESULT without "injecting"
variables into the RFC 3280 path validation algorithm. Especially since
this algorithm anyway only serves as an example algorithm (any other
algorithm is equally allowed as long as it produces the same result).

If we can agree on this basic fundamental, then I'm more than willing to
take this to the next level and discuss different ways to realize this
technically and in what ways augmentation options can be controlled and
managed and finally the most important aspect, what support we need from
standards.

Can we agree on these basics?

/Stefan

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: den 2 september 2004 22:18
> To: Stefan Santesson
> Cc: Peter Hesse; Santosh Chokhani; Steve Hanna; [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
> >Applying local trust policies is not a matter of interoperability. It
is
> >just a matter of local policy.
> >
> >An application may be configured, in accordance with local policy to
> >reject a certificate based on any reason it chooses.
> >
> >We are not arguing about how RFC 3280 path validation works. RFC 3280
> >path validation ignores TA extensions. Period.
> >
> >But if an application chooses to accept any restrictions set in the
TA
> >certificate, it is entitled to do so at its own discretion.
> 
> I was in agreement up to this point. The path validation process
> divides has fixed aspects, and a user-settable aspects. In terms of
> initialization, the standards (X.509 and RFC 3280) don't provide a
> means to initialize some of the variables that we would like, e.g.,
> name constraints. So, I think that an application is over stepping
> the bounds of the standard if it initializes variables for which the
> standards make no such provision.
> 
> 
> >It is not up
> >to any standard to say that it can't. This is then of course no
longer
> >basic RFC 3280 validation, but some form of augmented RFC 3280 path
> >validation (I.e RFC 3280 path validation + some locally defined
> >additional constraints).
> 
> i.e., it's non-standard :-)
> 
> >The only interoperability issue at hand is to make sure that all
> >applications 1) who choose just basic RFC 3280 path validation use
the
> >same rules and optionally 2) that those who choose to honour TA
> >extensions may do so in a uniform manner thanks to clearly defined
> >rules.
> 
> well, I'm generally opposed to having a CA issue a self-signed cert
> that is used as a TA, given that the TA parameters should be
> controlled by an RP, not the CA. BUT, the reality is that many folks
> DO take such certs and use them as TAs, then the problem with your
> suggestion is that the same cert use as a TA by different RPs will
> have different effects, which is not what the CA would anticipate
> under the standard path validation algorithm. So, if what you said
> was that the USER could augment the path validation algorithm by
> initializing parameter values that the standards don't allow, I'd be
> sympathetic since the intent is to allow the user, as an RP, to do
> what he should be able to do. But, you refer to an application doing
> this, not a user, and for that I am less sympathetic, because it
> sounds like a vendor of an application making a decision for
> everyone, and that is not in the spirit of allowing the RPs to
> exercise control over the validation process.
> 
> So, which do you mean?
> 
> Steve

Date: Thu, 2 Sep 2004 16:17:41 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Cc: "Peter Hesse" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "Steve Hanna" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
>Applying local trust policies is not a matter of interoperability. It is
>just a matter of local policy.
>
>An application may be configured, in accordance with local policy to
>reject a certificate based on any reason it chooses.
>
>We are not arguing about how RFC 3280 path validation works. RFC 3280
>path validation ignores TA extensions. Period.
>
>But if an application chooses to accept any restrictions set in the TA
>certificate, it is entitled to do so at its own discretion.

I was in agreement up to this point. The path validation process 
divides has fixed aspects, and a user-settable aspects. In terms of 
initialization, the standards (X.509 and RFC 3280) don't provide a 
means to initialize some of the variables that we would like, e.g., 
name constraints. So, I think that an application is over stepping 
the bounds of the standard if it initializes variables for which the 
standards make no such provision.

>It is not up
>to any standard to say that it can't. This is then of course no longer
>basic RFC 3280 validation, but some form of augmented RFC 3280 path
>validation (I.e RFC 3280 path validation + some locally defined
>additional constraints).

i.e., it's non-standard :-)

>The only interoperability issue at hand is to make sure that all
>applications 1) who choose just basic RFC 3280 path validation use the
>same rules and optionally 2) that those who choose to honour TA
>extensions may do so in a uniform manner thanks to clearly defined
>rules.

well, I'm generally opposed to having a CA issue a self-signed cert 
that is used as a TA, given that the TA parameters should be 
controlled by an RP, not the CA. BUT, the reality is that many folks 
DO take such certs and use them as TAs, then the problem with your 
suggestion is that the same cert use as a TA by different RPs will 
have different effects, which is not what the CA would anticipate 
under the standard path validation algorithm. So, if what you said 
was that the USER could augment the path validation algorithm by 
initializing parameter values that the standards don't allow, I'd be 
sympathetic since the intent is to allow the user, as an RP, to do 
what he should be able to do. But, you refer to an application doing 
this, not a user, and for that I am less sympathetic, because it 
sounds like a vendor of an application making a decision for 
everyone, and that is not in the spirit of allowing the RPs to 
exercise control over the validation process.

So, which do you mean?

Steve

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Thu, 2 Sep 2004 11:03:51 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Agreed, except the fact that NIST PKITS tests doesn't have any test
cases that detects this since it doesn't provide any Root certificates
with constraints :(

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 2 september 2004 04:48
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> I am ok with it as long as long as if a product or toolkit or API that
> claims 3280 compliance, provides an interface to the path validation
> engine
> to test compliance with 3280 and it passes the NIST PKITS tests.
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Wednesday, September 01, 2004 8:40 PM
> To: Peter Hesse; Santosh Chokhani; Steve Hanna
> Cc: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Applying local trust policies is not a matter of interoperability. It
is
> just a matter of local policy.
> 
> An application may be configured, in accordance with local policy to
> reject
> a certificate based on any reason it chooses.
> 
> We are not arguing about how RFC 3280 path validation works. RFC 3280
path
> validation ignores TA extensions. Period.
> 
> But if an application chooses to accept any restrictions set in the TA
> certificate, it is entitled to do so at its own discretion. It is not
up
> to
> any standard to say that it can't. This is then of course no longer
basic
> RFC 3280 validation, but some form of augmented RFC 3280 path
validation
> (I.e RFC 3280 path validation + some locally defined additional
> constraints).
> 
> The only interoperability issue at hand is to make sure that all
> applications 1) who choose just basic RFC 3280 path validation use the
> same
> rules and optionally 2) that those who choose to honour TA extensions
may
> do
> so in a uniform manner thanks to clearly defined rules.
> 
> Note this mail is not a proposal to start working on 2).
> 
> /Stefan
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Peter Hesse
> > Sent: den 1 september 2004 21:06
> > To: 'Santosh Chokhani'; Stefan Santesson; 'Steve Hanna'
> > Cc: [email-masked]
> > Subject: RE: On cross-certificates and pathLenConstraint
> >
> >
> > I agree wholeheartedly with Santosh.  Interoperability is what will
be
> > adversely affected if people use trust anchors to initialize path
> > processing in different ways.  We should have a standard which
clearly
> > defines
> how
> > this
> > mechanism should take place.
> >
> > IMHO, CA vendors should be able to produce a self-signed certificate
> with
> > no
> > (or few) extensions for basic interoperability, and one or more
> additional
> > self-signed certificates containing initialization parameters for
> > applications which can make use of them.  Likewise with certificate
> > validation systems--they should be able to import a self-signed
> > certificate as just a trust root (name and public key only) as well
as
> > an path validation initialization object (looking at things like
> > initial name constraints).
> >
> > --Peter
> >
> > +---------------------------------------------------------------+
> > | Peter Hesse                    [email-masked]     |
> > | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> > | ICQ: 1942828                     www.geminisecurity.com       |
> > +---------------------------------------------------------------+
> > "Pay no attention to what the critics say; there has never been a
> > statue set up in honor of a critic." --Jean Sibelius
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Santosh
Chokhani
> > > Sent: Wednesday, September 01, 2004 2:16 PM
> > > To: 'Stefan Santesson'; 'Steve Hanna'
> > > Cc: [email-masked]
> > > Subject: RE: On cross-certificates and pathLenConstraint
> > >
> > >
> > > Stefan and Steve Hanna:
> > >
> > > Section 6.1 also states the following:
> > >
> > > "This section describes an algorithm for validating certification
> > >    paths.  Conforming implementations of this specification are
not
> > >    required to implement this algorithm, but MUST provide
> > > functionality
> > >    equivalent to the external behavior resulting from this
> procedure.
> > >    Any algorithm may be used by a particular implementation so
long
> as
> > >    it derives the correct result."
> > >
> > > While I agree that we could take the values from trust anchor to
> > > initialize the certification path validation, that is not what the
> > > standard permits.
> > >
> > > As to your statement on Section 6.2, the language you cite and the
> > > examples imply items that either not integral to certification
path
> > > validation or are to process application specific extensions.  The
> > > name constraints example is states "apply name constraints to a
> > > specific trust anchor during
> > >    the initialization phase".  This can mean is the trust anchor
> > > appropriate for the name space.  Similarly, the subject alt name
in
> > > the end certificate is a pre or post path validation example.
> > >
> > > I am also concerned about your interpretation since it has
negative
> > > implications for interoperability.
> > >
> > > Having said that, I am not averse to a change in the standard that
> > > clearly defines what values can be initialized.
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Stefan
Santesson
> > > Sent: Tuesday, August 31, 2004 7:52 PM
> > > To: Steve Hanna; Santosh Chokhani
> > > Cc: [email-masked]
> > > Subject: RE: R: On cross-certificates and pathLenConstraint
> > >
> > >
> > >
> > > Thanks Steve for jumping in on this.
> > >
> > > We completely agree on the facts of RFC 3280 path processing and I
> > > think you showed this very well with support from the standard
text.
> > >
> > > We happen to disagree on the good or bad with processing root
> > > extensions but I think we should save that to later :-)
> > >
> > > Stefan Santesson
> > > Microsoft Security Center of Excellence (SCOE)
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > > On Behalf Of Steve Hanna
> > > > Sent: den 31 augusti 2004 22:05
> > > > To: Santosh Chokhani
> > > > Cc: [email-masked]
> > > > Subject: Re: R: On cross-certificates and pathLenConstraint
> > > >
> > > >
> > > > RFC 3280 says in section 6.1:
> > > >
> > > >     A particular certification path may not, however, be
> appropriate
> > > for
> > > >     all applications.  Therefore, an application MAY augment
this
> > > >     algorithm to further limit the set of valid paths.
> > > >
> > > > and in section 6.2:
> > > >
> > > >     An implementation that supports multiple trust anchors
> > > >     MAY augment the algorithm presented in section 6.1 to
further
> > > limit
> > > >     the set of valid certification paths which begin with a
> > > particular
> > > >     trust anchor.  For example, an implementation MAY modify the
> > > >     algorithm to apply name constraints to a specific trust
anchor
> > > during
> > > >     the initialization phase, or the application MAY require the
> > > presence
> > > >     of a particular alternative name form in the end entity
> > > certificate,
> > > >     or the application MAY impose requirements on
> > > application-specific
> > > >     extensions.  Thus, the path validation algorithm presented
in
> > > section
> > > >     6.1 defines the minimum conditions for a path to be
considered
> > > valid.
> > > >
> > > > Therefore, I believe that path validation implementations can go
> > > > beyond the usual path validation algorithm to impose any
> additional
> > > > requirements on paths that it likes (unless specifically
> > > prohibited by
> > > > RFC 3280). This would include processing name constraints in
trust
> > > > anchors, pathLenConstraints in trust anchors, etc.
> > > >
> > > > However, CAs who expect to act as trust anchors and issue
> > > self-signed
> > > > certificates for that purpose should not assume that all path
> > > > validation implementations will do this. If they REALLY
> > > want to ensure
> > > > that path lengths are limited, they should certify a
> > > subsidiary CA and
> > > > include a pathLen constraint in that certificate.
> > > >
> > > > Now, there's a separate question about whether processing
> > > constraints
> > > > in trust anchors is a good idea. I would argue that it's not.
But
> > > > that's a topic for another email.
> > > >
> > > > Thanks,
> > > >
> > > > Steve
> > > >
> > > > Santosh Chokhani wrote:
> > > >
> > > > > Steve Kent:
> > > > >
> > > > > We could take extensions in the TA and use them to initialize
a
> > > > > certification path values permitted by 3280, but for
> > > values such as
> > > path
> > > > > length that 3280 does not permit initialization of to an
> arbitrary
> > > > value, it
> > > > > will require a change in the standard.
> > > > >
> > > > > From security viewpoint, I do not object to it, but it is a
> change
> > > to
> > > > the
> > > > > standard.
> > > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > > On
> > > > > Behalf Of Stephen Kent
> > > > > Sent: Tuesday, August 31, 2004 9:51 AM
> > > > > To: Santoni Adriano
> > > > > Cc: [email-masked]
> > > > > Subject: Re: R: On cross-certificates and pathLenConstraint
> > > > >
> > > > >
> > > > >
> > > > > At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> > > > >
> > > > >>If I am getting you right, you are saying that the
> > > exensions in the
> > > > >>self-signed certificate of a trust anchor (root CA) should be
> > > > >>ignored. This is quite suprising to me!
> > > > >
> > > > >
> > > > > Unfortunately that is what X.509 has said for some time, and
> 3280
> > > has
> > > > > not deviated in this regard. I too was surprised by this
> > > initially.
> > > > >
> > > > > I discussed this issue with Sharon some time ago, noting
> > > that, for
> > > > > example, one would like to impose name constraints through
> > > > > configuration of trust anchors and the TA exception to
> > > the general
> > > > > processing rules prohibits that.  So I agree completely
> > > that I would
> > > > > like to see at least SOME of the constraints in a trust
> > > anchor cert
> > > > > be applied to cert path processing, although one needs to
> > > carefully
> > > > > examine the implications of doing this.
> > > > >
> > > > > BTW, Santosh is correct in noting that TAs are not
> > > literally certs,
> > > > > even though self-signed certs are often used as a means of
> > > > > representing TAs. However, since we admit that a TA can
contain
> > > > > parameters other than the TA name and key info, I think it is
> > > > > reasonable to allow for the full range of extensions that
might
> > > > > appear in a CA cert, and to then use them (most of them?)
> > > to control
> > > > > path processing.
> > > > >
> > > > > Steve
> > > > >
> > >
> > >
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 22:48:22 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

I am ok with it as long as long as if a product or toolkit or API that
claims 3280 compliance, provides an interface to the path validation engine
to test compliance with 3280 and it passes the NIST PKITS tests.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 01, 2004 8:40 PM
To: Peter Hesse; Santosh Chokhani; Steve Hanna
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Applying local trust policies is not a matter of interoperability. It is
just a matter of local policy.

An application may be configured, in accordance with local policy to reject
a certificate based on any reason it chooses.

We are not arguing about how RFC 3280 path validation works. RFC 3280 path
validation ignores TA extensions. Period.

But if an application chooses to accept any restrictions set in the TA
certificate, it is entitled to do so at its own discretion. It is not up to
any standard to say that it can't. This is then of course no longer basic
RFC 3280 validation, but some form of augmented RFC 3280 path validation
(I.e RFC 3280 path validation + some locally defined additional
constraints).

The only interoperability issue at hand is to make sure that all
applications 1) who choose just basic RFC 3280 path validation use the same
rules and optionally 2) that those who choose to honour TA extensions may do
so in a uniform manner thanks to clearly defined rules.

Note this mail is not a proposal to start working on 2). 

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Peter Hesse
> Sent: den 1 september 2004 21:06
> To: 'Santosh Chokhani'; Stefan Santesson; 'Steve Hanna'
> Cc: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> I agree wholeheartedly with Santosh.  Interoperability is what will be 
> adversely affected if people use trust anchors to initialize path 
> processing in different ways.  We should have a standard which clearly 
> defines
how
> this
> mechanism should take place.
> 
> IMHO, CA vendors should be able to produce a self-signed certificate
with
> no
> (or few) extensions for basic interoperability, and one or more
additional
> self-signed certificates containing initialization parameters for 
> applications which can make use of them.  Likewise with certificate 
> validation systems--they should be able to import a self-signed 
> certificate as just a trust root (name and public key only) as well as 
> an path validation initialization object (looking at things like 
> initial name constraints).
> 
> --Peter
> 
> +---------------------------------------------------------------+
> | Peter Hesse                    [email-masked]     |
> | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> | ICQ: 1942828                     www.geminisecurity.com       |
> +---------------------------------------------------------------+
> "Pay no attention to what the critics say; there has never been a 
> statue set up in honor of a critic." --Jean Sibelius
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> > Sent: Wednesday, September 01, 2004 2:16 PM
> > To: 'Stefan Santesson'; 'Steve Hanna'
> > Cc: [email-masked]
> > Subject: RE: On cross-certificates and pathLenConstraint
> >
> >
> > Stefan and Steve Hanna:
> >
> > Section 6.1 also states the following:
> >
> > "This section describes an algorithm for validating certification
> >    paths.  Conforming implementations of this specification are not
> >    required to implement this algorithm, but MUST provide 
> > functionality
> >    equivalent to the external behavior resulting from this
procedure.
> >    Any algorithm may be used by a particular implementation so long
as
> >    it derives the correct result."
> >
> > While I agree that we could take the values from trust anchor to 
> > initialize the certification path validation, that is not what the 
> > standard permits.
> >
> > As to your statement on Section 6.2, the language you cite and the 
> > examples imply items that either not integral to certification path 
> > validation or are to process application specific extensions.  The 
> > name constraints example is states "apply name constraints to a 
> > specific trust anchor during
> >    the initialization phase".  This can mean is the trust anchor 
> > appropriate for the name space.  Similarly, the subject alt name in 
> > the end certificate is a pre or post path validation example.
> >
> > I am also concerned about your interpretation since it has negative 
> > implications for interoperability.
> >
> > Having said that, I am not averse to a change in the standard that 
> > clearly defines what values can be initialized.
> >
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Stefan Santesson
> > Sent: Tuesday, August 31, 2004 7:52 PM
> > To: Steve Hanna; Santosh Chokhani
> > Cc: [email-masked]
> > Subject: RE: R: On cross-certificates and pathLenConstraint
> >
> >
> >
> > Thanks Steve for jumping in on this.
> >
> > We completely agree on the facts of RFC 3280 path processing and I 
> > think you showed this very well with support from the standard text.
> >
> > We happen to disagree on the good or bad with processing root 
> > extensions but I think we should save that to later :-)
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Steve Hanna
> > > Sent: den 31 augusti 2004 22:05
> > > To: Santosh Chokhani
> > > Cc: [email-masked]
> > > Subject: Re: R: On cross-certificates and pathLenConstraint
> > >
> > >
> > > RFC 3280 says in section 6.1:
> > >
> > >     A particular certification path may not, however, be
appropriate
> > for
> > >     all applications.  Therefore, an application MAY augment this
> > >     algorithm to further limit the set of valid paths.
> > >
> > > and in section 6.2:
> > >
> > >     An implementation that supports multiple trust anchors
> > >     MAY augment the algorithm presented in section 6.1 to further
> > limit
> > >     the set of valid certification paths which begin with a
> > particular
> > >     trust anchor.  For example, an implementation MAY modify the
> > >     algorithm to apply name constraints to a specific trust anchor
> > during
> > >     the initialization phase, or the application MAY require the
> > presence
> > >     of a particular alternative name form in the end entity
> > certificate,
> > >     or the application MAY impose requirements on
> > application-specific
> > >     extensions.  Thus, the path validation algorithm presented in
> > section
> > >     6.1 defines the minimum conditions for a path to be considered
> > valid.
> > >
> > > Therefore, I believe that path validation implementations can go 
> > > beyond the usual path validation algorithm to impose any
additional
> > > requirements on paths that it likes (unless specifically
> > prohibited by
> > > RFC 3280). This would include processing name constraints in trust 
> > > anchors, pathLenConstraints in trust anchors, etc.
> > >
> > > However, CAs who expect to act as trust anchors and issue
> > self-signed
> > > certificates for that purpose should not assume that all path 
> > > validation implementations will do this. If they REALLY
> > want to ensure
> > > that path lengths are limited, they should certify a
> > subsidiary CA and
> > > include a pathLen constraint in that certificate.
> > >
> > > Now, there's a separate question about whether processing
> > constraints
> > > in trust anchors is a good idea. I would argue that it's not. But 
> > > that's a topic for another email.
> > >
> > > Thanks,
> > >
> > > Steve
> > >
> > > Santosh Chokhani wrote:
> > >
> > > > Steve Kent:
> > > >
> > > > We could take extensions in the TA and use them to initialize a 
> > > > certification path values permitted by 3280, but for
> > values such as
> > path
> > > > length that 3280 does not permit initialization of to an
arbitrary
> > > value, it
> > > > will require a change in the standard.
> > > >
> > > > From security viewpoint, I do not object to it, but it is a
change
> > to
> > > the
> > > > standard.
> > > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On
> > > > Behalf Of Stephen Kent
> > > > Sent: Tuesday, August 31, 2004 9:51 AM
> > > > To: Santoni Adriano
> > > > Cc: [email-masked]
> > > > Subject: Re: R: On cross-certificates and pathLenConstraint
> > > >
> > > >
> > > >
> > > > At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> > > >
> > > >>If I am getting you right, you are saying that the
> > exensions in the
> > > >>self-signed certificate of a trust anchor (root CA) should be 
> > > >>ignored. This is quite suprising to me!
> > > >
> > > >
> > > > Unfortunately that is what X.509 has said for some time, and
3280
> > has
> > > > not deviated in this regard. I too was surprised by this
> > initially.
> > > >
> > > > I discussed this issue with Sharon some time ago, noting
> > that, for
> > > > example, one would like to impose name constraints through 
> > > > configuration of trust anchors and the TA exception to
> > the general
> > > > processing rules prohibits that.  So I agree completely
> > that I would
> > > > like to see at least SOME of the constraints in a trust
> > anchor cert
> > > > be applied to cert path processing, although one needs to
> > carefully
> > > > examine the implications of doing this.
> > > >
> > > > BTW, Santosh is correct in noting that TAs are not
> > literally certs,
> > > > even though self-signed certs are often used as a means of 
> > > > representing TAs. However, since we admit that a TA can contain 
> > > > parameters other than the TA name and key info, I think it is 
> > > > reasonable to allow for the full range of extensions that might 
> > > > appear in a CA cert, and to then use them (most of them?)
> > to control
> > > > path processing.
> > > >
> > > > Steve
> > > >
> >
> >

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Thu, 2 Sep 2004 01:39:38 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Peter Hesse" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, "Steve Hanna" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Applying local trust policies is not a matter of interoperability. It is
just a matter of local policy.

An application may be configured, in accordance with local policy to
reject a certificate based on any reason it chooses.

We are not arguing about how RFC 3280 path validation works. RFC 3280
path validation ignores TA extensions. Period.

But if an application chooses to accept any restrictions set in the TA
certificate, it is entitled to do so at its own discretion. It is not up
to any standard to say that it can't. This is then of course no longer
basic RFC 3280 validation, but some form of augmented RFC 3280 path
validation (I.e RFC 3280 path validation + some locally defined
additional constraints).

The only interoperability issue at hand is to make sure that all
applications 1) who choose just basic RFC 3280 path validation use the
same rules and optionally 2) that those who choose to honour TA
extensions may do so in a uniform manner thanks to clearly defined
rules.

Note this mail is not a proposal to start working on 2). 

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Peter Hesse
> Sent: den 1 september 2004 21:06
> To: 'Santosh Chokhani'; Stefan Santesson; 'Steve Hanna'
> Cc: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> I agree wholeheartedly with Santosh.  Interoperability is what will be
> adversely affected if people use trust anchors to initialize path
> processing
> in different ways.  We should have a standard which clearly defines
how
> this
> mechanism should take place.
> 
> IMHO, CA vendors should be able to produce a self-signed certificate
with
> no
> (or few) extensions for basic interoperability, and one or more
additional
> self-signed certificates containing initialization parameters for
> applications which can make use of them.  Likewise with certificate
> validation systems--they should be able to import a self-signed
> certificate
> as just a trust root (name and public key only) as well as an path
> validation initialization object (looking at things like initial name
> constraints).
> 
> --Peter
> 
> +---------------------------------------------------------------+
> | Peter Hesse                    [email-masked]     |
> | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> | ICQ: 1942828                     www.geminisecurity.com       |
> +---------------------------------------------------------------+
> "Pay no attention to what the critics say; there has never been
> a statue set up in honor of a critic." --Jean Sibelius
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> > Sent: Wednesday, September 01, 2004 2:16 PM
> > To: 'Stefan Santesson'; 'Steve Hanna'
> > Cc: [email-masked]
> > Subject: RE: On cross-certificates and pathLenConstraint
> >
> >
> > Stefan and Steve Hanna:
> >
> > Section 6.1 also states the following:
> >
> > "This section describes an algorithm for validating certification
> >    paths.  Conforming implementations of this specification are not
> >    required to implement this algorithm, but MUST provide
> > functionality
> >    equivalent to the external behavior resulting from this
procedure.
> >    Any algorithm may be used by a particular implementation so long
as
> >    it derives the correct result."
> >
> > While I agree that we could take the values from trust anchor
> > to initialize the certification path validation, that is not
> > what the standard permits.
> >
> > As to your statement on Section 6.2, the language you cite
> > and the examples imply items that either not integral to
> > certification path validation or are to process application
> > specific extensions.  The name constraints example is states
> > "apply name constraints to a specific trust anchor during
> >    the initialization phase".  This can mean is the trust
> > anchor appropriate for the name space.  Similarly, the
> > subject alt name in the end certificate is a pre or post path
> > validation example.
> >
> > I am also concerned about your interpretation since it has
> > negative implications for interoperability.
> >
> > Having said that, I am not averse to a change in the standard
> > that clearly defines what values can be initialized.
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stefan Santesson
> > Sent: Tuesday, August 31, 2004 7:52 PM
> > To: Steve Hanna; Santosh Chokhani
> > Cc: [email-masked]
> > Subject: RE: R: On cross-certificates and pathLenConstraint
> >
> >
> >
> > Thanks Steve for jumping in on this.
> >
> > We completely agree on the facts of RFC 3280 path processing
> > and I think you showed this very well with support from the
> > standard text.
> >
> > We happen to disagree on the good or bad with processing root
> > extensions but I think we should save that to later :-)
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Steve Hanna
> > > Sent: den 31 augusti 2004 22:05
> > > To: Santosh Chokhani
> > > Cc: [email-masked]
> > > Subject: Re: R: On cross-certificates and pathLenConstraint
> > >
> > >
> > > RFC 3280 says in section 6.1:
> > >
> > >     A particular certification path may not, however, be
appropriate
> > for
> > >     all applications.  Therefore, an application MAY augment this
> > >     algorithm to further limit the set of valid paths.
> > >
> > > and in section 6.2:
> > >
> > >     An implementation that supports multiple trust anchors
> > >     MAY augment the algorithm presented in section 6.1 to further
> > limit
> > >     the set of valid certification paths which begin with a
> > particular
> > >     trust anchor.  For example, an implementation MAY modify the
> > >     algorithm to apply name constraints to a specific trust anchor
> > during
> > >     the initialization phase, or the application MAY require the
> > presence
> > >     of a particular alternative name form in the end entity
> > certificate,
> > >     or the application MAY impose requirements on
> > application-specific
> > >     extensions.  Thus, the path validation algorithm presented in
> > section
> > >     6.1 defines the minimum conditions for a path to be considered
> > valid.
> > >
> > > Therefore, I believe that path validation implementations can go
> > > beyond the usual path validation algorithm to impose any
additional
> > > requirements on paths that it likes (unless specifically
> > prohibited by
> > > RFC 3280). This would include processing name constraints in trust
> > > anchors, pathLenConstraints in trust anchors, etc.
> > >
> > > However, CAs who expect to act as trust anchors and issue
> > self-signed
> > > certificates for that purpose should not assume that all path
> > > validation implementations will do this. If they REALLY
> > want to ensure
> > > that path lengths are limited, they should certify a
> > subsidiary CA and
> > > include a pathLen constraint in that certificate.
> > >
> > > Now, there's a separate question about whether processing
> > constraints
> > > in trust anchors is a good idea. I would argue that it's not. But
> > > that's a topic for another email.
> > >
> > > Thanks,
> > >
> > > Steve
> > >
> > > Santosh Chokhani wrote:
> > >
> > > > Steve Kent:
> > > >
> > > > We could take extensions in the TA and use them to initialize a
> > > > certification path values permitted by 3280, but for
> > values such as
> > path
> > > > length that 3280 does not permit initialization of to an
arbitrary
> > > value, it
> > > > will require a change in the standard.
> > > >
> > > > From security viewpoint, I do not object to it, but it is a
change
> > to
> > > the
> > > > standard.
> > > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On
> > > > Behalf Of Stephen Kent
> > > > Sent: Tuesday, August 31, 2004 9:51 AM
> > > > To: Santoni Adriano
> > > > Cc: [email-masked]
> > > > Subject: Re: R: On cross-certificates and pathLenConstraint
> > > >
> > > >
> > > >
> > > > At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> > > >
> > > >>If I am getting you right, you are saying that the
> > exensions in the
> > > >>self-signed certificate of a trust anchor (root CA) should be
> > > >>ignored. This is quite suprising to me!
> > > >
> > > >
> > > > Unfortunately that is what X.509 has said for some time, and
3280
> > has
> > > > not deviated in this regard. I too was surprised by this
> > initially.
> > > >
> > > > I discussed this issue with Sharon some time ago, noting
> > that, for
> > > > example, one would like to impose name constraints through
> > > > configuration of trust anchors and the TA exception to
> > the general
> > > > processing rules prohibits that.  So I agree completely
> > that I would
> > > > like to see at least SOME of the constraints in a trust
> > anchor cert
> > > > be applied to cert path processing, although one needs to
> > carefully
> > > > examine the implications of doing this.
> > > >
> > > > BTW, Santosh is correct in noting that TAs are not
> > literally certs,
> > > > even though self-signed certs are often used as a means of
> > > > representing TAs. However, since we admit that a TA can contain
> > > > parameters other than the TA name and key info, I think it is
> > > > reasonable to allow for the full range of extensions that might
> > > > appear in a CA cert, and to then use them (most of them?)
> > to control
> > > > path processing.
> > > >
> > > > Steve
> > > >
> >
> >

Date: Wed, 1 Sep 2004 16:50:26 -0400
To: <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: R: On cross-certificates and pathLenConstraint
Cc: <[email-masked]>
Sender: [email-masked]

At 5:33 PM +0100 9/1/04, Liaquat Khan wrote:
>OK I think we are in agreement on this point.  I just got a bit confused
>by your previous statement:
>
>"Unfortunately, the current specs do not allow us to do this, and that
>is a problem that needs to be fixed."
>
>I am not sure what you are referring to here exactly, which specs do you
>think are not adequate and need to be fixed?

X.509 and RFC 3280 make no provision for associating name constraints 
with a TA, for use in controlling path validation. In fact, the 
wording makes clear that if one uses a self-signed cert as the 
representation for a TA, extensions such as name constraints will be 
ignored in path validation.

That's what I was referring to in my prior message.

Steve

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'Jean-Marc Desperrier'" <[email-masked]>, <[email-masked]>
Subject: RE: Question - certificate status in past
Date: Wed, 1 Sep 2004 21:06:56 +0100
Importance: Normal
Sender: [email-masked]

Yes, exactly.

Regards,
LK

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Jean-Marc Desperrier
> Sent: 01 September 2004 18:53
> To: [email-masked]
> Subject: Re: Question - certificate status in past
> 
> 
> Liaquat Khan wrote:
> 
> > O ne could go a little further, as in the case of our PDF Signer
> > application, we embed the timestamp (RFC3161) and the signer's
> > certificate status information (CRLs or OCSP) at the time the user
> > signs the PDF document (actually shortly after signing).   Therefore
> > the information required to validate the signature in the future is
> > actually held within the document, i.e. independent proof of time of
> > signing and independent proof of signer's certificate status at time
> > of signing.
> >
> >     *From:* [email-masked]
> >     [mailto:[email-masked]] *On Behalf Of *Miguel
> Rodriguez
> >     *[....]*
> >
> >     I think that the best you can do within PKIX is to have a
> >     timestamp (RFC 3161) for your digital signature, preferably
right
> >     after the signature has been created. The the entity in charge
of
> >     validating the signature (some time in the future) will have to
> >     obtain revocation status for the signer's certificate (using
CRL,
> >     or OCSP).
> >
> A normalized format to do that has been defined by EU in ETSI TS 101
> 733, which content is also available in the informational RFC 3126.
> 

From: "Peter Hesse" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'Steve Hanna'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 15:05:51 -0400
Sender: [email-masked]

I agree wholeheartedly with Santosh.  Interoperability is what will be
adversely affected if people use trust anchors to initialize path processing
in different ways.  We should have a standard which clearly defines how this
mechanism should take place.  

IMHO, CA vendors should be able to produce a self-signed certificate with no
(or few) extensions for basic interoperability, and one or more additional
self-signed certificates containing initialization parameters for
applications which can make use of them.  Likewise with certificate
validation systems--they should be able to import a self-signed certificate
as just a trust root (name and public key only) as well as an path
validation initialization object (looking at things like initial name
constraints).

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Wednesday, September 01, 2004 2:16 PM
> To: 'Stefan Santesson'; 'Steve Hanna'
> Cc: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan and Steve Hanna:
> 
> Section 6.1 also states the following:
> 
> "This section describes an algorithm for validating certification
>    paths.  Conforming implementations of this specification are not
>    required to implement this algorithm, but MUST provide 
> functionality
>    equivalent to the external behavior resulting from this procedure.
>    Any algorithm may be used by a particular implementation so long as
>    it derives the correct result."
> 
> While I agree that we could take the values from trust anchor 
> to initialize the certification path validation, that is not 
> what the standard permits.
> 
> As to your statement on Section 6.2, the language you cite 
> and the examples imply items that either not integral to 
> certification path validation or are to process application 
> specific extensions.  The name constraints example is states 
> "apply name constraints to a specific trust anchor during
>    the initialization phase".  This can mean is the trust 
> anchor appropriate for the name space.  Similarly, the 
> subject alt name in the end certificate is a pre or post path 
> validation example.
> 
> I am also concerned about your interpretation since it has 
> negative implications for interoperability.
> 
> Having said that, I am not averse to a change in the standard 
> that clearly defines what values can be initialized.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 7:52 PM
> To: Steve Hanna; Santosh Chokhani
> Cc: [email-masked]
> Subject: RE: R: On cross-certificates and pathLenConstraint
> 
> 
> 
> Thanks Steve for jumping in on this.
> 
> We completely agree on the facts of RFC 3280 path processing 
> and I think you showed this very well with support from the 
> standard text.
> 
> We happen to disagree on the good or bad with processing root 
> extensions but I think we should save that to later :-)
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Steve Hanna
> > Sent: den 31 augusti 2004 22:05
> > To: Santosh Chokhani
> > Cc: [email-masked]
> > Subject: Re: R: On cross-certificates and pathLenConstraint
> > 
> > 
> > RFC 3280 says in section 6.1:
> > 
> >     A particular certification path may not, however, be appropriate
> for
> >     all applications.  Therefore, an application MAY augment this
> >     algorithm to further limit the set of valid paths.
> > 
> > and in section 6.2:
> > 
> >     An implementation that supports multiple trust anchors
> >     MAY augment the algorithm presented in section 6.1 to further
> limit
> >     the set of valid certification paths which begin with a 
> particular
> >     trust anchor.  For example, an implementation MAY modify the
> >     algorithm to apply name constraints to a specific trust anchor
> during
> >     the initialization phase, or the application MAY require the
> presence
> >     of a particular alternative name form in the end entity
> certificate,
> >     or the application MAY impose requirements on 
> application-specific
> >     extensions.  Thus, the path validation algorithm presented in
> section
> >     6.1 defines the minimum conditions for a path to be considered
> valid.
> > 
> > Therefore, I believe that path validation implementations can go 
> > beyond the usual path validation algorithm to impose any additional 
> > requirements on paths that it likes (unless specifically 
> prohibited by 
> > RFC 3280). This would include processing name constraints in trust 
> > anchors, pathLenConstraints in trust anchors, etc.
> > 
> > However, CAs who expect to act as trust anchors and issue 
> self-signed 
> > certificates for that purpose should not assume that all path 
> > validation implementations will do this. If they REALLY 
> want to ensure 
> > that path lengths are limited, they should certify a 
> subsidiary CA and 
> > include a pathLen constraint in that certificate.
> > 
> > Now, there's a separate question about whether processing 
> constraints 
> > in trust anchors is a good idea. I would argue that it's not. But 
> > that's a topic for another email.
> > 
> > Thanks,
> > 
> > Steve
> > 
> > Santosh Chokhani wrote:
> > 
> > > Steve Kent:
> > >
> > > We could take extensions in the TA and use them to initialize a 
> > > certification path values permitted by 3280, but for 
> values such as
> path
> > > length that 3280 does not permit initialization of to an arbitrary
> > value, it
> > > will require a change in the standard.
> > >
> > > From security viewpoint, I do not object to it, but it is a change
> to
> > the
> > > standard.
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> [mailto:[email-masked]]
> > On
> > > Behalf Of Stephen Kent
> > > Sent: Tuesday, August 31, 2004 9:51 AM
> > > To: Santoni Adriano
> > > Cc: [email-masked]
> > > Subject: Re: R: On cross-certificates and pathLenConstraint
> > >
> > >
> > >
> > > At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> > >
> > >>If I am getting you right, you are saying that the 
> exensions in the 
> > >>self-signed certificate of a trust anchor (root CA) should be 
> > >>ignored. This is quite suprising to me!
> > >
> > >
> > > Unfortunately that is what X.509 has said for some time, and 3280
> has
> > > not deviated in this regard. I too was surprised by this 
> initially.
> > >
> > > I discussed this issue with Sharon some time ago, noting 
> that, for 
> > > example, one would like to impose name constraints through 
> > > configuration of trust anchors and the TA exception to 
> the general 
> > > processing rules prohibits that.  So I agree completely 
> that I would 
> > > like to see at least SOME of the constraints in a trust 
> anchor cert 
> > > be applied to cert path processing, although one needs to 
> carefully 
> > > examine the implications of doing this.
> > >
> > > BTW, Santosh is correct in noting that TAs are not 
> literally certs, 
> > > even though self-signed certs are often used as a means of 
> > > representing TAs. However, since we admit that a TA can contain 
> > > parameters other than the TA name and key info, I think it is 
> > > reasonable to allow for the full range of extensions that might 
> > > appear in a CA cert, and to then use them (most of them?) 
> to control 
> > > path processing.
> > >
> > > Steve
> > >
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 14:19:26 -0400
Importance: Normal
Sender: [email-masked]

Tom:

If the product vendors and implementers do not object, I am all for change
and clarification in both X.509 and 3280 to be able to initialize the
various state variables for the path validation engine.

I would also suggest that the application could use the values in the trust
anchor certificate or define its own.  I would recommend that when the
application defines its own, they be more restrictive than those in the
trust anchor.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Wednesday, September 01, 2004 7:20 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

        Santosh:

        This has come up before, as I indicated in my last posting.  I ask 
for consensus to the effect that setting permitted_subtrees, 
excluded_subtrees, and max_path_length from configuration entries 
specifiable on a per-trust-anchor basis is a permissible "augmentation" of 
the RFC 3280 algorithm of the sort contemplated in the third and fourth 
sentences of RFC 3280 6.2.  In fact, the fourth sentence of that section 
explicitly suggests using name constraints in this way even though RFC 
3280 6.1.2 gives specific initial values for the "subtrees" parameters 
just as it does for max_path_length.  The initialization of 
max_path_length to "n" has no particular effect that would not be obtained 
by setting it to a large positive value instead.
        Obviously, packaging such a configuration entry within a v3 
certificate has no effect relevant to RFC 3280.  If the configuration 
entry is allowed, it may be derived from a certificate or may come from a 
file, at the RP's option.
        Although the argument above is based on the text of RFC 3280, I am 
not making it solely for that reason.  I believe that it is technically 
appropriate to implement such a feature as well.  In particular, an RP may 
have legitimate reasons to trust a departmental CA directly, and set 
max_path_length to 0; to trust a CA's EE certificates without trusting his 
cross certificates, also by setting max_path_length to 0; or to impose a 
naming space restriction on a directly trusted CA by setting 
permitted_subtrees.  I do not claim that I can compose plausible use cases 
for the entire breadth of these parameters.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
08/31/2004 12:19 PM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: On cross-certificates and pathLenConstraint

Stefan:

I think a trust anchor is not necessarily a certificate, let alone a CA
certificate.  Thus, 4.2.1.10 does not apply.  Also, as I have noted to
Sharon, you can not enforce the cA flag or initialize path length from the
root.  Thus, the use of this extension in the root is meaningless.

As to accepting constraints from the root, those that 3280 permits to be
initialized, is fine.  Path length is not one of them.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 11:32 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santosh,

You are right that you may provide trust information by means other than a
certificate, but if you form a root certificate according to RFC 3280, 
then
basic constraints MUST be present or the certificate is NOT RFC 3280
compliant.

RFC 3280 4.2.1.10
   This extension MUST appear as a critical extension in all CA
   certificates that contain public keys used to validate digital
   signatures on certificates.

Which is perfectly true also for roots.

Secondly, section 6.1 of RFC 3280 states:
   A particular certification path may not, however, be appropriate for
   all applications.  Therefore, an application MAY augment this
   algorithm to further limit the set of valid paths.

Accepting constraints configured in the applied root as input variables 
into
the path processing is therefore completely allowed by RFC 3280 path
processing as a way to augment the mandatory algorithm to further 
constrain
trust.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 31 augusti 2004 13:47
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> The standard does NOT require basic constraints to be in the root.
> 
> Also, when you enforce constraints on the trust anchor certificate, 
> that is not in compliance with the standard.
> 
> I agree that a more flexible standard would be one that honors 
> extensions in the root and also permits most of the values to be 
> initialized.  I know both X.509 and 3280 are moving towards the second 
> one.  The first one can become
> a backward compatibility issue.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 6:26 AM
> To: Santoni Adriano; Peter Hesse; David P. Kemp
> Cc: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> Santoni,
> 
> I just want to add/clarify that I agree that discarding all extensions 
> of root certificates in path processing is a bad design.
> 
> The result is as you conclude that Basic Constraints MUST be present 
> in roots but any present path length constraints, policy constraints, 
> explicit policies, name constraints etc, MAY be ignored.
> 
> However, as Sharon pointed out, it is not a violation of RFC 3280 to 
> honour any constraints set in the root certificate so MS CAPIs 
> decision to enforce ROOT extensions in this manner is not in conflict 
> with RFC 3280, but you can't rely on that other RFC 3280 compliant 
> implementations will do
this.
> They may legitimately ignore this data.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]
> > On Behalf Of Santoni Adriano
> > Sent: den 31 augusti 2004 09:26
> > To: Peter Hesse; David P. Kemp
> > Cc: [email-masked]
> > Subject: R: On cross-certificates and pathLenConstraint
> >
> >
> > If I am getting you right, you are saying that the exensions in the
> > self- signed certificate of a trust anchor (root CA) should be 
> > ignored. This is quite suprising to me!
> >
> > I thought it perfectly made sense to insert in a root CA certificate 
> > a basicConstraints with cA=TRUE and pathLenConstraint=0 (for
> > example) to signify that that CA only issues certificates to
> > end-users and not to subordinates. I am talking about the 
> > self-signed certificate used by an autonomous CA to distribute its 
> > own public key in a way that allows easy import into virtually all 
> > applications. [On the other hand, what CAs distribute their own 
> > public keys as a bare public keys? Virtually none.]
> >
> > It suddenly comes to my mind that perhaps the extensions in the root 
> > CA certificates contained in the Windows store were inserted for the 
> > sole purposes of accommodating MS CAPI idiosyncrasies (like 
> > mentioned by
> > Santesson) ...
> >
> > However, RFC 3280 says (§ 4.2.1.10  Basic Constraints):
> >              "...This extension MUST appear as a critical extension 
> > in
all
> CA
> > certificates
> >              that contain public keys used to validate digital
signatures on
> > certificates" ?
> >
> > (and the same hold for other extensions as well)
> >
> > It does not say "all CA certificates that are not trust anchors"; it 
> > says "all CA certificates".
> >
> > Is this statement not conflicting with your one?
> >
> > Adriano
> >
> >
> > -----Messaggio originale-----
> > Da: [email-masked] 
> > [mailto:[email-masked]]
> > Per conto di Peter Hesse
> > Inviato: lunedì 30 agosto 2004 18.43
> > A: 'David P. Kemp'; [email-masked]
> > Oggetto: RE: On cross-certificates and pathLenConstraint
> >
> >
> >
> > Section 6.1 of RFC 3280 states:
> >
> >    When the trust anchor is provided in the form of a self-signed
> >    certificate, this self-signed certificate is not included as part
of
> >    the prospective certification path.  Information about trust
anchors
> >    are provided as inputs to the certification path validation
algorithm
> >    (section 6.1.1).
> >
> > Thus I agree with Santosh that in no case should the extensions in a 
> > trust anchor's self-signed certificate affect the certification path 
> > validation.
> >
> > --Peter
> >
> > +---------------------------------------------------------------+
> > | Peter Hesse                    [email-masked]     |
> > | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> > | ICQ: 1942828                     www.geminisecurity.com       |
> > +---------------------------------------------------------------+
> > "Pay no attention to what the critics say; there has never been a 
> > statue set up in honor of a critic." --Jean Sibelius
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of David P. Kemp
> > > Sent: Monday, August 30, 2004 11:51 AM
> > > To: [email-masked]
> > > Subject: Re: On cross-certificates and pathLenConstraint
> > >
> > >
> > > Santosh,
> > >
> > > Is there ambiguity in the term trust anchor?  It seems possible to 
> > > regard the trust anchor as a bare public key or as a certificate.
> > >
> > > Because a self-signed certificate should appear only once at the 
> > > head of a path (and never elsewhere) the rule of "no extensions in 
> > > trust anchors" should apply only if "trust anchor" is defined to 
> > > be a public key that can be used to verify a certificate 
> > > (self-signed or otherwise).  It should not apply if the 
> > > self-signed certificate itself is defined to be the trust anchor.
> > >
> > > Perhaps X.509 and RFC 3280 should be clarified to state that there 
> > > is no such thing as a "self signed root".  There are roots (trust
> > > anchors) that are public keys only, and there are self signed
> > > certificates that may be validated by a root and whose extensions 
> > > are to be honored.
> > >
> > > Dave
> > >
> > >
> > > Santosh Chokhani wrote:
> > >
> > > >Stefan:
> > > >
> > > >I think extensions should be ignored in the trust anchor
> > > regardless of
> > > >their criticality
> > > >
> > > >For reasons such as MS CAPI, it is best to keep the trust anchors 
> > > >to bear minimum required.
> > > >
> > > >-----Original Message-----
> > > >From: Stefan Santesson [mailto:[email-masked]]
> > > >Sent: Saturday, August 28, 2004 5:10 AM
> > > >To: Santosh Chokhani; [email-masked]
> > > >Subject: RE: On cross-certificates and pathLenConstraint
> > > >
> > > >
> > > >The case when CA A is a self-signed root is different.
> > > >
> > > >If the Path Length constraint is present in the self signed root, 
> > > >it will be ignored by a X.509 and RFC 3280 compliant path
> > > validation implementation.
> > > >
> > > >However, there are implementations that honour Root
> > > extensions despite
> > > >this and would thus honour Path length constraints present in 
> > > >roots. E.g. I know that MS CAPI will.
> > > >
> > > >Despite that, I would say that it is wrong to rely on critical 
> > > >extensions in root certificates since they are ignored in
> > > RFC 3280 path validation.
> > > >
> > > >Stefan Santesson
> > > >Microsoft Security Center of Excellence (SCOE)
> > > >
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: [email-masked] 
> > > >>[mailto:[email-masked]]
> > > >>On Behalf Of Santosh Chokhani
> > > >>Sent: den 28 augusti 2004 00:52
> > > >>To: [email-masked]
> > > >>Subject: RE: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>Stefan has the right idea.
> > > >>
> > > >>If CA A is simply another CA, CA B certificate can be
> > > validated as an
> > > >>end (not intermediate certificate).
> > > >>
> > > >>If CA A is trust anchor, I think it can issue CA
> > > certificates.  I read
> > > >>both X.509 and 3280 to not enforce constraints in the trust 
> > > >>anchor.
> > > >>
> > > >>To complicate matters further, if the trust anchor issues itself 
> > > >>a self-issued certificate, I would think the pathLength in that 
> > > >>certificate should be honored.
> > > >>
> > > >>BTW, all this discussion of hierarchies and cross
> > > certificates should
> > > >>not be relevant.  Both X.509 and 3280 are (rightfully) trust 
> > > >>model agnostic.
> > > >>
> > > >>-----Original Message-----
> > > >>From: [email-masked] 
> > > >>[mailto:[email-masked]]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 9:28 AM
> > > >>To: Sharon Boeyen
> > > >>Cc: [email-masked]
> > > >>Subject: R: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>
> > > >>Sharon,
> > > >>
> > > >>you explained what happens when a cross-certificates contains a 
> > > >>pathLenConstraint=0, but I was referring to the
> > > pathLenConstraint in
> > > >>the trust-point certificate. Virtually all CA public keys are 
> > > >>distributed to end-users in the form of a self-signed 
> > > >>certificate which may (should) contain the BasicConstrains 
> > > >>extension. Some EU profiles actually mandate the BasicConstrains 
> > > >>to be present and critical.
> > > >>
> > > >>Using your example entities, my question can be re-phrased like
> > > >>follows: can CA A (my trust point) issue a cross-cert to CA
> > > B (e.g. a
> > > >>foreign one) if the self-issued certificate of CA A contains 
> > > >>pathLenConstraint=0 ?
> > > >>
> > > >>>From another viewpoint: setting pathLenConstraint=0 to prevent
> > > >>
> > > >>
> > > >>>hierarchical SubCAs does also hinder cross-certificates?
> > > >>>
> > > >>>
> > > >>Adriano
> > > >>
> > > >>-----Messaggio originale-----
> > > >>Da: Sharon Boeyen [mailto:[email-masked]]
> > > >>Inviato: venerdì 27 agosto 2004 14.34
> > > >>A: Santoni Adriano; [email-masked]
> > > >>Oggetto: RE: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>If you are talking about a non-hierarchical trust model, then 
> > > >>absolutely yes any CA can issue any cross-certificates they 
> > > >>wish. However, those cross-certificates will only be trusted if 
> > > >>paths are built to them that exclude the certificate that 
> > > >>contains the path length constraint.
> > > >>
> > > >>For example, take CA A, CA B, CA C and CA D
> > > >>
> > > >>CA A issues a cross certificate to CA B with a path length
> > > constraint
> > > >>of 0 CA B issues a cross certificate to CA C CA D issues a cross 
> > > >>certificate to CA B (no path length constraint)
> > > >>
> > > >>Assume that there are no other cross certs in the environment
> > > >>
> > > >>Users of CA A have no way to trust certificates issued by CA C 
> > > >>(because of the path length constraint)
> > > >>
> > > >>However, users of CA D are able to trust certificates
> > > issued by CA C
> > > >>because the cross-certificate from D to B contains no such
> > > constraint.
> > > >>
> > > >>As for your second question, yes there are implementations that 
> > > >>process paths including all the business controls. As for
> > > testing, I'd
> > > >>suggest you have a look at the PKITS test suite which tests
> > > all these
> > > >>features. http://csrc.nist.gov/pki/testing/x509paths.html
> > > >>
> > > >>Cheers,
> > > >>Sharon
> > > >>
> > > >>-----Original Message-----
> > > >>From: [email-masked] 
> > > >>[mailto:[email-masked]]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 5:37 AM
> > > >>To: [email-masked]
> > > >>Subject: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>
> > > >>Dear list,
> > > >>
> > > >>I have the following doubts regarding cross-certificates:
> > > >>
> > > >>can a CA with BasicConstraints.pathLenConstraint=0 issue a
> > > >>cross- certificate to another CA in a different domain?
> > > >>
> > > >>In case of a "cross-certificate" (so to speak) issued by
> > > the same CA
> > > >>for itself, to facilitate the CA key rollover, RFC 3280 seems to 
> > > >>to allow the cross-certificate issuance regardless of the 
> > > >>pathLenConstraint value, on the ground that in this case the 
> > > >>cross-certificate is "self-issued" and therefore, in a way, "out 
> > > >>of scope" as far as the pathLenConstraint is concerned.
> > > >>
> > > >>However, in the case of a "real" cross-certificate, to be issued 
> > > >>to another CA with a different name, it is not very clear to me 
> > > >>if the pathLenConstraint in CA1 affects the possibility of 
> > > >>issuing a cross-certificate to CA2.
> > > >>
> > > >>By the way, I wonder how are the most widespread
> > > applications handling
> > > >>certificate chains containing cross-certs, in the various
> > > cases (e.g.
> > > >>different values of pethLenConstraint down the chain); has 
> > > >>anybody done any testing to specifically investigate this area?
> > > >>
> > > >>Is anybody willing to shed some light and/or share informations?
> > > >>
> > > >>TIA,
> > > >>  Adriano
> > > >>
> > > >>
> > > >>*******************Internet Email Confidentiality
> > > >>Footer*******************
> > > >>
> > > >>
> > > >>Qualsiasi utilizzo non autorizzato del presente messaggio
> > > nonche dei
> > > >>suoi allegati e vietato e potrebbe costituire reato. Se ha 
> > > >>ricevuto per errore il presente messaggio, Le saremmo grati se 
> > > >>ci
> > > inviasse, via
> > > >>e-mail, una comunicazione al riguardo e provvedesse nel
> > > contempo alla
> > > >>distruzione del messaggio stesso e dei suoi eventuali allegati. 
> > > >>Le dichiarazioni contenute nel presente messaggio nonche' nei 
> > > >>suoi eventuali allegati devono essere attribuite esclusivamente
> > > al mittente
> > > >>e non possono essere considerate come trasmesse o autorizzate da 
> > > >>ACTALIS S.p.A.; le medesime dichiarazioni non impegnano
> > > ACTALIS S.p.A.
> > > >>nei confronti del destinatario o di terzi.
> > > >>ACTALIS S.p.A. non si assume alcuna responsabilita' per 
> > > >>eventuali intercettazioni, modifiche o danneggiamenti del 
> > > >>presente
> > > messaggio e-mail.
> > > >>
> > > >>
> > > >>
> > > >>Any unauthorized use of this e-mail or any of its attachments is 
> > > >>prohibited and could constitute an offence. If you are not the 
> > > >>intended addressee please advise immediately the sender by
> > > using the
> > > >>reply facility in your e-mail software and destroy the
> > > message and its
> > > >>attachments. The statements and opinions expressed in this 
> > > >>e-mail message are those of the author of the message and do not
> > > necessarily
> > > >>represent those of ACTALIS S.p.A. Besides, The contents of this 
> > > >>message shall be understood as neither given nor endorsed
> > > by ACTALIS
> > > >>S.p.A..
> > > >>ACTALIS S.p.A. does not accept liability for corruption,
> > > interception
> > > >>or amendment, if any, or the consequences thereof.
> > > >>
> > > >>
> > > >>*******************Internet Email Confidentiality
> > > >>Footer*******************
> > > >>
> > > >>
> > > >>Qualsiasi utilizzo non autorizzato del presente messaggio
> > > nonché dei
> > > >>suoi allegati è vietato e potrebbe costituire reato. Se ha 
> > > >>ricevuto per errore il presente messaggio, Le saremmo grati se 
> > > >>ci
> > > inviasse, via
> > > >>e-mail, una comunicazione al riguardo e provvedesse nel
> > > contempo alla
> > > >>distruzione del messaggio stesso e dei suoi eventuali allegati. 
> > > >>Le dichiarazioni contenute nel presente messaggio nonche' nei 
> > > >>suoi eventuali allegati devono essere attribuite esclusivamente
> > > al mittente
> > > >>e non possono essere considerate come trasmesse o autorizzate da 
> > > >>ACTALIS S.p.A.; le medesime dichiarazioni non impegnano
> > > ACTALIS S.p.A.
> > > >>nei confronti del destinatario o di terzi.
> > > >>ACTALIS S.p.A. non si assume alcuna responsabilita' per 
> > > >>eventuali intercettazioni, modifiche o danneggiamenti del 
> > > >>presente
> > > messaggio e-mail.
> > > >>
> > > >>
> > > >>
> > > >>Any unauthorized use of this e-mail or any of its attachments is 
> > > >>prohibited and could constitute an offence. If you are not the 
> > > >>intended addressee please advise immediately the sender by
> > > using the
> > > >>reply facility in your e-mail software and destroy the
> > > message and its
> > > >>attachments. The statements and opinions expressed in this 
> > > >>e-mail message are those of the author of the message and do not
> > > necessarily
> > > >>represent those of ACTALIS S.p.A. Besides, The contents of this 
> > > >>message shall be understood as neither given nor endorsed
> > > by ACTALIS
> > > >>S.p.A..
> > > >>ACTALIS S.p.A. does not accept liability for corruption,
> > > interception
> > > >>or amendment, if any, or the consequences thereof.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> > *******************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.
> >
> >
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "'Steve Hanna'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE:  On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 14:15:53 -0400
Importance: Normal
Sender: [email-masked]

Stefan and Steve Hanna:

Section 6.1 also states the following:

"This section describes an algorithm for validating certification
   paths.  Conforming implementations of this specification are not
   required to implement this algorithm, but MUST provide functionality
   equivalent to the external behavior resulting from this procedure.
   Any algorithm may be used by a particular implementation so long as
   it derives the correct result."

While I agree that we could take the values from trust anchor to initialize
the certification path validation, that is not what the standard permits.

As to your statement on Section 6.2, the language you cite and the examples
imply items that either not integral to certification path validation or are
to process application specific extensions.  The name constraints example is
states "apply name constraints to a specific trust anchor during
   the initialization phase".  This can mean is the trust anchor appropriate
for the name space.  Similarly, the subject alt name in the end certificate
is a pre or post path validation example.

I am also concerned about your interpretation since it has negative
implications for interoperability.

Having said that, I am not averse to a change in the standard that clearly
defines what values can be initialized.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 7:52 PM
To: Steve Hanna; Santosh Chokhani
Cc: [email-masked]
Subject: RE: R: On cross-certificates and pathLenConstraint

Thanks Steve for jumping in on this.

We completely agree on the facts of RFC 3280 path processing and I think you
showed this very well with support from the standard text.

We happen to disagree on the good or bad with processing root extensions but
I think we should save that to later :-)

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Steve Hanna
> Sent: den 31 augusti 2004 22:05
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: R: On cross-certificates and pathLenConstraint
> 
> 
> RFC 3280 says in section 6.1:
> 
>     A particular certification path may not, however, be appropriate
for
>     all applications.  Therefore, an application MAY augment this
>     algorithm to further limit the set of valid paths.
> 
> and in section 6.2:
> 
>     An implementation that supports multiple trust anchors
>     MAY augment the algorithm presented in section 6.1 to further
limit
>     the set of valid certification paths which begin with a particular
>     trust anchor.  For example, an implementation MAY modify the
>     algorithm to apply name constraints to a specific trust anchor
during
>     the initialization phase, or the application MAY require the
presence
>     of a particular alternative name form in the end entity
certificate,
>     or the application MAY impose requirements on application-specific
>     extensions.  Thus, the path validation algorithm presented in
section
>     6.1 defines the minimum conditions for a path to be considered
valid.
> 
> Therefore, I believe that path validation implementations
> can go beyond the usual path validation algorithm to impose any 
> additional requirements on paths that it likes (unless specifically 
> prohibited by RFC 3280). This would include processing name 
> constraints in trust anchors, pathLenConstraints in trust anchors, 
> etc.
> 
> However, CAs who expect to act as trust anchors and issue self-signed 
> certificates for that purpose should not assume that all path 
> validation implementations will do this. If they REALLY want to ensure 
> that path lengths are limited, they should certify a subsidiary CA and 
> include a pathLen constraint in that certificate.
> 
> Now, there's a separate question about whether processing constraints 
> in trust anchors is a good idea. I would argue that it's not. But 
> that's a topic for another email.
> 
> Thanks,
> 
> Steve
> 
> Santosh Chokhani wrote:
> 
> > Steve Kent:
> >
> > We could take extensions in the TA and use them to initialize a 
> > certification path values permitted by 3280, but for values such as
path
> > length that 3280 does not permit initialization of to an arbitrary
> value, it
> > will require a change in the standard.
> >
> > From security viewpoint, I do not object to it, but it is a change
to
> the
> > standard.
> >
> > -----Original Message-----
> > From: [email-masked]
[mailto:[email-masked]]
> On
> > Behalf Of Stephen Kent
> > Sent: Tuesday, August 31, 2004 9:51 AM
> > To: Santoni Adriano
> > Cc: [email-masked]
> > Subject: Re: R: On cross-certificates and pathLenConstraint
> >
> >
> >
> > At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> >
> >>If I am getting you right, you are saying that the exensions in the 
> >>self-signed certificate of a trust anchor (root CA) should be 
> >>ignored. This is quite suprising to me!
> >
> >
> > Unfortunately that is what X.509 has said for some time, and 3280
has
> > not deviated in this regard. I too was surprised by this initially.
> >
> > I discussed this issue with Sharon some time ago, noting that, for 
> > example, one would like to impose name constraints through 
> > configuration of trust anchors and the TA exception to the general 
> > processing rules prohibits that.  So I agree completely that I would 
> > like to see at least SOME of the constraints in a trust anchor cert 
> > be applied to cert path processing, although one needs to carefully 
> > examine the implications of doing this.
> >
> > BTW, Santosh is correct in noting that TAs are not literally certs, 
> > even though self-signed certs are often used as a means of 
> > representing TAs. However, since we admit that a TA can contain 
> > parameters other than the TA name and key info, I think it is 
> > reasonable to allow for the full range of extensions that might 
> > appear in a CA cert, and to then use them (most of them?) to control 
> > path processing.
> >
> > Steve
> >

Date: Wed, 01 Sep 2004 19:53:13 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Question - certificate status in past
Sender: [email-masked]

Liaquat Khan wrote:

> O ne could go a little further, as in the case of our PDF Signer 
> application, we embed the timestamp (RFC3161) and the signer's 
> certificate status information (CRLs or OCSP) at the time the user 
> signs the PDF document (actually shortly after signing).   Therefore 
> the information required to validate the signature in the future is 
> actually held within the document, i.e. independent proof of time of 
> signing and independent proof of signer's certificate status at time 
> of signing.  
>
>     *From:* [email-masked]
>     [mailto:[email-masked]] *On Behalf Of *Miguel Rodriguez
>     *[....]*
>       
>     I think that the best you can do within PKIX is to have a
>     timestamp (RFC 3161) for your digital signature, preferably right
>     after the signature has been created. The the entity in charge of
>     validating the signature (some time in the future) will have to
>     obtain revocation status for the signer's certificate (using CRL,
>     or OCSP).
>
A normalized format to do that has been defined by EU in ETSI TS 101 
733, which content is also available in the informational RFC 3126.

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'Miguel Rodriguez'" <[email-masked]>, <[email-masked]>
Subject: RE: Question - certificate status in past
Date: Wed, 1 Sep 2004 17:54:32 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00B2_01C4904C.BD5E3AC0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

One could go a little further, as in the case of our PDF Signer
application, we embed the timestamp (RFC3161) and the signer's
certificate status information (CRLs or OCSP) at the time the user signs
the PDF document (actually shortly after signing).   Therefore the
information required to validate the signature in the future is actually
held within the document, i.e. independent proof of time of signing and
independent proof of signer's certificate status at time of signing.  =20
=20
Regards,
LK  =20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Miguel Rodriguez
Sent: 01 September 2004 16:16
To: [email-masked]
Subject: RE: Question - certificate status in past

Hi Jaroslav,=20
=20
I think that the best you can do within PKIX is to have a timestamp (RFC
3161) for your digital signature, preferably right after the signature
has been created. The the entity in charge of validating the signature
(some time in the future) will have to obtain revocation status for the
signer's certificate (using CRL, or OCSP). In case the certificate has
been revoked, the validating entity will have to check if the revocation
happened after the issuing of the timestamp (checking the revocation
date against the timestamp's date). Time stamp server are required to
have a trusted source of time to avoid disputes. However CAs or OCSP
responders are allowed to use local "not trusted" clocks. Your point
raises important issues, I hope we can discuss it here.
=20
Regards,
=20
Miguel A Rodriguez
SeguriData
Mexico

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Pinkava Jaroslav
Sent: Wednesday, September 01, 2004 4:19 AM
To: [email-masked]
Subject: Question - certificate status in past

I couldn=B4t find answer to the following question. For CA services =
would
be useful service

giving answer to simple question.:

There is given a certificate, and moment of time (in the past). I want
know status of certificate

exactly in this time moment.

I have no implemented OCSP nor DVCS, but I want follow pkix
recomendation.

What is the simplest way?

=20

Thank You in Advance.

                      Jaroslav

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

Ing. Jaroslav Pinkava, CSc.,=20

Security Consultant

telefon: +420 541 558 281

mobil:  +420 604 222 854

fax:    +420 541 558 303

e-mail: [email-masked]

http://crypto-world.info/=20

=20

PVT  a.s.,=20

Veve=F8=ED 102=20

602 00, Brno

www.pvt.cz <file:///\\www.pvt.cz\>=20

=20

------=_NextPart_000_00B2_01C4904C.BD5E3AC0
Content-Type: text/html;
	charset="iso-8859-2"
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=3Diso-8859-2">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR>
<STYLE>@page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt =
70.85pt 70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.StylZprvyElektronickPoty17 {
	COLOR: windowtext; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DCS vLink=3Dpurple link=3Dblue>
<DIV><SPAN class=3D797323816-01092004><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D797323816-01092004><FONT face=3DArial color=3D#0000ff =
size=3D2>O</FONT></SPAN>ne=20
could go a little further, as&nbsp;in the case of our PDF Signer=20
application,&nbsp;we embed the timestamp (RFC3161) and the signer's =
certificate=20
status information (CRLs or OCSP)&nbsp;at&nbsp;the time the user signs=20
the&nbsp;PDF document (actually shortly after signing).&nbsp;&nbsp; =
Therefore=20
the information required to validate the signature in the future is =
actually=20
held within the document, i.e. independent proof of time of =
signing&nbsp;and=20
independent proof of signer's certificate status at time of =
signing.&nbsp;&nbsp;=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D797323816-01092004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D797323816-01092004><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D797323816-01092004><FONT face=3DArial color=3D#0000ff =

size=3D2>LK&nbsp;&nbsp; </FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Miguel Rodriguez<BR><B>Sent:</B> 01 September 2004=20
  16:16<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> RE: Question =
-=20
  certificate status in past<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D695010515-01092004>Hi=20
  Jaroslav, </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D695010515-01092004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D695010515-01092004>I=20
  think that the best you can do within PKIX is to have a timestamp (RFC =
3161)=20
  for your digital signature, preferably right after the signature has =
been=20
  created. The the entity in charge of validating the signature (some =
time in=20
  the future) will have to obtain revocation status&nbsp;for the =
signer's=20
  certificate (using CRL, or OCSP). In case the certificate has been =
revoked,=20
  the validating entity will have to check if the revocation happened =
after the=20
  issuing of the timestamp (checking the revocation date against the =
timestamp's=20
  date). Time stamp server are required to have a trusted source of time =
to=20
  avoid disputes. However CAs or OCSP responders are allowed to use =
local "not=20
  trusted" clocks. Your point raises important issues, I hope we can =
discuss it=20
  here.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D695010515-01092004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D695010515-01092004>Regards,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D695010515-01092004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D695010515-01092004>Miguel A Rodriguez</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D695010515-01092004>SeguriData</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D695010515-01092004>Mexico</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
    [email-masked] [mailto:[email-masked]] =
<B>On=20
    Behalf Of </B>Pinkava Jaroslav<BR><B>Sent:</B> Wednesday, September =
01, 2004=20
    4:19 AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Question =
-=20
    certificate status in past<BR><BR></FONT></DIV>
    <DIV class=3DSection1>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I couldn=B4t find =
answer to the=20
    following question. For CA services would be useful=20
service</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">giving answer to =
simple=20
    question.:</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">There is given a =
certificate,=20
    and moment of time (in the past). I want know status of=20
    certificate</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">exactly in this time=20
    moment.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I have no implemented =
OCSP nor=20
    DVCS, but I want follow pkix recomendation.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">What is the simplest=20
    way?</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">Thank You in=20
    Advance.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Jaroslav</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"></SPAN></FONT>&nbsp;</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"></SPAN></FONT>&nbsp;</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"></SPAN></FONT>&nbsp;</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"></SPAN></FONT>&nbsp;</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"></SPAN></FONT>&nbsp;</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"></SPAN></FONT>&nbsp;</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 style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
    size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">Ing. =
Jaroslav=20
    Pinkava, CSc., </SPAN></FONT></I></P>
    <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
    size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">Security =

    Consultant</SPAN></FONT></I></P>
    <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
    size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">telefon: =
+420 541=20
    558 281</SPAN></FONT></I></P>
    <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
    size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: =
italic">mobil:&nbsp; +420=20
    604 222 854</SPAN></FONT></I></P>
    <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
    size=3D1><SPAN=20
    style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">fax:&nbsp;&nbsp;&nbsp; =
+420 541=20
    558 303</SPAN></FONT></I></P>
    <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
    size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">e-mail:=20
    [email-masked]</SPAN></FONT></I></P>
    <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
    size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic"><A=20
    href=3D"http://crypto-world.info/">http://crypto-world.info/</A>=20
    </SPAN></FONT></I></P>
    <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><FONT face=3DArial =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
    size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: =
italic">PVT&nbsp; a.s.,=20
    </SPAN></FONT></I></P>
    <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
    size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: =
italic">Veve=F8=ED 102=20
    </SPAN></FONT></I></P>
    <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
    size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">602 00,=20
    Brno</SPAN></FONT></I></P>
    <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
    size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic"><A=20
    href=3D"file:///\\www.pvt.cz\">www.pvt.cz</A></SPAN></FONT></I></P>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: =
12pt"></SPAN></FONT>&nbsp;</P></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HT=
ML>

------=_NextPart_000_00B2_01C4904C.BD5E3AC0--

Content-class: urn:content-classes:message
Subject: RE: R: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 17:36:15 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I think you are absolutely right about that :-)

/Stefan

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: den 1 september 2004 17:31
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: RE: R: On cross-certificates and pathLenConstraint
> 
> At 3:44 PM +0100 9/1/04, Stefan Santesson wrote:
> >Steve,
> >
> >I agree to the legitimate need you express.
> >
> >To further expand on that you may also want to limit a TA to a
certain
> >usage, e.g. only to be used to validate code signing signatures.
> 
> agreed. although we may disagree about how to express that
> limitation, i.e., EKU vs. policy :-)
> 
> Steve

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: R: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 17:33:52 +0100
Importance: Normal
Sender: [email-masked]

OK I think we are in agreement on this point.  I just got a bit confused
by your previous statement: 

"Unfortunately, the current specs do not allow us to do this, and that
is a problem that needs to be fixed."

I am not sure what you are referring to here exactly, which specs do you
think are not adequate and need to be fixed?

Regards,
LK  

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: 01 September 2004 15:26
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: R: On cross-certificates and pathLenConstraint
> 
> 
> At 3:09 PM +0100 9/1/04, Liaquat Khan wrote:
> >I am not sure who actually imposed the model!
> 
> Netscape developed it, as part of SSl, then Microsoft copied it to 
> maintain compatibility with Netscape.
> 
> >   Although I agree being
> >able to associate such name constraints with TAs could be a useful 
> >feature.
> >
> >However, in my opinion this is a decision which is likely to 
> be made by 
> >the RP application, not the CA as such.
> 
> absolutely right. the RP should manage the TAs, but in the browser 
> case users are given only very crude management tools to do so.
> 
> >   For example, some RPs may wish
> >to accept the CompuDigi TA without any name constraints (i.e. any 
> >certificate issued under this TA is acceptable to these RPs), whilst 
> >other RPs may only use the TA to validate only CompuDigi corporate 
> >certs.
> 
> right.
> 
> >It may therefore be better to associate such name 
> constraints with a TA 
> >independently of the actual TA certificate (i.e. assuming 
> the TA is in 
> >form of a certificate).  This should also mean the current specs are 
> >sufficient.
> 
> We should remember that there is no such thing as a TA certificate! A 
> TA is a named entity, public key info, and associated parameters used 
> for path validation, usually introduced into an RP in an out of band 
> fashion. It is a convention that self-signed certs are used to 
> represent TAs in many implementations, but this is not a requirement 
> imposed by standards and, as you note, it leads to confusion because 
> it suggests that the CA is creating the TA parameters which should be 
> under control of the RP.
> 
> Steve
> 

Date: Wed, 01 Sep 2004 16:55:25 +0100
From: Stephen Henson <[email-masked]>
To: [email-masked]
Subject: Re: R: On cross-certificates and pathLenConstraint
Sender: [email-masked]

Stefan Santesson wrote:

> Steve,
> 
> I agree to the legitimate need you express. 
> 
> To further expand on that you may also want to limit a TA to a certain
> usage, e.g. only to be used to validate code signing signatures.
> 

I'd also agree. In the past policies was also mentioned as something
which should be included.

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

Date: Wed, 1 Sep 2004 11:30:45 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: R: On cross-certificates and pathLenConstraint
Cc: <[email-masked]>
Sender: [email-masked]

At 3:44 PM +0100 9/1/04, Stefan Santesson wrote:
>Steve,
>
>I agree to the legitimate need you express.
>
>To further expand on that you may also want to limit a TA to a certain
>usage, e.g. only to be used to validate code signing signatures.

agreed. although we may disagree about how to express that 
limitation, i.e., EKU vs. policy :-)

Steve

Date: Wed, 1 Sep 2004 10:25:56 -0400
To: <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: R: On cross-certificates and pathLenConstraint
Cc: <[email-masked]>
Sender: [email-masked]

At 3:09 PM +0100 9/1/04, Liaquat Khan wrote:
>I am not sure who actually imposed the model!

Netscape developed it, as part of SSl, then Microsoft copied it to 
maintain compatibility with Netscape.

>   Although I agree being
>able to associate such name constraints with TAs could be a useful
>feature. 
>
>However, in my opinion this is a decision which is likely to be made by
>the RP application, not the CA as such.

absolutely right. the RP should manage the TAs, but in the browser 
case users are given only very crude management tools to do so.

>   For example, some RPs may wish
>to accept the CompuDigi TA without any name constraints (i.e. any
>certificate issued under this TA is acceptable to these RPs), whilst
>other RPs may only use the TA to validate only CompuDigi corporate
>certs.

right.

>It may therefore be better to associate such name constraints with a TA
>independently of the actual TA certificate (i.e. assuming the TA is in
>form of a certificate).  This should also mean the current specs are
>sufficient.

We should remember that there is no such thing as a TA certificate! A 
TA is a named entity, public key info, and associated parameters used 
for path validation, usually introduced into an RP in an out of band 
fashion. It is a convention that self-signed certs are used to 
represent TAs in many implementations, but this is not a requirement 
imposed by standards and, as you note, it leads to confusion because 
it suggests that the CA is creating the TA parameters which should be 
under control of the RP.

Steve

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: RE: Question - certificate status in past
Date: Wed, 1 Sep 2004 10:16:18 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0016_01C4900C.C031C130
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Hi Jaroslav,=20
=20
I think that the best you can do within PKIX is to have a timestamp (RFC
3161) for your digital signature, preferably right after the signature
has been created. The the entity in charge of validating the signature
(some time in the future) will have to obtain revocation status for the
signer's certificate (using CRL, or OCSP). In case the certificate has
been revoked, the validating entity will have to check if the revocation
happened after the issuing of the timestamp (checking the revocation
date against the timestamp's date). Time stamp server are required to
have a trusted source of time to avoid disputes. However CAs or OCSP
responders are allowed to use local "not trusted" clocks. Your point
raises important issues, I hope we can discuss it here.
=20
Regards,
=20
Miguel A Rodriguez
SeguriData
Mexico

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Pinkava Jaroslav
Sent: Wednesday, September 01, 2004 4:19 AM
To: [email-masked]
Subject: Question - certificate status in past

I couldn=B4t find answer to the following question. For CA services =
would
be useful service

giving answer to simple question.:

There is given a certificate, and moment of time (in the past). I want
know status of certificate

exactly in this time moment.

I have no implemented OCSP nor DVCS, but I want follow pkix
recomendation.

What is the simplest way?

=20

Thank You in Advance.

                      Jaroslav

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

Ing. Jaroslav Pinkava, CSc.,=20

Security Consultant

telefon: +420 541 558 281

mobil:  +420 604 222 854

fax:    +420 541 558 303

e-mail: [email-masked]

http://crypto-world.info/=20

=20

PVT  a.s.,=20

Veve=F8=ED 102=20

602 00, Brno

www.pvt.cz <file:///\\www.pvt.cz\>=20

=20

------=_NextPart_000_0016_01C4900C.C031C130
Content-Type: text/html;
	charset="iso-8859-2"
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=3Diso-8859-2">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR>
<STYLE>@page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt =
70.85pt 70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.StylZprvyElektronickPoty17 {
	COLOR: windowtext; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DCS vLink=3Dpurple link=3Dblue>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D695010515-01092004>Hi=20
Jaroslav, </SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D695010515-01092004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D695010515-01092004>I=20
think that the best you can do within PKIX is to have a timestamp (RFC =
3161) for=20
your digital signature, preferably right after the signature has been =
created.=20
The the entity in charge of validating the signature (some time in the =
future)=20
will have to obtain revocation status&nbsp;for the signer's certificate =
(using=20
CRL, or OCSP). In case the certificate has been revoked, the validating =
entity=20
will have to check if the revocation happened after the issuing of the =
timestamp=20
(checking the revocation date against the timestamp's date). Time stamp =
server=20
are required to have a trusted source of time to avoid disputes. However =
CAs or=20
OCSP responders are allowed to use local "not trusted" clocks. Your =
point raises=20
important issues, I hope we can discuss it here.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D695010515-01092004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D695010515-01092004>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D695010515-01092004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D695010515-01092004>Miguel=20
A Rodriguez</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D695010515-01092004>SeguriData</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D695010515-01092004>Mexico</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Pinkava Jaroslav<BR><B>Sent:</B> Wednesday, September =
01, 2004=20
  4:19 AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Question -=20
  certificate status in past<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I couldn=B4t find answer =
to the=20
  following question. For CA services would be useful =
service</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">giving answer to simple=20
  question.:</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">There is given a =
certificate, and=20
  moment of time (in the past). I want know status of=20
  certificate</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">exactly in this time=20
  moment.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I have no implemented =
OCSP nor=20
  DVCS, but I want follow pkix recomendation.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">What is the simplest=20
  way?</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">Thank You in=20
  Advance.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Jaroslav</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"></SPAN></FONT>&nbsp;</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"></SPAN></FONT>&nbsp;</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"></SPAN></FONT>&nbsp;</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"></SPAN></FONT>&nbsp;</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"></SPAN></FONT>&nbsp;</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"></SPAN></FONT>&nbsp;</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 style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
  size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">Ing. =
Jaroslav Pinkava,=20
  CSc., </SPAN></FONT></I></P>
  <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
  size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">Security=20
  Consultant</SPAN></FONT></I></P>
  <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
  size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">telefon: =
+420 541 558=20
  281</SPAN></FONT></I></P>
  <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
  size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: =
italic">mobil:&nbsp; +420 604=20
  222 854</SPAN></FONT></I></P>
  <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
  size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: =
italic">fax:&nbsp;&nbsp;&nbsp;=20
  +420 541 558 303</SPAN></FONT></I></P>
  <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
  size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">e-mail:=20
  [email-masked]</SPAN></FONT></I></P>
  <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
  size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic"><A=20
  href=3D"http://crypto-world.info/">http://crypto-world.info/</A>=20
  </SPAN></FONT></I></P>
  <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><FONT face=3DArial =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
  size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">PVT&nbsp; =
a.s.,=20
  </SPAN></FONT></I></P>
  <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
  size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">Veve=F8=ED =
102=20
  </SPAN></FONT></I></P>
  <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
  size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic">602 00,=20
  Brno</SPAN></FONT></I></P>
  <P class=3DMsoNormal style=3D"LINE-HEIGHT: 12pt"><I><FONT =
face=3D"Times New Roman"=20
  size=3D1><SPAN style=3D"FONT-SIZE: 8pt; FONT-STYLE: italic"><A=20
  href=3D"file:///\\www.pvt.cz\">www.pvt.cz</A></SPAN></FONT></I></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: =
12pt"></SPAN></FONT>&nbsp;</P></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0016_01C4900C.C031C130--

From: Sharon Boeyen <[email-masked]>
To: "'Tom Gindin'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 10:56:09 -0400 
Sender: [email-masked]

Specifically on name constraints, I believe the reason this text please note
that the current X.509 work is adding the ability to configure those exact
variables in its path validation module. This is part of the ongoing
enhancement work that is now underway. I think (but my memory is not very
good) that the 3280 text was added around the same time we initiated the 509
work. 

While I do agree that enabling more of those path validation variables to be
configurable is a good thing, how a particular implementation actually
chooses to populate those variables needs to be left flexible. In some cases
populating them from corresponding values in a self signed cert makes sense,
but not in other cases. 

Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Wednesday, September 01, 2004 7:20 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

        Santosh:

        This has come up before, as I indicated in my last posting.  I ask 
for consensus to the effect that setting permitted_subtrees, 
excluded_subtrees, and max_path_length from configuration entries 
specifiable on a per-trust-anchor basis is a permissible "augmentation" of 
the RFC 3280 algorithm of the sort contemplated in the third and fourth 
sentences of RFC 3280 6.2.  In fact, the fourth sentence of that section 
explicitly suggests using name constraints in this way even though RFC 
3280 6.1.2 gives specific initial values for the "subtrees" parameters 
just as it does for max_path_length.  The initialization of 
max_path_length to "n" has no particular effect that would not be obtained 
by setting it to a large positive value instead.
        Obviously, packaging such a configuration entry within a v3 
certificate has no effect relevant to RFC 3280.  If the configuration 
entry is allowed, it may be derived from a certificate or may come from a 
file, at the RP's option.
        Although the argument above is based on the text of RFC 3280, I am 
not making it solely for that reason.  I believe that it is technically 
appropriate to implement such a feature as well.  In particular, an RP may 
have legitimate reasons to trust a departmental CA directly, and set 
max_path_length to 0; to trust a CA's EE certificates without trusting his 
cross certificates, also by setting max_path_length to 0; or to impose a 
naming space restriction on a directly trusted CA by setting 
permitted_subtrees.  I do not claim that I can compose plausible use cases 
for the entire breadth of these parameters.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
08/31/2004 12:19 PM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: On cross-certificates and pathLenConstraint

Stefan:

I think a trust anchor is not necessarily a certificate, let alone a CA
certificate.  Thus, 4.2.1.10 does not apply.  Also, as I have noted to
Sharon, you can not enforce the cA flag or initialize path length from the
root.  Thus, the use of this extension in the root is meaningless.

As to accepting constraints from the root, those that 3280 permits to be
initialized, is fine.  Path length is not one of them.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 11:32 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santosh,

You are right that you may provide trust information by means other than a
certificate, but if you form a root certificate according to RFC 3280, 
then
basic constraints MUST be present or the certificate is NOT RFC 3280
compliant.

RFC 3280 4.2.1.10
   This extension MUST appear as a critical extension in all CA
   certificates that contain public keys used to validate digital
   signatures on certificates.

Which is perfectly true also for roots.

Secondly, section 6.1 of RFC 3280 states:
   A particular certification path may not, however, be appropriate for
   all applications.  Therefore, an application MAY augment this
   algorithm to further limit the set of valid paths.

Accepting constraints configured in the applied root as input variables 
into
the path processing is therefore completely allowed by RFC 3280 path
processing as a way to augment the mandatory algorithm to further 
constrain
trust.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 31 augusti 2004 13:47
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> The standard does NOT require basic constraints to be in the root.
> 
> Also, when you enforce constraints on the trust anchor certificate, 
> that is not in compliance with the standard.
> 
> I agree that a more flexible standard would be one that honors 
> extensions in the root and also permits most of the values to be 
> initialized.  I know both X.509 and 3280 are moving towards the second 
> one.  The first one can become
> a backward compatibility issue.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 6:26 AM
> To: Santoni Adriano; Peter Hesse; David P. Kemp
> Cc: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> Santoni,
> 
> I just want to add/clarify that I agree that discarding all extensions 
> of root certificates in path processing is a bad design.
> 
> The result is as you conclude that Basic Constraints MUST be present 
> in roots but any present path length constraints, policy constraints, 
> explicit policies, name constraints etc, MAY be ignored.
> 
> However, as Sharon pointed out, it is not a violation of RFC 3280 to 
> honour any constraints set in the root certificate so MS CAPIs 
> decision to enforce ROOT extensions in this manner is not in conflict 
> with RFC 3280, but you can't rely on that other RFC 3280 compliant 
> implementations will do
this.
> They may legitimately ignore this data.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]
> > On Behalf Of Santoni Adriano
> > Sent: den 31 augusti 2004 09:26
> > To: Peter Hesse; David P. Kemp
> > Cc: [email-masked]
> > Subject: R: On cross-certificates and pathLenConstraint
> >
> >
> > If I am getting you right, you are saying that the exensions in the
> > self- signed certificate of a trust anchor (root CA) should be 
> > ignored. This is quite suprising to me!
> >
> > I thought it perfectly made sense to insert in a root CA certificate 
> > a basicConstraints with cA=TRUE and pathLenConstraint=0 (for
> > example) to signify that that CA only issues certificates to
> > end-users and not to subordinates. I am talking about the 
> > self-signed certificate used by an autonomous CA to distribute its 
> > own public key in a way that allows easy import into virtually all 
> > applications. [On the other hand, what CAs distribute their own 
> > public keys as a bare public keys? Virtually none.]
> >
> > It suddenly comes to my mind that perhaps the extensions in the root 
> > CA certificates contained in the Windows store were inserted for the 
> > sole purposes of accommodating MS CAPI idiosyncrasies (like 
> > mentioned by
> > Santesson) ...
> >
> > However, RFC 3280 says (§ 4.2.1.10  Basic Constraints):
> >              "...This extension MUST appear as a critical extension 
> > in
all
> CA
> > certificates
> >              that contain public keys used to validate digital
signatures on
> > certificates" ?
> >
> > (and the same hold for other extensions as well)
> >
> > It does not say "all CA certificates that are not trust anchors"; it 
> > says "all CA certificates".
> >
> > Is this statement not conflicting with your one?
> >
> > Adriano
> >
> >
> > -----Messaggio originale-----
> > Da: [email-masked] 
> > [mailto:[email-masked]]
> > Per conto di Peter Hesse
> > Inviato: lunedì 30 agosto 2004 18.43
> > A: 'David P. Kemp'; [email-masked]
> > Oggetto: RE: On cross-certificates and pathLenConstraint
> >
> >
> >
> > Section 6.1 of RFC 3280 states:
> >
> >    When the trust anchor is provided in the form of a self-signed
> >    certificate, this self-signed certificate is not included as part
of
> >    the prospective certification path.  Information about trust
anchors
> >    are provided as inputs to the certification path validation
algorithm
> >    (section 6.1.1).
> >
> > Thus I agree with Santosh that in no case should the extensions in a 
> > trust anchor's self-signed certificate affect the certification path 
> > validation.
> >
> > --Peter
> >
> > +---------------------------------------------------------------+
> > | Peter Hesse                    [email-masked]     |
> > | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> > | ICQ: 1942828                     www.geminisecurity.com       |
> > +---------------------------------------------------------------+
> > "Pay no attention to what the critics say; there has never been a 
> > statue set up in honor of a critic." --Jean Sibelius
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of David P. Kemp
> > > Sent: Monday, August 30, 2004 11:51 AM
> > > To: [email-masked]
> > > Subject: Re: On cross-certificates and pathLenConstraint
> > >
> > >
> > > Santosh,
> > >
> > > Is there ambiguity in the term trust anchor?  It seems possible to 
> > > regard the trust anchor as a bare public key or as a certificate.
> > >
> > > Because a self-signed certificate should appear only once at the 
> > > head of a path (and never elsewhere) the rule of "no extensions in 
> > > trust anchors" should apply only if "trust anchor" is defined to 
> > > be a public key that can be used to verify a certificate 
> > > (self-signed or otherwise).  It should not apply if the 
> > > self-signed certificate itself is defined to be the trust anchor.
> > >
> > > Perhaps X.509 and RFC 3280 should be clarified to state that there 
> > > is no such thing as a "self signed root".  There are roots (trust
> > > anchors) that are public keys only, and there are self signed
> > > certificates that may be validated by a root and whose extensions 
> > > are to be honored.
> > >
> > > Dave
> > >
> > >
> > > Santosh Chokhani wrote:
> > >
> > > >Stefan:
> > > >
> > > >I think extensions should be ignored in the trust anchor
> > > regardless of
> > > >their criticality
> > > >
> > > >For reasons such as MS CAPI, it is best to keep the trust anchors 
> > > >to bear minimum required.
> > > >
> > > >-----Original Message-----
> > > >From: Stefan Santesson [mailto:[email-masked]]
> > > >Sent: Saturday, August 28, 2004 5:10 AM
> > > >To: Santosh Chokhani; [email-masked]
> > > >Subject: RE: On cross-certificates and pathLenConstraint
> > > >
> > > >
> > > >The case when CA A is a self-signed root is different.
> > > >
> > > >If the Path Length constraint is present in the self signed root, 
> > > >it will be ignored by a X.509 and RFC 3280 compliant path
> > > validation implementation.
> > > >
> > > >However, there are implementations that honour Root
> > > extensions despite
> > > >this and would thus honour Path length constraints present in 
> > > >roots. E.g. I know that MS CAPI will.
> > > >
> > > >Despite that, I would say that it is wrong to rely on critical 
> > > >extensions in root certificates since they are ignored in
> > > RFC 3280 path validation.
> > > >
> > > >Stefan Santesson
> > > >Microsoft Security Center of Excellence (SCOE)
> > > >
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: [email-masked] 
> > > >>[mailto:[email-masked]]
> > > >>On Behalf Of Santosh Chokhani
> > > >>Sent: den 28 augusti 2004 00:52
> > > >>To: [email-masked]
> > > >>Subject: RE: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>Stefan has the right idea.
> > > >>
> > > >>If CA A is simply another CA, CA B certificate can be
> > > validated as an
> > > >>end (not intermediate certificate).
> > > >>
> > > >>If CA A is trust anchor, I think it can issue CA
> > > certificates.  I read
> > > >>both X.509 and 3280 to not enforce constraints in the trust 
> > > >>anchor.
> > > >>
> > > >>To complicate matters further, if the trust anchor issues itself 
> > > >>a self-issued certificate, I would think the pathLength in that 
> > > >>certificate should be honored.
> > > >>
> > > >>BTW, all this discussion of hierarchies and cross
> > > certificates should
> > > >>not be relevant.  Both X.509 and 3280 are (rightfully) trust 
> > > >>model agnostic.
> > > >>
> > > >>-----Original Message-----
> > > >>From: [email-masked] 
> > > >>[mailto:[email-masked]]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 9:28 AM
> > > >>To: Sharon Boeyen
> > > >>Cc: [email-masked]
> > > >>Subject: R: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>
> > > >>Sharon,
> > > >>
> > > >>you explained what happens when a cross-certificates contains a 
> > > >>pathLenConstraint=0, but I was referring to the
> > > pathLenConstraint in
> > > >>the trust-point certificate. Virtually all CA public keys are 
> > > >>distributed to end-users in the form of a self-signed 
> > > >>certificate which may (should) contain the BasicConstrains 
> > > >>extension. Some EU profiles actually mandate the BasicConstrains 
> > > >>to be present and critical.
> > > >>
> > > >>Using your example entities, my question can be re-phrased like
> > > >>follows: can CA A (my trust point) issue a cross-cert to CA
> > > B (e.g. a
> > > >>foreign one) if the self-issued certificate of CA A contains 
> > > >>pathLenConstraint=0 ?
> > > >>
> > > >>>From another viewpoint: setting pathLenConstraint=0 to prevent
> > > >>
> > > >>
> > > >>>hierarchical SubCAs does also hinder cross-certificates?
> > > >>>
> > > >>>
> > > >>Adriano
> > > >>
> > > >>-----Messaggio originale-----
> > > >>Da: Sharon Boeyen [mailto:[email-masked]]
> > > >>Inviato: venerdì 27 agosto 2004 14.34
> > > >>A: Santoni Adriano; [email-masked]
> > > >>Oggetto: RE: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>If you are talking about a non-hierarchical trust model, then 
> > > >>absolutely yes any CA can issue any cross-certificates they 
> > > >>wish. However, those cross-certificates will only be trusted if 
> > > >>paths are built to them that exclude the certificate that 
> > > >>contains the path length constraint.
> > > >>
> > > >>For example, take CA A, CA B, CA C and CA D
> > > >>
> > > >>CA A issues a cross certificate to CA B with a path length
> > > constraint
> > > >>of 0 CA B issues a cross certificate to CA C CA D issues a cross 
> > > >>certificate to CA B (no path length constraint)
> > > >>
> > > >>Assume that there are no other cross certs in the environment
> > > >>
> > > >>Users of CA A have no way to trust certificates issued by CA C 
> > > >>(because of the path length constraint)
> > > >>
> > > >>However, users of CA D are able to trust certificates
> > > issued by CA C
> > > >>because the cross-certificate from D to B contains no such
> > > constraint.
> > > >>
> > > >>As for your second question, yes there are implementations that 
> > > >>process paths including all the business controls. As for
> > > testing, I'd
> > > >>suggest you have a look at the PKITS test suite which tests
> > > all these
> > > >>features. http://csrc.nist.gov/pki/testing/x509paths.html
> > > >>
> > > >>Cheers,
> > > >>Sharon
> > > >>
> > > >>-----Original Message-----
> > > >>From: [email-masked] 
> > > >>[mailto:[email-masked]]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 5:37 AM
> > > >>To: [email-masked]
> > > >>Subject: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>
> > > >>Dear list,
> > > >>
> > > >>I have the following doubts regarding cross-certificates:
> > > >>
> > > >>can a CA with BasicConstraints.pathLenConstraint=0 issue a
> > > >>cross- certificate to another CA in a different domain?
> > > >>
> > > >>In case of a "cross-certificate" (so to speak) issued by
> > > the same CA
> > > >>for itself, to facilitate the CA key rollover, RFC 3280 seems to 
> > > >>to allow the cross-certificate issuance regardless of the 
> > > >>pathLenConstraint value, on the ground that in this case the 
> > > >>cross-certificate is "self-issued" and therefore, in a way, "out 
> > > >>of scope" as far as the pathLenConstraint is concerned.
> > > >>
> > > >>However, in the case of a "real" cross-certificate, to be issued 
> > > >>to another CA with a different name, it is not very clear to me 
> > > >>if the pathLenConstraint in CA1 affects the possibility of 
> > > >>issuing a cross-certificate to CA2.
> > > >>
> > > >>By the way, I wonder how are the most widespread
> > > applications handling
> > > >>certificate chains containing cross-certs, in the various
> > > cases (e.g.
> > > >>different values of pethLenConstraint down the chain); has 
> > > >>anybody done any testing to specifically investigate this area?
> > > >>
> > > >>Is anybody willing to shed some light and/or share informations?
> > > >>
> > > >>TIA,
> > > >>  Adriano
> > > >>
> > > >>
> > > >>*******************Internet Email Confidentiality
> > > >>Footer*******************
> > > >>
> > > >>
> > > >>Qualsiasi utilizzo non autorizzato del presente messaggio
> > > nonche dei
> > > >>suoi allegati e vietato e potrebbe costituire reato. Se ha 
> > > >>ricevuto per errore il presente messaggio, Le saremmo grati se 
> > > >>ci
> > > inviasse, via
> > > >>e-mail, una comunicazione al riguardo e provvedesse nel
> > > contempo alla
> > > >>distruzione del messaggio stesso e dei suoi eventuali allegati. 
> > > >>Le dichiarazioni contenute nel presente messaggio nonche' nei 
> > > >>suoi eventuali allegati devono essere attribuite esclusivamente
> > > al mittente
> > > >>e non possono essere considerate come trasmesse o autorizzate da 
> > > >>ACTALIS S.p.A.; le medesime dichiarazioni non impegnano
> > > ACTALIS S.p.A.
> > > >>nei confronti del destinatario o di terzi.
> > > >>ACTALIS S.p.A. non si assume alcuna responsabilita' per 
> > > >>eventuali intercettazioni, modifiche o danneggiamenti del 
> > > >>presente
> > > messaggio e-mail.
> > > >>
> > > >>
> > > >>
> > > >>Any unauthorized use of this e-mail or any of its attachments is 
> > > >>prohibited and could constitute an offence. If you are not the 
> > > >>intended addressee please advise immediately the sender by
> > > using the
> > > >>reply facility in your e-mail software and destroy the
> > > message and its
> > > >>attachments. The statements and opinions expressed in this 
> > > >>e-mail message are those of the author of the message and do not
> > > necessarily
> > > >>represent those of ACTALIS S.p.A. Besides, The contents of this 
> > > >>message shall be understood as neither given nor endorsed
> > > by ACTALIS
> > > >>S.p.A..
> > > >>ACTALIS S.p.A. does not accept liability for corruption,
> > > interception
> > > >>or amendment, if any, or the consequences thereof.
> > > >>
> > > >>
> > > >>*******************Internet Email Confidentiality
> > > >>Footer*******************
> > > >>
> > > >>
> > > >>Qualsiasi utilizzo non autorizzato del presente messaggio
> > > nonché dei
> > > >>suoi allegati è vietato e potrebbe costituire reato. Se ha 
> > > >>ricevuto per errore il presente messaggio, Le saremmo grati se 
> > > >>ci
> > > inviasse, via
> > > >>e-mail, una comunicazione al riguardo e provvedesse nel
> > > contempo alla
> > > >>distruzione del messaggio stesso e dei suoi eventuali allegati. 
> > > >>Le dichiarazioni contenute nel presente messaggio nonche' nei 
> > > >>suoi eventuali allegati devono essere attribuite esclusivamente
> > > al mittente
> > > >>e non possono essere considerate come trasmesse o autorizzate da 
> > > >>ACTALIS S.p.A.; le medesime dichiarazioni non impegnano
> > > ACTALIS S.p.A.
> > > >>nei confronti del destinatario o di terzi.
> > > >>ACTALIS S.p.A. non si assume alcuna responsabilita' per 
> > > >>eventuali intercettazioni, modifiche o danneggiamenti del 
> > > >>presente
> > > messaggio e-mail.
> > > >>
> > > >>
> > > >>
> > > >>Any unauthorized use of this e-mail or any of its attachments is 
> > > >>prohibited and could constitute an offence. If you are not the 
> > > >>intended addressee please advise immediately the sender by
> > > using the
> > > >>reply facility in your e-mail software and destroy the
> > > message and its
> > > >>attachments. The statements and opinions expressed in this 
> > > >>e-mail message are those of the author of the message and do not
> > > necessarily
> > > >>represent those of ACTALIS S.p.A. Besides, The contents of this 
> > > >>message shall be understood as neither given nor endorsed
> > > by ACTALIS
> > > >>S.p.A..
> > > >>ACTALIS S.p.A. does not accept liability for corruption,
> > > interception
> > > >>or amendment, if any, or the consequences thereof.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> > *******************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.
> >
> >
> 
> 

Content-class: urn:content-classes:message
Subject: RE: R: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 15:44:47 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Steve,

I agree to the legitimate need you express. 

To further expand on that you may also want to limit a TA to a certain
usage, e.g. only to be used to validate code signing signatures.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 1 september 2004 15:24
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: R: On cross-certificates and pathLenConstraint
> 
> 
> At 11:48 AM +0100 9/1/04, Liaquat Khan wrote:
> >  >
> >>  Does not this lead to a paradox? Being a TA is a subjective
> >>  attribute of a CA certificate, i.e. the same CA certificate
> >>  can be or not be a TA depending on the entity that is using
> >>  that certificate in a path validation process. Now, suppose a
> >>  root CA1 issues a certificate for a subordinate CA2, putting
> >>  pathLenConstraint=0 in the CA2 certificate. Then, enforcing
> >>  that constraint would depend on CA2 being considered a TA or
> >>  not. This can make sense from the point of view of the end
> >>  user, but certainly not from the point of view of the root
> >>  CA1, that most probably put that constraint in the CA2 for
> >>  policy reasons. Even if the user regards CA2 as a TA, rather
> >>  than CA1, from the point of view of CA1 that does not mean
> >>  that he (the user) can ignore the (critical) extensions in
> >>  the CA2 certificate!
> >
> >
> >I am not sure this is a problem, as I am of the view that if the user
> >has made CA2 its Trust Anchor, then he trusts this implicitly.
> 
> This is not a good model in general, although it is the model imposed
> by browsers. If one had the ability to associate more path validation
> constraints with TAs, then there would not be a need to implicitly
> trust them. For example, if I installed a TA for CompuDigi Corp, I
> might want to impose a name constraint with that TA, to ensure that
> the TA was used to validate certs only for CompuDigi Corp employees,
> servers, etc.  Unfortunately, the current specs do not allow us to do
> this, and that is a problem that needs to be fixed.
> 
> 
> >Steve

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: R: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 15:09:00 +0100
Importance: Normal
Sender: [email-masked]

I am not sure who actually imposed the model!  Although I agree being
able to associate such name constraints with TAs could be a useful
feature.  

However, in my opinion this is a decision which is likely to be made by
the RP application, not the CA as such.  For example, some RPs may wish
to accept the CompuDigi TA without any name constraints (i.e. any
certificate issued under this TA is acceptable to these RPs), whilst
other RPs may only use the TA to validate only CompuDigi corporate
certs.  

It may therefore be better to associate such name constraints with a TA
independently of the actual TA certificate (i.e. assuming the TA is in
form of a certificate).  This should also mean the current specs are
sufficient.  

Regards,
LK

> >I am not sure this is a problem, as I am of the view that if 
> the user 
> >has made CA2 its Trust Anchor, then he trusts this implicitly.
> 
> This is not a good model in general, although it is the model imposed 
> by browsers. If one had the ability to associate more path validation 
> constraints with TAs, then there would not be a need to implicitly 
> trust them. For example, if I installed a TA for CompuDigi Corp, I 
> might want to impose a name constraint with that TA, to ensure that 
> the TA was used to validate certs only for CompuDigi Corp employees, 
> servers, etc.  Unfortunately, the current specs do not allow us to do 
> this, and that is a problem that needs to be fixed.
> 
> 
> >Steve
> 

Date: Wed, 1 Sep 2004 09:24:24 -0400
To: <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: R: On cross-certificates and pathLenConstraint
Cc: <[email-masked]>
Sender: [email-masked]

At 11:48 AM +0100 9/1/04, Liaquat Khan wrote:
>  >
>>  Does not this lead to a paradox? Being a TA is a subjective
>>  attribute of a CA certificate, i.e. the same CA certificate
>>  can be or not be a TA depending on the entity that is using
>>  that certificate in a path validation process. Now, suppose a
>>  root CA1 issues a certificate for a subordinate CA2, putting
>>  pathLenConstraint=0 in the CA2 certificate. Then, enforcing
>>  that constraint would depend on CA2 being considered a TA or
>>  not. This can make sense from the point of view of the end
>>  user, but certainly not from the point of view of the root
>>  CA1, that most probably put that constraint in the CA2 for
>>  policy reasons. Even if the user regards CA2 as a TA, rather
>>  than CA1, from the point of view of CA1 that does not mean
>>  that he (the user) can ignore the (critical) extensions in
>>  the CA2 certificate!
>
>
>I am not sure this is a problem, as I am of the view that if the user
>has made CA2 its Trust Anchor, then he trusts this implicitly.

This is not a good model in general, although it is the model imposed 
by browsers. If one had the ability to associate more path validation 
constraints with TAs, then there would not be a need to implicitly 
trust them. For example, if I installed a TA for CompuDigi Corp, I 
might want to impose a name constraint with that TA, to ensure that 
the TA was used to validate certs only for CompuDigi Corp employees, 
servers, etc.  Unfortunately, the current specs do not allow us to do 
this, and that is a problem that needs to be fixed.

>Steve

To: "Santosh Chokhani" <[email-masked]>
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
From: Tom Gindin <[email-masked]>
Date: Wed, 1 Sep 2004 07:19:31 -0400
Sender: [email-masked]

        Santosh:

        This has come up before, as I indicated in my last posting.  I ask 
for consensus to the effect that setting permitted_subtrees, 
excluded_subtrees, and max_path_length from configuration entries 
specifiable on a per-trust-anchor basis is a permissible "augmentation" of 
the RFC 3280 algorithm of the sort contemplated in the third and fourth 
sentences of RFC 3280 6.2.  In fact, the fourth sentence of that section 
explicitly suggests using name constraints in this way even though RFC 
3280 6.1.2 gives specific initial values for the "subtrees" parameters 
just as it does for max_path_length.  The initialization of 
max_path_length to "n" has no particular effect that would not be obtained 
by setting it to a large positive value instead.
        Obviously, packaging such a configuration entry within a v3 
certificate has no effect relevant to RFC 3280.  If the configuration 
entry is allowed, it may be derived from a certificate or may come from a 
file, at the RP's option.
        Although the argument above is based on the text of RFC 3280, I am 
not making it solely for that reason.  I believe that it is technically 
appropriate to implement such a feature as well.  In particular, an RP may 
have legitimate reasons to trust a departmental CA directly, and set 
max_path_length to 0; to trust a CA's EE certificates without trusting his 
cross certificates, also by setting max_path_length to 0; or to impose a 
naming space restriction on a directly trusted CA by setting 
permitted_subtrees.  I do not claim that I can compose plausible use cases 
for the entire breadth of these parameters.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
08/31/2004 12:19 PM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: On cross-certificates and pathLenConstraint

Stefan:

I think a trust anchor is not necessarily a certificate, let alone a CA
certificate.  Thus, 4.2.1.10 does not apply.  Also, as I have noted to
Sharon, you can not enforce the cA flag or initialize path length from the
root.  Thus, the use of this extension in the root is meaningless.

As to accepting constraints from the root, those that 3280 permits to be
initialized, is fine.  Path length is not one of them.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 11:32 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santosh,

You are right that you may provide trust information by means other than a
certificate, but if you form a root certificate according to RFC 3280, 
then
basic constraints MUST be present or the certificate is NOT RFC 3280
compliant.

RFC 3280 4.2.1.10
   This extension MUST appear as a critical extension in all CA
   certificates that contain public keys used to validate digital
   signatures on certificates.

Which is perfectly true also for roots.

Secondly, section 6.1 of RFC 3280 states:
   A particular certification path may not, however, be appropriate for
   all applications.  Therefore, an application MAY augment this
   algorithm to further limit the set of valid paths.

Accepting constraints configured in the applied root as input variables 
into
the path processing is therefore completely allowed by RFC 3280 path
processing as a way to augment the mandatory algorithm to further 
constrain
trust.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 31 augusti 2004 13:47
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> The standard does NOT require basic constraints to be in the root.
> 
> Also, when you enforce constraints on the trust anchor certificate,
> that is not in compliance with the standard.
> 
> I agree that a more flexible standard would be one that honors
> extensions in the root and also permits most of the values to be 
> initialized.  I know both
> X.509 and 3280 are moving towards the second one.  The first one can
> become
> a backward compatibility issue.
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 6:26 AM
> To: Santoni Adriano; Peter Hesse; David P. Kemp
> Cc: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> Santoni,
> 
> I just want to add/clarify that I agree that discarding all extensions
> of root certificates in path processing is a bad design.
> 
> The result is as you conclude that Basic Constraints MUST be present
> in roots but any present path length constraints, policy constraints, 
> explicit policies, name constraints etc, MAY be ignored.
> 
> However, as Sharon pointed out, it is not a violation of RFC 3280 to
> honour any constraints set in the root certificate so MS CAPIs 
> decision to enforce
> ROOT extensions in this manner is not in conflict with RFC 3280, but you
> can't rely on that other RFC 3280 compliant implementations will do 
this.
> They may legitimately ignore this data.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > On Behalf Of Santoni Adriano
> > Sent: den 31 augusti 2004 09:26
> > To: Peter Hesse; David P. Kemp
> > Cc: [email-masked]
> > Subject: R: On cross-certificates and pathLenConstraint
> >
> >
> > If I am getting you right, you are saying that the exensions in the
> > self- signed certificate of a trust anchor (root CA) should be
> > ignored. This is quite suprising to me!
> >
> > I thought it perfectly made sense to insert in a root CA certificate
> > a basicConstraints with cA=TRUE and pathLenConstraint=0 (for 
> > example) to signify that that CA only issues certificates to 
> > end-users and not to subordinates. I am talking about the 
> > self-signed certificate used by an autonomous CA to distribute its 
> > own public key in a way that allows easy import into virtually all 
> > applications. [On the other hand, what CAs distribute their own 
> > public keys as a bare public keys? Virtually none.]
> >
> > It suddenly comes to my mind that perhaps the extensions in the root
> > CA certificates contained in the Windows store were inserted for the 
> > sole purposes of accommodating MS CAPI idiosyncrasies (like 
> > mentioned by
> > Santesson) ...
> >
> > However, RFC 3280 says (§ 4.2.1.10  Basic Constraints):
> >              "...This extension MUST appear as a critical extension in 
all
> CA
> > certificates
> >              that contain public keys used to validate digital 
signatures on
> > certificates" ?
> >
> > (and the same hold for other extensions as well)
> >
> > It does not say "all CA certificates that are not trust anchors"; it
> > says "all CA certificates".
> >
> > Is this statement not conflicting with your one?
> >
> > Adriano
> >
> >
> > -----Messaggio originale-----
> > Da: [email-masked]
> > [mailto:[email-masked]]
> > Per conto di Peter Hesse
> > Inviato: lunedì 30 agosto 2004 18.43
> > A: 'David P. Kemp'; [email-masked]
> > Oggetto: RE: On cross-certificates and pathLenConstraint
> >
> >
> >
> > Section 6.1 of RFC 3280 states:
> >
> >    When the trust anchor is provided in the form of a self-signed
> >    certificate, this self-signed certificate is not included as part 
of
> >    the prospective certification path.  Information about trust 
anchors
> >    are provided as inputs to the certification path validation 
algorithm
> >    (section 6.1.1).
> >
> > Thus I agree with Santosh that in no case should the extensions in a
> > trust anchor's self-signed certificate affect the certification path 
> > validation.
> >
> > --Peter
> >
> > +---------------------------------------------------------------+
> > | Peter Hesse                    [email-masked]     |
> > | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> > | ICQ: 1942828                     www.geminisecurity.com       |
> > +---------------------------------------------------------------+
> > "Pay no attention to what the critics say; there has never been a
> > statue set up in honor of a critic." --Jean Sibelius
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of David P. Kemp
> > > Sent: Monday, August 30, 2004 11:51 AM
> > > To: [email-masked]
> > > Subject: Re: On cross-certificates and pathLenConstraint
> > >
> > >
> > > Santosh,
> > >
> > > Is there ambiguity in the term trust anchor?  It seems possible to
> > > regard the trust anchor as a bare public key or as a certificate.
> > >
> > > Because a self-signed certificate should appear only once at the
> > > head of a path (and never elsewhere) the rule of "no extensions in 
> > > trust anchors" should apply only if "trust anchor" is defined to 
> > > be a public key that can be used to verify a certificate 
> > > (self-signed or otherwise).  It should not apply if the 
> > > self-signed certificate itself is defined to be the trust anchor.
> > >
> > > Perhaps X.509 and RFC 3280 should be clarified to state that there
> > > is no such thing as a "self signed root".  There are roots (trust
> > > anchors) that are public keys only, and there are self signed 
> > > certificates that may be validated by a root and whose extensions 
> > > are to be honored.
> > >
> > > Dave
> > >
> > >
> > > Santosh Chokhani wrote:
> > >
> > > >Stefan:
> > > >
> > > >I think extensions should be ignored in the trust anchor
> > > regardless of
> > > >their criticality
> > > >
> > > >For reasons such as MS CAPI, it is best to keep the trust anchors
> > > >to bear minimum required.
> > > >
> > > >-----Original Message-----
> > > >From: Stefan Santesson [mailto:[email-masked]]
> > > >Sent: Saturday, August 28, 2004 5:10 AM
> > > >To: Santosh Chokhani; [email-masked]
> > > >Subject: RE: On cross-certificates and pathLenConstraint
> > > >
> > > >
> > > >The case when CA A is a self-signed root is different.
> > > >
> > > >If the Path Length constraint is present in the self signed root,
> > > >it will be ignored by a X.509 and RFC 3280 compliant path
> > > validation implementation.
> > > >
> > > >However, there are implementations that honour Root
> > > extensions despite
> > > >this and would thus honour Path length constraints present in
> > > >roots. E.g. I know that MS CAPI will.
> > > >
> > > >Despite that, I would say that it is wrong to rely on critical
> > > >extensions in root certificates since they are ignored in
> > > RFC 3280 path validation.
> > > >
> > > >Stefan Santesson
> > > >Microsoft Security Center of Excellence (SCOE)
> > > >
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: [email-masked]
> > > >>[mailto:[email-masked]]
> > > >>On Behalf Of Santosh Chokhani
> > > >>Sent: den 28 augusti 2004 00:52
> > > >>To: [email-masked]
> > > >>Subject: RE: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>Stefan has the right idea.
> > > >>
> > > >>If CA A is simply another CA, CA B certificate can be
> > > validated as an
> > > >>end (not intermediate certificate).
> > > >>
> > > >>If CA A is trust anchor, I think it can issue CA
> > > certificates.  I read
> > > >>both X.509 and 3280 to not enforce constraints in the trust
> > > >>anchor.
> > > >>
> > > >>To complicate matters further, if the trust anchor issues itself
> > > >>a self-issued certificate, I would think the pathLength in that 
> > > >>certificate should be honored.
> > > >>
> > > >>BTW, all this discussion of hierarchies and cross
> > > certificates should
> > > >>not be relevant.  Both X.509 and 3280 are (rightfully) trust
> > > >>model agnostic.
> > > >>
> > > >>-----Original Message-----
> > > >>From: [email-masked]
> > > >>[mailto:[email-masked]]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 9:28 AM
> > > >>To: Sharon Boeyen
> > > >>Cc: [email-masked]
> > > >>Subject: R: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>
> > > >>Sharon,
> > > >>
> > > >>you explained what happens when a cross-certificates contains a
> > > >>pathLenConstraint=0, but I was referring to the
> > > pathLenConstraint in
> > > >>the trust-point certificate. Virtually all CA public keys are
> > > >>distributed to end-users in the form of a self-signed 
> > > >>certificate which may (should) contain the BasicConstrains 
> > > >>extension. Some EU profiles actually mandate the BasicConstrains 
> > > >>to be present and critical.
> > > >>
> > > >>Using your example entities, my question can be re-phrased like
> > > >>follows: can CA A (my trust point) issue a cross-cert to CA
> > > B (e.g. a
> > > >>foreign one) if the self-issued certificate of CA A contains
> > > >>pathLenConstraint=0 ?
> > > >>
> > > >>>From another viewpoint: setting pathLenConstraint=0 to prevent
> > > >>
> > > >>
> > > >>>hierarchical SubCAs does also hinder cross-certificates?
> > > >>>
> > > >>>
> > > >>Adriano
> > > >>
> > > >>-----Messaggio originale-----
> > > >>Da: Sharon Boeyen [mailto:[email-masked]]
> > > >>Inviato: venerdì 27 agosto 2004 14.34
> > > >>A: Santoni Adriano; [email-masked]
> > > >>Oggetto: RE: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>If you are talking about a non-hierarchical trust model, then
> > > >>absolutely yes any CA can issue any cross-certificates they 
> > > >>wish. However, those cross-certificates will only be trusted if 
> > > >>paths are built to them that exclude the certificate that 
> > > >>contains the path length constraint.
> > > >>
> > > >>For example, take CA A, CA B, CA C and CA D
> > > >>
> > > >>CA A issues a cross certificate to CA B with a path length
> > > constraint
> > > >>of 0 CA B issues a cross certificate to CA C CA D issues a cross
> > > >>certificate to CA B (no path length constraint)
> > > >>
> > > >>Assume that there are no other cross certs in the environment
> > > >>
> > > >>Users of CA A have no way to trust certificates issued by CA C
> > > >>(because of the path length constraint)
> > > >>
> > > >>However, users of CA D are able to trust certificates
> > > issued by CA C
> > > >>because the cross-certificate from D to B contains no such
> > > constraint.
> > > >>
> > > >>As for your second question, yes there are implementations that
> > > >>process paths including all the business controls. As for
> > > testing, I'd
> > > >>suggest you have a look at the PKITS test suite which tests
> > > all these
> > > >>features. http://csrc.nist.gov/pki/testing/x509paths.html
> > > >>
> > > >>Cheers,
> > > >>Sharon
> > > >>
> > > >>-----Original Message-----
> > > >>From: [email-masked]
> > > >>[mailto:[email-masked]]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 5:37 AM
> > > >>To: [email-masked]
> > > >>Subject: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>
> > > >>Dear list,
> > > >>
> > > >>I have the following doubts regarding cross-certificates:
> > > >>
> > > >>can a CA with BasicConstraints.pathLenConstraint=0 issue a
> > > >>cross- certificate to another CA in a different domain?
> > > >>
> > > >>In case of a "cross-certificate" (so to speak) issued by
> > > the same CA
> > > >>for itself, to facilitate the CA key rollover, RFC 3280 seems to
> > > >>to allow the cross-certificate issuance regardless of the 
> > > >>pathLenConstraint value, on the ground that in this case the 
> > > >>cross-certificate is "self-issued" and therefore, in a way, "out 
> > > >>of scope" as far as the pathLenConstraint is concerned.
> > > >>
> > > >>However, in the case of a "real" cross-certificate, to be issued
> > > >>to another CA with a different name, it is not very clear to me 
> > > >>if the pathLenConstraint in CA1 affects the possibility of 
> > > >>issuing a cross-certificate to CA2.
> > > >>
> > > >>By the way, I wonder how are the most widespread
> > > applications handling
> > > >>certificate chains containing cross-certs, in the various
> > > cases (e.g.
> > > >>different values of pethLenConstraint down the chain); has
> > > >>anybody done any testing to specifically investigate this area?
> > > >>
> > > >>Is anybody willing to shed some light and/or share informations?
> > > >>
> > > >>TIA,
> > > >>  Adriano
> > > >>
> > > >>
> > > >>*******************Internet Email Confidentiality
> > > >>Footer*******************
> > > >>
> > > >>
> > > >>Qualsiasi utilizzo non autorizzato del presente messaggio
> > > nonche dei
> > > >>suoi allegati e vietato e potrebbe costituire reato. Se ha
> > > >>ricevuto per errore il presente messaggio, Le saremmo grati se 
> > > >>ci
> > > inviasse, via
> > > >>e-mail, una comunicazione al riguardo e provvedesse nel
> > > contempo alla
> > > >>distruzione del messaggio stesso e dei suoi eventuali allegati.
> > > >>Le dichiarazioni contenute nel presente messaggio nonche' nei 
> > > >>suoi eventuali allegati devono essere attribuite esclusivamente
> > > al mittente
> > > >>e non possono essere considerate come trasmesse o autorizzate da
> > > >>ACTALIS S.p.A.; le medesime dichiarazioni non impegnano
> > > ACTALIS S.p.A.
> > > >>nei confronti del destinatario o di terzi.
> > > >>ACTALIS S.p.A. non si assume alcuna responsabilita' per
> > > >>eventuali intercettazioni, modifiche o danneggiamenti del 
> > > >>presente
> > > messaggio e-mail.
> > > >>
> > > >>
> > > >>
> > > >>Any unauthorized use of this e-mail or any of its attachments is
> > > >>prohibited and could constitute an offence. If you are not the 
> > > >>intended addressee please advise immediately the sender by
> > > using the
> > > >>reply facility in your e-mail software and destroy the
> > > message and its
> > > >>attachments. The statements and opinions expressed in this
> > > >>e-mail message are those of the author of the message and do not
> > > necessarily
> > > >>represent those of ACTALIS S.p.A. Besides, The contents of this
> > > >>message shall be understood as neither given nor endorsed
> > > by ACTALIS
> > > >>S.p.A..
> > > >>ACTALIS S.p.A. does not accept liability for corruption,
> > > interception
> > > >>or amendment, if any, or the consequences thereof.
> > > >>
> > > >>
> > > >>*******************Internet Email Confidentiality
> > > >>Footer*******************
> > > >>
> > > >>
> > > >>Qualsiasi utilizzo non autorizzato del presente messaggio
> > > nonché dei
> > > >>suoi allegati è vietato e potrebbe costituire reato. Se ha
> > > >>ricevuto per errore il presente messaggio, Le saremmo grati se 
> > > >>ci
> > > inviasse, via
> > > >>e-mail, una comunicazione al riguardo e provvedesse nel
> > > contempo alla
> > > >>distruzione del messaggio stesso e dei suoi eventuali allegati.
> > > >>Le dichiarazioni contenute nel presente messaggio nonche' nei 
> > > >>suoi eventuali allegati devono essere attribuite esclusivamente
> > > al mittente
> > > >>e non possono essere considerate come trasmesse o autorizzate da
> > > >>ACTALIS S.p.A.; le medesime dichiarazioni non impegnano
> > > ACTALIS S.p.A.
> > > >>nei confronti del destinatario o di terzi.
> > > >>ACTALIS S.p.A. non si assume alcuna responsabilita' per
> > > >>eventuali intercettazioni, modifiche o danneggiamenti del 
> > > >>presente
> > > messaggio e-mail.
> > > >>
> > > >>
> > > >>
> > > >>Any unauthorized use of this e-mail or any of its attachments is
> > > >>prohibited and could constitute an offence. If you are not the 
> > > >>intended addressee please advise immediately the sender by
> > > using the
> > > >>reply facility in your e-mail software and destroy the
> > > message and its
> > > >>attachments. The statements and opinions expressed in this
> > > >>e-mail message are those of the author of the message and do not
> > > necessarily
> > > >>represent those of ACTALIS S.p.A. Besides, The contents of this
> > > >>message shall be understood as neither given nor endorsed
> > > by ACTALIS
> > > >>S.p.A..
> > > >>ACTALIS S.p.A. does not accept liability for corruption,
> > > interception
> > > >>or amendment, if any, or the consequences thereof.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> > *******************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.
> >
> >
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: R: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 07:09:31 -0400
Importance: Normal
Sender: [email-masked]

I agree with Liaquat.

I will respond to Steve Hanna later.

-----Original Message-----
From: Liaquat Khan [mailto:[email-masked]] 
Sent: Wednesday, September 01, 2004 6:48 AM
To: 'Santoni Adriano'; 'Steve Hanna'; 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: R: On cross-certificates and pathLenConstraint

> 
> Does not this lead to a paradox? Being a TA is a subjective
> attribute of a CA certificate, i.e. the same CA certificate 
> can be or not be a TA depending on the entity that is using 
> that certificate in a path validation process. Now, suppose a 
> root CA1 issues a certificate for a subordinate CA2, putting 
> pathLenConstraint=0 in the CA2 certificate. Then, enforcing 
> that constraint would depend on CA2 being considered a TA or 
> not. This can make sense from the point of view of the end 
> user, but certainly not from the point of view of the root 
> CA1, that most probably put that constraint in the CA2 for 
> policy reasons. Even if the user regards CA2 as a TA, rather 
> than CA1, from the point of view of CA1 that does not mean 
> that he (the user) can ignore the (critical) extensions in 
> the CA2 certificate!

I am not sure this is a problem, as I am of the view that if the user
has made CA2 its Trust Anchor, then he trusts this implicitly.   The
user might not even know who is CA1, and therefore not care what
constraints were put on CA2 by this unrecogised CA1.

>From CA1's perspective if it wants to ensure that its constraints are
enforced, it has to ensure it acts as the TA for its end-users and not
CA2.  It can do this through policy, technical and legal means.  This is
why for example in PKIs like Identrus, the certifcate must be checked up
to the Identrus Root CA.  

Regards
LK

>                
> Adriano
> 
> 
> -----Messaggio originale-----
> Da: [email-masked] 
> [mailto:[email-masked]] Per conto di Steve Hanna
> Inviato: martedì 31 agosto 2004 22.05
> A: Santosh Chokhani
> Cc: [email-masked]
> Oggetto: Re: R: On cross-certificates and pathLenConstraint
> 
> 
> 
> RFC 3280 says in section 6.1:
> 
>     A particular certification path may not, however, be 
> appropriate for
>     all applications.  Therefore, an application MAY augment this
>     algorithm to further limit the set of valid paths.
> 
> and in section 6.2:
> 
>     An implementation that supports multiple trust anchors
>     MAY augment the algorithm presented in section 6.1 to 
> further limit
>     the set of valid certification paths which begin with a particular
>     trust anchor.  For example, an implementation MAY modify the
>     algorithm to apply name constraints to a specific trust 
> anchor during
>     the initialization phase, or the application MAY require 
> the presence
>     of a particular alternative name form in the end entity 
> certificate,
>     or the application MAY impose requirements on application-specific
>     extensions.  Thus, the path validation algorithm 
> presented in section
>     6.1 defines the minimum conditions for a path to be 
> considered valid.
> 
> Therefore, I believe that path validation implementations
> can go beyond the usual path validation algorithm to impose
> any additional requirements on paths that it likes (unless 
> specifically prohibited by RFC 3280). This would include 
> processing name constraints in trust anchors, 
> pathLenConstraints in trust anchors, etc.
> 
> However, CAs who expect to act as trust anchors and issue 
> self-signed certificates for that purpose should not assume 
> that all path validation implementations will do this. If 
> they REALLY want to ensure that path lengths are limited, 
> they should certify a subsidiary CA and include a pathLen 
> constraint in that certificate.
> 
> Now, there's a separate question about whether processing 
> constraints in trust anchors is a good idea. I would argue 
> that it's not. But that's a topic for another email.
> 
> Thanks,
> 
> Steve
> 
> Santosh Chokhani wrote:
> 
> > Steve Kent:
> > 
> > We could take extensions in the TA and use them to initialize a
> > certification path values permitted by 3280, but for values such as 
> > path length that 3280 does not permit initialization of to an 
> > arbitrary value, it will require a change in the standard.
> > 
> > From security viewpoint, I do not object to it, but it is a 
> change to
> > the standard.
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stephen Kent
> > Sent: Tuesday, August 31, 2004 9:51 AM
> > To: Santoni Adriano
> > Cc: [email-masked]
> > Subject: Re: R: On cross-certificates and pathLenConstraint
> > 
> > 
> > 
> > At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> > 
> >>If I am getting you right, you are saying that the exensions in the
> >>self-signed certificate of a trust anchor (root CA) should 
> be ignored. 
> >>This is quite suprising to me!
> > 
> > 
> > Unfortunately that is what X.509 has said for some time, 
> and 3280 has 
> > not deviated in this regard. I too was surprised by this initially.
> > 
> > I discussed this issue with Sharon some time ago, noting that, for 
> > example, one would like to impose name constraints through 
> > configuration of trust anchors and the TA exception to the general 
> > processing rules prohibits that.  So I agree completely 
> that I would 
> > like to see at least SOME of the constraints in a trust 
> anchor cert be 
> > applied to cert path processing, although one needs to carefully 
> > examine the implications of doing this.
> > 
> > BTW, Santosh is correct in noting that TAs are not literally certs, 
> > even though self-signed certs are often used as a means of 
> > representing TAs. However, since we admit that a TA can contain 
> > parameters other than the TA name and key info, I think it is 
> > reasonable to allow for the full range of extensions that 
> might appear 
> > in a CA cert, and to then use them (most of them?) to control path 
> > processing.
> > 
> > Steve
> > 
> 
> *******************Internet Email Confidentiality 
> Footer*******************
> 
> 
> Qualsiasi utilizzo non autorizzato del presente messaggio 
> nonché dei suoi allegati è vietato e potrebbe costituire 
> reato. Se ha ricevuto per errore il presente messaggio, Le 
> saremmo grati se ci inviasse, via e-mail, una comunicazione 
> al riguardo e provvedesse nel contempo alla distruzione del 
> messaggio stesso e dei suoi eventuali allegati. Le 
> dichiarazioni contenute nel presente messaggio nonche' nei 
> suoi eventuali allegati devono essere attribuite 
> esclusivamente al mittente e non possono essere considerate 
> come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime 
> dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del 
> destinatario o di terzi. 
> ACTALIS S.p.A. non si assume alcuna responsabilita' per 
> eventuali intercettazioni, modifiche o danneggiamenti del 
> presente messaggio e-mail. 
> 
> 
> 
> Any unauthorized use of this e-mail or any of its attachments 
> is prohibited and could constitute an offence. If you are not 
> the intended addressee please advise immediately the sender 
> by using the reply facility in your e-mail software and 
> destroy the message and its attachments. The statements and 
> opinions expressed in this e-mail message are those of the 
> author of the message and do not necessarily represent those 
> of ACTALIS S.p.A. Besides, The contents of this message shall 
> be understood as neither given nor endorsed by ACTALIS S.p.A.. 
> ACTALIS S.p.A. does not accept liability for corruption, 
> interception or amendment, if any, or the consequences thereof.
> 
> 
> 

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'Santoni Adriano'" <[email-masked]>, "'Steve Hanna'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: R: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 11:48:13 +0100
Importance: Normal
Sender: [email-masked]

> 
> Does not this lead to a paradox? Being a TA is a subjective 
> attribute of a CA certificate, i.e. the same CA certificate 
> can be or not be a TA depending on the entity that is using 
> that certificate in a path validation process. Now, suppose a 
> root CA1 issues a certificate for a subordinate CA2, putting 
> pathLenConstraint=0 in the CA2 certificate. Then, enforcing 
> that constraint would depend on CA2 being considered a TA or 
> not. This can make sense from the point of view of the end 
> user, but certainly not from the point of view of the root 
> CA1, that most probably put that constraint in the CA2 for 
> policy reasons. Even if the user regards CA2 as a TA, rather 
> than CA1, from the point of view of CA1 that does not mean 
> that he (the user) can ignore the (critical) extensions in 
> the CA2 certificate!

I am not sure this is a problem, as I am of the view that if the user
has made CA2 its Trust Anchor, then he trusts this implicitly.   The
user might not even know who is CA1, and therefore not care what
constraints were put on CA2 by this unrecogised CA1.

>From CA1's perspective if it wants to ensure that its constraints are
enforced, it has to ensure it acts as the TA for its end-users and not
CA2.  It can do this through policy, technical and legal means.  This is
why for example in PKIs like Identrus, the certifcate must be checked up
to the Identrus Root CA.  

Regards
LK

>                
> Adriano
> 
> 
> -----Messaggio originale-----
> Da: [email-masked] 
> [mailto:[email-masked]] Per conto di Steve Hanna
> Inviato: martedì 31 agosto 2004 22.05
> A: Santosh Chokhani
> Cc: [email-masked]
> Oggetto: Re: R: On cross-certificates and pathLenConstraint
> 
> 
> 
> RFC 3280 says in section 6.1:
> 
>     A particular certification path may not, however, be 
> appropriate for
>     all applications.  Therefore, an application MAY augment this
>     algorithm to further limit the set of valid paths.
> 
> and in section 6.2:
> 
>     An implementation that supports multiple trust anchors
>     MAY augment the algorithm presented in section 6.1 to 
> further limit
>     the set of valid certification paths which begin with a particular
>     trust anchor.  For example, an implementation MAY modify the
>     algorithm to apply name constraints to a specific trust 
> anchor during
>     the initialization phase, or the application MAY require 
> the presence
>     of a particular alternative name form in the end entity 
> certificate,
>     or the application MAY impose requirements on application-specific
>     extensions.  Thus, the path validation algorithm 
> presented in section
>     6.1 defines the minimum conditions for a path to be 
> considered valid.
> 
> Therefore, I believe that path validation implementations
> can go beyond the usual path validation algorithm to impose
> any additional requirements on paths that it likes (unless 
> specifically prohibited by RFC 3280). This would include 
> processing name constraints in trust anchors, 
> pathLenConstraints in trust anchors, etc.
> 
> However, CAs who expect to act as trust anchors and issue 
> self-signed certificates for that purpose should not assume 
> that all path validation implementations will do this. If 
> they REALLY want to ensure that path lengths are limited, 
> they should certify a subsidiary CA and include a pathLen 
> constraint in that certificate.
> 
> Now, there's a separate question about whether processing 
> constraints in trust anchors is a good idea. I would argue 
> that it's not. But that's a topic for another email.
> 
> Thanks,
> 
> Steve
> 
> Santosh Chokhani wrote:
> 
> > Steve Kent:
> > 
> > We could take extensions in the TA and use them to initialize a
> > certification path values permitted by 3280, but for values such as 
> > path length that 3280 does not permit initialization of to an 
> > arbitrary value, it will require a change in the standard.
> > 
> > From security viewpoint, I do not object to it, but it is a 
> change to
> > the standard.
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stephen Kent
> > Sent: Tuesday, August 31, 2004 9:51 AM
> > To: Santoni Adriano
> > Cc: [email-masked]
> > Subject: Re: R: On cross-certificates and pathLenConstraint
> > 
> > 
> > 
> > At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> > 
> >>If I am getting you right, you are saying that the exensions in the
> >>self-signed certificate of a trust anchor (root CA) should 
> be ignored. 
> >>This is quite suprising to me!
> > 
> > 
> > Unfortunately that is what X.509 has said for some time, 
> and 3280 has 
> > not deviated in this regard. I too was surprised by this initially.
> > 
> > I discussed this issue with Sharon some time ago, noting that, for 
> > example, one would like to impose name constraints through 
> > configuration of trust anchors and the TA exception to the general 
> > processing rules prohibits that.  So I agree completely 
> that I would 
> > like to see at least SOME of the constraints in a trust 
> anchor cert be 
> > applied to cert path processing, although one needs to carefully 
> > examine the implications of doing this.
> > 
> > BTW, Santosh is correct in noting that TAs are not literally certs, 
> > even though self-signed certs are often used as a means of 
> > representing TAs. However, since we admit that a TA can contain 
> > parameters other than the TA name and key info, I think it is 
> > reasonable to allow for the full range of extensions that 
> might appear 
> > in a CA cert, and to then use them (most of them?) to control path 
> > processing.
> > 
> > Steve
> > 
> 
> *******************Internet Email Confidentiality 
> Footer*******************
> 
> 
> Qualsiasi utilizzo non autorizzato del presente messaggio 
> nonché dei suoi allegati è vietato e potrebbe costituire 
> reato. Se ha ricevuto per errore il presente messaggio, Le 
> saremmo grati se ci inviasse, via e-mail, una comunicazione 
> al riguardo e provvedesse nel contempo alla distruzione del 
> messaggio stesso e dei suoi eventuali allegati. Le 
> dichiarazioni contenute nel presente messaggio nonche' nei 
> suoi eventuali allegati devono essere attribuite 
> esclusivamente al mittente e non possono essere considerate 
> come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime 
> dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del 
> destinatario o di terzi. 
> ACTALIS S.p.A. non si assume alcuna responsabilita' per 
> eventuali intercettazioni, modifiche o danneggiamenti del 
> presente messaggio e-mail. 
> 
> 
> 
> Any unauthorized use of this e-mail or any of its attachments 
> is prohibited and could constitute an offence. If you are not 
> the intended addressee please advise immediately the sender 
> by using the reply facility in your e-mail software and 
> destroy the message and its attachments. The statements and 
> opinions expressed in this e-mail message are those of the 
> author of the message and do not necessarily represent those 
> of ACTALIS S.p.A. Besides, The contents of this message shall 
> be understood as neither given nor endorsed by ACTALIS S.p.A.. 
> ACTALIS S.p.A. does not accept liability for corruption, 
> interception or amendment, if any, or the consequences thereof.
> 
> 
> 

content-class: urn:content-classes:message
Subject: Question - certificate status in past
Date: Wed, 1 Sep 2004 11:19:00 +0200
From: "Pinkava Jaroslav" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C49004.B7B7459B
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

I couldn=B4t find answer to the following question. For CA services =
would be useful service

giving answer to simple question.:

There is given a certificate, and moment of time (in the past). I want =
know status of certificate

exactly in this time moment.

I have no implemented OCSP nor DVCS, but I want follow pkix =
recomendation.

What is the simplest way?

=20

Thank You in Advance.

                      Jaroslav

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

Ing. Jaroslav Pinkava, CSc.,=20

Security Consultant

telefon: +420 541 558 281

mobil:  +420 604 222 854

fax:    +420 541 558 303

e-mail: [email-masked]

http://crypto-world.info/=20

=20

PVT  a.s.,=20

Veve=F8=ED 102=20

602 00, Brno

www.pvt.cz <file:///\\www.pvt.cz\>=20

=20

------_=_NextPart_001_01C49004.B7B7459B
Content-Type: text/html;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-2">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.StylZprvyElektronickPoty17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DCS link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I couldn=B4t find answer to the following question. =
For CA
services would be useful service</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>giving answer to simple question.:</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>There is given a certificate, and moment of time (in =
the
past). I want know status of certificate</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>exactly in this time moment.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I have no implemented OCSP nor DVCS, but I want =
follow pkix
recomendation.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>What is the simplest way?</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'>Thank You in Advance.</span></font></p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>Ing.
Jaroslav Pinkava, CSc., </span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>Security
Consultant</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>telefon:
+420 541 558 281</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>mobil:&nbsp;
+420 604 222 854</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>fax:&nbsp;&nbsp;&nbsp;
+420 541 558 303</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>e-mail:
[email-masked]</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'><a
href=3D"http://crypto-world.info/">http://crypto-world.info/</a> =
</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><font size=3D3 =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>PVT&nbsp;
a.s., </span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>Veve=F8=ED
102 </span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'>602 00,
Brno</span></font></i></p>

<p class=3DMsoNormal style=3D'line-height:12.0pt'><i><font size=3D1
face=3D"Times New Roman"><span =
style=3D'font-size:8.0pt;font-style:italic'><a
href=3D"file:///\\www.pvt.cz\">www.pvt.cz</a></span></font></i></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C49004.B7B7459B--

Content-Class: urn:content-classes:message
Subject: R: R: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 09:22:35 +0200
Importance: normal
From: "Santoni Adriano" <[email-masked]>
To: "Steve Hanna" <[email-masked]>, "Santosh Chokhani" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

<<However, CAs who expect to act as trust anchors and issue self-signed certificates for that purpose should not assume that all path validation implementations will do this. If they REALLY want to ensure that path lengths are limited, they should certify a subsidiary CA and include a pathLen constraint in that certificate.>>

>From the various contributes to this thread, it turns out that processing extensions in a TA certificate is allowed and may be useful but - in general - is not recommendable (sic) because it is not mandated by RFC 3280 and therefore the average application may not honour extensions in TAs. 

Does not this lead to a paradox? Being a TA is a subjective attribute of a CA certificate, i.e. the same CA certificate can be or not be a TA depending on the entity that is using that certificate in a path validation process. Now, suppose a root CA1 issues a certificate for a subordinate CA2, putting pathLenConstraint=0 in the CA2 certificate. Then, enforcing that constraint would depend on CA2 being considered a TA or not. This can make sense from the point of view of the end user, but certainly not from the point of view of the root CA1, that most probably put that constraint in the CA2 for policy reasons. Even if the user regards CA2 as a TA, rather than CA1, from the point of view of CA1 that does not mean that he (the user) can ignore the (critical) extensions in the CA2 certificate!
               
Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Steve Hanna
Inviato: martedì 31 agosto 2004 22.05
A: Santosh Chokhani
Cc: [email-masked]
Oggetto: Re: R: On cross-certificates and pathLenConstraint

RFC 3280 says in section 6.1:

    A particular certification path may not, however, be appropriate for
    all applications.  Therefore, an application MAY augment this
    algorithm to further limit the set of valid paths.

and in section 6.2:

    An implementation that supports multiple trust anchors
    MAY augment the algorithm presented in section 6.1 to further limit
    the set of valid certification paths which begin with a particular
    trust anchor.  For example, an implementation MAY modify the
    algorithm to apply name constraints to a specific trust anchor during
    the initialization phase, or the application MAY require the presence
    of a particular alternative name form in the end entity certificate,
    or the application MAY impose requirements on application-specific
    extensions.  Thus, the path validation algorithm presented in section
    6.1 defines the minimum conditions for a path to be considered valid.

Therefore, I believe that path validation implementations
can go beyond the usual path validation algorithm to impose
any additional requirements on paths that it likes (unless specifically prohibited by RFC 3280). This would include processing name constraints in trust anchors, pathLenConstraints in trust anchors, etc.

However, CAs who expect to act as trust anchors and issue self-signed certificates for that purpose should not assume that all path validation implementations will do this. If they REALLY want to ensure that path lengths are limited, they should certify a subsidiary CA and include a pathLen constraint in that certificate.

Now, there's a separate question about whether processing constraints in trust anchors is a good idea. I would argue that it's not. But that's a topic for another email.

Thanks,

Steve

Santosh Chokhani wrote:

> Steve Kent:
> 
> We could take extensions in the TA and use them to initialize a 
> certification path values permitted by 3280, but for values such as 
> path length that 3280 does not permit initialization of to an 
> arbitrary value, it will require a change in the standard.
> 
> From security viewpoint, I do not object to it, but it is a change to 
> the standard.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Tuesday, August 31, 2004 9:51 AM
> To: Santoni Adriano
> Cc: [email-masked]
> Subject: Re: R: On cross-certificates and pathLenConstraint
> 
> 
> 
> At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> 
>>If I am getting you right, you are saying that the exensions in the 
>>self-signed certificate of a trust anchor (root CA) should be ignored. 
>>This is quite suprising to me!
> 
> 
> Unfortunately that is what X.509 has said for some time, and 3280 has
> not deviated in this regard. I too was surprised by this initially.
> 
> I discussed this issue with Sharon some time ago, noting that, for
> example, one would like to impose name constraints through 
> configuration of trust anchors and the TA exception to the general 
> processing rules prohibits that.  So I agree completely that I would 
> like to see at least SOME of the constraints in a trust anchor cert 
> be applied to cert path processing, although one needs to carefully 
> examine the implications of doing this.
> 
> BTW, Santosh is correct in noting that TAs are not literally certs,
> even though self-signed certs are often used as a means of 
> representing TAs. However, since we admit that a TA can contain 
> parameters other than the TA name and key info, I think it is 
> reasonable to allow for the full range of extensions that might 
> appear in a CA cert, and to then use them (most of them?) to control 
> path processing.
> 
> Steve
> 

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

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

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