RE: R: On cross-certificates and pathLenConstraint

["Stefan Santesson" <[e-mail]>]

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: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Steve Hanna
> Sent: den 31 augusti 2004 22:05
> To: Santosh Chokhani
> Cc: [e-mail]
> 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: [e-mail]
[mailto:[e-mail]]
> On
> > Behalf Of Stephen Kent
> > Sent: Tuesday, August 31, 2004 9:51 AM
> > To: Santoni Adriano
> > Cc: [e-mail]
> > 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
> >





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VNqDbs018717; Tue, 31 Aug 2004 16:52:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VNqDY2018716; Tue, 31 Aug 2004 16:52:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VNqB2W018665 for <[e-mail]>; Tue, 31 Aug 2004 16:52:11 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Sep 2004 00:52:04 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: R: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 00:52:07 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: On cross-certificates and pathLenConstraint
Thread-Index: AcSPoCo6xr7v7oQbT3eA7WhznlAWWgAFMSEA
From: "Stefan Santesson" <[e-mail]>
To: "Steve Hanna" <[e-mail]>, "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 31 Aug 2004 23:52:04.0720 (UTC) FILETIME=[84730700:01C48FB5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VNqC2W018706
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks 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: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Steve Hanna
> Sent: den 31 augusti 2004 22:05
> To: Santosh Chokhani
> Cc: [e-mail]
> 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: [e-mail]
[mailto:[e-mail]]
> On
> > Behalf Of Stephen Kent
> > Sent: Tuesday, August 31, 2004 9:51 AM
> > To: Santoni Adriano
> > Cc: [e-mail]
> > 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
> >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VK5Dw4074004; Tue, 31 Aug 2004 13:05:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VK5Djo074003; Tue, 31 Aug 2004 13:05:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from trilmail.funk.com (26-71-51-66.reonbroadband.com [66.51.71.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VK5CCC073968 for <[e-mail]>; Tue, 31 Aug 2004 13:05:12 -0700 (PDT) (envelope-from [e-mail])
Received: from [127.0.0.1] (HANNAXP [192.168.21.23]) by trilmail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RX8MWBKK; Tue, 31 Aug 2004 16:05:05 -0400
Message-ID: <[e-mail]>
Date: Tue, 31 Aug 2004 16:05:10 -0400
From: Steve Hanna <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: R: On cross-certificates and pathLenConstraint
References: <01df01c48f71$428e8790$[e-mail]>
In-Reply-To: <01df01c48f71$428e8790$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

RFC 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Stephen Kent
> Sent: Tuesday, August 31, 2004 9:51 AM
> To: Santoni Adriano
> Cc: [e-mail]
> 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
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VHLXfl042188; Tue, 31 Aug 2004 10:21:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VHLXRD042187; Tue, 31 Aug 2004 10:21:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VHLW8X042146 for <[e-mail]>; Tue, 31 Aug 2004 10:21:32 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7VHLON03379; Tue, 31 Aug 2004 19:21:24 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 31 Aug 2004 19:21:24 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7VHLNi25106; Tue, 31 Aug 2004 19:21:23 +0200 (MEST)
Date: Tue, 31 Aug 2004 19:21:23 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> 
> RFC 3280 allows you to augment the path validation algorithm in any way you want as long as it is further limiting trust.
> 
> Adjusting the max_path_length variable in accordance with a root is fully compliant with this.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  

You don't necessarily need to augment the algorithm in any way to get this effect. Just take 'yourself' as trust anchor
and issue 'cross-certs' with whatever restrictions. 

Or, the other way around, anything that you would have created at intermediate steps
down in the validation algorithm should be usable as initial values. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VH6eoD039507; Tue, 31 Aug 2004 10:06:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VH6dpp039502; Tue, 31 Aug 2004 10:06:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm1.entrust.com (sottmxssm1.entrust.com [216.191.252.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VH6bw0039348 for <[e-mail]>; Tue, 31 Aug 2004 10:06:38 -0700 (PDT) (envelope-from [e-mail])
Received: from SOTTMXS01.entrust.com ([10.4.61.7]) by sottmxssm1.entrust.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7VHZhao017416; Tue, 31 Aug 2004 13:35:43 -0400
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2657.72) id <Q2Q0V9BZ>; Tue, 31 Aug 2004 13:06:35 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 13:06:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Agreed

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 11:17 AM
To: [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint



Sharon:

I agree that one is at liberty to take material from a trust anchor and use
to initialize the values for which X.509 and 3280 permit initialization.

However, part of this thread relates to basic constraints and path length.
For basic constraints, there is nothing to initialize.  X.509 and 3280 deal
with path length slightly differently (but in equivalent terms).  Thus, 3280
requires the value to be initialized from the length of the certification
path and X.509 initializes path depth to 1.  Thus, based on today's
standards, in neither case, you will take path length from the trust anchor
and initialize it.



-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]] 
Sent: Tuesday, August 31, 2004 10:45 AM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint


I'm always afraid to just say yes, because of nuances in phrasing :-)

On the first statement I can just say yes I agree.

On the second statement, I need to be a little bit more precise. I would
agree with the following "When you enforce constraints on the trust anchor
certificate as part of certificate processing in path validation, that is
not in compliance with the standard." However, if someone uses the relevant
constraints in the trust anchor certificate to initialize the path
validation variables or process constraints, then I would not say they were
non-compliant because the standard doesn't impose any particular source for
those variables values. That certificate is one possible source, but there
are others as well. 

Cheers,
Sharon 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 10:07 AM
To: [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint



Sharon:

So, you agree with the following statements.  Right?

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

-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]] 
Sent: Tuesday, August 31, 2004 9:57 AM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint


I just want to clarify that I absolutely agree that any extensions contained
in a self-signed cert are NOT processed as part of path validation. The self
signed cert is NOT part of the path that gets processed. It is a mechanism
that MAY be used to convey the public key that is used to verify the
signature on the first cert processed in the path. 

What I was trying to explain earlier is that if a self-signed certificate is
used to convey the public key of the CA that is the trust anchor to relying
parties there may be some extensions in that self signed certificate.
Because the self signed certificate is not part of the certification path,
it does not get processed in path validation. However the standards say
nothing about what other uses an implementor may decide to make of such
extensions. The example I gave was where an implementor may decide to use
those to ensure that a subordinate CA does not even issue certificates to
other CAs. Another possible use would be, as Santosh describes, to use those
values to configure the input variables to the path validation process (what
I was referring to as process constraints). However, those are separate from
path validation processing of certificates. 

I also agree with Santosh that X.509 is moving in a direction that enables
more variables to be inititalized (e.g. name constraints). However I don't
expect any standards defining what implementors use to intitalize those
values. In some cases it might be reasonable to use the extensions in a self
signed certificate. In other cases there could be other sources (especially
if there is a need to configure those input variables on a per user group,
per user, per application or even per transaction basis).

Cheers,
Sharon
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 7:47 AM
To: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 6:26 AM
To: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [e-mail]
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: [e-mail]
> [mailto:[e-mail]]
> On Behalf Of Santoni Adriano
> Sent: den 31 augusti 2004 09:26
> To: Peter Hesse; David P. Kemp
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> Per conto di Peter Hesse
> Inviato: lunedì 30 agosto 2004 18.43
> A: 'David P. Kemp'; [e-mail]
> 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                    [e-mail]     |
> | Phone: [phone]         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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of David P. Kemp
> > Sent: Monday, August 30, 2004 11:51 AM
> > To: [e-mail]
> > 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:[e-mail]]
> > >Sent: Saturday, August 28, 2004 5:10 AM
> > >To: Santosh Chokhani; [e-mail]
> > >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: [e-mail]
> > >>[mailto:[e-mail]]
> > >>On Behalf Of Santosh Chokhani
> > >>Sent: den 28 augusti 2004 00:52
> > >>To: [e-mail]
> > >>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: [e-mail]
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 9:28 AM
> > >>To: Sharon Boeyen
> > >>Cc: [e-mail]
> > >>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:[e-mail]]
> > >>Inviato: venerdì 27 agosto 2004 14.34
> > >>A: Santoni Adriano; [e-mail]
> > >>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: [e-mail]
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 5:37 AM
> > >>To: [e-mail]
> > >>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.
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VGa4El033743; Tue, 31 Aug 2004 09:36:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VGa412033742; Tue, 31 Aug 2004 09:36:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VGa24a033722 for <[e-mail]>; Tue, 31 Aug 2004 09:36:03 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 17:36:02 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 17:35:34 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: On cross-certificates and pathLenConstraint
Thread-Index: AcSPd/EWlmvUp69/TpOTOAQ1lRqxugAAERlg
From: "Stefan Santesson" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 31 Aug 2004 16:36:02.0498 (UTC) FILETIME=[9A8CC220:01C48F78]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VGa34a033737
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

RFC 3280 allows you to augment the path validation algorithm in any way you want as long as it is further limiting trust.

Adjusting the max_path_length variable in accordance with a root is fully compliant with this.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 31 augusti 2004 17:17
> To: [e-mail]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Sharon:
> 
> I agree that one is at liberty to take material from a trust anchor and
> use
> to initialize the values for which X.509 and 3280 permit initialization.
> 
> However, part of this thread relates to basic constraints and path length.
> For basic constraints, there is nothing to initialize.  X.509 and 3280
> deal
> with path length slightly differently (but in equivalent terms).  Thus,
> 3280
> requires the value to be initialized from the length of the certification
> path and X.509 initializes path depth to 1.  Thus, based on today's
> standards, in neither case, you will take path length from the trust
> anchor
> and initialize it.
> 
> 
> 
> -----Original Message-----
> From: Sharon Boeyen [mailto:[e-mail]]
> Sent: Tuesday, August 31, 2004 10:45 AM
> To: 'Santosh Chokhani'; [e-mail]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> I'm always afraid to just say yes, because of nuances in phrasing :-)
> 
> On the first statement I can just say yes I agree.
> 
> On the second statement, I need to be a little bit more precise. I would
> agree with the following "When you enforce constraints on the trust anchor
> certificate as part of certificate processing in path validation, that is
> not in compliance with the standard." However, if someone uses the
> relevant
> constraints in the trust anchor certificate to initialize the path
> validation variables or process constraints, then I would not say they
> were
> non-compliant because the standard doesn't impose any particular source
> for
> those variables values. That certificate is one possible source, but there
> are others as well.
> 
> Cheers,
> Sharon
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On
> Behalf Of Santosh Chokhani
> Sent: Tuesday, August 31, 2004 10:07 AM
> To: [e-mail]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> Sharon:
> 
> So, you agree with the following statements.  Right?
> 
> "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."
> 
> -----Original Message-----
> From: Sharon Boeyen [mailto:[e-mail]]
> Sent: Tuesday, August 31, 2004 9:57 AM
> To: 'Santosh Chokhani'; [e-mail]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> I just want to clarify that I absolutely agree that any extensions
> contained
> in a self-signed cert are NOT processed as part of path validation. The
> self
> signed cert is NOT part of the path that gets processed. It is a mechanism
> that MAY be used to convey the public key that is used to verify the
> signature on the first cert processed in the path.
> 
> What I was trying to explain earlier is that if a self-signed certificate
> is
> used to convey the public key of the CA that is the trust anchor to
> relying
> parties there may be some extensions in that self signed certificate.
> Because the self signed certificate is not part of the certification path,
> it does not get processed in path validation. However the standards say
> nothing about what other uses an implementor may decide to make of such
> extensions. The example I gave was where an implementor may decide to use
> those to ensure that a subordinate CA does not even issue certificates to
> other CAs. Another possible use would be, as Santosh describes, to use
> those
> values to configure the input variables to the path validation process
> (what
> I was referring to as process constraints). However, those are separate
> from
> path validation processing of certificates.
> 
> I also agree with Santosh that X.509 is moving in a direction that enables
> more variables to be inititalized (e.g. name constraints). However I don't
> expect any standards defining what implementors use to intitalize those
> values. In some cases it might be reasonable to use the extensions in a
> self
> signed certificate. In other cases there could be other sources
> (especially
> if there is a need to configure those input variables on a per user group,
> per user, per application or even per transaction basis).
> 
> Cheers,
> Sharon
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On
> Behalf Of Santosh Chokhani
> Sent: Tuesday, August 31, 2004 7:47 AM
> To: [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 6:26 AM
> To: Santoni Adriano; Peter Hesse; David P. Kemp
> Cc: [e-mail]
> 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: [e-mail]
> > [mailto:[e-mail]]
> > On Behalf Of Santoni Adriano
> > Sent: den 31 augusti 2004 09:26
> > To: Peter Hesse; David P. Kemp
> > Cc: [e-mail]
> > 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: [e-mail] [mailto:[e-mail]]
> > Per conto di Peter Hesse
> > Inviato: lunedì 30 agosto 2004 18.43
> > A: 'David P. Kemp'; [e-mail]
> > 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                    [e-mail]     |
> > | Phone: [phone]         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: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of David P. Kemp
> > > Sent: Monday, August 30, 2004 11:51 AM
> > > To: [e-mail]
> > > 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:[e-mail]]
> > > >Sent: Saturday, August 28, 2004 5:10 AM
> > > >To: Santosh Chokhani; [e-mail]
> > > >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: [e-mail]
> > > >>[mailto:[e-mail]]
> > > >>On Behalf Of Santosh Chokhani
> > > >>Sent: den 28 augusti 2004 00:52
> > > >>To: [e-mail]
> > > >>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: [e-mail]
> > > >>[mailto:[e-mail]]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 9:28 AM
> > > >>To: Sharon Boeyen
> > > >>Cc: [e-mail]
> > > >>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:[e-mail]]
> > > >>Inviato: venerdì 27 agosto 2004 14.34
> > > >>A: Santoni Adriano; [e-mail]
> > > >>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: [e-mail]
> > > >>[mailto:[e-mail]]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 5:37 AM
> > > >>To: [e-mail]
> > > >>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.
> >
> >
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VGTRxq032676; Tue, 31 Aug 2004 09:29:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VGTRLr032675; Tue, 31 Aug 2004 09:29:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp002.bizmail.yahoo.com (smtp002.bizmail.yahoo.com [216.136.172.126]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7VGTQo0032669 for <[e-mail]>; Tue, 31 Aug 2004 09:29:26 -0700 (PDT) (envelope-from [e-mail])
Received: from unknown (HELO ieca.com) ([e-mail]@70.17.75.218 with plain) by smtp002.bizmail.yahoo.com with SMTP; 31 Aug 2004 16:29:27 -0000
Message-ID: <[e-mail]>
Date: Tue, 31 Aug 2004 12:25:03 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: RFC3280 Nits
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here's two nits on RFC3280:

1. In 4.1.2.4 (Issuer) - the ASN.1 for NAME is

Name ::= CHOICE { RDNSequence }

but in the ASN.1 module it's:

Name ::= CHOICE { -- only one possibility for now --
rdnSequence RDNSequence }

2. Additionally in 4.1.2.4 it's

RelativeDistinguishedName ::= SET OF AttributeTypeAndValue

While in the module it's:

RelativeDistinguishedName ::= SET SIZE (1 .. MAX) OF AttributeTypeAndValue

Just want to make them the same.  I assume it ought to match what's in
the ASN.1 module.

Cheers - spt





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VGJdwl031949; Tue, 31 Aug 2004 09:19:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VGJdGD031948; Tue, 31 Aug 2004 09:19:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VGJcPE031939 for <[e-mail]>; Tue, 31 Aug 2004 09:19:38 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7VGJZod013917 for <[e-mail]>; Tue, 31 Aug 2004 12:19:35 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 12:19:31 -0400
Message-ID: <01f401c48f76$4eaeadc0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VGJdPE031943
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan:

I think 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:[e-mail]] 
Sent: Tuesday, August 31, 2004 11:32 AM
To: Santosh Chokhani; [e-mail]
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: [e-mail]
> [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 31 augusti 2004 13:47
> To: [e-mail]
> 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: [e-mail]
> [mailto:[e-mail]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 6:26 AM
> To: Santoni Adriano; Peter Hesse; David P. Kemp
> Cc: [e-mail]
> 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: [e-mail]
> > [mailto:[e-mail]]
> > On Behalf Of Santoni Adriano
> > Sent: den 31 augusti 2004 09:26
> > To: Peter Hesse; David P. Kemp
> > Cc: [e-mail]
> > 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: [e-mail]
> > [mailto:[e-mail]]
> > Per conto di Peter Hesse
> > Inviato: lunedì 30 agosto 2004 18.43
> > A: 'David P. Kemp'; [e-mail]
> > 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                    [e-mail]     |
> > | Phone: [phone]         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: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of David P. Kemp
> > > Sent: Monday, August 30, 2004 11:51 AM
> > > To: [e-mail]
> > > 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:[e-mail]]
> > > >Sent: Saturday, August 28, 2004 5:10 AM
> > > >To: Santosh Chokhani; [e-mail]
> > > >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: [e-mail]
> > > >>[mailto:[e-mail]]
> > > >>On Behalf Of Santosh Chokhani
> > > >>Sent: den 28 augusti 2004 00:52
> > > >>To: [e-mail]
> > > >>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: [e-mail]
> > > >>[mailto:[e-mail]]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 9:28 AM
> > > >>To: Sharon Boeyen
> > > >>Cc: [e-mail]
> > > >>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:[e-mail]]
> > > >>Inviato: venerdì 27 agosto 2004 14.34
> > > >>A: Santoni Adriano; [e-mail]
> > > >>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: [e-mail]
> > > >>[mailto:[e-mail]]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 5:37 AM
> > > >>To: [e-mail]
> > > >>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.
> >
> >
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFhUcm027039; Tue, 31 Aug 2004 08:43:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VFhUok027038; Tue, 31 Aug 2004 08:43:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFhPKf027020 for <[e-mail]>; Tue, 31 Aug 2004 08:43:29 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7VFhRod000878 for <[e-mail]>; Tue, 31 Aug 2004 11:43:28 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: R: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 11:43:16 -0400
Message-ID: <01df01c48f71$428e8790$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <p06110402bd5a30d557c3@[128.89.89.75]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VFhTKf027033
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve 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: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Tuesday, August 31, 2004 9:51 AM
To: Santoni Adriano
Cc: [e-mail]
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




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFWTEK025033; Tue, 31 Aug 2004 08:32:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VFWSvA025032; Tue, 31 Aug 2004 08:32:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFWRHD025013 for <[e-mail]>; Tue, 31 Aug 2004 08:32:27 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 16:32:04 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 16:31:55 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: On cross-certificates and pathLenConstraint
Thread-Index: AcSPW0j8RHOmwtxWROyvQtKDtSyq/AAEon/g
From: "Stefan Santesson" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 31 Aug 2004 15:32:04.0628 (UTC) FILETIME=[AB004540:01C48F6F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VFWSHD025027
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

You are 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: [e-mail] [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 31 augusti 2004 13:47
> To: [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 6:26 AM
> To: Santoni Adriano; Peter Hesse; David P. Kemp
> Cc: [e-mail]
> 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: [e-mail]
> > [mailto:[e-mail]]
> > On Behalf Of Santoni Adriano
> > Sent: den 31 augusti 2004 09:26
> > To: Peter Hesse; David P. Kemp
> > Cc: [e-mail]
> > 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: [e-mail] [mailto:[e-mail]]
> > Per conto di Peter Hesse
> > Inviato: lunedì 30 agosto 2004 18.43
> > A: 'David P. Kemp'; [e-mail]
> > 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                    [e-mail]     |
> > | Phone: [phone]         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: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of David P. Kemp
> > > Sent: Monday, August 30, 2004 11:51 AM
> > > To: [e-mail]
> > > 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:[e-mail]]
> > > >Sent: Saturday, August 28, 2004 5:10 AM
> > > >To: Santosh Chokhani; [e-mail]
> > > >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: [e-mail]
> > > >>[mailto:[e-mail]]
> > > >>On Behalf Of Santosh Chokhani
> > > >>Sent: den 28 augusti 2004 00:52
> > > >>To: [e-mail]
> > > >>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: [e-mail]
> > > >>[mailto:[e-mail]]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 9:28 AM
> > > >>To: Sharon Boeyen
> > > >>Cc: [e-mail]
> > > >>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:[e-mail]]
> > > >>Inviato: venerdì 27 agosto 2004 14.34
> > > >>A: Santoni Adriano; [e-mail]
> > > >>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: [e-mail]
> > > >>[mailto:[e-mail]]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 5:37 AM
> > > >>To: [e-mail]
> > > >>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.
> >
> >
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFHWXh022359; Tue, 31 Aug 2004 08:17:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VFHW2b022358; Tue, 31 Aug 2004 08:17:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VFHVIF022349 for <[e-mail]>; Tue, 31 Aug 2004 08:17:31 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7VFHXod022521 for <[e-mail]>; Tue, 31 Aug 2004 11:17:33 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 11:17:20 -0400
Message-ID: <01d401c48f6d$a3d50370$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VFHWIF022351
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sharon:

I agree that one is at liberty to take material from a trust anchor and use
to initialize the values for which X.509 and 3280 permit initialization.

However, part of this thread relates to basic constraints and path length.
For basic constraints, there is nothing to initialize.  X.509 and 3280 deal
with path length slightly differently (but in equivalent terms).  Thus, 3280
requires the value to be initialized from the length of the certification
path and X.509 initializes path depth to 1.  Thus, based on today's
standards, in neither case, you will take path length from the trust anchor
and initialize it.



-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]] 
Sent: Tuesday, August 31, 2004 10:45 AM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint


I'm always afraid to just say yes, because of nuances in phrasing :-)

On the first statement I can just say yes I agree.

On the second statement, I need to be a little bit more precise. I would
agree with the following "When you enforce constraints on the trust anchor
certificate as part of certificate processing in path validation, that is
not in compliance with the standard." However, if someone uses the relevant
constraints in the trust anchor certificate to initialize the path
validation variables or process constraints, then I would not say they were
non-compliant because the standard doesn't impose any particular source for
those variables values. That certificate is one possible source, but there
are others as well. 

Cheers,
Sharon 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 10:07 AM
To: [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint



Sharon:

So, you agree with the following statements.  Right?

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

-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]] 
Sent: Tuesday, August 31, 2004 9:57 AM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint


I just want to clarify that I absolutely agree that any extensions contained
in a self-signed cert are NOT processed as part of path validation. The self
signed cert is NOT part of the path that gets processed. It is a mechanism
that MAY be used to convey the public key that is used to verify the
signature on the first cert processed in the path. 

What I was trying to explain earlier is that if a self-signed certificate is
used to convey the public key of the CA that is the trust anchor to relying
parties there may be some extensions in that self signed certificate.
Because the self signed certificate is not part of the certification path,
it does not get processed in path validation. However the standards say
nothing about what other uses an implementor may decide to make of such
extensions. The example I gave was where an implementor may decide to use
those to ensure that a subordinate CA does not even issue certificates to
other CAs. Another possible use would be, as Santosh describes, to use those
values to configure the input variables to the path validation process (what
I was referring to as process constraints). However, those are separate from
path validation processing of certificates. 

I also agree with Santosh that X.509 is moving in a direction that enables
more variables to be inititalized (e.g. name constraints). However I don't
expect any standards defining what implementors use to intitalize those
values. In some cases it might be reasonable to use the extensions in a self
signed certificate. In other cases there could be other sources (especially
if there is a need to configure those input variables on a per user group,
per user, per application or even per transaction basis).

Cheers,
Sharon
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 7:47 AM
To: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 6:26 AM
To: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [e-mail]
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: [e-mail] 
> [mailto:[e-mail]]
> On Behalf Of Santoni Adriano
> Sent: den 31 augusti 2004 09:26
> To: Peter Hesse; David P. Kemp
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> Per conto di Peter Hesse
> Inviato: lunedì 30 agosto 2004 18.43
> A: 'David P. Kemp'; [e-mail]
> 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                    [e-mail]     |
> | Phone: [phone]         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: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of David P. Kemp
> > Sent: Monday, August 30, 2004 11:51 AM
> > To: [e-mail]
> > 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:[e-mail]]
> > >Sent: Saturday, August 28, 2004 5:10 AM
> > >To: Santosh Chokhani; [e-mail]
> > >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: [e-mail] 
> > >>[mailto:[e-mail]]
> > >>On Behalf Of Santosh Chokhani
> > >>Sent: den 28 augusti 2004 00:52
> > >>To: [e-mail]
> > >>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: [e-mail] 
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 9:28 AM
> > >>To: Sharon Boeyen
> > >>Cc: [e-mail]
> > >>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:[e-mail]]
> > >>Inviato: venerdì 27 agosto 2004 14.34
> > >>A: Santoni Adriano; [e-mail]
> > >>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: [e-mail] 
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 5:37 AM
> > >>To: [e-mail]
> > >>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.
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VEjToT017511; Tue, 31 Aug 2004 07:45:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VEjTOs017510; Tue, 31 Aug 2004 07:45:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm1.entrust.com (sottmxssm1.entrust.com [216.191.252.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VEjRSH017481 for <[e-mail]>; Tue, 31 Aug 2004 07:45:28 -0700 (PDT) (envelope-from [e-mail])
Received: from SOTTMXS01.entrust.com ([10.4.61.7]) by sottmxssm1.entrust.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7VFETTk029501; Tue, 31 Aug 2004 11:14:29 -0400
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2657.72) id <Q2Q0VTFZ>; Tue, 31 Aug 2004 10:45:22 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 10:45:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm always afraid to just say yes, because of nuances in phrasing :-)

On the first statement I can just say yes I agree.

On the second statement, I need to be a little bit more precise. I would
agree with the following "When you enforce constraints on the trust anchor
certificate as part of certificate processing in path validation, that is
not in compliance with the standard." However, if someone uses the relevant
constraints in the trust anchor certificate to initialize the path
validation variables or process constraints, then I would not say they were
non-compliant because the standard doesn't impose any particular source for
those variables values. That certificate is one possible source, but there
are others as well. 

Cheers,
Sharon 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 10:07 AM
To: [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint



Sharon:

So, you agree with the following statements.  Right?

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

-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]] 
Sent: Tuesday, August 31, 2004 9:57 AM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint


I just want to clarify that I absolutely agree that any extensions contained
in a self-signed cert are NOT processed as part of path validation. The self
signed cert is NOT part of the path that gets processed. It is a mechanism
that MAY be used to convey the public key that is used to verify the
signature on the first cert processed in the path. 

What I was trying to explain earlier is that if a self-signed certificate is
used to convey the public key of the CA that is the trust anchor to relying
parties there may be some extensions in that self signed certificate.
Because the self signed certificate is not part of the certification path,
it does not get processed in path validation. However the standards say
nothing about what other uses an implementor may decide to make of such
extensions. The example I gave was where an implementor may decide to use
those to ensure that a subordinate CA does not even issue certificates to
other CAs. Another possible use would be, as Santosh describes, to use those
values to configure the input variables to the path validation process (what
I was referring to as process constraints). However, those are separate from
path validation processing of certificates. 

I also agree with Santosh that X.509 is moving in a direction that enables
more variables to be inititalized (e.g. name constraints). However I don't
expect any standards defining what implementors use to intitalize those
values. In some cases it might be reasonable to use the extensions in a self
signed certificate. In other cases there could be other sources (especially
if there is a need to configure those input variables on a per user group,
per user, per application or even per transaction basis).

Cheers,
Sharon
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 7:47 AM
To: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 6:26 AM
To: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [e-mail]
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: [e-mail]
> [mailto:[e-mail]]
> On Behalf Of Santoni Adriano
> Sent: den 31 augusti 2004 09:26
> To: Peter Hesse; David P. Kemp
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> Per conto di Peter Hesse
> Inviato: lunedì 30 agosto 2004 18.43
> A: 'David P. Kemp'; [e-mail]
> 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                    [e-mail]     |
> | Phone: [phone]         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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of David P. Kemp
> > Sent: Monday, August 30, 2004 11:51 AM
> > To: [e-mail]
> > 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:[e-mail]]
> > >Sent: Saturday, August 28, 2004 5:10 AM
> > >To: Santosh Chokhani; [e-mail]
> > >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: [e-mail]
> > >>[mailto:[e-mail]]
> > >>On Behalf Of Santosh Chokhani
> > >>Sent: den 28 augusti 2004 00:52
> > >>To: [e-mail]
> > >>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: [e-mail]
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 9:28 AM
> > >>To: Sharon Boeyen
> > >>Cc: [e-mail]
> > >>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:[e-mail]]
> > >>Inviato: venerdì 27 agosto 2004 14.34
> > >>A: Santoni Adriano; [e-mail]
> > >>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: [e-mail]
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 5:37 AM
> > >>To: [e-mail]
> > >>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.
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VEUf0H014851; Tue, 31 Aug 2004 07:30:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VEUfv3014850; Tue, 31 Aug 2004 07:30:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VEUejt014835 for <[e-mail]>; Tue, 31 Aug 2004 07:30:40 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i7VEUaQM758910; Tue, 31 Aug 2004 10:30:36 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7VEVRrn138678; Tue, 31 Aug 2004 10:31:35 -0400
In-Reply-To: <[e-mail]>
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: On cross-certificates and pathLenConstraint
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 31 Aug 2004 10:30:18 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 HFB2|July 19, 2004) at 08/31/2004 10:30:22, Serialize complete at 08/31/2004 10:30:22
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VEUfjt014844
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        David:

        IMHO your suggestion is how path validation should work, as I 
stated in a discussion with Santosh a few months ago (
http://www.imc.org/ietf-pkix/mail-archive/msg02707.html).  Unfortunately, 
it is not how RFC 3280 6.1.2 k works - that initializes the maximum 
allowable length to the length of the path being tested.  Steve Hanna, in 
that same thread (http://www.imc.org/ietf-pkix/mail-archive/msg02717.html
), suggested that the first paragraph of 6.2 gave sufficient warrant to 
set the fields in the way I suggested in my posting if you want to, while 
still considering the validation algorithm 3280-compliant.  If you do that 
in your validation algorithm, it then becomes natural to honor 
NameConstraints and BasicConstraints from any v3 certificate which is 
being used to represent a trust anchor.  Of course, you can set the 
variables corresponding to those extensions from separate fields in your 
configuration database if you want to, or if you are using a v1 
certificate or bare public key to represent a trust anchor.
        Conditions on a trust anchor analogous to certificate extensions 
are natural.  What is IMO obscure is the meaning of the signature on a 
certificate being used to represent a trust anchor - the RP does not 
decide to trust or not trust the anchor based on that signature, but on 
its own independent judgment.

                Tom Gindin





"David P. Kemp" <[e-mail]>
Sent by: [e-mail]
08/30/2004 11:50 AM
 
        To:     [e-mail]
        cc: 
        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:[e-mail]] 
>Sent: Saturday, August 28, 2004 5:10 AM
>To: Santosh Chokhani; [e-mail]
>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: [e-mail] 
>>[mailto:[e-mail]]
>>On Behalf Of Santosh Chokhani
>>Sent: den 28 augusti 2004 00:52
>>To: [e-mail]
>>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: [e-mail] 
>>[mailto:[e-mail]]
>>On
>>Behalf Of Santoni Adriano
>>Sent: Friday, August 27, 2004 9:28 AM
>>To: Sharon Boeyen
>>Cc: [e-mail]
>>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:[e-mail]]
>>Inviato: venerdì 27 agosto 2004 14.34
>>A: Santoni Adriano; [e-mail]
>>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: [e-mail] 
>>[mailto:[e-mail]]
>>On
>>Behalf Of Santoni Adriano
>>Sent: Friday, August 27, 2004 5:37 AM
>>To: [e-mail]
>>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.
>>
>>
>>
>> 
>>
>
>
>
>
> 
>






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VE7Q2v011916; Tue, 31 Aug 2004 07:07:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VE7QPs011915; Tue, 31 Aug 2004 07:07:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VE7PHV011906 for <[e-mail]>; Tue, 31 Aug 2004 07:07:25 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7VE7Qod030449 for <[e-mail]>; Tue, 31 Aug 2004 10:07:26 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 10:07:22 -0400
Message-ID: <018701c48f63$d8d07190$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VE7PHV011909
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sharon:

So, you agree with the following statements.  Right?

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

-----Original Message-----
From: Sharon Boeyen [mailto:[e-mail]] 
Sent: Tuesday, August 31, 2004 9:57 AM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint


I just want to clarify that I absolutely agree that any extensions contained
in a self-signed cert are NOT processed as part of path validation. The self
signed cert is NOT part of the path that gets processed. It is a mechanism
that MAY be used to convey the public key that is used to verify the
signature on the first cert processed in the path. 

What I was trying to explain earlier is that if a self-signed certificate is
used to convey the public key of the CA that is the trust anchor to relying
parties there may be some extensions in that self signed certificate.
Because the self signed certificate is not part of the certification path,
it does not get processed in path validation. However the standards say
nothing about what other uses an implementor may decide to make of such
extensions. The example I gave was where an implementor may decide to use
those to ensure that a subordinate CA does not even issue certificates to
other CAs. Another possible use would be, as Santosh describes, to use those
values to configure the input variables to the path validation process (what
I was referring to as process constraints). However, those are separate from
path validation processing of certificates. 

I also agree with Santosh that X.509 is moving in a direction that enables
more variables to be inititalized (e.g. name constraints). However I don't
expect any standards defining what implementors use to intitalize those
values. In some cases it might be reasonable to use the extensions in a self
signed certificate. In other cases there could be other sources (especially
if there is a need to configure those input variables on a per user group,
per user, per application or even per transaction basis).

Cheers,
Sharon
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 7:47 AM
To: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 6:26 AM
To: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [e-mail]
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: [e-mail] 
> [mailto:[e-mail]]
> On Behalf Of Santoni Adriano
> Sent: den 31 augusti 2004 09:26
> To: Peter Hesse; David P. Kemp
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> Per conto di Peter Hesse
> Inviato: lunedì 30 agosto 2004 18.43
> A: 'David P. Kemp'; [e-mail]
> 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                    [e-mail]     |
> | Phone: [phone]         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: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of David P. Kemp
> > Sent: Monday, August 30, 2004 11:51 AM
> > To: [e-mail]
> > 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:[e-mail]]
> > >Sent: Saturday, August 28, 2004 5:10 AM
> > >To: Santosh Chokhani; [e-mail]
> > >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: [e-mail] 
> > >>[mailto:[e-mail]]
> > >>On Behalf Of Santosh Chokhani
> > >>Sent: den 28 augusti 2004 00:52
> > >>To: [e-mail]
> > >>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: [e-mail] 
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 9:28 AM
> > >>To: Sharon Boeyen
> > >>Cc: [e-mail]
> > >>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:[e-mail]]
> > >>Inviato: venerdì 27 agosto 2004 14.34
> > >>A: Santoni Adriano; [e-mail]
> > >>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: [e-mail] 
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 5:37 AM
> > >>To: [e-mail]
> > >>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.
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VDupUD009933; Tue, 31 Aug 2004 06:56:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VDupvs009932; Tue, 31 Aug 2004 06:56:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm1.entrust.com (sottmxssm1.entrust.com [216.191.252.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VDuo58009919 for <[e-mail]>; Tue, 31 Aug 2004 06:56:50 -0700 (PDT) (envelope-from [e-mail])
Received: from SOTTMXS01.entrust.com ([10.4.61.7]) by sottmxssm1.entrust.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7VEPrSx022059; Tue, 31 Aug 2004 10:25:53 -0400
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2657.72) id <Q2Q0VPMN>; Tue, 31 Aug 2004 09:56:47 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 09:56:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I just want to clarify that I absolutely agree that any extensions contained
in a self-signed cert are NOT processed as part of path validation. The self
signed cert is NOT part of the path that gets processed. It is a mechanism
that MAY be used to convey the public key that is used to verify the
signature on the first cert processed in the path. 

What I was trying to explain earlier is that if a self-signed certificate is
used to convey the public key of the CA that is the trust anchor to relying
parties there may be some extensions in that self signed certificate.
Because the self signed certificate is not part of the certification path,
it does not get processed in path validation. However the standards say
nothing about what other uses an implementor may decide to make of such
extensions. The example I gave was where an implementor may decide to use
those to ensure that a subordinate CA does not even issue certificates to
other CAs. Another possible use would be, as Santosh describes, to use those
values to configure the input variables to the path validation process (what
I was referring to as process constraints). However, those are separate from
path validation processing of certificates. 

I also agree with Santosh that X.509 is moving in a direction that enables
more variables to be inititalized (e.g. name constraints). However I don't
expect any standards defining what implementors use to intitalize those
values. In some cases it might be reasonable to use the extensions in a self
signed certificate. In other cases there could be other sources (especially
if there is a need to configure those input variables on a per user group,
per user, per application or even per transaction basis).

Cheers,
Sharon
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 7:47 AM
To: [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 6:26 AM
To: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [e-mail]
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: [e-mail]
> [mailto:[e-mail]]
> On Behalf Of Santoni Adriano
> Sent: den 31 augusti 2004 09:26
> To: Peter Hesse; David P. Kemp
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> Per conto di Peter Hesse
> Inviato: lunedì 30 agosto 2004 18.43
> A: 'David P. Kemp'; [e-mail]
> 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                    [e-mail]     |
> | Phone: [phone]         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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of David P. Kemp
> > Sent: Monday, August 30, 2004 11:51 AM
> > To: [e-mail]
> > 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:[e-mail]]
> > >Sent: Saturday, August 28, 2004 5:10 AM
> > >To: Santosh Chokhani; [e-mail]
> > >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: [e-mail]
> > >>[mailto:[e-mail]]
> > >>On Behalf Of Santosh Chokhani
> > >>Sent: den 28 augusti 2004 00:52
> > >>To: [e-mail]
> > >>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: [e-mail]
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 9:28 AM
> > >>To: Sharon Boeyen
> > >>Cc: [e-mail]
> > >>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:[e-mail]]
> > >>Inviato: venerdì 27 agosto 2004 14.34
> > >>A: Santoni Adriano; [e-mail]
> > >>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: [e-mail]
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 5:37 AM
> > >>To: [e-mail]
> > >>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.
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VDpXB5009136; Tue, 31 Aug 2004 06:51:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VDpXmC009135; Tue, 31 Aug 2004 06:51:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VDpSFI009092 for <[e-mail]>; Tue, 31 Aug 2004 06:51:28 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7VDpEjh016556; Tue, 31 Aug 2004 09:51:18 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06110402bd5a30d557c3@[128.89.89.75]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 31 Aug 2004 09:50:48 -0400
To: "Santoni Adriano" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: R: On cross-certificates and pathLenConstraint
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VBlJ7G067772; Tue, 31 Aug 2004 04:47:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VBlJHB067771; Tue, 31 Aug 2004 04:47:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VBlJsf067765 for <[e-mail]>; Tue, 31 Aug 2004 04:47:19 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7VBlKod008524 for <[e-mail]>; Tue, 31 Aug 2004 07:47:20 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 07:47:15 -0400
Message-ID: <013001c48f50$46208af0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VBlJsf067766
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan:

The 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: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 6:26 AM
To: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [e-mail]
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: [e-mail] 
> [mailto:[e-mail]]
> On Behalf Of Santoni Adriano
> Sent: den 31 augusti 2004 09:26
> To: Peter Hesse; David P. Kemp
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]] 
> Per conto di Peter Hesse
> Inviato: lunedì 30 agosto 2004 18.43
> A: 'David P. Kemp'; [e-mail]
> 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                    [e-mail]     |
> | Phone: [phone]         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: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of David P. Kemp
> > Sent: Monday, August 30, 2004 11:51 AM
> > To: [e-mail]
> > 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:[e-mail]]
> > >Sent: Saturday, August 28, 2004 5:10 AM
> > >To: Santosh Chokhani; [e-mail]
> > >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: [e-mail] 
> > >>[mailto:[e-mail]]
> > >>On Behalf Of Santosh Chokhani
> > >>Sent: den 28 augusti 2004 00:52
> > >>To: [e-mail]
> > >>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: [e-mail] 
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 9:28 AM
> > >>To: Sharon Boeyen
> > >>Cc: [e-mail]
> > >>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:[e-mail]]
> > >>Inviato: venerdì 27 agosto 2004 14.34
> > >>A: Santoni Adriano; [e-mail]
> > >>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: [e-mail] 
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 5:37 AM
> > >>To: [e-mail]
> > >>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.
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VBh0QT067342; Tue, 31 Aug 2004 04:43:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VBh0qs067341; Tue, 31 Aug 2004 04:43:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VBgxn2067335 for <[e-mail]>; Tue, 31 Aug 2004 04:42:59 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7VBgxod006435 for <[e-mail]>; Tue, 31 Aug 2004 07:43:00 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 07:42:55 -0400
Message-ID: <012b01c48f4f$ab57e8b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VBh0n2067336
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A trust anchor is not considered a certificate per X.509 and RFC 3280
regardless of what form it is promulgated in.  It could be a data structure
consisting of name, algorithm identifier, public key parameters, and public
key; it could be a self-signed certificate; or it could be a certificate. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santoni Adriano
Sent: Tuesday, August 31, 2004 3:26 AM
To: Peter Hesse; David P. Kemp
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] Per
conto di Peter Hesse
Inviato: lunedì 30 agosto 2004 18.43
A: 'David P. Kemp'; [e-mail]
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                    [e-mail]     |
| Phone: [phone]         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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of David P. Kemp
> Sent: Monday, August 30, 2004 11:51 AM
> To: [e-mail]
> 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:[e-mail]]
> >Sent: Saturday, August 28, 2004 5:10 AM
> >To: Santosh Chokhani; [e-mail]
> >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: [e-mail]
> >>[mailto:[e-mail]]
> >>On Behalf Of Santosh Chokhani
> >>Sent: den 28 augusti 2004 00:52
> >>To: [e-mail]
> >>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: [e-mail]
> >>[mailto:[e-mail]]
> >>On
> >>Behalf Of Santoni Adriano
> >>Sent: Friday, August 27, 2004 9:28 AM
> >>To: Sharon Boeyen
> >>Cc: [e-mail]
> >>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:[e-mail]]
> >>Inviato: venerdì 27 agosto 2004 14.34
> >>A: Santoni Adriano; [e-mail]
> >>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: [e-mail]
> >>[mailto:[e-mail]]
> >>On
> >>Behalf Of Santoni Adriano
> >>Sent: Friday, August 27, 2004 5:37 AM
> >>To: [e-mail]
> >>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.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VAmdmx060439; Tue, 31 Aug 2004 03:48:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VAmdMp060438; Tue, 31 Aug 2004 03:48:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from siamail.sia.it (mail.sia.it [193.203.230.133] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VAmbCn060416 for <[e-mail]>; Tue, 31 Aug 2004 03:48:38 -0700 (PDT) (envelope-from [e-mail])
Received: from ntexch06.office.corp.sia.it ([10.2.101.30]) by siamail.sia.it (8.12.11/8.12.11) with ESMTP id i7VAmUjA005756; Tue, 31 Aug 2004 12:48:30 +0200 (METDST)
Received: from NTEXCH00.office.corp.sia.it ([10.2.101.129]) by ntexch06.office.corp.sia.it with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 12:48:29 +0200
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
Content-Class: urn:content-classes:message
Subject: R: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 12:48:29 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: On cross-certificates and pathLenConstraint
Importance: normal
thread-index: AcSPRQRmLSFunUkTQwSWLJt2EczdrwAAOpfw
From: "Santoni Adriano" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>, "Peter Hesse" <[e-mail]>, "David P. Kemp" <[e-mail]>
X-OriginalArrivalTime: 31 Aug 2004 10:48:29.0969 (UTC) FILETIME=[0D795810:01C48F48]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VAmdCn060433
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thank you for clarifying your thought.

It seems to me, however, that some aspects to this topic are still a little blurry.

Adriano

-----Messaggio originale-----
Da: Stefan Santesson [mailto:[e-mail]] 
Inviato: martedì 31 agosto 2004 12.26
A: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [e-mail]
Oggetto: 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: [e-mail] 
> [mailto:[e-mail]]
> On Behalf Of Santoni Adriano
> Sent: den 31 augusti 2004 09:26
> To: Peter Hesse; David P. Kemp
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]] 
> Per conto di Peter Hesse
> Inviato: lunedì 30 agosto 2004 18.43
> A: 'David P. Kemp'; [e-mail]
> 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                    [e-mail]     |
> | Phone: [phone]         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: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of David P. Kemp
> > Sent: Monday, August 30, 2004 11:51 AM
> > To: [e-mail]
> > 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:[e-mail]]
> > >Sent: Saturday, August 28, 2004 5:10 AM
> > >To: Santosh Chokhani; [e-mail]
> > >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: [e-mail] 
> > >>[mailto:[e-mail]]
> > >>On Behalf Of Santosh Chokhani
> > >>Sent: den 28 augusti 2004 00:52
> > >>To: [e-mail]
> > >>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: [e-mail] 
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 9:28 AM
> > >>To: Sharon Boeyen
> > >>Cc: [e-mail]
> > >>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:[e-mail]]
> > >>Inviato: venerdì 27 agosto 2004 14.34
> > >>A: Santoni Adriano; [e-mail]
> > >>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: [e-mail] 
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 5:37 AM
> > >>To: [e-mail]
> > >>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.
> 
> 

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


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



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





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VAQoGd056491; Tue, 31 Aug 2004 03:26:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VAQoqj056490; Tue, 31 Aug 2004 03:26:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VAQhbc056435 for <[e-mail]>; Tue, 31 Aug 2004 03:26:44 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 11:26:40 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 11:26:13 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: On cross-certificates and pathLenConstraint
Thread-Index: AcSOsOV7Mj6Uzy2MSTKtnqoDCMaIwQAdNQ8AAAdHVlA=
From: "Stefan Santesson" <[e-mail]>
To: "Santoni Adriano" <[e-mail]>, "Peter Hesse" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 31 Aug 2004 10:26:40.0389 (UTC) FILETIME=[00E74B50:01C48F45]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7VAQibc056463
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santoni,

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: [e-mail] [mailto:[e-mail]]
> On Behalf Of Santoni Adriano
> Sent: den 31 augusti 2004 09:26
> To: Peter Hesse; David P. Kemp
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]] Per
> conto di Peter Hesse
> Inviato: lunedì 30 agosto 2004 18.43
> A: 'David P. Kemp'; [e-mail]
> 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                    [e-mail]     |
> | Phone: [phone]         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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of David P. Kemp
> > Sent: Monday, August 30, 2004 11:51 AM
> > To: [e-mail]
> > 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:[e-mail]]
> > >Sent: Saturday, August 28, 2004 5:10 AM
> > >To: Santosh Chokhani; [e-mail]
> > >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: [e-mail]
> > >>[mailto:[e-mail]]
> > >>On Behalf Of Santosh Chokhani
> > >>Sent: den 28 augusti 2004 00:52
> > >>To: [e-mail]
> > >>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: [e-mail]
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 9:28 AM
> > >>To: Sharon Boeyen
> > >>Cc: [e-mail]
> > >>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:[e-mail]]
> > >>Inviato: venerdì 27 agosto 2004 14.34
> > >>A: Santoni Adriano; [e-mail]
> > >>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: [e-mail]
> > >>[mailto:[e-mail]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 5:37 AM
> > >>To: [e-mail]
> > >>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.
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V7QAg9020494; Tue, 31 Aug 2004 00:26:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7V7QARx020493; Tue, 31 Aug 2004 00:26:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from siamail.sia.it (mail.sia.it [193.203.230.133] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7V7Q4vA020459 for <[e-mail]>; Tue, 31 Aug 2004 00:26:09 -0700 (PDT) (envelope-from [e-mail])
Received: from ntexch06.office.corp.sia.it ([10.2.101.30]) by siamail.sia.it (8.12.11/8.12.11) with ESMTP id i7V7PqeL002332; Tue, 31 Aug 2004 09:25:52 +0200 (METDST)
Received: from NTEXCH00.office.corp.sia.it ([10.2.101.129]) by ntexch06.office.corp.sia.it with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 09:25:52 +0200
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
Content-Class: urn:content-classes:message
Subject: R: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 09:25:51 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: On cross-certificates and pathLenConstraint
Importance: normal
thread-index: AcSOsOV7Mj6Uzy2MSTKtnqoDCMaIwQAdNQ8A
From: "Santoni Adriano" <[e-mail]>
To: "Peter Hesse" <[e-mail]>, "David P. Kemp" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 31 Aug 2004 07:25:52.0083 (UTC) FILETIME=[BECF2A30:01C48F2B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7V7Q9vA020485
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]] Per conto di Peter Hesse
Inviato: lunedì 30 agosto 2004 18.43
A: 'David P. Kemp'; [e-mail]
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                    [e-mail]     |
| Phone: [phone]         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: [e-mail]
> [mailto:[e-mail]] On Behalf Of David P. Kemp
> Sent: Monday, August 30, 2004 11:51 AM
> To: [e-mail]
> 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:[e-mail]]
> >Sent: Saturday, August 28, 2004 5:10 AM
> >To: Santosh Chokhani; [e-mail]
> >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: [e-mail] 
> >>[mailto:[e-mail]]
> >>On Behalf Of Santosh Chokhani
> >>Sent: den 28 augusti 2004 00:52
> >>To: [e-mail]
> >>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: [e-mail] 
> >>[mailto:[e-mail]]
> >>On
> >>Behalf Of Santoni Adriano
> >>Sent: Friday, August 27, 2004 9:28 AM
> >>To: Sharon Boeyen
> >>Cc: [e-mail]
> >>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:[e-mail]]
> >>Inviato: venerdì 27 agosto 2004 14.34
> >>A: Santoni Adriano; [e-mail]
> >>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: [e-mail] 
> >>[mailto:[e-mail]]
> >>On
> >>Behalf Of Santoni Adriano
> >>Sent: Friday, August 27, 2004 5:37 AM
> >>To: [e-mail]
> >>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.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ULtGQ3022993; Mon, 30 Aug 2004 14:55:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ULtGol022992; Mon, 30 Aug 2004 14:55:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ULtEa7022958 for <[e-mail]>; Mon, 30 Aug 2004 14:55:14 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 22:55:14 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates
Date: Mon, 30 Aug 2004 22:54:41 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC 3280 bug? - Special processing for self issued certificates
Thread-Index: AcSO2dvmJL9ePBbSTHiabqIa3rWhtgAATzMQ
From: "Stefan Santesson" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 30 Aug 2004 21:55:14.0657 (UTC) FILETIME=[07B68D10:01C48EDC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7ULtFa7022984
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

Yes that's true. That was not my question though :-) 

The question is: If we have an exception not to inhibit anyPolicy for
self issued certificates, since it only passes the policies from its
parent certificate, then why do we need to enforce inhibit anyPolicy
just because the self-issued certificate is last in a path.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 30 augusti 2004 22:45
> To: [e-mail]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> 
> Stefan:
> 
> For inhibit any policy, when you define skip certs, you want to
enforce
> the
> constraints on a specific CA down stream from you regardless of
whether
> the
> path is from your current certificate or from a current to roll over
> certificate.  Thus, skip certs for inhibit policy should not count
> self-issued certificates.
> 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On
> Behalf Of Stefan Santesson
> Sent: Monday, August 30, 2004 12:42 PM
> To: Steve Hanna
> Cc: Sharon Boeyen; [e-mail]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> 
> 
> Thanks Steve,
> 
> Yes, this is a valid technical argument.
> I suppose it is reasonable to accept a certificate as a key rollover
cert
> despite name constraints violations in subjAltName while you wouldn't
> accept
> those violations if the same certificate was used as an EE cert to
> validate
> e.g. a new name constraints violating e-mail address of that CA.
> 
> It seems harder however to transfer this logic to inhibit anyPolicy.
Any
> ideas/arguments there?
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On Behalf Of Steve Hanna
> > Sent: den 30 augusti 2004 17:07
> > To: Stefan Santesson
> > Cc: Sharon Boeyen; [e-mail]
> > Subject: Re: RFC 3280 bug? - Special processing for self issued
> > certificates
> >
> >
> > Stefan,
> >
> > You wrote:
> >  > For all valid paths to a self-issued certificate, the self-issued
> cert
> >  > will be preceded by a valid intermediary CA certificate with a  >
> > matching subject name. Lets call that the ICA cert.  >
> >  > It seams reasonable to me that that IF ICA has a valid subject
name
> >  > then that name would be OK also for the rollover cert, regardless
> of
> >  > whether it is used as an intermediary cert or validated as target
> > > cert.
> >
> > I will admit I had to check the archives on this one.
> > Your argument seemed compelling at first. But the email
> > below explains the problem. In a nutshell, the self-issued
certificate
> > can contain a *subjectAltName* that is not permitted by the name
> > constraints and not contained in the ICA cert.
> >
> > I hope that explains why this requirement is needed.
> >
> > Thanks,
> >
> > Steve
> >
> > -------- Original Message --------
> > Date: Fri, 04 May 2001 12:44:34 -0400
> > From: Steve Hanna <[e-mail]>
> > To: PKIX List <[e-mail]>
> > Subject: Ignoring name constraints with self-issued certs
> >
> > Regretfully, I must raise another issue with son-of-2459. In section
> > 4.2.1.11 of draft-ietf-pkix-new-part1-06.txt, it says:
> >
> >     Name constraints are not applied to certificates whose issuer
and
> >     subject are identical.  (This could prevent CAs that use name
> >     constraints from issuing self-signed certificates to implement
key
> >     rollover.)
> >
> > This statement is consistent with the validation algorithm in
section
> > 6.1, which says:
> >
> >     A certificate is termed self-issued if the DNs that appear in
the
> >     subject and issuer fields are identical and are not empty.  In
> >     general, the issuer and subject of the certificates that make up
a
> >     path are different for each certificate.  However, a CA may
issue
> a
> >     certificate to itself to support key rollover or changes in
> >     certificate policies.  These self-issued certificates are not
> >     counted when evaluating path length or name constraints.
> >
> > However, these statements (and the corresponding text in the
> validation
> > algorithm, steps (b) and (c) of section 6.1.3) are not consistent
with
> > the text in X.509(2000), which says (in step g of section 10.5.1)
"If
> > the certificate is not an intermediate self-issued certificate,
check
> > that the subject name is within the name-space given by the value of
> > permitted-subtrees and is not within the name-space given by the
value
> > of excluded-subtrees."
> >
> > Note the word *intermediate* in X.509(2000). If a self-issued
> > certificate is the last certificate in the path, the name
constraints
> > check MUST be performed. Otherwise, a security hole is opened up.
> > Consider the following chain of 2 certificates:
> >
> > Certificate 1:
> >   Issuer:  o=trusty, c=us
> >   Subject: o=shady, c=us
> >   Basic Constraints:
> >    cA=true
> >   Name Constraints:
> >    Permitted:
> >     directoryName: o=shady, c=us
> >     rfc822Name: .shady.com
> >
> > Certificate 2:
> >   Issuer:  o=shady, c=us
> >   Subject: o=shady, c=us
> >   SubjectAltNames:
> >    rfc822Name: [e-mail]
> >
> > If o=trusty, c=us is one of the trust anchors (and the certificate
> > signatures verify), this chain is valid according to son-of-2459. It
> is
> > not valid according to X.509(2000). I think you will agree that the
> > behavior described in X.509(2000) is correct. Otherwise, self-issued
> > certificates can be used to completely bypass the effects of name
> > constraints.
> >
> > Therefore, I suggest that section 4.2.1.11 of
> > draft-ietf-pkix-new-part1-06.txt be modified to say:
> >
> >     Name constraints are not applied to certificates whose issuer
and
> >     subject are identical (unless the certificate is the final
> >     certificate in the path).  (This could prevent CAs that use name
> >     constraints from issuing self-signed certificates to implement
key
> >     rollover.)
> >
> > We should also modify the last sentence of the paragraph in section
> 6.1
> > that begins "A certificate is termed self-issued ..." (listed in
full
> > above) to "These self-issued certificates are not counted when
> > evaluating path length. Name constraints are only applied to a
> > self-issued certificate if it is the final certificate in the path."
> >
> > I also suggest that the start of steps (b) and (c) in section 6.1.3
be
> > changed to read:
> >
> >        (b) If certificate i is self-issued and it is not the final
> >        certificate in the path, skip this step for certificate i.
> >        Otherwise, verify that the subject name is within one of the
> >        permitted_subtrees for X.500 distinguished names, and verify
> >        that each of the alternative names in the subjectAltName
> >        extension (critical or non-critical) is within one of the
> >        permitted_subtrees for that name type.
> >
> >        (c) If certificate i is self-issued and it is not the final
> >        certificate in the path, skip this step for certificate i.
> >        Otherwise, verify that the subject name is not within one of
> the
> >        excluded_subtrees for X.500 distinguished names, and verify
> that
> >        each of the alternative names in the subjectAltName extension
> >        (critical or non-critical) is not within one of the
> >        excluded_subtrees for that name type.
> >
> > Comments?
> >
> > Steve
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ULbcqp019377; Mon, 30 Aug 2004 14:37:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7ULbcFx019376; Mon, 30 Aug 2004 14:37:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ULbbNe019348 for <[e-mail]>; Mon, 30 Aug 2004 14:37:38 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Mon, 30 Aug 2004 17:37:30 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: On cross-certificates and pathLenConstraint
References: <002901c48ece$67dbc600$[e-mail]>
In-Reply-To: <002901c48ece$67dbc600$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Aug 2004 21:37:35.0448 (UTC) FILETIME=[90601580:01C48ED9]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

Yes, I agree.  I overlooked the paragraph that Peter pointed out; sorry 
for the confusion.

Dave



Santosh Chokhani wrote:

>David Kemp:
>
>I assume you are in agreement with me based on clarification by Peter Hesse?
>If not, I will be glad to respond.
>
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKiovZ008739; Mon, 30 Aug 2004 13:44:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UKiod9008738; Mon, 30 Aug 2004 13:44:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKinbX008731 for <[e-mail]>; Mon, 30 Aug 2004 13:44:49 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7UKirod000687 for <[e-mail]>; Mon, 30 Aug 2004 16:44:53 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates
Date: Mon, 30 Aug 2004 16:44:48 -0400
Message-ID: <005501c48ed2$341f0120$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7UKinbX008733
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan:

For inhibit any policy, when you define skip certs, you want to enforce the
constraints on a specific CA down stream from you regardless of whether the
path is from your current certificate or from a current to roll over
certificate.  Thus, skip certs for inhibit policy should not count
self-issued certificates.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Monday, August 30, 2004 12:42 PM
To: Steve Hanna
Cc: Sharon Boeyen; [e-mail]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates



Thanks Steve,

Yes, this is a valid technical argument. 
I suppose it is reasonable to accept a certificate as a key rollover cert
despite name constraints violations in subjAltName while you wouldn't accept
those violations if the same certificate was used as an EE cert to validate
e.g. a new name constraints violating e-mail address of that CA.

It seems harder however to transfer this logic to inhibit anyPolicy. Any
ideas/arguments there? 

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Steve Hanna
> Sent: den 30 augusti 2004 17:07
> To: Stefan Santesson
> Cc: Sharon Boeyen; [e-mail]
> Subject: Re: RFC 3280 bug? - Special processing for self issued 
> certificates
> 
> 
> Stefan,
> 
> You wrote:
>  > For all valid paths to a self-issued certificate, the self-issued
cert
>  > will be preceded by a valid intermediary CA certificate with a  > 
> matching subject name. Lets call that the ICA cert.  >
>  > It seams reasonable to me that that IF ICA has a valid subject name
>  > then that name would be OK also for the rollover cert, regardless
of
>  > whether it is used as an intermediary cert or validated as target  
> > cert.
> 
> I will admit I had to check the archives on this one.
> Your argument seemed compelling at first. But the email
> below explains the problem. In a nutshell, the self-issued certificate 
> can contain a *subjectAltName* that is not permitted by the name 
> constraints and not contained in the ICA cert.
> 
> I hope that explains why this requirement is needed.
> 
> Thanks,
> 
> Steve
> 
> -------- Original Message --------
> Date: Fri, 04 May 2001 12:44:34 -0400
> From: Steve Hanna <[e-mail]>
> To: PKIX List <[e-mail]>
> Subject: Ignoring name constraints with self-issued certs
> 
> Regretfully, I must raise another issue with son-of-2459. In section 
> 4.2.1.11 of draft-ietf-pkix-new-part1-06.txt, it says:
> 
>     Name constraints are not applied to certificates whose issuer and
>     subject are identical.  (This could prevent CAs that use name
>     constraints from issuing self-signed certificates to implement key
>     rollover.)
> 
> This statement is consistent with the validation algorithm in section 
> 6.1, which says:
> 
>     A certificate is termed self-issued if the DNs that appear in the
>     subject and issuer fields are identical and are not empty.  In
>     general, the issuer and subject of the certificates that make up a
>     path are different for each certificate.  However, a CA may issue
a
>     certificate to itself to support key rollover or changes in
>     certificate policies.  These self-issued certificates are not
>     counted when evaluating path length or name constraints.
> 
> However, these statements (and the corresponding text in the
validation
> algorithm, steps (b) and (c) of section 6.1.3) are not consistent with 
> the text in X.509(2000), which says (in step g of section 10.5.1) "If 
> the certificate is not an intermediate self-issued certificate, check 
> that the subject name is within the name-space given by the value of 
> permitted-subtrees and is not within the name-space given by the value 
> of excluded-subtrees."
> 
> Note the word *intermediate* in X.509(2000). If a self-issued 
> certificate is the last certificate in the path, the name constraints 
> check MUST be performed. Otherwise, a security hole is opened up. 
> Consider the following chain of 2 certificates:
> 
> Certificate 1:
>   Issuer:  o=trusty, c=us
>   Subject: o=shady, c=us
>   Basic Constraints:
>    cA=true
>   Name Constraints:
>    Permitted:
>     directoryName: o=shady, c=us
>     rfc822Name: .shady.com
> 
> Certificate 2:
>   Issuer:  o=shady, c=us
>   Subject: o=shady, c=us
>   SubjectAltNames:
>    rfc822Name: [e-mail]
> 
> If o=trusty, c=us is one of the trust anchors (and the certificate 
> signatures verify), this chain is valid according to son-of-2459. It
is
> not valid according to X.509(2000). I think you will agree that the 
> behavior described in X.509(2000) is correct. Otherwise, self-issued 
> certificates can be used to completely bypass the effects of name 
> constraints.
> 
> Therefore, I suggest that section 4.2.1.11 of 
> draft-ietf-pkix-new-part1-06.txt be modified to say:
> 
>     Name constraints are not applied to certificates whose issuer and
>     subject are identical (unless the certificate is the final
>     certificate in the path).  (This could prevent CAs that use name
>     constraints from issuing self-signed certificates to implement key
>     rollover.)
> 
> We should also modify the last sentence of the paragraph in section
6.1
> that begins "A certificate is termed self-issued ..." (listed in full
> above) to "These self-issued certificates are not counted when 
> evaluating path length. Name constraints are only applied to a 
> self-issued certificate if it is the final certificate in the path."
> 
> I also suggest that the start of steps (b) and (c) in section 6.1.3 be 
> changed to read:
> 
>        (b) If certificate i is self-issued and it is not the final
>        certificate in the path, skip this step for certificate i.
>        Otherwise, verify that the subject name is within one of the
>        permitted_subtrees for X.500 distinguished names, and verify
>        that each of the alternative names in the subjectAltName
>        extension (critical or non-critical) is within one of the
>        permitted_subtrees for that name type.
> 
>        (c) If certificate i is self-issued and it is not the final
>        certificate in the path, skip this step for certificate i.
>        Otherwise, verify that the subject name is not within one of
the
>        excluded_subtrees for X.500 distinguished names, and verify
that
>        each of the alternative names in the subjectAltName extension
>        (critical or non-critical) is not within one of the
>        excluded_subtrees for that name type.
> 
> Comments?
> 
> Steve





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKHk1V003309; Mon, 30 Aug 2004 13:17:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UKHkha003308; Mon, 30 Aug 2004 13:17:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKHffo003288 for <[e-mail]>; Mon, 30 Aug 2004 13:17:46 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7UKHgod022873 for <[e-mail]>; Mon, 30 Aug 2004 16:17:42 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Mon, 30 Aug 2004 16:17:34 -0400
Message-ID: <002901c48ece$67dbc600$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7UKHkfo003302
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Kemp:

I assume you are in agreement with me based on clarification by Peter Hesse?
If not, I will be glad to respond.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of David P. Kemp
Sent: Monday, August 30, 2004 11:51 AM
To: [e-mail]
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:[e-mail]]
>Sent: Saturday, August 28, 2004 5:10 AM
>To: Santosh Chokhani; [e-mail]
>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: [e-mail]
>>[mailto:[e-mail]]
>>On Behalf Of Santosh Chokhani
>>Sent: den 28 augusti 2004 00:52
>>To: [e-mail]
>>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: [e-mail]
>>[mailto:[e-mail]]
>>On
>>Behalf Of Santoni Adriano
>>Sent: Friday, August 27, 2004 9:28 AM
>>To: Sharon Boeyen
>>Cc: [e-mail]
>>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:[e-mail]]
>>Inviato: venerdì 27 agosto 2004 14.34
>>A: Santoni Adriano; [e-mail]
>>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: [e-mail]
>>[mailto:[e-mail]]
>>On
>>Behalf Of Santoni Adriano
>>Sent: Friday, August 27, 2004 5:37 AM
>>To: [e-mail]
>>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.
>>
>>
>>
>>    
>>
>
>
>
>
>  
>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UGgdbF060805; Mon, 30 Aug 2004 09:42:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UGgdIT060804; Mon, 30 Aug 2004 09:42:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail19g.g19.rapidsite.net (mail19g.g19.rapidsite.net [198.170.241.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7UGgbU8060797 for <[e-mail]>; Mon, 30 Aug 2004 09:42:38 -0700 (PDT) (envelope-from [e-mail])
Received: from www.geminisecurity.com (161.58.96.110) by mail19g.g19.rapidsite.net (RS ver 1.0.94vs) with SMTP id 3-0988374159; Mon, 30 Aug 2004 12:42:39 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, <[e-mail]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Mon, 30 Aug 2004 12:42:39 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <[e-mail]>
Thread-Index: AcSOr3ZlNYRb4gBxRXeaIJOZfo3/4gAAL3fQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Message-ID: <[e-mail]>
X-Loop-Detect: 1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7UGgcU8060799
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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                    [e-mail]     |
| Phone: [phone]         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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of David P. Kemp
> Sent: Monday, August 30, 2004 11:51 AM
> To: [e-mail]
> 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:[e-mail]]
> >Sent: Saturday, August 28, 2004 5:10 AM
> >To: Santosh Chokhani; [e-mail]
> >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: [e-mail]
> >>[mailto:[e-mail]]
> >>On Behalf Of Santosh Chokhani
> >>Sent: den 28 augusti 2004 00:52
> >>To: [e-mail]
> >>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: [e-mail]
> >>[mailto:[e-mail]]
> >>On
> >>Behalf Of Santoni Adriano
> >>Sent: Friday, August 27, 2004 9:28 AM
> >>To: Sharon Boeyen
> >>Cc: [e-mail]
> >>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:[e-mail]]
> >>Inviato: venerdì 27 agosto 2004 14.34
> >>A: Santoni Adriano; [e-mail]
> >>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: [e-mail]
> >>[mailto:[e-mail]]
> >>On
> >>Behalf Of Santoni Adriano
> >>Sent: Friday, August 27, 2004 5:37 AM
> >>To: [e-mail]
> >>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.
> >>
> >>
> >>
> >>    
> >>
> >
> >
> >
> >
> >  
> >
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UGg7GB060767; Mon, 30 Aug 2004 09:42:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UGg7A4060766; Mon, 30 Aug 2004 09:42:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UGg6Fa060757 for <[e-mail]>; Mon, 30 Aug 2004 09:42:06 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 17:41:49 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates
Date: Mon, 30 Aug 2004 17:41:31 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC 3280 bug? - Special processing for self issued certificates
Thread-Index: AcSOrdBSGfy82zmTQMSptWq8vKtOpgAAUmUw
From: "Stefan Santesson" <[e-mail]>
To: "Steve Hanna" <[e-mail]>
Cc: "Sharon Boeyen" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 30 Aug 2004 16:41:49.0020 (UTC) FILETIME=[3EAE11C0:01C48EB0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7UGg7Fa060761
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks Steve,

Yes, this is a valid technical argument. 
I suppose it is reasonable to accept a certificate as a key rollover
cert despite name constraints violations in subjAltName while you
wouldn't accept those violations if the same certificate was used as an
EE cert to validate e.g. a new name constraints violating e-mail address
of that CA.

It seems harder however to transfer this logic to inhibit anyPolicy. Any
ideas/arguments there? 

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Steve Hanna
> Sent: den 30 augusti 2004 17:07
> To: Stefan Santesson
> Cc: Sharon Boeyen; [e-mail]
> Subject: Re: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> 
> Stefan,
> 
> You wrote:
>  > For all valid paths to a self-issued certificate, the self-issued
cert
>  > will be preceded by a valid intermediary CA certificate with a
>  > matching subject name. Lets call that the ICA cert.
>  >
>  > It seams reasonable to me that that IF ICA has a valid subject name
>  > then that name would be OK also for the rollover cert, regardless
of
>  > whether it is used as an intermediary cert or validated as target
>  > cert.
> 
> I will admit I had to check the archives on this one.
> Your argument seemed compelling at first. But the email
> below explains the problem. In a nutshell, the self-issued
> certificate can contain a *subjectAltName* that is not
> permitted by the name constraints and not contained in
> the ICA cert.
> 
> I hope that explains why this requirement is needed.
> 
> Thanks,
> 
> Steve
> 
> -------- Original Message --------
> Date: Fri, 04 May 2001 12:44:34 -0400
> From: Steve Hanna <[e-mail]>
> To: PKIX List <[e-mail]>
> Subject: Ignoring name constraints with self-issued certs
> 
> Regretfully, I must raise another issue with son-of-2459. In section
> 4.2.1.11 of draft-ietf-pkix-new-part1-06.txt, it says:
> 
>     Name constraints are not applied to certificates whose issuer and
>     subject are identical.  (This could prevent CAs that use name
>     constraints from issuing self-signed certificates to implement key
>     rollover.)
> 
> This statement is consistent with the validation algorithm in section
> 6.1, which says:
> 
>     A certificate is termed self-issued if the DNs that appear in the
>     subject and issuer fields are identical and are not empty.  In
>     general, the issuer and subject of the certificates that make up a
>     path are different for each certificate.  However, a CA may issue
a
>     certificate to itself to support key rollover or changes in
>     certificate policies.  These self-issued certificates are not
>     counted when evaluating path length or name constraints.
> 
> However, these statements (and the corresponding text in the
validation
> algorithm, steps (b) and (c) of section 6.1.3) are not consistent with
> the text in X.509(2000), which says (in step g of section 10.5.1) "If
> the certificate is not an intermediate self-issued certificate, check
> that the subject name is within the name-space given by the value of
> permitted-subtrees and is not within the name-space given by the value
> of excluded-subtrees."
> 
> Note the word *intermediate* in X.509(2000). If a self-issued
> certificate is the last certificate in the path, the name constraints
> check MUST be performed. Otherwise, a security hole is opened up.
> Consider the following chain of 2 certificates:
> 
> Certificate 1:
>   Issuer:  o=trusty, c=us
>   Subject: o=shady, c=us
>   Basic Constraints:
>    cA=true
>   Name Constraints:
>    Permitted:
>     directoryName: o=shady, c=us
>     rfc822Name: .shady.com
> 
> Certificate 2:
>   Issuer:  o=shady, c=us
>   Subject: o=shady, c=us
>   SubjectAltNames:
>    rfc822Name: [e-mail]
> 
> If o=trusty, c=us is one of the trust anchors (and the certificate
> signatures verify), this chain is valid according to son-of-2459. It
is
> not valid according to X.509(2000). I think you will agree that the
> behavior described in X.509(2000) is correct. Otherwise, self-issued
> certificates can be used to completely bypass the effects of name
> constraints.
> 
> Therefore, I suggest that section 4.2.1.11 of
> draft-ietf-pkix-new-part1-06.txt be modified to say:
> 
>     Name constraints are not applied to certificates whose issuer and
>     subject are identical (unless the certificate is the final
>     certificate in the path).  (This could prevent CAs that use name
>     constraints from issuing self-signed certificates to implement key
>     rollover.)
> 
> We should also modify the last sentence of the paragraph in section
6.1
> that begins "A certificate is termed self-issued ..." (listed in full
> above) to "These self-issued certificates are not counted when
> evaluating path length. Name constraints are only applied to a
> self-issued certificate if it is the final certificate in the path."
> 
> I also suggest that the start of steps (b) and (c) in section 6.1.3 be
> changed to read:
> 
>        (b) If certificate i is self-issued and it is not the final
>        certificate in the path, skip this step for certificate i.
>        Otherwise, verify that the subject name is within one of the
>        permitted_subtrees for X.500 distinguished names, and verify
>        that each of the alternative names in the subjectAltName
>        extension (critical or non-critical) is within one of the
>        permitted_subtrees for that name type.
> 
>        (c) If certificate i is self-issued and it is not the final
>        certificate in the path, skip this step for certificate i.
>        Otherwise, verify that the subject name is not within one of
the
>        excluded_subtrees for X.500 distinguished names, and verify
that
>        each of the alternative names in the subjectAltName extension
>        (critical or non-critical) is not within one of the
>        excluded_subtrees for that name type.
> 
> Comments?
> 
> Steve




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UFokZu053767; Mon, 30 Aug 2004 08:50:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UFokEm053766; Mon, 30 Aug 2004 08:50:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UFoj7C053690 for <[e-mail]>; Mon, 30 Aug 2004 08:50:45 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Mon, 30 Aug 2004 11:50:36 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: On cross-certificates and pathLenConstraint
References: <004801c48cfa$6357fd40$[e-mail]>
In-Reply-To: <004801c48cfa$6357fd40$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 30 Aug 2004 15:50:37.0199 (UTC) FILETIME=[17BB61F0:01C48EA9]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

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:[e-mail]] 
>Sent: Saturday, August 28, 2004 5:10 AM
>To: Santosh Chokhani; [e-mail]
>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: [e-mail] 
>>[mailto:[e-mail]]
>>On Behalf Of Santosh Chokhani
>>Sent: den 28 augusti 2004 00:52
>>To: [e-mail]
>>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: [e-mail] 
>>[mailto:[e-mail]]
>>On
>>Behalf Of Santoni Adriano
>>Sent: Friday, August 27, 2004 9:28 AM
>>To: Sharon Boeyen
>>Cc: [e-mail]
>>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:[e-mail]]
>>Inviato: venerdì 27 agosto 2004 14.34
>>A: Santoni Adriano; [e-mail]
>>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: [e-mail] 
>>[mailto:[e-mail]]
>>On
>>Behalf Of Santoni Adriano
>>Sent: Friday, August 27, 2004 5:37 AM
>>To: [e-mail]
>>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.
>>
>>
>>
>>    
>>
>
>
>
>
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UF75gm045438; Mon, 30 Aug 2004 08:07:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UF754a045437; Mon, 30 Aug 2004 08:07:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from trilmail.funk.com (26-71-51-66.reonbroadband.com [66.51.71.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UF739E045412 for <[e-mail]>; Mon, 30 Aug 2004 08:07:04 -0700 (PDT) (envelope-from [e-mail])
Received: from [127.0.0.1] (HANNAXP [192.168.21.23]) by trilmail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RX8MWA8S; Mon, 30 Aug 2004 11:06:56 -0400
Message-ID: <[e-mail]>
Date: Mon, 30 Aug 2004 11:07:00 -0400
From: Steve Hanna <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Sharon Boeyen <[e-mail]>, [e-mail]
Subject: Re: RFC 3280 bug? - Special processing for self issued certificates
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

You wrote:
 > For all valid paths to a self-issued certificate, the self-issued cert
 > will be preceded by a valid intermediary CA certificate with a
 > matching subject name. Lets call that the ICA cert.
 >
 > It seams reasonable to me that that IF ICA has a valid subject name
 > then that name would be OK also for the rollover cert, regardless of
 > whether it is used as an intermediary cert or validated as target
 > cert.

I will admit I had to check the archives on this one.
Your argument seemed compelling at first. But the email
below explains the problem. In a nutshell, the self-issued
certificate can contain a *subjectAltName* that is not
permitted by the name constraints and not contained in
the ICA cert.

I hope that explains why this requirement is needed.

Thanks,

Steve

-------- Original Message --------
Date: Fri, 04 May 2001 12:44:34 -0400
From: Steve Hanna <[e-mail]>
To: PKIX List <[e-mail]>
Subject: Ignoring name constraints with self-issued certs

Regretfully, I must raise another issue with son-of-2459. In section
4.2.1.11 of draft-ietf-pkix-new-part1-06.txt, it says:

    Name constraints are not applied to certificates whose issuer and
    subject are identical.  (This could prevent CAs that use name
    constraints from issuing self-signed certificates to implement key
    rollover.)

This statement is consistent with the validation algorithm in section
6.1, which says:

    A certificate is termed self-issued if the DNs that appear in the
    subject and issuer fields are identical and are not empty.  In
    general, the issuer and subject of the certificates that make up a
    path are different for each certificate.  However, a CA may issue a
    certificate to itself to support key rollover or changes in
    certificate policies.  These self-issued certificates are not
    counted when evaluating path length or name constraints.

However, these statements (and the corresponding text in the validation
algorithm, steps (b) and (c) of section 6.1.3) are not consistent with
the text in X.509(2000), which says (in step g of section 10.5.1) "If
the certificate is not an intermediate self-issued certificate, check
that the subject name is within the name-space given by the value of
permitted-subtrees and is not within the name-space given by the value
of excluded-subtrees."

Note the word *intermediate* in X.509(2000). If a self-issued
certificate is the last certificate in the path, the name constraints
check MUST be performed. Otherwise, a security hole is opened up.
Consider the following chain of 2 certificates:

Certificate 1:
  Issuer:  o=trusty, c=us
  Subject: o=shady, c=us
  Basic Constraints:
   cA=true
  Name Constraints:
   Permitted:
    directoryName: o=shady, c=us
    rfc822Name: .shady.com

Certificate 2:
  Issuer:  o=shady, c=us
  Subject: o=shady, c=us
  SubjectAltNames:
   rfc822Name: [e-mail]

If o=trusty, c=us is one of the trust anchors (and the certificate
signatures verify), this chain is valid according to son-of-2459. It is
not valid according to X.509(2000). I think you will agree that the
behavior described in X.509(2000) is correct. Otherwise, self-issued
certificates can be used to completely bypass the effects of name
constraints.

Therefore, I suggest that section 4.2.1.11 of
draft-ietf-pkix-new-part1-06.txt be modified to say:

    Name constraints are not applied to certificates whose issuer and
    subject are identical (unless the certificate is the final
    certificate in the path).  (This could prevent CAs that use name
    constraints from issuing self-signed certificates to implement key
    rollover.)

We should also modify the last sentence of the paragraph in section 6.1
that begins "A certificate is termed self-issued ..." (listed in full
above) to "These self-issued certificates are not counted when
evaluating path length. Name constraints are only applied to a
self-issued certificate if it is the final certificate in the path."

I also suggest that the start of steps (b) and (c) in section 6.1.3 be
changed to read:

       (b) If certificate i is self-issued and it is not the final
       certificate in the path, skip this step for certificate i.
       Otherwise, verify that the subject name is within one of the
       permitted_subtrees for X.500 distinguished names, and verify
       that each of the alternative names in the subjectAltName
       extension (critical or non-critical) is within one of the
       permitted_subtrees for that name type.

       (c) If certificate i is self-issued and it is not the final
       certificate in the path, skip this step for certificate i.
       Otherwise, verify that the subject name is not within one of the
       excluded_subtrees for X.500 distinguished names, and verify that
       each of the alternative names in the subjectAltName extension
       (critical or non-critical) is not within one of the
       excluded_subtrees for that name type.

Comments?

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UEnwwo042096; Mon, 30 Aug 2004 07:49:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UEnw7V042095; Mon, 30 Aug 2004 07:49:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm1.entrust.com (sottmxssm1.entrust.com [216.191.252.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UEnvZZ042085 for <[e-mail]>; Mon, 30 Aug 2004 07:49:57 -0700 (PDT) (envelope-from [e-mail])
Received: from SOTTMXS01.entrust.com ([10.4.61.7]) by sottmxssm1.entrust.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7UFIo3M029952; Mon, 30 Aug 2004 11:18:50 -0400
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2657.72) id <Q2Q0RTQN>; Mon, 30 Aug 2004 10:49:54 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint
Date: Mon, 30 Aug 2004 10:49:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Getting back to Adriano's question:

Neither X.509 nor RFC 3280 use certificate extensions to control what
certificates can be issued by other CAs, but rather they both use the
extensions to control what certificates RPs trust. 

Dealing with path validation, if basicConstraints extension is included in a
self-signed certificate with a path length of 0, RPs will ignore that path
length constraint when the do path validation. 

However, dealing with certificate issuance, there would be nothing wrong
with using that path length constraint as a tool to help enforce the
domain's security policy, which in your example would mean that other CA's
shouldn't be issuing certificates to other CAs, but only to users. However,
beware that this is definitely not required by standards so relying on it in
any particular environment could be risky (different vendors may possibly
use different techniques to control the privileges CAs have when issuing
certificates). X.509 includes no such requirements, but focuses instead on
ensuring that only certificates that are intended to be trusted will
actually be trusted. 

Hope that helps rather than further confuses the issue :-)

Cheers,
Sharon
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Chokhani
Sent: Saturday, August 28, 2004 8:27 AM
To: [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint



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:[e-mail]] 
Sent: Saturday, August 28, 2004 5:10 AM
To: Santosh Chokhani; [e-mail]
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: [e-mail]
> [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 28 augusti 2004 00:52
> To: [e-mail]
> 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: [e-mail]
> [mailto:[e-mail]]
> On
> Behalf Of Santoni Adriano
> Sent: Friday, August 27, 2004 9:28 AM
> To: Sharon Boeyen
> Cc: [e-mail]
> 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:[e-mail]]
> Inviato: venerdì 27 agosto 2004 14.34
> A: Santoni Adriano; [e-mail]
> 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: [e-mail]
> [mailto:[e-mail]]
> On
> Behalf Of Santoni Adriano
> Sent: Friday, August 27, 2004 5:37 AM
> To: [e-mail]
> 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.
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UEa7Gi040277; Mon, 30 Aug 2004 07:36:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UEa78B040276; Mon, 30 Aug 2004 07:36:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm1.entrust.com (sottmxssm1.entrust.com [216.191.252.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UEa6ma040257 for <[e-mail]>; Mon, 30 Aug 2004 07:36:06 -0700 (PDT) (envelope-from [e-mail])
Received: from SOTTMXS01.entrust.com ([10.4.61.7]) by sottmxssm1.entrust.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7UF4xDt027389; Mon, 30 Aug 2004 11:04:59 -0400
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2657.72) id <Q2Q0RR0W>; Mon, 30 Aug 2004 10:36:03 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Sharon Boeyen <[e-mail]>, [e-mail]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificat es
Date: Mon, 30 Aug 2004 10:36:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I don't see a problem with the certificate validating differently in
different contexts. This happens all the time with target certificates if
client side setting of business controls is used (I like to call these
'process controls' as opposed to 'infrastructure controls' which is the term
I like to use for business controls placed in certificates). With the
identical certification path a certificate may pass validation in one
context (e.g. if the client side settings impose a policy related control
for one validation event but not for another). The process constraints could
be set different by the same RP for different applications, different
transactions, different physical environments etc. While I agree that this
is slightly different than the case you are describing because you aren't
using process constraints, I just wanted to provide an example of where the
same cert can have different results depending on the context in which it is
being validated. Therefore I don't see what you are describing as a problem
from that perspective.

Cheers,
Sharon

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Friday, August 27, 2004 12:54 PM
To: Sharon Boeyen; [e-mail]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates


Well,

That doesn't really help. What you say is what I assumed is the case.

However, I don't see any real threats avoided with the current approach,
only problems.

The only aspects that are influenced by this logic are name constraints and
processing anyPolicy when inhibited. I have tried to think hard here but I
can't see any real threats avoided by the current logic.

For all valid paths to a self-issued certificate, the self-issued cert will
be preceded by a valid intermediary CA certificate with a matching subject
name. Lets call that the ICA cert.

It seams reasonable to me that that IF ICA has a valid subject name then
that name would be OK also for the rollover cert, regardless of whether it
is used as an intermediary cert or validated as target cert.

Likewise, if ICA is valid for a certain set of policies, then those policies
would also be good for the rollover cert, regardless of whether it is used
as an intermediary cert or validated as target cert.

I just don't see the threat NOR the real benefit.

The problem that I sense (if this is a problem at all) is that the same
certificate placed under the same certificate path, may be both valid and
invalid at the same time, depending on the context within which you examine
it.

An example:

You look at the certificate path in a viewer and see the complete path as
valid. Then you click on the rollover cert to take a closer look at it and
suddenly that cert shows as invalid. It shows as invalid because when you
take a look just at this cert, it is now at the end of a path and can't be
validated.

Do you see the problem or are my worries completely false here. I want to
know whether I just see ghosts.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Sharon Boeyen [mailto:[e-mail]]
> Sent: den 27 augusti 2004 17:04
> To: Stefan Santesson; Sharon Boeyen; [e-mail]
> Subject: RE: RFC 3280 bug? - Special processing for self issued 
> certificates
> 
> I tried to address that at the end of my email but probably didn't do
a
> very
> good job of it. The reason for making the exceptions was primarily so
that
> CA key rollover didn't interfere with business controls for path 
> processing. However, if the self-issued certificate is the final 
> certificate in
the
> path
> then it should no longer get excepted because it is now the target of
the
> path validation and therefore the constraints should apply to it. In
the
> intermediate case the certificate's existence is most likely not even 
> known to the RP. If it is the target cert however, then it is most
definitely
> known to the RP and any business controls, whether imposed directly by
the
> RP through initializing settings for the path validation variables or
by
> CAs
> in cross certs should apply.
> 
> Does that help at all?
> 
> Cheers,
> Sharon
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Friday, August 27, 2004 10:01 AM
> To: Sharon Boeyen; [e-mail]
> Subject: RE: RFC 3280 bug? - Special processing for self issued 
> certificates
> 
> 
> Sharon,
> 
> I think you misread my question/issue.
> 
> I do not question why self-issued certs are excepted from path length 
> counting or anyPolicy inhabitation.
> 
> My question is why some exceptions for processing self-issued
certificates
> (mainly regarding processing of anyPolicy and name constraints
checking)
> are
> different if the self-issued certificate is intermediate or the last 
> certificate in the path.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: Sharon Boeyen [mailto:[e-mail]]
> > Sent: den 27 augusti 2004 14:56
> > To: Stefan Santesson; [e-mail]
> > Subject: RE: RFC 3280 bug? - Special processing for self issued 
> > certificates
> >
> > Hi Stefan,
> >
> > The reason for the exception cases for self-issued intermediate 
> > certificates deals mainly with their role in a CA key rollover 
> > situation. In this situation, the fact that a CA has rolled its key, 
> > should not change
> the
> > processing of a path. For example if a path length constraint of 3
is
> ok
> > before the rollover that same path length constraint should be ok
with
> the
> > self-issued intermediate cert that perfoms the key rollover. Similar
> logic
> > applies to the anyPolicy and to name constraints. From an X.509 
> > perspective, note that the anyPolicy situation was handled by DR
276.
> > FYI, here is
> just
> > the rationale piece of that DR. You can check its processing via the 
> > regular docs on Hoyt's server. I could look up the DTC TC numbers if 
> > you need them. DR 273 addressed the name constraints issues in this 
> > area. Some of
the
> > other
> > areas, such as basic constraints, were addressed in the 4th edition
> text.
> >
> > Rationale text from DR 276:
> > ---------------------
> > One use of self-issued certificates is for a CA to roll over its 
> > certificate and/or CRL signing keys without disruption to 
> > certification paths that were previously established. In such cases 
> > it is convenient for the CA to include
> > the special value anyPolicy in the certificate policies extension of
> the
> > self-issued certificate. This allows the self-issued certificate to 
> > provide a link in certification paths for any policy that would be 
> > valid if
> the
> > self-issued certificate did not exist. However, there is a problem
if
> the
> > inhibit-any-policy-indicator is set in the certification path
> processing
> > procedure prior to a self-issued certificate. The current text would 
> > result in failure of the path because of the existence of anyPolicy
in
> > the self-issued certificate. However, if the self-issued certificate 
> > did
> not
> > exist (i.e. the CA had not yet rolled over its key), paths for which 
> > specific policies are present in all subsequent certificates may
have
> > passed, but will always fail due to anyPolicy in the self-issued 
> > certificate.
> > ---------------------
> > That particular DR was accepted (along with other related ones and 
> > original non-defect changes in the 2000 text)
> >
> > These exceptions applied only to intermediate self issued certs
> because
> > the
> > exceptions are to allow paths to have the same result in these areas 
> > regardless of whether or not one or more CAs in the path had
undergone
> a
> > key
> > rollover. However, if the end certificate happens to be a
self-issued
> > certificate, the exceptions do not apply because that is the
> certificate
> > that is the one of interest. Therefore if any constraints preclude
> that
> > certificate, it cannot be considered valid.
> >
> > Cheers,
> > Sharon
> >
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Friday, August 27, 2004 6:01 AM
> > To: [e-mail]
> > Subject: RFC 3280 bug? - Special processing for self issued
> certificates
> >
> >
> >
> > I just cam across a small problem that we might want to add to the
> issues
> > list of RFC 3280.
> >
> > At a number of places in the path validation logic define a special 
> > exception case for self issued certificates, expressed with the
> following
> > logic:
> >
> >       If certificate i is self-issued and it is not the final
> >       certificate in the path....
> >
> > When this condition is fulfilled no name constraints applies.
Further,
> > anyPolicy is processed in the certificate even if anyPolicy
> has
> > been inhibited.
> >
> > The latter has the same logic expressed in a slightly different
form:
> >
> >       If the certificate policies extension includes the policy
> >       anyPolicy with the qualifier set AP-Q and either (a)
> >       inhibit_any-policy is greater than 0 or (b) i<n and the
> >       certificate is self-issued, then
> >
> >
> > Now to the problem:
> >
> > If I apply these rules to a self issued certificate that is
perfectly
> > valid inside I path, that certificate may appear as invalid when 
> > examined on
> its
> > own. That is because when it is examined on its own, it is now the
> last
> > certificate in the path and suddenly other rules apply for what is
> valid
> > and
> > what is not.
> >
> > E.g. the self issued certificate may have just anyPolicy present and
> when
> > examined on its own an inhibit_anyPolicy setting of the path will
then
> > result in an empty policy set of the path.
> >
> > The same type of situation may apply to name constraints (at least
in
> > theory)
> >
> > This creates the odd situation where valid self-issued certificates
> can't
> > be
> > examined on their own. Situations where this could be trouble are in 
> > certificate viewers and logic where you manage, examine and handle 
> > individual certificates in a local environment where some valid 
> > certificates can't be validated and thus show up as invalid.
> >
> > Can anyone remember why we can't make all self issued certificates
to
> be
> > exceptions even if they are the last certificate in the path?
> >
> > I can't see the problem here to allow generic processing of all self 
> > issued certificates regardless of position.
> >
> > Maybe I'm missing something.
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SCRUnx069685; Sat, 28 Aug 2004 05:27:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7SCRUmf069684; Sat, 28 Aug 2004 05:27:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7SCRTod069675 for <[e-mail]>; Sat, 28 Aug 2004 05:27:30 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7SCRVod011334 for <[e-mail]>; Sat, 28 Aug 2004 08:27:31 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Sat, 28 Aug 2004 08:27:25 -0400
Message-ID: <004801c48cfa$6357fd40$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7SCRUod069678
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan:

I think 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:[e-mail]] 
Sent: Saturday, August 28, 2004 5:10 AM
To: Santosh Chokhani; [e-mail]
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: [e-mail] 
> [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 28 augusti 2004 00:52
> To: [e-mail]
> 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: [e-mail] 
> [mailto:[e-mail]]
> On
> Behalf Of Santoni Adriano
> Sent: Friday, August 27, 2004 9:28 AM
> To: Sharon Boeyen
> Cc: [e-mail]
> 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:[e-mail]]
> Inviato: venerdì 27 agosto 2004 14.34
> A: Santoni Adriano; [e-mail]
> 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: [e-mail] 
> [mailto:[e-mail]]
> On
> Behalf Of Santoni Adriano
> Sent: Friday, August 27, 2004 5:37 AM
> To: [e-mail]
> 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.
> 
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S9Adp0038844; Sat, 28 Aug 2004 02:10:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7S9Adrp038843; Sat, 28 Aug 2004 02:10:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7S9AbG4038823 for <[e-mail]>; Sat, 28 Aug 2004 02:10:38 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 28 Aug 2004 10:10:29 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: On cross-certificates and pathLenConstraint
Date: Sat, 28 Aug 2004 10:10:04 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: On cross-certificates and pathLenConstraint
Thread-Index: AcSMkh+rP4nh0X5yQDKlFZzSOAnFOgAS8cwA
From: "Stefan Santesson" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 28 Aug 2004 09:10:29.0069 (UTC) FILETIME=[DCF1F7D0:01C48CDE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7S9AcG4038838
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The 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: [e-mail] [mailto:[e-mail]]
> On Behalf Of Santosh Chokhani
> Sent: den 28 augusti 2004 00:52
> To: [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> On
> Behalf Of Santoni Adriano
> Sent: Friday, August 27, 2004 9:28 AM
> To: Sharon Boeyen
> Cc: [e-mail]
> 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:[e-mail]]
> Inviato: venerdì 27 agosto 2004 14.34
> A: Santoni Adriano; [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> On
> Behalf Of Santoni Adriano
> Sent: Friday, August 27, 2004 5:37 AM
> To: [e-mail]
> 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.
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RMq3Jb069084; Fri, 27 Aug 2004 15:52:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RMq3nt069083; Fri, 27 Aug 2004 15:52:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RMq2B3069074 for <[e-mail]>; Fri, 27 Aug 2004 15:52:02 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7RMq4od022417 for <[e-mail]>; Fri, 27 Aug 2004 18:52:05 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Fri, 27 Aug 2004 18:52:05 -0400
Message-ID: <00b501c48c88$795c9cd0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RMq2B3069078
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan 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: [e-mail] [mailto:[e-mail]] On
Behalf Of Santoni Adriano
Sent: Friday, August 27, 2004 9:28 AM
To: Sharon Boeyen
Cc: [e-mail]
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:[e-mail]] 
Inviato: venerdì 27 agosto 2004 14.34
A: Santoni Adriano; [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Santoni Adriano
Sent: Friday, August 27, 2004 5:37 AM
To: [e-mail]
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.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGsfuX043947; Fri, 27 Aug 2004 09:54:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RGsfP6043946; Fri, 27 Aug 2004 09:54:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RGseJO043933 for <[e-mail]>; Fri, 27 Aug 2004 09:54:40 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 17:54:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates
Date: Fri, 27 Aug 2004 17:54:11 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC 3280 bug? - Special processing for self issued certificates
Thread-Index: AcSMRyHy9AODz6uqRPuu3wgvlsJF2AACxtrQ
From: "Stefan Santesson" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Aug 2004 16:54:36.0902 (UTC) FILETIME=[89225060:01C48C56]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RGsfJO043941
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well,

That doesn't really help. What you say is what I assumed is the case.

However, I don't see any real threats avoided with the current approach,
only problems.

The only aspects that are influenced by this logic are name constraints
and processing anyPolicy when inhibited. I have tried to think hard here
but I can't see any real threats avoided by the current logic.

For all valid paths to a self-issued certificate, the self-issued cert
will be preceded by a valid intermediary CA certificate with a matching
subject name. Lets call that the ICA cert.

It seams reasonable to me that that IF ICA has a valid subject name then
that name would be OK also for the rollover cert, regardless of whether
it is used as an intermediary cert or validated as target cert.

Likewise, if ICA is valid for a certain set of policies, then those
policies would also be good for the rollover cert, regardless of whether
it is used as an intermediary cert or validated as target cert.

I just don't see the threat NOR the real benefit.

The problem that I sense (if this is a problem at all) is that the same
certificate placed under the same certificate path, may be both valid
and invalid at the same time, depending on the context within which you
examine it.

An example:

You look at the certificate path in a viewer and see the complete path
as valid. Then you click on the rollover cert to take a closer look at
it and suddenly that cert shows as invalid. It shows as invalid because
when you take a look just at this cert, it is now at the end of a path
and can't be validated.

Do you see the problem or are my worries completely false here.
I want to know whether I just see ghosts.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Sharon Boeyen [mailto:[e-mail]]
> Sent: den 27 augusti 2004 17:04
> To: Stefan Santesson; Sharon Boeyen; [e-mail]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> I tried to address that at the end of my email but probably didn't do
a
> very
> good job of it. The reason for making the exceptions was primarily so
that
> CA key rollover didn't interfere with business controls for path
> processing.
> However, if the self-issued certificate is the final certificate in
the
> path
> then it should no longer get excepted because it is now the target of
the
> path validation and therefore the constraints should apply to it. In
the
> intermediate case the certificate's existence is most likely not even
> known
> to the RP. If it is the target cert however, then it is most
definitely
> known to the RP and any business controls, whether imposed directly by
the
> RP through initializing settings for the path validation variables or
by
> CAs
> in cross certs should apply.
> 
> Does that help at all?
> 
> Cheers,
> Sharon
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Friday, August 27, 2004 10:01 AM
> To: Sharon Boeyen; [e-mail]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> 
> Sharon,
> 
> I think you misread my question/issue.
> 
> I do not question why self-issued certs are excepted from path length
> counting or anyPolicy inhabitation.
> 
> My question is why some exceptions for processing self-issued
certificates
> (mainly regarding processing of anyPolicy and name constraints
checking)
> are
> different if the self-issued certificate is intermediate or the last
> certificate in the path.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: Sharon Boeyen [mailto:[e-mail]]
> > Sent: den 27 augusti 2004 14:56
> > To: Stefan Santesson; [e-mail]
> > Subject: RE: RFC 3280 bug? - Special processing for self issued
> > certificates
> >
> > Hi Stefan,
> >
> > The reason for the exception cases for self-issued intermediate
> > certificates deals mainly with their role in a CA key rollover
> > situation. In this situation, the fact that a CA has rolled its key,
> > should not change
> the
> > processing of a path. For example if a path length constraint of 3
is
> ok
> > before the rollover that same path length constraint should be ok
with
> the
> > self-issued intermediate cert that perfoms the key rollover. Similar
> logic
> > applies to the anyPolicy and to name constraints. From an X.509
> > perspective, note that the anyPolicy situation was handled by DR
276.
> > FYI, here is
> just
> > the rationale piece of that DR. You can check its processing via the
> > regular docs on Hoyt's server. I could look up the DTC TC numbers if
> > you need them.
> > DR 273 addressed the name constraints issues in this area. Some of
the
> > other
> > areas, such as basic constraints, were addressed in the 4th edition
> text.
> >
> > Rationale text from DR 276:
> > ---------------------
> > One use of self-issued certificates is for a CA to roll over its
> > certificate and/or CRL signing keys without disruption to
> > certification paths that were
> > previously established. In such cases it is convenient for the CA to
> > include
> > the special value anyPolicy in the certificate policies extension of
> the
> > self-issued certificate. This allows the self-issued certificate to
> > provide a link in certification paths for any policy that would be
> > valid if
> the
> > self-issued certificate did not exist. However, there is a problem
if
> the
> > inhibit-any-policy-indicator is set in the certification path
> processing
> > procedure prior to a self-issued certificate. The current text would
> > result in failure of the path because of the existence of anyPolicy
in
> > the self-issued certificate. However, if the self-issued certificate
> > did
> not
> > exist (i.e. the CA had not yet rolled over its key), paths for which
> > specific policies are present in all subsequent certificates may
have
> > passed, but will always fail due to anyPolicy in the self-issued
> > certificate.
> > ---------------------
> > That particular DR was accepted (along with other related ones and
> > original non-defect changes in the 2000 text)
> >
> > These exceptions applied only to intermediate self issued certs
> because
> > the
> > exceptions are to allow paths to have the same result in these areas
> > regardless of whether or not one or more CAs in the path had
undergone
> a
> > key
> > rollover. However, if the end certificate happens to be a
self-issued
> > certificate, the exceptions do not apply because that is the
> certificate
> > that is the one of interest. Therefore if any constraints preclude
> that
> > certificate, it cannot be considered valid.
> >
> > Cheers,
> > Sharon
> >
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Friday, August 27, 2004 6:01 AM
> > To: [e-mail]
> > Subject: RFC 3280 bug? - Special processing for self issued
> certificates
> >
> >
> >
> > I just cam across a small problem that we might want to add to the
> issues
> > list of RFC 3280.
> >
> > At a number of places in the path validation logic define a special
> > exception case for self issued certificates, expressed with the
> following
> > logic:
> >
> >       If certificate i is self-issued and it is not the final
> >       certificate in the path....
> >
> > When this condition is fulfilled no name constraints applies.
Further,
> > anyPolicy is processed in the certificate even if anyPolicy
> has
> > been inhibited.
> >
> > The latter has the same logic expressed in a slightly different
form:
> >
> >       If the certificate policies extension includes the policy
> >       anyPolicy with the qualifier set AP-Q and either (a)
> >       inhibit_any-policy is greater than 0 or (b) i<n and the
> >       certificate is self-issued, then
> >
> >
> > Now to the problem:
> >
> > If I apply these rules to a self issued certificate that is
perfectly
> > valid inside I path, that certificate may appear as invalid when
> > examined on
> its
> > own. That is because when it is examined on its own, it is now the
> last
> > certificate in the path and suddenly other rules apply for what is
> valid
> > and
> > what is not.
> >
> > E.g. the self issued certificate may have just anyPolicy present and
> when
> > examined on its own an inhibit_anyPolicy setting of the path will
then
> > result in an empty policy set of the path.
> >
> > The same type of situation may apply to name constraints (at least
in
> > theory)
> >
> > This creates the odd situation where valid self-issued certificates
> can't
> > be
> > examined on their own. Situations where this could be trouble are in
> > certificate viewers and logic where you manage, examine and handle
> > individual certificates in a local environment where some valid
> > certificates can't be validated and thus show up as invalid.
> >
> > Can anyone remember why we can't make all self issued certificates
to
> be
> > exceptions even if they are the last certificate in the path?
> >
> > I can't see the problem here to allow generic processing of all self
> > issued certificates regardless of position.
> >
> > Maybe I'm missing something.
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RF4DjN033543; Fri, 27 Aug 2004 08:04:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RF4DRp033542; Fri, 27 Aug 2004 08:04:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm1.entrust.com (sottmxssm1.entrust.com [216.191.252.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RF4CTH033509 for <[e-mail]>; Fri, 27 Aug 2004 08:04:12 -0700 (PDT) (envelope-from [e-mail])
Received: from SOTTMXS01.entrust.com ([10.4.61.7]) by sottmxssm1.entrust.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7RFWZax003206; Fri, 27 Aug 2004 11:32:35 -0400
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2657.72) id <Q2Q0G5TG>; Fri, 27 Aug 2004 11:04:09 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Sharon Boeyen <[e-mail]>, [e-mail]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificat es
Date: Fri, 27 Aug 2004 11:04:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I tried to address that at the end of my email but probably didn't do a very
good job of it. The reason for making the exceptions was primarily so that
CA key rollover didn't interfere with business controls for path processing.
However, if the self-issued certificate is the final certificate in the path
then it should no longer get excepted because it is now the target of the
path validation and therefore the constraints should apply to it. In the
intermediate case the certificate's existence is most likely not even known
to the RP. If it is the target cert however, then it is most definitely
known to the RP and any business controls, whether imposed directly by the
RP through initializing settings for the path validation variables or by CAs
in cross certs should apply. 

Does that help at all?

Cheers,
Sharon

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Friday, August 27, 2004 10:01 AM
To: Sharon Boeyen; [e-mail]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates


Sharon,

I think you misread my question/issue.

I do not question why self-issued certs are excepted from path length
counting or anyPolicy inhabitation.

My question is why some exceptions for processing self-issued certificates
(mainly regarding processing of anyPolicy and name constraints checking) are
different if the self-issued certificate is intermediate or the last
certificate in the path.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Sharon Boeyen [mailto:[e-mail]]
> Sent: den 27 augusti 2004 14:56
> To: Stefan Santesson; [e-mail]
> Subject: RE: RFC 3280 bug? - Special processing for self issued 
> certificates
> 
> Hi Stefan,
> 
> The reason for the exception cases for self-issued intermediate 
> certificates deals mainly with their role in a CA key rollover 
> situation. In this situation, the fact that a CA has rolled its key, 
> should not change
the
> processing of a path. For example if a path length constraint of 3 is
ok
> before the rollover that same path length constraint should be ok with
the
> self-issued intermediate cert that perfoms the key rollover. Similar
logic
> applies to the anyPolicy and to name constraints. From an X.509 
> perspective, note that the anyPolicy situation was handled by DR 276. 
> FYI, here is
just
> the rationale piece of that DR. You can check its processing via the 
> regular docs on Hoyt's server. I could look up the DTC TC numbers if 
> you need them.
> DR 273 addressed the name constraints issues in this area. Some of the
> other
> areas, such as basic constraints, were addressed in the 4th edition
text.
> 
> Rationale text from DR 276:
> ---------------------
> One use of self-issued certificates is for a CA to roll over its 
> certificate and/or CRL signing keys without disruption to 
> certification paths that were
> previously established. In such cases it is convenient for the CA to
> include
> the special value anyPolicy in the certificate policies extension of
the
> self-issued certificate. This allows the self-issued certificate to 
> provide a link in certification paths for any policy that would be 
> valid if
the
> self-issued certificate did not exist. However, there is a problem if
the
> inhibit-any-policy-indicator is set in the certification path
processing
> procedure prior to a self-issued certificate. The current text would 
> result in failure of the path because of the existence of anyPolicy in 
> the self-issued certificate. However, if the self-issued certificate 
> did
not
> exist (i.e. the CA had not yet rolled over its key), paths for which 
> specific policies are present in all subsequent certificates may have 
> passed, but will always fail due to anyPolicy in the self-issued 
> certificate.
> ---------------------
> That particular DR was accepted (along with other related ones and 
> original non-defect changes in the 2000 text)
> 
> These exceptions applied only to intermediate self issued certs
because
> the
> exceptions are to allow paths to have the same result in these areas 
> regardless of whether or not one or more CAs in the path had undergone
a
> key
> rollover. However, if the end certificate happens to be a self-issued 
> certificate, the exceptions do not apply because that is the
certificate
> that is the one of interest. Therefore if any constraints preclude
that
> certificate, it cannot be considered valid.
> 
> Cheers,
> Sharon
> 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On
> Behalf Of Stefan Santesson
> Sent: Friday, August 27, 2004 6:01 AM
> To: [e-mail]
> Subject: RFC 3280 bug? - Special processing for self issued
certificates
> 
> 
> 
> I just cam across a small problem that we might want to add to the
issues
> list of RFC 3280.
> 
> At a number of places in the path validation logic define a special 
> exception case for self issued certificates, expressed with the
following
> logic:
> 
>       If certificate i is self-issued and it is not the final
>       certificate in the path....
> 
> When this condition is fulfilled no name constraints applies. Further, 
> anyPolicy is processed in the certificate even if anyPolicy
has
> been inhibited.
> 
> The latter has the same logic expressed in a slightly different form:
> 
>       If the certificate policies extension includes the policy
>       anyPolicy with the qualifier set AP-Q and either (a)
>       inhibit_any-policy is greater than 0 or (b) i<n and the
>       certificate is self-issued, then
> 
> 
> Now to the problem:
> 
> If I apply these rules to a self issued certificate that is perfectly 
> valid inside I path, that certificate may appear as invalid when 
> examined on
its
> own. That is because when it is examined on its own, it is now the
last
> certificate in the path and suddenly other rules apply for what is
valid
> and
> what is not.
> 
> E.g. the self issued certificate may have just anyPolicy present and
when
> examined on its own an inhibit_anyPolicy setting of the path will then 
> result in an empty policy set of the path.
> 
> The same type of situation may apply to name constraints (at least in
> theory)
> 
> This creates the odd situation where valid self-issued certificates
can't
> be
> examined on their own. Situations where this could be trouble are in 
> certificate viewers and logic where you manage, examine and handle 
> individual certificates in a local environment where some valid 
> certificates can't be validated and thus show up as invalid.
> 
> Can anyone remember why we can't make all self issued certificates to
be
> exceptions even if they are the last certificate in the path?
> 
> I can't see the problem here to allow generic processing of all self 
> issued certificates regardless of position.
> 
> Maybe I'm missing something.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RE1YGW019127; Fri, 27 Aug 2004 07:01:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RE1YIw019126; Fri, 27 Aug 2004 07:01:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RE1Xxg019111 for <[e-mail]>; Fri, 27 Aug 2004 07:01:33 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 15:01:30 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates
Date: Fri, 27 Aug 2004 15:01:08 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC 3280 bug? - Special processing for self issued certificates
Thread-Index: AcSMNUguU6yecNvrQTuuZOlfskh4KgABx4gw
From: "Stefan Santesson" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Aug 2004 14:01:30.0911 (UTC) FILETIME=[5A99DAF0:01C48C3E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RE1Yxg019120
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sharon,

I think you misread my question/issue.

I do not question why self-issued certs are excepted from path length
counting or anyPolicy inhabitation.

My question is why some exceptions for processing self-issued
certificates (mainly regarding processing of anyPolicy and name
constraints checking) are different if the self-issued certificate is
intermediate or the last certificate in the path.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Sharon Boeyen [mailto:[e-mail]]
> Sent: den 27 augusti 2004 14:56
> To: Stefan Santesson; [e-mail]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> Hi Stefan,
> 
> The reason for the exception cases for self-issued intermediate
> certificates
> deals mainly with their role in a CA key rollover situation. In this
> situation, the fact that a CA has rolled its key, should not change
the
> processing of a path. For example if a path length constraint of 3 is
ok
> before the rollover that same path length constraint should be ok with
the
> self-issued intermediate cert that perfoms the key rollover. Similar
logic
> applies to the anyPolicy and to name constraints. From an X.509
> perspective,
> note that the anyPolicy situation was handled by DR 276. FYI, here is
just
> the rationale piece of that DR. You can check its processing via the
> regular
> docs on Hoyt's server. I could look up the DTC TC numbers if you need
> them.
> DR 273 addressed the name constraints issues in this area. Some of the
> other
> areas, such as basic constraints, were addressed in the 4th edition
text.
> 
> Rationale text from DR 276:
> ---------------------
> One use of self-issued certificates is for a CA to roll over its
> certificate
> and/or CRL signing keys without disruption to certification paths that
> were
> previously established. In such cases it is convenient for the CA to
> include
> the special value anyPolicy in the certificate policies extension of
the
> self-issued certificate. This allows the self-issued certificate to
> provide
> a link in certification paths for any policy that would be valid if
the
> self-issued certificate did not exist. However, there is a problem if
the
> inhibit-any-policy-indicator is set in the certification path
processing
> procedure prior to a self-issued certificate. The current text would
> result
> in failure of the path because of the existence of anyPolicy in the
> self-issued certificate. However, if the self-issued certificate did
not
> exist (i.e. the CA had not yet rolled over its key), paths for which
> specific policies are present in all subsequent certificates may have
> passed, but will always fail due to anyPolicy in the self-issued
> certificate.
> ---------------------
> That particular DR was accepted (along with other related ones and
> original
> non-defect changes in the 2000 text)
> 
> These exceptions applied only to intermediate self issued certs
because
> the
> exceptions are to allow paths to have the same result in these areas
> regardless of whether or not one or more CAs in the path had undergone
a
> key
> rollover. However, if the end certificate happens to be a self-issued
> certificate, the exceptions do not apply because that is the
certificate
> that is the one of interest. Therefore if any constraints preclude
that
> certificate, it cannot be considered valid.
> 
> Cheers,
> Sharon
> 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On
> Behalf Of Stefan Santesson
> Sent: Friday, August 27, 2004 6:01 AM
> To: [e-mail]
> Subject: RFC 3280 bug? - Special processing for self issued
certificates
> 
> 
> 
> I just cam across a small problem that we might want to add to the
issues
> list of RFC 3280.
> 
> At a number of places in the path validation logic define a special
> exception case for self issued certificates, expressed with the
following
> logic:
> 
>       If certificate i is self-issued and it is not the final
>       certificate in the path....
> 
> When this condition is fulfilled no name constraints applies.
> Further, anyPolicy is processed in the certificate even if anyPolicy
has
> been inhibited.
> 
> The latter has the same logic expressed in a slightly different form:
> 
>       If the certificate policies extension includes the policy
>       anyPolicy with the qualifier set AP-Q and either (a)
>       inhibit_any-policy is greater than 0 or (b) i<n and the
>       certificate is self-issued, then
> 
> 
> Now to the problem:
> 
> If I apply these rules to a self issued certificate that is perfectly
> valid
> inside I path, that certificate may appear as invalid when examined on
its
> own. That is because when it is examined on its own, it is now the
last
> certificate in the path and suddenly other rules apply for what is
valid
> and
> what is not.
> 
> E.g. the self issued certificate may have just anyPolicy present and
when
> examined on its own an inhibit_anyPolicy setting of the path will then
> result in an empty policy set of the path.
> 
> The same type of situation may apply to name constraints (at least in
> theory)
> 
> This creates the odd situation where valid self-issued certificates
can't
> be
> examined on their own. Situations where this could be trouble are in
> certificate viewers and logic where you manage, examine and handle
> individual certificates in a local environment where some valid
> certificates
> can't be validated and thus show up as invalid.
> 
> Can anyone remember why we can't make all self issued certificates to
be
> exceptions even if they are the last certificate in the path?
> 
> I can't see the problem here to allow generic processing of all self
> issued
> certificates regardless of position.
> 
> Maybe I'm missing something.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDRlOk011154; Fri, 27 Aug 2004 06:27:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RDRldC011153; Fri, 27 Aug 2004 06:27:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from siamail.sia.it (mail.sia.it [193.203.230.133] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDRgnL011134 for <[e-mail]>; Fri, 27 Aug 2004 06:27:47 -0700 (PDT) (envelope-from [e-mail])
Received: from ntexch06.office.corp.sia.it ([10.2.101.30]) by siamail.sia.it (8.12.11/8.12.11) with ESMTP id i7RDRckE029652; Fri, 27 Aug 2004 15:27:38 +0200 (METDST)
Received: from NTEXCH00.office.corp.sia.it ([10.2.101.129]) by ntexch06.office.corp.sia.it with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 15:27:37 +0200
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
Content-Class: urn:content-classes:message
Subject: R: On cross-certificates and pathLenConstraint
Date: Fri, 27 Aug 2004 15:27:37 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: On cross-certificates and pathLenConstraint
Importance: normal
thread-index: AcSMMiIZpr10rBknSQ606b1Vz9y9pgABYKQg
From: "Santoni Adriano" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 27 Aug 2004 13:27:37.0829 (UTC) FILETIME=[9ECA2950:01C48C39]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RDRlnL011148
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]] 
Inviato: venerdì 27 agosto 2004 14.34
A: Santoni Adriano; [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of Santoni Adriano
Sent: Friday, August 27, 2004 5:37 AM
To: [e-mail]
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.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDFiIP007707; Fri, 27 Aug 2004 06:15:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RDFi7t007706; Fri, 27 Aug 2004 06:15:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RDFhbu007688 for <[e-mail]>; Fri, 27 Aug 2004 06:15:44 -0700 (PDT) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-33.mail.demon.net with esmtp (Exim 3.35 #1) id 1C0gZz-0008fS-0X for [e-mail]; Fri, 27 Aug 2004 13:15:43 +0000
Message-ID: <[e-mail]>
Date: Fri, 27 Aug 2004 14:15:46 +0100
From: Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Yet another nitty RFC 3280 bug
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.85.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan Santesson wrote:
> When we are into filing small bugs, here is another one (unless already
> noted):
> 
> Page 77:
>   (h) If the issuer and subject names are not identical
> 
> I believe that this line means to say:
>   (h) If the certificate is not self-issued
> 
> The term self-issued is defined with a slightly different definition,
> adding the aspect that the names must not be empty.
> 
> Section 6:
>    A certificate is self-issued if the DNs that appear in the subject
>    and issuer fields are identical and are not empty.
> 
> 

On the subject of "identical" should its use above be interpreted as
identical encodings of DNs or simply "matching" that is following the
name comparison rules mentioned in 4.1.2.4?

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RCuUV6002494; Fri, 27 Aug 2004 05:56:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RCuU2J002493; Fri, 27 Aug 2004 05:56:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm1.entrust.com (sottmxssm1.entrust.com [216.191.252.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RCuTGU002459 for <[e-mail]>; Fri, 27 Aug 2004 05:56:29 -0700 (PDT) (envelope-from [e-mail])
Received: from SOTTMXS01.entrust.com ([10.4.61.7]) by sottmxssm1.entrust.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7RDOpZZ015122; Fri, 27 Aug 2004 09:24:51 -0400
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2657.72) id <Q2Q0GPGW>; Fri, 27 Aug 2004 08:56:26 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, [e-mail]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificat es
Date: Fri, 27 Aug 2004 08:56:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Stefan,

The reason for the exception cases for self-issued intermediate certificates
deals mainly with their role in a CA key rollover situation. In this
situation, the fact that a CA has rolled its key, should not change the
processing of a path. For example if a path length constraint of 3 is ok
before the rollover that same path length constraint should be ok with the
self-issued intermediate cert that perfoms the key rollover. Similar logic
applies to the anyPolicy and to name constraints. From an X.509 perspective,
note that the anyPolicy situation was handled by DR 276. FYI, here is just
the rationale piece of that DR. You can check its processing via the regular
docs on Hoyt's server. I could look up the DTC TC numbers if you need them.
DR 273 addressed the name constraints issues in this area. Some of the other
areas, such as basic constraints, were addressed in the 4th edition text.

Rationale text from DR 276:
---------------------
One use of self-issued certificates is for a CA to roll over its certificate
and/or CRL signing keys without disruption to certification paths that were
previously established. In such cases it is convenient for the CA to include
the special value anyPolicy in the certificate policies extension of the
self-issued certificate. This allows the self-issued certificate to provide
a link in certification paths for any policy that would be valid if the
self-issued certificate did not exist. However, there is a problem if the
inhibit-any-policy-indicator is set in the certification path processing
procedure prior to a self-issued certificate. The current text would result
in failure of the path because of the existence of anyPolicy in the
self-issued certificate. However, if the self-issued certificate did not
exist (i.e. the CA had not yet rolled over its key), paths for which
specific policies are present in all subsequent certificates may have
passed, but will always fail due to anyPolicy in the self-issued
certificate.
--------------------- 
That particular DR was accepted (along with other related ones and original
non-defect changes in the 2000 text)

These exceptions applied only to intermediate self issued certs because the
exceptions are to allow paths to have the same result in these areas
regardless of whether or not one or more CAs in the path had undergone a key
rollover. However, if the end certificate happens to be a self-issued
certificate, the exceptions do not apply because that is the certificate
that is the one of interest. Therefore if any constraints preclude that
certificate, it cannot be considered valid. 

Cheers,
Sharon  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Friday, August 27, 2004 6:01 AM
To: [e-mail]
Subject: RFC 3280 bug? - Special processing for self issued certificates



I just cam across a small problem that we might want to add to the issues
list of RFC 3280.

At a number of places in the path validation logic define a special
exception case for self issued certificates, expressed with the following
logic:

      If certificate i is self-issued and it is not the final
      certificate in the path....

When this condition is fulfilled no name constraints applies. 
Further, anyPolicy is processed in the certificate even if anyPolicy has
been inhibited.

The latter has the same logic expressed in a slightly different form:

      If the certificate policies extension includes the policy
      anyPolicy with the qualifier set AP-Q and either (a)
      inhibit_any-policy is greater than 0 or (b) i<n and the
      certificate is self-issued, then


Now to the problem:

If I apply these rules to a self issued certificate that is perfectly valid
inside I path, that certificate may appear as invalid when examined on its
own. That is because when it is examined on its own, it is now the last
certificate in the path and suddenly other rules apply for what is valid and
what is not.

E.g. the self issued certificate may have just anyPolicy present and when
examined on its own an inhibit_anyPolicy setting of the path will then
result in an empty policy set of the path.

The same type of situation may apply to name constraints (at least in
theory)

This creates the odd situation where valid self-issued certificates can't be
examined on their own. Situations where this could be trouble are in
certificate viewers and logic where you manage, examine and handle
individual certificates in a local environment where some valid certificates
can't be validated and thus show up as invalid.

Can anyone remember why we can't make all self issued certificates to be
exceptions even if they are the last certificate in the path?

I can't see the problem here to allow generic processing of all self issued
certificates regardless of position.

Maybe I'm missing something.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RCY1RJ096268; Fri, 27 Aug 2004 05:34:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RCY1Gd096267; Fri, 27 Aug 2004 05:34:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm1.entrust.com (sottmxssm1.entrust.com [216.191.252.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RCY0nJ096233 for <[e-mail]>; Fri, 27 Aug 2004 05:34:00 -0700 (PDT) (envelope-from [e-mail])
Received: from SOTTMXS01.entrust.com ([10.4.61.7]) by sottmxssm1.entrust.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7RD2JHp011848; Fri, 27 Aug 2004 09:02:19 -0400
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2657.72) id <Q2Q0GNMJ>; Fri, 27 Aug 2004 08:33:54 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Santoni Adriano'" <[e-mail]>, [e-mail]
Subject: RE: On cross-certificates and pathLenConstraint
Date: Fri, 27 Aug 2004 08:33:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Santoni Adriano
Sent: Friday, August 27, 2004 5:37 AM
To: [e-mail]
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.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC0rKb086308; Fri, 27 Aug 2004 05:00:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RC0rS6086306; Fri, 27 Aug 2004 05:00:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RC0qjV086273 for <[e-mail]>; Fri, 27 Aug 2004 05:00:52 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 13:00:50 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Yet another nitty RFC 3280 bug
Date: Fri, 27 Aug 2004 13:00:30 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Yet another nitty RFC 3280 bug
Thread-Index: AcSMLXLFhJfEsXqZTYOtYQpXlt31dg==
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 27 Aug 2004 12:00:50.0392 (UTC) FILETIME=[7EEA5580:01C48C2D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RC0rjV086298
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

When we are into filing small bugs, here is another one (unless already
noted):

Page 77:
  (h) If the issuer and subject names are not identical

I believe that this line means to say:
  (h) If the certificate is not self-issued

The term self-issued is defined with a slightly different definition,
adding the aspect that the names must not be empty.

Section 6:
   A certificate is self-issued if the DNs that appear in the subject
   and issuer fields are identical and are not empty.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBgXRv079181; Fri, 27 Aug 2004 04:42:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RBgXCs079180; Fri, 27 Aug 2004 04:42:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RBgVUd079165 for <[e-mail]>; Fri, 27 Aug 2004 04:42:32 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 12:42:33 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: On cross-certificates and pathLenConstraint
Date: Fri, 27 Aug 2004 12:42:12 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: On cross-certificates and pathLenConstraint
Thread-Index: AcSK20Jlu34ggxcqSqS2eB6fZn8hgABPB+pAAASrtqA=
From: "Stefan Santesson" <[e-mail]>
To: "Santoni Adriano" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Aug 2004 11:42:33.0011 (UTC) FILETIME=[F0D34830:01C48C2A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RBgWUd079172
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

No,

A CA, when represented by a CA certificate with pathLengthConstraints =
0, can't issue a valid cross cert to another CA.

To be really accurate: The cross cert would actually be valid as the
last cert in a path but nothing under that cross cert would be valid.

Stefan Santesson


> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Santoni Adriano
> Sent: den 27 augusti 2004 11:37
> To: [e-mail]
> 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.
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RA1Y1j045003; Fri, 27 Aug 2004 03:01:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7RA1YfN045002; Fri, 27 Aug 2004 03:01:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7RA1WuE044978 for <[e-mail]>; Fri, 27 Aug 2004 03:01:33 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 11:01:28 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RFC 3280 bug? - Special processing for self issued certificates
Date: Fri, 27 Aug 2004 11:01:09 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC 3280 bug? - Special processing for self issued certificates
Thread-Index: AcSKlvRu7WdKVxdJR1OxyyoInXln0QBgK2mw
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 27 Aug 2004 10:01:28.0981 (UTC) FILETIME=[D261BC50:01C48C1C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7RA1XuE044994
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I just cam across a small problem that we might want to add to the
issues list of RFC 3280.

At a number of places in the path validation logic define a special
exception case for self issued certificates, expressed with the
following logic:

      If certificate i is self-issued and it is not the final
      certificate in the path....

When this condition is fulfilled no name constraints applies. 
Further, anyPolicy is processed in the certificate even if anyPolicy has
been inhibited.

The latter has the same logic expressed in a slightly different form:

      If the certificate policies extension includes the policy
      anyPolicy with the qualifier set AP-Q and either (a)
      inhibit_any-policy is greater than 0 or (b) i<n and the
      certificate is self-issued, then


Now to the problem:

If I apply these rules to a self issued certificate that is perfectly
valid inside I path, that certificate may appear as invalid when
examined on its own. That is because when it is examined on its own, it
is now the last certificate in the path and suddenly other rules apply
for what is valid and what is not.

E.g. the self issued certificate may have just anyPolicy present and
when examined on its own an inhibit_anyPolicy setting of the path will
then result in an empty policy set of the path.

The same type of situation may apply to name constraints (at least in
theory)

This creates the odd situation where valid self-issued certificates
can't be examined on their own. Situations where this could be trouble
are in certificate viewers and logic where you manage, examine and
handle individual certificates in a local environment where some valid
certificates can't be validated and thus show up as invalid.

Can anyone remember why we can't make all self issued certificates to be
exceptions even if they are the last certificate in the path?

I can't see the problem here to allow generic processing of all self
issued certificates regardless of position.

Maybe I'm missing something.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R9bWAN036694; Fri, 27 Aug 2004 02:37:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7R9bWbu036693; Fri, 27 Aug 2004 02:37:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from siamail.sia.it (mail.sia.it [193.203.230.133] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7R9bRwr036617 for <[e-mail]>; Fri, 27 Aug 2004 02:37:32 -0700 (PDT) (envelope-from [e-mail])
Received: from ntexch06.office.corp.sia.it ([10.2.101.30]) by siamail.sia.it (8.12.11/8.12.11) with ESMTP id i7R9bEbe026758 for <[e-mail]>; Fri, 27 Aug 2004 11:37:14 +0200 (METDST)
Received: from NTEXCH00.office.corp.sia.it ([10.2.101.129]) by ntexch06.office.corp.sia.it with Microsoft SMTPSVC(6.0.3790.0); Fri, 27 Aug 2004 11:37:14 +0200
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
Content-Class: urn:content-classes:message
Subject: On cross-certificates and pathLenConstraint
Date: Fri, 27 Aug 2004 11:37:13 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: On cross-certificates and pathLenConstraint
Importance: normal
thread-index: AcSK20Jlu34ggxcqSqS2eB6fZn8hgABPB+pA
From: "Santoni Adriano" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 27 Aug 2004 09:37:14.0195 (UTC) FILETIME=[6F430230:01C48C19]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7R9bWwr036687
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJKtf5093304; Wed, 25 Aug 2004 12:20:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PJKtUT093303; Wed, 25 Aug 2004 12:20:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PJKr0h093292 for <[e-mail]>; Wed, 25 Aug 2004 12:20:54 -0700 (PDT) (envelope-from [e-mail])
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1C031v-0002td-TS; Wed, 25 Aug 2004 15:01:55 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: 'Internet X.509 Public Key Infrastructure Operational  Protocols: Certificate Store Access via HTTP' to Proposed Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 25 Aug 2004 15:01:55 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the Public-Key Infrastructure (X.509) WG 
to consider the following document:

- 'Internet X.509 Public Key Infrastructure Operational Protocols: Certificate 
   Store Access via HTTP '
   <draft-ietf-pkix-certstore-http-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2004-09-08.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-08.txt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAd4Pi080282; Wed, 25 Aug 2004 03:39:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PAd4SX080281; Wed, 25 Aug 2004 03:39:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAd2cr080270 for <[e-mail]>; Wed, 25 Aug 2004 03:39:03 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7PAd0N03609; Wed, 25 Aug 2004 12:39:00 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 25 Aug 2004 12:39:00 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7PAd0u03511; Wed, 25 Aug 2004 12:39:00 +0200 (MEST)
Date: Wed, 25 Aug 2004 12:39:00 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: boolean defaults
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It had been proposed to change the three boolean values
to OPTIONAL.

     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE, 
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE, 
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE, 

I am not sure whether this is useful or necessary.

It seems to me that it is sufficient just to *OR* the
two occurences in a query and the server conf in order
to get the most restrictive setting. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAcUuZ080174; Wed, 25 Aug 2004 03:38:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PAcUAM080173; Wed, 25 Aug 2004 03:38:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAcTxY080165 for <[e-mail]>; Wed, 25 Aug 2004 03:38:30 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7PAcRN03601; Wed, 25 Aug 2004 12:38:27 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 25 Aug 2004 12:38:27 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7PAcRG03508; Wed, 25 Aug 2004 12:38:27 +0200 (MEST)
Date: Wed, 25 Aug 2004 12:38:27 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: SCVP trust anchors.
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The current text concerning trust anchors is: 

..

3.2.14 trustAnchors 
   
  The OPTIONAL trustAnchors item specifies the trust anchors to be 
  used by the SCVP server.  One or more certificate policy MAY be 
  associated with each trust anchor.  If a trustAnchors item is 
  present, the server MUST NOT use any certification path trust 
  anchors other than those provided. 

..

6.5 trustAnchors 
   
  The trustAnchors item specifies the default trust anchors that the 
  SCVP server will use if the client directly or indirectly omits the 
  trustAnchours from the request.   
   

I am not sure whether this text is clear enough to allow the 
following:

1 - the server has a list of trust anchors, and the client may select
    a subset. (an enterprise server)

2 - The server has a potentially empty default list of trust anchors, 
    and the client can (must if empty) select another one.

In fact, I'd rather split the second one into two different policies,
or in other words, when the default server list is empty, the client's
list is taken as is, otherwise only the elemnts in both client and
server list are taken. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PA8Ujv073064; Wed, 25 Aug 2004 03:08:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PA8UjB073063; Wed, 25 Aug 2004 03:08:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PA8SP9073024 for <[e-mail]>; Wed, 25 Aug 2004 03:08:29 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7PA8LN03334; Wed, 25 Aug 2004 12:08:21 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 25 Aug 2004 12:08:21 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7PA8Lj03452; Wed, 25 Aug 2004 12:08:21 +0200 (MEST)
Date: Wed, 25 Aug 2004 12:08:21 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: scvp
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The following message was not send to the list a few days ago.



The path validation algorithm is defined for end certificates. 

> [TF] If the path validation algorithm in 3280 cannot validate CA
> certificates I would consider that a defect against 3280. However I
> cannot see ant such defect so if you believe that to be the case you
> need to take that up with the authors.

The text explicitely says that the algorithm is for end entity certs: 

6.1.3 at the end: 

   If i is not equal to n, continue by performing the preparatory steps
   listed in 6.1.4.  If i is equal to n, perform the wrap-up steps
   listed in 6.1.5.

6.1.5  Wrap-up procedure

   To complete the processing of the end entity certificate ...


Take a invalid path  trust ... CA1 --> CA2 
with CA1 having a pathlength constraint 0 in its cert.

path length is n. CA1 is trusted somehow. 
maxpathlength = n
when you arrice at CA1, the maxpathlength will be 2 
path length constraint is 0 ==> set maxpathlength = 0

Then at the last step the 6.1.5 procedure is called
which does not fail. 

Please tell for your scenario who is responsible to detect
the wrong path. 


> [TF] Before we get into the solution, can you provide some examples
> (like I did for isCA) where path length is a useful policy input. In the
> example I cited, use of the isCA Boolean does not require path length as
> a policy input.

Just apply recursion up to the trust anchor. 


> * 
> * We could require that
> * 
> *    when isCA is set,
> *    the DPV client MUST provide the path to the trust anchor,
> *    or MUST provide the chain from the ee to the ca cert to be
> validated,
> *    including the ee cert,
> * 
> * (
> *    or in case of multiple paths that validate a CA, the state of the
> path
> * validation
> *    algorithm for any of the paths MUST be identical. ???
> * )

The previous was a proposition intened to be commnted. 

> * 
> * > We do have a facility to do this via the basic constraints extension
> * > in a CA cert, but we know that this feature is hard to use unless
> one
> * > knows the structure of the PKI pointed to by a cross cert that
> * > incorporates this feature. As a result, I generally suggest not
> * > making use of this optional part of this extension. I've heard
> others
> * > make the same comment, e.g., Sharon Boyen. I realize that 3280 makes
> * > no comment about this feature, so we have not deprecated it, but ...
> * 
> * I think it is not a bad practice to have pathlength = 0 in CA certs
> * that are only used to sign EE certs.
> [TF] That is the only useful instance of path length for a
> infrastructure management perspective but not for a validation
> perspective.

What do you mean by this? 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJSxfb050088; Tue, 24 Aug 2004 12:28:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OJSxvJ050087; Tue, 24 Aug 2004 12:28:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OJSwkn050081 for <[e-mail]>; Tue, 24 Aug 2004 12:28:58 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-bvi4-413.fastq.com [65.39.91.160]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i7OJSsa36870; Tue, 24 Aug 2004 12:28:54 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: RE: SCVP issue
Date: Tue, 24 Aug 2004 12:27:37 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <p0611040abd428423c064@[128.89.89.75]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

I agree with your proposal for MUST support OIDs, SHOULD/MAY support
parameters.

Mike

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Stephen Kent
Sent: Friday, August 13, 2004 8:01 AM
To: [e-mail]
Subject: SCVP issue



Folks,

A few of us have been discussing (off list) the issue of having a
client send an OID to specify a validation policy at an SCVP (DPV)
server, vs. having the client send parameters to direct validation.

My position is that support for OID-based policy references should be
the default, and the mandatory minimum policy specification mechanism
for both clients and servers, i.e., a MUST, and that support for
explicit parameter passing should be an option, a SHOULD or MAY.
there are several reasons for
my saying this.

First, configuring a client to pass an OID is obviously simpler than
configuring the client with all the parameters needed to direct path
validation, and with the default policy feature that SCVP must
support, one could image a zero-config  situation in some contexts.
In general enterprises find it hard to manage configuration info for
every client, and this problem is only magnified as the number of
configuration parameters grows. Thus OID-specified validation is much
simpler than parameter-specified validation, from a client
perspective. Since the "S" in SCVP does stand for simple, ...

Also, as Trevor brought to my attention, one may choose to define
additional
parameters that define cert validity for a given application context,
beyond the standard set of parameters used for path validation. If we
want a allow an administrator to define such validation policies, we
can't assume that standard clients will be prepared to convey the
necessary parameters. This is especially
true if we assume that the clients and servers are not produced by
the same vendor. So, only via use of OIDs can we hope to allow such
customization of cert validity in mixed vendor (or mixed version)
environments.

These two points seem to argue for making OIDs the MUST method for
conveying cert validation selection between  client and server,
relegating parameter passing to a lesser status, e.g., SHOULD or MAY.

I'd like to receive feedback fro the list on this issue.

Steve





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OHOGSx024074; Tue, 24 Aug 2004 10:24:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OHOGZC024073; Tue, 24 Aug 2004 10:24:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7OHOGfd024064 for <[e-mail]>; Tue, 24 Aug 2004 10:24:16 -0700 (PDT) (envelope-from [e-mail])
Received: from unknown (HELO ieca.com) ([e-mail]@70.17.124.75 with plain) by smtp003.bizmail.yahoo.com with SMTP; 24 Aug 2004 17:24:19 -0000
Message-ID: <[e-mail]>
Date: Tue, 24 Aug 2004 13:20:37 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: SCVP issue
References: <p0611040abd428423c064@[128.89.89.75]>
In-Reply-To: <p0611040abd428423c064@[128.89.89.75]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with the "simple" protocol argument and I like the OIDs as the 
mandatory over the parameters.  As to whether oid and parameters are in 
the same structure or in a separate extension ... well that's the next 
discussion.

spt

Stephen Kent wrote:

>
> Folks,
>
> A few of us have been discussing (off list) the issue of having a 
> client send an OID to specify a validation policy at an SCVP (DPV) 
> server, vs. having the client send parameters to direct validation.
>
> My position is that support for OID-based policy references should be 
> the default, and the mandatory minimum policy specification mechanism 
> for both clients and servers, i.e., a MUST, and that support for 
> explicit parameter passing should be an option, a SHOULD or MAY. there 
> are several reasons for
> my saying this.
>
> First, configuring a client to pass an OID is obviously simpler than 
> configuring the client with all the parameters needed to direct path 
> validation, and with the default policy feature that SCVP must 
> support, one could image a zero-config  situation in some contexts. In 
> general enterprises find it hard to manage configuration info for 
> every client, and this problem is only magnified as the number of 
> configuration parameters grows. Thus OID-specified validation is much 
> simpler than parameter-specified validation, from a client 
> perspective. Since the "S" in SCVP does stand for simple, ...
>
> Also, as Trevor brought to my attention, one may choose to define 
> additional
> parameters that define cert validity for a given application context, 
> beyond the standard set of parameters used for path validation. If we 
> want a allow an administrator to define such validation policies, we 
> can't assume that standard clients will be prepared to convey the 
> necessary parameters. This is especially
> true if we assume that the clients and servers are not produced by the 
> same vendor. So, only via use of OIDs can we hope to allow such 
> customization of cert validity in mixed vendor (or mixed version) 
> environments.
>
> These two points seem to argue for making OIDs the MUST method for 
> conveying cert validation selection between  client and server, 
> relegating parameter passing to a lesser status, e.g., SHOULD or MAY.
>
> I'd like to receive feedback fro the list on this issue.
>
> Steve
>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGJv6q009181; Tue, 24 Aug 2004 09:19:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OGJvUe009180; Tue, 24 Aug 2004 09:19:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OGJvJA009170 for <[e-mail]>; Tue, 24 Aug 2004 09:19:57 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 24 Aug 2004 09:19:59 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Aug 2004 09:20:00 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Aug 2004 09:19:59 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Aug 2004 09:20:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Speak now or forever hold your peace...
Date: Tue, 24 Aug 2004 09:19:57 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Speak now or forever hold your peace...
Thread-Index: AcSJ1E4+X4U2+UqLQdep+/tm1lkg9gAIRfdA
From: "Trevor Freeman" <[e-mail]>
To: "Faisal Maqsood" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 24 Aug 2004 16:20:09.0996 (UTC) FILETIME=[39EC3CC0:01C489F6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7OGJvJA009172
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Faisal Maqsood
* Sent: Tuesday, August 24, 2004 4:38 AM
* To: [e-mail]; [e-mail]
* Subject: Re: Speak now or forever hold your peace...
* 
* 
* Hi All,
* 
* I have two more things to concern for SCVP draft 15 as below:
* 
* 1- According to SCVP draft 15, 'RequestReference' is not OPTIONAL in
scvp
* response structure.As by default 'requestRefHash' is TRUE in Query, if
* server fails to calculate hash for any reason how can the server sends
* 'Internal Error' response back to client without 'RequestReference'
when
* it
* is set as mandatory ? Should 'RequestReference' not be OPTIONAL?
[TF] this is already fixed in 16
* 
* 2- Section 6.2 describes PolicyID which seems to belong only to
default
* validation policy. If so, it should be an optional element in scvp
* response
* because if client uses validation policy other than default, there is
no
* need to insert PolicyID in scvp response.
[TF] If the client uses a validation policy other that default which
does not define every parameter, and the client also omits the missing
values in the request, the default values are used for whatever is
missing therefore the policy ID potentially applies to any response. 
* 
* Regards,
* Faisal
* 
* ----- Original Message -----
* From: <[e-mail]>
* To: <[e-mail]>
* Sent: Thursday, August 05, 2004 05:06
* Subject: SCVP: Speak now or forever hold your peace...
* 
* 
* >
* >
* >
* > Folks,
* >
* > It is time to get serious and finish up SCVP.  In the slides
presented
* at
* our
* > meeting this morning, the SCVP editors requested a "Definitive and
final
* list
* > of all issues from workgroup".  I believe that is a reasonable
request.
* Let's
* > do our best to get that list documented ASAP, so that -16 can be our
* *last*.
* >
* > I am requesting that everyone in the WG make time to review SCVP and
* document
* > any issues you find by Friday the 13th.  (I am not setting a
deadline
* for
* > terminating discussion - it may take a few days to reach consensus
on
* the
* > issue list.  I am just trying to surface all the issues ASAP.)  Once
the
* issue
* > list is stable, I am sure we can work out solutions.
* >
* > Please post all technical comments to the list.  Editorial comments
can
* be
* > sent to Trevor directly.  Include SCVP in the subject line
regardless!
* >
* > Thanks,
* >
* > Tim Polk
* >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OBg9wT046684; Tue, 24 Aug 2004 04:42:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OBg9dA046683; Tue, 24 Aug 2004 04:42:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OBg8PJ046647 for <[e-mail]>; Tue, 24 Aug 2004 04:42:08 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i7OBfsHr624812; Tue, 24 Aug 2004 07:41:54 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7OBh3Ox173544; Tue, 24 Aug 2004 07:43:03 -0400
In-Reply-To: <[e-mail]>
To: "Trevor Freeman" <[e-mail]>
Cc: [e-mail], "Peter Sylvester" <[e-mail]>
MIME-Version: 1.0
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 24 Aug 2004 07:41:48 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 HFB2|July 19, 2004) at 08/24/2004 07:41:54, Serialize complete at 08/24/2004 07:41:54
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Trevor:

        Path length 0 reflects a real condition - it can be imposed as a 
way of enforcing one of the following statements: "the subject is a 
departmental CA and may issue EE certificates but no others" or "I trust 
you to issue EE certificates, but I do not choose to trust your 
cross-certificates".  Of course, the first statement occurs only in a 
hierarchical relationship and the second does not - indeed the second 
statement is one an RP might want to make about a trust anchor if he 
could.  OTOH I have no idea how an issuer would sensibly decide that one 
subject CA gets a path length of 3 while another subject CA gets a path 
length of 4 - AFAIK we're just following X.509 there.
        I guess it would be helpful to break this feature out into two 
questions to everybody who's administered a CA lately (or supported those 
who do):
        First, have you issued a cross certificate (or tried to, or asked 
if the CA software supports it) with path length between 1 and 10?  I'm 
assuming that path lengths greater than 10 are used as loop limits rather 
than actual security constraints.
        Second, have you issued a cross certificate (or tried to, or asked 
if the CA software supports it) with path length 0?

                Tom Gindin

P.S.-   The opinions expressed above are mine personally, and not 
necessarily those of my employer.





"Trevor Freeman" <[e-mail]>
Sent by: [e-mail]
08/18/2004 04:24 PM
 
        To:     "Peter Sylvester" <[e-mail]>
        cc:     <[e-mail]>
        Subject:        RE: PKIX WG Agenda for 60th IETF (second try!)



Hi Peter,
I don't know if this is broken or not. I am applying a is "this a real
or useful problem to solve filer check" before I proceed to problem
analysis or solution. I have never found the path length as a valuable
input into an validation criteria. However if there is consensus to
solve this in the context of SCVP then I will spend some time on it.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Wednesday, August 18, 2004 3:36 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > Hi Peter,
* > I cannot begin to understand why anyone would set an arbitrary
length of
* > a path i.e. is good as long as there are only 3 CA certificates in
the
* > path, however since you raised the point in conjunction to DPD
requests,
* > then the simplest solution is to allow the client to request all
paths.
* 
* you are insisting that I mentioned a use case for DPD,
* but my the question is for DPV as I said already.
* In fact, DPD does not have a problem here, since you can implement
* several paths, as you say (using the servercontext parameter).
* (We havn't even started to handle policies).
* 
* I don't think that servercontext is intended for DPV.
* 
* BTW: The example seems wrong to me, none of the paths is valid.
* The CA3 certs are one too low.
* 
*  EE <- CA1 <- CA2 <- CA3withpathlength1 <- CAX .. sometrustanchor
*                   <- CA3withpathlength2 <- CAY ..
* 
* It seem that you finally admit that there is a problem, and now
* you escape to a social argument. if someone thinks that the situation
* is technical non sense, please tell.
* IMO the PKI structure is conformant with the standards.
* 
* One may choose a solution to provide the path EE <- CA1 <- CA2
* in some way, and ask for a valid path.
* 
* or, one may restruct SCVP DPV processing for certain use cases
* in order to ensure that the server can respond to a client.
* 
* Peter
* 
* PS: you haven't yet answered to two other remarks.
* 
* 
* > Trevor
* >
* > * -----Original Message-----
* > * From: Peter Sylvester [mailto:[e-mail]]
* > * Sent: Sunday, August 15, 2004 4:52 AM
* > * To: [e-mail]; Trevor Freeman
* > * Cc: [e-mail]
* > * Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* > *
* > * > Hi Peter,
* > * > The validation algorithm in 3280 section 6 works for all
* > certificates.
* > *
* > * The algorithm is defined for EE-certs.
* > *
* > * > Trevor
* > * >
* > *
* > *
* > * You have not commented the following:
* > *
* > * > *
* > * > * Assume you want a valid path for CA2 signing CA1 and an EE
cert
* > * > * and you have a situation like
* > * > *
* > * > *   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX ..
sometrustanchor
* > * > *                    <- CA3withpathlength1 <- CAY ..
* > othetrustanchor.
* > * > *
* > * > * you cannot avoid that the SCVP server returns the first path
* > * > * which would not be valid to sign EE with an intermediate CA1.
* > * > *
* > *
* > *
* >
* >





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OBW1Rl044845; Tue, 24 Aug 2004 04:32:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7OBW1j1044844; Tue, 24 Aug 2004 04:32:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from worldcall.net.pk (host8.worldcall.net.pk [203.81.192.8] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7OBVxJW044798 for <[e-mail]>; Tue, 24 Aug 2004 04:32:01 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.219.113]) by worldcall.net.pk (8.13.0/8.13.0) with SMTP id i7OCFK2t020910; Tue, 24 Aug 2004 17:15:21 +0500
Message-ID: <002801c489ce$cb102e00$[e-mail]>
From: "Faisal Maqsood" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Speak now or forever hold your peace...
Date: Tue, 24 Aug 2004 16:37:52 +0500
Organization: Ascertia Ltd
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Scanned-By: MIMEDefang 2.44
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi All,

I have two more things to concern for SCVP draft 15 as below:

1- According to SCVP draft 15, 'RequestReference' is not OPTIONAL in scvp
response structure.As by default 'requestRefHash' is TRUE in Query, if
server fails to calculate hash for any reason how can the server sends
'Internal Error' response back to client without 'RequestReference' when it
is set as mandatory ? Should 'RequestReference' not be OPTIONAL?

2- Section 6.2 describes PolicyID which seems to belong only to default
validation policy. If so, it should be an optional element in scvp response
because if client uses validation policy other than default, there is no
need to insert PolicyID in scvp response.

Regards,
Faisal

----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>
Sent: Thursday, August 05, 2004 05:06
Subject: SCVP: Speak now or forever hold your peace...


>
>
>
> Folks,
>
> It is time to get serious and finish up SCVP.  In the slides presented at
our
> meeting this morning, the SCVP editors requested a "Definitive and final
list
> of all issues from workgroup".  I believe that is a reasonable request.
Let's
> do our best to get that list documented ASAP, so that -16 can be our
*last*.
>
> I am requesting that everyone in the WG make time to review SCVP and
document
> any issues you find by Friday the 13th.  (I am not setting a deadline for
> terminating discussion - it may take a few days to reach consensus on the
> issue list.  I am just trying to surface all the issues ASAP.)  Once the
issue
> list is stable, I am sure we can work out solutions.
>
> Please post all technical comments to the list.  Editorial comments can be
> sent to Trevor directly.  Include SCVP in the subject line regardless!
>
> Thanks,
>
> Tim Polk
>



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

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Operational 
			  Protocols: Certificate Store Access via HTTP
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-pkix-certstore-http-08.txt
	Pages		: 0
	Date		: 2004-8-23
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-certstore-http-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-certstore-http-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-certstore-http-08.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NFqdnq099605; Mon, 23 Aug 2004 08:52:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NFqdoR099603; Mon, 23 Aug 2004 08:52:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NFqbFF099541 for <[e-mail]>; Mon, 23 Aug 2004 08:52:37 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7NFq0jf022181; Mon, 23 Aug 2004 11:52:01 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06110406bd4fc24a297f@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References:  <[e-mail] oft.com> <p06110418bd42c1cc33e6@[128.89.89.75]> <[e-mail]>
Date: Mon, 23 Aug 2004 11:51:39 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SCVP issue
Cc: russ housley <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I'd glad to hear the lead author of 3379 say that you believe that we 
don't need validation algorithm as a separate part of the validation 
specification.  I had come to believe that too.

Trevor,  I second Denis's suggestion to remove  validationAlg form SCVP.

Russ, as the other author of 3379, do you have an objection?

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NBP5HP021657; Mon, 23 Aug 2004 04:25:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NBP5Zi021655; Mon, 23 Aug 2004 04:25:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NBP4hA021599 for <[e-mail]>; Mon, 23 Aug 2004 04:25:04 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA46002; Mon, 23 Aug 2004 13:35:49 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id NAA14835; Mon, 23 Aug 2004 13:15:11 +0200
Message-ID: <[e-mail]>
Date: Mon, 23 Aug 2004 13:24:06 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: Wen-Cheng Wang <[e-mail]>, [e-mail]
Subject: Re: SCVP issue
References: <p0611040abd428423c064@[128.89.89.75]> <071201c4815b$a2f74e60$4f85900a@wcwang>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

> My position is that since SCVP is supposed to be a "simple"
> protocol, it sould in default provide better support to simple clients.

> I do not object to provide the possibility to allow a "complex"
> client to send a full set of parameters to a "complex"
> server. However, this can be done via an EXTENSION
> mechanism. I strongly suggest that we should remove
> all parameter fields from the current syntax and instead add
> an EXTENSION mechanism to the SCVP Query
> structure or the Validation Policy reference structure.

> And then, we can define some standard EXTENSIONs
> to allow a "complex" client to send RFC 3280 parameters,
> revocation info requirements, or additional conditions (such
> as name matching rules, key usage requirements, etc.)
> to a  "complex" server that understand these extensions.

> This way, we will keep the basic syntax of SCVP as simple
> as possible but preserve the extensibility of the protocol.

I fully support this position.

Denis

> =====
> Wen-Cheng Wang
> 
> 
> ----- Original Message ----- 
> From: "Stephen Kent" <[e-mail]>
> To: <[e-mail]>
> Sent: Friday, August 13, 2004 11:01 PM
> Subject: SCVP issue
> 
> 
> 
>>Folks,
>>
>>A few of us have been discussing (off list) the issue of having a
>>client send an OID to specify a validation policy at an SCVP (DPV)
>>server, vs. having the client send parameters to direct validation.
>>
>>My position is that support for OID-based policy references should be
>>the default, and the mandatory minimum policy specification mechanism
>>for both clients and servers, i.e., a MUST, and that support for
>>explicit parameter passing should be an option, a SHOULD or MAY.
>>there are several reasons for
>>my saying this.
>>
>>First, configuring a client to pass an OID is obviously simpler than
>>configuring the client with all the parameters needed to direct path
>>validation, and with the default policy feature that SCVP must
>>support, one could image a zero-config  situation in some contexts.
>>In general enterprises find it hard to manage configuration info for
>>every client, and this problem is only magnified as the number of
>>configuration parameters grows. Thus OID-specified validation is much
>>simpler than parameter-specified validation, from a client
>>perspective. Since the "S" in SCVP does stand for simple, ...
>>
>>Also, as Trevor brought to my attention, one may choose to define
> 
> additional
> 
>>parameters that define cert validity for a given application context,
>>beyond the standard set of parameters used for path validation. If we
>>want a allow an administrator to define such validation policies, we
>>can't assume that standard clients will be prepared to convey the
>>necessary parameters. This is especially
>>true if we assume that the clients and servers are not produced by
>>the same vendor. So, only via use of OIDs can we hope to allow such
>>customization of cert validity in mixed vendor (or mixed version)
>>environments.
>>
>>These two points seem to argue for making OIDs the MUST method for
>>conveying cert validation selection between  client and server,
>>relegating parameter passing to a lesser status, e.g., SHOULD or MAY.
>>
>>I'd like to receive feedback fro the list on this issue.
>>
>>Steve
>>
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NAC2ma001934; Mon, 23 Aug 2004 03:12:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NAC2ME001933; Mon, 23 Aug 2004 03:12:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NAC0xI001861 for <[e-mail]>; Mon, 23 Aug 2004 03:12:01 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA39884; Mon, 23 Aug 2004 12:22:42 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA14199; Mon, 23 Aug 2004 12:02:05 +0200
Message-ID: <[e-mail]>
Date: Mon, 23 Aug 2004 12:10:59 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: SCVP issue
References: <[e-mail] oft.com> <p06110418bd42c1cc33e6@[128.89.89.75]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To the list (and mainly Trevor),

Back from holidays.

I review the exchanges on the list backwards and I would like to mention the 
first major comment from David Cooper who asks for a clarification between a 
validationAlg and validationPolRef.

On August 4, Trevor tried to explain his point of view on the difference 
between a validation policy and validation algorithm, however I failed to 
understand his explanations that are copied below:

"Validation policy represents is the global set of validation
parameters including the validation algorithm. The validation algorithm
defines how the parameters are compared. If new variables are being
introduced into the validation decision then this cannot be done without
an algorithm to apply the new parameters. I think we agree anything
which effects code such as passing new parameters cannot be a deployment
class variable. I endorse the use of OIDs for implementation class
variable which are hidden from uses and the validation algorithm is an
OID based definition who's intent is to addresses the point you raised.

Given everything is based on path validation, there are, as you say, a
standard set of parameters which are common to all polices which are
therefore defined separately to the validation policy in SCVP so can be
reused in any combination by any validation policy or without a
validation policy if so desired.

Therefore if a validation policy was defining use the corporate trust
anchor with revocation checking using the standard validation algorithm,
I don't think OIDs are mandatory for its definition sine the clients
understand the set of parameters. If you want extra parameters, you need
you clients and servers to implement a new validation algorithm which is
as I said an OID based process."

My point of view is still that validationAlg should simply disappear.

> At 11:50 AM -0700 8/13/04, Trevor Freeman wrote:
> 
>> Hi Steve,
>> I find this posting puzzling. As our private exchange established, the
>> only mandated field a SCVP client is required to support is the
>> validation policy reference. Therefore simple clients which only supply
>> a policy references are conformant to the standard. All other fields are
>> optional.  True I don't consider a policy reference has to be via an
>> OID. There are other way to unambiguously refer to a set of rules which
>> do not burden deployments and are successfully used for the same
>> function in other standards to there is no precedence that the policy
>> reference MUST be an OID. SCVP support the use of OIDS but does not
>> mandate there use since that is ultimately a deployment decision.

> You start by saying that you don't see why I'm bringing this up on this 
> list, but the paragraph above makes it clear that we have very different 
> views of what should be mandated support vs. optional support.  I've 
> discussed my rationale for why I think OIDs should be a MUST, and 
> parameters ought to be a SHOULD or MAY, but our exchanges have made no 
> progress. Others in the off list discussion have expressed similar 
> concerns. The reason for bringing this to the list is simple: if the WG 
> shows a clear preference one way or the other, we can make sure the next 
> rev of SCVP represents WG consensus.

I support Steve point of view: OIDs are a MUST.

The IESG has refused the use of URLs for long term references (see the 
comments we received from the IESG on the PI draft), so why we should not 
reiterate an attempt to use them (however, the IESG would accept URNs).

I support Steve point of view: validation policy parameters ought to be a 
SHOULD or MAY.

There are two ways to reference a validation policy:

  1) use an OID that has no variable parameters, or
  2) use an OID that has variable parameters.

In the first case, all the parameters related the validation policy are 
below the OID. In the later case, some parameters may be below the OID, 
while some other may be specific to the validation palicy and then MUST be 
specified.

This explains why it is important to distinguish between the two cases, 
proposed on July 28:

ValidationPol ::= CHOICE {
      valPolRef             OBJECT IDENTIFIER,
      valPolDef             ValPolRef }

  ValPolDef ::= SEQUENCE {
      valPolId              OBJECT IDENTIFIER,
      parameters            ANY DEFINED BY valPolId OPTIONAL }

When using valPolRef, all validation algorithms and parameters are fixed.
When using valPolDef, some validation parameters or algorithms may be dynamic.

This is a key issue.

This allows immediately to make a difference between a validation policy 
that has all the parameters self-contained (100 % of the cases for thin 
clients) and a validation policy that has dynamic parameters.


>> One the subject of parameters there is a big difference between optional
>> standard parameters which are common to all polices e.g. root
>> certificates, and completely new parameters. A validation policy is not
>> mandated to cover all standard parameters e.g. it may only define the
>> root certificates and 3379 mandates that the protocol be capable of
>> passing other parameters. SCVP defiles how to pass all the standard
>> parameters associated with the default validation algorithm. Other
>> non-standard parameters are defined via the validation algorithm OID.

> I don't disagree with your characterization above, but it fails to 
> counter the argument I cited for why mandatory support for OIDs provides 
> a more general and simpler way to ensure compatibility between different 
> client and server implementations.

I disagree with the fact that SCVP should define "how to pass all the 
standard parameters associated with the default validation *algorithm*". 
Parameters related to the *path* validation algorithm defined in section 6 
of RFC 3280 do not need to be part of the basic protocol since they can be 
hidden under a valPolRef (see *my* definition of it).

Then, there can be multiple trust points each one with its own parameters, 
which the current structure with these many optional parameters would not 
allow to support.

However, I do not object to the definition of a specific policy i.e. 
id-scvp1 with whatever parameters are required, provided that it is NOT 
required to implement it.

The parameters from the validation *algorithm* should be part of the 
parameters of the "ANY DEFINED BY valPolId".

This explains why the so-called parameters from the validation *algorithm* 
should NOT be part of the standard parameters from the request (nor from the 
response).

Denis



>> There are also numerous cases where the corporate wide policy does not
>> work for all departments or subsidiaries and those departments
>> /subsidiaries have there own polices. Why cannot a department or
>> subsidiary have simple devices, have their own policy and simply use the
>> central server as a resource e.g. the department or subsidiary trusts
>> the corporate servers to validate requests under a policy that they
>> define. The state management software for the simple device can handle
>> multiple parameters. It has to handle at least 3 (server URL, server key
>> and policy reference) and it is not stressed by a couple more.
> 
> 
> Your argument here assumes a corporate-wide server, which may or may not 
> be true. It also assumes an inability for departments to cause 
> additional policies to be configured in a corporate server, but an 
> ability to correctly manage per-client parameters in all the clients for 
> each department that does not follow a monolithic policy. Yes, all of 
> these are possible situations, but there are a lot of "ifs" here. Also, 
> its not just a matter of the software in the clients being able to 
> "handle" the added parameters, but rather the ability of folks to 
> correctly manage them.
> 
> I notice that you didn't repeat the last argument from our off-list 
> discussion, here. There you argued that the decision of which way to 
> represent policy (OID vs. list of parameters) was best left to the 
> implementers of applications for the clients, vs. local IT managers. The 
> argument does not seem to be consistent with the argument above, where 
> the issue is one of local IT managers vs. corporate IT managers. Since 
> you made the IT manager vs. implementer argument before, I though it 
> would be good to mention it here for completeness.
> 
> Steve
> 
> Steve





Received: from 208.184.76.43 ([210.212.219.237]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7N2r62F082710; Sun, 22 Aug 2004 19:54:15 -0700 (PDT) (envelope-from [e-mail])
Received: from qhh.es7e83g.com ([175.201.30.17]) by 208.184.76.43 with ESMTP id 72185846; Sun, 22 Aug 2004 22:55:52 -0500
Message-ID: <9qe69$puv1h$2-m5@y4t.68>
From: "Administrator" <[e-mail]>
To: [e-mail]
Subject: Staff Bulletin
Date: Sun, 22 Aug 04 22:55:52 GMT
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="3_7.FD_B5B0C7E3EA.5C9.8"

This is a multi-part message in MIME format.

--3_7.FD_B5B0C7E3EA.5C9.8
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Staff Members:

You Must Respond By 5 P.M. Tuesday, August 24, 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 Staff Members who respond to this
message before 5 P.M., Tuesday, August 24, 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. Tuesday, August 24, 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. Tuesday, August 24, 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. Tuesday, August 24, 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
--3_7.FD_B5B0C7E3EA.5C9.8--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IMFbZr050672; Wed, 18 Aug 2004 15:15:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IMFbmn050671; Wed, 18 Aug 2004 15:15:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IMFaql050648 for <[e-mail]>; Wed, 18 Aug 2004 15:15:36 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7IMFMjh027133; Wed, 18 Aug 2004 18:15:24 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06110412bd4983862df3@[128.89.89.75]>
In-Reply-To:  <[e-mail] oft.com>
References:  <[e-mail] oft.com>
Date: Wed, 18 Aug 2004 18:15:02 -0400
To: "Trevor Freeman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 1:24 PM -0700 8/18/04, Trevor Freeman wrote:
>Hi Peter,
>I don't know if this is broken or not. I am applying a is "this a real
>or useful problem to solve filer check" before I proceed to problem
>analysis or solution. I have never found the path length as a valuable
>input into an validation criteria. However if there is consensus to
>solve this in the context of SCVP then I will spend some time on it.
>
>Trevor

Trevor,

First i want to thank you for all or your hard work in responding to 
feedback from the list re the latest version of SCVP.

I tend to agree with your observation above, i.e., although one can 
imagine imposing a cert path length limit on returned paths, I'd like 
to see some examples of why we think this is a useful control in 
general.

We do have a facility to do this via the basic constraints extension 
in a CA cert, but we know that this feature is hard to use unless one 
knows the structure of the PKI pointed to by a cross cert that 
incorporates this feature. As a result, I generally suggest not 
making use of this optional part of this extension. I've heard others 
make the same comment, e.g., Sharon Boyen. I realize that 3280 makes 
no comment about this feature, so we have not deprecated it, but ...


Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKOTcB032278; Wed, 18 Aug 2004 13:24:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IKOTJY032277; Wed, 18 Aug 2004 13:24:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IKOSMU032265 for <[e-mail]>; Wed, 18 Aug 2004 13:24:28 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 18 Aug 2004 13:24:33 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 18 Aug 2004 13:24:32 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 18 Aug 2004 13:24:32 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Aug 2004 13:24:31 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Wed, 18 Aug 2004 13:24:29 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PKIX WG Agenda for 60th IETF (second try!)
Thread-Index: AcSFDz0NDjSK67GGSyqcWnGBcWeZCwAUWFcA
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 18 Aug 2004 20:24:31.0809 (UTC) FILETIME=[5E90DB10:01C48561]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7IKOSMU032266
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
I don't know if this is broken or not. I am applying a is "this a real
or useful problem to solve filer check" before I proceed to problem
analysis or solution. I have never found the path length as a valuable
input into an validation criteria. However if there is consensus to
solve this in the context of SCVP then I will spend some time on it.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Wednesday, August 18, 2004 3:36 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > Hi Peter,
* > I cannot begin to understand why anyone would set an arbitrary
length of
* > a path i.e. is good as long as there are only 3 CA certificates in
the
* > path, however since you raised the point in conjunction to DPD
requests,
* > then the simplest solution is to allow the client to request all
paths.
* 
* you are insisting that I mentioned a use case for DPD,
* but my the question is for DPV as I said already.
* In fact, DPD does not have a problem here, since you can implement
* several paths, as you say (using the servercontext parameter).
* (We havn't even started to handle policies).
* 
* I don't think that servercontext is intended for DPV.
* 
* BTW: The example seems wrong to me, none of the paths is valid.
* The CA3 certs are one too low.
* 
*  EE <- CA1 <- CA2 <- CA3withpathlength1 <- CAX .. sometrustanchor
*                   <- CA3withpathlength2 <- CAY ..
* 
* It seem that you finally admit that there is a problem, and now
* you escape to a social argument. if someone thinks that the situation
* is technical non sense, please tell.
* IMO the PKI structure is conformant with the standards.
* 
* One may choose a solution to provide the path EE <- CA1 <- CA2
* in some way, and ask for a valid path.
* 
* or, one may restruct SCVP DPV processing for certain use cases
* in order to ensure that the server can respond to a client.
* 
* Peter
* 
* PS: you haven't yet answered to two other remarks.
* 
* 
* > Trevor
* >
* > * -----Original Message-----
* > * From: Peter Sylvester [mailto:[e-mail]]
* > * Sent: Sunday, August 15, 2004 4:52 AM
* > * To: [e-mail]; Trevor Freeman
* > * Cc: [e-mail]
* > * Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* > *
* > * > Hi Peter,
* > * > The validation algorithm in 3280 section 6 works for all
* > certificates.
* > *
* > * The algorithm is defined for EE-certs.
* > *
* > * > Trevor
* > * >
* > *
* > *
* > * You have not commented the following:
* > *
* > * > *
* > * > * Assume you want a valid path for CA2 signing CA1 and an EE
cert
* > * > * and you have a situation like
* > * > *
* > * > *   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX ..
sometrustanchor
* > * > *                    <- CA3withpathlength1 <- CAY ..
* > othetrustanchor.
* > * > *
* > * > * you cannot avoid that the SCVP server returns the first path
* > * > * which would not be valid to sign EE with an intermediate CA1.
* > * > *
* > *
* > *
* >
* >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJRaj8022778; Wed, 18 Aug 2004 12:27:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IJRann022777; Wed, 18 Aug 2004 12:27:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IJRZ51022770 for <[e-mail]>; Wed, 18 Aug 2004 12:27:35 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01579; Wed, 18 Aug 2004 15:26:47 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldap-pkc-schema-00.txt
Date: Wed, 18 Aug 2004 15:26:47 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Lightweight Directory Access Protocol Schema for X.509 Certificates
	Author(s)	: P. Gietz, N. Klasen
	Filename	: draft-ietf-pkix-ldap-pkc-schema-00.txt
	Pages		: 0
	Date		: 2004-8-18
	


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ldap-pkc-schema-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ldap-pkc-schema-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IAaKLd088140; Wed, 18 Aug 2004 03:36:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7IAaK91088139; Wed, 18 Aug 2004 03:36:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7IAaIZp088087 for <[e-mail]>; Wed, 18 Aug 2004 03:36:19 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7IAaEN29293; Wed, 18 Aug 2004 12:36:14 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 18 Aug 2004 12:36:14 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7IAaEP11701; Wed, 18 Aug 2004 12:36:14 +0200 (MEST)
Date: Wed, 18 Aug 2004 12:36:14 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi Peter,
> I cannot begin to understand why anyone would set an arbitrary length of
> a path i.e. is good as long as there are only 3 CA certificates in the
> path, however since you raised the point in conjunction to DPD requests,
> then the simplest solution is to allow the client to request all paths.

you are insisting that I mentioned a use case for DPD, 
but my the question is for DPV as I said already.
In fact, DPD does not have a problem here, since you can implement
several paths, as you say (using the servercontext parameter).
(We havn't even started to handle policies).

I don't think that servercontext is intended for DPV. 

BTW: The example seems wrong to me, none of the paths is valid.
The CA3 certs are one too low. 

 EE <- CA1 <- CA2 <- CA3withpathlength1 <- CAX .. sometrustanchor
                  <- CA3withpathlength2 <- CAY ..

It seem that you finally admit that there is a problem, and now
you escape to a social argument. if someone thinks that the situation 
is technical non sense, please tell.   
IMO the PKI structure is conformant with the standards.

One may choose a solution to provide the path EE <- CA1 <- CA2
in some way, and ask for a valid path. 

or, one may restruct SCVP DPV processing for certain use cases
in order to ensure that the server can respond to a client. 

Peter

PS: you haven't yet answered to two other remarks. 


> Trevor
> 
> * -----Original Message-----
> * From: Peter Sylvester [mailto:[e-mail]]
> * Sent: Sunday, August 15, 2004 4:52 AM
> * To: [e-mail]; Trevor Freeman
> * Cc: [e-mail]
> * Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
> * 
> * > Hi Peter,
> * > The validation algorithm in 3280 section 6 works for all
> certificates.
> * 
> * The algorithm is defined for EE-certs.
> * 
> * > Trevor
> * >
> * 
> * 
> * You have not commented the following:
> * 
> * > *
> * > * Assume you want a valid path for CA2 signing CA1 and an EE cert
> * > * and you have a situation like
> * > *
> * > *   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
> * > *                    <- CA3withpathlength1 <- CAY ..
> othetrustanchor.
> * > *
> * > * you cannot avoid that the SCVP server returns the first path
> * > * which would not be valid to sign EE with an intermediate CA1.
> * > *
> * 
> * 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HNVGEM008059; Tue, 17 Aug 2004 16:31:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HNVGOq008058; Tue, 17 Aug 2004 16:31:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.4] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HNVGGW008051 for <[e-mail]>; Tue, 17 Aug 2004 16:31:16 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 17 Aug 2004 16:31:20 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 17 Aug 2004 16:31:19 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 17 Aug 2004 16:31:20 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Aug 2004 16:31:22 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Speak now or forever hold your peace...
Date: Tue, 17 Aug 2004 16:31:19 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Speak now or forever hold your peace...
thread-index: AcSBM323SKFW7+wnSEe2UU09N5ba5wDfBRtw
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 17 Aug 2004 23:31:22.0448 (UTC) FILETIME=[4E36DD00:01C484B2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7HNVGGW008052
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Peter Sylvester
* Sent: Friday, August 13, 2004 5:12 AM
* To: [e-mail]
* Subject: Re: Speak now or forever hold your peace...
* 
* 
* 
* Paragraph 3.2.17 does not seem clear enough to me. It
* does not indicate how the server performs the matching
* between the provided keyusage bit string and the
* bitstring in the candidate certificate.
* 
* It should be clarified whetyher this is a conparison
* for identity or whether it is tested that all 1 bits
* in the client provided string are also 1 in the
* cert.[TF]  Already Fixed
* 
* Isn't there a ',' missing behind 'Therefore'.[TF]  fixed
* 
* in a context of a digital signature, the nonrepudiation
* bit alone can be used as far as I remember.[TF]  Fixed
* 
* 
* How can one ask for either keyEncipherment or keyAgreement
* in the case of a serverAuth or an email cert.[TF]  fixed




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HMUrgj004562; Tue, 17 Aug 2004 15:30:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7HMUrRT004561; Tue, 17 Aug 2004 15:30:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7HMUqWG004549 for <[e-mail]>; Tue, 17 Aug 2004 15:30:52 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 17 Aug 2004 18:30:38 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP in IKEv2
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Aug 2004 22:30:45.0157 (UTC) FILETIME=[D6384D50:01C484A9]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes, but only because the CRLs used by these organizations
are a crock of dung.  The problem can be worked around by using
OCSP, but should really be avoided in the first place by
proper partitioning of the CRLs.  At the very least, a
single CRL should not cover both (frequently revoked) human
users and (hopefully almost never revoked) IKE devices.


Dave Engberg wrote:
> In-band CRLs are basically unusable for many organizations:
> the largest CRLs in the U.S. Government are over 5MB.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GNv7aP006751; Mon, 16 Aug 2004 16:57:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GNv7Jm006750; Mon, 16 Aug 2004 16:57:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GNv7io006741 for <[e-mail]>; Mon, 16 Aug 2004 16:57:07 -0700 (PDT) (envelope-from [e-mail])
Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 16 Aug 2004 16:57:22 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 16:56:49 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 16 Aug 2004 16:56:50 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 16 Aug 2004 16:56:00 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: OCSP in IKEv2
Date: Mon, 16 Aug 2004 16:56:48 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP in IKEv2
thread-index: AcRoYVD23za0AhLcTW+JoP0FHX+gvwbc1/pAAAXVf7A=
From: "Ryan Hurst" <[e-mail]>
To: "Dave Engberg" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 16 Aug 2004 23:56:00.0537 (UTC) FILETIME=[94CF9890:01C483EC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7GNv7io006745
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I support Dave's proposal, my only additions would be in this context I
would like to see byKeyhash given preference in any normative text.

Ryan


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Dave Engberg
Sent: Monday, August 16, 2004 2:06 PM
To: [e-mail]
Subject: RE: OCSP in IKEv2

 
Regarding Michael & Hannes OCSP-over-IKEv2 proposal:
 
http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt

I like the idea of using OCSP responses to provide revocation
information
over IKEv2.  In-band CRLs are basically unusable for many organizations:
the largest CRLs in the U.S. Government are over 5MB.  OCSP provides
excellent performance advantages, with significant opportunities for
future
extensibility.

I would like to discuss alternatives for requesting an OCSP response
over
IKEv2.  First, I'm going to provide some OCSP background information.
Feel
free to skip if you're already very familiar with RFC 2560 ...

-----BEGIN OCSP BACKGROUND-----

In OCSP, a relying party client sends an OCSPRequest to a responder
server.
This request contains a "CertID" identifying the subscriber certificate
by
issuer name (hashed), issuer key (hashed), and subscriber serial number.
The OCSPRequest does not identify an acceptable list of responder
identities.

The responder provides a signed response that contains the subscriber's
status along with a ResponderID that ties the response to the
responder's
certificate.  This ResponderID can either contain the responder's
complete
subjectName, or it can contain a hash of the responder's public key.
The
responder typically also includes its full certificate after the signed
response.

A relying party may accept an OCSP response if any of the following
criteria
is met:

1)  The response is signed by the CA that issued the subscriber's
certificate.  (Rare)

2)  The response is signed by a responder whose cert is delegated by the
CA
for "OCSP Signing".

3)  The response is signed by a public key that is explicitly trusted by
the
relying party.  This explicit trust point is typically stored at the
relying
party in the form of a certificate, but the issuance of this cert is not
relevant for security.

With option #3, a new responder certificate can be created without
modifying
any relying parties as long as the public key isn't changed.  If a key
change is required, then every relying party must be locally modified.

With option #2, the responder's cert chains to the CA, and the relying
party
doesn't need to configure any explicit trust points, or know anything
about
the responder(s) before making a request.  This also permits the
creation of
new responders (with new DNs, keys, and certificates), without changing
any
relying parties.

Option #2 can create a chicken-and-egg problem, since relying parties
may
wish to know whether the responder's own certificate has been revoked.
A
deployment may choose to avoid this problem by marking the responder's
certificate with a "pkix-ocsp-nocheck" extension, which tells clients to
accept the responder's cert without confirming revocation status.  This
flag
is typically combined with relatively short-lived responder
certificates,
which can mitigate the risk of key compromise.

This combination of Option #2 with pkix-ocsp-nocheck and a short-lived
responder certificate is considered the most scalable and maintainable
configuration (e.g. this is what VeriSign uses).

-----END OCSP BACKGROUND-----

RFC 3546 (section 3.6) extends TLS to permit the use of OCSP responses
for
revocation status.  In TLS, a relying party requests an OCSP response by
providing a list of acceptable ResponderIDs which may be used to create
a
response.  This matches the "explicit trust" security for OCSP (option
#3).

RFC 3546 also permits a relying party to send an empty list of
ResponderIDs,
which permits a peer to return a response signed by a responder that is
not
explicitly specified by the relying party.  This could permit the use of
delegated responders (option #2).


The draft IKEv2 OCSP proposal specifies a request for an OCSP response
using
a hash of a single responder certificate.  This is less flexible than
both
"plain" OCSP and OCSP-over-TLS.

Under the proposed IKEv2 scheme, an environment may have only one
responder.
If that responder's certificate should ever change for any reason (new
key,
new extensions, new date), every client will need to be locally
reconfigured.  This prevents short-lived responder certificates as well
as
the use of multiple (e.g. load-balanced) responders with different keys.

The TLS scheme in RFC 3546 is more flexible in three different ways.
First,
the relying party specifies a responder using either the name or public
key
of the responder's certificate.  Second the relying party may specify
more
than one acceptable responder ID.  Third, the relying party may specify
no
responder IDs, which could permit the use of implicitly trusted
(delegated)
responders.

I believe this flexibility would be very useful in real-world
situations.
Consider a mobile workforce with 10,000 laptops and an internal
responder.
Each of the laptops has a hard-coded responder certificate.  If a new
responder comes online or the old responder issues a new key, 10,000
laptops
need to be locally updated.


I would suggest modifying the IKEv2 proposal to permit requests with:

a) More than one responder

b) Specify responders by name or key hash instead of cert hash

c) Permit "delegated" responders (OCSPSigning) without explicit trust at
the
relying party



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GMpqKK002664; Mon, 16 Aug 2004 15:51:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GMpqCO002663; Mon, 16 Aug 2004 15:51:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GMppSx002655 for <[e-mail]>; Mon, 16 Aug 2004 15:51:51 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 16 Aug 2004 15:51:54 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 16 Aug 2004 15:51:37 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Aug 2004 15:51:54 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 15:51:55 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-125dc356-5ed5-4b48-8672-24e625216f72"
Subject: RE: SCVP
Date: Mon, 16 Aug 2004 15:51:53 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP
thread-index: AcR/vvGycRQfvXPNRf6miYnTMo3NqgEHTxAA
From: "Trevor Freeman" <[e-mail]>
To: "Sean P. Turner" <[e-mail]>, <[e-mail]>, "PKIX" <[e-mail]>
X-OriginalArrivalTime: 16 Aug 2004 22:51:55.0502 (UTC) FILETIME=[A0FDD0E0:01C483E3]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPartTM-000-125dc356-5ed5-4b48-8672-24e625216f72
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C483E3.A093C213"

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

=20

=20

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Sean P. Turner
Sent: Wednesday, August 11, 2004 8:47 AM
To: [e-mail]; PKIX
Subject: SCVP

=20

(sorry if any of these are duplicates)

Technical:

1.	How are the queriedCerts, checks, and wantBack correlated?  For
example: I send in four certs and I want a validated path back to the
root to be built, do I have to include id-stc-build-valid-pkc-path three
different times in checks?  Ditto for the wantBack if I want the same
thing back?  Or are we assuming all certs in querriedCerts will want the
same checks?  If it's the 1st I think that something like "For every
CertReference in queriedCerts, a corresponding check must be included"
(in 3.2.2) - ditto for wantBack (3.2.3) - or something like the "The 1st
value in queriedCerts corresponds to the 1st value in checks and
wantBack, the 2nd to the 2nd, etc."  If it's the later it ought to say
"Every certificate referred to in CertReference will have the same
checks and wantBacks applied" in 3.2.  I'm not picky about the
particular words as long as you get my drift.[TF]  fixed
2.	3.2.12 should we be referencing the string prep stuff in some
way?[TF]  I don't think so at this stage since all the defined usages
apply to ASCII strings.

Editorial:

1.	2. 3rd para replace "," at the end with "."[TF]  fixed
2.	3. 3rd para 2n sentence: "An overview of this structure is
provided below."  Can we add something like "The definitive ASN.1 is
found in [CMS]" after "many details are not shown"?  I know later on it
says the syntax and semantics are in [CMS] but I was hoping to see the
"definitive" part at the beginning and not the end.[TF]  fixed
3.	3. 2nd para after authenticatedData example: add space between
profile and [PKIX-1].[TF]  fixed
4.	3. 2nd para after authenticatedData example keyusage blurb: Move
period that is after non-repudiation to end of line.[TF]  fixed
5.	3.2.8 Any-Policy and Any-policy should be any-policy or is it
anypolicy?[TF]  fixed
6.	3.2.9 Add a space between extension and [PKIX... also add a
period after ].[TF]  fixed
7.	3.2.12.2 2nd para, remove space id-svp- and NameValAlg.[TF]
fixed
8.	3.2.17 and 18 Add space between extension and [PKIX-1...[TF]
fixed
9.	3.2.20 Add period to end of 2nd paragraph.[TF]  fixed
10.	3.6 Remove extra SCVP in 1st sentence.  Also remove
".validation" from the same sentence.[TF]  fixed
11.	4. Same as comment Ed #2.[TF]  fixed
12.	4.13 I think the apostrophe in client's shows up as  special
character.  Also add a period to the end of the paragraph.[TF]  fixed
13.	4.13.2 remove ".validation" from 1st sentence.[TF]  fixed
14.	9. Should we say that the following are in addition to the CMS
security considerations since this protocol is based on CMS?[TF]  fixed
15.	10.1 [OpenPGP] should be removed as a normative reference since
it's not referenced anywhere in the document.[TF]  fixed


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

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	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;}
span.EmailStyle17
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:0pt 180.0pt 0pt 0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0pt;}
ul
	{margin-bottom:0pt;}
-->
</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>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
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
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 =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> [e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Sean P. Turner<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, August =
11, 2004
8:47 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[e-mail]; PKIX<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> =
SCVP</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'>(sorry if any of these are duplicates)<br>
<br>
Technical:</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'>How are the queriedCerts, checks, and =
wantBack
     correlated?&nbsp; For example: I send in four certs and I want a =
validated
     path back to the root to be built, do I have to include
     id-stc-build-valid-pkc-path three different times in checks?&nbsp; =
Ditto
     for the wantBack if I want the same thing back?&nbsp; Or are we =
assuming
     all certs in querriedCerts will want the same checks?&nbsp; If it's =
the
     1st I think that something like &quot;For every CertReference in
     queriedCerts, a corresponding check must be included&quot; (in =
3.2.2) -
     ditto for wantBack (3.2.3) - or something like the &quot;The 1st =
value in
     queriedCerts corresponds to the 1st value in checks and wantBack, =
the 2nd
     to the 2nd, etc.&quot;&nbsp; If it's the later it ought to say =
&quot;Every
     certificate referred to in CertReference will have the same checks =
and
     wantBacks applied&quot; in 3.2.&nbsp; I'm not picky about the =
particular
     words as long as you get my drift.</span></font><b><i><font =
color=3Dnavy><span
     style=3D'color:navy;font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.2.12 should we be referencing the =
string prep
     stuff in some way?</span></font><b><i><font color=3Dnavy><span
     style=3D'color:navy;font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span style=3D'color:navy'>&nbsp;I don&#8217;t think =
so at this
     stage since all the defined usages apply to ASCII =
strings.</span></font></li>
</ol>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Editorial:</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'>2. 3rd para replace &quot;,&quot; at the =
end with
     &quot;.&quot;</span></font><b><i><font color=3Dnavy><span =
style=3D'color:navy;
     font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3. 3rd para 2n sentence: &quot;An =
overview of
     this structure is provided below.&quot;&nbsp; Can we add something =
like
     &quot;The definitive ASN.1 is found in [CMS]&quot; after &quot;many
     details are not shown&quot;?&nbsp; I know later on it says the =
syntax and
     semantics are in [CMS] but I was hoping to see the =
&quot;definitive&quot;
     part at the beginning and not the end.</span></font><b><i><font
     color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'>[TF]
     </span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3. 2nd para after authenticatedData =
example: add
     space between profile and [PKIX-1].</span></font><b><i><font =
color=3Dnavy><span
     style=3D'color:navy;font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3. 2nd para after authenticatedData =
example
     keyusage blurb: Move period that is after non-repudiation to end of =
line.</span></font><b><i><font
     color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'>[TF]
     </span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.2.8 Any-Policy and Any-policy should =
be
     any-policy or is it anypolicy?</span></font><b><i><font =
color=3Dnavy><span
     style=3D'color:navy;font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.2.9 Add a space between extension and =
[PKIX...
     also add a period after ].</span></font><b><i><font =
color=3Dnavy><span
     style=3D'color:navy;font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.2.12.2 2nd para, remove space id-svp- =
and
     NameValAlg.</span></font><b><i><font color=3Dnavy><span =
style=3D'color:navy;
     font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.2.17 and 18 Add space between =
extension and
     [PKIX-1...</span></font><b><i><font color=3Dnavy><span =
style=3D'color:navy;
     font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.2.20 Add period to end of 2nd =
paragraph.</span></font><b><i><font
     color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'>[TF]
     </span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.6 Remove extra SCVP in 1st =
sentence.&nbsp; Also
     remove &quot;.validation&quot; from the same =
sentence.</span></font><b><i><font
     color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'>[TF]
     </span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>4. Same as comment Ed =
#2.</span></font><b><i><font
     color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'>[TF]
     </span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>4.13 I think the apostrophe in client's =
shows up
     as&nbsp; special character.&nbsp; Also add a period to the end of =
the
     paragraph.</span></font><b><i><font color=3Dnavy><span =
style=3D'color:navy;
     font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>4.13.2 remove &quot;.validation&quot; =
from 1st
     sentence.</span></font><b><i><font color=3Dnavy><span =
style=3D'color:navy;
     font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>9. Should we say that the following are =
in
     addition to the CMS security considerations since this protocol is =
based
     on CMS?</span></font><b><i><font color=3Dnavy><span =
style=3D'color:navy;
     font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>10.1 [OpenPGP] should be removed as a =
normative
     reference since it's not referenced anywhere in the =
document.</span></font><b><i><font
     color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'>[TF]
     </span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
</ol>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C483E3.A093C213--

------=_NextPartTM-000-125dc356-5ed5-4b48-8672-24e625216f72--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GLj4gu098727; Mon, 16 Aug 2004 14:45:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GLj4FS098726; Mon, 16 Aug 2004 14:45:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GLj3C6098720 for <[e-mail]>; Mon, 16 Aug 2004 14:45:03 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 16 Aug 2004 14:45:07 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 16 Aug 2004 14:44:50 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Aug 2004 14:45:07 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 14:44:56 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on SCVP Draft 15
Date: Mon, 16 Aug 2004 14:45:05 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on SCVP Draft 15
thread-index: AcSBVt66uR1AuT5iT7iImNucXYBoCQCgxbAA
From: "Trevor Freeman" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 16 Aug 2004 21:44:56.0519 (UTC) FILETIME=[457DAD70:01C483DA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7GLj3C6098721
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: Wen-Cheng Wang [mailto:[e-mail]]
* Sent: Friday, August 13, 2004 9:59 AM
* To: [e-mail]; [e-mail]; Trevor Freeman
* Subject: Re: Comments on SCVP Draft 15
* 
* Sorry! I forgot one comment in my last post.
* 
* 11. Section 3.2.12.2
* It is strange to have "Name Validation Algorithm" as a sub section of
* of "3.2.12 validationAlg". Does it means a "Name Validation Algorithm"
* itself can be regarded as a certificate validation algorithm?
* My understanding is a Name Validation Algorithm is only a part of the
* whole validation algorithm (or is an additional conditions to the
* validation
* algorithm, it can not be used to replace the whole validation
algorithm.
* However, with the current syntax, if one specifies a Name Validation
* Algorithm, then it can not specify the validation algorithm anymore.
That
* is unreasonable.
[TF] I have added text to clarity that all validation algorithm is be a
superset of the basic(was default but that name is causing
confusion)algorithm functionality.
* 
* =====
* Wen-Cheng Wang
* 
* ----- Original Message -----
* From: "Wen-Cheng Wang" <[e-mail]>
* To: <[e-mail]>; <[e-mail]>;
* <[e-mail]>
* Sent: Saturday, August 14, 2004 12:45 AM
* Subject: Comments on SCVP Draft 15
* 
* 
* > Here is my comments on SCVP Draft 15:
* >
* > 1. Should it be called "certificate path" or "certification path"?
* > In SCVP Draft 15, sometimes it is called "certificate path",
* > otherwhile it is called "certification path"? Please be consistent.
* > I believe that "certification path" is the mainstream use.
* >
* > 2. Do we really need to keep the validationAlg item in the SCVP
Query?
* > It is very confusing to have both the references of a validation
policy
* > and a validation algorithm in the SCVP Query. There is a large
* > overlap between the concepts of a validation policy and a validation
* > algorithm. My understanding is that the validation algorithm is part
* > of the validation policy. That is, if one specifies a validation
policy,
* > then it already implies a validation algorithm. Therefore, there is
* > no need to have a validationAlg item in the SCVP Query. If we
* > remove a validationAlg item from the SCVP Query, we can still
* > regard inputs such as trust anchors, user-initial-policy-set,
* > initial-policy-mapping-inhibit, initial-explicit-policy, or
* > initial-any-policy-inhibit as parameters to the validation policy.
* > (Be sure to make all these parameters optional, because the
* > validation might already implies all of them.)
* >
* > 3. Please consider to reorganize the SCVP Query data structure.
* > Especially, please consider to group parameters such as trust
anchors,
* > user-initial-policy-set, initial-policy-mapping-inhibit,
* > initial-explicit-policy,
* > or initial-any-policy-inhibit into a sub-structure. (If I remember
* > correctly,
* > Denis had similar opinion.)
* >
* > In my opinion, the current syntax for the SCVP Query data structure
is
* > not only ugly but also very likely causes ambiguity. For example, it
is
* > not clear if one can specify any parameters without specifing a
* > validation policy (or a validation algorithm). I believe that design
* > good data structures is an important part of designing a protocol.
* > A good protocol should have well-designed data structures. That
* > is the principle of data structures we learnt in the college
computer
* > science
* > course, isn't it?
* >
* > 4. Parameters such as inhibitPolMap, requireExplicitPol,
ignoreAnyPol,
* > IsCA should be OPTIONAL fields instead of being fields with a
DEFAULT
* > value. In many cases, the client would like to OMIT these
parameters.
* (For
* > example in the cases where the validation policy implies all the
* > parameters.)
* > If we let these parameters be  fields with a DEFAULT value, then
there
* > is no way to distinct whether the client want to omit them or want
to
* > use the default value. Besides, there is no consensus on the default
* value
* > for these parameters in this WG. Especially, I do not agree why the
* default
* > value for requireExplicitPol is FALSE, because I believe most
serious
* > verifiers would require a explict certificate policy be set in all
* > certificates
* > in the path.
* >
* > 5. Please consider change the name of the parameters to align with
* > the names used in RFC 3280. Especially, I think 'ignoreAnyPol' is
* > a bad name. Please note that it is called
'initial-any-policy-inhibit'
* > in RFC 3280, and 'inhibit' and 'ignore' have quite different
meaning.
* > Besides, since all these parameters are all 'initial' parameters, I
* > think it is better to keep the 'initial' in their names. Therefore,
how
* > about change their name into 'initPolMapInhibit', 'initExplicitPol',
* > 'initAnyPolInhibit', and 'initCertPolSet'.
* >
* > 6. Section 3.2.4
* > What if the client requests the server to include the full request
in
* > the response but the server does not support that? Should the
* > server return a error to the client? If not, should the client
reject
* the
* > response that only includes a hash of the request?
* >
* > 7. Section 3.2.5
* > What if the client requests the server to include the
fullPolResponse
* > in the CVResponse but the server does not support that? Should
* > the server return a error to the client? If not, should the client
* reject
* > the response that does not include the fullPolResponse in the
* > CVResponse?
* >
* > 8. Section 3.2.10
* > What if the client requests the server to sign the response but the
* > server does not support that? Should the server return a error to
* > the client? If not, should the client reject the unsigned response?
* >
* > 9. Section 3.2.13
* > In additional to supporting validating a certificate relative to a
* > specific validatyTime or current time, it is also important to allow
* > the client to ask the server whether the target certificate
* > is valid during a "time period" (i.e., from time t1 to time t2).
* > In the cases where a client want to verify a long-term digital
* > signature which might be signed between time t1 and time t2,
* > the client needs make sure whether the signer's certificate
* > is valid from time t1 to time t2. Please take a look at RFC 3126
* > and the paper titled "General principles of digital signature"
* > (http://www.timestamp.cyber.ee/principles_en.pdf), then you will
* > see why it is important to determine whether the target certificate
* > is valid during a "time period".
* >
* > 10. Section 3.2.14
* > I do not see why user-initial-policy-set needs to be associated
* > with the trust anchor. This is not align with RFC 3280. Please
* > consider moving this parameter to the same level as other
* > parameters such as initial-policy-mapping-inhibit,
* > initial-explicit-policy, and initial-any-policy-inhibit.
* >
* > =====
* > Wen-Cheng Wang
* >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GL5Rsg095668; Mon, 16 Aug 2004 14:05:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GL5RKB095667; Mon, 16 Aug 2004 14:05:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GL5QKc095651 for <[e-mail]>; Mon, 16 Aug 2004 14:05:26 -0700 (PDT) (envelope-from [e-mail])
Content-class: urn:content-classes:message
Subject: RE: OCSP in IKEv2
MIME-Version: 1.0
Date: Mon, 16 Aug 2004 17:06:13 -0400
Content-Type: multipart/signed; boundary="----=_NextPart_000_00AD_01C483B3.39949540"; protocol="application/x-pkcs7-signature"; micalg=SHA1
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP in IKEv2
Thread-Index: AcRoYVD23za0AhLcTW+JoP0FHX+gvwbc1/pA
From: "Dave Engberg" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00AD_01C483B3.39949540
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 
Regarding Michael & Hannes OCSP-over-IKEv2 proposal:
  http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt

I like the idea of using OCSP responses to provide revocation information
over IKEv2.  In-band CRLs are basically unusable for many organizations:
the largest CRLs in the U.S. Government are over 5MB.  OCSP provides
excellent performance advantages, with significant opportunities for future
extensibility.

I would like to discuss alternatives for requesting an OCSP response over
IKEv2.  First, I'm going to provide some OCSP background information.  Feel
free to skip if you're already very familiar with RFC 2560 ...

-----BEGIN OCSP BACKGROUND-----

In OCSP, a relying party client sends an OCSPRequest to a responder server.
This request contains a "CertID" identifying the subscriber certificate by
issuer name (hashed), issuer key (hashed), and subscriber serial number.
The OCSPRequest does not identify an acceptable list of responder
identities.

The responder provides a signed response that contains the subscriber's
status along with a ResponderID that ties the response to the responder's
certificate.  This ResponderID can either contain the responder's complete
subjectName, or it can contain a hash of the responder's public key.  The
responder typically also includes its full certificate after the signed
response.

A relying party may accept an OCSP response if any of the following criteria
is met:

1)  The response is signed by the CA that issued the subscriber's
certificate.  (Rare)

2)  The response is signed by a responder whose cert is delegated by the CA
for "OCSP Signing".

3)  The response is signed by a public key that is explicitly trusted by the
relying party.  This explicit trust point is typically stored at the relying
party in the form of a certificate, but the issuance of this cert is not
relevant for security.

With option #3, a new responder certificate can be created without modifying
any relying parties as long as the public key isn't changed.  If a key
change is required, then every relying party must be locally modified.

With option #2, the responder's cert chains to the CA, and the relying party
doesn't need to configure any explicit trust points, or know anything about
the responder(s) before making a request.  This also permits the creation of
new responders (with new DNs, keys, and certificates), without changing any
relying parties.

Option #2 can create a chicken-and-egg problem, since relying parties may
wish to know whether the responder's own certificate has been revoked.  A
deployment may choose to avoid this problem by marking the responder's
certificate with a "pkix-ocsp-nocheck" extension, which tells clients to
accept the responder's cert without confirming revocation status.  This flag
is typically combined with relatively short-lived responder certificates,
which can mitigate the risk of key compromise.

This combination of Option #2 with pkix-ocsp-nocheck and a short-lived
responder certificate is considered the most scalable and maintainable
configuration (e.g. this is what VeriSign uses).

-----END OCSP BACKGROUND-----

RFC 3546 (section 3.6) extends TLS to permit the use of OCSP responses for
revocation status.  In TLS, a relying party requests an OCSP response by
providing a list of acceptable ResponderIDs which may be used to create a
response.  This matches the "explicit trust" security for OCSP (option #3).

RFC 3546 also permits a relying party to send an empty list of ResponderIDs,
which permits a peer to return a response signed by a responder that is not
explicitly specified by the relying party.  This could permit the use of
delegated responders (option #2).


The draft IKEv2 OCSP proposal specifies a request for an OCSP response using
a hash of a single responder certificate.  This is less flexible than both
"plain" OCSP and OCSP-over-TLS.

Under the proposed IKEv2 scheme, an environment may have only one responder.
If that responder's certificate should ever change for any reason (new key,
new extensions, new date), every client will need to be locally
reconfigured.  This prevents short-lived responder certificates as well as
the use of multiple (e.g. load-balanced) responders with different keys.

The TLS scheme in RFC 3546 is more flexible in three different ways.  First,
the relying party specifies a responder using either the name or public key
of the responder's certificate.  Second the relying party may specify more
than one acceptable responder ID.  Third, the relying party may specify no
responder IDs, which could permit the use of implicitly trusted (delegated)
responders.

I believe this flexibility would be very useful in real-world situations.
Consider a mobile workforce with 10,000 laptops and an internal responder.
Each of the laptops has a hard-coded responder certificate.  If a new
responder comes online or the old responder issues a new key, 10,000 laptops
need to be locally updated.


I would suggest modifying the IKEv2 proposal to permit requests with:

a) More than one responder

b) Specify responders by name or key hash instead of cert hash

c) Permit "delegated" responders (OCSPSigning) without explicit trust at the
relying party

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII1jCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA4wwggL1oAMCAQICARkwDQYJKoZI
hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE
AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDQwNzEyMTMwMjE4WhcNMDUw
NzI2MTMwMjE4WjBnMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRYwFAYD
VQQDEw1EYXZpZCBFbmdiZXJnMSYwJAYJKoZIhvcNAQkBFhdkZW5nYmVyZ0Bjb3Jlc3RyZWV0LmNv
bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJXX+JZ1oaEb2TCawk31rzpOIRTHZyP
UGTUGNyMasqczNZATvXu2RTlon8dwEuO4evr5KE9iDe0jQSkj1g5HBEsFAH+JPU7Y0uYupm/kiyr
6FiyhBCQtWhrcNii0yahcIEbH/fBAf5V10Y2wHKFrPH6uTrj+YGhBpaXxkEZpXCe2QZtkR/kcbKa
QaMCaU27vLAZ4QT6vJTf5oG/SD1KU232kYttiLeRjnePWipH8In7crGPhgJCeQP5UtE9uHDjOStt
eZxXsWAzU7oW9nb9jHL2xOWPQyhBs4JaPvgSdFkenI6L8flsQm72U8lrV/4dqKu330m5pH89XTYl
o2PcqIUCAwEAAaOB2DCB1TAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDov
L2NybC5nZW90cnVzdC5jb20vY3Jscy9jb3Jlc3RyZWV0LmNybDAiBgNVHREEGzAZgRdkZW5nYmVy
Z0Bjb3Jlc3RyZWV0LmNvbTAfBgNVHSMEGDAWgBTY7H+TGMVmA8MQbDwE9neFPv8LtjBABggrBgEF
BQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9nZW90cnVzdC1vY3NwLmNvcmVzdHJlZXQuY29t
LzANBgkqhkiG9w0BAQUFAAOBgQAtAQMtzyIzARw6d/sy1qPn+Mqr7aPEJFofkSW57NE639PcrXmC
E9LzVm5mtmoNkeeyHDOgla79ez8MzndDxhlwQvNdaiu124jWbgEoHC1q2K4McbaJlxjhPbCpFr7Z
CzxQxOmFxXjb16XGotrxX1aj2YWuAAdt9H3x+tHBXCn+WDGCAxowggMWAgEBMFcwUjELMAkGA1UE
BhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkCARkwCQYFKw4DAhoFAKCCAZgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwODE2MjEwNTI2WjAjBgkqhkiG9w0BCQQxFgQUMtltxxHG
dUM6F+4F21uKwdr5qhEwZgYJKwYBBAGCNxAEMVkwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP
Q29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0
eQIBGTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG
9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgsq
hkiG9w0BCRACCzFZoFcwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEp
MCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCARkwDQYJKoZIhvcNAQEB
BQAEggEAK2k8AO1/yPk+0OdMHlBisqTgu+Hup0eOB7pAHanPsp7+D/INKqk+gvghWHxg+BiQprAp
h1OH3GWq66A1vtOsypgSGDpkSiC9cHBYFVc3G76BO6J17AdazL1FWJiQ+akVpXwtF9RJJlRDjzgU
hyNt1ZE2LnDptJ0JPG0MW4Z7wnNbVaogPUxz86xk2ZfwI4CLaHRd5ASe+2TF0R1O+Dq0z9gkB/tF
B1RWZwkdbMbNXMvQShvthItTFUtxpCBWsNVbBuDYw3DhUVoBXQyvvFnffWg4ELFQOplLfyX4Jh/q
oBmAqAN3/iPWvCcRHRt+ny8hj8eLOV93RzouS/p/iADi1AAAAAAAAA==

------=_NextPart_000_00AD_01C483B3.39949540--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GJJU5T087238; Mon, 16 Aug 2004 12:19:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GJJUj8087237; Mon, 16 Aug 2004 12:19:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GJJUtP087230 for <[e-mail]>; Mon, 16 Aug 2004 12:19:30 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24714; Mon, 16 Aug 2004 15:19:32 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ecc-pkalgs-00.txt
Date: Mon, 16 Aug 2004 15:19:31 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Additional Algorithms and Identifiers for use of 
			  Elliptic Curve Cryptography with PKIX
	Author(s)	: D. Brown
	Filename	: draft-ietf-pkix-ecc-pkalgs-00.txt
	Pages		: 22
	Date		: 2004-8-16
	
This document gives additional algorithms and associated ASN.1
   identifiers for elliptic curve cryptography (ECC) used with the
   Internet X.509 Public Key Infrastructure Certificate and
   Certificate Revocation List (CRL) Profile (PKIX).  The algorithms
   and identifiers here are consistent with both ANSI X9.62-1998 and
   X9.63-2001, and shall be consistent with the forthcoming revisions
   of these documents.  Consistency shall also be maintained with SEC1
   and SEC2, and any revisions or successors of such documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ecc-pkalgs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ecc-pkalgs-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ecc-pkalgs-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GIQXiD082697; Mon, 16 Aug 2004 11:26:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GIQXBH082696; Mon, 16 Aug 2004 11:26:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GIQWtk082690 for <[e-mail]>; Mon, 16 Aug 2004 11:26:32 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 16 Aug 2004 11:26:13 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 16 Aug 2004 11:26:13 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Aug 2004 11:26:13 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 11:26:15 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on SCVP Draft 15
Date: Mon, 16 Aug 2004 11:26:11 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on SCVP Draft 15
thread-index: AcSBVQlq7sf4fPcKRsyv9FGWY1zmyACZUaYQ
From: "Trevor Freeman" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 16 Aug 2004 18:26:15.0546 (UTC) FILETIME=[84098DA0:01C483BE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7GIQXtk082691
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: Wen-Cheng Wang [mailto:[e-mail]]
* Sent: Friday, August 13, 2004 9:46 AM
* To: [e-mail]; [e-mail]; Trevor Freeman
* Subject: Comments on SCVP Draft 15
* 
* Here is my comments on SCVP Draft 15:
* 
* 1. Should it be called "certificate path" or "certification path"?[TF]
Fixed]
* In SCVP Draft 15, sometimes it is called "certificate path",
* otherwhile it is called "certification path"? Please be consistent.
* I believe that "certification path" is the mainstream use.
* 
* 2. Do we really need to keep the validationAlg item in the SCVP
Query?[TF]  Already fixed and is now optional
* It is very confusing to have both the references of a validation
policy
* and a validation algorithm in the SCVP Query. There is a large
* overlap between the concepts of a validation policy and a validation
* algorithm. My understanding is that the validation algorithm is part
* of the validation policy. That is, if one specifies a validation
policy,
* then it already implies a validation algorithm. Therefore, there is
* no need to have a validationAlg item in the SCVP Query. If we
* remove a validationAlg item from the SCVP Query, we can still
* regard inputs such as trust anchors, user-initial-policy-set,
* initial-policy-mapping-inhibit, initial-explicit-policy, or
* initial-any-policy-inhibit as parameters to the validation policy.
* (Be sure to make all these parameters optional, because the
* validation might already implies all of them.)
* 
* 3. Please consider to reorganize the SCVP Query data structure. 
[TF] Data structures and ambiguity of syntax are two orthogonal issues.
The intent is to not artificially restrict the combinations of
arguments.
* Especially, please consider to group parameters such as trust anchors,
* user-initial-policy-set, initial-policy-mapping-inhibit,
* initial-explicit-policy,
* or initial-any-policy-inhibit into a sub-structure. (If I remember
* correctly,
* Denis had similar opinion.)
* 
* In my opinion, the current syntax for the SCVP Query data structure is
* not only ugly but also very likely causes ambiguity. For example, it
is
* not clear if one can specify any parameters without specifing a
* validation policy (or a validation algorithm). I believe that design
* good data structures is an important part of designing a protocol.
* A good protocol should have well-designed data structures. That
* is the principle of data structures we learnt in the college computer
* science
* course, isn't it?
* 
* 4. Parameters such as inhibitPolMap, requireExplicitPol, ignoreAnyPol,
* IsCA should be OPTIONAL
[TF] Fixed
 fields instead of being fields with a DEFAULT
* value. In many cases, the client would like to OMIT these parameters.
(For
* example in the cases where the validation policy implies all the
* parameters.)
* If we let these parameters be  fields with a DEFAULT value, then there
* is no way to distinct whether the client want to omit them or want to
* use the default value. Besides, there is no consensus on the default
value
* for these parameters in this WG. Especially, I do not agree why the
* default
* value for requireExplicitPol is FALSE, because I believe most serious
* verifiers would require a explict certificate policy be set in all
* certificates
* in the path.
* 
* 5. Please consider change the name of the parameters to align with
* the names used in RFC 3280. 
[TF] Fixed
Especially, I think 'ignoreAnyPol' is
* a bad name. Please note that it is called 'initial-any-policy-inhibit'
* in RFC 3280, and 'inhibit' and 'ignore' have quite different meaning.
* Besides, since all these parameters are all 'initial' parameters, I
* think it is better to keep the 'initial' in their names. Therefore,
how
* about change their name into 'initPolMapInhibit', 'initExplicitPol',
* 'initAnyPolInhibit', and 'initCertPolSet'.
* 
* 6. Section 3.2.4
* What if the client requests the server to include the full request in
* the response but the server does not support that? Should the
* server return a error to the client? 
[TF] The server should return an error. I have added text to clarify
that success is returned when the server fully complies with the
request.
If not, should the client reject the
* response that only includes a hash of the request?
* 
* 7. Section 3.2.5
* What if the client requests the server to include the fullPolResponse
* in the CVResponse but the server does not support that? Should
* the server return a error to the client? If not, should the client
reject
* the response that does not include the fullPolResponse in the
* CVResponse?[TF]  fixed (see above)
* 
* 8. Section 3.2.10
* What if the client requests the server to sign the response but the
* server does not support that? Should the server return a error to
* the client? If not, should the client reject the unsigned response?
[TF] fixed (see above)
* 
* 9. Section 3.2.13
* In additional to supporting validating a certificate relative to a
* specific validatyTime or current time, it is also important to allow
* the client to ask the server whether the target certificate
* is valid during a "time period" (i.e., from time t1 to time t2).
* In the cases where a client want to verify a long-term digital
* signature which might be signed between time t1 and time t2,
* the client needs make sure whether the signer's certificate
* is valid from time t1 to time t2. Please take a look at RFC 3126
* and the paper titled "General principles of digital signature"
* (http://www.timestamp.cyber.ee/principles_en.pdf), then you will
* see why it is important to determine whether the target certificate
* is valid during a "time period".
[TF] That can be supported by a validation algorithm.
* 
* 10. Section 3.2.14
* I do not see why user-initial-policy-set needs to be associated
* with the trust anchor. This is not align with RFC 3280. Please
* consider moving this parameter to the same level as other
* parameters such as initial-policy-mapping-inhibit,
* initial-explicit-policy, and initial-any-policy-inhibit.
[TF] Fixed
* 
* =====
* Wen-Cheng Wang




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GH423O075325; Mon, 16 Aug 2004 10:04:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7GH42gB075324; Mon, 16 Aug 2004 10:04:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7GH41pQ075313 for <[e-mail]>; Mon, 16 Aug 2004 10:04:02 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 16 Aug 2004 10:04:00 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 16 Aug 2004 10:04:00 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Aug 2004 10:03:59 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Aug 2004 10:03:58 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Mon, 16 Aug 2004 10:03:58 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PKIX WG Agenda for 60th IETF (second try!)
thread-index: AcSCvlkPYV/WoFy9Qh+fjA9s7SOZvgA9BnWg
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 16 Aug 2004 17:03:58.0685 (UTC) FILETIME=[057058D0:01C483B3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7GH42pQ075318
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
I cannot begin to understand why anyone would set an arbitrary length of
a path i.e. is good as long as there are only 3 CA certificates in the
path, however since you raised the point in conjunction to DPD requests,
then the simplest solution is to allow the client to request all paths.
Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Sunday, August 15, 2004 4:52 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > Hi Peter,
* > The validation algorithm in 3280 section 6 works for all
certificates.
* 
* The algorithm is defined for EE-certs.
* 
* > Trevor
* >
* 
* 
* You have not commented the following:
* 
* > *
* > * Assume you want a valid path for CA2 signing CA1 and an EE cert
* > * and you have a situation like
* > *
* > *   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
* > *                    <- CA3withpathlength1 <- CAY ..
othetrustanchor.
* > *
* > * you cannot avoid that the SCVP server returns the first path
* > * which would not be valid to sign EE with an intermediate CA1.
* > *
* 
* 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FC9eD0019835; Sun, 15 Aug 2004 05:09:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7FC9edA019834; Sun, 15 Aug 2004 05:09:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FC9dv8019819 for <[e-mail]>; Sun, 15 Aug 2004 05:09:40 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7FC9eN22625; Sun, 15 Aug 2004 14:09:40 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sun, 15 Aug 2004 14:09:40 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7FC9dZ03774; Sun, 15 Aug 2004 14:09:39 +0200 (MEST)
Date: Sun, 15 Aug 2004 14:09:39 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Hi Peter,
> The question in point still comes back to how was the certificate
> validated i.e. the algorithm and the parameters used by the server when
> it returned the positive response. SCVP defines a default algorithm
> where the server performs the path validation itself and provides an
> extension mechanisms to define other algorithms. I don't see any
> blocking issues to you defining a new validation algorithm which
> encompasses DPV server delegating the validation decision to other DPV
> server.

I don't need to defined anything since it is already in SCVP.
SCVP explicitely says that it can use the response from another DPV server.

   In order to obtain the revocation status information of any
   certificate from the certification path, the DPV server might use, in
   accordance with the validation policy, different sources of
   revocation information.  For example, a combination of OCSP
   responses, CRLs, and delta CRLs could be used.  Alternatively, a
   response from another DPV server could be used.

And the requirements say that the server must be able to return all
information that is used to base its decision on.

> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FBqR5o013707; Sun, 15 Aug 2004 04:52:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7FBqRPJ013706; Sun, 15 Aug 2004 04:52:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7FBqPTl013632 for <[e-mail]>; Sun, 15 Aug 2004 04:52:26 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7FBqHN22462; Sun, 15 Aug 2004 13:52:17 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sun, 15 Aug 2004 13:52:17 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7FBqGe03759; Sun, 15 Aug 2004 13:52:16 +0200 (MEST)
Date: Sun, 15 Aug 2004 13:52:16 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi Peter,
> The validation algorithm in 3280 section 6 works for all certificates.

The algorithm is defined for EE-certs.

> Trevor
>


You have not commented the following: 

> * 
> * Assume you want a valid path for CA2 signing CA1 and an EE cert
> * and you have a situation like
> * 
> *   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
> *                    <- CA3withpathlength1 <- CAY .. othetrustanchor.
> * 
> * you cannot avoid that the SCVP server returns the first path
> * which would not be valid to sign EE with an intermediate CA1.
> *

 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E1k04Z083355; Fri, 13 Aug 2004 18:46:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7E1k0w4083354; Fri, 13 Aug 2004 18:46:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E1jxKV083347 for <[e-mail]>; Fri, 13 Aug 2004 18:45:59 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 18:45:46 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Aug 2004 18:45:48 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Aug 2004 18:45:46 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 18:45:36 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP: Speak now or forever hold your peace... 
Date: Fri, 13 Aug 2004 18:45:50 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP: Speak now or forever hold your peace... 
thread-index: AcR/nqiJGE3CqjO+SgKSp0YbTylJOQB9lrqg
From: "Trevor Freeman" <[e-mail]>
To: "Francis Dupont" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 14 Aug 2004 01:45:36.0636 (UTC) FILETIME=[653B6BC0:01C481A0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7E1jxKV083348
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Francis Dupont
* Sent: Wednesday, August 11, 2004 4:49 AM
* To: [e-mail]
* Cc: [e-mail]
* Subject: Re: SCVP: Speak now or forever hold your peace...
* 
* 
* Here are ASN.1 & co typos and suggestions: first letter of a field in
* lower case, of a type in upper case, plural for [wW]antBack.
*  - 3.2 title Query -> query[TF]  already fixed
*  - in 3.2: [wW]antBack -> [wW]antBacks, IsCA -> isCA,[TF]  already
fixed
*    SignResponse -> signResponse[TF]  already fixed
*    missing "," after queryExtensions and producedAt (same in 8)[TF]
already fixed
*  - in 3.2.3, including the title, [wW]antBack -> [wW]antBacks[TF]
wantBack is in the singular in the ASN?
*  - put 3.2.12 before 3.2.4 (to follow the field order) [TF] fixed
*  - in 3.2.12.2 KeyPurposedId -> keyPurposedId (in definition and
text),
*    ValidationNames -> validationNames [TF] fixed
*  - in 3.2.16 riType -> reType, riValue -> reValue [TF] fixed
*  - in 3.3 and 4.6 title Requestor -> requestor [TF] Already fixed
*  - in 4 id-ct-scvp-psResponse -> id-ct-scvp-certValResponse
(twice)[TF] Already fixed
*  - in 4 and 8, missing "," after validationPolRef [TF] Already fixed
*  - in 4.5.2 text PSRequest -> CVRequest [TF] Fixed
*  - in 4.8.5, including the title, [rR]eplyWantBack ->
[rR]eplyWantBacks [TF] fixed
*    (note this is *not* a suggestion, cf 4.8 where are the plurals
*     and there is a ReplyWantBack type too: caution!)
*  - in 4.11 IsCA -> isCA [TF] Fixed
*  - in 4.11 and 8 trustAnchors should be OPTIONAL (because in the
second
* usage, {TF] Fixed
*    PolResponse, there already is a trustAnchors field).
*  - in 6 and in 6.2, including title, DefaultPolicyID ->
defaultPolicyID
*  - in 6.7 AuthPolRefBy{OID,URI} -> authPolRefBy{OID,URI}
*  - in 8 (extra typos): [TF] Fixed
*    * Query: valalidationAlg -> validationAlg [TF] Fixed
*             keyusage -> keyUsage [TF] Fixed
*  - in B application/scvp-{request,response} ->
*         application/cv-{request,response} Fixed
* 
* Regards
* 
* [e-mail]




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E0N3LM077552; Fri, 13 Aug 2004 17:23:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7E0N3lW077551; Fri, 13 Aug 2004 17:23:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7E0N0mX077541 for <[e-mail]>; Fri, 13 Aug 2004 17:23:00 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 17:23:02 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Aug 2004 17:23:04 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Aug 2004 17:23:10 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 17:22:58 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP: Speak now or forever hold your peace... 
Date: Fri, 13 Aug 2004 17:23:06 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP: Speak now or forever hold your peace... 
thread-index: AcR/j566WT3xJj/tTGqkR0WcgC1pdQB/vqMg
From: "Trevor Freeman" <[e-mail]>
To: "Francis Dupont" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 14 Aug 2004 00:22:58.0796 (UTC) FILETIME=[DA2112C0:01C48194]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7E0N0mX077543
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Francis Dupont
* Sent: Wednesday, August 11, 2004 3:16 AM
* To: [e-mail]
* Cc: [e-mail]
* Subject: Re: SCVP: Speak now or forever hold your peace...
* 
* 
* Here are the ASN.1 bugs:
*  - CertReference is an ambiguous CHOICE. In a previous version
*    one tried to solve the ambiguity by changing the ACReference tags
*    to 3 and 4 (I don't know if this is really allowed or recognized
*    by compilers, of course it works but as I'd like to get the
reference
*    stuff a bit extended perhaps it is better to tag the CertReference
* itself).[TF]  Already fixed
*  - responseStatus 50 is missing in 4.4[TF]  fixed
*  - change the fullPolRequestUnsuported into fullPolResponseUnsuported
in
* 4.4[TF] fixed
*    and 8
*  - the cert field in CertReply is CertReference in 4.8 and
* ReplyCertificate
*    in 8. I prefer the 8 (and previous draft) version because it is a
*    simple way to enforce the return of the whole certificate. There
are
*    many ways to fix this:
*    - just fix 8
*    - same but add a want back to get the certificate itself (note that
* with
*      IKE the certificate itself is useful only if the name validation
*      algorithm doesn't work, and in the other case the public key is
*      enough).[TF]  Fixed
*    - just fix 8 and adding in 4.8.1 that the whole certificate is
* mandatory
*    - go back to previous draft, i.e., fix 4.8 and 4.8.1
*    (note: I prefer the second solution (and get the validation
algorithm
*     error issue fixed!))
*  - change the valAlg of CertReply (4.8 and 8) into validationAlg[TF]
[TF]  fixed
*  - fix the name of Pol{icies}Response in 5[TF]  fixed
*  - add the i to validationPolices (to get validationPolicies) in 6 and
*    add a subsection describing it between 6.5 and 6.6[TF]  fixed
* 
* Regards
* 
* [e-mail]
[TF] 
Trevor




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DKdCqQ061353; Fri, 13 Aug 2004 13:39:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DKdCfT061352; Fri, 13 Aug 2004 13:39:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DKdBMQ061346 for <[e-mail]>; Fri, 13 Aug 2004 13:39:11 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i7DKckNR032734 for <[e-mail]>; Fri, 13 Aug 2004 16:38:46 -0400
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i7DKcNWP017799 for <[e-mail]>; Fri, 13 Aug 2004 16:38:23 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 13 Aug 2004 16:38:48 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031010
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Technical comments on SCVP Draft 15
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
All,<br>
<br>
Tim Polk asked me to review SCVP draft 15 in the hope of obtaining the
perspective of someone who has not read RFC 3379 nor any of the
preceding SCVP drafts.&nbsp; So, I read through draft 15 and prepared a set
of technical and editorial comments.&nbsp; The technical comments are
below.&nbsp; I will send the editorial comments directly to the editors.<br>
<br>
Dave<br>
<hr width="100%" size="2">
<title>Technical Comments on draft-ietf-pkix-scvp-15</title>
<meta content="OpenOffice.org 1.1.2  (Linux)" name="GENERATOR">
<meta content="David Cooper" name="AUTHOR">
<meta content="20040813;15350000" name="CREATED">
<meta content="David Cooper" name="CHANGEDBY">
<meta content="20040813;16192200" name="CHANGED">
<style>
	<!--
		@page { size: 8.27in 11.69in; margin: 0.79in }
		P { margin-bottom: 0.08in }
	-->
	</style>
<p style="margin-bottom: 0in;"><font size="3">Technical comments on
draft-ietf-pkix-scvp-15.txt:</font><br>
</p>
<ol>
  <li>
    <p><font size="3">General Comment: The document needs to clarify
the differences/relationships between validationAlg (3.2.12) and
validationPolRef (3.2.21) in the request and valPolResponse (4.11) and
validationPolRef (4.? - no section).</font></p>
  </li>
</ol>
<blockquote>
  <ul>
    <li>
      <p><font size="3">Assuming that the
ValidationPolRef can be a single reference specifying all the
contents of ValidationPolicy, then it is a superset of validationAlg.
Why is validationAlgorithm mandatory in the request? If you specify
a ValidationPolRef you wouldn't seem to need it.</font></p>
    </li>
    <li>
      <p><font size="3">When are valPolResponse
and validationPolRef included in a response? Could both appear?</font></p>
    </li>
    <li>
      <p><font size="3">If the server includes
valPolResponse, the validationAlgorithm is a mandatory field. If the
server includes certReply, valAlg is a mandatory field for every
cert. What if they conflict?</font></p>
    </li>
  </ul>
</blockquote>
<ol start="2">
  <li>
    <p><font size="3">Section 3: In the ASN.1, there are comments
indicating that SignedAttributes and AuthAttributes are required in the
SignerInfo and AuthenticatedData structures, respectively. What
attributes are required?</font></p>
  </li>
  <li>
    <p><font size="3">The new syntax for CertReference (below) makes it
difficult to distinguish between a public key certificate and an
attribute certificate. When the ESSCertID method is chosen, it will not
be possible to determine whether a public key or attribute certificate
has been referenced until the certificate has been obtained and parsed.
Even if the certificate is included, it will have to be at least
partially parsed before it can be determined what type of certificate
it is. Why were the tags in ACReference changed from [3] and [4] to [1]
and [2]?</font></p>
  </li>
</ol>
<blockquote>
  <blockquote><font size="3" face="Courier New">CertReference
::= CHOICE {</font><font face="Courier New">
    <br>
    </font><font size="3" face="Courier New">pkc PKCReference,</font><font
 face="Courier New">
    <br>
    </font><font size="3" face="Courier New">ac ACReference }</font><font
 face="Courier New">
    <br>
    <br>
    </font><font size="3" face="Courier New">PKCReference
::= CHOICE {</font><font face="Courier New">
    <br>
    </font><font size="3" face="Courier New">cert [1] Certificate,</font><font
 face="Courier New">
    <br>
    </font><font size="3" face="Courier New">pkcRef [2] ESSCertID }</font><font
 face="Courier New">
    <br>
    <br>
    </font><font size="3" face="Courier New">ACReference
::= CHOICE {</font><font face="Courier New">
    <br>
    </font><font size="3" face="Courier New">attrCert [1]
AttributeCertificate,</font><font face="Courier New">
    <br>
    </font><font size="3" face="Courier New">acRef [2] ESSCertID }</font><br>
  </blockquote>
</blockquote>
<ol start="4">
  <li>
    <p><font size="3">Sections 3.2.1, 3.2.2, and 3.2.3: Can the
queriedCerts item in a single request include both public key and
attribute certificates? There is nothing in section 3.2.1 that suggests
otherwise. However, in sections 3.2.2 and 3.2.2, each of the checks and
want backs defined is specific to either a public key certificate or an
attribute certificate. If the server must respond to each check and
want back for each certificate in the queriedCerts item, this would
suggest that a single query can not include both types of certificates.
An alternative would be for the server's response for each certificate
to only include responses to those checks and want backs that are
relevant to for the given type of certificate, however the
specification does not indicate that this is acceptable.</font></p>
  </li>
  <li>
    <p><font size="3">Section 3.2.9 states &#8220;If the client does not care
it MUST omit the Boolean.&#8221; However, the isCA flag is not OPTIONAL. isCA
may be either TRUE or FALSE, but may not be omitted.</font></p>
  </li>
  <li>
    <p><font size="3">Sections 3.2.6 through 3.2.8: Should
inhibitPolMap, requireExplicitPol, ignoreAnyPol also be OPTIONAL?
Otherwise, how can we indicate that we use the server&#8217;s default or
specify these values using the validationAlg or validationPolRef? </font>
    </p>
  </li>
  <li>
    <p><font size="3">Section 3.2.9:</font></p>
    <ul>
      <li>
        <p><font size="3">What is the purpose of the isCA flag?</font></p>
      </li>
      <li>
        <p><font size="3">Under what circumstances would the client
need to know whether the referenced certificate is a CA? Isn't it
sufficient to check that the certificate has the appropriate key usage,
extended key usage, policy, etc.? (NOTE: The cA field of the
basicConstraints extension indicates &#8220;if the certified public key may
be used to verify certificate signatures.&#8221; So, if the cA flag is TRUE,
then the certificate subject is a CA. However, a cA flag set to FALSE
or an absent basicConstraints extension does not mean that the
certificate subject is not a CA. It merely indicates that the subject
public key <u>in this certificate</u> may not be used to verify
certificate signatures.)</font></p>
      </li>
      <li>
        <p><font size="3">How should the isCA flag be set (and/or
interpreted) if the referenced certificate is an attribute certificate?</font></p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 3.2.12.2:</font></p>
    <ul>
      <li>
        <p><font size="3">This section is not clear. If the name
validation algorithm is specified, is the server expected to validate
the certificate according to the rules specified for the default
validation algorithm in addition to comparing the names? </font> </p>
      </li>
      <li>
        <p><font size="3">Why is name comparison a considered to be a
validation algorithm? Why isn't this treated the same way are keyUsage
or extendedKeyUsage?</font></p>
      </li>
      <li>
        <p><font size="3">What is the reason for the KeyPurposeID?
Aren't the name matching rules for DNs, email addresses, DNS names,
etc. the same no matter what protocol is being used?</font></p>
      </li>
      <li>
        <p><font size="3">If an email address is supplied, is the
server required to look in both the subjectAltName extension for the
subject field (in an emailAddress attribute) for the email address.</font></p>
      </li>
      <li>
        <p><font size="3">Where the text states &#8220;all names MUST be ...
valid according to the name matching rules requested.&#8221; Does this mean
that all of the names must appear in the certificate (i.e., that each
name in the request must match a name in the certificate, when the
specified name comparison rules are used).</font></p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 3.2.14 states:</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><tt><font size="3">The
OPTIONAL certPolicies item specifies a list of policy identifiers
that the SCVP server MUST use when forming and validating a
certification path that terminates at the associated trust anchor. If
certPolicies is not specified, then any-policy MUST be used.</font></tt></p>
<p style="margin-left: 0.49in;"><font size="3">Is there an implicit
assumption here that requireExplicitPol will be set to TRUE if
certPolicies is included?</font></p>
<ol start="10">
  <li>
    <p><font size="3">Section 3.2.15: The intermediateCerts is of type
CertBundle. Shouldn&#8217;t CertBundle be defined as <font
 face="Courier New, monospace">SEQUENCE SIZE (1..MAX) OF Certificate</font>
instead <font face="Courier New, monospace">SEQUENCE SIZE (1..MAX) OF
PKCReference</font>? If a server rec&#8217;d the ESSCertID choice of
PKCReference for the intermediateCerts, this implies the server would
already have the certificates. In this case, we didn&#8217;t need this field!</font></p>
  </li>
  <li>
    <p><font size="3">Section 3.2.17: Note we assume this applies only
to the end certificate. Even with this clarification, this section
needs to provide more information on how the match is performed.
Specifically:</font></p>
    <ul>
      <li>
        <p><font size="3">If more than one bit is set by the client, do
all of these bits need to be set in the key usage extension in the
certificate?</font></p>
      </li>
      <li>
        <p><font size="3">What if there is no key usage extension in
the certificate? Does this constitute an automatic match?</font><br>
        </p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 3.2.18: Basically the same questions and
assumptions as for key usage:</font></p>
    <ul>
      <li>
        <p><font size="3">If the request includes more than one OID,
must all OIDs be present in the certificate?</font></p>
      </li>
      <li>
        <p><font size="3">What if there is no extended key usage
extension in the certificate? Does this constitute an automatic match?</font></p>
      </li>
      <li>
        <p><font size="3">If the extended key usage extension is
present and includes the anyExtendedKeyUsage OID, does this constitute
an automatic match or do the OIDs in the request need to be explicitly
asserted in the extension?</font><br>
        </p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 3.2.21:</font></p>
    <ul>
      <li>
        <p><font size="3">Why is there a mandate to do a binary
comparison between policy references? If two URIs match according to
the standard matching rules for that type of URI (e.g., case
insensitive match), why wouldn't that be acceptable?</font></p>
      </li>
      <li>
        <p><font size="3">Does the URI <i>represent</i> a human
readable definition of the policy or does it <i>point</i> to a human
readable definition?</font><br>
        </p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 4: Don't these two sentences contradict
each other?</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">The
inclusion of policies in the SigningCertificate attribute is also
OPTIONAL. The policies item in the SigningCertificate attribute SHALL
not be present.</font></font><br>
</p>
<ol start="15">
  <li>
    <p><font size="3">Section 4: I don't understand what the sentence
below means. More explanation is needed.</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">The
value of the message-digest attribute in the signedAttrs within
SignerInfo MAY be used as an identifier of the response generated by
the SCVP server.</font></font></p>
<ol start="16">
  <li>
    <p><font size="3">Section 4: The statement below contradicts
section 3.4.</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">The
requestNonce item MUST be included if the request included a
requestNonce item.</font></font></p>
<ol start="17">
  <li>
    <p><font size="3">Section 4.1 needs more explanation.</font></p>
    <ul>
      <li>
        <p><font size="3">Is the <font face="Courier New, monospace">svcpVersion</font>
number in the response required to match the <font
 face="Courier New, monospace">scvpVersion</font> number in the request
(if the server can process that version of SCVP)?</font></p>
      </li>
      <li>
        <p><font size="3">If the <font face="Courier New, monospace">svcpVersion</font>
number in the request is higher than the highest version number that
the server can process, is the server required to send an error
response? Should the <font face="Courier New, monospace">svcpVersion</font>
number in the response be the highest version number that the server
can process?</font><br>
        </p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 4.4: This sentence needs to be re-written
since there is no requirement to sign DPD responses if the <font
 face="Courier New, monospace">SignResponse</font> flag in the request
is FALSE.</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">Status
codes 0-9 are reserved for codes where the request was processed by
the server and therefore MUST be sent in a signed response.</font></font></p>
<ol start="19">
  <li>
    <p><font size="3">Section 4.7: What is the reason for the responder
item? How is it used? It is included in the response but of only of
local significance? Perhaps this for retrospective audit trail lookups?</font></p>
  </li>
  <li>
    <p><font size="3">Section 4.8.1: Does the contents of the <font
 face="Courier New, monospace">cert</font> item in the response need to
match the contents of the corresponding certificate from the <font
 face="Courier New, monospace">queriedCerts</font> item in the request?
This is, if the request includes a <font face="Courier New, monospace">Certificate</font>,
does the response also need to include a <font
 face="Courier New, monospace">Certificate</font> rather than an <font
 face="Courier New, monospace">ESSCertID</font>? If the request
includes an <font face="Courier New, monospace">ESSCertID</font>, does
the response need to include an <font face="Courier New, monospace">ESSCertID</font>
rather than a <font face="Courier New, monospace">Certificate</font>?</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">The
cert item contains either the public key certificate or the attribute
certificate or a reference to the certificate about which the client
is requesting information.</font></font></p>
<ol start="21">
  <li>
    <p><font size="3">Section 4.8.2: Why aren't the errors below <font
 face="Courier New, monospace">responseStatus</font> errors? Since each
of these applies to every certificate, making it a <font
 face="Courier New, monospace">replyStatus</font> means repeating the
same error for every certificate in the query rather than just
specifiying the error once.</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">5 Failure: the
certificate policy OID is not recognized</font></font></p>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">6 Failure: the validation
<strike><font color="#0000ff">policy</font></strike>
<u><font color="#0000ff">algorithm</font></u> OID is not recognized</font></font></p>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">7 Failure: the extension
OID is not recognized</font></font></p>
<ol start="22">
  <li>
    <p><font size="3">Section 4.8.2: The conditions that would lead to
one of the error values below should really result in a <font
 face="Courier New, monospace">ReplyStatus</font> of <font
 face="Courier New, monospace">success</font> (0) since &#8220;a definitive
answer follows&#8221;. The definitive answer that follows will be that no
valid path could be constructed (e.g., in <font
 face="Courier New, monospace">ReplyChecks</font> and/or <font
 face="Courier New, monospace">replyWantBacks</font>).</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">10
Failure: no certification path could be constructed</font></font></p>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">11
Failure: the constructed certification path is invalid</font></font></p>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">12
Failure: the constructed certification path is invalid, but a
query at a later time may be successful</font></font></p>
<ol start="23">
  <li>
    <p><font size="3">Section 4.8.4: In responses to <font
 face="Courier New, monospace">{id-stc 3}</font>, <font
 face="Courier New, monospace">{id-stc 6}</font>, and <font
 face="Courier New, monospace">{id-stc 7}</font>, what is the
difference between Unknown (2) and Unavailable (3)?</font></p>
  </li>
  <li>
    <p><font size="3">Section 4.8.4 and 4.8.5: The reply check {id-stc
1} (simple validation processing with no status checking) or {id-stc 2}
(but with the Revoked, Unknown, and Unavailable responses being
condensed down to FALSE) would seem to correspond to the wantback for
public key certificate status, { id-swb 3 }.</font></p>
  </li>
</ol>
<blockquote>
  <p style="margin-left: 0.21in;"><font size="3">We should eliminate
the
wantback (or clarify the difference!)</font></p>
</blockquote>
<ol start="25">
  <li>
    <p><font size="3">Section 4.8.5: Same question as above. How does
wantback { id-swb 8 } differ from the corresponding check item { id-stc
7 }? Why is it needed?</font></p>
  </li>
  <li>
    <p><font size="3">Section 4.8.6: Is valAlg required to match the
validationAlg specified in the request or can the server choose a
different validation algorithm?</font></p>
  </li>
  <li>
    <p><font size="3">Section 4.8.7: Should the <font
 face="Courier New, monospace">nextUpdate</font> item be included if
the validation time is not the current time?</font></p>
  </li>
  <li>
    <p><font size="3">Section 4.11: More information needs to be
provided about what information can be implicitly specified by a <font
 face="Courier New, monospace">ValidationPolRef</font>. This section
seems to indicate that things such as the value for <font
 face="Courier New, monospace">inhibitPolMap</font> can be part part of
the definition of a policy reference. However, section 3.2.21 states
that a server must return an error if there a a discrepency between the
policy reference and the contents of the request and <font
 face="Courier New, monospace">inhibitPolMap</font> is not an optional
item in the request. So, if the value for <font
 face="Courier New, monospace">inhibitPolMap</font> is specified in the
policy referrence, the client will be forced to specify the same value
for this boolean in its request in order to avoid an error response,
making its inclusion as part of the definition of the policy reference
useless. Is a <font face="Courier New, monospace">ValidationPolRef</font>
limited to defining values for the parameters specified in <font
 face="Courier New, monospace">ValPolicy</font> in section 4.11?</font></p>
  </li>
  <li>
    <p><font size="3">Section 4.13.1: paragraph 1 sentences 2 through 4
are confusing.</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">It
is a<u><font color="#0000ff">n</font></u> implementation decision how
the keys are stored. This can be accomplished by cryptographic hashes
of public keys used to sign signedData responses. It could also be
shared symmetric keys used to HMAC authenticatedData responses.</font></font></p>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font size="3">Could
we replace these three sentences with: &nbsp; </font><font
 face="Courier New, monospace"><font size="3">Mechanisms for storage
of server keys or identifiers is a local matter. For example, a
client could store cryptographic hashes of public keys used to verify
signedData responses. Alternatively, a client could store shared
symmetric keys used to HMAC authenticatedData responses.</font></font></p>
<ol start="30">
  <li>
    <p><font size="3">Section 5: What is the meaning of the <font
 face="Courier New, monospace">svcpVersion</font> in the request? Is it
the highest version number that the client supports?</font></p>
  </li>
  <li>
    <p><font size="3">Section 6.1: Does the <font
 face="Courier New, monospace">svcpVersion</font> number in the
response need to match the <font face="Courier New, monospace">svcpVersion</font>
number in the request? If the highest version that the server can
process is lower than the version specified by the client, should it
specify the highest version number that it can process? If the version
specified by the client is lower than the highest version number that
the server can process, is the server required to respond with a
version number equal to that in the request?</font></p>
  </li>
  <li>
    <p><font size="3">Section 6:</font></p>
    <ul>
      <li>
        <p><font size="3">Is <font face="Courier New, monospace">validationPolicies</font>
the set of <font face="Courier New, monospace">ValidationPolRef</font>
that the server supports, whereas <font face="Courier New, monospace">defaultValPol</font>
is the validation policy used if none is specified? The <font
 face="Courier New, monospace">validationPolices</font> item is not
defined in this section.</font></p>
      </li>
      <li>
        <p><font size="3">What is <font face="Courier New, monospace">authDataCert</font>?
It is not defined.</font><br>
        </p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 9: Section 6 states that the policies
response MUST be signed. This conflicts with the seventh paragraph in
the Security Considerations:</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">The
request and response for which policies are supported on the server
are unsigned. These could lead to a denial of service attack where a
man-in-the-middle indicates that a server supports a different set of
validation policies than it actually does. This could result in the
client requesting validation based on a policy the server does not
support or lead the client using a less desirable policy.</font></font></p>
<blockquote>
  <p style="margin-left: 0.21in; margin-bottom: 0in;"><font size="3">Perhaps
we can delete this text from security considerations?</font></p>
</blockquote>
<br>
<br>
</body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DKAmEm058654; Fri, 13 Aug 2004 13:10:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DKAmPs058653; Fri, 13 Aug 2004 13:10:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DKAlah058630 for <[e-mail]>; Fri, 13 Aug 2004 13:10:47 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7DKAgjf022071; Fri, 13 Aug 2004 16:10:42 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06110418bd42c1cc33e6@[128.89.89.75]>
In-Reply-To:  <[e-mail] oft.com>
References:  <[e-mail] oft.com>
Date: Fri, 13 Aug 2004 15:22:08 -0400
To: "Trevor Freeman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SCVP issue
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:50 AM -0700 8/13/04, Trevor Freeman wrote:
>Hi Steve,
>I find this posting puzzling. As our private exchange established, the
>only mandated field a SCVP client is required to support is the
>validation policy reference. Therefore simple clients which only supply
>a policy references are conformant to the standard. All other fields are
>optional.  True I don't consider a policy reference has to be via an
>OID. There are other way to unambiguously refer to a set of rules which
>do not burden deployments and are successfully used for the same
>function in other standards to there is no precedence that the policy
>reference MUST be an OID. SCVP support the use of OIDS but does not
>mandate there use since that is ultimately a deployment decision.

You start by saying that you don't see why I'm bringing this up on 
this list, but the paragraph above makes it clear that we have very 
different views of what should be mandated support vs. optional 
support.  I've discussed my rationale for why I think OIDs should be 
a MUST, and parameters ought to be a SHOULD or MAY, but our exchanges 
have made no progress. Others in the off list discussion have 
expressed similar concerns. The reason for bringing this to the list 
is simple: if the WG shows a clear preference one way or the other, 
we can make sure the next rev of SCVP represents WG consensus.


>One the subject of parameters there is a big difference between optional
>standard parameters which are common to all polices e.g. root
>certificates, and completely new parameters. A validation policy is not
>mandated to cover all standard parameters e.g. it may only define the
>root certificates and 3379 mandates that the protocol be capable of
>passing other parameters. SCVP defiles how to pass all the standard
>parameters associated with the default validation algorithm. Other
>non-standard parameters are defined via the validation algorithm OID.

I don't disagree with your characterization above, but it fails to 
counter the argument I cited for why mandatory support for OIDs 
provides a more general and simpler way to ensure compatibility 
between different client and server implementations.

>There are also numerous cases where the corporate wide policy does not
>work for all departments or subsidiaries and those departments
>/subsidiaries have there own polices. Why cannot a department or
>subsidiary have simple devices, have their own policy and simply use the
>central server as a resource e.g. the department or subsidiary trusts
>the corporate servers to validate requests under a policy that they
>define. The state management software for the simple device can handle
>multiple parameters. It has to handle at least 3 (server URL, server key
>and policy reference) and it is not stressed by a couple more.

Your argument here assumes a corporate-wide server, which may or may 
not be true. It also assumes an inability for departments to cause 
additional policies to be configured in a corporate server, but an 
ability to correctly manage per-client parameters in all the clients 
for each department that does not follow a monolithic policy. Yes, 
all of these are possible situations, but there are a lot of "ifs" 
here. Also, its not just a matter of the software in the clients 
being able to "handle" the added parameters, but rather the ability 
of folks to correctly manage them.

I notice that you didn't repeat the last argument from our off-list 
discussion, here. There you argued that the decision of which way to 
represent policy (OID vs. list of parameters) was best left to the 
implementers of applications for the clients, vs. local IT managers. 
The argument does not seem to be consistent with the argument above, 
where the issue is one of local IT managers vs. corporate IT 
managers. Since you made the IT manager vs. implementer argument 
before, I though it would be good to mention it here for completeness.

Steve

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DIof5V051037; Fri, 13 Aug 2004 11:50:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DIof1k051036; Fri, 13 Aug 2004 11:50:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DIoefH051029 for <[e-mail]>; Fri, 13 Aug 2004 11:50:40 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 11:50:44 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Aug 2004 11:50:44 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Aug 2004 11:50:43 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 11:50:40 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP issue
Date: Fri, 13 Aug 2004 11:50:42 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP issue
thread-index: AcSBSlWguO4JNjZiShSozHsiZ+pU1wAFi/iA
From: "Trevor Freeman" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 13 Aug 2004 18:50:40.0857 (UTC) FILETIME=[6E310490:01C48166]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7DIoffH051030
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Steve,
I find this posting puzzling. As our private exchange established, the
only mandated field a SCVP client is required to support is the
validation policy reference. Therefore simple clients which only supply
a policy references are conformant to the standard. All other fields are
optional.  True I don't consider a policy reference has to be via an
OID. There are other way to unambiguously refer to a set of rules which
do not burden deployments and are successfully used for the same
function in other standards to there is no precedence that the policy
reference MUST be an OID. SCVP support the use of OIDS but does not
mandate there use since that is ultimately a deployment decision.

One the subject of parameters there is a big difference between optional
standard parameters which are common to all polices e.g. root
certificates, and completely new parameters. A validation policy is not
mandated to cover all standard parameters e.g. it may only define the
root certificates and 3379 mandates that the protocol be capable of
passing other parameters. SCVP defiles how to pass all the standard
parameters associated with the default validation algorithm. Other
non-standard parameters are defined via the validation algorithm OID. 

There are also numerous cases where the corporate wide policy does not
work for all departments or subsidiaries and those departments
/subsidiaries have there own polices. Why cannot a department or
subsidiary have simple devices, have their own policy and simply use the
central server as a resource e.g. the department or subsidiary trusts
the corporate servers to validate requests under a policy that they
define. The state management software for the simple device can handle
multiple parameters. It has to handle at least 3 (server URL, server key
and policy reference) and it is not stressed by a couple more.

Trevor

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Stephen Kent
* Sent: Friday, August 13, 2004 8:01 AM
* To: [e-mail]
* Subject: SCVP issue
* 
* 
* Folks,
* 
* A few of us have been discussing (off list) the issue of having a
* client send an OID to specify a validation policy at an SCVP (DPV)
* server, vs. having the client send parameters to direct validation.
* 
* My position is that support for OID-based policy references should be
* the default, and the mandatory minimum policy specification mechanism
* for both clients and servers, i.e., a MUST, and that support for
* explicit parameter passing should be an option, a SHOULD or MAY.
* there are several reasons for
* my saying this.
* 
* First, configuring a client to pass an OID is obviously simpler than
* configuring the client with all the parameters needed to direct path
* validation, and with the default policy feature that SCVP must
* support, one could image a zero-config  situation in some contexts.
* In general enterprises find it hard to manage configuration info for
* every client, and this problem is only magnified as the number of
* configuration parameters grows. Thus OID-specified validation is much
* simpler than parameter-specified validation, from a client
* perspective. Since the "S" in SCVP does stand for simple, ...
* 
* Also, as Trevor brought to my attention, one may choose to define
* additional
* parameters that define cert validity for a given application context,
* beyond the standard set of parameters used for path validation. If we
* want a allow an administrator to define such validation policies, we
* can't assume that standard clients will be prepared to convey the
* necessary parameters. This is especially
* true if we assume that the clients and servers are not produced by
* the same vendor. So, only via use of OIDs can we hope to allow such
* customization of cert validity in mixed vendor (or mixed version)
* environments.
* 
* These two points seem to argue for making OIDs the MUST method for
* conveying cert validation selection between  client and server,
* relegating parameter passing to a lesser status, e.g., SHOULD or MAY.
* 
* I'd like to receive feedback fro the list on this issue.
* 
* Steve




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHXn6k042058; Fri, 13 Aug 2004 10:33:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHXnuN042057; Fri, 13 Aug 2004 10:33:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHXmYo042025 for <[e-mail]>; Fri, 13 Aug 2004 10:33:48 -0700 (PDT) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id i7DHXStj011230; Sat, 14 Aug 2004 01:33:28 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id i7DHXSAl019550; Sat, 14 Aug 2004 01:33:28 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id i7DHXQ0i019463; Sat, 14 Aug 2004 01:33:26 +0800
Message-ID: <071201c4815b$a2f74e60$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>, "Stephen Kent" <[e-mail]>
References: <p0611040abd428423c064@[128.89.89.75]>
Subject: Re: SCVP issue
Date: Sat, 14 Aug 2004 01:33:23 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My position is that since SCVP is supposed to be a "simple"
protocol, it sould in default provide better support to simple clients.

I do not object to provide the possibility to allow a "complex"
client to send a full set of parameters to a "complex"
server. However, this can be done via an EXTENSION
mechanism. I strongly suggest that we should remove
all parameter fields from the current syntax and instead add
an EXTENSION mechanism to the SCVP Query
structure or the Validation Policy reference structure.
And then, we can define some standard EXTENSIONs
to allow a "complex" client to send RFC 3280 parameters,
revocation info requirements, or additional conditions (such
as name matching rules, key usage requirements, etc.)
to a  "complex" server that understand these extensions.
This way, we will keep the basic syntax of SCVP as simple
as possible but preserve the extensibility of the protocol.

=====
Wen-Cheng Wang


----- Original Message ----- 
From: "Stephen Kent" <[e-mail]>
To: <[e-mail]>
Sent: Friday, August 13, 2004 11:01 PM
Subject: SCVP issue


>
> Folks,
>
> A few of us have been discussing (off list) the issue of having a
> client send an OID to specify a validation policy at an SCVP (DPV)
> server, vs. having the client send parameters to direct validation.
>
> My position is that support for OID-based policy references should be
> the default, and the mandatory minimum policy specification mechanism
> for both clients and servers, i.e., a MUST, and that support for
> explicit parameter passing should be an option, a SHOULD or MAY.
> there are several reasons for
> my saying this.
>
> First, configuring a client to pass an OID is obviously simpler than
> configuring the client with all the parameters needed to direct path
> validation, and with the default policy feature that SCVP must
> support, one could image a zero-config  situation in some contexts.
> In general enterprises find it hard to manage configuration info for
> every client, and this problem is only magnified as the number of
> configuration parameters grows. Thus OID-specified validation is much
> simpler than parameter-specified validation, from a client
> perspective. Since the "S" in SCVP does stand for simple, ...
>
> Also, as Trevor brought to my attention, one may choose to define
additional
> parameters that define cert validity for a given application context,
> beyond the standard set of parameters used for path validation. If we
> want a allow an administrator to define such validation policies, we
> can't assume that standard clients will be prepared to convey the
> necessary parameters. This is especially
> true if we assume that the clients and servers are not produced by
> the same vendor. So, only via use of OIDs can we hope to allow such
> customization of cert validity in mixed vendor (or mixed version)
> environments.
>
> These two points seem to argue for making OIDs the MUST method for
> conveying cert validation selection between  client and server,
> relegating parameter passing to a lesser status, e.g., SHOULD or MAY.
>
> I'd like to receive feedback fro the list on this issue.
>
> Steve
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHEvJk039894; Fri, 13 Aug 2004 10:14:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHEvMW039893; Fri, 13 Aug 2004 10:14:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHEuiH039885 for <[e-mail]>; Fri, 13 Aug 2004 10:14:57 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 10:14:53 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Aug 2004 10:14:54 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Aug 2004 10:14:53 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 10:14:33 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Fri, 13 Aug 2004 10:14:52 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PKIX WG Agenda for 60th IETF (second try!)
thread-index: AcSBKNp0CqHYjd6IRV6K5t0EtOgaFwAL/M/Q
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 13 Aug 2004 17:14:33.0341 (UTC) FILETIME=[007BEAD0:01C48159]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7DHEviH039886
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
The validation algorithm in 3280 section 6 works for all certificates.
Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Friday, August 13, 2004 4:30 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > *
* > * To which value do you intialize max_path_length of point k in
6.1.2
* > * if you want to validate a CA cert that is used to signed another
CA?
* > *
* > [TF] SCVP supports all the inputs as defined in 6.1.1
* 
* 
* It seems that SCVP pretends to be able to valdidate *ANY* CA
certificate
* by using the isCA boolean which I think cannot work.
* 
* First, we are clearly outside the scope of the
* algorithm inputs of path validation algorithm of 3280, since the
* algorithm works is intended to work for EEs:
* 
*    The primary goal of path validation is to verify the binding
between
*    a subject distinguished name or a subject alternative name and
*    subject public key, as represented in the end entity certificate,
* 
* The algorithm still can work slightly modified if the EE cert is not
* present, in order just to validate the first CA.
* 
* But, in order to validate an intermediate CA that has not signed
directly
* the EE cert, one has to assume that the client has performed the 3280
* validation
* up to the CA in question, and one has to give correct information to
the
* SCVP
* server to do "the rest" or you have to return the intermediate values,
* i.e. the current maximum path length still allowed.
* 
* Assume you want a valid path for CA2 signing CA1 and an EE cert
* and you have a situation like
* 
*   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
*                    <- CA3withpathlength1 <- CAY .. othetrustanchor.
* 
* you cannot avoid that the SCVP server returns the first path
* which would not be valid to sign EE with an intermediate CA1.
* 
* 
* 
* 
* 
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHCVLf039567; Fri, 13 Aug 2004 10:12:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHCV2p039566; Fri, 13 Aug 2004 10:12:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHCULG039560 for <[e-mail]>; Fri, 13 Aug 2004 10:12:30 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 13 Aug 2004 10:12:34 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Aug 2004 10:12:34 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Aug 2004 10:12:33 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Aug 2004 10:12:06 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Fri, 13 Aug 2004 10:12:32 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PKIX WG Agenda for 60th IETF (second try!)
thread-index: AcSBGtSH9lzmiLiZTUK2dEJbnaVoyAAO413g
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 13 Aug 2004 17:12:06.0324 (UTC) FILETIME=[A8DAE740:01C48158]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7DHCULG039561
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
The question in point still comes back to how was the certificate
validated i.e. the algorithm and the parameters used by the server when
it returned the positive response. SCVP defines a default algorithm
where the server performs the path validation itself and provides an
extension mechanisms to define other algorithms. I don't see any
blocking issues to you defining a new validation algorithm which
encompasses DPV server delegating the validation decision to other DPV
server.
Trevor 

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Friday, August 13, 2004 2:49 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* >
* > Hi Peter,
* > I don't see any clause in 3379 that requires SCVP to support the
* > scenario you describe. In fact section 4.2 states "Protocols
designed to
* > satisfy these requirements MAY include optional fields and/or
extensions
* > to support relaying, re-direction or multicasting."
* 
* SCVP explicitely supports relaying.
* 
* The description of relaying in SCVP implies that the relaying
* server obtains a response from a remote server, and has to interprete
* it to provide a positive response, since the initial client does
* not necessarily trust the remote server.
* 
* > Therefore SCVP meets the 3379 requirements. The scenario you
describe
* > requires at a minimum the rely server to have a new validation
algorithm
* > because as you describe  it is not verifying the result itself but
* > verifying the DPV response from another server. Therefore you are at
* > liberty to define such extensions.
* 
* There is no need for any extension.
* 
* The relaying server creates a valid path and indicates *ALL*
information
* that it has used to determine this information. And since SCVP allows
* for relaying, it must alow allow for returning the response from the
* remote server as is, quite similar as for OCSP reponses etc.
* 
* 
* 
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGxrIl038110; Fri, 13 Aug 2004 09:59:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DGxrpi038109; Fri, 13 Aug 2004 09:59:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGxqOD038058 for <[e-mail]>; Fri, 13 Aug 2004 09:59:52 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7DGxijh011586; Fri, 13 Aug 2004 12:59:45 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06110415bd429ff94697@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 13 Aug 2004 12:45:57 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SCVP issue
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 5:51 PM +0200 8/13/04, Peter Sylvester wrote:
>  >>
>>  I'd like to receive feedback fro the list on this issue.
>
>Does the following corresponds in some way to your idea?
>
>
>>From sylvest Thu May  6 18:25:04 2004
>To: [e-mail], [e-mail]
>Subject: Re: FW: scvp
>Cc: [e-mail]
>
>I agree with Denis about a single value policy.
>
>I think that we have already a structure elsewhere that
>is close to what can be used. 
>
>    PolicyInformation ::= SEQUENCE {
>         policyIdentifier   CertPolicyId,
>         policyQualifiers   SEQUENCE SIZE (1..MAX) OF
>                                 PolicyQualifierInfo OPTIONAL }
>
>    CertPolicyId ::= OBJECT IDENTIFIER
>
>    PolicyQualifierInfo ::= SEQUENCE {
>         policyQualifierId  PolicyQualifierId,
>         qualifier          ANY DEFINED BY policyQualifierId }
>
>
>the PolicyQualifierId would be an indidation of a
>particular algorithm that needs to be performed and its
>parameters. one would be "3280 path processing input"
>another would be 'end entry naming comparison', etc.

this seems like a reasonable way to encode this info. I don't have 
strong opinions re the encoding choice. First I'd like to get 
agreement on the OIDs vs. parameters question.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGxMgg037836; Fri, 13 Aug 2004 09:59:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DGxMR6037835; Fri, 13 Aug 2004 09:59:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGxK7p037794 for <[e-mail]>; Fri, 13 Aug 2004 09:59:21 -0700 (PDT) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id i7DGxFpK008552; Sat, 14 Aug 2004 00:59:15 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id i7DGxFfa031410; Sat, 14 Aug 2004 00:59:15 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id i7DGxF0i031323; Sat, 14 Aug 2004 00:59:15 +0800
Message-ID: <06bb01c48156$db7d77a0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Comments on SCVP Draft 15
Date: Sat, 14 Aug 2004 00:59:12 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry! I forgot one comment in my last post.

11. Section 3.2.12.2
It is strange to have "Name Validation Algorithm" as a sub section of
of "3.2.12 validationAlg". Does it means a "Name Validation Algorithm"
itself can be regarded as a certificate validation algorithm?
My understanding is a Name Validation Algorithm is only a part of the
whole validation algorithm (or is an additional conditions to the validation
algorithm, it can not be used to replace the whole validation algorithm.
However, with the current syntax, if one specifies a Name Validation
Algorithm, then it can not specify the validation algorithm anymore. That
is unreasonable.

=====
Wen-Cheng Wang

----- Original Message ----- 
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Saturday, August 14, 2004 12:45 AM
Subject: Comments on SCVP Draft 15


> Here is my comments on SCVP Draft 15:
>
> 1. Should it be called "certificate path" or "certification path"?
> In SCVP Draft 15, sometimes it is called "certificate path",
> otherwhile it is called "certification path"? Please be consistent.
> I believe that "certification path" is the mainstream use.
>
> 2. Do we really need to keep the validationAlg item in the SCVP Query?
> It is very confusing to have both the references of a validation policy
> and a validation algorithm in the SCVP Query. There is a large
> overlap between the concepts of a validation policy and a validation
> algorithm. My understanding is that the validation algorithm is part
> of the validation policy. That is, if one specifies a validation policy,
> then it already implies a validation algorithm. Therefore, there is
> no need to have a validationAlg item in the SCVP Query. If we
> remove a validationAlg item from the SCVP Query, we can still
> regard inputs such as trust anchors, user-initial-policy-set,
> initial-policy-mapping-inhibit, initial-explicit-policy, or
> initial-any-policy-inhibit as parameters to the validation policy.
> (Be sure to make all these parameters optional, because the
> validation might already implies all of them.)
>
> 3. Please consider to reorganize the SCVP Query data structure.
> Especially, please consider to group parameters such as trust anchors,
> user-initial-policy-set, initial-policy-mapping-inhibit,
> initial-explicit-policy,
> or initial-any-policy-inhibit into a sub-structure. (If I remember
> correctly,
> Denis had similar opinion.)
>
> In my opinion, the current syntax for the SCVP Query data structure is
> not only ugly but also very likely causes ambiguity. For example, it is
> not clear if one can specify any parameters without specifing a
> validation policy (or a validation algorithm). I believe that design
> good data structures is an important part of designing a protocol.
> A good protocol should have well-designed data structures. That
> is the principle of data structures we learnt in the college computer
> science
> course, isn't it?
>
> 4. Parameters such as inhibitPolMap, requireExplicitPol, ignoreAnyPol,
> IsCA should be OPTIONAL fields instead of being fields with a DEFAULT
> value. In many cases, the client would like to OMIT these parameters. (For
> example in the cases where the validation policy implies all the
> parameters.)
> If we let these parameters be  fields with a DEFAULT value, then there
> is no way to distinct whether the client want to omit them or want to
> use the default value. Besides, there is no consensus on the default value
> for these parameters in this WG. Especially, I do not agree why the
default
> value for requireExplicitPol is FALSE, because I believe most serious
> verifiers would require a explict certificate policy be set in all
> certificates
> in the path.
>
> 5. Please consider change the name of the parameters to align with
> the names used in RFC 3280. Especially, I think 'ignoreAnyPol' is
> a bad name. Please note that it is called 'initial-any-policy-inhibit'
> in RFC 3280, and 'inhibit' and 'ignore' have quite different meaning.
> Besides, since all these parameters are all 'initial' parameters, I
> think it is better to keep the 'initial' in their names. Therefore, how
> about change their name into 'initPolMapInhibit', 'initExplicitPol',
> 'initAnyPolInhibit', and 'initCertPolSet'.
>
> 6. Section 3.2.4
> What if the client requests the server to include the full request in
> the response but the server does not support that? Should the
> server return a error to the client? If not, should the client reject the
> response that only includes a hash of the request?
>
> 7. Section 3.2.5
> What if the client requests the server to include the fullPolResponse
> in the CVResponse but the server does not support that? Should
> the server return a error to the client? If not, should the client reject
> the response that does not include the fullPolResponse in the
> CVResponse?
>
> 8. Section 3.2.10
> What if the client requests the server to sign the response but the
> server does not support that? Should the server return a error to
> the client? If not, should the client reject the unsigned response?
>
> 9. Section 3.2.13
> In additional to supporting validating a certificate relative to a
> specific validatyTime or current time, it is also important to allow
> the client to ask the server whether the target certificate
> is valid during a "time period" (i.e., from time t1 to time t2).
> In the cases where a client want to verify a long-term digital
> signature which might be signed between time t1 and time t2,
> the client needs make sure whether the signer's certificate
> is valid from time t1 to time t2. Please take a look at RFC 3126
> and the paper titled "General principles of digital signature"
> (http://www.timestamp.cyber.ee/principles_en.pdf), then you will
> see why it is important to determine whether the target certificate
> is valid during a "time period".
>
> 10. Section 3.2.14
> I do not see why user-initial-policy-set needs to be associated
> with the trust anchor. This is not align with RFC 3280. Please
> consider moving this parameter to the same level as other
> parameters such as initial-policy-mapping-inhibit,
> initial-explicit-policy, and initial-any-policy-inhibit.
>
> =====
> Wen-Cheng Wang
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGkKLN035844; Fri, 13 Aug 2004 09:46:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DGkKfw035843; Fri, 13 Aug 2004 09:46:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGkJ8Z035819 for <[e-mail]>; Fri, 13 Aug 2004 09:46:19 -0700 (PDT) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by fw.chttl.com.tw (8.13.1/8.13.1) with ESMTP id i7DGk3WQ007501; Sat, 14 Aug 2004 00:46:03 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id i7DGk3To018529; Sat, 14 Aug 2004 00:46:03 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id i7DGk10i018440; Sat, 14 Aug 2004 00:46:02 +0800
Message-ID: <06a401c48155$03351430$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Comments on SCVP Draft 15
Date: Sat, 14 Aug 2004 00:45:58 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here is my comments on SCVP Draft 15:

1. Should it be called "certificate path" or "certification path"?
In SCVP Draft 15, sometimes it is called "certificate path",
otherwhile it is called "certification path"? Please be consistent.
I believe that "certification path" is the mainstream use.

2. Do we really need to keep the validationAlg item in the SCVP Query?
It is very confusing to have both the references of a validation policy
and a validation algorithm in the SCVP Query. There is a large
overlap between the concepts of a validation policy and a validation
algorithm. My understanding is that the validation algorithm is part
of the validation policy. That is, if one specifies a validation policy,
then it already implies a validation algorithm. Therefore, there is
no need to have a validationAlg item in the SCVP Query. If we
remove a validationAlg item from the SCVP Query, we can still
regard inputs such as trust anchors, user-initial-policy-set,
initial-policy-mapping-inhibit, initial-explicit-policy, or
initial-any-policy-inhibit as parameters to the validation policy.
(Be sure to make all these parameters optional, because the
validation might already implies all of them.)

3. Please consider to reorganize the SCVP Query data structure.
Especially, please consider to group parameters such as trust anchors,
user-initial-policy-set, initial-policy-mapping-inhibit,
initial-explicit-policy,
or initial-any-policy-inhibit into a sub-structure. (If I remember
correctly,
Denis had similar opinion.)

In my opinion, the current syntax for the SCVP Query data structure is
not only ugly but also very likely causes ambiguity. For example, it is
not clear if one can specify any parameters without specifing a
validation policy (or a validation algorithm). I believe that design
good data structures is an important part of designing a protocol.
A good protocol should have well-designed data structures. That
is the principle of data structures we learnt in the college computer
science
course, isn't it?

4. Parameters such as inhibitPolMap, requireExplicitPol, ignoreAnyPol,
IsCA should be OPTIONAL fields instead of being fields with a DEFAULT
value. In many cases, the client would like to OMIT these parameters. (For
example in the cases where the validation policy implies all the
parameters.)
If we let these parameters be  fields with a DEFAULT value, then there
is no way to distinct whether the client want to omit them or want to
use the default value. Besides, there is no consensus on the default value
for these parameters in this WG. Especially, I do not agree why the default
value for requireExplicitPol is FALSE, because I believe most serious
verifiers would require a explict certificate policy be set in all
certificates
in the path.

5. Please consider change the name of the parameters to align with
the names used in RFC 3280. Especially, I think 'ignoreAnyPol' is
a bad name. Please note that it is called 'initial-any-policy-inhibit'
in RFC 3280, and 'inhibit' and 'ignore' have quite different meaning.
Besides, since all these parameters are all 'initial' parameters, I
think it is better to keep the 'initial' in their names. Therefore, how
about change their name into 'initPolMapInhibit', 'initExplicitPol',
'initAnyPolInhibit', and 'initCertPolSet'.

6. Section 3.2.4
What if the client requests the server to include the full request in
the response but the server does not support that? Should the
server return a error to the client? If not, should the client reject the
response that only includes a hash of the request?

7. Section 3.2.5
What if the client requests the server to include the fullPolResponse
in the CVResponse but the server does not support that? Should
the server return a error to the client? If not, should the client reject
the response that does not include the fullPolResponse in the
CVResponse?

8. Section 3.2.10
What if the client requests the server to sign the response but the
server does not support that? Should the server return a error to
the client? If not, should the client reject the unsigned response?

9. Section 3.2.13
In additional to supporting validating a certificate relative to a
specific validatyTime or current time, it is also important to allow
the client to ask the server whether the target certificate
is valid during a "time period" (i.e., from time t1 to time t2).
In the cases where a client want to verify a long-term digital
signature which might be signed between time t1 and time t2,
the client needs make sure whether the signer's certificate
is valid from time t1 to time t2. Please take a look at RFC 3126
and the paper titled "General principles of digital signature"
(http://www.timestamp.cyber.ee/principles_en.pdf), then you will
see why it is important to determine whether the target certificate
is valid during a "time period".

10. Section 3.2.14
I do not see why user-initial-policy-set needs to be associated
with the trust anchor. This is not align with RFC 3280. Please
consider moving this parameter to the same level as other
parameters such as initial-policy-mapping-inhibit,
initial-explicit-policy, and initial-any-policy-inhibit.

=====
Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGCn8E032855; Fri, 13 Aug 2004 09:12:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DGCnl9032854; Fri, 13 Aug 2004 09:12:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DGClVn032838 for <[e-mail]>; Fri, 13 Aug 2004 09:12:48 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft4.fr.colt.net with ESMTP id i7DGCa610808 for <[e-mail]>; Fri, 13 Aug 2004 18:12:42 +0200
Message-ID: <[e-mail]>
Date: Fri, 13 Aug 2004 18:12:42 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226
X-Accept-Language: fr, en-us, en, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: SCVP issue
References: <p0611040abd428423c064@[128.89.89.75]>
In-Reply-To: <p0611040abd428423c064@[128.89.89.75]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:

> First, configuring a client to pass an OID is obviously simpler than 
> configuring the client with all the parameters needed to direct path 
> validation, [...]

In other words, OID enables server based configuration management, 
whereas the other has to be client based.

Seen like that, this is /etc/host against DNS, and there is no 
hesitation as to which one is the right choice.
 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFp8ZH030096; Fri, 13 Aug 2004 08:51:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DFp8fU030095; Fri, 13 Aug 2004 08:51:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DFp66K030088 for <[e-mail]>; Fri, 13 Aug 2004 08:51:07 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7DFp2N04141; Fri, 13 Aug 2004 17:51:02 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 13 Aug 2004 17:51:02 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7DFp1F00180; Fri, 13 Aug 2004 17:51:01 +0200 (MEST)
Date: Fri, 13 Aug 2004 17:51:01 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: SCVP issue
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> 
> I'd like to receive feedback fro the list on this issue.

Does the following corresponds in some way to your idea?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DF1iHo021639; Fri, 13 Aug 2004 08:01:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DF1iM2021638; Fri, 13 Aug 2004 08:01:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DF1hXQ021586 for <[e-mail]>; Fri, 13 Aug 2004 08:01:43 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7DF1bjf005054 for <[e-mail]>; Fri, 13 Aug 2004 11:01:38 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0611040abd428423c064@[128.89.89.75]>
Date: Fri, 13 Aug 2004 11:01:20 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: SCVP issue
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

A few of us have been discussing (off list) the issue of having a 
client send an OID to specify a validation policy at an SCVP (DPV) 
server, vs. having the client send parameters to direct validation.

My position is that support for OID-based policy references should be 
the default, and the mandatory minimum policy specification mechanism 
for both clients and servers, i.e., a MUST, and that support for 
explicit parameter passing should be an option, a SHOULD or MAY. 
there are several reasons for
my saying this.

First, configuring a client to pass an OID is obviously simpler than 
configuring the client with all the parameters needed to direct path 
validation, and with the default policy feature that SCVP must 
support, one could image a zero-config  situation in some contexts. 
In general enterprises find it hard to manage configuration info for 
every client, and this problem is only magnified as the number of 
configuration parameters grows. Thus OID-specified validation is much 
simpler than parameter-specified validation, from a client 
perspective. Since the "S" in SCVP does stand for simple, ...

Also, as Trevor brought to my attention, one may choose to define additional
parameters that define cert validity for a given application context, 
beyond the standard set of parameters used for path validation. If we 
want a allow an administrator to define such validation policies, we 
can't assume that standard clients will be prepared to convey the 
necessary parameters. This is especially
true if we assume that the clients and servers are not produced by 
the same vendor. So, only via use of OIDs can we hope to allow such 
customization of cert validity in mixed vendor (or mixed version) 
environments.

These two points seem to argue for making OIDs the MUST method for 
conveying cert validation selection between  client and server, 
relegating parameter passing to a lesser status, e.g., SHOULD or MAY.

I'd like to receive feedback fro the list on this issue.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DCLJ0f061354; Fri, 13 Aug 2004 05:21:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DCLJar061353; Fri, 13 Aug 2004 05:21:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DCLHZC061339 for <[e-mail]>; Fri, 13 Aug 2004 05:21:18 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7DCLJN01674 for <[e-mail]>; Fri, 13 Aug 2004 14:21:19 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 13 Aug 2004 14:21:19 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7DCLId29594 for [e-mail]; Fri, 13 Aug 2004 14:21:18 +0200 (MEST)
Date: Fri, 13 Aug 2004 14:21:18 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Speak now or forever hold your peace...
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

3.3 Requestor 
   
  The requestor item MUST be an octet string.  

What is the reason for this statement. It is defined as an ASN1
octet string. So there is no other choice.

                                              No provisions are made 
  to ensure uniqueness of the requestor octet string; however, all of 
  the octets MUST have values other than zero.

This is inconsistent of what is specified in relaying
where zeros are allowed. 

7 SCVP Server Relay 

... 
 
  When an SVCP server receives a request that contains a requestor 
  item, the server MUST check for its own identifier.  The identifier 
  could be located at the beginning of the octet string followed by a 
  zero octet, or it could be located between two zero octets.

With thgis logic a server cannot detect immediately a loop to itself
of a request relayed to it by another server.


I strongly suggest again to replace this handling by using a sequence
of octet strings at least for the second request instaed of this
null logic.  



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DCBvxJ058392; Fri, 13 Aug 2004 05:11:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DCBvpu058391; Fri, 13 Aug 2004 05:11:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DCBufZ058377 for <[e-mail]>; Fri, 13 Aug 2004 05:11:56 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7DCBvN01639 for <[e-mail]>; Fri, 13 Aug 2004 14:11:57 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 13 Aug 2004 14:11:57 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7DCBut29591 for [e-mail]; Fri, 13 Aug 2004 14:11:56 +0200 (MEST)
Date: Fri, 13 Aug 2004 14:11:56 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Speak now or forever hold your peace...
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paragraph 3.2.17 does not seem clear enough to me. It
does not indicate how the server performs the matching
between the provided keyusage bit string and the
bitstring in the candidate certificate. 

It should be clarified whetyher this is a conparison
for identity or whether it is tested that all 1 bits
in the client provided string are also 1 in the
cert. 

Isn't there a ',' missing behind 'Therefore'.

in a context of a digital signature, the nonrepudiation
bit alone can be used as far as I remember. 


How can one ask for either keyEncipherment or keyAgreement
in the case of a serverAuth or an email cert. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DBTeS6044065; Fri, 13 Aug 2004 04:29:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DBTeNK044064; Fri, 13 Aug 2004 04:29:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DBTcog044049 for <[e-mail]>; Fri, 13 Aug 2004 04:29:39 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7DBTdN01315; Fri, 13 Aug 2004 13:29:39 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 13 Aug 2004 13:29:39 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7DBTcp29517; Fri, 13 Aug 2004 13:29:38 +0200 (MEST)
Date: Fri, 13 Aug 2004 13:29:38 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> * 
> * To which value do you intialize max_path_length of point k in 6.1.2
> * if you want to validate a CA cert that is used to signed another CA?
> * 
> [TF] SCVP supports all the inputs as defined in 6.1.1


It seems that SCVP pretends to be able to valdidate *ANY* CA certificate
by using the isCA boolean which I think cannot work.

First, we are clearly outside the scope of the 
algorithm inputs of path validation algorithm of 3280, since the
algorithm works is intended to work for EEs:

   The primary goal of path validation is to verify the binding between
   a subject distinguished name or a subject alternative name and
   subject public key, as represented in the end entity certificate,

The algorithm still can work slightly modified if the EE cert is not
present, in order just to validate the first CA. 

But, in order to validate an intermediate CA that has not signed directly
the EE cert, one has to assume that the client has performed the 3280 validation
up to the CA in question, and one has to give correct information to the SCVP
server to do "the rest" or you have to return the intermediate values, 
i.e. the current maximum path length still allowed. 

Assume you want a valid path for CA2 signing CA1 and an EE cert
and you have a situation like

  EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
                   <- CA3withpathlength1 <- CAY .. othetrustanchor.

you cannot avoid that the SCVP server returns the first path
which would not be valid to sign EE with an intermediate CA1.

 







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D9nHtx019303; Fri, 13 Aug 2004 02:49:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D9nHc2019302; Fri, 13 Aug 2004 02:49:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D9nFvw019293 for <[e-mail]>; Fri, 13 Aug 2004 02:49:16 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7D9nFN00244; Fri, 13 Aug 2004 11:49:15 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 13 Aug 2004 11:49:15 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7D9nFU29323; Fri, 13 Aug 2004 11:49:15 +0200 (MEST)
Date: Fri, 13 Aug 2004 11:49:15 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Hi Peter,
> I don't see any clause in 3379 that requires SCVP to support the
> scenario you describe. In fact section 4.2 states "Protocols designed to
> satisfy these requirements MAY include optional fields and/or extensions
> to support relaying, re-direction or multicasting."

SCVP explicitely supports relaying.

The description of relaying in SCVP implies that the relaying
server obtains a response from a remote server, and has to interprete
it to provide a positive response, since the initial client does
not necessarily trust the remote server. 

> Therefore SCVP meets the 3379 requirements. The scenario you describe
> requires at a minimum the rely server to have a new validation algorithm
> because as you describe  it is not verifying the result itself but
> verifying the DPV response from another server. Therefore you are at
> liberty to define such extensions.

There is no need for any extension. 

The relaying server creates a valid path and indicates *ALL* information
that it has used to determine this information. And since SCVP allows
for relaying, it must alow allow for returning the response from the
remote server as is, quite similar as for OCSP reponses etc. 







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D8lMrj001896; Fri, 13 Aug 2004 01:47:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7D8lMsk001895; Fri, 13 Aug 2004 01:47:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7D8lHxI001872 for <[e-mail]>; Fri, 13 Aug 2004 01:47:18 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7D8kwN29670; Fri, 13 Aug 2004 10:46:58 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 13 Aug 2004 10:46:58 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7D8kvJ29231; Fri, 13 Aug 2004 10:46:57 +0200 (MEST)
Date: Fri, 13 Aug 2004 10:46:57 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Speak now or forever hold your peace...
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Good news. 
I stand corrected.
Thanks for the information. 
Peter

> -----
> There are **MANY** ASN.1 specs that have tags in excess of 30.
> I know of no commercial-grade ASN.1 toolkit, nor any of the
> popular free ones, that suffers from such a deficiency.
> 
> In the early 1990's the implementor's organization in Europe, the U.S.A
> (NIST Stable Implementation Guideline) and Asia agreed that ASN.1 specs
> should not use tag numbers greater than 16383, and implicitly, that tools
> should support tags of at least that size.  To the best of my knowledge
> all commercial-grade and popular free ASN.1 toolkits support tags this
> large.
> -----
> 
> Olivier
> 



Received: from 208.184.76.43 ([218.12.43.234]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7D2Q5sp062180; Thu, 12 Aug 2004 19:26:09 -0700 (PDT) (envelope-from [e-mail])
Received: from hf5m.p3t7.net (HELO qdap) ([152.228.228.168]) by 208.184.76.43 with ESMTP id <456605-73431>; Fri, 13 Aug 2004 07:20:46 +0400
Message-ID: <6--8-2c9n00---2$-$$[e-mail]>
From: "Administrator" <[e-mail]>
To: [e-mail]
Subject: Staff Bulletin
Date: Fri, 13 Aug 04 07:20:46 GMT
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: The Bat! (v1.52f) Business
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="528D1__D7E"

This is a multi-part message in MIME format.

--528D1__D7E
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Staff Members:

You Must Respond By 5 P.M. Monday, August 16, 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 Staff Members, who respond to this
message before 5 P.M., Monday, August 16, 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. Monday, August 16, 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 Nonprofit Staff Member or Associate.
  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. Monday, August 16, 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. Monday, August 16, 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
--528D1__D7E--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CF3nTC090239; Thu, 12 Aug 2004 08:03:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7CF3n2X090238; Thu, 12 Aug 2004 08:03:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7CF3k9Z090212 for <[e-mail]>; Thu, 12 Aug 2004 08:03:47 -0700 (PDT) (envelope-from [e-mail])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Aug 2004 17:03:39 +0200
Received: from [10.193.13.101] ([10.193.13.101]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Aug 2004 17:03:38 +0200
Message-ID: <[e-mail]>
Date: Thu, 12 Aug 2004 17:03:38 +0200
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom - Research & Development  Division
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], SCOTT Bancroft <[e-mail]>
Subject: Re: Speak now or forever hold your peace...
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Aug 2004 15:03:38.0745 (UTC) FILETIME=[8C5DEE90:01C4807D]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester wrote:

>>>tags > 30 create most likely some problems in decoders, too.
>>
>>You mean: In decoders badly hand-coded. ;)  I'm not aware of such a bug 
>>with decoders generated by a compiler.
> 
> 
> This is not a question of a bug, it is a question of whether
> low level routines can supports tags > 30.
> 
> This has not much to do whether the syntax is treated by a compiler
> but with the possibility of decoding larger value in low level routines
> in a situation where all practical well known syntaxes do not have 
> tags > 30, thus, the low level implementation of tag decoding can 
> assume that you have only one octet for a tag.
> 
> I have not seen any compiler that is able to link againt a low level
> decoder specific with the maximum tag length that can ever occur the
> given compilation environment. 
> 
> how many compilers can handle a context tag of about 2**130
> 
> But well, we are somehow getting out of scope of this discussion.

We may be out of scope, but since your assertion about decoders looked 
wrong to me, I checked with Bancroft Scott from OSS Nokalva and here is 
what he said:
-----
There are **MANY** ASN.1 specs that have tags in excess of 30.
I know of no commercial-grade ASN.1 toolkit, nor any of the
popular free ones, that suffers from such a deficiency.

In the early 1990's the implementor's organization in Europe, the U.S.A
(NIST Stable Implementation Guideline) and Asia agreed that ASN.1 specs
should not use tag numbers greater than 16383, and implicitly, that tools
should support tags of at least that size.  To the best of my knowledge
all commercial-grade and popular free ASN.1 toolkits support tags this
large.
-----

Olivier



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C8eZ7h000406; Thu, 12 Aug 2004 01:40:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C8eZ85000405; Thu, 12 Aug 2004 01:40:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk (ns3.worldcall.net.pk [203.81.192.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C8eXNa000399 for <[e-mail]>; Thu, 12 Aug 2004 01:40:34 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.203.97]) by ns3.worldcall.net.pk (8.12.5+Sun/8.12.5) with SMTP id i7C8ZqjT014880; Thu, 12 Aug 2004 14:35:53 +0600 (PKST)
Message-ID: <01b701c48048$c896e770$[e-mail]>
From: "Faisal Maqsood" <[e-mail]>
To: "Francis Dupont" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Speak now or forever hold your peace... 
Date: Thu, 12 Aug 2004 13:45:48 +0500
Organization: Ascertia Ltd
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi FD,

please see comments below:

Regards,
Faisal

==============================
----- Original Message -----
From: "Francis Dupont" <[e-mail]>
To: "Faisal Maqsood" <[e-mail]>
Sent: Wednesday, August 11, 2004 21:08
Subject: Re: Speak now or forever hold your peace...


In your previous mail you wrote:

   => you should get the .... to for CertConfig. I have a concern about
                              too
   this: this gives two different ways to specify the parameters for
   an unique cert.

   [FM: No, By "....." I mean the remaining part of Query in draft 15 .

=> I mean the same thing(s).

   Yes this gives two different ways, but let me explain how this helps:

=> I understand your idea but with per cert checks/wantbacks why not
per cert isCA flag, etc.
[FM:
As I have already written that my puposed structure will come out
with new things. But as in current SCVP structure there are elements
provided only to facilitate the client to make single request/response in a
single file so that client can make his archives in a better way according
to their needs i.e. Refering to 3.2.5. To consider such elements the
purposed structure can benefit
the clients and it also saves time of client to make different requests and
also communication time will be reduced.
In addition you may see similar problem with TrustAnchors if client puts
three certificates in QueriedCerts and four certificates in TrustAnchors...
will it not make burden on server in DPD? Ofcourse it will.
You may imagine the real time requests/responses of more number of
QueriedCerts and TrustAnchors, so I am not happy with the existing structure
but it is all upto ASN.1 designers to consider such more serious things
present in existing structure.]

   IMHO the best option is just to accept one certificate per request.
   It keeps SCVP so simple (:-)! Sharing of certificates (huge structures)
   is already handled by references, we need only a way to share crls,
   i.e., define our own RevocationInfo reference system?

=> I put this again because it is a good summary of my opinion.

Regards

[e-mail]





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C7K9dH083603; Thu, 12 Aug 2004 00:20:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7C7K9ad083602; Thu, 12 Aug 2004 00:20:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7C7K8vT083591 for <[e-mail]>; Thu, 12 Aug 2004 00:20:09 -0700 (PDT) (envelope-from [e-mail])
Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i7C7K8il009743 for <[e-mail]>; Thu, 12 Aug 2004 01:20:08 -0600 (MDT)
Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i7C7K7UZ010302 for <[e-mail]>; Thu, 12 Aug 2004 01:20:08 -0600 (MDT)
Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7C7HS1G007606; Thu, 12 Aug 2004 02:17:28 -0500 (CDT)
Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7C7HSQl007605; Thu, 12 Aug 2004 02:17:28 -0500 (CDT)
Date: Thu, 12 Aug 2004 02:17:28 -0500
From: Nicolas Williams <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [Pki4ipsec] OCSP in IKEv2
Message-ID: <[e-mail]>
Mail-Followup-To: Michael Myers <[e-mail]>, [e-mail], [e-mail], [e-mail]
References: <p06110402bd36e8023a47@[130.129.131.20]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Your I-D actually cleared up some confusion in the KRB WG over the
meaning of "OCSP tunnelling" and led to achievement of consensus on how
to add support for OCSP to PKINIT.  Thank you.

Nico
-- 

On Sat, Aug 07, 2004 at 10:21:32AM -0700, Michael Myers wrote:
> All,
> 
> The intersection of IPSEC with PKI is of recent interest.  Towards that
> dialog, Hannes Tschofenig and I have proposed how OCSP could be used to
> deliver certificate status in-band to IKEv2.  We were driven first to
> consider the important use case of EAP (i.e. the Road Warrior) but also
> considered the Peer-to-Peer case in order to develop a general solution.
> 
> This individual submission I-D can be found at:
> http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt
> 
> Two new certificate encoding types are proposed:  OCSP Responder Hash
> and OCSP Response.  An OCSP Responder Hash is sent in a CERTREQ,
> computed as trust anchor hashes are computed but sent in a separate
> CERTREQ.  A corresponding OCSP Response is sent back in its own CERT
> payload and in the context of the CERT payload carrying the
> participant's certificate.  That is, an IKEv2 participant sends both its
> cert and that cert's status in separate CERT payloads.
> 
> Hannes and I look forward to your comments and debate.  I've
> cross-posted due to intersecting interests but please post comments to
> the IPSEC list only.
> 
> Michael Myers
> 
> 
> _______________________________________________
> pki4ipsec mailing list
> [e-mail]
> http://honor.icsalabs.com/mailman/listinfo/pki4ipsec



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BKwPDN089604; Wed, 11 Aug 2004 13:58:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BKwPgM089603; Wed, 11 Aug 2004 13:58:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BKwOq8089590 for <[e-mail]>; Wed, 11 Aug 2004 13:58:24 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Aug 2004 13:58:24 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 2004 13:58:24 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 13:58:24 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 13:58:41 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Wed, 11 Aug 2004 13:58:26 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PKIX WG Agenda for 60th IETF (second try!)
thread-index: AcR/w2f9I2rgO+fhRu6EGC99JlNTZAAIFBjg
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Aug 2004 20:58:41.0197 (UTC) FILETIME=[FB3465D0:01C47FE5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BKwOq8089598
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
I don't see any clause in 3379 that requires SCVP to support the
scenario you describe. In fact section 4.2 states "Protocols designed to
satisfy these requirements MAY include optional fields and/or extensions
to support relaying, re-direction or multicasting."

Therefore SCVP meets the 3379 requirements. The scenario you describe
requires at a minimum the rely server to have a new validation algorithm
because as you describe  it is not verifying the result itself but
verifying the DPV response from another server. Therefore you are at
liberty to define such extensions.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Wednesday, August 11, 2004 9:51 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > Hi Peter,
* > The TSA and DPVs responses are both in the paragraph you refer to
and
* > both are outside the bounds of the validation algorithms defined
today
* > so do not constitute information useful to a relying party. So I
think
* > SCVP 15 conforms to RFC3379.  Wherever you define the algorithm that
* > does use such values as part of the validation process you can also
* > define how to return them in the response. The SVP response is
* > extensible so I am confident you can do that.
* 
* 
* The scenario is a local DPV server operating as a locally trusted
* interface like in OCSP. The DPV server has the knoweldge about
* which other DPV servers are to be contacted to validate the cert
* in question.
* 
* The DPV relay thus simply asks the external service (operated closely
* to a CA for example), and then simply confirms the result by
* telling its client that the cert is good 'because the other DPV told
it',
* and it includes the original DPV response.
* 
* This behaviour is IMO an essential feature for the different types
* of relaying.
* 
* it is not up to me to define these things: SCVP needs to support them
* to conform wityh 3379. That's why I propose simply to add a text
* with a response value containing a CMS content-type. I do not think
* that this should require another document.
* 
* 
* 
* 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHaVdf068731; Wed, 11 Aug 2004 10:36:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BHaVZK068730; Wed, 11 Aug 2004 10:36:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHaUNO068724 for <[e-mail]>; Wed, 11 Aug 2004 10:36:30 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Aug 2004 10:36:14 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 2004 10:36:13 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 10:36:14 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 10:34:24 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Wed, 11 Aug 2004 10:36:14 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PKIX WG Agenda for 60th IETF (second try!)
thread-index: AcR/yA9B2DXs5MMWRB2dUJSJNbszJwAAU3kA
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Aug 2004 17:34:24.0121 (UTC) FILETIME=[716B0690:01C47FC9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BHaUNO068725
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Wednesday, August 11, 2004 10:24 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > * To which value do you intialize max_path_length of point k in
6.1.2
* > * if you want to validate a CA cert that is used to signed another
CA?
* > *
* > [TF] SCVP supports all the inputs as defined in 6.1.1
* >
* 
* Are you saying that 3280 is broken?
[TF] no
* 
* My question is whether you can you validate a CA certificate
* of a partial path where you alreaduy know that you have a subCA.
[TF] We support path validation from defined roots down.
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHOFiF067311; Wed, 11 Aug 2004 10:24:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BHOFQk067310; Wed, 11 Aug 2004 10:24:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHODYY067302 for <[e-mail]>; Wed, 11 Aug 2004 10:24:14 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7BHOGN04584; Wed, 11 Aug 2004 19:24:16 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 11 Aug 2004 19:24:16 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7BHOFW24192; Wed, 11 Aug 2004 19:24:15 +0200 (MEST)
Date: Wed, 11 Aug 2004 19:24:15 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> * To which value do you intialize max_path_length of point k in 6.1.2
> * if you want to validate a CA cert that is used to signed another CA?
> * 
> [TF] SCVP supports all the inputs as defined in 6.1.1
> 

Are you saying that 3280 is broken? 

My question is whether you can you validate a CA certificate
of a partial path where you alreaduy know that you have a subCA.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHDDTR065693; Wed, 11 Aug 2004 10:13:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BHDDoG065692; Wed, 11 Aug 2004 10:13:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BHDCXd065684 for <[e-mail]>; Wed, 11 Aug 2004 10:13:12 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Aug 2004 10:13:13 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 2004 10:13:12 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 10:13:13 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 10:11:27 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Wed, 11 Aug 2004 10:13:10 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PKIX WG Agenda for 60th IETF (second try!)
thread-index: AcR/xPz7yaJyNnujQ96xhGg/OpxBhgAAN9Xg
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Aug 2004 17:11:27.0059 (UTC) FILETIME=[3CA00A30:01C47FC6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BHDCXd065687
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Wednesday, August 11, 2004 10:02 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* >
* > RFC3280, section 6.1.6 item k states
* >
* you mean 6.1.4 I guess.
* 
* > "Verify that the certificate is a CA certificate (as specified in a
* > basicConstraints extension or as verified out-of-band)."
* >
* > Therefore the server does use the Boolean in the basic constraints
* > extension to determine if the certificate is a CA or not. Therefore
use
* > of a Boolean with SCVP is in alignment with 3280.
* 
* To which value do you intialize max_path_length of point k in 6.1.2
* if you want to validate a CA cert that is used to signed another CA?
* 
[TF] SCVP supports all the inputs as defined in 6.1.1



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BH25Qx064694; Wed, 11 Aug 2004 10:02:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BH25vH064693; Wed, 11 Aug 2004 10:02:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BH23bK064686 for <[e-mail]>; Wed, 11 Aug 2004 10:02:04 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7BH26N04363; Wed, 11 Aug 2004 19:02:06 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 11 Aug 2004 19:02:06 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7BH25d24149; Wed, 11 Aug 2004 19:02:05 +0200 (MEST)
Date: Wed, 11 Aug 2004 19:02:05 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> RFC3280, section 6.1.6 item k states
> 
you mean 6.1.4 I guess.

> "Verify that the certificate is a CA certificate (as specified in a
> basicConstraints extension or as verified out-of-band)."
> 
> Therefore the server does use the Boolean in the basic constraints
> extension to determine if the certificate is a CA or not. Therefore use
> of a Boolean with SCVP is in alignment with 3280.

To which value do you intialize max_path_length of point k in 6.1.2
if you want to validate a CA cert that is used to signed another CA?




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGoWfh063769; Wed, 11 Aug 2004 09:50:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BGoWjw063768; Wed, 11 Aug 2004 09:50:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGoUfl063758 for <[e-mail]>; Wed, 11 Aug 2004 09:50:31 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7BGoXN04194; Wed, 11 Aug 2004 18:50:33 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 11 Aug 2004 18:50:33 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7BGoWZ24101; Wed, 11 Aug 2004 18:50:32 +0200 (MEST)
Date: Wed, 11 Aug 2004 18:50:32 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi Peter,
> The TSA and DPVs responses are both in the paragraph you refer to and
> both are outside the bounds of the validation algorithms defined today
> so do not constitute information useful to a relying party. So I think
> SCVP 15 conforms to RFC3379.  Wherever you define the algorithm that
> does use such values as part of the validation process you can also
> define how to return them in the response. The SVP response is
> extensible so I am confident you can do that.


The scenario is a local DPV server operating as a locally trusted
interface like in OCSP. The DPV server has the knoweldge about
which other DPV servers are to be contacted to validate the cert
in question. 

The DPV relay thus simply asks the external service (operated closely
to a CA for example), and then simply confirms the result by
telling its client that the cert is good 'because the other DPV told it',
and it includes the original DPV response.

This behaviour is IMO an essential feature for the different types
of relaying. 

it is not up to me to define these things: SCVP needs to support them
to conform wityh 3379. That's why I propose simply to add a text
with a response value containing a CMS content-type. I do not think
that this should require another document.  

 

 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGXb1d061441; Wed, 11 Aug 2004 09:33:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BGXbHB061440; Wed, 11 Aug 2004 09:33:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGXbsw061428 for <[e-mail]>; Wed, 11 Aug 2004 09:33:37 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Aug 2004 09:33:35 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 2004 09:33:34 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 09:33:34 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 09:31:53 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP remarks.
Date: Wed, 11 Aug 2004 09:33:29 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP remarks.
thread-index: AcR/lkDyta4LE8KuQXKS2t7dEMnk5QAKjK9Q
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Aug 2004 16:31:53.0719 (UTC) FILETIME=[B6011870:01C47FC0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BGXbsw061434
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
Let me repeat my previous posting which was after this mail.

[TF] Since you had not linked our discussion on the requestor field to
this section of 3379 before we have been at cross purposes. As Dennis
pointed out this field is intended for SCVP relay so the current text is
accurate for that purpose. It's a opaque blob to the server so
definition of any standard structures in this case was and is a
pointless exercise.

It is also not appropriate to reuse the requestor field because of the
case of authenticated relay. Since the client signed the request with a
certificate in this case, the request complies with 3379. We just need
to add a GeneralName field in the response for this purpose. Though
remember that with cached responses this will not be possible.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Wednesday, August 11, 2004 4:27 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: SCVP remarks.
* 
* 
* 
* I'll repeat The purpose is not only relaying.
* 
* Using an opaque blob for the server is not conformant with the text
* and spirit of 3379. I had asked for those fields during the
* discussions of 3379, and the intention was by no means to have
* opaque blob but 'potentially global identifiers'.
* 
* 3379 clearly indicates that a server may possesses some logic to
* match these identiiers with the ones used for authentication.
* 
* An opaque blob does not allow IMO to implement any useful
interoperable
* interpretation by the server which serves to identify the
participating
* entities.
* 
* > [TF] Since you had not linked our discussion on the requestor field
to
* > this section of 3379 before we have been at cross purposes. As
Dennis
* > pointed out this field is intended for SCVP relay so the current
text is
* > accurate for that purpose. It's a opaque blob to the server so
* > definition of any standard structures in this case was and is a
* > pointless exercise.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGPMRE060337; Wed, 11 Aug 2004 09:25:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BGPMVC060336; Wed, 11 Aug 2004 09:25:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGPL2k060330 for <[e-mail]>; Wed, 11 Aug 2004 09:25:21 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Aug 2004 09:25:24 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 2004 09:25:24 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 09:25:24 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 09:23:44 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Wed, 11 Aug 2004 09:25:20 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PKIX WG Agenda for 60th IETF (second try!)
thread-index: AcR/lkEr/isGC3UaSIiJmNxOZXdm5QAKJ1lA
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Aug 2004 16:23:44.0823 (UTC) FILETIME=[92997C70:01C47FBF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BGPL2k060331
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
The TSA and DPVs responses are both in the paragraph you refer to and
both are outside the bounds of the validation algorithms defined today
so do not constitute information useful to a relying party. So I think
SCVP 15 conforms to RFC3379.  Wherever you define the algorithm that
does use such values as part of the validation process you can also
define how to return them in the response. The SVP response is
extensible so I am confident you can do that.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Wednesday, August 11, 2004 4:27 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > * 1) RFC 3379 says:
* > *    The DPV request MUST allow the client to request that the
server
* > *    include in its response additional information which will allow
* > *    relying parties not trusting the DPV server to be confident
that
* > the
* > *    certificate validation has correctly been performed.  Such
* > *    information may (not necessarily exclusively) consist of a
* > *    certification path, revocation status information from
authorized
* > CRL
* > *    issuers or authorized OCSP responders, revocation status
* > information
* > *    from CRL issuers or OCSP responders trusted under the
validation
* > *    policy, time-stamp tokens from TSAs responders trusted under
the
* > *    validation policy, or a DPV response from a DPV server that is
* > *                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
* > *
* > *    trusted under the validation policy.  When the certificate is
valid
* > *    according to the validation policy, the server MUST, upon
request,
* > *    include that information in the response.  However, the server
MAY
* > *    omit that information when the certificate is invalid or when
it
* > *    cannot determine the validity.
* > *
* > *    ==> no provision (as far as I see).
* >
* > [TF] Given that SCVP requires the server ensure that the validation
* > policy has been complied with and permits all the parameters for the
* > currently defined validation algorithms to be returned ( full
* > certificate path, CRLs, OCSP responses) then I consider SCVP to be
fully
* > compliant with 3379. There are no currently defined validation
* > algorithms which have a TSA response or a DPV response from another
SCVP
* > server as an input, however if such as algorithm were to be defined,
* > then the extension mechanisms within SCVP would permit TSA responses
or
* > DPV responses to be also returned.
* >
* 
* If you read the text above the XXX above I am not talking about TSAs.
* There has been a lengthy discussion about this requirement years ago
* with at least some understaning that a DPV server can operate in a
similar
* way as an OCSP server, thus returning DPV server responses have the
* similar functionality.
* 
* I suggest to return a CMS contenttype as one of the possible return
* values.
* 
* > Also which discussing the client requesting the validation
information
* > by value in section 3.2.5 states
* >
* > "include by value in the CVResponse  every aspect of the validation
* > policy"
* >
* >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGIj9B059673; Wed, 11 Aug 2004 09:18:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BGIjXn059672; Wed, 11 Aug 2004 09:18:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BGIjEW059666 for <[e-mail]>; Wed, 11 Aug 2004 09:18:45 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Aug 2004 09:18:14 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 2004 09:18:14 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 09:18:14 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 09:16:35 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Wed, 11 Aug 2004 09:18:11 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PKIX WG Agenda for 60th IETF (second try!)
thread-index: AcR/ljqySe1z8mroRI2SlO3jz1Ej2gAJvs0w
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Aug 2004 16:16:35.0578 (UTC) FILETIME=[92BFE5A0:01C47FBE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BGIjEW059667
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,

RFC3280, section 6.1.6 item k states

"Verify that the certificate is a CA certificate (as specified in a
basicConstraints extension or as verified out-of-band)."

Therefore the server does use the Boolean in the basic constraints
extension to determine if the certificate is a CA or not. Therefore use
of a Boolean with SCVP is in alignment with 3280.

I would be happy to add an OID to allow a DPD client to request all
paths be returned so a DPD client can make more granular choices along
the lines you discuss.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Wednesday, August 11, 2004 4:27 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > * 3) In May 204 trevor wrote:
* > *
* > * > I think we can use the Cert sign bit in key usage so the is CA
bit
* > can
* > * > be removed from SCVP15
* > *
* > * which was not done.
* >
* >
* > [TF] Yes I reconsidered that position. Since the 3280 path
validation
* > algorithm uses the basic constrains extension as it's test for CA
* > certificates (3280, 6.1.4, k) and that algorithm is a mandatory
feature
* > for every SCVP validation algorithm, I concluded it was safer to use
the
* > same test rather than risk another based on key usage.
* >
* 
* The boolean isCA does not indicate at all how the server determines
* whether a cert is a CA cert. You may consider to at least reference
* what the server is supposed to perform as a test.
* 
* Since you returned to you original definition, please respond to
* my repeated suggestion to use an integer representing a minimal value
* for pathmenth in the basicconstraints instead of a boolean.
* 
* 
* > *
* > * 4) Somewhat related to this, and to the provisions to search in
DPD or
* > * validate
* > *    in DPV several types of extensions, I had proposed to
opetionally
* > * search
* > *    for the pathlength basicconstraint. if for example a client has
a
* > *    cert and a CA cert then one could use it to search only for CAs
* > that
* > *    have at least a pathlength of 1.
* > *
* >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BG6MUF058356; Wed, 11 Aug 2004 09:06:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BG6MLT058355; Wed, 11 Aug 2004 09:06:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BG6LL0058349 for <[e-mail]>; Wed, 11 Aug 2004 09:06:21 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Aug 2004 09:06:22 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 2004 09:06:22 -0700
Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 09:06:22 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 09:04:45 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Speak now or forever hold your peace...
Date: Wed, 11 Aug 2004 09:06:23 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Speak now or forever hold your peace...
thread-index: AcR/igkdj12RMdItQsmb5DbiiFaUpgAMs/7A
From: "Trevor Freeman" <[e-mail]>
To: "Faisal Maqsood" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 Aug 2004 16:04:45.0631 (UTC) FILETIME=[EB9694F0:01C47FBC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BG6ML0058350
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Faisal,
Since requestRefHash has a default value, it can be omitted from the
encoding and therefore does not result in bits on the wire.

Trevor

* -----Original Message-----
* From: Faisal Maqsood [mailto:[e-mail]]
* Sent: Wednesday, August 11, 2004 3:06 AM
* To: Trevor Freeman; [e-mail]; [e-mail]
* Subject: Re: Speak now or forever hold your peace...
* 
* Hi Trevor,
* 
* Thanks for the reply. In your sentence what is meant by encoded ? I
think
* If
* you make this element optional then this will reduce the size of SCVP
* Request.
* 
* Regards,
* Faisal
* 
* ----- Original Message -----
* From: "Trevor Freeman" <[e-mail]>
* To: "Trevor Freeman" <[e-mail]>; "Faisal
Maqsood"
* <[e-mail]>; <[e-mail]>; <[e-mail]>
* Sent: Tuesday, August 10, 2004 21:49
* Subject: RE: Speak now or forever hold your peace...
* 
* 
* > Sorry, one correction to this. requestRefHash is already defaulted
so is
* > not encoded i.e. there are no bits on the wire to save so it can say
as
* > it is.
* >
* > Trevor
* >
* > * -----Original Message-----
* > * From: [e-mail]
* > [mailto:[e-mail]]
* > * On Behalf Of Trevor Freeman
* > * Sent: Tuesday, August 10, 2004 8:39 AM
* > * To: Faisal Maqsood; [e-mail]; [e-mail]
* > * Subject: RE: Speak now or forever hold your peace...
* > *
* > *
* > *
* > * Hi Faisal,
* > * Thanks for this.
* > * Trevor
* > *
* > * * -----Original Message-----
* > * * From: [e-mail]
* > * [mailto:[e-mail]]
* > * * On Behalf Of Faisal Maqsood
* > * * Sent: Tuesday, August 10, 2004 3:51 AM
* > * * To: [e-mail]; [e-mail]
* > * * Subject: Re: Speak now or forever hold your peace...
* > * *
* > * *
* > * * Hi,
* > * *
* > * * Below are my points on SCVP-15:
* > * *
* > * * - In following structure why 'requestRefHash' is not tagged?[TF]
* > * Fixed
* > * * - Should 'IsCA' not be 'isCA'?[TF] already fixed
* > * * - Should 'SignResponse' not be 'signResponse'?[TF]  already
fixed
* > * * - Should there not be commas in tags 13 and 14?[TF]  already
fixed
* > * * - If we know default values for 'requestRefHash' and tagged 0 to
5,
* > * why we
* > * * are not making these as optional? To make them optional will
benifit
* > * for
* > * * low
* > * * network traffic and if these optional value are not inserted in
* > * request
* > * * server will automatically use default values.[TF]  fixed
* > * *
* > * * Query ::= SEQUENCE {
* > * *      queriedCerts             SEQUENCE SIZE (1..MAX) OF
* > CertReference,
* > * *      checks                   CertChecks,
* > * *      wantBack                 WantBack,
* > * *      validationAlg            ValidationAlg,
* > * *      requestRefHash           BOOLEAN DEFAULT TRUE,
* > * *      fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
* > * *      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
* > * *      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
* > * *      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
* > * *      IsCA                 [4] BOOLEAN DEFAULT FALSE,
* > * *      SignResponse         [5] BOOLEAN DEFAULT TRUE,
* > * *      serverContextInfo    [6] OCTET STRING OPTIONAL,
* > * *      validityTime         [7] GeneralizedTime OPTIONAL,
* > * *      trustAnchors         [8] TrustAnchors OPTIONAL,
* > * *      intermediateCerts    [9] CertBundle OPTIONAL,
* > * *      revInfos            [10] RevocationInfos OPTIONAL,
* > * *      keyUsage            [11] KeyUsage OPTIONAL,
* > * *      extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
* > * *      queryExtensions     [13] Extensions OPTIONAL
* > * *      producedAt          [14] GeneralizedTime OPTIONAL
* > * *      validationPolRef    [15] ValidationPolRef OPTIONAL}
* > * *
* > * * - In following structure tags are not correct for 'attrCert' and
* > * 'acRef'?[TF]  fixed
* > * *
* > * *     CertReference ::= CHOICE {
* > * *       pkc                   PKCReference,
* > * *       ac                    ACReference }
* > * *
* > * *     PKCReference ::= CHOICE {
* > * *       cert              [1] Certificate,
* > * *       pkcRef            [2] ESSCertID }
* > * *
* > * *     ACReference ::= CHOICE {
* > * *       attrCert          [1] AttributeCertificate,
* > * *       acRef             [2] ESSCertID }
* > * *
* > * * - In above structure why tag start from 1 instead of 0 in
'cert'?
* > * *
* > * * - In structure below why 'requestor' tag starts from 1 instead
of
* > * 0?[TF]  fixed
* > * *
* > * *     CVResponse ::= SEQUENCE {
* > * *       scvpVersion           INTEGER,
* > * *       policyID              INTEGER,
* > * *       producedAt            GeneralizedTime,
* > * *       responseStatus        ResponseStatus,
* > * *       requestRef            RequestReference,
* > * *       requestor         [1] OCTET STRING OPTIONAL,
* > * *       responder         [2] OCTET STRING OPTIONAL,
* > * *       replyObjects      [3] ReplyObjects OPTIONAL,
* > * *       requestNonce      [4] OCTET STRING OPTIONAL,
* > * *       serverContextInfo [5] OCTET STRING OPTIONAL,
* > * *       valPolResponse    [6] ValPolicy OPTIONAL,
* > * *       validationPolRef  [7] ValidationPolicyRef OPTIONAL
* > * *       respExtensions    [8] Extensions OPTIONAL }
* > * *
* > * * - In following structure should 'requestHash' tag not be start
from
* > 0
* > * * instead 1?[TF]  fixed
* > * *
* > * *     RequestReference ::= CHOICE {
* > * *       requestHash       [1] HashValue, -- hash of CVRequest
* > * *       fullRequest       [2] CVRequest }
* > * *
* > * * - In following structure should 'nextUpdate' tag not be start
from 0
* > * * instead 1?[TF]  fixed
* > * *
* > * *     CertReply ::= SEQUENCE {
* > * *       cert                       CertReference,
* > * *       replyStatus                ReplyStatus,
* > * *       replyValTime               GeneralizedTime,
* > * *       replyChecks                ReplyChecks,
* > * *       replyWantBacks             ReplyWantBacks,
* > * *       valAlg                     ValidationAlg,
* > * *       nextUpdate             [1] GeneralizedTime OPTIONAL,
* > * *       certReplyExtensions    [2] Extensions OPTIONAL }
* > * *
* > * * - In the following paragraph referenced section 3.2.7 should be
* > 3.2.15
* > * to
* > * * point CertBundle[TF]  fixed
* > * *
* > * *   The octet string value for the certification path used to
verify
* > * *   the certificate in the request, { id-swb 1 }, contains the
* > * *   CertBundle type.  The syntax and semantics of the CertBundle
type
* > * *   are described in section 3.2.7.
* > * *
* > * * Regards,
* > * * Faisal
* > * *
* > * * ----- Original Message -----
* > * * From: <[e-mail]>
* > * * To: <[e-mail]>
* > * * Sent: Thursday, August 05, 2004 05:06
* > * * Subject: SCVP: Speak now or forever hold your peace...
* > * *
* > * *
* > * * >
* > * * >
* > * * >
* > * * > Folks,
* > * * >
* > * * > It is time to get serious and finish up SCVP.  In the slides
* > * presented
* > * * at
* > * * our
* > * * > meeting this morning, the SCVP editors requested a "Definitive
and
* > * final
* > * * list
* > * * > of all issues from workgroup".  I believe that is a reasonable
* > * request.
* > * * Let's
* > * * > do our best to get that list documented ASAP, so that -16 can
be
* > our
* > * * *last*.
* > * * >
* > * * > I am requesting that everyone in the WG make time to review
SCVP
* > and
* > * * document
* > * * > any issues you find by Friday the 13th.  (I am not setting a
* > * deadline
* > * * for
* > * * > terminating discussion - it may take a few days to reach
consensus
* > * on
* > * * the
* > * * > issue list.  I am just trying to surface all the issues ASAP.)
* > Once
* > * the
* > * * issue
* > * * > list is stable, I am sure we can work out solutions.
* > * * >
* > * * > Please post all technical comments to the list.  Editorial
* > comments
* > * can
* > * * be
* > * * > sent to Trevor directly.  Include SCVP in the subject line
* > * regardless!
* > * * >
* > * * > Thanks,
* > * * >
* > * * > Tim Polk
* > * * >
* > *
* >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BG0kfZ057769; Wed, 11 Aug 2004 09:00:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BG0khW057768; Wed, 11 Aug 2004 09:00:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BG0jZk057760 for <[e-mail]>; Wed, 11 Aug 2004 09:00:46 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7BG0kN03394; Wed, 11 Aug 2004 18:00:46 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 11 Aug 2004 18:00:46 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7BG0jY23941; Wed, 11 Aug 2004 18:00:45 +0200 (MEST)
Date: Wed, 11 Aug 2004 18:00:45 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: SCVP: Speak now or forever hold your peace...
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At least in some countries this part of the year is a vacation period, 
I think that 10 days is not a good proposal. 

> 
> Folks,
> 
> It is time to get serious and finish up SCVP.  In the slides presented at our 
> meeting this morning, the SCVP editors requested a "Definitive and final list 
> of all issues from workgroup".  I believe that is a reasonable request.  Let's 
> do our best to get that list documented ASAP, so that -16 can be our *last*.
> 
> I am requesting that everyone in the WG make time to review SCVP and document 
> any issues you find by Friday the 13th.  (I am not setting a deadline for 
> terminating discussion - it may take a few days to reach consensus on the 
> issue list.  I am just trying to surface all the issues ASAP.)  Once the issue 
> list is stable, I am sure we can work out solutions.
> 
> Please post all technical comments to the list.  Editorial comments can be 
> sent to Trevor directly.  Include SCVP in the subject line regardless! 
> 
> Thanks,
> 
> Tim Polk  
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BFtu6B056881; Wed, 11 Aug 2004 08:55:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BFtuLe056880; Wed, 11 Aug 2004 08:55:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BFttlY056869 for <[e-mail]>; Wed, 11 Aug 2004 08:55:55 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7BFtvN03293; Wed, 11 Aug 2004 17:55:57 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 11 Aug 2004 17:55:57 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7BFtuX23902; Wed, 11 Aug 2004 17:55:56 +0200 (MEST)
Date: Wed, 11 Aug 2004 17:55:56 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Speak now or forever hold your peace...
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> > tags > 30 create most likely some problems in decoders, too.
> 
> You mean: In decoders badly hand-coded. ;)  I'm not aware of such a bug 
> with decoders generated by a compiler.

This is not a question of a bug, it is a question of whether
low level routines can supports tags > 30.

This has not much to do whether the syntax is treated by a compiler
but with the possibility of decoding larger value in low level routines
in a situation where all practical well known syntaxes do not have 
tags > 30, thus, the low level implementation of tag decoding can 
assume that you have only one octet for a tag.

I have not seen any compiler that is able to link againt a low level
decoder specific with the maximum tag length that can ever occur the
given compilation environment. 

how many compilers can handle a context tag of about 2**130

But well, we are somehow getting out of scope of this discussion.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BFnqlx055924; Wed, 11 Aug 2004 08:49:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BFnqEO055923; Wed, 11 Aug 2004 08:49:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp002.bizmail.yahoo.com (smtp002.bizmail.yahoo.com [216.136.172.126]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7BFnq15055917 for <[e-mail]>; Wed, 11 Aug 2004 08:49:52 -0700 (PDT) (envelope-from [e-mail])
Received: from unknown (HELO ieca.com) ([e-mail]@70.17.64.84 with plain) by smtp002.bizmail.yahoo.com with SMTP; 11 Aug 2004 15:49:54 -0000
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 2004 11:47:04 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], PKIX <[e-mail]>
Subject: SCVP
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!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">
(sorry if any of these are duplicates)<br>
<br>
Technical:<br>
<ol>
  <li>How are the queriedCerts, checks, and wantBack correlated?&nbsp; For
example: I send in four certs and I want a validated path back to the
root to be built, do I have to include id-stc-build-valid-pkc-path
three different times in checks?&nbsp; Ditto for the wantBack if I want the
same thing back?&nbsp; Or are we assuming all certs in querriedCerts will
want the same checks?&nbsp; If it's the 1st I think that something like "For
every CertReference in queriedCerts, a corresponding check must be
included" (in 3.2.2) - ditto for wantBack (3.2.3) - or something like
the "The 1st value in queriedCerts corresponds to the 1st value in
checks and wantBack, the 2nd to the 2nd, etc."&nbsp; If it's the later it
ought to say "Every certificate referred to in CertReference will have
the same checks and wantBacks applied" in 3.2.&nbsp; I'm not picky about the
particular words as long as you get my drift.</li>
  <li>3.2.12 should we be referencing the string prep stuff in some way?<br>
  </li>
</ol>
Editorial:<br>
<ol>
  <li>2. 3rd para replace "," at the end with "."</li>
  <li>3. 3rd para 2n sentence: "An overview of this structure is
provided below."&nbsp; Can we add something like "The definitive ASN.1 is
found in [CMS]" after "many details are not shown"?&nbsp; I know later on it
says the syntax and semantics are in [CMS] but I was hoping to see the
"definitive" part at the beginning and not the end.<br>
  </li>
  <li>3. 2nd para after authenticatedData example: add space between
profile and [PKIX-1].</li>
  <li>3. 2nd para after authenticatedData example keyusage blurb: Move
period that is after non-repudiation to end of line.<br>
  </li>
  <li>3.2.8 Any-Policy and Any-policy should be any-policy or is it
anypolicy?</li>
  <li>3.2.9 Add a space between extension and [PKIX... also add a
period after ].</li>
  <li>3.2.12.2 2nd para, remove space id-svp- and NameValAlg.<br>
  </li>
  <li>3.2.17 and 18 Add space between extension and [PKIX-1...<br>
  </li>
  <li>3.2.20 Add period to end of 2nd paragraph.</li>
  <li>3.6 Remove extra SCVP in 1st sentence.&nbsp; Also remove ".validation"
from the same sentence.</li>
  <li>4. Same as comment Ed #2.</li>
  <li>4.13 I think the apostrophe in client's shows up as&nbsp; special
character.&nbsp; Also add a period to the end of the paragraph.<br>
  </li>
  <li>4.13.2 remove ".validation" from 1st sentence.<br>
  </li>
  <li>9. Should we say that the following are in addition to the CMS
security considerations since this protocol is based on CMS?<br>
  </li>
  <li>10.1 [OpenPGP] should be removed as a normative reference since
it's not referenced anywhere in the document.</li>
</ol>
</body>
</html>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BFUkLk054023; Wed, 11 Aug 2004 08:30:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BFUj7U054021; Wed, 11 Aug 2004 08:30:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BFUhfa054009 for <[e-mail]>; Wed, 11 Aug 2004 08:30:44 -0700 (PDT) (envelope-from [e-mail])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 17:30:45 +0200
Received: from [10.193.13.101] ([10.193.13.101]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 17:30:45 +0200
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 2004 17:30:45 +0200
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom - Research & Development  Division
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Speak now or forever hold your peace...
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Aug 2004 15:30:45.0272 (UTC) FILETIME=[2B708180:01C47FB8]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester wrote:
>>   
>>=> we have the choice. We can begin by 123456 and put 999999 in the next.
>>
> 
> 
> I think that explicitly using the tags that would
> be used with AUTOMATIC tagging is not such a bad idea. 

Agree!

> tags > 30 create most likely some problems in decoders, too.

You mean: In decoders badly hand-coded. ;)  I'm not aware of such a bug 
with decoders generated by a compiler.

Olivier



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BF7ZUJ051402; Wed, 11 Aug 2004 08:07:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BF7Z9K051401; Wed, 11 Aug 2004 08:07:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk (ns3.worldcall.net.pk [203.81.192.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BF7Xo0051395 for <[e-mail]>; Wed, 11 Aug 2004 08:07:34 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.215.18]) by ns3.worldcall.net.pk (8.12.5+Sun/8.12.5) with SMTP id i7BEtZjT026684; Wed, 11 Aug 2004 20:55:35 +0600 (PKST)
Message-ID: <041001c47fb4$ab11fc60$[e-mail]>
From: "Faisal Maqsood" <[e-mail]>
To: "Francis Dupont" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Speak now or forever hold your peace... 
Date: Wed, 11 Aug 2004 20:05:30 +0500
Organization: Ascertia Ltd
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well FD ,

please see comments below:

Regards,
Faisal

==============================
----- Original Message -----
From: "Francis Dupont" <[e-mail]>
To: "Faisal Maqsood" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Wednesday, August 11, 2004 18:36
Subject: Re: Speak now or forever hold your peace...



 In your previous mail you wrote:

   1. Client put all three certificates in Query of a single SCVP request
   and for want backs client puts all his required OIDs.

=> this suggests to spread most of the Query fields to a per cert
structure... I agree, IMHO only requestRefHash and signResponse are
clearly per CVRequest.

   2. Client generates three different SCVP requests with his requirement
   as stated in above case.

=> IMHO multiple SCVP requests are better at one exception: when you'd
like to get the whole thing in one CMS message. In fact the real issue
is that ASN.1 has no reference, so can't handle easily sharing
(one can say this is another consequence of the incredible incompetence
of ASN.1 designers in computer science :-).

   I would propose the following structure.

   Query ::= SEQUENCE {
    QueriedCerts SEQUENCE SIZE (1..MAX) OF CertConfig,
    Checks     [0] CertChecks OPTIONAL,
    WantBack    [1] WantBack OPTIONAL,
    .....
       }

   CertConfig::= SEQUENCE{
    Cert  CertReference,
    Checks      [0] CertChecks OPTIONAL,
    WantBack    [1] WantBack   OPTIONAL
   }

=> you should get the .... to for CertConfig. I have a concern about
this: this gives two different ways to specify the parameters for
an unique cert.

[FM: No, By "....." I mean the remaining part of Query in draft 15 . Yes
this gives
two different ways, but let me explain how this helps:
    - Firstly for the case I mentioned above in my original email,
client
can use CertConfig optional elements i.e. checks & wantback to be
specified
for each certificate and not to use Query optional elements checks,
wantback.
    - Secondly for the case if client has multiple certificates and for
one
certificate he needs only certification path(s) while for all other
certificates client needs same other wantback, in this case client will
use
CertConfig optional elements checks, wantback only for first certificate
and
not for others but also client can use the Query optional elements
checks,
wantback to specify common wantback for other certificates (for which
client
has not used CertConfig optional elements).
By this way client has choice to control network trafic too.]

IMHO the best option is just to accept one certificate per request.
It keeps SCVP so simple (:-)! Sharing of certificates (huge structures)
is already handled by references, we need only a way to share crls,
i.e., define our own RevocationInfo reference system?

Regards

[e-mail]





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BEsIUG050243; Wed, 11 Aug 2004 07:54:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BEsISO050242; Wed, 11 Aug 2004 07:54:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BEsGoF050218 for <[e-mail]>; Wed, 11 Aug 2004 07:54:17 -0700 (PDT) (envelope-from [e-mail])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Aug 2004 16:54:15 +0200
Received: from [10.193.13.101] ([10.193.13.101]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Aug 2004 16:54:15 +0200
Message-ID: <[e-mail]>
Date: Wed, 11 Aug 2004 16:54:14 +0200
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom - Research & Development  Division
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Francis Dupont <[e-mail]>
CC: Faisal Maqsood <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Speak now or forever hold your peace...
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Aug 2004 14:54:15.0444 (UTC) FILETIME=[12334540:01C47FB3]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Francis Dupont wrote:

>  In your previous mail you wrote:
> 
>       - If we know default values for 'requestRefHash' and tagged 0 to 5, why
>    we are not making these as optional?
>    
>    => DEFAULT is similar to OPTIONAL, both are not always encoded according
>    to T-REC-X.680-200207 24.14 for instance.

24.14 deals with extension additions, but I think that your type has no 
extension marker.
The relevant subclauses are 24.10 and 24.11:
24.10	If OPTIONAL or DEFAULT are present, the corresponding value may be 
omitted from a value of the new type.
24.11	If DEFAULT occurs, the omission of a value for that type shall be 
exactly equivalent to the insertion of the value defined by "Value", 
which shall be a value notation for a value of the type defined by 
"Type" in the "NamedType" production sequence.

>        [FM: But DEFAULT is not same to OPTIONAL,
> 
> => not but they are described together in X.680.
> 
>    so it will be better to explicitly mention DEFAULT with OPTIONAL.
> 
> => I disagree and I don't understand, in the unlikely case it is legal (*),

It is illegal to have both OPTIONAL and DEFAULT applied to the same 
component of a structured type.

> what it means. (*) X.680 syntax excludes DEFAULT with OPTIONAL.
> 
>    Although tagged elements are by default OPTIONAL]
> 
> => ??? I don't think the OPTIONAL keyword is optional!

I didn't understand either what "tagged elements are by default 
OPTIONAL" means.
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BEVqJ7048458; Wed, 11 Aug 2004 07:31:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BEVq0a048457; Wed, 11 Aug 2004 07:31:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BEVoqE048449 for <[e-mail]>; Wed, 11 Aug 2004 07:31:51 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7BEVqN02043; Wed, 11 Aug 2004 16:31:52 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 11 Aug 2004 16:31:52 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7BEVoa23671; Wed, 11 Aug 2004 16:31:50 +0200 (MEST)
Date: Wed, 11 Aug 2004 16:31:50 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Speak now or forever hold your peace...
Cc: [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>    
> => we have the choice. We can begin by 123456 and put 999999 in the next.
> 

I think that explicitly using the tags that would
be used with AUTOMATIC tagging is not such a bad idea. 

tags > 30 create most likely some problems in decoders, too.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BEGo3x047397; Wed, 11 Aug 2004 07:16:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BEGoTP047396; Wed, 11 Aug 2004 07:16:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BEGmFw047384 for <[e-mail]>; Wed, 11 Aug 2004 07:16:49 -0700 (PDT) (envelope-from [e-mail])
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i7BEGhg07206; Wed, 11 Aug 2004 16:16:44 +0200
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7BEGhSj060626; Wed, 11 Aug 2004 16:16:44 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Francis Dupont <[e-mail]>
To: "Faisal Maqsood" <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Speak now or forever hold your peace... 
In-reply-to: Your message of Wed, 11 Aug 2004 19:06:48 +0500. <039501c47fac$7570dd90$[e-mail]> 
Date: Wed, 11 Aug 2004 16:16:43 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 In your previous mail you wrote:

      - If we know default values for 'requestRefHash' and tagged 0 to 5, why
   we are not making these as optional?
   
   => DEFAULT is similar to OPTIONAL, both are not always encoded according
   to T-REC-X.680-200207 24.14 for instance.
       [FM: But DEFAULT is not same to OPTIONAL,

=> not but they are described together in X.680.

   so it will be better to explicitly mention DEFAULT with OPTIONAL.

=> I disagree and I don't understand, in the unlikely case it is legal (*),
what it means. (*) X.680 syntax excludes DEFAULT with OPTIONAL.

   Although tagged elements are by default OPTIONAL]

=> ??? I don't think the OPTIONAL keyword is optional!
   
      - In above structure why tag start from 1 instead of 0 in 'cert'?
   
   => we have the choice. We can begin by 123456 and put 999999 in the next.
       [FM: Same goes for OPTIONAL? right, but it is better to follow some
   standard way so that readers can feel comfortable that they have not skipped
   or author has not skipped some thing]
   
=> this is really a matter of taste. IMHO the authors still stand well
between dictatorship and anarchy (:-).
   
Regards
  
[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BE1cd6045794; Wed, 11 Aug 2004 07:01:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BE1ca2045793; Wed, 11 Aug 2004 07:01:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk (ns3.worldcall.net.pk [203.81.192.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BE1am1045778 for <[e-mail]>; Wed, 11 Aug 2004 07:01:37 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.215.18]) by ns3.worldcall.net.pk (8.12.5+Sun/8.12.5) with SMTP id i7BDurjT021311; Wed, 11 Aug 2004 19:56:54 +0600 (PKST)
Message-ID: <039501c47fac$7570dd90$[e-mail]>
From: "Faisal Maqsood" <[e-mail]>
To: "Francis Dupont" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Speak now or forever hold your peace... 
Date: Wed, 11 Aug 2004 19:06:48 +0500
Organization: Ascertia Ltd
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well FD ,

please see comments below:

Regards,
Faisal

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

In your previous mail you wrote:

   Below are my points on SCVP-15:

   - In following structure why 'requestRefHash' is not tagged?

=> this is the first one so we don't need to tag it.
    [FM: what is logic that first one do not need to be tag?]

   - Should 'IsCA' not be 'isCA'?
   - Should 'SignResponse' not be 'signResponse'?
   - Should there not be commas in tags 13 and 14?

=> typos (I found then too).

   - If we know default values for 'requestRefHash' and tagged 0 to 5, why
we
   are not making these as optional?

=> DEFAULT is similar to OPTIONAL, both are not always encoded according
to T-REC-X.680-200207 24.14 for instance.
    [FM: But DEFAULT is not same to OPTIONAL, so it will be better to
explicitly mention DEFAULT with OPTIONAL. Although tagged elements are by
default OPTIONAL]

   - In following structure tags are not correct for 'attrCert' and 'acRef'?

       CertReference ::= CHOICE {
         pkc                   PKCReference,
         ac                    ACReference }

       PKCReference ::= CHOICE {
         cert              [1] Certificate,
         pkcRef            [2] ESSCertID }

       ACReference ::= CHOICE {
         attrCert          [1] AttributeCertificate,
         acRef             [2] ESSCertID }

=> do you mean they should be 3 and 4?
    [FM: Yes]

   - In above structure why tag start from 1 instead of 0 in 'cert'?

=> we have the choice. We can begin by 123456 and put 999999 in the next.
    [FM: Same goes for OPTIONAL? right, but it is better to follow some
standard way so that readers can feel comfortable that they have not skipped
or author has not skipped some thing]

   - In structure below why 'requestor' tag starts from 1 instead of 0?

   - In following structure should 'requestHash' tag not be start from 0
   instead 1?

   - In following structure should 'nextUpdate' tag not be start from 0
   instead 1?

=> same.

   - In the following paragraph referenced section 3.2.7 should be 3.2.15 to
   point CertBundle

=> I missed this one.

Regards

[e-mail]




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BDb2cx042428; Wed, 11 Aug 2004 06:37:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BDb200042427; Wed, 11 Aug 2004 06:37:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BDb1Gb042421 for <[e-mail]>; Wed, 11 Aug 2004 06:37:01 -0700 (PDT) (envelope-from [e-mail])
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i7BDav703062; Wed, 11 Aug 2004 15:36:57 +0200
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7BDavSj060399; Wed, 11 Aug 2004 15:36:57 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Francis Dupont <[e-mail]>
To: "Faisal Maqsood" <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Speak now or forever hold your peace... 
In-reply-to: Your message of Wed, 11 Aug 2004 16:53:17 +0500. <018701c47f99$d04eb740$[e-mail]> 
Date: Wed, 11 Aug 2004 15:36:57 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 In your previous mail you wrote:

   1. Client put all three certificates in Query of a single SCVP request
   and for want backs client puts all his required OIDs.

=> this suggests to spread most of the Query fields to a per cert
structure... I agree, IMHO only requestRefHash and signResponse are
clearly per CVRequest.

   2. Client generates three different SCVP requests with his requirement
   as stated in above case.
   
=> IMHO multiple SCVP requests are better at one exception: when you'd
like to get the whole thing in one CMS message. In fact the real issue
is that ASN.1 has no reference, so can't handle easily sharing
(one can say this is another consequence of the incredible incompetence
of ASN.1 designers in computer science :-).

   I would propose the following structure.
   
   Query ::= SEQUENCE {
    QueriedCerts SEQUENCE SIZE (1..MAX) OF CertConfig,
    Checks     [0] CertChecks OPTIONAL,
    WantBack    [1] WantBack OPTIONAL,
    .....
       }
   
   CertConfig::= SEQUENCE{
    Cert  CertReference,
    Checks      [0] CertChecks OPTIONAL,
    WantBack    [1] WantBack   OPTIONAL
   }
   
=> you should get the .... to for CertConfig. I have a concern about
this: this gives two different ways to specify the parameters for
an unique cert.
   
IMHO the best option is just to accept one certificate per request.
It keeps SCVP so simple (:-)! Sharing of certificates (huge structures)
is already handled by references, we need only a way to share crls,
i.e., define our own RevocationInfo reference system?

Regards

[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BDDLYn040628; Wed, 11 Aug 2004 06:13:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BDDLqL040627; Wed, 11 Aug 2004 06:13:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BDDKKw040614 for <[e-mail]>; Wed, 11 Aug 2004 06:13:21 -0700 (PDT) (envelope-from [e-mail])
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i7BDDCI00651; Wed, 11 Aug 2004 15:13:12 +0200
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7BDDCSj060284; Wed, 11 Aug 2004 15:13:12 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Francis Dupont <[e-mail]>
To: "Faisal Maqsood" <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Speak now or forever hold your peace... 
In-reply-to: Your message of Tue, 10 Aug 2004 15:51:25 +0500. <007a01c47ec7$ffa6ce10$[e-mail]> 
Date: Wed, 11 Aug 2004 15:13:12 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 In your previous mail you wrote:

   Below are my points on SCVP-15:
   
   - In following structure why 'requestRefHash' is not tagged?

=> this is the first one so we don't need to tag it.

   - Should 'IsCA' not be 'isCA'?
   - Should 'SignResponse' not be 'signResponse'?
   - Should there not be commas in tags 13 and 14?

=> typos (I found then too).

   - If we know default values for 'requestRefHash' and tagged 0 to 5, why we
   are not making these as optional?

=> DEFAULT is similar to OPTIONAL, both are not always encoded according
to T-REC-X.680-200207 24.14 for instance.

   - In following structure tags are not correct for 'attrCert' and 'acRef'?
   
       CertReference ::= CHOICE {
         pkc                   PKCReference,
         ac                    ACReference }
   
       PKCReference ::= CHOICE {
         cert              [1] Certificate,
         pkcRef            [2] ESSCertID }
   
       ACReference ::= CHOICE {
         attrCert          [1] AttributeCertificate,
         acRef             [2] ESSCertID }
   
=> do you mean they should be 3 and 4?

   - In above structure why tag start from 1 instead of 0 in 'cert'?
   
=> we have the choice. We can begin by 123456 and put 999999 in the next.

   - In structure below why 'requestor' tag starts from 1 instead of 0?
   
   - In following structure should 'requestHash' tag not be start from 0
   instead 1?
   
   - In following structure should 'nextUpdate' tag not be start from 0
   instead 1?
   
=> same.
   
   - In the following paragraph referenced section 3.2.7 should be 3.2.15 to
   point CertBundle
   
=> I missed this one.

Regards

[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BCeq83028971; Wed, 11 Aug 2004 05:40:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BCeqfJ028970; Wed, 11 Aug 2004 05:40:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BCepRq028957 for <[e-mail]>; Wed, 11 Aug 2004 05:40:51 -0700 (PDT) (envelope-from [e-mail])
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i7BCehk29846; Wed, 11 Aug 2004 14:40:43 +0200
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7BCehSj059439; Wed, 11 Aug 2004 14:40:43 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Francis Dupont <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Re: SCVP: Speak now or forever hold your peace... 
In-reply-to: Your message of Wed, 04 Aug 2004 20:06:11 EDT. <[e-mail]> 
Date: Wed, 11 Aug 2004 14:40:43 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are editorial issues:

 - in 2 "request- response" -> "request-response"
  "validation request," -> "validation request."
 - in 3 SCVPRequest -> CVRequest (IMHO better than SCVP request)
   "request i.e." -> "request, i.e.,"
 - in 3.2 and in every places the fields are listed: update the
   list(s) in order to follow the current definition!
 - in 3.2.9 I am not sure that to use a BOOLEAN with a DEFAULT is
   a correct way to handle a field with 3 different possible values,
   i.e., can the DEFAULT override the "missing" value? BTW it works
   with OpenSSL but OpenSSL ASN.1 is not as standard as it should be.
 - in 3.2.9 the first sentence doesn't parse. IMHO there is an extra
   "certificate" word (last one).
 - in 3.2.10 I have two concerns:
   * the field should not be in query because it is about the response
     so the whole request. For instance what does happen formally when
     the field is set to different values in different queries of the
     same request.
   * not only DPD and DPV abbrevs must be expanded but I strongly suggest
     a reference to the RFC ([RQMTS])
 - in 3.3.12.1 "an valAlgId" -> "a valAlgId"
 - in 3.2.18 I suggest to contact the pki4ipsec WG where the EKU is
   an hot topic in order to know what id-kp to use (including none).
 - in 3.2.21 please specify what error to return (ReplyStatus 6?,
   in this case fix the error definition, i.e., add URI to OID).
 - in 3.6 and 4.13.2 I can't parse "PKIX-1.validation"
 - in 4 where is the certificate field in AuthenticatedData?
 - in 4.5 first paragraph: the hash doesn't cover encapsulated content
   and authenticated attributes, but only CVRequest. I suggest to remove
   the two statements refering to CMS.
 - in 4.8.4 we must explain the differences between Unknown and Unavailable
   or at least put the reference to the document where it is explained.
 - in 4.13 not ASCII betwen client and "s knowledge"
 - in 4.13 missing final "."
 - in 4.13.1 "a implementation" -> "an implementation"
 - in 5 and 6 please use either "Server" and "Validation" in titles.
 - in 6 polResponse -> PolResponse
 - in 6.8 "request i.e." -> "request, i.e.,",
   "requestors nonce" -> "requestor nonce" (or 's)
 - in 9 serverContextInformation -> serverContextInfo

Regards

[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBp898009948; Wed, 11 Aug 2004 04:51:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BBp8oJ009947; Wed, 11 Aug 2004 04:51:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBp6L1009925 for <[e-mail]>; Wed, 11 Aug 2004 04:51:07 -0700 (PDT) (envelope-from [e-mail])
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i7BBoPk23361; Wed, 11 Aug 2004 13:50:35 +0200
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7BBmsSj059325; Wed, 11 Aug 2004 13:49:14 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Francis Dupont <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Re: SCVP: Speak now or forever hold your peace... 
In-reply-to: Your message of Wed, 04 Aug 2004 20:06:11 EDT. <[e-mail]> 
Date: Wed, 11 Aug 2004 13:48:54 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are ASN.1 & co typos and suggestions: first letter of a field in
lower case, of a type in upper case, plural for [wW]antBack.
 - 3.2 title Query -> query
 - in 3.2: [wW]antBack -> [wW]antBacks, IsCA -> isCA,
   SignResponse -> signResponse
   missing "," after queryExtensions and producedAt (same in 8)
 - in 3.2.3, including the title, [wW]antBack -> [wW]antBacks
 - put 3.2.12 before 3.2.4 (to follow the field order)
 - in 3.2.12.2 KeyPurposedId -> keyPurposedId (in definition and text),
   ValidationNames -> validationNames
 - in 3.2.16 riType -> reType, riValue -> reValue
 - in 3.3 and 4.6 title Requestor -> requestor
 - in 4 id-ct-scvp-psResponse -> id-ct-scvp-certValResponse (twice)
 - in 4 and 8, missing "," after validationPolRef
 - in 4.5.2 text PSRequest -> CVRequest
 - in 4.8.5, including the title, [rR]eplyWantBack -> [rR]eplyWantBacks
   (note this is *not* a suggestion, cf 4.8 where are the plurals
    and there is a ReplyWantBack type too: caution!)
 - in 4.11 IsCA -> isCA
 - in 4.11 and 8 trustAnchors should be OPTIONAL (because in the second usage,
   PolResponse, there already is a trustAnchors field).
 - in 6 and in 6.2, including title, DefaultPolicyID -> defaultPolicyID
 - in 6.7 AuthPolRefBy{OID,URI} -> authPolRefBy{OID,URI}
 - in 8 (extra typos):
   * Query: valalidationAlg -> validationAlg
            keyusage -> keyUsage
 - in B application/scvp-{request,response} ->
        application/cv-{request,response}

Regards

[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBm3Pw009025; Wed, 11 Aug 2004 04:48:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BBm3gM009024; Wed, 11 Aug 2004 04:48:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk (ns3.worldcall.net.pk [203.81.192.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBm14k008968 for <[e-mail]>; Wed, 11 Aug 2004 04:48:02 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.215.18]) by ns3.worldcall.net.pk (8.12.5+Sun/8.12.5) with SMTP id i7BBhMjT027895; Wed, 11 Aug 2004 17:43:25 +0600 (PKST)
Message-ID: <018701c47f99$d04eb740$[e-mail]>
From: "Faisal Maqsood" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Speak now or forever hold your peace...
Date: Wed, 11 Aug 2004 16:53:17 +0500
Organization: Ascertia Ltd
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Sorry for the long email but it is important.

Let's imagine of an SCVP client which puts three certificates in an SCVP
request message and in the reply it wants:
- only certification path(s) for the first certificate and
- only validated path for second certificate and
- only revocation status and OCSP/CRL used for third certificate.


I think to do this client has two options:

1. Client put all three certificates in Query of a single SCVP request
and for want backs client puts all his required OIDs.
2. Client generates three different SCVP requests with his requirement
as stated in above case.

If client uses method 1, it will make burden on SCVP Server (In this
case server has to collect all the information as stated by the want
backs OIDs for all the certificates)

If client uses method 2, it makes burden on Client (In this case the
client has to set different configs for each different request)

Note: This is just an example, there may be more complex use cases like
when involving ESSCertIDs, attribute certificates etc in the
combination.

Regarding this confusion/restriction in the protocol, I already sent an
email to the group list with subject "SCVP Structure Suggestions" but
may be subject was not good or what so ever, I did not get any response
of that email.

Now with this thread call, I again request to consider these cases
before new release.

>>>>> Relevant Suggestion Again >>>>>
In the CVRequest->Query one can specify Checks and WantBack.

I believe the Request ASNStructure should be similar to the strategy
used in the CVResponse->CertReply i.e CertChecks and WantBack should
also be present along with each certificate being validated in the
request message.

I would propose the following structure.

Query ::= SEQUENCE {
 QueriedCerts SEQUENCE SIZE (1..MAX) OF CertConfig,
 Checks     [0] CertChecks OPTIONAL,
 WantBack    [1] WantBack OPTIONAL,
 .....
    }

CertConfig::= SEQUENCE{
 Cert  CertReference,
 Checks      [0] CertChecks OPTIONAL,
 WantBack    [1] WantBack   OPTIONAL
}


Note: by placing CertChecks and WantBack according to above has
following benefits:

- User can define WantBack, CertChecks for each Certificate separately
providing greater flexibility. The CVResponse->CertReply ASN structure
already supports seperate WantBack, CertChecks for each Certificate.

-  WantBack, CertChecks inside CVRequest->Query ASN Structure should
remain to provide default settings but would be OPTIONAL. If in
CertConfig one does not provide WantBack and CertChecks then these
default values (CVRequest->Query->WantBack,
CVRequest->Query->CertChecks) MUST be present and used.

- Benefit of providing Checks and WantBack inside Query would be to
allow some or all of the Cert inside CertConfig to use default Checks +
WantBack settings thus reducing CVRequest size and thus reduces network
load.
<<<<<

Regards,
Faisal


----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>
Sent: Thursday, August 05, 2004 05:06
Subject: SCVP: Speak now or forever hold your peace...


>
>
>
> Folks,
>
> It is time to get serious and finish up SCVP.  In the slides presented at
our
> meeting this morning, the SCVP editors requested a "Definitive and final
list
> of all issues from workgroup".  I believe that is a reasonable request.
Let's
> do our best to get that list documented ASAP, so that -16 can be our
*last*.
>
> I am requesting that everyone in the WG make time to review SCVP and
document
> any issues you find by Friday the 13th.  (I am not setting a deadline for
> terminating discussion - it may take a few days to reach consensus on the
> issue list.  I am just trying to surface all the issues ASAP.)  Once the
issue
> list is stable, I am sure we can work out solutions.
>
> Please post all technical comments to the list.  Editorial comments can be
> sent to Trevor directly.  Include SCVP in the subject line regardless!
>
> Thanks,
>
> Tim Polk
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBYDep004131; Wed, 11 Aug 2004 04:34:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BBYDHE004129; Wed, 11 Aug 2004 04:34:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBYBBe004113 for <[e-mail]>; Wed, 11 Aug 2004 04:34:12 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7BBYCN29417; Wed, 11 Aug 2004 13:34:12 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 11 Aug 2004 13:34:12 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7BBYCQ23171; Wed, 11 Aug 2004 13:34:12 +0200 (MEST)
Date: Wed, 11 Aug 2004 13:34:12 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: SCVP remarks.
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry for the bad subject in the previous mail.

> * 1) RFC 3379 says:
> *    The DPV request MUST allow the client to request that the server
> *    include in its response additional information which will allow
> *    relying parties not trusting the DPV server to be confident that
> the
> *    certificate validation has correctly been performed.  Such
> *    information may (not necessarily exclusively) consist of a
> *    certification path, revocation status information from authorized
> CRL
> *    issuers or authorized OCSP responders, revocation status
> information
> *    from CRL issuers or OCSP responders trusted under the validation
> *    policy, time-stamp tokens from TSAs responders trusted under the
> *    validation policy, or a DPV response from a DPV server that is
> *                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> * 
> *    trusted under the validation policy.  When the certificate is valid
> *    according to the validation policy, the server MUST, upon request,
> *    include that information in the response.  However, the server MAY
> *    omit that information when the certificate is invalid or when it
> *    cannot determine the validity.
> * 
> *    ==> no provision (as far as I see).
> 
> [TF] Given that SCVP requires the server ensure that the validation
> policy has been complied with and permits all the parameters for the
> currently defined validation algorithms to be returned ( full
> certificate path, CRLs, OCSP responses) then I consider SCVP to be fully
> compliant with 3379. There are no currently defined validation
> algorithms which have a TSA response or a DPV response from another SCVP
> server as an input, however if such as algorithm were to be defined,
> then the extension mechanisms within SCVP would permit TSA responses or
> DPV responses to be also returned. 
> 

If you read the text above the XXX above I am not talking about TSAs.
There has been a lengthy discussion about this requirement years ago
with at least some understaning that a DPV server can operate in a similar
way as an OCSP server, thus returning DPV server responses have the
similar functionality. 

I suggest to return a CMS contenttype as one of the possible return values.

> Also which discussing the client requesting the validation information
> by value in section 3.2.5 states
> 
> "include by value in the CVResponse  every aspect of the validation
> policy"
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBXpMF004007; Wed, 11 Aug 2004 04:33:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BBXpvl004006; Wed, 11 Aug 2004 04:33:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBXofN003989 for <[e-mail]>; Wed, 11 Aug 2004 04:33:50 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7BBXpN29401; Wed, 11 Aug 2004 13:33:51 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 11 Aug 2004 13:33:51 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7BBXoe23159; Wed, 11 Aug 2004 13:33:50 +0200 (MEST)
Date: Wed, 11 Aug 2004 13:33:50 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: SCVP remarks.
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry for the bad subject in the previous mail.

> * 3) In May 204 trevor wrote:
> * 
> * > I think we can use the Cert sign bit in key usage so the is CA bit
> can
> * > be removed from SCVP15
> * 
> * which was not done.
> 
> 
> [TF] Yes I reconsidered that position. Since the 3280 path validation
> algorithm uses the basic constrains extension as it's test for CA
> certificates (3280, 6.1.4, k) and that algorithm is a mandatory feature
> for every SCVP validation algorithm, I concluded it was safer to use the
> same test rather than risk another based on key usage.
> 

The boolean isCA does not indicate at all how the server determines
whether a cert is a CA cert. You may consider to at least reference 
what the server is supposed to perform as a test.  

Since you returned to you original definition, please respond to
my repeated suggestion to use an integer representing a minimal value
for pathmenth in the basicconstraints instead of a boolean.   


> * 
> * 4) Somewhat related to this, and to the provisions to search in DPD or
> * validate
> *    in DPV several types of extensions, I had proposed to opetionally
> * search
> *    for the pathlength basicconstraint. if for example a client has a
> *    cert and a CA cert then one could use it to search only for CAs
> that
> *    have at least a pathlength of 1.
> * 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBRIGR001749; Wed, 11 Aug 2004 04:27:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BBRIrT001748; Wed, 11 Aug 2004 04:27:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBRHwF001733 for <[e-mail]>; Wed, 11 Aug 2004 04:27:17 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7BBRHN29289; Wed, 11 Aug 2004 13:27:17 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 11 Aug 2004 13:27:17 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7BBRHv23128; Wed, 11 Aug 2004 13:27:17 +0200 (MEST)
Date: Wed, 11 Aug 2004 13:27:17 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> * 1) RFC 3379 says:
> *    The DPV request MUST allow the client to request that the server
> *    include in its response additional information which will allow
> *    relying parties not trusting the DPV server to be confident that
> the
> *    certificate validation has correctly been performed.  Such
> *    information may (not necessarily exclusively) consist of a
> *    certification path, revocation status information from authorized
> CRL
> *    issuers or authorized OCSP responders, revocation status
> information
> *    from CRL issuers or OCSP responders trusted under the validation
> *    policy, time-stamp tokens from TSAs responders trusted under the
> *    validation policy, or a DPV response from a DPV server that is
> *                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> * 
> *    trusted under the validation policy.  When the certificate is valid
> *    according to the validation policy, the server MUST, upon request,
> *    include that information in the response.  However, the server MAY
> *    omit that information when the certificate is invalid or when it
> *    cannot determine the validity.
> * 
> *    ==> no provision (as far as I see).
> 
> [TF] Given that SCVP requires the server ensure that the validation
> policy has been complied with and permits all the parameters for the
> currently defined validation algorithms to be returned ( full
> certificate path, CRLs, OCSP responses) then I consider SCVP to be fully
> compliant with 3379. There are no currently defined validation
> algorithms which have a TSA response or a DPV response from another SCVP
> server as an input, however if such as algorithm were to be defined,
> then the extension mechanisms within SCVP would permit TSA responses or
> DPV responses to be also returned. 
> 

If you read the text above the XXX above I am not talking about TSAs.
There has been a lengthy discussion about this requirement years ago
with at least some understaning that a DPV server can operate in a similar
way as an OCSP server, thus returning DPV server responses have the
similar functionality. 

I suggest to return a CMS contenttype as one of the possible return values.

> Also which discussing the client requesting the validation information
> by value in section 3.2.5 states
> 
> "include by value in the CVResponse  every aspect of the validation
> policy"
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBRDMX001710; Wed, 11 Aug 2004 04:27:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BBRDHJ001708; Wed, 11 Aug 2004 04:27:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBRBba001646 for <[e-mail]>; Wed, 11 Aug 2004 04:27:12 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7BBR5N29275; Wed, 11 Aug 2004 13:27:05 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 11 Aug 2004 13:27:05 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7BBR4Q23122; Wed, 11 Aug 2004 13:27:04 +0200 (MEST)
Date: Wed, 11 Aug 2004 13:27:04 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: SCVP remarks.
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'll repeat The purpose is not only relaying.

Using an opaque blob for the server is not conformant with the text
and spirit of 3379. I had asked for those fields during the
discussions of 3379, and the intention was by no means to have
opaque blob but 'potentially global identifiers'. 

3379 clearly indicates that a server may possesses some logic to 
match these identiiers with the ones used for authentication. 

An opaque blob does not allow IMO to implement any useful interoperable 
interpretation by the server which serves to identify the participating
entities. 

> [TF] Since you had not linked our discussion on the requestor field to
> this section of 3379 before we have been at cross purposes. As Dennis
> pointed out this field is intended for SCVP relay so the current text is
> accurate for that purpose. It's a opaque blob to the server so
> definition of any standard structures in this case was and is a
> pointless exercise.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBRDJq001711; Wed, 11 Aug 2004 04:27:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BBRD7i001703; Wed, 11 Aug 2004 04:27:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BBRBUn001673 for <[e-mail]>; Wed, 11 Aug 2004 04:27:12 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i7BBRAN29282; Wed, 11 Aug 2004 13:27:10 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 11 Aug 2004 13:27:10 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i7BBR9N23125; Wed, 11 Aug 2004 13:27:09 +0200 (MEST)
Date: Wed, 11 Aug 2004 13:27:09 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> * 3) In May 204 trevor wrote:
> * 
> * > I think we can use the Cert sign bit in key usage so the is CA bit
> can
> * > be removed from SCVP15
> * 
> * which was not done.
> 
> 
> [TF] Yes I reconsidered that position. Since the 3280 path validation
> algorithm uses the basic constrains extension as it's test for CA
> certificates (3280, 6.1.4, k) and that algorithm is a mandatory feature
> for every SCVP validation algorithm, I concluded it was safer to use the
> same test rather than risk another based on key usage.
> 

The boolean isCA does not indicate at all how the server determines
whether a cert is a CA cert. You may consider to at least reference 
what the server is supposed to perform as a test.  

Since you returned to you original definition, please respond to
my repeated suggestion to use an integer representing a minimal value
for pathmenth in the basicconstraints instead of a boolean.   


> * 
> * 4) Somewhat related to this, and to the provisions to search in DPD or
> * validate
> *    in DPV several types of extensions, I had proposed to opetionally
> * search
> *    for the pathlength basicconstraint. if for example a client has a
> *    cert and a CA cert then one could use it to search only for CAs
> that
> *    have at least a pathlength of 1.
> * 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BAGKeI076844; Wed, 11 Aug 2004 03:16:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BAGKBT076843; Wed, 11 Aug 2004 03:16:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BAGJAU076795 for <[e-mail]>; Wed, 11 Aug 2004 03:16:20 -0700 (PDT) (envelope-from [e-mail])
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i7BAGE312400; Wed, 11 Aug 2004 12:16:14 +0200
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7BAGESj059161; Wed, 11 Aug 2004 12:16:14 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Francis Dupont <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Re: SCVP: Speak now or forever hold your peace... 
In-reply-to: Your message of Wed, 04 Aug 2004 20:06:11 EDT. <[e-mail]> 
Date: Wed, 11 Aug 2004 12:16:14 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are the ASN.1 bugs:
 - CertReference is an ambiguous CHOICE. In a previous version
   one tried to solve the ambiguity by changing the ACReference tags
   to 3 and 4 (I don't know if this is really allowed or recognized
   by compilers, of course it works but as I'd like to get the reference
   stuff a bit extended perhaps it is better to tag the CertReference itself).
 - responseStatus 50 is missing in 4.4
 - change the fullPolRequestUnsuported into fullPolResponseUnsuported in 4.4
   and 8
 - the cert field in CertReply is CertReference in 4.8 and ReplyCertificate
   in 8. I prefer the 8 (and previous draft) version because it is a
   simple way to enforce the return of the whole certificate. There are
   many ways to fix this:
   - just fix 8
   - same but add a want back to get the certificate itself (note that with
     IKE the certificate itself is useful only if the name validation
     algorithm doesn't work, and in the other case the public key is
     enough).
   - just fix 8 and adding in 4.8.1 that the whole certificate is mandatory
   - go back to previous draft, i.e., fix 4.8 and 4.8.1
   (note: I prefer the second solution (and get the validation algorithm
    error issue fixed!))
 - change the valAlg of CertReply (4.8 and 8) into validationAlg
 - fix the name of Pol{icies}Response in 5
 - add the i to validationPolices (to get validationPolicies) in 6 and
   add a subsection describing it between 6.5 and 6.6

Regards

[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BA0eI6070694; Wed, 11 Aug 2004 03:00:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7BA0e1D070693; Wed, 11 Aug 2004 03:00:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk (ns3.worldcall.net.pk [203.81.192.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BA0cvC070672 for <[e-mail]>; Wed, 11 Aug 2004 03:00:39 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.215.18]) by ns3.worldcall.net.pk (8.12.5+Sun/8.12.5) with SMTP id i7B9u2jT017509; Wed, 11 Aug 2004 15:56:03 +0600 (PKST)
Message-ID: <005801c47f8a$cf97c120$[e-mail]>
From: "Faisal Maqsood" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Speak now or forever hold your peace...
Date: Wed, 11 Aug 2004 15:05:56 +0500
Organization: Ascertia Ltd
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Trevor,

Thanks for the reply. In your sentence what is meant by encoded ? I think If
you make this element optional then this will reduce the size of SCVP
Request.

Regards,
Faisal

----- Original Message -----
From: "Trevor Freeman" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>; "Faisal Maqsood"
<[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Tuesday, August 10, 2004 21:49
Subject: RE: Speak now or forever hold your peace...


> Sorry, one correction to this. requestRefHash is already defaulted so is
> not encoded i.e. there are no bits on the wire to save so it can say as
> it is.
>
> Trevor
>
> * -----Original Message-----
> * From: [e-mail]
> [mailto:[e-mail]]
> * On Behalf Of Trevor Freeman
> * Sent: Tuesday, August 10, 2004 8:39 AM
> * To: Faisal Maqsood; [e-mail]; [e-mail]
> * Subject: RE: Speak now or forever hold your peace...
> *
> *
> *
> * Hi Faisal,
> * Thanks for this.
> * Trevor
> *
> * * -----Original Message-----
> * * From: [e-mail]
> * [mailto:[e-mail]]
> * * On Behalf Of Faisal Maqsood
> * * Sent: Tuesday, August 10, 2004 3:51 AM
> * * To: [e-mail]; [e-mail]
> * * Subject: Re: Speak now or forever hold your peace...
> * *
> * *
> * * Hi,
> * *
> * * Below are my points on SCVP-15:
> * *
> * * - In following structure why 'requestRefHash' is not tagged?[TF]
> * Fixed
> * * - Should 'IsCA' not be 'isCA'?[TF] already fixed
> * * - Should 'SignResponse' not be 'signResponse'?[TF]  already fixed
> * * - Should there not be commas in tags 13 and 14?[TF]  already fixed
> * * - If we know default values for 'requestRefHash' and tagged 0 to 5,
> * why we
> * * are not making these as optional? To make them optional will benifit
> * for
> * * low
> * * network traffic and if these optional value are not inserted in
> * request
> * * server will automatically use default values.[TF]  fixed
> * *
> * * Query ::= SEQUENCE {
> * *      queriedCerts             SEQUENCE SIZE (1..MAX) OF
> CertReference,
> * *      checks                   CertChecks,
> * *      wantBack                 WantBack,
> * *      validationAlg            ValidationAlg,
> * *      requestRefHash           BOOLEAN DEFAULT TRUE,
> * *      fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
> * *      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
> * *      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
> * *      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
> * *      IsCA                 [4] BOOLEAN DEFAULT FALSE,
> * *      SignResponse         [5] BOOLEAN DEFAULT TRUE,
> * *      serverContextInfo    [6] OCTET STRING OPTIONAL,
> * *      validityTime         [7] GeneralizedTime OPTIONAL,
> * *      trustAnchors         [8] TrustAnchors OPTIONAL,
> * *      intermediateCerts    [9] CertBundle OPTIONAL,
> * *      revInfos            [10] RevocationInfos OPTIONAL,
> * *      keyUsage            [11] KeyUsage OPTIONAL,
> * *      extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
> * *      queryExtensions     [13] Extensions OPTIONAL
> * *      producedAt          [14] GeneralizedTime OPTIONAL
> * *      validationPolRef    [15] ValidationPolRef OPTIONAL}
> * *
> * * - In following structure tags are not correct for 'attrCert' and
> * 'acRef'?[TF]  fixed
> * *
> * *     CertReference ::= CHOICE {
> * *       pkc                   PKCReference,
> * *       ac                    ACReference }
> * *
> * *     PKCReference ::= CHOICE {
> * *       cert              [1] Certificate,
> * *       pkcRef            [2] ESSCertID }
> * *
> * *     ACReference ::= CHOICE {
> * *       attrCert          [1] AttributeCertificate,
> * *       acRef             [2] ESSCertID }
> * *
> * * - In above structure why tag start from 1 instead of 0 in 'cert'?
> * *
> * * - In structure below why 'requestor' tag starts from 1 instead of
> * 0?[TF]  fixed
> * *
> * *     CVResponse ::= SEQUENCE {
> * *       scvpVersion           INTEGER,
> * *       policyID              INTEGER,
> * *       producedAt            GeneralizedTime,
> * *       responseStatus        ResponseStatus,
> * *       requestRef            RequestReference,
> * *       requestor         [1] OCTET STRING OPTIONAL,
> * *       responder         [2] OCTET STRING OPTIONAL,
> * *       replyObjects      [3] ReplyObjects OPTIONAL,
> * *       requestNonce      [4] OCTET STRING OPTIONAL,
> * *       serverContextInfo [5] OCTET STRING OPTIONAL,
> * *       valPolResponse    [6] ValPolicy OPTIONAL,
> * *       validationPolRef  [7] ValidationPolicyRef OPTIONAL
> * *       respExtensions    [8] Extensions OPTIONAL }
> * *
> * * - In following structure should 'requestHash' tag not be start from
> 0
> * * instead 1?[TF]  fixed
> * *
> * *     RequestReference ::= CHOICE {
> * *       requestHash       [1] HashValue, -- hash of CVRequest
> * *       fullRequest       [2] CVRequest }
> * *
> * * - In following structure should 'nextUpdate' tag not be start from 0
> * * instead 1?[TF]  fixed
> * *
> * *     CertReply ::= SEQUENCE {
> * *       cert                       CertReference,
> * *       replyStatus                ReplyStatus,
> * *       replyValTime               GeneralizedTime,
> * *       replyChecks                ReplyChecks,
> * *       replyWantBacks             ReplyWantBacks,
> * *       valAlg                     ValidationAlg,
> * *       nextUpdate             [1] GeneralizedTime OPTIONAL,
> * *       certReplyExtensions    [2] Extensions OPTIONAL }
> * *
> * * - In the following paragraph referenced section 3.2.7 should be
> 3.2.15
> * to
> * * point CertBundle[TF]  fixed
> * *
> * *   The octet string value for the certification path used to verify
> * *   the certificate in the request, { id-swb 1 }, contains the
> * *   CertBundle type.  The syntax and semantics of the CertBundle type
> * *   are described in section 3.2.7.
> * *
> * * Regards,
> * * Faisal
> * *
> * * ----- Original Message -----
> * * From: <[e-mail]>
> * * To: <[e-mail]>
> * * Sent: Thursday, August 05, 2004 05:06
> * * Subject: SCVP: Speak now or forever hold your peace...
> * *
> * *
> * * >
> * * >
> * * >
> * * > Folks,
> * * >
> * * > It is time to get serious and finish up SCVP.  In the slides
> * presented
> * * at
> * * our
> * * > meeting this morning, the SCVP editors requested a "Definitive and
> * final
> * * list
> * * > of all issues from workgroup".  I believe that is a reasonable
> * request.
> * * Let's
> * * > do our best to get that list documented ASAP, so that -16 can be
> our
> * * *last*.
> * * >
> * * > I am requesting that everyone in the WG make time to review SCVP
> and
> * * document
> * * > any issues you find by Friday the 13th.  (I am not setting a
> * deadline
> * * for
> * * > terminating discussion - it may take a few days to reach consensus
> * on
> * * the
> * * > issue list.  I am just trying to surface all the issues ASAP.)
> Once
> * the
> * * issue
> * * > list is stable, I am sure we can work out solutions.
> * * >
> * * > Please post all technical comments to the list.  Editorial
> comments
> * can
> * * be
> * * > sent to Trevor directly.  Include SCVP in the subject line
> * regardless!
> * * >
> * * > Thanks,
> * * >
> * * > Tim Polk
> * * >
> *
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B9qIxX067894; Wed, 11 Aug 2004 02:52:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7B9qI8A067893; Wed, 11 Aug 2004 02:52:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B9qGxB067822 for <[e-mail]>; Wed, 11 Aug 2004 02:52:17 -0700 (PDT) (envelope-from [e-mail])
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i7B9ps309938; Wed, 11 Aug 2004 11:51:54 +0200
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i7B9prSj059090; Wed, 11 Aug 2004 11:51:54 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Francis Dupont <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Re: SCVP: Speak now or forever hold your peace... 
In-reply-to: Your message of Wed, 04 Aug 2004 20:06:11 EDT. <[e-mail]> 
Date: Wed, 11 Aug 2004 11:51:53 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have many comments about the SCVP draft 15: in its current case
IMHO it should not be sent to the RFC editor. I've tried to classify
comments into major problems, ASN.1 problems and editorial problems.
Here are the major problems (other issues will be next messages):
 - IMHO we *really* need an explanation about the validation policy
   and algorithm terms. Currently this is spread between lines among
   the whole document.
 - there is no hint about how to return validation algorithm errors,
   two examples:
   * what happens when isCA is set in a query and the entity type of
     the certificate is not the right one? One can believe the status
     (want back 3) should be set to invalid but a more detailed report
     should be fine and this doesn't answer to the next point.
   * how to use the name validation algorithm errors? They are defined
     but there is no place to put them in response/reply.
 - the signature stuff is completely misleading. I believe there are two
   usage modes:
   * SCVP over HTTP/HTTPS where only raw requests/responses (i.e.,
     CVRequest/CVResponse/... in DER) are sent without any embedded
     signature or MAC.
   * SCVP over CMS where SignedData and AuthenticatedData can bind
     a signature or MAC to encapsulated requests/responses.
   All discussions about signature, for instance the signResponse stuff,
   are about the second mode only.
 - in the HTTP/HTTPS mode I can't see any benefit to validate more than
   one certificate per exchange. In order to keep SCVP simple we can add
   this as an implementation hint, can't we?
 - I'd like to use SCVP in order to handle certificate validation in
   IKE, including the new Hash and URL stuff of IKEv2. But this doesn't
   work with ESSCertID because it uses an optional IssuerSerial in place
   of the URL. I'd like to get an extended way to give a pointer to
   a certificate in addition to its SHA-1 hash.

Regards

[e-mail]

   



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AGnF99045510; Tue, 10 Aug 2004 09:49:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AGnFiS045509; Tue, 10 Aug 2004 09:49:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AGnENX045503 for <[e-mail]>; Tue, 10 Aug 2004 09:49:14 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 10 Aug 2004 09:49:15 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Aug 2004 09:49:17 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Aug 2004 09:49:17 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Aug 2004 09:49:14 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Speak now or forever hold your peace...
Date: Tue, 10 Aug 2004 09:49:13 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Speak now or forever hold your peace...
thread-index: AcR+zbt3zMS/xFoiSO+DI3QEsqUSvwAIVmbgAAKiwbA=
From: "Trevor Freeman" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, "Faisal Maqsood" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 10 Aug 2004 16:49:14.0907 (UTC) FILETIME=[F83006B0:01C47EF9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7AGnENX045504
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry, one correction to this. requestRefHash is already defaulted so is
not encoded i.e. there are no bits on the wire to save so it can say as
it is.

Trevor

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Trevor Freeman
* Sent: Tuesday, August 10, 2004 8:39 AM
* To: Faisal Maqsood; [e-mail]; [e-mail]
* Subject: RE: Speak now or forever hold your peace...
* 
* 
* 
* Hi Faisal,
* Thanks for this.
* Trevor
* 
* * -----Original Message-----
* * From: [e-mail]
* [mailto:[e-mail]]
* * On Behalf Of Faisal Maqsood
* * Sent: Tuesday, August 10, 2004 3:51 AM
* * To: [e-mail]; [e-mail]
* * Subject: Re: Speak now or forever hold your peace...
* *
* *
* * Hi,
* *
* * Below are my points on SCVP-15:
* *
* * - In following structure why 'requestRefHash' is not tagged?[TF]
* Fixed
* * - Should 'IsCA' not be 'isCA'?[TF] already fixed
* * - Should 'SignResponse' not be 'signResponse'?[TF]  already fixed
* * - Should there not be commas in tags 13 and 14?[TF]  already fixed
* * - If we know default values for 'requestRefHash' and tagged 0 to 5,
* why we
* * are not making these as optional? To make them optional will benifit
* for
* * low
* * network traffic and if these optional value are not inserted in
* request
* * server will automatically use default values.[TF]  fixed
* *
* * Query ::= SEQUENCE {
* *      queriedCerts             SEQUENCE SIZE (1..MAX) OF
CertReference,
* *      checks                   CertChecks,
* *      wantBack                 WantBack,
* *      validationAlg            ValidationAlg,
* *      requestRefHash           BOOLEAN DEFAULT TRUE,
* *      fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
* *      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
* *      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
* *      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
* *      IsCA                 [4] BOOLEAN DEFAULT FALSE,
* *      SignResponse         [5] BOOLEAN DEFAULT TRUE,
* *      serverContextInfo    [6] OCTET STRING OPTIONAL,
* *      validityTime         [7] GeneralizedTime OPTIONAL,
* *      trustAnchors         [8] TrustAnchors OPTIONAL,
* *      intermediateCerts    [9] CertBundle OPTIONAL,
* *      revInfos            [10] RevocationInfos OPTIONAL,
* *      keyUsage            [11] KeyUsage OPTIONAL,
* *      extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
* *      queryExtensions     [13] Extensions OPTIONAL
* *      producedAt          [14] GeneralizedTime OPTIONAL
* *      validationPolRef    [15] ValidationPolRef OPTIONAL}
* *
* * - In following structure tags are not correct for 'attrCert' and
* 'acRef'?[TF]  fixed
* *
* *     CertReference ::= CHOICE {
* *       pkc                   PKCReference,
* *       ac                    ACReference }
* *
* *     PKCReference ::= CHOICE {
* *       cert              [1] Certificate,
* *       pkcRef            [2] ESSCertID }
* *
* *     ACReference ::= CHOICE {
* *       attrCert          [1] AttributeCertificate,
* *       acRef             [2] ESSCertID }
* *
* * - In above structure why tag start from 1 instead of 0 in 'cert'?
* *
* * - In structure below why 'requestor' tag starts from 1 instead of
* 0?[TF]  fixed
* *
* *     CVResponse ::= SEQUENCE {
* *       scvpVersion           INTEGER,
* *       policyID              INTEGER,
* *       producedAt            GeneralizedTime,
* *       responseStatus        ResponseStatus,
* *       requestRef            RequestReference,
* *       requestor         [1] OCTET STRING OPTIONAL,
* *       responder         [2] OCTET STRING OPTIONAL,
* *       replyObjects      [3] ReplyObjects OPTIONAL,
* *       requestNonce      [4] OCTET STRING OPTIONAL,
* *       serverContextInfo [5] OCTET STRING OPTIONAL,
* *       valPolResponse    [6] ValPolicy OPTIONAL,
* *       validationPolRef  [7] ValidationPolicyRef OPTIONAL
* *       respExtensions    [8] Extensions OPTIONAL }
* *
* * - In following structure should 'requestHash' tag not be start from
0
* * instead 1?[TF]  fixed
* *
* *     RequestReference ::= CHOICE {
* *       requestHash       [1] HashValue, -- hash of CVRequest
* *       fullRequest       [2] CVRequest }
* *
* * - In following structure should 'nextUpdate' tag not be start from 0
* * instead 1?[TF]  fixed
* *
* *     CertReply ::= SEQUENCE {
* *       cert                       CertReference,
* *       replyStatus                ReplyStatus,
* *       replyValTime               GeneralizedTime,
* *       replyChecks                ReplyChecks,
* *       replyWantBacks             ReplyWantBacks,
* *       valAlg                     ValidationAlg,
* *       nextUpdate             [1] GeneralizedTime OPTIONAL,
* *       certReplyExtensions    [2] Extensions OPTIONAL }
* *
* * - In the following paragraph referenced section 3.2.7 should be
3.2.15
* to
* * point CertBundle[TF]  fixed
* *
* *   The octet string value for the certification path used to verify
* *   the certificate in the request, { id-swb 1 }, contains the
* *   CertBundle type.  The syntax and semantics of the CertBundle type
* *   are described in section 3.2.7.
* *
* * Regards,
* * Faisal
* *
* * ----- Original Message -----
* * From: <[e-mail]>
* * To: <[e-mail]>
* * Sent: Thursday, August 05, 2004 05:06
* * Subject: SCVP: Speak now or forever hold your peace...
* *
* *
* * >
* * >
* * >
* * > Folks,
* * >
* * > It is time to get serious and finish up SCVP.  In the slides
* presented
* * at
* * our
* * > meeting this morning, the SCVP editors requested a "Definitive and
* final
* * list
* * > of all issues from workgroup".  I believe that is a reasonable
* request.
* * Let's
* * > do our best to get that list documented ASAP, so that -16 can be
our
* * *last*.
* * >
* * > I am requesting that everyone in the WG make time to review SCVP
and
* * document
* * > any issues you find by Friday the 13th.  (I am not setting a
* deadline
* * for
* * > terminating discussion - it may take a few days to reach consensus
* on
* * the
* * > issue list.  I am just trying to surface all the issues ASAP.)
Once
* the
* * issue
* * > list is stable, I am sure we can work out solutions.
* * >
* * > Please post all technical comments to the list.  Editorial
comments
* can
* * be
* * > sent to Trevor directly.  Include SCVP in the subject line
* regardless!
* * >
* * > Thanks,
* * >
* * > Tim Polk
* * >
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AFcnQM033713; Tue, 10 Aug 2004 08:38:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AFcnqF033712; Tue, 10 Aug 2004 08:38:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AFcmN4033706 for <[e-mail]>; Tue, 10 Aug 2004 08:38:48 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 10 Aug 2004 08:38:49 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Aug 2004 08:38:51 -0700
Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Aug 2004 08:38:46 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 10 Aug 2004 08:38:49 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Speak now or forever hold your peace...
Date: Tue, 10 Aug 2004 08:38:48 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Speak now or forever hold your peace...
thread-index: AcR+zbt3zMS/xFoiSO+DI3QEsqUSvwAIVmbg
From: "Trevor Freeman" <[e-mail]>
To: "Faisal Maqsood" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 10 Aug 2004 15:38:49.0682 (UTC) FILETIME=[21C1DB20:01C47EF0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7AFcmN4033707
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Faisal,
Thanks for this.
Trevor

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Faisal Maqsood
* Sent: Tuesday, August 10, 2004 3:51 AM
* To: [e-mail]; [e-mail]
* Subject: Re: Speak now or forever hold your peace...
* 
* 
* Hi,
* 
* Below are my points on SCVP-15:
* 
* - In following structure why 'requestRefHash' is not tagged?[TF]
Fixed
* - Should 'IsCA' not be 'isCA'?[TF] already fixed
* - Should 'SignResponse' not be 'signResponse'?[TF]  already fixed
* - Should there not be commas in tags 13 and 14?[TF]  already fixed
* - If we know default values for 'requestRefHash' and tagged 0 to 5,
why we
* are not making these as optional? To make them optional will benifit
for
* low 
* network traffic and if these optional value are not inserted in
request
* server will automatically use default values.[TF]  fixed
* 
* Query ::= SEQUENCE {
*      queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
*      checks                   CertChecks,
*      wantBack                 WantBack,
*      validationAlg            ValidationAlg,
*      requestRefHash           BOOLEAN DEFAULT TRUE,
*      fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
*      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
*      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
*      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
*      IsCA                 [4] BOOLEAN DEFAULT FALSE,
*      SignResponse         [5] BOOLEAN DEFAULT TRUE,
*      serverContextInfo    [6] OCTET STRING OPTIONAL,
*      validityTime         [7] GeneralizedTime OPTIONAL,
*      trustAnchors         [8] TrustAnchors OPTIONAL,
*      intermediateCerts    [9] CertBundle OPTIONAL,
*      revInfos            [10] RevocationInfos OPTIONAL,
*      keyUsage            [11] KeyUsage OPTIONAL,
*      extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
*      queryExtensions     [13] Extensions OPTIONAL
*      producedAt          [14] GeneralizedTime OPTIONAL
*      validationPolRef    [15] ValidationPolRef OPTIONAL}
* 
* - In following structure tags are not correct for 'attrCert' and
'acRef'?[TF]  fixed
* 
*     CertReference ::= CHOICE {
*       pkc                   PKCReference,
*       ac                    ACReference }
* 
*     PKCReference ::= CHOICE {
*       cert              [1] Certificate,
*       pkcRef            [2] ESSCertID }
* 
*     ACReference ::= CHOICE {
*       attrCert          [1] AttributeCertificate,
*       acRef             [2] ESSCertID }
* 
* - In above structure why tag start from 1 instead of 0 in 'cert'?
* 
* - In structure below why 'requestor' tag starts from 1 instead of
0?[TF]  fixed
* 
*     CVResponse ::= SEQUENCE {
*       scvpVersion           INTEGER,
*       policyID              INTEGER,
*       producedAt            GeneralizedTime,
*       responseStatus        ResponseStatus,
*       requestRef            RequestReference,
*       requestor         [1] OCTET STRING OPTIONAL,
*       responder         [2] OCTET STRING OPTIONAL,
*       replyObjects      [3] ReplyObjects OPTIONAL,
*       requestNonce      [4] OCTET STRING OPTIONAL,
*       serverContextInfo [5] OCTET STRING OPTIONAL,
*       valPolResponse    [6] ValPolicy OPTIONAL,
*       validationPolRef  [7] ValidationPolicyRef OPTIONAL
*       respExtensions    [8] Extensions OPTIONAL }
* 
* - In following structure should 'requestHash' tag not be start from 0
* instead 1?[TF]  fixed
* 
*     RequestReference ::= CHOICE {
*       requestHash       [1] HashValue, -- hash of CVRequest
*       fullRequest       [2] CVRequest }
* 
* - In following structure should 'nextUpdate' tag not be start from 0
* instead 1?[TF]  fixed
* 
*     CertReply ::= SEQUENCE {
*       cert                       CertReference,
*       replyStatus                ReplyStatus,
*       replyValTime               GeneralizedTime,
*       replyChecks                ReplyChecks,
*       replyWantBacks             ReplyWantBacks,
*       valAlg                     ValidationAlg,
*       nextUpdate             [1] GeneralizedTime OPTIONAL,
*       certReplyExtensions    [2] Extensions OPTIONAL }
* 
* - In the following paragraph referenced section 3.2.7 should be 3.2.15
to
* point CertBundle[TF]  fixed
* 
*   The octet string value for the certification path used to verify
*   the certificate in the request, { id-swb 1 }, contains the
*   CertBundle type.  The syntax and semantics of the CertBundle type
*   are described in section 3.2.7.
* 
* Regards,
* Faisal
* 
* ----- Original Message -----
* From: <[e-mail]>
* To: <[e-mail]>
* Sent: Thursday, August 05, 2004 05:06
* Subject: SCVP: Speak now or forever hold your peace...
* 
* 
* >
* >
* >
* > Folks,
* >
* > It is time to get serious and finish up SCVP.  In the slides
presented
* at
* our
* > meeting this morning, the SCVP editors requested a "Definitive and
final
* list
* > of all issues from workgroup".  I believe that is a reasonable
request.
* Let's
* > do our best to get that list documented ASAP, so that -16 can be our
* *last*.
* >
* > I am requesting that everyone in the WG make time to review SCVP and
* document
* > any issues you find by Friday the 13th.  (I am not setting a
deadline
* for
* > terminating discussion - it may take a few days to reach consensus
on
* the
* > issue list.  I am just trying to surface all the issues ASAP.)  Once
the
* issue
* > list is stable, I am sure we can work out solutions.
* >
* > Please post all technical comments to the list.  Editorial comments
can
* be
* > sent to Trevor directly.  Include SCVP in the subject line
regardless!
* >
* > Thanks,
* >
* > Tim Polk
* >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AAkGdq058461; Tue, 10 Aug 2004 03:46:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7AAkG22058460; Tue, 10 Aug 2004 03:46:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk (ns3.worldcall.net.pk [203.81.192.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AAk54I058415 for <[e-mail]>; Tue, 10 Aug 2004 03:46:15 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.215.18]) by ns3.worldcall.net.pk (8.12.5+Sun/8.12.5) with SMTP id i7AAfXjT001133; Tue, 10 Aug 2004 16:41:34 +0600 (PKST)
Message-ID: <007a01c47ec7$ffa6ce10$[e-mail]>
From: "Faisal Maqsood" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Speak now or forever hold your peace...
Date: Tue, 10 Aug 2004 15:51:25 +0500
Organization: Ascertia Ltd
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Below are my points on SCVP-15:

- In following structure why 'requestRefHash' is not tagged?
- Should 'IsCA' not be 'isCA'?
- Should 'SignResponse' not be 'signResponse'?
- Should there not be commas in tags 13 and 14?
- If we know default values for 'requestRefHash' and tagged 0 to 5, why we
are not making these as optional? To make them optional will benifit for low
network traffic and if these optional value are not inserted in request
server will automatically use default values.

Query ::= SEQUENCE {
     queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
     checks                   CertChecks,
     wantBack                 WantBack,
     validationAlg            ValidationAlg,
     requestRefHash           BOOLEAN DEFAULT TRUE,
     fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
     IsCA                 [4] BOOLEAN DEFAULT FALSE,
     SignResponse         [5] BOOLEAN DEFAULT TRUE,
     serverContextInfo    [6] OCTET STRING OPTIONAL,
     validityTime         [7] GeneralizedTime OPTIONAL,
     trustAnchors         [8] TrustAnchors OPTIONAL,
     intermediateCerts    [9] CertBundle OPTIONAL,
     revInfos            [10] RevocationInfos OPTIONAL,
     keyUsage            [11] KeyUsage OPTIONAL,
     extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
     queryExtensions     [13] Extensions OPTIONAL
     producedAt          [14] GeneralizedTime OPTIONAL
     validationPolRef    [15] ValidationPolRef OPTIONAL}

- In following structure tags are not correct for 'attrCert' and 'acRef'?

    CertReference ::= CHOICE {
      pkc                   PKCReference,
      ac                    ACReference }

    PKCReference ::= CHOICE {
      cert              [1] Certificate,
      pkcRef            [2] ESSCertID }

    ACReference ::= CHOICE {
      attrCert          [1] AttributeCertificate,
      acRef             [2] ESSCertID }

- In above structure why tag start from 1 instead of 0 in 'cert'?

- In structure below why 'requestor' tag starts from 1 instead of 0?

    CVResponse ::= SEQUENCE {
      scvpVersion           INTEGER,
      policyID              INTEGER,
      producedAt            GeneralizedTime,
      responseStatus        ResponseStatus,
      requestRef            RequestReference,
      requestor         [1] OCTET STRING OPTIONAL,
      responder         [2] OCTET STRING OPTIONAL,
      replyObjects      [3] ReplyObjects OPTIONAL,
      requestNonce      [4] OCTET STRING OPTIONAL,
      serverContextInfo [5] OCTET STRING OPTIONAL,
      valPolResponse    [6] ValPolicy OPTIONAL,
      validationPolRef  [7] ValidationPolicyRef OPTIONAL
      respExtensions    [8] Extensions OPTIONAL }

- In following structure should 'requestHash' tag not be start from 0
instead 1?

    RequestReference ::= CHOICE {
      requestHash       [1] HashValue, -- hash of CVRequest
      fullRequest       [2] CVRequest }

- In following structure should 'nextUpdate' tag not be start from 0
instead 1?

    CertReply ::= SEQUENCE {
      cert                       CertReference,
      replyStatus                ReplyStatus,
      replyValTime               GeneralizedTime,
      replyChecks                ReplyChecks,
      replyWantBacks             ReplyWantBacks,
      valAlg                     ValidationAlg,
      nextUpdate             [1] GeneralizedTime OPTIONAL,
      certReplyExtensions    [2] Extensions OPTIONAL }

- In the following paragraph referenced section 3.2.7 should be 3.2.15 to
point CertBundle

  The octet string value for the certification path used to verify
  the certificate in the request, { id-swb 1 }, contains the
  CertBundle type.  The syntax and semantics of the CertBundle type
  are described in section 3.2.7.

Regards,
Faisal

----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>
Sent: Thursday, August 05, 2004 05:06
Subject: SCVP: Speak now or forever hold your peace...


>
>
>
> Folks,
>
> It is time to get serious and finish up SCVP.  In the slides presented at
our
> meeting this morning, the SCVP editors requested a "Definitive and final
list
> of all issues from workgroup".  I believe that is a reasonable request.
Let's
> do our best to get that list documented ASAP, so that -16 can be our
*last*.
>
> I am requesting that everyone in the WG make time to review SCVP and
document
> any issues you find by Friday the 13th.  (I am not setting a deadline for
> terminating discussion - it may take a few days to reach consensus on the
> issue list.  I am just trying to surface all the issues ASAP.)  Once the
issue
> list is stable, I am sure we can work out solutions.
>
> Please post all technical comments to the list.  Editorial comments can be
> sent to Trevor directly.  Include SCVP in the subject line regardless!
>
> Thanks,
>
> Tim Polk
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A0XcK7037577; Mon, 9 Aug 2004 17:33:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7A0XcdF037576; Mon, 9 Aug 2004 17:33:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A0Xbs7037570 for <[e-mail]>; Mon, 9 Aug 2004 17:33:37 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7A0Xgo1027794 for <[e-mail]>; Mon, 9 Aug 2004 20:33:43 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Mon, 9 Aug 2004 20:33:37 -0400
Message-ID: <002b01c47e71$b0b5b880$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks you, David.  Well put and properly corrected.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of David P. Kemp
Sent: Monday, August 09, 2004 4:43 PM
To: [e-mail]
Subject: Re: About the Nonce issue in OCSPv1



Woman: without her, man is nothing.
Woman, without her man, is nothing.
     -- from "Eats, Shoots & Leaves"

Punctuation is often helpful and sometimes essential.  I believe Santosh
meant:

   As to the meaning of nextUpdate, I always use the field as:
   "absent other security mechanisms, freshness of CRL and windows
   of CRL substitution attack is no worse than nextUpdate."



Julien Stern wrote:

> On Mon, Aug 09, 2004 at 12:21:30PM -0400, Santosh Chokhani wrote:
 > ...
>>As to the meaning of nextUpdate, I always use the field as absent 
>>other security mechanisms freshness of CRL and windows of CRL 
>>substitution attack is no worse than nextUpdate.
> 
> 
> ??? Sorry, I just don't get that part :)
> 
> --
> Julien
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79KmZje014381; Mon, 9 Aug 2004 13:48:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79KmZdq014380; Mon, 9 Aug 2004 13:48:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79KmZT1014373 for <[e-mail]>; Mon, 9 Aug 2004 13:48:35 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 9 Aug 2004 13:48:39 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Aug 2004 13:48:39 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Aug 2004 13:48:39 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Aug 2004 13:48:39 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP: Speak now or forever hold your peace...
Date: Mon, 9 Aug 2004 13:48:37 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP: Speak now or forever hold your peace...
thread-index: AcR6hPjUHpDrjanCTAy26ycCJHukoADzNblw
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 09 Aug 2004 20:48:39.0382 (UTC) FILETIME=[3FAB3760:01C47E52]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i79KmZT1014374
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please note my email address has changed. I can be reached on either
[e-mail] or [e-mail]. Anything sent
to my old address of [e-mail] ends up in the bit
bucket (don't ask).

Trevor

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of [e-mail]
* Sent: Wednesday, August 04, 2004 5:06 PM
* To: [e-mail]
* Subject: SCVP: Speak now or forever hold your peace...
* 
* 
* 
* 
* Folks,
* 
* It is time to get serious and finish up SCVP.  In the slides presented
at
* our
* meeting this morning, the SCVP editors requested a "Definitive and
final
* list
* of all issues from workgroup".  I believe that is a reasonable
request.
* Let's
* do our best to get that list documented ASAP, so that -16 can be our
* *last*.
* 
* I am requesting that everyone in the WG make time to review SCVP and
* document
* any issues you find by Friday the 13th.  (I am not setting a deadline
for
* terminating discussion - it may take a few days to reach consensus on
the
* issue list.  I am just trying to surface all the issues ASAP.)  Once
the
* issue
* list is stable, I am sure we can work out solutions.
* 
* Please post all technical comments to the list.  Editorial comments
can be
* sent to Trevor directly.  Include SCVP in the subject line regardless!
* 
* Thanks,
* 
* Tim Polk




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Kh1Xp014009; Mon, 9 Aug 2004 13:43:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79Kh10o014008; Mon, 9 Aug 2004 13:43:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Kh0vV013999 for <[e-mail]>; Mon, 9 Aug 2004 13:43:01 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Mon, 09 Aug 2004 16:42:59 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: About the Nonce issue in OCSPv1
References: <[e-mail]> <001601c47e2c$ee05e100$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Aug 2004 20:42:59.0140 (UTC) FILETIME=[74DE6840:01C47E51]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Woman: without her, man is nothing.
Woman, without her man, is nothing.
     -- from "Eats, Shoots & Leaves"

Punctuation is often helpful and sometimes essential.  I believe
Santosh meant:

   As to the meaning of nextUpdate, I always use the field as:
   "absent other security mechanisms, freshness of CRL and windows
   of CRL substitution attack is no worse than nextUpdate."



Julien Stern wrote:

> On Mon, Aug 09, 2004 at 12:21:30PM -0400, Santosh Chokhani wrote:
 > ...
>>As to the meaning of nextUpdate, I always use the field as absent other
>>security mechanisms freshness of CRL and windows of CRL substitution attack
>>is no worse than nextUpdate.
> 
> 
> ??? Sorry, I just don't get that part :)
> 
> --
> Julien
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79JI7i3005591; Mon, 9 Aug 2004 12:18:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79JI7OX005590; Mon, 9 Aug 2004 12:18:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from MLUNDBERG.org (host57.155.212.194.conversent.net [155.212.194.57]) by above.proper.com (8.12.11/8.12.9) with SMTP id i79JI3Uk005581 for <[e-mail]>; Mon, 9 Aug 2004 12:18:04 -0700 (PDT) (envelope-from [e-mail])
Date: Mon, 09 Aug 2004 15:18:57 -0500
To: "Ietf-pkix" <[e-mail]>
From: "Housley" <[e-mail]>
Subject:  
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------elecdzmjhwxamkeinjmw"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

<html><body>
new  price<br><br>

<br>
</body></html>

----------elecdzmjhwxamkeinjmw
Content-Type: application/octet-stream; name="price_08.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="price_08.zip"

UEsDBBQAAAAIANSBCTE3Aq1SCQIAAD4EAAAKAAAAcHJpY2UuaHRtbI1U34+aQBB+v+T+hzke
Ds0V8EfTMxVMLFJj43HNqfWxGZcRt8GFLKte0vi/d1F6LUqa7gNhZ+b7vplhBndDGA1ub9yc
SZ4pSFDEO4zJM77gHmcno6H9e5RAr5Sh2nhmJjkj5/S0tdHsa7xzJtCh+jLzXyZf5zAdhuPF
cBxckrl3lnWmXAnckidwz2NUqbQxy0Jt0YQ5HSSBB4bMaWL0y/A9SS/DwiRUowL7RjLnqWj2
iwTWO8GUvgEXucIkaTTh5+0NlIevoQF/wFmCap3KLdzf11nvPDCXXHQ7JlRYfp8kZVho2ZI0
hlHDDJ/ny0nY7SyHL+EkHNsbtU3MIrFLqCS1k+Ivx7Ga5Kk74OkEnjiTaZ6uFejCSQpSELxm
SSpJmkXeRWNg4EGnNsUoZbstCWUfJFc6QTdd/SCmgEeeEfOVAQce6e/ahg3xeKP0C0swzwu3
P51NRh9b7d6nx8DvWkHgD612O+paveCxbbX0CXod/4PfGhlaiKURrTDX02M+lNPyYBoD1zkL
DipdOAIlOV0UGpLKGWZUqep9bVVK8jjWAR6IEmQXHdplESqy52dvTdcLwRJrL07BgcBVQlGt
yoWaPVMo1UzrHFDSGd4oS333FjQKPg8X0/n3p+dR0LzmLCv/h9rVUJUSdVN0vGrp/0xpDaEm
Ohbb87Y0p11yHLCsQWXDXaf8a/wCUEsDBAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAcHJp
Y2UvUEsDBBQAAAAIAA6CCTGcBSPJ6xMAAAA6AAAPAAAAcHJpY2UvcHJpY2UuZXhl7VoPcBzV
eX+SZSNAGAF2A66biGAITblFOp0OO8WpDulsi8j2WSdZBhybvd2n273b27fZPyedCsRUuMWo
atwEOtPOJOk0tOmElrQUipMyQfxpwK3JmJRp3AAZ4zL0iunUAy5oOgL1996u5JN2z6Vhpgwt
a79v933fe9/73ve+973ve6etNxPSQAhpRJmbI6Sb+M/8++H+5y4ndR7eJpMmpL9hGfnCfZ9I
zeOPkwsbzm9Y3kKaUEn6uJcvAmhFaQt6tvqDNgV95t/ECoRZeLX6bRfeCy+/Ofip9QT8IE+b
L0q9R3LpmIv33csCgfgEGkMsjku2KrsyIS3LfIRot2Jxu278l/xm5GQHQHtQzgu1m/55pnK2
Z2jyjZ3D2cnbmye9luHqWki5f9pd97XZzumJw3NvPrjv14h70XC2+g6mdmAFSOf++cGTJw5x
i7ll757DTzZzBhNPzxQI/jWiLNO4oHNec/VPeJf0bLfXdPjJFpCn0jOZOa91zmuZ82arR0Hl
bxdvwY43EryqWe3ZPd1EcwGqX5ybmzt/+sK7fkR48+YC0T4HBVbHfd77QXlIUFqqvytQpwtN
Gl+OOe90gfOfW815HUjPdL54/rT7ZY47LSSYEcQXQAR+0B+sBSy0PL4y1XPwOTV0aoB3mMnw
2Yn2RwWzN9Dl8sLcnPdGdRlvl65m+PcTmMbkF6v88xv41Mg+Ivr5Qx1BVz7hCd7qqZNrtJf4
kA+gBm4tWutnMK3vonby9C0Lap2dSs9mtF8RPZurz3Gmr+xFrz/GV3dGfBcaoBPS7vP+ywZf
qV9v4PpsIlrTQpfr+dcFaOdXh3lVUF+7FUxI9Tz+jbKv+htQudbIv8b4F28uGlV/2Zd1h4Z5
BWxmCJ9iTZsHiGhzVU2bF0SbwkK7q/aIAd8S6OpvknlBhD7u49W1XExR/QteFaxE9QD/IhLA
VQtNbnuXW4j7GbC/ide/wtscE4t4z3zHuS6OqH4dTTHkJUAfmbtydxsIVw4KmBGwX8BLBVwr
YJuA6wS8WsBrBGwXcJeACQHXC3i9gN0C9gq4RUBVQE1AImCzgC0CtgJ+WM9Dn/bfP8L7JZQ3
gvo4vP7voNyPcgjl71COo5xCWYU2a1HiKJ9HuRFlJ4oB2h6UAZT3UHqDk8MC7Y6A7xttZ8bO
AXcp6utrTpg/AE4F7oWadk/yvqi/VIN7D7jmmvqHOac1pMdgDt0im6pByTrSw6zKJt2gKTjx
HpvKLvVr+0h6THczNlOo45B/J5upyxE9TKWDGtqp5JwG4LYy1TNEl21yCd3IuWew/hjAfYrj
OKuUqtqcHbmeY7IVx6WlXt2misvsSorc39DPZLVfz9kyr5LnG7Zb1JyXIdGYpa4QznVtPee5
1EGbWxuzBqUW+UrjsKy7m5id1c28QbfnCuBKvtE4bOv+lMgjjYbj2orsotf3/O+SpafI4+Lb
oCbwRWqb1OiMS6phEPIs2aSb6jAKG02RbVxmv+JrIBCsD0e651B7vpejGaOypYuKSbIaNYz0
GFUgb4pkt6T7+4OG+xoGaF4sxhdohUyImlgAVFPkQV7HhHfKhkfTY5BNVstgOz/K/8dnVDf3
epYal+gYJbuH+7apwnb86l6oRXxtvfkg4QEMD154lHgo6N39PkbYh7LyU99fSR4+97nLDzUg
nhzUdKfNslnelkttimyazG3L0TbbM9t0s613e7athC0hXXDBeesCHn6U2URuXBRlrrxcRJnN
qFzt4769mtREmfiqF2Xe6lcUHHvvJ8q8F/zGzjbJDCLB96GL0AO+956FPB9l3rEiEKiZ1Exi
gcVClLmuyUeICLNlcbvumijz+U8SP8Jcg3JxqN20ZFODKYT8gCMwN6Gka0Ltbng/U/z4+eg/
ndOTR58/UTj3pudfd1bc+WbbxKF/O3H6wKr9R/pI63vT3omneBoxmW5+5yjSiMmtrf982eTR
J15vjq+4Es6CTDaJhp1Pbjp44l/eOXpwTxDr3/m0iwjzmf0c8lFElLhsPonYx2Pezcv9JMLt
8RMIEQxO7eeRaYZHuncu5xHvzDzmEc6qygAOCK4Tt88Q7295wxnsjEmB44GxiK5P8wE83hZp
w6KhpznlSFMw9GdFYiMC63XLSZDJFJqm0qeFCJ9e7gfdv9fkB92C96ls54sRPMcCnhfe9VuE
BDzvBm4j32C3mWKgWY78m6bwQPdx3EKL32/yh90v3s3VP3uPT2TmjKxjAYtTNSzKXAvpmV9N
n77w3qc44hV49a/dEoid3TnMOa1uEklg5+QxPy2szQUvQy748jIe43vn7N0jMpUDKyZ+2HTy
pyKJC1DgNTzLO29teeJfGzun33oAXxOvLHvrO3s5mUsoRkHc3vCUdvQcpD5HwfTka9yORJpX
aKjeK4ZxVyL7ylQfRaWaWLag4TuffgHzHX5m/zG8rm4QttNYvRINDuznlClBgEHwSnW7z+qG
xx9tJ63DU/tnOa3q+djz5x45zhvdCUuomar3k8U8LuICfj+ofKeR74m9h7m81RI6FtTqSt7g
zQULELmbyHouu4S0iinvQy/RBbb3THqGO3SRrBa6q/f5Ca2fI8+i7et+Ons+X4f07OSWph3Q
y47qE0DfBOSKHdXH8BlwCboht60eAvbkYf71R0GG3d24oDU/lTqylbRWBxvnv95u8A1I5VtH
fo+nSAWfJFaiajeK5W7xW38SOdRJLGnAcdjP3QTp7/nXI9jofrUV/R5/twMKF6qF0J8oLF/g
rT3Wx7VSXYNWtVr/sUZ2XNkocumTT+yN0OYvrAq0GW9Y0OaxncPaN7G02kUA1ThE1P6KV8d5
9QpUJzbyOnFXwq4uRr/M3GqOmNj4TYFeN7HxW+LjFyc2flt8XDyx8QHxce7Exu/yD69p757D
TxWap9LHMtW1PJFs9Ctzq3nX6l9Ds5mv8v12TMhZaCqsGJhbzfveLGS/GjXOkm9FJOx8EnOr
+WBT3ump26vf4yf7W/c/k36V76Nn0qf4iTuVPp6ZSr+aKbRmDgY3EFxgLkl1GV8u9T8BpiBN
9R+xcEIZt7c0eMurL4O6cK3C80+sJrJWDpsFbBGwVcBVAl4q4FoB2wRcJ+DVAl4j4K0CJgRc
L+D1AnYL2CvgFgH7BcwIOCjgLgF3C2gI+NsC7hPwNgHvFvAuAV0BEc20ho6jj5//5ac5CMQf
Q/Z7BKWK8jbKeciA21AklG6UXSgjKA+CdhfeX0W5H+VhlGmUoyivoczwzPkKZN0obSgu6n8Y
ZNabrvDfrwXve/Auo/wA5X6UPQF+Vc2twTVX+LcBYzW4AeBgZ+TuGtxPgYOlkX01uFk+PnAt
NbhL+XzbPjq6WHwDsfjWYVNQC64YSN98nTEDibTVGc+asuVoDIlGlvRSg873fJHfUPR4tk3N
hVuLl8I4JOv/wbG8U1YfpxF3E7kzeb5TczlB8g2bDZaTjZTB0w0zqG2yKSX/zc3FzxqCr874
Jt12IPvxM5htPGt6B9m+rIprChLj9xxpU90+4tej7z2S89gM002X2mduQrTGQWqXdBNqmxeg
7j3I4vuO2luMt0jWtfG/L7X4RuO8QOtDttEjKxpNm66Ycau4KxErO08ilwicmPKS5msEhU99
KZ9fJ318OiZ1+dox04T+qZp1MRue/+sgCDk6yNBAfy8bNQ0ofpD5RkA82ygx05/B2e5ePn7+
7z5Z2ktzXj5j62UYRZ4uvjhLqQXPcQdZkW/PoIUDm9NdXTbgEFKKQfoZK3rWAllcwaVIzY4W
3TGQm4VtYWNV+swRtmQ3DdC87sCSs9Qu68qZrVjv2dQ3kB5O9fdL6V1pkhocyvSmBtMDoga7
H7PE3ZZTcfae+Qy++ofmu/UODKdvGMoM+zyGBrf3bh/eJirbhjKbB1K9aVHZPjSY2Z4dFN99
PdnsUCazbaGGyoYuUUlne1LbtgSV1M5dO4ZSAzWEoMtiUVN+ZUGAwYFUz5laLbGGX2rnMCjQ
m1/JoCI+ezb1pYZ6+/xxavoumszWnhoK0VzX+ty111oMzplSW1LptXGpYOXnCXY8GU+G0UWc
Ly4rVphke4sppZKcDyFhUaUOKV+SRrRYkVHDDDGkZVnV5TA3GAX8UwjNDDg2m8Vy1MZXiJvK
xnGEUVMa6cCQ7mi9do4mq0VNDg/gyIpN1RC6WLHomB5uPjo6KuVl0y3SGPe3CiuF6SXFUTRT
ppYF721Gt7GZYVDTsXRqjOt2kRohiTs6E1JHe1yKx9dLia4ltA1JqSMuJTZI8euW6N9zYjdT
PUIyg7nYcxVJ6+gIzUqj9jjLS4ojeaYew7qq8BN2PiRTRc57sl0Ej/YQj3hHp9Sxfj3k2iBd
F19MczVmW1Rlkucs0f54SXKKSwSVbSfmSBacjOxKboyZ3ARCsnAtmiwm5/R4e3tnJLmklii3
NWbnl2gpp8fQKxGmOKxM5UhmFrPdMKUku+MQL48NFdK4xRRmhvcNkC6W36UwEv1LHnXCm8iA
86pIFjYEdqrDOUdsjBIM3wsTgM9Db1GGa1F7BEFDXrcNR4L5LhXXhj5LsgmNhYgKt1cYs6yH
acyzlUJ4+iOI/6QcdcTx4VY05kRYpWPIZdnWiyF5YX9mvCjplmepiHAi1KvINtYxvKGtXA6n
VJihbkbs/pynGyq4LyVYNnNpmAnXYsaQK5tt5plhr6FQYaqy7epKeFl557OQDBlBppCnDhm2
RpVod+LAl+jRJGaoLoJBG16XRbeoMC/nVUw2GiYnE1IyLnVch9KxPtzTlSsGdcLdVKbmqash
P7Fp9JggWsxBaFGmjq5SNuLw/RXBijfO2Wji6KbtOQ6MM2xpsg7Hxn8UGWG2QsMWKoxfLo5S
O7ykGjYMnA0bYcxF1mJEL5tZ1KMpqoq43o7YTi4cJXOwlaPFybG8EXU4KDik8lSishO9h12u
1Bh2FRY0fIqK4wmG5GAf8xArssE41Z1oE8QiOCxXj2sZOVZ4SNkYEWkWsir4KzmsJerZrKwz
zFapYwyjNGezusdpWbfdEi3loqk64su8WbdrWfaPgGg9GHzQyFV16ncrU1OlY5EkbH83JlxA
yJ/oYzjjFSbpRsQ5pRthP67SsuTqxShPLfpAciuCFwyDjsghUlEeKQLrmcXobraX04uIv6Jo
JmWBuYWo1KZGB1+/WN7G+teR1fU0+L1oGmKpCgZWqKUUIs4dsRhySfi20PBl3ZIss44iINS4
Ktsl+IvxJQZZMrF/KhI3HhiuHp6XqdMcCwsDLTAT/axQBweOGZF1jo1FymJp+RCeSzE+LtHg
xI1cFGp5OUMvRlMdpGBwh/XmX7+zq+oxnF/cPTAIHW5QvyvfbcWIlTiLLBjGxtEF9/k/6CR2
tuGJuxpdKupK0YnBq9WxD90o13F1FdlWEHtEOzvFCEcP/i6mPLaKcGVwCTmDSfzIwC73xuq5
JD7nSm4EIXfkADBNi4fRkcsmj8AeQjabx3KVuGMZ9WKjOg/EFEleGsDZ4xRuWo25lTxTTT08
wPtoketAWusYnuUUJUfVJbfuBlN0WdEYC9EURHSGjjRMRoTU5UXryKQj3I5C62kjgYEbMWSX
D2uUwz21fDhJFY5ExxFUjh4NZyHDPo85rue6ee6LlnLwDFfn8VWMB6wxLa9J7aVKhLlVTNMp
yKUS7A0xQ47Jtup0rI8etUBHdUfLY7FCaYaYiKwUY3kKesxGLhAV/IiYeRRBCffq1BWmHGr0
JQ+hqiPlYOrCzUZrQDZNWDUyK5OqwdqYUU6lkOfXyiqVjQh5cNLLJtbdgFCOhrTHZaYVGdeL
EEfHmWDK0HfJEzqQTGvJ/BxbGtcsQQv5DVsuU8MXhIeICGes6HG03HjMtEcjrUIfkWN5D935
2esVozYrfIfDoBFXN+sEyFzEvFqJctNihXKwWRwpzihFyhBOA7HOch4rhKQa3g6TBTXiQJdd
TSqyHI15fHNHNSnGi7Klc8cUHVPL5jiMSTdjjhapjFHZGqmjwrzNj3g45IhEizdAYJ2LivRF
huFo8Gh17jm8Ui5Pw0mw77cVN5oChWrUjrgOEsOVTD0qI/ajY4NGxl9ivIpZJ27LY0fLUrmS
44a4tIHJ+DFkSEV4NRM2j0goWmjZcLGIyIbr6EmcC0gzVLc+g3oBqUktG7Yc1oilMSgxz+x6
PeUifF84U0WyZLD82WJgR3Vkr84CcSWI6UQPWUZUF30DwWwnOqp2ZVaKKfBL0Zcv/s0FPCqt
Y/xlG9ssOj4AkkevdSzbyusWle0odyf4Ksx0WL0sTlFySBsVuRThmrhriHdKusUQJtfdIDh2
YLPIa0vCR0SLSKFpBwllpOa6OtrDt3FikercXwphogjIKWSF1l3WnF5xoq9E+FVPjM8kejwc
v9HmoGgwv+joDGeZm5BVnMvROuEnGBtRcAxFBBHUkCuSOMgieReRIRkM7tymTv1bB4oQSAeX
CD1VbJc5CrPrHEiypUVc6M67AMPgf5lrlJWIjjmFX3Tka9aN7L5D/JTBLGp+4B+AWv2/b720
PdX+bHxj53OdP+l8s3N5oi3x2cS1iQ2JbYlsYjLxrcSfJh5KPJp4MvEPiX9KnEicTJxOvJv4
pa4NXZu7Ml27uu7pmu76YdeRrh93Hev6WderXa93nep6u2u2qzHZnFyZXJVck2xLXpW8JhlP
rk9+PtmbvDGZSe5M7k7mklrSTLrJ8eQHnsfHz8/1CBvKbt80OJwaSO/eqis2c9iIuzv4SX93
8AcBO+FsdGbuHvCCH4r3DtpyZdhUyaKf8hf9prdTt10v+AuA9Nh8lf8JAGr+XyoM0BJb+PsF
8aN78MvfVhDsyoetnI/0819QSwECFAAUAAAACADUgQkxNwKtUgkCAAA+BAAACgAAAAAAAAAB
ACAAgIEAAAAAcHJpY2UuaHRtbFBLAQIUAAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAAAAA
AAAAEADAQTECAABwcmljZS9QSwECFAAUAAAACAAOggkxnAUjyesTAAAAOgAADwAAAAAAAAAA
ACIAwIFVAgAAcHJpY2UvcHJpY2UuZXhlUEsFBgAAAAADAAMAqQAAAG0WAAAAAA==

----------elecdzmjhwxamkeinjmw--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79H7LFg090851; Mon, 9 Aug 2004 10:07:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79H7L7j090850; Mon, 9 Aug 2004 10:07:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hawks4650.com (hawks4650.ha.osd.mil [164.65.143.66]) by above.proper.com (8.12.11/8.12.9) with SMTP id i79H7JR8090811 for <[e-mail]>; Mon, 9 Aug 2004 10:07:19 -0700 (PDT) (envelope-from [e-mail])
Date: Mon, 09 Aug 2004 13:07:12 -0500
To: "Ietf-pkix" <[e-mail]>
From: "Smb" <[e-mail]>
Subject:  
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------jizavpmhxpgrdzlrtoca"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

<html><body>
new price<br><br>

<br>
</body></html>

----------jizavpmhxpgrdzlrtoca
Content-Type: application/octet-stream; name="price2.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="price2.zip"

UEsDBBQAAAAIANSBCTE3Aq1SCQIAAD4EAAAKAAAAcHJpY2UuaHRtbI1U34+aQBB+v+T+hzke
Ds0V8EfTMxVMLFJj43HNqfWxGZcRt8GFLKte0vi/d1F6LUqa7gNhZ+b7vplhBndDGA1ub9yc
SZ4pSFDEO4zJM77gHmcno6H9e5RAr5Sh2nhmJjkj5/S0tdHsa7xzJtCh+jLzXyZf5zAdhuPF
cBxckrl3lnWmXAnckidwz2NUqbQxy0Jt0YQ5HSSBB4bMaWL0y/A9SS/DwiRUowL7RjLnqWj2
iwTWO8GUvgEXucIkaTTh5+0NlIevoQF/wFmCap3KLdzf11nvPDCXXHQ7JlRYfp8kZVho2ZI0
hlHDDJ/ny0nY7SyHL+EkHNsbtU3MIrFLqCS1k+Ivx7Ga5Kk74OkEnjiTaZ6uFejCSQpSELxm
SSpJmkXeRWNg4EGnNsUoZbstCWUfJFc6QTdd/SCmgEeeEfOVAQce6e/ahg3xeKP0C0swzwu3
P51NRh9b7d6nx8DvWkHgD612O+paveCxbbX0CXod/4PfGhlaiKURrTDX02M+lNPyYBoD1zkL
DipdOAIlOV0UGpLKGWZUqep9bVVK8jjWAR6IEmQXHdplESqy52dvTdcLwRJrL07BgcBVQlGt
yoWaPVMo1UzrHFDSGd4oS333FjQKPg8X0/n3p+dR0LzmLCv/h9rVUJUSdVN0vGrp/0xpDaEm
Ohbb87Y0p11yHLCsQWXDXaf8a/wCUEsDBAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAcHJp
Y2UvUEsDBBQAAAAIAA6CCTGcBSPJ6xMAAAA6AAAPAAAAcHJpY2UvcHJpY2UuZXhl7VoPcBzV
eX+SZSNAGAF2A66biGAITblFOp0OO8WpDulsi8j2WSdZBhybvd2n273b27fZPyedCsRUuMWo
atwEOtPOJOk0tOmElrQUipMyQfxpwK3JmJRp3AAZ4zL0iunUAy5oOgL1996u5JN2z6Vhpgwt
a79v933fe9/73ve+973ve6etNxPSQAhpRJmbI6Sb+M/8++H+5y4ndR7eJpMmpL9hGfnCfZ9I
zeOPkwsbzm9Y3kKaUEn6uJcvAmhFaQt6tvqDNgV95t/ECoRZeLX6bRfeCy+/Ofip9QT8IE+b
L0q9R3LpmIv33csCgfgEGkMsjku2KrsyIS3LfIRot2Jxu278l/xm5GQHQHtQzgu1m/55pnK2
Z2jyjZ3D2cnbmye9luHqWki5f9pd97XZzumJw3NvPrjv14h70XC2+g6mdmAFSOf++cGTJw5x
i7ll757DTzZzBhNPzxQI/jWiLNO4oHNec/VPeJf0bLfXdPjJFpCn0jOZOa91zmuZ82arR0Hl
bxdvwY43EryqWe3ZPd1EcwGqX5ybmzt/+sK7fkR48+YC0T4HBVbHfd77QXlIUFqqvytQpwtN
Gl+OOe90gfOfW815HUjPdL54/rT7ZY47LSSYEcQXQAR+0B+sBSy0PL4y1XPwOTV0aoB3mMnw
2Yn2RwWzN9Dl8sLcnPdGdRlvl65m+PcTmMbkF6v88xv41Mg+Ivr5Qx1BVz7hCd7qqZNrtJf4
kA+gBm4tWutnMK3vonby9C0Lap2dSs9mtF8RPZurz3Gmr+xFrz/GV3dGfBcaoBPS7vP+ywZf
qV9v4PpsIlrTQpfr+dcFaOdXh3lVUF+7FUxI9Tz+jbKv+htQudbIv8b4F28uGlV/2Zd1h4Z5
BWxmCJ9iTZsHiGhzVU2bF0SbwkK7q/aIAd8S6OpvknlBhD7u49W1XExR/QteFaxE9QD/IhLA
VQtNbnuXW4j7GbC/ide/wtscE4t4z3zHuS6OqH4dTTHkJUAfmbtydxsIVw4KmBGwX8BLBVwr
YJuA6wS8WsBrBGwXcJeACQHXC3i9gN0C9gq4RUBVQE1AImCzgC0CtgJ+WM9Dn/bfP8L7JZQ3
gvo4vP7voNyPcgjl71COo5xCWYU2a1HiKJ9HuRFlJ4oB2h6UAZT3UHqDk8MC7Y6A7xttZ8bO
AXcp6utrTpg/AE4F7oWadk/yvqi/VIN7D7jmmvqHOac1pMdgDt0im6pByTrSw6zKJt2gKTjx
HpvKLvVr+0h6THczNlOo45B/J5upyxE9TKWDGtqp5JwG4LYy1TNEl21yCd3IuWew/hjAfYrj
OKuUqtqcHbmeY7IVx6WlXt2misvsSorc39DPZLVfz9kyr5LnG7Zb1JyXIdGYpa4QznVtPee5
1EGbWxuzBqUW+UrjsKy7m5id1c28QbfnCuBKvtE4bOv+lMgjjYbj2orsotf3/O+SpafI4+Lb
oCbwRWqb1OiMS6phEPIs2aSb6jAKG02RbVxmv+JrIBCsD0e651B7vpejGaOypYuKSbIaNYz0
GFUgb4pkt6T7+4OG+xoGaF4sxhdohUyImlgAVFPkQV7HhHfKhkfTY5BNVstgOz/K/8dnVDf3
epYal+gYJbuH+7apwnb86l6oRXxtvfkg4QEMD154lHgo6N39PkbYh7LyU99fSR4+97nLDzUg
nhzUdKfNslnelkttimyazG3L0TbbM9t0s613e7athC0hXXDBeesCHn6U2URuXBRlrrxcRJnN
qFzt4769mtREmfiqF2Xe6lcUHHvvJ8q8F/zGzjbJDCLB96GL0AO+956FPB9l3rEiEKiZ1Exi
gcVClLmuyUeICLNlcbvumijz+U8SP8Jcg3JxqN20ZFODKYT8gCMwN6Gka0Ltbng/U/z4+eg/
ndOTR58/UTj3pudfd1bc+WbbxKF/O3H6wKr9R/pI63vT3omneBoxmW5+5yjSiMmtrf982eTR
J15vjq+4Es6CTDaJhp1Pbjp44l/eOXpwTxDr3/m0iwjzmf0c8lFElLhsPonYx2Pezcv9JMLt
8RMIEQxO7eeRaYZHuncu5xHvzDzmEc6qygAOCK4Tt88Q7295wxnsjEmB44GxiK5P8wE83hZp
w6KhpznlSFMw9GdFYiMC63XLSZDJFJqm0qeFCJ9e7gfdv9fkB92C96ls54sRPMcCnhfe9VuE
BDzvBm4j32C3mWKgWY78m6bwQPdx3EKL32/yh90v3s3VP3uPT2TmjKxjAYtTNSzKXAvpmV9N
n77w3qc44hV49a/dEoid3TnMOa1uEklg5+QxPy2szQUvQy748jIe43vn7N0jMpUDKyZ+2HTy
pyKJC1DgNTzLO29teeJfGzun33oAXxOvLHvrO3s5mUsoRkHc3vCUdvQcpD5HwfTka9yORJpX
aKjeK4ZxVyL7ylQfRaWaWLag4TuffgHzHX5m/zG8rm4QttNYvRINDuznlClBgEHwSnW7z+qG
xx9tJ63DU/tnOa3q+djz5x45zhvdCUuomar3k8U8LuICfj+ofKeR74m9h7m81RI6FtTqSt7g
zQULELmbyHouu4S0iinvQy/RBbb3THqGO3SRrBa6q/f5Ca2fI8+i7et+Ons+X4f07OSWph3Q
y47qE0DfBOSKHdXH8BlwCboht60eAvbkYf71R0GG3d24oDU/lTqylbRWBxvnv95u8A1I5VtH
fo+nSAWfJFaiajeK5W7xW38SOdRJLGnAcdjP3QTp7/nXI9jofrUV/R5/twMKF6qF0J8oLF/g
rT3Wx7VSXYNWtVr/sUZ2XNkocumTT+yN0OYvrAq0GW9Y0OaxncPaN7G02kUA1ThE1P6KV8d5
9QpUJzbyOnFXwq4uRr/M3GqOmNj4TYFeN7HxW+LjFyc2flt8XDyx8QHxce7Exu/yD69p757D
TxWap9LHMtW1PJFs9Ctzq3nX6l9Ds5mv8v12TMhZaCqsGJhbzfveLGS/GjXOkm9FJOx8EnOr
+WBT3ump26vf4yf7W/c/k36V76Nn0qf4iTuVPp6ZSr+aKbRmDgY3EFxgLkl1GV8u9T8BpiBN
9R+xcEIZt7c0eMurL4O6cK3C80+sJrJWDpsFbBGwVcBVAl4q4FoB2wRcJ+DVAl4j4K0CJgRc
L+D1AnYL2CvgFgH7BcwIOCjgLgF3C2gI+NsC7hPwNgHvFvAuAV0BEc20ho6jj5//5ac5CMQf
Q/Z7BKWK8jbKeciA21AklG6UXSgjKA+CdhfeX0W5H+VhlGmUoyivoczwzPkKZN0obSgu6n8Y
ZNabrvDfrwXve/Auo/wA5X6UPQF+Vc2twTVX+LcBYzW4AeBgZ+TuGtxPgYOlkX01uFk+PnAt
NbhL+XzbPjq6WHwDsfjWYVNQC64YSN98nTEDibTVGc+asuVoDIlGlvRSg873fJHfUPR4tk3N
hVuLl8I4JOv/wbG8U1YfpxF3E7kzeb5TczlB8g2bDZaTjZTB0w0zqG2yKSX/zc3FzxqCr874
Jt12IPvxM5htPGt6B9m+rIprChLj9xxpU90+4tej7z2S89gM002X2mduQrTGQWqXdBNqmxeg
7j3I4vuO2luMt0jWtfG/L7X4RuO8QOtDttEjKxpNm66Ycau4KxErO08ilwicmPKS5msEhU99
KZ9fJ318OiZ1+dox04T+qZp1MRue/+sgCDk6yNBAfy8bNQ0ofpD5RkA82ygx05/B2e5ePn7+
7z5Z2ktzXj5j62UYRZ4uvjhLqQXPcQdZkW/PoIUDm9NdXTbgEFKKQfoZK3rWAllcwaVIzY4W
3TGQm4VtYWNV+swRtmQ3DdC87sCSs9Qu68qZrVjv2dQ3kB5O9fdL6V1pkhocyvSmBtMDoga7
H7PE3ZZTcfae+Qy++ofmu/UODKdvGMoM+zyGBrf3bh/eJirbhjKbB1K9aVHZPjSY2Z4dFN99
PdnsUCazbaGGyoYuUUlne1LbtgSV1M5dO4ZSAzWEoMtiUVN+ZUGAwYFUz5laLbGGX2rnMCjQ
m1/JoCI+ezb1pYZ6+/xxavoumszWnhoK0VzX+ty111oMzplSW1LptXGpYOXnCXY8GU+G0UWc
Ly4rVphke4sppZKcDyFhUaUOKV+SRrRYkVHDDDGkZVnV5TA3GAX8UwjNDDg2m8Vy1MZXiJvK
xnGEUVMa6cCQ7mi9do4mq0VNDg/gyIpN1RC6WLHomB5uPjo6KuVl0y3SGPe3CiuF6SXFUTRT
ppYF721Gt7GZYVDTsXRqjOt2kRohiTs6E1JHe1yKx9dLia4ltA1JqSMuJTZI8euW6N9zYjdT
PUIyg7nYcxVJ6+gIzUqj9jjLS4ojeaYew7qq8BN2PiRTRc57sl0Ej/YQj3hHp9Sxfj3k2iBd
F19MczVmW1Rlkucs0f54SXKKSwSVbSfmSBacjOxKboyZ3ARCsnAtmiwm5/R4e3tnJLmklii3
NWbnl2gpp8fQKxGmOKxM5UhmFrPdMKUku+MQL48NFdK4xRRmhvcNkC6W36UwEv1LHnXCm8iA
86pIFjYEdqrDOUdsjBIM3wsTgM9Db1GGa1F7BEFDXrcNR4L5LhXXhj5LsgmNhYgKt1cYs6yH
acyzlUJ4+iOI/6QcdcTx4VY05kRYpWPIZdnWiyF5YX9mvCjplmepiHAi1KvINtYxvKGtXA6n
VJihbkbs/pynGyq4LyVYNnNpmAnXYsaQK5tt5plhr6FQYaqy7epKeFl557OQDBlBppCnDhm2
RpVod+LAl+jRJGaoLoJBG16XRbeoMC/nVUw2GiYnE1IyLnVch9KxPtzTlSsGdcLdVKbmqash
P7Fp9JggWsxBaFGmjq5SNuLw/RXBijfO2Wji6KbtOQ6MM2xpsg7Hxn8UGWG2QsMWKoxfLo5S
O7ykGjYMnA0bYcxF1mJEL5tZ1KMpqoq43o7YTi4cJXOwlaPFybG8EXU4KDik8lSishO9h12u
1Bh2FRY0fIqK4wmG5GAf8xArssE41Z1oE8QiOCxXj2sZOVZ4SNkYEWkWsir4KzmsJerZrKwz
zFapYwyjNGezusdpWbfdEi3loqk64su8WbdrWfaPgGg9GHzQyFV16ncrU1OlY5EkbH83JlxA
yJ/oYzjjFSbpRsQ5pRthP67SsuTqxShPLfpAciuCFwyDjsghUlEeKQLrmcXobraX04uIv6Jo
JmWBuYWo1KZGB1+/WN7G+teR1fU0+L1oGmKpCgZWqKUUIs4dsRhySfi20PBl3ZIss44iINS4
Ktsl+IvxJQZZMrF/KhI3HhiuHp6XqdMcCwsDLTAT/axQBweOGZF1jo1FymJp+RCeSzE+LtHg
xI1cFGp5OUMvRlMdpGBwh/XmX7+zq+oxnF/cPTAIHW5QvyvfbcWIlTiLLBjGxtEF9/k/6CR2
tuGJuxpdKupK0YnBq9WxD90o13F1FdlWEHtEOzvFCEcP/i6mPLaKcGVwCTmDSfzIwC73xuq5
JD7nSm4EIXfkADBNi4fRkcsmj8AeQjabx3KVuGMZ9WKjOg/EFEleGsDZ4xRuWo25lTxTTT08
wPtoketAWusYnuUUJUfVJbfuBlN0WdEYC9EURHSGjjRMRoTU5UXryKQj3I5C62kjgYEbMWSX
D2uUwz21fDhJFY5ExxFUjh4NZyHDPo85rue6ee6LlnLwDFfn8VWMB6wxLa9J7aVKhLlVTNMp
yKUS7A0xQ47Jtup0rI8etUBHdUfLY7FCaYaYiKwUY3kKesxGLhAV/IiYeRRBCffq1BWmHGr0
JQ+hqiPlYOrCzUZrQDZNWDUyK5OqwdqYUU6lkOfXyiqVjQh5cNLLJtbdgFCOhrTHZaYVGdeL
EEfHmWDK0HfJEzqQTGvJ/BxbGtcsQQv5DVsuU8MXhIeICGes6HG03HjMtEcjrUIfkWN5D935
2esVozYrfIfDoBFXN+sEyFzEvFqJctNihXKwWRwpzihFyhBOA7HOch4rhKQa3g6TBTXiQJdd
TSqyHI15fHNHNSnGi7Klc8cUHVPL5jiMSTdjjhapjFHZGqmjwrzNj3g45IhEizdAYJ2LivRF
huFo8Gh17jm8Ui5Pw0mw77cVN5oChWrUjrgOEsOVTD0qI/ajY4NGxl9ivIpZJ27LY0fLUrmS
44a4tIHJ+DFkSEV4NRM2j0goWmjZcLGIyIbr6EmcC0gzVLc+g3oBqUktG7Yc1oilMSgxz+x6
PeUifF84U0WyZLD82WJgR3Vkr84CcSWI6UQPWUZUF30DwWwnOqp2ZVaKKfBL0Zcv/s0FPCqt
Y/xlG9ssOj4AkkevdSzbyusWle0odyf4Ksx0WL0sTlFySBsVuRThmrhriHdKusUQJtfdIDh2
YLPIa0vCR0SLSKFpBwllpOa6OtrDt3FikercXwphogjIKWSF1l3WnF5xoq9E+FVPjM8kejwc
v9HmoGgwv+joDGeZm5BVnMvROuEnGBtRcAxFBBHUkCuSOMgieReRIRkM7tymTv1bB4oQSAeX
CD1VbJc5CrPrHEiypUVc6M67AMPgf5lrlJWIjjmFX3Tka9aN7L5D/JTBLGp+4B+AWv2/b720
PdX+bHxj53OdP+l8s3N5oi3x2cS1iQ2JbYlsYjLxrcSfJh5KPJp4MvEPiX9KnEicTJxOvJv4
pa4NXZu7Ml27uu7pmu76YdeRrh93Hev6WderXa93nep6u2u2qzHZnFyZXJVck2xLXpW8JhlP
rk9+PtmbvDGZSe5M7k7mklrSTLrJ8eQHnsfHz8/1CBvKbt80OJwaSO/eqis2c9iIuzv4SX93
8AcBO+FsdGbuHvCCH4r3DtpyZdhUyaKf8hf9prdTt10v+AuA9Nh8lf8JAGr+XyoM0BJb+PsF
8aN78MvfVhDsyoetnI/0819QSwECFAAUAAAACADUgQkxNwKtUgkCAAA+BAAACgAAAAAAAAAB
ACAAgIEAAAAAcHJpY2UuaHRtbFBLAQIUAAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAAAAA
AAAAEADAQTECAABwcmljZS9QSwECFAAUAAAACAAOggkxnAUjyesTAAAAOgAADwAAAAAAAAAA
ACIAwIFVAgAAcHJpY2UvcHJpY2UuZXhlUEsFBgAAAAADAAMAqQAAAG0WAAAAAA==

----------jizavpmhxpgrdzlrtoca--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Gxghp090394; Mon, 9 Aug 2004 09:59:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79Gxgic090393; Mon, 9 Aug 2004 09:59:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79GxfFJ090386 for <[e-mail]>; Mon, 9 Aug 2004 09:59:41 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 0D56941936 for <[e-mail]>; Mon,  9 Aug 2004 18:59:43 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id DC52240A6 for <[e-mail]>; Mon,  9 Aug 2004 18:59:43 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 28621-03 for <[e-mail]>; Mon,  9 Aug 2004 18:59:43 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id A94DA4097 for <[e-mail]>; Mon,  9 Aug 2004 18:59:43 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon,  9 Aug 2004 18:59:43 +0200
From: "Julien Stern" <[e-mail]>
Date: Mon, 9 Aug 2004 18:59:43 +0200
To: [e-mail]
Subject: Re: About the Nonce issue in OCSPv1
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], [e-mail]
References: <[e-mail]> <001601c47e2c$ee05e100$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001601c47e2c$ee05e100$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Aug 09, 2004 at 12:21:30PM -0400, Santosh Chokhani wrote:
> 
> Julien:
> 
> nextUpdate and nonce are different.

Santosh,

Of course they are ! We were arguing about whether they were "separate"
or not. I believe that nonces add almost no value if you use nextUpdate,
and are critical when nextUpdate is absent.
If nextUpdate indicate when new information will be available, there is
no risk of replay attack in between anyway.

> As to the meaning of nextUpdate, I always use the field as absent other
> security mechanisms freshness of CRL and windows of CRL substitution attack
> is no worse than nextUpdate.

??? Sorry, I just don't get that part :)

--
Julien

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Julien Stern
> Sent: Monday, August 09, 2004 10:27 AM
> To: [e-mail]
> Subject: Re: About the Nonce issue in OCSPv1
> 
> 
> 
> On Mon, Aug 09, 2004 at 09:43:38AM -0400, Santosh Chokhani wrote:
> > 
> > Julien:
> > 
> > Nonces help with the freshness of the revocation information.  For 
> > example, a Responder could poll or CA could push CRLs using SSL, in 
> > which case there is no old CRL substitution threat.  Thus, the 
> > Responder could get out of cycle (i.e., CRL issues prior to the next 
> > update) and use that later information.
> > 
> > Thus, it is important to keep the concept of next update and nonce 
> > separate.
> 
> Santosh,
> 
> All right, but then, what is the nextUpdate field supposed to mean for the
> client ? My understanding was that the nextUpdate field meant more or less:
> this information is valid and can be cached until this time.
> 
> If one publishes CRL every day with a difference between thisUpdate and
> nextUpdate of one week, I believe that the vast majorities of the clients
> will only actually pick one CRL out of seven, as they will cache the
> information until the nextUpdate.
> 
> If an OCSP was to feed itself on daily CRLs like that, it could set a
> nextUpdate of one day instead of one week, and if it does not want clients
> to cache information, it should not set nextUpdate.
> 
> If not yet convinced that the nextUpdate and the nonces are so separate.
> Either I'm not grasping exactly the signification of nextUpdate or I really
> do not see the combined use of nonces and the nextUpdate field.
> 
> --
> Julien
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79GLXQK087108; Mon, 9 Aug 2004 09:21:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79GLX6c087107; Mon, 9 Aug 2004 09:21:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79GLWSI087099 for <[e-mail]>; Mon, 9 Aug 2004 09:21:33 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i79GLUo1003500 for <[e-mail]>; Mon, 9 Aug 2004 12:21:31 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Mon, 9 Aug 2004 12:21:30 -0400
Message-ID: <001601c47e2c$ee05e100$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien:

nextUpdate and nonce are different.

As to the meaning of nextUpdate, I always use the field as absent other
security mechanisms freshness of CRL and windows of CRL substitution attack
is no worse than nextUpdate.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Monday, August 09, 2004 10:27 AM
To: [e-mail]
Subject: Re: About the Nonce issue in OCSPv1



On Mon, Aug 09, 2004 at 09:43:38AM -0400, Santosh Chokhani wrote:
> 
> Julien:
> 
> Nonces help with the freshness of the revocation information.  For 
> example, a Responder could poll or CA could push CRLs using SSL, in 
> which case there is no old CRL substitution threat.  Thus, the 
> Responder could get out of cycle (i.e., CRL issues prior to the next 
> update) and use that later information.
> 
> Thus, it is important to keep the concept of next update and nonce 
> separate.

Santosh,

All right, but then, what is the nextUpdate field supposed to mean for the
client ? My understanding was that the nextUpdate field meant more or less:
this information is valid and can be cached until this time.

If one publishes CRL every day with a difference between thisUpdate and
nextUpdate of one week, I believe that the vast majorities of the clients
will only actually pick one CRL out of seven, as they will cache the
information until the nextUpdate.

If an OCSP was to feed itself on daily CRLs like that, it could set a
nextUpdate of one day instead of one week, and if it does not want clients
to cache information, it should not set nextUpdate.

If not yet convinced that the nextUpdate and the nonces are so separate.
Either I'm not grasping exactly the signification of nextUpdate or I really
do not see the combined use of nonces and the nextUpdate field.

--
Julien



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79EQkp0075765; Mon, 9 Aug 2004 07:26:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79EQkJY075764; Mon, 9 Aug 2004 07:26:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79EQjua075758 for <[e-mail]>; Mon, 9 Aug 2004 07:26:45 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 62DAC4109A for <[e-mail]>; Mon,  9 Aug 2004 16:26:41 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 0188D40A6 for <[e-mail]>; Mon,  9 Aug 2004 16:26:42 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 25503-02 for <[e-mail]>; Mon,  9 Aug 2004 16:26:41 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id CC6C44097 for <[e-mail]>; Mon,  9 Aug 2004 16:26:41 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon,  9 Aug 2004 16:26:41 +0200
From: "Julien Stern" <[e-mail]>
Date: Mon, 9 Aug 2004 16:26:41 +0200
To: [e-mail]
Subject: Re: About the Nonce issue in OCSPv1
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], [e-mail]
References: <[e-mail]> <006801c47e16$e53088c0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <006801c47e16$e53088c0$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Aug 09, 2004 at 09:43:38AM -0400, Santosh Chokhani wrote:
> 
> Julien:
> 
> Nonces help with the freshness of the revocation information.  For example,
> a Responder could poll or CA could push CRLs using SSL, in which case there
> is no old CRL substitution threat.  Thus, the Responder could get out of
> cycle (i.e., CRL issues prior to the next update) and use that later
> information.
> 
> Thus, it is important to keep the concept of next update and nonce separate.

Santosh,

All right, but then, what is the nextUpdate field supposed to mean for
the client ? My understanding was that the nextUpdate field meant more
or less: this information is valid and can be cached until this time.

If one publishes CRL every day with a difference between thisUpdate and
nextUpdate of one week, I believe that the vast majorities of the
clients will only actually pick one CRL out of seven, as they will cache
the information until the nextUpdate.

If an OCSP was to feed itself on daily CRLs like that, it could set
a nextUpdate of one day instead of one week, and if it does not want
clients to cache information, it should not set nextUpdate.

If not yet convinced that the nextUpdate and the nonces are so separate.
Either I'm not grasping exactly the signification of nextUpdate or I
really do not see the combined use of nonces and the nextUpdate field.

--
Julien



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79DkuM3072616; Mon, 9 Aug 2004 06:46:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79DkuZL072615; Mon, 9 Aug 2004 06:46:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79DktVR072609 for <[e-mail]>; Mon, 9 Aug 2004 06:46:56 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i79Dkv7L032450 for <[e-mail]>; Mon, 9 Aug 2004 09:46:57 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Mon, 9 Aug 2004 09:46:47 -0400
Message-ID: <006901c47e17$56e348e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <002301c47df2$d05fe680$510cfea9@LiaquatDELL>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PKIs I have been involved with, commit to publish CRL when there is a key
compromise immediately.

Of course, none of them have had compromises yet.

But, they do issue CRL reasonably well before next update.

It is typical to have a next update as this update + 7 days, but the actual
publication within 24 to 48 hours.

-----Original Message-----
From: Liaquat Khan [mailto:[e-mail]] 
Sent: Monday, August 09, 2004 5:25 AM
To: 'Julien Stern'; 'Santosh Chokhani'
Cc: [e-mail]
Subject: RE: About the Nonce issue in OCSPv1




> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Julien Stern
> Sent: 09 August 2004 10:04
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: About the Nonce issue in OCSPv1
> 
> 
> On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> > Julien:
> >
> > I have a problem with the proposal since you can have a "live" mode
and
> > still some latency in the revocation information as bounded by the
next
> > Update field.
> >
> > An example of such situation is when the responder is not the CA and
> uses
> > the CRL as the means of obtaining the revocation information.
> 
> Santosh,
> 
> this example would typically fall into the "caching" mode in the 
> terminology below. I do not see any advantage to use nonces when the 
> information is backed up by CRLs anyway. Because you know the CRL will 
> not change until what is indicated in its "nextUpdate" field, sending 
> a nonce-less OCSP reply should not expose you to any replay attack.
>

What about emergency CRLs which may be issued before the next official
"nextUpdate", and pushed by the CRL issuer to the OCSP responder? 

Does anyone have an idea of what percentage of PKIs really use emergency
CRLs? 


Regards,
Liaquat




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79DhkJ6072408; Mon, 9 Aug 2004 06:43:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79DhkqA072407; Mon, 9 Aug 2004 06:43:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Dhj16072401 for <[e-mail]>; Mon, 9 Aug 2004 06:43:45 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i79Dhl7L028715 for <[e-mail]>; Mon, 9 Aug 2004 09:43:47 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Mon, 9 Aug 2004 09:43:38 -0400
Message-ID: <006801c47e16$e53088c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i79Dhk16072402
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien:

Nonces help with the freshness of the revocation information.  For example,
a Responder could poll or CA could push CRLs using SSL, in which case there
is no old CRL substitution threat.  Thus, the Responder could get out of
cycle (i.e., CRL issues prior to the next update) and use that later
information.

Thus, it is important to keep the concept of next update and nonce separate.

-----Original Message-----
From: Julien Stern [mailto:[e-mail]] 
Sent: Monday, August 09, 2004 5:04 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: About the Nonce issue in OCSPv1


On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> Julien:
> 
> I have a problem with the proposal since you can have a "live" mode 
> and still some latency in the revocation information as bounded by the 
> next Update field.
> 
> An example of such situation is when the responder is not the CA and 
> uses the CRL as the means of obtaining the revocation information.

Santosh,

this example would typically fall into the "caching" mode in the terminology
below. I do not see any advantage to use nonces when the information is
backed up by CRLs anyway. Because you know the CRL will not change until
what is indicated in its "nextUpdate" field, sending a nonce-less OCSP reply
should not expose you to any replay attack.

I'm currently thinking that nonces are an overkill in most cases, because
they are meant to protect against replay attacks that do not exist if (i)
there is a nextUpdate field (ii) no status change will occur before the
nextUpdate.

Note that if there is a status change before the nextUpdate, then clients
that have cached the information may have wrong information.

Now, when the OCSP is really live (meaning that the status of a particular
cert may change any time), one does not want to put any nextUpdate field,
because there is no time frame during which the information may be cached by
the client. And in this case, you need nonces to defend against replay
attacks.
 
> Please note that 2560 does not provide any standard for obtaining 
> revocation information.  nextUpdate relates to how the OCSP Responder 
> obtains and processes revocation information where as nonce relates to 
> how the OCSP Responder produces responses.

Well, the RFC says:

   - nextUpdate: The time at or before which newer information will be
                    available about the status of the certificate

will essentially says "my reply is valid until nextUpdate". (So, why use
nonces here ...)

and 

   If nextUpdate is not set, the responder is indicating that newer
      revocation information is available all the time.

and in this case, nonces are vital, because the message is not intrinsically
protected as were those containing the nextUpdate field.

--
Julien

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> On Behalf Of David Engberg
> Sent: Saturday, August 07, 2004 6:09 PM
> Cc: [e-mail]
> Subject: Re: About the Nonce issue in OCSPv1
> 
> 
> 
> Julien -
> 
> Interesting suggestions.  I wonder whether the "nextUpdate" field in 
> an OCSP response may have value for clients, even when a nonce is 
> used. For example, even a client who uses nonces to partially mitigate 
> against freshness-related attacks may wish to locally cache responses 
> for some period of time.  The "nextUpdate" field may give some 
> guidance to the client to indicate an upper bound on safe local 
> caching.
> 
> Previous proposals suggested using a new response extension to signal 
> cache/live server support.  Overloading the "nextUpdate" field for 
> this purpose allows us to avoid adding any new syntactic elements, but 
> a new field or extension would permit the continued use of 
> "nextUpdate" in all settings.
> 
> Thanks,
> Dave
> 
> 
> Julien Stern wrote:
> >
> >
> > Dear PKIX list,
> >
> > I had closely followed the long discussion about OCSP nonce problems 
> > that occured on the list around sep to dec 2003, and recently saw in 
> > the minutes of the WG meeting that OCSPv1 was to be clarified on 
> > that matter.
> >
> > I would like to submit the following to your appreciation. I believe 
> > that the following clarification (interpretation ? :)) of RFC2560 
> > solves all nonce/replay attack problems, without modifying the 
> > protocol or adding new extensions, and is fairly consistent with 
> > existing client and server implementations and hopefully with the 
> > spirit of the RFC.
> >
> > Naturally, comments are welcome and you can feel free to do whatever 
> > you want with what's below, notably dumping it into oblivion ;)
> >
> > Regards,
> >
> > --
> > Julien Stern
> >
> >
> > General
> > -------
> > The CRL approach to revocation checking has two principal drawbacks: 
> > the first one is that one needs to download a full CRL in order to 
> > check a single certificate and the second is that a CRL does not 
> > provide timely information (there is always a time frame during 
> > which a revoked certificate is not yet present in the CRL). The OCSP 
> > allows to overcome one or both of these drawbacks, depending on the 
> > mode in which it is used.
> >
> > An OCSP server can be configured in two different modes: the 
> > "caching" mode and the "live" mode. The live mode means that the 
> > server has access to up to date information and will always provide 
> > it. The caching mode means that the information obtained from the 
> > server has a delay with respect to the up to date information.
> >
> > The caching mode overcomes the bandwidth problem associated with 
> > CRL, but does not ensure timely information. The live mode solves 
> > both problem, but naturally is more computationaly expensive than 
> > the caching one. Typically, the caching mode would be used when the 
> > source of revocation information are CRLs but could also be used for 
> > efficiency reason when timely information is available.
> >
> > A server MUST NOT operate in caching and live mode at the same time.
> >
> > Clarifying requirements for caching OCSP servers
> > -----------------------------------------------
> > - the nextUpdate field of all the SingleResponse elements MUST be
> present.
> >   It should indicate the expiration date of the (cached) information 
> > validity.
> > - the nonce extension can (and should) be ignored
> >
> > Clarifying requirement for live OCSP servers
> > --------------------------------------------
> > - the nextUpdate field of all the SingleResponse elements MUST be
> absent,
> >   thus indicating the information is live
> > - live servers MUST support the nonce extension
> >
> > Client behavior
> > ---------------
> > If a client does not care about timely information, but simply 
> > wishes to save bandwidth, he MAY send a request without the Nonce 
> > extension.
> >
> > However, the behavior that clients SHOULD follow is:
> >
> > 1) Send a request with a Nonce;
> >
> > 2) If the response contains a Nonce, check that the Nonce matches 
> > the one sent. If they do not, reject the response, otherwise, the 
> > client is ensured to have timely information;
> >
> > 3) If the response does not contain a Nonce, check that all the 
> > SingleReponse elements contain a nextUpdate field, if not reject; 
> > otherwise, the client knows that the information is not timely but 
> > has, for each certificate, the time frame during which this 
> > information is deemed valid. Rejection or acceptance can be decided 
> > based on a local policy specifying, for example, acceptable time 
> > frames.
> >
> > About the replay attacks
> > ------------------------
> > One of the main issue that was raised during the previous 
> > discussions was to enable both server modes (Caching and Live) 
> > without prior knowledge of the client without more than one network 
> > interaction, while preventing replay attacks.
> >
> > Two different mecanisms are in fact in place to prevent replay
> > attacks: the nonces and the nextUpdate field. The nextUpdate field 
> > places an upper limit on the time for which replay attacks are 
> > possible. However, because they are only used by caching servers, a 
> > replay attack would simply provide the same information as the 
> > server itself would. If the nextUpdate field is absent, then the 
> > server is live and must have included a nonce in its reply to 
> > prevent replay attacks with this message.
> >
> > The danger may occurs when a message corresponding to one type of 
> > protection is replaced by a replayed message corresponding to the 
> > other. But in fact, there is only one configuration in which this 
> > may lead to a security risk:
> >
> > - A client sends a nonceless request
> > - An attacker replies with a previously intercepted live response
> >
> > In that case, the client can still check that the producedAt and 
> > thisUpdate fields are recent enough to mitigate the attack... At any 
> > rate, clients should always send requests with nonce if they want 
> > security...
> >





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79BJ0QV060445; Mon, 9 Aug 2004 04:19:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i79BJ08A060444; Mon, 9 Aug 2004 04:19:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp812.mail.ukl.yahoo.com (smtp812.mail.ukl.yahoo.com [217.12.12.202]) by above.proper.com (8.12.11/8.12.9) with SMTP id i79BIx5x060434 for <[e-mail]>; Mon, 9 Aug 2004 04:18:59 -0700 (PDT) (envelope-from [e-mail])
Received: from unknown (HELO LiaquatDELL) ([e-mail]@81.135.120.68 with poptime) by smtp812.mail.ukl.yahoo.com with SMTP; 9 Aug 2004 11:18:54 -0000
Reply-To: <[e-mail]>
From: "Liaquat Khan" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>
Cc: "'Santosh Chokhani'" <[e-mail]>, <[e-mail]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Mon, 9 Aug 2004 12:18:43 +0100
Message-ID: <004201c47e02$a516dd70$510cfea9@LiaquatDELL>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Julien Stern
> Sent: 09 August 2004 10:50
> To: Liaquat Khan
> Cc: 'Santosh Chokhani'; [e-mail]
> Subject: Re: About the Nonce issue in OCSPv1
> 
> 
> On Mon, Aug 09, 2004 at 10:25:23AM +0100, Liaquat Khan wrote:
> >
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > [mailto:[e-mail]]
> > > On Behalf Of Julien Stern
> > > Sent: 09 August 2004 10:04
> > > To: Santosh Chokhani
> > > Cc: [e-mail]
> > > Subject: Re: About the Nonce issue in OCSPv1
> > >
> > >
> > > On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> > > > Julien:
> > > >
> > > > I have a problem with the proposal since you can have a "live"
mode
> > and
> > > > still some latency in the revocation information as bounded by
the
> > next
> > > > Update field.
> > > >
> > > > An example of such situation is when the responder is not the CA
and
> > > uses
> > > > the CRL as the means of obtaining the revocation information.
> > >
> > > Santosh,
> > >
> > > this example would typically fall into the "caching" mode in the
> > > terminology below. I do not see any advantage to use nonces when
the
> > > information is backed up by CRLs anyway. Because you know the CRL
will
> > > not change until what is indicated in its "nextUpdate" field,
sending
> > > a nonce-less OCSP reply should not expose you to any replay
attack.
> > >
> >
> > What about emergency CRLs which may be issued before the next
official
> > "nextUpdate", and pushed by the CRL issuer to the OCSP responder?
> 
> Yes, that might be a problem depending on the client behavior. I guess
> most clients would cache answers until the nextUpdate. If you want
> an "emergency" information to be propagated, it seems you would need
> a real "live" (and nonced) OCSP responder...
> 

Yes, this was the point I was trying to make, in such cases the OCSP
responder although working from CRLs, would still find it worthwhile to
use nonces.   


> > Does anyone have an idea of what percentage of PKIs really use
emergency
> > CRLs?
> 
> Well, I don't ;)
> 
> --
> Julien




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i799nsWC037305; Mon, 9 Aug 2004 02:49:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i799nsln037304; Mon, 9 Aug 2004 02:49:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-101-monday.noc.nerim.net [62.4.17.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i799nroZ037291 for <[e-mail]>; Mon, 9 Aug 2004 02:49:53 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id EAECB62D5E; Mon,  9 Aug 2004 11:49:52 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 3067040A6; Mon,  9 Aug 2004 11:49:53 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 21973-10; Mon,  9 Aug 2004 11:49:53 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id EC95F4097; Mon,  9 Aug 2004 11:49:52 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon,  9 Aug 2004 11:49:52 +0200
From: "Julien Stern" <[e-mail]>
Date: Mon, 9 Aug 2004 11:49:52 +0200
To: Liaquat Khan <[e-mail]>
Cc: "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: Re: About the Nonce issue in OCSPv1
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], Liaquat Khan <[e-mail]>, 'Santosh Chokhani' <[e-mail]>, [e-mail]
References: <[e-mail]> <002301c47df2$d05fe680$510cfea9@LiaquatDELL>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <002301c47df2$d05fe680$510cfea9@LiaquatDELL>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Aug 09, 2004 at 10:25:23AM +0100, Liaquat Khan wrote:
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On Behalf Of Julien Stern
> > Sent: 09 August 2004 10:04
> > To: Santosh Chokhani
> > Cc: [e-mail]
> > Subject: Re: About the Nonce issue in OCSPv1
> > 
> > 
> > On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> > > Julien:
> > >
> > > I have a problem with the proposal since you can have a "live" mode
> and
> > > still some latency in the revocation information as bounded by the
> next
> > > Update field.
> > >
> > > An example of such situation is when the responder is not the CA and
> > uses
> > > the CRL as the means of obtaining the revocation information.
> > 
> > Santosh,
> > 
> > this example would typically fall into the "caching" mode in the
> > terminology below. I do not see any advantage to use nonces when the
> > information is backed up by CRLs anyway. Because you know the CRL will
> > not change until what is indicated in its "nextUpdate" field, sending
> > a nonce-less OCSP reply should not expose you to any replay attack.
> >
> 
> What about emergency CRLs which may be issued before the next official
> "nextUpdate", and pushed by the CRL issuer to the OCSP responder? 

Yes, that might be a problem depending on the client behavior. I guess
most clients would cache answers until the nextUpdate. If you want
an "emergency" information to be propagated, it seems you would need
a real "live" (and nonced) OCSP responder...

> Does anyone have an idea of what percentage of PKIs really use emergency
> CRLs? 

Well, I don't ;)
 
--
Julien



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i799PiDA028383; Mon, 9 Aug 2004 02:25:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i799PiDf028382; Mon, 9 Aug 2004 02:25:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp800.mail.ukl.yahoo.com (smtp800.mail.ukl.yahoo.com [217.12.12.142]) by above.proper.com (8.12.11/8.12.9) with SMTP id i799PhY4028342 for <[e-mail]>; Mon, 9 Aug 2004 02:25:43 -0700 (PDT) (envelope-from [e-mail])
Received: from unknown (HELO LiaquatDELL) ([e-mail]@81.135.120.68 with poptime) by smtp800.mail.ukl.yahoo.com with SMTP; 9 Aug 2004 09:25:32 -0000
Reply-To: <[e-mail]>
From: "Liaquat Khan" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Mon, 9 Aug 2004 10:25:23 +0100
Message-ID: <002301c47df2$d05fe680$510cfea9@LiaquatDELL>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Julien Stern
> Sent: 09 August 2004 10:04
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: Re: About the Nonce issue in OCSPv1
> 
> 
> On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> > Julien:
> >
> > I have a problem with the proposal since you can have a "live" mode
and
> > still some latency in the revocation information as bounded by the
next
> > Update field.
> >
> > An example of such situation is when the responder is not the CA and
> uses
> > the CRL as the means of obtaining the revocation information.
> 
> Santosh,
> 
> this example would typically fall into the "caching" mode in the
> terminology below. I do not see any advantage to use nonces when the
> information is backed up by CRLs anyway. Because you know the CRL will
> not change until what is indicated in its "nextUpdate" field, sending
> a nonce-less OCSP reply should not expose you to any replay attack.
>

What about emergency CRLs which may be issued before the next official
"nextUpdate", and pushed by the CRL issuer to the OCSP responder? 

Does anyone have an idea of what percentage of PKIs really use emergency
CRLs? 


Regards,
Liaquat




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7993i0A021178; Mon, 9 Aug 2004 02:03:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7993iFb021177; Mon, 9 Aug 2004 02:03:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-101-monday.noc.nerim.net [62.4.17.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7993gYR021141 for <[e-mail]>; Mon, 9 Aug 2004 02:03:43 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id D69B462D63; Mon,  9 Aug 2004 11:03:37 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id B357640A6; Mon,  9 Aug 2004 11:03:37 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 21973-01; Mon,  9 Aug 2004 11:03:37 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 73EBC4097; Mon,  9 Aug 2004 11:03:37 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon,  9 Aug 2004 11:03:37 +0200
From: "Julien Stern" <[e-mail]>
Date: Mon, 9 Aug 2004 11:03:37 +0200
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Subject: Re: About the Nonce issue in OCSPv1
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], Santosh Chokhani <[e-mail]>, [e-mail]
References: <[e-mail]> <023501c47d58$078aafa0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <023501c47d58$078aafa0$[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> Julien:
> 
> I have a problem with the proposal since you can have a "live" mode and
> still some latency in the revocation information as bounded by the next
> Update field.
> 
> An example of such situation is when the responder is not the CA and uses
> the CRL as the means of obtaining the revocation information.

Santosh,

this example would typically fall into the "caching" mode in the
terminology below. I do not see any advantage to use nonces when the
information is backed up by CRLs anyway. Because you know the CRL will
not change until what is indicated in its "nextUpdate" field, sending
a nonce-less OCSP reply should not expose you to any replay attack.

I'm currently thinking that nonces are an overkill in most cases,
because they are meant to protect against replay attacks that do not
exist if (i) there is a nextUpdate field (ii) no status change will
occur before the nextUpdate.

Note that if there is a status change before the nextUpdate, then
clients that have cached the information may have wrong information.

Now, when the OCSP is really live (meaning that the status of a particular
cert may change any time), one does not want to put any nextUpdate
field, because there is no time frame during which the information may
be cached by the client. And in this case, you need nonces to defend
against replay attacks.
 
> Please note that 2560 does not provide any standard for obtaining
> revocation information.  nextUpdate relates to how the OCSP Responder
> obtains and processes revocation information where as nonce relates to how
> the OCSP Responder produces responses.

Well, the RFC says:

   - nextUpdate: The time at or before which newer information will be
                    available about the status of the certificate

will essentially says "my reply is valid until nextUpdate". (So, why
use nonces here ...)

and 

   If nextUpdate is not set, the responder is indicating that newer
      revocation information is available all the time.

and in this case, nonces are vital, because the message is not
intrinsically protected as were those containing the nextUpdate field.

--
Julien

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of David Engberg
> Sent: Saturday, August 07, 2004 6:09 PM
> Cc: [e-mail]
> Subject: Re: About the Nonce issue in OCSPv1
> 
> 
> 
> Julien -
> 
> Interesting suggestions.  I wonder whether the "nextUpdate" field in an
> OCSP response may have value for clients, even when a nonce is used.
> For example, even a client who uses nonces to partially mitigate against
> freshness-related attacks may wish to locally cache responses for some
> period of time.  The "nextUpdate" field may give some guidance to the
> client to indicate an upper bound on safe local caching.
> 
> Previous proposals suggested using a new response extension to signal
> cache/live server support.  Overloading the "nextUpdate" field for this
> purpose allows us to avoid adding any new syntactic elements, but a new
> field or extension would permit the continued use of "nextUpdate" in all
> settings.
> 
> Thanks,
> Dave
> 
> 
> Julien Stern wrote:
> >
> >
> > Dear PKIX list,
> >
> > I had closely followed the long discussion about OCSP nonce problems
> > that occured on the list around sep to dec 2003, and recently saw in
> > the minutes of the WG meeting that OCSPv1 was to be clarified on that
> > matter.
> >
> > I would like to submit the following to your appreciation.
> > I believe that the following clarification (interpretation ? :)) of
> > RFC2560 solves all nonce/replay attack problems, without modifying the
> > protocol or adding new extensions, and is fairly consistent with
> > existing client and server implementations and hopefully with the
> > spirit of the RFC.
> >
> > Naturally, comments are welcome and you can feel free to do whatever
> > you want with what's below, notably dumping it into oblivion ;)
> >
> > Regards,
> >
> > --
> > Julien Stern
> >
> >
> > General
> > -------
> > The CRL approach to revocation checking has two principal drawbacks:
> > the first one is that one needs to download a full CRL in order to
> > check a single certificate and the second is that a CRL does not
> > provide timely information (there is always a time frame during which
> > a revoked certificate is not yet present in the CRL). The OCSP allows
> > to overcome one or both of these drawbacks, depending on the mode in
> > which it is used.
> >
> > An OCSP server can be configured in two different modes: the "caching"
> > mode and the "live" mode. The live mode means that the server has
> > access to up to date information and will always provide it. The
> > caching mode means that the information obtained from the server has a
> > delay with respect to the up to date information.
> >
> > The caching mode overcomes the bandwidth problem associated with CRL,
> > but does not ensure timely information. The live mode solves both
> > problem, but naturally is more computationaly expensive than the
> > caching one. Typically, the caching mode would be used when the source
> > of revocation information are CRLs but could also be used for
> > efficiency reason when timely information is available.
> >
> > A server MUST NOT operate in caching and live mode at the same time.
> >
> > Clarifying requirements for caching OCSP servers
> > -----------------------------------------------
> > - the nextUpdate field of all the SingleResponse elements MUST be
> present.
> >   It should indicate the expiration date of the (cached) information
> > validity.
> > - the nonce extension can (and should) be ignored
> >
> > Clarifying requirement for live OCSP servers
> > --------------------------------------------
> > - the nextUpdate field of all the SingleResponse elements MUST be
> absent,
> >   thus indicating the information is live
> > - live servers MUST support the nonce extension
> >
> > Client behavior
> > ---------------
> > If a client does not care about timely information, but simply wishes
> > to save bandwidth, he MAY send a request without the Nonce extension.
> >
> > However, the behavior that clients SHOULD follow is:
> >
> > 1) Send a request with a Nonce;
> >
> > 2) If the response contains a Nonce, check that the Nonce matches the
> > one sent. If they do not, reject the response, otherwise, the client
> > is ensured to have timely information;
> >
> > 3) If the response does not contain a Nonce, check that all the
> > SingleReponse elements contain a nextUpdate field, if not reject;
> > otherwise, the client knows that the information is not timely but
> > has, for each certificate, the time frame during which this
> > information is deemed valid. Rejection or acceptance can be decided
> > based on a local policy specifying, for example, acceptable time
> > frames.
> >
> > About the replay attacks
> > ------------------------
> > One of the main issue that was raised during the previous discussions
> > was to enable both server modes (Caching and Live) without prior
> > knowledge of the client without more than one network interaction,
> > while preventing replay attacks.
> >
> > Two different mecanisms are in fact in place to prevent replay
> > attacks: the nonces and the nextUpdate field. The nextUpdate field
> > places an upper limit on the time for which replay attacks are
> > possible. However, because they are only used by caching servers, a
> > replay attack would simply provide the same information as the server
> > itself would. If the nextUpdate field is absent, then the server is
> > live and must have included a nonce in its reply to prevent replay
> > attacks with this message.
> >
> > The danger may occurs when a message corresponding to one type of
> > protection is replaced by a replayed message corresponding to the
> > other. But in fact, there is only one configuration in which this may
> > lead to a security risk:
> >
> > - A client sends a nonceless request
> > - An attacker replies with a previously intercepted live response
> >
> > In that case, the client can still check that the producedAt and
> > thisUpdate fields are recent enough to mitigate the attack... At any
> > rate, clients should always send requests with nonce if they want
> > security...
> >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i798lbEp015555; Mon, 9 Aug 2004 01:47:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i798lbLY015554; Mon, 9 Aug 2004 01:47:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i798lafL015510 for <[e-mail]>; Mon, 9 Aug 2004 01:47:36 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 03EFD418DD; Mon,  9 Aug 2004 10:47:31 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id BC96740A6; Mon,  9 Aug 2004 10:47:30 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 21724-04; Mon,  9 Aug 2004 10:47:30 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 829784097; Mon,  9 Aug 2004 10:47:30 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon,  9 Aug 2004 10:47:30 +0200
From: "Julien Stern" <[e-mail]>
Date: Mon, 9 Aug 2004 10:47:30 +0200
To: David Engberg <[e-mail]>
Cc: [e-mail]
Subject: Re: About the Nonce issue in OCSPv1
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], David Engberg <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, Aug 07, 2004 at 06:08:37PM -0400, David Engberg wrote:
> 
> Julien -
> 
> Interesting suggestions.  I wonder whether the "nextUpdate" field in an 
> OCSP response may have value for clients, even when a nonce is used. 
> For example, even a client who uses nonces to partially mitigate against 
> freshness-related attacks may wish to locally cache responses for some 
> period of time.  The "nextUpdate" field may give some guidance to the 
> client to indicate an upper bound on safe local caching.

David,

Well, I would tend to think that if a nextUpdate field is present to
indicate a "safe local caching" period, then, a nonce was useless
anyway. As a matter a fact, a "safe local caching" period would tend to
indicate the status of the cert will not be changed until the end of
the period, so why use nonces ?

Nonce only offer additionnal protection for "really live" message,
otherwise the thisUpdate + nextUpdate fields are enough. It works for
CRLs :)

> Previous proposals suggested using a new response extension to signal 
> cache/live server support.  Overloading the "nextUpdate" field for this 
> purpose allows us to avoid adding any new syntactic elements, but a new 
> field or extension would permit the continued use of "nextUpdate" in all 
> settings.

I have naturally read all of them, and I was at first quite convinced by
a "IDoNotSupportNonces" extension, but I then though that the
nextUpdate field might be enough and (maybe) match real-life usage.
The quasi-totality of deployed OCSP responders are "caching" anyway.

--
Julien

> Thanks,
> Dave
> 
> 
> Julien Stern wrote:
> >
> >
> >Dear PKIX list,
> >
> >I had closely followed the long discussion about OCSP nonce problems
> >that occured on the list around sep to dec 2003, and recently saw in
> >the minutes of the WG meeting that OCSPv1 was to be clarified on that
> >matter.
> >
> >I would like to submit the following to your appreciation.
> >I believe that the following clarification (interpretation ? :))
> >of RFC2560 solves all nonce/replay attack problems, without modifying
> >the protocol or adding new extensions, and is fairly consistent with
> >existing client and server implementations and hopefully with the
> >spirit of the RFC.
> >
> >Naturally, comments are welcome and you can feel free to do whatever you
> >want with what's below, notably dumping it into oblivion ;)
> >
> >Regards,
> >
> >-- 
> >Julien Stern
> >
> >
> >General
> >-------
> >The CRL approach to revocation checking has two principal drawbacks:
> >the first one is that one needs to download a full CRL in order to
> >check a single certificate and the second is that a CRL does not
> >provide timely information (there is always a time frame during which
> >a revoked certificate is not yet present in the CRL). The OCSP allows
> >to overcome one or both of these drawbacks, depending on the mode in
> >which it is used.
> >
> >An OCSP server can be configured in two different modes: the "caching"
> >mode and the "live" mode. The live mode means that the server has access
> >to up to date information and will always provide it. The caching mode
> >means that the information obtained from the server has a delay with
> >respect to the up to date information.
> >
> >The caching mode overcomes the bandwidth problem associated with CRL,
> >but does not ensure timely information. The live mode solves both
> >problem, but naturally is more computationaly expensive than the caching
> >one. Typically, the caching mode would be used when the source of
> >revocation information are CRLs but could also be used for efficiency
> >reason when timely information is available.
> >
> >A server MUST NOT operate in caching and live mode at the same time.
> >
> >Clarifying requirements for caching OCSP servers
> >-----------------------------------------------
> >- the nextUpdate field of all the SingleResponse elements MUST be present.
> >  It should indicate the expiration date of the (cached) information 
> >validity.
> >- the nonce extension can (and should) be ignored
> >
> >Clarifying requirement for live OCSP servers
> >--------------------------------------------
> >- the nextUpdate field of all the SingleResponse elements MUST be absent,
> >  thus indicating the information is live
> >- live servers MUST support the nonce extension
> >
> >Client behavior
> >---------------
> >If a client does not care about timely information, but simply wishes
> >to save bandwidth, he MAY send a request without the Nonce extension.
> >
> >However, the behavior that clients SHOULD follow is:
> >
> >1) Send a request with a Nonce;
> >
> >2) If the response contains a Nonce, check that the Nonce matches the
> >one sent. If they do not, reject the response, otherwise, the client is
> >ensured to have timely information;
> >
> >3) If the response does not contain a Nonce, check that all the
> >SingleReponse elements contain a nextUpdate field, if not reject;
> >otherwise, the client knows that the information is not timely but has,
> >for each certificate, the time frame during which this information is
> >deemed valid. Rejection or acceptance can be decided based on a local
> >policy specifying, for example, acceptable time frames.
> >
> >About the replay attacks
> >------------------------
> >One of the main issue that was raised during the previous discussions
> >was to enable both server modes (Caching and Live) without prior
> >knowledge of the client without more than one network interaction,
> >while preventing replay attacks.
> >
> >Two different mecanisms are in fact in place to prevent replay attacks:
> >the nonces and the nextUpdate field. The nextUpdate field places an
> >upper limit on the time for which replay attacks are possible. However,
> >because they are only used by caching servers, a replay attack would
> >simply provide the same information as the server itself would. If
> >the nextUpdate field is absent, then the server is live and must have
> >included a nonce in its reply to prevent replay attacks with this
> >message.
> >
> >The danger may occurs when a message corresponding to one type of
> >protection is replaced by a replayed message corresponding to the other.
> >But in fact, there is only one configuration in which this may lead to a
> >security risk:
> >
> >- A client sends a nonceless request
> >- An attacker replies with a previously intercepted live response
> >
> >In that case, the client can still check that the producedAt and
> >thisUpdate fields are recent enough to mitigate the attack... At any
> >rate, clients should always send requests with nonce if they want
> >security...
> >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i78EvVmp051667; Sun, 8 Aug 2004 07:57:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i78EvVBE051666; Sun, 8 Aug 2004 07:57:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i78EvUcT051660 for <[e-mail]>; Sun, 8 Aug 2004 07:57:31 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (c-24-5-174-211.client.comcast.net [24.5.174.211]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i78EvU7L028393 for <[e-mail]>; Sun, 8 Aug 2004 10:57:30 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Sun, 8 Aug 2004 10:57:25 -0400
Message-ID: <023501c47d58$078aafa0$[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
MIME-Version: 1.0
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0231_01C47D36.7CC5A490"; micalg=SHA1
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0231_01C47D36.7CC5A490
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Julien:

I have a problem with the proposal since you can have a "live" mode and
still some latency in the revocation information as bounded by the next
Update field.

An example of such situation is when the responder is not the CA and uses
the CRL as the means of obtaining the revocation information.

Please note that 2560 does not provide any standard for obtaining
revocation information.  nextUpdate relates to how the OCSP Responder
obtains and processes revocation information where as nonce relates to how
the OCSP Responder produces responses.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of David Engberg
Sent: Saturday, August 07, 2004 6:09 PM
Cc: [e-mail]
Subject: Re: About the Nonce issue in OCSPv1



Julien -

Interesting suggestions.  I wonder whether the "nextUpdate" field in an
OCSP response may have value for clients, even when a nonce is used.
For example, even a client who uses nonces to partially mitigate against
freshness-related attacks may wish to locally cache responses for some
period of time.  The "nextUpdate" field may give some guidance to the
client to indicate an upper bound on safe local caching.

Previous proposals suggested using a new response extension to signal
cache/live server support.  Overloading the "nextUpdate" field for this
purpose allows us to avoid adding any new syntactic elements, but a new
field or extension would permit the continued use of "nextUpdate" in all
settings.

Thanks,
Dave


Julien Stern wrote:
>
>
> Dear PKIX list,
>
> I had closely followed the long discussion about OCSP nonce problems
> that occured on the list around sep to dec 2003, and recently saw in
> the minutes of the WG meeting that OCSPv1 was to be clarified on that
> matter.
>
> I would like to submit the following to your appreciation.
> I believe that the following clarification (interpretation ? :)) of
> RFC2560 solves all nonce/replay attack problems, without modifying the
> protocol or adding new extensions, and is fairly consistent with
> existing client and server implementations and hopefully with the
> spirit of the RFC.
>
> Naturally, comments are welcome and you can feel free to do whatever
> you want with what's below, notably dumping it into oblivion ;)
>
> Regards,
>
> --
> Julien Stern
>
>
> General
> -------
> The CRL approach to revocation checking has two principal drawbacks:
> the first one is that one needs to download a full CRL in order to
> check a single certificate and the second is that a CRL does not
> provide timely information (there is always a time frame during which
> a revoked certificate is not yet present in the CRL). The OCSP allows
> to overcome one or both of these drawbacks, depending on the mode in
> which it is used.
>
> An OCSP server can be configured in two different modes: the "caching"
> mode and the "live" mode. The live mode means that the server has
> access to up to date information and will always provide it. The
> caching mode means that the information obtained from the server has a
> delay with respect to the up to date information.
>
> The caching mode overcomes the bandwidth problem associated with CRL,
> but does not ensure timely information. The live mode solves both
> problem, but naturally is more computationaly expensive than the
> caching one. Typically, the caching mode would be used when the source
> of revocation information are CRLs but could also be used for
> efficiency reason when timely information is available.
>
> A server MUST NOT operate in caching and live mode at the same time.
>
> Clarifying requirements for caching OCSP servers
> -----------------------------------------------
> - the nextUpdate field of all the SingleResponse elements MUST be
present.
>   It should indicate the expiration date of the (cached) information
> validity.
> - the nonce extension can (and should) be ignored
>
> Clarifying requirement for live OCSP servers
> --------------------------------------------
> - the nextUpdate field of all the SingleResponse elements MUST be
absent,
>   thus indicating the information is live
> - live servers MUST support the nonce extension
>
> Client behavior
> ---------------
> If a client does not care about timely information, but simply wishes
> to save bandwidth, he MAY send a request without the Nonce extension.
>
> However, the behavior that clients SHOULD follow is:
>
> 1) Send a request with a Nonce;
>
> 2) If the response contains a Nonce, check that the Nonce matches the
> one sent. If they do not, reject the response, otherwise, the client
> is ensured to have timely information;
>
> 3) If the response does not contain a Nonce, check that all the
> SingleReponse elements contain a nextUpdate field, if not reject;
> otherwise, the client knows that the information is not timely but
> has, for each certificate, the time frame during which this
> information is deemed valid. Rejection or acceptance can be decided
> based on a local policy specifying, for example, acceptable time
> frames.
>
> About the replay attacks
> ------------------------
> One of the main issue that was raised during the previous discussions
> was to enable both server modes (Caching and Live) without prior
> knowledge of the client without more than one network interaction,
> while preventing replay attacks.
>
> Two different mecanisms are in fact in place to prevent replay
> attacks: the nonces and the nextUpdate field. The nextUpdate field
> places an upper limit on the time for which replay attacks are
> possible. However, because they are only used by caching servers, a
> replay attack would simply provide the same information as the server
> itself would. If the nextUpdate field is absent, then the server is
> live and must have included a nonce in its reply to prevent replay
> attacks with this message.
>
> The danger may occurs when a message corresponding to one type of
> protection is replaced by a replayed message corresponding to the
> other. But in fact, there is only one configuration in which this may
> lead to a security risk:
>
> - A client sends a nonceless request
> - An attacker replies with a previously intercepted live response
>
> In that case, the client can still check that the producedAt and
> thisUpdate fields are recent enough to mitigate the attack... At any
> rate, clients should always send requests with nonce if they want
> security...
>

------=_NextPart_000_0231_01C47D36.7CC5A490
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOODCCBEQw
ggMsoAMCAQICBEClFlYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9y
aW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGll
czEMMAoGA1UECxMDQ0ExMB4XDTA0MDYyMjE1MDY0NVoXDTA3MDYyMjE1MzY0NVowXzELMAkGA1UE
BhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczESMBAGA1UECxMJRW1wbG95
ZWVzMRkwFwYDVQQDExBTYW50b3NoIENob2toYW5pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQCtExu25dsN38n+WyugNc1a9y0A/kbFHPHuTZ76rzrRcX+bbTh5XwSQDUaZbknZmFjRbPswVXA8
a0pNRFn0Oy0TJaHXkX+AGH71RPf/4I1S8CjuxjPvhTMC6zWyZnWwE9TBNDjzba4jic1hdvg47JLb
xM320g7P5VqWWDhKEOtXrQIDAQABo4IBhzCCAYMwCwYDVR0PBAQDAgUgMCAGA1UdEQQZMBeBFWNo
b2toYW5pQG9yaW9uc2VjLmNvbTCB6wYDVR0fBIHjMIHgMHmgd6B1pHMwcTELMAkGA1UEBhMCVVMx
ITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlv
biBBdXRob3JpdGllczEMMAoGA1UECxMDQ0ExMQ0wCwYDVQQDEwRDUkwxMDKgMKAuhixodHRwOi8v
d3d3Lm9yaW9uc2VjLmNvbS9DUkwvY2ExX2NybGZpbGU0LmNybDAvoC2gK4YpZmlsZTovL1xcU2Jl
dGVsZ2V1c2VcQ1JMXGNhMV9jcmxmaWxlNC5jcmwwHwYDVR0jBBgwFoAUyLI83rqa64kJoNY0MpsZ
QobMmNIwHQYDVR0OBBYEFAmbKwqwClYqMfveZYM0xD79HkWNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9
B0EABAwwChsEVjcuMAMCBLAwDQYJKoZIhvcNAQEFBQADggEBAEQMBLlUVl1R3Xndf+qw6hTAJ0kR
AwgU3DEu5/S5k1aEh2mPqnsbsi9Ubq45APRcFLhL8HKPzpcOmsC4wawuSvKf2Cy9fq+9+csEbK8A
yDnCVBXHLHP0l6pdDloVbg0MWygzkyJsJ8PFZP9daiAMRzUcSFzOTr1tPqQ+HHQVSFxL+Mmz8oVu
9Uk6qaHNQDSpDKGNggo5uboa6FcrOoTM2CfBvdLpWusojaJqDiff1P+N5mWF6ss/FQHavO1l8m3z
rT9tP4TUA2jcJ+/Z1+mVQjxI4gCN4TT851QYLaJ4MoQhonZU9onWuP8LjKi8JLfVnh0Rh4zEM+uW
IbNgt0wgwgUwggRxMIIDWaADAgECAgRApRZVMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlVT
MSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsTGUNlcnRpZmljYXRp
b24gQXV0aG9yaXRpZXMxDDAKBgNVBAsTA0NBMTAeFw0wNDA2MjIxNTA2NDVaFw0wNzA2MjIxNTM2
NDVaMF8xCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxEjAQ
BgNVBAsTCUVtcGxveWVlczEZMBcGA1UEAxMQU2FudG9zaCBDaG9raGFuaTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAqWgiRzunDUzHc5g9cPyEBG4BanbIqCf3+RTYM7ARY/yOjfnEbKXgCovz
pjCl6erpIVq5MYq7mn7UpPnUtLzm/wcgZ9wDyM/KJSTa3kfT5X8JFRXn0DQ1Zps7NlaVbuh3tUmQ
st+fOp143LqfRHIVz7cGDEpbBeTzUf6daKz6D+MCAwEAAaOCAbQwggGwMAsGA1UdDwQEAwIHgDAr
BgNVHRAEJDAigA8yMDA0MDYyMjE1MDY0NVqBDzIwMDYwNzI5MDMzNjQ1WjAgBgNVHREEGTAXgRVj
aG9raGFuaUBvcmlvbnNlYy5jb20wgesGA1UdHwSB4zCB4DB5oHegdaRzMHExCzAJBgNVBAYTAlVT
MSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsTGUNlcnRpZmljYXRp
b24gQXV0aG9yaXRpZXMxDDAKBgNVBAsTA0NBMTENMAsGA1UEAxMEQ1JMMTAyoDCgLoYsaHR0cDov
L3d3dy5vcmlvbnNlYy5jb20vQ1JML2NhMV9jcmxmaWxlNC5jcmwwL6AtoCuGKWZpbGU6Ly9cXFNi
ZXRlbGdldXNlXENSTFxjYTFfY3JsZmlsZTQuY3JsMB8GA1UdIwQYMBaAFMiyPN66muuJCaDWNDKb
GUKGzJjSMB0GA1UdDgQWBBTCs7sP/fzSU5RD39PQ5brwSYqp8DAJBgNVHRMEAjAAMBkGCSqGSIb2
fQdBAAQMMAobBFY3LjADAgSwMA0GCSqGSIb3DQEBBQUAA4IBAQB1VS+6FJtEmiQMYFaLcx+q3Gev
bk/FyVo+anTlCwYlJbBPF+MjihgEH2+5Fmi2bdY1e6KdhZbj8/f8M3oKNZjDqjkcOl9WlmfQR2Lx
cdhFFvAO4nyoW9gLEPW4ZsePJyC8WKFFoKv616EeQE655FDpO1RFLy0gB1bz9MECSynphxTOQIpN
Oa8Cl1iSsIITV5sSoFYPqr6pqRPSLlvZcIZNF4b4Zu+lKIOAjMQvxlTwII/K6/w5JQ+HWUvqeOUd
Kjb3so/MgzlDuIKBgpVckxxK7xLxrWvAD9dYBpYGd5NzG8Miaa3h7KJ2j+KvbWfqoTHyizhKV75U
/99xifOY6yMmMIIFdzCCBF+gAwIBAgIEQKUTUTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJV
UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTEwHhcNMDQwNTE0MTkwMzEyWhcNMjQwNTE0MTkz
MzEyWjBiMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIw
IAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTEwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgmMvicMxt6fbcKfUpOjgN8cO181kY5bAFbZcj12Of9W5d
c7aGPqdfivgbWU3C0KkNifsunzR0dEV2mfsaeqt80wciwoNpFjGknR+CLiAT0t0zCeawQTxY42Pv
I9VG4jperjed87wtNl6Edo343BR2CH+tcNAuu7UBrFhtol+2SkYbDIwOY/C1+BXdO81/yDnSYJNw
CuKkNWba3MLi8g500JhAl+xGhCCC0vBvL2c3LHAcoceHs6URk+pUk8afVLWrMXEqNFwsfDM/i8oP
ofydjmd1WTfgItnmOrn2RymhVMMwvJKXk9ODrMG5L7VLSeeAEBb0U6pQ5MFEzLGoeSaDAgMBAAGj
ggIzMIICLzCCAYQGA1UdHwSCAXswggF3MHmgd6B1pHMwcTELMAkGA1UEBhMCVVMxITAfBgNVBAoT
GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dGllczEMMAoGA1UECxMDQ0ExMQ0wCwYDVQQDEwRDUkwxMDKgMKAuhixodHRwOi8vd3d3Lm9yaW9u
c2VjLmNvbS9DUkwvY2ExX2NybGZpbGU0LmNybDCBlKCBkaCBjoaBi2xkYXA6Ly9TQkVURUxHRVVT
RS9jbj1XaW5Db21iaW5lZDQsb3U9Q0ExLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv
PU9yaW9uJTIwU2VjdXJpdHklMjBTb2x1dGlvbnMsYz1VUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25M
aXN0P0Jhc2UwL6AtoCuGKWZpbGU6Ly9cXFNiZXRlbGdldXNlXENSTFxjYTFfY3JsZmlsZTQuY3Js
MCsGA1UdEAQkMCKADzIwMDQwNTE0MTkwMzEyWoEPMjAyNDA1MTQxOTMzMTJaMAsGA1UdDwQEAwIB
BjAfBgNVHSMEGDAWgBTIsjzeuprriQmg1jQymxlChsyY0jAdBgNVHQ4EFgQUyLI83rqa64kJoNY0
MpsZQobMmNIwDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAEEDAOGwhWNy4wOjQuMAMCBJAwDQYJ
KoZIhvcNAQEFBQADggEBAD0tK6tpqLDds75N2y8K6mlPh1u53f6XDot6RTML25UXMptWlVSiFR7M
0njPPsVtNXfTMU0FSuMzy3ChIlD6lsB0lGGu9r3PO0mn7NHWEOIXjFR9D9WFxbkdDwC524wB0M7I
NtzapAV5TBFh+iecmlZkg2ILJRq8VcqhMqgboqRoN+sGIou05fLqbT1CvV1DvAacvyL6IQMZUWIK
OUnUl4/S8M+D6g7BZhOtpbr2Z7kR9deGG+CEBti2TCgR/FLyEDFF8WqH7wtMh/2cvy6D0iZx9CpV
mFEGwLxbb5hPMut7GeAdSl51cm5qz9dVJbX4I6o63+BT2VY8P4YP7n0VgkgxggK0MIICsAIBATBq
MGIxCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNV
BAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAKBgNVBAsTA0NBMQIEQKUWVTAJBgUrDgMC
GgUAoIIBoDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4MDgx
NDU3MjRaMCMGCSqGSIb3DQEJBDEWBBQFe+U2woar09NU4s2y/bcpkTBnCzBJBgkqhkiG9w0BCQ8x
PDA6MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAHBgUrDgMCGjAKBggqhkiG
9w0CBTB5BgkrBgEEAYI3EAQxbDBqMGIxCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1
cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAKBgNV
BAsTA0NBMQIEQKUWVjB7BgsqhkiG9w0BCRACCzFsoGowYjELMAkGA1UEBhMCVVMxITAfBgNVBAoT
GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dGllczEMMAoGA1UECxMDQ0ExAgRApRZWMA0GCSqGSIb3DQEBAQUABIGANxzIUduHygei/ClEf/dt
+cLunyxcWISHIcIGHXY9Z18IWyIVKvwu//avglV2DELnKQtO0jYoMLZkLx62tZrU4LWgRoQgmZ5+
Y9ayN8B/UpQrOdbpikDwT9yyuFa56q0700PARlxP2g3yVerCKTD3sS4NwpqDvhLuLMnIeRYwaGYA
AAAAAAA=

------=_NextPart_000_0231_01C47D36.7CC5A490--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77MAfEb079321; Sat, 7 Aug 2004 15:10:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i77MAfsd079320; Sat, 7 Aug 2004 15:10:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77MAfau079313 for <[e-mail]>; Sat, 7 Aug 2004 15:10:41 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc13) with ESMTP id <2004080722103501500np0i4e>; Sat, 7 Aug 2004 22:10:40 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1BtZMx-0004hf-00 for <[e-mail]>; Sat, 07 Aug 2004 18:08:51 -0400
Message-ID: <[e-mail]>
Date: Sat, 07 Aug 2004 18:08:37 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: About the Nonce issue in OCSPv1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050401040707090001020009"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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


Julien -

Interesting suggestions.  I wonder whether the "nextUpdate" field in an 
OCSP response may have value for clients, even when a nonce is used. 
For example, even a client who uses nonces to partially mitigate against 
freshness-related attacks may wish to locally cache responses for some 
period of time.  The "nextUpdate" field may give some guidance to the 
client to indicate an upper bound on safe local caching.

Previous proposals suggested using a new response extension to signal 
cache/live server support.  Overloading the "nextUpdate" field for this 
purpose allows us to avoid adding any new syntactic elements, but a new 
field or extension would permit the continued use of "nextUpdate" in all 
settings.

Thanks,
Dave


Julien Stern wrote:
> 
> 
> Dear PKIX list,
> 
> I had closely followed the long discussion about OCSP nonce problems
> that occured on the list around sep to dec 2003, and recently saw in
> the minutes of the WG meeting that OCSPv1 was to be clarified on that
> matter.
> 
> I would like to submit the following to your appreciation.
> I believe that the following clarification (interpretation ? :))
> of RFC2560 solves all nonce/replay attack problems, without modifying
> the protocol or adding new extensions, and is fairly consistent with
> existing client and server implementations and hopefully with the
> spirit of the RFC.
> 
> Naturally, comments are welcome and you can feel free to do whatever you
> want with what's below, notably dumping it into oblivion ;)
> 
> Regards,
> 
> -- 
> Julien Stern
> 
> 
> General
> -------
> The CRL approach to revocation checking has two principal drawbacks:
> the first one is that one needs to download a full CRL in order to
> check a single certificate and the second is that a CRL does not
> provide timely information (there is always a time frame during which
> a revoked certificate is not yet present in the CRL). The OCSP allows
> to overcome one or both of these drawbacks, depending on the mode in
> which it is used.
> 
> An OCSP server can be configured in two different modes: the "caching"
> mode and the "live" mode. The live mode means that the server has access
> to up to date information and will always provide it. The caching mode
> means that the information obtained from the server has a delay with
> respect to the up to date information.
> 
> The caching mode overcomes the bandwidth problem associated with CRL,
> but does not ensure timely information. The live mode solves both
> problem, but naturally is more computationaly expensive than the caching
> one. Typically, the caching mode would be used when the source of
> revocation information are CRLs but could also be used for efficiency
> reason when timely information is available.
> 
> A server MUST NOT operate in caching and live mode at the same time.
> 
> Clarifying requirements for caching OCSP servers
> -----------------------------------------------
> - the nextUpdate field of all the SingleResponse elements MUST be present.
>   It should indicate the expiration date of the (cached) information 
> validity.
> - the nonce extension can (and should) be ignored
> 
> Clarifying requirement for live OCSP servers
> --------------------------------------------
> - the nextUpdate field of all the SingleResponse elements MUST be absent,
>   thus indicating the information is live
> - live servers MUST support the nonce extension
> 
> Client behavior
> ---------------
> If a client does not care about timely information, but simply wishes
> to save bandwidth, he MAY send a request without the Nonce extension.
> 
> However, the behavior that clients SHOULD follow is:
> 
> 1) Send a request with a Nonce;
> 
> 2) If the response contains a Nonce, check that the Nonce matches the
> one sent. If they do not, reject the response, otherwise, the client is
> ensured to have timely information;
> 
> 3) If the response does not contain a Nonce, check that all the
> SingleReponse elements contain a nextUpdate field, if not reject;
> otherwise, the client knows that the information is not timely but has,
> for each certificate, the time frame during which this information is
> deemed valid. Rejection or acceptance can be decided based on a local
> policy specifying, for example, acceptable time frames.
> 
> About the replay attacks
> ------------------------
> One of the main issue that was raised during the previous discussions
> was to enable both server modes (Caching and Live) without prior
> knowledge of the client without more than one network interaction,
> while preventing replay attacks.
> 
> Two different mecanisms are in fact in place to prevent replay attacks:
> the nonces and the nextUpdate field. The nextUpdate field places an
> upper limit on the time for which replay attacks are possible. However,
> because they are only used by caching servers, a replay attack would
> simply provide the same information as the server itself would. If
> the nextUpdate field is absent, then the server is live and must have
> included a nonce in its reply to prevent replay attacks with this
> message.
> 
> The danger may occurs when a message corresponding to one type of
> protection is replaced by a replayed message corresponding to the other.
> But in fact, there is only one configuration in which this may lead to a
> security risk:
> 
> - A client sends a nonceless request
> - An attacker replies with a previously intercepted live response
> 
> In that case, the client can still check that the producedAt and
> thisUpdate fields are recent enough to mitigate the attack... At any
> rate, clients should always send requests with nonce if they want
> security...
> 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4DCC
ArwwggIloAMCAQICAgDYMA0GCSqGSIb3DQEBBQUAMFMxCzAJBgNVBAYTAlVTMRwwGgYDVQQK
ExNFcXVpZmF4IFNlY3VyZSBJbmMuMSYwJAYDVQQDEx1FcXVpZmF4IFNlY3VyZSBlQnVzaW5l
c3MgQ0EtMTAeFw0wNDA2MDIxOTU3NDJaFw0yMDA2MjEwNDAwMDBaMFIxCzAJBgNVBAYTAlVT
MRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlm
aWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCvQeEexZnbGRLo
FuiMxe90Y+hEktwCzadQFJnpecm+cfEHBW9FSSqsJIHAoG6uGOoap7eg7GHq0LrBS4aHAt2H
JZMFJg7jr08lTHTaXKKiGpRny7TKyEIvfn+UD4yRm5tyYXEewuVM8KRL/4Ds9nDMiMqssBRP
RWbA1MtNgSDUXwIDAQABo4GfMIGcMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQU2Ox/kxjF
ZgPDEGw8BPZ3hT7/C7YwHwYDVR0jBBgwFoAUSngyUhHbWRY2Xt/BFDZAakd8TKEwDwYDVR0T
AQH/BAUwAwEB/zA5BgNVHR8EMjAwMC6gLKAqhihodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9j
cmxzL2ViaXpjYTEuY3JsMA0GCSqGSIb3DQEBBQUAA4GBAMIcP08EPA88OS1IsL+NGl70Kt2m
PwKPsYHWh3jiPUP7kgmOL7CuG4ne2VHenkyXNcZQSPx4UG1nKZgGJZ0u8hWrAzPadhYF4VZe
i7pP6fhqRwXvTyMzcyEVc/zai95//EnPD0jOVWYj0OMOuQvbBdfD8hHldM/aJBg9xvF6e2jr
MIIDjDCCAvWgAwIBAgIBGTANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEYMBYGA1UE
ChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1
dGhvcml0eTAeFw0wNDA3MTIxMzAyMThaFw0wNTA3MjYxMzAyMThaMGcxCzAJBgNVBAYTAlVT
MRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xFjAUBgNVBAMTDURhdmlkIEVuZ2JlcmcxJjAk
BgkqhkiG9w0BCQEWF2RlbmdiZXJnQGNvcmVzdHJlZXQuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAwldf4lnWhoRvZMJrCTfWvOk4hFMdnI9QZNQY3IxqypzM1kBO9e7Z
FOWifx3AS47h6+vkoT2IN7SNBKSPWDkcESwUAf4k9TtjS5i6mb+SLKvoWLKEEJC1aGtw2KLT
JqFwgRsf98EB/lXXRjbAcoWs8fq5OuP5gaEGlpfGQRmlcJ7ZBm2RH+RxsppBowJpTbu8sBnh
BPq8lN/mgb9IPUpTbfaRi22It5GOd49aKkfwiftysY+GAkJ5A/lS0T24cOM5K215nFexYDNT
uhb2dv2McvbE5Y9DKEGzglo++BJ0WR6cjovx+WxCbvZTyWtX/h2oq7ffSbmkfz1dNiWjY9yo
hQIDAQABo4HYMIHVMA4GA1UdDwEB/wQEAwIF4DA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8v
Y3JsLmdlb3RydXN0LmNvbS9jcmxzL2NvcmVzdHJlZXQuY3JsMCIGA1UdEQQbMBmBF2Rlbmdi
ZXJnQGNvcmVzdHJlZXQuY29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAG
CCsGAQUFBwEBBDQwMjAwBggrBgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0
cmVldC5jb20vMA0GCSqGSIb3DQEBBQUAA4GBAC0BAy3PIjMBHDp3+zLWo+f4yqvto8QkWh+R
Jbns0Trf09yteYIT0vNWbma2ag2R57IcM6CVrv17PwzOd0PGGXBC811qK7XbiNZuASgcLWrY
rgxxtomXGOE9sKkWvtkLPFDE6YXFeNvXpcai2vFfVqPZha4AB230ffH60cFcKf5YMIIDjDCC
AvWgAwIBAgIBGTANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29y
ZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0
eTAeFw0wNDA3MTIxMzAyMThaFw0wNTA3MjYxMzAyMThaMGcxCzAJBgNVBAYTAlVTMRgwFgYD
VQQKEw9Db3JlU3RyZWV0IEx0ZC4xFjAUBgNVBAMTDURhdmlkIEVuZ2JlcmcxJjAkBgkqhkiG
9w0BCQEWF2RlbmdiZXJnQGNvcmVzdHJlZXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAwldf4lnWhoRvZMJrCTfWvOk4hFMdnI9QZNQY3IxqypzM1kBO9e7ZFOWifx3A
S47h6+vkoT2IN7SNBKSPWDkcESwUAf4k9TtjS5i6mb+SLKvoWLKEEJC1aGtw2KLTJqFwgRsf
98EB/lXXRjbAcoWs8fq5OuP5gaEGlpfGQRmlcJ7ZBm2RH+RxsppBowJpTbu8sBnhBPq8lN/m
gb9IPUpTbfaRi22It5GOd49aKkfwiftysY+GAkJ5A/lS0T24cOM5K215nFexYDNTuhb2dv2M
cvbE5Y9DKEGzglo++BJ0WR6cjovx+WxCbvZTyWtX/h2oq7ffSbmkfz1dNiWjY9yohQIDAQAB
o4HYMIHVMA4GA1UdDwEB/wQEAwIF4DA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8vY3JsLmdl
b3RydXN0LmNvbS9jcmxzL2NvcmVzdHJlZXQuY3JsMCIGA1UdEQQbMBmBF2RlbmdiZXJnQGNv
cmVzdHJlZXQuY29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAGCCsGAQUF
BwEBBDQwMjAwBggrBgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0cmVldC5j
b20vMA0GCSqGSIb3DQEBBQUAA4GBAC0BAy3PIjMBHDp3+zLWo+f4yqvto8QkWh+RJbns0Trf
09yteYIT0vNWbma2ag2R57IcM6CVrv17PwzOd0PGGXBC811qK7XbiNZuASgcLWrYrgxxtomX
GOE9sKkWvtkLPFDE6YXFeNvXpcai2vFfVqPZha4AB230ffH60cFcKf5YMYIDBTCCAwECAQEw
VzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBD
b3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBGTAJBgUrDgMCGgUAoIIBgzAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4MDcyMjA4MzdaMCMG
CSqGSIb3DQEJBDEWBBRWaXBQtM13iXoBhQu+i54CYupIsTBSBgkqhkiG9w0BCQ8xRTBDMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq
hkiG9w0DAgIBKDBmBgkrBgEEAYI3EAQxWTBXMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9D
b3JlU3RyZWV0IEx0ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9y
aXR5AgEZMGgGCyqGSIb3DQEJEAILMVmgVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29y
ZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0
eQIBGTANBgkqhkiG9w0BAQEFAASCAQABscIBWdePUJSNqmrTczVIA5h3iuyCm0k0QfycET3/
5frinwdN0kbeUYDewMF24Xg/hz12uZW1+3smqT6rUAOtdErCjSOWTKobG8zOZvX4EcEkeL96
PkA2AkSjkBQmhYE4/tUK0nfjx34obDQzj/JtwbUJOCvvSUUnRQqwNjmd/lP9X0SxEOp3TEku
12htLotb/qWySBbl7byZmTPWH+QlRzFhAQg5PR2vomFIMJyaBjuHg05NyzBrth3XubPbuxQ+
o11mf1KJuOaFjkXXzr43U2ZGxfvn6zNJOsPsMuiO6Fv4xAHwY50RU068tVIXU1LrK8BRBE9d
KswP3Id3ZlmRAAAAAAAA
--------------ms050401040707090001020009--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77HMTYm060218; Sat, 7 Aug 2004 10:22:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i77HMTtt060217; Sat, 7 Aug 2004 10:22:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77HMT8n060211 for <[e-mail]>; Sat, 7 Aug 2004 10:22:29 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i77HMM809599; Sat, 7 Aug 2004 10:22:22 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "Ietf-Pkix@Imc. Org" <[e-mail]>, "Pki4ipsec@Honor. Icsalabs. Com" <[e-mail]>
Subject: OCSP in IKEv2
Date: Sat, 7 Aug 2004 10:21:32 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <p06110402bd36e8023a47@[130.129.131.20]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

The intersection of IPSEC with PKI is of recent interest.  Towards that
dialog, Hannes Tschofenig and I have proposed how OCSP could be used to
deliver certificate status in-band to IKEv2.  We were driven first to
consider the important use case of EAP (i.e. the Road Warrior) but also
considered the Peer-to-Peer case in order to develop a general solution.

This individual submission I-D can be found at:
http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt

Two new certificate encoding types are proposed:  OCSP Responder Hash
and OCSP Response.  An OCSP Responder Hash is sent in a CERTREQ,
computed as trust anchor hashes are computed but sent in a separate
CERTREQ.  A corresponding OCSP Response is sent back in its own CERT
payload and in the context of the CERT payload carrying the
participant's certificate.  That is, an IKEv2 participant sends both its
cert and that cert's status in separate CERT payloads.

Hannes and I look forward to your comments and debate.  I've
cross-posted due to intersecting interests but please post comments to
the IPSEC list only.

Michael Myers




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76Mw02U072042; Fri, 6 Aug 2004 15:58:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i76Mw0ZD072041; Fri, 6 Aug 2004 15:58:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76MvxNL072027 for <[e-mail]>; Fri, 6 Aug 2004 15:57:59 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i76Mw3809248; Fri, 6 Aug 2004 15:58:03 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: SCVP: Speak now or forever hold your peace...
Date: Fri, 6 Aug 2004 15:57:14 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

Regarding SCVP closure, I still feel that the document should
normatively translate 3379's notions of DPD and DPV into SCVP ASN.1.
Doing so will reduce ambiguity down the road.  Think OCSP nonces.

Mike



-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of [e-mail]
Sent: Wednesday, August 04, 2004 5:06 PM
To: [e-mail]
Subject: SCVP: Speak now or forever hold your peace...





Folks,

It is time to get serious and finish up SCVP.  In the slides presented
at our
meeting this morning, the SCVP editors requested a "Definitive and final
list
of all issues from workgroup".  I believe that is a reasonable request.
Let's
do our best to get that list documented ASAP, so that -16 can be our
*last*.

I am requesting that everyone in the WG make time to review SCVP and
document
any issues you find by Friday the 13th.  (I am not setting a deadline
for
terminating discussion - it may take a few days to reach consensus on
the
issue list.  I am just trying to surface all the issues ASAP.)  Once the
issue
list is stable, I am sure we can work out solutions.

Please post all technical comments to the list.  Editorial comments can
be
sent to Trevor directly.  Include SCVP in the subject line regardless!

Thanks,

Tim Polk





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76MrlLw071713; Fri, 6 Aug 2004 15:53:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i76MrlE0071712; Fri, 6 Aug 2004 15:53:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76Mrk58071703 for <[e-mail]>; Fri, 6 Aug 2004 15:53:47 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i76Mrm808911; Fri, 6 Aug 2004 15:53:48 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Julien Stern" <[e-mail]>, <[e-mail]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Fri, 6 Aug 2004 15:52:58 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

Yes, we will be clarifying 2560 in this regard.  As I said in San Diego,
the text will be "accomodative" of servers unable to respond to nonced
requests.  I am aiming to keep this clarification to a paragraph at
most.  Your text is nonetheless very good input.  I look forward to your
review of the final text when it becomes available.

Mike

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Julien Stern
Sent: Friday, August 06, 2004 3:35 AM
To: [e-mail]
Subject: About the Nonce issue in OCSPv1




Dear PKIX list,

I had closely followed the long discussion about OCSP nonce problems
that occured on the list around sep to dec 2003, and recently saw in
the minutes of the WG meeting that OCSPv1 was to be clarified on that
matter.

I would like to submit the following to your appreciation.
I believe that the following clarification (interpretation ? :))
of RFC2560 solves all nonce/replay attack problems, without modifying
the protocol or adding new extensions, and is fairly consistent with
existing client and server implementations and hopefully with the
spirit of the RFC.

Naturally, comments are welcome and you can feel free to do whatever you
want with what's below, notably dumping it into oblivion ;)

Regards,

--
Julien Stern


General
-------
The CRL approach to revocation checking has two principal drawbacks:
the first one is that one needs to download a full CRL in order to
check a single certificate and the second is that a CRL does not
provide timely information (there is always a time frame during which
a revoked certificate is not yet present in the CRL). The OCSP allows
to overcome one or both of these drawbacks, depending on the mode in
which it is used.

An OCSP server can be configured in two different modes: the "caching"
mode and the "live" mode. The live mode means that the server has access
to up to date information and will always provide it. The caching mode
means that the information obtained from the server has a delay with
respect to the up to date information.

The caching mode overcomes the bandwidth problem associated with CRL,
but does not ensure timely information. The live mode solves both
problem, but naturally is more computationaly expensive than the caching
one. Typically, the caching mode would be used when the source of
revocation information are CRLs but could also be used for efficiency
reason when timely information is available.

A server MUST NOT operate in caching and live mode at the same time.

Clarifying requirements for caching OCSP servers
-----------------------------------------------
- the nextUpdate field of all the SingleResponse elements MUST be
present.
  It should indicate the expiration date of the (cached) information
validity.
- the nonce extension can (and should) be ignored

Clarifying requirement for live OCSP servers
--------------------------------------------
- the nextUpdate field of all the SingleResponse elements MUST be
absent,
  thus indicating the information is live
- live servers MUST support the nonce extension

Client behavior
---------------
If a client does not care about timely information, but simply wishes
to save bandwidth, he MAY send a request without the Nonce extension.

However, the behavior that clients SHOULD follow is:

1) Send a request with a Nonce;

2) If the response contains a Nonce, check that the Nonce matches the
one sent. If they do not, reject the response, otherwise, the client is
ensured to have timely information;

3) If the response does not contain a Nonce, check that all the
SingleReponse elements contain a nextUpdate field, if not reject;
otherwise, the client knows that the information is not timely but has,
for each certificate, the time frame during which this information is
deemed valid. Rejection or acceptance can be decided based on a local
policy specifying, for example, acceptable time frames.

About the replay attacks
------------------------
One of the main issue that was raised during the previous discussions
was to enable both server modes (Caching and Live) without prior
knowledge of the client without more than one network interaction,
while preventing replay attacks.

Two different mecanisms are in fact in place to prevent replay attacks:
the nonces and the nextUpdate field. The nextUpdate field places an
upper limit on the time for which replay attacks are possible. However,
because they are only used by caching servers, a replay attack would
simply provide the same information as the server itself would. If
the nextUpdate field is absent, then the server is live and must have
included a nonce in its reply to prevent replay attacks with this
message.

The danger may occurs when a message corresponding to one type of
protection is replaced by a replayed message corresponding to the other.
But in fact, there is only one configuration in which this may lead to a
security risk:

- A client sends a nonceless request
- An attacker replies with a previously intercepted live response

In that case, the client can still check that the producedAt and
thisUpdate fields are recent enough to mitigate the attack... At any
rate, clients should always send requests with nonce if they want
security...





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76AYo4a005935; Fri, 6 Aug 2004 03:34:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i76AYo23005934; Fri, 6 Aug 2004 03:34:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-105-friday.noc.nerim.net [62.4.17.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i76AYm57005917 for <[e-mail]>; Fri, 6 Aug 2004 03:34:49 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 9667662D63 for <[e-mail]>; Fri,  6 Aug 2004 12:34:48 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 2BDEE4148 for <[e-mail]>; Fri,  6 Aug 2004 12:34:49 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 32456-04 for <[e-mail]>; Fri,  6 Aug 2004 12:34:48 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id DF34A40B3 for <[e-mail]>; Fri,  6 Aug 2004 12:34:48 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Fri,  6 Aug 2004 12:34:48 +0200
From: "Julien Stern" <[e-mail]>
Date: Fri, 6 Aug 2004 12:34:48 +0200
To: [e-mail]
Subject: About the Nonce issue in OCSPv1
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear PKIX list,

I had closely followed the long discussion about OCSP nonce problems
that occured on the list around sep to dec 2003, and recently saw in
the minutes of the WG meeting that OCSPv1 was to be clarified on that
matter.

I would like to submit the following to your appreciation.
I believe that the following clarification (interpretation ? :))
of RFC2560 solves all nonce/replay attack problems, without modifying
the protocol or adding new extensions, and is fairly consistent with
existing client and server implementations and hopefully with the
spirit of the RFC.

Naturally, comments are welcome and you can feel free to do whatever you
want with what's below, notably dumping it into oblivion ;)

Regards,

--
Julien Stern


General
-------
The CRL approach to revocation checking has two principal drawbacks:
the first one is that one needs to download a full CRL in order to
check a single certificate and the second is that a CRL does not
provide timely information (there is always a time frame during which
a revoked certificate is not yet present in the CRL). The OCSP allows
to overcome one or both of these drawbacks, depending on the mode in
which it is used.

An OCSP server can be configured in two different modes: the "caching"
mode and the "live" mode. The live mode means that the server has access
to up to date information and will always provide it. The caching mode
means that the information obtained from the server has a delay with
respect to the up to date information.

The caching mode overcomes the bandwidth problem associated with CRL,
but does not ensure timely information. The live mode solves both
problem, but naturally is more computationaly expensive than the caching
one. Typically, the caching mode would be used when the source of
revocation information are CRLs but could also be used for efficiency
reason when timely information is available.

A server MUST NOT operate in caching and live mode at the same time.

Clarifying requirements for caching OCSP servers
-----------------------------------------------
- the nextUpdate field of all the SingleResponse elements MUST be present.
  It should indicate the expiration date of the (cached) information validity.
- the nonce extension can (and should) be ignored

Clarifying requirement for live OCSP servers
--------------------------------------------
- the nextUpdate field of all the SingleResponse elements MUST be absent,
  thus indicating the information is live
- live servers MUST support the nonce extension

Client behavior
---------------
If a client does not care about timely information, but simply wishes
to save bandwidth, he MAY send a request without the Nonce extension.

However, the behavior that clients SHOULD follow is:

1) Send a request with a Nonce;

2) If the response contains a Nonce, check that the Nonce matches the
one sent. If they do not, reject the response, otherwise, the client is
ensured to have timely information;

3) If the response does not contain a Nonce, check that all the
SingleReponse elements contain a nextUpdate field, if not reject;
otherwise, the client knows that the information is not timely but has,
for each certificate, the time frame during which this information is
deemed valid. Rejection or acceptance can be decided based on a local
policy specifying, for example, acceptable time frames.

About the replay attacks
------------------------
One of the main issue that was raised during the previous discussions
was to enable both server modes (Caching and Live) without prior
knowledge of the client without more than one network interaction,
while preventing replay attacks.

Two different mecanisms are in fact in place to prevent replay attacks:
the nonces and the nextUpdate field. The nextUpdate field places an
upper limit on the time for which replay attacks are possible. However,
because they are only used by caching servers, a replay attack would
simply provide the same information as the server itself would. If
the nextUpdate field is absent, then the server is live and must have
included a nonce in its reply to prevent replay attacks with this
message.

The danger may occurs when a message corresponding to one type of
protection is replaced by a replayed message corresponding to the other.
But in fact, there is only one configuration in which this may lead to a
security risk:

- A client sends a nonceless request
- An attacker replies with a previously intercepted live response

In that case, the client can still check that the producedAt and
thisUpdate fields are recent enough to mitigate the attack... At any
rate, clients should always send requests with nonce if they want
security...



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75KaxOq033150; Thu, 5 Aug 2004 13:36:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75KaxNq033149; Thu, 5 Aug 2004 13:36:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75KauSa033141 for <[e-mail]>; Thu, 5 Aug 2004 13:36:56 -0700 (PDT) (envelope-from [e-mail])
Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i75KatQl015386; Thu, 5 Aug 2004 16:36:55 -0400
Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id i75KYcos009607; Thu, 5 Aug 2004 16:34:38 -0400
Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id i75KYbUx009605; Thu, 5 Aug 2004 16:34:37 -0400
Received: from opene-130-129-133-7.ietf60.ietf.org (opene-130-129-133-7.ietf60.ietf.org [130.129.133.7])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Thu,  5 Aug 2004 16:34:37 -0400
Message-ID: <[e-mail]>
Date: Thu,  5 Aug 2004 16:34:37 -0400
From: [e-mail]
To: Francis Dupont <[e-mail]>
Cc: [e-mail]
Subject: Re: SCVP: Speak now or forever hold your peace...
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 130.129.133.7
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Francis,

I am sorry some previous comments appeared to be overlooked.  I appreciate 
your resubmitting those so we can build a complete issues list.

BTW, I certainly consider issues like MIME types to be important issues, 
rather than nits.  These issues could adversely affect interoperability, and 
should be noted on list.  Typos, etc. are things best sent straight to the 
editors, since they may become OBE based on other edits.

Thanks,

Tim

Quoting Francis Dupont <[e-mail]>:

>  In your previous mail you wrote:
> 
>    It is time to get serious and finish up SCVP...
> 
> => I had many comments about the previous draft but unfortunately some
> are still valid. As an example of nits the application MIME types changed
> but not everywhere so there are still both application/cv-request and
> application/scvp-request in the document. I'll try to make all comments
> before the dead-line and in the list (as previous comments sent in private
> seemed to have been ignored).
> 
> Regards
> 
> [e-mail]
> 
> PS: I'd like to perform all the certificate validation needed by an IKE
> server in a SCVP responder. I used a partial implementation of SCVP
> in OpenSSL and for the IKE daemon racoon, both on FreeBSD and Linux.
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75H5WR5016376; Thu, 5 Aug 2004 10:05:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75H5WYY016375; Thu, 5 Aug 2004 10:05:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75H5VVt016369 for <[e-mail]>; Thu, 5 Aug 2004 10:05:32 -0700 (PDT) (envelope-from [e-mail])
Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i75H4aQl002443; Thu, 5 Aug 2004 13:04:36 -0400
Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id i75H2Jos028416; Thu, 5 Aug 2004 13:02:19 -0400
Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id i75H2JlQ028414; Thu, 5 Aug 2004 13:02:19 -0400
Received: from opene-130-129-133-7.ietf60.ietf.org (opene-130-129-133-7.ietf60.ietf.org [130.129.133.7])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Thu,  5 Aug 2004 13:02:18 -0400
Message-ID: <[e-mail]>
Date: Thu,  5 Aug 2004 13:02:18 -0400
From: [e-mail]
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: SCVP: Speak now or forever hold your peace...
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 130.129.133.7
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I certainly am counting your nine concerns and Peter's four comments as 
unresolved issues.  I understand that deadline will be hard for some people to 
meet, and am sorry that you are one of that group.  As you have commented 
extensively in the past, I am hopeful that 99% of your concerns have already 
been raised.

You may have noticed that I requested (begged?) that issues be raised by the 
deadline, but didn't absolutely forbid posting new issues after that date.  We 
are a security WG, and if security issues are identified on August 14 we will 
have to address them.  (However, late submissions may be ignored if they do 
not fall into that category.)

I hope everyone will treat this as a hard deadline, though.  Establishing a 
complete list is more than a courtesy to the editors of SCVP.  It is a 
necessary step towards completion and progression of SCVP.  The status of SCVP 
has become a major impediment to the development and deployment of products.  
This deadline is a necessary evil.

With respect to the two issues highlighted below:
(1) Your major concern (referencing a single OID in the request) is well 
understood, and has already prompted a lot of discussion.  I expect we can 
handle this one in your absence.  
(2) I believe we can clarify the DPD - DPV split quite easily.  Restructuring 
the document is not necessary, though, and would introduce unacceptable delays.

Have a nice vacation.

Tim


Quoting Denis Pinkas <[e-mail]>:

> Tim,
> 
> I am leaving for holidays tonight, so your message reached me just in time 
> to tell you that I will have not have the time to send more comments before 
> the deadline of Friday 13.
> 
> I may simply say that in general the answers from Trevor have not correctly 
> answered to the nine concerns I raised on July 28.
> 
> The major concern remains to ability to refence only one OID for the 
> validation policy and leave ALL the complexity of client-defined parameters 
> for a validation policy or a validation algorithm (whatever name is being 
> used) as an OPTIONAL feature that DOES not have to be supported by
> implementers.
> 
> I am also supportive of a much cleaner separation between CVP and DPD as 
> advocated by Mike. Even if there are similarities, the two protocols are 
> differents. Some restructuring of the document will be necessary so that 
> this goal can be achieved.
> 
> The comments from Peter should not be forgotten.
> 
> As mentionned by Steve, the S from SCVP is still supposed to mean Simple.
> 
> Denis
> 
> 
> > Folks,
> > 
> > It is time to get serious and finish up SCVP.  In the slides presented at
> our 
> > meeting this morning, the SCVP editors requested a "Definitive and final
> list 
> > of all issues from workgroup".  I believe that is a reasonable request. 
> Let's 
> > do our best to get that list documented ASAP, so that -16 can be our
> *last*.
> > 
> > I am requesting that everyone in the WG make time to review SCVP and
> document 
> > any issues you find by Friday the 13th.  (I am not setting a deadline for 
> > terminating discussion - it may take a few days to reach consensus on the 
> > issue list.  I am just trying to surface all the issues ASAP.)  Once the
> issue 
> > list is stable, I am sure we can work out solutions.
> > 
> > Please post all technical comments to the list.  Editorial comments can be
> 
> > sent to Trevor directly.  Include SCVP in the subject line regardless! 
> > 
> > Thanks,
> > 
> > Tim Polk  
> > 
> 
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75Fc742008203; Thu, 5 Aug 2004 08:38:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75Fc7Sd008202; Thu, 5 Aug 2004 08:38:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75Fc5jk008191 for <[e-mail]>; Thu, 5 Aug 2004 08:38:06 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA27060; Thu, 5 Aug 2004 17:48:32 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id RAA29158; Thu, 5 Aug 2004 17:38:04 +0200
Message-ID: <[e-mail]>
Date: Thu, 05 Aug 2004 17:36:19 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: SCVP: Speak now or forever hold your peace...
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

I am leaving for holidays tonight, so your message reached me just in time 
to tell you that I will have not have the time to send more comments before 
the deadline of Friday 13.

I may simply say that in general the answers from Trevor have not correctly 
answered to the nine concerns I raised on July 28.

The major concern remains to ability to refence only one OID for the 
validation policy and leave ALL the complexity of client-defined parameters 
for a validation policy or a validation algorithm (whatever name is being 
used) as an OPTIONAL feature that DOES not have to be supported by implementers.

I am also supportive of a much cleaner separation between CVP and DPD as 
advocated by Mike. Even if there are similarities, the two protocols are 
differents. Some restructuring of the document will be necessary so that 
this goal can be achieved.

The comments from Peter should not be forgotten.

As mentionned by Steve, the S from SCVP is still supposed to mean Simple.

Denis


> Folks,
> 
> It is time to get serious and finish up SCVP.  In the slides presented at our 
> meeting this morning, the SCVP editors requested a "Definitive and final list 
> of all issues from workgroup".  I believe that is a reasonable request.  Let's 
> do our best to get that list documented ASAP, so that -16 can be our *last*.
> 
> I am requesting that everyone in the WG make time to review SCVP and document 
> any issues you find by Friday the 13th.  (I am not setting a deadline for 
> terminating discussion - it may take a few days to reach consensus on the 
> issue list.  I am just trying to surface all the issues ASAP.)  Once the issue 
> list is stable, I am sure we can work out solutions.
> 
> Please post all technical comments to the list.  Editorial comments can be 
> sent to Trevor directly.  Include SCVP in the subject line regardless! 
> 
> Thanks,
> 
> Tim Polk  
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i752vOeQ047914; Wed, 4 Aug 2004 19:57:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i752vOVk047913; Wed, 4 Aug 2004 19:57:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i752vMEX047893 for <[e-mail]>; Wed, 4 Aug 2004 19:57:23 -0700 (PDT) (envelope-from [e-mail])
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i752vIW23001; Thu, 5 Aug 2004 04:57:18 +0200
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i752vISj012406; Thu, 5 Aug 2004 04:57:18 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Francis Dupont <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Re: SCVP: Speak now or forever hold your peace... 
In-reply-to: Your message of Wed, 04 Aug 2004 20:06:11 EDT. <[e-mail]> 
Date: Thu, 05 Aug 2004 04:57:18 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 In your previous mail you wrote:

   It is time to get serious and finish up SCVP...

=> I had many comments about the previous draft but unfortunately some
are still valid. As an example of nits the application MIME types changed
but not everywhere so there are still both application/cv-request and
application/scvp-request in the document. I'll try to make all comments
before the dead-line and in the list (as previous comments sent in private
seemed to have been ignored).

Regards

[e-mail]

PS: I'd like to perform all the certificate validation needed by an IKE
server in a SCVP responder. I used a partial implementation of SCVP
in OpenSSL and for the IKE daemon racoon, both on FreeBSD and Linux.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7508OUm032734; Wed, 4 Aug 2004 17:08:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7508Oc0032733; Wed, 4 Aug 2004 17:08:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7508NFV032726 for <[e-mail]>; Wed, 4 Aug 2004 17:08:24 -0700 (PDT) (envelope-from [e-mail])
Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i7508RNR021069 for <[e-mail]>; Wed, 4 Aug 2004 20:08:27 -0400
Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id i7506Cos031750 for <[e-mail]>; Wed, 4 Aug 2004 20:06:12 -0400
Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id i7506CHe031748 for [e-mail]; Wed, 4 Aug 2004 20:06:12 -0400
Received: from opene-130-129-132-142.ietf60.ietf.org (opene-130-129-132-142.ietf60.ietf.org [130.129.132.142])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Wed,  4 Aug 2004 20:06:11 -0400
Message-ID: <[e-mail]>
Date: Wed,  4 Aug 2004 20:06:11 -0400
From: [e-mail]
To: [e-mail]
Subject: SCVP: Speak now or forever hold your peace...
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 130.129.132.142
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

It is time to get serious and finish up SCVP.  In the slides presented at our 
meeting this morning, the SCVP editors requested a "Definitive and final list 
of all issues from workgroup".  I believe that is a reasonable request.  Let's 
do our best to get that list documented ASAP, so that -16 can be our *last*.

I am requesting that everyone in the WG make time to review SCVP and document 
any issues you find by Friday the 13th.  (I am not setting a deadline for 
terminating discussion - it may take a few days to reach consensus on the 
issue list.  I am just trying to surface all the issues ASAP.)  Once the issue 
list is stable, I am sure we can work out solutions.

Please post all technical comments to the list.  Editorial comments can be 
sent to Trevor directly.  Include SCVP in the subject line regardless! 

Thanks,

Tim Polk  



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74LJU8T018071; Wed, 4 Aug 2004 14:19:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74LJUe5018070; Wed, 4 Aug 2004 14:19:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74LJRoM018063 for <[e-mail]>; Wed, 4 Aug 2004 14:19:29 -0700 (PDT) (envelope-from [e-mail])
Received: from romans (opene-130-129-132-221.ietf60.ietf.org [130.129.132.221]) by smtp3.pacifier.net (Postfix) with ESMTP id 736D36E2F8; Wed,  4 Aug 2004 14:19:29 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>
Cc: "IETF-PKIX" <[e-mail]>
Subject: 
Date: Wed, 4 Aug 2004 14:27:23 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcR6adSErR5uFMYdRH6dhpHhwzdjQQ==
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

ASN.1 Errors

1.  General names is in the rfc3280 implicit not explicit.

2.  Line Missing comma following optional for producedAt and queryExtensions

3.  NameValidationAlg - fields are to be lower case names

4.  SCVPStatusCode - values have upper case names not lower case names

5.  fullRequestRefUnsupported has a } not a ) on the value of 51

6.  ValPolicy.isCA is uppercased needs to be lower cased

7.  PoliciesResponse.defaultPolicyID is upper cased - needs to be lower case

8.  ResponseTypes fields need hyphenation

9.  SubjectPublicKeyInfo is imported but never referenced


Jim




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74I5F2C002130; Wed, 4 Aug 2004 11:05:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74I5FqQ002124; Wed, 4 Aug 2004 11:05:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74I5EfP002113 for <[e-mail]>; Wed, 4 Aug 2004 11:05:15 -0700 (PDT) (envelope-from [e-mail])
Received: from [130.129.134.171] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i74I5B7X014360 for <[e-mail]>; Wed, 4 Aug 2004 14:05:12 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06110407bd36d12498fc@[130.129.134.171]>
Date: Wed, 4 Aug 2004 14:04:58 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft meeting minutes for review & comment by 8-20
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PKIX WG Meeting 8-4-04

Edited by Steve Kent

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

The PKIX WG met once during the 60th IETF. A total of approximately 
73 individuals participated in the meeting.


WG Status and Direction

Document Status Review [Tim Polk (NIST)]

The working group has a number of Internet-Drafts.  Many documents 
are with the ADs or in various stages of WG Last Call. Several others 
are ready for Last Call. (Also, The working group milestones have 
been out of date, although several were recently updated. An 
additional pass to revise the milestones will be made by the WG 
chairs, and the results posted to the WG home page. (slides)


PKIX WG Specifications

LDAP Specifications

PKIX has a number of LDAP-based specifications supporting publication 
and distribution of certificates and CRLs.


LDAP Schemas, String Values, etc. - David Chadwick (U. of Salford)

  draft-ietf-pkix-ldap-crl-schema-02.txt
  draft-ietf-pkix-ldap-ac-schema-01.txt

The WG has a suite of LDAP-PKIX drafts forming a comprehensive 
solution for LDAP based PKI information distribution.  New drafts of 
two I-Ds have been submitted since IETF 59 and additional drafts will 
be published soon after this meeting. Documents will be 
Informational, WG submissions, having previously been individual 
submissions. A late September WG last call is planned, to accommodate 
the author's schedule. (slides)


Practical Considerations for Use of LDAP in PKIX - Kurt Zeilenga 
(LDAPbis WG co-chair)

        Practical considerations must be considered to maximize the 
utility and interoperability of LDAP-based PKIs. This presentation 
discussed known issues and (where applicable) ways to address them. 
Highlights include ";binary" support. Goal is to complete this work 
(3 documents) via staged WG last calls in late August, September, and 
October, so that all 3 are done before D.C. UETF meeting. (slides)


Matching Text Strings in PKIX Certificates - Paul Hoffman (IMC) & 
Steve Hanna (Sun->Funky)

  draft-hoffman-pkix-stringmatch-00.txt

        This specification describes the use of (LDAP) Stringprep to 
support comparison and matching of international text strings.  This 
document resolves an open issue from RFC 3280, where the minimum 
requirements for name comparison were specified as binary matching. 
Since the publication of RFC 3280, the Stringprep specification has 
been completed, providing a solid basis for comparison and matching 
of test strings in PKIX certificates. Target is a standards track 
document as a PKIX WG item, to be referenced from 3280bis. X.500 
provides per-attribute matching rules, and is being updated to use 
Stringprep, so the emphasis in PKIX should be on alternative name 
matching. Target is to identify, and resolve, issues by the next IETF 
meeting. (slides)


RFC 3280 Progression- Tim Polk (NIST)

        NIST will present the current plan and milestones for 
progression of RFC 3280 to Draft Standard. Russ identified a problem 
for 3280bis, related to international string matching, i.e., 3280 
punted on the topic of wildcard matching, and so 3280bis needs to 
address this issue, in the Stringprep context. (slides)


Subject Identification Method - Tim Polk (NIST) for Jongwook Park (KISA)

  draft-ietf-pkix-sim-03.txt

        A new draft of the Subject Identification Method has been 
submitted since IETF 59.  The document is relatively stable and 
mature.  WG Last Call is expected very soon for the next (final?) 
draft of this document. (slides)


SCVP Progression - Tim Polk (NIST) for Trevor Freeman (Microsoft)

  draft-ietf-pkix-scvp-15.txt

        This document has been in WG Last Call since early 2004. 
Completion of WG Last Call was blocked by newly identified 
implementation requirements for unsigned messages to support DPD. 
Early proposals did not satisfy RFC 3739, and were rejected.  A new 
draft has been submitted since IETF 59 implementing unsigned messages 
while satisfying RFC 3379 and the implementation requirements. It 
seems likely that there additional revisions will be needed before 
the document is finished, given last call comments. Target is to be 
done before D.C. meeting. (slides)


OCSPv1 Progression to DRAFT - Mike Myers (Traceroute)
	 Need to resolve an ambiguity in the text, re nonces, to 
clarify this in a fashion that accommodates existing implementation 
practice. Should me a 1 paragraph change and allow the document to 
proceed to DRAFT quickly. (no slides)


Related Specifications & Liaison Presentations

Specification of OCSP in IKEv2 - Mike Myers (TraceRoute)

  draft-myers-ipsec-ikev2-oscp-00.txt

This is an IPsec topic that uses a PKIX protocol. The presentation 
described issues with the specification of OCSP in IKEv2, to provide 
an alternative to sending CRLs via IKE. Motivations are to avoid 
fragmentation concerns in IKE, and because it might be hard to gain 
access to an OCSP server w/o secure access (a chicken & egg problem). 
An individual submission; not a PKIX document. (slides)


User Interface Requirement for the Internet X.509 Public Key 
Infrastructure - Jaehoo Yoon (KISA)

  draft-choi-pkix-ui-00.txt

This document proposes basic requirements for a user interface for 
PKI client software, with an emphasis on usability and smart card 
support. Requirements addressed by the document include root CA 
certificate management, certificate sharing among applications, local 
storage, etc. Targeted to be an informational document for system 
designers. An individual (not PKIX) submission. (slides)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i746kZDt084684; Tue, 3 Aug 2004 23:46:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i746kZrt084683; Tue, 3 Aug 2004 23:46:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i746kYs3084672 for <[e-mail]>; Tue, 3 Aug 2004 23:46:34 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Aug 2004 23:46:34 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Aug 2004 23:46:34 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Aug 2004 23:46:34 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.243]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Aug 2004 23:46:37 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Tue, 3 Aug 2004 23:46:38 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PKIX WG Agenda for 60th IETF (second try!)
thread-index: AcR0o2Y6DrzdmZ4CTSCj9wG1cAJ87QFRvkpQ
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 04 Aug 2004 06:46:37.0044 (UTC) FILETIME=[C9F17B40:01C479EE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i746kYs3084674
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
Sorry I missed this but as Tim said, I am on vacation and not attending
San Diego so have not been reading every posting. If you had also sent
this mail to me personally you would have at least found out I am on
vacation. Dennis changed the subject line to include SCVP which caught
my attention and since I did not find another posting with the same
subject I wrongly assumed he had forwarded a private mail to the list.
My apologies. 

I will therefore repost my comments directly to you.

Trevor
* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Peter Sylvester
* Sent: Wednesday, July 28, 2004 5:33 AM
* To: [e-mail]
* Cc: [e-mail]
* Subject: Re: PKIX WG Agenda for 60th IETF (second try!)
* 
* 
* 
* it seems to me that some of the results of discussions between
* the editor and me have been forgotten or so.
* 
* 
* I still think that the scvp is not conformant to RFC 3379
* and/or the editors has not done something as announced.
* 
* 1) RFC 3379 says:
*    The DPV request MUST allow the client to request that the server
*    include in its response additional information which will allow
*    relying parties not trusting the DPV server to be confident that
the
*    certificate validation has correctly been performed.  Such
*    information may (not necessarily exclusively) consist of a
*    certification path, revocation status information from authorized
CRL
*    issuers or authorized OCSP responders, revocation status
information
*    from CRL issuers or OCSP responders trusted under the validation
*    policy, time-stamp tokens from TSAs responders trusted under the
*    validation policy, or a DPV response from a DPV server that is
*                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
* 
*    trusted under the validation policy.  When the certificate is valid
*    according to the validation policy, the server MUST, upon request,
*    include that information in the response.  However, the server MAY
*    omit that information when the certificate is invalid or when it
*    cannot determine the validity.
* 
*    ==> no provision (as far as I see).

[TF] Given that SCVP requires the server ensure that the validation
policy has been complied with and permits all the parameters for the
currently defined validation algorithms to be returned ( full
certificate path, CRLs, OCSP responses) then I consider SCVP to be fully
compliant with 3379. There are no currently defined validation
algorithms which have a TSA response or a DPV response from another SCVP
server as an input, however if such as algorithm were to be defined,
then the extension mechanisms within SCVP would permit TSA responses or
DPV responses to be also returned. 

Also which discussing the client requesting the validation information
by value in section 3.2.5 states

"include by value in the CVResponse  every aspect of the validation
policy"


* 
* 
* 2) RFC 3379 says:
*    When the DPV request is authenticated, the client SHOULD be able to
*    include a client identifier in the request for the DPV server to
copy
*    into the response.  Mechanisms for matching this identifier with
the
*    authenticated identity depends on local DPV server conditions
and/or
*    the validation policy.  The DPV server MAY choose to blindly copy
the
*    identifier, omit the identifier, or return an error response.
* 
* The current text is SCVP says:
* 
*   The OPTIONAL requestor item is used to identify the requestor.  The
*   value is only of local significance to the requestor.  If the SCVP
*   client includes a requestor value in the request, then the SCVP
*   server MUST return the same value if the server is generating a
*   specific response.
* 
* 
* tf also said:
* 
* > Given there are plenty of ways a client can generate a "unique" as
well
* > as other behaviors like it can encode a DN in the octet sting if it
* > likes I don't see a problem. Its down to the client to do what it
thinks
* > fit. The value is simply replayed by the server so it is treated a
* > binary blob.
* 
[TF] Since you had not linked our discussion on the requestor field to
this section of 3379 before we have been at cross purposes. As Dennis
pointed out this field is intended for SCVP relay so the current text is
accurate for that purpose. It's a opaque blob to the server so
definition of any standard structures in this case was and is a
pointless exercise.

It is also not appropriate to reuse the requestor field because of the
case of authenticated relay. Since the client signed the request with a
certificate in this case, the request complies with 3379. We just need
to add a GeneralName field in the response for this purpose. Though
remember that with cached responses this will not be possible.

.
* There is nothing else possible for the server except copying, or,
* no mechanisms to match this with the some authenticated entity
* can be safely developped if it is solely 'up to the client to encode
* whatever'.
* 
* I had proposed two changes to the logic of 0 terminated octet strings
by:
* 
* - a sequence of octet strings allowing a real opaque string.
* - a choice of generalname
* 
* I.e.
* 
*    Identifiers ::= SEQUENCE OF {
*           CHOICE {
*                opaqueId OCTET STRING,
*                nameId GeneralName
*           }
* 
* No comment to this proposition as far as I remember.
* 
* 3) In May 204 trevor wrote:
* 
* > I think we can use the Cert sign bit in key usage so the is CA bit
can
* > be removed from SCVP15
* 
* which was not done.


[TF] Yes I reconsidered that position. Since the 3280 path validation
algorithm uses the basic constrains extension as it's test for CA
certificates (3280, 6.1.4, k) and that algorithm is a mandatory feature
for every SCVP validation algorithm, I concluded it was safer to use the
same test rather than risk another based on key usage.

* 
* 4) Somewhat related to this, and to the provisions to search in DPD or
* validate
*    in DPV several types of extensions, I had proposed to opetionally
* search
*    for the pathlength basicconstraint. if for example a client has a
*    cert and a CA cert then one could use it to search only for CAs
that
*    have at least a pathlength of 1.
* 
* 
* I seem to understand that the rule in this WG is:
* 
* - editor, chairmen, iesg says something ==> accepted if no response
* - others ==> rejected if no response from anyone.
* 
* all totally independant of the content of the comment.
* 
* At least point 3 doesn't fit into this rule.
* 
* I'd like to to see whether there is someone participating
* in this list who agrees with something or considers it as useful ...
* 
* Thanks for consideration
* Peter
* 
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740qvU4017007; Tue, 3 Aug 2004 17:52:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i740qvpH017006; Tue, 3 Aug 2004 17:52:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i740qtSX016999 for <[e-mail]>; Tue, 3 Aug 2004 17:52:56 -0700 (PDT) (envelope-from [e-mail])
Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i740qpQl024751; Tue, 3 Aug 2004 20:52:51 -0400
Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id i740obos013483; Tue, 3 Aug 2004 20:50:37 -0400
Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id i740obJh013481; Tue, 3 Aug 2004 20:50:37 -0400
Received: from opene-130-129-131-47.ietf60.ietf.org (opene-130-129-131-47.ietf60.ietf.org [130.129.131.47])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Tue,  3 Aug 2004 20:50:37 -0400
Message-ID: <[e-mail]>
Date: Tue,  3 Aug 2004 20:50:37 -0400
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: Final Agenda for PKIX session
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 130.129.131.47
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here is the final agenda for the PKIX session at the 60th IETF.

Changes:
(1) I will present the SIM draft and the SCVP discussion, as the lead authors
are unavailable.
(2) The URL for the Internet Draft associated with Mike Myers' presentation
has been specified.
(3) Jaehoo Yoon will present the user interface draft.


Thanks,

Tim Polk

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

PKIX WG (pkix-wg)

Wednesday August 4, 2004 0900-1130
=================================

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

AGENDA:

1. WG Status and Direction

1.1 Document Status Review [Tim Polk (NIST)]

        The working group has a number of Internet-Drafts.  Many
        documents are with the ADs or in various stages of WG Last Call.
        Several others are ready for Last Call. (10 min.)

1.2 Proposed WG Milestones [Tim Polk (NIST)]

        The working group milestones are out of date.  New milestones are
        needed; these milestones need to satisfy IESG direction for an orderly
        closeout of WG activities. (10 min.)

2. PKIX WG Specifications

2.1 LDAP Specifications

       The PKIX WG has a number of LDAP-based specifications supporting
       publication and distribution of certificates and CRLs.

2.1 LDAP Schemas, String Values, and more
       - David Chadwick (U. of Salford)

   http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-02.txt
   http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-01.txt

       The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution
       for LDAP based PKI information distribution.  New drafts of two I-Ds
       have been submitted since IETF 59; additional drafts will be published
       soon after this meeting; the presenter will discuss the changes in the
       and highlight issues that must be resolved before Last Call.  (15 min.)

2.2 Practical Considerations for Use of LDAP in PKIX
       - Kurt Zeilenga (LDAPbis WG co-chair)

   (no draft)

       Practical considerations must be considered to maximize the utility
       and interoperability of LDAP-based PKIs.  This presentation will
       highlight known issues and (where applicable) ways to address them.
       (10 min.)


2.3 Matching Text Strings in PKIX Certificates
       - Paul Hoffman (IMC) and Steve Hanna (Sun)

   http://www.ietf.org/internet-drafts/draft-hoffman-pkix-stringmatch-00.txt

       This specification describes the use of Stringprep to support comparison
       and matching of international text strings.  This document resolves 
       an open issue from RFC 3280, where the minimum requirements for name 
       comparison were specified as binary matching.  Since the publication of 
       RFC 3280, the stringprep specification has been completed, providing a
       solid basis for comparison and matching of test strings in PKIX
       certificates. (15 min.)

[see also

   http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-strprep-04.txt]


2.4 RFC 3280 Progression
       - Tim Polk (NIST)

   (no draft)

       NIST will present the current plan and milestones for progression of
       RFC 3280 to Draft Standard.   (5 min.)

2.5 Subject Identification Method
       - Tim Polk

   http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-03.txt

       A new draft of the Subject Identification Method has been submitted 
since
       IETF 59.  The document is relatively stable and mature.  WG Last Call is
       expected for the next draft of this document. (15 min.)

2.6 SCVP Progression
       - Tim Polk

http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-15.txt

       This document has been in WG Last Call since early 2004.  Completion 
       of WG Last Call was blocked by newly identified implementation
       requirements for unsigned messages to support DPD.  Early proposals
       did not satisfy RFC 3739, and were rejected.  A new draft has been
       submitted since IETF 59 implementing unsigned messgaes while satisfying
       RFC 3379 and the implementation requirements. (5 min.)

3. Related Specifications & Liaison Presentations

       Time allowing, liaison presentations will be accommodated to ensure the
       PKIX WG is aware of related specifications currently progressing as 
       individual drafts.


3.1 Specification of OCSP in IKEv2
        - Mike Myers (TraceRoute)

   http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt

        This presentation will highlight issues with the specification of OCSP
        in IKEv2. (10 min.)

3.2 User Interface Requirement for the Internet X.509 Public Key Infrastructure
        - Jaehoo Yoon (KISA)

   http://www.ietf.org/internet-drafts/draft-choi-pkix-ui-00.txt

        This document provides basic requirements of user interface at PKI
        client software that satisfy a full of PKI implementation with
        usability. To meet with the requirements, it defines root CA
        certificate trust mechanism, certificate sharing mechanism, and 
        certificate representation method. (10 min.)





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72KdxdY089049; Mon, 2 Aug 2004 13:39:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72KdxXI089048; Mon, 2 Aug 2004 13:39:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72KdwIs089041 for <[e-mail]>; Mon, 2 Aug 2004 13:39:59 -0700 (PDT) (envelope-from [e-mail])
Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i72KdQQl030356; Mon, 2 Aug 2004 16:39:26 -0400
Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id i72KbEos008131; Mon, 2 Aug 2004 16:37:14 -0400
Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id i72KbEWi008129; Mon, 2 Aug 2004 16:37:14 -0400
Received: from wired-130-129-64-102.ietf60.ietf.org (wired-130-129-64-102.ietf60.ietf.org [130.129.64.102])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Mon,  2 Aug 2004 16:37:13 -0400
Message-ID: <[e-mail]>
Date: Mon,  2 Aug 2004 16:37:13 -0400
From: [e-mail]
To: Peter Sylvester <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on SCVP15
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 130.129.64.102
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Quoting Peter Sylvester <[e-mail]>:
> Note again, that Trevor answers Denis, not to my comments, 
> I may be on his black list. 

It is far more likely that Trevor did not read your message because the 
subject line indicated it was a comment on the PKIX agenda.

As Trevor is on vacation, and will not be in San Diego, comments on the agenda 
probably seem immaterial.

I have forwarded the message to Trevor with a more concise subject line...

Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Jsopk085695; Mon, 2 Aug 2004 12:54:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72Jso4M085694; Mon, 2 Aug 2004 12:54:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72JsmEo085679 for <[e-mail]>; Mon, 2 Aug 2004 12:54:49 -0700 (PDT) (envelope-from [e-mail])
Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i72JrXQl020387; Mon, 2 Aug 2004 15:53:33 -0400
Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id i72JpKos005284; Mon, 2 Aug 2004 15:51:20 -0400
Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id i72JpI8R005282; Mon, 2 Aug 2004 15:51:18 -0400
Received: from wired-130-129-64-102.ietf60.ietf.org (wired-130-129-64-102.ietf60.ietf.org [130.129.64.102])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Mon,  2 Aug 2004 15:51:18 -0400
Message-ID: <[e-mail]>
Date: Mon,  2 Aug 2004 15:51:18 -0400
From: [e-mail]
To: Peter Sylvester <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on SCVP15
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 130.129.64.102
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

In your last email you stated:

Quoting Peter Sylvester <[e-mail]>:
> Since last call, many changes had been added without any discussion, 
> i.e. all the extensions stuff, these are clearly new features, and 
> not just editorial or bug corrections. 
> 
> I think that all extensions which are features and not
> completions should be properly discussed and developed
> or removed.
> 
> Peter
> 

Please note that a "design team" was formed at my request to bring the whole 
unsigned DPD issue to resolution.  I was hoping that the design team would be 
more efficient in finding a soilution than the on-list discussion.  So, if the 
changes you refer to involve unsigned DPD, it is *entirely* appropriate for 
these features to be included in the new draft.  

To quote RFC 2418:

> 6.5. Design teams

>    It is often useful, and perhaps inevitable, for a sub-group of a
>    working group to develop a proposal to solve a particular problem.
>    Such a sub-group is called a design team.  In order for a design team
>    to remain small and agile, it is acceptable to have closed membership
>    and private meetings.  Design teams may range from an informal chat
>    between people in a hallway to a formal set of expert volunteers that
>    the WG chair or AD appoints to attack a controversial problem.  The
>    output of a design team is always subject to approval, rejection or
>    modification by the WG as a whole.

Please note the final sentence: the WG still gets the final say, not the 
design team!

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72EmcQB061849; Mon, 2 Aug 2004 07:48:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72Emc4d061848; Mon, 2 Aug 2004 07:48:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Emb51061841 for <[e-mail]>; Mon, 2 Aug 2004 07:48:37 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i72Emb835687; Mon, 2 Aug 2004 07:48:37 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, <[e-mail]>
Subject: RE: SCVP-15
Date: Mon, 2 Aug 2004 07:47:48 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I fully agree with your first point.  3379 is the defining document on
the concepts of DPD and DPV.  That's why we worked so hard on it.  But
my point is that, as with other 3379 text, those concepts need
translation into an implementable protocol.  Thus, for example, any SCVP
request containing any of the <validated path> certCheck or wantBack
values is, by definition, NOT a DPD request.  I think we need crisp,
normative definitions in this instance along the lines I proposed in
order to ensure security in implementations and interoperability among
them.

Mike



-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Trevor Freeman
Sent: Monday, August 02, 2004 12:05 AM
To: Michael Myers; [e-mail]
Subject: RE: SCVP-15



Hi Mike,
I think the definitions in 3379 are more accurate since it is what the
client does with the response which is litmus test between DPD and DPV.
I am happy to add test along the lines you suggest as illustrations of
what a DPD client might do.

Trevor

* -----Original Message-----
* From: Michael Myers [mailto:[e-mail]]
* Sent: Saturday, July 31, 2004 8:08 AM
* To: Trevor Freeman; [e-mail]
* Subject: RE: SCVP-15
*
* 3379's definitions work well for 3379, but I think the document should
* say that with respect to 3379, "DPD" in this document (i.e. SCVP)
means
* a request where:
*
* 1. certChecks contains at most id-stc-build-pkc-path; AND
*
* 2. wantBack contains at most either one or both of
*    {id-swb-pkc-cert-path, id-swb-pkc-revocation-info}.
*
* while "DPV" means a request that includes any of the other values
* defined for use in these two elements.
*
* Mike
*
* -----Original Message-----
* From: [e-mail]
* [mailto:[e-mail]]On Behalf Of Trevor Freeman
* Sent: Friday, July 30, 2004 10:38 PM
* To: Michael Myers; [e-mail]
* Subject: RE: SCVP-15
*
*
*
* Hi Mike,
* Sorry for the slow response but I am on vacation so am not reading
mail
* as frequently as normal. I agree with your point on needing clear
* definitions for DPD and DPV but I think the ones provided in 3379 are
* adequate. That would simply require adding references to sections 2
and
* 3 of the RFC.
*
* Do you agree?
* Trevor
*
* * -----Original Message-----
* * From: [e-mail]
* [mailto:[e-mail]]
* * On Behalf Of Michael Myers
* * Sent: Thursday, July 22, 2004 11:43 AM
* * To: [e-mail]
* * Subject: Re: SCVP-15
* *
* *
* * Trevor,
* *
* * Section 3.2.10, extracted below, is a good step forward to closure
on
* * the issue.  Given its definition as a BOOLEAN in Query syntax, I am
* * comfortable with its default to TRUE.
* *
* * The second paragraph however needs an implementable definition of
DPD
* * vice DPV with respect to SCVP ASN.1 in order to assert that that a
* * request is in error if it asks for a validation assertion in the
* context
* * of signResponse set to FALSE.
* *
* * Mike
* *
* *
* *
* *
* * 3.2.10 signResponse
* *
* *   The signResponse specifies if the client requires the server to
* *   sign a response to the validation request. If the client is
* *   performing full chain validation on the response and it is not
* *   concerned about the authenticity of the source of the data, then
* *   the client does not benefit from the signature on the response in
* *   which case it can indicate to the server that the signature is
* *   unnecessary via the signResponse value.
* *
* *   SCVP clients that support DPD MUST support setting this value to
* *   FALSE. Since DPV responses must be signed, DPV only SCVP clients
* *   MUST NOT to support this value. SCVP servers SHOULD support
* *   returning unsigned responses. It is a local policy decision on the
* *   part of the server to return signed or unsigned responses if this
* *   value is set to FALSE.
* *
*
*
*






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72DbpF7056994; Mon, 2 Aug 2004 06:37:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72DbpVR056993; Mon, 2 Aug 2004 06:37:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72Dbnq5056982 for <[e-mail]>; Mon, 2 Aug 2004 06:37:50 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA57874; Mon, 2 Aug 2004 15:48:12 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA29491; Mon, 2 Aug 2004 15:37:46 +0200
Message-ID: <[e-mail]>
Date: Mon, 02 Aug 2004 15:36:11 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: Peter Sylvester <[e-mail]>, [e-mail]
Subject: Re: Comments on SCVP15
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

Would you please also respond to Peter ?
Peter is correct when saying that major changes have been made.

>>Hi Denis,
>>The concern you express here is touching.

I have some difficulties to understand the meaning of this sentence.

I certainly missed some or all of the e-mails you sent explaining the 
differences between the successive versions of SCVP, or/and the section at 
the very end of the document that would be there to keep track of the 
changes until the document is published. :-(

Going back to technical concerns, we still have a major disagreement about 
the concept and the use of a validation policy.

RFC 3379 states:

    it is expected that most clients will simply reference a validation
    policy for a given application or accept the DPV server's default
    validation policy.

Referencing a validation policy does not require to define any parameter, 
hence why all validation policy parameters should be removed from the "first 
level" of the parameters from the SCVP request" and be placed under the OID 
of a "parametrable" validation policy. This is not stylistic.

RFC 3379 states:

    A validation policy is a set of rules against which the validation of
    the certificate is performed.

    A validation policy MAY include several trust anchors.  A trust
    anchor is defined as one public key, a CA name, and a validity time
    interval; a trust anchor optionally includes additional constraints.
    The use of a self-signed certificate is one way to specify the public
    key to be used, the issuer name, and the validity period of the
    public key.

    Additional constraints for each trust anchor MAY be defined.  These
    constraints might include a set of certification policy constraints
    or a set of naming constraints.  These constraints MAY also be
    included in self-signed certificates.

    Additional conditions that apply to the certificates in the path MAY
    also be specified in the validation policy.  For example, specific
    values could be provided for the inputs to the certification path
    validation algorithm in [PKIX-1], such as user-initial-policy-set,
    initial-policy-mapping-inhibit, initial-explicit-policy, or initial-
    any-policy-inhibit.

    Additional conditions that apply to the end-entity certificate MAY
    also be specified in the validation policy.  For example, a specific
    name form might be required.

I believe that our disagrement comes from the fact that you restict a 
validation policy to be only a certification path check done according to 
RFC 3280 section 6, while it may be much more than that: see above.

Denis


PS. I have no time available today to respond to your detailed response to 
my comments. I will try to do it later.


>>See answers below.
>>Trevor
>>
> 
> 
> I am not sure to whom Trevor is talking in the following. 
> Since the original message was from me, and Trevor did not
> answer, Denis, would be be so glad to comment again
> or/and to remind him that he is trying to respond to
> my message. 
> 
> Note again, that Trevor answers Denis, not to my comments, 
> I may be on his black list. 
> 
> 
>>* 
>>* Now awaiting SCVP-16 ... or much better, before issuing it, a response
>>to
>>* the many technical comments raised on this mailing list on SCVP-15.
>>
>>[TF] A reply to you last posting has been made. What is of concern is
>>the fact that you requested changes in your posting on SCVP15 to
>>sections of SCVP which have been stable for the past 15 versions. I will
>>only post draft 16 when I have a definitive and final set of issues from
>>you and there will only be editorial changes from then on. This point is
>>not negotiable. Anything else will have to wait. 
> 
> 
> Trevor, are you assuming that people haven't archived
> the previous 15 versions? configID, policyID had changed
> and this was a little bit more than a textual change IMO.
> Furthermore, the resulting texts were sometimes uncomprehensible
> since the asn1 syntaxes were inconsistent or unimplementable. 
> 
> Since last call, many changes had been added without any discussion, 
> i.e. all the extensions stuff, these are clearly new features, and 
> not just editorial or bug corrections. 
> 
> I think that all extensions which are features and not
> completions should be properly discussed and developed
> or removed.
> 
> Peter
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72D6Im0054807; Mon, 2 Aug 2004 06:06:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72D6I3J054806; Mon, 2 Aug 2004 06:06:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72D6GlE054789 for <[e-mail]>; Mon, 2 Aug 2004 06:06:17 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i72D6BN24208; Mon, 2 Aug 2004 15:06:11 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 2 Aug 2004 15:06:11 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i72D6Ad25932; Mon, 2 Aug 2004 15:06:10 +0200 (MEST)
Date: Mon, 2 Aug 2004 15:06:10 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on SCVP15
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 
> Hi Denis,
> The concern you express here is touching.
> See answers below.
> Trevor
> 

I am not sure to whom Trevor is talking in the following. 
Since the original message was from me, and Trevor did not
answer, Denis, would be be so glad to comment again
or/and to remind him that he is trying to respond to
my message. 

Note again, that Trevor answers Denis, not to my comments, 
I may be on his black list. 

> * 
> * Now awaiting SCVP-16 ... or much better, before issuing it, a response
> to
> * the many technical comments raised on this mailing list on SCVP-15.
> 
> [TF] A reply to you last posting has been made. What is of concern is
> the fact that you requested changes in your posting on SCVP15 to
> sections of SCVP which have been stable for the past 15 versions. I will
> only post draft 16 when I have a definitive and final set of issues from
> you and there will only be editorial changes from then on. This point is
> not negotiable. Anything else will have to wait. 

Trevor, are you assuming that people haven't archived
the previous 15 versions? configID, policyID had changed
and this was a little bit more than a textual change IMO.
Furthermore, the resulting texts were sometimes uncomprehensible
since the asn1 syntaxes were inconsistent or unimplementable. 

Since last call, many changes had been added without any discussion, 
i.e. all the extensions stuff, these are clearly new features, and 
not just editorial or bug corrections. 

I think that all extensions which are features and not
completions should be properly discussed and developed
or removed.

Peter














Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7275Ooq064849; Mon, 2 Aug 2004 00:05:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7275Odj064848; Mon, 2 Aug 2004 00:05:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7275NCa064838 for <[e-mail]>; Mon, 2 Aug 2004 00:05:23 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 2 Aug 2004 00:05:23 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Aug 2004 00:05:16 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Aug 2004 00:05:23 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.247]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Aug 2004 00:04:52 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: SCVP-15
Date: Mon, 2 Aug 2004 00:05:26 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP-15
thread-index: AcR3EC2oL/fZtjxPTQitT7Ak82VoEwBTocFw
From: "Trevor Freeman" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 02 Aug 2004 07:04:52.0896 (UTC) FILETIME=[024BBA00:01C4785F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7275NCa064839
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Mike,
I think the definitions in 3379 are more accurate since it is what the
client does with the response which is litmus test between DPD and DPV.
I am happy to add test along the lines you suggest as illustrations of
what a DPD client might do.

Trevor

* -----Original Message-----
* From: Michael Myers [mailto:[e-mail]]
* Sent: Saturday, July 31, 2004 8:08 AM
* To: Trevor Freeman; [e-mail]
* Subject: RE: SCVP-15
* 
* 3379's definitions work well for 3379, but I think the document should
* say that with respect to 3379, "DPD" in this document (i.e. SCVP)
means
* a request where:
* 
* 1. certChecks contains at most id-stc-build-pkc-path; AND
* 
* 2. wantBack contains at most either one or both of
*    {id-swb-pkc-cert-path, id-swb-pkc-revocation-info}.
* 
* while "DPV" means a request that includes any of the other values
* defined for use in these two elements.
* 
* Mike
* 
* -----Original Message-----
* From: [e-mail]
* [mailto:[e-mail]]On Behalf Of Trevor Freeman
* Sent: Friday, July 30, 2004 10:38 PM
* To: Michael Myers; [e-mail]
* Subject: RE: SCVP-15
* 
* 
* 
* Hi Mike,
* Sorry for the slow response but I am on vacation so am not reading
mail
* as frequently as normal. I agree with your point on needing clear
* definitions for DPD and DPV but I think the ones provided in 3379 are
* adequate. That would simply require adding references to sections 2
and
* 3 of the RFC.
* 
* Do you agree?
* Trevor
* 
* * -----Original Message-----
* * From: [e-mail]
* [mailto:[e-mail]]
* * On Behalf Of Michael Myers
* * Sent: Thursday, July 22, 2004 11:43 AM
* * To: [e-mail]
* * Subject: Re: SCVP-15
* *
* *
* * Trevor,
* *
* * Section 3.2.10, extracted below, is a good step forward to closure
on
* * the issue.  Given its definition as a BOOLEAN in Query syntax, I am
* * comfortable with its default to TRUE.
* *
* * The second paragraph however needs an implementable definition of
DPD
* * vice DPV with respect to SCVP ASN.1 in order to assert that that a
* * request is in error if it asks for a validation assertion in the
* context
* * of signResponse set to FALSE.
* *
* * Mike
* *
* *
* *
* *
* * 3.2.10 signResponse
* *
* *   The signResponse specifies if the client requires the server to
* *   sign a response to the validation request. If the client is
* *   performing full chain validation on the response and it is not
* *   concerned about the authenticity of the source of the data, then
* *   the client does not benefit from the signature on the response in
* *   which case it can indicate to the server that the signature is
* *   unnecessary via the signResponse value.
* *
* *   SCVP clients that support DPD MUST support setting this value to
* *   FALSE. Since DPV responses must be signed, DPV only SCVP clients
* *   MUST NOT to support this value. SCVP servers SHOULD support
* *   returning unsigned responses. It is a local policy decision on the
* *   part of the server to return signed or unsigned responses if this
* *   value is set to FALSE.
* *
* 
* 
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72719Ct063337; Mon, 2 Aug 2004 00:01:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i72719jp063336; Mon, 2 Aug 2004 00:01:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.8.3] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i72717q8063322 for <[e-mail]>; Mon, 2 Aug 2004 00:01:07 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 2 Aug 2004 00:01:07 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Aug 2004 00:01:02 -0700
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Aug 2004 00:01:07 -0700
Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.247]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Aug 2004 00:00:37 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: Comments on SCVP15
Date: Mon, 2 Aug 2004 00:01:10 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on SCVP15
thread-index: AcR1P+CAyilai+tBQ+m5bPv/jMvexwDFOHEA
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 02 Aug 2004 07:00:37.0107 (UTC) FILETIME=[69D56C30:01C4785E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i72717q8063324
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Denis,
The concern you express here is touching.
See answers below.
Trevor

* -----Original Message-----
* From: [e-mail]
[mailto:[e-mail]]
* On Behalf Of Denis Pinkas
* Sent: Thursday, July 29, 2004 12:06 AM
* To: Peter Sylvester
* Cc: [e-mail]
* Subject: Comments on SCVP15
* 
* 
* Peter,
* 
* I am in general agreement with the *technical* comments you sent.
* 
* The current version of SCVP is still not compliant with RFC 3379.
* A large amount of work still needs to be done on this draft.
* 
* It is also a pitty that the new draft (15) has only be officially
* distributed on July 20.
* 
* On May 17, Trevor said: "I will be posting SCVP 15 shortly so you can
* review
* the latest draft." I replied: "An extract of the proposal sent to the
* mailing list and targeted to this problem would probably save another
* round."
* 
* Should I undertstand that, for Trevor, "shortly" practically means
"more
* than 2 months" ?


[TF] I will pass on you comments to my management when we are next
discussing my work schedule. I am sure they value such input.

* 
* Now awaiting SCVP-16 ... or much better, before issuing it, a response
to
* the many technical comments raised on this mailing list on SCVP-15.

[TF] A reply to you last posting has been made. What is of concern is
the fact that you requested changes in your posting on SCVP15 to
sections of SCVP which have been stable for the past 15 versions. I will
only post draft 16 when I have a definitive and final set of issues from
you and there will only be editorial changes from then on. This point is
not negotiable. Anything else will have to wait.

* 
* Denis
* 
* (as "someone participating in this list who agrees with something or
* considers it as useful").
* 
* 
* > it seems to me that some of the results of discussions between
* > the editor and me have been forgotten or so.
* >
* >
* > I still think that the scvp is not conformant to RFC 3379
* > and/or the editors has not done something as announced.
* >
* > 1) RFC 3379 says:
* >    The DPV request MUST allow the client to request that the server
* >    include in its response additional information which will allow
* >    relying parties not trusting the DPV server to be confident that
the
* >    certificate validation has correctly been performed.  Such
* >    information may (not necessarily exclusively) consist of a
* >    certification path, revocation status information from authorized
CRL
* >    issuers or authorized OCSP responders, revocation status
information
* >    from CRL issuers or OCSP responders trusted under the validation
* >    policy, time-stamp tokens from TSAs responders trusted under the
* >    validation policy, or a DPV response from a DPV server that is
* >                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


[TF] Given that SCVP requires the server ensure that the validation
policy has been complied with and permits all the parameters for the
currently defined validation algorithms to be returned ( full
certificate path, CRLs, OCSP responses) then I consider SCVP to be fully
compliant with 3379. There are no currently defined validation
algorithms which have a TSA response as an input, however is such as
algorithm were to be defined, then the extension mechanisms within SCVP
would permit TSA responses to be also returned. It is also conceivable
that a validation algorithm where a DPV response from another SCVP
server was also an input, and the same extension mechanisms would permit
these responses to be likewise returned.

* >
* >    trusted under the validation policy.  When the certificate is
valid
* >    according to the validation policy, the server MUST, upon
request,
* >    include that information in the response.  However, the server
MAY
* >    omit that information when the certificate is invalid or when it
* >    cannot determine the validity.
* >
* >    ==> no provision (as far as I see).
* >
* >
* > 2) RFC 3379 says:
* >    When the DPV request is authenticated, the client SHOULD be able
to
* >    include a client identifier in the request for the DPV server to
copy
* >    into the response.  Mechanisms for matching this identifier with
the
* >    authenticated identity depends on local DPV server conditions
and/or
* >    the validation policy.  The DPV server MAY choose to blindly copy
the
* >    identifier, omit the identifier, or return an error response.

[TF]Peter had not linked our discussion on the requestor field to this
section of 3379 before. As you pointed out this field is intended for
SCVP relay so the current text is accurate for that purpose. Given that
this is a SHOULD clause you cannot claim that SCVP is non-conformant to
3379 if it does not support this feature. 

* >
* > The current text is SCVP says:
* >
* >   The OPTIONAL requestor item is used to identify the requestor.
The
* >   value is only of local significance to the requestor.  If the SCVP
* >   client includes a requestor value in the request, then the SCVP
* >   server MUST return the same value if the server is generating a
* >   specific response.
* >
* >
* > tf also said:
* >
* >
* >>Given there are plenty of ways a client can generate a "unique" as
well
* >>as other behaviors like it can encode a DN in the octet sting if it
* >>likes I don't see a problem. Its down to the client to do what it
thinks
* >>fit. The value is simply replayed by the server so it is treated a
* >>binary blob.
* >
* >
* > There is nothing else possible for the server except copying, or,
* > no mechanisms to match this with the some authenticated entity
* > can be safely developped if it is solely 'up to the client to encode
* whatever'.
* >
* > I had proposed two changes to the logic of 0 terminated octet
strings
* by:
* >
* > - a sequence of octet strings allowing a real opaque string.
* > - a choice of generalname
* >
* > I.e.
* >
* >    Identifiers ::= SEQUENCE OF {
* >           CHOICE {
* >                opaqueId OCTET STRING,
* >                nameId GeneralName
* >           }
* >
* > No comment to this proposition as far as I remember.
* >
* > 3) In May 204 trevor wrote:
* >
* >
* >>I think we can use the Cert sign bit in key usage so the is CA bit
can
* >>be removed from SCVP15
* >
* >
* > which was not done.


[TF] Yes I reconsidered that position. Since the 3280 path validation
algorithm uses the basic constrains extension as it's test for CA
certificates (3280, 6.1.4 k) and that algorithm is a mandatory feature
for every SCVP validation algorithm, I concluded it was safer to use the
same test rather than risk another based on key usage.


* >
* > 4) Somewhat related to this, and to the provisions to search in DPD
or
* validate
* >    in DPV several types of extensions, I had proposed to opetionally
* search
* >    for the pathlength basicconstraint. if for example a client has a
* >    cert and a CA cert then one could use it to search only for CAs
that
* >    have at least a pathlength of 1.
* >
* >
* > I seem to understand that the rule in this WG is:
* >
* > - editor, chairmen, iesg says something ==> accepted if no response
* > - others ==> rejected if no response from anyone.
* >
* > all totally independant of the content of the comment.
* >
* > At least point 3 doesn't fit into this rule.
* >
* > I'd like to to see whether there is someone participating
* > in this list who agrees with something or considers it as useful ...
* >
* > Thanks for consideration
* > Peter
* >
* >
* >
* >
*