RE: Rationales for CA clearance constraints

[Tom Gindin <[e-mail]>]

        Dave:

        This leaves me with one question.  Is a processing directive 
similar 
to my proposed rule C for clearance constraints legal? 
C)      Any relying party unfamiliar with a given SecurityCategory.Type 
SHOULD treat the intersection of two SecurityCategory entries with that 
Type and different Value as being empty

                Tom Gindin




"Kemp, David P." <[e-mail]> 
Sent by: [e-mail]
10/31/2008 02:26 PM

To
<[e-mail]>
cc

Subject
RE: Rationales for CA clearance constraints







Santosh,

5280 uses the verbs "recognize" and "process".   It is not necessary to
provide any more precision than currently exists to argue that using two
verbs creates confusion because they refer to the same atomic operation.
An application must produce a specified result when presented with a
particular extension -- we don't care one iota if it "recognizes" the
extension but fails to produce that result or doesn't "recognize" the
extension and still fails to produce the result.  The application either
produces the result by "processing" the extension or it doesn't.

When the non-critical requirement is translated to use only one verb,
Tim's problem goes away:

   A non-critical extension MAY be ignored if it cannot be processed,
but MUST be processed if it can be.

But this is still not good enough: if you MAY ignore it, what do you do
if you choose not to ignore it and can't process it?  My suggested
language tried to be more explicit in saying that an application MUST
either ignore a non-critical extension or reject the certificate if the
extension cannot be processed, and if the extension is processed, the
processing MUST NOT vary based on the value of the critical flag.

Dave


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, October 31, 2008 1:18 PM
To: Kemp, David P.
Cc: [e-mail]
Subject: RE: Rationales for CA clearance constraints

Dave,

What do you mean by "able to process an extension" or "information that
it can <not> process"?  Once we all have a common ground on what we mean
by processing an extension and processing information, then only can we
determine if 5280 needs to be changed.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Kemp, David P.
Sent: Friday, October 31, 2008 12:45 PM
To: [e-mail]
Subject: RE: Rationales for CA clearance constraints


Agree with Steve (and by implication disagree with Paul and Santosh).

The language of 5280 ...

    4.2.  Certificate Extensions

      A certificate-using system MUST reject the certificate if it
encounters
      a critical extension it does not recognize or a critical extension
      that contains information that it cannot process.  A non-critical
      extension MAY be ignored if it is not recognized, but MUST be
      processed if it is recognized.

... is misleading in that it implies that there are two different cases
for rejection: those for which the extension is not recognized and those
for which the extension is recognized but the data within the extension
is not (forex because unrecognized types are used in a table constraint
or because a later version uses fields not defined in an extensible
earlier version).   But there is really only one case: the specific
instance of the extension under consideration cannot be processed.

The language of 5280 should be changed.  It is not necessary to address
this on a per-extension basis, even though it is possible for a specific
extension to define mandatory and optional processing requirements.

      A certificate-using system MUST reject the certificate if it
encounters
      a critical extension that it cannot process.  If a
certificate-using system
      encounters a non-critical extension, it MUST either process the
extension
      as if it were marked critical or ignore the extension entirely.

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: Wednesday, October 29, 2008 1:08 AM
To: Timothy J. Miller
Cc: Yoav Nir; Paul Hoffman; [e-mail]
Subject: Re: Rationales for CA clearance constraints


At 8:11 AM -0500 10/28/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>if this extension is marked critical, then an RP that does not 
>>understand it will declare the cert invalid, which is the desired 
>>outcome.
>
>Ah, but what about a RP that understands the extension but *not* the 
>intersection logic of the policy?  Accept or reject?  If accept, how 
>do we know the constraint was applied correctly?
>
>-- Tim

An RP either knows how to process constraints under a specified 
policy, or it doesn't. If it doesn't, the cert MUST be rejected.

Steve


-------- Original Message -----------
>Paul Hoffman wrote:
>
>>>If the ACC extension is non-critical and the RP doesn't grok the
policy requirements, ...?
>
>>The draft should say what to do in that case.
>
>Is this something that *5280* should say?  It seems like a missing
case--extension non-critical but contains information that can't be
processed.

I don't think so. It should be on an extension-by-extension basis, with
the spec of the extension having to say what to do in all cases.

--Paul Hoffman, Director
--VPN Consortium






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VLdBgo021212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2008 14:39:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9VLdBi0021211; Fri, 31 Oct 2008 14:39:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VLcxl3021171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 31 Oct 2008 14:39:10 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9VLcxaX017459 for <[e-mail]>; Fri, 31 Oct 2008 17:38:59 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9VLcxex125354 for <[e-mail]>; Fri, 31 Oct 2008 17:38:59 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9VLcwP3023808 for <[e-mail]>; Fri, 31 Oct 2008 17:38:58 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9VLcwO9023802; Fri, 31 Oct 2008 17:38:58 -0400
In-Reply-To: <[e-mail]>
To: "Kemp, David P." <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: RE: Rationales for CA clearance constraints
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 31 Oct 2008 17:38:57 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1|February 07, 2008) at 10/31/2008 17:38:58, Serialize complete at 10/31/2008 17:38:58
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>

        Dave:

        This leaves me with one question.  Is a processing directive 
similar 
to my proposed rule C for clearance constraints legal? 
C)      Any relying party unfamiliar with a given SecurityCategory.Type 
SHOULD treat the intersection of two SecurityCategory entries with that 
Type and different Value as being empty

                Tom Gindin




"Kemp, David P." <[e-mail]> 
Sent by: [e-mail]
10/31/2008 02:26 PM

To
<[e-mail]>
cc

Subject
RE: Rationales for CA clearance constraints







Santosh,

5280 uses the verbs "recognize" and "process".   It is not necessary to
provide any more precision than currently exists to argue that using two
verbs creates confusion because they refer to the same atomic operation.
An application must produce a specified result when presented with a
particular extension -- we don't care one iota if it "recognizes" the
extension but fails to produce that result or doesn't "recognize" the
extension and still fails to produce the result.  The application either
produces the result by "processing" the extension or it doesn't.

When the non-critical requirement is translated to use only one verb,
Tim's problem goes away:

   A non-critical extension MAY be ignored if it cannot be processed,
but MUST be processed if it can be.

But this is still not good enough: if you MAY ignore it, what do you do
if you choose not to ignore it and can't process it?  My suggested
language tried to be more explicit in saying that an application MUST
either ignore a non-critical extension or reject the certificate if the
extension cannot be processed, and if the extension is processed, the
processing MUST NOT vary based on the value of the critical flag.

Dave


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]] 
Sent: Friday, October 31, 2008 1:18 PM
To: Kemp, David P.
Cc: [e-mail]
Subject: RE: Rationales for CA clearance constraints

Dave,

What do you mean by "able to process an extension" or "information that
it can <not> process"?  Once we all have a common ground on what we mean
by processing an extension and processing information, then only can we
determine if 5280 needs to be changed.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Kemp, David P.
Sent: Friday, October 31, 2008 12:45 PM
To: [e-mail]
Subject: RE: Rationales for CA clearance constraints


Agree with Steve (and by implication disagree with Paul and Santosh).

The language of 5280 ...

    4.2.  Certificate Extensions

      A certificate-using system MUST reject the certificate if it
encounters
      a critical extension it does not recognize or a critical extension
      that contains information that it cannot process.  A non-critical
      extension MAY be ignored if it is not recognized, but MUST be
      processed if it is recognized.

... is misleading in that it implies that there are two different cases
for rejection: those for which the extension is not recognized and those
for which the extension is recognized but the data within the extension
is not (forex because unrecognized types are used in a table constraint
or because a later version uses fields not defined in an extensible
earlier version).   But there is really only one case: the specific
instance of the extension under consideration cannot be processed.

The language of 5280 should be changed.  It is not necessary to address
this on a per-extension basis, even though it is possible for a specific
extension to define mandatory and optional processing requirements.

      A certificate-using system MUST reject the certificate if it
encounters
      a critical extension that it cannot process.  If a
certificate-using system
      encounters a non-critical extension, it MUST either process the
extension
      as if it were marked critical or ignore the extension entirely.

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: Wednesday, October 29, 2008 1:08 AM
To: Timothy J. Miller
Cc: Yoav Nir; Paul Hoffman; [e-mail]
Subject: Re: Rationales for CA clearance constraints


At 8:11 AM -0500 10/28/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>if this extension is marked critical, then an RP that does not 
>>understand it will declare the cert invalid, which is the desired 
>>outcome.
>
>Ah, but what about a RP that understands the extension but *not* the 
>intersection logic of the policy?  Accept or reject?  If accept, how 
>do we know the constraint was applied correctly?
>
>-- Tim

An RP either knows how to process constraints under a specified 
policy, or it doesn't. If it doesn't, the cert MUST be rejected.

Steve


-------- Original Message -----------
>Paul Hoffman wrote:
>
>>>If the ACC extension is non-critical and the RP doesn't grok the
policy requirements, ...?
>
>>The draft should say what to do in that case.
>
>Is this something that *5280* should say?  It seems like a missing
case--extension non-critical but contains information that can't be
processed.

I don't think so. It should be on an extension-by-extension basis, with
the spec of the extension having to say what to do in all cases.

--Paul Hoffman, Director
--VPN Consortium





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VL7n3E014636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2008 14:07:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9VL7nHI014635; Fri, 31 Oct 2008 14:07:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VL7c6x014609 for <[e-mail]>; Fri, 31 Oct 2008 14:07:49 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id m9VL7Ye9013955 for <[e-mail]>; Fri, 31 Oct 2008 17:07:36 -0400 (EDT)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 17:05:34 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Rationales for CA clearance constraints
Date: Fri, 31 Oct 2008 17:07:33 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack7hSXiwesJM5dJTUmFiavhyQdorQAAWBvw
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 31 Oct 2008 21:05:34.0171 (UTC) FILETIME=[6A55BAB0:01C93B9C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave C,

I start with the assumption that an extension marked critical must be
processed identically to an extension marked non-critical if it is
processed at all, and that processing requirements that refer to
criticality are therefore incorrect.  Name constraints has two such
statements (here is one) ...

   If a name constraints extension that is marked as critical
   imposes constraints on a particular name form, and an instance of
   that name form appears in the subject field or subjectAltName
   extension of a subsequent certificate, then the application MUST
   either process the constraint or reject the certificate.

... and conforming CAs MUST mark name constraints as critical.  If an
application finds a non-critical name constraints and a path contains
SANs using dNSname form and the application cannot process that form,
then it is better to reject the certificate than to constrain subject DN
while allowing dNSname to pass unconstrained.  Under what circumstances
would it ever be a good thing to process some name constraints while
silently ignoring others?


As you state with the AIA example, it is possible to define rules for
processing a critical extension that state what information can be
ignored without invalidating the certificate.   5280 correctly says that
conforming CAs MUST mark AIA as non-critical because there is no reason
for the extension invalidate a certificate.  But if an application
receives a critical AIA, the correct processing is still to not
invalidate a certificate even if no AccessDescription instances can be
initiated or no results are received.  There are no processing
requirements that refer to criticality, and in my opinion any
interpretation of a critical AIA that requires applications to initiate
a query for any (or every) AccessDescription present in the extension is
incorrect.


For a third example, 5280 allows the CA to mark EKU as either critical
or non-critical.  However, the processing requirements, again correctly,
make no reference to criticality:

   If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated.  If multiple purposes are
   indicated the application need not recognize all purposes indicated,
   as long as the intended purpose is present.


To answer your last question below, "no".  But the same behavior
(processing what it can and ignoring the rest) should be required where
appropriate (as with AIA and EKU) if the extension is marked critical.
Name constraints should be fixed so that the appropriate behavior
(constrain all present subject names or reject) is required even if the
constraint is non-critical.

Dave K


-----Original Message-----
From: David A. Cooper [mailto:[e-mail]]=20
Sent: Friday, October 31, 2008 2:18 PM
To: Kemp, David P.
Cc: [e-mail]
Subject: Re: Rationales for CA clearance constraints

Kemp, David P. wrote:
> The language of 5280 should be changed.  It is not necessary to
address
> this on a per-extension basis, even though it is possible for a
specific
> extension to define mandatory and optional processing requirements.
>
>  A certificate-using system MUST reject the certificate if it
encounters
>  a critical extension that it cannot process.  If a certificate-using
system
>  encounters a non-critical extension, it MUST either process the
extension
>  as if it were marked critical or ignore the extension entirely.

David,

I believe that the reason that 5280 did not provide more information=20
about how to process non-critical extensions for which the client is=20
only capable of processing some of the information in the extension was=20
the difficultly in arriving at consensus of what the rule should be.  I=20
believe that according to X.509, one should essentially process the=20
non-critical extension to the degree possible and ignore those portions=20
that cannot be processed.

The following text appears in X.509:

   If unknown elements appear within the extension, and the extension
   is not marked critical, those unknown elements shall be ignored
   according to the rules of extensibility documented in 12.2.2 in
   ITU-T Rec. X.519 | ISO/IEC 9594-5.

The relevant text from X.519 seems to be:

  a) ignore all unknown bit name assignments within a bit string; and

  b) ignore all unknown named numbers in an ENUMERATED type
     or INTEGER type that is being used in the enumerated style,
     provided the number occurs as an optional element of a SET or
     SEQUENCE; and

  c) ignore all unknown elements in SETs, at the end of SEQUENCEs,
     or in CHOICEs where the CHOICE is itself an optional element
     of a SET or SEQUENCE.


To give a couple of examples, if a nameConstraints extension is=20
non-critical, the client should process the constraint for any name=20
forms that are present that it can process and ignore the presence of=20
any name forms that it cannot process.  That seems preferable to=20
ignoring all of the constraints in the extension simply because some of=20
the constraints cannot be processed.  Similarly, if a non-critical=20
policyConstraints extension is present and includes both=20
requireExplicitPolicy and inhibitPolicyMappings, but the client can only

process one of the two, shouldn't the client process rather than ignore=20
the field that it can process?

How would the rule that you propose apply to an extension, such as=20
authorityInfoAccess, that by definition MUST always be marked=20
non-critical?  If the AIA extension included an instance of a new=20
accessMethod that the client didn't recognize would the client be=20
required to ignore all of the potentially useful information in the=20
extension or would we need to define rules for the processing of a=20
critical AIA extension that would specifically allow the client to use=20
whatever information it wanted from the extension and ignore the rest?

Can you point to an extension that might be marked non-critical for=20
which a client that cannot process all of the information included in an

instance of the extension would be better off ignoring the entire=20
extension rather than processing those portions that it can process?

Dave



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VKmm7l011474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2008 13:48:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9VKmmc2011473; Fri, 31 Oct 2008 13:48:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9VKmaEU011436 for <[e-mail]>; Fri, 31 Oct 2008 13:48:47 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 31518 invoked from network); 31 Oct 2008 20:49:00 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Oct 2008 20:49:00 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Oct 2008 20:49:00 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Rationales for CA clearance constraints
Date: Fri, 31 Oct 2008 16:48:35 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack5lH38MADFOTDUSv6E42+4crixfAB1/pSAAAPQt2AAAFl6MAAHKGhg
References:  <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Kemp, David P." <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,

If you are basically saying that if the extension is processed, the
processing results should not be impacted due to criticality, I am with
you.  We have not done anything other than that in the I-D.

We look forward to your feedback after the I-D is posted and you have a
chance to review the actual text.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Kemp, David P.
Sent: Friday, October 31, 2008 2:26 PM
To: [e-mail]
Subject: RE: Rationales for CA clearance constraints


Santosh,

5280 uses the verbs "recognize" and "process".   It is not necessary to
provide any more precision than currently exists to argue that using two
verbs creates confusion because they refer to the same atomic operation.
An application must produce a specified result when presented with a
particular extension -- we don't care one iota if it "recognizes" the
extension but fails to produce that result or doesn't "recognize" the
extension and still fails to produce the result.  The application either
produces the result by "processing" the extension or it doesn't.

When the non-critical requirement is translated to use only one verb,
Tim's problem goes away:

   A non-critical extension MAY be ignored if it cannot be processed,
but MUST be processed if it can be.

But this is still not good enough: if you MAY ignore it, what do you do
if you choose not to ignore it and can't process it?  My suggested
language tried to be more explicit in saying that an application MUST
either ignore a non-critical extension or reject the certificate if the
extension cannot be processed, and if the extension is processed, the
processing MUST NOT vary based on the value of the critical flag.

Dave


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]=20
Sent: Friday, October 31, 2008 1:18 PM
To: Kemp, David P.
Cc: [e-mail]
Subject: RE: Rationales for CA clearance constraints

Dave,

What do you mean by "able to process an extension" or "information that
it can <not> process"?  Once we all have a common ground on what we mean
by processing an extension and processing information, then only can we
determine if 5280 needs to be changed.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Kemp, David P.
Sent: Friday, October 31, 2008 12:45 PM
To: [e-mail]
Subject: RE: Rationales for CA clearance constraints


Agree with Steve (and by implication disagree with Paul and Santosh).

The language of 5280 ...

    4.2.  Certificate Extensions

      A certificate-using system MUST reject the certificate if it
encounters
      a critical extension it does not recognize or a critical extension
      that contains information that it cannot process.  A non-critical
      extension MAY be ignored if it is not recognized, but MUST be
      processed if it is recognized.

... is misleading in that it implies that there are two different cases
for rejection: those for which the extension is not recognized and those
for which the extension is recognized but the data within the extension
is not (forex because unrecognized types are used in a table constraint
or because a later version uses fields not defined in an extensible
earlier version).   But there is really only one case: the specific
instance of the extension under consideration cannot be processed.

The language of 5280 should be changed.  It is not necessary to address
this on a per-extension basis, even though it is possible for a specific
extension to define mandatory and optional processing requirements.

      A certificate-using system MUST reject the certificate if it
encounters
      a critical extension that it cannot process.  If a
certificate-using system
      encounters a non-critical extension, it MUST either process the
extension
      as if it were marked critical or ignore the extension entirely.

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: Wednesday, October 29, 2008 1:08 AM
To: Timothy J. Miller
Cc: Yoav Nir; Paul Hoffman; [e-mail]
Subject: Re: Rationales for CA clearance constraints


At 8:11 AM -0500 10/28/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>if this extension is marked critical, then an RP that does not=20
>>understand it will declare the cert invalid, which is the desired=20
>>outcome.
>
>Ah, but what about a RP that understands the extension but *not* the=20
>intersection logic of the policy?  Accept or reject?  If accept, how=20
>do we know the constraint was applied correctly?
>
>-- Tim

An RP either knows how to process constraints under a specified=20
policy, or it doesn't. If it doesn't, the cert MUST be rejected.

Steve


-------- Original Message -----------
>Paul Hoffman wrote:
>
>>>If the ACC extension is non-critical and the RP doesn't grok the
policy requirements, ...?
>
>>The draft should say what to do in that case.
>
>Is this something that *5280* should say?  It seems like a missing
case--extension non-critical but contains information that can't be
processed.

I don't think so. It should be on an extension-by-extension basis, with
the spec of the extension having to say what to do in all cases.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VIQ7xa084276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2008 11:26:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9VIQ7KT084275; Fri, 31 Oct 2008 11:26:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VIQ7oM084259 for <[e-mail]>; Fri, 31 Oct 2008 11:26:07 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id m9VIQ5UT007223 for <[e-mail]>; Fri, 31 Oct 2008 14:26:05 -0400 (EDT)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 14:24:05 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Rationales for CA clearance constraints
Date: Fri, 31 Oct 2008 14:26:04 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack5lH38MADFOTDUSv6E42+4crixfAB1/pSAAAPQt2AAAFl6MA==
References:  <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 31 Oct 2008 18:24:05.0765 (UTC) FILETIME=[DB984B50:01C93B85]
Sender: [e-mail]
Precedence: 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,

5280 uses the verbs "recognize" and "process".   It is not necessary to
provide any more precision than currently exists to argue that using two
verbs creates confusion because they refer to the same atomic operation.
An application must produce a specified result when presented with a
particular extension -- we don't care one iota if it "recognizes" the
extension but fails to produce that result or doesn't "recognize" the
extension and still fails to produce the result.  The application either
produces the result by "processing" the extension or it doesn't.

When the non-critical requirement is translated to use only one verb,
Tim's problem goes away:

   A non-critical extension MAY be ignored if it cannot be processed,
but MUST be processed if it can be.

But this is still not good enough: if you MAY ignore it, what do you do
if you choose not to ignore it and can't process it?  My suggested
language tried to be more explicit in saying that an application MUST
either ignore a non-critical extension or reject the certificate if the
extension cannot be processed, and if the extension is processed, the
processing MUST NOT vary based on the value of the critical flag.

Dave


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]=20
Sent: Friday, October 31, 2008 1:18 PM
To: Kemp, David P.
Cc: [e-mail]
Subject: RE: Rationales for CA clearance constraints

Dave,

What do you mean by "able to process an extension" or "information that
it can <not> process"?  Once we all have a common ground on what we mean
by processing an extension and processing information, then only can we
determine if 5280 needs to be changed.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Kemp, David P.
Sent: Friday, October 31, 2008 12:45 PM
To: [e-mail]
Subject: RE: Rationales for CA clearance constraints


Agree with Steve (and by implication disagree with Paul and Santosh).

The language of 5280 ...

    4.2.  Certificate Extensions

      A certificate-using system MUST reject the certificate if it
encounters
      a critical extension it does not recognize or a critical extension
      that contains information that it cannot process.  A non-critical
      extension MAY be ignored if it is not recognized, but MUST be
      processed if it is recognized.

... is misleading in that it implies that there are two different cases
for rejection: those for which the extension is not recognized and those
for which the extension is recognized but the data within the extension
is not (forex because unrecognized types are used in a table constraint
or because a later version uses fields not defined in an extensible
earlier version).   But there is really only one case: the specific
instance of the extension under consideration cannot be processed.

The language of 5280 should be changed.  It is not necessary to address
this on a per-extension basis, even though it is possible for a specific
extension to define mandatory and optional processing requirements.

      A certificate-using system MUST reject the certificate if it
encounters
      a critical extension that it cannot process.  If a
certificate-using system
      encounters a non-critical extension, it MUST either process the
extension
      as if it were marked critical or ignore the extension entirely.

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: Wednesday, October 29, 2008 1:08 AM
To: Timothy J. Miller
Cc: Yoav Nir; Paul Hoffman; [e-mail]
Subject: Re: Rationales for CA clearance constraints


At 8:11 AM -0500 10/28/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>if this extension is marked critical, then an RP that does not=20
>>understand it will declare the cert invalid, which is the desired=20
>>outcome.
>
>Ah, but what about a RP that understands the extension but *not* the=20
>intersection logic of the policy?  Accept or reject?  If accept, how=20
>do we know the constraint was applied correctly?
>
>-- Tim

An RP either knows how to process constraints under a specified=20
policy, or it doesn't. If it doesn't, the cert MUST be rejected.

Steve


-------- Original Message -----------
>Paul Hoffman wrote:
>
>>>If the ACC extension is non-critical and the RP doesn't grok the
policy requirements, ...?
>
>>The draft should say what to do in that case.
>
>Is this something that *5280* should say?  It seems like a missing
case--extension non-critical but contains information that can't be
processed.

I don't think so. It should be on an extension-by-extension basis, with
the spec of the extension having to say what to do in all cases.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VIIw5D082995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2008 11:18:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9VIIwBJ082994; Fri, 31 Oct 2008 11:18:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VIIu0a082979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 31 Oct 2008 11:18:57 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9VIIrMU021523; Fri, 31 Oct 2008 14:18:53 -0400
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m9VIIkNo024497; Fri, 31 Oct 2008 14:18:47 -0400
Message-ID: <[e-mail]>
Date: Fri, 31 Oct 2008 14:18:01 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (X11/20080926)
MIME-Version: 1.0
To: "Kemp, David P." <[e-mail]>
CC: [e-mail]
Subject: Re: Rationales for CA clearance constraints
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-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>

Kemp, David P. wrote:
> The language of 5280 should be changed.  It is not necessary to address
> this on a per-extension basis, even though it is possible for a specific
> extension to define mandatory and optional processing requirements.
>
>  A certificate-using system MUST reject the certificate if it encounters
>  a critical extension that it cannot process.  If a certificate-using system
>  encounters a non-critical extension, it MUST either process the extension
>  as if it were marked critical or ignore the extension entirely.

David,

I believe that the reason that 5280 did not provide more information 
about how to process non-critical extensions for which the client is 
only capable of processing some of the information in the extension was 
the difficultly in arriving at consensus of what the rule should be.  I 
believe that according to X.509, one should essentially process the 
non-critical extension to the degree possible and ignore those portions 
that cannot be processed.

The following text appears in X.509:

   If unknown elements appear within the extension, and the extension
   is not marked critical, those unknown elements shall be ignored
   according to the rules of extensibility documented in 12.2.2 in
   ITU-T Rec. X.519 | ISO/IEC 9594-5.

The relevant text from X.519 seems to be:

  a) ignore all unknown bit name assignments within a bit string; and

  b) ignore all unknown named numbers in an ENUMERATED type
     or INTEGER type that is being used in the enumerated style,
     provided the number occurs as an optional element of a SET or
     SEQUENCE; and

  c) ignore all unknown elements in SETs, at the end of SEQUENCEs,
     or in CHOICEs where the CHOICE is itself an optional element
     of a SET or SEQUENCE.


To give a couple of examples, if a nameConstraints extension is 
non-critical, the client should process the constraint for any name 
forms that are present that it can process and ignore the presence of 
any name forms that it cannot process.  That seems preferable to 
ignoring all of the constraints in the extension simply because some of 
the constraints cannot be processed.  Similarly, if a non-critical 
policyConstraints extension is present and includes both 
requireExplicitPolicy and inhibitPolicyMappings, but the client can only 
process one of the two, shouldn't the client process rather than ignore 
the field that it can process?

How would the rule that you propose apply to an extension, such as 
authorityInfoAccess, that by definition MUST always be marked 
non-critical?  If the AIA extension included an instance of a new 
accessMethod that the client didn't recognize would the client be 
required to ignore all of the potentially useful information in the 
extension or would we need to define rules for the processing of a 
critical AIA extension that would specifically allow the client to use 
whatever information it wanted from the extension and ignore the rest?

Can you point to an extension that might be marked non-critical for 
which a client that cannot process all of the information included in an 
instance of the extension would be better off ignoring the entire 
extension rather than processing those portions that it can process?

Dave



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VHIVY2068221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2008 10:18:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9VHIVu2068220; Fri, 31 Oct 2008 10:18:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9VHIKxM068178 for <[e-mail]>; Fri, 31 Oct 2008 10:18:30 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 29443 invoked from network); 31 Oct 2008 17:18:42 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Oct 2008 17:18:42 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Oct 2008 17:18:42 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Rationales for CA clearance constraints
Date: Fri, 31 Oct 2008 13:18:17 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack5lH38MADFOTDUSv6E42+4crixfAB1/pSAAAPQt2A=
References:  <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Kemp, David P." <[e-mail]>
Cc: <[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>

Dave,

What do you mean by "able to process an extension" or "information that
it can <not> process"?  Once we all have a common ground on what we mean
by processing an extension and processing information, then only can we
determine if 5280 needs to be changed.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Kemp, David P.
Sent: Friday, October 31, 2008 12:45 PM
To: [e-mail]
Subject: RE: Rationales for CA clearance constraints


Agree with Steve (and by implication disagree with Paul and Santosh).

The language of 5280 ...

    4.2.  Certificate Extensions

      A certificate-using system MUST reject the certificate if it
encounters
      a critical extension it does not recognize or a critical extension
      that contains information that it cannot process.  A non-critical
      extension MAY be ignored if it is not recognized, but MUST be
      processed if it is recognized.

... is misleading in that it implies that there are two different cases
for rejection: those for which the extension is not recognized and those
for which the extension is recognized but the data within the extension
is not (forex because unrecognized types are used in a table constraint
or because a later version uses fields not defined in an extensible
earlier version).   But there is really only one case: the specific
instance of the extension under consideration cannot be processed.

The language of 5280 should be changed.  It is not necessary to address
this on a per-extension basis, even though it is possible for a specific
extension to define mandatory and optional processing requirements.

      A certificate-using system MUST reject the certificate if it
encounters
      a critical extension that it cannot process.  If a
certificate-using system
      encounters a non-critical extension, it MUST either process the
extension
      as if it were marked critical or ignore the extension entirely.

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: Wednesday, October 29, 2008 1:08 AM
To: Timothy J. Miller
Cc: Yoav Nir; Paul Hoffman; [e-mail]
Subject: Re: Rationales for CA clearance constraints


At 8:11 AM -0500 10/28/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>if this extension is marked critical, then an RP that does not=20
>>understand it will declare the cert invalid, which is the desired=20
>>outcome.
>
>Ah, but what about a RP that understands the extension but *not* the=20
>intersection logic of the policy?  Accept or reject?  If accept, how=20
>do we know the constraint was applied correctly?
>
>-- Tim

An RP either knows how to process constraints under a specified=20
policy, or it doesn't. If it doesn't, the cert MUST be rejected.

Steve


-------- Original Message -----------
>Paul Hoffman wrote:
>
>>>If the ACC extension is non-critical and the RP doesn't grok the
policy requirements, ...?
>
>>The draft should say what to do in that case.
>
>Is this something that *5280* should say?  It seems like a missing
case--extension non-critical but contains information that can't be
processed.

I don't think so. It should be on an extension-by-extension basis, with
the spec of the extension having to say what to do in all cases.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VGj4SN061063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2008 09:45:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9VGj4vE061062; Fri, 31 Oct 2008 09:45:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VGir7x061027 for <[e-mail]>; Fri, 31 Oct 2008 09:45:03 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id m9VGiqg4000451 for <[e-mail]>; Fri, 31 Oct 2008 12:44:52 -0400 (EDT)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Oct 2008 12:42:52 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Rationales for CA clearance constraints
Date: Fri, 31 Oct 2008 12:44:52 -0400
Message-ID: <[e-mail]>
In-Reply-To: <p06240507c52d9fe588ca@[193.0.24.250]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack5lH38MADFOTDUSv6E42+4crixfAB1/pSA
References:  <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 31 Oct 2008 16:42:52.0796 (UTC) FILETIME=[B7D2C3C0:01C93B77]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Agree with Steve (and by implication disagree with Paul and Santosh).

The language of 5280 ...

    4.2.  Certificate Extensions

      A certificate-using system MUST reject the certificate if it
encounters
      a critical extension it does not recognize or a critical extension
      that contains information that it cannot process.  A non-critical
      extension MAY be ignored if it is not recognized, but MUST be
      processed if it is recognized.

... is misleading in that it implies that there are two different cases
for rejection: those for which the extension is not recognized and those
for which the extension is recognized but the data within the extension
is not (forex because unrecognized types are used in a table constraint
or because a later version uses fields not defined in an extensible
earlier version).   But there is really only one case: the specific
instance of the extension under consideration cannot be processed.

The language of 5280 should be changed.  It is not necessary to address
this on a per-extension basis, even though it is possible for a specific
extension to define mandatory and optional processing requirements.

      A certificate-using system MUST reject the certificate if it
encounters
      a critical extension that it cannot process.  If a
certificate-using system
      encounters a non-critical extension, it MUST either process the
extension
      as if it were marked critical or ignore the extension entirely.

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: Wednesday, October 29, 2008 1:08 AM
To: Timothy J. Miller
Cc: Yoav Nir; Paul Hoffman; [e-mail]
Subject: Re: Rationales for CA clearance constraints


At 8:11 AM -0500 10/28/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>if this extension is marked critical, then an RP that does not=20
>>understand it will declare the cert invalid, which is the desired=20
>>outcome.
>
>Ah, but what about a RP that understands the extension but *not* the=20
>intersection logic of the policy?  Accept or reject?  If accept, how=20
>do we know the constraint was applied correctly?
>
>-- Tim

An RP either knows how to process constraints under a specified=20
policy, or it doesn't. If it doesn't, the cert MUST be rejected.

Steve


-------- Original Message -----------
>Paul Hoffman wrote:
>
>>>If the ACC extension is non-critical and the RP doesn't grok the
policy requirements, ...?
>
>>The draft should say what to do in that case.
>
>Is this something that *5280* should say?  It seems like a missing
case--extension non-critical but contains information that can't be
processed.

I don't think so. It should be on an extension-by-extension basis, with
the spec of the extension having to say what to do in all cases.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9ULTBkG052261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 14:29:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9ULTAJD052259; Thu, 30 Oct 2008 14:29:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9ULSxtD052212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Oct 2008 14:29:10 -0700 (MST) (envelope-from [e-mail])
Received: from [10.211.55.3] (dhcp-212-205.cs.dartmouth.edu [129.170.212.205]) (authenticated bits=0) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id m9ULSHnG001589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Oct 2008 17:28:18 -0400
Message-ID: <[e-mail]>
Date: Thu, 30 Oct 2008 17:28:17 -0400
From: Scott Rea <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Thierry Moreau <[e-mail]>
CC: [e-mail]
Subject: Re: A random PKI question ... (philosophic)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
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>

The idea of being able to sign in a browser would give it credence to 
being the ultimate UI tool to enable a lot more applications than it 
currently can without the kludgey add-ons. But what is proposed is 
ultimately just a tool - Thierry you seem to be referring to an 
implementation issue or how the "tool" might be used. A car is a great 
tool for moving people or cargo efficiently and speedily over vast 
distances, but if it is pointed at a person, or another car, it can kill 
or maim them - that doesn't make the car inherently bad - its just a bad 
use of a tool.
And as far as signatures go - they are just an artifact to prove intent 
of the signer  - it usually comes down to lawyers if there's a challenge 
anyway. Sign tags in a browser would just give applications better tools 
to implement their logic.
-Scott

Thierry Moreau wrote:
>
> OK, while off-topics discussions ae taking place, here is my question:
>
> Do you really think a parent should train his/her 12 years old child 
> to *sign* a form when a teacher requests so - e.g. an unspecified 
> paper form that the child thinks is *acceptable* in his mind according 
> to the influence present at the moment?
>
> Please transpose this where the teacher is an IT support person, the 
> child is an end-user, and the form signature is the ubiquitous 
> client-side PKI signature technology that you, the PKI gurus as the 
> parent above, think is good for the next generation of civilized 
> (computer-literate) persons.
>
> Not awaiting a response really, ...
>
> R.i.p (rest in peace) PKI.
>
> Regards,
>

-- 
Scott Rea
Director, HEBCA Operating Authority
Dartmouth College Sr PKI Architect
Peter Kiewit Computing Services
Dartmouth College
HB 6238, #058 Sudikoff
Hanover, NH 03755

Em: [e-mail]
Ph#[phone]
Ot#[phone]
Ce#[phone] 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UKj1Tx044060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 13:45:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9UKj1tS044059; Thu, 30 Oct 2008 13:45:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UKj03E044046 for <[e-mail]>; Thu, 30 Oct 2008 13:45:01 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 2EC973A6B45; Thu, 30 Oct 2008 13:45:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 30 Oct 2008 13:45:01 -0700 (PDT)
Sender: [e-mail]
Precedence: 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           : Trust Anchor Management Requirements
	Author(s)       : R. Reddy, C. Wallace
	Filename        : draft-ietf-pkix-ta-mgmt-reqs-02.txt
	Pages           : 19
	Date            : 2008-10-30

A trust anchor represents an authoritative entity via a public key
and associated data.  The public key is used to verify digital
signatures and the associated data is used to constrain the types of
information for which the trust anchor is authoritative.  A relying
party uses trust anchors to determine if a digitally signed object is
valid by verifying a digital signature using the trust anchor's
public key, and by enforcing the constraints expressed in the
associated data for the trust anchor.  This document describes some
of the problems associated with the lack of a standard trust anchor
management mechanism and defines requirements for data formats and
protocols designed to address these problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-reqs-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-ta-mgmt-reqs-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UIfVCB021237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 11:41:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9UIfVXS021236; Thu, 30 Oct 2008 11:41:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp112.sat.emailsrvr.com (smtp112.sat.emailsrvr.com [66.216.121.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UIfJkX021197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Oct 2008 11:41:30 -0700 (MST) (envelope-from [e-mail])
Received: from relay1.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay1.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 780A6C063A for <[e-mail]>; Thu, 30 Oct 2008 14:41:19 -0400 (EDT)
Received: by relay1.relay.sat.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTP id 9B736C0634 for <[e-mail]>; Thu, 30 Oct 2008 14:41:18 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 31 Oct 2008 05:41:15 +1100
From: Stephen Wilson <[e-mail]>
Reply-To: [e-mail]
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: A random PKI question ... (philosophic)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have no idea what the analogy is trying to say.  But I suspect you're 
barking up the wrong tree.  The idea of telling people to sign things 
like this just doesn't carry over into e-business.

If we could get everyone away from the utopian idea of a general all 
purpose ID certificate used to sign anything and everything -- like the 
ridiculous fountain pen still beloved by CAs in their marketing material 
-- and move on to practical use cases, then so much of this debate would 
evaporate.

Practical experience is that PKI works well in closed communities.  The 
lesson is not that closed communities are an early stage in the 
evolution of PKI to some general purpose end state.  Rather, the lesson 
is that PKI really is best suited to closed communities -- see trade 
documentation, e-prescribing, conveyancing, set top boxes, smartcards 
etc etc etc.  Closed PKI really is the general use case, and not a 
special use case!

Theoretical analysis leads to the conclusion that PKI is best for 
automating routine formal transactions between parties that already know 
each other (or know of each other's authorities) in a defined context. 
It is not much good at all for stranger-to-stranger context free 
e-business (and this is where I agree with Anders that e-mail is not 
much of a "business system").

Cheers,

Steve Wilson

Lockstep
www.lockstep.com.au




Thierry Moreau wrote:
> 
> OK, while off-topics discussions ae taking place, here is my question:
> 
> Do you really think a parent should train his/her 12 years old child to 
> *sign* a form when a teacher requests so - e.g. an unspecified paper 
> form that the child thinks is *acceptable* in his mind according to the 
> influence present at the moment?
> 
> Please transpose this where the teacher is an IT support person, the 
> child is an end-user, and the form signature is the ubiquitous 
> client-side PKI signature technology that you, the PKI gurus as the 
> parent above, think is good for the next generation of civilized 
> (computer-literate) persons.
> 
> Not awaiting a response really, ...
> 
> R.i.p (rest in peace) PKI.
> 
> Regards,
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UHGTRn003172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 10:16:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9UHGTLB003171; Thu, 30 Oct 2008 10:16:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UHGIJ6003129 for <[e-mail]>; Thu, 30 Oct 2008 10:16:29 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA9501BDB271; Thu, 30 Oct 2008 18:16:14 +0100
Message-ID: <64A60A2591CD469ABB9838D9AAEC4011@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Scott Rea" <[e-mail]>, "Timothy J. Miller" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC> <[e-mail]> <866118DC6DE2423789593062E599DBE1@AndersPC> <[e-mail]> <36CF9AC0AD7C46909949FB86935D8DAA@AndersPC> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]
Date: Thu, 30 Oct 2008 18:16:20 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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's statement regarding JVM is indeed correct and actually you
have to *install* the applet (I.e. accepting a signed software)
which doesn't work well in some environments.

I also wonder if Microsoft would be terribly interested in establishing
Java as a web signature standard (although we are almost there...).

Regarding HTML5 and signatures, I recently received a note from
one of the core developers who said they had tabled that item.
IMHO that was the right thing to do, because before progress
can be done, the integration of signatures in information systems
must be specified otherwise it won't deliver.

If somebody wonders what this is about I can give you a hint:
In a browser-session a "signature" today means hitting an OK
button or similar while being shown a static view of something
(purchase, doctor appointment, end-user agreement etc.) which
means that the user-view is just a presentation not the actual transaction.
Actually, the user-view is not even a presentation of a transaction,
but a transaction *request*; the transaction itself is *optionally*
performed *after* receival of the OK.  IMHO, a web-browser
signature scheme should be aligned with this notion although there
surely are people who object to that since this has few if any
simularities with signed e-mail.  OTOH; On-line <<>> off-line.

Anders

----- Original Message ----- 
From: "Scott Rea" <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Thursday, October 30, 2008 14:37
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]


G'day Tim,

I appreciate your perspective - see my responses inline...

Regards,
-Scott

Timothy J. Miller wrote:
> Scott Rea wrote:
>
>> Anders Rundgren wrote:
>
>>> The Java applet etc. solution you refer to is in fact the kind of 
>>> stuff I
>>> (rightly or wrongly), refer to as proprietary.  
>
>> I'm not sure I would call Stephen's solution proprietary - from a 
>> browser perspective (which I believe is what was started out talking 
>> about) java is supported quite healthily across the spectrum. 
>
> I think Anders' point is when you do this you're not really in the 
> browser any more, you're in the JVM.  That puts us in the mobile code 
> arena, which invokes all kinds of paranoia in some environments.
>
> What Anders is asking for is a standard invoke PKI operations via 
> standard markup.  E.g., something like <form 
> enctype="application/pkcs7-mime" cmstype="enveloped-data"> and <form 
> enctype="application/pkcs7-mime" cmstype="signed-data"> would be very, 
> very powerful to have.
OK, I can appreciate that - I have had to deal with my share of client 
paranoia in my time. I am 100% behind your standard mark-up suggestion - 
HTML5??
>
>>                                 One issue is a standard way to access 
>> private keys which are stored in multiple keystores - but I think the 
>> later versions of java available in major browsers do a pretty goos 
>> job of that these days.
>
> This is still a PITA for anything other than software keystores.
>
>> I thought PKCS11 was pretty standard in this space...
>
> Yes, but making even this work isn't trivial for the vast majority of 
> users.  While *I* can load a module into NSS in a heartbeat, my wife 
> wouldn't be able to do so.  In a controlled deployment environment 
> this is less of a problem, but for any uncontrolled environment (e.g., 
> trying to support a community of retired employees) it's a serious 
> problem. And when you start talking cross-platform, oy vey...
So here at Dartmouth we have been working on a library that we hope will 
trivialize this for most folks - libPKI - ref : 
https://www.openca.org/projects/libpki/
>
>> Most that I have talked to who understand the ROI of going paperless 
>> are quite interested in anything that saves them time & money.
>
> Do they understand the hidden costs of archiving records in a 
> paperless environment?  :)
This is not a hidden cost - perhaps sometimes forgotten cost by parties 
involved, but there is also arguments for positive ROI in this aspect 
also. In fact, many projects have been undertaken to address just this 
aspect (convert paper records to electronic for storage purposes only) 
for just that reason of the available benefits of doing so.
>
> -- Tim
>
>

-- 
Scott Rea
Director, HEBCA Operating Authority
Dartmouth College Sr PKI Architect
Peter Kiewit Computing Services
Dartmouth College
HB 6238, #058 Sudikoff
Hanover, NH 03755

Em: [e-mail]
Ph#[phone]
Ot#[phone]
Ce#[phone] 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UFa0Yg080266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 08:36:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9UFa0s0080265; Thu, 30 Oct 2008 08:36:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp109.rog.mail.re2.yahoo.com (smtp109.rog.mail.re2.yahoo.com [68.142.225.207]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9UFZmeU080206 for <[e-mail]>; Thu, 30 Oct 2008 08:35:59 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 22188 invoked from network); 30 Oct 2008 15:35:48 -0000
Received: from unknown (HELO connotech.com) (thierry.moreau@209.148.165.15 with plain) by smtp109.rog.mail.re2.yahoo.com with SMTP; 30 Oct 2008 15:35:48 -0000
X-YMail-OSG: _aBQUWcVM1mOaWHBqu5uqzzeDUhlhND5.Vsr8jUb2iMYg.hPLW9614ot4rIOFmmYNg--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[e-mail]>
Date: Thu, 30 Oct 2008 10:41:25 -0500
From: Thierry Moreau <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.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: A random PKI question ... (philosophic)
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>

OK, while off-topics discussions ae taking place, here is my question:

Do you really think a parent should train his/her 12 years old child to 
*sign* a form when a teacher requests so - e.g. an unspecified paper 
form that the child thinks is *acceptable* in his mind according to the 
influence present at the moment?

Please transpose this where the teacher is an IT support person, the 
child is an end-user, and the form signature is the ubiquitous 
client-side PKI signature technology that you, the PKI gurus as the 
parent above, think is good for the next generation of civilized 
(computer-literate) persons.

Not awaiting a response really, ...

R.i.p (rest in peace) PKI.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: [phone]
Fax:  [phone]

web site: http://www.connotech.com
e-mail: [e-mail]




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UF4aep073405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 08:04:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9UF4aKU073404; Thu, 30 Oct 2008 08:04:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UF4OEr073358 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Thu, 30 Oct 2008 08:04:35 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed
Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <[e-mail]> for [e-mail]; Thu, 30 Oct 2008 10:04:23 -0500 (CDT)
Received: from [192.168.0.14] (static.unknown.charter.com [97.92.189.144]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 30 Oct 2008 10:04:20 -0500 (CDT)
Date: Thu, 30 Oct 2008 10:04:19 -0500
From: Eric Norman <[e-mail]>
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
X-Mailer: Apple Mail (2.624)
X-Spam-Report: AuthenticatedSender=yes, SenderIP=97.92.189.144
X-Spam-PmxInfo: Server=avs-9, Version=5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.10.30.144014, SenderIP=97.92.189.144
References: <p06240500c52b6b1ec3cf@[10.242.22.83]> <p06240506c52c4db21d94@[193.0.24.250]> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC> <[e-mail]> <866118DC6DE2423789593062E599DBE1@AndersPC> <[e-mail]> <36CF9AC0AD7C46909949FB86935D8DAA@AndersPC> <[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>

On Oct 30, 2008, at 8:35 AM, Moudrick M. Dadashov wrote:

>
>> Here is another indication of that there is a some mismatch in
>> the PKI industry:
>> http://www.cabforum.org/client_pki_2008/cfp_v05.htm
>> Note the absence of people representing applications!
>
> I should note that the majority of CABForum members are CA's:
> http://www.cabforum.org/forum.html
>
> do you really believe they don't represent applications? Come on, today
> almost every CA offers a bunch of signing and authentication tools for
> applications.

Correction: they offer tools that use certificates.

They have a hammer; therefore every problem is a nail.

For example, they offer EV certificates as the solution
to the phishing problem (after promising that regular
server certificates are a solution to the phishing problem).

Eric Norman



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UF01NC072238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 08:00:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9UF01CY072237; Thu, 30 Oct 2008 08:00:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UF01j8072226 for <[e-mail]>; Thu, 30 Oct 2008 08:00:01 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 311C43A699D; Thu, 30 Oct 2008 08:00:00 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-05.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 30 Oct 2008 08:00:01 -0700 (PDT)
Sender: [e-mail]
Precedence: 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: Additional Algorithms and Identifiers for DSA and ECDSA
	Author(s)       : Q. Dang
	Filename        : draft-ietf-pkix-sha2-dsa-ecdsa-05.txt
	Pages           : 13
	Date            : 2008-10-30

This document supplements RFC 3279. It specifies algorithm 
identifiers and ASN.1 encoding rules for the Digital 
Signature Algorithm (DSA) and Elliptic Curve Digital 
Signature Algorithm (ECDSA) digital signatures when using 
SHA-224, SHA-256, SHA-384 or SHA-512 as hashing algorithm. 
This specification applies to the Internet X.509 Public Key 
Infrastructure (PKI) when digital signatures are used to 
sign certificates and certificate revocation lists (CRLs).  

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" in this document are to be interpreted as 
described in [RFC 2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-sha2-dsa-ecdsa-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UDcfk3052537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 06:38:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9UDcfan052535; Thu, 30 Oct 2008 06:38:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UDcSpc052462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Oct 2008 06:38:39 -0700 (MST) (envelope-from [e-mail])
Received: from [10.211.55.3] (dhcp-212-205.cs.dartmouth.edu [129.170.212.205]) (authenticated bits=0) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id m9UDbR1u004316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Oct 2008 09:37:28 -0400
Message-ID: <[e-mail]>
Date: Thu, 30 Oct 2008 09:37:25 -0400
From: Scott Rea <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: "Timothy J. Miller" <[e-mail]>
CC: Anders Rundgren <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC> <[e-mail]> <866118DC6DE2423789593062E599DBE1@AndersPC> <[e-mail]> <36CF9AC0AD7C46909949FB86935D8DAA@AndersPC> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
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>

G'day Tim,

I appreciate your perspective - see my responses inline...

Regards,
-Scott

Timothy J. Miller wrote:
> Scott Rea wrote:
>
>> Anders Rundgren wrote:
>
>>> The Java applet etc. solution you refer to is in fact the kind of 
>>> stuff I
>>> (rightly or wrongly), refer to as proprietary.  
>
>> I'm not sure I would call Stephen's solution proprietary - from a 
>> browser perspective (which I believe is what was started out talking 
>> about) java is supported quite healthily across the spectrum. 
>
> I think Anders' point is when you do this you're not really in the 
> browser any more, you're in the JVM.  That puts us in the mobile code 
> arena, which invokes all kinds of paranoia in some environments.
>
> What Anders is asking for is a standard invoke PKI operations via 
> standard markup.  E.g., something like <form 
> enctype="application/pkcs7-mime" cmstype="enveloped-data"> and <form 
> enctype="application/pkcs7-mime" cmstype="signed-data"> would be very, 
> very powerful to have.
OK, I can appreciate that - I have had to deal with my share of client 
paranoia in my time. I am 100% behind your standard mark-up suggestion - 
HTML5??
>
>>                                 One issue is a standard way to access 
>> private keys which are stored in multiple keystores - but I think the 
>> later versions of java available in major browsers do a pretty goos 
>> job of that these days.
>
> This is still a PITA for anything other than software keystores.
>
>> I thought PKCS11 was pretty standard in this space...
>
> Yes, but making even this work isn't trivial for the vast majority of 
> users.  While *I* can load a module into NSS in a heartbeat, my wife 
> wouldn't be able to do so.  In a controlled deployment environment 
> this is less of a problem, but for any uncontrolled environment (e.g., 
> trying to support a community of retired employees) it's a serious 
> problem. And when you start talking cross-platform, oy vey...
So here at Dartmouth we have been working on a library that we hope will 
trivialize this for most folks - libPKI - ref : 
https://www.openca.org/projects/libpki/
>
>> Most that I have talked to who understand the ROI of going paperless 
>> are quite interested in anything that saves them time & money.
>
> Do they understand the hidden costs of archiving records in a 
> paperless environment?  :)
This is not a hidden cost - perhaps sometimes forgotten cost by parties 
involved, but there is also arguments for positive ROI in this aspect 
also. In fact, many projects have been undertaken to address just this 
aspect (convert paper records to electronic for storage purposes only) 
for just that reason of the available benefits of doing so.
>
> -- Tim
>
>

-- 
Scott Rea
Director, HEBCA Operating Authority
Dartmouth College Sr PKI Architect
Peter Kiewit Computing Services
Dartmouth College
HB 6238, #058 Sudikoff
Hanover, NH 03755

Em: [e-mail]
Ph#[phone]
Ot#[phone]
Ce#[phone] 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UDZf3U051631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 06:35:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9UDZfvV051630; Thu, 30 Oct 2008 06:35:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ssc.lt (mail.ssc.lt [195.43.64.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UDZTvH051577 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Oct 2008 06:35:40 -0700 (MST) (envelope-from [e-mail])
Received: from localhost ([127.0.0.1] helo=mail.ssc.lt) by mail.ssc.lt with esmtp (Exim 4.50) id 1KvXgI-0002Y4-N0; Thu, 30 Oct 2008 15:35:22 +0200
Received: from 84.240.23.130 (SquirrelMail authenticated user [e-mail]) by mail.ssc.lt with HTTP; Thu, 30 Oct 2008 15:35:22 +0200 (EET)
Message-ID: <[e-mail]>
In-Reply-To: <36CF9AC0AD7C46909949FB86935D8DAA@AndersPC>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC> <[e-mail]> <866118DC6DE2423789593062E599DBE1@AndersPC> <[e-mail]> <36CF9AC0AD7C46909949FB86935D8DAA@AndersPC>
Date: Thu, 30 Oct 2008 15:35:22 +0200 (EET)
Subject: Re: Random PKI critiques [was: Rationales for CA clearance  constraints]
From: "Moudrick M. Dadashov" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail], "Scott Rea" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
User-Agent: SquirrelMail/1.4.6
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
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>

> Here is another indication of that there is a some mismatch in
> the PKI industry:
> http://www.cabforum.org/client_pki_2008/cfp_v05.htm
> Note the absence of people representing applications!

I should note that the majority of CABForum members are CA's:
http://www.cabforum.org/forum.html

do you really believe they don't represent applications? Come on, today
almost every CA offers a bunch of signing and authentication tools for
applications.

M.D.
cell: [phone]

On Thu, October 30, 2008 10:56, Anders Rundgren wrote:
>
> Stephen,
>
> Note: this is not a critique of PKI.  PKI is indeed ready in the
> kind of apps you described in your previous posting but I'm
> exclusively referring to general-purpose identity PKIs that
> obviously need equally general-purpose software solutions.
>
> The Java applet etc. solution you refer to is in fact the kind of stuff I
> (rightly or wrongly), refer to as proprietary.  What I'm requesting is
> a built-in facility that would be the browser's counterpart to the S/MIME
> support available in just about of every e-mail client.
>
> There is absolutely nothing wrong with the described scheme but
> it is unlikely to be compatible with its numerous cousins, making
> interoperability and the ability to develop "standard solutions"
> an issue.  Password-using solutions however, do not suffer from
> such problems, they work right-out-of-the-box.  Quite logically,
> the bulk of the market takes the shortest route, leaving schemes
> like the one you describe to advanced users who still often find
> themselves locked in an eternal "piloting" stage.
>
> Another issue with these solutions is the ability to roll them out to
> consumers since the variation in consumer platforms make the
> deployment of additional software difficult particularly when it
> has to connect to hardware.  Due to the lack of standards
> in this space, service providers become software distributors as well.
> This is a reality in EU where general-purpose identity PKIs is very
> much a consumer/citizen thing.
>
> I also suspect that few enterprise or government agency IS-managers
> are particularly interested in distributing one-of-a-kind signature
> solutions
> either, even if they actually have managed bringing out smart cards for
> login.
> Some of these solutions cost some $50 per seat which is quite unattractive
> except for small-scale usage and then you are back to the "interesting",
> "promising", "forward-looking" state.
>

>
> Regards
> Anders Rundgren
>
> ----- Original Message -----
> From: "Stephen Wilson" <[e-mail]>
> To: "Anders Rundgren" <[e-mail]>
> Cc: "Scott Rea" <[e-mail]>; <[e-mail]>
> Sent: Wednesday, October 29, 2008 21:45
> Subject: Re: Random PKI critiques [was: Rationales for CA clearance
> constraints]
>
>
>
>
> Anders Rundgren wrote:
>
>> But, it is a fact that there is no such thing as digital signatures in
>> browser
>> sessions except through entirely proprietary solutions.  There are
>> hundreds
>> of such and they are all different and usually require NDAs if you want
>> to
>> look a bit closer.
>
> Sorry, but this 'fact' is just not true!
>
> Lockstep has recently demonstrated a whole suite of privacy enhancing
> solutions for web based transactions (anonymous health record lodgement,
> secure credit Card-Not-Present payments, anonymous e-voting) where
> digital signatures are created at the browser.  We do send a Java applet
> from the server, to generate the signature when the user clicks 'ok'
> (but you wouldn't call that 'proprietary' would you? ).
>
> The building blocks are simply a FIPS-201 type smartcard (with exposed
> PKI interfaces), CAPICOM, XMLsignatures, Javascript and, in this case,
> .NET.
>
> We even found it easy to implement pretty rich business logic.  For
> example, our smartcards contain several keys and certificates; e.g. one
> for voting, one for a credit card number, one for the health ID.  The
> server sends the client the name of the CA that the server is interested
> in for the transaction at hand (e.g. if it's a vote, the only sensible
> certificate is one issued by the electoral commission).  In this way we
> seamlessly manage multiple certificates, in ways that cynics still seem
> to think will be inevitably complex.  In more complex situations, we
> could readily use Policy OIDs, or stems of OIDs, to embody the business
> logic.
>
> Cheers,
>
> Steve Wilson
> www.lockstep.com.au/technologies.
>
>
>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UD8BmN043745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 06:08:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9UD8BX5043744; Thu, 30 Oct 2008 06:08:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UD80Y9043682 for <[e-mail]>; Thu, 30 Oct 2008 06:08:10 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9UD7xdK028385 for <[e-mail]>; Thu, 30 Oct 2008 09:07:59 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9UD7xRH028381; Thu, 30 Oct 2008 09:07:59 -0400
Received: from [129.83.200.4] (129.83.200.4) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 30 Oct 2008 09:07:58 -0400
Message-ID: <[e-mail]>
Date: Thu, 30 Oct 2008 08:07:55 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Scott Rea <[e-mail]>
CC: Anders Rundgren <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC> <[e-mail]> <866118DC6DE2423789593062E599DBE1@AndersPC> <[e-mail]> <36CF9AC0AD7C46909949FB86935D8DAA@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060003050302060909050201"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms060003050302060909050201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Scott Rea wrote:

> Anders Rundgren wrote:

>> The Java applet etc. solution you refer to is in fact the kind of stuff I
>> (rightly or wrongly), refer to as proprietary.  

> I'm not sure I would call Stephen's solution proprietary - from a 
> browser perspective (which I believe is what was started out talking 
> about) java is supported quite healthily across the spectrum. 

I think Anders' point is when you do this you're not really in the 
browser any more, you're in the JVM.  That puts us in the mobile code 
arena, which invokes all kinds of paranoia in some environments.

What Anders is asking for is a standard invoke PKI operations via 
standard markup.  E.g., something like <form 
enctype="application/pkcs7-mime" cmstype="enveloped-data"> and <form 
enctype="application/pkcs7-mime" cmstype="signed-data"> would be very, 
very powerful to have.

>								One issue 
> is a standard way to access private keys which are stored in multiple 
> keystores - but I think the later versions of java available in major 
> browsers do a pretty goos job of that these days.

This is still a PITA for anything other than software keystores.

> I thought PKCS11 was pretty standard in this space...

Yes, but making even this work isn't trivial for the vast majority of 
users.  While *I* can load a module into NSS in a heartbeat, my wife 
wouldn't be able to do so.  In a controlled deployment environment this 
is less of a problem, but for any uncontrolled environment (e.g., trying 
to support a community of retired employees) it's a serious problem. 
And when you start talking cross-platform, oy vey...

> Most that I have talked to who understand the ROI of going paperless are 
> quite interested in anything that saves them time & money.

Do they understand the hidden costs of archiving records in a paperless 
environment?  :)

-- Tim



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMzAxMzA3NTVaMCMGCSqGSIb3DQEJBDEWBBSyy5VsQMy4KZnUgXuoPygF0zaRXTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgGllAJ1rDJXdJXQMak0rfG0X2a7vxIWadpZRIA0bQcfbon4+2gP0B0l0jwmy
sIGaqhHSxBANjjmwOVCcAGyks1zlNQAa1+O1nZV0gTQ5TOr8nuWPkwdBtYAoYaOTcOCumSUp
gDUGajwMrbBph1vWXiJlbwXeN6rbfi7MvZW25qY7AAAAAAAA
--------------ms060003050302060909050201--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UAFHIS007236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 03:15:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9UAFHjb007233; Thu, 30 Oct 2008 03:15:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhub1.dartmouth.edu (mailhub1.dartmouth.edu [129.170.16.122]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UAF5kK007172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Oct 2008 03:15:16 -0700 (MST) (envelope-from [e-mail])
Received: from newdasher.Dartmouth.EDU (newdasher.dartmouth.edu [129.170.208.30]) by mailhub1.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id m9U7N2He000423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 06:14:48 -0400
X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system.
Received: from c-75-69-92-17.hsd1.nh.comcast.net [75.69.92.17] by newdasher.Dartmouth.EDU (Mac) via SMTP  for  id <135416957>; 30 Oct 2008 06:14:45 -0400
Message-ID: <[e-mail]>
Date: Thu, 30 Oct 2008 06:14:38 -0400
From: Scott Rea <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC> <[e-mail]> <866118DC6DE2423789593062E599DBE1@AndersPC> <[e-mail]> <36CF9AC0AD7C46909949FB86935D8DAA@AndersPC>
In-Reply-To: <36CF9AC0AD7C46909949FB86935D8DAA@AndersPC>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
X-MailScanner-SpamCheck: spam, SpamAssassin on mailhub1 (score=5.528, required 1, BAYES_40 -0.18, DNS_FROM_SECURITYSAGE 1.51, HELO_DYNAMIC_IPADDR 4.20)
X-MailScanner-SpamScore: sssss
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>

Anders,
I am not sure of some of the points you are making - see my comments 
inline...
-Scott

Anders Rundgren wrote:
> Stephen,
>
> Note: this is not a critique of PKI.  PKI is indeed ready in the
> kind of apps you described in your previous posting but I'm
> exclusively referring to general-purpose identity PKIs that
> obviously need equally general-purpose software solutions.
>
> The Java applet etc. solution you refer to is in fact the kind of stuff I
> (rightly or wrongly), refer to as proprietary.  
I'm not sure I would call Stephen's solution proprietary - from a 
browser perspective (which I believe is what was started out talking 
about) java is supported quite healthily across the spectrum. One issue 
is a standard way to access private keys which are stored in multiple 
keystores - but I think the later versions of java available in major 
browsers do a pretty goos job of that these days.
> What I'm requesting is
> a built-in facility that would be the browser's counterpart to the S/MIME
> support available in just about of every e-mail client.
>
> There is absolutely nothing wrong with the described scheme but
> it is unlikely to be compatible with its numerous cousins, making
> interoperability and the ability to develop "standard solutions"
> an issue.  
If the output is a CMS or XML D-Sig object, then I do not see any reason 
why it would not be "compatible with it's numerous cousins"
> Password-using solutions however, do not suffer from
> such problems, they work right-out-of-the-box.  
Anyone can generate cryptographic keys for a signing event - what makes 
a signature using an identity PKI credential superior is the binding of 
the identity in the credential itself - its the "I" in PKI that provides 
that benefit. Passwords when combined with PK may "work 
right-out-of-the-box", but they will never provide the assurance that a 
properly defined PKI credential can.

> Quite logically,
> the bulk of the market takes the shortest route, leaving schemes
> like the one you describe to advanced users who still often find
> themselves locked in an eternal "piloting" stage.
>
> Another issue with these solutions is the ability to roll them out to
> consumers since the variation in consumer platforms make the
> deployment of additional software difficult particularly when it
> has to connect to hardware.  Due to the lack of standards
> in this space, 
I thought PKCS11 was pretty standard in this space...
> service providers become software distributors as well.
> This is a reality in EU where general-purpose identity PKIs is very
> much a consumer/citizen thing.
>
> I also suspect that few enterprise or government agency IS-managers
> are particularly interested in distributing one-of-a-kind signature solutions
> either, even if they actually have managed bringing out smart cards for login.
>   
Most that I have talked to who understand the ROI of going paperless are 
quite interested in anything that saves them time & money.
> Some of these solutions cost some $50 per seat which is quite unattractive
> except for small-scale usage and then you are back to the "interesting",
> "promising", "forward-looking" state.
>
> Here is another indication of that there is a some mismatch in
> the PKI industry:
> http://www.cabforum.org/client_pki_2008/cfp_v05.htm
> Note the absence of people representing applications!
>   
The CAB Forum by definition is a quorum of Certificate Authorities & 
Browser vendors  - the link you refer to is an invitation to application 
vendors and researchers to help set directions for future development - 
I would say this is EXACTLY what we need - where is the mismatch here?
> Regards
> Anders Rundgren
>
> ----- Original Message ----- 
> From: "Stephen Wilson" <[e-mail]>
> To: "Anders Rundgren" <[e-mail]>
> Cc: "Scott Rea" <[e-mail]>; <[e-mail]>
> Sent: Wednesday, October 29, 2008 21:45
> Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]
>
>
>
>
> Anders Rundgren wrote:
>
>   
>> But, it is a fact that there is no such thing as digital signatures in browser
>> sessions except through entirely proprietary solutions.  There are hundreds
>> of such and they are all different and usually require NDAs if you want to
>> look a bit closer.
>>     
>
> Sorry, but this 'fact' is just not true!
>
> Lockstep has recently demonstrated a whole suite of privacy enhancing 
> solutions for web based transactions (anonymous health record lodgement, 
> secure credit Card-Not-Present payments, anonymous e-voting) where 
> digital signatures are created at the browser.  We do send a Java applet 
> from the server, to generate the signature when the user clicks 'ok' 
> (but you wouldn't call that 'proprietary' would you? ).
>
> The building blocks are simply a FIPS-201 type smartcard (with exposed 
> PKI interfaces), CAPICOM, XMLsignatures, Javascript and, in this case, 
> .NET.
>
> We even found it easy to implement pretty rich business logic.  For 
> example, our smartcards contain several keys and certificates; e.g. one 
> for voting, one for a credit card number, one for the health ID.  The 
> server sends the client the name of the CA that the server is interested 
> in for the transaction at hand (e.g. if it's a vote, the only sensible 
> certificate is one issued by the electoral commission).  In this way we 
> seamlessly manage multiple certificates, in ways that cynics still seem 
> to think will be inevitably complex.  In more complex situations, we 
> could readily use Policy OIDs, or stems of OIDs, to embody the business 
> logic.
>
> Cheers,
>
> Steve Wilson
> www.lockstep.com.au/technologies.
>
>
>   

-- 
Scott Rea
Director, HEBCA|USHER Operating Authority
Dartmouth Senior PKI Architect
Peter Kiewit Computing Services
Dartmouth College
HB 6238, #058 Sudikoff
Hanover, NH 03755

Em: [e-mail]
Ph#[phone]
Ot#[phone]
Ce#[phone]



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U9YD5V097982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 02:34:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9U9YDQL097978; Thu, 30 Oct 2008 02:34:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U9YCtR097971 for <[e-mail]>; Thu, 30 Oct 2008 02:34:13 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C50151614F; Thu, 30 Oct 2008 10:34:05 +0100
Message-ID: <12776F76578C4462A0E60227A00CC6F6@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: "Scott Rea" <[e-mail]>, <[e-mail]>
References:    <[e-mail]    osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]>    <[e-mail]    osoft.com> <p06240506c52c4db21d94@[193.0.24.250]>    <[e-mail]    osoft.com> <p06240824c52cd4852e85@[10.20.30.152]>    <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]>    <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]>    <15519BF0552B4C7CB58F992A9318E67B@AndersPC>    <[e-mail]>    <866118DC6DE2423789593062E599DBE1@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: (Other) dubious uses of PKI technology [was: Rationales for CA clearance constraints]
Date: Thu, 30 Oct 2008 10:34:10 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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 Moudrick,

> http://ec.europa.eu/idabc/en/document/6484/5644

There is a problem with EU PKI efforts and it is called Germany.
In Germany invoices must be signed by qualified signatures which
are personal signatures.   To make this practical, security companies
provide devices that can host dozens of smart cards, all issued for
an "authorized person" who with a single PIN-code can sign
multiple invoices.   This is of course very inefficient and expensive,
and has nothing to do with IT which is about improving processes.

The German PKI schemes and MIT's ECAT  ( http://web.mit.edu/ecat )
top my list of incorrect application of PKI technology. 

In ECAT a client cert is used for merchant login while a server-cert
is used for securing the purchase order to the very same merchant.
What's the logic in that?   In addition, I once demonstrated how
I could hack the merchant login with notepad and some HTML
in spite of using PKI.  It was not due to a bad implementation,
but to a flaw in the architecture itself.   The consortia that once
raised this scheme (OBI) ceased to exist some seven years ago,
including their web-site.

Anders

----- Original Message ----- 
From: "Moudrick M. Dadashov" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "Scott Rea" <[e-mail]>; <[e-mail]>
Sent: Wednesday, October 29, 2008 20:38
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]


Hi Anders,

This is the publication you might want to look at:

http://ec.europa.eu/idabc/en/document/6484/5644

M.D.
cell: [phone]

On Wed, October 29, 2008 18:58, Anders Rundgren wrote:
>
> <snip>
>>- PIV/CAC
>>Again, the benefit with these credentials is only when there is a broad
>>population base that carries them - the US fed govt is still rolling out
>>this program to its employees. Once critical mass is achieved, I think
>>the benefits of others having these credentials will begin to be
>> realized.
>
> Scott,
> As you probably agree with the Internet-browser has become the primary
> way to interact with just about all kinds of "information systems".
>
> As you probably also agree with, digital signatures is one of the core
> PKI (and thus PIV/CAC) mechanisms.
>
> But, it is a fact that there is no such thing as digital signatures in
> browser
> sessions except through entirely proprietary solutions.  There are
> hundreds
> of such and they are all different and usually require NDAs if you want to
> look a bit closer.
>
> In addition, and this is the really serious part, no authority, government
> body,
> or even academic institution have published anything on how client-side
> PKI should actually work with common information system processes.
>
> It does not IMHO make much difference if we wait another decade or so
> because nothing will actually happen until this very basic job is done.
>
> Anders
>
>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U9LdBS095739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 02:21:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9U9LdSK095738; Thu, 30 Oct 2008 02:21:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin.bull.net (odin.bull.net [129.184.85.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U9LRY0095699 for <[e-mail]>; Thu, 30 Oct 2008 02:21:38 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin.bull.net (8.9.3/8.9.3) with ESMTP id KAA29846 for <[e-mail]>; Thu, 30 Oct 2008 10:23:20 +0100
Received: from FRMYA-SIA24 ([129.182.109.126]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008103010205351:277075 ; Thu, 30 Oct 2008 10:20:53 +0100 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Date: Thu, 30 Oct 2008 10:20:57 +0100
Message-Id: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 30/10/2008 10:20:53, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 30/10/2008 10:21:26, Serialize complete at 30/10/2008 10:21:26
Content-Type: multipart/alternative;  boundary="----=_NextPart_08103010205689562270153_002"
Sender: [e-mail]
Precedence: 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_08103010205689562270153_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

There are so many messages on that topic, that it is difficult to follow all of them.
Nevertheless, I have a comment on this one.

The question is whether the ACC extension MUST be marked critical or not.

Suppose a case where the CA issues some PKCs with clearances and some other PKCs without clearances.

Why should a relying party be forced to understand the ACC extension, if the PKC or the CA contains no clearance ?

The starting point when doing path processing is to look at the PKC or the AC.

I would see the following logic:

- If the PKC or the AC contains no clearance, then ignore all ACC extensions and 
  do NOT compute any clearance constraints when building the certification path.

- If the PKC or the AC contains at least one clearance, then consider all the ACC extensions and
  compute clearance constraints when building the certification path.

As a conclusion:
 
- the ACC extension MAY be marked critical if all issued PKCs or ACs contain at least one clearance.
- the ACC extension SHOULD be marked non critical if some PKCs or ACs contain no clearance at all.

Denis

----- Message reçu ----- 
De : owner-ietf-pkix 
À : Stephen Kent 
Date : 2008-10-29, 18:51:54
Sujet : Re: Rationales for CA clearance constraints


Pièce(s) Jointe(s) au message original :
  (1). smime.p7s


Stephen Kent wrote:

> You are right, i.e., a non-critical extension that is not understood by 
> an RP can safely be ignored. I didn't mean to suggest otherwise.

There's two levels of "understand" here: (1) recognizing the clearance 
constraint extension; and (2) recognizing the semantics of the 
particular clearance policyIds. For arbitrary policyIds, one could have 
(1) but not (2).

I agree with Yoav's suggestion; the ACC extension MUST be marked 
critical. Then there's no question what to do if the RP doesn't know 
what to do with the policyId.

I still think 5280 should say something about non-critical extensions 
that contain information that can't be processed--even if this is only 
to note that each extension must define what to do in that case.

-- Tim

------=_NextPart_08103010205689562270153_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV>There are so many messages on that topic, that it is difficult to 
follow&nbsp;all of them.</DIV>
<DIV>Nevertheless, I have a comment on this one.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The question is whether the ACC extension MUST be marked critical or 
not.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Suppose a case where the CA issues some PKCs with&nbsp;clearances and some 
other PKCs&nbsp;without clearances.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Why should a relying party be forced to understand the ACC extension, if 
the PKC or the CA contains no clearance ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>The starting point when doing path processing is to look at the PKC or the 
AC.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I would see the following logic:</DIV>
<DIV>&nbsp;</DIV>
<DIV>- If the PKC or the AC contains no clearance, then ignore all ACC 
extensions and </DIV>
<DIV>&nbsp;&nbsp;do NOT&nbsp;compute any clearance constraints when building the 
certification path.</DIV>
<DIV>
<DIV>&nbsp;</DIV>
<DIV>- If the PKC or the AC contains&nbsp;at least one clearance, then consider 
all the&nbsp;ACC extensions and</DIV>
<DIV>&nbsp;&nbsp;compute&nbsp;clearance constraints when building the 
certification path.</DIV>
<DIV>&nbsp;</DIV>
<DIV>As a conclusion:</DIV>
<DIV>&nbsp;</DIV>
<DIV>- the&nbsp;ACC extension MAY&nbsp;be marked critical if all 
issued&nbsp;PKCs or&nbsp;ACs contain&nbsp;at least one&nbsp;clearance.</DIV>
<DIV>
<DIV>- the&nbsp;ACC extension SHOULD&nbsp;be marked non critical if 
some&nbsp;PKCs or&nbsp;ACs contain&nbsp;no&nbsp;clearance at all.</DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV>
<DIV>&nbsp;</DIV>
<DIV>----- Message reçu ----- </DIV></DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[e-mail]">owner-ietf-pkix</A> 
</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[e-mail]">Stephen Kent</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-10-29, 18:51:54</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> Re: Rationales for CA clearance constraints</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV>
  <DIV><U><STRONG>Pièce(s) Jointe(s) au message original :</STRONG></U></DIV>
  <DIV>&nbsp;&nbsp;(1).&nbsp;smime.p7s</DIV><BR></DIV>
  <DIV>
  <DIV>Stephen Kent wrote:<BR><BR>&gt; You are right, i.e., a non-critical 
  extension that is not understood by <BR>&gt; an RP can safely be ignored. I 
  didn't mean to suggest otherwise.<BR><BR>There's two levels of "understand" 
  here: (1) recognizing the clearance <BR>constraint extension; and (2) 
  recognizing the semantics of the <BR>particular clearance policyIds. For 
  arbitrary policyIds, one could have <BR>(1) but not (2).<BR><BR>I agree with 
  Yoav's suggestion; the ACC extension MUST be marked <BR>critical. Then there's 
  no question what to do if the RP doesn't know <BR>what to do with the 
  policyId.<BR><BR>I still think 5280 should say something about non-critical 
  extensions <BR>that contain information that can't be processed--even if this 
  is only <BR>to note that each extension must define what to do in that 
  case.<BR><BR>-- Tim<BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08103010205689562270153_002--






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U8uSa8089592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 01:56:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9U8uSo2089591; Thu, 30 Oct 2008 01:56:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U8uHj4089476 for <[e-mail]>; Thu, 30 Oct 2008 01:56:28 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C501512F43; Thu, 30 Oct 2008 09:56:13 +0100
Message-ID: <36CF9AC0AD7C46909949FB86935D8DAA@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: "Scott Rea" <[e-mail]>, <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC> <[e-mail]> <866118DC6DE2423789593062E599DBE1@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]
Date: Thu, 30 Oct 2008 09:56:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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,

Note: this is not a critique of PKI.  PKI is indeed ready in the
kind of apps you described in your previous posting but I'm
exclusively referring to general-purpose identity PKIs that
obviously need equally general-purpose software solutions.

The Java applet etc. solution you refer to is in fact the kind of stuff I
(rightly or wrongly), refer to as proprietary.  What I'm requesting is
a built-in facility that would be the browser's counterpart to the S/MIME
support available in just about of every e-mail client.

There is absolutely nothing wrong with the described scheme but
it is unlikely to be compatible with its numerous cousins, making
interoperability and the ability to develop "standard solutions"
an issue.  Password-using solutions however, do not suffer from
such problems, they work right-out-of-the-box.  Quite logically,
the bulk of the market takes the shortest route, leaving schemes
like the one you describe to advanced users who still often find
themselves locked in an eternal "piloting" stage.

Another issue with these solutions is the ability to roll them out to
consumers since the variation in consumer platforms make the
deployment of additional software difficult particularly when it
has to connect to hardware.  Due to the lack of standards
in this space, service providers become software distributors as well.
This is a reality in EU where general-purpose identity PKIs is very
much a consumer/citizen thing.

I also suspect that few enterprise or government agency IS-managers
are particularly interested in distributing one-of-a-kind signature solutions
either, even if they actually have managed bringing out smart cards for login.
Some of these solutions cost some $50 per seat which is quite unattractive
except for small-scale usage and then you are back to the "interesting",
"promising", "forward-looking" state.

Here is another indication of that there is a some mismatch in
the PKI industry:
http://www.cabforum.org/client_pki_2008/cfp_v05.htm
Note the absence of people representing applications!

Regards
Anders Rundgren

----- Original Message ----- 
From: "Stephen Wilson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "Scott Rea" <[e-mail]>; <[e-mail]>
Sent: Wednesday, October 29, 2008 21:45
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]




Anders Rundgren wrote:

> But, it is a fact that there is no such thing as digital signatures in browser
> sessions except through entirely proprietary solutions.  There are hundreds
> of such and they are all different and usually require NDAs if you want to
> look a bit closer.

Sorry, but this 'fact' is just not true!

Lockstep has recently demonstrated a whole suite of privacy enhancing 
solutions for web based transactions (anonymous health record lodgement, 
secure credit Card-Not-Present payments, anonymous e-voting) where 
digital signatures are created at the browser.  We do send a Java applet 
from the server, to generate the signature when the user clicks 'ok' 
(but you wouldn't call that 'proprietary' would you? ).

The building blocks are simply a FIPS-201 type smartcard (with exposed 
PKI interfaces), CAPICOM, XMLsignatures, Javascript and, in this case, 
.NET.

We even found it easy to implement pretty rich business logic.  For 
example, our smartcards contain several keys and certificates; e.g. one 
for voting, one for a credit card number, one for the health ID.  The 
server sends the client the name of the CA that the server is interested 
in for the transaction at hand (e.g. if it's a vote, the only sensible 
certificate is one issued by the electoral commission).  In this way we 
seamlessly manage multiple certificates, in ways that cynics still seem 
to think will be inevitably complex.  In more complex situations, we 
could readily use Policy OIDs, or stems of OIDs, to embody the business 
logic.

Cheers,

Steve Wilson
www.lockstep.com.au/technologies.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U5JS1M048920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 22:19:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9U5JSDw048919; Wed, 29 Oct 2008 22:19:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U5JQlR048912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 29 Oct 2008 22:19:27 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.24.250]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1KvPwJ-0006Jl-C9; Thu, 30 Oct 2008 01:19:24 -0400
Mime-Version: 1.0
Message-Id: <p06240502c52eed0c13ce@[193.0.24.250]>
In-Reply-To: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]> <p06240500c52e2f16c45f@[193.0.24.250]> <[e-mail]>
Date: Thu, 30 Oct 2008 01:20:28 -0400
To: "Timothy J. Miller" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Cc: Yoav Nir <[e-mail]>, Paul Hoffman <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:51 PM -0500 10/29/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>You are right, i.e., a non-critical extension that is not 
>>understood by an RP can safely be ignored.  I didn't mean to 
>>suggest otherwise.
>
>There's two levels of "understand" here: (1) recognizing the 
>clearance constraint extension; and (2) recognizing the semantics of 
>the particular clearance policyIds.  For arbitrary policyIds, one 
>could have (1) but not (2).

yes, but 1 without 2 isn't very useful for an RP.  Let's see what 
Santosh provides as a default processing algorithm, before we decide 
whether there is a safe way for an RP to accept these extensions even 
when they do not have a detailed understanding of the levels and 
categories.

>I agree with Yoav's suggestion; the ACC extension MUST be marked 
>critical.  Then there's no question what to do if the RP doesn't 
>know what to do with the policyId.

I thought this too, at first, but I am not so sure now. Imagine a web 
server that requires a user cert for access (e.g., for auditing 
purposes). The web site may be on a net that operates at exactly one 
security level, so anyone who can access the web server at layer 3 is 
authorized to do so, as far as clearance processing is concerned. The 
server can safely ignore these extensions, given lower layer security 
mechanisms. If we mark the extension a MUST, then COTS server 
software will reject the user access, until it is updated to process 
the extension. So, I am not longer convinced that this extension must 
be critical.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U4jOL8042175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 21:45:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9U4jNBX042174; Wed, 29 Oct 2008 21:45:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U4jBMa042113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 29 Oct 2008 21:45:23 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.24.250]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1KvPPB-0005tH-AX; Thu, 30 Oct 2008 00:45:09 -0400
Mime-Version: 1.0
Message-Id: <p06240501c52eec82f377@[172.16.1.23]>
In-Reply-To: <[e-mail]>
References: <p0624050cc52dffec79c0@[193.0.24.250]> <[e-mail]>
Date: Thu, 30 Oct 2008 00:46:13 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Rationales for CA clearance constraints
Cc: "Stefan Santesson" <[e-mail]>, <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-986780518==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-986780518==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 9:03 AM -0400 10/29/08, Santosh Chokhani wrote:
>Steve,
>
>At a minimum, binary comparison of constraints in the intermediate 
>certificates and the clearance in the end certificates is possible 
>even if the syntax and semantics of value for the various security 
>categories TYPE are unknown.  Given all these are SET, the binary 
>comparison can be efficiently implemented.
>
>That could be the minimum processing for all TYPE OID.  If the RP 
>knows the syntax and semantics of values for a given TYPE, it can do 
>finer processing.
>
>In the default processing, lack of match for a category will result 
>in its deprecation and not the rejection of certificate.  This is 
>safe and secure.
>
>If you like, we can enhance the I-D along these lines and let the 
>group review it.
>

yes, please do.

Thanks,

Steve
--============_-986780518==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>RE: Rationales for CA clearance
constraints</title></head><body>
<div>At 9:03 AM -0400 10/29/08, Santosh Chokhani wrote:</div>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">Steve,</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">At a minimum, binary comparison of constraints in the
intermediate certificates and the clearance in the end certificates is
possible even if the syntax and semantics of value for the various
security categories TYPE are unknown. &nbsp;Given all these are SET,
the binary comparison can be efficiently
implemented.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">That could be the minimum processing for all TYPE OID.
&nbsp;If the RP knows the syntax and semantics of values for a given
TYPE, it can do finer processing.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">In the default processing, lack of match for a
category will result in its deprecation and not the rejection of
certificate.&nbsp; This is safe and secure.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000080">If you like, we can enhance the I-D along these lines
and let the group review it.</font></blockquote>
<blockquote type="cite" cite>
<hr size="2"></blockquote>
<div><font face="Tahoma" size="-1"><b><br></b></font></div>
<div><font face="Tahoma" size="-1"><b>yes, please do.</b></font></div>
<div><font face="Tahoma" size="-1"><b><br></b></font></div>
<div><font face="Tahoma" size="-1"><b>Thanks,</b></font></div>
<div><font face="Tahoma" size="-1"><b><br></b></font></div>
<div><font face="Tahoma" size="-1"><b>Steve</b></font></div>
</body>
</html>
--============_-986780518==_ma============--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U0Zb1m097345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 17:35:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9U0ZbWZ097344; Wed, 29 Oct 2008 17:35:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9U0ZPK8097309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 29 Oct 2008 17:35:36 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9U0ZMuU005936 for <[e-mail]>; Wed, 29 Oct 2008 20:35:22 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9U0ZKDo077398 for <[e-mail]>; Wed, 29 Oct 2008 20:35:22 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9U0ZDgu014622 for <[e-mail]>; Wed, 29 Oct 2008 20:35:13 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9U0ZDi8014618; Wed, 29 Oct 2008 20:35:13 -0400
In-Reply-To: <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: RE: draft-turner-caclearanceconstraints-01.txt
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 29 Oct 2008 20:35:18 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1|February 07, 2008) at 10/29/2008 20:35:19, Serialize complete at 10/29/2008 20:35:19
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Santosh:

        Since criterion D is explicitly dependent on 
SecurityCategory.Type, only a few examples will fit into the final version 
of this draft.  I don't think you need an exhaustive catalogue of its 
possibilities to go forward.  BIT STRING probably deserves an explicit 
rule of its own, namely the logical AND of the the two values, considering 
the shorter one as padded with zeroes.  Enumerated integers, and string 
values which are intended as effectively enumerated sets, cannot be 
subjected IMHO to rules which are both elaborate and standardized. 
Character strings considered as opaque values, or object ID's considered 
as such, are processed by the default of binary equality.

                Tom Gindin





"Santosh Chokhani" <[e-mail]> 
Sent by: [e-mail]
10/29/2008 08:54 AM

To
<[e-mail]>
cc

Subject
RE: draft-turner-caclearanceconstraints-01.txt







Tom,

Thanks.

A, B, and C is what I have planned for.

D is the area, I need to decide what types of values to support.  Some
of the times, values may be bit string or enumerated integers and hence
binary comparison may not be valid.

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]] 
Sent: Tuesday, October 28, 2008 8:15 PM
To: Stefan Santesson
Cc: [e-mail]; Santosh Chokhani
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        Stefan, Santosh:

        I would like to put forward a set of processing rules which
might 
actually be implementable for the "intersection" problem here:
A)      The intersection of two SecurityCategory entries with different 
SecurityCategory.Type is empty
B)      The intersection of two SecurityCategory entries with the same 
Type and Value is an entry with that Type and Value
C)      Any relying party unfamiliar with a given SecurityCategory.Type 
SHOULD treat the intersection of two SecurityCategory entries with that 
Type and different Value as being empty
D)      A relying party familiar with a given SecurityCategory.Type MAY 
process the intersection of two SecurityCategory entries with that Type 
and different Value according to customized rules for that type
        One customized type which I would suggest is "prefixable OID".
The 
intersection of two values of this type is the longer of the two if the 
shorter one is its leading binary substring, and is empty otherwise.

                Tom Gindin





Stefan Santesson <[e-mail]> 
Sent by: [e-mail]
10/24/2008 10:00 PM

To
Santosh Chokhani <[e-mail]>, "[e-mail]" 
<[e-mail]>
cc

Subject
RE: draft-turner-caclearanceconstraints-01.txt







Santosh,

What you suggest comes closer to the exercise I think need to be done 
before we decide what to do with this.

To standardize constraints with undefined processing rules feels to me 
like wanting to have one's cake and eat it too.
I think it is absolutely necessary to limit the logic so that an 
implementation can process any legal data within it. Otherwise the basic

idea with having a standard seems a bit lost.

Now, processing all data does not mean that you know the meaning of all 
data, but at least you should be able to process it and hand it over to 
the next layer.

I would also like to have some rationales clarified, but I will ask for 
that in a separate thread.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Santosh Chokhani
> Sent: den 24 oktober 2008 15:52
> To: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Stefan,
>
> As stated in other strands of this thread, this will be handled by
> enhancing the I-D for a specific set of syntaxes of security
categories
> or by deprecating the security categories from the clearance
> constraints.  The latter can obviate the need for taking the
> intersection of security categories.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Stefan Santesson
> Sent: Friday, October 24, 2008 9:27 AM
> To: Timothy J. Miller; Russ Housley
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Thanks for putting such good words to it :)
>
> Yes, that sounds very much like what I meant.
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
> > -----Original Message-----
> > From: Timothy J. Miller [mailto:[e-mail]]
> > Sent: den 24 oktober 2008 15:23
> > To: Russ Housley
> > Cc: Stefan Santesson; [e-mail]
> > Subject: Re: draft-turner-caclearanceconstraints-01.txt
> >
> > Russ Housley wrote:
> >
> > > Where does the document say anything about mapping between
security
> > > policies?
> >
> > I don't think that's what he means.  I think what he's driving at
is:
> > how does a single vendor writing a single chaining library do it
such
> > that the code works under any arbitrary intersection logic the end
> user
> > may specify?
> >
> > Did I get that right, Stefan?
> >
> > -- Tim
>







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TKl0Fi053862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 13:47:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TKl0o7053861; Wed, 29 Oct 2008 13:47:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp192.sat.emailsrvr.com (smtp192.sat.emailsrvr.com [66.216.121.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TKknjs053812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 29 Oct 2008 13:46:59 -0700 (MST) (envelope-from [e-mail])
Received: from relay19.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id EA8001B40ED; Wed, 29 Oct 2008 16:46:48 -0400 (EDT)
Received: by relay19.relay.sat.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTP id EAB7F1B400B; Wed, 29 Oct 2008 16:46:47 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 30 Oct 2008 07:45:55 +1100
From: Stephen Wilson <[e-mail]>
Reply-To: [e-mail]
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Scott Rea <[e-mail]>, [e-mail]
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC> <[e-mail]> <866118DC6DE2423789593062E599DBE1@AndersPC>
In-Reply-To: <866118DC6DE2423789593062E599DBE1@AndersPC>
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>

Anders Rundgren wrote:

> But, it is a fact that there is no such thing as digital signatures in browser
> sessions except through entirely proprietary solutions.  There are hundreds
> of such and they are all different and usually require NDAs if you want to
> look a bit closer.

Sorry, but this 'fact' is just not true!

Lockstep has recently demonstrated a whole suite of privacy enhancing 
solutions for web based transactions (anonymous health record lodgement, 
secure credit Card-Not-Present payments, anonymous e-voting) where 
digital signatures are created at the browser.  We do send a Java applet 
from the server, to generate the signature when the user clicks 'ok' 
(but you wouldn't call that 'proprietary' would you? ).

The building blocks are simply a FIPS-201 type smartcard (with exposed 
PKI interfaces), CAPICOM, XMLsignatures, Javascript and, in this case, 
.NET.

We even found it easy to implement pretty rich business logic.  For 
example, our smartcards contain several keys and certificates; e.g. one 
for voting, one for a credit card number, one for the health ID.  The 
server sends the client the name of the CA that the server is interested 
in for the transaction at hand (e.g. if it's a vote, the only sensible 
certificate is one issued by the electoral commission).  In this way we 
seamlessly manage multiple certificates, in ways that cynics still seem 
to think will be inevitably complex.  In more complex situations, we 
could readily use Policy OIDs, or stems of OIDs, to embody the business 
logic.

Cheers,

Steve Wilson
www.lockstep.com.au/technologies.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TJd9Cc035800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 12:39:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TJd8j8035799; Wed, 29 Oct 2008 12:39:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ssc.lt (mail.ssc.lt [195.43.64.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TJcuFI035748 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 29 Oct 2008 12:39:08 -0700 (MST) (envelope-from [e-mail])
Received: from localhost ([127.0.0.1] helo=mail.ssc.lt) by mail.ssc.lt with esmtp (Exim 4.50) id 1KvGsU-0007p0-AL; Wed, 29 Oct 2008 21:38:50 +0200
Received: from 84.240.23.130 (SquirrelMail authenticated user [e-mail]) by mail.ssc.lt with HTTP; Wed, 29 Oct 2008 21:38:50 +0200 (EET)
Message-ID: <[e-mail]>
In-Reply-To: <866118DC6DE2423789593062E599DBE1@AndersPC>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC> <[e-mail]> <866118DC6DE2423789593062E599DBE1@AndersPC>
Date: Wed, 29 Oct 2008 21:38:50 +0200 (EET)
Subject: Re: Random PKI critiques [was: Rationales for CA clearance  constraints]
From: "Moudrick M. Dadashov" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "Scott Rea" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
User-Agent: SquirrelMail/1.4.6
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
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>

Hi Anders,

This is the publication you might want to look at:

http://ec.europa.eu/idabc/en/document/6484/5644

M.D.
cell: [phone]

On Wed, October 29, 2008 18:58, Anders Rundgren wrote:
>
> <snip>
>>- PIV/CAC
>>Again, the benefit with these credentials is only when there is a broad
>>population base that carries them - the US fed govt is still rolling out
>>this program to its employees. Once critical mass is achieved, I think
>>the benefits of others having these credentials will begin to be
>> realized.
>
> Scott,
> As you probably agree with the Internet-browser has become the primary
> way to interact with just about all kinds of "information systems".
>
> As you probably also agree with, digital signatures is one of the core
> PKI (and thus PIV/CAC) mechanisms.
>
> But, it is a fact that there is no such thing as digital signatures in
> browser
> sessions except through entirely proprietary solutions.  There are
> hundreds
> of such and they are all different and usually require NDAs if you want to
> look a bit closer.
>
> In addition, and this is the really serious part, no authority, government
> body,
> or even academic institution have published anything on how client-side
> PKI should actually work with common information system processes.
>
> It does not IMHO make much difference if we wait another decade or so
> because nothing will actually happen until this very basic job is done.
>
> Anders
>
>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TInZFe025896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 11:49:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TInZmO025895; Wed, 29 Oct 2008 11:49:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9TInOpT025851 for <[e-mail]>; Wed, 29 Oct 2008 11:49:35 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 3852 invoked from network); 29 Oct 2008 18:35:33 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;29 Oct 2008 18:35:33 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 29 Oct 2008 18:35:33 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Rationales for CA clearance constraints
Date: Wed, 29 Oct 2008 14:49:15 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack58PexB4643HoTRjubikc+uawj7AABdlVw
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]> <p06240500c52e2f16c45f@[193.0.24.250]> <[e-mail]>
From: "Santosh Chokhani" <[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>

Minimum processing (without deep inspection of the security categories)
will not require rejecting a certificate.

The updated I-D when posted should be reviewed to post comments.=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Timothy J. Miller
Sent: Wednesday, October 29, 2008 1:52 PM
To: Stephen Kent
Cc: Yoav Nir; Paul Hoffman; [e-mail]
Subject: Re: Rationales for CA clearance constraints

Stephen Kent wrote:

> You are right, i.e., a non-critical extension that is not understood
by=20
> an RP can safely be ignored.  I didn't mean to suggest otherwise.

There's two levels of "understand" here: (1) recognizing the clearance=20
constraint extension; and (2) recognizing the semantics of the=20
particular clearance policyIds.  For arbitrary policyIds, one could have

(1) but not (2).

I agree with Yoav's suggestion; the ACC extension MUST be marked=20
critical.  Then there's no question what to do if the RP doesn't know=20
what to do with the policyId.

I still think 5280 should say something about non-critical extensions=20
that contain information that can't be processed--even if this is only=20
to note that each extension must define what to do in that case.

-- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9THq9AD013861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 10:52:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9THq9xM013860; Wed, 29 Oct 2008 10:52:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9THpwNw013812 for <[e-mail]>; Wed, 29 Oct 2008 10:52:08 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9THpvog031376 for <[e-mail]>; Wed, 29 Oct 2008 13:51:57 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9THpvD9031365; Wed, 29 Oct 2008 13:51:57 -0400
Received: from [129.83.200.5] (129.83.200.5) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 29 Oct 2008 13:51:57 -0400
Message-ID: <[e-mail]>
Date: Wed, 29 Oct 2008 12:51:54 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Yoav Nir <[e-mail]>, Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: Rationales for CA clearance constraints
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]> <p06240500c52e2f16c45f@[193.0.24.250]>
In-Reply-To: <p06240500c52e2f16c45f@[193.0.24.250]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040003000405050308050901"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms040003000405050308050901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> You are right, i.e., a non-critical extension that is not understood by 
> an RP can safely be ignored.  I didn't mean to suggest otherwise.

There's two levels of "understand" here: (1) recognizing the clearance 
constraint extension; and (2) recognizing the semantics of the 
particular clearance policyIds.  For arbitrary policyIds, one could have 
(1) but not (2).

I agree with Yoav's suggestion; the ACC extension MUST be marked 
critical.  Then there's no question what to do if the RP doesn't know 
what to do with the policyId.

I still think 5280 should say something about non-critical extensions 
that contain information that can't be processed--even if this is only 
to note that each extension must define what to do in that case.

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjkxNzUxNTRaMCMGCSqGSIb3DQEJBDEWBBRVI6tRwwPzcD1sqHM22wWmGdHauDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgJCde+kU9frDhjNrCZP7C+dbYI5MKe+cEBZmlHNkllySAc75U93vkwx2zoNX
SJJfVsB1xJE2/tFqHdF0EjYW6JVzqCri6iu4irIwTmoVIpM1/g31Vz0edPUtI4cwVmdDeoU6
JPGxyoaRnoVOFVxpJpu/MBP/wR1AxwHr3pTIop2qAAAAAAAA
--------------ms040003000405050308050901--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TGwjYc000924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 09:58:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TGwjNT000923; Wed, 29 Oct 2008 09:58:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TGwYqN000888 for <[e-mail]>; Wed, 29 Oct 2008 09:58:45 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) id 47A979500470596E; Wed, 29 Oct 2008 17:58:16 +0100
Message-ID: <866118DC6DE2423789593062E599DBE1@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Scott Rea" <[e-mail]>, <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]
Date: Wed, 29 Oct 2008 17:58:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<snip>
>- PIV/CAC
>Again, the benefit with these credentials is only when there is a broad 
>population base that carries them - the US fed govt is still rolling out 
>this program to its employees. Once critical mass is achieved, I think 
>the benefits of others having these credentials will begin to be realized.

Scott,
As you probably agree with the Internet-browser has become the primary
way to interact with just about all kinds of "information systems".

As you probably also agree with, digital signatures is one of the core
PKI (and thus PIV/CAC) mechanisms.

But, it is a fact that there is no such thing as digital signatures in browser
sessions except through entirely proprietary solutions.  There are hundreds
of such and they are all different and usually require NDAs if you want to
look a bit closer.

In addition, and this is the really serious part, no authority, government body,
or even academic institution have published anything on how client-side
PKI should actually work with common information system processes.

It does not IMHO make much difference if we wait another decade or so
because nothing will actually happen until this very basic job is done.

Anders



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TGdmsl096760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 09:39:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TGdmj4096759; Wed, 29 Oct 2008 09:39:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TGdbWw096723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Wed, 29 Oct 2008 09:39:48 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (67-150-23-123.lsan.mdsg-pacwest.com [67.150.23.123]) by smtp2.pacifier.net (Postfix) with ESMTP id 2081475310; Wed, 29 Oct 2008 09:38:44 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: Rationales for CA clearance constraints
Date: Wed, 29 Oct 2008 09:38:36 -0700
Message-ID: <020201c939e4$d81f0c90$885d25b0$@com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0203_01C939AA.2BC03490"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ack4vGm2UNmhSGLXRRel/gzdkKkBRwAGSbiAACdjnbA=
X-MS-TNEF-Correlator: 00000000C61F957EEEE3D311963C000086335A64E422AB00
Content-Language: en-us
Sender: [e-mail]
Precedence: 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 multipart message in MIME format.

------=_NextPart_000_0203_01C939AA.2BC03490
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

I believe that point 5 already exists today and in an area that you have
covered.  If a name constraint exists, it is up to that name constraint to
define what the hierarchical intersection requirements are.  If I don't
understand that name form, how do I determine if the name is properly
contained within the legal name space?

I don't see a difference between this case and the clearance constraint
processing.

Jim


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Stefan Santesson
> Sent: Tuesday, October 28, 2008 2:09 AM
> To: Stephen Kent
> Cc: [e-mail]
> Subject: RE: Rationales for CA clearance constraints
> 
> 
> Let me recap:
> 
> 1) Practical use of PKI, primary in defense/military applications has
> resulted in a need to include clearance information in certificates.
> 
> 2) These applications require clearance constraints processing
> 
> 3) Clearance is defined within a context. An infinite combination of
> context and clearance levels may exist.
> 
> 4) The constraints mechanism calculates the effective clearance of an
> End Entity (EE). The effective clearance for the EE is the intersection
> of all clearances of the path.
> 
> 5) Calculation of effective clearance is dependent on the definition of
> clearance levels (classList) and context (securityCategories and
> policyId), and has no default deterministic logic.
> 
> 
> This differs IMO from anything else we have defined in the past in one
> important way. No prior path validation mechanism that we have defined
> previously (that I can think of) requires you to calculate an
> intersection of values without providing you with the logic for
> calculating that intersection.
> 
> - For policy constraints, I can calculate intersection of valid
> policies without knowing the meaning of each policy.
> - Name constraints are only valid for hierarchical name forms and each
> name form defines the "intersection" logic for matching constraints
> 
> 
> This may seem like a small thing, but I'm not sure it is. If we define
> standards that require us to calculate a certain value X without
> defining the logic for calculating X, then I fear that we may create
> serious interoperability problems and set precedence for bad protocol
> design. Or am I just seeing ghosts?
> 
> 
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > -----Original Message-----
> > From: Stephen Kent [mailto:[e-mail]]
> > Sent: den 28 oktober 2008 06:10
> > To: Stefan Santesson
> > Cc: [e-mail]
> > Subject: RE: Rationales for CA clearance constraints
> >
> > At 12:17 AM +0000 10/28/08, Stefan Santesson wrote:
> > >Stephen, Thanks for a great and elaborate reply.
> > >
> > >It's great to see a list of entities with a certain interest in
> > >this. Nobody but them can decide whether their need is legitimate.
> > >Only we can decide whether this should be standardized.
> > >So I guess my question is more on that why a standard, rather than
> > >if it is legitimate. Many organizations have defined private
> > >extensions. For Banking specific needs you can create a banking
> > >standard and for l military use I assume you can create a military
> > >standard. So if there is no commercial application. Does a standard
> > >still serve the community at large?
> >
> > The IETF has adopted standards that serve communities such as this in
> > the past, c.f., RFC 1108.
> >
> > >Also, you don't tell me why we need constraints, only that it is
> > >very close to our old ANY DEFINED BY. However, the way the undefined
> > >logic here affects path processing is unprecedented. Yes, we have
> > >ANY DEFINED BY in algorithm data, but we don't have constraints
> > >mechanism logic being altered dependent on algorithm.
> > >
> >
> > The constraints mechanism is needed so that one issue a cert to a CA
> > and constraint the range of clearance extensions that are acceptable
> > under that CA.  This is analogous to the use of name constraints in
> > cross certs.
> >
> > I cited the ANY DEFINED BY construct as an example of why the
> > syntactic challenges you cited are analogous to things we have dealt
> > with before.
> >
> > Steve


------=_NextPart_000_0203_01C939AA.2BC03490
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+IjsQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQYABwABAAAAAAAAAQOQBgDIDwAANgAAAAsAAgABAAAAAwAmAAAA
AAALACkAAAAAAAsAKwAAAAAAAwAuAAAAAAACATEAAQAAABgAAAAAAAAAxh+Vfu7j0xGWPAAAhjNa
ZCQiqwAeAHAAAQAAACgAAABSYXRpb25hbGVzIGZvciBDQSBjbGVhcmFuY2UgY29uc3RyYWludHMA
AgFxAAEAAAAgAAAAAck4vGm2UNmhSGLXRRel/gzdkKkBRwAGSbiAACdjnbALAAEOAAAAAAIBCg4B
AAAAGAAAAAAAAADGH5V+7uPTEZY8AACGM1pkwoAAAAMAFA4BAAAAHgAoDgEAAAA3AAAAMDAwMDAw
MGIBaWV0ZkBhdWd1c3RjZWxsYXJzLmNvbQFpZXRmQGF1Z3VzdGNlbGxhcnMuY29tAAAeACkOAQAA
ADcAAAAwMDAwMDAwYgFpZXRmQGF1Z3VzdGNlbGxhcnMuY29tAWlldGZAYXVndXN0Y2VsbGFycy5j
b20AAAIBCRABAAAA3QkAANkJAACiEwAATFpGdZWFSp0DAAoAcmNwZzEyNSIyA0N0ZXgFQmJp/mQE
AAMwAQMB9wqAAqQD5P8HEwKAEHMAUARWCFUHshGlJw5RAwECAGNoCsBzZdx0MgYABsMRpTMERhQ3
3jASrBGzCO8J9zsYnw4wdjURogxgYwBQCwkBZDNeNhbQC6YGAA6wZgBwLAcKogqECoBJIGJlbGEI
kHZlIHQUYAVAcGZvC4AFQDUgB0AYoGFYZHkgDsAEAHQEIHTNBHBhIHAAcGQgC4AhUdcgACAxHzR5
CGAgFGAfEQcFoB8QGKEuICBJZnEgACBuYQeAIyEAgHTucgtxBUAglCwhkAVAD1H8dXAg8R80JC4m
MQEBC4DdHyB3H1IfQB8gaAiRCsA/FFAN4AdAIZEOsBSBY3SKaQIgIBigcXVpGKC/B4ACMAQgIgEj
pB6gZAIg+icFQHUhcCnhAZAhcSZoyQIQcm0lgGhvB+AsAPcr0hSgBJBtKBIGkCiTJCPVD1FwA2Bw
BJBsIHAkcX8BkCgRIYAD8B9AIaEoomwsZWcpgSQjcwqwY2X+Px3sLAQUkB8gIjAPQAEgzSNhbjLw
HrF0dwnhHzHfD1EpcBSQIVMoomMyEArAfwBwNUEkeTAxMvAEEAuAZzouHepKB3Ad6h3kPiBqLTtC
TwUQZwuAKYFNsTihYWdlO0M6xkYDYcw6IC4gKCByLQiQADDALXBraXhAAMADEBIuB3BjLgWwZyBb
Oz7CIQA6Pck6xj5/XSBSTwOgQmUUYGwj4E//I+AddAYCDrAEEAIgOsYGYGsCMD2gVApQcyEhJYBP
zSogbx7ABcAyOCWAAdBEMDhGIDowORFATW06xlQ/8B1icCiwA6BL8ysBOsZDYz2gPig/FURHmHVi
aioRPaBSRUtxvx9gKkEHQAeRLbESoEE3D60k0nM6xk5OTBSgICRBExigKXBwOk5OMSkgrlAkwCoh
KXJ1NmFvI+D4UEtJJYAwMAdwCsAgcO8hoQEBCfAUkC8u8B7gAZD/U3FQYAtQKWEqMgQgFGBON/kY
oHN1P9AxMSGiJqAJ4O8s8SZAC4BM8HUBAEzpC4D/LbJL4yGSMvAAIAaQVSIHkOs5BU6oMlGgVCiw
NmJU+l8qhUzvTfM4WU5OM1GgQ/9YWAQgJ+QxRyIwMMIOwSOg/kFZgigBJaAjEgbQO9EqM39SoDrG
YpUhU12IMhAfEGzvBCAAwCB1Wp80W7NeGweAkxRRAwBzbTYxbGNWkP9aUiiTAREqEiMCXZdSoQBw
XTrGRSFxbYAqMHQgcCj4RUUpI6Bo4mt/NUFMgn8oom5AJcIooim6OsZssmz/AyBdhwQgUqEoogqw
H0Bnr/41YJFqlWRkbs9hFzBgLHF/H8EqUSiiJ+MloGRtZh4o812ANlBzTCCxUaBlw2VVvigqAQhx
bgB1gA6wZwWwPwiQKzEhcEDHBvAN4HlJfGQpJYAhYlWxJqAnw2HfVpEulyCxDeAyAG87wD8wH05P
R0Y2AjTEBCBJTU/3LaADYSFReTGCP3Bm0Sgx/yjBIvJhhjGlCrAgwCGSAiD+ZTrGB3AfkAAgQ8Eo
QCEwPSOgTiZAUyEFsXQCIHb/B0APMFlEaegfQ4WtQMcYoO52KkBSYDCRKB9DHqApcPk1025rUpFR
oCqFBCAiov8mMWqHbNkpu1KhihFFMTFT/whgOEONUA9AhSEiojFiMcT/gZItomTHdZaFIR9DKbqB
3/4tPVCJkn7TTYolgI40kDjfkX+KIn5LfdKS5mt/8APw/5ZzHyAHgGohhSF2QgDQifD3fsSXt5jA
TiQ8KzN4cTCR/4oTTHMo6y1nffOfozrGLWdrJ9VrFCIpuiKUyGcBdP8pQYUhTZ+CT4NUZxI0YWpg
fR7gazSCalByooTzJYBi+ZMxSSdqYH/wNEEIcC8h/yWyI6Aj0YWhJ+Q6xiyzCxH/axIfYV0GUmCP
/VnDC3GSZPwgWJLWOsZ49J6VqCiV6v5YJYAooQOgHqA08ArBi2b/ZxIFACBADrCv5wZxjXEppP8w
UgGgVGIgcDAxAmAq4KS03xSRjRIy8Hgxb+ViIFAwIu8hABgRtGgAkGeXoEJgBcC7JDAr0WpSYDRD
hRJnLhD/IMEzFapvwZ9DT0RYiYJRwHeBkCTAamBNAHA8YZVXV/sLgCwAdwZCfQQlgB1wsIX/wa47
Lzw/yRI9ZEf6P4esgLECMEBiYpegY+FdyLhvRMR4MUYhPbBrRdVGgjD4NjoxAUDIx0e1w1/I9L9J
P0pKSu9L/12fqdk+yLguQQVADiDQcDdHASArp0aARoBRgDAvRjAvRpDvx4LRrChAvYFlUIfJEUf1
9yWAW9AAcGvWdCIwCcEfYf+k0wtgBuAkwGOxGKALUKBY4di7Pkl0JwQg3sQmMf80ZB7ghzF2Qm3S
nYayySmz/weQh0LcuTXyiRIG4CBhraL/KKFqYlOynXBYEShQFKAosP9wMyrAVzQPUTIReUFZMStw
f9y5QnAwkYWh589wMg9Rc52TEWwhgB7AsFdpeiOB+9y6LmJnRTFm8SBwKqDlUd9ZY2bxBbCiQotV
aCFBsFf/JYDfsei0bOjJES9BJaTp2e/FgiBwP1FqIXpVR4X5UyH/ihC5CMkRDsFUAVViI6CY4v5C
3hGFEjLA6BFaIVczj6T/moO40yPxvTD5s9y5sGYhU7/WkgMgVFdSYh6ge4F1JEH/+w9UVvyPCyAj
oO9RL0Sugn9/02PhB4ApMAcxVNojoET+b33isFcBWz7gcsC5oR8T/WPDbSxgbfIfYQtgP2AzBsPY
u2jiSUVURn+jIFD/unBWsrBtB0QH5n3SVoCf0T9/wTXz5ZqG1iWAPzBmLrElgFJGQ1GA0IA44Fj1
3LlBZuBvJYD/wiwEZXD/crEkQfHChaFXQ5mbomOWpP8lsty5I1EwoRgwNmEmMbngR8TwvdAhgEFO
WQUwRaBGSU5FREKQWSOg9kguIB8BcrcjiNIokyxi74xbyRGU1AMTYXaDMBGJ0rs4aCXDbrxGVrEj
oFkFYN8lgIWlEVoYK1bjbH2i5DD7plGxIGGthK9SLBOF09ev/90TaeiU1M/AhRKyQOUihoD/d+sh
h+BfCW9pH2okA2JXUf8LYgKwsQOHka7RVoCytleC/1cg1tDIuHwVN+am8jdRPHD/UpLXCPiYsPSi
Ip/AvHALQP+6sPSwyLgaYrfl1tBjAINU/2FRxaGBgbniV5EaI1J0pdP/XirlmvuAFyCksFnSWojY
2f+aYWOhV3FxASBtL1QNsGWh/6SyZ0GhIASQUoPxwqbxyLj8c3nMkFHj+3BCwfSwMGH/+uU64zJz
NYz8UZLBhbcmYf/IuOQTz8DWkeppzhllcB+WBZhEfUcQAAAAAgEUOgEAAAAQAAAAyC91k0jgz02M
qgs8wN+xEQMA3j+fTgAAAwDxPwkEAAADAAlZAQAAAAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAABCF
AAAAAAAACwAFgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAAaACCAGAAAAAADAAAAAAAAA
RgAAAAABhQAAAAAAAAsAB4AIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAACwAIgAggBgAAAAAA
wAAAAAAAAEYAAAAADoUAAAAAAAADAAqACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAFoAI
IAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwBPgAMgBgAAAAAAwAAAAAAAAEYAAAAAHIEAAAAA
AAADAFOAAyAGAAAAAADAAAAAAAAARgAAAAABgQAAAAAAAAMAVIADIAYAAAAAAMAAAAAAAABGAAAA
ABOBAAABAAAAAwBWgAMgBgAAAAAAwAAAAAAAAEYAAAAAI4EAAP///38LABSBAyAGAAAAAADAAAAA
AAAARgAAAAAmgQAAAAAAAAsAF4EDIAYAAAAAAMAAAAAAAABGAAAAAAOBAAAAAAAABQAkgQMgBgAA
AAAAwAAAAAAAAEYAAAAAAoEAAAAAAAAAAAAAAwAlgQMgBgAAAAAAwAAAAAAAAEYAAAAAEIEAAAAA
AAADACaBAyAGAAAAAADAAAAAAAAARgAAAAARgQAAAAAAAAsAK4EDIAYAAAAAAMAAAAAAAABGAAAA
ACSBAAAAAAAACwAsgQMgBgAAAAAAwAAAAAAAAEYAAAAALIEAAAAAAAADAC2BAyAGAAAAAADAAAAA
AAAARgAAAAApgQAAAAAAAAMALoEDIAYAAAAAAMAAAAAAAABGAAAAACqBAAAAAAAAHgAzgQMgBgAA
AAAAwAAAAAAAAEYAAAAAJ4EAAAEAAAABAAAAAAAAAAMANoEDIAYAAAAAAMAAAAAAAABGAAAAABKB
AAABAAAAHgA5gQMgBgAAAAAAwAAAAAAAAEYAAAAAIYEAAAEAAAABAAAAAAAAAAsAHw4BAAAAAgH4
DwEAAAAQAAAAxh+Vfu7j0xGWPAAAhjNaZAIB+g8BAAAAEAAAAMYflX7u49MRljwAAIYzWmQDAP4P
BQAAAAMADTT9P6MGAwAPNP0/owYCARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAx
AAAAMDAwMDAwMDBDNjFGOTU3RUVFRTNEMzExOTYzQzAwMDA4NjMzNUE2NEU0MjJBQjAwAAAAAAMA
BhBC9aKWAwAHELsMAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAU1RFRkFOLElCRUxJRVZF
VEhBVFBPSU5UNUFMUkVBRFlFWElTVFNUT0RBWUFORElOQU5BUkVBVEhBVFlPVUhBVkVDT1ZFUkVE
SUZBTkFNRUNPTlNUUkFJTlRFWElTVFMsSVRJUwAAAAAD0g==

------=_NextPart_000_0203_01C939AA.2BC03490--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TFZgRu083155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 08:35:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TFZg1X083151; Wed, 29 Oct 2008 08:35:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TFZV9I083091 for <[e-mail]>; Wed, 29 Oct 2008 08:35:41 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.16.1.23]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KvD4z-0000uF-Da; Wed, 29 Oct 2008 11:35:29 -0400
Mime-Version: 1.0
Message-Id: <p06240500c52e2f16c45f@[193.0.24.250]>
In-Reply-To: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]>
Date: Wed, 29 Oct 2008 11:18:45 -0400
To: "Timothy J. Miller" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Cc: Yoav Nir <[e-mail]>, Paul Hoffman <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:03 AM -0500 10/29/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>An RP either knows how to process constraints under a specified 
>>policy, or it doesn't. If it doesn't, the cert MUST be rejected.
>
>Rejection of a cert for failure to process a NON-critical extension 
>strikes me as contrary to the spirit of non-criticality.
>
>-- Tim
>

You are right, i.e., a non-critical extension that is not understood 
by an RP can safely be ignored.  I didn't mean to suggest otherwise.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TEelfx071376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 07:40:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TEeluF071375; Wed, 29 Oct 2008 07:40:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TEekYL071345 for <[e-mail]>; Wed, 29 Oct 2008 07:40:46 -0700 (MST) (envelope-from [e-mail])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7D781294005; Wed, 29 Oct 2008 16:40:45 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C0709294003; Wed, 29 Oct 2008 16:40:44 +0200 (IST)
Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9TEehQC004650; Wed, 29 Oct 2008 16:40:43 +0200 (IST)
Message-Id: <[e-mail]>
From: Yoav Nir <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>, Stephen Kent <[e-mail]>, Paul Hoffman <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Rationales for CA clearance constraints
Date: Wed, 29 Oct 2008 16:40:43 +0200
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

s/constraint/extension/

On Oct 29, 2008, at 4:10 PM, Yoav Nir wrote:

>
> I think this constraint MUST be critical, specifically because this  
> extension (unlike mpeg-of-cat) can make a certificate chain invalid.
>
> On Oct 29, 2008, at 4:03 PM, Timothy J. Miller wrote:
>
>> Stephen Kent wrote:
>>
>>> An RP either knows how to process constraints under a specified  
>>> policy, or it doesn't. If it doesn't, the cert MUST be rejected.
>>
>> Rejection of a cert for failure to process a NON-critical extension  
>> strikes me as contrary to the spirit of non-criticality.
>>
>> -- Tim
>
>
> Scanned by Check Point Total Security Gateway.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TERXEg068443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 07:27:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TERXQL068442; Wed, 29 Oct 2008 07:27:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TERKvk068400 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 29 Oct 2008 07:27:32 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 29 Oct 2008 14:27:20 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Wed, 29 Oct 2008 14:27:20 +0000
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Wed, 29 Oct 2008 14:27:15 +0000
Subject: RE: Comments on the TA requirements document
Thread-Topic: Comments on the TA requirements document
Thread-Index: Ack1Gw5RwCiacYlDQg28ouWioo7jOwAAqt+wAADFKSAAAPbXgAAKFblQAD7RurAAIPrTIAA71DLAAIWYnhA=
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D32195AA918CAEAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Santosh,

I did read the requirements I-D in a very different manner than you, and fo=
r that reason I stopped pretty quickly noticing what specific things that c=
ould change in order for it to support both approaches.
I will give this one more go and try to come up with a reasonable response =
to your request.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Santosh Chokhani
Sent: den 26 oktober 2008 23:43
To: [e-mail]
Subject: RE: Comments on the TA requirements document

Stefan,

I also do not see the I-D as favoring "push" over "pull".

Can you recommend what specific changes you want to make to the I-D?  That =
may get there faster.

My reading of the requirements document is that your model of publishing po=
licies and pulling them by clients is supported by the I-D provided other s=
ecurity related requirements for authentication, integrity, and replay prot=
ection are met.

Why do you think your approach does not meet the requirements I-D?  Again, =
if you suggest specific changes, that are at requirements level (vice imple=
mentation), we are liable to get there and get there faster.

________________________________
From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Carl Wallace
Sent: Saturday, October 25, 2008 2:26 PM
To: [e-mail]
Subject: RE: Comments on the TA requirements document

responses inline...
________________________________
From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Stefan Santesson
Sent: Friday, October 24, 2008 10:48 PM
To: Kemp, David P.; [e-mail]
Subject: RE: Comments on the TA requirements document
Dave

This is not a matter of transport protocol. This is a matter of how you man=
age policies and what protocols you need to support both management and exe=
cution of these policies.

The current requirement document mix together policy management and policy =
execution in one bucket for TA management.

The policy management part deals with ensuring that all hosts knows what ke=
ys they are allowed to trust.
The policy execution part deals with obtaining the keys and parameters asso=
ciated with managed policies and to put them in use in a compliant manner.

Policy management is always initiated and managed centrally and pushed down=
 to users/hosts, or at least enforced upon users/hosts in some way or anoth=
er. There are many ways to do this, but it always involves some kind of cen=
tral management. One way to do this that is very common in my world, is to =
use a directory as the central mechanism to publish policies combined with =
other functions (like system health checks) to make sure hat policies has b=
een downloaded and implemented. In these common cases, there is no need for=
 any new protocol.

Policy execution is something that is carried out by the user/host, based o=
n the centrally distributed policy. One part of policy execution in this ca=
se is to obtain/download the TAs that are considered trustworthy by the dis=
tributed policy. Since the user/host is in control and thus responsible for=
 policy execution, they can also "pull" down any key data associated with t=
he TA policy. The only thing they would need in order to do that, is a comm=
on data format for TA keys and their parameters, signed by some kind of "ma=
ster" TA policy management key. That common data format for TA key informat=
ion is all I currently need.

[CRW] Section 3.2.1 allows for this, i.e.,  a message to replace an entire =
trust anchor store.   This sort of message is essentially a common data for=
mat for TA key information.  Most of the requirements in the draft are quit=
e fundamental - replay detection, integrity, source authentication, intende=
d purposes, basic format requirements, etc. - and would be required by pret=
ty much any TA key information format that could be defined.

We may convince ourselves that we can make a central manager in control of =
policy execution on behalf of users/hosts if we write a super smart protoco=
l (like PKIX TAM), but that would be an illusion. To some extent we will al=
ways need to trust the user/host to carry out the policy in an appropriate =
manner.

This is the world I'm coming from when approaching this subject. When I rea=
d the req document for TA management I do not recognize any protocol that f=
it the needs of my environment.

[CRW] You should recognize lots in common with protocols in your environmen=
t, namely certificates and certificate revocation lists.   Messages to add =
trust anchors are very similar to certificates.  Messages to remove certifi=
cates are very similar to certificate revocation lists.  Most of the diffic=
ulty comes from limiting the applicability/scope of the trust anchor keys.

This is why I have problems providing constructive feedback on it.

Stefan Santesson
Senior Program Manager
Windows Security, Standards
 <snip>

--_000_9F11911AED01D24BAA1C2355723C3D32195AA918CAEAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.htmlpreformattedchar0
	{mso-style-name:htmlpreformattedchar;
	mso-style-priority:99;
	font-family:"Courier New";}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.h41
	{mso-style-name:h41;
	font-family:"Courier New";
	font-weight:bold;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle26
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:navy;}
span.EmailStyle27
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span style=3D'color:#1F49=
7D'>Santosh,<o:p></o:p></span></a></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I did read =
the
requirements I-D in a very different manner than you, and for that reason I
stopped pretty quickly noticing what specific things that could change in o=
rder
for it to support both approaches.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I will give=
 this one
more go and try to come up with a reasonable response to your request.<o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Santosh Chokhani<=
br>
<b>Sent:</b> den 26 oktober 2008 23:43<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> RE: Comments on the TA requirements document<o:p></o:p></sp=
an></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:navy'>Stefan,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:navy'>I also do not see the I-D as favoring &#8220;push&#8221; over &=
#8220;pull&#8221;.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:navy'>Can you recommend what specific changes you want to make to the
I-D? &nbsp;That may get there faster.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:navy'>My reading of the requirements document is that your model of
publishing policies and pulling them by clients is supported by the I-D
provided other security related requirements for authentication, integrity,=
 and
replay protection are met.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:navy'>Why do you think your approach does not meet the requirements I=
-D?
&nbsp;Again, if you suggest specific changes, that are at requirements leve=
l
(vice implementation), we are liable to get there and get there faster.<o:p=
></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span lan=
g=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>

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

</span></div>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Carl Wallace<br>
<b>Sent:</b> Saturday, October 25, 2008 2:26 PM<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> RE: Comments on the TA requirements document</span><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New Roman","serif=
"'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:blue'>responses inline...</span><span style=3D'font-size:12.0pt;font-=
family:
"Times New Roman","serif"'><o:p></o:p></span></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span lan=
g=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>

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

</span></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></=
b><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[e-mail] [mailto:[e-mail]] <b>On Be=
half
Of </b>Stefan Santesson<br>
<b>Sent:</b> Friday, October 24, 2008 10:48 PM<br>
<b>To:</b> Kemp, David P.; [e-mail]<br>
<b>Subject:</b> RE: Comments on the TA requirements document</span><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New Roman","serif=
"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Dave<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>This is not=
 a matter
of transport protocol. This is a matter of how you manage policies and what
protocols you need to support both management and execution of these polici=
es.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>The current
requirement document mix together policy management and policy execution in=
 one
bucket for TA management.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>The policy =
management
part deals with ensuring that all hosts knows what keys they are allowed to
trust.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>The policy =
execution
part deals with obtaining the keys and parameters associated with managed
policies and to put them in use in a compliant manner.<o:p></o:p></span></p=
>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Policy mana=
gement is
always initiated and managed centrally and pushed down to users/hosts, or a=
t
least enforced upon users/hosts in some way or another. There are many ways=
 to
do this, but it always involves some kind of central management. One way to=
 do
this that is very common in my world, is to use a directory as the central
mechanism to publish policies combined with other functions (like system he=
alth
checks) to make sure hat policies has been downloaded and implemented. In t=
hese
common cases, there is no need for any new protocol.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Policy exec=
ution is
something that is carried out by the user/host, based on the centrally
distributed policy. One part of policy execution in this case is to
obtain/download the TAs that are considered trustworthy by the distributed
policy. Since the user/host is in control and thus responsible for policy
execution, they can also &#8220;pull&#8221; down any key data associated wi=
th the TA
policy. The only thing they would need in order to do that, is a common dat=
a
format for TA keys and their parameters, signed by some kind of &#8220;mast=
er&#8221; TA
policy management key. That common data format for TA key information is al=
l I
currently need.</span><span lang=3DEN-US style=3D'font-size:10.0pt;font-fam=
ily:
"Arial","sans-serif";color:blue'>&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>[CRW]&nbsp;=
Section
3.2.1 allows for&nbsp;this,&nbsp;i.e., &nbsp;a message to replace an
entire&nbsp;trust anchor store.&nbsp;&nbsp; This sort of message is
essentially&nbsp;a common data format for TA key information.&nbsp; Most of=
 the
requirements in the draft are quite fundamental - replay detection, integri=
ty,
source authentication, intended purposes, basic format requirements, etc. -=
 and
would&nbsp;be required by pretty much any TA key information format that co=
uld
be defined.</span><o:p></o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>&nbsp;<o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>We may conv=
ince
ourselves that we can make a central manager in control of policy execution=
 on
behalf of users/hosts if we write a super smart protocol (like PKIX TAM), b=
ut
that would be an illusion. To some extent we will always need to trust the
user/host to carry out the policy in an appropriate manner.<o:p></o:p></spa=
n></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>This is the=
 world I&#8217;m
coming from when approaching this subject. When I read the req document for=
 TA
management I do not recognize any protocol that fit the needs of my
environment.&nbsp;</span><span lang=3DEN-US style=3D'font-size:10.0pt;font-=
family:
"Arial","sans-serif";color:blue'>&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>[CRW] You s=
hould
recognize lots in common with protocols in your environment, namely
certificates and certificate revocation lists. &nbsp; Messages to add trust
anchors are very similar to certificates.&nbsp; Messages to remove certific=
ates
are very similar to certificate revocation lists.&nbsp; Most of the difficu=
lty
comes from limiting the applicability/scope of the trust anchor
keys.&nbsp;&nbsp; </span><o:p></o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>&nbsp;<o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>This is why=
 I have
problems providing constructive feedback on it.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:blue'>&nbsp;&lt;snip&gt;&nbsp;</span><span lang=3DEN-US style=3D'colo=
r:#1F497D'><o:p></o:p></span></p>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D32195AA918CAEAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TEB1OY062700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 07:11:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TEB0r4062696; Wed, 29 Oct 2008 07:11:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TEAmS4062615 for <[e-mail]>; Wed, 29 Oct 2008 07:10:59 -0700 (MST) (envelope-from [e-mail])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 50842294005; Wed, 29 Oct 2008 16:10:42 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 675AE294003; Wed, 29 Oct 2008 16:10:41 +0200 (IST)
Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9TEAfQC020852; Wed, 29 Oct 2008 16:10:41 +0200 (IST)
Cc: Stephen Kent <[e-mail]>, Paul Hoffman <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Yoav Nir <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Rationales for CA clearance constraints
Date: Wed, 29 Oct 2008 16:10:35 +0200
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think this constraint MUST be critical, specifically because this  
extension (unlike mpeg-of-cat) can make a certificate chain invalid.

On Oct 29, 2008, at 4:03 PM, Timothy J. Miller wrote:

> Stephen Kent wrote:
>
>> An RP either knows how to process constraints under a specified  
>> policy, or it doesn't. If it doesn't, the cert MUST be rejected.
>
> Rejection of a cert for failure to process a NON-critical extension  
> strikes me as contrary to the spirit of non-criticality.
>
> -- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TE3BWN060852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 07:03:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TE3Beu060851; Wed, 29 Oct 2008 07:03:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TE394H060834 for <[e-mail]>; Wed, 29 Oct 2008 07:03:09 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9TE385r007604 for <[e-mail]>; Wed, 29 Oct 2008 10:03:09 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9TE38DR007588; Wed, 29 Oct 2008 10:03:08 -0400
Received: from [129.83.200.5] (129.83.200.5) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 29 Oct 2008 10:03:08 -0400
Message-ID: <[e-mail]>
Date: Wed, 29 Oct 2008 09:03:05 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Yoav Nir <[e-mail]>, Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: Rationales for CA clearance constraints
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <p06240507c52d9fe588ca@[193.0.24.250]>
In-Reply-To: <p06240507c52d9fe588ca@[193.0.24.250]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080007070703030600010002"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms080007070703030600010002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> An RP either knows how to process constraints under a specified policy, 
> or it doesn't. If it doesn't, the cert MUST be rejected.

Rejection of a cert for failure to process a NON-critical extension 
strikes me as contrary to the spirit of non-criticality.

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjkxNDAzMDVaMCMGCSqGSIb3DQEJBDEWBBR7DZefdi6Fe97z/oBeDeIU8KvOszBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgIHW7ufSvWZ7ZFM5IEIP5+EvrGnskvZ2XkSCyEm6sRk9eh7gtHirU43BkqI9
cZT2Dod0v0EFpYlWgu3CkC43hMFe9ndQEXGAt0g9BU+tdmQl0HKyi+jOWUn0Rtu24/SdHy4g
AzbnxDXEEZ+NS+5ZHWFHcpImu6hVQsxKHJ7W1UTrAAAAAAAA
--------------ms080007070703030600010002--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TDsDFs058784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 06:54:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TDsDJU058783; Wed, 29 Oct 2008 06:54:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TDs1J8058740 for <[e-mail]>; Wed, 29 Oct 2008 06:54:12 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9TDs0t0011310 for <[e-mail]>; Wed, 29 Oct 2008 09:54:00 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9TDs0qL011302; Wed, 29 Oct 2008 09:54:00 -0400
Received: from [129.83.200.5] (129.83.200.5) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 29 Oct 2008 09:54:00 -0400
Message-ID: <[e-mail]>
Date: Wed, 29 Oct 2008 08:53:57 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050607030506030901030809"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms050607030506030901030809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stephen Wilson wrote:

> But I don't understand this critique at all.  I think the reason BCAs 
> have failed in business is because they don't offer anything deeply 
> useful in terms of helping to determine if a transaction-specific 
> certificate is fit for purpose.  

Personally I think bridging is flailing because the implementation is 
complex and difficult for non-PKI-experts to wrap their heads around. 
Hell, even PKI experts have to stop and think about it.  :)

Meanwhile identity federation meets 90% of the same enterprise needs 
with a simpler conceptual model (for non-PKI-experts, that is; "It's 
like Kerberos for the web" goes a long way toward explaining it).

-- Tim



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjkxMzUzNTdaMCMGCSqGSIb3DQEJBDEWBBTTfz57yYbS2DPHVN71kWYhW6ogZzBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgD1gRT3fgNNWFJRVVJKIlSR78G6+CKngApJeW5jiRGkdKQ3xjsVc8vkvFtHb
gSn/Oe99IXc0o4cuhayiJraH/iP+qRc5N2RT6ptuq/n7r3hzY771dqB9uQeegZFylduE1O5P
aBkh9z0QujWCCR+H9vGelj382nQakF2FOSXP7V7JAAAAAAAA
--------------ms050607030506030901030809--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TD3AOH048337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 06:03:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TD3Agk048336; Wed, 29 Oct 2008 06:03:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9TD39Ej048329 for <[e-mail]>; Wed, 29 Oct 2008 06:03:09 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 742 invoked from network); 29 Oct 2008 12:49:21 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;29 Oct 2008 12:49:21 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 29 Oct 2008 12:49:21 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C939C6.AD6472E0"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Rationales for CA clearance constraints
Date: Wed, 29 Oct 2008 09:03:02 -0400
Message-ID: <[e-mail]>
In-Reply-To: <p0624050cc52dffec79c0@[193.0.24.250]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack5wFJHIh6/knJyRZivMAKFTHWqlAABbG3A
References: <p0624050cc52dffec79c0@[193.0.24.250]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

Steve,

=20

At a minimum, binary comparison of constraints in the intermediate
certificates and the clearance in the end certificates is possible even
if the syntax and semantics of value for the various security categories
TYPE are unknown.  Given all these are SET, the binary comparison can be
efficiently implemented.

=20

That could be the minimum processing for all TYPE OID.  If the RP knows
the syntax and semantics of values for a given TYPE, it can do finer
processing.

=20

In the default processing, lack of match for a category will result in
its deprecation and not the rejection of certificate.  This is safe and
secure.

=20

If you like, we can enhance the I-D along these lines and let the group
review it.

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: Wednesday, October 29, 2008 8:06 AM
To: Stefan Santesson
Cc: [e-mail]
Subject: RE: Rationales for CA clearance constraints

=20

Stefan,

=20

here are some observations re your message from Tuesday.

=20

		Let me recap:

		=20

		1) Practical use of PKI, primary in defense/military
applications has resulted in a need to include clearance information in
certificates.

	=20

yes

=20

		2) These applications require clearance constraints
processing

	=20

yes

=20

	3) Clearance is defined within a context. An infinite
combination of context and clearance levels may exist.

=20

the operative term here is may. in practice I don't think there will be
that many combinations of contexts and clearance levels.

=20

		=20

		4) The constraints mechanism calculates the effective
clearance of an End Entity (EE). The effective clearance for the EE is
the intersection of all clearances of the path.

	=20

=20

yes.

		5) Calculation of effective clearance is dependent on
the definition of clearance levels (classList) and context
(securityCategories and policyId), and has no default deterministic
logic.

	=20

=20

yes.

		This differs IMO from anything else we have defined in
the past in one important way. No prior path validation mechanism that
we have defined previously (that I can think of) requires you to
calculate an intersection of values without providing you with the logic
for calculating that intersection.

=20

fair criticism.

=20

		- For policy constraints, I can calculate intersection
of valid policies without knowing the meaning of each policy.

	=20

=20

because the intersection is computed just on the OID values, right?

=20

		- Name constraints are only valid for hierarchical name
forms and each name form defines the "intersection" logic for matching
constraints

	=20

=20

yes, and the same is true for the address space and AS # extensions
defined in RFC 3779. BTW, 3779 is a good example of a standard that
extends the path processing logic, but does not claim to change the
underlying base spec (3280.5280).

=20

		This may seem like a small thing, but I'm not sure it
is. If we define standards that require us to calculate a certain value
X without defining the logic for calculating X, then I fear that we may
create serious interoperability problems and set precedence for bad
protocol design. Or am I just seeing ghosts?

=20

=20

I think you have done a good job of concisely characterizing the issues
we have been discussing, and have clearly articulated your concerns.

=20

We could chose to simply the situation, a bit, by requiring that the
same clearance policy id be present in all of the certs in a path. Sean
& Santosh, do we think there are circumstances where that constraint
would pose problems? If not, then this simplifies the problem, a bit,
because it means that the same intersection logic will apply down the
path.

=20

We do have to face the fact that a relying party processing either
extension will have to have a way to plug in software that knows how to
do this processing, on a per-policy basis. This is analogous to
supporting different signature and hash algorithms, but admittedly more
complex because of the need

to use this code during path processing. Nonetheless, the bottom line is
similar:

=20

        - not all RPs will need to know how to process these extensions.

=20

        - RPs that do know how to process these extensions do not need

          to know  how to process all policy IDs.

=20

        - an RP that does deal with these extensions probably will need
to

          deal with one or a very few policy IDs. If this is true, then
only

          a few plug-in modules will be needed by an RP. this is similar
to

          the typical RP need for crypto algorithm support.

=20

I think you have identified two primary concerns:

=20

        - a vendor who serves a very wide range of users needs to have

          a way for its RP software to load plug-ins for various policy
IDs,

          to enable clearance and clearance constraint processing,

=20

        - that vendor, or others, need to write the plug-ins for the
user

          community.

=20

I'm not convinced that this a bigger challenge than dealing crypto
algorithms specified by OIDs. Crypto algorithms also have to be invoked
at each tier in cert path validation process. Yes, the interface to the
plug-ins is a bit more complex, but the parameters that need to be
passed to a clearance plug-in are well-defined. There is a similar need
to be able to manage the loading of clearance (and algorithm) plug-ins
in a secure fashion.

=20

Stefan, I just saw your message of a few minutes ago. I'm glad you agree
that PKIX can take o this new work item. The straw poll yielded a
majority of votes in favor of the work, although there was far from
unanimous agreement on this topic.

=20

Sean & Santosh, please post an updated version of the document as a 00
PKIX I-D as soon as possible.

=20

Thanks,

=20

Steve


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: Rationales for CA clearance constraints</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body 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'>Steve,<o:p></o:p></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'><o:p>&nbsp;</o:p></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'>At a minimum, binary comparison of =
constraints
in the intermediate certificates and the clearance in the end =
certificates is
possible even if the syntax and semantics of value for the various =
security
categories TYPE are unknown. &nbsp;Given all these are SET, the binary =
comparison can
be efficiently implemented.<o:p></o:p></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'><o:p>&nbsp;</o:p></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'>That could be the minimum =
processing for
all TYPE OID. &nbsp;If the RP knows the syntax and semantics of values =
for a given
TYPE, it can do finer processing.<o:p></o:p></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'><o:p>&nbsp;</o:p></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'>In the default processing, lack of =
match
for a category will result in its deprecation and not the rejection of
certificate.&nbsp; This is safe and secure.<o:p></o:p></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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>If you like, we can enhance the I-D =
along
these lines and let the group review it.<o:p></o:p></span></font></p>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, October =
29, 2008
8:06 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Rationales =
for CA
clearance constraints</span></font><o:p></o:p></p>

</div>

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

<div>

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

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>here are some observations re your message from =
Tuesday.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite =
cite>

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

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

</blockquote>

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

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

</blockquote>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>1) Practical use of PKI, primary in defense/military =
applications has
resulted in a need to include clearance information in =
certificates.<o:p></o:p></span></font></p>

</blockquote>

</blockquote>

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

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

</blockquote>

<div>

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

</div>

<div>

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

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite =
cite>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>2) These applications require clearance constraints =
processing<o:p></o:p></span></font></p>

</blockquote>

</blockquote>

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

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

</blockquote>

<div>

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

</div>

<div>

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

</div>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>3) Clearance is defined within a context. An infinite =
combination of
context and clearance levels may exist.<o:p></o:p></span></font></p>

</blockquote>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>the operative term here is<u> may</u>. in practice I don't think =
there
will be that many combinations of contexts and clearance =
levels.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite =
cite>

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

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>4) The constraints mechanism calculates the effective clearance =
of an
End Entity (EE). The effective clearance for the EE is the intersection =
of all
clearances of the path.<o:p></o:p></span></font></p>

</blockquote>

</blockquote>

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

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

</blockquote>

<div>

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

</div>

<div>

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

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite =
cite>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>5) Calculation of effective clearance is dependent on the =
definition of
clearance levels (classList) and context (securityCategories and =
policyId), and
has no default deterministic logic.<o:p></o:p></span></font></p>

</blockquote>

</blockquote>

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

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

</blockquote>

<div>

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

</div>

<div>

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

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite =
cite>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>This differs IMO from anything else we have defined in the past =
in one
important way. No prior path validation mechanism that we have defined
previously (that I can think of) requires you to calculate an =
intersection of
values without providing you with the logic for calculating that =
intersection.<o:p></o:p></span></font></p>

</blockquote>

</blockquote>

<div>

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

</div>

<div>

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

</div>

<div>

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

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite =
cite>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>- For policy constraints, I can calculate intersection of valid
policies without knowing the meaning of each =
policy.<o:p></o:p></span></font></p>

</blockquote>

</blockquote>

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

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

</blockquote>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>because the intersection is computed just on the OID values, =
right?<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite =
cite>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>- Name constraints are only valid for hierarchical name forms =
and each
name form defines the &quot;intersection&quot; logic for matching =
constraints<o:p></o:p></span></font></p>

</blockquote>

</blockquote>

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

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

</blockquote>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>yes, and the same is true for the address space and AS # =
extensions
defined in RFC 3779. BTW, 3779 is a good example of a standard that =
extends the
path processing logic, but does not claim to change the underlying base =
spec
(3280.5280).<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite =
cite>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>This may seem like a small thing, but I'm not sure it is. If we =
define
standards that require us to calculate a certain value X without =
defining the
logic for calculating X, then I fear that we may create serious
interoperability problems and set precedence for bad protocol design. Or =
am I
just seeing ghosts?<o:p></o:p></span></font></p>

</blockquote>

</blockquote>

<div>

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

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>I think you have done a good job of concisely characterizing the =
issues
we have been discussing, and have clearly articulated your =
concerns.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>We could chose to simply the situation, a bit, by requiring that =
the
same clearance policy id be present in all of the certs in a =
path.<b><span
style=3D'font-weight:bold'> Sean &amp; Santosh, do we think there are
circumstances where that constraint would pose problems?</span></b> If =
not,
then this simplifies the problem, a bit, because it means that the same
intersection logic will apply down the =
path.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>We do have to face the fact that a relying party processing =
either
extension will have to have a way to plug in software that knows how to =
do this
processing, on a per-policy basis. This is analogous to supporting =
different
signature and hash algorithms, but admittedly more complex because of =
the need<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>to use this code during path processing. Nonetheless, the bottom =
line
is similar:<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -<u> not all</u> RPs =
will
need to know how to process these =
extensions.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - RPs that<u> do</u> =
know
how to process these extensions<u> do not</u> =
need<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
know&nbsp;
how to process all policy IDs.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - an RP that does =
deal with
these extensions<u> probably</u> will need =
to<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; deal with =
one or
a very few policy IDs. If this is true, then =
only<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a few =
plug-in
modules will be needed by an RP. this is similar =
to<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
typical RP
need for crypto algorithm support.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>I think you have identified two primary =
concerns:<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - a vendor who serves =
a very
wide range of users needs to have<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a way for =
its RP
software to load plug-ins for various policy =
IDs,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to enable
clearance and clearance constraint =
processing,<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - that vendor, or =
others,
need to write the plug-ins for the user<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>I'm not convinced that this a bigger challenge than dealing =
crypto
algorithms specified by OIDs. Crypto algorithms also have to be invoked =
at each
tier in cert path validation process. Yes, the interface to the plug-ins =
is a
bit more complex, but the parameters that need to be passed to a =
clearance
plug-in are well-defined. There is a similar need to be able to manage =
the
loading of clearance (and algorithm) plug-ins in a secure =
fashion.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>Stefan, I just saw your =
message of a
few minutes ago. I'm glad you agree that PKIX can take o this new work =
item.
The straw poll yielded a majority of votes in favor of the work, =
although there
was far from unanimous agreement on this =
topic.</span></font></b><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>Sean &amp; Santosh, please =
post an
updated version of the document as a 00 PKIX I-D as soon as =
possible.</span></font></b><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

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

</div>

<div>

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

</div>

<div>

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

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C939C6.AD6472E0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TCseT8046786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 05:54:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TCse9b046785; Wed, 29 Oct 2008 05:54:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9TCsTL6046743 for <[e-mail]>; Wed, 29 Oct 2008 05:54:39 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 696 invoked from network); 29 Oct 2008 12:40:31 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;29 Oct 2008 12:40:31 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 29 Oct 2008 12:40:31 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Wed, 29 Oct 2008 08:54:13 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: Ack5W1gUCShHB1FnSMKdxdH78s+kbAAadCuA
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[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>

Tom,

Thanks.

A, B, and C is what I have planned for.

D is the area, I need to decide what types of values to support.  Some
of the times, values may be bit string or enumerated integers and hence
binary comparison may not be valid.

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]=20
Sent: Tuesday, October 28, 2008 8:15 PM
To: Stefan Santesson
Cc: [e-mail]; Santosh Chokhani
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        Stefan, Santosh:

        I would like to put forward a set of processing rules which
might=20
actually be implementable for the "intersection" problem here:
A)      The intersection of two SecurityCategory entries with different=20
SecurityCategory.Type is empty
B)      The intersection of two SecurityCategory entries with the same=20
Type and Value is an entry with that Type and Value
C)      Any relying party unfamiliar with a given SecurityCategory.Type=20
SHOULD treat the intersection of two SecurityCategory entries with that=20
Type and different Value as being empty
D)      A relying party familiar with a given SecurityCategory.Type MAY=20
process the intersection of two SecurityCategory entries with that Type=20
and different Value according to customized rules for that type
        One customized type which I would suggest is "prefixable OID".
The=20
intersection of two values of this type is the longer of the two if the=20
shorter one is its leading binary substring, and is empty otherwise.

                Tom Gindin





Stefan Santesson <[e-mail]>=20
Sent by: [e-mail]
10/24/2008 10:00 PM

To
Santosh Chokhani <[e-mail]>, "[e-mail]"=20
<[e-mail]>
cc

Subject
RE: draft-turner-caclearanceconstraints-01.txt







Santosh,

What you suggest comes closer to the exercise I think need to be done=20
before we decide what to do with this.

To standardize constraints with undefined processing rules feels to me=20
like wanting to have one's cake and eat it too.
I think it is absolutely necessary to limit the logic so that an=20
implementation can process any legal data within it. Otherwise the basic

idea with having a standard seems a bit lost.

Now, processing all data does not mean that you know the meaning of all=20
data, but at least you should be able to process it and hand it over to=20
the next layer.

I would also like to have some rationales clarified, but I will ask for=20
that in a separate thread.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Santosh Chokhani
> Sent: den 24 oktober 2008 15:52
> To: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Stefan,
>
> As stated in other strands of this thread, this will be handled by
> enhancing the I-D for a specific set of syntaxes of security
categories
> or by deprecating the security categories from the clearance
> constraints.  The latter can obviate the need for taking the
> intersection of security categories.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Stefan Santesson
> Sent: Friday, October 24, 2008 9:27 AM
> To: Timothy J. Miller; Russ Housley
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Thanks for putting such good words to it :)
>
> Yes, that sounds very much like what I meant.
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
> > -----Original Message-----
> > From: Timothy J. Miller [mailto:[e-mail]]
> > Sent: den 24 oktober 2008 15:23
> > To: Russ Housley
> > Cc: Stefan Santesson; [e-mail]
> > Subject: Re: draft-turner-caclearanceconstraints-01.txt
> >
> > Russ Housley wrote:
> >
> > > Where does the document say anything about mapping between
security
> > > policies?
> >
> > I don't think that's what he means.  I think what he's driving at
is:
> > how does a single vendor writing a single chaining library do it
such
> > that the code works under any arbitrary intersection logic the end
> user
> > may specify?
> >
> > Did I get that right, Stefan?
> >
> > -- Tim
>





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TC4k1B036727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 05:04:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TC4kjw036726; Wed, 29 Oct 2008 05:04:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TC4YEf036669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 29 Oct 2008 05:04:45 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.24.250]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Kv9mr-0001DZ-AF; Wed, 29 Oct 2008 08:04:33 -0400
Mime-Version: 1.0
Message-Id: <p0624050cc52dffec79c0@[193.0.24.250]>
Date: Wed, 29 Oct 2008 08:05:38 -0400
To: Stefan Santesson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Rationales for CA clearance constraints
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-986840555==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-986840555==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Stefan,

here are some observations re your message from Tuesday.

>Let me recap:
>
>1) Practical use of PKI, primary in defense/military applications 
>has resulted in a need to include clearance information in 
>certificates.

yes

>2) These applications require clearance constraints processing

yes

3) Clearance is defined within a context. An infinite combination of 
context and clearance levels may exist.


the operative term here is may. in practice I don't think there will 
be that many combinations of contexts and clearance levels.

>
>4) The constraints mechanism calculates the effective clearance of 
>an End Entity (EE). The effective clearance for the EE is the 
>intersection of all clearances of the path.


yes.

>5) Calculation of effective clearance is dependent on the definition 
>of clearance levels (classList) and context (securityCategories and 
>policyId), and has no default deterministic logic.


yes.

>This differs IMO from anything else we have defined in the past in 
>one important way. No prior path validation mechanism that we have 
>defined previously (that I can think of) requires you to calculate 
>an intersection of values without providing you with the logic for 
>calculating that intersection.

fair criticism.

>- For policy constraints, I can calculate intersection of valid 
>policies without knowing the meaning of each policy.


because the intersection is computed just on the OID values, right?


>- Name constraints are only valid for hierarchical name forms and 
>each name form defines the "intersection" logic for matching 
>constraints


yes, and the same is true for the address space and AS # extensions 
defined in RFC 3779. BTW, 3779 is a good example of a standard that 
extends the path processing logic, but does not claim to change the 
underlying base spec (3280.5280).


>This may seem like a small thing, but I'm not sure it is. If we 
>define standards that require us to calculate a certain value X 
>without defining the logic for calculating X, then I fear that we 
>may create serious interoperability problems and set precedence for 
>bad protocol design. Or am I just seeing ghosts?


I think you have done a good job of concisely characterizing the 
issues we have been discussing, and have clearly articulated your 
concerns.

We could chose to simply the situation, a bit, by requiring that the 
same clearance policy id be present in all of the certs in a path. 
Sean & Santosh, do we think there are circumstances where that 
constraint would pose problems? If not, then this simplifies the 
problem, a bit, because it means that the same intersection logic 
will apply down the path.

We do have to face the fact that a relying party processing either 
extension will have to have a way to plug in software that knows how 
to do this processing, on a per-policy basis. This is analogous to 
supporting different signature and hash algorithms, but admittedly 
more complex because of the need
to use this code during path processing. Nonetheless, the bottom line 
is similar:

         - not all RPs will need to know how to process these extensions.

         - RPs that do know how to process these extensions do not need
           to know  how to process all policy IDs.

         - an RP that does deal with these extensions probably will need to
           deal with one or a very few policy IDs. If this is true, then only
           a few plug-in modules will be needed by an RP. this is similar to
           the typical RP need for crypto algorithm support.

I think you have identified two primary concerns:

         - a vendor who serves a very wide range of users needs to have
           a way for its RP software to load plug-ins for various policy IDs,
           to enable clearance and clearance constraint processing,

         - that vendor, or others, need to write the plug-ins for the user
           community.

I'm not convinced that this a bigger challenge than dealing crypto 
algorithms specified by OIDs. Crypto algorithms also have to be 
invoked at each tier in cert path validation process. Yes, the 
interface to the plug-ins is a bit more complex, but the parameters 
that need to be passed to a clearance plug-in are well-defined. There 
is a similar need to be able to manage the loading of clearance (and 
algorithm) plug-ins in a secure fashion.

Stefan, I just saw your message of a few minutes ago. I'm glad you 
agree that PKIX can take o this new work item. The straw poll yielded 
a majority of votes in favor of the work, although there was far from 
unanimous agreement on this topic.

Sean & Santosh, please post an updated version of the document as a 
00 PKIX I-D as soon as possible.

Thanks,

Steve
--============_-986840555==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>RE: Rationales for CA clearance
constraints</title></head><body>
<div>Stefan,</div>
<div><br></div>
<div>here are some observations re your message from Tuesday.</div>
<div><br></div>
<blockquote type="cite" cite>
<blockquote>Let me recap:</blockquote>
<blockquote><br></blockquote>
<blockquote>1) Practical use of PKI, primary in defense/military
applications has resulted in a need to include clearance information
in certificates.</blockquote>
</blockquote>
<blockquote><br></blockquote>
<div>yes</div>
<div><br></div>
<blockquote type="cite" cite>
<blockquote>2) These applications require clearance constraints
processing</blockquote>
</blockquote>
<blockquote><br></blockquote>
<div>yes</div>
<div><br></div>
<blockquote>3) Clearance is defined within a context. An infinite
combination of context and clearance levels may exist.<br>
</blockquote>
<div>&nbsp;</div>
<div>the operative term here is<u> may</u>. in practice I don't think
there will be that many combinations of contexts and clearance
levels.</div>
<div>&nbsp;</div>
<blockquote type="cite" cite><br>
<blockquote>4) The constraints mechanism calculates the effective
clearance of an End Entity (EE). The effective clearance for the EE is
the intersection of all clearances of the path.</blockquote>
</blockquote>
<blockquote><br></blockquote>
<div>&nbsp;</div>
<div>yes.<br>
</div>
<blockquote type="cite" cite>
<blockquote>5) Calculation of effective clearance is dependent on the
definition of clearance levels (classList) and context
(securityCategories and policyId), and has no default deterministic
logic.</blockquote>
</blockquote>
<blockquote><br></blockquote>
<div>&nbsp;</div>
<div>yes.<br>
</div>
<blockquote type="cite" cite>
<blockquote>This differs IMO from anything else we have defined in the
past in one important way. No prior path validation mechanism that we
have defined previously (that I can think of) requires you to
calculate an intersection of values without providing you with the
logic for calculating that intersection.</blockquote>
</blockquote>
<div><br></div>
<div>fair criticism.</div>
<div>&nbsp;</div>
<blockquote type="cite" cite>
<blockquote>- For policy constraints, I can calculate intersection of
valid policies without knowing the meaning of each
policy.</blockquote>
</blockquote>
<blockquote><br></blockquote>
<div>&nbsp;</div>
<div>because the intersection is computed just on the OID values,
right?</div>
<div>&nbsp;<br>
</div>
<blockquote type="cite" cite>
<blockquote>- Name constraints are only valid for hierarchical name
forms and each name form defines the &quot;intersection&quot; logic
for matching constraints</blockquote>
</blockquote>
<blockquote><br></blockquote>
<div>&nbsp;</div>
<div>yes, and the same is true for the address space and AS #
extensions defined in RFC 3779. BTW, 3779 is a good example of a
standard that extends the path processing logic, but does not claim to
change the underlying base spec (3280.5280).</div>
<div>&nbsp;<br>
</div>
<blockquote type="cite" cite>
<blockquote>This may seem like a small thing, but I'm not sure it is.
If we define standards that require us to calculate a certain value X
without defining the logic for calculating X, then I fear that we may
create serious interoperability problems and set precedence for bad
protocol design. Or am I just seeing ghosts?</blockquote>
</blockquote>
<div><br></div>
<div>&nbsp;</div>
<div>I think you have done a good job of concisely characterizing the
issues we have been discussing, and have clearly articulated your
concerns.</div>
<div>&nbsp;</div>
<div>We could chose to simply the situation, a bit, by requiring that
the same clearance policy id be present in all of the certs in a
path.<b> Sean &amp; Santosh, do we think there are circumstances where
that constraint would pose problems?</b> If not, then this simplifies
the problem, a bit, because it means that the same intersection logic
will apply down the path.</div>
<div>&nbsp;</div>
<div>We do have to face the fact that a relying party processing
either extension will have to have a way to plug in software that
knows how to do this processing, on a per-policy basis. This is
analogous to supporting different signature and hash algorithms, but
admittedly more complex because of the need</div>
<div>to use this code during path processing. Nonetheless, the bottom
line is similar:</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -<u> not all</u> RPs
will need to know how to process these extensions.</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - RPs that<u> do</u>
know how to process these extensions<u> do not</u> need</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to know&nbsp;
how to process all policy IDs.</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - an RP that does deal
with these extensions<u> probably</u> will need to</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; deal with
one or a very few policy IDs. If this is true, then only</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a few
plug-in modules will be needed by an RP. this is similar to</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the
typical RP need for crypto algorithm support.</div>
<div>&nbsp;</div>
<div>I think you have identified two primary concerns:</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - a vendor who serves
a very wide range of users needs to have</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a way for
its RP software to load plug-ins for various policy IDs,</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to enable
clearance and clearance constraint processing,</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - that vendor, or
others, need to write the plug-ins for the user</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
community.</div>
<div>&nbsp;</div>
<div>I'm not convinced that this a bigger challenge than dealing
crypto algorithms specified by OIDs. Crypto algorithms also have to be
invoked at each tier in cert path validation process. Yes, the
interface to the plug-ins is a bit more complex, but the parameters
that need to be passed to a clearance plug-in are well-defined. There
is a similar need to be able to manage the loading of clearance (and
algorithm) plug-ins in a secure fashion.</div>
<div>&nbsp;</div>
<div><b>Stefan, I just saw your message of a few minutes ago. I'm glad
you agree that PKIX can take o this new work item. The straw poll
yielded a majority of votes in favor of the work, although there was
far from unanimous agreement on this topic.</b></div>
<div><br></div>
<div><b>Sean &amp; Santosh, please post an updated version of the
document as a 00 PKIX I-D as soon as possible.</b></div>
<div><br></div>
<div>Thanks,</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-986840555==_ma============--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TBKukf026677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 04:20:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TBKuNC026676; Wed, 29 Oct 2008 04:20:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TBKim7026636 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 29 Oct 2008 04:20:55 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 29 Oct 2008 11:20:43 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Wed, 29 Oct 2008 11:20:43 +0000
From: Stefan Santesson <[e-mail]>
To: "[e-mail]" <[e-mail]>
CC: Stephen Kent <[e-mail]>
Date: Wed, 29 Oct 2008 11:20:41 +0000
Subject: RE: Rationales for CA clearance constraints
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack5lRMAZbFg3cXSQKuc2SvtgdaF6QAIYIBw
Message-ID: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC> <p06240501c52dae4b506e@[193.0.24.250]>
In-Reply-To: <p06240501c52dae4b506e@[193.0.24.250]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I still have my doubts about clearances in certificates and constraints pro=
cessing with undefined logic, but I think the rationale for the work has be=
en reasonably defended and that there is enough substantial support for thi=
s work for the WG to take it on.

If we decide to accept this work, I would like to propose 2 changes/amendme=
nts to the current approach.

1) To define a default logic for processing the permitted-clearance that is=
 generally implementable.
2) To add a flag or mechanism through which I can tell whether I can apply =
the default logic to the present clearance values.

I think #2 would be possible to solve within the extension syntax without b=
reaking the 3281 attribute syntax.


Stefan Santesson
Senior Program Manager
Windows Security, Standards




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TAE6X8012860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 03:14:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TAE6ho012856; Wed, 29 Oct 2008 03:14:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TADrmF012796 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 29 Oct 2008 03:14:05 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 29 Oct 2008 10:13:52 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Wed, 29 Oct 2008 10:13:52 +0000
From: Stefan Santesson <[e-mail]>
To: Paul Hoffman <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Wed, 29 Oct 2008 10:13:50 +0000
Subject: RE: Rationales for CA clearance constraints
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack5FDA7IHdsTwa4SdqYvfX/fo8pwQAmZvaA
Message-ID: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]>
In-Reply-To: <p06240824c52cd4852e85@[10.20.30.152]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: 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:owner-ietf-
> [e-mail]] On Behalf Of Paul Hoffman
> Sent: den 28 oktober 2008 15:52
>
>
> At 9:09 AM +0000 10/28/08, Stefan Santesson wrote:
> >This differs IMO from anything else we have defined in the past in one
> important way.
>
> Fully disagree.
>
> >No prior path validation mechanism that we have defined previously
> (that I can think of) requires you to calculate an intersection of
> values without providing you with the logic for calculating that
> intersection.
>
> And this one doesn't either, as is clear in the draft. A system that
> does not understand Authority Clearance Constraints doesn't even bother
> with them. One that does can make the calculation given a local
> security policy.
>

Exactly. That is my point. You need to know the processing rule for each an=
d every context identifier to successfully calculate "permitted-clearances"=
, as is clear in the draft.
This is different from any other constraint processing algorithm we have de=
fined in the past.

That does not necessarily mean we should not do it.

/Stefan


> --Paul Hoffman, Director
> --VPN Consortium
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9T6Q11J066319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 23:26:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9T6Q1rj066318; Tue, 28 Oct 2008 23:26:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9T6Q0ca066311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 23:26:01 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.24.250]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Kv4VD-00069O-BY; Wed, 29 Oct 2008 02:25:59 -0400
Mime-Version: 1.0
Message-Id: <p06240501c52dae4b506e@[193.0.24.250]>
In-Reply-To: <15519BF0552B4C7CB58F992A9318E67B@AndersPC>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC>
Date: Wed, 29 Oct 2008 02:13:49 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:54 PM +0100 10/28/08, Anders Rundgren wrote:
>As a side-comment I would like to remind you of some other
>US government PKI-ideas that haven't paid off:
>
>- Bridge CAs
>http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/B2B-article.pdf
>Although it is a cute idea that commercial entities would unite on
>funding sector-BCAs, the need for such arrangements is
>obviated by the use of web-server certificates that can be
>bought for very little money and doesn't even require
>organizations to deploy client-side PKI.

bridge CAs have provided to be valuable in the USG, Japan, and other 
large PKI contexts, irrespective of the B2B article you cite above. 
Also, the notion of a bridge CA is NOT a NIST or USG concept; it was 
developed first in the auto industry context to connect PKIs for the 
major auto manufacturers and parts suppliers.

>- PIV/CAC for purchasing
>It is of little surprise that another NIST department haven't
>plotted with security in the following demo:
>http://www.mel.nist.gov/msid/b2btestbed
>After waiting 10 years for a blueprint describing how you
>would use PIV/CAC in workflow systems, I think it is fair
>concluding that it actually IS impossible to use PKI in an
>end-to-end fashion except for e-mail, but e-mail is neither
>a business system, nor a particularly useful work-flow system.

The primary purpose of the CAC is NOT as a means to enable purchasing.

>It is possible that CA clearance constraints have been extensively
>researched with respect to alternative approaches but I wouldn't
>count on that based on previous endeavors in this space :-)
>
>Anders R

and I wouldn't count on you having a broad understanding of these PKI 
issues based on your previous messages :-).

Steve

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9T6PwML066304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 23:25:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9T6Pwx4066302; Tue, 28 Oct 2008 23:25:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9T6Pmnt066264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 23:25:56 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.24.250]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Kv4Ux-00069O-Cg; Wed, 29 Oct 2008 02:25:44 -0400
Mime-Version: 1.0
Message-Id: <p06240507c52d9fe588ca@[193.0.24.250]>
In-Reply-To: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]>
Date: Wed, 29 Oct 2008 01:07:46 -0400
To: "Timothy J. Miller" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Cc: Yoav Nir <[e-mail]>, Paul Hoffman <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:11 AM -0500 10/28/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>if this extension is marked critical, then an RP that does not 
>>understand it will declare the cert invalid, which is the desired 
>>outcome.
>
>Ah, but what about a RP that understands the extension but *not* the 
>intersection logic of the policy?  Accept or reject?  If accept, how 
>do we know the constraint was applied correctly?
>
>-- Tim

An RP either knows how to process constraints under a specified 
policy, or it doesn't. If it doesn't, the cert MUST be rejected.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9T6PwDr066305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 23:25:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9T6Pwbj066303; Tue, 28 Oct 2008 23:25:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9T6PoKb066265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 23:25:56 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.24.250]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Kv4V3-00069O-Bk; Wed, 29 Oct 2008 02:25:49 -0400
Mime-Version: 1.0
Message-Id: <p06240519c52cb7e81c70@[193.0.24.250]>
In-Reply-To: <[e-mail]>
References: <[e-mail] osoft.com> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 29 Oct 2008 01:18:07 -0400
To: Yoav Nir <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Cc:  <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:02 PM +0200 10/28/08, Yoav Nir wrote:
>>...
>
>On recent discussion on the TLS mailing list, someone said that 
>browsers will silently send a certificate if prompted to by HTTPS 
>web servers. So your comment 2a has broader application.
>
>It's not just Iraqi insurgents capturing a US or British soldier and 
>checking his or her certificate (terrorists as relying parties), but 
>if a DoD employee uses their work computer to surf to, say, Amazon 
>or gmail, their name, rank and clearance levels leak to that party.
>
>I have no idea what's the harm in telling Amazon, gmail or the 
>Russian Mafia that you have top secret clearance, but it sounds bad.


Yaov,

The clearance attribute was defined a while ago, in X.500, and 
adopted by 3281 as a attribute in attribute certs. The user community 
that wants to put this attribute into PKCs understands these issues 
and they want to do it anyway. So, let's not continue to debate 
whether this is a reasonable idea in general. I think it makes more 
sense to focus on the proposed  clearance constraints extension, to 
address the issues Stefan cited in his most recent message.

Steve







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9T4fBQi045174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 21:41:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9T4fBpm045173; Tue, 28 Oct 2008 21:41:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9T4f0eU045126 for <[e-mail]>; Tue, 28 Oct 2008 21:41:11 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.24.250]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1Kv2rb-0004eP-Df; Wed, 29 Oct 2008 00:40:59 -0400
Mime-Version: 1.0
Message-Id: <p06240500c52d992bf542@[193.0.24.250]>
In-Reply-To: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail]>
Date: Wed, 29 Oct 2008 00:40:47 -0400
To: "Timothy J. Miller" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Cc: Stefan Santesson <[e-mail]>, "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:05 AM -0500 10/28/08, Timothy J. Miller wrote:
>Stephen Kent wrote:
>
>>The constraints mechanism is needed so that one issue a cert to a 
>>CA and constraint the range of clearance extensions that are 
>>acceptable under that CA.  This is analogous to the use of name 
>>constraints in cross certs.
>
>I guess I'm just not getting it.  I get (though I don't agree with) 
>the desire to stuff clearance into PKCs, and I agree with providing 
>that mechanism since not everyone sees the division the same way I 
>do.
>
>However, if I have, frex, a CA running at sensitivity level SECRET 
>*issuing* PKCs asserting TOPSECRET, I'm thinking I have bigger 
>problems with my PKI than just whether clients will catch this via 
>clearance constraints.

The CA running on a machine approved for SECRET can easily issue 
certs that have TS clearances, because someone makes an error. We 
can't, in our standards, prevent such errors, but we can create 
mechanisms, e.g., the constraints extension, that serve to mitigate 
such errors.

>  Similarly with categories/compartments--is it realistic to expect a 
>PKI to be partitioned *by CA* so finely that one CA issues TOPSECRET 
>compartments A and B, and another only in compartment C?

maybe.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9T0EoKH095537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 17:14:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9T0Eo67095536; Tue, 28 Oct 2008 17:14:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9T0Ed9M095500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 28 Oct 2008 17:14:50 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id m9T0BCCU024481 for <[e-mail]>; Tue, 28 Oct 2008 20:11:12 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9T0Ec0r119842 for <[e-mail]>; Tue, 28 Oct 2008 20:14:38 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9T0EbjY003993 for <[e-mail]>; Tue, 28 Oct 2008 20:14:37 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9T0Ebab003987; Tue, 28 Oct 2008 20:14:37 -0400
In-Reply-To: <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Santosh Chokhani <[e-mail]>
MIME-Version: 1.0
Subject: RE: draft-turner-caclearanceconstraints-01.txt
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 28 Oct 2008 20:14:36 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1|February 07, 2008) at 10/28/2008 20:14:37, Serialize complete at 10/28/2008 20:14:37
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>

        Stefan, Santosh:

        I would like to put forward a set of processing rules which might 
actually be implementable for the "intersection" problem here:
A)      The intersection of two SecurityCategory entries with different 
SecurityCategory.Type is empty
B)      The intersection of two SecurityCategory entries with the same 
Type and Value is an entry with that Type and Value
C)      Any relying party unfamiliar with a given SecurityCategory.Type 
SHOULD treat the intersection of two SecurityCategory entries with that 
Type and different Value as being empty
D)      A relying party familiar with a given SecurityCategory.Type MAY 
process the intersection of two SecurityCategory entries with that Type 
and different Value according to customized rules for that type
        One customized type which I would suggest is "prefixable OID". The 
intersection of two values of this type is the longer of the two if the 
shorter one is its leading binary substring, and is empty otherwise.

                Tom Gindin





Stefan Santesson <[e-mail]> 
Sent by: [e-mail]
10/24/2008 10:00 PM

To
Santosh Chokhani <[e-mail]>, "[e-mail]" 
<[e-mail]>
cc

Subject
RE: draft-turner-caclearanceconstraints-01.txt







Santosh,

What you suggest comes closer to the exercise I think need to be done 
before we decide what to do with this.

To standardize constraints with undefined processing rules feels to me 
like wanting to have one's cake and eat it too.
I think it is absolutely necessary to limit the logic so that an 
implementation can process any legal data within it. Otherwise the basic 
idea with having a standard seems a bit lost.

Now, processing all data does not mean that you know the meaning of all 
data, but at least you should be able to process it and hand it over to 
the next layer.

I would also like to have some rationales clarified, but I will ask for 
that in a separate thread.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Santosh Chokhani
> Sent: den 24 oktober 2008 15:52
> To: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Stefan,
>
> As stated in other strands of this thread, this will be handled by
> enhancing the I-D for a specific set of syntaxes of security categories
> or by deprecating the security categories from the clearance
> constraints.  The latter can obviate the need for taking the
> intersection of security categories.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Stefan Santesson
> Sent: Friday, October 24, 2008 9:27 AM
> To: Timothy J. Miller; Russ Housley
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Thanks for putting such good words to it :)
>
> Yes, that sounds very much like what I meant.
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
> > -----Original Message-----
> > From: Timothy J. Miller [mailto:[e-mail]]
> > Sent: den 24 oktober 2008 15:23
> > To: Russ Housley
> > Cc: Stefan Santesson; [e-mail]
> > Subject: Re: draft-turner-caclearanceconstraints-01.txt
> >
> > Russ Housley wrote:
> >
> > > Where does the document say anything about mapping between security
> > > policies?
> >
> > I don't think that's what he means.  I think what he's driving at is:
> > how does a single vendor writing a single chaining library do it such
> > that the code works under any arbitrary intersection logic the end
> user
> > may specify?
> >
> > Did I get that right, Stefan?
> >
> > -- Tim
>





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SN1Kha082141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 16:01:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SN1KU0082140; Tue, 28 Oct 2008 16:01:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp172.sat.emailsrvr.com (smtp172.sat.emailsrvr.com [66.216.121.172]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SN19mh082085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 16:01:19 -0700 (MST) (envelope-from [e-mail])
Received: from relay7.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay7.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 041741B41CD for <[e-mail]>; Tue, 28 Oct 2008 19:01:09 -0400 (EDT)
Received: by relay7.relay.sat.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTP id 4A4A91B414B for <[e-mail]>; Tue, 28 Oct 2008 19:01:08 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 29 Oct 2008 10:01:09 +1100
From: Stephen Wilson <[e-mail]>
Reply-To: [e-mail]
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: [e-mail]
Subject: Random PKI critiques [was: Rationales for CA clearance constraints]
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC>
In-Reply-To: <15519BF0552B4C7CB58F992A9318E67B@AndersPC>
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>

Anders Rundgren wrote:
> As a side-comment I would like to remind you of some other
> US government PKI-ideas that haven't paid off:
> 
> - Bridge CAs
> http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/B2B-article.pdf
> Although it is a cute idea that commercial entities would unite on
> funding sector-BCAs ... 

Yes, "cute" is a good word for it.  Bridge CAs have intuitive appeal but 
only if you're interested in one size fits all "passport" for e-commerce.

> the need for such arrangements is
> obviated by the use of web-server certificates that can be
> bought for very little money and doesn't even require
> organizations to deploy client-side PKI.

But I don't understand this critique at all.  I think the reason BCAs 
have failed in business is because they don't offer anything deeply 
useful in terms of helping to determine if a transaction-specific 
certificate is fit for purpose.  The BCA assumes all certificates in the 
pool are more or less equivalent.  I have written about this at 
www.lockstep.com.au/library/babysteps.

So the BCA experience tells us very little about client side PKI in 
general.

> - PIV/CAC for purchasing
> It is of little surprise that another NIST department haven't
> plotted with security in the following demo:
> http://www.mel.nist.gov/msid/b2btestbed
> After waiting 10 years for a blueprint describing how you
> would use PIV/CAC in workflow systems, I think it is fair
> concluding that it actually IS impossible to use PKI in an
> end-to-end fashion except for e-mail, but e-mail is neither
> a business system, nor a particularly useful work-flow system.

Agree very much that e-mail is not a business system, but totally 
disagree with the extrapolation that end-to-end PKI is impossible. 
Unless we're using a very specific, orthodox and outmoded definition of 
"PKI" (to mean something like a commercial one size fits all general 
purpose identity certificate), then there are actually plenty of 
examples of end-to-end PKI, usually in embedded or domain-specific 
applications.  To name a few:

- OpenCable set-top boxes
- Pan Asia Alliance certificates used in trade documentation
- Skype
- Estonia's e-voting system
- nascent e-prescribing solutions using health cards
- Dynamic Data Authentication EMV cards
- my company Lockstep's solution to Card Not Present fraud using 
smartcards ... where we've successfully implemented client side signing 
by smartcard, and server side verification, including the ability for 
the server to tell the browser which certificate amongst many to select 
from the card store.

[If anyone on the list happens to be at the Cartes Conference in Paris 
next week, I can show you the system working.]


And in any case, abstracting the problems of PIV to conclude things 
about PKI in general is pretty tough!  PIV is a politically charged 
billion dollar IT program, which like all politically charged billion 
dollar IT programs has struggled.  They've set aside all value-adding 
exercises until such time as they meet their stripped back deadlines.


Cheers,


Stephen Wilson
Managing Director
Lockstep Technologies

Phone [phone]

www.lockstep.com.au/technologies
-------------------
  * Global Security Challenge Asia Top Five 2008
  * Australian Technology Showcase    2008
  * AusIndustry COMET Grant Recipient  2007
  * ICT Secrets of Innovation Finalist  2007
  * Anthill / PwC Cool Company Finalist  2007
-------------------
Lockstep Consulting provides independent specialist advice and analysis
on authentication, PKI and smartcards.  Lockstep Technologies develops
unique new smart ID solutions that safeguard identity and privacy.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SM1CGw070729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 15:01:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SM1CfB070728; Tue, 28 Oct 2008 15:01:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SM10dc070666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 15:01:11 -0700 (MST) (envelope-from [e-mail])
Received: from [10.211.55.3] (dhcp-212-205.cs.dartmouth.edu [129.170.212.205]) (authenticated bits=0) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id m9SM0bDB005208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <[e-mail]>; Tue, 28 Oct 2008 18:00:39 -0400
Message-ID: <[e-mail]>
Date: Tue, 28 Oct 2008 18:00:37 -0400
From: Scott Rea <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Rationales for CA clearance constraints
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]> <15519BF0552B4C7CB58F992A9318E67B@AndersPC>
In-Reply-To: <15519BF0552B4C7CB58F992A9318E67B@AndersPC>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
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>

- Bridge CAs
Bridge CAs were never about identifying web servers- I think that use 
case for PKI works reasonably well as long as TLS vendors actually add 
some value by vetting the requests for credentials (a lot of them 
don't). Where Bridges become important is when there needs to be 
reliable mutual authentication of service and user - which requires 
client side PKI (the password technology most enterprises are still 
relying upon are a joke) - when there is a broad population of PKI 
credentialed users, THEN I think we will find Bridges to be very 
relevant and important. So from my perspective, Bridges are a technology 
that are still waiting for their day in the sun.

- PIV/CAC
Again, the benefit with these credentials is only when there is a broad 
population base that carries them - the US fed govt is still rolling out 
this program to its employees. Once critical mass is achieved, I think 
the benefits of others having these credentials will begin to be realized.

Have these technologies paid off yet - I agree with Anders - no!
But where I disagree with my colleague, is that I still think these are 
relevant technologies that are yet to have their day in the sun - and 
that day is coming - Your just a little premature Anders!

-Scott

Anders Rundgren wrote:
> As a side-comment I would like to remind you of some other
> US government PKI-ideas that haven't paid off:
>
> - Bridge CAs
> http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/B2B-article.pdf
> Although it is a cute idea that commercial entities would unite on
> funding sector-BCAs, the need for such arrangements is
> obviated by the use of web-server certificates that can be
> bought for very little money and doesn't even require
> organizations to deploy client-side PKI.
>
> - PIV/CAC for purchasing
> It is of little surprise that another NIST department haven't
> plotted with security in the following demo:
> http://www.mel.nist.gov/msid/b2btestbed
> After waiting 10 years for a blueprint describing how you
> would use PIV/CAC in workflow systems, I think it is fair
> concluding that it actually IS impossible to use PKI in an
> end-to-end fashion except for e-mail, but e-mail is neither
> a business system, nor a particularly useful work-flow system.
>
> It is possible that CA clearance constraints have been extensively
> researched with respect to alternative approaches but I wouldn't
> count on that based on previous endeavors in this space :-)
>
> Anders R
>
>   

-- 
Scott Rea
Director, HEBCA Operating Authority
Dartmouth College Sr PKI Architect
Peter Kiewit Computing Services
Dartmouth College
HB 6238, #058 Sudikoff
Hanover, NH 03755

Em: [e-mail]
Ph#[phone]
Ot#[phone]
Ce#[phone] 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SKsLJK057265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 13:54:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SKsLWr057264; Tue, 28 Oct 2008 13:54:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SKsAYx057203 for <[e-mail]>; Tue, 28 Oct 2008 13:54:21 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) id 47A97950046C93DC for [e-mail]; Tue, 28 Oct 2008 21:54:09 +0100
Message-ID: <15519BF0552B4C7CB58F992A9318E67B@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]>
In-Reply-To: <p06240831c52d0b8712e3@[10.20.30.152]>
Subject: Re: Rationales for CA clearance constraints
Date: Tue, 28 Oct 2008 21:54:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As a side-comment I would like to remind you of some other
US government PKI-ideas that haven't paid off:

- Bridge CAs
http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/B2B-article.pdf
Although it is a cute idea that commercial entities would unite on
funding sector-BCAs, the need for such arrangements is
obviated by the use of web-server certificates that can be
bought for very little money and doesn't even require
organizations to deploy client-side PKI.

- PIV/CAC for purchasing
It is of little surprise that another NIST department haven't
plotted with security in the following demo:
http://www.mel.nist.gov/msid/b2btestbed
After waiting 10 years for a blueprint describing how you
would use PIV/CAC in workflow systems, I think it is fair
concluding that it actually IS impossible to use PKI in an
end-to-end fashion except for e-mail, but e-mail is neither
a business system, nor a particularly useful work-flow system.

It is possible that CA clearance constraints have been extensively
researched with respect to alternative approaches but I wouldn't
count on that based on previous endeavors in this space :-)

Anders R



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SJhsF3041993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 12:43:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SJhsTB041992; Tue, 28 Oct 2008 12:43:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9SJhh6I041942 for <[e-mail]>; Tue, 28 Oct 2008 12:43:53 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 24727 invoked from network); 28 Oct 2008 19:30:01 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;28 Oct 2008 19:30:01 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 28 Oct 2008 19:30:01 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Rationales for CA clearance constraints
Date: Tue, 28 Oct 2008 15:43:42 -0400
Message-ID: <[e-mail]>
In-Reply-To: <p06240831c52d0b8712e3@[10.20.30.152]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack5LajxqRN2NjqIQ6SCG82IrJvA6QAB7edA
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]> <p06240831c52d0b8712e3@[10.20.30.152]>
From: "Santosh Chokhani" <[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>

I agree with Paul.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Paul Hoffman
Sent: Tuesday, October 28, 2008 2:34 PM
To: Timothy J. Miller
Cc: [e-mail]
Subject: Re: Rationales for CA clearance constraints


At 12:34 PM -0500 10/28/08, Timothy J. Miller wrote:
>Paul Hoffman wrote:
>
>>>If the ACC extension is non-critical and the RP doesn't grok the
policy requirements, ...?
>
>>The draft should say what to do in that case.
>
>Is this something that *5280* should say?  It seems like a missing
case--extension non-critical but contains information that can't be
processed.

I don't think so. It should be on an extension-by-extension basis, with
the spec of the extension having to say what to do in all cases.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SIYUQQ026406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 11:34:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SIYUQL026405; Tue, 28 Oct 2008 11:34:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SIYPko026372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 11:34:28 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240831c52d0b8712e3@[10.20.30.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]> <[e-mail]>
Date: Tue, 28 Oct 2008 11:34:23 -0700
To: "Timothy J. Miller" <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:34 PM -0500 10/28/08, Timothy J. Miller wrote:
>Paul Hoffman wrote:
>
>>>If the ACC extension is non-critical and the RP doesn't grok the policy requirements, ...?
>
>>The draft should say what to do in that case.
>
>Is this something that *5280* should say?  It seems like a missing case--extension non-critical but contains information that can't be processed.

I don't think so. It should be on an extension-by-extension basis, with the spec of the extension having to say what to do in all cases.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SHYM6R013593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 10:34:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SHYMJh013590; Tue, 28 Oct 2008 10:34:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SHYKK2013568 for <[e-mail]>; Tue, 28 Oct 2008 10:34:21 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9SHYKQl010725 for <[e-mail]>; Tue, 28 Oct 2008 13:34:20 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9SHYKGW010718; Tue, 28 Oct 2008 13:34:20 -0400
Received: from [129.83.200.4] (129.83.200.4) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 28 Oct 2008 13:34:20 -0400
Message-ID: <[e-mail]>
Date: Tue, 28 Oct 2008 12:34:18 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Paul Hoffman <[e-mail]>
CC: [e-mail]
Subject: Re: Rationales for CA clearance constraints
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]> <p06240828c52ce95a104c@[10.20.30.152]>
In-Reply-To: <p06240828c52ce95a104c@[10.20.30.152]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060900010304000401020601"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms060900010304000401020601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Paul Hoffman wrote:

>> If the ACC extension is non-critical and the RP doesn't grok the policy requirements, ...?

> The draft should say what to do in that case.

Is this something that *5280* should say?  It seems like a missing 
case--extension non-critical but contains information that can't be 
processed.

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjgxNzM0MThaMCMGCSqGSIb3DQEJBDEWBBQTjqUGBs7xKRNUUQghJ1cYqLr2PDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgAdpV1jnQOjWAhUUuQEVeI/SoxU349D67SKb0byDa0kB8xGc6ZuCAtFNNjho
qgRYw4bqtzxOZ+L36pueZ01PcvhzrJgbztUmtXADV/bmhBBbBwthfisCKiyjIQkOT+CHZPqM
Nut35whlMBgTvg/JWQJBr6EpOypdSB0owAvT/aQaAAAAAAAA
--------------ms060900010304000401020601--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SHF1rq009495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 10:15:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SHF1oO009494; Tue, 28 Oct 2008 10:15:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SHF190009488 for <[e-mail]>; Tue, 28 Oct 2008 10:15:01 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 54F4528C323; Tue, 28 Oct 2008 10:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-tac-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 28 Oct 2008 10:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: 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		: Traceable Anonymous Certificate
	Author(s)	: S. Park, H. Park, Y. Won, J. Lee, S. Kent
	Filename	: draft-ietf-pkix-tac-01.txt
	Pages		: 31
	Date		: 2008-10-28
	
Public Key Infrastructure (PKI) provides a powerful means of 
   authenticating individuals, organizations, and computers(e.g.,  
   web servers). However, when individuals use certificates to  
   access resources on the public Internet, there are legitimate 
   concerns about personal privacy, and thus there are increasing 
   demands for privacy enhancing techniques on the Internet. 

   In a PKI, an authorized entity such as a certification Authority 
   (CA) or a Registration Authority (RA) may be perceived, from a 
   privacy perspective, as a "big brother," even when a CA issues a 
   certificate containing a Subject name that is a pseudonym. This  
   is because such entities can always map a pseudonym in a  
   certificate they issued to the name of the real user to whom it  
   was issued. This document defines a practical architecture and 
   protocols for offering privacy for a user who requests and uses  
   an X.509 certificate containing a pseudonym, while still retaining 
   the ability to map such a certificate to the real user who  
   requested it. The architecture is compatible with IETF certificate 
   request formats such as PKCS10 [2], CRMF [3]. The architecture 
   separates the authorities involved in issuing a certificate: one  
   for verifying ownership of a private key (Blind Issuer) and the  
   other for validating the contents of a certificate (Anonymous  
   Issuer). The end-entity(EE) certificates issued under this model  
   are called Traceable Anonymous Certificates (TACs).

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-tac-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SG9ZXu093455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 09:09:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SG9Zbs093454; Tue, 28 Oct 2008 09:09:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SG9X5q093441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 09:09:34 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240828c52ce95a104c@[10.20.30.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]> <[e-mail]>
Date: Tue, 28 Oct 2008 09:09:32 -0700
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:53 AM -0500 10/28/08, Timothy J. Miller wrote:
>So per 5280 if an RP recognizes the ACC extension, it MUST process it, whether critical or non-critical.

Correct.

>  If the ACC extension is critical and the RP doesn't grok the policy requirements, then it MUST reject ("contains information that it cannot process").

Sounds right to me, but it would be better if the draft itself said that directly.

>If the ACC extension is non-critical and the RP doesn't grok the policy requirements, ...?

The draft should say what to do in that case.

Of course, none of this is relevant to whether or not the WG should take on this work.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SG6RDe092663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 09:06:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SG6RCG092662; Tue, 28 Oct 2008 09:06:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9SG6QhR092647 for <[e-mail]>; Tue, 28 Oct 2008 09:06:26 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 22830 invoked from network); 28 Oct 2008 15:52:45 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;28 Oct 2008 15:52:45 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 28 Oct 2008 15:52:45 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Rationales for CA clearance constraints
Date: Tue, 28 Oct 2008 12:06:25 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack5DBUnRPtJZA4gSFO6Gs5ZX4m3KgACFbiw
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[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>

Tim,

The relying party is able to process the security categories.  It
securely deprecates the ones whose OID it does not know.  This is safe.

In the end, the certification path does not have any security category
assertion for the subject certificate for the given OID, which is safe.

-----Original Message-----
From: Timothy J. Miller [mailto:[e-mail]]=20
Sent: Tuesday, October 28, 2008 10:47 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: Rationales for CA clearance constraints

Santosh Chokhani wrote:
> If a relying party does not know the semantics of OID asserted in the
> TYPE field of a security category, it will not be doing access control
> on an object asserting the same and hence can ignore that security
> category.

"""
4.2.  Certificate Extensions

							   [...] A
    certificate-using system MUST reject the certificate if it
encounters
    a critical extension it does not recognize or a critical extension
    that contains information that it cannot process.
"""

-- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SFrdo1089131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 08:53:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SFrcRg089130; Tue, 28 Oct 2008 08:53:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SFrbnL089108 for <[e-mail]>; Tue, 28 Oct 2008 08:53:37 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9SFraXL008606 for <[e-mail]>; Tue, 28 Oct 2008 11:53:36 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9SFra6r008596; Tue, 28 Oct 2008 11:53:36 -0400
Received: from [129.83.200.4] (129.83.200.4) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 28 Oct 2008 11:53:36 -0400
Message-ID: <[e-mail]>
Date: Tue, 28 Oct 2008 10:53:34 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Paul Hoffman <[e-mail]>
CC: [e-mail]
Subject: Re: Rationales for CA clearance constraints
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com> <p06240824c52cd4852e85@[10.20.30.152]>
In-Reply-To: <p06240824c52cd4852e85@[10.20.30.152]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040300070307050103010406"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms040300070307050103010406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Paul Hoffman wrote:

> And this one doesn't either, as is clear in the draft. A system that does not understand Authority Clearance Constraints doesn't even bother with them. One that does can make the calculation given a local security policy.

"""
4.2.  Certificate Extensions

    [...]							A
    certificate-using system MUST reject the certificate if it encounters
    a critical extension it does not recognize or a critical extension
    that contains information that it cannot process.  A non-critical
    extension MAY be ignored if it is not recognized, but MUST be
    processed if it is recognized.
"""

So per 5280 if an RP recognizes the ACC extension, it MUST process it, 
whether critical or non-critical.  If the ACC extension is critical and 
the RP doesn't grok the policy requirements, then it MUST reject 
("contains information that it cannot process").

If the ACC extension is non-critical and the RP doesn't grok the policy 
requirements, ...?

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjgxNTUzMzRaMCMGCSqGSIb3DQEJBDEWBBQHwVF1q6e/ozqaemtdWaLzfU/BYTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgA0nNCFkBDHzAnbM2QSQ5Xemn5/UfTjCRfSLXVZdNO/pW/vBnMLoVWEiFL9k
gMLwWSUfstmQfr32HHAo2kX/1rg5NYp1oyRzfd7AhwtFvzbGqDuSkPl/stKHmK0HXOUqmOYT
SA7352S9J0YkJqhvCJ2nVlpcdMfmBxaVQW+vKAjtAAAAAAAA
--------------ms040300070307050103010406--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SFlBEi087459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 08:47:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SFlBb2087458; Tue, 28 Oct 2008 08:47:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9SFl0uQ087401 for <[e-mail]>; Tue, 28 Oct 2008 08:47:10 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 22667 invoked from network); 28 Oct 2008 15:33:19 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;28 Oct 2008 15:33:19 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 28 Oct 2008 15:33:18 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93914.69C5E084"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Rationales for CA clearance constraints
Date: Tue, 28 Oct 2008 11:46:59 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack5C3cfR3B0KQuJQC2kc+3HKeGxPQAB8d9w
References: <[e-mail]> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail]> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "ietf-pkix" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C93914.69C5E084
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Denis,

=20

See responses in-line.

=20

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Denis Pinkas
Sent: Tuesday, October 28, 2008 10:30 AM
To: ietf-pkix
Subject: RE: Rationales for CA clearance constraints

=20

Debate about PKC is misleading since the I-D covers the clearances in
both PKC and AC. PKC is included for broader applicability.

=20

[Denis] If the logic only applies to ACs, then it is sufficient to apply
the constraints to AAs,
which means only to the AA that issues clearances. Then the topic is no
more about path processing.

The big advantage is that path processing is unchanged. If clearances
are supported by the RP=20
then the RP shall look only look at the clearance constraints (if any)
included in the certificate issued to the AA.

[Santosh] This I-D, when it becomes an RFC, will not change 5280.  I see
the resulting RFC as a stand-alone RFC to which compliance can be
claimed.  If a CA asserts clearance constraint to be critical and a
relying party does not understand the extension, it should gracefully
reject the certificate.  If the CA asserts clearance constraint as
non-critical, it can be ignored.  So, I do not see this I-D impacting
5280 or 5280 compliant clients.

=20

Looking for "broader applicability" creates problems, the first one
behing that it is a bad practice=20
to place clearances on PKCs. Not everybody needs to know that someone is
cleared to TOP SECRET=20
for some categories.

[Santosh]The environments that decide to put clearance in PKC will do so
with this recognition.

=20

I would have no problem supporting a NWI about clearance constraints, if
the scope is limited to AAs.


If the logic listed below is applies, we do not need any of the
constraints in the current 5280. You may need to provide granular
clearance authorities to the CAs.

In addition, in cross certified environments, the Enterprise CAs in
Enterprise "A" may be authorized for all clearances, but other
Enterprises "B" and "C" may want to trust "A" for different clearances
depending on business relationship. CA Clearance Constraints assist
with that.

=20

[Denis] I am not sure to get the point. I fear that the argumentation
above is in favor=20
of applying constraints by the RP directly through the use of validation
policies rather than by CAs.

One RP can place some clearance constraints on an AA while another may
have different ones.=20
In such a model, clearances constraints are not set by ACs anymore, but
by RPs through=20
different validation policies.

[Santosh] Constraints are asserted by authorities in signed objects and
enforced by relying parties during path validation.  If a specific
relying party wanted to constrain a trust anchor, that is accommodated
in the I-D.  Any other constraints on intermediate certificates created
by the relying party are outside the scope of path validation.  This is
consistent with X.509 and 5280 approach to path validation.


In summary constraints in CAs let different CAs authorize a CA for
different privileges. Constraints allow the relying parties to enforce
these constraints based on the assertions made by their trust anchor.

-----Original Message-----
From: [e-mail]
<mailto:[e-mail]>
[mailto:[e-mail]
<mailto:[e-mail]> ]
On Behalf Of Timothy J. Miller
Sent: Tuesday, October 28, 2008 9:05 AM
To: Stephen Kent
Cc: Stefan Santesson; [e-mail] <mailto:[e-mail]>=20
Subject: Re: Rationales for CA clearance constraints

Stephen Kent wrote:

> The constraints mechanism is needed so that one issue a cert to a CA
and=20
> constraint the range of clearance extensions that are acceptable under

> that CA. This is analogous to the use of name constraints in cross
certs.

I guess I'm just not getting it. I get (though I don't agree with) the=20
desire to stuff clearance into PKCs, and I agree with providing that=20
mechanism since not everyone sees the division the same way I do.

However, if I have, frex, a CA running at sensitivity level SECRET=20
*issuing* PKCs asserting TOPSECRET, I'm thinking I have bigger problems=20
with my PKI than just whether clients will catch this via clearance=20
constraints. Similarly with categories/compartments--is it realistic to

expect a PKI to be partitioned *by CA* so finely that one CA issues=20
TOPSECRET compartments A and B, and another only in compartment C?

-- Tim




------_=_NextPart_001_01C93914.69C5E084
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dblue =
leftmargin=3D5 topmargin=3D5>

<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'>Denis,<o:p></o:p></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'><o:p>&nbsp;</o:p></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'>See responses =
in-line.<o:p></o:p></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'><o:p>&nbsp;</o:p></span></font></p>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Denis Pinkas<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, October =
28, 2008
10:30 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ietf-pkix<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Rationales =
for CA
clearance constraints</span></font><o:p></o:p></p>

</div>

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

<div>

<p class=3DMsoNormal><font size=3D1 face=3DTahoma><span =
style=3D'font-size:8.0pt;
font-family:Tahoma'>Debate about PKC is misleading since the I-D covers =
the
clearances in<br>
both PKC and AC. PKC is included for broader =
applicability.<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DTahoma><span =
style=3D'font-size:8.0pt;
font-family:Tahoma'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:navy'>[Denis] If the logic only applies =
to ACs,
then it is sufficient to apply the constraints to AAs,<br>
which means only to the AA that issues&nbsp;clearances. Then the topic =
is no
more about&nbsp;path processing.</span></font><font size=3D1 =
face=3DTahoma><span
style=3D'font-size:8.0pt;font-family:Tahoma'><o:p></o:p></span></font></p=
>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:navy'>The big advantage is that path =
processing
is unchanged. If clearances are supported by the RP <br>
then the RP&nbsp;shall look only look at the clearance constraints (if
any)&nbsp;included in the certificate issued to =
the&nbsp;AA.</span></font><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'><o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Santosh] This I-D, when it becomes an RFC, will not =
change 5280.
&nbsp;I see the resulting RFC as a stand-alone RFC to which compliance =
can be
claimed. &nbsp;If a CA asserts clearance constraint to be critical and a =
relying
party does not understand the extension, it should gracefully reject the
certificate. &nbsp;If the CA asserts clearance constraint as =
non-critical, it can be
ignored. &nbsp;So, I do not see this I-D impacting 5280 or 5280 =
compliant clients.</span></font></i></b><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DTahoma><span =
style=3D'font-size:8.0pt;
font-family:Tahoma'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:navy'>Looking for &quot;broader
applicability&quot; creates problems, the first one behing that it is a =
bad
practice <br>
to place clearances on PKCs. Not everybody needs to know that someone is
cleared to TOP SECRET <br>
for some categories.</span></font><font size=3D2 face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Santosh]The environments that decide to put =
clearance in
PKC will do so with this recognition.</span></font></i></b><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DTahoma><span =
style=3D'font-size:8.0pt;
font-family:Tahoma'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:navy'>I would have no problem supporting =
a NWI
about clearance constraints, if the scope is limited to =
AAs</span></font><font
size=3D1 color=3Dnavy face=3DTahoma><span =
style=3D'font-size:8.0pt;font-family:Tahoma;
color:navy'>.</span></font><font size=3D1 face=3DTahoma><span =
style=3D'font-size:
8.0pt;font-family:Tahoma'><o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DTahoma><span =
style=3D'font-size:8.0pt;
font-family:Tahoma'><br>
If the logic listed below is applies, we do not need any of the<br>
constraints in the current 5280. You may need to provide granular<br>
clearance authorities to the CAs.<br>
<br>
In addition, in cross certified environments, the Enterprise CAs in<br>
<st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Enterprise</st1:place></st1:City>
&quot;A&quot; may be authorized for all clearances, but other<br>
Enterprises &quot;B&quot; and &quot;C&quot; may want to trust =
&quot;A&quot; for
different clearances<br>
depending on business relationship. CA Clearance Constraints assist<br>
with that.<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DTahoma><span =
style=3D'font-size:8.0pt;
font-family:Tahoma'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:navy'>[Denis] I am not sure to get the =
point. I
fear that the argumentation above is in favor <br>
of applying constraints by the RP directly through the use =
of&nbsp;validation
policies rather than by CAs.</span></font><font size=3D1 =
face=3DTahoma><span
style=3D'font-size:8.0pt;font-family:Tahoma'><o:p></o:p></span></font></p=
>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:navy'>One RP can place some clearance
constraints on an AA while another may have different ones. <br>
In such a model, clearances constraints are not set by ACs anymore, but =
by RPs
through <br>
different validation policies.</span></font><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'><o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[Santosh] Constraints are asserted by authorities in =
signed
objects and enforced by relying parties during path validation. &nbsp;If =
a specific
relying party wanted to constrain a trust anchor, that is accommodated =
in the
I-D. &nbsp;Any other constraints on intermediate certificates created by =
the relying
party are outside the scope of path validation. &nbsp;This is consistent =
with X.509
and 5280 approach to path validation.</span></font></i></b><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D1 =
face=3DTahoma><span
style=3D'font-size:8.0pt;font-family:Tahoma'><br>
In summary constraints in CAs let different CAs authorize a CA for<br>
different privileges. Constraints allow the relying parties to =
enforce<br>
these constraints based on the assertions made by their trust =
anchor.<br>
<br>
-----Original Message-----<br>
From: <a =
href=3D"mailto:[e-mail]">[e-mail].=
org</a>
[mailto:<a =
href=3D"mailto:[e-mail]">[e-mail].=
org</a>]<br>
On Behalf Of Timothy J. Miller<br>
Sent: Tuesday, October 28, 2008 9:05 AM<br>
To: Stephen Kent<br>
Cc: Stefan Santesson; <a =
href=3D"mailto:[e-mail]">[e-mail]</a><br>
Subject: Re: Rationales for CA clearance constraints<br>
<br>
Stephen Kent wrote:<br>
<br>
&gt; The constraints mechanism is needed so that one issue a cert to a =
CA<br>
and <br>
&gt; constraint the range of clearance extensions that are acceptable =
under<br>
<br>
&gt; that CA. This is analogous to the use of name constraints in =
cross<br>
certs.<br>
<br>
I guess I'm just not getting it. I get (though I don't agree with) the =
<br>
desire to stuff clearance into PKCs, and I agree with providing that =
<br>
mechanism since not everyone sees the division the same way I do.<br>
<br>
However, if I have, frex, a CA running at sensitivity level SECRET <br>
*issuing* PKCs asserting TOPSECRET, I'm thinking I have bigger problems =
<br>
with my PKI than just whether clients will catch this via clearance <br>
constraints. Similarly with categories/compartments--is it realistic =
to<br>
<br>
expect a PKI to be partitioned *by CA* so finely that one CA issues <br>
TOPSECRET compartments A and B, and another only in compartment C?<br>
<br>
-- Tim<br>
<br>
<o:p></o:p></span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C93914.69C5E084--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SEvJrG075006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 07:57:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SEvJSb075005; Tue, 28 Oct 2008 07:57:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SEvHvv074991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 07:57:18 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240825c52cd7d6f552@[10.20.30.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]>
Date: Tue, 28 Oct 2008 07:57:00 -0700
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:11 AM -0500 10/28/08, Timothy J. Miller wrote:
>Ah, but what about a RP that understands the extension but *not* the intersection logic of the policy?  Accept or reject?  If accept, how do we know the constraint was applied correctly?

This is covered in the current draft, although vaguely. (We are all reading the draft we're talking about, yes?)

       -- Calculate securityCategories intersection in accordance with
          guidelines associated with the security policy represented by
          the policyID.

I would read this as "if it's not covered in the security policy represented by the policyID, you're hosed; abort path processing". Adding that to the draft might be of value.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SEvI6O074998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 07:57:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SEvIT7074997; Tue, 28 Oct 2008 07:57:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SEvHvt074991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 07:57:18 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240824c52cd4852e85@[10.20.30.152]>
In-Reply-To: <[e-mail] osoft.com>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail] osoft.com>
Date: Tue, 28 Oct 2008 07:51:52 -0700
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: RE: Rationales for CA clearance constraints
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:09 AM +0000 10/28/08, Stefan Santesson wrote:
>This differs IMO from anything else we have defined in the past in one important way.

Fully disagree.

>No prior path validation mechanism that we have defined previously (that I can think of) requires you to calculate an intersection of values without providing you with the logic for calculating that intersection.

And this one doesn't either, as is clear in the draft. A system that does not understand Authority Clearance Constraints doesn't even bother with them. One that does can make the calculation given a local security policy.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SElLAk073113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 07:47:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SElLfQ073112; Tue, 28 Oct 2008 07:47:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SElJOK073097 for <[e-mail]>; Tue, 28 Oct 2008 07:47:20 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9SElImh008647 for <[e-mail]>; Tue, 28 Oct 2008 10:47:18 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9SElIZU008629; Tue, 28 Oct 2008 10:47:18 -0400
Received: from [129.83.200.4] (129.83.200.4) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 28 Oct 2008 10:47:14 -0400
Message-ID: <[e-mail]>
Date: Tue, 28 Oct 2008 09:47:12 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Rationales for CA clearance constraints
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000005010109050004070201"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms000005010109050004070201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Santosh Chokhani wrote:
> If a relying party does not know the semantics of OID asserted in the
> TYPE field of a security category, it will not be doing access control
> on an object asserting the same and hence can ignore that security
> category.

"""
4.2.  Certificate Extensions

							   [...] A
    certificate-using system MUST reject the certificate if it encounters
    a critical extension it does not recognize or a critical extension
    that contains information that it cannot process.
"""

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjgxNDQ3MTJaMCMGCSqGSIb3DQEJBDEWBBT3P3zvJ+BmohEfEIc7v4NO27BtkjBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgGhGdAabZWmNv3J8Rlgdak4u0j8b4m4nAM0rcXJqDBJR+Bt4huCEJl5+071L
tVhPy+ilLL2prRvTFJEZnNTQYa2nE9mGxjLf7HGDcNsOIrjnoANjRtuqRFVX0+x/ru9nXv5p
amN1xSoJj5cot/tmy2CUOm/2h4cbnZ0mXhWa6vqlAAAAAAAA
--------------ms000005010109050004070201--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SEc6R2071291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 07:38:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SEc66s071290; Tue, 28 Oct 2008 07:38:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9SEbtpj071250 for <[e-mail]>; Tue, 28 Oct 2008 07:38:05 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 13638 invoked by uid 0); 28 Oct 2008 14:37:52 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.145.18) by woodstock.binhost.com with SMTP; 28 Oct 2008 14:37:52 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 28 Oct 2008 10:34:54 -0400
To: "BRUMBY, Ian" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-3281update-01.txt 
In-Reply-To: <[e-mail] stems.com>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
I agree.&nbsp; However, I'd like to find out what document (or early
draft of a document) the existing OID was taken from.&nbsp; Basically, we
need to provide implementor guidance about both OIDs.<br><br>
Russ<br><br>
At 06:59 PM 10/27/2008, BRUMBY, Ian wrote:<br>
<blockquote type=cite class=cite cite=""><font size=2 color="#000080">
Since the over-the-wire encoding has been changed to be compatible with
X.501, and incompatible with RFC 3281, shouldn’t the OID of the attribute
be changed to match X.501?<br>
&nbsp;<br>
&nbsp;<br>
<hr>
<div align="center"></font></div>
<font face="Tahoma" size=2><b>From:</b> [e-mail]
[<a href="mailto:[e-mail]" eudora="autourl">
mailto:[e-mail]</a>] <b>On Behalf Of </b>Russ
Housley<br>
<b>Sent:</b> Tuesday, 28 October 2008 12:13 AM<br>
<b>To:</b> BRUMBY, Ian; [e-mail]<br>
<b>Subject:</b> RE: Rationales for CA clearance constraints<br>
</font><font face="Times New Roman, Times">&nbsp;<br>
This fact has been reported in an RFC Errata:<br><br>
Note that clearance was NOT defined in X.501(1993), but X.500(1997).
However, X.501(2005) may be the best reference for clearance.<br><br>
<br>
At 08:13 PM 10/26/2008, BRUMBY, Ian wrote:<br><br>
</font><font face="Times New Roman, Times" size=2 color="#000080">The
Clearance attribute is defined in the current X.501 (2001 and v6 draft)
with an OID of 2.5.4.55. RFC 3281 (as referenced by
draft-turner-caclearanceconstraints-01.txt) defines it as 2.5.1.5.55. It
refers to X.501-1993 as the source of this definition. I’ve dug up the
1993 standard and can’t find any reference to Clearance. If Clearance
Constraints are implemented, maybe it should be clarified if it
constrains X.501 (2003) Clearance attributes, if they are present in the
certificate, or specifically doesn’t constrain them.</font> <br><br>
<pre>&quot;Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.&nbsp; If you have received this
email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.&nbsp; It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer.&quot;

</pre><font face="Courier New, Courier"></font></blockquote></body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SETooW068949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 07:29:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SETokx068948; Tue, 28 Oct 2008 07:29:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SETbfg068900 for <[e-mail]>; Tue, 28 Oct 2008 07:29:48 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA29678 for <[e-mail]>; Tue, 28 Oct 2008 15:42:17 +0100
Received: from FRMYA-SIA24 ([129.182.109.126]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008102815293162:200636 ; Tue, 28 Oct 2008 15:29:31 +0100 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: RE: Rationales for CA clearance constraints
Date: Tue, 28 Oct 2008 15:29:30 +0100
Message-Id: <[e-mail]>
References: <[e-mail]> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail]> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 28/10/2008 15:29:31, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 28/10/2008 15:29:36, Serialize complete at 28/10/2008 15:29:36
Content-Type: multipart/alternative;  boundary="----=_NextPart_08102815293050564830721_002"
Sender: [e-mail]
Precedence: 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_08102815293050564830721_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

Debate about PKC is misleading since the I-D covers the clearances in
both PKC and AC. PKC is included for broader applicability.

[Denis] If the logic only applies to ACs, then it is sufficient to apply the constraints to AAs,
which means only to the AA that issues clearances. Then the topic is no more about path processing.
The big advantage is that path processing is unchanged. If clearances are supported by the RP 
then the RP shall look only look at the clearance constraints (if any) included in the certificate issued to the AA.

Looking for "broader applicability" creates problems, the first one behing that it is a bad practice 
to place clearances on PKCs. Not everybody needs to know that someone is cleared to TOP SECRET 
for some categories.

I would have no problem supporting a NWI about clearance constraints, if the scope is limited to AAs.

If the logic listed below is applies, we do not need any of the
constraints in the current 5280. You may need to provide granular
clearance authorities to the CAs.

In addition, in cross certified environments, the Enterprise CAs in
Enterprise "A" may be authorized for all clearances, but other
Enterprises "B" and "C" may want to trust "A" for different clearances
depending on business relationship. CA Clearance Constraints assist
with that.

[Denis] I am not sure to get the point. I fear that the argumentation above is in favor 
of applying constraints by the RP directly through the use of validation policies rather than by CAs.
One RP can place some clearance constraints on an AA while another may have different ones. 
In such a model, clearances constraints are not set by ACs anymore, but by RPs through 
different validation policies.

In summary constraints in CAs let different CAs authorize a CA for
different privileges. Constraints allow the relying parties to enforce
these constraints based on the assertions made by their trust anchor.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Timothy J. Miller
Sent: Tuesday, October 28, 2008 9:05 AM
To: Stephen Kent
Cc: Stefan Santesson; [e-mail]
Subject: Re: Rationales for CA clearance constraints

Stephen Kent wrote:

> The constraints mechanism is needed so that one issue a cert to a CA
and 
> constraint the range of clearance extensions that are acceptable under

> that CA. This is analogous to the use of name constraints in cross
certs.

I guess I'm just not getting it. I get (though I don't agree with) the 
desire to stuff clearance into PKCs, and I agree with providing that 
mechanism since not everyone sees the division the same way I do.

However, if I have, frex, a CA running at sensitivity level SECRET 
*issuing* PKCs asserting TOPSECRET, I'm thinking I have bigger problems 
with my PKI than just whether clients will catch this via clearance 
constraints. Similarly with categories/compartments--is it realistic to

expect a PKI to be partitioned *by CA* so finely that one CA issues 
TOPSECRET compartments A and B, and another only in compartment C?

-- Tim

------=_NextPart_08102815293050564830721_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 8pt; FONT-FAMILY: Tahoma" bgColor=#ffffff leftMargin=5 
topMargin=5>
<DIV>Debate about PKC is misleading since the I-D covers the clearances 
in<BR>both PKC and AC. PKC is included for broader applicability.</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#000080 size=2>[Denis] If the logic only applies to ACs, then 
it is sufficient to apply the constraints to AAs,<BR>which means only to the AA 
that issues&nbsp;clearances. Then the topic is no more about&nbsp;path 
processing.</FONT></DIV>
<DIV><FONT color=#000080 size=2>The big advantage is that path processing is 
unchanged. </FONT><FONT color=#000080 size=2>If clearances are supported by the 
RP <BR>then the RP&nbsp;shall look only look at the clearance constraints (if 
any)&nbsp;included in the certificate issued to the&nbsp;AA.</FONT></DIV>
<DIV><FONT color=#000080 size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#000080 size=2>Looking for "broader applicability" creates 
problems, the first one behing that it is a bad practice <BR>to place clearances 
on PKCs. Not everybody needs to know that someone is cleared to TOP SECRET 
<BR>for some categories.</FONT></DIV>
<DIV><FONT color=#000080 size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#000080><FONT size=2>I would have no problem supporting a NWI 
about clearance constraints, if the scope is limited to AAs</FONT>.</FONT></DIV>
<DIV><BR>If the logic listed below is applies, we do not need any of 
the<BR>constraints in the current 5280. You may need to provide 
granular<BR>clearance authorities to the CAs.<BR><BR>In addition, in cross 
certified environments, the Enterprise CAs in<BR>Enterprise "A" may be 
authorized for all clearances, but other<BR>Enterprises "B" and "C" may want to 
trust "A" for different clearances<BR>depending on business relationship. CA 
Clearance Constraints assist<BR>with that.</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#000080 size=2>[Denis] I am not sure to get the point. I fear 
that the argumentation above is in favor <BR>of applying constraints by the RP 
directly through the use of&nbsp;validation policies rather than by 
CAs.</FONT></DIV>
<DIV><FONT color=#000080 size=2>One RP can place some clearance constraints on 
an AA while another may have different ones. <BR>In such a model, clearances 
constraints are not set by ACs anymore, but by RPs through <BR>different 
validation policies.</FONT></DIV>
<DIV><BR>In summary constraints in CAs let different CAs authorize a CA 
for<BR>different privileges. Constraints allow the relying parties to 
enforce<BR>these constraints based on the assertions made by their trust 
anchor.<BR><BR>-----Original Message-----<BR>From: <A 
href="mailto: [e-mail]">[e-mail]</A> 
[mailto:<A 
href="mailto: [e-mail]">[e-mail]</A>]<BR>On 
Behalf Of Timothy J. Miller<BR>Sent: Tuesday, October 28, 2008 9:05 AM<BR>To: 
Stephen Kent<BR>Cc: Stefan Santesson; <A 
href="mailto: [e-mail]">[e-mail]</A><BR>Subject: Re: 
Rationales for CA clearance constraints<BR><BR>Stephen Kent wrote:<BR><BR>&gt; 
The constraints mechanism is needed so that one issue a cert to a CA<BR>and 
<BR>&gt; constraint the range of clearance extensions that are acceptable 
under<BR><BR>&gt; that CA. This is analogous to the use of name constraints in 
cross<BR>certs.<BR><BR>I guess I'm just not getting it. I get (though I don't 
agree with) the <BR>desire to stuff clearance into PKCs, and I agree with 
providing that <BR>mechanism since not everyone sees the division the same way I 
do.<BR><BR>However, if I have, frex, a CA running at sensitivity level SECRET 
<BR>*issuing* PKCs asserting TOPSECRET, I'm thinking I have bigger problems 
<BR>with my PKI than just whether clients will catch this via clearance 
<BR>constraints. Similarly with categories/compartments--is it realistic 
to<BR><BR>expect a PKI to be partitioned *by CA* so finely that one CA issues 
<BR>TOPSECRET compartments A and B, and another only in compartment C?<BR><BR>-- 
Tim<BR><BR><BR></DIV></BODY></HTML>

------=_NextPart_08102815293050564830721_002--






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SDqECX059157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 06:52:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SDqEJN059155; Tue, 28 Oct 2008 06:52:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9SDqDkW059147 for <[e-mail]>; Tue, 28 Oct 2008 06:52:13 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 21498 invoked from network); 28 Oct 2008 13:38:32 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;28 Oct 2008 13:38:32 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 28 Oct 2008 13:38:32 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Rationales for CA clearance constraints
Date: Tue, 28 Oct 2008 09:52:12 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack5APRSifeJ4OdsTT+QojGB33vfHAAAh8qg
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]> <[e-mail]>
From: "Santosh Chokhani" <[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>

Debate about PKC is misleading since the I-D covers the clearances in
both PKC and AC.  PKC is included for broader applicability.

If the logic listed below is applies, we do not need any of the
constraints in the current 5280.  You may need to provide granular
clearance authorities to the CAs.

In addition, in cross certified environments, the Enterprise CAs in
Enterprise "A" may be authorized for all clearances, but other
Enterprises "B" and "C" may want to trust "A" for different clearances
depending on business relationship.  CA Clearance Constraints assist
with that.

In summary constraints in CAs let different CAs authorize a CA for
different privileges.  Constraints allow the relying parties to enforce
these constraints based on the assertions made by their trust anchor.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Timothy J. Miller
Sent: Tuesday, October 28, 2008 9:05 AM
To: Stephen Kent
Cc: Stefan Santesson; [e-mail]
Subject: Re: Rationales for CA clearance constraints

Stephen Kent wrote:

> The constraints mechanism is needed so that one issue a cert to a CA
and=20
> constraint the range of clearance extensions that are acceptable under

> that CA.  This is analogous to the use of name constraints in cross
certs.

I guess I'm just not getting it.  I get (though I don't agree with) the=20
desire to stuff clearance into PKCs, and I agree with providing that=20
mechanism since not everyone sees the division the same way I do.

However, if I have, frex, a CA running at sensitivity level SECRET=20
*issuing* PKCs asserting TOPSECRET, I'm thinking I have bigger problems=20
with my PKI than just whether clients will catch this via clearance=20
constraints.  Similarly with categories/compartments--is it realistic to

expect a PKI to be partitioned *by CA* so finely that one CA issues=20
TOPSECRET compartments A and B, and another only in compartment C?

-- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SDk1fX057926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 06:46:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SDk1E4057925; Tue, 28 Oct 2008 06:46:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9SDjxwm057909 for <[e-mail]>; Tue, 28 Oct 2008 06:46:00 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 21436 invoked from network); 28 Oct 2008 13:32:19 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;28 Oct 2008 13:32:19 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 28 Oct 2008 13:32:19 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Rationales for CA clearance constraints
Date: Tue, 28 Oct 2008 09:45:59 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack5APTa71xwkaPmSLO9bpCT596NkQAAb7Qg
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]> <[e-mail]>
From: "Santosh Chokhani" <[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>

If a relying party does not know the semantics of OID asserted in the
TYPE field of a security category, it will not be doing access control
on an object asserting the same and hence can ignore that security
category.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Timothy J. Miller
Sent: Tuesday, October 28, 2008 9:12 AM
To: Stephen Kent
Cc: Yoav Nir; Paul Hoffman; [e-mail]
Subject: Re: Rationales for CA clearance constraints

Stephen Kent wrote:

> if this extension is marked critical, then an RP that does not=20
> understand it will declare the cert invalid, which is the desired=20
> outcome. =20

Ah, but what about a RP that understands the extension but *not* the=20
intersection logic of the policy?  Accept or reject?  If accept, how do=20
we know the constraint was applied correctly?

-- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SDK1nP052523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 06:20:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SDK1VA052522; Tue, 28 Oct 2008 06:20:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SDJxvC052505 for <[e-mail]>; Tue, 28 Oct 2008 06:20:00 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9SDJwnc007156 for <[e-mail]>; Tue, 28 Oct 2008 09:19:59 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9SDJw7E007152; Tue, 28 Oct 2008 09:19:58 -0400
Received: from [129.83.200.4] (129.83.200.4) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 28 Oct 2008 09:19:58 -0400
Message-ID: <[e-mail]>
Date: Tue, 28 Oct 2008 08:19:55 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Yoav Nir <[e-mail]>
CC: "BRUMBY, Ian" <[e-mail]>, [e-mail]
Subject: Re: Rationales for CA clearance constraints
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010705020805090505020507"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms010705020805090505020507
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Yoav Nir wrote:

> I have no idea what's the harm in telling Amazon, gmail or the Russian 
> Mafia that you have top secret clearance, but it sounds bad.

This is a wonderfully muddy area with no strict rules, up to a point, in 
the US.  In the end, it depends on who you're telling; you wouldn't put 
your clearance on an application to Domino's Pizza, but you would on an 
application to Lockheed-Martin--provided the application was for a gov't 
contract position.

The "up to a point" is that this rule of thumb applies generally only to 
sensitivity levels up to TS/SCI, but explicitly *not* to cleared 
compartments.  Compartment membership is usually sensitive information 
itself.

-- Tim



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjgxMzE5NTVaMCMGCSqGSIb3DQEJBDEWBBRdLC373t1J2BEk/LKRKNqATdLIrzBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgJGHK7tLh/zOdAi1QD/RGck6iC+dJe0tKhjLHk3ut4VMCuPvE+cQ70lqYixm
v6qGVHSEKVxel7BqNxCsidqYa9wbBOsUf6rLADFfd/7GD8TWvUECJTIQhuBUzPjGvg2Ytpmq
BGXEJe16Er/Hh/Eu3YHBGSZu5Lh772BghAUuoCcfAAAAAAAA
--------------ms010705020805090505020507--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SDBbwK050803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 06:11:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SDBbMm050801; Tue, 28 Oct 2008 06:11:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SDBaA2050790 for <[e-mail]>; Tue, 28 Oct 2008 06:11:36 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9SDBZxd014006 for <[e-mail]>; Tue, 28 Oct 2008 09:11:35 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9SDBYec013993; Tue, 28 Oct 2008 09:11:34 -0400
Received: from [129.83.200.4] (129.83.200.4) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 28 Oct 2008 09:11:34 -0400
Message-ID: <[e-mail]>
Date: Tue, 28 Oct 2008 08:11:30 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Yoav Nir <[e-mail]>, Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: Rationales for CA clearance constraints
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]> <p06240512c52c94298261@[193.0.24.250]>
In-Reply-To: <p06240512c52c94298261@[193.0.24.250]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080601000307020705040007"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms080601000307020705040007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> if this extension is marked critical, then an RP that does not 
> understand it will declare the cert invalid, which is the desired 
> outcome.  

Ah, but what about a RP that understands the extension but *not* the 
intersection logic of the policy?  Accept or reject?  If accept, how do 
we know the constraint was applied correctly?

-- Tim


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjgxMzExMzBaMCMGCSqGSIb3DQEJBDEWBBTfEqnD47Na7+BsrdmUrotN7A5ZbzBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgCrNLzi4VgltnpgTEy0GtQ64hq6ZtoUk0Us6i7HQB75LzSZmcRWTkUFY8H4P
+a+BJeltirTwM3ztvWNrPzQ3HcUZr7PoF3JNAEEzcDzYpyhWr/h0hyYo6X4vXOxyOdg8K2dm
J5+MWOsl8zrhNzf+PjRrGnUrT8r1j/iNexjosvP3AAAAAAAA
--------------ms080601000307020705040007--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SD5VfR049601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 06:05:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SD5VAB049600; Tue, 28 Oct 2008 06:05:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SD5JxC049561 for <[e-mail]>; Tue, 28 Oct 2008 06:05:30 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9SD5It1027063 for <[e-mail]>; Tue, 28 Oct 2008 09:05:19 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9SD5IiN027055; Tue, 28 Oct 2008 09:05:18 -0400
Received: from [129.83.200.4] (129.83.200.4) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 28 Oct 2008 09:05:18 -0400
Message-ID: <[e-mail]>
Date: Tue, 28 Oct 2008 08:05:14 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Stefan Santesson <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]>
In-Reply-To: <p06240506c52c4db21d94@[193.0.24.250]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080601020203010500010708"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms080601020203010500010708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stephen Kent wrote:

> The constraints mechanism is needed so that one issue a cert to a CA and 
> constraint the range of clearance extensions that are acceptable under 
> that CA.  This is analogous to the use of name constraints in cross certs.

I guess I'm just not getting it.  I get (though I don't agree with) the 
desire to stuff clearance into PKCs, and I agree with providing that 
mechanism since not everyone sees the division the same way I do.

However, if I have, frex, a CA running at sensitivity level SECRET 
*issuing* PKCs asserting TOPSECRET, I'm thinking I have bigger problems 
with my PKI than just whether clients will catch this via clearance 
constraints.  Similarly with categories/compartments--is it realistic to 
expect a PKI to be partitioned *by CA* so finely that one CA issues 
TOPSECRET compartments A and B, and another only in compartment C?

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjgxMzA1MTRaMCMGCSqGSIb3DQEJBDEWBBRPFQsxcPv3VRblTfyAY4uvIhRMJjBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgDxECv1+rEWrhQ+PtXtOXZhCibd4pTKug84pDSZ2qItXeFIYDbnKGPApXnDe
Kuz1ZeJ3WMlmp4ujCovXOXSWIoY4AcdnPMZSra0j0si8ucQabGTcxYc2VB7Tw2IdyAanGDDD
qymBqGtZtfoG8HSALgcK9MpxT1xVwx95VK7iG4aeAAAAAAAA
--------------ms080601020203010500010708--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SC7C7N038287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 05:07:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SC7Cpq038286; Tue, 28 Oct 2008 05:07:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9SC71tl038239 for <[e-mail]>; Tue, 28 Oct 2008 05:07:11 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 20709 invoked from network); 28 Oct 2008 11:53:03 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;28 Oct 2008 11:53:03 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 28 Oct 2008 11:53:03 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Rationales for CA clearance constraints
Date: Tue, 28 Oct 2008 08:06:43 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack41T5GWbbvBNe4SDa60zgrlnoSxQAIFXxg
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Yoav Nir" <[e-mail]>, "Paul Hoffman" <[e-mail]>
Cc: <[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>

The constraint can be made optionally critical for those relying parties
who do not worry about clearance.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Yoav Nir
Sent: Tuesday, October 28, 2008 3:59 AM
To: Paul Hoffman
Cc: [e-mail]
Subject: Re: Rationales for CA clearance constraints


On Oct 28, 2008, at 4:34 AM, Paul Hoffman wrote:
>
> At 12:17 AM +0000 10/28/08, Stefan Santesson wrote:
>> It's great to see a list of entities with a certain interest in =20
>> this. Nobody but them can decide whether their need is legitimate. =20
>> Only we can decide whether this should be standardized.
>> So I guess my question is more on that why a standard, rather than =20
>> if it is legitimate. Many organizations have defined private =20
>> extensions. For Banking specific needs you can create a banking =20
>> standard and for l military use I assume you can create a military =20
>> standard. So if there is no commercial application. Does a standard =20
>> still serve the community at large?
>
> I am very uncomfortable with this logic. The IETF has a long history =20
> of extending their standards for one particular group who is =20
> interested in interoperability without forcing the group to prove =20
> that there is a "commercial application". Having a WG chair try to =20
> chase off a community because he doesn't think their need is =20
> "legitimate" is a significant divergence from the way the IETF has =20
> done things to date.

The problem is not with the mere existence of an extension. For =20
example, a relying party with no use for the MPEG-of-cat extension can =20
simply ignore its existence in a certificate.

This extension, however, constrains the processing of a certificate =20
chain. A non-military relying party with no interest in clearances =20
(such as a web server) may be presented with a certificate chain that =20
contains the clearance extension. Such a chain may be invalid because =20
of constraints (maybe the CA can only sign for "SECRET" but in fact it =20
has signed for "TOP SECRET"), but an RP which ignores the clearance =20
extension may treat this chain as valid.

I'm not sure if that's a bad thing. If my security policy is to give =20
anyone some information regardless of their clearance level, that I =20
don't care that their CA violates the clearance level standard. OTOH =20
accepting as valid a chain that is invalid can be considered a =20
security problem.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SC3IO6037523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 05:03:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SC3IPa037522; Tue, 28 Oct 2008 05:03:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SC35p2037471 for <[e-mail]>; Tue, 28 Oct 2008 05:03:16 -0700 (MST) (envelope-from [e-mail])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C6AF529C001; Tue, 28 Oct 2008 14:02:59 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 446EE294003; Tue, 28 Oct 2008 14:02:58 +0200 (IST)
Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9SC2vQC019002; Tue, 28 Oct 2008 14:02:57 +0200 (IST)
Cc: <[e-mail]>
Message-Id: <[e-mail]>
From: Yoav Nir <[e-mail]>
To: "BRUMBY, Ian" <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/alternative; boundary=Apple-Mail-1--72442016
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Rationales for CA clearance constraints
Date: Tue, 28 Oct 2008 14:02:57 +0200
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Apple-Mail-1--72442016
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

On Oct 27, 2008, at 2:13 AM, BRUMBY, Ian wrote:

> My comments on the topic:
>
> The Clearance attribute is defined in the current X.501 (2001 and v6 =20=

> draft) with an OID of 2.5.4.55. RFC 3281 (as referenced by draft-=20
> turner-caclearanceconstraints-01.txt) defines it as 2.5.1.5.55. It =20
> refers to X.501-1993 as the source of this definition. I=92ve dug up =20=

> the 1993 standard and can=92t find any reference to Clearance. If =20
> Clearance Constraints are implemented, maybe it should be clarified =20=

> if it constrains X.501 (2003) Clearance attributes, if they are =20
> present in the certificate, or specifically doesn=92t constrain them.
>
> With regards as to whether Clearance should be held in the =20
> Certificate or the Directory:
> I=92ve heard concern that it shouldn=92t be held in either. In a =20
> Prisoner of War scenario it potentially identifies the people with =20
> the potential to have the most knowledge.
> FYI =96 at least one Directory vendor is using the Clearance attribute =
=20
> on the Certificate that is used to bind to the Directory to control =20=

> access to the Directory.
>
> Ian Brumby
> BAE Systems

On recent discussion on the TLS mailing list, someone said that =20
browsers will silently send a certificate if prompted to by HTTPS web =20=

servers. So your comment 2a has broader application.

It's not just Iraqi insurgents capturing a US or British soldier and =20
checking his or her certificate (terrorists as relying parties), but =20
if a DoD employee uses their work computer to surf to, say, Amazon or =20=

gmail, their name, rank and clearance levels leak to that party.

I have no idea what's the harm in telling Amazon, gmail or the Russian =20=

Mafia that you have top secret clearance, but it sounds bad.


--Apple-Mail-1--72442016
Content-Type: text/html;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div><div>On Oct 27, 2008, at =
2:13 AM, BRUMBY, Ian wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Arial; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><div lang=3D"EN-AU" link=3D"blue" =
vlink=3D"#606420" style=3D"word-wrap: break-word; -webkit-nbsp-mode: =
space; -webkit-line-break: after-white-space; "><div =
class=3D"Section1"><div style=3D"margin-top: 0cm; margin-right: 0cm; =
margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; font-family: =
'Times New Roman'; "><font size=3D"2" color=3D"navy" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: navy; ">My comments =
on the topic:<o:p></o:p></span></font></div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"2" =
color=3D"navy" face=3D"Arial"><span style=3D"font-size: 10pt; =
font-family: Arial; color: navy; =
"><o:p>&nbsp;</o:p></span></font></div><ol start=3D"1" type=3D"1" =
style=3D"margin-top: 0cm; margin-bottom: 0cm; "><li class=3D"MsoNormal" =
style=3D"color: navy; margin-top: 0cm; margin-right: 0cm; margin-left: =
0cm; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"navy" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; ">The Clearance attribute =
is defined in the current X.501 (2001 and v6 draft) with an OID of =
2.5.4.55. RFC 3281 (as referenced by =
draft-turner-caclearanceconstraints-01.txt) defines it as 2.5.1.5.55. It =
refers to X.501-1993 as the source of this definition. I=92ve dug up the =
1993 standard and can=92t find any reference to Clearance. If Clearance =
Constraints are implemented, maybe it should be clarified if it =
constrains X.501 (2003) Clearance attributes, if they are present in the =
certificate, or specifically doesn=92t constrain =
them.<o:p></o:p></span></font></li></ol><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><font size=3D"2" color=3D"navy" =
face=3D"Arial"><span style=3D"font-size: 10pt; font-family: Arial; =
color: navy; "><o:p>&nbsp;</o:p></span></font></div><ol start=3D"2" =
type=3D"1" style=3D"margin-top: 0cm; margin-bottom: 0cm; "><li =
class=3D"MsoNormal" style=3D"color: navy; margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman'; "><font size=3D"2" color=3D"navy" =
face=3D"Arial"><span style=3D"font-size: 10pt; font-family: Arial; =
">With regards as to whether Clearance should be held in the Certificate =
or the Directory:<o:p></o:p></span></font></li></ol><ol start=3D"1" =
type=3D"1" style=3D"margin-top: 0cm; margin-bottom: 0cm; "><ol start=3D"1"=
 type=3D"a" style=3D"margin-top: 0cm; margin-bottom: 0cm; "><li =
class=3D"MsoNormal" style=3D"color: navy; margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman'; "><font size=3D"2" color=3D"navy" =
face=3D"Arial"><span style=3D"font-size: 10pt; font-family: Arial; =
">I=92ve heard concern that it shouldn=92t be held in either. In a =
Prisoner of War scenario it potentially identifies the people with the =
potential to have the most knowledge.<o:p></o:p></span></font></li><li =
class=3D"MsoNormal" style=3D"color: navy; margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman'; "><font size=3D"2" color=3D"navy" =
face=3D"Arial"><span style=3D"font-size: 10pt; font-family: Arial; ">FYI =
=96 at least one Directory vendor is using the Clearance attribute on =
the Certificate that is used to bind to the Directory to control access =
to the Directory.<o:p></o:p></span></font></li></ol></ol><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"navy" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: navy; =
"><o:p>&nbsp;</o:p></span></font></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><font size=3D"2" color=3D"navy" =
face=3D"Arial"><span style=3D"font-size: 10pt; font-family: Arial; =
color: navy; ">Ian Brumby<o:p></o:p></span></font></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"navy" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: navy; ">BAE =
Systems<o:p></o:p></span></font></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; =
"></div></div></div></span></blockquote></div><br><div>On recent =
discussion on the TLS mailing list, someone said that browsers will =
silently send a certificate if prompted to by HTTPS web servers. So your =
comment 2a has broader application.</div><div><br></div><div>It's not =
just Iraqi insurgents capturing a US or British soldier and checking his =
or her certificate (terrorists as relying parties), but if a DoD =
employee uses their work computer to surf to, say, Amazon or gmail, =
their name, rank and clearance levels leak to that =
party.&nbsp;</div><div><br></div><div>I have no idea what's the harm in =
telling Amazon, gmail or the Russian Mafia that you have top secret =
clearance, but it sounds bad.</div><div><br></div></body></html>=

--Apple-Mail-1--72442016--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SAU2Kf019009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 03:30:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9SAU2fO019008; Tue, 28 Oct 2008 03:30:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9SATrgW018957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 03:30:01 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.24.250]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Kulpc-0004yA-CI; Tue, 28 Oct 2008 06:29:49 -0400
Mime-Version: 1.0
Message-Id: <p06240512c52c94298261@[193.0.24.250]>
In-Reply-To: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]> <[e-mail]>
Date: Tue, 28 Oct 2008 06:30:52 -0400
To: Yoav Nir <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:58 AM +0200 10/28/08, Yoav Nir wrote:
>On Oct 28, 2008, at 4:34 AM, Paul Hoffman wrote:
>>
>>At 12:17 AM +0000 10/28/08, Stefan Santesson wrote:
>>>It's great to see a list of entities with a certain interest in 
>>>this. Nobody but them can decide whether their need is legitimate. 
>>>Only we can decide whether this should be standardized.
>>>So I guess my question is more on that why a standard, rather than 
>>>if it is legitimate. Many organizations have defined private 
>>>extensions. For Banking specific needs you can create a banking 
>>>standard and for l military use I assume you can create a military 
>>>standard. So if there is no commercial application. Does a 
>>>standard still serve the community at large?
>>
>>I am very uncomfortable with this logic. The IETF has a long 
>>history of extending their standards for one particular group who 
>>is interested in interoperability without forcing the group to 
>>prove that there is a "commercial application". Having a WG chair 
>>try to chase off a community because he doesn't think their need is 
>>"legitimate" is a significant divergence from the way the IETF has 
>>done things to date.
>
>The problem is not with the mere existence of an extension. For 
>example, a relying party with no use for the MPEG-of-cat extension 
>can simply ignore its existence in a certificate.
>
>This extension, however, constrains the processing of a certificate 
>chain. A non-military relying party with no interest in clearances 
>(such as a web server) may be presented with a certificate chain 
>that contains the clearance extension. Such a chain may be invalid 
>because of constraints (maybe the CA can only sign for "SECRET" but 
>in fact it has signed for "TOP SECRET"), but an RP which ignores the 
>clearance extension may treat this chain as valid.
>
>I'm not sure if that's a bad thing. If my security policy is to give 
>anyone some information regardless of their clearance level, that I 
>don't care that their CA violates the clearance level standard. OTOH 
>accepting as valid a chain that is invalid can be considered a 
>security problem.

if this extension is marked critical, then an RP that does not 
understand it will declare the cert invalid, which is the desired 
outcome.  If the extension is not critical, the RP can safely ignore 
it if it doesn't understand it. I realize that the document allows 
critical or non-critical marking, but given the security nature of 
this extension, I'd suggest making it critical.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S9I63x004576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 02:18:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9S9I6HD004575; Tue, 28 Oct 2008 02:18:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S9I4MC004552 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 02:18:05 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 28 Oct 2008 09:18:03 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Tue, 28 Oct 2008 09:18:04 +0000
From: Stefan Santesson <[e-mail]>
To: Paul Hoffman <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Tue, 28 Oct 2008 09:18:01 +0000
Subject: RE: Rationales for CA clearance constraints
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack4qpwh98DeX+O3SEKJk9xyZ2mWPwAMqcSg
Message-ID: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]>
In-Reply-To: <p0624081ac52c289bcda0@[10.20.30.152]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul

> Having a WG chair try to chase off a
> community because he doesn't think their need is "legitimate" is a
> significant divergence from the way the IETF has done things to date.

I would certainly agree.

I'm having a fruitful discussion and I see many valid points coming across.
I'm certainly not going to chase this WG item off if the WG wants to work o=
n it.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Paul Hoffman
> Sent: den 28 oktober 2008 03:35
> To: [e-mail]
> Subject: RE: Rationales for CA clearance constraints
>
>
> At 12:17 AM +0000 10/28/08, Stefan Santesson wrote:
> >It's great to see a list of entities with a certain interest in this.
> Nobody but them can decide whether their need is legitimate. Only we
> can decide whether this should be standardized.
> >So I guess my question is more on that why a standard, rather than if
> it is legitimate. Many organizations have defined private extensions.
> For Banking specific needs you can create a banking standard and for l
> military use I assume you can create a military standard. So if there
> is no commercial application. Does a standard still serve the community
> at large?
>
> I am very uncomfortable with this logic. The IETF has a long history of
> extending their standards for one particular group who is interested in
> interoperability without forcing the group to prove that there is a
> "commercial application". Having a WG chair try to chase off a
> community because he doesn't think their need is "legitimate" is a
> significant divergence from the way the IETF has done things to date.
>
> --Paul Hoffman, Director
> --VPN Consortium
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S99eSv002767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 02:09:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9S99elo002766; Tue, 28 Oct 2008 02:09:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S99S8l002713 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 02:09:39 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 28 Oct 2008 09:09:27 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 28 Oct 2008 09:09:27 +0000
From: Stefan Santesson <[e-mail]>
To: Stephen Kent <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Tue, 28 Oct 2008 09:09:26 +0000
Subject: RE: Rationales for CA clearance constraints
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack4vGm2UNmhSGLXRRel/gzdkKkBRwAGSbiA
Message-ID: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p06240506c52c4db21d94@[193.0.24.250]>
In-Reply-To: <p06240506c52c4db21d94@[193.0.24.250]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Let me recap:

1) Practical use of PKI, primary in defense/military applications has resul=
ted in a need to include clearance information in certificates.

2) These applications require clearance constraints processing

3) Clearance is defined within a context. An infinite combination of contex=
t and clearance levels may exist.

4) The constraints mechanism calculates the effective clearance of an End E=
ntity (EE). The effective clearance for the EE is the intersection of all c=
learances of the path.

5) Calculation of effective clearance is dependent on the definition of cle=
arance levels (classList) and context (securityCategories and policyId), an=
d has no default deterministic logic.


This differs IMO from anything else we have defined in the past in one impo=
rtant way. No prior path validation mechanism that we have defined previous=
ly (that I can think of) requires you to calculate an intersection of value=
s without providing you with the logic for calculating that intersection.

- For policy constraints, I can calculate intersection of valid policies wi=
thout knowing the meaning of each policy.
- Name constraints are only valid for hierarchical name forms and each name=
 form defines the "intersection" logic for matching constraints


This may seem like a small thing, but I'm not sure it is. If we define stan=
dards that require us to calculate a certain value X without defining the l=
ogic for calculating X, then I fear that we may create serious interoperabi=
lity problems and set precedence for bad protocol design. Or am I just seei=
ng ghosts?




Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: den 28 oktober 2008 06:10
> To: Stefan Santesson
> Cc: [e-mail]
> Subject: RE: Rationales for CA clearance constraints
>
> At 12:17 AM +0000 10/28/08, Stefan Santesson wrote:
> >Stephen, Thanks for a great and elaborate reply.
> >
> >It's great to see a list of entities with a certain interest in
> >this. Nobody but them can decide whether their need is legitimate.
> >Only we can decide whether this should be standardized.
> >So I guess my question is more on that why a standard, rather than
> >if it is legitimate. Many organizations have defined private
> >extensions. For Banking specific needs you can create a banking
> >standard and for l military use I assume you can create a military
> >standard. So if there is no commercial application. Does a standard
> >still serve the community at large?
>
> The IETF has adopted standards that serve communities such as this in
> the past, c.f., RFC 1108.
>
> >Also, you don't tell me why we need constraints, only that it is
> >very close to our old ANY DEFINED BY. However, the way the undefined
> >logic here affects path processing is unprecedented. Yes, we have
> >ANY DEFINED BY in algorithm data, but we don't have constraints
> >mechanism logic being altered dependent on algorithm.
> >
>
> The constraints mechanism is needed so that one issue a cert to a CA
> and constraint the range of clearance extensions that are acceptable
> under that CA.  This is analogous to the use of name constraints in
> cross certs.
>
> I cited the ANY DEFINED BY construct as an example of why the
> syntactic challenges you cited are analogous to things we have dealt
> with before.
>
> Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S7x0xv089710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 00:59:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9S7x0GR089709; Tue, 28 Oct 2008 00:59:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S7wmMY089662 for <[e-mail]>; Tue, 28 Oct 2008 00:58:59 -0700 (MST) (envelope-from [e-mail])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0E04729C001; Tue, 28 Oct 2008 09:58:38 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 36FA4294005; Tue, 28 Oct 2008 09:58:37 +0200 (IST)
Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9S7waQC006639; Tue, 28 Oct 2008 09:58:36 +0200 (IST)
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Yoav Nir <[e-mail]>
To: Paul Hoffman <[e-mail]>
In-Reply-To: <p0624081ac52c289bcda0@[10.20.30.152]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Rationales for CA clearance constraints
Date: Tue, 28 Oct 2008 09:58:36 +0200
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com> <p0624081ac52c289bcda0@[10.20.30.152]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: 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 Oct 28, 2008, at 4:34 AM, Paul Hoffman wrote:
>
> At 12:17 AM +0000 10/28/08, Stefan Santesson wrote:
>> It's great to see a list of entities with a certain interest in  
>> this. Nobody but them can decide whether their need is legitimate.  
>> Only we can decide whether this should be standardized.
>> So I guess my question is more on that why a standard, rather than  
>> if it is legitimate. Many organizations have defined private  
>> extensions. For Banking specific needs you can create a banking  
>> standard and for l military use I assume you can create a military  
>> standard. So if there is no commercial application. Does a standard  
>> still serve the community at large?
>
> I am very uncomfortable with this logic. The IETF has a long history  
> of extending their standards for one particular group who is  
> interested in interoperability without forcing the group to prove  
> that there is a "commercial application". Having a WG chair try to  
> chase off a community because he doesn't think their need is  
> "legitimate" is a significant divergence from the way the IETF has  
> done things to date.

The problem is not with the mere existence of an extension. For  
example, a relying party with no use for the MPEG-of-cat extension can  
simply ignore its existence in a certificate.

This extension, however, constrains the processing of a certificate  
chain. A non-military relying party with no interest in clearances  
(such as a web server) may be presented with a certificate chain that  
contains the clearance extension. Such a chain may be invalid because  
of constraints (maybe the CA can only sign for "SECRET" but in fact it  
has signed for "TOP SECRET"), but an RP which ignores the clearance  
extension may treat this chain as valid.

I'm not sure if that's a bad thing. If my security policy is to give  
anyone some information regardless of their clearance level, that I  
don't care that their CA violates the clearance level standard. OTOH  
accepting as valid a chain that is invalid can be considered a  
security problem.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S5H6P3060438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 22:17:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9S5H6EN060436; Mon, 27 Oct 2008 22:17:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S5GseJ060400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 27 Oct 2008 22:17:05 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.24.250]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Kugwk-0008RZ-CT; Tue, 28 Oct 2008 01:16:51 -0400
Mime-Version: 1.0
Message-Id: <p06240506c52c4db21d94@[193.0.24.250]>
In-Reply-To: <[e-mail] osoft.com>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com>
Date: Tue, 28 Oct 2008 01:09:55 -0400
To: Stefan Santesson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Rationales for CA clearance constraints
Cc: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:17 AM +0000 10/28/08, Stefan Santesson wrote:
>Stephen, Thanks for a great and elaborate reply.
>
>It's great to see a list of entities with a certain interest in 
>this. Nobody but them can decide whether their need is legitimate. 
>Only we can decide whether this should be standardized.
>So I guess my question is more on that why a standard, rather than 
>if it is legitimate. Many organizations have defined private 
>extensions. For Banking specific needs you can create a banking 
>standard and for l military use I assume you can create a military 
>standard. So if there is no commercial application. Does a standard 
>still serve the community at large?

The IETF has adopted standards that serve communities such as this in 
the past, c.f., RFC 1108.

>Also, you don't tell me why we need constraints, only that it is 
>very close to our old ANY DEFINED BY. However, the way the undefined 
>logic here affects path processing is unprecedented. Yes, we have 
>ANY DEFINED BY in algorithm data, but we don't have constraints 
>mechanism logic being altered dependent on algorithm.
>

The constraints mechanism is needed so that one issue a cert to a CA 
and constraint the range of clearance extensions that are acceptable 
under that CA.  This is analogous to the use of name constraints in 
cross certs.

I cited the ANY DEFINED BY construct as an example of why the 
syntactic challenges you cited are analogous to things we have dealt 
with before.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S2Ycx5031087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 19:34:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9S2YcvK031086; Mon, 27 Oct 2008 19:34:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S2YY0W031074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 27 Oct 2008 19:34:37 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624081ac52c289bcda0@[10.20.30.152]>
In-Reply-To: <[e-mail] osoft.com>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]> <[e-mail] osoft.com>
Date: Mon, 27 Oct 2008 19:34:33 -0700
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: RE: Rationales for CA clearance constraints
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:17 AM +0000 10/28/08, Stefan Santesson wrote:
>It's great to see a list of entities with a certain interest in this. Nobody but them can decide whether their need is legitimate. Only we can decide whether this should be standardized.
>So I guess my question is more on that why a standard, rather than if it is legitimate. Many organizations have defined private extensions. For Banking specific needs you can create a banking standard and for l military use I assume you can create a military standard. So if there is no commercial application. Does a standard still serve the community at large?

I am very uncomfortable with this logic. The IETF has a long history of extending their standards for one particular group who is interested in interoperability without forcing the group to prove that there is a "commercial application". Having a WG chair try to chase off a community because he doesn't think their need is "legitimate" is a significant divergence from the way the IETF has done things to date.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S0HPIa010502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 17:17:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9S0HP6r010501; Mon, 27 Oct 2008 17:17:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S0HDef010469 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 27 Oct 2008 17:17:24 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 28 Oct 2008 00:17:12 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 28 Oct 2008 00:17:12 +0000
From: Stefan Santesson <[e-mail]>
To: Stephen Kent <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Tue, 28 Oct 2008 00:17:11 +0000
Subject: RE: Rationales for CA clearance constraints
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack4VTLlx665NUXCSYecetblqJoeCAAOUJTA
Message-ID: <[e-mail]>
References: <[e-mail] osoft.com> <p06240500c52b6b1ec3cf@[10.242.22.83]>
In-Reply-To: <p06240500c52b6b1ec3cf@[10.242.22.83]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D32195AA90D46EAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Stephen, Thanks for a great and elaborate reply.

It's great to see a list of entities with a certain interest in this. Nobod=
y but them can decide whether their need is legitimate. Only we can decide =
whether this should be standardized.
So I guess my question is more on that why a standard, rather than if it is=
 legitimate. Many organizations have defined private extensions. For Bankin=
g specific needs you can create a banking standard and for l military use I=
 assume you can create a military standard. So if there is no commercial ap=
plication. Does a standard still serve the community at large?

Also, you don't tell me why we need constraints, only that it is very close=
 to our old ANY DEFINED BY. However, the way the undefined logic here affec=
ts path processing is unprecedented. Yes, we have ANY DEFINED BY in algorit=
hm data, but we don't have constraints mechanism logic being altered depend=
ent on algorithm.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: Stephen Kent [mailto:[e-mail]]
Sent: den 27 oktober 2008 14:35
To: Stefan Santesson
Cc: [e-mail]
Subject: Re: Rationales for CA clearance constraints

At 3:19 AM +0100 10/25/08, Stefan Santesson wrote:
The discussion on CA clearance constraints have made me wonder about some b=
asic rationales for writing this standard in the manner suggested.

It would be great if those advocating this solution could help me understan=
d better. I have 3 major questions:


1)      Why do this in certificates at all? It seems that most people are a=
greeing that certificates is not a good place to specify the clearance of a=
 subject. Are we suggesting this purely because some "important" organizati=
ons have decided to implement this anyway and would feel better about it if=
 it became a standard, or do we have anyone who want to speak up and explai=
n why this actually is a great idea?

By my count, "most people" is not an accurate characterization of the respo=
nses to this thread :-). Moreover, a non-trivial set of users have years of=
 experience embedding clearance/authorization info in certs, a fact that se=
ems to be overlook in this debate. Yes, one can try to put too much of this=
 sort of mandatory access control info info a cert and create a management =
problem. But, the same can be said for creating subject names that map so c=
losely to an org chart that every time someone is promoted or transfers, th=
e cert has to be revoked.  So, let's not allow concerns about how this migh=
t be done badly overshadow the fact that there are legitimate ways to make =
use of this data in certs. BTW, the "important organizations" to which you =
allude include not only the U.S. DoD, but also the Canadian and Brisith MoD=
, NATO, and others. Do I think this has commercial applicability, no. But t=
hat's because I think the commercial sector has never had a real need for t=
he sort of mandatory access controls that we're discussing here.

 2)      Why do we need the constraints mechanism? The constraints processi=
ng logic is without any doubt the most problematic. The basic problem is al=
most obvious. Because we can't make a rigid standard for expressing neither=
 clearance levels, nor the context within which they apply, it seems equall=
y impossible to specify exactly how to constrain this in certificate path p=
rocessing. The result is an open logic that may differ from case to case, w=
hich is very challenging to implement.

Your observation about the potential difficulty of constraints processing c=
ould be accurate under some circumstances. However, this is a little like o=
ur favorite old ASN.1 construct: ANY DEFINED BY. How can an implementation =
be prepared to process the subject public key info field in a cert when thi=
s ASN.1 construct is used? The answer is that implementations are prepared =
to deal with specific algorithms, identified by OIDs, and they rejects cert=
s that contain OIDs that they d not recognize. In practice, an implementati=
on will not be expected to receive and accept clearance info defined under =
an arbitrary set of policy OIDs. So, the issue is whether one can define a =
way to plug in the necessary logic for interpreting the constraints and com=
paring local authorization info against a received  EE cert.


3)      Does viable alternatives exist? This goes both for clearance in cer=
tificates as well as the constraints logic. For example, could one simply d=
efine certificate policies, where one policy could define both clearance le=
vel and context, and then use policy constraints. If we would lose some fun=
ctionality, would that differences be big enough to merit a new standardize=
d way to do this?

I have not considered this approach, but it would likely generate a very la=
rge number of policies, to accommodate the various combinations of sensitiv=
ity levels and ranges thereof (and that's not even considering categories).

Steve

--_000_9F11911AED01D24BAA1C2355723C3D32195AA90D46EAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<title>Re: Rationales for CA clearance constraints</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style=
=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Stephen, Thanks fo=
r a
great and elaborate reply.<o:p></o:p></span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>It&#8217;s great to see a list of entities with a certain
interest in this. Nobody but them can decide whether their need is legitima=
te.
Only we can decide whether this should be standardized.<o:p></o:p></span></=
p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>So I guess my question is more on that why a standard, rathe=
r
than if it is legitimate. Many organizations have defined private extension=
s.
For Banking specific needs you can create a banking standard and for l mili=
tary
use I assume you can create a military standard. So if there is no commerci=
al
application. Does a standard still serve the community at large?<o:p></o:p>=
</span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>Also, you don&#8217;t tell me why we need constraints, only =
that
it is very close to our old ANY DEFINED BY. However, the way the undefined
logic here affects path processing is unprecedented. Yes, we have ANY DEFIN=
ED
BY in algorithm data, but we don&#8217;t have constraints mechanism logic b=
eing
altered dependent on algorithm. <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'col=
or:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> Stephen Kent [mailto:[e-mail]] <br>
<b>Sent:</b> den 27 oktober 2008 14:35<br>
<b>To:</b> Stefan Santesson<br>
<b>Cc:</b> [e-mail]<br>
<b>Subject:</b> Re: Rationales for CA clearance constraints<o:p></o:p></spa=
n></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal>At 3:19 AM +0100 10/25/08, Stefan Santesson wrote:<o:p=
></o:p></p>

</div>

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

<p class=3DMsoNormal>The discussion on CA clearance constraints have made m=
e
wonder about some basic rationales for writing this standard in the manner
suggested.<o:p></o:p></p>

</blockquote>

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

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</blockquote>

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

<p class=3DMsoNormal>It would be great if those advocating this solution co=
uld
help me understand better. I have 3 major questions:<o:p></o:p></p>

</blockquote>

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

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</blockquote>

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

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</blockquote>

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

<p class=3DMsoNormal>1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b> Why do this in
certificates at all?</b> It seems that most people are agreeing that
certificates is not a good place to specify the clearance of a subject. Are=
 we
suggesting this purely because some &quot;important&quot; organizations hav=
e
decided to implement this anyway and would feel better about it if it becam=
e a
standard, or do we have anyone who want to speak up and explain why this
actually is a great idea?<o:p></o:p></p>

</blockquote>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>By my count, &quot;most people&quot; is not an accurat=
e
characterization of the responses to this thread :-). Moreover, a non-trivi=
al
set of users have years of experience embedding clearance/authorization inf=
o in
certs, a fact that seems to be overlook in this debate. Yes, one can try to=
 put
too much of this sort of mandatory access control info info a cert and crea=
te a
management problem. But, the same can be said for creating subject names th=
at
map so closely to an org chart that every time someone is promoted or
transfers, the cert has to be revoked.&nbsp; So, let's not allow concerns a=
bout
how this<u> might</u> be done badly overshadow the fact that there are
legitimate ways to make use of this data in certs. BTW, the &quot;important
organizations&quot; to which you allude include not only the U.S. DoD, but =
also
the Canadian and Brisith MoD, NATO, and others. Do I think this has commerc=
ial
applicability, no. But that's because I think the commercial sector has nev=
er
had a real need for the sort of mandatory access controls that we're discus=
sing
here.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><o:p>&nbsp;</o:p></p>

</div>

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

<p class=3DMsoNormal>&nbsp;2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b> Why do we ne=
ed the
constraints mechanism?</b> The constraints processing logic is without any
doubt the most problematic. The basic problem is almost obvious. Because we
can't make a rigid standard for expressing neither clearance levels, nor th=
e
context within which they apply, it seems equally impossible to specify exa=
ctly
how to constrain this in certificate path processing. The result is an open
logic that may differ from case to case, which is very challenging to
implement.<o:p></o:p></p>

</blockquote>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>Your observation about the potential difficulty of
constraints processing could be accurate under some circumstances. However,
this is a little like our favorite old ASN.1 construct: ANY DEFINED BY. How=
 can
an implementation be prepared to process the subject public key info field =
in a
cert when this ASN.1 construct is used? The answer is that implementations =
are
prepared to deal with specific algorithms, identified by OIDs, and they rej=
ects
certs that contain OIDs that they d not recognize. In practice, an
implementation will not be expected to receive and accept clearance info
defined under an arbitrary set of policy OIDs. So, the issue is whether one=
 can
define a way to plug in the necessary logic for interpreting the constraint=
s
and comparing local authorization info against a received&nbsp; EE cert.<o:=
p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

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

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</blockquote>

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

<p class=3DMsoNormal>3)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b> Does viable altern=
atives
exist?</b> This goes both for clearance in certificates as well as the
constraints logic. For example, could one simply define certificate policie=
s,
where one policy could define both clearance level and context, and then us=
e
policy constraints. If we would lose some functionality, would that differe=
nces
be big enough to merit a new standardized way to do this?<o:p></o:p></p>

</blockquote>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>I have not considered this approach, but it would like=
ly
generate a very large number of policies, to accommodate the various
combinations of sensitivity levels and ranges thereof (and that's not even
considering categories).<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>Steve<o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D32195AA90D46EAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RMxdap003161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 15:59:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9RMxdDV003160; Mon, 27 Oct 2008 15:59:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from gateway.baea.com.au (gateway.baea.com.au [202.20.20.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RMxQga003124 for <[e-mail]>; Mon, 27 Oct 2008 15:59:37 -0700 (MST) (envelope-from [e-mail])
Received: from unknown (HELO bunya.baea.com.au) ([150.207.1.63]) by fep.baea.com.au with ESMTP; 28 Oct 2008 09:29:25 +1030
Received: from SBW3OWEX1.au.baesystems.com (exchange [150.207.4.37]) by bunya.baea.com.au (8.13.8+Sun/8.13.8) with ESMTP id m9RMxMkx027596; Tue, 28 Oct 2008 09:29:25 +1030 (CST)
Received: from brdw3ex1.au.baesystems.com ([150.207.68.10]) by SBW3OWEX1.au.baesystems.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 09:29:22 +1030
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93887.A5F1213F"
Subject: RE: draft-ietf-pkix-3281update-01.txt 
Date: Tue, 28 Oct 2008 09:59:21 +1100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-3281update-01.txt 
Thread-Index: Ack4OFFpTG68tGzXRhOnR53nnu36AwATHRlA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "BRUMBY, Ian" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Oct 2008 22:59:22.0226 (UTC) FILETIME=[A6853D20:01C93887]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

Since the over-the-wire encoding has been changed to be compatible with
X.501, and incompatible with RFC 3281, shouldn't the OID of the
attribute be changed to match X.501?

=20

=20

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Russ Housley
Sent: Tuesday, 28 October 2008 12:13 AM
To: BRUMBY, Ian; [e-mail]
Subject: RE: Rationales for CA clearance constraints

=20

This fact has been reported in an RFC Errata:

Note that clearance was NOT defined in X.501(1993), but X.500(1997).
However, X.501(2005) may be the best reference for clearance.


At 08:13 PM 10/26/2008, BRUMBY, Ian wrote:



The Clearance attribute is defined in the current X.501 (2001 and v6
draft) with an OID of 2.5.4.55. RFC 3281 (as referenced by
draft-turner-caclearanceconstraints-01.txt) defines it as 2.5.1.5.55. It
refers to X.501-1993 as the source of this definition. I've dug up the
1993 standard and can't find any reference to Clearance. If Clearance
Constraints are implemented, maybe it should be clarified if it
constrains X.501 (2003) Clearance attributes, if they are present in the
certificate, or specifically doesn't constrain them.=20

"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:#606420;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-AU link=3Dblue vlink=3D"#606420">

<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'>Since the over-the-wire encoding has b=
een
changed to be compatible with X.501, and incompatible with RFC 3281, should=
n&#8217;t
the OID of the attribute be changed to match X.501?<o:p></o:p></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'><o:p>&nbsp;</o:p></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'><o:p>&nbsp;</o:p></span></font></p>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>=
</font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US style=3D'font-size:10.0pt;font-fa=
mily:Tahoma'>
[e-mail] [mailto:[e-mail]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Russ Housley<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, 28 October 20=
08
12:13 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> BRUMBY, Ian; ietf-pkix@i=
mc.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Rationales for =
CA clearance
constraints</span></font><span lang=3DEN-US><o:p></o:p></span></p>

</div>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>This fact has been reported in an RFC Errata:<br>
<br>
Note that clearance was NOT defined in X.501(1993), but X.500(1997). Howeve=
r,
X.501(2005) may be the best reference for clearance.<br>
<br>
<br>
At 08:13 PM 10/26/2008, BRUMBY, Ian wrote:<br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New Roman"><=
span
style=3D'font-size:10.0pt;color:navy'>The Clearance attribute is defined in=
 the
current X.501 (2001 and v6 draft) with an OID of 2.5.4.55. RFC 3281 (as
referenced by draft-turner-caclearanceconstraints-01.txt) defines it as
2.5.1.5.55. It refers to X.501-1993 as the source of this definition.
I&#8217;ve dug up the 1993 standard and can&#8217;t find any reference to
Clearance. If Clearance Constraints are implemented, maybe it should be
clarified if it constrains X.501 (2003) Clearance attributes, if they are
present in the certificate, or specifically doesn&#8217;t constrain them.</=
span></font>
<o:p></o:p></p>

</div>

<pre>"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."

</pre></body>

</html>

------_=_NextPart_001_01C93887.A5F1213F--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RIF2Bc045698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 11:15:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9RIF2DR045696; Mon, 27 Oct 2008 11:15:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RIF143045683 for <[e-mail]>; Mon, 27 Oct 2008 11:15:01 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 98B223A6BBE; Mon, 27 Oct 2008 11:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-3281update-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 27 Oct 2008 11:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: 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		: An Internet Attribute Certificate Profile for Authorization: Update
	Author(s)	: R. Housley, S. Farrell, S. Turner
	Filename	: draft-ietf-pkix-3281update-01.txt
	Pages		: 12
	Date		: 2008-10-27
	
This document updates RFC 3281.  It incorporates verified errata.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-3281update-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RIF2QF045701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 11:15:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9RIF2TB045697; Mon, 27 Oct 2008 11:15:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RIF1eJ045682 for <[e-mail]>; Mon, 27 Oct 2008 11:15:01 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 95BA628C10D; Mon, 27 Oct 2008 11:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-09.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 27 Oct 2008 11:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: 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		: Elliptic Curve Cryptography Subject Public Key Information
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ecc-subpubkeyinfo-09.txt
	Pages		: 34
	Date		: 2008-10-27
	
This document specifies the syntax and semantics for the Subject 
   Public Key Information field in certificates that support Elliptic 
   Curve Cryptography.  This document updates Sections 2.3.5, 3, and 5 
   of RFC 3279.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-ecc-subpubkeyinfo-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RGw7L9026499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 09:58:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9RGw7FU026497; Mon, 27 Oct 2008 09:58:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RGvvRn026448 for <[e-mail]>; Mon, 27 Oct 2008 09:58:05 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.16.1.23]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KuVPf-0005KP-Fk; Mon, 27 Oct 2008 12:57:56 -0400
Mime-Version: 1.0
Message-Id: <p06240502c52b762dacd8@[10.242.22.83]>
In-Reply-To: <[e-mail]>
References: <[e-mail] osoft.com> <[e-mail]>
Date: Mon, 27 Oct 2008 09:59:26 -0400
To: Yoav Nir <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Cc: Stefan Santesson <[e-mail]>, "[e-mail]" <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-986995754==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-986995754==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 9:46 PM +0200 10/25/08, Yoav Nir wrote:
>On Oct 25, 2008, at 4:19 AM, Stefan Santesson wrote:
>
>>
>>
>>1)      Why do this in certificates at all? It seems that most 
>>people are agreeing that certificates is not a good place to 
>>specify the clearance of a subject. Are we suggesting this purely 
>>because some "important" organizations have decided to implement 
>>this anyway and would feel better about it if it became a standard, 
>>or do we have anyone who want to speak up and explain why this 
>>actually is a great idea?
>>
>
>I have to say that this one seems very weird to me. Clearance as the 
>term is used in military, government and private organizations 
>around the world is not a type of access control. Rather, it's just 
>one input to an access control system.
>
>If a document is classified "top secret", I shouldn't be able to 
>read it unless I have "top secret" clearance, but the converse is 
>not true. If I do have "top secret" clearance, I still should not be 
>able to access most "top secret" documents. An organization would 
>have to be crazy to have a server with all the top secret documents, 
>and leave all access control to the clearance of the accessor.

Your characterization above represents the traditional dichotomy 
between mandatory and discretionary access controls, the latter often 
referred to as "need-to-know." However, today there is increased 
pressure to reduce the discretionary aspect of access control for 
some data; the buzz term is "need-to-share." Thus granting access to 
data to a user based on clearance, independent of identity, is not 
uncommon. Also, since the clearance is an extension in a cert that 
contains an identity, both inputs to an access control decision are 
available, and bound securely to one another, if both have to be 
processed.

>If I understand correctly, the only good reason to specify some 
>attribute of the subject in a certificate (either identity or 
>attribute) is to save the server having to access a directory. But 
>access control cannot be fully specified by clearance data, so this 
>hypothetical server with all the top secret documents still needs to 
>do some access control based on a lookup in a directory.  Wouldn't 
>said directory already hold the clearance information as well as the 
>fact that this user is allowed to read this particular document?

See my comments above about circumstances where just the clearance 
may suffice. Also, even if one had to rely on directory access to 
check discretionary access control that does not make it desirable to 
rely on the directory for mandatory access controls. Also, it's 
arguably more secure to bind them into a cert than to rely on the 
integrity of a directory entry.

Steve
--============_-986995754==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Rationales for CA clearance
constraints</title></head><body>
<div>At 9:46 PM +0200 10/25/08, Yoav Nir wrote:</div>
<blockquote type="cite" cite>On Oct 25, 2008, at 4:19 AM, Stefan
Santesson wrote:<br>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite"
cite>1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>Why do this in
certificates at all?</b>&nbsp;It seems that most people are agreeing
that certificates is not a good place to specify the clearance of a
subject. Are we suggesting this purely because some "important"
organizations have decided to implement this anyway and would feel
better about it if it became a standard, or do we have anyone who want
to speak up and explain why this actually is a great
idea?</blockquote>
<blockquote type="cite" cite><br></blockquote>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>I have to say that this one seems very
weird to me. Clearance as the term is used in military, government and
private organizations around the world is not a type of access
control. Rather, it's just one input to an access control
system.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>If a document is classified &quot;top
secret&quot;, I shouldn't be able to read it unless I have &quot;top
secret&quot; clearance, but the converse is not true. If I do have
&quot;top secret&quot; clearance, I still should not be able to access
most &quot;top secret&quot; documents. An organization would have to
be crazy to have a server with all the top secret documents, and leave
all access control to the clearance of the accessor.</blockquote>
<div><br></div>
<div>Your characterization above represents the traditional dichotomy
between mandatory and discretionary access controls, the latter often
referred to as &quot;need-to-know.&quot; However, today there is
increased pressure to reduce the discretionary aspect of access
control for some data; the buzz term is &quot;need-to-share.&quot;
Thus granting access to data to a user based on clearance, independent
of identity, is not uncommon. Also, since the clearance is an
extension in a cert that contains an identity, both inputs to an
access control decision are available, and bound securely to one
another, if both have to be processed.</div>
<div><br></div>
<blockquote type="cite" cite>If I understand correctly, the only good
reason to specify some attribute of the subject in a certificate
(either identity or attribute) is to save the server having to access
a directory. But access control cannot be fully specified by clearance
data, so this hypothetical server with all the top secret documents
still needs to do some access control based on a lookup in a
directory. &nbsp;Wouldn't said directory already hold the clearance
information as well as the fact that this user is allowed to read this
particular document?</blockquote>
<div><br></div>
<div>See my comments above about circumstances where just the
clearance may suffice. Also, even if one had to rely on directory
access to check discretionary access control that does not make it
desirable to rely on the directory for mandatory access controls.
Also, it's arguably more secure to bind them into a cert than to rely
on the integrity of a directory entry.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-986995754==_ma============--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RGw7e0026498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 09:58:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9RGw6J6026494; Mon, 27 Oct 2008 09:58:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RGvs5p026438 for <[e-mail]>; Mon, 27 Oct 2008 09:58:05 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.16.1.23]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KuVPd-0005KP-E2; Mon, 27 Oct 2008 12:57:54 -0400
Mime-Version: 1.0
Message-Id: <p06240500c52b6b1ec3cf@[10.242.22.83]>
In-Reply-To: <[e-mail] osoft.com>
References: <[e-mail] osoft.com>
Date: Mon, 27 Oct 2008 09:34:42 -0400
To: Stefan Santesson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Rationales for CA clearance constraints
Cc: "[e-mail]" <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-986995757==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-986995757==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 3:19 AM +0100 10/25/08, Stefan Santesson wrote:
>The discussion on CA clearance constraints have made me wonder about 
>some basic rationales for writing this standard in the manner 
>suggested.
>
>It would be great if those advocating this solution could help me 
>understand better. I have 3 major questions:
>
>
>1)      Why do this in certificates at all? It seems that most 
>people are agreeing that certificates is not a good place to specify 
>the clearance of a subject. Are we suggesting this purely because 
>some "important" organizations have decided to implement this anyway 
>and would feel better about it if it became a standard, or do we 
>have anyone who want to speak up and explain why this actually is a 
>great idea?

By my count, "most people" is not an accurate characterization of the 
responses to this thread :-). Moreover, a non-trivial set of users 
have years of experience embedding clearance/authorization info in 
certs, a fact that seems to be overlook in this debate. Yes, one can 
try to put too much of this sort of mandatory access control info 
info a cert and create a management problem. But, the same can be 
said for creating subject names that map so closely to an org chart 
that every time someone is promoted or transfers, the cert has to be 
revoked.  So, let's not allow concerns about how this might be done 
badly overshadow the fact that there are legitimate ways to make use 
of this data in certs. BTW, the "important organizations" to which 
you allude include not only the U.S. DoD, but also the Canadian and 
Brisith MoD, NATO, and others. Do I think this has commercial 
applicability, no. But that's because I think the commercial sector 
has never had a real need for the sort of mandatory access controls 
that we're discussing here.


>  2)      Why do we need the constraints mechanism? The constraints 
>processing logic is without any doubt the most problematic. The 
>basic problem is almost obvious. Because we can't make a rigid 
>standard for expressing neither clearance levels, nor the context 
>within which they apply, it seems equally impossible to specify 
>exactly how to constrain this in certificate path processing. The 
>result is an open logic that may differ from case to case, which is 
>very challenging to implement.

Your observation about the potential difficulty of constraints 
processing could be accurate under some circumstances. However, this 
is a little like our favorite old ASN.1 construct: ANY DEFINED BY. 
How can an implementation be prepared to process the subject public 
key info field in a cert when this ASN.1 construct is used? The 
answer is that implementations are prepared to deal with specific 
algorithms, identified by OIDs, and they rejects certs that contain 
OIDs that they d not recognize. In practice, an implementation will 
not be expected to receive and accept clearance info defined under an 
arbitrary set of policy OIDs. So, the issue is whether one can define 
a way to plug in the necessary logic for interpreting the constraints 
and comparing local authorization info against a received  EE cert.

>
>3)      Does viable alternatives exist? This goes both for clearance 
>in certificates as well as the constraints logic. For example, could 
>one simply define certificate policies, where one policy could 
>define both clearance level and context, and then use policy 
>constraints. If we would lose some functionality, would that 
>differences be big enough to merit a new standardized way to do this?

I have not considered this approach, but it would likely generate a 
very large number of policies, to accommodate the various 
combinations of sensitivity levels and ranges thereof (and that's not 
even considering categories).

Steve
--============_-986995757==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Rationales for CA clearance
constraints</title></head><body>
<div>At 3:19 AM +0100 10/25/08, Stefan Santesson wrote:</div>
<blockquote type="cite" cite>The discussion on CA clearance
constraints have made me wonder about some basic rationales for
writing this standard in the manner suggested.</blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite>It would be great if those advocating
this solution could help me understand better. I have 3 major
questions:</blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite>1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b> Why
do this in certificates at all?</b> It seems that most people are
agreeing that certificates is not a good place to specify the
clearance of a subject. Are we suggesting this purely because some
"important" organizations have decided to implement this anyway and
would feel better about it if it became a standard, or do we have
anyone who want to speak up and explain why this actually is a great
idea?</blockquote>
<div><br></div>
<div>By my count, &quot;most people&quot; is not an accurate
characterization of the responses to this thread :-). Moreover, a
non-trivial set of users have years of experience embedding
clearance/authorization info in certs, a fact that seems to be
overlook in this debate. Yes, one can try to put too much of this sort
of mandatory access control info info a cert and create a management
problem. But, the same can be said for creating subject names that map
so closely to an org chart that every time someone is promoted or
transfers, the cert has to be revoked.&nbsp; So, let's not allow
concerns about how this<u> might</u> be done badly overshadow the fact
that there are legitimate ways to make use of this data in certs. BTW,
the &quot;important organizations&quot; to which you allude include
not only the U.S. DoD, but also the Canadian and Brisith MoD, NATO,
and others. Do I think this has commercial applicability, no. But
that's because I think the commercial sector has never had a real need
for the sort of mandatory access controls that we're discussing
here.</div>
<div><br>
<br>
</div>
<blockquote type="cite" cite>&nbsp;2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>
Why do we need the constraints mechanism?</b> The constraints
processing logic is without any doubt the most problematic. The basic
problem is almost obvious. Because we can't make a rigid standard
for expressing neither clearance levels, nor the context within which
they apply, it seems equally impossible to specify exactly how to
constrain this in certificate path processing. The result is an open
logic that may differ from case to case, which is very challenging to
implement.</blockquote>
<div><br></div>
<div>Your observation about the potential difficulty of constraints
processing could be accurate under some circumstances. However, this
is a little like our favorite old ASN.1 construct: ANY DEFINED BY. How
can an implementation be prepared to process the subject public key
info field in a cert when this ASN.1 construct is used? The answer is
that implementations are prepared to deal with specific algorithms,
identified by OIDs, and they rejects certs that contain OIDs that they
d not recognize. In practice, an implementation will not be expected
to receive and accept clearance info defined under an arbitrary set of
policy OIDs. So, the issue is whether one can define a way to plug in
the necessary logic for interpreting the constraints and comparing
local authorization info against a received&nbsp; EE cert.</div>
<div><br></div>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite>3)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b> Does
viable alternatives exist?</b> This goes both for clearance in
certificates as well as the constraints logic. For example, could one
simply define certificate policies, where one policy could define both
clearance level and context, and then use policy constraints. If we
would lose some functionality, would that differences be big enough to
merit a new standardized way to do this?</blockquote>
<div><br></div>
<div>I have not considered this approach, but it would likely generate
a very large number of policies, to accommodate the various
combinations of sensitivity levels and ranges thereof (and that's not
even considering categories).</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-986995757==_ma============--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RDKY6R080191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 06:20:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9RDKYSi080190; Mon, 27 Oct 2008 06:20:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9RDKM70080143 for <[e-mail]>; Mon, 27 Oct 2008 06:20:33 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 6901 invoked by uid 0); 27 Oct 2008 13:19:51 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.145.18) by woodstock.binhost.com with SMTP; 27 Oct 2008 13:19:51 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 27 Oct 2008 09:13:09 -0400
To: "BRUMBY, Ian" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Rationales for CA clearance constraints
In-Reply-To: <[e-mail] stems.com>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
This fact has been reported in an RFC Errata:<br><br>
Note that clearance was NOT defined in X.501(1993), but X.500(1997).
However, X.501(2005) may be the best reference for clearance.<br><br>
<br>
At 08:13 PM 10/26/2008, BRUMBY, Ian wrote:<br>
<blockquote type=cite class=cite cite=""><font size=2 color="#000080">The
Clearance attribute is defined in the current X.501 (2001 and v6 draft)
with an OID of 2.5.4.55. RFC 3281 (as referenced by
draft-turner-caclearanceconstraints-01.txt) defines it as 2.5.1.5.55. It
refers to X.501-1993 as the source of this definition. I’ve dug up the
1993 standard and can’t find any reference to Clearance. If Clearance
Constraints are implemented, maybe it should be clarified if it
constrains X.501 (2003) Clearance attributes, if they are present in the
certificate, or specifically doesn’t constrain them.</font>
</blockquote></body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RCJYQZ068044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 05:19:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9RCJYDA068043; Mon, 27 Oct 2008 05:19:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9RCJMD6067999 for <[e-mail]>; Mon, 27 Oct 2008 05:19:33 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 8859 invoked from network); 27 Oct 2008 12:05:28 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;27 Oct 2008 12:05:28 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 27 Oct 2008 12:05:28 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt
Date: Mon, 27 Oct 2008 08:19:06 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt
Thread-Index: Ack4EoMt3M+Gs5HVSeujDHAyHd2JfQAGP0qw
References: <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>, "ietf-pkix" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

RE: WG meetings discussions - Validation policies and TAM have been
discussed on this list and the TAM BOF list.  The slides and audio feeds
from the cited meetings are available.

RE: push/pull - As noted in recent related threads, the current draft
supports "push" and "pull".

RE: relying parties and TAs - Relying parties use trust anchor stores.
TA managers manage trust anchor stores.  Relying parties may be TA
managers.

RE: TA manager involvement in given scenarios - The involvement of a TA
manager in the two cited scenarios depends on how the TA format is
defined.  See draft-ietf-pkix-ta-format-00 for a proposal.  In that
case, a TA manager may be involved in both scenarios.

RE: TA managers and validation policy managers - Though we've not
defined "validation policy manager", it seems likely that a validation
policy manager would use a TA store when composing a validation policy.
That TA store would be managed by a TA manager.  As with relying
parties, the same entity may function as a TA manager and as a
validation policy manager.

RE: validation policies - Trust anchor usage is a broader topic than
validation policy usage.   We are not defining requirements for
validation policy management.  Since the draft does not define a
concrete trust anchor format and is not addressing validation policy
management, a discussion of the relationship between concrete TA formats
and validation policies is unnecessary.


________________________________

	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Denis Pinkas
	Sent: Monday, October 27, 2008 4:40 AM
	To: ietf-pkix
	Subject: RE: Response to WGLC on TAM:
draft-ietf-pkix-ta-mgmt-reqs-01.txt
=09
=09
	The fact that some topics were discussed at WG meetings such as
in Philadelphia or Dublin=20
	does  not mean that any decision what taken on these topics.
Since everybody cannot attend meetings
	the mailing list has the last word.

	First of all, I pleased to read that you consider that the pull
model should be part of the requirements.
	Nonetheless, I  will be interested to see how the draft is
redrafted to allow the use of a pull model.=20

	I would be particularly interested to understand what a "TA
manager" means in such a case.

	One basic question is whether constraints may be included within
self-signed certificates or/and=20
	may be associated with self-signed certificates. IMO, both cases
exist, but there is a major difference=20
	between these two cases :

	   a) Constraints included within a self-signed certificate are
valid for *all RPs* during the whole validity period=20
	      of the self-signed certificate and *cannot be changed*
during its life-time.

	    b) Constraints associated with a self-signed certificate can
be tailored by every RP to a specific use=20
	        and thus can be changed by the RP during the life-time
of the self-signed certificate.

	I have two questions:

	1) What is the relationship between a  "TA manager" and a RP ?

	2) According to your understanding of the responsabilities
dedicated to a "TA manager",=20
	is a "TA manager" involved or not involved in the above two
cases ?

	RFC 5055, which is a standard track document, specifies in its
introduction:

	   The path construction or validation

	   (e.g., making sure that none of the certificates in the path
are

	   revoked) is performed according to a validation policy, which

	   contains one or more trust anchors. =20

	It is clear that TAs are data elements contained in a validation
policy.=20
	If someone manages TAs, its relationship with a validation
policy manager must be clarified.

	RFC 5055 also references the definition given in RF 3379:

	   A validation policy (as defined in RFC 3379 [RQMTS])
specifies the

	   rules and parameters to be used by the SCVP server when
validating a

	   certificate.

	A core of the disagreement relates to comment 22 where you say:

	[CRW] A discussion of the relationship between concrete TA
formats and validation policy=20
	is probably appropriate for a document, but this is not the
appropriate document.=20
	No change resulted from this comment.

	Since this is a very important issue, I believe that a
discussion of the relationship between concrete TA formats=20
	and validation policy is necessary. Until the draft clarifies
the relationship between concrete TA formats=20
	and validation policies we will make no progress on that topic.

	Denis

	<snip>

=09



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9R8e7r7024320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 01:40:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9R8e7kx024318; Mon, 27 Oct 2008 01:40:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9R8dsce024270 for <[e-mail]>; Mon, 27 Oct 2008 01:40:06 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA110302 for <[e-mail]>; Mon, 27 Oct 2008 09:52:34 +0100
Received: from FRMYA-SIA24 ([129.182.109.122]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008102709393161:126718 ; Mon, 27 Oct 2008 09:39:31 +0100 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: RE: Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt
Date: Mon, 27 Oct 2008 09:39:30 +0100
Message-Id: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 27/10/2008 09:39:31, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 27/10/2008 09:39:54, Serialize complete at 27/10/2008 09:39:54
Content-Type: multipart/alternative;  boundary="----=_NextPart_08102709392986334210006_002"
Sender: [e-mail]
Precedence: 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_08102709392986334210006_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

The fact that some topics were discussed at WG meetings such as in Philadelphia or Dublin 
does  not mean that any decision what taken on these topics. Since everybody cannot attend meetings
the mailing list has the last word.
First of all, I pleased to read that you consider that the pull model should be part of the requirements.
Nonetheless, I  will be interested to see how the draft is redrafted to allow the use of a pull model. 
I would be particularly interested to understand what a "TA manager" means in such a case.
One basic question is whether constraints may be included within self-signed certificates or/and 
may be associated with self-signed certificates. IMO, both cases exist, but there is a major difference 
between these two cases :
   a) Constraints included within a self-signed certificate are valid for *all RPs* during the whole validity period 
      of the self-signed certificate and *cannot be changed* during its life-time.
    b) Constraints associated with a self-signed certificate can be tailored by every RP to a specific use 
        and thus can be changed by the RP during the life-time of the self-signed certificate.
I have two questions:
1) What is the relationship between a  "TA manager" and a RP ?
2) According to your understanding of the responsabilities dedicated to a "TA manager", 
is a "TA manager" involved or not involved in the above two cases ?
RFC 5055, which is a standard track document, specifies in its introduction:
   The path construction or validation
   (e.g., making sure that none of the certificates in the path are
   revoked) is performed according to a validation policy, which
   contains one or more trust anchors.  
It is clear that TAs are data elements contained in a validation policy. 
If someone manages TAs, its relationship with a validation policy manager must be clarified.
RFC 5055 also references the definition given in RF 3379:
   A validation policy (as defined in RFC 3379 [RQMTS]) specifies the
   rules and parameters to be used by the SCVP server when validating a
   certificate.
A core of the disagreement relates to comment 22 where you say:
[CRW] A discussion of the relationship between concrete TA formats and validation policy 
is probably appropriate for a document, but this is not the appropriate document. 
No change resulted from this comment.
Since this is a very important issue, I believe that a discussion of the relationship between concrete TA formats 
and validation policy is necessary. Until the draft clarifies the relationship between concrete TA formats 
and validation policies we will make no progress on that topic.
Denis
De : owner-ietf-pkix 
À : ietf-pkix 
Date : 2008-10-16, 21:26:36
Sujet : RE: Comments 14 to 28 - Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt


Responses to specific comments are inline below. I've snipped some
lengthy portions of the comments to avoid exceeding whatever message
length requirement prevented the initial distribution of the comments.

________________________________

 <snip - introductory text>

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

14 - The definition of a Trust Anchor (see section 1.1) is not adequate
and 
should be changed. 

RFC 3379 states: "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". 

Replacement proposal: 

Trust Anchor: data that includes one public key, a CA name, a validity
time 
interval and optionally additional constraints to be used when
constructing and 
validating a certification path, *as well as information for updates*. A
self- 
signed certificate with or without constraints may be used to specify
the root 
key of a trust anchor and additional constraints". 

[CRW] The current definition was the result of much discussion on the
TAM BOF/PKIX mailing lists. The current definition accommodates the
suggested scenario if validity period, update information, etc. is
viewed as associated data. No change resulted from this comment.

15 - The current definition of a Trust Anchor Store (see section 1.1) is
: 
Trust Anchor Store: A trust anchor store is a set of one or more trust
anchors. 
A trust anchor store may be managed by one or more trust anchor
managers. A 
device may have more than one trust anchor store. 

Change into: 

"Trust Anchor Store: A trust anchor store is a container which contains
one 
trust anchor". 

Within a validation policy, TAs can be grouped into sets, so that
different sets 
can be used for different purposes. For example, within a signature
validation 
policy, a set of TAs may be used to validate Attributes Certificates,
while 
another one may be used to validate time-stamp tokens. 

<snip - RFC 3379 quotation>

16 - Additional proposal: 

<snip - validation policy store definition>

17 - Instead of a Trust Anchor Manager, a Validation Policy Manager
should be 
defined. 

Proposal: 

Validation Policy Manager: A role responsible for managing the full
contents of 
a given validation policy store. 

[CRW] Re: 15, 16 and 17, we're not defining the requirements for
managing or using validation policies so these definitions are not
applicable. No change resulted from these comments. 

18 - Since a device or a system may support several validation policies,
some 
entity should be able to create empty validation policy stores and then
tell who 
is able to manage each of them. 

Proposal: "Validation Policy Stores Manager": A role responsible for
managing, 
for a given device or system, associations between validation policies
stores 
and validation policy managers. 

19 - The requirements in sections 3.X should be on validation policies
rather 
than on TAs. 

20 - In section 3.2.1, if would be better to separate the functional 
requirements for validation policy stores managers, validation policy
managers 
and the functional requirements for TAs. 

<snip - functional requirements for validation policies>

[CRW] Re: 18, 19 and 20, we're not defining the requirements for
managing or using validation policies. No change resulted from this
comment. Comment 19 neatly summarizes the core disagreement.

21 - Section 3.5.1 is omitting to mention the revocation conditions that
apply 
in RFC 5280 as well as the additional constraints that may exist. 

[CRW] Will add a note to 3.5.2 noting that trust anchors used to
validate certification paths must provide revocation status information.

22 - Section 3.7.1 is about "Trust Anchor Formats". The problem is that
a 
validation policy does not simply include TAs, but other information.
The 
relationship between the TA formats and the validation policy format
should be 
explained. 

[CRW] A discussion of the relationship between concrete TA formats and
validation policy is probably appropriate for a document, but this is
not the appropriate document. No change resulted from this comment.

23 - Section 3.7.1 is about "Trust Anchor Formats". The texts states: 

   Minimally, a trust anchor management protocol must support management

   of trust anchors represented as self-signed certificates and trust 
   anchors represented as a distinguished name and public key 
   information. 

This sentence is incorrect since a trust anchor is not simply defined
using a 
distinguished name and public key information. Please refer to new
proposed 
definition of a Trust anchor. 

[CRW] Will augment this statement to include associated data.

There is also the need for a management protocol to support the
management of a 
validation policy as a whole. 

[CRW] We're not defining the requirements for managing or using
validation policies. 

The texts states: 

The definition of a trust anchor must include a public key, a public key

algorithm and, if necessary, public key parameters. 

This is in contradiction with the previous sentence. 

   When the public key is used to validate certification paths, a 
   distinguished name also must be included per [RFC3852]. 

The next sentence attempts to express a requirement, but is not
understandable : 

A trust anchor format should enable specification of public key
identifier to 
enable other applications of the trust anchor, for example, verification
of data 
signed using the Cryptographic Message Syntax (CMS) SignedData structure

[RFC3852]. 

What is the "specification of public key identifier" ? 

[CRW] In contexts where TAs are represented as certificates, it is the
inclusion of a subjectKeyIdentifier extension.

The conditions that would 
apply to verify data signed using CMS may not be included in the TA
format since 
a root CA may not be aware of all the various usages of its root
certificate. 

[CRW] In some cases this is true, in other cases the usages are known.
The requirement is that the protocol support the expression of these
constraints, not that all systems use this.

<snip - discussion of constraint placement>

24 - Section 3.8.1. Functional requirements that apply to validation
policy 
managers and validation policy stores managers should also be considered

instead. Proposal: 

<snip - discussion of validation policy managers>

[CRW] We're not defining the requirements for managing or using
validation policies. No change resulted from this comment. 

25 - Section 3.9 about source authentication. The functional
requirements from 
section 3.9.1 are unrelated to the rationale from section 3.9.2. The
rational is 
about authorization while the requirements are about authentication.
This 
section needs to be revised. 

[CRW] This section will be revised. Most likely, sections 3.8 and 3.9
will be collapsed into one section.

26 - Section 3.10 about a reduction of reliance on out-of-bands
mechanism. While 
the rationale from section 3.10.2 is roughly correct, the functional 
requirements from section 3.10.1 are unrelated. 

Replace with: 

Out-of-band trust mechanisms should only be required to allow validation
policy 
stores managers to manage validation policy stores. 

[CRW] We're not defining the requirements for managing or using
validation policies, so the replacement text was not used. I fail to
see that 3.10.1 and 3.10.2 are unrelated, but they are inconsistent.
Revised text for section 3.10.1 will be included in the next draft. 

27 - Section 12 is about disaster recovery. 

This requirement should not be placed in the MUST category but in the
SHOULD 
category (it is only a nice-to-have feature). Systems should not be
mandated to 
implement it. It is unsure what the editors have in mind behind this 
requirement. Further explanations would be appreciated. 

[CRW] The requirement is that the protocol support this. Systems are
not mandated to implement it. Will try to make this more clear in the
draft. 

28 - Section 4. Security considerations section. 

The text states: 

In all scenarios, regardless of the authentication mechanism, at least
one trust 
anchor manager must be established for each trust anchor store during
the 
initial configuration of the trust anchor store. 

The text should be reworded as follows: 

In all scenarios, regardless of the authentication mechanism, at least
one 
validation policy stores manager must be established for each device or
system.

[CRW] We're not defining the requirements for managing or using
validation policies. No change resulted from this comment. 

------=_NextPart_08102709392986334210006_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Tahoma; mso-ansi-language: EN-GB">
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><SPAN 
lang=EN-GB 
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA">The 
fact that some topics were discussed at WG meetings such as in 
</SPAN><?xml:namespace prefix = st1 ns = 
"urn:schemas-microsoft-com:office:smarttags" /><st1:City><st1:place><SPAN 
lang=EN-GB 
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA">Philadelphia</SPAN></st1:place></st1:City><SPAN 
lang=EN-GB 
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA"> 
or </SPAN><st1:City><st1:place><SPAN lang=EN-GB 
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA">Dublin</SPAN></st1:place></st1:City><SPAN 
lang=EN-GB 
style="FONT-SIZE: 12pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA"> 
<BR>does</SPAN><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA">&nbsp;</SPAN></SPAN><FONT 
size=3><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3> not mean that any decision what taken on these topics.</FONT>&nbsp;<FONT 
size=3>Since everybody cannot attend meetings<BR>the&nbsp;mailing list has the 
last word.</FONT></SPAN></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3><FONT size=3><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" 
/><o:p></o:p></FONT></SPAN></FONT>First of all, I pleased to read that you 
consider that the pull model should be&nbsp;part of the 
requirements.<BR></FONT></SPAN><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3>Nonetheless, I &nbsp;will be interested to see how the draft is redrafted 
to allow the use of a pull model. </FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3>I would be particularly interested to understand what a "TA manager" 
means in such a case.<o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3>One basic question is whether&nbsp;constraints may be&nbsp;included 
within self-signed certificates or/and <BR>may be&nbsp;associated with 
self-signed certificates. IMO, both cases&nbsp;exist, but there is a major 
difference <BR>between these two cases :<o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3><SPAN style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>a) Constraints 
included within a self-signed certificate are valid for *all RPs* during the 
whole validity period <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the self-signed 
certificate and *cannot be changed* during 
its&nbsp;life-time.<o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3><SPAN style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>b) Constraints 
associated with a self-signed certificate can be tailored by every RP to a 
specific use&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and thus 
can be changed by the RP during the life-time of the self-signed 
certificate.<o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA"><FONT 
size=3>I have two questions:</FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA"><FONT 
size=3>1) What is the relationship between a <SPAN 
style="mso-spacerun: yes">&nbsp;</SPAN>"TA manager" and a RP 
?</FONT></SPAN></P><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA"><FONT 
size=3>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3>2) According to your understanding of the responsabilities&nbsp;dedicated 
to a "TA manager", <BR>is a "TA manager" involved or not involved in the above 
two cases ?<o:p></o:p></FONT></SPAN></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt">RFC 5055, which is a standard 
track document, specifies in its introduction:</P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT 
face="Courier New">&nbsp;&nbsp;&nbsp;The path construction or 
validation<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>(e.g., making sure that none of 
the certificates in the path are<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>revoked) is performed according to 
a validation policy, which<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>contains one or more trust 
anchors.<SPAN style="mso-spacerun: yes">&nbsp; </SPAN></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3>It is clear that TAs are data elements contained in a validation policy. 
<BR>If someone manages TAs, its relationship with a validation policy manager 
must be clarified.</FONT></SPAN></P><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3>RFC 5055 also references the definition given in RF 
3379:</FONT></SPAN></P><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>A validation policy (as defined in 
RFC 3379 [RQMTS]) specifies the<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>rules and parameters to be used by 
the SCVP server when validating a<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; 
</SPAN>certificate.</SPAN></SPAN></P></FONT></SPAN>
<P><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3>A</FONT></SPAN><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3> core of the disagreement&nbsp;relates to comment 22 where you 
say:<o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3>[CRW] A discussion of the relationship between concrete TA formats and 
validation policy <BR>is probably appropriate for a document, but this is not 
the appropriate document. <BR>No change resulted from this 
comment.<o:p></o:p></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"><FONT 
size=3>Since this is a very important&nbsp;issue, I believe that a discussion of 
the relationship between concrete TA formats <BR>and validation policy is 
necessary. Until the draft clarifies the relationship between concrete TA 
formats <BR>and validation policies we will make no progress on that 
topic.<o:p></o:p></FONT></SPAN></P></FONT></SPAN>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"><SPAN lang=EN-GB 
style="FONT-SIZE: 8pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA"><FONT 
size=3>Denis</FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 12pt"></SPAN><B>De :</B> <A 
href="mailto :[e-mail]">owner-ietf-pkix</A> </P>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[e-mail]">ietf-pkix</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-10-16, 21:26:36</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> RE: Comments 14 to 28 - Response to WGLC on TAM: 
  draft-ietf-pkix-ta-mgmt-reqs-01.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>Responses to specific comments are inline below. I've snipped 
  some<BR>lengthy portions of the comments to avoid exceeding whatever 
  message<BR>length requirement prevented the initial distribution of the 
  comments.<BR><BR>________________________________<BR><BR>&nbsp;&lt;snip - 
  introductory text&gt;<BR><BR>=============================<BR><BR>14 - The 
  definition of a Trust Anchor (see section 1.1) is not adequate<BR>and 
  <BR>should be changed. <BR><BR>RFC 3379 states: "A trust anchor is defined as 
  one public key, a CA<BR>name, and a <BR>validity time interval; a trust anchor 
  optionally includes additional <BR>constraints. The use of a self-signed 
  certificate is one way to specify<BR>the <BR>public key to be used, the issuer 
  name, and the validity period of the<BR>public <BR>key". <BR><BR>Replacement 
  proposal: <BR><BR>Trust Anchor: data that includes one public key, a CA name, 
  a validity<BR>time <BR>interval and optionally additional constraints to be 
  used when<BR>constructing and <BR>validating a certification path, *as well as 
  information for updates*. A<BR>self- <BR>signed certificate with or without 
  constraints may be used to specify<BR>the root <BR>key of a trust anchor and 
  additional constraints". <BR><BR>[CRW] The current definition was the result 
  of much discussion on the<BR>TAM BOF/PKIX mailing lists. The current 
  definition accommodates the<BR>suggested scenario if validity period, update 
  information, etc. is<BR>viewed as associated data. No change resulted from 
  this comment.<BR><BR>15 - The current definition of a Trust Anchor Store (see 
  section 1.1) is<BR>: <BR>Trust Anchor Store: A trust anchor store is a set of 
  one or more trust<BR>anchors. <BR>A trust anchor store may be managed by one 
  or more trust anchor<BR>managers. A <BR>device may have more than one trust 
  anchor store. <BR><BR>Change into: <BR><BR>"Trust Anchor Store: A trust anchor 
  store is a container which contains<BR>one <BR>trust anchor". <BR><BR>Within a 
  validation policy, TAs can be grouped into sets, so that<BR>different sets 
  <BR>can be used for different purposes. For example, within a 
  signature<BR>validation <BR>policy, a set of TAs may be used to validate 
  Attributes Certificates,<BR>while <BR>another one may be used to validate 
  time-stamp tokens. <BR><BR>&lt;snip - RFC 3379 quotation&gt;<BR><BR>16 - 
  Additional proposal: <BR><BR>&lt;snip - validation policy store 
  definition&gt;<BR><BR>17 - Instead of a Trust Anchor Manager, a Validation 
  Policy Manager<BR>should be <BR>defined. <BR><BR>Proposal: <BR><BR>Validation 
  Policy Manager: A role responsible for managing the full<BR>contents of <BR>a 
  given validation policy store. <BR><BR>[CRW] Re: 15, 16 and 17, we're not 
  defining the requirements for<BR>managing or using validation policies so 
  these definitions are not<BR>applicable. No change resulted from these 
  comments. <BR><BR>18 - Since a device or a system may support several 
  validation policies,<BR>some <BR>entity should be able to create empty 
  validation policy stores and then<BR>tell who <BR>is able to manage each of 
  them. <BR><BR>Proposal: "Validation Policy Stores Manager": A role responsible 
  for<BR>managing, <BR>for a given device or system, associations between 
  validation policies<BR>stores <BR>and validation policy managers. <BR><BR>19 - 
  The requirements in sections 3.X should be on validation policies<BR>rather 
  <BR>than on TAs. <BR><BR>20 - In section 3.2.1, if would be better to separate 
  the functional <BR>requirements for validation policy stores managers, 
  validation policy<BR>managers <BR>and the functional requirements for TAs. 
  <BR><BR>&lt;snip - functional requirements for validation 
  policies&gt;<BR><BR>[CRW] Re: 18, 19 and 20, we're not defining the 
  requirements for<BR>managing or using validation policies. No change resulted 
  from this<BR>comment. Comment 19 neatly summarizes the core 
  disagreement.<BR><BR>21 - Section 3.5.1 is omitting to mention the revocation 
  conditions that<BR>apply <BR>in RFC 5280 as well as the additional constraints 
  that may exist. <BR><BR>[CRW] Will add a note to 3.5.2 noting that trust 
  anchors used to<BR>validate certification paths must provide revocation status 
  information.<BR><BR>22 - Section 3.7.1 is about "Trust Anchor Formats". The 
  problem is that<BR>a <BR>validation policy does not simply include TAs, but 
  other information.<BR>The <BR>relationship between the TA formats and the 
  validation policy format<BR>should be <BR>explained. <BR><BR>[CRW] A 
  discussion of the relationship between concrete TA formats and<BR>validation 
  policy is probably appropriate for a document, but this is<BR>not the 
  appropriate document. No change resulted from this comment.<BR><BR>23 - 
  Section 3.7.1 is about "Trust Anchor Formats". The texts states: 
  <BR><BR>&nbsp;&nbsp;&nbsp;Minimally, a trust anchor management protocol must 
  support management<BR><BR>&nbsp;&nbsp;&nbsp;of trust anchors represented as 
  self-signed certificates and trust <BR>&nbsp;&nbsp;&nbsp;anchors represented 
  as a distinguished name and public key <BR>&nbsp;&nbsp;&nbsp;information. 
  <BR><BR>This sentence is incorrect since a trust anchor is not simply 
  defined<BR>using a <BR>distinguished name and public key information. Please 
  refer to new<BR>proposed <BR>definition of a Trust anchor. <BR><BR>[CRW] Will 
  augment this statement to include associated data.<BR><BR>There is also the 
  need for a management protocol to support the<BR>management of a 
  <BR>validation policy as a whole. <BR><BR>[CRW] We're not defining the 
  requirements for managing or using<BR>validation policies. <BR><BR>The texts 
  states: <BR><BR>The definition of a trust anchor must include a public key, a 
  public key<BR><BR>algorithm and, if necessary, public key parameters. 
  <BR><BR>This is in contradiction with the previous sentence. 
  <BR><BR>&nbsp;&nbsp;&nbsp;When the public key is used to validate 
  certification paths, a <BR>&nbsp;&nbsp;&nbsp;distinguished name also must be 
  included per [RFC3852]. <BR><BR>The next sentence attempts to express a 
  requirement, but is not<BR>understandable : <BR><BR>A trust anchor format 
  should enable specification of public key<BR>identifier to <BR>enable other 
  applications of the trust anchor, for example, verification<BR>of data 
  <BR>signed using the Cryptographic Message Syntax (CMS) SignedData 
  structure<BR><BR>[RFC3852]. <BR><BR>What is the "specification of public key 
  identifier" ? <BR><BR>[CRW] In contexts where TAs are represented as 
  certificates, it is the<BR>inclusion of a subjectKeyIdentifier 
  extension.<BR><BR>The conditions that would <BR>apply to verify data signed 
  using CMS may not be included in the TA<BR>format since <BR>a root CA may not 
  be aware of all the various usages of its root<BR>certificate. <BR><BR>[CRW] 
  In some cases this is true, in other cases the usages are known.<BR>The 
  requirement is that the protocol support the expression of 
  these<BR>constraints, not that all systems use this.<BR><BR>&lt;snip - 
  discussion of constraint placement&gt;<BR><BR>24 - Section 3.8.1. Functional 
  requirements that apply to validation<BR>policy <BR>managers and validation 
  policy stores managers should also be considered<BR><BR>instead. Proposal: 
  <BR><BR>&lt;snip - discussion of validation policy managers&gt;<BR><BR>[CRW] 
  We're not defining the requirements for managing or using<BR>validation 
  policies. No change resulted from this comment. <BR><BR>25 - Section 3.9 about 
  source authentication. The functional<BR>requirements from <BR>section 3.9.1 
  are unrelated to the rationale from section 3.9.2. The<BR>rational is 
  <BR>about authorization while the requirements are about 
  authentication.<BR>This <BR>section needs to be revised. <BR><BR>[CRW] This 
  section will be revised. Most likely, sections 3.8 and 3.9<BR>will be 
  collapsed into one section.<BR><BR>26 - Section 3.10 about a reduction of 
  reliance on out-of-bands<BR>mechanism. While <BR>the rationale from section 
  3.10.2 is roughly correct, the functional <BR>requirements from section 3.10.1 
  are unrelated. <BR><BR>Replace with: <BR><BR>Out-of-band trust mechanisms 
  should only be required to allow validation<BR>policy <BR>stores managers to 
  manage validation policy stores. <BR><BR>[CRW] We're not defining the 
  requirements for managing or using<BR>validation policies, so the replacement 
  text was not used. I fail to<BR>see that 3.10.1 and 3.10.2 are unrelated, but 
  they are inconsistent.<BR>Revised text for section 3.10.1 will be included in 
  the next draft. <BR><BR>27 - Section 12 is about disaster recovery. 
  <BR><BR>This requirement should not be placed in the MUST category but in 
  the<BR>SHOULD <BR>category (it is only a nice-to-have feature). Systems should 
  not be<BR>mandated to <BR>implement it. It is unsure what the editors have in 
  mind behind this <BR>requirement. Further explanations would be appreciated. 
  <BR><BR>[CRW] The requirement is that the protocol support this. Systems 
  are<BR>not mandated to implement it. Will try to make this more clear in 
  the<BR>draft. <BR><BR>28 - Section 4. Security considerations section. 
  <BR><BR>The text states: <BR><BR>In all scenarios, regardless of the 
  authentication mechanism, at least<BR>one trust <BR>anchor manager must be 
  established for each trust anchor store during<BR>the <BR>initial 
  configuration of the trust anchor store. <BR><BR>The text should be reworded 
  as follows: <BR><BR>In all scenarios, regardless of the authentication 
  mechanism, at least<BR>one <BR>validation policy stores manager must be 
  established for each device or<BR>system.<BR><BR>[CRW] We're not defining the 
  requirements for managing or using<BR>validation policies. No change resulted 
  from this comment. <BR><BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08102709392986334210006_002--






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9R0EADs036048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Oct 2008 17:14:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9R0EAwh036047; Sun, 26 Oct 2008 17:14:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from gateway.baea.com.au (gateway.baea.com.au [202.20.20.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9R0DwW9036012 for <[e-mail]>; Sun, 26 Oct 2008 17:14:09 -0700 (MST) (envelope-from [e-mail])
Received: from unknown (HELO bunya.baea.com.au) ([150.207.1.63]) by fep.baea.com.au with ESMTP; 27 Oct 2008 10:43:56 +1030
Received: from SBW3OWEX1.au.baesystems.com (exchange [150.207.4.37]) by bunya.baea.com.au (8.13.8+Sun/8.13.8) with ESMTP id m9R0DsRO020315 for <[e-mail]>; Mon, 27 Oct 2008 10:43:56 +1030 (CST)
Received: from brdw3ex1.au.baesystems.com ([150.207.68.10]) by SBW3OWEX1.au.baesystems.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 10:43:55 +1030
Content-class: urn:content-classes:message
Subject: RE: Rationales for CA clearance constraints
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C937C8.E6008F09"
Date: Mon, 27 Oct 2008 11:13:54 +1100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack22y4p+RR31pBzS9C9gMp+re9v7wA6ha9g
References: <[e-mail]> <[e-mail]>
From: "BRUMBY, Ian" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 27 Oct 2008 00:13:55.0269 (UTC) FILETIME=[E63FAF50:01C937C8]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

My comments on the topic:

=20

1.	The Clearance attribute is defined in the current X.501 (2001
and v6 draft) with an OID of 2.5.4.55. RFC 3281 (as referenced by
draft-turner-caclearanceconstraints-01.txt) defines it as 2.5.1.5.55. It
refers to X.501-1993 as the source of this definition. I've dug up the
1993 standard and can't find any reference to Clearance. If Clearance
Constraints are implemented, maybe it should be clarified if it
constrains X.501 (2003) Clearance attributes, if they are present in the
certificate, or specifically doesn't constrain them.

=20

2.	With regards as to whether Clearance should be held in the
Certificate or the Directory:

	a.	I've heard concern that it shouldn't be held in either.
In a Prisoner of War scenario it potentially identifies the people with
the potential to have the most knowledge.
	b.	FYI - at least one Directory vendor is using the
Clearance attribute on the Certificate that is used to bind to the
Directory to control access to the Directory.

=20

Ian Brumby

BAE Systems

=20

"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."


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

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:#606420;
	text-decoration:underline;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1389646059;
	mso-list-type:hybrid;
	mso-list-template-ids:-967174674 201916431 201916441 201916443 201916431 2=
01916441 201916443 201916431 201916441 201916443;}
@list l0:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1
	{mso-list-id:1467965732;
	mso-list-type:hybrid;
	mso-list-template-ids:1047432362 201916431 201916441 201916443 201916431 2=
01916441 201916443 201916431 201916441 201916443;}
@list l1:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

<body lang=3DEN-AU link=3Dblue vlink=3D"#606420" style=3D'word-wrap: break-=
word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<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'>My comments on the topic:<o:p></o:p></=
span></font></p>

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

<ol style=3D'margin-top:0cm' start=3D1 type=3D1>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 lfo2'><font s=
ize=3D2
     color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:=
Arial'>The
     Clearance attribute is defined in the current X.501 (2001 and v6 draft=
) with
     an OID of 2.5.4.55. RFC 3281 (as referenced by draft-turner-caclearanc=
econstraints-01.txt)
     defines it as 2.5.1.5.55. It refers to X.501-1993 as the source of this
     definition. I&#8217;ve dug up the 1993 standard and can&#8217;t find a=
ny
     reference to Clearance. If Clearance Constraints are implemented, mayb=
e it
     should be clarified if it constrains X.501 (2003) Clearance attributes=
, if
     they are present in the certificate, or specifically doesn&#8217;t
     constrain them.<o:p></o:p></span></font></li>
</ol>

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

<ol style=3D'margin-top:0cm' start=3D2 type=3D1>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l0 level1 lfo2'><font s=
ize=3D2
     color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:=
Arial'>With
     regards as to whether Clearance should be held in the Certificate or t=
he
     Directory:<o:p></o:p></span></font></li>
</ol>

<ol style=3D'margin-top:0cm' start=3D1 type=3D1>
 <ol style=3D'margin-top:0cm' start=3D1 type=3Da>
  <li class=3DMsoNormal style=3D'color:navy;mso-list:l1 level2 lfo1'><font =
size=3D2
      color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family=
:Arial'>I&#8217;ve
      heard concern that it shouldn&#8217;t be held in either. In a Prisone=
r of
      War scenario it potentially identifies the people with the potential =
to
      have the most knowledge.<o:p></o:p></span></font></li>
  <li class=3DMsoNormal style=3D'color:navy;mso-list:l1 level2 lfo1'><font =
size=3D2
      color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family=
:Arial'>FYI
      &#8211; at least one Directory vendor is using the Clearance attribut=
e on
      the Certificate that is used to bind to the Directory to control acce=
ss
      to the Directory.<o:p></o:p></span></font></li>
 </ol>
</ol>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></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'>Ian Brumby<o:p></o:p></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'>BAE Systems<o:p></o:p></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'><o:p>&nbsp;</o:p></span></font></p>

</div>

<pre>"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."

</pre></body>

</html>

------_=_NextPart_001_01C937C8.E6008F09--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9QMgwAc023766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Oct 2008 15:42:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9QMgwqt023765; Sun, 26 Oct 2008 15:42:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9QMgkAu023752 for <[e-mail]>; Sun, 26 Oct 2008 15:42:57 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 2298 invoked from network); 26 Oct 2008 22:29:07 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;26 Oct 2008 22:29:07 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 26 Oct 2008 22:29:07 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C937BC.299732A0"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Comments on the TA requirements document
Date: Sun, 26 Oct 2008 18:42:44 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on the TA requirements document
Thread-Index: Ack1Gw5RwCiacYlDQg28ouWioo7jOwAAqt+wAADFKSAAAPbXgAAKFblQAD7RurAAIPrTIAA71DLA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C937BC.299732A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

I also do not see the I-D as favoring "push" over "pull".

=20

Can you recommend what specific changes you want to make to the I-D?
That may get there faster.

=20

My reading of the requirements document is that your model of publishing
policies and pulling them by clients is supported by the I-D provided
other security related requirements for authentication, integrity, and
replay protection are met.

=20

Why do you think your approach does not meet the requirements I-D?
Again, if you suggest specific changes, that are at requirements level
(vice implementation), we are liable to get there and get there faster.

=20

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Carl Wallace
Sent: Saturday, October 25, 2008 2:26 PM
To: [e-mail]
Subject: RE: Comments on the TA requirements document

=20

responses inline...

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Friday, October 24, 2008 10:48 PM
To: Kemp, David P.; [e-mail]
Subject: RE: Comments on the TA requirements document

Dave

=20

This is not a matter of transport protocol. This is a matter of how you
manage policies and what protocols you need to support both management
and execution of these policies.

=20

The current requirement document mix together policy management and
policy execution in one bucket for TA management.

=20

The policy management part deals with ensuring that all hosts knows what
keys they are allowed to trust.

The policy execution part deals with obtaining the keys and parameters
associated with managed policies and to put them in use in a compliant
manner.

=20

Policy management is always initiated and managed centrally and pushed
down to users/hosts, or at least enforced upon users/hosts in some way
or another. There are many ways to do this, but it always involves some
kind of central management. One way to do this that is very common in my
world, is to use a directory as the central mechanism to publish
policies combined with other functions (like system health checks) to
make sure hat policies has been downloaded and implemented. In these
common cases, there is no need for any new protocol.

=20

Policy execution is something that is carried out by the user/host,
based on the centrally distributed policy. One part of policy execution
in this case is to obtain/download the TAs that are considered
trustworthy by the distributed policy. Since the user/host is in control
and thus responsible for policy execution, they can also "pull" down any
key data associated with the TA policy. The only thing they would need
in order to do that, is a common data format for TA keys and their
parameters, signed by some kind of "master" TA policy management key.
That common data format for TA key information is all I currently need.=20

=20

[CRW] Section 3.2.1 allows for this, i.e.,  a message to replace an
entire trust anchor store.   This sort of message is essentially a
common data format for TA key information.  Most of the requirements in
the draft are quite fundamental - replay detection, integrity, source
authentication, intended purposes, basic format requirements, etc. - and
would be required by pretty much any TA key information format that
could be defined.

=20

We may convince ourselves that we can make a central manager in control
of policy execution on behalf of users/hosts if we write a super smart
protocol (like PKIX TAM), but that would be an illusion. To some extent
we will always need to trust the user/host to carry out the policy in an
appropriate manner.

=20

This is the world I'm coming from when approaching this subject. When I
read the req document for TA management I do not recognize any protocol
that fit the needs of my environment. =20

=20

[CRW] You should recognize lots in common with protocols in your
environment, namely certificates and certificate revocation lists.
Messages to add trust anchors are very similar to certificates.
Messages to remove certificates are very similar to certificate
revocation lists.  Most of the difficulty comes from limiting the
applicability/scope of the trust anchor keys.  =20

=20

This is why I have problems providing constructive feedback on it.

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

 <snip>=20


------_=_NextPart_001_01C937BC.299732A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns2=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/"
xmlns:ns3=3D"http://schemas.openxmlformats.org/markup-compatibility/2006"=

xmlns:ns0=3D"http://schemas.microsoft.com/office/2004/12/omml"
xmlns:ns4=3D"http://schemas.openxmlformats.org/package/2006/relationships=
"
xmlns:ns5=3D"http://schemas.microsoft.com/exchange/services/2006/types"
xmlns:ns6=3D"http://schemas.microsoft.com/exchange/services/2006/messages=
"
xmlns:ns7=3D"urn:schemas-microsoft-com:">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--a:link
	{mso-style-priority: 99
;}
span.MSOHYPERLINK
	{mso-style-priority: 99
;}
a:visited
	{mso-style-priority: 99
;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority: 99
;}
p
	{mso-style-priority: 99;}
pre
	{mso-style-priority: 99;}
span.HTMLPREFORMATTEDCHAR
	{mso-style-priority: 99;}

 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Calibri;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{font-family:"Courier New";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:Calibri;
	color:windowtext;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.h41
	{font-family:"Courier New";
	font-weight:bold;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body 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'>Stefan,<o:p></o:p></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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I also do not see the I-D as =
favoring &#8220;push&#8221;
over &#8220;pull&#8221;.<o:p></o:p></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'><o:p>&nbsp;</o:p></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'>Can you recommend what specific =
changes
you want to make to the I-D? &nbsp;That may get there =
faster.<o:p></o:p></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'><o:p>&nbsp;</o:p></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'>My reading of the requirements =
document is
that your model of publishing policies and pulling them by clients is =
supported
by the I-D provided other security related requirements for =
authentication,
integrity, and replay protection are met.<o:p></o:p></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'><o:p>&nbsp;</o:p></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'>Why do you think your approach does =
not
meet the requirements I-D? &nbsp;Again, if you suggest specific changes, =
that
are at requirements level (vice implementation), we are liable to get =
there and
get there faster.<o:p></o:p></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'><o:p>&nbsp;</o:p></span></font></p>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Carl Wallace<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Saturday, October =
25, 2008
2:26 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Comments on =
the TA
requirements document</span></font><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DSV
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>responses =
inline...</span></font><font
size=3D3 face=3D"Times New Roman"><span lang=3DSV =
style=3D'font-size:12.0pt;font-family:
"Times New Roman"'><o:p></o:p></span></font></p>

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

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

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, October 24, =
2008
10:48 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Kemp, David P.;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Comments on =
the TA
requirements document</span></font><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><font size=3D2 =
color=3D"#1f497d"
face=3DCalibri><span =
style=3D'font-size:11.0pt;color:#1F497D'>Dave</span></font></a><font
color=3D"#1f497d"><span =
style=3D'color:#1F497D'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'><o:p>&nbsp;</o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>This is not a matter of =
transport
protocol. This is a matter of how you manage policies and what protocols =
you
need to support both management and execution of these =
policies.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'><o:p>&nbsp;</o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>The current requirement =
document mix
together policy management and policy execution in one bucket for TA
management.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'><o:p>&nbsp;</o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>The policy management part =
deals with
ensuring that all hosts knows what keys they are allowed to =
trust.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>The policy execution part deals =
with
obtaining the keys and parameters associated with managed policies and =
to put
them in use in a compliant manner.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'><o:p>&nbsp;</o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>Policy management is always =
initiated
and managed centrally and pushed down to users/hosts, or at least =
enforced upon
users/hosts in some way or another. There are many ways to do this, but =
it
always involves some kind of central management. One way to do this that =
is
very common in my world, is to use a directory as the central mechanism =
to
publish policies combined with other functions (like system health =
checks) to
make sure hat policies has been downloaded and implemented. In these =
common
cases, there is no need for any new =
protocol.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'><o:p>&nbsp;</o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>Policy execution is something =
that is
carried out by the user/host, based on the centrally distributed policy. =
One
part of policy execution in this case is to obtain/download the TAs that =
are
considered trustworthy by the distributed policy. Since the user/host is =
in
control and thus responsible for policy execution, they can also
&#8220;pull&#8221; down any key data associated with the TA policy. The =
only
thing they would need in order to do that, is a common data format for =
TA keys
and their parameters, signed by some kind of &#8220;master&#8221; TA =
policy
management key. That common data format for TA key information is all I
currently need.</span></font><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>&nbsp;</span></fo=
nt><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span lang=3DSV =
style=3D'font-size:
11.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>[CRW]&nbsp;Section 3.2.1 allows
for&nbsp;this,&nbsp;i.e., &nbsp;a message to replace an =
entire&nbsp;trust
anchor store.&nbsp;&nbsp; This sort of message is essentially&nbsp;a =
common
data format for TA key information.&nbsp; Most of the requirements in =
the draft
are quite fundamental - replay detection, integrity, source =
authentication,
intended purposes, basic format requirements, etc. - and would&nbsp;be =
required
by pretty much any TA key information format that could be =
defined.</span></font><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>&nbsp;<o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>We may convince ourselves that =
we can
make a central manager in control of policy execution on behalf of =
users/hosts
if we write a super smart protocol (like PKIX TAM), but that would be an
illusion. To some extent we will always need to trust the user/host to =
carry
out the policy in an appropriate manner.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'><o:p>&nbsp;</o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>This is the world I&#8217;m =
coming from
when approaching this subject. When I read the req document for TA =
management I
do not recognize any protocol that fit the needs of my =
environment.&nbsp;</span></font><font
size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>&nbsp;</span></font><span lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span lang=3DSV =
style=3D'font-size:
11.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>[CRW] You should recognize lots =
in
common with protocols in your environment, namely certificates and =
certificate
revocation lists. &nbsp; Messages to add trust anchors are very similar =
to
certificates.&nbsp; Messages to remove certificates are very similar to
certificate revocation lists.&nbsp; Most of the difficulty comes from =
limiting
the applicability/scope of the trust anchor keys.&nbsp;&nbsp; =
</span></font><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>&nbsp;<o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'>This is why I have problems =
providing
constructive feedback on it.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;color:#1F497D'><o:p>&nbsp;</o:p></span></font><=
/p>

<div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dmaroon face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:maroon;font-weight:bold=
'>Stefan
Santesson</span></font></b><font size=3D3 color=3D"#1f497d" =
face=3D"Times New Roman"><span
lang=3DEN-GB style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
size=3D3 color=3Dnavy face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman";color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D2 color=3D"#400040" =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:#400040;font-weight:bol=
d'>Windows
Security, Standards</span></font></b><font color=3D"#1f497d"><span
style=3D'color:#1F497D'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&nbsp;&lt;snip&gt;&nbsp;</span></fon=
t><font
color=3D"#1f497d"><span =
style=3D'color:#1F497D'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C937BC.299732A0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9QLR6wH015655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Oct 2008 14:27:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9QLR6bB015654; Sun, 26 Oct 2008 14:27:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9QLQsln015614 for <[e-mail]>; Sun, 26 Oct 2008 14:27:05 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 1936 invoked from network); 26 Oct 2008 21:13:16 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;26 Oct 2008 21:13:16 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 26 Oct 2008 21:13:15 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C937B1.90E4F46A"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Rationales for CA clearance constraints
Date: Sun, 26 Oct 2008 17:26:52 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack2SA9aLjZZzSbqQcypOookjCoC2wBZFrPQ
References: <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C937B1.90E4F46A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

These issues are important and should be discussed and resolved once the
working group adopts the work item.

=20

I would also like to point out that many of the issues raised here are
repeated from other threads that had been dealt with.

=20

Nonetheless, I have provided a response to these below.

=20

Having discussed and resolved your concerns, I am counting on your vote
in favor of adoption of this work item.

=20

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Friday, October 24, 2008 10:19 PM
To: [e-mail]
Subject: Rationales for CA clearance constraints

=20

The discussion on CA clearance constraints have made me wonder about
some basic rationales for writing this standard in the manner suggested.

=20

It would be great if those advocating this solution could help me
understand better. I have 3 major questions:

=20

=20

1)      Why do this in certificates at all? It seems that most people
are agreeing that certificates is not a good place to specify the
clearance of a subject.=20

[Santosh] I am not sure that is the case.  We have a poll to adopt the
I-D.  Furthermore, the I-D is trying to be a broad standard and thus, it
covers clearance in subject directory attribute extension of the PKC and
attribute in AC

Are we suggesting this purely because some "important" organizations
have decided to implement this anyway and would feel better about it if
it became a standard, or do we have anyone who want to speak up and
explain why this actually is a great idea?

[Santosh] I would say that there are environments where clearance is
relatively static and can be vetted during identity vetting.  These
environments benefit from efficiency and cost savings by putting
clearance in the PKC as opposed to standing up another infrastructure
for AC.  The approach also results in lower software complexity and
lower computational complexity for relying parties.

=20

2)      Why do we need the constraints mechanism? The constraints
processing logic is without any doubt the most problematic. The basic
problem is almost obvious. Because we can't make a rigid standard for
expressing neither clearance levels, nor the context within which they
apply, it seems equally impossible to specify exactly how to constrain
this in certificate path processing. The result is an open logic that
may differ from case to case, which is very challenging to implement.=20

[Santosh] Your last post on Friday October 24 2008 agreed to the
approach of defining detailed logic for a known set of syntaxes as a
viable approach.  If the working group does not reach a consensus on
this approach, we have fallback of simple binary comparison or
deprecating categories.  All of this should be sorted out during the I-D
editing phase after the work item adoption.=20

=20

3)      Does viable alternatives exist? This goes both for clearance in
certificates as well as the constraints logic. For example, could one
simply define certificate policies, where one policy could define both
clearance level and context, and then use policy constraints. If we
would lose some functionality, would that differences be big enough to
merit a new standardized way to do this?

[Santosh] I am willing to discuss a concrete alternative to achieve the
objective.  Please note that the proposal above lacks details to comment
on.  Policy constraints extension has two somewhat unrelated fields
regarding inhibit policy mapping and require explicit policy; these do
not seem to relate to this.  But, I suspect you have something else in
mind.  Note that mapping clearance to certificate policies approach will
be problematic since it will result in unwieldy number of policies and
will not be amenable to access control since objects will have labels
based on clearance  Another problem with this approach is that it ties
the assurance mechanism that is part of X.509 path processing to access
control.  I do not think mixing the two is a good idea.  But, may be you
mean a mechanism other than certificate policies and policy constraints.

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20


------_=_NextPart_001_01C937B1.90E4F46A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns2=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/"
xmlns:ns3=3D"http://schemas.openxmlformats.org/markup-compatibility/2006"=

xmlns:ns0=3D"http://schemas.microsoft.com/office/2004/12/omml"
xmlns:ns4=3D"http://schemas.openxmlformats.org/package/2006/relationships=
"
xmlns:ns5=3D"http://schemas.microsoft.com/exchange/services/2006/types"
xmlns:ns6=3D"http://schemas.microsoft.com/exchange/services/2006/messages=
"
xmlns:ns7=3D"urn:schemas-microsoft-com:">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}
p.MSOLISTPARAGRAPH
	{mso-style-priority:34;}
li.MSOLISTPARAGRAPH
	{mso-style-priority:34;}
div.MSOLISTPARAGRAPH
	{mso-style-priority:34;}

 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Calibri;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.msolistparagraph, li.msolistparagraph, div.msolistparagraph
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Calibri;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Calibri;
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1230459812;
	mso-list-type:hybrid;
	mso-list-template-ids:-1819002030 69009425 69009433 69009435 69009423 =
69009433 69009435 69009423 69009433 69009435;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body 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'>Stefan,<o:p></o:p></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'><o:p>&nbsp;</o:p></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'>These issues are important and =
should be
discussed and resolved once the working group adopts the work =
item.<o:p></o:p></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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I would also like to point out that =
many
of the issues raised here are repeated from other threads that had been =
dealt
with.<o:p></o:p></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'><o:p>&nbsp;</o:p></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'>Nonetheless, I have provided a =
response to
these below.<o:p></o:p></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'><o:p>&nbsp;</o:p></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'>Having discussed and resolved your
concerns, I am counting on your vote in favor of adoption of this work =
item.<o:p></o:p></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'><o:p>&nbsp;</o:p></span></font></p>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, October 24, =
2008
10:19 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Rationales for =
CA
clearance constraints</span></font><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt'>The
discussion on CA clearance constraints have made me wonder about some =
basic
rationales for writing this standard in the manner =
suggested.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt'>It
would be great if those advocating this solution could help me =
understand
better. I have 3 major questions:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3Dmsolistparagraph style=3D'text-indent:-.25in;mso-list:l0 =
level1 lfo2'><![if !supportLists]><font
size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt'><span =
style=3D'mso-list:Ignore'>1)<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><b><span =
style=3D'font-weight:bold'>Why
do this in certificates at all?</span></b> It seems that most people are
agreeing that certificates is not a good place to specify the clearance =
of a
subject. <o:p></o:p></p>

<p class=3Dmsolistparagraph style=3D'margin-left:0in'><b><i><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'>[Santosh] I am not sure =
that is
the case.&nbsp; We have a poll to adopt the I-D.&nbsp; Furthermore, the =
I-D is
trying to be a broad standard and thus, it covers clearance in subject
directory attribute extension of the PKC and attribute in =
AC<o:p></o:p></span></font></i></b></p>

<p class=3Dmsolistparagraph><font size=3D2 face=3DCalibri><span =
style=3D'font-size:
11.0pt'>Are we suggesting this purely because some =
&#8220;important&#8221;
organizations have decided to implement this anyway and would feel =
better about
it if it became a standard, or do we have anyone who want to speak up =
and
explain why this actually is a great idea?<o:p></o:p></span></font></p>

<p class=3Dmsolistparagraph style=3D'margin-left:0in'><b><i><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'>[Santosh] I would say =
that there
are environments where clearance is relatively static and can be vetted =
during
identity vetting.&nbsp; These environments benefit from efficiency and =
cost
savings by putting clearance in the PKC as opposed to standing up =
another
infrastructure for AC.&nbsp; The approach also results in lower software
complexity and lower computational complexity for relying =
parties.</span></font></i></b><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

<p class=3Dmsolistparagraph><font size=3D2 face=3DCalibri><span =
style=3D'font-size:
11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3Dmsolistparagraph style=3D'text-indent:-.25in;mso-list:l0 =
level1 lfo2'><![if !supportLists]><font
size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt'><span =
style=3D'mso-list:Ignore'>2)<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><b><span =
style=3D'font-weight:bold'>Why
do we need the constraints mechanism?</span></b> The constraints =
processing
logic is without any doubt the most problematic. The basic problem is =
almost
obvious. Because we can&#8217;t make a rigid standard for expressing =
neither
clearance levels, nor the context within which they apply, it seems =
equally
impossible to specify exactly how to constrain this in certificate path
processing. The result is an open logic that may differ from case to =
case,
which is very challenging to implement. <o:p></o:p></p>

<p class=3Dmsolistparagraph style=3D'margin-left:0in'><b><i><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'>[Santosh] Your last post =
on
Friday October 24 2008 agreed to the approach of defining detailed logic =
for a
known set of syntaxes as a viable approach.&nbsp; If the working group =
does not
reach a consensus on this approach, we have fallback of simple binary
comparison or deprecating categories.&nbsp; All of this should be sorted =
out
during the I-D editing phase after the work item adoption. =
</span></font></i></b><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

<p class=3Dmsolistparagraph><font size=3D2 face=3DCalibri><span =
style=3D'font-size:
11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3Dmsolistparagraph style=3D'text-indent:-.25in;mso-list:l0 =
level1 lfo2'><![if !supportLists]><font
size=3D2 face=3DCalibri><span style=3D'font-size:11.0pt'><span =
style=3D'mso-list:Ignore'>3)<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><b><span =
style=3D'font-weight:bold'>Does
viable alternatives exist?</span></b> This goes both for clearance in
certificates as well as the constraints logic. For example, could one =
simply
define certificate policies, where one policy could define both =
clearance level
and context, and then use policy constraints. If we would lose some
functionality, would that differences be big enough to merit a new =
standardized
way to do this?<o:p></o:p></p>

<p class=3Dmsolistparagraph style=3D'margin-left:0in'><b><i><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold;font-style:italic'>[Santosh] I am willing to
discuss a concrete alternative to achieve the objective.&nbsp; Please =
note that
the proposal above lacks details to comment on.&nbsp; Policy constraints
extension has two somewhat unrelated fields regarding inhibit policy =
mapping
and require explicit policy; these do not seem to relate to this.&nbsp; =
But, I
suspect you have something else in mind.&nbsp; Note that mapping =
clearance to
certificate policies approach will be problematic since it will result =
in
unwieldy number of policies and will not be amenable to access control =
since
objects will have labels based on clearance&nbsp; Another problem with =
this
approach is that it ties the assurance mechanism that is part of X.509 =
path
processing to access control.&nbsp; I do not think mixing the two is a =
good
idea.&nbsp; But, may be you mean a mechanism other than certificate =
policies
and policy constraints.</span></font></i></b><font size=3D2 color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span=
></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D2 color=3Dmaroon face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:maroon;font-weight:bold=
'>Stefan
Santesson</span></font></b><font size=3D3 color=3D"#1f497d" =
face=3D"Times New Roman"><span
lang=3DEN-GB style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
size=3D3 color=3Dnavy face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman";color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D2 color=3D"#400040" =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:#400040;font-weight:bol=
d'>Windows
Security, Standards</span></font></b><font color=3D"#1f497d"><span
style=3D'color:#1F497D'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C937B1.90E4F46A--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9QJc6wx096012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Oct 2008 12:38:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9QJc6pv096011; Sun, 26 Oct 2008 12:38:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp182.sat.emailsrvr.com (smtp182.sat.emailsrvr.com [66.216.121.182]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9QJbtLh095974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 26 Oct 2008 12:38:06 -0700 (MST) (envelope-from [e-mail])
Received: from relay8.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 3809411B26EA for <[e-mail]>; Sun, 26 Oct 2008 15:37:55 -0400 (EDT)
Received: by relay8.relay.sat.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTP id 7355611B26C7 for <[e-mail]>; Sun, 26 Oct 2008 15:37:54 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 27 Oct 2008 06:37:52 +1100
From: Stephen Wilson <[e-mail]>
Reply-To: [e-mail]
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: relation between certificate policies and CP/CPS  identification
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I worked with a health sector client a few years ago where we had this 
issue -- namely their PKI was covering several different distinct 
certificates all issued under very similar technical circumstances but 
with different identification methods and applications, and therefore 
different Policy OIDs.

To explain, there was a backend 'wholesale' CA that was servicing 
different RAs, each responsible for issuing certificates to members of 
diverse professional groups (nurses, General Practitioners, specialists, 
employees at particular hospitals etc.).  The overall service included 
processes for helping bring new 'communities of interest' into the 
system; each community would undertake a business case analysis (to make 
sure they really needed certificates!), followed by threat & risk 
assessment on their registration procedures, then customisation of the 
certificate profile, and documentation of local RA procedures.  All 
communities used the same RA technology, supported by the scheme.

To handle the CP, we wrote a master CP and a suite of "Annexes".  For 
each community in the scheme, there would be a different Annex to the CP 
that specified the variations: identification processes, intended 
applications, banned applications, the X.509 profile etc. We would 
assign a unique Policy OIDs for all certificates issued by the 
community; it was basically a leaf from a Policy OID assigned to the 
Master CP document.  In practical terms, we found that each CP annex was 
about three pages long.

Incidentally, an elegant and useful outcome was that for software 
developers in the health sector, the meaning of each certificate in the 
scheme became very easy to discern, and business logic easy to 
implement.  The Policy OID in most cases indicated very simply the 
membership of the Subject to a certain professional group; e.g. the 
Subject might be a registered General Practitioner, or member of the 
College of Cardiology, or employee of Sydney Public Hospital, or 
contracted provider at Acme HMO.  To sign (or validate) particular types 
of transactions, the software would invoke the appropriate certificate 
usually based on context and Policy OID alone; e.g. insurance claims 
would be signed using the HMO certificate, hospital admissions and 
discharge summaries using the hospital certificate, e-prescriptions 
using the GP certificate.  If a medical professional had more than one 
role or membership, then they would be issued multiple certificates.

Cheers,

Steve Wilson.

Lockstep
www.lockstep.com.au
-------------------
Lockstep Consulting provides independent specialist advice and analysis
on authentication, PKI and smartcards.  Lockstep Technologies develops
unique new smart ID solutions that safeguard identity and privacy.




>> hello,
>>
>> I would like to have some opinion about the usage of object identifiers
>> for certificate policies.
>>
>> It happens sometimes that the difference between two policies is
>> very small, as an example the lifetime of a certficate (2 years or 3 
>> days),
>> where all other parameters are identical, i.e. one woould like to
>> make a policy based decision based on two object identifiers for
>> such cases. Does thst means that one need to publish two
>> independant documents, or would it be sufficient to indicate
>> in the text that two OIDs are handled?
>>
>> Also, sometimes, a PC text changes slightly. Does this means
>> that one has to allocate a new identifier in all cases.
>>
>>
>> TIA
>> Peter
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9PJkxSE015965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Oct 2008 12:46:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9PJkxOg015964; Sat, 25 Oct 2008 12:46:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9PJklTv015925 for <[e-mail]>; Sat, 25 Oct 2008 12:46:58 -0700 (MST) (envelope-from [e-mail])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2CE3729C001; Sat, 25 Oct 2008 21:46:47 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2A0E5294003; Sat, 25 Oct 2008 21:46:46 +0200 (IST)
Received: from [172.31.24.21] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9PJkZQC029700; Sat, 25 Oct 2008 21:46:45 +0200 (IST)
Cc: "[e-mail]" <[e-mail]>
Message-Id: <[e-mail]>
From: Yoav Nir <[e-mail]>
To: Stefan Santesson <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/alternative; boundary=Apple-Mail-2--303824096
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Rationales for CA clearance constraints
Date: Sat, 25 Oct 2008 21:46:35 +0200
References: <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Apple-Mail-2--303824096
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable


On Oct 25, 2008, at 4:19 AM, Stefan Santesson wrote:
>
>
> 1)      Why do this in certificates at all? It seems that most =20
> people are agreeing that certificates is not a good place to specify =20=

> the clearance of a subject. Are we suggesting this purely because =20
> some =93important=94 organizations have decided to implement this =
anyway =20
> and would feel better about it if it became a standard, or do we =20
> have anyone who want to speak up and explain why this actually is a =20=

> great idea?
>

I have to say that this one seems very weird to me. Clearance as the =20
term is used in military, government and private organizations around =20=

the world is not a type of access control. Rather, it's just one input =20=

to an access control system.

If a document is classified "top secret", I shouldn't be able to read =20=

it unless I have "top secret" clearance, but the converse is not true. =20=

If I do have "top secret" clearance, I still should not be able to =20
access most "top secret" documents. An organization would have to be =20
crazy to have a server with all the top secret documents, and leave =20
all access control to the clearance of the accessor.

If I understand correctly, the only good reason to specify some =20
attribute of the subject in a certificate (either identity or =20
attribute) is to save the server having to access a directory. But =20
access control cannot be fully specified by clearance data, so this =20
hypothetical server with all the top secret documents still needs to =20
do some access control based on a lookup in a directory.  Wouldn't =20
said directory already hold the clearance information as well as the =20
fact that this user is allowed to read this particular document?



--Apple-Mail-2--303824096
Content-Type: text/html;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><div>On Oct 25, 2008, =
at 4:19 AM, Stefan Santesson wrote:</div><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Arial; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><div lang=3D"SV" link=3D"blue" =
vlink=3D"purple"><div class=3D"Section1"><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
11pt; font-family: Calibri, sans-serif; "><span class=3D"Apple-style-span"=
 style=3D"color: rgb(20, 79, 174); font-size: 12px; =
-webkit-text-stroke-width: -1; ">&nbsp;</span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif; "><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></div><div =
style=3D"text-indent: -18pt; margin-top: 0cm; margin-right: 0cm; =
margin-left: 36pt; margin-bottom: 0.0001pt; font-size: 11pt; =
font-family: Calibri, sans-serif; "><span lang=3D"EN-US"><span>1)<span =
style=3D"font: normal normal normal 7pt/normal 'Times New Roman'; =
">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span></span></span></span><b><span=
 lang=3D"EN-US">Why do this in certificates at all?</span></b><span =
lang=3D"EN-US"><span class=3D"Apple-converted-space">&nbsp;</span>It =
seems that most people are agreeing that certificates is not a good =
place to specify the clearance of a subject. Are we suggesting this =
purely because some =93important=94 organizations have decided to =
implement this anyway and would feel better about it if it became a =
standard, or do we have anyone who want to speak up and explain why this =
actually is a great idea?<o:p></o:p></span></div><div style=3D"margin-top:=
 0cm; margin-right: 0cm; margin-left: 36pt; margin-bottom: 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif; =
"><br></div></div></div></span></blockquote><br></div><div>I have to say =
that this one seems very weird to me. Clearance as the term is used in =
military, government and private organizations around the world is not a =
type of access control. Rather, it's just one input to an access control =
system.</div><div><br></div><div>If a document is classified "top =
secret", I shouldn't be able to read it unless I have "top secret" =
clearance, but the converse is not true. If I do have "top secret" =
clearance, I still should not be able to access most "top secret" =
documents. An organization would have to be crazy to have a server with =
all the top secret documents, and leave all access control to the =
clearance of the accessor.&nbsp;</div><div><br></div><div>If I =
understand correctly, the only good reason to specify some attribute of =
the subject in a certificate (either identity or attribute) is to save =
the server having to access a directory. But access control cannot be =
fully specified by clearance data, so this hypothetical server with all =
the top secret documents still needs to do some access control based on =
a lookup in a directory. &nbsp;Wouldn't said directory already hold the =
clearance information as well as the fact that this user is allowed to =
read this particular =
document?</div><div><br></div><div><br></div></body></html>=

--Apple-Mail-2--303824096--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9PJOA6b014663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Oct 2008 12:24:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9PJOA9h014662; Sat, 25 Oct 2008 12:24:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9PJO91U014656 for <[e-mail]>; Sat, 25 Oct 2008 12:24:09 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 26375 invoked by uid 0); 25 Oct 2008 19:24:03 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.145.18) by woodstock.binhost.com with SMTP; 25 Oct 2008 19:24:03 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 25 Oct 2008 15:00:26 -0400
To: Peter Sylvester <[e-mail]>, pkix <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: relation between certificate policies and CP/CPS identification
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have seen CP documents that define more than one policy, where the 
vast majority of the material is the same, and then the few places 
that differ include something like:

If implementing policy A, then ...

If implementing policy B, then ...

Russ

At 02:10 PM 10/23/2008, Peter Sylvester wrote:

>hello,
>
>I would like to have some opinion about the usage of object identifiers
>for certificate policies.
>
>It happens sometimes that the difference between two policies is
>very small, as an example the lifetime of a certficate (2 years or 3 days),
>where all other parameters are identical, i.e. one woould like to
>make a policy based decision based on two object identifiers for
>such cases. Does thst means that one need to publish two
>independant documents, or would it be sufficient to indicate
>in the text that two OIDs are handled?
>
>Also, sometimes, a PC text changes slightly. Does this means
>that one has to allocate a new identifier in all cases.
>
>
>TIA
>Peter



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9PIPsh3011829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Oct 2008 11:25:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9PIPslQ011828; Sat, 25 Oct 2008 11:25:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9PIPh3F011780 for <[e-mail]>; Sat, 25 Oct 2008 11:25:53 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 20550 invoked from network); 25 Oct 2008 18:12:05 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;25 Oct 2008 18:12:05 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 25 Oct 2008 18:12:05 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C936CF.1637991C"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Comments on the TA requirements document
Date: Sat, 25 Oct 2008 14:25:40 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on the TA requirements document
Thread-Index: Ack1Gw5RwCiacYlDQg28ouWioo7jOwAAqt+wAADFKSAAAPbXgAAKFblQAD7RurAAIPrTIA==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C936CF.1637991C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

responses inline...


________________________________

	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
	Sent: Friday, October 24, 2008 10:48 PM
	To: Kemp, David P.; [e-mail]
	Subject: RE: Comments on the TA requirements document
=09
=09

	Dave

	=20

	This is not a matter of transport protocol. This is a matter of
how you manage policies and what protocols you need to support both
management and execution of these policies.

	=20

	The current requirement document mix together policy management
and policy execution in one bucket for TA management.

	=20

	The policy management part deals with ensuring that all hosts
knows what keys they are allowed to trust.

	The policy execution part deals with obtaining the keys and
parameters associated with managed policies and to put them in use in a
compliant manner.

	=20

	Policy management is always initiated and managed centrally and
pushed down to users/hosts, or at least enforced upon users/hosts in
some way or another. There are many ways to do this, but it always
involves some kind of central management. One way to do this that is
very common in my world, is to use a directory as the central mechanism
to publish policies combined with other functions (like system health
checks) to make sure hat policies has been downloaded and implemented.
In these common cases, there is no need for any new protocol.

	=20

	Policy execution is something that is carried out by the
user/host, based on the centrally distributed policy. One part of policy
execution in this case is to obtain/download the TAs that are considered
trustworthy by the distributed policy. Since the user/host is in control
and thus responsible for policy execution, they can also "pull" down any
key data associated with the TA policy. The only thing they would need
in order to do that, is a common data format for TA keys and their
parameters, signed by some kind of "master" TA policy management key.
That common data format for TA key information is all I currently need.=20

	=20

	[CRW] Section 3.2.1 allows for this, i.e.,  a message to replace
an entire trust anchor store.   This sort of message is essentially a
common data format for TA key information.  Most of the requirements in
the draft are quite fundamental - replay detection, integrity, source
authentication, intended purposes, basic format requirements, etc. - and
would be required by pretty much any TA key information format that
could be defined.

	=20

	We may convince ourselves that we can make a central manager in
control of policy execution on behalf of users/hosts if we write a super
smart protocol (like PKIX TAM), but that would be an illusion. To some
extent we will always need to trust the user/host to carry out the
policy in an appropriate manner.

	=20

	This is the world I'm coming from when approaching this subject.
When I read the req document for TA management I do not recognize any
protocol that fit the needs of my environment. =20

	=20

	[CRW] You should recognize lots in common with protocols in your
environment, namely certificates and certificate revocation lists.
Messages to add trust anchors are very similar to certificates.
Messages to remove certificates are very similar to certificate
revocation lists.  Most of the difficulty comes from limiting the
applicability/scope of the trust anchor keys.  =20

	=20

	This is why I have problems providing constructive feedback on
it.

	 =20

	Stefan Santesson

	Senior Program Manager

	Windows Security, Standards

	  <snip>=20


------_=_NextPart_001_01C936CF.1637991C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20
"urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20
"urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =
=3D=20
"urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20
"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20
"urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20
"http://www.w3.org/TR/REC-html40" xmlns:q =3D=20
"http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 =
=3D=20
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20
"http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20
"http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20
"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec =
=3D=20
"http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20
"http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf =3D=20
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf =3D=20
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver =3D=20
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m =
=3D=20
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels =3D=20
"http://schemas.openxmlformats.org/package/2006/relationships" =
xmlns:ex12t =3D=20
"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m =
=3D=20
"http://schemas.microsoft.com/exchange/services/2006/messages" XMLNS:Z =
=3D=20
"urn:schemas-microsoft-com:" xmlns:st =3D "=01"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16735" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: SimSun;
}
@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @SimSun;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt =
70.85pt; }
P.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
"Calibri","sans-serif"
}
LI.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
"Calibri","sans-serif"
}
DIV.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
"Calibri","sans-serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: =
"Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto
}
PRE {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"; =
mso-style-priority: 99; mso-style-link: "HTML Preformatted Char"
}
SPAN.HTMLPreformattedChar {
	FONT-FAMILY: "Courier New"; mso-style-priority: 99; mso-style-link: =
"HTML Preformatted"; mso-style-name: "HTML Preformatted Char"
}
SPAN.EmailStyle20 {
	COLOR: windowtext; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal
}
SPAN.EmailStyle21 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal
}
SPAN.h41 {
	FONT-WEIGHT: bold; FONT-FAMILY: "Courier New"; mso-style-name: h41
}
SPAN.EmailStyle23 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal
}
SPAN.EmailStyle24 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DSV vLink=3Dpurple link=3Dblue><SPAN =
class=3D218010518-25102008></SPAN><FONT=20
face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D218010518-25102008>responses </SPAN>inline...<SPAN=20
class=3D218010518-25102008></SPAN></FONT></FONT></FONT><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =

  [mailto:[e-mail]] <B>On Behalf Of </B>Stefan=20
  Santesson<BR><B>Sent:</B> Friday, October 24, 2008 10:48 =
PM<BR><B>To:</B>=20
  Kemp, David P.; [e-mail]<BR><B>Subject:</B> RE: Comments on =
the TA=20
  requirements document<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d">Dave<o:p></o:p></SPAN></A></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">This =
is not a=20
  matter of transport protocol. This is a matter of how you manage =
policies and=20
  what protocols you need to support both management and execution of =
these=20
  policies.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">The =
current=20
  requirement document mix together policy management and policy =
execution in=20
  one bucket for TA management.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">The =
policy=20
  management part deals with ensuring that all hosts knows what keys =
they are=20
  allowed to trust.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">The =
policy=20
  execution part deals with obtaining the keys and parameters associated =
with=20
  managed policies and to put them in use in a compliant=20
  manner.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: =
#1f497d">Policy management=20
  is always initiated and managed centrally and pushed down to =
users/hosts, or=20
  at least enforced upon users/hosts in some way or another. There are =
many ways=20
  to do this, but it always involves some kind of central management. =
One way to=20
  do this that is very common in my world, is to use a directory as the =
central=20
  mechanism to publish policies combined with other functions (like =
system=20
  health checks) to make sure hat policies has been downloaded and =
implemented.=20
  In these common cases, there is no need for any new=20
  protocol.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: =
#1f497d">Policy execution is=20
  something that is carried out by the user/host, based on the centrally =

  distributed policy. One part of policy execution in this case is to=20
  obtain/download the TAs that are considered trustworthy by the =
distributed=20
  policy. Since the user/host is in control and thus responsible for =
policy=20
  execution, they can also &#8220;pull&#8221; down any key data =
associated with the TA=20
  policy. The only thing they would need in order to do that, is a =
common data=20
  format for TA keys and their parameters, signed by some kind of =
&#8220;master&#8221; TA=20
  policy management key. That common data format for TA key information =
is all I=20
  currently need.<SPAN class=3D218010518-25102008><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d"><SPAN =

  class=3D218010518-25102008></SPAN></SPAN>&nbsp;</P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d"><SPAN =

  class=3D218010518-25102008>[CRW]&nbsp;Section 3.2.1 allows=20
  for&nbsp;this,&nbsp;i.e., &nbsp;a message to replace an =
entire&nbsp;trust=20
  anchor store.&nbsp;&nbsp; This sort of message is essentially&nbsp;a =
common=20
  data format for TA key information.&nbsp; Most of the requirements in =
the=20
  draft are quite fundamental - replay detection, integrity, source=20
  authentication, intended purposes, basic format requirements, etc. - =
and=20
  would&nbsp;be required by pretty much any TA key information format =
that could=20
  be defined.</SPAN></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d"><SPAN =

  class=3D218010518-25102008>&nbsp;</SPAN><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">We =
may convince=20
  ourselves that we can make a central manager in control of policy =
execution on=20
  behalf of users/hosts if we write a super smart protocol (like PKIX =
TAM), but=20
  that would be an illusion. To some extent we will always need to trust =
the=20
  user/host to carry out the policy in an appropriate=20
  manner.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">This =
is the world=20
  I&#8217;m coming from when approaching this subject. When I read the =
req document=20
  for TA management I do not recognize any protocol that fit the needs =
of my=20
  environment.&nbsp;<SPAN class=3D218010518-25102008><FONT face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d"><SPAN =

  class=3D218010518-25102008></SPAN></SPAN>&nbsp;</P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d"><SPAN =

  class=3D218010518-25102008>[CRW] You should recognize lots in common =
with=20
  protocols in your environment, namely certificates and certificate =
revocation=20
  lists. &nbsp; Messages to add trust anchors are very similar to=20
  certificates.&nbsp; Messages to remove certificates are very similar =
to=20
  certificate revocation lists.&nbsp; Most of the difficulty comes from =
limiting=20
  the applicability/scope of the trust anchor keys.&nbsp;&nbsp;=20
  </SPAN></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d"><SPAN =

  class=3D218010518-25102008>&nbsp;</SPAN><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">This =
is why I have=20
  problems providing constructive feedback on it.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
  Santesson</SPAN></B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 12pt; COLOR: #1f497d; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Senior=20
  Program Manager</SPAN><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Windows=20
  Security, Standards</SPAN></B><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P></DIV>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"><SPAN=20
  class=3D218010518-25102008><FONT face=3DArial=20
  =
color=3D#0000ff>&nbsp;&lt;snip&gt;&nbsp;</FONT></SPAN></SPAN></P></DIV></=
BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C936CF.1637991C--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9P8DEwl065398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Oct 2008 01:13:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9P8DEO5065397; Sat, 25 Oct 2008 01:13:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9P8D3dh065389 for <[e-mail]>; Sat, 25 Oct 2008 01:13:14 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn1.fre.skanova.net (7.3.129) id 4843FAEB02246BCD for [e-mail]; Sat, 25 Oct 2008 10:13:02 +0200
Message-ID: <A21D1706C10C40F79AC1D94FD05F9D45@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Alternative Route. Was: Comments on the TA requirements document
Date: Sat, 25 Oct 2008 10:13:02 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Irrespective of what we think about TA and TAM, I would (if I were
one of the advocates), consider other ways of establishing the goal than
[immediately] going through an IETF process.

So what to do then?  Create an Open Source project where you
in addition to specification also provide code for the platforms
you primarily target.  IF the concept gets traction, you MAY one
day create an RFC but then based on working (proven) code.
This process is probably twice as fast in calendar time.

As an example of a PKI(X)-related standardardization target that
would go nowhere in IETF is the concept of signing data on the web
in a browser session.  Why wouldn't such a thing go nowhere in the
IETF one may wonder?  Because a standards process would most
likely target the traditional view of signatures (a document with an
embedded signature), which in practical terms means supporting
native PDF, ODF, and OOXML formats in the signature "plug-in".
This principle however is based on a lack of understanding how
the web actually works today and even more how user attestations
actually are dealt with in information systems.  Due to that I am
in the processes of creating an Open Source project that is based
on "frozen" document views and detached signatures which is about
1/100 as complex the "right" solution.

A related initiative of mine that wouldn't get any support in PKIX
( http://www.imc.org/ietf-pkix/old-archive-03/msg01663.html )
is challenging schemes like Microsoft's CertEnroll and Mozilla's
generateCRMFRequest () in spite of the fact that they are only
supported by a single vendor respectively.

Anders Rundgren
http://WebPKI.org



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9P2lpOU048495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 19:47:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9P2lpVK048494; Fri, 24 Oct 2008 19:47:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9P2lm6j048486 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 24 Oct 2008 19:47:49 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 25 Oct 2008 03:47:48 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Sat, 25 Oct 2008 03:47:48 +0100
From: Stefan Santesson <[e-mail]>
To: "Kemp, David P." <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Sat, 25 Oct 2008 03:47:45 +0100
Subject: RE: Comments on the TA requirements document
Thread-Topic: Comments on the TA requirements document
Thread-Index: Ack1Gw5RwCiacYlDQg28ouWioo7jOwAAqt+wAADFKSAAAPbXgAAKFblQAD7RurA=
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D32195A6F405DEAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Dave

This is not a matter of transport protocol. This is a matter of how you man=
age policies and what protocols you need to support both management and exe=
cution of these policies.

The current requirement document mix together policy management and policy =
execution in one bucket for TA management.

The policy management part deals with ensuring that all hosts knows what ke=
ys they are allowed to trust.
The policy execution part deals with obtaining the keys and parameters asso=
ciated with managed policies and to put them in use in a compliant manner.

Policy management is always initiated and managed centrally and pushed down=
 to users/hosts, or at least enforced upon users/hosts in some way or anoth=
er. There are many ways to do this, but it always involves some kind of cen=
tral management. One way to do this that is very common in my world, is to =
use a directory as the central mechanism to publish policies combined with =
other functions (like system health checks) to make sure hat policies has b=
een downloaded and implemented. In these common cases, there is no need for=
 any new protocol.

Policy execution is something that is carried out by the user/host, based o=
n the centrally distributed policy. One part of policy execution in this ca=
se is to obtain/download the TAs that are considered trustworthy by the dis=
tributed policy. Since the user/host is in control and thus responsible for=
 policy execution, they can also "pull" down any key data associated with t=
he TA policy. The only thing they would need in order to do that, is a comm=
on data format for TA keys and their parameters, signed by some kind of "ma=
ster" TA policy management key. That common data format for TA key informat=
ion is all I currently need.
We may convince ourselves that we can make a central manager in control of =
policy execution on behalf of users/hosts if we write a super smart protoco=
l (like PKIX TAM), but that would be an illusion. To some extent we will al=
ways need to trust the user/host to carry out the policy in an appropriate =
manner.

This is the world I'm coming from when approaching this subject. When I rea=
d the req document for TA management I do not recognize any protocol that f=
it the needs of my environment.
This is why I have problems providing constructive feedback on it.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Kemp, David P.
Sent: den 23 oktober 2008 23:02
To: [e-mail]
Subject: RE: Comments on the TA requirements document

Stefan,

Is there ever a distinction to be made at the application layer between pus=
h and pull?  Like picking TCP vs UDP, there are performance reasons for cho=
osing one transport vs. another, but at the Functional Requirements level, =
the goal is for recipients to remain up-to-date regardless of who initiates=
 a connection.   Is messaging push or pull?  (Sending email via SMTP is pus=
h, receiving email via IMAP is pull, who knows how to characterize IM trans=
port over XMPP or text transport over SMS; in all cases the user's desired =
end result is simply to see messages shortly after they are written).    Pu=
sh vs. pull makes even less sense in simplex transport scenarios - is recei=
ving a pager message or a stock quote over FM radio subcarrier a push or pu=
ll transaction?

As Carl says, I don't see how anything in the TA requirements favors either=
 management station initiated (snmp?) or client initiated (imap? http?) tra=
nsport.

Dave


From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Carl Wallace
Sent: Thursday, October 23, 2008 11:35 AM
To: Stefan Santesson; [e-mail]
Subject: RE: Comments on the TA requirements document

What about this requirement could not be met by a TA mgmt message addressed=
 to all TA stores for which a manager is responsible and pulled from a dire=
ctory?  This does not require push.

________________________________
From: Stefan Santesson [mailto:[e-mail]]
Sent: Thursday, October 23, 2008 11:24 AM
To: Carl Wallace; [e-mail]
Subject: RE: Comments on the TA requirements document
Carl,



[CRW] I don't see the confusion w.r.t push/pull. There is no intent to requ=
ire a push model exclusively or even favor a push model.  What text is crea=
ting this impression?

This is clearly requirements for an active push protocol. For example:

3.3.1.  Functional Requirements

   A protocol for TA management must allow a TA management transaction
   to be directed to:

      All TA stores for which the manager is responsible
      An enumerated list of one or more groups of trust anchor stores
      An individual trust anchor store


This is only relevant requirement for a push model. And it goes on and on t=
hroughout the requirements.
And that is fine.  I'd rather have it saying that it is requirements for a =
specific type of TA management protocol out of many possible management mod=
els.



[CRW] There is no pretending that mechanisms do not exist.  This draft simp=
ly defines a set of requirements for these mechanisms with an aim of establ=
ishing an interoperable solution.  If existing mechanisms meet the requirem=
ents or can be modified to do so, great.  Right now, we're just trying to d=
efine the set of requirements.

My point is that these requirements does not fit the policy management mode=
l that is used in the systems I know of. The main reason is that the curren=
t document describes requirements for active direct management of TA stores=
 instead of a pull model as a result of a separate policy enforcement solut=
ion.



[CRW] Assuming the language is clarified such that push is not the focus, w=
hat remaining concerns do you have?

I don't think that is a language issue. I would rather accept that this is =
a requirements document for a push oriented protocol, but to clarify that o=
ther models may be used where this protocol may be redundant.
It would also be great to position this document among possible TA manageme=
nt models.

If I could wish for something more, then that would be to separate out the =
requirements for standardizing the syntax of a TA list form the requirement=
s on a TA management protocol.
The reason is that we agreed to run these specifications separately.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: Carl Wallace [mailto:[e-mail]]
Sent: den 23 oktober 2008 17:03
To: Stefan Santesson; [e-mail]
Subject: RE: Comments on the TA requirements document

inline...

________________________________
From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Stefan Santesson
Sent: Thursday, October 23, 2008 10:24 AM
To: [e-mail]
Subject: Comments on the TA requirements document
Commenting on draft-ietf-pkix-ta-mgmt-reqs-01, both in general and as respo=
nse to Denis Detailed comments.
http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01

I thought I better post this comment as a separate e-mail to keep it clear =
from other threads.

On the general issue I am, as I have stated before,  not overly enthusiasti=
c about the TA management protocol. The main reason is that I can't see tha=
t I need one.

TA management is just another aspect of policy management and modern comple=
x  IT environments already have systems and tools to deal with policy manag=
ement. It may not be pretty, and it may not be generic, but it's there and =
we can't pretend it's not.

[CRW] There is no pretending that mechanisms do not exist.  This draft simp=
ly defines a set of requirements for these mechanisms with an aim of establ=
ishing an interoperable solution.  If existing mechanisms meet the requirem=
ents or can be modified to do so, great.  Right now, we're just trying to d=
efine the set of requirements.

TA management is also subordinate to the larger security management aspects=
 of an IT environment. If we can't manage user access, policy distribution =
and policy enforcement in a large IT network, all bets are off. The most ge=
nius TA management protocol in the world won't save us. And since we alread=
y depend on the current security management for success, we night as well a=
llow it to manage the policies concerning trust in TAs.



I believe more in a TA management solution where clients "retrieve" the TA =
they have been instructed to use by the overall policy management infrastru=
cture (whatever it is), rather than a model where a TA Manager push this in=
formation onto the client and actively manages the TA stores in the client =
and server hosts.



[CRW] I don't see the confusion w.r.t push/pull. There is no intent to requ=
ire a push model exclusively or even favor a push model.  What text is crea=
ting this impression?





Denis comments:

I want to address Denis comments in principle rather than detailed in depth=
 at this point.



I agree in principle with Denis observation that the current approach is st=
ructured as a push model over a pull model. This is a disconnect from how m=
ost systems and current protocols work today. I strongly encourage the pull=
 model to be the main and default principle for TA management.

[CRW] See above re: push/pull.



I disagree that a TA Management structure need to be structured around the =
root cross certification scheme of CMP (old with new and new with old signi=
ng). It should be possible, but this is seldom implemented in reality.



I disagree with Denis on the issue of including validation policies into th=
e requirements of this protocol.

The reasons are again that trust policy management is a lot larger than wha=
t we possibly can define in the PKIX working group. Whatever we would come =
up with other than standardized protocol elements to be used by other proto=
cols, we will end up guessing and most likely miss the target, or just serv=
e a few corner cases with a complex protocol.







Comments on the TA req document:



I think there is one fundamental flaw in the general assumptions of the doc=
ument:



>From 1.1



   Trust relationships between PKIs are negotiated by policy
   authorities.  Negotiations frequently require significant time to
   ensure all participating parties' requirements are satisfied.  These
   requirements are expressed, to some extent, in public key
   certificates via policy constraints, name constraints and etc.  In
   order for these requirements to be enforced, trust anchor stores must
   be managed in accord with policy authority intentions and avoid
   circumventing constraints defined in a cross-certificate by
   recognizing the subject of the cross certificate as a trust anchor.





I find this assumption wrong as management of trust anchors is a matter of =
local policy only.

The whole path processing logic is designed so that the statements made by =
each CA will be enforced appropriately in accordance with the TA that the l=
ocal relying party has chosen as a result of local policy only.



[CRW] I can see where this text is confusing.  The policy authority referen=
ced here is the local policy authority.  The point of the requirement is th=
at when a local policy authority issues a cross certificate to an external =
enterprise root, it should not be possible to avoid the constraints include=
d in the cross-cert by installing the self-signed certificate issued to the=
 subject of the cross-certificate.  The trust anchor stores subject to the =
local policy authority must be managed in accord with the policy authority'=
s intentions or all bets are off.



This defeats a substantial part of the rationale for having a push model ra=
ther than a pull model.

[CRW] See above re: push/pull.





Conclusion



The working group has already decided to adopt this work, and it is not my =
intention to try to block its progress.

I'm just expressing the rationale why I doubt its usefulness in its current=
 form and why I have problems providing detailed comments on the requiremen=
ts document.



[CRW] Assuming the language is clarified such that push is not the focus, w=
hat remaining concerns do you have?









Stefan Santesson
Senior Program Manager
Windows Security, Standards


--_000_9F11911AED01D24BAA1C2355723C3D32195A6F405DEAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.h41
	{mso-style-name:h41;
	font-family:"Courier New";
	font-weight:bold;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style=
=3D'color:
#1F497D'>Dave<o:p></o:p></span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>This is not=
 a matter
of transport protocol. This is a matter of how you manage policies and what
protocols you need to support both management and execution of these polici=
es.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>The current
requirement document mix together policy management and policy execution in=
 one
bucket for TA management.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>The policy =
management
part deals with ensuring that all hosts knows what keys they are allowed to
trust.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>The policy =
execution part
deals with obtaining the keys and parameters associated with managed polici=
es
and to put them in use in a compliant manner.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Policy mana=
gement is always
initiated and managed centrally and pushed down to users/hosts, or at least
enforced upon users/hosts in some way or another. There are many ways to do
this, but it always involves some kind of central management. One way to do=
 this
that is very common in my world, is to use a directory as the central mecha=
nism
to publish policies combined with other functions (like system health check=
s) to
make sure hat policies has been downloaded and implemented. In these common=
 cases,
there is no need for any new protocol.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Policy exec=
ution is something
that is carried out by the user/host, based on the centrally distributed
policy. One part of policy execution in this case is to obtain/download the=
 TAs
that are considered trustworthy by the distributed policy. Since the user/h=
ost
is in control and thus responsible for policy execution, they can also &#82=
20;pull&#8221;
down any key data associated with the TA policy. The only thing they would =
need
in order to do that, is a common data format for TA keys and their paramete=
rs,
signed by some kind of &#8220;master&#8221; TA policy management key. That
common data format for TA key information is all I currently need.<o:p></o:=
p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>We may conv=
ince
ourselves that we can make a central manager in control of policy execution=
 on
behalf of users/hosts if we write a super smart protocol (like PKIX TAM), b=
ut
that would be an illusion. To some extent we will always need to trust the
user/host to carry out the policy in an appropriate manner.<o:p></o:p></spa=
n></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>This is the=
 world I&#8217;m
coming from when approaching this subject. When I read the req document for=
 TA
management I do not recognize any protocol that fit the needs of my
environment. <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>This is why=
 I have
problems providing constructive feedback on it.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Kemp, David P.<br=
>
<b>Sent:</b> den 23 oktober 2008 23:02<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> RE: Comments on the TA requirements document<o:p></o:p></sp=
an></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Stefan,<o:p=
></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Is there ev=
er a
distinction to be made at the application layer between push and pull?&nbsp=
;
Like picking TCP vs UDP, there are performance reasons for choosing one
transport vs. another, but at the Functional Requirements level, the goal i=
s
for recipients to remain up-to-date regardless of who initiates a
connection.&nbsp; &nbsp;Is messaging push or pull?&nbsp; (Sending email via
SMTP is push, receiving email via IMAP is pull, who knows how to characteri=
ze
IM transport over XMPP or text transport over SMS; in all cases the
user&#8217;s desired end result is simply to see messages shortly after the=
y
are written).&nbsp;&nbsp;&nbsp; Push vs. pull makes even less sense in simp=
lex
transport scenarios &#8211; is receiving a pager message or a stock quote o=
ver
FM radio subcarrier a push or pull transaction? <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>As Carl say=
s, I
don&#8217;t see how anything in the TA requirements favors either managemen=
t
station initiated (snmp?) or client initiated (imap? http?) transport.<o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>Dave<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Carl Wallace<br>
<b>Sent:</b> Thursday, October 23, 2008 11:35 AM<br>
<b>To:</b> Stefan Santesson; [e-mail]<br>
<b>Subject:</b> RE: Comments on the TA requirements document<o:p></o:p></sp=
an></p>

</div>

</div>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:blue'>What about this requirement could not be met by a TA mgmt messa=
ge
addressed to all TA stores for which a manager is responsible and pulled fr=
om a
directory?&nbsp; This does not require push.</span><span style=3D'font-size=
:12.0pt;
font-family:"Times New Roman","serif"'><o:p></o:p></span></p>

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

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

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span lan=
g=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>

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

</span></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></=
b><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
Stefan
Santesson [mailto:[e-mail]] <br>
<b>Sent:</b> Thursday, October 23, 2008 11:24 AM<br>
<b>To:</b> Carl Wallace; [e-mail]<br>
<b>Subject:</b> RE: Comments on the TA requirements document</span><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New Roman","serif=
"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Carl,<o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW] I don't see the
confusion w.r.t push/pull. There is no intent to require a push model
exclusively&nbsp;or even favor a push model.&nbsp; What text is creating th=
is
impression?</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>This is cle=
arly
requirements for an active push protocol. For example:<o:p></o:p></span></p=
>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><a name=3Dsection-3.3.1><b><span lang=3DEN style=3D'fo=
nt-size:
12.0pt;font-family:"Courier New"'>3.3.1</span></b></a><b><span lang=3DEN
style=3D'font-size:12.0pt;font-family:"Courier New"'>.&nbsp; Functional
Requirements</span></b><span lang=3DEN style=3D'font-size:12.0pt;font-famil=
y:"Courier New"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'>&nbsp;&nbsp;
A protocol for TA management must allow a TA management transaction<o:p></o=
:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'>&nbsp;&nbsp;
to be directed to:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
All TA stores for which the manager is responsible<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
An enumerated list of one or more groups of trust anchor stores<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
An individual trust anchor store<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>This is onl=
y relevant
requirement for a push model. And it goes on and on throughout the
requirements.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>And that is=
 fine.
&nbsp;I&#8217;d rather have it saying that it is requirements for a specifi=
c
type of TA management protocol out of many possible management models.<o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW]&nbsp;There is no
pretending that mechanisms do not exist.&nbsp; This draft simply defines a =
set
of requirements for these mechanisms with an aim of establishing&nbsp;an
interoperable solution.&nbsp; If existing mechanisms meet the requirements =
or
can be modified to do so, great.&nbsp; Right now, we're just trying to
define&nbsp;the set of requirements.</span><span lang=3DEN-US><o:p></o:p></=
span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>My point is=
 that
these requirements does not fit the policy management model that is used in=
 the
systems I know of. The main reason is that the current document describes
requirements for active direct management of TA stores instead of a pull mo=
del
as a result of a separate policy enforcement solution.<o:p></o:p></span></p=
>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW] Assuming the lang=
uage
is clarified such that push is not the focus,&nbsp;what remaining concerns =
do
you have?</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"C=
alibri","sans-serif"'>&nbsp;</span><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:blue'>
</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I don&#8217=
;t think
that is a language issue. I would rather accept that this is a requirements
document for a push oriented protocol, but to clarify that other models may=
 be
used where this protocol may be redundant.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>It would al=
so be
great to position this document among possible TA management models.<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>If I could =
wish for
something more, then that would be to separate out the requirements for
standardizing the syntax of a TA list form the requirements on a TA managem=
ent
protocol.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>The reason =
is that we
agreed to run these specifications separately.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> Carl Wallace [mailto:CWallace@cygnacom.=
com]
<br>
<b>Sent:</b> den 23 oktober 2008 17:03<br>
<b>To:</b> Stefan Santesson; [e-mail]<br>
<b>Subject:</b> RE: Comments on the TA requirements document<o:p></o:p></sp=
an></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:blue'>inline...</span><span style=3D'font-size:12.0pt;font-family:"Ti=
mes New Roman","serif"'><o:p></o:p></span></p>

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

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

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span lan=
g=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>

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

</span></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></=
b><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[e-mail] [mailto:[e-mail]] <b>On Be=
half
Of </b>Stefan Santesson<br>
<b>Sent:</b> Thursday, October 23, 2008 10:24 AM<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> Comments on the TA requirements document</span><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New Roman","serif=
"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Commenting on
draft-ietf-pkix-ta-mgmt-reqs-01, both in general and as response to Denis
Detailed comments.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><a
href=3D"http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01">http://=
tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01</a><o:p></o:p></span></=
p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I thought I better post this commen=
t as a
separate e-mail to keep it clear from other threads.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>On the general issue I am, as I hav=
e stated
before, &nbsp;not overly enthusiastic about the TA management protocol. The
main reason is that I can&#8217;t see that I need one.<o:p></o:p></span></p=
>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>TA management is just another as=
pect
of policy management and modern complex &nbsp;IT environments already have
systems and tools to deal with policy management. It may not be pretty, and=
 it
may not be generic, but it&#8217;s there and we can&#8217;t pretend it&#821=
7;s
not.</span><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial"=
,"sans-serif";
color:blue'>&nbsp;</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW]&nbsp;There is no
pretending that mechanisms do not exist.&nbsp; This draft simply defines a =
set
of requirements for these mechanisms with an aim of establishing&nbsp;an
interoperable solution.&nbsp; If existing mechanisms meet the requirements =
or
can be modified to do so, great.&nbsp; Right now, we're just trying to
define&nbsp;the set of requirements.</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>TA management is also subordinat=
e to
the larger security management aspects of an IT environment. If we can&#821=
7;t
manage user access, policy distribution and policy enforcement in a large I=
T
network, all bets are off. The most genius TA management protocol in the wo=
rld
won&#8217;t save us. And since we already depend on the current security
management for success, we night as well allow it to manage the policies
concerning trust in TAs.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I believe more in a TA managemen=
t
solution where clients &#8220;retrieve&#8221; the TA they have been instruc=
ted
to use by the overall policy management infrastructure (whatever it is), ra=
ther
than a model where a TA Manager push this information onto the client and
actively manages the TA stores in the client and server hosts. <o:p></o:p><=
/span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW] I don't see the
confusion w.r.t push/pull. There is no intent to require a push model
exclusively&nbsp;or even favor a push model.&nbsp; What text is creating th=
is
impression?</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif"'><o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><u><span lang=3DEN-US
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Denis comment=
s:<o:p></o:p></span></u></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I want to address Denis comments=
 in
principle rather than detailed in depth at this point.<o:p></o:p></span></p=
>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I agree in principle with Denis
observation that the current approach is structured as a push model over a =
pull
model. This is a disconnect from how most systems and current protocols wor=
k
today. I strongly encourage the pull model to be the main and default princ=
iple
for TA management.</span><span lang=3DEN-US style=3D'font-size:10.0pt;font-=
family:
"Arial","sans-serif";color:blue'>&nbsp;</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW] See above re:
push/pull.</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"=
Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I disagree that a TA Management
structure need to be structured around the root cross certification scheme =
of
CMP (old with new and new with old signing). It should be possible, but thi=
s is
seldom implemented in reality.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I disagree with Denis on the iss=
ue
of including validation policies into the requirements of this protocol.<o:=
p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>The reasons are again that trust
policy management is a lot larger than what we possibly can define in the P=
KIX
working group. Whatever we would come up with other than standardized proto=
col
elements to be used by other protocols, we will end up guessing and most li=
kely
miss the target, or just serve a few corner cases with a complex protocol.<=
/span><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:blue'>&nbsp;</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><u><span lang=3DEN-US
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Comments on t=
he TA
req document:&nbsp;<o:p></o:p></span></u></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I think there is one fundamental
flaw in the general assumptions of the document:&nbsp;<o:p></o:p></span></p=
>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>From 1.1<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Calibri","sans-serif"'>&nbsp;&nbsp; Trust relationships
between PKIs are negotiated by policy<br>
&nbsp;&nbsp; authorities.&nbsp; Negotiations frequently require significant
time to<br>
&nbsp;&nbsp; ensure all participating parties' requirements are
satisfied.&nbsp; These<br>
&nbsp;&nbsp; requirements are expressed, to some extent, in public key<br>
&nbsp;&nbsp; certificates via policy constraints, name constraints and
etc.&nbsp; In<br>
&nbsp;&nbsp; order for these requirements to be enforced, trust anchor <u>s=
tores
must<br>
&nbsp;&nbsp; be managed in accord with policy authority intentions</u> and
avoid<br>
&nbsp;&nbsp; circumventing constraints defined in a cross-certificate by<br=
>
&nbsp;&nbsp; recognizing the subject of the cross certificate as a trust
anchor.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I find this assumption wrong as
management of trust anchors is a matter of local policy only.<o:p></o:p></s=
pan></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>The whole path processing logic =
is
designed so that the statements made by each CA will be enforced appropriat=
ely
in accordance with the TA that the local relying party has chosen as a resu=
lt
of local policy only.</span><span lang=3DEN-US style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif";color:blue'>&nbsp;</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'>&nbsp;<o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW]&nbsp;I can see wh=
ere
this text is confusing.&nbsp; The policy authority referenced here is the l=
ocal
policy authority.&nbsp; The point of the requirement is that when a local
policy authority issues a cross certificate&nbsp;to an
external&nbsp;enterprise&nbsp;root, it should not be possible to avoid the =
constraints
included in the cross-cert by installing the self-signed certificate issued=
 to
the subject of the cross-certificate.&nbsp;&nbsp;The trust anchor stores
subject&nbsp;to the local policy authority must be managed in accord with t=
he
policy authority's&nbsp;intentions or all bets are off.</span><span lang=3D=
EN-US
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></=
o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>This defeats a substantial part =
of
the rationale for having a push model rather than a pull model.</span><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:blue'>&nbsp;</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW] See above re:
push/pull.</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"=
Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><u><span lang=3DEN-US
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Conclusion<o:=
p></o:p></span></u></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>The working group has already
decided to adopt this work, and it is not my intention to try to block its =
progress.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I&#8217;m just expressing the
rationale why I doubt its usefulness in its current form and why I have
problems providing detailed comments on the requirements document.</span><s=
pan
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:blue'>&nbsp;</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'>&nbsp;<o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW] Assuming the lang=
uage
is clarified such that push is not the focus,&nbsp;what remaining concerns =
do
you have?</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"C=
alibri","sans-serif"'>&nbsp;</span><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:blue'>
</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif"'><o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</blockquote>

</div>

</blockquote>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D32195A6F405DEAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9P2JBDW046238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 19:19:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9P2JBlp046237; Fri, 24 Oct 2008 19:19:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9P2J9K9046231 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 24 Oct 2008 19:19:11 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 25 Oct 2008 03:19:09 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Sat, 25 Oct 2008 03:19:09 +0100
From: Stefan Santesson <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Sat, 25 Oct 2008 03:19:08 +0100
Subject: Rationales for CA clearance constraints
Thread-Topic: Rationales for CA clearance constraints
Thread-Index: Ack2SA9aLjZZzSbqQcypOookjCoC2w==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D32195A6F405CEAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

The discussion on CA clearance constraints have made me wonder about some b=
asic rationales for writing this standard in the manner suggested.

It would be great if those advocating this solution could help me understan=
d better. I have 3 major questions:



1)      Why do this in certificates at all? It seems that most people are a=
greeing that certificates is not a good place to specify the clearance of a=
 subject. Are we suggesting this purely because some "important" organizati=
ons have decided to implement this anyway and would feel better about it if=
 it became a standard, or do we have anyone who want to speak up and explai=
n why this actually is a great idea?



2)      Why do we need the constraints mechanism? The constraints processin=
g logic is without any doubt the most problematic. The basic problem is alm=
ost obvious. Because we can't make a rigid standard for expressing neither =
clearance levels, nor the context within which they apply, it seems equally=
 impossible to specify exactly how to constrain this in certificate path pr=
ocessing. The result is an open logic that may differ from case to case, wh=
ich is very challenging to implement.



3)      Does viable alternatives exist? This goes both for clearance in cer=
tificates as well as the constraints logic. For example, could one simply d=
efine certificate policies, where one policy could define both clearance le=
vel and context, and then use policy constraints. If we would lose some fun=
ctionality, would that differences be big enough to merit a new standardize=
d way to do this?



Stefan Santesson
Senior Program Manager
Windows Security, Standards


--_000_9F11911AED01D24BAA1C2355723C3D32195A6F405CEAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1230459812;
	mso-list-type:hybrid;
	mso-list-template-ids:-1819002030 69009425 69009433 69009435 69009423 6900=
9433 69009435 69009423 69009433 69009435;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>The discussion on CA clearance cons=
traints
have made me wonder about some basic rationales for writing this standard i=
n
the manner suggested.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>It would be great if those advocati=
ng this
solution could help me understand better. I have 3 major questions:<o:p></o=
:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US><span style=3D'mso-list:Ignore'>1)<span style=3D'font:7.0pt "T=
imes New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><b><span lang=3DEN-US>Why do this in certifi=
cates
at all?</span></b><span lang=3DEN-US> It seems that most people are agreein=
g that
certificates is not a good place to specify the clearance of a subject. Are=
 we
suggesting this purely because some &#8220;important&#8221; organizations h=
ave
decided to implement this anyway and would feel better about it if it becam=
e a
standard, or do we have anyone who want to speak up and explain why this
actually is a great idea?<o:p></o:p></span></p>

<p class=3DMsoListParagraph><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US><span style=3D'mso-list:Ignore'>2)<span style=3D'font:7.0pt "T=
imes New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><b><span lang=3DEN-US>Why do we need the con=
straints
mechanism?</span></b><span lang=3DEN-US> The constraints processing logic i=
s
without any doubt the most problematic. The basic problem is almost obvious=
. Because
we can&#8217;t make a rigid standard for expressing neither clearance level=
s,
nor the context within which they apply, it seems equally impossible to spe=
cify
exactly how to constrain this in certificate path processing. The result is=
 an open
logic that may differ from case to case, which is very challenging to imple=
ment.
<o:p></o:p></span></p>

<p class=3DMsoListParagraph><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US><span style=3D'mso-list:Ignore'>3)<span style=3D'font:7.0pt "T=
imes New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><b><span lang=3DEN-US>Does viable alternativ=
es
exist?</span></b><span lang=3DEN-US> This goes both for clearance in certif=
icates
as well as the constraints logic. For example, could one simply define
certificate policies, where one policy could define both clearance level an=
d
context, and then use policy constraints. If we would lose some functionali=
ty,
would that differences be big enough to merit a new standardized way to do
this?<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D32195A6F405CEAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9P20un0043879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 19:00:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9P20udC043878; Fri, 24 Oct 2008 19:00:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9P20hrp043850 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 24 Oct 2008 19:00:55 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sat, 25 Oct 2008 03:00:43 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Sat, 25 Oct 2008 03:00:42 +0100
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Sat, 25 Oct 2008 03:00:41 +0100
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: Ack127PEa97rVbqZSeqU5dnzEIHPFAAAFzigAADFPLAAGSvgQA==
Message-ID: <[e-mail]>
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: 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,

What you suggest comes closer to the exercise I think need to be done befor=
e we decide what to do with this.

To standardize constraints with undefined processing rules feels to me like=
 wanting to have one's cake and eat it too.
I think it is absolutely necessary to limit the logic so that an implementa=
tion can process any legal data within it. Otherwise the basic idea with ha=
ving a standard seems a bit lost.

Now, processing all data does not mean that you know the meaning of all dat=
a, but at least you should be able to process it and hand it over to the ne=
xt layer.

I would also like to have some rationales clarified, but I will ask for tha=
t in a separate thread.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Santosh Chokhani
> Sent: den 24 oktober 2008 15:52
> To: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Stefan,
>
> As stated in other strands of this thread, this will be handled by
> enhancing the I-D for a specific set of syntaxes of security categories
> or by deprecating the security categories from the clearance
> constraints.  The latter can obviate the need for taking the
> intersection of security categories.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Stefan Santesson
> Sent: Friday, October 24, 2008 9:27 AM
> To: Timothy J. Miller; Russ Housley
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Thanks for putting such good words to it :)
>
> Yes, that sounds very much like what I meant.
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
> > -----Original Message-----
> > From: Timothy J. Miller [mailto:[e-mail]]
> > Sent: den 24 oktober 2008 15:23
> > To: Russ Housley
> > Cc: Stefan Santesson; [e-mail]
> > Subject: Re: draft-turner-caclearanceconstraints-01.txt
> >
> > Russ Housley wrote:
> >
> > > Where does the document say anything about mapping between security
> > > policies?
> >
> > I don't think that's what he means.  I think what he's driving at is:
> > how does a single vendor writing a single chaining library do it such
> > that the code works under any arbitrary intersection logic the end
> user
> > may specify?
> >
> > Did I get that right, Stefan?
> >
> > -- Tim
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9OFOhcX005199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 08:24:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9OFOhfM005198; Fri, 24 Oct 2008 08:24:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9OFOVLD005172 for <[e-mail]>; Fri, 24 Oct 2008 08:24:42 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 7104 invoked from network); 24 Oct 2008 15:10:56 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;24 Oct 2008 15:10:56 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 24 Oct 2008 15:10:56 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Fri, 24 Oct 2008 11:24:30 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: Ack16rSnQI1hy8obQ7mmcfFhmjilwAAACOXg
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[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>

Tim,

An example of ANY is Algorithm Identifier which appears in Signature,
SIGNED MACRO, and SPKI.

So, there is a precedence for it.

I was hoping to define 2-3 specific structures: An existing one in use;
one we all agree on if this I-D is adopted as work item; and an optional
one that may be useful to what folks ate doing for NFS.  2 and 3 could
be combined.=20

For deprecation approaches, see my post from Thursday October 23 from a
strand on this thread.

-----Original Message-----
From: Timothy J. Miller [mailto:[e-mail]]=20
Sent: Friday, October 24, 2008 11:11 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: draft-turner-caclearanceconstraints-01.txt

Santosh Chokhani wrote:

> As stated in other strands of this thread, this will be handled by
> enhancing the I-D for a specific set of syntaxes of security
categories
> or by deprecating the security categories from the clearance
> constraints.  The latter can obviate the need for taking the
> intersection of security categories.

IMHO, picking a couple of examples for category intersection doesn't=20
solve the problem for coders, and might well be taken as implying that=20
the examples are the only possibilities.

If these are the two options then I'd vote for going beyond deprecation=20
and define clearance constraints *only* for sensitivity.  The constraint

algorithm then becomes the much simpler task of finding the minimum=20
value of classList in the chain.

-- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9OFAqDv004293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 08:10:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9OFAqhx004292; Fri, 24 Oct 2008 08:10:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9OFAoZd004284 for <[e-mail]>; Fri, 24 Oct 2008 08:10:51 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9OFAora014450 for <[e-mail]>; Fri, 24 Oct 2008 11:10:50 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9OFAod4014445; Fri, 24 Oct 2008 11:10:50 -0400
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 24 Oct 2008 11:10:50 -0400
Message-ID: <[e-mail]>
Date: Fri, 24 Oct 2008 10:10:47 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: <[e-mail]>
Subject: Re: draft-turner-caclearanceconstraints-01.txt
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070705090500010204090909"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms070705090500010204090909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Santosh Chokhani wrote:

> As stated in other strands of this thread, this will be handled by
> enhancing the I-D for a specific set of syntaxes of security categories
> or by deprecating the security categories from the clearance
> constraints.  The latter can obviate the need for taking the
> intersection of security categories.

IMHO, picking a couple of examples for category intersection doesn't 
solve the problem for coders, and might well be taken as implying that 
the examples are the only possibilities.

If these are the two options then I'd vote for going beyond deprecation 
and define clearance constraints *only* for sensitivity.  The constraint 
algorithm then becomes the much simpler task of finding the minimum 
value of classList in the chain.

-- Tim


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjQxNTEwNDdaMCMGCSqGSIb3DQEJBDEWBBRVnJgkdrZgPGPhu3ZTAejQKNEWLDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgDJudYU3l9njT/CcllzztmMbJtHNj670MNdhjEDXq4jsuyZSVJBg9lugVhXv
rye21dn1zQHlRPDxde4eN22GpdBR2E5WPRqjCFyWxTbr3H0q07q5joekTYwwq2gWkvcPdP8H
sHaRWIOOT47L52fLe9skJ0AbvFZk/AgLFaefaOebAAAAAAAA
--------------ms070705090500010204090909--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9ODpX1m099521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 06:51:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9ODpXPH099520; Fri, 24 Oct 2008 06:51:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9ODpWpU099514 for <[e-mail]>; Fri, 24 Oct 2008 06:51:33 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 6383 invoked from network); 24 Oct 2008 13:37:57 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;24 Oct 2008 13:37:57 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 24 Oct 2008 13:37:57 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Fri, 24 Oct 2008 09:51:31 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: Ack127PEa97rVbqZSeqU5dnzEIHPFAAAFzigAADFPLA=
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[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>

Stefan,

As stated in other strands of this thread, this will be handled by
enhancing the I-D for a specific set of syntaxes of security categories
or by deprecating the security categories from the clearance
constraints.  The latter can obviate the need for taking the
intersection of security categories.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Friday, October 24, 2008 9:27 AM
To: Timothy J. Miller; Russ Housley
Cc: [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt


Thanks for putting such good words to it :)

Yes, that sounds very much like what I meant.

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Timothy J. Miller [mailto:[e-mail]]
> Sent: den 24 oktober 2008 15:23
> To: Russ Housley
> Cc: Stefan Santesson; [e-mail]
> Subject: Re: draft-turner-caclearanceconstraints-01.txt
>
> Russ Housley wrote:
>
> > Where does the document say anything about mapping between security
> > policies?
>
> I don't think that's what he means.  I think what he's driving at is:
> how does a single vendor writing a single chaining library do it such
> that the code works under any arbitrary intersection logic the end
user
> may specify?
>
> Did I get that right, Stefan?
>
> -- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9ODQxXc098538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 06:26:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9ODQxK4098537; Fri, 24 Oct 2008 06:26:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9ODQkx2098525 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 24 Oct 2008 06:26:58 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 24 Oct 2008 14:26:46 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Fri, 24 Oct 2008 14:26:46 +0100
From: Stefan Santesson <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>, Russ Housley <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Fri, 24 Oct 2008 14:26:45 +0100
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: Ack127PEa97rVbqZSeqU5dnzEIHPFAAAFzig
Message-ID: <[e-mail]>
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: 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 for putting such good words to it :)

Yes, that sounds very much like what I meant.

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Timothy J. Miller [mailto:[e-mail]]
> Sent: den 24 oktober 2008 15:23
> To: Russ Housley
> Cc: Stefan Santesson; [e-mail]
> Subject: Re: draft-turner-caclearanceconstraints-01.txt
>
> Russ Housley wrote:
>
> > Where does the document say anything about mapping between security
> > policies?
>
> I don't think that's what he means.  I think what he's driving at is:
> how does a single vendor writing a single chaining library do it such
> that the code works under any arbitrary intersection logic the end user
> may specify?
>
> Did I get that right, Stefan?
>
> -- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9ODNDKF098301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 06:23:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9ODNDXk098300; Fri, 24 Oct 2008 06:23:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9ODN18S098288 for <[e-mail]>; Fri, 24 Oct 2008 06:23:12 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9ODN041024507 for <[e-mail]>; Fri, 24 Oct 2008 09:23:00 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9ODN0XE024502; Fri, 24 Oct 2008 09:23:00 -0400
Received: from [129.83.200.3] (129.83.200.3) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 24 Oct 2008 09:23:00 -0400
Message-ID: <[e-mail]>
Date: Fri, 24 Oct 2008 08:22:54 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Stefan Santesson <[e-mail]>, <[e-mail]>
Subject: Re: draft-turner-caclearanceconstraints-01.txt
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070602050900040801090006"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms070602050900040801090006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Russ Housley wrote:

> Where does the document say anything about mapping between security 
> policies?

I don't think that's what he means.  I think what he's driving at is: 
how does a single vendor writing a single chaining library do it such 
that the code works under any arbitrary intersection logic the end user 
may specify?

Did I get that right, Stefan?

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjQxMzIyNTRaMCMGCSqGSIb3DQEJBDEWBBTAbEvHXq9ENLlqv2NRH7h/lR43qTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgCZEbeCnvun5tq23gZDeAZyYpRgIBs4H+4NsWE0lvG4PGFbhQLPdaAE2WiCw
acW/dnu+qzpDZHxAnZMVqhXfxM7dMD0bJCL6OJ5j0gryMX6Y0zwDwy66CmcsDQxzgRMYe1gR
6NbOG1gL3kRc1wipLkiN6gOv3gLxLKASKXMiZhvxAAAAAAAA
--------------ms070602050900040801090006--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9OC7Bdn091963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 05:07:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9OC7BTM091962; Fri, 24 Oct 2008 05:07:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9OC6xio091941 for <[e-mail]>; Fri, 24 Oct 2008 05:07:10 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 5578 invoked from network); 24 Oct 2008 11:53:24 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;24 Oct 2008 11:53:24 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 24 Oct 2008 11:53:22 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Fri, 24 Oct 2008 08:06:56 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: Ack1bTW2ZXoJpPpOTbiTEG740aUqzgAY3tpA
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[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>

Tom,

I been thinking the same thing.  The OID in the type field should
dictate how to compute the intersection.

I am also thinking that we can define these for couple of types such as
use in some systems today and an approach this group may want to take
align with other work in the categories in IETF.

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]=20
Sent: Thursday, October 23, 2008 8:12 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        Santosh:

        This brings up another question.  Does it make more sense for
the=20
intersection to be defined based on policyID or on
SecurityCategory.Type?=20
SecurityCategory.Type is far more likely to be reused, and a few=20
syntax/intersection-semantic pairs could be predefined such as opaque=20
string, opaque object ID, and object ID with prefix match.
        Since drafting this, I've noticed your comments about=20
SecurityCategory.  It is true that the "intersection rule" is the main=20
thing in this draft which is more trouble than it's worth.=20

                Tom Gindin




"Santosh Chokhani" <[e-mail]>=20
Sent by: [e-mail]
10/23/2008 09:16 AM

To
<[e-mail]>
cc

Subject
RE: draft-turner-caclearanceconstraints-01.txt







Tom,

Thanks for your input.

If this is adopted as a work item, we will consider your suggestion.

Some of the things that come to mind are casting the security categories
structure concretely or giving 1 or 2 examples.

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]=20
Sent: Wednesday, October 22, 2008 9:02 PM
To: Santosh Chokhani
Cc: [e-mail]; [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        Santosh:

        I have to mainly agree with Stefan about this.  I cannot see how

to implement general purpose code to handle securityCategories without a

rule governing policyID's whose security policy is unknown to the
relying=20
party.  My own guess (although without much background in this area) is=20
that the desired final condition in such a case is either for all=20
securityCategories for such a policyID to be eliminated from=20
effective-clearance, or for the Clearance containing such a policyID to
be=20
eliminated if any SecurityCategory values are encountered in the=20
end-entity certificate.
        Such an algorithm could probably be implemented with an "SPI"=20
interface, at least in Java.  That's still a lot of work for this
purpose,=20
and defining default types of SecurityCategory with known intersection=20
characteristics might be worthwhile.  The current algorithm, with no=20
defined handling for unknown policyID's, can't be implemented robustly.

                Tom Gindin




"Santosh Chokhani" <[e-mail]>=20
Sent by: [e-mail]
10/22/2008 12:26 PM

To
<[e-mail]>
cc

Subject
RE: draft-turner-caclearanceconstraints-01.txt







Stefan,

One answer to your question will be that this can be sorted out during
the comment period.

But, specific answer to your question is that in all cases logical
intersection of categories is computed.  Specific details beyond that
will depend on how the categories are encoded.

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Wednesday, October 22, 2008 10:40 AM
To: Turner, Sean P.; Santosh Chokhani; 'Timothy J. Miller'; Carl Wallace
Cc: [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

The major problem I have is that there is no set logic for the
constraints processing.

I have been told that there are current implementations of this and that
this fact itself should prove that it is implementable.
It is however my strong guess that current implementations work only
because they assume no difference in calculating intersections of
SecurityCategories for different known PolicyIDs.

The problem comes when someone introduce a PolicyID which defines a
different intersection logic or order of classes.
The only way I can accept that Policy ID is to write new code.

There is a huge difference between allowing inclusion of different
policy OIDs, than to allow then to define individual path processing
logic.

Just imagine if every certificate policy OID was allowed to specify
individual mapping logic (Like policy A is equal to policy B,C and D),
and then expect the path processing code to learn the mapping logic for
each and every Policy OID.

I don't think anyone would consider that a good architecture and
protocol design to standardize.
But as far as I read it, this is precisely what the current CA clearance
constraints proposal wants us to do.




Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Turner, Sean P.
> Sent: den 14 oktober 2008 14:59
> To: 'Santosh Chokhani'; 'Timothy J. Miller'; 'Carl Wallace'
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
>
> I just wanted to add that the ID does not address relationships
between
> security policies.  It only addresses whether the EE's asserted
> clearance is
> within the issuer's allowed clearance set.
>
> spt
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Santosh Chokhani
> Sent: Monday, October 13, 2008 10:33 AM
> To: Timothy J. Miller; Carl Wallace
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Differences in various policies are articulated using the
> security policy OID in the clearance structure that has been
> accepted by the Internet Standards Community.
>
> In addition, clearance is a well defined mathematical concept
> and formalized using lattice structure.  Within a security
> policy, Clearance consists of a hierarchical sensitivity level
> and non-hierarchical category set.  Two clearances within a
> security can be ordered or can be incomparable based on simple
> and well-defines mathematical rules.
>
> People in other parts of IETF are using these concepts to label
> the data and make information flow decisions.
>
> Some pioneering work has been done in the technical community
> (albeit not exposed to the IETF) in the area of comparing
> clearances of two security policies.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Timothy J. Miller
> Sent: Monday, October 13, 2008 10:03 AM
> To: Carl Wallace
> Cc: [e-mail]
> Subject: Re: draft-turner-caclearanceconstraints-01.txt
>
> Carl Wallace wrote:
> > I vote yes to adopting this as a PKIX work item.  Specification
> details
> > can be resolved after the draft is accepted as a working group
draft.
>
> Can we even say for certain that clearance is a consistent
> enough concept within and across jurisdictions to enable a
> single logic for constraint processing?  I'd argue not.
>
> E.g., RFC3281 talks about "the" basic clearance hierarchy, which
> doesn't
>
> even exist.  What's the relationship between NATO CONFIDENTIAL
> and US UNCLASSIFIED CONTROLLED INFORMATION?  How about US UCI
> and US FOR OFFICIAL USE ONLY?  US SECRET/NOFOREIGN?  US TS/SCI
> and TS/SAP?  And that's without even getting into the obscure
> corners of the US alone.
>
> What I'm trying to say is that classification is *not* a strict
> hierarchy.  It's semi-structured.  We have trouble enough
> figuring this stuff out in the real world without having to
> write code for it.  :)
>
> Presuming I have a vote, I vote no.
>
> -- Tim
>







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9O0D48n054123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 17:13:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9O0D48j054122; Thu, 23 Oct 2008 17:13:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9O0Cq7p054109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 23 Oct 2008 17:13:03 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9O0FOab000716 for <[e-mail]>; Thu, 23 Oct 2008 20:15:24 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9O0CUcO103522 for <[e-mail]>; Thu, 23 Oct 2008 20:12:30 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9O0CQCQ031852 for <[e-mail]>; Thu, 23 Oct 2008 20:12:26 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9O0CQM9031849; Thu, 23 Oct 2008 20:12:26 -0400
In-Reply-To: <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: RE: draft-turner-caclearanceconstraints-01.txt
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 23 Oct 2008 20:12:28 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1|February 07, 2008) at 10/23/2008 20:12:29, Serialize complete at 10/23/2008 20:12:29
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Santosh:

        This brings up another question.  Does it make more sense for the 
intersection to be defined based on policyID or on SecurityCategory.Type? 
SecurityCategory.Type is far more likely to be reused, and a few 
syntax/intersection-semantic pairs could be predefined such as opaque 
string, opaque object ID, and object ID with prefix match.
        Since drafting this, I've noticed your comments about 
SecurityCategory.  It is true that the "intersection rule" is the main 
thing in this draft which is more trouble than it's worth. 

                Tom Gindin




"Santosh Chokhani" <[e-mail]> 
Sent by: [e-mail]
10/23/2008 09:16 AM

To
<[e-mail]>
cc

Subject
RE: draft-turner-caclearanceconstraints-01.txt







Tom,

Thanks for your input.

If this is adopted as a work item, we will consider your suggestion.

Some of the things that come to mind are casting the security categories
structure concretely or giving 1 or 2 examples.

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]] 
Sent: Wednesday, October 22, 2008 9:02 PM
To: Santosh Chokhani
Cc: [e-mail]; [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        Santosh:

        I have to mainly agree with Stefan about this.  I cannot see how

to implement general purpose code to handle securityCategories without a

rule governing policyID's whose security policy is unknown to the
relying 
party.  My own guess (although without much background in this area) is 
that the desired final condition in such a case is either for all 
securityCategories for such a policyID to be eliminated from 
effective-clearance, or for the Clearance containing such a policyID to
be 
eliminated if any SecurityCategory values are encountered in the 
end-entity certificate.
        Such an algorithm could probably be implemented with an "SPI" 
interface, at least in Java.  That's still a lot of work for this
purpose, 
and defining default types of SecurityCategory with known intersection 
characteristics might be worthwhile.  The current algorithm, with no 
defined handling for unknown policyID's, can't be implemented robustly.

                Tom Gindin




"Santosh Chokhani" <[e-mail]> 
Sent by: [e-mail]
10/22/2008 12:26 PM

To
<[e-mail]>
cc

Subject
RE: draft-turner-caclearanceconstraints-01.txt







Stefan,

One answer to your question will be that this can be sorted out during
the comment period.

But, specific answer to your question is that in all cases logical
intersection of categories is computed.  Specific details beyond that
will depend on how the categories are encoded.

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Wednesday, October 22, 2008 10:40 AM
To: Turner, Sean P.; Santosh Chokhani; 'Timothy J. Miller'; Carl Wallace
Cc: [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

The major problem I have is that there is no set logic for the
constraints processing.

I have been told that there are current implementations of this and that
this fact itself should prove that it is implementable.
It is however my strong guess that current implementations work only
because they assume no difference in calculating intersections of
SecurityCategories for different known PolicyIDs.

The problem comes when someone introduce a PolicyID which defines a
different intersection logic or order of classes.
The only way I can accept that Policy ID is to write new code.

There is a huge difference between allowing inclusion of different
policy OIDs, than to allow then to define individual path processing
logic.

Just imagine if every certificate policy OID was allowed to specify
individual mapping logic (Like policy A is equal to policy B,C and D),
and then expect the path processing code to learn the mapping logic for
each and every Policy OID.

I don't think anyone would consider that a good architecture and
protocol design to standardize.
But as far as I read it, this is precisely what the current CA clearance
constraints proposal wants us to do.




Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Turner, Sean P.
> Sent: den 14 oktober 2008 14:59
> To: 'Santosh Chokhani'; 'Timothy J. Miller'; 'Carl Wallace'
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
>
> I just wanted to add that the ID does not address relationships
between
> security policies.  It only addresses whether the EE's asserted
> clearance is
> within the issuer's allowed clearance set.
>
> spt
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Santosh Chokhani
> Sent: Monday, October 13, 2008 10:33 AM
> To: Timothy J. Miller; Carl Wallace
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Differences in various policies are articulated using the
> security policy OID in the clearance structure that has been
> accepted by the Internet Standards Community.
>
> In addition, clearance is a well defined mathematical concept
> and formalized using lattice structure.  Within a security
> policy, Clearance consists of a hierarchical sensitivity level
> and non-hierarchical category set.  Two clearances within a
> security can be ordered or can be incomparable based on simple
> and well-defines mathematical rules.
>
> People in other parts of IETF are using these concepts to label
> the data and make information flow decisions.
>
> Some pioneering work has been done in the technical community
> (albeit not exposed to the IETF) in the area of comparing
> clearances of two security policies.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Timothy J. Miller
> Sent: Monday, October 13, 2008 10:03 AM
> To: Carl Wallace
> Cc: [e-mail]
> Subject: Re: draft-turner-caclearanceconstraints-01.txt
>
> Carl Wallace wrote:
> > I vote yes to adopting this as a PKIX work item.  Specification
> details
> > can be resolved after the draft is accepted as a working group
draft.
>
> Can we even say for certain that clearance is a consistent
> enough concept within and across jurisdictions to enable a
> single logic for constraint processing?  I'd argue not.
>
> E.g., RFC3281 talks about "the" basic clearance hierarchy, which
> doesn't
>
> even exist.  What's the relationship between NATO CONFIDENTIAL
> and US UNCLASSIFIED CONTROLLED INFORMATION?  How about US UCI
> and US FOR OFFICIAL USE ONLY?  US SECRET/NOFOREIGN?  US TS/SCI
> and TS/SAP?  And that's without even getting into the obscure
> corners of the US alone.
>
> What I'm trying to say is that classification is *not* a strict
> hierarchy.  It's semi-structured.  We have trouble enough
> figuring this stuff out in the real world without having to
> write code for it.  :)
>
> Presuming I have a vote, I vote no.
>
> -- Tim
>







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NL1neJ043906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 14:01:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NL1nsw043904; Thu, 23 Oct 2008 14:01:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NL1bG7043884 for <[e-mail]>; Thu, 23 Oct 2008 14:01:47 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id m9NL1aM4000459 for <[e-mail]>; Thu, 23 Oct 2008 17:01:37 -0400 (EDT)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Oct 2008 16:59:48 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93552.896FB6D7"
Subject: RE: Comments on the TA requirements document
Date: Thu, 23 Oct 2008 17:01:36 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on the TA requirements document
Thread-Index: Ack1Gw5RwCiacYlDQg28ouWioo7jOwAAqt+wAADFKSAAAPbXgAAKFblQ
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 23 Oct 2008 20:59:48.0421 (UTC) FILETIME=[48F27750:01C93552]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C93552.896FB6D7
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

Is there ever a distinction to be made at the application layer between
push and pull?  Like picking TCP vs UDP, there are performance reasons
for choosing one transport vs. another, but at the Functional
Requirements level, the goal is for recipients to remain up-to-date
regardless of who initiates a connection.   Is messaging push or pull?
(Sending email via SMTP is push, receiving email via IMAP is pull, who
knows how to characterize IM transport over XMPP or text transport over
SMS; in all cases the user's desired end result is simply to see
messages shortly after they are written).    Push vs. pull makes even
less sense in simplex transport scenarios - is receiving a pager message
or a stock quote over FM radio subcarrier a push or pull transaction?=20

=20

As Carl says, I don't see how anything in the TA requirements favors
either management station initiated (snmp?) or client initiated (imap?
http?) transport.

=20

Dave

=20

=20

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Carl Wallace
Sent: Thursday, October 23, 2008 11:35 AM
To: Stefan Santesson; [e-mail]
Subject: RE: Comments on the TA requirements document

=20

What about this requirement could not be met by a TA mgmt message
addressed to all TA stores for which a manager is responsible and pulled
from a directory?  This does not require push.

=20


  _____ =20


From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Thursday, October 23, 2008 11:24 AM
To: Carl Wallace; [e-mail]
Subject: RE: Comments on the TA requirements document

Carl,

=20

=20

[CRW] I don't see the confusion w.r.t push/pull. There is no intent to
require a push model exclusively or even favor a push model.  What text
is creating this impression?

=20

This is clearly requirements for an active push protocol. For example:

=20

3.3.1.  Functional Requirements

=20

   A protocol for TA management must allow a TA management transaction

   to be directed to:

=20

      All TA stores for which the manager is responsible

      An enumerated list of one or more groups of trust anchor stores

      An individual trust anchor store

=20

=20

This is only relevant requirement for a push model. And it goes on and
on throughout the requirements.

And that is fine.  I'd rather have it saying that it is requirements for
a specific type of TA management protocol out of many possible
management models.

=20

=20

[CRW] There is no pretending that mechanisms do not exist.  This draft
simply defines a set of requirements for these mechanisms with an aim of
establishing an interoperable solution.  If existing mechanisms meet the
requirements or can be modified to do so, great.  Right now, we're just
trying to define the set of requirements.

=20

My point is that these requirements does not fit the policy management
model that is used in the systems I know of. The main reason is that the
current document describes requirements for active direct management of
TA stores instead of a pull model as a result of a separate policy
enforcement solution.

=20

=20

[CRW] Assuming the language is clarified such that push is not the
focus, what remaining concerns do you have? =20

=20

I don't think that is a language issue. I would rather accept that this
is a requirements document for a push oriented protocol, but to clarify
that other models may be used where this protocol may be redundant.

It would also be great to position this document among possible TA
management models.

=20

If I could wish for something more, then that would be to separate out
the requirements for standardizing the syntax of a TA list form the
requirements on a TA management protocol.

The reason is that we agreed to run these specifications separately.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: Carl Wallace [mailto:[e-mail]]=20
Sent: den 23 oktober 2008 17:03
To: Stefan Santesson; [e-mail]
Subject: RE: Comments on the TA requirements document

=20

inline...

=20


  _____ =20


From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Thursday, October 23, 2008 10:24 AM
To: [e-mail]
Subject: Comments on the TA requirements document

Commenting on draft-ietf-pkix-ta-mgmt-reqs-01, both in general and as
response to Denis Detailed comments.

http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01

=20

I thought I better post this comment as a separate e-mail to keep it
clear from other threads.

=20

On the general issue I am, as I have stated before,  not overly
enthusiastic about the TA management protocol. The main reason is that I
can't see that I need one.

TA management is just another aspect of policy management and modern
complex  IT environments already have systems and tools to deal with
policy management. It may not be pretty, and it may not be generic, but
it's there and we can't pretend it's not.=20

[CRW] There is no pretending that mechanisms do not exist.  This draft
simply defines a set of requirements for these mechanisms with an aim of
establishing an interoperable solution.  If existing mechanisms meet the
requirements or can be modified to do so, great.  Right now, we're just
trying to define the set of requirements.

TA management is also subordinate to the larger security management
aspects of an IT environment. If we can't manage user access, policy
distribution and policy enforcement in a large IT network, all bets are
off. The most genius TA management protocol in the world won't save us.
And since we already depend on the current security management for
success, we night as well allow it to manage the policies concerning
trust in TAs.

=20

I believe more in a TA management solution where clients "retrieve" the
TA they have been instructed to use by the overall policy management
infrastructure (whatever it is), rather than a model where a TA Manager
push this information onto the client and actively manages the TA stores
in the client and server hosts.=20

=20

[CRW] I don't see the confusion w.r.t push/pull. There is no intent to
require a push model exclusively or even favor a push model.  What text
is creating this impression?

=20

=20

Denis comments:

I want to address Denis comments in principle rather than detailed in
depth at this point.

=20

I agree in principle with Denis observation that the current approach is
structured as a push model over a pull model. This is a disconnect from
how most systems and current protocols work today. I strongly encourage
the pull model to be the main and default principle for TA management.=20

[CRW] See above re: push/pull.=20

=20

I disagree that a TA Management structure need to be structured around
the root cross certification scheme of CMP (old with new and new with
old signing). It should be possible, but this is seldom implemented in
reality.

=20

I disagree with Denis on the issue of including validation policies into
the requirements of this protocol.

The reasons are again that trust policy management is a lot larger than
what we possibly can define in the PKIX working group. Whatever we would
come up with other than standardized protocol elements to be used by
other protocols, we will end up guessing and most likely miss the
target, or just serve a few corner cases with a complex protocol.=20

=20

=20

=20

Comments on the TA req document:=20

=20

I think there is one fundamental flaw in the general assumptions of the
document:=20

=20

>From 1.1

=20

   Trust relationships between PKIs are negotiated by policy
   authorities.  Negotiations frequently require significant time to
   ensure all participating parties' requirements are satisfied.  These
   requirements are expressed, to some extent, in public key
   certificates via policy constraints, name constraints and etc.  In
   order for these requirements to be enforced, trust anchor stores must
   be managed in accord with policy authority intentions and avoid
   circumventing constraints defined in a cross-certificate by
   recognizing the subject of the cross certificate as a trust anchor.

=20

=20

I find this assumption wrong as management of trust anchors is a matter
of local policy only.

The whole path processing logic is designed so that the statements made
by each CA will be enforced appropriately in accordance with the TA that
the local relying party has chosen as a result of local policy only.=20

=20

[CRW] I can see where this text is confusing.  The policy authority
referenced here is the local policy authority.  The point of the
requirement is that when a local policy authority issues a cross
certificate to an external enterprise root, it should not be possible to
avoid the constraints included in the cross-cert by installing the
self-signed certificate issued to the subject of the cross-certificate.
The trust anchor stores subject to the local policy authority must be
managed in accord with the policy authority's intentions or all bets are
off.=20

=20

This defeats a substantial part of the rationale for having a push model
rather than a pull model.=20

[CRW] See above re: push/pull.=20

=20

=20

Conclusion

=20

The working group has already decided to adopt this work, and it is not
my intention to try to block its progress.

I'm just expressing the rationale why I doubt its usefulness in its
current form and why I have problems providing detailed comments on the
requirements document.=20

=20

[CRW] Assuming the language is clarified such that push is not the
focus, what remaining concerns do you have? =20

=20

=20

=20

=20

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20


------_=_NextPart_001_01C93552.896FB6D7
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@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:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.h41
	{mso-style-name:h41;
	font-family:"Courier New";
	font-weight:bold;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Stefan,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Is there ever a =
distinction to
be made at the application layer between push and pull?&nbsp; Like =
picking TCP
vs UDP, there are performance reasons for choosing one transport vs. =
another,
but at the Functional Requirements level, the goal is for recipients to =
remain
up-to-date regardless of who initiates a connection.&nbsp; &nbsp;Is =
messaging
push or pull?&nbsp; (Sending email via SMTP is push, receiving email via =
IMAP
is pull, who knows how to characterize IM transport over XMPP or text =
transport
over SMS; in all cases the user&#8217;s desired end result is simply to =
see
messages shortly after they are written).&nbsp;&nbsp;&nbsp; Push vs. =
pull makes
even less sense in simplex transport scenarios &#8211; is receiving a =
pager
message or a stock quote over FM radio subcarrier a push or pull =
transaction? <o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>As Carl says, I =
don&#8217;t see
how anything in the TA requirements favors either management station =
initiated (snmp?)
or client initiated (imap? http?) transport.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Dave<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
[e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Carl =
Wallace<br>
<b>Sent:</b> Thursday, October 23, 2008 11:35 AM<br>
<b>To:</b> Stefan Santesson; [e-mail]<br>
<b>Subject:</b> RE: Comments on the TA requirements =
document<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>What about this requirement could not be met by a TA mgmt =
message
addressed to all TA stores for which a manager is responsible and pulled =
from a
directory?&nbsp; This does not require push.</span><span lang=3DSV
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p>&nbsp;</o:p></span></p>

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

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

</span></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Stefan Santesson
[mailto:[e-mail]] <br>
<b>Sent:</b> Thursday, October 23, 2008 11:24 AM<br>
<b>To:</b> Carl Wallace; [e-mail]<br>
<b>Subject:</b> RE: Comments on the TA requirements document</span><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DSV =
style=3D'color:#1F497D'>Carl,</span></a><span
lang=3DSV style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DSV =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DSV =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif";color:blue'>[CRW] I don't see the =
confusion
w.r.t push/pull. There is no intent to require a push model =
exclusively&nbsp;or
even favor a push model.&nbsp; What text is creating this =
impression?</span><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p>

<p class=3DMsoNormal><span lang=3DSV =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>This is clearly =
requirements for
an active push protocol. For example:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><a name=3Dsection-3.3.1><b><span lang=3DEN =
style=3D'font-size:
12.0pt;font-family:"Courier New"'>3.3.1</span></b></a><b><span lang=3DEN
style=3D'font-size:12.0pt;font-family:"Courier New"'>.&nbsp; Functional
Requirements</span></b><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
A protocol for TA management must allow a TA management =
transaction<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
to be directed to:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
All TA stores for which the manager is responsible<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
An enumerated list of one or more groups of trust anchor =
stores<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
An individual trust anchor store<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>This is only relevant
requirement for a push model. And it goes on and on throughout the
requirements.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>And that is fine.
&nbsp;I&#8217;d rather have it saying that it is requirements for a =
specific
type of TA management protocol out of many possible management =
models.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif";color:blue'>[CRW]&nbsp;There is no =
pretending
that mechanisms do not exist.&nbsp; This draft simply defines a set of
requirements for these mechanisms with an aim of establishing&nbsp;an
interoperable solution.&nbsp; If existing mechanisms meet the =
requirements or
can be modified to do so, great.&nbsp; Right now, we're just trying to
define&nbsp;the set of requirements.</span><o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>My point is that =
these
requirements does not fit the policy management model that is used in =
the
systems I know of. The main reason is that the current document =
describes
requirements for active direct management of TA stores instead of a pull =
model
as a result of a separate policy enforcement =
solution.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif";color:blue'>[CRW] Assuming the language =
is
clarified such that push is not the focus,&nbsp;what remaining concerns =
do you
have?</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;</spa=
n><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blue'> =
</span><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I don&#8217;t think =
that is a
language issue. I would rather accept that this is a requirements =
document for
a push oriented protocol, but to clarify that other models may be used =
where
this protocol may be redundant.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>It would also be =
great to
position this document among possible TA management =
models.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>If I could wish for =
something
more, then that would be to separate out the requirements for =
standardizing the
syntax of a TA list form the requirements on a TA management =
protocol.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>The reason is that we =
agreed to
run these specifications separately.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif";color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman","serif";color:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:#400040'>Windows Security, =
Standards</span></b><span
style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Carl =
Wallace
[mailto:[e-mail]] <br>
<b>Sent:</b> den 23 oktober 2008 17:03<br>
<b>To:</b> Stefan Santesson; [e-mail]<br>
<b>Subject:</b> RE: Comments on the TA requirements =
document<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><span lang=3DSV><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>inline...</span><span lang=3DSV =
style=3D'font-size:12.0pt;font-family:
"Times New Roman","serif"'><o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DSV =
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p>&nbsp;</o:p></span></p>

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

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

</span></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Stefan =
Santesson<br>
<b>Sent:</b> Thursday, October 23, 2008 10:24 AM<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> Comments on the TA requirements document</span><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal>Commenting on draft-ietf-pkix-ta-mgmt-reqs-01, both =
in
general and as response to Denis Detailed comments.<o:p></o:p></p>

<p class=3DMsoNormal><a
href=3D"http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01">http:=
//tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I thought I better post this comment as a separate =
e-mail to
keep it clear from other threads.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>On the general issue I am, as I have stated before,
&nbsp;not overly enthusiastic about the TA management protocol. The main =
reason
is that I can&#8217;t see that I need one.<o:p></o:p></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>TA management is just another aspect =
of
policy management and modern complex &nbsp;IT environments already have =
systems
and tools to deal with policy management. It may not be pretty, and it =
may not
be generic, but it&#8217;s there and we can&#8217;t pretend it&#8217;s =
not.</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blue'>&n=
bsp;</span><span
lang=3DSV><o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif";color:blue'>[CRW]&nbsp;There is no =
pretending
that mechanisms do not exist.&nbsp; This draft simply defines a set of
requirements for these mechanisms with an aim of establishing&nbsp;an
interoperable solution.&nbsp; If existing mechanisms meet the =
requirements or
can be modified to do so, great.&nbsp; Right now, we're just trying to
define&nbsp;the set of requirements.</span><span =
lang=3DSV><o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>TA management is also subordinate to =
the
larger security management aspects of an IT environment. If we =
can&#8217;t
manage user access, policy distribution and policy enforcement in a =
large IT
network, all bets are off. The most genius TA management protocol in the =
world
won&#8217;t save us. And since we already depend on the current security
management for success, we night as well allow it to manage the policies
concerning trust in TAs.<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>I believe more in a TA management =
solution
where clients &#8220;retrieve&#8221; the TA they have been instructed to =
use by
the overall policy management infrastructure (whatever it is), rather =
than a
model where a TA Manager push this information onto the client and =
actively
manages the TA stores in the client and server hosts. =
<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif";color:blue'>[CRW] I don't see the =
confusion
w.r.t push/pull. There is no intent to require a push model =
exclusively&nbsp;or
even favor a push model.&nbsp; What text is creating this =
impression?</span><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><u><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Denis =
comments:<o:p></o:p></span></u></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>I want to address Denis comments in
principle rather than detailed in depth at this =
point.<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>I agree in principle with Denis =
observation
that the current approach is structured as a push model over a pull =
model. This
is a disconnect from how most systems and current protocols work today. =
I
strongly encourage the pull model to be the main and default principle =
for TA
management.</span><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>&nbsp;</span><span lang=3DSV><o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif";color:blue'>[CRW] See above re: =
push/pull.</span><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p>=
</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>I disagree that a TA Management =
structure
need to be structured around the root cross certification scheme of CMP =
(old
with new and new with old signing). It should be possible, but this is =
seldom
implemented in reality.<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>I disagree with Denis on the issue =
of
including validation policies into the requirements of this =
protocol.<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>The reasons are again that trust =
policy
management is a lot larger than what we possibly can define in the PKIX =
working
group. Whatever we would come up with other than standardized protocol =
elements
to be used by other protocols, we will end up guessing and most likely =
miss the
target, or just serve a few corner cases with a complex =
protocol.</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blue'>&n=
bsp;</span><span
lang=3DSV><o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><u><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Comments on the TA req =
document:&nbsp;<o:p></o:p></span></u></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>I think there is one fundamental =
flaw in
the general assumptions of the document:&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>From 1.1<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:10.0pt;
font-family:"Calibri","sans-serif"'>&nbsp;&nbsp; Trust relationships =
between
PKIs are negotiated by policy<br>
&nbsp;&nbsp; authorities.&nbsp; Negotiations frequently require =
significant
time to<br>
&nbsp;&nbsp; ensure all participating parties' requirements are
satisfied.&nbsp; These<br>
&nbsp;&nbsp; requirements are expressed, to some extent, in public =
key<br>
&nbsp;&nbsp; certificates via policy constraints, name constraints and
etc.&nbsp; In<br>
&nbsp;&nbsp; order for these requirements to be enforced, trust anchor =
<u>stores
must<br>
&nbsp;&nbsp; be managed in accord with policy authority intentions</u> =
and
avoid<br>
&nbsp;&nbsp; circumventing constraints defined in a cross-certificate =
by<br>
&nbsp;&nbsp; recognizing the subject of the cross certificate as a trust
anchor.<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>I find this assumption wrong as =
management
of trust anchors is a matter of local policy only.<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>The whole path processing logic is =
designed
so that the statements made by each CA will be enforced appropriately in
accordance with the TA that the local relying party has chosen as a =
result of
local policy only.</span><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>&nbsp;</span><span lang=3DSV><o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
lang=3DSV>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif";color:blue'>[CRW]&nbsp;I can see where =
this
text is confusing.&nbsp; The policy authority referenced here is the =
local
policy authority.&nbsp; The point of the requirement is that when a =
local
policy authority issues a cross certificate&nbsp;to an =
external&nbsp;enterprise&nbsp;root,
it should not be possible to avoid the constraints included in the =
cross-cert
by installing the self-signed certificate issued to the subject of the
cross-certificate.&nbsp;&nbsp;The trust anchor stores subject&nbsp;to =
the local
policy authority must be managed in accord with the policy
authority's&nbsp;intentions or all bets are off.</span><span =
style=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>This defeats a substantial part of =
the
rationale for having a push model rather than a pull model.</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blue'>&n=
bsp;</span><span
lang=3DSV><o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif";color:blue'>[CRW] See above re: =
push/pull.</span><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p>=
</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><u><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Conclusion<o:p></o:p></span></u></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>The working group has already =
decided to
adopt this work, and it is not my intention to try to block its =
progress.<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>I&#8217;m just expressing the =
rationale why
I doubt its usefulness in its current form and why I have problems =
providing
detailed comments on the requirements document.</span><span =
style=3D'font-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>&nbsp;</span><span =
lang=3DSV><o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
lang=3DSV>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif";color:blue'>[CRW] Assuming the language =
is
clarified such that push is not the focus,&nbsp;what remaining concerns =
do you
have?</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;</spa=
n><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blue'> =
</span><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif";color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman","serif";color:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:#400040'>Windows Security, =
Standards</span></b><span
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</blockquote>

</div>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C93552.896FB6D7--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NKmwuJ042971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 13:48:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NKmwuM042970; Thu, 23 Oct 2008 13:48:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9NKmvUs042963 for <[e-mail]>; Thu, 23 Oct 2008 13:48:57 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 30921 invoked from network); 23 Oct 2008 20:35:23 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;23 Oct 2008 20:35:23 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 23 Oct 2008 20:35:23 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: relation between certificate policies and CP/CPS identification
Date: Thu, 23 Oct 2008 16:48:56 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: relation between certificate policies and CP/CPS identification
Thread-Index: Ack1PdJ9U2sEJdBlQn6R+2ktCgiZQAAEpLBQ
References: <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, "pkix" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

In terms of your first question, it is acceptable to had two OID in the =
same certificate policy document.

As to your second question, if the relying parties do not need to =
distinguish (which seems to be the case), there is no need to allocate a =
new OID.

A new OID should be assigned only if there is material change in the =
assurance or the relying party application need to discern the =
difference.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On Behalf Of Peter Sylvester
Sent: Thursday, October 23, 2008 2:10 PM
To: pkix
Subject: relation between certificate policies and CP/CPS identification

hello,

I would like to have some opinion about the usage of object identifiers
for certificate policies.

It happens sometimes that the difference between two policies is
very small, as an example the lifetime of a certficate (2 years or 3 =
days),
where all other parameters are identical, i.e. one woould like to
make a policy based decision based on two object identifiers for
such cases. Does thst means that one need to publish two
independant documents, or would it be sufficient to indicate
in the text that two OIDs are handled?

Also, sometimes, a PC text changes slightly. Does this means
that one has to allocate a new identifier in all cases.


TIA
Peter


--=20

<http://www.edelweb.fr>
*Edel/W/eb* 	Peter SYLVESTER
Consultant S=E9curit=E9 des Syst=E8mes d'Information
-----------------------------------------------------------
EdelWeb - Groupe ON-X
15, quai de Dion-Bouton
F-92816 Puteaux Cedex
Tel : [phone] / Fax : [phone]
www.edelweb.fr <http://www.edelweb.fr> / www.on-x.com =
<http://www.on-x.com>
-----------------------------------------------------------
To verify the message signature, see edelpki.edelweb.fr=20
<http://edelpki.edelweb.fr/>
Cela vous permet de charger le certificat de l'autorit=E9 de racine=20
<http://edelpki.edelweb.fr/cacerts/EdelPKI-ca.der>;
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NKfx8E042692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 13:41:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NKfxb1042691; Thu, 23 Oct 2008 13:41:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9NKfmEB042677 for <[e-mail]>; Thu, 23 Oct 2008 13:41:58 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 30850 invoked from network); 23 Oct 2008 20:28:14 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;23 Oct 2008 20:28:14 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 23 Oct 2008 20:28:14 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Thu, 23 Oct 2008 16:41:47 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: AcktPo1xbBGJg+IZTZOD+0tgp11GwAAAKwnQAC8iOcABlZKT4AAD3NvgACVIDNAABsE5sAAPHlGg
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[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>

Stefan,

If this work item is taken up, another option we should consider under
casting the categories structure is to deprecate the security
categories.  While we can not change the ASN.1 of the existing clearance
structure, security category deprecation can be achieved using one of
the following means:

1.  We can reject the certificate if categories are present in the
clearance constraints
2.  We can ignore the categories in the clearance constraints
3.  We can define a new structure for the clearance constraints so that
the clearance constraints only contain the classification levels and do
not contain categories.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Thursday, October 23, 2008 9:20 AM
To: [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt


Stefan,

I realize that a generic structure for security categories can not be
implemented.

I hope you see the point that without casting the security categories
more concretely, I can not provide more detailed pseudo-code than saying
that take a set theoretic intersection.

If the work item is taken up, we would definitely look at option of
casting the security categories structure concretely or giving couple of
examples for different structures.=20

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Thursday, October 23, 2008 8:28 AM
To: Santosh Chokhani; [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

Santosh,

> One answer to your question will be that this can be sorted out during
> the comment period.

I have thought about that, but I would prefer not.
The reason is that this is a fundamental aspect of the standard and I
want to see that you can build a reasonable solution to a reasonable
problem before I would support to standardize it.

>
> But, specific answer to your question is that in all cases logical
> intersection of categories is computed.  Specific details beyond that
> will depend on how the categories are encoded.


I don't understand what you mean here. The current specification makes
clear that the intersection logic can change in any way for each Policy
ID.
There is no defined "default" logic and no way to tell if a PolicyID
alters this logic.
As such I can't write a code that can perform the fundamental
intersection logic of the protocol.
I would have to build a solution that allows every "user" to invoke
custom code for every PolicyID.

That to me is a too complex response to this problem, especially since I
don't think this problem should be handled in certificates at all.
And that if this would be done in certificates anyway, that we at least
should skip the constraints logic.

I miss the balance discussion. Writing a new standard comes with a cost.
We are potentially confusing the community with another specification.
We potentially promote making PKI more complex. We potentially promote
Certificates to be the right place to carry clearance information.

Just because something could be useful in some corner cases, does not
make it the right thing to standardize.



Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Santosh Chokhani
> Sent: den 22 oktober 2008 18:26
> To: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Stefan,
>
> One answer to your question will be that this can be sorted out during
> the comment period.
>
> But, specific answer to your question is that in all cases logical
> intersection of categories is computed.  Specific details beyond that
> will depend on how the categories are encoded.
>





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NIA9sO034281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 11:10:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NIA9Tq034280; Thu, 23 Oct 2008 11:10:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NI9vI1034251 for <[e-mail]>; Thu, 23 Oct 2008 11:10:08 -0700 (MST) (envelope-from [e-mail])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 48D997A for <[e-mail]>; Thu, 23 Oct 2008 20:09:56 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008102320095548:186593 ; Thu, 23 Oct 2008 20:09:55 +0200 
Message-ID: <[e-mail]>
Date: Thu, 23 Oct 2008 20:10:21 +0200
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: relation between certificate policies and CP/CPS identification
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 10/23/2008 08:09:55 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 10/23/2008 08:09:56 PM, Serialize complete at 10/23/2008 08:09:56 PM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090603080807040001060405"
Sender: [e-mail]
Precedence: 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.

--------------ms090603080807040001060405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

hello,

I would like to have some opinion about the usage of object identifiers
for certificate policies.

It happens sometimes that the difference between two policies is
very small, as an example the lifetime of a certficate (2 years or 3 days=
),
where all other parameters are identical, i.e. one woould like to
make a policy based decision based on two object identifiers for
such cases. Does thst means that one need to publish two
independant documents, or would it be sufficient to indicate
in the text that two OIDs are handled?

Also, sometimes, a PC text changes slightly. Does this means
that one has to allocate a new identifier in all cases.


TIA
Peter


--=20

<http://www.edelweb.fr>
*Edel/W/eb* 	Peter SYLVESTER
Consultant S=E9curit=E9 des Syst=E8mes d'Information
-----------------------------------------------------------
EdelWeb - Groupe ON-X
15, quai de Dion-Bouton
F-92816 Puteaux Cedex
Tel : [phone] / Fax : [phone]
www.edelweb.fr <http://www.edelweb.fr> / www.on-x.com <http://www.on-x.co=
m>
-----------------------------------------------------------
To verify the message signature, see edelpki.edelweb.fr=20
<http://edelpki.edelweb.fr/>
Cela vous permet de charger le certificat de l'autorit=E9 de racine=20
<http://edelpki.edelweb.fr/cacerts/EdelPKI-ca.der>;
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0
MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV
HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh
Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff
2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP
2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma
1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT
DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9
lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn
qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd
kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/
FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI
cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ
PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB
MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug
RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr
DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w
ODEwMjMxODEwMjFaMCMGCSqGSIb3DQEJBDEWBBSnD9ldWybobx7YUhAGgMmUFNWPODBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl
MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk
ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI
hvcNAQEBBQAEgYDAhBm1zHsdSpkQSd0u2SPw2ERsjLNjbzjhZW0N0HCi3mGSBEkU6zyMnxdF
h17hovfdlYQzKWLd9DQ6qka7O/9wd97NV2VVCv9NLO+XHT55Os14IVp0ZcqKyV79NEA4rMaz
N1MFhgHJkS+nBRckaBDiM9/DDcA6TtVynDmJNXCkTQAAAAAAAA==
--------------ms090603080807040001060405--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NFYkKi017619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 08:34:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NFYjYi017618; Thu, 23 Oct 2008 08:34:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9NFYiJr017612 for <[e-mail]>; Thu, 23 Oct 2008 08:34:45 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 27636 invoked from network); 23 Oct 2008 15:21:11 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;23 Oct 2008 15:21:11 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 23 Oct 2008 15:21:09 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93524.DED36822"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Comments on the TA requirements document
Date: Thu, 23 Oct 2008 11:34:39 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on the TA requirements document
Thread-Index: Ack1Gw5RwCiacYlDQg28ouWioo7jOwAAqt+wAADFKSAAAPbXgA==
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

What about this requirement could not be met by a TA mgmt message
addressed to all TA stores for which a manager is responsible and pulled
from a directory?  This does not require push.


________________________________

	From: Stefan Santesson [mailto:[e-mail]]=20
	Sent: Thursday, October 23, 2008 11:24 AM
	To: Carl Wallace; [e-mail]
	Subject: RE: Comments on the TA requirements document
=09
=09

	Carl,

	=20

	=20

	[CRW] I don't see the confusion w.r.t push/pull. There is no
intent to require a push model exclusively or even favor a push model.
What text is creating this impression?

	=20

	This is clearly requirements for an active push protocol. For
example:

	=20

	3.3.1.  Functional Requirements

	=20

	   A protocol for TA management must allow a TA management
transaction

	   to be directed to:

	=20

	      All TA stores for which the manager is responsible

	      An enumerated list of one or more groups of trust anchor
stores

	      An individual trust anchor store

	=20

	=20

	This is only relevant requirement for a push model. And it goes
on and on throughout the requirements.

	And that is fine.  I'd rather have it saying that it is
requirements for a specific type of TA management protocol out of many
possible management models.

	=20

	=20

	[CRW] There is no pretending that mechanisms do not exist.  This
draft simply defines a set of requirements for these mechanisms with an
aim of establishing an interoperable solution.  If existing mechanisms
meet the requirements or can be modified to do so, great.  Right now,
we're just trying to define the set of requirements.

	=20

	My point is that these requirements does not fit the policy
management model that is used in the systems I know of. The main reason
is that the current document describes requirements for active direct
management of TA stores instead of a pull model as a result of a
separate policy enforcement solution.

	=20

	=20

	[CRW] Assuming the language is clarified such that push is not
the focus, what remaining concerns do you have? =20

	=20

	I don't think that is a language issue. I would rather accept
that this is a requirements document for a push oriented protocol, but
to clarify that other models may be used where this protocol may be
redundant.

	It would also be great to position this document among possible
TA management models.

	=20

	If I could wish for something more, then that would be to
separate out the requirements for standardizing the syntax of a TA list
form the requirements on a TA management protocol.

	The reason is that we agreed to run these specifications
separately.

	=20

	=20

	Stefan Santesson

	Senior Program Manager

	Windows Security, Standards

	=20

	From: Carl Wallace [mailto:[e-mail]]=20
	Sent: den 23 oktober 2008 17:03
	To: Stefan Santesson; [e-mail]
	Subject: RE: Comments on the TA requirements document

	=20

	inline...

		=20

	=09
________________________________


		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
		Sent: Thursday, October 23, 2008 10:24 AM
		To: [e-mail]
		Subject: Comments on the TA requirements document

		Commenting on draft-ietf-pkix-ta-mgmt-reqs-01, both in
general and as response to Denis Detailed comments.

=09
http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01

		=20

		I thought I better post this comment as a separate
e-mail to keep it clear from other threads.

		=20

		On the general issue I am, as I have stated before,  not
overly enthusiastic about the TA management protocol. The main reason is
that I can't see that I need one.

		TA management is just another aspect of policy
management and modern complex  IT environments already have systems and
tools to deal with policy management. It may not be pretty, and it may
not be generic, but it's there and we can't pretend it's not.=20

		[CRW] There is no pretending that mechanisms do not
exist.  This draft simply defines a set of requirements for these
mechanisms with an aim of establishing an interoperable solution.  If
existing mechanisms meet the requirements or can be modified to do so,
great.  Right now, we're just trying to define the set of requirements.

		TA management is also subordinate to the larger security
management aspects of an IT environment. If we can't manage user access,
policy distribution and policy enforcement in a large IT network, all
bets are off. The most genius TA management protocol in the world won't
save us. And since we already depend on the current security management
for success, we night as well allow it to manage the policies concerning
trust in TAs.

		=20

		I believe more in a TA management solution where clients
"retrieve" the TA they have been instructed to use by the overall policy
management infrastructure (whatever it is), rather than a model where a
TA Manager push this information onto the client and actively manages
the TA stores in the client and server hosts.=20

		=20

		[CRW] I don't see the confusion w.r.t push/pull. There
is no intent to require a push model exclusively or even favor a push
model.  What text is creating this impression?

		=20

		=20

		Denis comments:

		I want to address Denis comments in principle rather
than detailed in depth at this point.

		=20

		I agree in principle with Denis observation that the
current approach is structured as a push model over a pull model. This
is a disconnect from how most systems and current protocols work today.
I strongly encourage the pull model to be the main and default principle
for TA management.=20

		[CRW] See above re: push/pull.=20

		=20

		I disagree that a TA Management structure need to be
structured around the root cross certification scheme of CMP (old with
new and new with old signing). It should be possible, but this is seldom
implemented in reality.

		=20

		I disagree with Denis on the issue of including
validation policies into the requirements of this protocol.

		The reasons are again that trust policy management is a
lot larger than what we possibly can define in the PKIX working group.
Whatever we would come up with other than standardized protocol elements
to be used by other protocols, we will end up guessing and most likely
miss the target, or just serve a few corner cases with a complex
protocol.=20

		=20

		=20

		=20

		Comments on the TA req document:=20

		=20

		I think there is one fundamental flaw in the general
assumptions of the document:=20

		=20

		From 1.1

		=20

		   Trust relationships between PKIs are negotiated by
policy
		   authorities.  Negotiations frequently require
significant time to
		   ensure all participating parties' requirements are
satisfied.  These
		   requirements are expressed, to some extent, in public
key
		   certificates via policy constraints, name constraints
and etc.  In
		   order for these requirements to be enforced, trust
anchor stores must
		   be managed in accord with policy authority intentions
and avoid
		   circumventing constraints defined in a
cross-certificate by
		   recognizing the subject of the cross certificate as a
trust anchor.

		=20

		=20

		I find this assumption wrong as management of trust
anchors is a matter of local policy only.

		The whole path processing logic is designed so that the
statements made by each CA will be enforced appropriately in accordance
with the TA that the local relying party has chosen as a result of local
policy only.=20

		=20

		[CRW] I can see where this text is confusing.  The
policy authority referenced here is the local policy authority.  The
point of the requirement is that when a local policy authority issues a
cross certificate to an external enterprise root, it should not be
possible to avoid the constraints included in the cross-cert by
installing the self-signed certificate issued to the subject of the
cross-certificate.  The trust anchor stores subject to the local policy
authority must be managed in accord with the policy authority's
intentions or all bets are off.=20

		=20

		This defeats a substantial part of the rationale for
having a push model rather than a pull model.=20

		[CRW] See above re: push/pull.=20

		=20

		=20

		Conclusion

		=20

		The working group has already decided to adopt this
work, and it is not my intention to try to block its progress.

		I'm just expressing the rationale why I doubt its
usefulness in its current form and why I have problems providing
detailed comments on the requirements document.=20

		=20

		[CRW] Assuming the language is clarified such that push
is not the focus, what remaining concerns do you have? =20

		=20

		=20

		=20

		=20

		=20

		=20

		Stefan Santesson

		Senior Program Manager

		Windows Security, Standards

		=20


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20
"urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20
"urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =
=3D=20
"urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20
"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20
"urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20
"http://www.w3.org/TR/REC-html40" xmlns:q =3D=20
"http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 =
=3D=20
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20
"http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20
"http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20
"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec =
=3D=20
"http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20
"http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf =3D=20
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf =3D=20
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver =3D=20
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m =
=3D=20
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels =3D=20
"http://schemas.openxmlformats.org/package/2006/relationships" =
xmlns:ex12t =3D=20
"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m =
=3D=20
"http://schemas.microsoft.com/exchange/services/2006/messages" XMLNS:Z =
=3D=20
"urn:schemas-microsoft-com:" xmlns:st =3D "=01"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16735" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: SimSun;
}
@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @SimSun;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt =
70.85pt; }
P.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
"Calibri","sans-serif"
}
LI.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
"Calibri","sans-serif"
}
DIV.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
"Calibri","sans-serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: =
"Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto
}
PRE {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"; =
mso-style-priority: 99; mso-style-link: "HTML Preformatted Char"
}
SPAN.EmailStyle18 {
	COLOR: windowtext; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal
}
SPAN.EmailStyle19 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal-reply
}
SPAN.HTMLPreformattedChar {
	FONT-FAMILY: "Courier New"; mso-style-priority: 99; mso-style-link: =
"HTML Preformatted"; mso-style-name: "HTML Preformatted Char"
}
SPAN.h41 {
	FONT-WEIGHT: bold; FONT-FAMILY: "Courier New"; mso-style-name: h41
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DSV vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D082143315-23102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>What about this requirement could not be met by =
a TA mgmt=20
message addressed to all TA stores for which a manager is responsible =
and pulled=20
from a directory?&nbsp; This does not require =
push.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Stefan Santesson=20
  [mailto:[e-mail]] <BR><B>Sent:</B> Thursday, October 23, =
2008=20
  11:24 AM<BR><B>To:</B> Carl Wallace; =
[e-mail]<BR><B>Subject:</B> RE:=20
  Comments on the TA requirements document<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN=20
  style=3D"COLOR: #1f497d">Carl,<o:p></o:p></SPAN></A></P>
  <P class=3DMsoNormal><SPAN style=3D"COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN style=3D"COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">[CRW]=20
  I don't see the confusion w.r.t push/pull. There is no intent to =
require a=20
  push model exclusively&nbsp;or even favor a push model.&nbsp; What =
text is=20
  creating this impression?</SPAN><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN style=3D"COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">This =
is clearly=20
  requirements for an active push protocol. For =
example:<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><A name=3Dsection-3.3.1><B><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Courier =
New'">3.3.1</SPAN></B></A><B><SPAN=20
  lang=3DEN style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Courier =
New'">.&nbsp; Functional=20
  Requirements</SPAN></B><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Courier =
New'"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; A =
protocol=20
  for TA management must allow a TA management =
transaction<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Courier New'">&nbsp;&nbsp; to =
be=20
  directed to:<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  All TA stores for which the manager is =
responsible<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  An enumerated list of one or more groups of trust anchor=20
  stores<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  An individual trust anchor store<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">This =
is only=20
  relevant requirement for a push model. And it goes on and on =
throughout the=20
  requirements.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">And =
that is fine.=20
  &nbsp;I&#8217;d rather have it saying that it is requirements for a =
specific type of=20
  TA management protocol out of many possible management=20
  models.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">[CRW]&nbsp;There=20
  is no pretending that mechanisms do not exist.&nbsp; This draft simply =
defines=20
  a set of requirements for these mechanisms with an aim of =
establishing&nbsp;an=20
  interoperable solution.&nbsp; If existing mechanisms meet the =
requirements or=20
  can be modified to do so, great.&nbsp; Right now, we're just trying to =

  define&nbsp;the set of requirements.</SPAN><SPAN=20
  lang=3DEN-US><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">My =
point is that=20
  these requirements does not fit the policy management model that is =
used in=20
  the systems I know of. The main reason is that the current document =
describes=20
  requirements for active direct management of TA stores instead of a =
pull model=20
  as a result of a separate policy enforcement =
solution.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">[CRW]=20
  Assuming the language is clarified such that push is not the =
focus,&nbsp;what=20
  remaining concerns do you have?</SPAN><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;</SPAN><SPAN=20
  lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">=20
  </SPAN><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">I =
don&#8217;t think that=20
  is a language issue. I would rather accept that this is a requirements =

  document for a push oriented protocol, but to clarify that other =
models may be=20
  used where this protocol may be redundant.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">It =
would also be=20
  great to position this document among possible TA management=20
  models.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">If I =
could wish for=20
  something more, then that would be to separate out the requirements =
for=20
  standardizing the syntax of a TA list form the requirements on a TA =
management=20
  protocol.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US style=3D"COLOR: #1f497d">The =
reason is that=20
  we agreed to run these specifications =
separately.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
  Santesson</SPAN></B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 12pt; COLOR: #1f497d; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Senior=20
  Program Manager</SPAN><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Windows=20
  Security, Standards</SPAN></B><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P></DIV>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=3DMsoNormal><B><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
  lang=3DEN-US style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'"> Carl=20
  Wallace [mailto:[e-mail]] <BR><B>Sent:</B> den 23 oktober =
2008=20
  17:03<BR><B>To:</B> Stefan Santesson; =
[e-mail]<BR><B>Subject:</B> RE:=20
  Comments on the TA requirements =
document<o:p></o:p></SPAN></P></DIV></DIV>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">inline...</SPAN><SPAN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p></o:p></SPAN></P>
  <BLOCKQUOTE=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: =
medium none">
    <P class=3DMsoNormal><SPAN=20
    style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><SPAN=20
    lang=3DEN-US style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'">
    <HR align=3Dcenter width=3D"100%" SIZE=3D2>
    </SPAN></DIV>
    <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><SPAN =
lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
    lang=3DEN-US style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">=20
    [e-mail] [mailto:[e-mail]] =
<B>On=20
    Behalf Of </B>Stefan Santesson<BR><B>Sent:</B> Thursday, October 23, =
2008=20
    10:24 AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> Comments =
on the=20
    TA requirements document</SPAN><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US>Commenting on=20
    draft-ietf-pkix-ta-mgmt-reqs-01, both in general and as response to =
Denis=20
    Detailed comments.<o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US><A=20
    =
href=3D"http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01">http:=
//tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01</A><o:p></o:p></SPA=
N></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US>I thought I better post this =
comment as=20
    a separate e-mail to keep it clear from other =
threads.<o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US>On the general issue I am, =
as I have=20
    stated before, &nbsp;not overly enthusiastic about the TA management =

    protocol. The main reason is that I can&#8217;t see that I need=20
    one.<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">TA =
management=20
    is just another aspect of policy management and modern complex =
&nbsp;IT=20
    environments already have systems and tools to deal with policy =
management.=20
    It may not be pretty, and it may not be generic, but it&#8217;s =
there and we can&#8217;t=20
    pretend it&#8217;s not.</SPAN><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">&nbsp;</SPAN><o:p></o:p></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">[CRW]&nbsp;There=20
    is no pretending that mechanisms do not exist.&nbsp; This draft =
simply=20
    defines a set of requirements for these mechanisms with an aim of=20
    establishing&nbsp;an interoperable solution.&nbsp; If existing =
mechanisms=20
    meet the requirements or can be modified to do so, great.&nbsp; =
Right now,=20
    we're just trying to define&nbsp;the set of=20
    requirements.</SPAN><o:p></o:p></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">TA =
management=20
    is also subordinate to the larger security management aspects of an =
IT=20
    environment. If we can&#8217;t manage user access, policy =
distribution and policy=20
    enforcement in a large IT network, all bets are off. The most genius =
TA=20
    management protocol in the world won&#8217;t save us. And since we =
already depend=20
    on the current security management for success, we night as well =
allow it to=20
    manage the policies concerning trust in TAs.<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I =
believe more=20
    in a TA management solution where clients &#8220;retrieve&#8221; the =
TA they have been=20
    instructed to use by the overall policy management infrastructure =
(whatever=20
    it is), rather than a model where a TA Manager push this information =
onto=20
    the client and actively manages the TA stores in the client and =
server=20
    hosts. <o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">[CRW]=20
    I don't see the confusion w.r.t push/pull. There is no intent to =
require a=20
    push model exclusively&nbsp;or even favor a push model.&nbsp; What =
text is=20
    creating this impression?</SPAN><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><U><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">Denis =

    comments:<o:p></o:p></SPAN></U></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I =
want to=20
    address Denis comments in principle rather than detailed in depth at =
this=20
    point.<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I =
agree in=20
    principle with Denis observation that the current approach is =
structured as=20
    a push model over a pull model. This is a disconnect from how most =
systems=20
    and current protocols work today. I strongly encourage the pull =
model to be=20
    the main and default principle for TA management.</SPAN><SPAN =
lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">&nbsp;</SPAN><o:p></o:p></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">[CRW]=20
    See above re: push/pull.</SPAN><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I =
disagree that=20
    a TA Management structure need to be structured around the root =
cross=20
    certification scheme of CMP (old with new and new with old signing). =
It=20
    should be possible, but this is seldom implemented in=20
    reality.<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I =
disagree with=20
    Denis on the issue of including validation policies into the =
requirements of=20
    this protocol.<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">The =
reasons are=20
    again that trust policy management is a lot larger than what we =
possibly can=20
    define in the PKIX working group. Whatever we would come up with =
other than=20
    standardized protocol elements to be used by other protocols, we =
will end up=20
    guessing and most likely miss the target, or just serve a few corner =
cases=20
    with a complex protocol.</SPAN><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">&nbsp;</SPAN><o:p></o:p></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><U><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">Comments on the=20
    TA req document:&nbsp;<o:p></o:p></SPAN></U></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I =
think there=20
    is one fundamental flaw in the general assumptions of the=20
    document:&nbsp;<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">From=20
    1.1<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;&nbsp;=20
    Trust relationships between PKIs are negotiated by =
policy<BR>&nbsp;&nbsp;=20
    authorities.&nbsp; Negotiations frequently require significant time=20
    to<BR>&nbsp;&nbsp; ensure all participating parties' requirements =
are=20
    satisfied.&nbsp; These<BR>&nbsp;&nbsp; requirements are expressed, =
to some=20
    extent, in public key<BR>&nbsp;&nbsp; certificates via policy =
constraints,=20
    name constraints and etc.&nbsp; In<BR>&nbsp;&nbsp; order for these=20
    requirements to be enforced, trust anchor <U>stores =
must<BR>&nbsp;&nbsp; be=20
    managed in accord with policy authority intentions</U> and=20
    avoid<BR>&nbsp;&nbsp; circumventing constraints defined in a=20
    cross-certificate by<BR>&nbsp;&nbsp; recognizing the subject of the =
cross=20
    certificate as a trust anchor.<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I =
find this=20
    assumption wrong as management of trust anchors is a matter of local =
policy=20
    only.<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">The =
whole path=20
    processing logic is designed so that the statements made by each CA =
will be=20
    enforced appropriately in accordance with the TA that the local =
relying=20
    party has chosen as a result of local policy only.</SPAN><SPAN =
lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">&nbsp;</SPAN><o:p></o:p></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt">&nbsp;<o:p></o:p></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">[CRW]&nbsp;I=20
    can see where this text is confusing.&nbsp; The policy authority =
referenced=20
    here is the local policy authority.&nbsp; The point of the =
requirement is=20
    that when a local policy authority issues a cross =
certificate&nbsp;to an=20
    external&nbsp;enterprise&nbsp;root, it should not be possible to =
avoid the=20
    constraints included in the cross-cert by installing the self-signed =

    certificate issued to the subject of the =
cross-certificate.&nbsp;&nbsp;The=20
    trust anchor stores subject&nbsp;to the local policy authority must =
be=20
    managed in accord with the policy authority's&nbsp;intentions or all =
bets=20
    are off.</SPAN><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">This =
defeats a=20
    substantial part of the rationale for having a push model rather =
than a pull=20
    model.</SPAN><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">&nbsp;</SPAN><o:p></o:p></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">[CRW]=20
    See above re: push/pull.</SPAN><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><U><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">Conclusion<o:p></o:p></SPAN></U></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">The =
working=20
    group has already decided to adopt this work, and it is not my =
intention to=20
    try to block its progress.<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">I&#8217;m just=20
    expressing the rationale why I doubt its usefulness in its current =
form and=20
    why I have problems providing detailed comments on the requirements=20
    document.</SPAN><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">&nbsp;</SPAN><o:p></o:p></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt">&nbsp;<o:p></o:p></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">[CRW]=20
    Assuming the language is clarified such that push is not the=20
    focus,&nbsp;what remaining concerns do you have?</SPAN><SPAN =
lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;</SPAN><SPAN=20
    lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
'Arial','sans-serif'">=20
    </SPAN><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
    <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P>
    <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
    Santesson</SPAN></B><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 12pt; COLOR: #1f497d; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Senior=20
    Program Manager</SPAN><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Windows=20
    Security, Standards</SPAN></B><SPAN lang=3DEN-US=20
    style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><SPAN=20
  =
lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P></BLOCKQUOTE></DIV></DIV></BLOCK=
QUOTE></BODY></HTML>

------_=_NextPart_001_01C93524.DED36822--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NFNswo016883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 08:23:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NFNsht016882; Thu, 23 Oct 2008 08:23:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NFNpja016873 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 23 Oct 2008 08:23:52 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 23 Oct 2008 16:23:50 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 23 Oct 2008 16:23:50 +0100
From: Stefan Santesson <[e-mail]>
To: Carl Wallace <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Thu, 23 Oct 2008 16:23:48 +0100
Subject: RE: Comments on the TA requirements document
Thread-Topic: Comments on the TA requirements document
Thread-Index: Ack1Gw5RwCiacYlDQg28ouWioo7jOwAAqt+wAADFKSA=
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D32195A6F3934EAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Carl,



[CRW] I don't see the confusion w.r.t push/pull. There is no intent to requ=
ire a push model exclusively or even favor a push model.  What text is crea=
ting this impression?

This is clearly requirements for an active push protocol. For example:

3.3.1.  Functional Requirements

   A protocol for TA management must allow a TA management transaction
   to be directed to:

      All TA stores for which the manager is responsible
      An enumerated list of one or more groups of trust anchor stores
      An individual trust anchor store


This is only relevant requirement for a push model. And it goes on and on t=
hroughout the requirements.
And that is fine.  I'd rather have it saying that it is requirements for a =
specific type of TA management protocol out of many possible management mod=
els.



[CRW] There is no pretending that mechanisms do not exist.  This draft simp=
ly defines a set of requirements for these mechanisms with an aim of establ=
ishing an interoperable solution.  If existing mechanisms meet the requirem=
ents or can be modified to do so, great.  Right now, we're just trying to d=
efine the set of requirements.

My point is that these requirements does not fit the policy management mode=
l that is used in the systems I know of. The main reason is that the curren=
t document describes requirements for active direct management of TA stores=
 instead of a pull model as a result of a separate policy enforcement solut=
ion.



[CRW] Assuming the language is clarified such that push is not the focus, w=
hat remaining concerns do you have?

I don't think that is a language issue. I would rather accept that this is =
a requirements document for a push oriented protocol, but to clarify that o=
ther models may be used where this protocol may be redundant.
It would also be great to position this document among possible TA manageme=
nt models.

If I could wish for something more, then that would be to separate out the =
requirements for standardizing the syntax of a TA list form the requirement=
s on a TA management protocol.
The reason is that we agreed to run these specifications separately.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: Carl Wallace [mailto:[e-mail]]
Sent: den 23 oktober 2008 17:03
To: Stefan Santesson; [e-mail]
Subject: RE: Comments on the TA requirements document

inline...

________________________________
From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Stefan Santesson
Sent: Thursday, October 23, 2008 10:24 AM
To: [e-mail]
Subject: Comments on the TA requirements document
Commenting on draft-ietf-pkix-ta-mgmt-reqs-01, both in general and as respo=
nse to Denis Detailed comments.
http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01

I thought I better post this comment as a separate e-mail to keep it clear =
from other threads.

On the general issue I am, as I have stated before,  not overly enthusiasti=
c about the TA management protocol. The main reason is that I can't see tha=
t I need one.

TA management is just another aspect of policy management and modern comple=
x  IT environments already have systems and tools to deal with policy manag=
ement. It may not be pretty, and it may not be generic, but it's there and =
we can't pretend it's not.

[CRW] There is no pretending that mechanisms do not exist.  This draft simp=
ly defines a set of requirements for these mechanisms with an aim of establ=
ishing an interoperable solution.  If existing mechanisms meet the requirem=
ents or can be modified to do so, great.  Right now, we're just trying to d=
efine the set of requirements.

TA management is also subordinate to the larger security management aspects=
 of an IT environment. If we can't manage user access, policy distribution =
and policy enforcement in a large IT network, all bets are off. The most ge=
nius TA management protocol in the world won't save us. And since we alread=
y depend on the current security management for success, we night as well a=
llow it to manage the policies concerning trust in TAs.



I believe more in a TA management solution where clients "retrieve" the TA =
they have been instructed to use by the overall policy management infrastru=
cture (whatever it is), rather than a model where a TA Manager push this in=
formation onto the client and actively manages the TA stores in the client =
and server hosts.



[CRW] I don't see the confusion w.r.t push/pull. There is no intent to requ=
ire a push model exclusively or even favor a push model.  What text is crea=
ting this impression?





Denis comments:

I want to address Denis comments in principle rather than detailed in depth=
 at this point.



I agree in principle with Denis observation that the current approach is st=
ructured as a push model over a pull model. This is a disconnect from how m=
ost systems and current protocols work today. I strongly encourage the pull=
 model to be the main and default principle for TA management.

[CRW] See above re: push/pull.



I disagree that a TA Management structure need to be structured around the =
root cross certification scheme of CMP (old with new and new with old signi=
ng). It should be possible, but this is seldom implemented in reality.



I disagree with Denis on the issue of including validation policies into th=
e requirements of this protocol.

The reasons are again that trust policy management is a lot larger than wha=
t we possibly can define in the PKIX working group. Whatever we would come =
up with other than standardized protocol elements to be used by other proto=
cols, we will end up guessing and most likely miss the target, or just serv=
e a few corner cases with a complex protocol.







Comments on the TA req document:



I think there is one fundamental flaw in the general assumptions of the doc=
ument:



>From 1.1



   Trust relationships between PKIs are negotiated by policy
   authorities.  Negotiations frequently require significant time to
   ensure all participating parties' requirements are satisfied.  These
   requirements are expressed, to some extent, in public key
   certificates via policy constraints, name constraints and etc.  In
   order for these requirements to be enforced, trust anchor stores must
   be managed in accord with policy authority intentions and avoid
   circumventing constraints defined in a cross-certificate by
   recognizing the subject of the cross certificate as a trust anchor.





I find this assumption wrong as management of trust anchors is a matter of =
local policy only.

The whole path processing logic is designed so that the statements made by =
each CA will be enforced appropriately in accordance with the TA that the l=
ocal relying party has chosen as a result of local policy only.



[CRW] I can see where this text is confusing.  The policy authority referen=
ced here is the local policy authority.  The point of the requirement is th=
at when a local policy authority issues a cross certificate to an external =
enterprise root, it should not be possible to avoid the constraints include=
d in the cross-cert by installing the self-signed certificate issued to the=
 subject of the cross-certificate.  The trust anchor stores subject to the =
local policy authority must be managed in accord with the policy authority'=
s intentions or all bets are off.



This defeats a substantial part of the rationale for having a push model ra=
ther than a pull model.

[CRW] See above re: push/pull.





Conclusion



The working group has already decided to adopt this work, and it is not my =
intention to try to block its progress.

I'm just expressing the rationale why I doubt its usefulness in its current=
 form and why I have problems providing detailed comments on the requiremen=
ts document.



[CRW] Assuming the language is clarified such that push is not the focus, w=
hat remaining concerns do you have?









Stefan Santesson
Senior Program Manager
Windows Security, Standards


--_000_9F11911AED01D24BAA1C2355723C3D32195A6F3934EAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.h41
	{mso-style-name:h41;
	font-family:"Courier New";
	font-weight:bold;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span style=3D'color:#1F49=
7D'>Carl,<o:p></o:p></span></a></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW] I don't see the
confusion w.r.t push/pull. There is no intent to require a push model
exclusively&nbsp;or even favor a push model.&nbsp; What text is creating th=
is
impression?</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>This is cle=
arly
requirements for an active push protocol. For example:<o:p></o:p></span></p=
>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><a name=3Dsection-3.3.1><b><span lang=3DEN style=3D'fo=
nt-size:
12.0pt;font-family:"Courier New"'>3.3.1</span></b></a><b><span lang=3DEN
style=3D'font-size:12.0pt;font-family:"Courier New"'>.&nbsp; Functional
Requirements</span></b><span lang=3DEN style=3D'font-size:12.0pt;font-famil=
y:"Courier New"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'>&nbsp;&nbsp;
A protocol for TA management must allow a TA management transaction<o:p></o=
:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'>&nbsp;&nbsp;
to be directed to:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
All TA stores for which the manager is responsible<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
An enumerated list of one or more groups of trust anchor stores<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
An individual trust anchor store<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:12.0pt;font-family:=
"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>This is onl=
y relevant
requirement for a push model. And it goes on and on throughout the
requirements.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>And that is=
 fine. &nbsp;I&#8217;d
rather have it saying that it is requirements for a specific type of TA man=
agement
protocol out of many possible management models.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW]&nbsp;There is no
pretending that mechanisms do not exist.&nbsp; This draft simply defines a =
set
of requirements for these mechanisms with an aim of establishing&nbsp;an
interoperable solution.&nbsp; If existing mechanisms meet the requirements =
or
can be modified to do so, great.&nbsp; Right now, we're just trying to
define&nbsp;the set of requirements.</span><span lang=3DEN-US><o:p></o:p></=
span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>My point is=
 that
these requirements does not fit the policy management model that is used in=
 the
systems I know of. The main reason is that the current document describes
requirements for active direct management of TA stores instead of a pull mo=
del
as a result of a separate policy enforcement solution.<o:p></o:p></span></p=
>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW] Assuming the lang=
uage
is clarified such that push is not the focus,&nbsp;what remaining concerns =
do
you have?</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"C=
alibri","sans-serif"'>&nbsp;</span><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:blue'>
</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>I don&#8217=
;t think
that is a language issue. I would rather accept that this is a requirements
document for a push oriented protocol, but to clarify that other models may=
 be
used where this protocol may be redundant.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>It would al=
so be
great to position this document among possible TA management models.<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>If I could =
wish for something
more, then that would be to separate out the requirements for standardizing=
 the
syntax of a TA list form the requirements on a TA management protocol.<o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'>The reason =
is that we
agreed to run these specifications separately.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'color:#1F497D'><o:p>&nbsp;=
</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> Carl Wallace [mailto:CWallace@cygnacom.=
com]
<br>
<b>Sent:</b> den 23 oktober 2008 17:03<br>
<b>To:</b> Stefan Santesson; [e-mail]<br>
<b>Subject:</b> RE: Comments on the TA requirements document<o:p></o:p></sp=
an></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif";
color:blue'>inline...</span><span style=3D'font-size:12.0pt;font-family:"Ti=
mes New Roman","serif"'><o:p></o:p></span></p>

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

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

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span lan=
g=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>

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

</span></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></=
b><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[e-mail] [mailto:[e-mail]] <b>On Be=
half
Of </b>Stefan Santesson<br>
<b>Sent:</b> Thursday, October 23, 2008 10:24 AM<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> Comments on the TA requirements document</span><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New Roman","serif=
"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>Commenting on
draft-ietf-pkix-ta-mgmt-reqs-01, both in general and as response to Denis
Detailed comments.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><a
href=3D"http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01">http://=
tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01</a><o:p></o:p></span></=
p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I thought I better post this commen=
t as a
separate e-mail to keep it clear from other threads.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>On the general issue I am, as I hav=
e stated
before, &nbsp;not overly enthusiastic about the TA management protocol. The
main reason is that I can&#8217;t see that I need one.<o:p></o:p></span></p=
>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>TA management is just another as=
pect
of policy management and modern complex &nbsp;IT environments already have
systems and tools to deal with policy management. It may not be pretty, and=
 it
may not be generic, but it&#8217;s there and we can&#8217;t pretend it&#821=
7;s
not.</span><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial"=
,"sans-serif";
color:blue'>&nbsp;</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW]&nbsp;There is no
pretending that mechanisms do not exist.&nbsp; This draft simply defines a =
set
of requirements for these mechanisms with an aim of establishing&nbsp;an
interoperable solution.&nbsp; If existing mechanisms meet the requirements =
or
can be modified to do so, great.&nbsp; Right now, we're just trying to
define&nbsp;the set of requirements.</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>TA management is also subordinat=
e to
the larger security management aspects of an IT environment. If we can&#821=
7;t
manage user access, policy distribution and policy enforcement in a large I=
T
network, all bets are off. The most genius TA management protocol in the wo=
rld
won&#8217;t save us. And since we already depend on the current security
management for success, we night as well allow it to manage the policies
concerning trust in TAs.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I believe more in a TA managemen=
t
solution where clients &#8220;retrieve&#8221; the TA they have been instruc=
ted
to use by the overall policy management infrastructure (whatever it is), ra=
ther
than a model where a TA Manager push this information onto the client and
actively manages the TA stores in the client and server hosts. <o:p></o:p><=
/span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW] I don't see the
confusion w.r.t push/pull. There is no intent to require a push model
exclusively&nbsp;or even favor a push model.&nbsp; What text is creating th=
is
impression?</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif"'><o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><u><span lang=3DEN-US
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Denis comment=
s:<o:p></o:p></span></u></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I want to address Denis comments=
 in
principle rather than detailed in depth at this point.<o:p></o:p></span></p=
>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I agree in principle with Denis
observation that the current approach is structured as a push model over a =
pull
model. This is a disconnect from how most systems and current protocols wor=
k
today. I strongly encourage the pull model to be the main and default princ=
iple
for TA management.</span><span lang=3DEN-US style=3D'font-size:10.0pt;font-=
family:
"Arial","sans-serif";color:blue'>&nbsp;</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW] See above re:
push/pull.</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"=
Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I disagree that a TA Management
structure need to be structured around the root cross certification scheme =
of
CMP (old with new and new with old signing). It should be possible, but thi=
s is
seldom implemented in reality.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I disagree with Denis on the iss=
ue
of including validation policies into the requirements of this protocol.<o:=
p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>The reasons are again that trust
policy management is a lot larger than what we possibly can define in the P=
KIX
working group. Whatever we would come up with other than standardized proto=
col
elements to be used by other protocols, we will end up guessing and most li=
kely
miss the target, or just serve a few corner cases with a complex protocol.<=
/span><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:blue'>&nbsp;</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><u><span lang=3DEN-US
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Comments on t=
he TA
req document:&nbsp;<o:p></o:p></span></u></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I think there is one fundamental
flaw in the general assumptions of the document:&nbsp;<o:p></o:p></span></p=
>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>From 1.1<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Calibri","sans-serif"'>&nbsp;&nbsp; Trust relationships
between PKIs are negotiated by policy<br>
&nbsp;&nbsp; authorities.&nbsp; Negotiations frequently require significant
time to<br>
&nbsp;&nbsp; ensure all participating parties' requirements are
satisfied.&nbsp; These<br>
&nbsp;&nbsp; requirements are expressed, to some extent, in public key<br>
&nbsp;&nbsp; certificates via policy constraints, name constraints and
etc.&nbsp; In<br>
&nbsp;&nbsp; order for these requirements to be enforced, trust anchor <u>s=
tores
must<br>
&nbsp;&nbsp; be managed in accord with policy authority intentions</u> and
avoid<br>
&nbsp;&nbsp; circumventing constraints defined in a cross-certificate by<br=
>
&nbsp;&nbsp; recognizing the subject of the cross certificate as a trust
anchor.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I find this assumption wrong as
management of trust anchors is a matter of local policy only.<o:p></o:p></s=
pan></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>The whole path processing logic =
is
designed so that the statements made by each CA will be enforced appropriat=
ely
in accordance with the TA that the local relying party has chosen as a resu=
lt
of local policy only.</span><span lang=3DEN-US style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif";color:blue'>&nbsp;</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'>&nbsp;<o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW]&nbsp;I can see wh=
ere
this text is confusing.&nbsp; The policy authority referenced here is the l=
ocal
policy authority.&nbsp; The point of the requirement is that when a local
policy authority issues a cross certificate&nbsp;to an
external&nbsp;enterprise&nbsp;root, it should not be possible to avoid the
constraints included in the cross-cert by installing the self-signed
certificate issued to the subject of the cross-certificate.&nbsp;&nbsp;The
trust anchor stores subject&nbsp;to the local policy authority must be mana=
ged
in accord with the policy authority's&nbsp;intentions or all bets are off.<=
/span><span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>=
&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>This defeats a substantial part =
of
the rationale for having a push model rather than a pull model.</span><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:blue'>&nbsp;</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW] See above re:
push/pull.</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"=
Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><u><span lang=3DEN-US
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Conclusion<o:=
p></o:p></span></u></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>The working group has already
decided to adopt this work, and it is not my intention to try to block its
progress.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I&#8217;m just expressing the
rationale why I doubt its usefulness in its current form and why I have
problems providing detailed comments on the requirements document.</span><s=
pan
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:blue'>&nbsp;</span><o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'>&nbsp;<o:p></o:p></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Arial","sans-serif";color:blue'>[CRW] Assuming the lang=
uage
is clarified such that push is not the focus,&nbsp;what remaining concerns =
do
you have?</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"C=
alibri","sans-serif"'>&nbsp;</span><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:blue'>
</span><span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","=
sans-serif"'><o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</blockquote>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D32195A6F3934EAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NF2dH0015371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 08:02:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NF2dlS015370; Thu, 23 Oct 2008 08:02:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9NF2bnw015363 for <[e-mail]>; Thu, 23 Oct 2008 08:02:38 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 27207 invoked from network); 23 Oct 2008 14:49:03 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;23 Oct 2008 14:49:03 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 23 Oct 2008 14:49:02 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93520.623A25F4"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Comments on the TA requirements document
Date: Thu, 23 Oct 2008 11:02:31 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on the TA requirements document
Thread-Index: Ack1Gw5RwCiacYlDQg28ouWioo7jOwAAqt+w
References: <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C93520.623A25F4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

inline...


________________________________

	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
	Sent: Thursday, October 23, 2008 10:24 AM
	To: [e-mail]
	Subject: Comments on the TA requirements document
=09
=09

	Commenting on draft-ietf-pkix-ta-mgmt-reqs-01, both in general
and as response to Denis Detailed comments.

	http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01

	=20

	I thought I better post this comment as a separate e-mail to
keep it clear from other threads.

	=20

	On the general issue I am, as I have stated before,  not overly
enthusiastic about the TA management protocol. The main reason is that I
can't see that I need one.

	TA management is just another aspect of policy management and
modern complex  IT environments already have systems and tools to deal
with policy management. It may not be pretty, and it may not be generic,
but it's there and we can't pretend it's not.=20

	[CRW] There is no pretending that mechanisms do not exist.  This
draft simply defines a set of requirements for these mechanisms with an
aim of establishing an interoperable solution.  If existing mechanisms
meet the requirements or can be modified to do so, great.  Right now,
we're just trying to define the set of requirements.

	TA management is also subordinate to the larger security
management aspects of an IT environment. If we can't manage user access,
policy distribution and policy enforcement in a large IT network, all
bets are off. The most genius TA management protocol in the world won't
save us. And since we already depend on the current security management
for success, we night as well allow it to manage the policies concerning
trust in TAs.

	=20

	I believe more in a TA management solution where clients
"retrieve" the TA they have been instructed to use by the overall policy
management infrastructure (whatever it is), rather than a model where a
TA Manager push this information onto the client and actively manages
the TA stores in the client and server hosts.=20

	=20

	[CRW] I don't see the confusion w.r.t push/pull.  There is no
intent to require a push model exclusively or even favor a push model.
What text is creating this impression?

	=20

	=20

	Denis comments:

	I want to address Denis comments in principle rather than
detailed in depth at this point.

	=20

	I agree in principle with Denis observation that the current
approach is structured as a push model over a pull model. This is a
disconnect from how most systems and current protocols work today. I
strongly encourage the pull model to be the main and default principle
for TA management.=20

	[CRW] See above re: push/pull.=20

	=20

	I disagree that a TA Management structure need to be structured
around the root cross certification scheme of CMP (old with new and new
with old signing). It should be possible, but this is seldom implemented
in reality.

	=20

	I disagree with Denis on the issue of including validation
policies into the requirements of this protocol.

	The reasons are again that trust policy management is a lot
larger than what we possibly can define in the PKIX working group.
Whatever we would come up with other than standardized protocol elements
to be used by other protocols, we will end up guessing and most likely
miss the target, or just serve a few corner cases with a complex
protocol.=20

	=20

	=20

	=20

	Comments on the TA req document:=20

	=20

	I think there is one fundamental flaw in the general assumptions
of the document:=20

	=20

	From 1.1

	=20

	   Trust relationships between PKIs are negotiated by policy
	   authorities.  Negotiations frequently require significant
time to
	   ensure all participating parties' requirements are satisfied.
These
	   requirements are expressed, to some extent, in public key
	   certificates via policy constraints, name constraints and
etc.  In
	   order for these requirements to be enforced, trust anchor
stores must
	   be managed in accord with policy authority intentions and
avoid
	   circumventing constraints defined in a cross-certificate by
	   recognizing the subject of the cross certificate as a trust
anchor.

	=20

	=20

	I find this assumption wrong as management of trust anchors is a
matter of local policy only.

	The whole path processing logic is designed so that the
statements made by each CA will be enforced appropriately in accordance
with the TA that the local relying party has chosen as a result of local
policy only.=20

	=20

	[CRW] I can see where this text is confusing.  The policy
authority referenced here is the local policy authority.  The point of
the requirement is that when a local policy authority issues a cross
certificate to an external enterprise root, it should not be possible to
avoid the constraints included in the cross-cert by installing the
self-signed certificate issued to the subject of the cross-certificate.
The trust anchor stores subject to the local policy authority must be
managed in accord with the policy authority's intentions or all bets are
off.=20

	=20

	This defeats a substantial part of the rationale for having a
push model rather than a pull model.=20

	[CRW] See above re: push/pull.=20

	=20

	=20

	Conclusion

	=20

	The working group has already decided to adopt this work, and it
is not my intention to try to block its progress.

	I'm just expressing the rationale why I doubt its usefulness in
its current form and why I have problems providing detailed comments on
the requirements document.=20

	=20

	[CRW] Assuming the language is clarified such that push is not
the focus, what remaining concerns do you have? =20

	=20

	=20

	=20

	=20

	=20

	=20

	Stefan Santesson

	Senior Program Manager

	Windows Security, Standards

	=20


------_=_NextPart_001_01C93520.623A25F4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20
"urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20
"urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =
=3D=20
"urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20
"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20
"urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20
"http://www.w3.org/TR/REC-html40" xmlns:q =3D=20
"http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 =
=3D=20
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20
"http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20
"http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20
"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec =
=3D=20
"http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20
"http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf =3D=20
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf =3D=20
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver =3D=20
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m =
=3D=20
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels =3D=20
"http://schemas.openxmlformats.org/package/2006/relationships" =
xmlns:ex12t =3D=20
"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m =
=3D=20
"http://schemas.microsoft.com/exchange/services/2006/messages" XMLNS:Z =
=3D=20
"urn:schemas-microsoft-com:" xmlns:st =3D "=01"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16735" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: SimSun;
}
@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: @SimSun;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt =
70.85pt; }
P.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
"Calibri","sans-serif"
}
LI.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
"Calibri","sans-serif"
}
DIV.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
"Calibri","sans-serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: =
"Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: =
auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal-compose
}
.MsoChpDefault {
	mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DSV vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D439344314-23102008>inline...</SPAN></FONT></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =

  [mailto:[e-mail]] <B>On Behalf Of </B>Stefan=20
  Santesson<BR><B>Sent:</B> Thursday, October 23, 2008 10:24 =
AM<BR><B>To:</B>=20
  [e-mail]<BR><B>Subject:</B> Comments on the TA requirements=20
  document<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><SPAN lang=3DEN-US>Commenting on=20
  draft-ietf-pkix-ta-mgmt-reqs-01, both in general and as response to =
Denis=20
  Detailed comments.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US><A=20
  =
href=3D"http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01">http:=
//tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01</A><o:p></o:p></SPA=
N></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US>I thought I better post this =
comment as a=20
  separate e-mail to keep it clear from other =
threads.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US>On the general issue I am, as =
I have=20
  stated before, &nbsp;not overly enthusiastic about the TA management =
protocol.=20
  The main reason is that I can&#8217;t see that I need =
one.<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">TA =
management is=20
  just another aspect of policy management and modern complex &nbsp;IT=20
  environments already have systems and tools to deal with policy =
management. It=20
  may not be pretty, and it may not be generic, but it&#8217;s there and =
we can&#8217;t=20
  pretend it&#8217;s not.<SPAN class=3D439344314-23102008><FONT =
face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'"><SPAN=20
  class=3D439344314-23102008><FONT face=3DArial color=3D#0000ff=20
  size=3D2>[CRW]&nbsp;There is no pretending that mechanisms do not =
exist.&nbsp;=20
  This draft simply defines a set of requirements for these mechanisms =
with an=20
  aim of establishing&nbsp;an interoperable solution.&nbsp; If existing=20
  mechanisms meet the requirements or can be modified to do so, =
great.&nbsp;=20
  Right now, we're just trying to define&nbsp;the set of=20
  requirements.</FONT></SPAN></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">TA =
management is=20
  also subordinate to the larger security management aspects of an IT=20
  environment. If we can&#8217;t manage user access, policy distribution =
and policy=20
  enforcement in a large IT network, all bets are off. The most genius =
TA=20
  management protocol in the world won&#8217;t save us. And since we =
already depend on=20
  the current security management for success, we night as well allow it =
to=20
  manage the policies concerning trust in TAs.<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I =
believe more in=20
  a TA management solution where clients &#8220;retrieve&#8221; the TA =
they have been=20
  instructed to use by the overall policy management infrastructure =
(whatever it=20
  is), rather than a model where a TA Manager push this information onto =
the=20
  client and actively manages the TA stores in the client and server =
hosts.=20
  <o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p><SPAN=20
  class=3D439344314-23102008><FONT face=3DArial color=3D#0000ff =
size=3D2>[CRW] I don't=20
  see the confusion w.r.t push/pull.&nbsp; There is no intent to require =
a push=20
  model exclusively&nbsp;or even favor a push model.&nbsp; What text is =
creating=20
  this impression?</FONT></SPAN></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><U><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">Denis=20
  comments:<o:p></o:p></SPAN></U></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I want =
to address=20
  Denis comments in principle rather than detailed in depth at this=20
  point.<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I agree =
in=20
  principle with Denis observation that the current approach is =
structured as a=20
  push model over a pull model. This is a disconnect from how most =
systems and=20
  current protocols work today. I strongly encourage the pull model to =
be the=20
  main and default principle for TA management.<SPAN=20
  class=3D439344314-23102008><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'"><SPAN=20
  class=3D439344314-23102008><FONT face=3DArial color=3D#0000ff =
size=3D2>[CRW] See above=20
  re: push/pull.</FONT>&nbsp;</SPAN><o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I =
disagree that a=20
  TA Management structure need to be structured around the root cross=20
  certification scheme of CMP (old with new and new with old signing). =
It should=20
  be possible, but this is seldom implemented in =
reality.<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I =
disagree with=20
  Denis on the issue of including validation policies into the =
requirements of=20
  this protocol.<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">The =
reasons are=20
  again that trust policy management is a lot larger than what we =
possibly can=20
  define in the PKIX working group. Whatever we would come up with other =
than=20
  standardized protocol elements to be used by other protocols, we will =
end up=20
  guessing and most likely miss the target, or just serve a few corner =
cases=20
  with a complex protocol.<SPAN class=3D439344314-23102008><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><U><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">Comments on the=20
  TA req document:&nbsp;<o:p></o:p></SPAN></U></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I think =
there is=20
  one fundamental flaw in the general assumptions of the=20
  document:&nbsp;<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">From=20
  1.1<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;&nbsp;=20
  Trust relationships between PKIs are negotiated by =
policy<BR>&nbsp;&nbsp;=20
  authorities.&nbsp; Negotiations frequently require significant time=20
  to<BR>&nbsp;&nbsp; ensure all participating parties' requirements are=20
  satisfied.&nbsp; These<BR>&nbsp;&nbsp; requirements are expressed, to =
some=20
  extent, in public key<BR>&nbsp;&nbsp; certificates via policy =
constraints,=20
  name constraints and etc.&nbsp; In<BR>&nbsp;&nbsp; order for these=20
  requirements to be enforced, trust anchor <U>stores =
must<BR>&nbsp;&nbsp; be=20
  managed in accord with policy authority intentions</U> and=20
  avoid<BR>&nbsp;&nbsp; circumventing constraints defined in a =
cross-certificate=20
  by<BR>&nbsp;&nbsp; recognizing the subject of the cross certificate as =
a trust=20
  anchor.<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">I find =
this=20
  assumption wrong as management of trust anchors is a matter of local =
policy=20
  only.<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">The =
whole path=20
  processing logic is designed so that the statements made by each CA =
will be=20
  enforced appropriately in accordance with the TA that the local =
relying party=20
  has chosen as a result of local policy only.<SPAN=20
  class=3D439344314-23102008><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'"><SPAN=20
  class=3D439344314-23102008></SPAN></SPAN>&nbsp;</P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'"><SPAN=20
  class=3D439344314-23102008><FONT face=3DArial color=3D#0000ff =
size=3D2>[CRW]&nbsp;I=20
  can see where this text is confusing.&nbsp; The policy authority =
referenced=20
  here is the local policy authority.&nbsp; The point of the requirement =
is that=20
  when a local policy authority issues a cross certificate&nbsp;to an=20
  external&nbsp;enterprise&nbsp;root, it should not be possible to avoid =
the=20
  constraints included in the cross-cert by installing the self-signed=20
  certificate issued to the subject of the =
cross-certificate.&nbsp;&nbsp;The=20
  trust anchor stores subject&nbsp;to the local policy authority must be =
managed=20
  in accord with the policy authority's&nbsp;intentions or all bets are=20
  off.</FONT>&nbsp;</SPAN><o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">This =
defeats a=20
  substantial part of the rationale for having a push model rather than =
a pull=20
  model.<SPAN class=3D439344314-23102008><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'"><SPAN=20
  class=3D439344314-23102008><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'"><SPAN=20
  class=3D439344314-23102008><FONT face=3DArial color=3D#0000ff =
size=3D2>[CRW] See above=20
  re: push/pull.</FONT></SPAN></SPAN>&nbsp;</SPAN><o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><U><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">Conclusion<o:p></o:p></SPAN></U></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'">The =
working group=20
  has already decided to adopt this work, and it is not my intention to =
try to=20
  block its progress.<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">I&#8217;m just=20
  expressing the rationale why I doubt its usefulness in its current =
form and=20
  why I have problems providing detailed comments on the requirements=20
  document.<SPAN class=3D439344314-23102008><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'"><SPAN=20
  class=3D439344314-23102008></SPAN></SPAN>&nbsp;</P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Calibri','sans-serif'"><SPAN=20
  class=3D439344314-23102008><FONT face=3DArial color=3D#0000ff =
size=3D2>[CRW] Assuming=20
  the language is clarified such that push is not the focus,&nbsp;what =
remaining=20
  concerns do you have?</FONT>&nbsp;<FONT face=3DArial color=3D#0000ff =
size=3D2>=20
  </FONT></SPAN><o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
  <P style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; FONT-FAMILY: =
'Calibri','sans-serif'">&nbsp;<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
  Santesson</SPAN></B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 12pt; COLOR: #1f497d; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Senior=20
  Program Manager</SPAN><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Windows=20
  Security, Standards</SPAN></B><SPAN lang=3DEN-US=20
  style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P></DIV></BLOCKQUOTE></BODY></HTML=
>

------_=_NextPart_001_01C93520.623A25F4--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NEpXY3014444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 07:51:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NEpXCx014443; Thu, 23 Oct 2008 07:51:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NEpLnr014427 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 23 Oct 2008 07:51:32 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 23 Oct 2008 15:51:20 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 23 Oct 2008 15:51:20 +0100
From: Stefan Santesson <[e-mail]>
To: Russ Housley <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Thu, 23 Oct 2008 15:51:18 +0100
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: Ack1Go7JVY8QHw2YQOGdgAr4053yAAAAI/1Q
Message-ID: <[e-mail]>
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Nowhere.

That was a hypothetical example of something that would be equally hard to =
implement if it was added into current path processing.
I was just trying to make a point :)


Let me see if I can clarify.

The current syntax includes SecurityCategory

     SecurityCategory ::=3D SEQUENCE {
       type      [0]  IMPLICIT OBJECT IDENTIFIER,
       value     [1]  ANY DEFINED BY type
     }

    - securityCategories provides additional authorization information.


So the semantics of the ClassList and Security category is defined by the p=
olicyID, and it is extensible.

     - policyId identifies the security policy to which the clearance
      relates.  The policyId indicates the semantics of the classList
      and securityCategory fields.



In the path processing logic I'm supposed to calculate the intersection of =
clearance of the certificates in the path

   Assuming a certification path consisting of n certificates, the
   effective-clearance for the subject of the end certificate is the
   intersection of Clearance in the subject certificate, Authority
   Clearance Constraints, if present, in trust anchor and all Authority
   Clearance Constraints present in intermediate certificates.


Now how do I calculate this intersection? Well 4.1.1.3 gives us the answer,=
 but in short it requires me to process values of unknown semantics, unless=
 I know the policyId.
I.e.:

       -- Calculate securityCategories intersection in accordance with
          guidelines associated with the security policy represented by
          the policyID.



That logic may also define mappings. E.g. the semantics for a given Securit=
yCategory may be equal to another SecurityCategory. There is at least nothi=
ng suggesting that this is not allowed.
All in all, I may need new code for each policyId, unless I know them befor=
ehand and the semantics they define.



Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: den 23 oktober 2008 16:20
> To: Stefan Santesson
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
> Stefan:
>
> Where does the document say anything about mapping between security
> policies?
>
> Russ
>
> At 10:40 AM 10/22/2008, Stefan Santesson wrote:
>
> >The major problem I have is that there is no set logic for the
> >constraints processing.
> >
> >I have been told that there are current implementations of this and
> >that this fact itself should prove that it is implementable.
> >It is however my strong guess that current implementations work only
> >because they assume no difference in calculating intersections of
> >SecurityCategories for different known PolicyIDs.
> >
> >The problem comes when someone introduce a PolicyID which defines a
> >different intersection logic or order of classes.
> >The only way I can accept that Policy ID is to write new code.
> >
> >There is a huge difference between allowing inclusion of different
> >policy OIDs, than to allow then to define individual path processing
> logic.
> >
> >Just imagine if every certificate policy OID was allowed to specify
> >individual mapping logic (Like policy A is equal to policy B,C and
> >D), and then expect the path processing code to learn the mapping
> >logic for each and every Policy OID.
> >
> >I don't think anyone would consider that a good architecture and
> >protocol design to standardize.
> >But as far as I read it, this is precisely what the current CA
> >clearance constraints proposal wants us to do.
> >
> >
> >
> >
> >Stefan Santesson
> >Senior Program Manager
> >Windows Security, Standards
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:owner-ietf-
> > > [e-mail]] On Behalf Of Turner, Sean P.
> > > Sent: den 14 oktober 2008 14:59
> > > To: 'Santosh Chokhani'; 'Timothy J. Miller'; 'Carl Wallace'
> > > Cc: [e-mail]
> > > Subject: RE: draft-turner-caclearanceconstraints-01.txt
> > >
> > >
> > >
> > > I just wanted to add that the ID does not address relationships
> between
> > > security policies.  It only addresses whether the EE's asserted
> > > clearance is
> > > within the issuer's allowed clearance set.
> > >
> > > spt
> > >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Santosh Chokhani
> > > Sent: Monday, October 13, 2008 10:33 AM
> > > To: Timothy J. Miller; Carl Wallace
> > > Cc: [e-mail]
> > > Subject: RE: draft-turner-caclearanceconstraints-01.txt
> > >
> > >
> > > Differences in various policies are articulated using the
> > > security policy OID in the clearance structure that has been
> > > accepted by the Internet Standards Community.
> > >
> > > In addition, clearance is a well defined mathematical concept
> > > and formalized using lattice structure.  Within a security
> > > policy, Clearance consists of a hierarchical sensitivity level
> > > and non-hierarchical category set.  Two clearances within a
> > > security can be ordered or can be incomparable based on simple
> > > and well-defines mathematical rules.
> > >
> > > People in other parts of IETF are using these concepts to label
> > > the data and make information flow decisions.
> > >
> > > Some pioneering work has been done in the technical community
> > > (albeit not exposed to the IETF) in the area of comparing
> > > clearances of two security policies.
> > >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:owner-ietf-
> > > [e-mail]]
> > > On Behalf Of Timothy J. Miller
> > > Sent: Monday, October 13, 2008 10:03 AM
> > > To: Carl Wallace
> > > Cc: [e-mail]
> > > Subject: Re: draft-turner-caclearanceconstraints-01.txt
> > >
> > > Carl Wallace wrote:
> > > > I vote yes to adopting this as a PKIX work item.  Specification
> > > details
> > > > can be resolved after the draft is accepted as a working group
> draft.
> > >
> > > Can we even say for certain that clearance is a consistent
> > > enough concept within and across jurisdictions to enable a
> > > single logic for constraint processing?  I'd argue not.
> > >
> > > E.g., RFC3281 talks about "the" basic clearance hierarchy, which
> > > doesn't
> > >
> > > even exist.  What's the relationship between NATO CONFIDENTIAL
> > > and US UNCLASSIFIED CONTROLLED INFORMATION?  How about US UCI
> > > and US FOR OFFICIAL USE ONLY?  US SECRET/NOFOREIGN?  US TS/SCI
> > > and TS/SAP?  And that's without even getting into the obscure
> > > corners of the US alone.
> > >
> > > What I'm trying to say is that classification is *not* a strict
> > > hierarchy.  It's semi-structured.  We have trouble enough
> > > figuring this stuff out in the real world without having to
> > > write code for it.  :)
> > >
> > > Presuming I have a vote, I vote no.
> > >
> > > -- Tim
> > >
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NEOXoq012706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 07:24:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NEOXIJ012705; Thu, 23 Oct 2008 07:24:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NEOVlS012698 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 23 Oct 2008 07:24:32 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 23 Oct 2008 15:24:30 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Thu, 23 Oct 2008 15:24:30 +0100
From: Stefan Santesson <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Thu, 23 Oct 2008 15:24:27 +0100
Subject: Comments on the TA requirements document
Thread-Topic: Comments on the TA requirements document
Thread-Index: Ack1Gw5RwCiacYlDQg28ouWioo7jOw==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D32195A6F388BEAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Commenting on draft-ietf-pkix-ta-mgmt-reqs-01, both in general and as respo=
nse to Denis Detailed comments.
http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01

I thought I better post this comment as a separate e-mail to keep it clear =
from other threads.

On the general issue I am, as I have stated before,  not overly enthusiasti=
c about the TA management protocol. The main reason is that I can't see tha=
t I need one.

TA management is just another aspect of policy management and modern comple=
x  IT environments already have systems and tools to deal with policy manag=
ement. It may not be pretty, and it may not be generic, but it's there and =
we can't pretend it's not.

TA management is also subordinate to the larger security management aspects=
 of an IT environment. If we can't manage user access, policy distribution =
and policy enforcement in a large IT network, all bets are off. The most ge=
nius TA management protocol in the world won't save us. And since we alread=
y depend on the current security management for success, we night as well a=
llow it to manage the policies concerning trust in TAs.



I believe more in a TA management solution where clients "retrieve" the TA =
they have been instructed to use by the overall policy management infrastru=
cture (whatever it is), rather than a model where a TA Manager push this in=
formation onto the client and actively manages the TA stores in the client =
and server hosts.







Denis comments:

I want to address Denis comments in principle rather than detailed in depth=
 at this point.



I agree in principle with Denis observation that the current approach is st=
ructured as a push model over a pull model. This is a disconnect from how m=
ost systems and current protocols work today. I strongly encourage the pull=
 model to be the main and default principle for TA management.



I disagree that a TA Management structure need to be structured around the =
root cross certification scheme of CMP (old with new and new with old signi=
ng). It should be possible, but this is seldom implemented in reality.



I disagree with Denis on the issue of including validation policies into th=
e requirements of this protocol.

The reasons are again that trust policy management is a lot larger than wha=
t we possibly can define in the PKIX working group. Whatever we would come =
up with other than standardized protocol elements to be used by other proto=
cols, we will end up guessing and most likely miss the target, or just serv=
e a few corner cases with a complex protocol.







Comments on the TA req document:



I think there is one fundamental flaw in the general assumptions of the doc=
ument:



>From 1.1



   Trust relationships between PKIs are negotiated by policy
   authorities.  Negotiations frequently require significant time to
   ensure all participating parties' requirements are satisfied.  These
   requirements are expressed, to some extent, in public key
   certificates via policy constraints, name constraints and etc.  In
   order for these requirements to be enforced, trust anchor stores must
   be managed in accord with policy authority intentions and avoid
   circumventing constraints defined in a cross-certificate by
   recognizing the subject of the cross certificate as a trust anchor.





I find this assumption wrong as management of trust anchors is a matter of =
local policy only.

The whole path processing logic is designed so that the statements made by =
each CA will be enforced appropriately in accordance with the TA that the l=
ocal relying party has chosen as a result of local policy only.



This defeats a substantial part of the rationale for having a push model ra=
ther than a pull model.





Conclusion



The working group has already decided to adopt this work, and it is not my =
intention to try to block its progress.

I'm just expressing the rationale why I doubt its usefulness in its current=
 form and why I have problems providing detailed comments on the requiremen=
ts document.









Stefan Santesson
Senior Program Manager
Windows Security, Standards


--_000_9F11911AED01D24BAA1C2355723C3D32195A6F388BEAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>Commenting on draft-ietf-pkix-ta-mg=
mt-reqs-01,
both in general and as response to Denis Detailed comments.<o:p></o:p></spa=
n></p>

<p class=3DMsoNormal><span lang=3DEN-US><a
href=3D"http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01">http://=
tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01</a><o:p></o:p></span></=
p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I thought I better post this commen=
t as a
separate e-mail to keep it clear from other threads.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>On the general issue I am, as I hav=
e stated
before, &nbsp;not overly enthusiastic about the TA management protocol. The
main reason is that I can&#8217;t see that I need one.<o:p></o:p></span></p=
>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>TA management is just another as=
pect
of policy management and modern complex &nbsp;IT environments already have
systems and tools to deal with policy management. It may not be pretty, and=
 it
may not be generic, but it&#8217;s there and we can&#8217;t pretend it&#821=
7;s
not.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>TA management is also subordinat=
e to
the larger security management aspects of an IT environment. If we can&#821=
7;t
manage user access, policy distribution and policy enforcement in a large I=
T
network, all bets are off. The most genius TA management protocol in the wo=
rld
won&#8217;t save us. And since we already depend on the current security ma=
nagement
for success, we night as well allow it to manage the policies concerning tr=
ust
in TAs.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I believe more in a TA managemen=
t
solution where clients &#8220;retrieve&#8221; the TA they have been instruc=
ted
to use by the overall policy management infrastructure (whatever it is), ra=
ther
than a model where a TA Manager push this information onto the client and
actively manages the TA stores in the client and server hosts. <o:p></o:p><=
/span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><u><span lang=3DEN-US
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Denis comment=
s:<o:p></o:p></span></u></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I want to address Denis comments=
 in
principle rather than detailed in depth at this point.<o:p></o:p></span></p=
>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I agree in principle with Denis
observation that the current approach is structured as a push model over a =
pull
model. This is a disconnect from how most systems and current protocols wor=
k
today. I strongly encourage the pull model to be the main and default princ=
iple
for TA management.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I disagree that a TA Management
structure need to be structured around the root cross certification scheme =
of
CMP (old with new and new with old signing). It should be possible, but thi=
s is
seldom implemented in reality.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I disagree with Denis on the iss=
ue
of including validation policies into the requirements of this protocol.<o:=
p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>The reasons are again that trust
policy management is a lot larger than what we possibly can define in the P=
KIX
working group. Whatever we would come up with other than standardized proto=
col
elements to be used by other protocols, we will end up guessing and most li=
kely
miss the target, or just serve a few corner cases with a complex protocol.<=
o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><u><span lang=3DEN-US
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Comments on t=
he TA
req document:&nbsp;<o:p></o:p></span></u></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I think there is one fundamental
flaw in the general assumptions of the document:&nbsp;<o:p></o:p></span></p=
>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>From 1.1<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
10.0pt;font-family:"Calibri","sans-serif"'>&nbsp;&nbsp; Trust relationships
between PKIs are negotiated by policy<br>
&nbsp;&nbsp; authorities.&nbsp; Negotiations frequently require significant
time to<br>
&nbsp;&nbsp; ensure all participating parties' requirements are
satisfied.&nbsp; These<br>
&nbsp;&nbsp; requirements are expressed, to some extent, in public key<br>
&nbsp;&nbsp; certificates via policy constraints, name constraints and
etc.&nbsp; In<br>
&nbsp;&nbsp; order for these requirements to be enforced, trust anchor <u>s=
tores
must<br>
&nbsp;&nbsp; be managed in accord with policy authority intentions</u> and
avoid<br>
&nbsp;&nbsp; circumventing constraints defined in a cross-certificate by<br=
>
&nbsp;&nbsp; recognizing the subject of the cross certificate as a trust
anchor.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I find this assumption wrong as =
management
of trust anchors is a matter of local policy only.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>The whole path processing logic =
is
designed so that the statements made by each CA will be enforced appropriat=
ely
in accordance with the TA that the local relying party has chosen as a resu=
lt
of local policy only.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>This defeats a substantial part =
of
the rationale for having a push model rather than a pull model.<o:p></o:p><=
/span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><u><span lang=3DEN-US
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Conclusion<o:=
p></o:p></span></u></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>The working group has already de=
cided
to adopt this work, and it is not my intention to try to block its progress=
.<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>I&#8217;m just expressing the ra=
tionale
why I doubt its usefulness in its current form and why I have problems
providing detailed comments on the requirements document.<o:p></o:p></span>=
</p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><span lang=3DEN-US style=3D'f=
ont-size:
11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D32195A6F388BEAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NEKheD012436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 07:20:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NEKh6h012435; Thu, 23 Oct 2008 07:20:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9NEKWMC012409 for <[e-mail]>; Thu, 23 Oct 2008 07:20:42 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 8057 invoked by uid 0); 23 Oct 2008 14:20:28 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.145.18) by woodstock.binhost.com with SMTP; 23 Oct 2008 14:20:28 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 23 Oct 2008 10:20:20 -0400
To: Stefan Santesson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Cc: [e-mail]
In-Reply-To: <9F11911AED01D24BAA1C2355723C3D3218DDC3E0B3@EA-EXMSG-C332.e urope.corp.microsoft.com>
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan:

Where does the document say anything about mapping between security policies?

Russ

At 10:40 AM 10/22/2008, Stefan Santesson wrote:

>The major problem I have is that there is no set logic for the 
>constraints processing.
>
>I have been told that there are current implementations of this and 
>that this fact itself should prove that it is implementable.
>It is however my strong guess that current implementations work only 
>because they assume no difference in calculating intersections of 
>SecurityCategories for different known PolicyIDs.
>
>The problem comes when someone introduce a PolicyID which defines a 
>different intersection logic or order of classes.
>The only way I can accept that Policy ID is to write new code.
>
>There is a huge difference between allowing inclusion of different 
>policy OIDs, than to allow then to define individual path processing logic.
>
>Just imagine if every certificate policy OID was allowed to specify 
>individual mapping logic (Like policy A is equal to policy B,C and 
>D), and then expect the path processing code to learn the mapping 
>logic for each and every Policy OID.
>
>I don't think anyone would consider that a good architecture and 
>protocol design to standardize.
>But as far as I read it, this is precisely what the current CA 
>clearance constraints proposal wants us to do.
>
>
>
>
>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> > [e-mail]] On Behalf Of Turner, Sean P.
> > Sent: den 14 oktober 2008 14:59
> > To: 'Santosh Chokhani'; 'Timothy J. Miller'; 'Carl Wallace'
> > Cc: [e-mail]
> > Subject: RE: draft-turner-caclearanceconstraints-01.txt
> >
> >
> >
> > I just wanted to add that the ID does not address relationships between
> > security policies.  It only addresses whether the EE's asserted
> > clearance is
> > within the issuer's allowed clearance set.
> >
> > spt
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Santosh Chokhani
> > Sent: Monday, October 13, 2008 10:33 AM
> > To: Timothy J. Miller; Carl Wallace
> > Cc: [e-mail]
> > Subject: RE: draft-turner-caclearanceconstraints-01.txt
> >
> >
> > Differences in various policies are articulated using the
> > security policy OID in the clearance structure that has been
> > accepted by the Internet Standards Community.
> >
> > In addition, clearance is a well defined mathematical concept
> > and formalized using lattice structure.  Within a security
> > policy, Clearance consists of a hierarchical sensitivity level
> > and non-hierarchical category set.  Two clearances within a
> > security can be ordered or can be incomparable based on simple
> > and well-defines mathematical rules.
> >
> > People in other parts of IETF are using these concepts to label
> > the data and make information flow decisions.
> >
> > Some pioneering work has been done in the technical community
> > (albeit not exposed to the IETF) in the area of comparing
> > clearances of two security policies.
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> > [e-mail]]
> > On Behalf Of Timothy J. Miller
> > Sent: Monday, October 13, 2008 10:03 AM
> > To: Carl Wallace
> > Cc: [e-mail]
> > Subject: Re: draft-turner-caclearanceconstraints-01.txt
> >
> > Carl Wallace wrote:
> > > I vote yes to adopting this as a PKIX work item.  Specification
> > details
> > > can be resolved after the draft is accepted as a working group draft.
> >
> > Can we even say for certain that clearance is a consistent
> > enough concept within and across jurisdictions to enable a
> > single logic for constraint processing?  I'd argue not.
> >
> > E.g., RFC3281 talks about "the" basic clearance hierarchy, which
> > doesn't
> >
> > even exist.  What's the relationship between NATO CONFIDENTIAL
> > and US UNCLASSIFIED CONTROLLED INFORMATION?  How about US UCI
> > and US FOR OFFICIAL USE ONLY?  US SECRET/NOFOREIGN?  US TS/SCI
> > and TS/SAP?  And that's without even getting into the obscure
> > corners of the US alone.
> >
> > What I'm trying to say is that classification is *not* a strict
> > hierarchy.  It's semi-structured.  We have trouble enough
> > figuring this stuff out in the real world without having to
> > write code for it.  :)
> >
> > Presuming I have a vote, I vote no.
> >
> > -- Tim
> >



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NDKR1i008553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 06:20:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NDKRxE008552; Thu, 23 Oct 2008 06:20:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9NDKQrU008546 for <[e-mail]>; Thu, 23 Oct 2008 06:20:27 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 26314 invoked from network); 23 Oct 2008 13:06:53 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;23 Oct 2008 13:06:53 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 23 Oct 2008 13:06:53 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Thu, 23 Oct 2008 09:20:25 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: AcktPo1xbBGJg+IZTZOD+0tgp11GwAAAKwnQAC8iOcABlZKT4AAD3NvgACVIDNAABsE5sA==
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[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>

Stefan,

I realize that a generic structure for security categories can not be
implemented.

I hope you see the point that without casting the security categories
more concretely, I can not provide more detailed pseudo-code than saying
that take a set theoretic intersection.

If the work item is taken up, we would definitely look at option of
casting the security categories structure concretely or giving couple of
examples for different structures.=20

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Thursday, October 23, 2008 8:28 AM
To: Santosh Chokhani; [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

Santosh,

> One answer to your question will be that this can be sorted out during
> the comment period.

I have thought about that, but I would prefer not.
The reason is that this is a fundamental aspect of the standard and I
want to see that you can build a reasonable solution to a reasonable
problem before I would support to standardize it.

>
> But, specific answer to your question is that in all cases logical
> intersection of categories is computed.  Specific details beyond that
> will depend on how the categories are encoded.


I don't understand what you mean here. The current specification makes
clear that the intersection logic can change in any way for each Policy
ID.
There is no defined "default" logic and no way to tell if a PolicyID
alters this logic.
As such I can't write a code that can perform the fundamental
intersection logic of the protocol.
I would have to build a solution that allows every "user" to invoke
custom code for every PolicyID.

That to me is a too complex response to this problem, especially since I
don't think this problem should be handled in certificates at all.
And that if this would be done in certificates anyway, that we at least
should skip the constraints logic.

I miss the balance discussion. Writing a new standard comes with a cost.
We are potentially confusing the community with another specification.
We potentially promote making PKI more complex. We potentially promote
Certificates to be the right place to carry clearance information.

Just because something could be useful in some corner cases, does not
make it the right thing to standardize.



Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Santosh Chokhani
> Sent: den 22 oktober 2008 18:26
> To: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Stefan,
>
> One answer to your question will be that this can be sorted out during
> the comment period.
>
> But, specific answer to your question is that in all cases logical
> intersection of categories is computed.  Specific details beyond that
> will depend on how the categories are encoded.
>





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NDHC7b008256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 06:17:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NDHCqh008255; Thu, 23 Oct 2008 06:17:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9NDH1dE008247 for <[e-mail]>; Thu, 23 Oct 2008 06:17:11 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 26279 invoked from network); 23 Oct 2008 13:03:27 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;23 Oct 2008 13:03:27 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 23 Oct 2008 13:03:26 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Thu, 23 Oct 2008 09:16:59 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: Ack0qvGbKgFicLwXQmqh/doLPeRvuAAZmuUg
References: <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[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>

Tom,

Thanks for your input.

If this is adopted as a work item, we will consider your suggestion.

Some of the things that come to mind are casting the security categories
structure concretely or giving 1 or 2 examples.

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]]=20
Sent: Wednesday, October 22, 2008 9:02 PM
To: Santosh Chokhani
Cc: [e-mail]; [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

        Santosh:

        I have to mainly agree with Stefan about this.  I cannot see how

to implement general purpose code to handle securityCategories without a

rule governing policyID's whose security policy is unknown to the
relying=20
party.  My own guess (although without much background in this area) is=20
that the desired final condition in such a case is either for all=20
securityCategories for such a policyID to be eliminated from=20
effective-clearance, or for the Clearance containing such a policyID to
be=20
eliminated if any SecurityCategory values are encountered in the=20
end-entity certificate.
        Such an algorithm could probably be implemented with an "SPI"=20
interface, at least in Java.  That's still a lot of work for this
purpose,=20
and defining default types of SecurityCategory with known intersection=20
characteristics might be worthwhile.  The current algorithm, with no=20
defined handling for unknown policyID's, can't be implemented robustly.

                Tom Gindin




"Santosh Chokhani" <[e-mail]>=20
Sent by: [e-mail]
10/22/2008 12:26 PM

To
<[e-mail]>
cc

Subject
RE: draft-turner-caclearanceconstraints-01.txt







Stefan,

One answer to your question will be that this can be sorted out during
the comment period.

But, specific answer to your question is that in all cases logical
intersection of categories is computed.  Specific details beyond that
will depend on how the categories are encoded.

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Wednesday, October 22, 2008 10:40 AM
To: Turner, Sean P.; Santosh Chokhani; 'Timothy J. Miller'; Carl Wallace
Cc: [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

The major problem I have is that there is no set logic for the
constraints processing.

I have been told that there are current implementations of this and that
this fact itself should prove that it is implementable.
It is however my strong guess that current implementations work only
because they assume no difference in calculating intersections of
SecurityCategories for different known PolicyIDs.

The problem comes when someone introduce a PolicyID which defines a
different intersection logic or order of classes.
The only way I can accept that Policy ID is to write new code.

There is a huge difference between allowing inclusion of different
policy OIDs, than to allow then to define individual path processing
logic.

Just imagine if every certificate policy OID was allowed to specify
individual mapping logic (Like policy A is equal to policy B,C and D),
and then expect the path processing code to learn the mapping logic for
each and every Policy OID.

I don't think anyone would consider that a good architecture and
protocol design to standardize.
But as far as I read it, this is precisely what the current CA clearance
constraints proposal wants us to do.




Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Turner, Sean P.
> Sent: den 14 oktober 2008 14:59
> To: 'Santosh Chokhani'; 'Timothy J. Miller'; 'Carl Wallace'
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
>
> I just wanted to add that the ID does not address relationships
between
> security policies.  It only addresses whether the EE's asserted
> clearance is
> within the issuer's allowed clearance set.
>
> spt
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Santosh Chokhani
> Sent: Monday, October 13, 2008 10:33 AM
> To: Timothy J. Miller; Carl Wallace
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Differences in various policies are articulated using the
> security policy OID in the clearance structure that has been
> accepted by the Internet Standards Community.
>
> In addition, clearance is a well defined mathematical concept
> and formalized using lattice structure.  Within a security
> policy, Clearance consists of a hierarchical sensitivity level
> and non-hierarchical category set.  Two clearances within a
> security can be ordered or can be incomparable based on simple
> and well-defines mathematical rules.
>
> People in other parts of IETF are using these concepts to label
> the data and make information flow decisions.
>
> Some pioneering work has been done in the technical community
> (albeit not exposed to the IETF) in the area of comparing
> clearances of two security policies.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Timothy J. Miller
> Sent: Monday, October 13, 2008 10:03 AM
> To: Carl Wallace
> Cc: [e-mail]
> Subject: Re: draft-turner-caclearanceconstraints-01.txt
>
> Carl Wallace wrote:
> > I vote yes to adopting this as a PKIX work item.  Specification
> details
> > can be resolved after the draft is accepted as a working group
draft.
>
> Can we even say for certain that clearance is a consistent
> enough concept within and across jurisdictions to enable a
> single logic for constraint processing?  I'd argue not.
>
> E.g., RFC3281 talks about "the" basic clearance hierarchy, which
> doesn't
>
> even exist.  What's the relationship between NATO CONFIDENTIAL
> and US UNCLASSIFIED CONTROLLED INFORMATION?  How about US UCI
> and US FOR OFFICIAL USE ONLY?  US SECRET/NOFOREIGN?  US TS/SCI
> and TS/SAP?  And that's without even getting into the obscure
> corners of the US alone.
>
> What I'm trying to say is that classification is *not* a strict
> hierarchy.  It's semi-structured.  We have trouble enough
> figuring this stuff out in the real world without having to
> write code for it.  :)
>
> Presuming I have a vote, I vote no.
>
> -- Tim
>





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NDD0pd008017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 06:13:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NDD0Gt008016; Thu, 23 Oct 2008 06:13:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NDCwCc008006 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 23 Oct 2008 06:12:59 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 23 Oct 2008 14:12:57 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 23 Oct 2008 14:12:57 +0100
From: Stefan Santesson <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Thu, 23 Oct 2008 14:12:54 +0100
Subject: Call for agenda items, IETF 73 in Minneapolis
Thread-Topic: Call for agenda items, IETF 73 in Minneapolis
Thread-Index: Ack1EQ+em4J/r1qATzyKBW//YkuVCw==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D32195A6F3796EAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Time to start collecting items for the PKIX meeting agenda in Minneapolis.

As usual I want at least one editor from each active document to let me kno=
w your need for time slot.
Others are free to request time slots and I will try to accommodate as much=
 as I can.

I would appreciate to have all requests by EOD Monday, November 3.

I hope to have a complete agenda posted by November 7


Stefan Santesson
Senior Program Manager
Windows Security, Standards


--_000_9F11911AED01D24BAA1C2355723C3D32195A6F3796EAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>Time to start collecting items for =
the PKIX
meeting agenda in Minneapolis.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>As usual I want at least one editor=
 from
each active document to let me know your need for time slot.<o:p></o:p></sp=
an></p>

<p class=3DMsoNormal><span lang=3DEN-US>Others are free to request time slo=
ts and I
will try to accommodate as much as I can.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I would appreciate to have all requ=
ests by EOD
Monday, November 3.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I hope to have a complete agenda po=
sted by
November 7<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F49=
7D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'fon=
t-size:
12.0pt;font-family:"Times New Roman","serif";color:navy'><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D32195A6F3796EAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NCRp8q004366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 05:27:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NCRpMC004365; Thu, 23 Oct 2008 05:27:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NCRc2d004337 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 23 Oct 2008 05:27:49 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 23 Oct 2008 13:27:37 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.235]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Thu, 23 Oct 2008 13:27:37 +0100
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Thu, 23 Oct 2008 13:27:36 +0100
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: AcktPo1xbBGJg+IZTZOD+0tgp11GwAAAKwnQAC8iOcABlZKT4AAD3NvgACVIDNA=
Message-ID: <[e-mail]>
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: 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,

> One answer to your question will be that this can be sorted out during
> the comment period.

I have thought about that, but I would prefer not.
The reason is that this is a fundamental aspect of the standard and I want =
to see that you can build a reasonable solution to a reasonable problem bef=
ore I would support to standardize it.

>
> But, specific answer to your question is that in all cases logical
> intersection of categories is computed.  Specific details beyond that
> will depend on how the categories are encoded.


I don't understand what you mean here. The current specification makes clea=
r that the intersection logic can change in any way for each Policy ID.
There is no defined "default" logic and no way to tell if a PolicyID alters=
 this logic.
As such I can't write a code that can perform the fundamental intersection =
logic of the protocol.
I would have to build a solution that allows every "user" to invoke custom =
code for every PolicyID.

That to me is a too complex response to this problem, especially since I do=
n't think this problem should be handled in certificates at all.
And that if this would be done in certificates anyway, that we at least sho=
uld skip the constraints logic.

I miss the balance discussion. Writing a new standard comes with a cost. We=
 are potentially confusing the community with another specification. We pot=
entially promote making PKI more complex. We potentially promote Certificat=
es to be the right place to carry clearance information.

Just because something could be useful in some corner cases, does not make =
it the right thing to standardize.



Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Santosh Chokhani
> Sent: den 22 oktober 2008 18:26
> To: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Stefan,
>
> One answer to your question will be that this can be sorted out during
> the comment period.
>
> But, specific answer to your question is that in all cases logical
> intersection of categories is computed.  Specific details beyond that
> will depend on how the categories are encoded.
>





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9N11x5d059530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2008 18:01:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9N11xsQ059529; Wed, 22 Oct 2008 18:01:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9N11l0N059518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 22 Oct 2008 18:01:58 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9N11lI8030103 for <[e-mail]>; Wed, 22 Oct 2008 21:01:47 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9N11lbQ126310 for <[e-mail]>; Wed, 22 Oct 2008 21:01:47 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9N11h87015178 for <[e-mail]>; Wed, 22 Oct 2008 21:01:43 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9N11hQW015171; Wed, 22 Oct 2008 21:01:43 -0400
In-Reply-To: <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Subject: RE: draft-turner-caclearanceconstraints-01.txt
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 22 Oct 2008 21:01:45 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1|February 07, 2008) at 10/22/2008 21:01:46, Serialize complete at 10/22/2008 21:01:46
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Santosh:

        I have to mainly agree with Stefan about this.  I cannot see how 
to implement general purpose code to handle securityCategories without a 
rule governing policyID's whose security policy is unknown to the relying 
party.  My own guess (although without much background in this area) is 
that the desired final condition in such a case is either for all 
securityCategories for such a policyID to be eliminated from 
effective-clearance, or for the Clearance containing such a policyID to be 
eliminated if any SecurityCategory values are encountered in the 
end-entity certificate.
        Such an algorithm could probably be implemented with an "SPI" 
interface, at least in Java.  That's still a lot of work for this purpose, 
and defining default types of SecurityCategory with known intersection 
characteristics might be worthwhile.  The current algorithm, with no 
defined handling for unknown policyID's, can't be implemented robustly.

                Tom Gindin




"Santosh Chokhani" <[e-mail]> 
Sent by: [e-mail]
10/22/2008 12:26 PM

To
<[e-mail]>
cc

Subject
RE: draft-turner-caclearanceconstraints-01.txt







Stefan,

One answer to your question will be that this can be sorted out during
the comment period.

But, specific answer to your question is that in all cases logical
intersection of categories is computed.  Specific details beyond that
will depend on how the categories are encoded.

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Wednesday, October 22, 2008 10:40 AM
To: Turner, Sean P.; Santosh Chokhani; 'Timothy J. Miller'; Carl Wallace
Cc: [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

The major problem I have is that there is no set logic for the
constraints processing.

I have been told that there are current implementations of this and that
this fact itself should prove that it is implementable.
It is however my strong guess that current implementations work only
because they assume no difference in calculating intersections of
SecurityCategories for different known PolicyIDs.

The problem comes when someone introduce a PolicyID which defines a
different intersection logic or order of classes.
The only way I can accept that Policy ID is to write new code.

There is a huge difference between allowing inclusion of different
policy OIDs, than to allow then to define individual path processing
logic.

Just imagine if every certificate policy OID was allowed to specify
individual mapping logic (Like policy A is equal to policy B,C and D),
and then expect the path processing code to learn the mapping logic for
each and every Policy OID.

I don't think anyone would consider that a good architecture and
protocol design to standardize.
But as far as I read it, this is precisely what the current CA clearance
constraints proposal wants us to do.




Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Turner, Sean P.
> Sent: den 14 oktober 2008 14:59
> To: 'Santosh Chokhani'; 'Timothy J. Miller'; 'Carl Wallace'
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
>
> I just wanted to add that the ID does not address relationships
between
> security policies.  It only addresses whether the EE's asserted
> clearance is
> within the issuer's allowed clearance set.
>
> spt
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Santosh Chokhani
> Sent: Monday, October 13, 2008 10:33 AM
> To: Timothy J. Miller; Carl Wallace
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Differences in various policies are articulated using the
> security policy OID in the clearance structure that has been
> accepted by the Internet Standards Community.
>
> In addition, clearance is a well defined mathematical concept
> and formalized using lattice structure.  Within a security
> policy, Clearance consists of a hierarchical sensitivity level
> and non-hierarchical category set.  Two clearances within a
> security can be ordered or can be incomparable based on simple
> and well-defines mathematical rules.
>
> People in other parts of IETF are using these concepts to label
> the data and make information flow decisions.
>
> Some pioneering work has been done in the technical community
> (albeit not exposed to the IETF) in the area of comparing
> clearances of two security policies.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Timothy J. Miller
> Sent: Monday, October 13, 2008 10:03 AM
> To: Carl Wallace
> Cc: [e-mail]
> Subject: Re: draft-turner-caclearanceconstraints-01.txt
>
> Carl Wallace wrote:
> > I vote yes to adopting this as a PKIX work item.  Specification
> details
> > can be resolved after the draft is accepted as a working group
draft.
>
> Can we even say for certain that clearance is a consistent
> enough concept within and across jurisdictions to enable a
> single logic for constraint processing?  I'd argue not.
>
> E.g., RFC3281 talks about "the" basic clearance hierarchy, which
> doesn't
>
> even exist.  What's the relationship between NATO CONFIDENTIAL
> and US UNCLASSIFIED CONTROLLED INFORMATION?  How about US UCI
> and US FOR OFFICIAL USE ONLY?  US SECRET/NOFOREIGN?  US TS/SCI
> and TS/SAP?  And that's without even getting into the obscure
> corners of the US alone.
>
> What I'm trying to say is that classification is *not* a strict
> hierarchy.  It's semi-structured.  We have trouble enough
> figuring this stuff out in the real world without having to
> write code for it.  :)
>
> Presuming I have a vote, I vote no.
>
> -- Tim
>





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9MLYaxT046850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2008 14:34:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9MLYa86046849; Wed, 22 Oct 2008 14:34:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9MLYPb8046826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 22 Oct 2008 14:34:36 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (dslstat-77-ppp-125.fastq.com [65.39.77.125] (may be forged)) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id m9MLZhYr010675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Oct 2008 14:35:44 -0700
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Stefan Santesson <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v912)
Subject: Re: OCSP Delegation Clarification
Date: Wed, 22 Oct 2008 14:34:23 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.912)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

That's pretty much what I intended.

Mike



On Oct 22, 2008, at 8:40 AM, Stefan Santesson wrote (in part):

>
> . . . authority to provide OCSP services for the target certificate  
> is either
> specified in the target certificate itself or a matter of local  
> configuration
> by the relying party.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9MGQSFD013977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2008 09:26:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9MGQSYi013976; Wed, 22 Oct 2008 09:26:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9MGQGoX013946 for <[e-mail]>; Wed, 22 Oct 2008 09:26:27 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 15317 invoked from network); 22 Oct 2008 16:12:39 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;22 Oct 2008 16:12:39 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 22 Oct 2008 16:12:39 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Wed, 22 Oct 2008 12:26:09 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: AcktPo1xbBGJg+IZTZOD+0tgp11GwAAAKwnQAC8iOcABlZKT4AAD3Nvg
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie> <[e-mail]>
From: "Santosh Chokhani" <[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>

Stefan,

One answer to your question will be that this can be sorted out during
the comment period.

But, specific answer to your question is that in all cases logical
intersection of categories is computed.  Specific details beyond that
will depend on how the categories are encoded.

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Wednesday, October 22, 2008 10:40 AM
To: Turner, Sean P.; Santosh Chokhani; 'Timothy J. Miller'; Carl Wallace
Cc: [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

The major problem I have is that there is no set logic for the
constraints processing.

I have been told that there are current implementations of this and that
this fact itself should prove that it is implementable.
It is however my strong guess that current implementations work only
because they assume no difference in calculating intersections of
SecurityCategories for different known PolicyIDs.

The problem comes when someone introduce a PolicyID which defines a
different intersection logic or order of classes.
The only way I can accept that Policy ID is to write new code.

There is a huge difference between allowing inclusion of different
policy OIDs, than to allow then to define individual path processing
logic.

Just imagine if every certificate policy OID was allowed to specify
individual mapping logic (Like policy A is equal to policy B,C and D),
and then expect the path processing code to learn the mapping logic for
each and every Policy OID.

I don't think anyone would consider that a good architecture and
protocol design to standardize.
But as far as I read it, this is precisely what the current CA clearance
constraints proposal wants us to do.




Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Turner, Sean P.
> Sent: den 14 oktober 2008 14:59
> To: 'Santosh Chokhani'; 'Timothy J. Miller'; 'Carl Wallace'
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
>
> I just wanted to add that the ID does not address relationships
between
> security policies.  It only addresses whether the EE's asserted
> clearance is
> within the issuer's allowed clearance set.
>
> spt
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Santosh Chokhani
> Sent: Monday, October 13, 2008 10:33 AM
> To: Timothy J. Miller; Carl Wallace
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Differences in various policies are articulated using the
> security policy OID in the clearance structure that has been
> accepted by the Internet Standards Community.
>
> In addition, clearance is a well defined mathematical concept
> and formalized using lattice structure.  Within a security
> policy, Clearance consists of a hierarchical sensitivity level
> and non-hierarchical category set.  Two clearances within a
> security can be ordered or can be incomparable based on simple
> and well-defines mathematical rules.
>
> People in other parts of IETF are using these concepts to label
> the data and make information flow decisions.
>
> Some pioneering work has been done in the technical community
> (albeit not exposed to the IETF) in the area of comparing
> clearances of two security policies.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Timothy J. Miller
> Sent: Monday, October 13, 2008 10:03 AM
> To: Carl Wallace
> Cc: [e-mail]
> Subject: Re: draft-turner-caclearanceconstraints-01.txt
>
> Carl Wallace wrote:
> > I vote yes to adopting this as a PKIX work item.  Specification
> details
> > can be resolved after the draft is accepted as a working group
draft.
>
> Can we even say for certain that clearance is a consistent
> enough concept within and across jurisdictions to enable a
> single logic for constraint processing?  I'd argue not.
>
> E.g., RFC3281 talks about "the" basic clearance hierarchy, which
> doesn't
>
> even exist.  What's the relationship between NATO CONFIDENTIAL
> and US UNCLASSIFIED CONTROLLED INFORMATION?  How about US UCI
> and US FOR OFFICIAL USE ONLY?  US SECRET/NOFOREIGN?  US TS/SCI
> and TS/SAP?  And that's without even getting into the obscure
> corners of the US alone.
>
> What I'm trying to say is that classification is *not* a strict
> hierarchy.  It's semi-structured.  We have trouble enough
> figuring this stuff out in the real world without having to
> write code for it.  :)
>
> Presuming I have a vote, I vote no.
>
> -- Tim
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9MFeMCc009531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2008 08:40:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9MFeMfK009530; Wed, 22 Oct 2008 08:40:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9MFeKDN009517 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 22 Oct 2008 08:40:21 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 22 Oct 2008 16:40:46 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.73]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Wed, 22 Oct 2008 16:40:17 +0100
From: Stefan Santesson <[e-mail]>
To: Patrick Patterson <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Wed, 22 Oct 2008 16:40:03 +0100
Subject: RE: OCSP Delegation Clarification
Thread-Topic: OCSP Delegation Clarification
Thread-Index: AckzX0QUtpSQY9WXRc2vG8UyUhgRdwA/KM7A
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Responding to the initial question.

> For OCSP, I fail to see how to build the path for determining the
> validity of an OCSP response based on the above.
>

What I think has been stated repeatedly here is that authority to provide O=
CSP services for the target certificate is either specified in the target c=
ertificate itself or a matter of local configuration by the relying party.

The mechanism how to specify this in the target certificate is defined in S=
ection 3.1 of RFC 2560.



Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Patrick Patterson
> Sent: den 21 oktober 2008 10:36
> To: [e-mail]
> Subject: OCSP Delegation Clarification
>
>
> Hello there,
>
> In RFC2560, there is the following text in section 2.6:
>
> The key that signs a certificate's status information need not be the
>    same key that signed the certificate. A certificate's issuer
>    explicitly delegates OCSP signing authority by issuing a certificate
>    containing a unique value for extendedKeyUsage in the OCSP signer's
>    certificate. This certificate MUST be issued directly to the
>    responder by the cognizant CA.
>
> I'm trying to figure out how this is supposed to work. For CRL
> delegation, this is very clear - there exists a CRLIssuers field within
> CRLDP, and if that value is in the end-entity certificate, then the
> designated entity in the CRLIssuers field may issue valid CRL
> information for that end-entity certificate.
>
> For OCSP, I fail to see how to build the path for determining the
> validity of an OCSP response based on the above.
>
> Can someone clarify?
>
> Thanks.
>
> ---
> Patrick Patterson
> PKI Architect,
> Carillon Information Security Inc.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9MEeVVR001546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2008 07:40:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9MEeVQm001545; Wed, 22 Oct 2008 07:40:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9MEeIaR001485 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 22 Oct 2008 07:40:29 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 22 Oct 2008 15:40:44 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.73]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Wed, 22 Oct 2008 15:40:17 +0100
From: Stefan Santesson <[e-mail]>
To: "Turner, Sean P." <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'Timothy J. Miller'" <[e-mail]>, "'Carl Wallace'" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Wed, 22 Oct 2008 15:40:15 +0100
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: AcktPo1xbBGJg+IZTZOD+0tgp11GwAAAKwnQAC8iOcABlZKT4A==
Message-ID: <[e-mail]>
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <D1165D0004A74F2EB89FD9FFC0606D31@Wylie>
In-Reply-To: <D1165D0004A74F2EB89FD9FFC0606D31@Wylie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: 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 major problem I have is that there is no set logic for the constraints =
processing.

I have been told that there are current implementations of this and that th=
is fact itself should prove that it is implementable.
It is however my strong guess that current implementations work only becaus=
e they assume no difference in calculating intersections of SecurityCategor=
ies for different known PolicyIDs.

The problem comes when someone introduce a PolicyID which defines a differe=
nt intersection logic or order of classes.
The only way I can accept that Policy ID is to write new code.

There is a huge difference between allowing inclusion of different policy O=
IDs, than to allow then to define individual path processing logic.

Just imagine if every certificate policy OID was allowed to specify individ=
ual mapping logic (Like policy A is equal to policy B,C and D), and then ex=
pect the path processing code to learn the mapping logic for each and every=
 Policy OID.

I don't think anyone would consider that a good architecture and protocol d=
esign to standardize.
But as far as I read it, this is precisely what the current CA clearance co=
nstraints proposal wants us to do.




Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Turner, Sean P.
> Sent: den 14 oktober 2008 14:59
> To: 'Santosh Chokhani'; 'Timothy J. Miller'; 'Carl Wallace'
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
>
> I just wanted to add that the ID does not address relationships between
> security policies.  It only addresses whether the EE's asserted
> clearance is
> within the issuer's allowed clearance set.
>
> spt
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Santosh Chokhani
> Sent: Monday, October 13, 2008 10:33 AM
> To: Timothy J. Miller; Carl Wallace
> Cc: [e-mail]
> Subject: RE: draft-turner-caclearanceconstraints-01.txt
>
>
> Differences in various policies are articulated using the
> security policy OID in the clearance structure that has been
> accepted by the Internet Standards Community.
>
> In addition, clearance is a well defined mathematical concept
> and formalized using lattice structure.  Within a security
> policy, Clearance consists of a hierarchical sensitivity level
> and non-hierarchical category set.  Two clearances within a
> security can be ordered or can be incomparable based on simple
> and well-defines mathematical rules.
>
> People in other parts of IETF are using these concepts to label
> the data and make information flow decisions.
>
> Some pioneering work has been done in the technical community
> (albeit not exposed to the IETF) in the area of comparing
> clearances of two security policies.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Timothy J. Miller
> Sent: Monday, October 13, 2008 10:03 AM
> To: Carl Wallace
> Cc: [e-mail]
> Subject: Re: draft-turner-caclearanceconstraints-01.txt
>
> Carl Wallace wrote:
> > I vote yes to adopting this as a PKIX work item.  Specification
> details
> > can be resolved after the draft is accepted as a working group draft.
>
> Can we even say for certain that clearance is a consistent
> enough concept within and across jurisdictions to enable a
> single logic for constraint processing?  I'd argue not.
>
> E.g., RFC3281 talks about "the" basic clearance hierarchy, which
> doesn't
>
> even exist.  What's the relationship between NATO CONFIDENTIAL
> and US UNCLASSIFIED CONTROLLED INFORMATION?  How about US UCI
> and US FOR OFFICIAL USE ONLY?  US SECRET/NOFOREIGN?  US TS/SCI
> and TS/SAP?  And that's without even getting into the obscure
> corners of the US alone.
>
> What I'm trying to say is that classification is *not* a strict
> hierarchy.  It's semi-structured.  We have trouble enough
> figuring this stuff out in the real world without having to
> write code for it.  :)
>
> Presuming I have a vote, I vote no.
>
> -- Tim
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LL3uAZ086598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 14:03:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LL3u1Y086597; Tue, 21 Oct 2008 14:03:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LL3hcw086588 for <[e-mail]>; Tue, 21 Oct 2008 14:03:54 -0700 (MST) (envelope-from [e-mail])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA297682943; Tue, 21 Oct 2008 23:02:23 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA27789; Tue, 21 Oct 2008 23:02:22 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: draft-ietf-pkix-other-certs-01
To: [e-mail]
Date: Tue, 21 Oct 2008 23:02:22 +0200 (MESZ)
Cc: [e-mail]
In-Reply-To: <[e-mail]> from Stephen Farrell at Oct "21," 2008 "09:36:41" am
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Farrell responded to my previous comments:

> Hi Alfred,
> 
> Thanks for those. Couple of responses below.
> 
> BTW - if you meant to, (you didn't), cc the pkix list, its
> fine by me to continue this on the list, or not, as you
> prefer.

The details deemed to me being too minor for the list,
but you may be right, at least item (3) emerging after
starting my comments, might have deserved being copied
to the list.  As such I'll cc the pkix list now.   :-)


> Alfred HÎnes wrote:
>> ...
>> 
>> (1)  Nits
>> 
> ...
> Thanks
>> 
>> (2)  Section 3, ASN.1
>> 
>> The name form 'id-pe' comes out of the blue in Section 3.
>> 
>> Perhaps, the two ASN.1 lines should be amended by (I present
>> a 'luxurious' version):
>> 
>>    where [pkix-oids] :
>>    id-pe   OBJECT IDENTIFIER ::= { id-pkix 1 }
>>                                  -- PKIX certificate extensions
>>    id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
>>                dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
> 
> I don't think that's required - that's all in the ASN.1 module and
> anyone that could understand the above would not be puzzled by the
> current text.

I found it there, but I recalled to have appreciated the style
followed in most recent PKIX and SMIME documents, giving the
reader immediately complete information in the prose.

As indicated originally, a more terse version would also be
possible, collapsing the two definitions above into one.

>> ... and a URL ref. added to Section 8 :
>> 
>>    [pkix-oids]  The PKIX Object Identifier Registry, URL:
>>                 <http://www.imc.org/ietf-pkix/pkix-oid.asn>
> 
> I think its ok with just the mention in the ASN.1 module
> appendix.

This nice resource IMHO is not very well-known; thus, the above
comment offered a chance for me to try to push a citation
to it in an IETF document (and ultimately into an RFC).  :-)

Maybe, draft-ietf-pkix-new-asn1 and draft-ietf-smime-new-asn1
may be more appropriate places to put this citation in now.

>> (3) Discuss items
>> 
>> (3a) Section 3, last paragraph  (EE only)
>> 
>> I support the restriction on end-entity certificates,
>> and the rationale given.
> 
> Fair enough. I guess I do too. I'll leave in the comment for
> now though in case someone thinks the opposite.
> 
>> 
>> (3b) Section 7, last 2 paragraphs  (NC issue)
>> 
>> IMO, that conflict should be left to implementation and policy,
>> with a fallback / default of 'strict' behavior;
>> perhaps, a 'callback' to the user upon detection of such
>> NC violations would make sense, offering the opportunity
>> to override 'normal' NC processing; unfortunately, this
>> strategy is not feasable for client certificate verification
>> at a server.
> 
> I'm not sure I'm following you there. (Though I also find
> the issue tricky.) Any suggestion as to text changes though?
> I'm quite open to whatever might work.
> 
> Thanks again,
> Stephen.


Kind regards,
  Alfred HÎnes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LIMHuq075730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 11:22:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LIMHAH075729; Tue, 21 Oct 2008 11:22:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost2.indra.es (mailhost1.indra.es [213.170.46.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9LIMGeB075723 for <[e-mail]>; Tue, 21 Oct 2008 11:22:16 -0700 (MST) (envelope-from [e-mail])
Received: from MADARRMAIL1.indra.es ([192.168.10.182]) by mailhost2.indra.es with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 20:22:09 +0200
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: OCSP Delegation Clarification
Date: Tue, 21 Oct 2008 20:22:07 +0200
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Delegation Clarification
Thread-Index: AckzmDiMTIKv9zCEQWWIT+fboyVwRgAAFTjQAAIsKgAAAF3gUAAA/F/gAAAWH1A=
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: =?iso-8859-1?Q?P=E9rez_Herrero=2C_David_Antonio?= <[e-mail]>
To: "Seth Hitchings" <[e-mail]>, "Johannes Merkle" <[e-mail]>, "Bentkofsky, Michael" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 21 Oct 2008 18:22:09.0032 (UTC) FILETIME=[EDE2C080:01C933A9]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Seth, I agree with you. But in the case of delegation, signing the OCSP =
responder certificate with a CA different from that issued the =
certificate, could be a special issue if we go into archiving long term =
signature world.

If end-entity status information is in ocsp responses form, it would be =
still necessary to store status information for OCSP responder =
certificates (now in CRL form). Considering size issue, it's better to =
store a CRL issued by the CA root (not a ARL in this case) that a CRL =
issued by an end-entity CA (bigger).

David.


-----Mensaje original-----
De: Seth Hitchings [mailto:[e-mail]]=20
Enviado el: martes, 21 de octubre de 2008 19:59
Para: P=E9rez Herrero, David Antonio; Johannes Merkle; Bentkofsky, =
Michael
CC: pkix
Asunto: RE: OCSP Delegation Clarification

Sorry, that should have read "trust each and every OCSP responder =
certificate issued by the root CA".

Seth

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On Behalf Of Seth Hitchings
Sent: Tuesday, October 21, 2008 1:48 PM
To: P=E9rez Herrero, David Antonio; Johannes Merkle; Bentkofsky, Michael
Cc: pkix
Subject: RE: OCSP Delegation Clarification


David,

I would say that anything is a valid case as long as your client =
supports it; the problem is that you'll either have to find a client =
that supports delegated (automatic) trust when the OCSP responder =
certificates are issued by the root CA, or you'll have to manually =
configure your OCSP client to explicitly trust each and every OCSP =
client issued by the root CA, which rapidly becomes difficult to manage.

Seth

-----Original Message-----
From: P=E9rez Herrero, David Antonio [mailto:[e-mail]]=20
Sent: Tuesday, October 21, 2008 1:24 PM
To: Seth Hitchings; Johannes Merkle; Bentkofsky, Michael
Cc: pkix
Subject: RE: OCSP Delegation Clarification

Hello All.

Then I understand that signing OCSP responder certificate by a root CA =
(in a multilevel PKI) IS A VALID CASE, and it belongs to first type =
("matches a local configuration of OCSP signing authority..."). Is that =
true?

David.


-----Mensaje original-----
De: [e-mail] [mailto:[e-mail]] =
En nombre de Seth Hitchings
Enviado el: martes, 21 de octubre de 2008 18:29
Para: Johannes Merkle; Bentkofsky, Michael
CC: pkix
Asunto: RE: OCSP Delegation Clarification


I find the specification to be reasonably clear. There are two types of
trust that are standards-based and that any OCSP client claiming to
implement the standard should be expected to support:

4.2.2.2  Authorized Responders

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

Additionally, the specification leaves open the option for
domain-specific trust configurations, which by definition are beyond the
scope of the standard:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

Most OCSP client implementations allow, at a minimum, the definition of
explicitly trusted responder certificates, such as Tim described for the
DoD use case. In addition, organizations such as IdenTrust have defined
specific delegated trust rules for their communities.

What's important about case (1) is that the specification intentionally
doesn't state what a client must do to verify that the responder is
authorized, so any use of "local configuration" requires out-of-band
knowledge.

Seth



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LI22E2072849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 11:02:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LI22X6072848; Tue, 21 Oct 2008 11:02:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LI21lc072840 for <[e-mail]>; Tue, 21 Oct 2008 11:02:01 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9LI20BK012256 for <[e-mail]>; Tue, 21 Oct 2008 14:02:01 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9LI20bx012252; Tue, 21 Oct 2008 14:02:00 -0400
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 14:02:00 -0400
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 13:01:57 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: David Antonio <[e-mail]>
CC: Seth Hitchings <[e-mail]>, Johannes Merkle <[e-mail]>, "Bentkofsky, Michael" <[e-mail]>, pkix <[e-mail]>
Subject: Re: OCSP Delegation Clarification
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040709020206080506090601"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms040709020206080506090601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

P=E9rez Herrero wrote:

> Then I understand that signing OCSP responder certificate by a root CA =
(in a multilevel PKI) IS A VALID CASE, and it belongs to first type ("mat=
ches a local configuration of OCSP signing authority..."). Is that true?

I would concur.  At one point I had considered adding root-signed OCSP=20
responder certificates as a special case, but then I realized it was=20
already covered.

-- Tim


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjExODAxNTdaMCMGCSqGSIb3DQEJBDEWBBQwhHdBiVFL0QUnQ0ZJBj1pno42IDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgA17RzL8uvImh1zpND5nkxcbIS+Gyw8DZBPqpgJEG2BF8ofJOSxTJ19IaDT5
XXZSIPTodA83C4dCd+9GoTNH1kcsEOakqIkjpmsDsmczFNIPRvGtPibbCoBTtcK5KITaEJYk
4c+ElJKHXk2T0G7SlBnFhQTRbT7XxVKyFpS9bzelAAAAAAAA
--------------ms040709020206080506090601--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LHxHtC072270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 10:59:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LHxHcb072269; Tue, 21 Oct 2008 10:59:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LHxGW1072261 for <[e-mail]>; Tue, 21 Oct 2008 10:59:16 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: OCSP Delegation Clarification
Date: Tue, 21 Oct 2008 13:59:15 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Delegation Clarification
Thread-Index: AckzmDiMTIKv9zCEQWWIT+fboyVwRgAAFTjQAAIsKgAAAF3gUAAA/F/g
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Seth Hitchings" <[e-mail]>
To: =?iso-8859-1?Q?P=E9rez_Herrero=2C_David_Antonio?= <[e-mail]>, "Johannes Merkle" <[e-mail]>, "Bentkofsky, Michael" <[e-mail]>
Cc: "pkix" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry, that should have read "trust each and every OCSP responder =
certificate issued by the root CA".

Seth

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On Behalf Of Seth Hitchings
Sent: Tuesday, October 21, 2008 1:48 PM
To: P=E9rez Herrero, David Antonio; Johannes Merkle; Bentkofsky, Michael
Cc: pkix
Subject: RE: OCSP Delegation Clarification


David,

I would say that anything is a valid case as long as your client =
supports it; the problem is that you'll either have to find a client =
that supports delegated (automatic) trust when the OCSP responder =
certificates are issued by the root CA, or you'll have to manually =
configure your OCSP client to explicitly trust each and every OCSP =
client issued by the root CA, which rapidly becomes difficult to manage.

Seth

-----Original Message-----
From: P=E9rez Herrero, David Antonio [mailto:[e-mail]]=20
Sent: Tuesday, October 21, 2008 1:24 PM
To: Seth Hitchings; Johannes Merkle; Bentkofsky, Michael
Cc: pkix
Subject: RE: OCSP Delegation Clarification

Hello All.

Then I understand that signing OCSP responder certificate by a root CA =
(in a multilevel PKI) IS A VALID CASE, and it belongs to first type =
("matches a local configuration of OCSP signing authority..."). Is that =
true?

David.


-----Mensaje original-----
De: [e-mail] [mailto:[e-mail]] =
En nombre de Seth Hitchings
Enviado el: martes, 21 de octubre de 2008 18:29
Para: Johannes Merkle; Bentkofsky, Michael
CC: pkix
Asunto: RE: OCSP Delegation Clarification


I find the specification to be reasonably clear. There are two types of
trust that are standards-based and that any OCSP client claiming to
implement the standard should be expected to support:

4.2.2.2  Authorized Responders

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

Additionally, the specification leaves open the option for
domain-specific trust configurations, which by definition are beyond the
scope of the standard:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

Most OCSP client implementations allow, at a minimum, the definition of
explicitly trusted responder certificates, such as Tim described for the
DoD use case. In addition, organizations such as IdenTrust have defined
specific delegated trust rules for their communities.

What's important about case (1) is that the specification intentionally
doesn't state what a client must do to verify that the responder is
authorized, so any use of "local configuration" requires out-of-band
knowledge.

Seth



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LHlYNl070731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 10:47:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LHlYnV070730; Tue, 21 Oct 2008 10:47:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LHlXYQ070723 for <[e-mail]>; Tue, 21 Oct 2008 10:47:33 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: OCSP Delegation Clarification
Date: Tue, 21 Oct 2008 13:47:32 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Delegation Clarification
Thread-Index: AckzmDiMTIKv9zCEQWWIT+fboyVwRgAAFTjQAAIsKgAAAF3gUA==
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Seth Hitchings" <[e-mail]>
To: =?iso-8859-1?Q?P=E9rez_Herrero=2C_David_Antonio?= <[e-mail]>, "Johannes Merkle" <[e-mail]>, "Bentkofsky, Michael" <[e-mail]>
Cc: "pkix" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

I would say that anything is a valid case as long as your client =
supports it; the problem is that you'll either have to find a client =
that supports delegated (automatic) trust when the OCSP responder =
certificates are issued by the root CA, or you'll have to manually =
configure your OCSP client to explicitly trust each and every OCSP =
client issued by the root CA, which rapidly becomes difficult to manage.

Seth

-----Original Message-----
From: P=E9rez Herrero, David Antonio [mailto:[e-mail]]=20
Sent: Tuesday, October 21, 2008 1:24 PM
To: Seth Hitchings; Johannes Merkle; Bentkofsky, Michael
Cc: pkix
Subject: RE: OCSP Delegation Clarification

Hello All.

Then I understand that signing OCSP responder certificate by a root CA =
(in a multilevel PKI) IS A VALID CASE, and it belongs to first type =
("matches a local configuration of OCSP signing authority..."). Is that =
true?

David.


-----Mensaje original-----
De: [e-mail] [mailto:[e-mail]] =
En nombre de Seth Hitchings
Enviado el: martes, 21 de octubre de 2008 18:29
Para: Johannes Merkle; Bentkofsky, Michael
CC: pkix
Asunto: RE: OCSP Delegation Clarification


I find the specification to be reasonably clear. There are two types of
trust that are standards-based and that any OCSP client claiming to
implement the standard should be expected to support:

4.2.2.2  Authorized Responders

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

Additionally, the specification leaves open the option for
domain-specific trust configurations, which by definition are beyond the
scope of the standard:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

Most OCSP client implementations allow, at a minimum, the definition of
explicitly trusted responder certificates, such as Tim described for the
DoD use case. In addition, organizations such as IdenTrust have defined
specific delegated trust rules for their communities.

What's important about case (1) is that the specification intentionally
doesn't state what a client must do to verify that the responder is
authorized, so any use of "local configuration" requires out-of-band
knowledge.

Seth



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LHU4rQ067843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 10:30:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LHU4lJ067842; Tue, 21 Oct 2008 10:30:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LHU3fL067836 for <[e-mail]>; Tue, 21 Oct 2008 10:30:03 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9LHU2aQ017100 for <[e-mail]>; Tue, 21 Oct 2008 13:30:03 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9LHU2iJ017089; Tue, 21 Oct 2008 13:30:02 -0400
Received: from [129.83.200.3] (129.83.200.3) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 13:30:02 -0400
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 12:29:59 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Seth Hitchings <[e-mail]>
CC: Johannes Merkle <[e-mail]>, "Bentkofsky, Michael" <[e-mail]>, pkix <[e-mail]>
Subject: Re: OCSP Delegation Clarification
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090003030101080100070508"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms090003030101080100070508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Seth Hitchings wrote:

> Most OCSP client implementations allow, at a minimum, the definition of
> explicitly trusted responder certificates, such as Tim described for the
> DoD use case. In addition, organizations such as IdenTrust have defined
> specific delegated trust rules for their communities.

Actually, my experience is that support for explicit OCSP trust is the 
exception, rather than the norm.

-- Tim


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjExNzI5NTlaMCMGCSqGSIb3DQEJBDEWBBSJUeA6/rc5bVNL+7VwUhNVtlKDbDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgJOw1NseL8QucS9aSIoVUxssd3X1gS/E33sNR2eCU0/SZieB7e1wxjtMbcu2
MUn7LCtRZDj33xO5Qh8KzdsNCL/7bIHbUtAxM8+8rZIKbIU6ZBBYF0DU+ZjW2id48r+YsIPe
CiJ66abyg4A5mc9ans5O9phUKDmy0nAXe4QH6eCxAAAAAAAA
--------------ms090003030101080100070508--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LHNrUP066847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 10:23:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LHNreB066846; Tue, 21 Oct 2008 10:23:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost3.indra.es (mailhost1.indra.es [213.170.46.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9LHNgqp066822 for <[e-mail]>; Tue, 21 Oct 2008 10:23:52 -0700 (MST) (envelope-from [e-mail])
Received: from MADARRMAIL1.indra.es ([192.168.10.182]) by mailhost3.indra.es with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 19:23:40 +0200
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: OCSP Delegation Clarification
Date: Tue, 21 Oct 2008 19:23:40 +0200
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Delegation Clarification
Thread-Index: AckzmDiMTIKv9zCEQWWIT+fboyVwRgAAFTjQAAIsKgA=
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: =?iso-8859-1?Q?P=E9rez_Herrero=2C_David_Antonio?= <[e-mail]>
To: "Seth Hitchings" <[e-mail]>, "Johannes Merkle" <[e-mail]>, "Bentkofsky, Michael" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 21 Oct 2008 17:23:40.0785 (UTC) FILETIME=[C2CEBE10:01C933A1]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello All.

Then I understand that signing OCSP responder certificate by a root CA =
(in a multilevel PKI) IS A VALID CASE, and it belongs to first type =
("matches a local configuration of OCSP signing authority..."). Is that =
true?

David.


-----Mensaje original-----
De: [e-mail] [mailto:[e-mail]] =
En nombre de Seth Hitchings
Enviado el: martes, 21 de octubre de 2008 18:29
Para: Johannes Merkle; Bentkofsky, Michael
CC: pkix
Asunto: RE: OCSP Delegation Clarification


I find the specification to be reasonably clear. There are two types of
trust that are standards-based and that any OCSP client claiming to
implement the standard should be expected to support:

4.2.2.2  Authorized Responders

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

Additionally, the specification leaves open the option for
domain-specific trust configurations, which by definition are beyond the
scope of the standard:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

Most OCSP client implementations allow, at a minimum, the definition of
explicitly trusted responder certificates, such as Tim described for the
DoD use case. In addition, organizations such as IdenTrust have defined
specific delegated trust rules for their communities.

What's important about case (1) is that the specification intentionally
doesn't state what a client must do to verify that the responder is
authorized, so any use of "local configuration" requires out-of-band
knowledge.

Seth



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LH4oYT062956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 10:04:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LH4oPT062955; Tue, 21 Oct 2008 10:04:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LH4nBs062936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 21 Oct 2008 10:04:50 -0700 (MST) (envelope-from [e-mail])
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id m9LH1rYf032441; Tue, 21 Oct 2008 13:01:53 -0400
Received: from DUL1WNEXMB05.vcorp.ad.vrsn.com ([10.170.12.240]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 18:04:48 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: OCSP Delegation Clarification
Date: Tue, 21 Oct 2008 13:04:47 -0400
Message-ID: <[e-mail]>
In-Reply-To: <p0624081dc523a71d5d0e@[10.20.30.152]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Delegation Clarification
Thread-Index: AckzmzmY/Kh1ZyghR9SLVyLpKzuj3AAArJDA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0624081dc523a71d5d0e@[10.20.30.152]>
From: "Bentkofsky, Michael" <[e-mail]>
To: "pkix" <[e-mail]>
Cc: "Paul Hoffman" <[e-mail]>
X-OriginalArrivalTime: 21 Oct 2008 17:04:48.0904 (UTC) FILETIME=[20276880:01C9339F]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,


> At 4:07 PM +0300 10/21/08, Suomela Tero wrote:
> I no longer have a copy of their book, but you have to take a=20
> very limited view of the text in RFC 2560 to come to that conclusion.
>=20
>    The key that signs a certificate's status information need=20
> not be the
>    same key that signed the certificate. A certificate's issuer
>    explicitly delegates OCSP signing authority by issuing a=20
> certificate
>    containing a unique value for extendedKeyUsage in the OCSP signer's
>    certificate. This certificate MUST be issued directly to the
>    responder by the cognizant CA.
>=20
> If you look at only the first sentence, their conclusion=20
> makes sense. If you look at the whole paragraph, it doesn't=20
> make sense at all.

In looking through the text of the RFC, it looks like section 2.6, which
you cite above, is only part of the discussion on this. Section 4.2.2.2
leaves open the optional client behavior for local configuration.

Regards,

Mike



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LGnrur060772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 09:49:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LGnrKI060771; Tue, 21 Oct 2008 09:49:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LGnfsY060742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 21 Oct 2008 09:49:52 -0700 (MST) (envelope-from [e-mail])
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id m9LGkGYS026892; Tue, 21 Oct 2008 12:46:16 -0400
Received: from DUL1WNEXMB05.vcorp.ad.vrsn.com ([10.170.12.240]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 12:49:41 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: OCSP Delegation Clarification
Date: Tue, 21 Oct 2008 12:49:40 -0400
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004A_01C9337B.7B8111A0"
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Delegation Clarification
Thread-Index: Ackzl/fKbiZFXKBHQB+JqbY7c1hfMwAAEpFw
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Bentkofsky, Michael" <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 21 Oct 2008 16:49:41.0231 (UTC) FILETIME=[03237FF0:01C9339D]
Sender: [e-mail]
Precedence: 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_004A_01C9337B.7B8111A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Tim,

> 
> That's in Vista SP1 at DoD behest to support our current OCSP 
> service. 
> That others benefit from it is a bonus.  :)

Unfortunately that behavior is unlikely to be universal across clients. When
something works for 70% of clients, that still leaves 30% miffed that
something isn't working for them.

> Actually, it's a royal pain in the rear, especially with 
> distributed OCSP services and client configuration management 
> added to the mix.

I assume you mean it's a pain to allow OCSP responses to be signed by a
separate CA. I'll agree it's undesirable to be ambiguous in the client
behavior, but I can certainly think of cases where this might be useful to
an issuing CA. I was thinking of cases where a CA is migrating from one
trust chain to another, say to plan for expiration of the roots in the chain
being migrated from. Being able to sign all OCSP responses from the chain
being migrated to, rather than keeping track of which end-entity certs had
been migrated and which had not, could make the OCSP infrastructure actually
simpler.

Best regards,

Mike

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOnzCCAwMw
ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl
cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ
bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl
cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ
bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma
/MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY
8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ
KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV
9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ
W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggOmMIIDD6ADAgECAhB91+6/1s2TH7itq7xF
P3LtMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl
ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05OTAyMjUwMDAw
MDBaFw0xMDAyMjQyMzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMg
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNp
Z24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+i
crdKBi741yksNJ2CvEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+
FVc04Ri8/931r2dZIArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm
5OpaA6g9X/sLAgMBAAGjgbAwga0wEQYJYIZIAYb4QgEBBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQEw
CwYDVR0PBAQDAgEGMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0
cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl
cmlzaWduLmNvbS9wY2EyLWcyLmNybDANBgkqhkiG9w0BAQUFAAOBgQCF82pfhtIQIfWQ/J2W5REa
ZDwYHuvBwZiNeuApiBEYxtivofG9n7ESDvJ133jFabBKmyhUmJm1zZ9UbtzeLbcKpAULCJfisSpU
ogKEvK94w3ug4oUIptQZlAWdik5Ruci15v42FbGws/9vVnAkfCZG1mm5kUlzV5cFUfeo9X0fjjCC
A8AwggMpoAMCAQICECTOLrlL1nhSRPJ8u+NVI40wDQYJKoZIhvcNAQEFBQAwga0xFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL
E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh
LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAy
MjUwMDAwMDBaFw0xMDAyMjMyMzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wIrRh2Gi6jADVWsINvCX+hpUNSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqx
pHKPpbn3LXxg47Xf6X1OISFh1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfA
bKbxYwglsQQXlaCN/n8CAwEAAaOB3zCB3DApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0
ZUxhYmVsMS0xMTgwEQYJYIZIAYb4QgEBBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQD
AgEGMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu
dmVyaXNpZ24uY29tL3JwYTA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9WU0NsYXNzMkludC5jcmwwDQYJKoZIhvcNAQEFBQADgYEAnkqKrb5GGg91KsrXybo8c7ffBfCU
oOcXnjIvQprkzVfcQ3QVzrZG9K558M/PW130GCmqIrwtV41C1VCdxVHL9JuM1/MziNmdYRUiPpqw
PH4myYmiuu/854AgDdhyLq/OLwMCg7+jke3lXCYj+UwsZCmSYbs26cp2IB55DOOGeXIwggQmMIID
j6ADAgECAhAJ0cbKnD2Z/o1rEUR5uYtaMA0GCSqGSIb3DQEBBQUAMIGsMRcwFQYDVQQKEw5WZXJp
U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNl
IGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAo
Yyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw0wODA3MTEwMDAw
MDBaFw0wOTA3MTEyMzU5NTlaMHUxETAPBgNVBAoTCFZFUklTSUdOMRAwDgYDVQQLEwdWQS1FQVNU
MRMwEQYDVQQDEwpSZWNpcGllbnRzMTkwNwYDVQQDEzBNQmVudGtvZnNreSAoQmVudGtvZnNreSBN
aWNoYWVsLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL4au5ly
cGXkaMf/mEr/05ob/XIPYvupVPpeeOwdNvfDtPU9MU24u92CcTlcQGu0EBdbbXUmP/QQ8TIlemXj
jp51wV8E29/5JxcY18RMnH9CPybpTdgc1xJbYYs1Qp9zSxoAiNZSQzSUwQU8GxacuYQQJxbQF0/9
S0xcNc/BMduHAgMBAAGjggF9MIIBeTAJBgNVHRMEAjAAMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6
Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0
ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwIwYDVR0RBBwwGoEYbWJlbnRrb2Zza3lAdmVyaXNpZ24u
Y29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBW
ZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC
MA0GCSqGSIb3DQEBBQUAA4GBAGHEXMHupo8vNfnOHaWGhxOr5nyqpY1HkeAXD5bBMZMtJwED0Dm9
gemD3A06TEIPbXKnFrVZ2n9Z0i3UgF963T7nu3+o/X5a19RWw99axXpxuhP7QVH3dceaA8BVuSAD
T1ihskoaK3Ok3jMlBu8f6VtzbRidjF4aBVIjY0eLLXzxMYID8jCCA+4CAQEwgcEwgawxFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYD
VQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v
cnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhAJ0cbK
nD2Z/o1rEUR5uYtaMAkGBSsOAwIaBQCgggKGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTA4MTAyMTE2NDk0MFowIwYJKoZIhvcNAQkEMRYEFKU22uisMEPt+lrZYMY0
f4yTiJl1MHsGCSqGSIb3DQEJDzFuMGwwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAoGCCqGSIb3
DQMHMAcGBSsOAwIaMAoGCCqGSIb3DQICMAoGCCqGSIb3DQIEMAoGCCqGSIb3DQIFMAsGCSqGSIb3
DQEBBTALBgkqhkiG9w0BAQAwgdIGCSsGAQQBgjcQBDGBxDCBwTCBrDEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBp
cyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMp
OTkxJTAjBgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0ECEAnRxsqcPZn+jWsRRHm5
i1owgdQGCyqGSIb3DQEJEAILMYHEoIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQCdHGypw9mf6NaxFEebmLWjANBgkqhkiG9w0B
AQEFAASBgDrlkSWp5S1OKnlNXwGegZuh3eHydjMkhUqDCOJIGtii0aqe31/BB+JhkU2A3WHaB4J1
DeO9zQ0xglIYmS6HK0Hd1r7SOlPhBN9Y8bpDdDRX15Ehn+7E6aCzDgpUagtfxwewK6MyjyNh64tz
DfyE3YItjcY4V8w0WvLTHu2XTTLCAAAAAAAA

------=_NextPart_000_004A_01C9337B.7B8111A0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LGY87j059767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 09:34:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LGY8G2059766; Tue, 21 Oct 2008 09:34:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LGXu1f059744 for <[e-mail]>; Tue, 21 Oct 2008 09:34:07 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9LGXuMp016859 for <[e-mail]>; Tue, 21 Oct 2008 12:33:56 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9LGXutv016850; Tue, 21 Oct 2008 12:33:56 -0400
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 12:33:55 -0400
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 11:33:52 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Paul Hoffman <[e-mail]>
CC: Suomela Tero <[e-mail]>, pkix <[e-mail]>
Subject: Re: OCSP Delegation Clarification
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0624081dc523a71d5d0e@[10.20.30.152]>
In-Reply-To: <p0624081dc523a71d5d0e@[10.20.30.152]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030605010909050402060309"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms030605010909050402060309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Paul Hoffman wrote:
> At 4:07 PM +0300 10/21/08, Suomela Tero wrote:
>> This is how I also would interpret the RFC. However, I just read about this from the book "Understanding PKI" by Carlisle Adams and Steve Lloyd, and their interpretation was that the responder certificate may be signed by some other CA also as long as the client can trust it (the responder or the other CA).
> 
> I no longer have a copy of their book, but you have to take a very limited view of the text in RFC 2560 to come to that conclusion.
> 
>    The key that signs a certificate's status information need not be the
>    same key that signed the certificate. A certificate's issuer
>    explicitly delegates OCSP signing authority by issuing a certificate
>    containing a unique value for extendedKeyUsage in the OCSP signer's
>    certificate. This certificate MUST be issued directly to the
>    responder by the cognizant CA.
> 
> If you look at only the first sentence, their conclusion makes sense. If you look at the whole paragraph, it doesn't make sense at all.

I'm not sure I understand the extended discussion.  4.2.2.2 seems 
explicit enough to me:  If the queried certificate's CA doesn't sign the 
response id-kp-OCSPSigning must be in the responder cert; also, clients 
are free to explicitly trust any responder certificate they choose with 
no caveats.

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjExNjMzNTJaMCMGCSqGSIb3DQEJBDEWBBTGDVSIboCDNIze4nusdjz05SdQLDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgH+g8G4Q4TrKxIw8UBRs+i0xjEp2W1BnkvSQQGUsYvoy27fSxX9baVWvkZ5s
WRUdZgktk81ZqPoGVNRDvGjduYC9sGwYIbHzYoRRO0O7A+Wmul0btYm4EhErOPkLEThekZyn
pAXfCu8H8zpt0OFHblRiMhEfkimRg+WedAHxGMEXAAAAAAAA
--------------ms030605010909050402060309--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LGT8fQ059440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 09:29:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LGT8EL059439; Tue, 21 Oct 2008 09:29:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LGSuV5059423 for <[e-mail]>; Tue, 21 Oct 2008 09:29:07 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: OCSP Delegation Clarification
Date: Tue, 21 Oct 2008 12:28:55 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Delegation Clarification
Thread-Index: AckzmDiMTIKv9zCEQWWIT+fboyVwRgAAFTjQ
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Seth Hitchings" <[e-mail]>
To: "Johannes Merkle" <[e-mail]>, "Bentkofsky, Michael" <[e-mail]>
Cc: "pkix" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I find the specification to be reasonably clear. There are two types of
trust that are standards-based and that any OCSP client claiming to
implement the standard should be expected to support:

4.2.2.2  Authorized Responders

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

Additionally, the specification leaves open the option for
domain-specific trust configurations, which by definition are beyond the
scope of the standard:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

Most OCSP client implementations allow, at a minimum, the definition of
explicitly trusted responder certificates, such as Tim described for the
DoD use case. In addition, organizations such as IdenTrust have defined
specific delegated trust rules for their communities.

What's important about case (1) is that the specification intentionally
doesn't state what a client must do to verify that the responder is
authorized, so any use of "local configuration" requires out-of-band
knowledge.

Seth



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LGD7jS058282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 09:13:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LGD6bE058280; Tue, 21 Oct 2008 09:13:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LGD4B1058268 for <[e-mail]>; Tue, 21 Oct 2008 09:13:05 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9LGD4dY022756 for <[e-mail]>; Tue, 21 Oct 2008 12:13:04 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9LGD4CU022752; Tue, 21 Oct 2008 12:13:04 -0400
Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 12:13:04 -0400
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 11:13:01 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: "Bentkofsky, Michael" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: OCSP Delegation Clarification
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020405030706090300090708"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms020405030706090300090708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bentkofsky, Michael wrote:

> The ability for the acceptance of the OCSP response if it "matches a
> local configuration of OCSP signing authority for the certificate in
> question" appears to be open to interpretation. The following link
> (search for OCSP) shows that IE 7 SP1 is at least allowing some kind of
> local configuration:
> http://technet.microsoft.com/en-us/library/cc709618.aspx. 

That's in Vista SP1 at DoD behest to support our current OCSP service. 
That others benefit from it is a bonus.  :)

> It also seems that there are some cases where this may be desirable
> behavior from a CA's perspective. By having the OCSP signer be in a
> separate trust chain from the issuing CA, it could make some migrations
> easier when planning for issuer expiration and so forth. 

Actually, it's a royal pain in the rear, especially with distributed 
OCSP services and client configuration management added to the mix.

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjExNjEzMDFaMCMGCSqGSIb3DQEJBDEWBBQe5zvSWZgQGYfkNWkym22ddQjvqjBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgClfNOp6rUd7ZZTEv3q72zMMqFnHkJhrP2Ij5UG3USRbPKxqAJ8GRG7Zn8Qn
vvt5DfHM9xjeGy+KB1bHiNyp3bxUWi3UloGnXSVQ83AUiUpJoAAHxlAm/zOreUDxaVa5HYEh
rCU1rh0ASOLshlwU7ZxyqUaixmN/8Vr10qW7K+LgAAAAAAAA
--------------ms020405030706090300090708--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LG4d20057390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 09:04:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LG4dRn057389; Tue, 21 Oct 2008 09:04:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from a.mx.secunet.com (a.mx.secunet.com [213.68.205.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LG4Sm8057355 for <[e-mail]>; Tue, 21 Oct 2008 09:04:39 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (alg3 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id A84B620C09C; Tue, 21 Oct 2008 18:04:26 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 7586A20C082; Tue, 21 Oct 2008 18:04:26 +0200 (CEST)
Received: from [10.208.1.240] ([10.208.1.240]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 18:04:25 +0200
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 18:04:18 +0200
From: Johannes Merkle <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: "Bentkofsky, Michael" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: OCSP Delegation Clarification
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Oct 2008 16:04:25.0678 (UTC) FILETIME=[B08AFEE0:01C93396]
Sender: [e-mail]
Precedence: 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 ability for the acceptance of the OCSP response if it "matches a
> local configuration of OCSP signing authority for the certificate in
> question" appears to be open to interpretation. The following link
> (search for OCSP) shows that IE 7 SP1 is at least allowing some kind of
> local configuration:
> http://technet.microsoft.com/en-us/library/cc709618.aspx. 
> 
> But it also seems that local configuration could be simply interpreted
> to mean the client trusts multiple CA's. If CA1 issues a certificate and
> CA2 issues an OCSP response for the certificate, and the client trusts
> both CA's, it might be a completely valid interpretation that the OCSP
> response should be accepted despite no trust relationship between CA1
> and CA2. Both CA's are "locally configured" to be trusted.

This shows that the local configuration of trusted OCSP responder certificates without assignment to certain CAs is 
error-prone.

A mechanism similar to the CRLIssuers for CRLs would be desirable.

Johannes



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LFdUkL053223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 08:39:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LFdUr3053222; Tue, 21 Oct 2008 08:39:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LFbwoO052902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 08:38:00 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624081dc523a71d5d0e@[10.20.30.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 21 Oct 2008 08:37:57 -0700
To: Suomela Tero <[e-mail]>, pkix <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: RE: OCSP Delegation Clarification
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:07 PM +0300 10/21/08, Suomela Tero wrote:
>This is how I also would interpret the RFC. However, I just read about this from the book "Understanding PKI" by Carlisle Adams and Steve Lloyd, and their interpretation was that the responder certificate may be signed by some other CA also as long as the client can trust it (the responder or the other CA).

I no longer have a copy of their book, but you have to take a very limited view of the text in RFC 2560 to come to that conclusion.

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. A certificate's issuer
   explicitly delegates OCSP signing authority by issuing a certificate
   containing a unique value for extendedKeyUsage in the OCSP signer's
   certificate. This certificate MUST be issued directly to the
   responder by the cognizant CA.

If you look at only the first sentence, their conclusion makes sense. If you look at the whole paragraph, it doesn't make sense at all.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LF77o3045857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 08:07:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LF775s045851; Tue, 21 Oct 2008 08:07:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LF6toc045783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 21 Oct 2008 08:07:06 -0700 (MST) (envelope-from [e-mail])
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id m9LF3xtV027325 for <[e-mail]>; Tue, 21 Oct 2008 11:03:59 -0400
Received: from DUL1WNEXMB05.vcorp.ad.vrsn.com ([10.170.12.240]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 11:06:54 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: OCSP Delegation Clarification
Date: Tue, 21 Oct 2008 11:06:54 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP Delegation Clarification
Thread-Index: AckzfK/buPKrfYBwRzeEqfgUKdvBkAAACp6QAAPOkDA=
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Bentkofsky, Michael" <[e-mail]>
To: "pkix" <[e-mail]>
X-OriginalArrivalTime: 21 Oct 2008 15:06:54.0945 (UTC) FILETIME=[A7BEED10:01C9338E]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>=20
> > > It means that the CA key that signs the certificates=20
> covered by the=20
> > > responder either signs the OCSP response directly or it issues a=20
> > > special OCSP responder certificate whose key is used to
> > sign responses.
> > >
> > > I.e.
> > >
> > > CA->OCSP response
> > > CA->OCSP responder certificate->OCSP response
>=20
> This is how I also would interpret the RFC. However, I just=20
> read about this from the book "Understanding PKI" by Carlisle=20
> Adams and Steve Lloyd, and their interpretation was that the=20
> responder certificate may be signed by some other CA also as=20
> long as the client can trust it (the responder or the other CA).
>=20

The ability for the acceptance of the OCSP response if it "matches a
local configuration of OCSP signing authority for the certificate in
question" appears to be open to interpretation. The following link
(search for OCSP) shows that IE 7 SP1 is at least allowing some kind of
local configuration:
http://technet.microsoft.com/en-us/library/cc709618.aspx.=20

But it also seems that local configuration could be simply interpreted
to mean the client trusts multiple CA's. If CA1 issues a certificate and
CA2 issues an OCSP response for the certificate, and the client trusts
both CA's, it might be a completely valid interpretation that the OCSP
response should be accepted despite no trust relationship between CA1
and CA2. Both CA's are "locally configured" to be trusted.

It also seems that there are some cases where this may be desirable
behavior from a CA's perspective. By having the OCSP signer be in a
separate trust chain from the issuing CA, it could make some migrations
easier when planning for issuer expiration and so forth.=20

Regards.
=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LDKlGY029134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 06:20:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LDKllu029133; Tue, 21 Oct 2008 06:20:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LDKaiR029107 for <[e-mail]>; Tue, 21 Oct 2008 06:20:46 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9LDKZgi013416 for <[e-mail]>; Tue, 21 Oct 2008 09:20:35 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9LDKZ8S013410; Tue, 21 Oct 2008 09:20:35 -0400
Received: from [129.83.200.4] (129.83.200.4) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 09:20:34 -0400
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 08:20:25 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Patrick Patterson <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: OCSP Delegation Clarification
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060000020102060904020903"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms060000020102060904020903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Patrick Patterson wrote:

> scenario - I guess I was thinking of how the above would be applied to
> the scenario where the CA delegates the OCSP response to some other CA,
> and I failed to see how this was possible. The answer, of course, is
> that it doesn't.

"""
4.2.2.2  Authorized Responders

    The key that signs a certificate's status information need not be the
    same key that signed the certificate. It is necessary however to
    ensure that the entity signing this information is authorized to do
    so.  Therefore, a certificate's issuer MUST either sign the OCSP
    responses itself or it MUST explicitly designate this authority to
    another entity.  OCSP signing delegation SHALL be designated by the
    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
    extension included in the OCSP response signer's certificate.  This
    certificate MUST be issued directly by the CA that issued the
    certificate in question.

    id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

    Systems or applications that rely on OCSP responses MUST be capable
    of detecting and enforcing use of the id-ad-ocspSigning value as
    described above. They MAY provide a means of locally configuring one
    or more OCSP signing authorities, and specifying the set of CAs for
    which each signing authority is trusted. They MUST reject the
    response if the certificate required to validate the signature on the
    response fails to meet at least one of the following criteria:

    1. Matches a local configuration of OCSP signing authority for the
    certificate in question; or

    2. Is the certificate of the CA that issued the certificate in
    question; or

    3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
    extension and is issued by the CA that issued the certificate in
    question."

    Additional acceptance or rejection criteria may apply to either the
    response itself or to the certificate used to validate the signature
    on the response.
"""

In short per (1), you can specify at the client side direct trust for a 
response signer certificate.  The DoD OCSP infrastructure does this 
currentlym using a self-signed responder cert, and this mode is 
supported in at least two major OCSP client vendors I know of (plus 
OpenSSL and Firefox/Thunderbird).

-- Tim


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMjExMzIwMjVaMCMGCSqGSIb3DQEJBDEWBBQdHM74wUkl88pwdFa0VAitNqF7ITBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgGtFORee4CNwQ4kVqDbPvQsEqEMiL9o9LPu0JupEtjVlj73u0Rtqkk3K+rtz
qVXvcmBmooUqShAex6LaJmm67S7xeENxbCpseQybISX2bulcxCrwsE/k1LsVMnkEvoaKRJAo
mkyXSEotSfrQBi2Jpy7HicZaAns7ArCYQDlskeW8AAAAAAAA
--------------ms060000020102060904020903--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LD7kUR026375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 06:07:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LD7kn1026374; Tue, 21 Oct 2008 06:07:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.insta.fi (mail.insta.fi [212.246.151.130]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LD7X8D026324 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Tue, 21 Oct 2008 06:07:45 -0700 (MST) (envelope-from [e-mail])
Received: from mail.insta.fi ([10.64.0.66]) by mail.insta.fi ([10.64.0.66]) with mapi; Tue, 21 Oct 2008 16:07:26 +0300
From: Suomela Tero <[e-mail]>
To: pkix <[e-mail]>
Date: Tue, 21 Oct 2008 16:07:24 +0300
Subject: RE: OCSP Delegation Clarification
Thread-Topic: OCSP Delegation Clarification
Thread-Index: AckzfK/buPKrfYBwRzeEqfgUKdvBkAAACp6Q
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: 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,

> > It means that the CA key that signs the certificates covered by the
> > responder either signs the OCSP response directly or it issues a
> > special OCSP responder certificate whose key is used to
> sign responses.
> >
> > I.e.
> >
> > CA->OCSP response
> > CA->OCSP responder certificate->OCSP response

This is how I also would interpret the RFC. However, I just read about this=
 from the book "Understanding PKI" by Carlisle Adams and Steve Lloyd, and t=
heir interpretation was that the responder certificate may be signed by som=
e other CA also as long as the client can trust it (the responder or the ot=
her CA).

Regards,
Tero



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LCtV5j025124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 05:55:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LCtVB3025123; Tue, 21 Oct 2008 05:55:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.nerim.net (smtp-100-sunday.noc.nerim.net [62.4.17.100]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LCtKg5025098 for <[e-mail]>; Tue, 21 Oct 2008 05:55:30 -0700 (MST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by mallaury.nerim.net (Postfix) with ESMTP id DEBFA4FF20 for <[e-mail]>; Tue, 21 Oct 2008 14:55:04 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id CB7C8440E5 for <[e-mail]>; Tue, 21 Oct 2008 14:55:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at cryptolog.com
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTFOPTVxXAFP for <[e-mail]>; Tue, 21 Oct 2008 14:55:06 +0200 (CEST)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 4FFC24400C for <[e-mail]>; Tue, 21 Oct 2008 14:55:06 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 14:55:06 +0200
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP Delegation Clarification
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 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>

Patrick Patterson wrote:
> Hi Steve:
> 
> Dr Stephen Henson wrote:
>> Patrick Patterson wrote:
>>> Hello there,
>>>
>>> In RFC2560, there is the following text in section 2.6:
>>>
>>> The key that signs a certificate's status information need not be the
>>>    same key that signed the certificate. A certificate's issuer
>>>    explicitly delegates OCSP signing authority by issuing a certificate
>>>    containing a unique value for extendedKeyUsage in the OCSP signer's
>>>    certificate. This certificate MUST be issued directly to the
>>>    responder by the cognizant CA.
>>>
>>> I'm trying to figure out how this is supposed to work. For CRL
>>> delegation, this is very clear - there exists a CRLIssuers field within
>>> CRLDP, and if that value is in the end-entity certificate, then the
>>> designated entity in the CRLIssuers field may issue valid CRL
>>> information for that end-entity certificate.
>>>
>>> For OCSP, I fail to see how to build the path for determining the
>>> validity of an OCSP response based on the above.
>>>
>>> Can someone clarify?
>>>
>> It means that the CA key that signs the certificates covered by the
>> responder either signs the OCSP response directly or it issues a special
>> OCSP responder certificate whose key is used to sign responses.
>>
>> I.e.
>>
>> CA->OCSP response
>> CA->OCSP responder certificate->OCSP response
>>
>> To prevent an end entity certificate masquerading as a responder the
>> responder certificate must include the id-kp-OCSPSigning
>> extendedKeyUsage OID.
>>
> Ok - serves me right for complicating things - I am aware of the
> 
> CA->OCSP responder certificate->OCSP response
> 
> scenario - I guess I was thinking of how the above would be applied to
> the scenario where the CA delegates the OCSP response to some other CA,
> and I failed to see how this was possible. The answer, of course, is
> that it doesn't.

Well, check the RFC section 4.2.2.2 :
you can also verify that the certificate:

    1. Matches a local configuration of OCSP signing authority for the
    certificate in question; or

in other words: "whatever you feel like".
So you have the option to verify the certificate when delegated to some 
other CA, of even to verify that the number of certificates in the chain 
is an even number ;)

However, the most sensible interpretation (in my humble opinion) is a 
"direct trust" in an OCSP responder certificate...

--
Julien



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LCl79C024211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 05:47:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LCl67R024210; Tue, 21 Oct 2008 05:47:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brendan.brad.office.comodo.net (brad.comodogroup.com [82.109.38.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LCkrxj024183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 21 Oct 2008 05:47:05 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 1883 invoked by uid 1000); 21 Oct 2008 12:46:50 -0000
Received: from nigel.brad.office.comodo.net (HELO nigel.brad.office.comodo.net) (192.168.0.58) (smtp-auth username rob, mechanism login) by brendan.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Tue, 21 Oct 2008 13:46:50 +0100
From: Rob Stradling <[e-mail]>
Organization: COMODO CA Limited
To: [e-mail]
Subject: Re: OCSP Delegation Clarification
Date: Tue, 21 Oct 2008 13:46:48 +0100
User-Agent: KMail/1.9.9
Cc: "Liaquat Khan" <[e-mail]>, "'Patrick Patterson'" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

"and that the OCSP responder cert contains an EKU marked for OCSP signing"

Yes, that's correct...when OCSP signing delegation is used.

However, when non-delegated OCSP response signing is used, the "OCSP Signing" 
EKU will most likely *not* be present in the certificate that signs the OCSP 
Responses (because that signing certificate will be the CA Certificate that 
issued the certificate for which status information is being requested).
And it is perfectly valid for it to not be present.

This may seem like an obvious point, but at least 1 major OCSP client 
application was broken in this regard for a number of years!  It *only* 
supported OCSP signing delegation!

On Tuesday 21 October 2008 13:13:48 Liaquat Khan wrote:
> In our OCSP client applications we check that the issuer of the OCSP
> responder cert and the issuer of the target certificate is the same; and
> that the OCSP responder cert contains an EKU marked for OCSP signing.
>
> There are some PKI environments where an OCSP responder provides a service
> on behalf of one CA but is actually certified by a different CA (e.g. a
> Root CA within that environment), so you cannot always enforce this check.
>
> Hope this answers your question.
>
> Regards,
> LK
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Patrick Patterson
> Sent: 21 October 2008 12:36
> To: [e-mail]
> Subject: OCSP Delegation Clarification
>
>
> Hello there,
>
> In RFC2560, there is the following text in section 2.6:
>
> The key that signs a certificate's status information need not be the
>    same key that signed the certificate. A certificate's issuer
>    explicitly delegates OCSP signing authority by issuing a certificate
>    containing a unique value for extendedKeyUsage in the OCSP signer's
>    certificate. This certificate MUST be issued directly to the
>    responder by the cognizant CA.
>
> I'm trying to figure out how this is supposed to work. For CRL
> delegation, this is very clear - there exists a CRLIssuers field within
> CRLDP, and if that value is in the end-entity certificate, then the
> designated entity in the CRLIssuers field may issue valid CRL
> information for that end-entity certificate.
>
> For OCSP, I fail to see how to build the path for determining the
> validity of an OCSP response based on the above.
>
> Can someone clarify?
>
> Thanks.
>
> ---
> Patrick Patterson
> PKI Architect,
> Carillon Information Security Inc.



-- 
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: [phone]
Fax Europe: +44.(0)1274.730909
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LCUGhY022316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 05:30:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LCUG9l022315; Tue, 21 Oct 2008 05:30:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LCU5rY022296 for <[e-mail]>; Tue, 21 Oct 2008 05:30:16 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id AEA5E32804A for <[e-mail]>; Tue, 21 Oct 2008 08:30:04 -0400 (EDT)
Received: from mail.carillon.ca ([127.0.0.1]) by localhost (rhea.carillon.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEz-Kh4pix7X for <[e-mail]>; Tue, 21 Oct 2008 08:30:04 -0400 (EDT)
Received: from [172.28.10.27] (unknown [81.183.250.34]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTP id E743432803F for <[e-mail]>; Tue, 21 Oct 2008 08:30:03 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 08:30:02 -0400
From: Patrick Patterson <[e-mail]>
Organization: Carillon Information Security Inc.
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: OCSP Delegation Clarification
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Steve:

Dr Stephen Henson wrote:
> Patrick Patterson wrote:
>> Hello there,
>>
>> In RFC2560, there is the following text in section 2.6:
>>
>> The key that signs a certificate's status information need not be the
>>    same key that signed the certificate. A certificate's issuer
>>    explicitly delegates OCSP signing authority by issuing a certificate
>>    containing a unique value for extendedKeyUsage in the OCSP signer's
>>    certificate. This certificate MUST be issued directly to the
>>    responder by the cognizant CA.
>>
>> I'm trying to figure out how this is supposed to work. For CRL
>> delegation, this is very clear - there exists a CRLIssuers field within
>> CRLDP, and if that value is in the end-entity certificate, then the
>> designated entity in the CRLIssuers field may issue valid CRL
>> information for that end-entity certificate.
>>
>> For OCSP, I fail to see how to build the path for determining the
>> validity of an OCSP response based on the above.
>>
>> Can someone clarify?
>>
> 
> It means that the CA key that signs the certificates covered by the
> responder either signs the OCSP response directly or it issues a special
> OCSP responder certificate whose key is used to sign responses.
> 
> I.e.
> 
> CA->OCSP response
> CA->OCSP responder certificate->OCSP response
> 
> To prevent an end entity certificate masquerading as a responder the
> responder certificate must include the id-kp-OCSPSigning
> extendedKeyUsage OID.
> 
Ok - serves me right for complicating things - I am aware of the

CA->OCSP responder certificate->OCSP response

scenario - I guess I was thinking of how the above would be applied to
the scenario where the CA delegates the OCSP response to some other CA,
and I failed to see how this was possible. The answer, of course, is
that it doesn't.

Thanks.

Patrick.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LCIHJI021551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 05:18:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LCIHe9021550; Tue, 21 Oct 2008 05:18:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay10.mail.uk.clara.net (relay10.mail.uk.clara.net [80.168.70.190]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LCI6eH021465 for <[e-mail]>; Tue, 21 Oct 2008 05:18:16 -0700 (MST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49536 helo=[192.168.7.8]) by relay10.mail.uk.clara.net with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1KsGBW-0000CP-QX; Tue, 21 Oct 2008 13:18:03 +0100
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 13:18:04 +0100
From: Dr Stephen Henson <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: pkix <[e-mail]>
CC: Patrick Patterson <[e-mail]>
Subject: Re: OCSP Delegation Clarification
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Patrick Patterson wrote:
> Hello there,
> 
> In RFC2560, there is the following text in section 2.6:
> 
> The key that signs a certificate's status information need not be the
>    same key that signed the certificate. A certificate's issuer
>    explicitly delegates OCSP signing authority by issuing a certificate
>    containing a unique value for extendedKeyUsage in the OCSP signer's
>    certificate. This certificate MUST be issued directly to the
>    responder by the cognizant CA.
> 
> I'm trying to figure out how this is supposed to work. For CRL
> delegation, this is very clear - there exists a CRLIssuers field within
> CRLDP, and if that value is in the end-entity certificate, then the
> designated entity in the CRLIssuers field may issue valid CRL
> information for that end-entity certificate.
> 
> For OCSP, I fail to see how to build the path for determining the
> validity of an OCSP response based on the above.
> 
> Can someone clarify?
> 

It means that the CA key that signs the certificates covered by the
responder either signs the OCSP response directly or it issues a special
OCSP responder certificate whose key is used to sign responses.

I.e.

CA->OCSP response
CA->OCSP responder certificate->OCSP response

To prevent an end entity certificate masquerading as a responder the
responder certificate must include the id-kp-OCSPSigning
extendedKeyUsage OID.

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 balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LCEH7a021173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 05:14:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LCEHgx021172; Tue, 21 Oct 2008 05:14:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ascertia.com (server5852.dedicated.webfusion.co.uk [81.21.74.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LCE56H021159 for <[e-mail]>; Tue, 21 Oct 2008 05:14:16 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from ASCUK001 ([87.201.190.150]) by ds5852.dedicated.turbodns.co.uk with MailEnable ESMTP; Tue, 21 Oct 2008 13:14:10 +0100
From: "Liaquat Khan" <[e-mail]>
To: "'Patrick Patterson'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP Delegation Clarification
Date: Tue, 21 Oct 2008 16:13:48 +0400
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.2900.5579
In-Reply-To: <[e-mail]>
Thread-Index: AckzZ92lHBr/CTOZRiy1w+JfQrRPEQADfNuw
X-ME-Bayesian: 0.000000
Sender: [e-mail]
Precedence: 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 our OCSP client applications we check that the issuer of the OCSP
responder cert and the issuer of the target certificate is the same; and
that the OCSP responder cert contains an EKU marked for OCSP signing.  

There are some PKI environments where an OCSP responder provides a service
on behalf of one CA but is actually certified by a different CA (e.g. a Root
CA within that environment), so you cannot always enforce this check. 

Hope this answers your question.

Regards,
LK 
  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Patrick Patterson
Sent: 21 October 2008 12:36
To: [e-mail]
Subject: OCSP Delegation Clarification


Hello there,

In RFC2560, there is the following text in section 2.6:

The key that signs a certificate's status information need not be the
   same key that signed the certificate. A certificate's issuer
   explicitly delegates OCSP signing authority by issuing a certificate
   containing a unique value for extendedKeyUsage in the OCSP signer's
   certificate. This certificate MUST be issued directly to the
   responder by the cognizant CA.

I'm trying to figure out how this is supposed to work. For CRL
delegation, this is very clear - there exists a CRLIssuers field within
CRLDP, and if that value is in the end-entity certificate, then the
designated entity in the CRLIssuers field may issue valid CRL
information for that end-entity certificate.

For OCSP, I fail to see how to build the path for determining the
validity of an OCSP response based on the above.

Can someone clarify?

Thanks.

---
Patrick Patterson
PKI Architect,
Carillon Information Security Inc.







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9L8a9ti002833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 01:36:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9L8a9ML002832; Tue, 21 Oct 2008 01:36:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9L8Zw0Q002814 for <[e-mail]>; Tue, 21 Oct 2008 01:36:08 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id 84A9632804A for <[e-mail]>; Tue, 21 Oct 2008 04:35:54 -0400 (EDT)
Received: from mail.carillon.ca ([127.0.0.1]) by localhost (rhea.carillon.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6jz7MUPzW5X for <[e-mail]>; Tue, 21 Oct 2008 04:35:54 -0400 (EDT)
Received: from [192.168.1.115] (dsl540263D1.pool.t-online.hu [84.2.99.209]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTP id B7EE9328002 for <[e-mail]>; Tue, 21 Oct 2008 04:35:53 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 04:35:51 -0400
From: Patrick Patterson <[e-mail]>
Organization: Carillon Information Security Inc.
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: [e-mail]
Subject: OCSP Delegation Clarification
Content-Type: text/plain; charset=ISO-8859-1
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>

Hello there,

In RFC2560, there is the following text in section 2.6:

The key that signs a certificate's status information need not be the
   same key that signed the certificate. A certificate's issuer
   explicitly delegates OCSP signing authority by issuing a certificate
   containing a unique value for extendedKeyUsage in the OCSP signer's
   certificate. This certificate MUST be issued directly to the
   responder by the cognizant CA.

I'm trying to figure out how this is supposed to work. For CRL
delegation, this is very clear - there exists a CRLIssuers field within
CRLDP, and if that value is in the end-entity certificate, then the
designated entity in the CRLIssuers field may issue valid CRL
information for that end-entity certificate.

For OCSP, I fail to see how to build the path for determining the
validity of an OCSP response based on the above.

Can someone clarify?

Thanks.

---
Patrick Patterson
PKI Architect,
Carillon Information Security Inc.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9JAHxKH006072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Oct 2008 03:17:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9JAHxvm006071; Sun, 19 Oct 2008 03:17:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9JAHkht006018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 19 Oct 2008 03:17:58 -0700 (MST) (envelope-from [e-mail])
Received: from ERA1 ([94.191.243.107]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id ZUK20643 for <[e-mail]>; Sun, 19 Oct 2008 12:17:43 +0200
From: "Erik Andersen" <[e-mail]>
To: "PKIX" <[e-mail]>
Subject: Edition 6 of X.500, including X.509
Date: Sun, 19 Oct 2008 12:17:54 +0200
Message-ID: <C11EC9C66E7944C6BD6CA88092BC0409@ERA1>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C931E4.B8F1F920"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
Thread-Index: Ackx0/LWxQ8QekAuTIepyZFhHFNXwg==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

This is just to make you aware that the sixth edition of X.509 is competed
from the editor's hand. X.509 now includes federated PMI and several
corrections as documented in two corrigenda to the fifth edition.

 

You may find links to the X.500 documents on
http://www.x500standard.com/index.php?n=Extension.Ed6.

 

Regards,

 

Erik Andersen

Andersen's L-Service

Elsevej 48, DK-3500 Vaerloese

Denmark

Mobile: [phone]

email: [e-mail]

www.x500.eu

www.x500standard.com

 


------=_NextPart_000_0004_01C931E4.B8F1F920
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h3
	{margin-top:9.05pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:0cm;
	text-align:justify;
	page-break-after:avoid;
	font-size:10.0pt;
	font-family:Times;}
p.MsoToc4, li.MsoToc4, div.MsoToc4
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:87.9pt;
	margin-bottom:.0001pt;
	text-align:justify;
	text-indent:-45.35pt;
	font-size:10.0pt;
	font-family:"Times New Roman";}
p.MsoToc5, li.MsoToc5, div.MsoToc5
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:48.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.ASN1, li.ASN1, div.ASN1
	{margin-top:6.8pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:0cm;
	margin-bottom:.0001pt;
	punctuation-wrap:simple;
	text-autospace:none;
	font-size:9.0pt;
	font-family:Helvetica;
	font-weight:bold;}
span.EmailStyle20
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>This is just to make you aware that the sixth =
edition
of X.509 is competed from the editor&#8217;s hand. X.509 now includes =
federated
PMI and several corrections as documented in two corrigenda to the fifth
edition.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>You may find links to the X.500 documents on =
<a
href=3D"http://www.x500standard.com/index.php?n=3DExtension.Ed6">http://w=
ww.x500standard.com/index.php?n=3DExtension.Ed6</a>.</span></font></p>

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

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

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

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

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Andersen's L-Service</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Elsevej 48, DK-3500 Vaerloese</span></font></p>

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

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
  10.0pt;font-family:Arial'>Mobile</span></font><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>: +45 2097 =
1490</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>email: </span></font><font size=3D2 =
face=3DArial><span
 lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>[e-mail]</span></font></p=
>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>www.x500.eu</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>www.x500standard.com</span></font></p>

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

</div>

</body>

</html>

------=_NextPart_000_0004_01C931E4.B8F1F920--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9IHO89b055511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Oct 2008 10:24:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9IHO87t055510; Sat, 18 Oct 2008 10:24:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9IHNu0V055493 for <[e-mail]>; Sat, 18 Oct 2008 10:24:07 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 19130 invoked from network); 18 Oct 2008 17:23:56 -0000
Received: from unknown (HELO Wylie) (turners@96.241.102.168 with login) by smtp109.biz.mail.re2.yahoo.com with SMTP; 18 Oct 2008 17:23:55 -0000
X-YMail-OSG: wqF1KQ8VM1mqzf_4gQADUWiPFCz8OG_GfgEQgSk0e8tmMRA8TrmMhba28p64fPt66IGXpEn_UmydnQjzzPOhGZrrmAbUppGt6kcTptRGIZobgoXyb5H_XkigPg0icYT9lyeWqu2590H5tlWD2Zl0INtJ8w--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-3281update-00.txt 
Date: Sat, 18 Oct 2008 13:23:51 -0400
Organization: IECA, Inc.
Message-ID: <59242D34106A4120A23677C1EA5772FD@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AckwpgMCbLbRkil5S96DMhi9cILZjwAoAWQA
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

For those that don't mind using the HTML version, you can use the following
link (IE also won't tell you it's a zip):
http://tools.ietf.org/html/draft-ietf-pkix-3281update 

spt

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of 
>[e-mail]
>Sent: Friday, October 17, 2008 6:15 PM
>To: [e-mail]
>Cc: [e-mail]
>Subject: I-D ACTION:draft-ietf-pkix-3281update-00.txt 
>
>A New Internet-Draft is available from the on-line 
>Internet-Drafts directories.
>This draft is a work item of the Public-Key Infrastructure 
>(X.509) Working Group of the IETF.
>
>	Title		: An Internet Attribute Certificate 
>Profile for Authorization: Update 
>	Author(s)	: R. Housley, S. Farrell, S. Turner
>	Filename	: draft-ietf-pkix-3281update-00.txt
>	Pages		: 12
>	Date		: 2008-10-8
>	
> This document updates RFC 3281.  It incorporates verified errata. 
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-3281update-00.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>Below is the data which will enable a MIME compliant mail 
>reader implementation to automatically retrieve the ASCII 
>version of the Internet-Draft.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9HMG89r092963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2008 15:16:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9HMG87p092962; Fri, 17 Oct 2008 15:16:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9HMG8p8092956 for <[e-mail]>; Fri, 17 Oct 2008 15:16:08 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 82B6C3A6B15; Fri, 17 Oct 2008 15:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-3281update-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri, 17 Oct 2008 15:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: 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		: An Internet Attribute Certificate Profile for Authorization: Update 
	Author(s)	: R. Housley, S. Farrell, S. Turner
	Filename	: draft-ietf-pkix-3281update-00.txt
	Pages		: 12
	Date		: 2008-10-8
	
 This document updates RFC 3281.  It incorporates verified errata. 

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-3281update-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9HB8jMV046467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2008 04:08:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9HB8jZM046466; Fri, 17 Oct 2008 04:08:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9HB8XNV046444 for <[e-mail]>; Fri, 17 Oct 2008 04:08:44 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id 967023FAC0; Fri, 17 Oct 2008 12:08:32 +0100 (IST)
X-Virus-Scanned: amavisd-new at cs.tcd.ie
Received: from cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TaADISAqj+F; Fri, 17 Oct 2008 12:08:31 +0100 (IST)
Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18]) by smtp.cs.tcd.ie (Postfix) with ESMTP id A82C23FA65; Fri, 17 Oct 2008 12:08:30 +0100 (IST)
Message-ID: <[e-mail]>
Date: Fri, 17 Oct 2008 12:09:36 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: Carl Wallace <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.
References: <p06240519c5098940c2e4@[128.89.89.71]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Carl,

Thanks for those. I guess mostly I'll just peek at the next rev for
the changes. A few follow-ups below though.

S.

Carl Wallace wrote:


> 3: Does 3.1.1 imply that message integrity cannot be provided by a
> transport
> security service/mechanism but MUST be defined and used "in-band" in the
> TAMP
> protocol? I think I don't mind for this protocol, but its not quite
> clear from
> the text.
> 
> [CRW] Section 3.1 has been clarified as requiring in-band integrity.

Seems ok. But I think you need to specify if use is required or
optional, i.e. the options seem to be "a TAMP MUST define in-band
integrity mechanisms," or "every TAMP message MUST use an in-band
integrity mechanism." I'd go for the former, just on the basis
that the latter is harder to state correctly (there might be some
message that's ok without in-band integrity and there could be
some deployments where transport-layer integrity is doable and
sufficient). But if you prefer the latter, I wouldn't object as
long as its clearly stated.

> 7: 3.4.1 calls for delegation to be a "MUST" for the protocol. I would
> have
> thought that a "MAY" is better here since delegation is inherently
> complex and
> a simpler protocol might turn out to be better. A "MAY" here lets us
> decide
> that later.  Delegation in 3.6.1 is a "should" vs a "must" in 3.4.1 - is
> that
> deliberate? (I'd go for "MAY" in both cases)
> 
> [CRW] Will relax the requirement in 3.4.1 to SHOULD.

Not sure that SHOULD is right here - its a requirement that a protocol
designer has to meet, so unless you can say when its ok to not provide
delegation, then how could you judge a proposed protocol?

> 12: 3.13.1 seems to be out of scope for a TAMP since its imposing a
> requirement
> on the 5280 processor and not on a TAMP. Maybe change from a requirement
> to a
> nice bit of advice or a security consideration?  (3.13.2 also
> contradicts the
> "must" in 3.13.1 I think)
> 
> [CRW] A great deal of the value associated with a TAM protocol is lost
> if enforcement of TA constraints is inconsistent.  I don't think this
> can be omitted as a requirement.  This was discussed during the last
> working group meeting.  The wording in the draft is based on some
> comments from Tim (either during or after the meeting).  I think Stefan
> advocated having specs require constraints to be processed, but no
> general requirement.

I still don't get how you'll judge this when presented with a proposed
protocol and hence still think this is better as a security
consideration rather than present it as a requirement that a TAM
*protocol* has to meet (which it cannot).





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9GKQdhE061175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2008 13:26:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9GKQdX9061174; Thu, 16 Oct 2008 13:26:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9GKQcxb061168 for <[e-mail]>; Thu, 16 Oct 2008 13:26:38 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 13533 invoked from network); 16 Oct 2008 20:13:14 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;16 Oct 2008 20:13:14 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 16 Oct 2008 20:13:13 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Comments 14 to 28 - Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt
Date: Thu, 16 Oct 2008 16:26:36 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments 14 to 28 - Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt
Thread-Index: AckvaM4/wpoNdAOCSrOBdyuFGhi0jQATS1+w
References: <[e-mail]>
From: "Carl Wallace" <[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>

Responses to specific comments are inline below.   I've snipped some
lengthy portions of the comments to avoid exceeding whatever message
length requirement prevented the initial distribution of the comments.

________________________________

 <snip - introductory text>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

14 - The definition of a Trust Anchor (see section 1.1) is not adequate
and=20
should be changed.=20

RFC 3379 states: "A trust anchor is defined as one public key, a CA
name, and a=20
validity time interval; a trust anchor optionally includes additional=20
constraints. The use of a self-signed certificate is one way to specify
the=20
public key to be used, the issuer name, and the validity period of the
public=20
key".=20

Replacement proposal:=20

Trust Anchor: data that includes one public key, a CA name, a validity
time=20
interval and optionally additional constraints to be used when
constructing and=20
validating a certification path, *as well as information for updates*. A
self-=20
signed certificate with or without constraints may be used to specify
the root=20
key of a trust anchor and additional constraints".=20

[CRW] The current definition was the result of much discussion on the
TAM BOF/PKIX mailing lists.  The current definition accommodates the
suggested scenario if validity period, update information, etc. is
viewed as associated data.  No change resulted from this comment.

15 - The current definition of a Trust Anchor Store (see section 1.1) is
:=20
Trust Anchor Store: A trust anchor store is a set of one or more trust
anchors.=20
A trust anchor store may be managed by one or more trust anchor
managers. A=20
device may have more than one trust anchor store.=20

Change into:=20

"Trust Anchor Store: A trust anchor store is a container which contains
one=20
trust anchor".=20

Within a validation policy, TAs can be grouped into sets, so that
different sets=20
can be used for different purposes. For example, within a signature
validation=20
policy, a set of TAs may be used to validate Attributes Certificates,
while=20
another one may be used to validate time-stamp tokens.=20

<snip - RFC 3379 quotation>

16 - Additional proposal:=20

<snip - validation policy store definition>

17 - Instead of a Trust Anchor Manager, a Validation Policy Manager
should be=20
defined.=20

Proposal:=20

Validation Policy Manager: A role responsible for managing the full
contents of=20
a given validation policy store.=20

[CRW] Re: 15, 16 and 17, we're not defining the requirements for
managing or using validation policies so these definitions are not
applicable.  No change resulted from these comments.=20

18 - Since a device or a system may support several validation policies,
some=20
entity should be able to create empty validation policy stores and then
tell who=20
is able to manage each of them.=20

Proposal: "Validation Policy Stores Manager": A role responsible for
managing,=20
for a given device or system, associations between validation policies
stores=20
and validation policy managers.=20

19 - The requirements in sections 3.X should be on validation policies
rather=20
than on TAs.=20

20 - In section 3.2.1, if would be better to separate the functional=20
requirements for validation policy stores managers, validation policy
managers=20
and the functional requirements for TAs.=20

<snip - functional requirements for validation policies>

[CRW] Re: 18, 19 and 20, we're not defining the requirements for
managing or using validation policies.  No change resulted from this
comment.  Comment 19 neatly summarizes the core disagreement.

21 - Section 3.5.1 is omitting to mention the revocation conditions that
apply=20
in RFC 5280 as well as the additional constraints that may exist.=20

[CRW] Will add a note to 3.5.2 noting that trust anchors used to
validate certification paths must provide revocation status information.

22 - Section 3.7.1 is about "Trust Anchor Formats". The problem is that
a=20
validation policy does not simply include TAs, but other information.
The=20
relationship between the TA formats and the validation policy format
should be=20
explained.=20

[CRW] A discussion of the relationship between concrete TA formats and
validation policy is probably appropriate for a document, but this is
not the appropriate document.  No change resulted from this comment.

23 - Section 3.7.1 is about "Trust Anchor Formats". The texts states:=20

   Minimally, a trust anchor management protocol must support management

   of trust anchors represented as self-signed certificates and trust=20
   anchors represented as a distinguished name and public key=20
   information.=20

This sentence is incorrect since a trust anchor is not simply defined
using a=20
distinguished name and public key information. Please refer to new
proposed=20
definition of a Trust anchor.=20

[CRW] Will augment this statement to include associated data.

There is also the need for a management protocol to support the
management of a=20
validation policy as a whole.=20

[CRW] We're not defining the requirements for managing or using
validation policies. =20

The texts states:=20

The definition of a trust anchor must include a public key, a public key

algorithm and, if necessary, public key parameters.=20

This is in contradiction with the previous sentence.=20

   When the public key is used to validate certification paths, a=20
   distinguished name also must be included per [RFC3852].=20

The next sentence attempts to express a requirement, but is not
understandable :=20

A trust anchor format should enable specification of public key
identifier to=20
enable other applications of the trust anchor, for example, verification
of data=20
signed using the Cryptographic Message Syntax (CMS) SignedData structure

[RFC3852].=20

What is the "specification of public key identifier" ?=20

[CRW] In contexts where TAs are represented as certificates, it is the
inclusion of a subjectKeyIdentifier extension.

The conditions that would=20
apply to verify data signed using CMS may not be included in the TA
format since=20
a root CA may not be aware of all the various usages of its root
certificate.=20

[CRW] In some cases this is true, in other cases the usages are known.
The requirement is that the protocol support the expression of these
constraints, not that all systems use this.

<snip - discussion of constraint placement>

24 - Section 3.8.1. Functional requirements that apply to validation
policy=20
managers and validation policy stores managers should also be considered

instead. Proposal:=20

<snip - discussion of validation policy managers>

[CRW] We're not defining the requirements for managing or using
validation policies.  No change resulted from this comment.=20

25 - Section 3.9 about source authentication. The functional
requirements from=20
section 3.9.1 are unrelated to the rationale from section 3.9.2. The
rational is=20
about authorization while the requirements are about authentication.
This=20
section needs to be revised.=20

[CRW] This section will be revised.  Most likely, sections 3.8 and 3.9
will be collapsed into one section.

26 - Section 3.10 about a reduction of reliance on out-of-bands
mechanism. While=20
the rationale from section 3.10.2 is roughly correct, the functional=20
requirements from section 3.10.1 are unrelated.=20

Replace with:=20

Out-of-band trust mechanisms should only be required to allow validation
policy=20
stores managers to manage validation policy stores.=20

[CRW] We're not defining the requirements for managing or using
validation policies, so the replacement text was not used.  I fail to
see that 3.10.1 and 3.10.2 are unrelated, but they are inconsistent.
Revised text for section 3.10.1 will be included in the next draft.=20

27 - Section 12 is about disaster recovery.=20

This requirement should not be placed in the MUST category but in the
SHOULD=20
category (it is only a nice-to-have feature). Systems should not be
mandated to=20
implement it. It is unsure what the editors have in mind behind this=20
requirement. Further explanations would be appreciated.=20

[CRW] The requirement is that the protocol support this.  Systems are
not mandated to implement it.  Will try to make this more clear in the
draft.=20

28 - Section 4. Security considerations section.=20

The text states:=20

In all scenarios, regardless of the authentication mechanism, at least
one trust=20
anchor manager must be established for each trust anchor store during
the=20
initial configuration of the trust anchor store.=20

The text should be reworded as follows:=20

In all scenarios, regardless of the authentication mechanism, at least
one=20
validation policy stores manager must be established for each device or
system.

[CRW] We're not defining the requirements for managing or using
validation policies.  No change resulted from this comment.=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9GKQXPI061151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2008 13:26:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9GKQXKH061149; Thu, 16 Oct 2008 13:26:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9GKQSIV061128 for <[e-mail]>; Thu, 16 Oct 2008 13:26:33 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 13523 invoked from network); 16 Oct 2008 20:13:04 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;16 Oct 2008 20:13:04 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 16 Oct 2008 20:13:03 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.
Date: Thu, 16 Oct 2008 16:26:26 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.
Thread-Index: AckojMc72h2rsjXfS1yb6xi6tK4IEwHMUZDg
References: <p06240519c5098940c2e4@[128.89.89.71]> <[e-mail]>
From: "Carl Wallace" <[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>

Comments moved from attachment and copied below along with responses.


Comments on http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01

General:
-------

1: A scope question - does this document specify requirements for a
protocol
where the TAM is not represented as a TA?  If not (which is fine), then
perhaps
just say so directly, rather than indirectly as (I think) is currently
the
case.

[CRW] The intent was not to limit the representation of a TAM to be a
TA.  This could be delegated using a certificate.  Will clarify this in
section 3.4 and in the definition of a trust anchor manager. =20

2: MUST/SHOULD etc. Section 2 says in part "...trust anchor stores must
be
managed in accord with..." whereas section 3 has a bunch of more
specific uses
of "must" (all lowercase, but whatever). It should be clear which bits
are RFC
2119 language and which aren't. I'd also prefer use of uppercase MUSTs
where
2119 is supposed to apply (and then a reference is needed as well.) The
specific sentence is section 2 isn't something that I think can be a
MUST since
its unenforceable. Similarly, in 3.1.2 the word "required" is used
though the
section is called "rationale" - is that meant to be a 2119 keyword or
not?

[CRW] Have adopted RFC2119 language for the next draft.

3: Does 3.1.1 imply that message integrity cannot be provided by a
transport
security service/mechanism but MUST be defined and used "in-band" in the
TAMP
protocol? I think I don't mind for this protocol, but its not quite
clear from
the text.

[CRW] Section 3.1 has been clarified as requiring in-band integrity.

4: Does "transport independent" here mean the same as "can be used in
both
session oriented and store-and-forward contexts"? If not, then would a
TAMP
that (somehow) works over TCP but not DCCP comply? If so, then maybe
merge the
first two sentences of 3.1.1 and lose the "must be transport
independent"
phrase.

[CRW] Section 3.1 has been revised per some offlist comments.  These
should address your concerns.

5: section 3.2.2 - what does "are compound" mean? If its not needed
maybe
delete the sentence. If its needed, I think it needs to be clearer.

[CRW] Will clarify.  The intent is that multiple trust anchors can be
acted upon in a single add or remove message.

6: 3.3.1 seems to introduce "groups of trust anchor stores" with the
implication that they are named groups, but the sentence isn't clear
about
that. If named groups are required say so. If not, get rid of the term.
(If the
latter, then bullets 2 & 3 here could be merged into "an emumerated list
of
trust anchor stores" since a single element list is a fine list:-)

[CRW] Will clarify that named groups are intended.

7: 3.4.1 calls for delegation to be a "MUST" for the protocol. I would
have
thought that a "MAY" is better here since delegation is inherently
complex and
a simpler protocol might turn out to be better. A "MAY" here lets us
decide
that later.  Delegation in 3.6.1 is a "should" vs a "must" in 3.4.1 - is
that
deliberate? (I'd go for "MAY" in both cases)

[CRW] Will relax the requirement in 3.4.1 to SHOULD.

8: 3.8.1 calls for replay detection for reports - surely the requirement
would
also apply to other operations as well? (Reading further it seems that
3.11.1
does call for that, so suggest removing that from 3.8.1 in which case
one of
3.8.1 or 3.9.1 can be removed?)

[CRW] Will collapse 3.8 and 3.9 into one section.  Will let 3.11 serve
as replay detection requirement.

9: 3.10.1 might be defining a new operation or might be covered in
3.2.1, I'm
not sure. If its covered, then maybe delete 3.10.1, or is the point that
3.2.1
is must whereas 3.10.1 is a should?=20

[CRW] 3.10 is not a new operation but is probably best presented as
rationale.  Will probably fold content into 3.2.

10: 3.11.1 almost seems to prevent use of reliable time information,
which I
guess isn't right. Presumably it'd be ok to have a TAMP that with an
applicability statement saying it only applied where time was available?
(I do
however, like the idea of also being able to work where there's no good
time,
but perhaps that implies that there's a "MAY" missing somewhere?)

[CRW] Reworded to require a replay detection mechanism to be available
that does not require reliable time and to clarify that mechanisms may
be available that do. =20

11: 3.12.1 - a "MUST" here seems too strong, in particular for the
"source of
trust anchor information" - I think that'd be better as a MAY.

[CRW] MUST seems right here to me.  The protocol MUST provide a means
for recovering from loss of a TA key.  A protocol without this would not
meet the requirements.  An implementation may choose not to provide this
or a system may choose not to use it.  Replaced "source of trust anchor
information" with "trust anchor manager"

12: 3.13.1 seems to be out of scope for a TAMP since its imposing a
requirement
on the 5280 processor and not on a TAMP. Maybe change from a requirement
to a
nice bit of advice or a security consideration?  (3.13.2 also
contradicts the
"must" in 3.13.1 I think)

[CRW] A great deal of the value associated with a TAM protocol is lost
if enforcement of TA constraints is inconsistent.  I don't think this
can be omitted as a requirement.  This was discussed during the last
working group meeting.  The wording in the draft is based on some
comments from Tim (either during or after the meeting).  I think Stefan
advocated having specs require constraints to be processed, but no
general requirement.

13: I think the security considerations could usefully point out that a
TAMP
creates a nice new target to attack - if I can get at the TAM private
key or
replace the public key I can control a lot of the security stuff on the
box.
Also, if a TAM makes a mistake (e.g. a typo in an allowed name
constraint) that
creates a new accidental-DoS vector.

[CRW] OK. =20

Nits:
-----

1: section 1, 1st bullet "begins a certification path" is a bit
ambiguous
depending on whether the EE or CA is first or last. Suggest rephrasing
(maybe
just say "a public key certificate" and leave it at that)

[CRW] The phrase is consistent with RFC 5280, which states that "Valid
paths begin with certificates issued by a trust anchor."  I assume you
don't want the change simply to accommodate invalid paths:-)

2: section 2, "Throughout this document, trust anchor managers are
assumed to
be represented as trust anchors." Well, in the case where an application
manages trust anchors (e.g. like a browser) that may not be true. Maybe
just
add a caveat here that other schemes are possible but aren't covered in
this
document.=20

[CRW] This has been reworded in response to another comment - not
exactly this way but maybe good enough.

3: s/and etc./etc./

4: last para of section 2, s/which trust anchors/the set of trust
anchors/

5: section 3.3.1: is "TA Management" the same as "TA Manager" (the
latter is a
defined term, the former not). If so, just use one; if not, please
define the
term.

6: "specification of public key identifier" needs an "a" in 3.7.1

[CRW] Fixed all of the above.

7: 3.8.1 and 3.9.1 seem to overlap a bit and could maybe be simplified
(3.9.1
seems to call for everything in 3.8.1 other than replay detection)

[CRW] Will collapse these two sections.

8: I've no idea if 5280 and 5055 should be normative references for a
protocol
requirements document, but then I also don't care. However, maybe
someone else
does? :-)

[CRW] Left as-is pending comments from someone else.
=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Farrell
Sent: Tuesday, October 07, 2008 10:36 AM
To: [e-mail]
Subject: Re: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.


Bunch of comments attached. While this version is quite close, I think
some of these do warrant changes.

Cheers,
Stephen.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9GKQYWF061162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2008 13:26:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9GKQYHM061161; Thu, 16 Oct 2008 13:26:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9GKQXVn061139 for <[e-mail]>; Thu, 16 Oct 2008 13:26:33 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 13528 invoked from network); 16 Oct 2008 20:13:09 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;16 Oct 2008 20:13:09 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 16 Oct 2008 20:13:08 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Comments 1 to 13 - Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt
Date: Thu, 16 Oct 2008 16:26:31 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments 1 to 13 - Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt
Thread-Index: AckvZ2EJ4acr1dOtQ6u2yGMBicTQnQAQrdHg
References: <[e-mail]>
From: "Carl Wallace" <[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>

Responses are inline below.   I've snipped some lengthy portions of the
comments to avoid exceeding whatever message length requirement
prevented the initial distribution of the comments. =20

________________________________

 <snip - introductory text>
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
Comments on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt. October 3, 2008 =20

Summary =20

The current draft omits to take into consideration the existence of a TA

management protocol that already exists and which is defied in RFC 4210.

=20
[CRW] A reference to the RFC 4210 mechanism has been added to section 2
of the draft.  The RFC 4210 mechanism was discussed relative to the
requirements draft during the WG meeting in Dublin. =20

The current draft omits to take into consideration the concept of a
validation =20
policy which is described in RFC 3379 and in RFC 3125.  =20
=20
[CRW] Validation policies are indirectly referenced in section 3.5,
which requires the trust anchor management protocol to support
management of trust anchors in accordance with RFCs 5280 and 5055.
Validation policies were discussed relative to the requirements draft
during the WG meetings in Philadelphia and Dublin.

The current draft only considers a push model, whereas a pull model
should be =20
considered.  =20
=20
[CRW] The requirements are applicable to either push or pull models.
This will be made explicit in section 3.1.

A different approach with three steps is proposed. =20

Please find below a list of 28 detailed comments. =20

1 - The document states in the abstract: "A trust anchor represents an =20
authoritative entity via a public key and associated data. The public
key is =20
used to verify digital signatures ...". =20

This is incorrect. A trust anchor is not simply used to verify *digital

signatures*, but to verify *chains of certificates*. =20
=20
[CRW] The definition in the draft was the result of much mailing list
and WG/BOF discussion.  TAs are used for purposes other than
verification of "chains of certificates".  No change resulted from this
comment.
=20
2 - The abstract is incorrect, since it mentions the "lack of a standard
trust =20
anchor management mechanism", whereas a management protocol based on
pull model =20
described in RFC 4210 exists.  =20
=20
[CRW] As noted above, a reference to the 4210 mechanism has been added
to section 2.  =20

3 - The document is only considering one way to manage TAs, i.e. when TA

information is "pushed" towards a device or a system.  =20
=20
[CRW] As noted above, the requirements are applicable to push or pull
models.  This will be made explicit in section 3.1.

 <snip - CMP discussion>
=20
4 - In order to allow the use of the pull model, additional data needs
to be =20
associated with a TA. Hereafter is a proposal for a requirement: =20

"Section 3.X. TA format for automatic update =20

3.X.1 Functional requirement =20

The format of the TA must support the CMP protocol defined in RFC 4210
that =20
allows changing self-signed certificates. The format must allow
indicating: (a) =20
whether automatic updates are allowed or not, (b) where the information
may be =20
fetched, and (c) the expected time period between two consecutive
published =20
information. Once a TA has been updated there should be two TAs valid at
a time =20
for the same CA: the old one and the new one. =20

3.X.2. Rationale =20

CMP defines a protocol which allows root CAs to provide information that
allows =20
a smooth change key rollover. The protocol allows to pull information
from a CA =20
store and to automatically update TA information. When a root CA renews
its =20
self-signed certificate, the old self-signed certificate needs to be
used to =20
verify old certificates, while the new one needs to be used to verify
new =20
certificates. This means that usually two TAs are valid at one point of
time for =20
each root CA".  =20
=20
[CRW] Section 3.7 requires support for managing self-signed
certificates.  This provides a bridge to the RFC 4210 mechanism.  The
automatic update information could be instantiated as an instance of the
"associated data" included in the definition of a TA.   No change
resulted from this comment.

5 - As RFC 3379 mentions, TAs are used in validation policies: =20

 <snip - quotation from RFC 3379>
=20
The format of a validation policy may be rather complex. Before
attempting to =20
standardize its detailed content, a first step would be to define the
format of =20
TAs that must be placed inside validation policies. Systems or devices
could =20
then locate TA information within the validation policies, and take into
account =20
the format of the TAs to automatically renew the TAs, if allowed.  =20
=20
[CRW] Validation policies are already been standardized - in RFC 5055.
The requirements for TA formats are defined in section 3.7.   We're not
defining the requirements for managing or using validation policies.  No
change resulted from this comment.

6 - A second step, more ambitious, in the direction of standardization
would be =20
to allow to add, remove or replace validation policies as a whole, but
treat the =20
detailed rules as opaque. The additional requirements would be reduced
to the =20
identification of the validation policies and the identification of the
entities =20
allowed managing them as a whole.  =20
=20
[CRW]  We've discussed validation policies at two PKIX meetings and
there has been little (or no) support voiced for using validation
policies as TAs or TA stores.  No change resulted from this comment.

7 - In order to address the second step, a validation policy must
include =20
information such as: =20

   - a unique identifier of the policy, =20
   - the name of the issuer of the policy, =20
   - the field of application of the policy, etc ... =20

8 - To summarize the approach for both the first and the second steps, a

validation policy store would include: =20
   - management information for the ownership of a validation policy
store =20
     (not modifiable by the validation policy manager). =20
   - a unique identifier of the policy, the name of the issuer of the
policy, =20
     the field of application of the policy, etc ... =20
   - a set of TAs, each one with : =20
       - an indicator to state whether automatic self-signed certificate
updates =20
         are allowed or not, =20
       - URLs to say where the updated self-signed certificates may be
fetched, =20
         and =20
       - optionally, the time period between two consecutive self-signed

         certificate updates. =20
   - an opaque definition of the validation policy that contains
pointers =20
     to the TAs placed above with constraints for each TA. =20

The picture below attempts to show the general content of a validation
policy =20
and its relationship with TAs, each TA being placed in *one* TAS (TA
store) =20

 <snip - ASCII art>
=20
Note: if the above example, if the validation policy 1 is applied to a
CMS =20
message that is both signed and encrypted, then Purpose 1 specifies the

conditions for signature validation, while purpose 2 specifies the
conditions =20
for decryption. =20

9 - If the concern is also addition and deletion of trust anchors, TAs
anchors =20
that are present in a validation policy store can only be defined, added
or =20
removed by a "validation policy manager", i.e. NOT a "TA store manager"=20

10 - The final step would be the definition of the detailed contents of
some =20
validation policies.  =20
=20
[CRW] Re: 7, 8, 9 and 10, we're not defining the requirements for
managing or using validation policies.  No change resulted from this
comment.=20

11 - The document states: "There is currently no standard means of
limiting the =20
applicability (scope) of a trust anchor except by placing different TAs
in =20
different stores and limiting the set of applications that access a
given TA =20
store".   =20

This is incorrect. RFC 3125 introduces the concept of a "signature
policy" and =20
of a "signature validation policy" that allows to designate different
trust =20
anchors for the validation of the signer's certificate *and* for the
validation =20
of time-stamp tokens. TAs are placed in validation policies, not in
Trust Anchor =20
Stores.  =20
=20
[CRW]  Will reword to state that there is no standard general purpose
mechanism.  In any case, RFC 3125 is experimental.

12 - The verification of a chain of certificates mandates the checking
of =20
revocation statuses of the certificates from the revocation chain. This
aspect =20
is not addressed in the draft. Such rules need to be defined in the
validation =20
policy. =20

Some old implementations are simply omitting to check the revocation
statuses. =20
In some other cases, it may be sufficient to use ARLs for CA
certificates, but =20
for leaf certificates an OCSP response may sometimes be required. In
some other =20
cases, the use of delta CRLs may be required. When OCSP is used the
source of =20
authority may not necessarily be the CA that has issued the certificate.
In some =20
other cases, it may be required to check at regular intervals if an
emergency =20
ARL or CRL has not been issued. In that case the intervals should be
specified. =20

All these aspects are related to the third step. They should be
mentioned in the =20
draft.  =20
=20
[CRW] RFC 5280 addresses revocation status checking.  The revocation
status of trust anchors is not checked, hence the omission of a
discussion of revocation status checking.  No change resulted from this
comment.=20

13 - Signature validation policies (that are used for non-repudiation
purposes) =20
cannot be changed (i.e. redefined), but can only be replaced. This means
that =20
updating a TA within a signature validation policy is not allowed. As a

consequence, a signature validation policy can only be changed as a
whole. =20

On the contrary, TAs contained in other types of validation policies
(e.g. used =20
for authentication purposes) may be changed. =20
=20
[CRW] We're not defining the requirements for managing or using
validation policies.  No change resulted from this comment.=20
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


See the second message for comments 14 to 28.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9GKQX3W061150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2008 13:26:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9GKQXkI061143; Thu, 16 Oct 2008 13:26:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9GKQM0j061126 for <[e-mail]>; Thu, 16 Oct 2008 13:26:33 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 13518 invoked from network); 16 Oct 2008 20:12:58 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;16 Oct 2008 20:12:58 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 16 Oct 2008 20:12:58 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.
Date: Thu, 16 Oct 2008 16:26:20 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.
Thread-Index: Ackm1V0iNQqMUbMETDSF7Oi6hQgfLwI7k1Pg
References: <p06240519c5098940c2e4@[128.89.89.71]> <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[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>

I think the comment in 3.2.1 should be removed and the decision
regarding what an implementation must/may implement left to protocol
specifications.

-----Original Message-----
From: Yoav Nir [mailto:[e-mail]]=20
Sent: Sunday, October 05, 2008 6:30 AM
To: Carl Wallace
Cc: [e-mail]
Subject: Re: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.

Hi

I've just read through this document, and I have but one comment.

In section 3.2.1 it says, "A trust anchor management protocol must
provide support for these basic operations, however, not all
implementations must support each option..."

I think a similar paragraph is needed in sections 3.3.1 and 3.4.1:
- It's perfectly reasonable to have a certain implementation (maybe the
same one that only replaces the entire store) only make messages for all
the TA stores for which it is responsible
- It's also reasonable for certain implementations to never delegate
authority to another manager, and only support re-key.

Other than that, I think the document is ready for publication.

On Oct 3, 2008, at 7:53 PM, Carl Wallace wrote:

>
> We just submitted a new version of this draft.  Changes are minor=20
> aside from the addition of section 3.13, which adds a requirement to=20
> enforce constraints where a TA mgmt protocol is used to manage a trust

> anchor store.  Please review the -01 version for WGLC.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9G8ARGI093439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2008 01:10:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9G8AR1w093438; Thu, 16 Oct 2008 01:10:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9G8APci093430 for <[e-mail]>; Thu, 16 Oct 2008 01:10:25 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA60038 for <[e-mail]>; Thu, 16 Oct 2008 10:22:56 +0200
Received: from FRMYA-SIA24 ([129.182.109.114]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008101610102418:255471 ; Thu, 16 Oct 2008 10:10:24 +0200 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Comments 14 to 28 - Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt
Date: Thu, 16 Oct 2008 10:10:23 +0200
Message-Id: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 16/10/2008 10:10:24, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 16/10/2008 10:10:24, Serialize complete at 16/10/2008 10:10:24
Content-Type: multipart/alternative;  boundary="----=_NextPart_08101610102335803588420_002"
Sender: [e-mail]
Precedence: 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_08101610102335803588420_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

These comments have been sent twice to the WG list but have not appeared on the list.
The first message was sent on October 10.

These comments have then been sent to the co-chairs for investigation, but there is no result yet.
So I am reposting them, split in two parts, in case the original message was rejected because it was too long.
The first part was about comments 1 to 13.
The second part is about comments 14 to 28.
=============================
14 - The definition of a Trust Anchor (see section 1.1) is not adequate and 
should be changed. 

RFC 3379 states: "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". 

Replacement proposal: 

Trust Anchor: data that includes one public key, a CA name, a validity time 
interval and optionally additional constraints to be used when constructing and 
validating a certification path, *as well as information for updates*. A self- 
signed certificate with or without constraints may be used to specify the root 
key of a trust anchor and additional constraints". 

15 - The current definition of a Trust Anchor Store (see section 1.1) is : 
Trust Anchor Store: A trust anchor store is a set of one or more trust anchors. 
A trust anchor store may be managed by one or more trust anchor managers. A 
device may have more than one trust anchor store. 

Change into: 

“Trust Anchor Store: A trust anchor store is a container which contains one 
trust anchor”. 

Within a validation policy, TAs can be grouped into sets, so that different sets 
can be used for different purposes. For example, within a signature validation 
policy, a set of TAs may be used to validate Attributes Certificates, while 
another one may be used to validate time-stamp tokens. 

RFC 3379 states in section 7: 

   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. (...) 
   Additional constraints for each trust anchor MAY be defined. (...) 
   These constraints MAY also be included in self-signed certificates. 

16 - Additional proposal: 

Validation Policy Store: compartment to place a set of rules, uniquely 
identified, that serve specific purposes against which the validation of a 
certificate or of a signature shall be performed. It includes at least one 
trust anchor associated with constraints, but may include several sets of trust 
anchors associated with other constraints to be used within the policy for a 
specific purpose". 

17 - Instead of a Trust Anchor Manager, a Validation Policy Manager should be 
defined. 

Proposal: 

Validation Policy Manager: A role responsible for managing the full contents of 
a given validation policy store. 

18 - Since a device or a system may support several validation policies, some 
entity should be able to create empty validation policy stores and then tell who 
is able to manage each of them. 

Proposal: "Validation Policy Stores Manager": A role responsible for managing, 
for a given device or system, associations between validation policies stores 
and validation policy managers. 

19 - The requirements in sections 3.X should be on validation policies rather 
than on TAs. 

20 - In section 3.2.1, if would be better to separate the functional 
requirements for validation policy stores managers, validation policy managers 
and the functional requirements for TAs. 

Functional requirement for validation policy stores managers: 
   o List the identifier and the attributes of the validation policies stores 

Functional requirements for validation policy managers: 
   o Determine the content of a validation policy store 
   o Define the content of a validation policy store 
   o Replace the content of a validation policy store 
   o Delete the content of a validation policy store 

Functional requirement for TAs: 
   o Update one or more TAs contained in a validation policy. 

21 - Section 3.5.1 is omitting to mention the revocation conditions that apply 
in RFC 5280 as well as the additional constraints that may exist. 

22 - Section 3.7.1 is about "Trust Anchor Formats". The problem is that a 
validation policy does not simply include TAs, but other information. The 
relationship between the TA formats and the validation policy format should be 
explained. 

23 - Section 3.7.1 is about "Trust Anchor Formats". The texts states: 

   Minimally, a trust anchor management protocol must support management 
   of trust anchors represented as self-signed certificates and trust 
   anchors represented as a distinguished name and public key 
   information. 

This sentence is incorrect since a trust anchor is not simply defined using a 
distinguished name and public key information. Please refer to new proposed 
definition of a Trust anchor. 

There is also the need for a management protocol to support the management of a 
validation policy as a whole. 

The texts states: 

The definition of a trust anchor must include a public key, a public key 
algorithm and, if necessary, public key parameters. 

This is in contradiction with the previous sentence. 

   When the public key is used to validate certification paths, a 
   distinguished name also must be included per [RFC3852]. 

The next sentence attempts to express a requirement, but is not understandable : 

A trust anchor format should enable specification of public key identifier to 
enable other applications of the trust anchor, for example, verification of data 
signed using the Cryptographic Message Syntax (CMS) SignedData structure 
[RFC3852]. 

What is the "specification of public key identifier" ? The conditions that would 
apply to verify data signed using CMS may not be included in the TA format since 
a root CA may not be aware of all the various usages of its root certificate. 

The last sentence states: 

A trust anchor format should also enable the use of constraints that can be 
applied to specify the type/usage of a trust anchor. 

It makes sense to associate additional constraints with TAs. The basic question 
is whether they should be included in the format of the TA or placed outside, 
i.e. in the validation policy. 
Since TAs may be used for different purposes in the same validation policy or in 
different validation policies, it should be allowed to associate different 
constraints. 

   - If the constraints are included in self-signed certificates, then they are 
     set by CA managers. 

   - If the constraints are not included in self-signed certificates, then they 
     are set by validation policy managers (rather than by TA managers). 

The above requirement does not capture these aspects. 

24 - Section 3.8.1. Functional requirements that apply to validation policy 
managers and validation policy stores managers should also be considered 
instead. Proposal: 

A validation policy manager must be able to authenticate which validation policy 
store corresponds to a report listing the contents of a validation policy 
storage and be able to confirm the contents of the report have not been 
subsequently altered. Replay of old reports (from the same device or system) 
must be detectable by a validation policy manager. 

A validation policy manager must be able to authenticate which device or system 
corresponds to a report listing the characteristics of the validation policy 
stores and be able to confirm the contents of the report have not been 
subsequently altered. Replay of old reports (from the same device or system) 
must be detectable by a validation policy stores manager. 

25 - Section 3.9 about source authentication. The functional requirements from 
section 3.9.1 are unrelated to the rationale from section 3.9.2. The rational is 
about authorization while the requirements are about authentication. This 
section needs to be revised. 

26 - Section 3.10 about a reduction of reliance on out-of-bands mechanism. While 
the rationale from section 3.10.2 is roughly correct, the functional 
requirements from section 3.10.1 are unrelated. 

Replace with: 

Out-of-band trust mechanisms should only be required to allow validation policy 
stores managers to manage validation policy stores. 

27 - Section 12 is about disaster recovery. 

This requirement should not be placed in the MUST category but in the SHOULD 
category (it is only a nice-to-have feature). Systems should not be mandated to 
implement it. It is unsure what the editors have in mind behind this 
requirement. Further explanations would be appreciated. 

28 - Section 4. Security considerations section. 

The text states: 

In all scenarios, regardless of the authentication mechanism, at least one trust 
anchor manager must be established for each trust anchor store during the 
initial configuration of the trust anchor store. 

The text should be reworded as follows: 

In all scenarios, regardless of the authentication mechanism, at least one 
validation policy stores manager must be established for each device or system.

------=_NextPart_08101610102335803588420_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 8pt; FONT-FAMILY: Tahoma" bgColor=#ffffff leftMargin=5 
topMargin=5>
<P>These comments have been sent twice to the WG list but have not appeared on 
the list.<BR>The first message was sent on October 10.<BR><BR>These comments 
have then been sent to the co-chairs for investigation, but there is no result 
yet.<BR>So I am reposting them, split in two parts, in case the original message 
was rejected because it was too long.</P>
<P>The first part was about comments 1 to 13.<BR>The second part is 
about&nbsp;comments 14 to 28.</P>
<P>=============================</P>
<P>14 - The definition of a Trust Anchor (see section 1.1) is not adequate and 
<BR>should be changed. <BR><BR>RFC 3379 states: "A trust anchor is defined as 
one public key, a CA name, and a <BR>validity time interval; a trust anchor 
optionally includes additional <BR>constraints. The use of a self-signed 
certificate is one way to specify the <BR>public key to be used, the issuer 
name, and the validity period of the public <BR>key". <BR><BR>Replacement 
proposal: <BR><BR>Trust Anchor: data that includes one public key, a CA name, a 
validity time <BR>interval and optionally additional constraints to be used when 
constructing and <BR>validating a certification path, *as well as information 
for updates*. A self- <BR>signed certificate with or without constraints may be 
used to specify the root <BR>key of a trust anchor and additional constraints". 
<BR><BR>15 - The current definition of a Trust Anchor Store (see section 1.1) is 
: <BR>Trust Anchor Store: A trust anchor store is a set of one or more trust 
anchors. <BR>A trust anchor store may be managed by one or more trust anchor 
managers. A <BR>device may have more than one trust anchor store. <BR><BR>Change 
into: <BR><BR>“Trust Anchor Store: A trust anchor store is a container which 
contains one <BR>trust anchor”. <BR><BR>Within a validation policy, TAs can be 
grouped into sets, so that different sets <BR>can be used for different 
purposes. For example, within a signature validation <BR>policy, a set of TAs 
may be used to validate Attributes Certificates, while <BR>another one may be 
used to validate time-stamp tokens. <BR><BR>RFC 3379 states in section 7: 
<BR><BR>&nbsp;&nbsp;&nbsp;A validation policy is a set of rules against which 
the validation <BR>&nbsp;&nbsp;&nbsp;of the certificate is performed. 
<BR>&nbsp;&nbsp;&nbsp;A validation policy MAY include several trust anchors. 
(...) <BR>&nbsp;&nbsp;&nbsp;Additional constraints for each trust anchor MAY be 
defined. (...) <BR>&nbsp;&nbsp;&nbsp;These constraints MAY also be included in 
self-signed certificates. <BR><BR>16 - Additional proposal: <BR><BR>Validation 
Policy Store: compartment to place a set of rules, uniquely <BR>identified, that 
serve specific purposes against which the validation of a <BR>certificate or of 
a signature shall be performed. It includes at least one <BR>trust anchor 
associated with constraints, but may include several sets of trust <BR>anchors 
associated with other constraints to be used within the policy for a 
<BR>specific purpose". <BR><BR>17 - Instead of a Trust Anchor Manager, a 
Validation Policy Manager should be <BR>defined. <BR><BR>Proposal: 
<BR><BR>Validation Policy Manager: A role responsible for managing the full 
contents of <BR>a given validation policy store. <BR><BR>18 - Since a device or 
a system may support several validation policies, some <BR>entity should be able 
to create empty validation policy stores and then tell who <BR>is able to manage 
each of them. <BR><BR>Proposal: "Validation Policy Stores Manager": A role 
responsible for managing, <BR>for a given device or system, associations between 
validation policies stores <BR>and validation policy managers. <BR><BR>19 - The 
requirements in sections 3.X should be on validation policies rather <BR>than on 
TAs. <BR><BR>20 - In section 3.2.1, if would be better to separate the 
functional <BR>requirements for validation policy stores managers, validation 
policy managers <BR>and the functional requirements for TAs. <BR><BR>Functional 
requirement for validation policy stores managers: <BR>&nbsp;&nbsp;&nbsp;o List 
the identifier and the attributes of the validation policies stores 
<BR><BR>Functional requirements for validation policy managers: 
<BR>&nbsp;&nbsp;&nbsp;o Determine the content of a validation policy store 
<BR>&nbsp;&nbsp;&nbsp;o Define the content of a validation policy store 
<BR>&nbsp;&nbsp;&nbsp;o Replace the content of a validation policy store 
<BR>&nbsp;&nbsp;&nbsp;o Delete the content of a validation policy store 
<BR><BR>Functional requirement for TAs: <BR>&nbsp;&nbsp;&nbsp;o Update one or 
more TAs contained in a validation policy. <BR><BR>21 - Section 3.5.1 is 
omitting to mention the revocation conditions that apply <BR>in RFC 5280 as well 
as the additional constraints that may exist. <BR><BR>22 - Section 3.7.1 is 
about "Trust Anchor Formats". The problem is that a <BR>validation policy does 
not simply include TAs, but other information. The <BR>relationship between the 
TA formats and the validation policy format should be <BR>explained. <BR><BR>23 
- Section 3.7.1 is about "Trust Anchor Formats". The texts states: 
<BR><BR>&nbsp;&nbsp;&nbsp;Minimally, a trust anchor management protocol must 
support management <BR>&nbsp;&nbsp;&nbsp;of trust anchors represented as 
self-signed certificates and trust <BR>&nbsp;&nbsp;&nbsp;anchors represented as 
a distinguished name and public key <BR>&nbsp;&nbsp;&nbsp;information. 
<BR><BR>This sentence is incorrect since a trust anchor is not simply defined 
using a <BR>distinguished name and public key information. Please refer to new 
proposed <BR>definition of a Trust anchor. <BR><BR>There is also the need for a 
management protocol to support the management of a <BR>validation policy as a 
whole. <BR><BR>The texts states: <BR><BR>The definition of a trust anchor must 
include a public key, a public key <BR>algorithm and, if necessary, public key 
parameters. <BR><BR>This is in contradiction with the previous sentence. 
<BR><BR>&nbsp;&nbsp;&nbsp;When the public key is used to validate certification 
paths, a <BR>&nbsp;&nbsp;&nbsp;distinguished name also must be included per 
[RFC3852]. <BR><BR>The next sentence attempts to express a requirement, but is 
not understandable : <BR><BR>A trust anchor format should enable specification 
of public key identifier to <BR>enable other applications of the trust anchor, 
for example, verification of data <BR>signed using the Cryptographic Message 
Syntax (CMS) SignedData structure <BR>[RFC3852]. <BR><BR>What is the 
"specification of public key identifier" ? The conditions that would <BR>apply 
to verify data signed using CMS may not be included in the TA format since <BR>a 
root CA may not be aware of all the various usages of its root certificate. 
<BR><BR>The last sentence states: <BR><BR>A trust anchor format should also 
enable the use of constraints that can be <BR>applied to specify the type/usage 
of a trust anchor. <BR><BR>It makes sense to associate additional constraints 
with TAs. The basic question <BR>is whether they should be included in the 
format of the TA or placed outside, <BR>i.e. in the validation policy. <BR>Since 
TAs may be used for different purposes in the same validation policy or in 
<BR>different validation policies, it should be allowed to associate different 
<BR>constraints. <BR><BR>&nbsp;&nbsp;&nbsp;- If the constraints are included in 
self-signed certificates, then they are <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;set by 
CA managers. <BR><BR>&nbsp;&nbsp;&nbsp;- If the constraints are not included in 
self-signed certificates, then they <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;are set by 
validation policy managers (rather than by TA managers). <BR><BR>The above 
requirement does not capture these aspects. <BR><BR>24 - Section 3.8.1. 
Functional requirements that apply to validation policy <BR>managers and 
validation policy stores managers should also be considered <BR>instead. 
Proposal: <BR><BR>A validation policy manager must be able to authenticate which 
validation policy <BR>store corresponds to a report listing the contents of a 
validation policy <BR>storage and be able to confirm the contents of the report 
have not been <BR>subsequently altered. Replay of old reports (from the same 
device or system) <BR>must be detectable by a validation policy manager. 
<BR><BR>A validation policy manager must be able to authenticate which device or 
system <BR>corresponds to a report listing the characteristics of the validation 
policy <BR>stores and be able to confirm the contents of the report have not 
been <BR>subsequently altered. Replay of old reports (from the same device or 
system) <BR>must be detectable by a validation policy stores manager. <BR><BR>25 
- Section 3.9 about source authentication. The functional requirements from 
<BR>section 3.9.1 are unrelated to the rationale from section 3.9.2. The 
rational is <BR>about authorization while the requirements are about 
authentication. This <BR>section needs to be revised. <BR><BR>26 - Section 3.10 
about a reduction of reliance on out-of-bands mechanism. While <BR>the rationale 
from section 3.10.2 is roughly correct, the functional <BR>requirements from 
section 3.10.1 are unrelated. <BR><BR>Replace with: <BR><BR>Out-of-band trust 
mechanisms should only be required to allow validation policy <BR>stores 
managers to manage validation policy stores. <BR><BR>27 - Section 12 is about 
disaster recovery. <BR><BR>This requirement should not be placed in the MUST 
category but in the SHOULD <BR>category (it is only a nice-to-have feature). 
Systems should not be mandated to <BR>implement it. It is unsure what the 
editors have in mind behind this <BR>requirement. Further explanations would be 
appreciated. <BR><BR>28 - Section 4. Security considerations section. 
<BR><BR>The text states: <BR><BR>In all scenarios, regardless of the 
authentication mechanism, at least one trust <BR>anchor manager must be 
established for each trust anchor store during the <BR>initial configuration of 
the trust anchor store. <BR><BR>The text should be reworded as follows: 
<BR><BR>In all scenarios, regardless of the authentication mechanism, at least 
one <BR>validation policy stores manager must be established for each device or 
system.<BR></P></BODY></HTML>

------=_NextPart_08101610102335803588420_002--





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9G7uEJs092167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2008 00:56:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9G7uEGS092166; Thu, 16 Oct 2008 00:56:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9G7u1JD092147 for <[e-mail]>; Thu, 16 Oct 2008 00:56:12 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA31226 for <[e-mail]>; Thu, 16 Oct 2008 10:08:31 +0200
Received: from FRMYA-SIA24 ([129.182.109.114]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008101609553336:254877 ; Thu, 16 Oct 2008 09:55:33 +0200 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "ietf-pkix"<[e-mail]>
Subject: Comments 1 to 13 - Response to WGLC on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt
Date: Thu, 16 Oct 2008 09:55:32 +0200
Message-Id: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 16/10/2008 09:55:33, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 16/10/2008 09:56:00, Serialize complete at 16/10/2008 09:56:00
Content-Type: multipart/alternative;  boundary="----=_NextPart_08101609553232610604324_002"
Sender: [e-mail]
Precedence: 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_08101609553232610604324_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

These comments have been sent twice to the WG list, but have not appeared on the list. 
The first message was sent on October 10. 

These comments have then been sent to the co-chairs for investigation, but there is no result yet. 
So I am reposting them, split in two parts, in case the original message was rejected because it was too long. 
The first part is about comments 1 to 13. 
The second part will be about comments 14 to 28.
 
=========================================================== 
Comments on TAM: draft-ietf-pkix-ta-mgmt-reqs-01.txt. October 3, 2008  

Summary  

The current draft omits to take into consideration the existence of a TA  
management protocol that already exists and which is defied in RFC 4210.  

The current draft omits to take into consideration the concept of a validation  
policy which is described in RFC 3379 and in RFC 3125.  

The current draft only considers a push model, whereas a pull model should be  
considered.  

A different approach with three steps is proposed.  

Please find below a list of 28 detailed comments.  

1 - The document states in the abstract: "A trust anchor represents an  
authoritative entity via a public key and associated data. The public key is  
used to verify digital signatures ...".  

This is incorrect. A trust anchor is not simply used to verify *digital  
signatures*, but to verify *chains of certificates*.  

2 - The abstract is incorrect, since it mentions the "lack of a standard trust  
anchor management mechanism", whereas a management protocol based on pull model  
described in RFC 4210 exists.  

3 - The document is only considering one way to manage TAs, i.e. when TA  
information is "pushed" towards a device or a system.  

CMP (RFC 4210) defines a protocol which allows root CAs to make available  
information that allows updating TAs. See section 4.4. "Root CA Key Update".  
In order to use it efficiently, the following data should be placed within a TA:  

   - an indicator to state whether automatic self-signed certificate updates are  
     allowed or not,  
   - URLs to say where the updated self-signed certificates may be fetched, and  
   - the expected time period between two consecutive self-signed certificate  
     updates.  

This would allow a RP to pull self-signed certificates and to renew them before  
they expire.  
As a consequence, when only updates of root keys is a concern, no new protocol  
for updating TA information needs to be defined, since there already exists one.  

Such a pull protocol offers a major advantage over the push model. When the  
system is placed in an intranet behind a firewall, it can make use of a web  
proxy to acquire updated self-signed certificates, usually on the Internet. As a  
consequence, there is no need to open new ports on the firewall to allow  
external connections for remote management. That information may be cached and  
the external world is then unaware of the number of devices or systems that uses it.  

The other major advantage is that the access control rights are included in the  
self-signed certificate: only the CA that has signed it is allowed to change it.  
This a very compact form which avoids managing access rights as it would be the  
case with the push model.  

4 - In order to allow the use of the pull model, additional data needs to be  
associated with a TA. Hereafter is a proposal for a requirement:  

"Section 3.X. TA format for automatic update  

3.X.1 Functional requirement  

The format of the TA must support the CMP protocol defined in RFC 4210 that  
allows changing self-signed certificates. The format must allow indicating: (a)  
whether automatic updates are allowed or not, (b) where the information may be  
fetched, and (c) the expected time period between two consecutive published  
information. Once a TA has been updated there should be two TAs valid at a time  
for the same CA: the old one and the new one.  

3.X.2. Rationale  

CMP defines a protocol which allows root CAs to provide information that allows  
a smooth change key rollover. The protocol allows to pull information from a CA  
store and to automatically update TA information. When a root CA renews its  
self-signed certificate, the old self-signed certificate needs to be used to  
verify old certificates, while the new one needs to be used to verify new  
certificates. This means that usually two TAs are valid at one point of time for  
each root CA".  

5 - As RFC 3379 mentions, TAs are used in validation policies:  

   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.  

   A validation policy is built from three components:  

   1. Certification path requirements,  
   2. Revocation requirements, and  
   3. End-entity certificate specific requirements.  

The format of a validation policy may be rather complex. Before attempting to  
standardize its detailed content, a first step would be to define the format of  
TAs that must be placed inside validation policies. Systems or devices could  
then locate TA information within the validation policies, and take into account  
the format of the TAs to automatically renew the TAs, if allowed.  

6 - A second step, more ambitious, in the direction of standardization would be  
to allow to add, remove or replace validation policies as a whole, but treat the  
detailed rules as opaque. The additional requirements would be reduced to the  
identification of the validation policies and the identification of the entities  
allowed managing them as a whole.  

7 - In order to address the second step, a validation policy must include  
information such as:  

   - a unique identifier of the policy,  
   - the name of the issuer of the policy,  
   - the field of application of the policy, etc ...  

8 - To summarize the approach for both the first and the second steps, a  
validation policy store would include:  
   - management information for the ownership of a validation policy store  
     (not modifiable by the validation policy manager).  
   - a unique identifier of the policy, the name of the issuer of the policy,  
     the field of application of the policy, etc ...  
   - a set of TAs, each one with :  
       - an indicator to state whether automatic self-signed certificate updates  
         are allowed or not,  
       - URLs to say where the updated self-signed certificates may be fetched,  
         and  
       - optionally, the time period between two consecutive self-signed  
         certificate updates.  
   - an opaque definition of the validation policy that contains pointers  
     to the TAs placed above with constraints for each TA.  

The picture below attempts to show the general content of a validation policy  
and its relationship with TAs, each TA being placed in *one* TAS (TA store)  

  +------------------------+   +------------------------+
  |   Validation policy 1  |   |   Validation policy 2  |
  |                        |   |                        |
  |     Description        |   |     Description        |
  |      +--------+        |   |      +--------+        |
  |      |  TAS 1 |        |   |      |  TAS 2 |        |
  |      +--------+        |   |      +--------+        |
  |      +--------+        |   |      +--------+        |
  |      |  TAS 2 |        |   |      |  TAS 3 |        |
  |      +--------+        |   |      +--------+        |
  |   +--------------+     |   |   +--------------+     |
  |   |  Purpose 1   |     |   |   |  Purpose 1   |     |
  |   |              |     |   |   |              |     |
  |   | TAS 1 Ref.   |     |   |   | TAS 2 Ref.   |     |
  |   |+ constraints |     |   |   |+ constraints |     |
  |   |              |     |   |   |              |     |
  |   | TAS 2 Ref.   |     |   |   | TAS 3 Ref.   |     |
  |   |+ constraints |     |   |   |+ constraints |     |
  |   +--------------+     |   |   +--------------+     |
  |   +--------------+     |   |   +--------------+     |
  |   |  Purpose 2   |     |   |   |  Purpose 3   |     |
  |   |              |     |   |   |              |     |
  |   | TAS 2 Ref.   |     |   |   | TAS 3 Ref.   |     |
  |   |+ constraints |     |   |   |+ constraints |     |
  |   +--------------+     |   |   +--------------+     |
  +------------------------+   +------------------------+

Note: if the above example, if the validation policy 1 is applied to a CMS  
message that is both signed and encrypted, then Purpose 1 specifies the  
conditions for signature validation, while purpose 2 specifies the conditions  
for decryption.  

9 - If the concern is also addition and deletion of trust anchors, TAs anchors  
that are present in a validation policy store can only be defined, added or  
removed by a "validation policy manager", i.e. NOT a “TA store manager” 

10 - The final step would be the definition of the detailed contents of some  
validation policies.  

11 - The document states: "There is currently no standard means of limiting the  
applicability (scope) of a trust anchor except by placing different TAs in  
different stores and limiting the set of applications that access a given TA  
store".  

This is incorrect. RFC 3125 introduces the concept of a "signature policy" and  
of a "signature validation policy" that allows to designate different trust  
anchors for the validation of the signer's certificate *and* for the validation  
of time-stamp tokens. TAs are placed in validation policies, not in Trust Anchor  
Stores.  

12 - The verification of a chain of certificates mandates the checking of  
revocation statuses of the certificates from the revocation chain. This aspect  
is not addressed in the draft. Such rules need to be defined in the validation  
policy.  

Some old implementations are simply omitting to check the revocation statuses.  
In some other cases, it may be sufficient to use ARLs for CA certificates, but  
for leaf certificates an OCSP response may sometimes be required. In some other  
cases, the use of delta CRLs may be required. When OCSP is used the source of  
authority may not necessarily be the CA that has issued the certificate. In some  
other cases, it may be required to check at regular intervals if an emergency  
ARL or CRL has not been issued. In that case the intervals should be specified.  

All these aspects are related to the third step. They should be mentioned in the  
draft.  

13 - Signature validation policies (that are used for non-repudiation purposes)  
cannot be changed (i.e. redefined), but can only be replaced. This means that  
updating a TA within a signature validation policy is not allowed. As a  
consequence, a signature validation policy can only be changed as a whole.  

On the contrary, TAs contained in other types of validation policies (e.g. used  
for authentication purposes) may be changed.  

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

See the second message for comments 14 to 28.

------=_NextPart_08101609553232610604324_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5>
<DIV>These&nbsp;comments&nbsp;have&nbsp;been&nbsp;sent&nbsp;twice&nbsp;to&nbsp;the&nbsp;WG&nbsp;list,&nbsp;but&nbsp;have&nbsp;not&nbsp;appeared&nbsp;on&nbsp;the&nbsp;list. 
<BR>The&nbsp;first&nbsp;message&nbsp;was&nbsp;sent&nbsp;on&nbsp;October&nbsp;10. 
<BR><BR>These&nbsp;comments&nbsp;have&nbsp;then&nbsp;been&nbsp;sent&nbsp;to&nbsp;the&nbsp;co-chairs&nbsp;for&nbsp;investigation,&nbsp;but&nbsp;there&nbsp;is&nbsp;no&nbsp;result&nbsp;yet. 
<BR>So&nbsp;I&nbsp;am&nbsp;reposting&nbsp;them,&nbsp;split&nbsp;in&nbsp;two&nbsp;parts,&nbsp;in&nbsp;case&nbsp;the&nbsp;original&nbsp;message&nbsp;was&nbsp;rejected&nbsp;because&nbsp;it&nbsp;was&nbsp;too&nbsp;long. 
<BR>The&nbsp;first&nbsp;part&nbsp;is&nbsp;about&nbsp;comments&nbsp;1&nbsp;to&nbsp;13. 
<BR>The&nbsp;second&nbsp;part&nbsp;will&nbsp;be&nbsp;about&nbsp;comments&nbsp;14&nbsp;to&nbsp;28.</DIV>
<DIV>&nbsp;<BR>=========================================================== 
<BR>Comments&nbsp;on&nbsp;TAM:&nbsp;draft-ietf-pkix-ta-mgmt-reqs-01.txt.&nbsp;October&nbsp;3,&nbsp;2008&nbsp; 
<BR><BR>Summary&nbsp; 
<BR><BR>The&nbsp;current&nbsp;draft&nbsp;omits&nbsp;to&nbsp;take&nbsp;into&nbsp;consideration&nbsp;the&nbsp;existence&nbsp;of&nbsp;a&nbsp;TA&nbsp; 
<BR>management&nbsp;protocol&nbsp;that&nbsp;already&nbsp;exists&nbsp;and&nbsp;which&nbsp;is&nbsp;defied&nbsp;in&nbsp;RFC&nbsp;4210.&nbsp; 
<BR><BR>The&nbsp;current&nbsp;draft&nbsp;omits&nbsp;to&nbsp;take&nbsp;into&nbsp;consideration&nbsp;the&nbsp;concept&nbsp;of&nbsp;a&nbsp;validation&nbsp; 
<BR>policy&nbsp;which&nbsp;is&nbsp;described&nbsp;in&nbsp;RFC&nbsp;3379&nbsp;and&nbsp;in&nbsp;RFC&nbsp;3125.&nbsp; 
<BR><BR>The&nbsp;current&nbsp;draft&nbsp;only&nbsp;considers&nbsp;a&nbsp;push&nbsp;model,&nbsp;whereas&nbsp;a&nbsp;pull&nbsp;model&nbsp;should&nbsp;be&nbsp; 
<BR>considered.&nbsp; 
<BR><BR>A&nbsp;different&nbsp;approach&nbsp;with&nbsp;three&nbsp;steps&nbsp;is&nbsp;proposed.&nbsp; 
<BR><BR>Please&nbsp;find&nbsp;below&nbsp;a&nbsp;list&nbsp;of&nbsp;28&nbsp;detailed&nbsp;comments.&nbsp; 
<BR><BR>1&nbsp;-&nbsp;The&nbsp;document&nbsp;states&nbsp;in&nbsp;the&nbsp;abstract:&nbsp;"A&nbsp;trust&nbsp;anchor&nbsp;represents&nbsp;an&nbsp; 
<BR>authoritative&nbsp;entity&nbsp;via&nbsp;a&nbsp;public&nbsp;key&nbsp;and&nbsp;associated&nbsp;data.&nbsp;The&nbsp;public&nbsp;key&nbsp;is&nbsp; 
<BR>used&nbsp;to&nbsp;verify&nbsp;digital&nbsp;signatures&nbsp;...".&nbsp; 
<BR><BR>This&nbsp;is&nbsp;incorrect.&nbsp;A&nbsp;trust&nbsp;anchor&nbsp;is&nbsp;not&nbsp;simply&nbsp;used&nbsp;to&nbsp;verify&nbsp;*digital&nbsp; 
<BR>signatures*,&nbsp;but&nbsp;to&nbsp;verify&nbsp;*chains&nbsp;of&nbsp;certificates*.&nbsp; 
<BR><BR>2&nbsp;-&nbsp;The&nbsp;abstract&nbsp;is&nbsp;incorrect,&nbsp;since&nbsp;it&nbsp;mentions&nbsp;the&nbsp;"lack&nbsp;of&nbsp;a&nbsp;standard&nbsp;trust&nbsp; 
<BR>anchor&nbsp;management&nbsp;mechanism",&nbsp;whereas&nbsp;a&nbsp;management&nbsp;protocol&nbsp;based&nbsp;on&nbsp;pull&nbsp;model&nbsp; 
<BR>described&nbsp;in&nbsp;RFC&nbsp;4210&nbsp;exists.&nbsp; 
<BR><BR>3&nbsp;-&nbsp;The&nbsp;document&nbsp;is&nbsp;only&nbsp;considering&nbsp;one&nbsp;way&nbsp;to&nbsp;manage&nbsp;TAs,&nbsp;i.e.&nbsp;when&nbsp;TA&nbsp; 
<BR>information&nbsp;is&nbsp;"pushed"&nbsp;towards&nbsp;a&nbsp;device&nbsp;or&nbsp;a&nbsp;system.&nbsp; 
<BR><BR>CMP&nbsp;(RFC&nbsp;4210)&nbsp;defines&nbsp;a&nbsp;protocol&nbsp;which&nbsp;allows&nbsp;root&nbsp;CAs&nbsp;to&nbsp;make&nbsp;available&nbsp; 
<BR>information&nbsp;that&nbsp;allows&nbsp;updating&nbsp;TAs.&nbsp;See&nbsp;section&nbsp;4.4.&nbsp;"Root&nbsp;CA&nbsp;Key&nbsp;Update".&nbsp; 
<BR>In&nbsp;order&nbsp;to&nbsp;use&nbsp;it&nbsp;efficiently,&nbsp;the&nbsp;following&nbsp;data&nbsp;should&nbsp;be&nbsp;placed&nbsp;within&nbsp;a&nbsp;TA:&nbsp; 
<BR><BR>&nbsp;&nbsp;&nbsp;-&nbsp;an&nbsp;indicator&nbsp;to&nbsp;state&nbsp;whether&nbsp;automatic&nbsp;self-signed&nbsp;certificate&nbsp;updates&nbsp;are&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;allowed&nbsp;or&nbsp;not,&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;-&nbsp;URLs&nbsp;to&nbsp;say&nbsp;where&nbsp;the&nbsp;updated&nbsp;self-signed&nbsp;certificates&nbsp;may&nbsp;be&nbsp;fetched,&nbsp;and&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;-&nbsp;the&nbsp;expected&nbsp;time&nbsp;period&nbsp;between&nbsp;two&nbsp;consecutive&nbsp;self-signed&nbsp;certificate&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;updates.&nbsp; 
<BR><BR>This&nbsp;would&nbsp;allow&nbsp;a&nbsp;RP&nbsp;to&nbsp;pull&nbsp;self-signed&nbsp;certificates&nbsp;and&nbsp;to&nbsp;renew&nbsp;them&nbsp;before&nbsp; 
<BR>they&nbsp;expire.&nbsp; 
<BR>As&nbsp;a&nbsp;consequence,&nbsp;when&nbsp;only&nbsp;updates&nbsp;of&nbsp;root&nbsp;keys&nbsp;is&nbsp;a&nbsp;concern,&nbsp;no&nbsp;new&nbsp;protocol&nbsp; 
<BR>for&nbsp;updating&nbsp;TA&nbsp;information&nbsp;needs&nbsp;to&nbsp;be&nbsp;defined,&nbsp;since&nbsp;there&nbsp;already&nbsp;exists&nbsp;one.&nbsp; 
<BR><BR>Such&nbsp;a&nbsp;pull&nbsp;protocol&nbsp;offers&nbsp;a&nbsp;major&nbsp;advantage&nbsp;over&nbsp;the&nbsp;push&nbsp;model.&nbsp;When&nbsp;the&nbsp; 
<BR>system&nbsp;is&nbsp;placed&nbsp;in&nbsp;an&nbsp;intranet&nbsp;behind&nbsp;a&nbsp;firewall,&nbsp;it&nbsp;can&nbsp;make&nbsp;use&nbsp;of&nbsp;a&nbsp;web&nbsp; 
<BR>proxy&nbsp;to&nbsp;acquire&nbsp;updated&nbsp;self-signed&nbsp;certificates,&nbsp;usually&nbsp;on&nbsp;the&nbsp;Internet.&nbsp;As&nbsp;a&nbsp; 
<BR>consequence,&nbsp;there&nbsp;is&nbsp;no&nbsp;need&nbsp;to&nbsp;open&nbsp;new&nbsp;ports&nbsp;on&nbsp;the&nbsp;firewall&nbsp;to&nbsp;allow&nbsp; 
<BR>external&nbsp;connections&nbsp;for&nbsp;remote&nbsp;management.&nbsp;That&nbsp;information&nbsp;may&nbsp;be&nbsp;cached&nbsp;and&nbsp; 
<BR>the&nbsp;external&nbsp;world&nbsp;is&nbsp;then&nbsp;unaware&nbsp;of&nbsp;the&nbsp;number&nbsp;of&nbsp;devices&nbsp;or&nbsp;systems&nbsp;that&nbsp;uses&nbsp;it.&nbsp; 
<BR><BR>The&nbsp;other&nbsp;major&nbsp;advantage&nbsp;is&nbsp;that&nbsp;the&nbsp;access&nbsp;control&nbsp;rights&nbsp;are&nbsp;included&nbsp;in&nbsp;the&nbsp; 
<BR>self-signed&nbsp;certificate:&nbsp;only&nbsp;the&nbsp;CA&nbsp;that&nbsp;has&nbsp;signed&nbsp;it&nbsp;is&nbsp;allowed&nbsp;to&nbsp;change&nbsp;it.&nbsp; 
<BR>This&nbsp;a&nbsp;very&nbsp;compact&nbsp;form&nbsp;which&nbsp;avoids&nbsp;managing&nbsp;access&nbsp;rights&nbsp;as&nbsp;it&nbsp;would&nbsp;be&nbsp;the&nbsp; 
<BR>case&nbsp;with&nbsp;the&nbsp;push&nbsp;model.&nbsp; 
<BR><BR>4&nbsp;-&nbsp;In&nbsp;order&nbsp;to&nbsp;allow&nbsp;the&nbsp;use&nbsp;of&nbsp;the&nbsp;pull&nbsp;model,&nbsp;additional&nbsp;data&nbsp;needs&nbsp;to&nbsp;be&nbsp; 
<BR>associated&nbsp;with&nbsp;a&nbsp;TA.&nbsp;Hereafter&nbsp;is&nbsp;a&nbsp;proposal&nbsp;for&nbsp;a&nbsp;requirement:&nbsp; 
<BR><BR>"Section&nbsp;3.X.&nbsp;TA&nbsp;format&nbsp;for&nbsp;automatic&nbsp;update&nbsp; 
<BR><BR>3.X.1&nbsp;Functional&nbsp;requirement&nbsp; 
<BR><BR>The&nbsp;format&nbsp;of&nbsp;the&nbsp;TA&nbsp;must&nbsp;support&nbsp;the&nbsp;CMP&nbsp;protocol&nbsp;defined&nbsp;in&nbsp;RFC&nbsp;4210&nbsp;that&nbsp; 
<BR>allows&nbsp;changing&nbsp;self-signed&nbsp;certificates.&nbsp;The&nbsp;format&nbsp;must&nbsp;allow&nbsp;indicating:&nbsp;(a)&nbsp; 
<BR>whether&nbsp;automatic&nbsp;updates&nbsp;are&nbsp;allowed&nbsp;or&nbsp;not,&nbsp;(b)&nbsp;where&nbsp;the&nbsp;information&nbsp;may&nbsp;be&nbsp; 
<BR>fetched,&nbsp;and&nbsp;(c)&nbsp;the&nbsp;expected&nbsp;time&nbsp;period&nbsp;between&nbsp;two&nbsp;consecutive&nbsp;published&nbsp; 
<BR>information.&nbsp;Once&nbsp;a&nbsp;TA&nbsp;has&nbsp;been&nbsp;updated&nbsp;there&nbsp;should&nbsp;be&nbsp;two&nbsp;TAs&nbsp;valid&nbsp;at&nbsp;a&nbsp;time&nbsp; 
<BR>for&nbsp;the&nbsp;same&nbsp;CA:&nbsp;the&nbsp;old&nbsp;one&nbsp;and&nbsp;the&nbsp;new&nbsp;one.&nbsp; 
<BR><BR>3.X.2.&nbsp;Rationale&nbsp; 
<BR><BR>CMP&nbsp;defines&nbsp;a&nbsp;protocol&nbsp;which&nbsp;allows&nbsp;root&nbsp;CAs&nbsp;to&nbsp;provide&nbsp;information&nbsp;that&nbsp;allows&nbsp; 
<BR>a&nbsp;smooth&nbsp;change&nbsp;key&nbsp;rollover.&nbsp;The&nbsp;protocol&nbsp;allows&nbsp;to&nbsp;pull&nbsp;information&nbsp;from&nbsp;a&nbsp;CA&nbsp; 
<BR>store&nbsp;and&nbsp;to&nbsp;automatically&nbsp;update&nbsp;TA&nbsp;information.&nbsp;When&nbsp;a&nbsp;root&nbsp;CA&nbsp;renews&nbsp;its&nbsp; 
<BR>self-signed&nbsp;certificate,&nbsp;the&nbsp;old&nbsp;self-signed&nbsp;certificate&nbsp;needs&nbsp;to&nbsp;be&nbsp;used&nbsp;to&nbsp; 
<BR>verify&nbsp;old&nbsp;certificates,&nbsp;while&nbsp;the&nbsp;new&nbsp;one&nbsp;needs&nbsp;to&nbsp;be&nbsp;used&nbsp;to&nbsp;verify&nbsp;new&nbsp; 
<BR>certificates.&nbsp;This&nbsp;means&nbsp;that&nbsp;usually&nbsp;two&nbsp;TAs&nbsp;are&nbsp;valid&nbsp;at&nbsp;one&nbsp;point&nbsp;of&nbsp;time&nbsp;for&nbsp; 
<BR>each&nbsp;root&nbsp;CA".&nbsp; 
<BR><BR>5&nbsp;-&nbsp;As&nbsp;RFC&nbsp;3379&nbsp;mentions,&nbsp;TAs&nbsp;are&nbsp;used&nbsp;in&nbsp;validation&nbsp;policies:&nbsp; 
<BR><BR>&nbsp;&nbsp;&nbsp;A&nbsp;validation&nbsp;policy&nbsp;is&nbsp;a&nbsp;set&nbsp;of&nbsp;rules&nbsp;against&nbsp;which&nbsp;the&nbsp;validation&nbsp;of&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;the&nbsp;certificate&nbsp;is&nbsp;performed.&nbsp; 
<BR><BR>&nbsp;&nbsp;&nbsp;A&nbsp;validation&nbsp;policy&nbsp;MAY&nbsp;include&nbsp;several&nbsp;trust&nbsp;anchors.&nbsp;A&nbsp;trust&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;anchor&nbsp;is&nbsp;defined&nbsp;as&nbsp;one&nbsp;public&nbsp;key,&nbsp;a&nbsp;CA&nbsp;name,&nbsp;and&nbsp;a&nbsp;validity&nbsp;time&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;interval;&nbsp;a&nbsp;trust&nbsp;anchor&nbsp;optionally&nbsp;includes&nbsp;additional&nbsp;constraints.&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;The&nbsp;use&nbsp;of&nbsp;a&nbsp;self-signed&nbsp;certificate&nbsp;is&nbsp;one&nbsp;way&nbsp;to&nbsp;specify&nbsp;the&nbsp;public&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;key&nbsp;to&nbsp;be&nbsp;used,&nbsp;the&nbsp;issuer&nbsp;name,&nbsp;and&nbsp;the&nbsp;validity&nbsp;period&nbsp;of&nbsp;the&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;public&nbsp;key.&nbsp; 
<BR><BR>&nbsp;&nbsp;&nbsp;Additional&nbsp;constraints&nbsp;for&nbsp;each&nbsp;trust&nbsp;anchor&nbsp;MAY&nbsp;be&nbsp;defined.&nbsp;These&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;constraints&nbsp;might&nbsp;include&nbsp;a&nbsp;set&nbsp;of&nbsp;certification&nbsp;policy&nbsp;constraints&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;or&nbsp;a&nbsp;set&nbsp;of&nbsp;naming&nbsp;constraints.&nbsp;These&nbsp;constraints&nbsp;MAY&nbsp;also&nbsp;be&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;included&nbsp;in&nbsp;self-signed&nbsp;certificates.&nbsp; 
<BR><BR>&nbsp;&nbsp;&nbsp;Additional&nbsp;conditions&nbsp;that&nbsp;apply&nbsp;to&nbsp;the&nbsp;certificates&nbsp;in&nbsp;the&nbsp;path&nbsp;MAY&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;also&nbsp;be&nbsp;specified&nbsp;in&nbsp;the&nbsp;validation&nbsp;policy.&nbsp;For&nbsp;example,&nbsp;specific&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;values&nbsp;could&nbsp;be&nbsp;provided&nbsp;for&nbsp;the&nbsp;inputs&nbsp;to&nbsp;the&nbsp;certification&nbsp;path&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;validation&nbsp;algorithm&nbsp;in&nbsp;[PKIX-1],&nbsp;such&nbsp;as&nbsp;user-initial-policy-set,&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;initial-policy-mapping-inhibit,&nbsp;initial-explicit-policy,&nbsp;or&nbsp;initial-&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;any-policy-inhibit.&nbsp; 
<BR><BR>&nbsp;&nbsp;&nbsp;Additional&nbsp;conditions&nbsp;that&nbsp;apply&nbsp;to&nbsp;the&nbsp;end-entity&nbsp;certificate&nbsp;MAY&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;also&nbsp;be&nbsp;specified&nbsp;in&nbsp;the&nbsp;validation&nbsp;policy.&nbsp;For&nbsp;example,&nbsp;a&nbsp;specific&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;name&nbsp;form&nbsp;might&nbsp;be&nbsp;required.&nbsp; 
<BR><BR>&nbsp;&nbsp;&nbsp;A&nbsp;validation&nbsp;policy&nbsp;is&nbsp;built&nbsp;from&nbsp;three&nbsp;components:&nbsp; 
<BR><BR>&nbsp;&nbsp;&nbsp;1.&nbsp;Certification&nbsp;path&nbsp;requirements,&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;2.&nbsp;Revocation&nbsp;requirements,&nbsp;and&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;3.&nbsp;End-entity&nbsp;certificate&nbsp;specific&nbsp;requirements.&nbsp; 
<BR><BR>The&nbsp;format&nbsp;of&nbsp;a&nbsp;validation&nbsp;policy&nbsp;may&nbsp;be&nbsp;rather&nbsp;complex.&nbsp;Before&nbsp;attempting&nbsp;to&nbsp; 
<BR>standardize&nbsp;its&nbsp;detailed&nbsp;content,&nbsp;a&nbsp;first&nbsp;step&nbsp;would&nbsp;be&nbsp;to&nbsp;define&nbsp;the&nbsp;format&nbsp;of&nbsp; 
<BR>TAs&nbsp;that&nbsp;must&nbsp;be&nbsp;placed&nbsp;inside&nbsp;validation&nbsp;policies.&nbsp;Systems&nbsp;or&nbsp;devices&nbsp;could&nbsp; 
<BR>then&nbsp;locate&nbsp;TA&nbsp;information&nbsp;within&nbsp;the&nbsp;validation&nbsp;policies,&nbsp;and&nbsp;take&nbsp;into&nbsp;account&nbsp; 
<BR>the&nbsp;format&nbsp;of&nbsp;the&nbsp;TAs&nbsp;to&nbsp;automatically&nbsp;renew&nbsp;the&nbsp;TAs,&nbsp;if&nbsp;allowed.&nbsp; 
<BR><BR>6&nbsp;-&nbsp;A&nbsp;second&nbsp;step,&nbsp;more&nbsp;ambitious,&nbsp;in&nbsp;the&nbsp;direction&nbsp;of&nbsp;standardization&nbsp;would&nbsp;be&nbsp; 
<BR>to&nbsp;allow&nbsp;to&nbsp;add,&nbsp;remove&nbsp;or&nbsp;replace&nbsp;validation&nbsp;policies&nbsp;as&nbsp;a&nbsp;whole,&nbsp;but&nbsp;treat&nbsp;the&nbsp; 
<BR>detailed&nbsp;rules&nbsp;as&nbsp;opaque.&nbsp;The&nbsp;additional&nbsp;requirements&nbsp;would&nbsp;be&nbsp;reduced&nbsp;to&nbsp;the&nbsp; 
<BR>identification&nbsp;of&nbsp;the&nbsp;validation&nbsp;policies&nbsp;and&nbsp;the&nbsp;identification&nbsp;of&nbsp;the&nbsp;entities&nbsp; 
<BR>allowed&nbsp;managing&nbsp;them&nbsp;as&nbsp;a&nbsp;whole.&nbsp; 
<BR><BR>7&nbsp;-&nbsp;In&nbsp;order&nbsp;to&nbsp;address&nbsp;the&nbsp;second&nbsp;step,&nbsp;a&nbsp;validation&nbsp;policy&nbsp;must&nbsp;include&nbsp; 
<BR>information&nbsp;such&nbsp;as:&nbsp; 
<BR><BR>&nbsp;&nbsp;&nbsp;-&nbsp;a&nbsp;unique&nbsp;identifier&nbsp;of&nbsp;the&nbsp;policy,&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;-&nbsp;the&nbsp;name&nbsp;of&nbsp;the&nbsp;issuer&nbsp;of&nbsp;the&nbsp;policy,&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;-&nbsp;the&nbsp;field&nbsp;of&nbsp;application&nbsp;of&nbsp;the&nbsp;policy,&nbsp;etc&nbsp;...&nbsp; 
<BR><BR>8&nbsp;-&nbsp;To&nbsp;summarize&nbsp;the&nbsp;approach&nbsp;for&nbsp;both&nbsp;the&nbsp;first&nbsp;and&nbsp;the&nbsp;second&nbsp;steps,&nbsp;a&nbsp; 
<BR>validation&nbsp;policy&nbsp;store&nbsp;would&nbsp;include:&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;-&nbsp;management&nbsp;information&nbsp;for&nbsp;the&nbsp;ownership&nbsp;of&nbsp;a&nbsp;validation&nbsp;policy&nbsp;store&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(not&nbsp;modifiable&nbsp;by&nbsp;the&nbsp;validation&nbsp;policy&nbsp;manager).&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;-&nbsp;a&nbsp;unique&nbsp;identifier&nbsp;of&nbsp;the&nbsp;policy,&nbsp;the&nbsp;name&nbsp;of&nbsp;the&nbsp;issuer&nbsp;of&nbsp;the&nbsp;policy,&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;field&nbsp;of&nbsp;application&nbsp;of&nbsp;the&nbsp;policy,&nbsp;etc&nbsp;...&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;-&nbsp;a&nbsp;set&nbsp;of&nbsp;TAs,&nbsp;each&nbsp;one&nbsp;with&nbsp;:&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&nbsp;an&nbsp;indicator&nbsp;to&nbsp;state&nbsp;whether&nbsp;automatic&nbsp;self-signed&nbsp;certificate&nbsp;updates&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;are&nbsp;allowed&nbsp;or&nbsp;not,&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&nbsp;URLs&nbsp;to&nbsp;say&nbsp;where&nbsp;the&nbsp;updated&nbsp;self-signed&nbsp;certificates&nbsp;may&nbsp;be&nbsp;fetched,&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&nbsp;optionally,&nbsp;the&nbsp;time&nbsp;period&nbsp;between&nbsp;two&nbsp;consecutive&nbsp;self-signed&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;certificate&nbsp;updates.&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;-&nbsp;an&nbsp;opaque&nbsp;definition&nbsp;of&nbsp;the&nbsp;validation&nbsp;policy&nbsp;that&nbsp;contains&nbsp;pointers&nbsp; 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to&nbsp;the&nbsp;TAs&nbsp;placed&nbsp;above&nbsp;with&nbsp;constraints&nbsp;for&nbsp;each&nbsp;TA.&nbsp; 
<BR><BR>The&nbsp;picture&nbsp;below&nbsp;attempts&nbsp;to&nbsp;show&nbsp;the&nbsp;general&nbsp;content&nbsp;of&nbsp;a&nbsp;validation&nbsp;policy&nbsp; 
<BR>and&nbsp;its&nbsp;relationship&nbsp;with&nbsp;TAs,&nbsp;each&nbsp;TA&nbsp;being&nbsp;placed&nbsp;in&nbsp;*one*&nbsp;TAS&nbsp;(TA&nbsp;store)&nbsp; 
<BR><BR><FONT face="Courier New">&nbsp; +------------------------+&nbsp;&nbsp; 
+------------------------+<BR>&nbsp; |&nbsp;&nbsp; Validation policy 1&nbsp; 
|&nbsp;&nbsp; |&nbsp;&nbsp; Validation policy 2&nbsp; |<BR>&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; 
Description&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; Description&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|<BR>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; TAS 1 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; TAS 2 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; TAS 2 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; TAS 3 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; 
+--------------+&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; 
+--------------+&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; |&nbsp; 
Purpose 1&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; 
|&nbsp; Purpose 1&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; 
|&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; | TAS 1 Ref.&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; | TAS 2 Ref.&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; |+ constraints 
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; |+ constraints 
|&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; | TAS 2 Ref.&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; | TAS 3 Ref.&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; |+ constraints 
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; |+ constraints 
|&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; 
+--------------+&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; 
+--------------+&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; 
+--------------+&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; 
+--------------+&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; |&nbsp; 
Purpose 2&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; 
|&nbsp; Purpose 3&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; 
|&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; | TAS 2 Ref.&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; | TAS 3 Ref.&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; |+ constraints 
|&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; |+ constraints 
|&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp; 
+--------------+&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp; 
+--------------+&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; 
+------------------------+&nbsp;&nbsp; +------------------------+</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Note:&nbsp;if&nbsp;the&nbsp;above&nbsp;example,&nbsp;if&nbsp;the&nbsp;validation&nbsp;policy&nbsp;1&nbsp;is&nbsp;applied&nbsp;to&nbsp;a&nbsp;CMS&nbsp; 
<BR>message&nbsp;that&nbsp;is&nbsp;both&nbsp;signed&nbsp;and&nbsp;encrypted,&nbsp;then&nbsp;Purpose&nbsp;1&nbsp;specifies&nbsp;the&nbsp; 
<BR>conditions&nbsp;for&nbsp;signature&nbsp;validation,&nbsp;while&nbsp;purpose&nbsp;2&nbsp;specifies&nbsp;the&nbsp;conditions&nbsp; 
<BR>for&nbsp;decryption.&nbsp; 
<BR><BR>9&nbsp;-&nbsp;If&nbsp;the&nbsp;concern&nbsp;is&nbsp;also&nbsp;addition&nbsp;and&nbsp;deletion&nbsp;of&nbsp;trust&nbsp;anchors,&nbsp;TAs&nbsp;anchors&nbsp; 
<BR>that&nbsp;are&nbsp;present&nbsp;in&nbsp;a&nbsp;validation&nbsp;policy&nbsp;store&nbsp;can&nbsp;only&nbsp;be&nbsp;defined,&nbsp;added&nbsp;or&nbsp; 
<BR>removed&nbsp;by&nbsp;a&nbsp;"validation&nbsp;policy&nbsp;manager",&nbsp;i.e.&nbsp;NOT&nbsp;a&nbsp;“TA&nbsp;store&nbsp;manager” 
<BR><BR>10&nbsp;-&nbsp;The&nbsp;final&nbsp;step&nbsp;would&nbsp;be&nbsp;the&nbsp;definition&nbsp;of&nbsp;the&nbsp;detailed&nbsp;contents&nbsp;of&nbsp;some&nbsp; 
<BR>validation&nbsp;policies.&nbsp; 
<BR><BR>11&nbsp;-&nbsp;The&nbsp;document&nbsp;states:&nbsp;"There&nbsp;is&nbsp;currently&nbsp;no&nbsp;standard&nbsp;means&nbsp;of&nbsp;limiting&nbsp;the&nbsp; 
<BR>applicability&nbsp;(scope)&nbsp;of&nbsp;a&nbsp;trust&nbsp;anchor&nbsp;except&nbsp;by&nbsp;placing&nbsp;different&nbsp;TAs&nbsp;in&nbsp; 
<BR>different&nbsp;stores&nbsp;and&nbsp;limiting&nbsp;the&nbsp;set&nbsp;of&nbsp;applications&nbsp;that&nbsp;access&nbsp;a&nbsp;given&nbsp;TA&nbsp; 
<BR>store".&nbsp; 
<BR><BR>This&nbsp;is&nbsp;incorrect.&nbsp;RFC&nbsp;3125&nbsp;introduces&nbsp;the&nbsp;concept&nbsp;of&nbsp;a&nbsp;"signature&nbsp;policy"&nbsp;and&nbsp; 
<BR>of&nbsp;a&nbsp;"signature&nbsp;validation&nbsp;policy"&nbsp;that&nbsp;allows&nbsp;to&nbsp;designate&nbsp;different&nbsp;trust&nbsp; 
<BR>anchors&nbsp;for&nbsp;the&nbsp;validation&nbsp;of&nbsp;the&nbsp;signer's&nbsp;certificate&nbsp;*and*&nbsp;for&nbsp;the&nbsp;validation&nbsp; 
<BR>of&nbsp;time-stamp&nbsp;tokens.&nbsp;TAs&nbsp;are&nbsp;placed&nbsp;in&nbsp;validation&nbsp;policies,&nbsp;not&nbsp;in&nbsp;Trust&nbsp;Anchor&nbsp; 
<BR>Stores.&nbsp; 
<BR><BR>12&nbsp;-&nbsp;The&nbsp;verification&nbsp;of&nbsp;a&nbsp;chain&nbsp;of&nbsp;certificates&nbsp;mandates&nbsp;the&nbsp;checking&nbsp;of&nbsp; 
<BR>revocation&nbsp;statuses&nbsp;of&nbsp;the&nbsp;certificates&nbsp;from&nbsp;the&nbsp;revocation&nbsp;chain.&nbsp;This&nbsp;aspect&nbsp; 
<BR>is&nbsp;not&nbsp;addressed&nbsp;in&nbsp;the&nbsp;draft.&nbsp;Such&nbsp;rules&nbsp;need&nbsp;to&nbsp;be&nbsp;defined&nbsp;in&nbsp;the&nbsp;validation&nbsp; 
<BR>policy.&nbsp; 
<BR><BR>Some&nbsp;old&nbsp;implementations&nbsp;are&nbsp;simply&nbsp;omitting&nbsp;to&nbsp;check&nbsp;the&nbsp;revocation&nbsp;statuses.&nbsp; 
<BR>In&nbsp;some&nbsp;other&nbsp;cases,&nbsp;it&nbsp;may&nbsp;be&nbsp;sufficient&nbsp;to&nbsp;use&nbsp;ARLs&nbsp;for&nbsp;CA&nbsp;certificates,&nbsp;but&nbsp; 
<BR>for&nbsp;leaf&nbsp;certificates&nbsp;an&nbsp;OCSP&nbsp;response&nbsp;may&nbsp;sometimes&nbsp;be&nbsp;required.&nbsp;In&nbsp;some&nbsp;other&nbsp; 
<BR>cases,&nbsp;the&nbsp;use&nbsp;of&nbsp;delta&nbsp;CRLs&nbsp;may&nbsp;be&nbsp;required.&nbsp;When&nbsp;OCSP&nbsp;is&nbsp;used&nbsp;the&nbsp;source&nbsp;of&nbsp; 
<BR>authority&nbsp;may&nbsp;not&nbsp;necessarily&nbsp;be&nbsp;the&nbsp;CA&nbsp;that&nbsp;has&nbsp;issued&nbsp;the&nbsp;certificate.&nbsp;In&nbsp;some&nbsp; 
<BR>other&nbsp;cases,&nbsp;it&nbsp;may&nbsp;be&nbsp;required&nbsp;to&nbsp;check&nbsp;at&nbsp;regular&nbsp;intervals&nbsp;if&nbsp;an&nbsp;emergency&nbsp; 
<BR>ARL&nbsp;or&nbsp;CRL&nbsp;has&nbsp;not&nbsp;been&nbsp;issued.&nbsp;In&nbsp;that&nbsp;case&nbsp;the&nbsp;intervals&nbsp;should&nbsp;be&nbsp;specified.&nbsp; 
<BR><BR>All&nbsp;these&nbsp;aspects&nbsp;are&nbsp;related&nbsp;to&nbsp;the&nbsp;third&nbsp;step.&nbsp;They&nbsp;should&nbsp;be&nbsp;mentioned&nbsp;in&nbsp;the&nbsp; 
<BR>draft.&nbsp; 
<BR><BR>13&nbsp;-&nbsp;Signature&nbsp;validation&nbsp;policies&nbsp;(that&nbsp;are&nbsp;used&nbsp;for&nbsp;non-repudiation&nbsp;purposes)&nbsp; 
<BR>cannot&nbsp;be&nbsp;changed&nbsp;(i.e.&nbsp;redefined),&nbsp;but&nbsp;can&nbsp;only&nbsp;be&nbsp;replaced.&nbsp;This&nbsp;means&nbsp;that&nbsp; 
<BR>updating&nbsp;a&nbsp;TA&nbsp;within&nbsp;a&nbsp;signature&nbsp;validation&nbsp;policy&nbsp;is&nbsp;not&nbsp;allowed.&nbsp;As&nbsp;a&nbsp; 
<BR>consequence,&nbsp;a&nbsp;signature&nbsp;validation&nbsp;policy&nbsp;can&nbsp;only&nbsp;be&nbsp;changed&nbsp;as&nbsp;a&nbsp;whole.&nbsp; 
<BR><BR>On&nbsp;the&nbsp;contrary,&nbsp;TAs&nbsp;contained&nbsp;in&nbsp;other&nbsp;types&nbsp;of&nbsp;validation&nbsp;policies&nbsp;(e.g.&nbsp;used&nbsp; 
<BR>for&nbsp;authentication&nbsp;purposes)&nbsp;may&nbsp;be&nbsp;changed.&nbsp; 
<BR></DIV>
<DIV>==================================================</DIV>
<DIV><BR>See&nbsp;the&nbsp;second&nbsp;message&nbsp;for&nbsp;comments&nbsp;14&nbsp;to&nbsp;28.</DIV></BODY></HTML>

------=_NextPart_08101609553232610604324_002--





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9FHiSqC033391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 10:44:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9FHiSmS033390; Wed, 15 Oct 2008 10:44:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9FHiHWX033372 for <[e-mail]>; Wed, 15 Oct 2008 10:44:27 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 31886 invoked from network); 15 Oct 2008 17:30:41 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;15 Oct 2008 17:30:41 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 15 Oct 2008 17:30:41 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
Date: Wed, 15 Oct 2008 13:44:02 -0400
Message-ID: <[e-mail]>
In-Reply-To: <23DCBBAFAFD0404F9AF1350439C4FF8E@Wylie>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
Thread-Index: Acku4bxkgVg3AzgtQ5iOYr3Gn4/HIgAAe0hwAAJ3xCA=
References: <p0624051ac5098a5a04fd@[128.89.89.71]> <[e-mail]> <C796FE05ECBA48A782064FECF8326CE2@Wylie> <[e-mail]> <23DCBBAFAFD0404F9AF1350439C4FF8E@Wylie>
From: "Santosh Chokhani" <[e-mail]>
To: "Turner, Sean P." <[e-mail]>, "Stephen Farrell" <[e-mail]>
Cc: <[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>

Sean,

Is it worth making the recursive nature of inheritance explicit?=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Turner, Sean P.
Sent: Wednesday, October 15, 2008 12:53 PM
To: 'Stephen Farrell'
Cc: [e-mail]
Subject: RE: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt


>-----Original Message-----
>From: Stephen Farrell [mailto:[e-mail]]=20
>Sent: Wednesday, October 15, 2008 12:17 PM
>To: Turner, Sean P.
>Cc: [e-mail]
>Subject: Re: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>
>
>
>Turner, Sean P. wrote:
>> Stephen,
>>=20
>> Carl and Dave also raised a similar comment, but Russ was concerned=20
>> that people that do DSA already supported inheritance. Can=20
>you live with:
>>=20
>> o implicitCurve allows the elliptic curve parameters to be=20
>inherited.=20
>> This choice MAY be supported.
>
>That's clear enough for me, so long as the behaviour of a=20
>non-supporting RP when faced with a cert using this is clear -=20
>is it? (I can re-read the thing but you probably know already:-)
>
>S.

If I didn't know how DSA inheritance works, then I'd say they weren't
addressed in the ID.  RFC 3279 says they're inherited but leaves it to
the
reader to figure out that it's like DSA.  We should adapt some text from
2.3.2 of RFC 3279 for 2.1.1 of draft-ietf-pkix-ecc-subpubkeyinfo-09 to
fully
explain what we mean by "inherited":

The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
within
a certificate where the domain parameters may be used.  If the ECDSA,
ECMQV,
or ECDH algorithm parameters are omitted from the subjectPublicKeyInfo
AlgorithmIdentifier and the CA signed the subject certificate using
ECDSA,
then the certificate issuer's ECDSA parameters apply to the subject's
ECDSA,
ECMQV, or ECDH key.  If the ECDSA, ECMQV, or ECDH domain parameters are
omitted from the subjectPublicKeyInfo AlgorithmIdentifier and the CA
signed
the subject certificate using a signature algorithm other than ECDSA,
then
the subject's ECDSA, ECMQV, and ECDH domain parameters are distributed
by
other means. If the subjectPublicKeyInfo AlgorithmIdentifier field omits
the
parameters component, the CA signed the subject with a signature
algorithm
other than ECDSA, and the subject's ECDSA, ECMQV, and ECDH parameters
are
not available through other means, then clients MUST reject the
certificate.

spt

>>=20
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Stephen Farrell
>>> Sent: Tuesday, October 07, 2008 10:46 AM
>>> To: [e-mail]
>>> Subject: Re: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>>>
>>>
>>>
>>> The draft says:
>>>
>>>      o implicitCurve allows the elliptic curve parameters to be
>>>        inherited.  This choice MAY be supported, but if subordinate
>>>        certificates use the same namedCurve as their superior, then
>>>        the subordinate certificate MUST use the namedCurve option.
>>>        That is, implicitCurve is only supported if the superior
>>>        doesn't use the namedCurve option.
>>>
>>> "MAY be supported" seems wrong, ought it be "MAY be used"?
>>>
>>> And could we RECOMMEND that it not be used? I find it hard=20
>to see how=20
>>> a programmer can make the right choice, and easy to see that a CA=20
>>> operator could make the wrong choice. And its generally a confusing=20
>>> bit of text.
>>>
>>> Otherwise this seems fine as far as I can tell (which isn't far in=20
>>> the case of EC related stuff:-)
>>>
>>> Stephen.
>>>
>>>
>>>
>>>
>>>
>>> Stephen Kent wrote:
>>>> I have been told that the IEEE 801.1 AR folks are hoping=20
>to refer to=20
>>>> cite draft-ietf-pkix-ecc-subpubkeyinfo as an RFC in their
>>> work, so it
>>>> behooves us to move ahead as soon as possible.  It also=20
>appears that=20
>>>> discussion has settled down on this draft, so I am
>>> initiating WGLC on
>>>> it as well, effective today, and continuing until 10/15.
>>>>
>>>> Thanks,
>>>>
>>>> Steve
>>>>
>>>>
>>=20
>>=20



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9FGra7H027879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 09:53:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9FGraL7027878; Wed, 15 Oct 2008 09:53:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9FGrPDW027845 for <[e-mail]>; Wed, 15 Oct 2008 09:53:35 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 64963 invoked from network); 15 Oct 2008 16:53:24 -0000
Received: from unknown (HELO Wylie) (turners@71.191.14.55 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 15 Oct 2008 16:53:24 -0000
X-YMail-OSG: YrkAXFYVM1lYrFP3TEdQ8WBAWOW4_0IduTIdk1_trO6Fu6GrCpjml1NFKRSWmooamXn6Uxk4dW8eFVWdQCqSkEl18OApy6L4jwSEO_jUBmAZlUPu4dFaMFo85bZI6OhLZjw2Qr571Eu252o5.ERpPoJvUg--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Stephen Farrell'" <[e-mail]>
Cc: <[e-mail]>
References: <p0624051ac5098a5a04fd@[128.89.89.71]> <[e-mail]> <C796FE05ECBA48A782064FECF8326CE2@Wylie> <[e-mail]>
Subject: RE: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
Date: Wed, 15 Oct 2008 12:52:58 -0400
Organization: IECA, Inc.
Message-ID: <23DCBBAFAFD0404F9AF1350439C4FF8E@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: Acku4bxkgVg3AzgtQ5iOYr3Gn4/HIgAAe0hw
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: Stephen Farrell [mailto:[e-mail]] 
>Sent: Wednesday, October 15, 2008 12:17 PM
>To: Turner, Sean P.
>Cc: [e-mail]
>Subject: Re: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>
>
>
>Turner, Sean P. wrote:
>> Stephen,
>> 
>> Carl and Dave also raised a similar comment, but Russ was concerned 
>> that people that do DSA already supported inheritance. Can 
>you live with:
>> 
>> o implicitCurve allows the elliptic curve parameters to be 
>inherited. 
>> This choice MAY be supported.
>
>That's clear enough for me, so long as the behaviour of a 
>non-supporting RP when faced with a cert using this is clear - 
>is it? (I can re-read the thing but you probably know already:-)
>
>S.

If I didn't know how DSA inheritance works, then I'd say they weren't
addressed in the ID.  RFC 3279 says they're inherited but leaves it to the
reader to figure out that it's like DSA.  We should adapt some text from
2.3.2 of RFC 3279 for 2.1.1 of draft-ietf-pkix-ecc-subpubkeyinfo-09 to fully
explain what we mean by "inherited":

The AlgorithmIdentifier within subjectPublicKeyInfo is the only place within
a certificate where the domain parameters may be used.  If the ECDSA, ECMQV,
or ECDH algorithm parameters are omitted from the subjectPublicKeyInfo
AlgorithmIdentifier and the CA signed the subject certificate using ECDSA,
then the certificate issuer's ECDSA parameters apply to the subject's ECDSA,
ECMQV, or ECDH key.  If the ECDSA, ECMQV, or ECDH domain parameters are
omitted from the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed
the subject certificate using a signature algorithm other than ECDSA, then
the subject's ECDSA, ECMQV, and ECDH domain parameters are distributed by
other means. If the subjectPublicKeyInfo AlgorithmIdentifier field omits the
parameters component, the CA signed the subject with a signature algorithm
other than ECDSA, and the subject's ECDSA, ECMQV, and ECDH parameters are
not available through other means, then clients MUST reject the certificate.

spt

>> 
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Stephen Farrell
>>> Sent: Tuesday, October 07, 2008 10:46 AM
>>> To: [e-mail]
>>> Subject: Re: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>>>
>>>
>>>
>>> The draft says:
>>>
>>>      o implicitCurve allows the elliptic curve parameters to be
>>>        inherited.  This choice MAY be supported, but if subordinate
>>>        certificates use the same namedCurve as their superior, then
>>>        the subordinate certificate MUST use the namedCurve option.
>>>        That is, implicitCurve is only supported if the superior
>>>        doesn't use the namedCurve option.
>>>
>>> "MAY be supported" seems wrong, ought it be "MAY be used"?
>>>
>>> And could we RECOMMEND that it not be used? I find it hard 
>to see how 
>>> a programmer can make the right choice, and easy to see that a CA 
>>> operator could make the wrong choice. And its generally a confusing 
>>> bit of text.
>>>
>>> Otherwise this seems fine as far as I can tell (which isn't far in 
>>> the case of EC related stuff:-)
>>>
>>> Stephen.
>>>
>>>
>>>
>>>
>>>
>>> Stephen Kent wrote:
>>>> I have been told that the IEEE 801.1 AR folks are hoping 
>to refer to 
>>>> cite draft-ietf-pkix-ecc-subpubkeyinfo as an RFC in their
>>> work, so it
>>>> behooves us to move ahead as soon as possible.  It also 
>appears that 
>>>> discussion has settled down on this draft, so I am
>>> initiating WGLC on
>>>> it as well, effective today, and continuing until 10/15.
>>>>
>>>> Thanks,
>>>>
>>>> Steve
>>>>
>>>>
>> 
>> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9FGJEoM024285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 09:19:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9FGJEYN024284; Wed, 15 Oct 2008 09:19:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9FGJ2NS024264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 15 Oct 2008 09:19:13 -0700 (MST) (envelope-from [e-mail])
Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id 6C109337CE; Wed, 15 Oct 2008 17:15:41 +0100 (IST)
Received: from [10.87.48.4] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id m9FGFd3F017743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Oct 2008 17:15:40 +0100
Message-ID: <[e-mail]>
Date: Wed, 15 Oct 2008 17:16:35 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: "Turner, Sean P." <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
References: <p0624051ac5098a5a04fd@[128.89.89.71]> <[e-mail]> <C796FE05ECBA48A782064FECF8326CE2@Wylie>
In-Reply-To: <C796FE05ECBA48A782064FECF8326CE2@Wylie>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.00 () [Hold at 8.00] 
X-Canit-Stats-ID: 32992616 - 79db4666e31e (trained as not-spam)
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Turner, Sean P. wrote:
> Stephen,
> 
> Carl and Dave also raised a similar comment, but Russ was concerned that
> people that do DSA already supported inheritance. Can you live with:
> 
> o implicitCurve allows the elliptic curve parameters to be inherited. This
> choice MAY be supported.

That's clear enough for me, so long as the behaviour of a non-supporting
RP when faced with a cert using this is clear - is it? (I can re-read
the thing but you probably know already:-)

S.

> 
> spt
> 
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Stephen Farrell
>> Sent: Tuesday, October 07, 2008 10:46 AM
>> To: [e-mail]
>> Subject: Re: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>>
>>
>>
>> The draft says:
>>
>>      o implicitCurve allows the elliptic curve parameters to be
>>        inherited.  This choice MAY be supported, but if subordinate
>>        certificates use the same namedCurve as their superior, then
>>        the subordinate certificate MUST use the namedCurve option.
>>        That is, implicitCurve is only supported if the superior
>>        doesn't use the namedCurve option.
>>
>> "MAY be supported" seems wrong, ought it be "MAY be used"?
>>
>> And could we RECOMMEND that it not be used? I find it hard to 
>> see how a programmer can make the right choice, and easy to 
>> see that a CA operator could make the wrong choice. And its 
>> generally a confusing bit of text.
>>
>> Otherwise this seems fine as far as I can tell (which isn't 
>> far in the case of EC related stuff:-)
>>
>> Stephen.
>>
>>
>>
>>
>>
>> Stephen Kent wrote:
>>> I have been told that the IEEE 801.1 AR folks are hoping to refer to 
>>> cite draft-ietf-pkix-ecc-subpubkeyinfo as an RFC in their 
>> work, so it 
>>> behooves us to move ahead as soon as possible.  It also appears that 
>>> discussion has settled down on this draft, so I am 
>> initiating WGLC on 
>>> it as well, effective today, and continuing until 10/15.
>>>
>>> Thanks,
>>>
>>> Steve
>>>
>>>
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9FFkwg3021587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 08:46:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9FFkw7v021586; Wed, 15 Oct 2008 08:46:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9FFkk5l021560 for <[e-mail]>; Wed, 15 Oct 2008 08:46:57 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 98908 invoked from network); 15 Oct 2008 15:46:46 -0000
Received: from unknown (HELO Wylie) (turners@71.191.14.55 with login) by smtp101.biz.mail.re2.yahoo.com with SMTP; 15 Oct 2008 15:46:45 -0000
X-YMail-OSG: 0NlF05sVM1kWPU98x78wkoPuQxIMYd0HHssHxmzIAqa4hA3nRj3Ud2945GeDHeX70sOxToPrIODy.kg5jpLpsV8WQ.kOPDM89qUO32.kYtxo3KbjKlOKldS9sEuZTKEAajcyL2o_Y3QGEephwKqmSa6_tON1IU_ugIhmOzCY4TBAMo3Z0gn17ftL0uQyVQ--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Paul Hoffman'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <001301c92331$3ab9baf0$b02d30d0$@com> <[e-mail]> <627A4B89CDE54115ADDCE5121D9F8AE3@Wylie> <p0624081ec509ab4e8609@[10.20.30.152]> <p0624052dc50aa7b6e691@[128.89.89.71]> <p06240841c50ae3cf2671@[10.20.30.152]> <p06240540c50aeb6ac4a4@[128.89.89.71]> <p0624084ec50afcb5fc6d@[10.20.30.152]>
Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
Date: Wed, 15 Oct 2008 11:46:19 -0400
Organization: IECA, Inc.
Message-ID: <ECF87E2058E54DE39E2D4D865C1DA6DA@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: Ackk46+ooh6UKA1pQ3KA5EAefeLyrAJ+Qe9g
In-Reply-To: <p0624084ec50afcb5fc6d@[10.20.30.152]>
Sender: [e-mail]
Precedence: 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 Paul Hoffman
>Sent: Thursday, October 02, 2008 6:39 PM
>To: Stephen Kent
>Cc: [e-mail]
>Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
>
>
>At 5:33 PM -0400 10/2/08, Stephen Kent wrote:
>>At 1:50 PM -0700 10/2/08, Paul Hoffman wrote:
>>>At 12:35 PM -0400 10/2/08, Stephen Kent wrote:
>>>>I agree that the wording might be improved, but I do think 
>that PKIX is a special case vs. most of the crypto-related 
>RFCs in the security area.  The reason is that we don't define 
>specific algorithm suites as do IPsec, TLS, SMIME, SSH, etc. 
>Since we don't specify default or preferred algorithms, our 
>standards that do mention specific algorithms are more 
>susceptible to misinterpretation by readers unfamiliar with 
>that aspect of PKIX standards.
>>>
>>>We have not seen that someone reading RFC 3279 would tend to 
>think that the IETF is suggesting that all of its algorithms 
>are equally strong or useful. In fact, we have seen the 
>opposite. I do not think that this document will be any different.
>>
>>Paul,
>>
>>I've become confused about the essential disagreement at this 
>stage :-).
>>
>>RFC 3279 has clear language that says that MD2 is 
>problematic, and that MD5 is of concern as well. So, relative 
>to the discussion I thought we were having, it seems to have 
>appropriate language.
>
>Sure, "appropriate language" might be good to steer people 
>away from MD2 and MD5. But what Sean proposed is not similar 
>at all to what is in RFC 3279 about MD2 and MD5.
>
>At 5:29 PM -0400 10/1/08, Turner, Sean P. wrote:
>>Cryptographic algorithms will be broken or weakened over time.  
>>Implementers and users need to check that the cryptographic 
>algorithms 
>>listed in this document continue to provide the expected level of 
>>security.  For example, some consider MD2 and MD5 weak cryptographic 
>>algorithms due to collisions [RC95] and [YU05], repsectively.
>
>In this case, MD2 and MD5 are *examples* of algorithms that 
>have weakened over time. Further, there is nothing like his 
>first two sentences in the Security Considerations of RFC 
>3279. Telling people that they need to check that algorithms 
>are still good, without saying what to check or when, is not 
>of any value.
>
>>Perhaps a better way to address this issue is not to include 
>text about the fact that, over time, the perceived strength of 
>algorithms may change. Instead, we should note that the fact 
>that a document includes OIDs for algorithms does not imply 
>endorsement of the strength of the algorithms, and when 
>appropriate, we can note specific algorithms that, at the time 
>of publication, are of concern but are nonetheless included 
>for completeness.
>
>That would work for me. We could simply re-use the actual 
>words from RFC 3279:
>   The use of MD5
>   for new applications is discouraged.  It is still reasonable to use
>   MD5 to verify existing signatures.
>
>--Paul Hoffman, Director
>--VPN Consortium

Paul/Steve,

We already reference the security considerations in RFC 3279, but I'll also
add the following to the ietf-pkix-ecc-subpubkeyinfo-09 security
considerations:

As noted in [PKI-ALG], the use of MD2 and MD5 for new applications is
discouraged.  It is still reasonable to use MD2 and MD5 to verify existing
signatures.

spt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9FFhbsS021350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 08:43:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9FFhbRp021349; Wed, 15 Oct 2008 08:43:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9FFhPPr021332 for <[e-mail]>; Wed, 15 Oct 2008 08:43:36 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 44338 invoked from network); 15 Oct 2008 15:43:25 -0000
Received: from unknown (HELO Wylie) (turners@71.191.14.55 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 15 Oct 2008 15:43:24 -0000
X-YMail-OSG: odk0MScVM1nCxLHVh7.xwYlEC8r0czsUCDnapZiMHeVFh7ZNNjpFlGWI80MuS4DrX9LPXZ__qx7fUIobm2U_6FH8t7jQu2yHvNVWWx4tUtBTa_8jGTJTOj5Y4tXMIJFLGWJZTS.gBREcITgoZkF9gnUi5JzPWdIIUnKkvcyjFUaBtoasf9GAK63ZPnMOcQ--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Stephen Farrell'" <[e-mail]>, <[e-mail]>
References: <p0624051ac5098a5a04fd@[128.89.89.71]> <[e-mail]>
Subject: RE: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
Date: Wed, 15 Oct 2008 11:42:58 -0400
Organization: IECA, Inc.
Message-ID: <C796FE05ECBA48A782064FECF8326CE2@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: Ackoj6dbQFk6wvvnQcydMlTkjXzHMgGTMg+Q
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>

Stephen,

Carl and Dave also raised a similar comment, but Russ was concerned that
people that do DSA already supported inheritance. Can you live with:

o implicitCurve allows the elliptic curve parameters to be inherited. This
choice MAY be supported.

spt

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Stephen Farrell
>Sent: Tuesday, October 07, 2008 10:46 AM
>To: [e-mail]
>Subject: Re: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
>
>
>
>The draft says:
>
>      o implicitCurve allows the elliptic curve parameters to be
>        inherited.  This choice MAY be supported, but if subordinate
>        certificates use the same namedCurve as their superior, then
>        the subordinate certificate MUST use the namedCurve option.
>        That is, implicitCurve is only supported if the superior
>        doesn't use the namedCurve option.
>
>"MAY be supported" seems wrong, ought it be "MAY be used"?
>
>And could we RECOMMEND that it not be used? I find it hard to 
>see how a programmer can make the right choice, and easy to 
>see that a CA operator could make the wrong choice. And its 
>generally a confusing bit of text.
>
>Otherwise this seems fine as far as I can tell (which isn't 
>far in the case of EC related stuff:-)
>
>Stephen.
>
>
>
>
>
>Stephen Kent wrote:
>> 
>> I have been told that the IEEE 801.1 AR folks are hoping to refer to 
>> cite draft-ietf-pkix-ecc-subpubkeyinfo as an RFC in their 
>work, so it 
>> behooves us to move ahead as soon as possible.  It also appears that 
>> discussion has settled down on this draft, so I am 
>initiating WGLC on 
>> it as well, effective today, and continuing until 10/15.
>> 
>> Thanks,
>> 
>> Steve
>> 
>> 
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9F7Jdpb075871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 00:19:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9F7JdYo075870; Wed, 15 Oct 2008 00:19:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9F7JRtF075856 for <[e-mail]>; Wed, 15 Oct 2008 00:19:38 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 48A144C50113C32C; Wed, 15 Oct 2008 09:19:25 +0200
Message-ID: <D9DD17B00BDC4EEDA82697121FFEB87C@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Julien Stern" <[e-mail]>, <[e-mail]>
References: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC> <[e-mail]> <6FC4E24D42684B0BAC968790E5600182@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
Date: Wed, 15 Oct 2008 09:19:32 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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,
Thank you for the response.

I guess that I get about the same "vibes" as when I hear people
claiming that S/MIME is a perfect security solution.
IMHO the Internet would had been a much better place if e-mail
security had been placed at the server/domain level and left
S/MIME to exceptional cases.  Yes, there is STARTTLS but
how do I know if a message is actually using that?

That is, setting the security bar too high may sometimes generate
the opposite result; no security.  In the actual use-case, I'm mainly
worried about interoperability and complexity which could kill the
whole idea.

Based on current input, I will probably keep the door open to both
solutions and let the "market" decide.

Anders

----- Original Message ----- 
From: "Julien Stern" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, October 14, 2008 18:15
Subject: Re: Signing and Encrypting with the same key?



Anders Rundgren wrote:
> Dave,
> 
> I'm fully aware of the different operational requirements on
> signing and encryption keys for *users*.  It is rather the
> following I would like to get an explanation to if there is one:
> http://www.imc.org/ietf-pkix/mail-archive/msg04750.html
> 
> Anders

Anders,

To the question: "can I use the same key to sign and encrypt with PKCS#1" ?

one can take two different standpoint:

1. "Yes, if there is no known attack"
2. "No, unless I can demonstrate this does not weaken the schemes"

As far as I remember, there are no known attacks, but there aren't any 
proofs that it does not weaken security (actually, I believe someone 
published a paper with some hints that there may be a theoretical 
weakness, but that was really long time ago, maybe someone else would know).

At any rate, it is really a matter of perspective, standpoint 1) being 
somewhat pragmatic, and standpoint 2) begin conservative.

Considering there have mean many publications on either real 
cryptanalysis or simply weaknesses on various RSA paddings, (I'm pretty 
sure one was published at Eurocrypt 2000, among others), I, for one, 
would not recommend signing and encrypting with the same key with 
RSA-PKCS#1.5. I believe that signing with PSS and encrypting with OAEP 
with the same key can be shown to be _considerably_ more secure. Now, is 
it a matter of risk evaluation...

Regards,

--
Julien



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EGGKKF011056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 09:16:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9EGGKUO011055; Tue, 14 Oct 2008 09:16:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from maiev.nerim.net (smtp-116-tuesday.nerim.net [62.4.16.116]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EGG9ms011039 for <[e-mail]>; Tue, 14 Oct 2008 09:16:20 -0700 (MST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by maiev.nerim.net (Postfix) with ESMTP id 35A57B93BC for <[e-mail]>; Tue, 14 Oct 2008 18:16:06 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 08B0F44104 for <[e-mail]>; Tue, 14 Oct 2008 18:16:06 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at cryptolog.com
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fsy0wR8XFL3Y for <[e-mail]>; Tue, 14 Oct 2008 18:15:58 +0200 (CEST)
Received: from [10.0.1.30] (leda.cry.pto [10.0.1.30]) by uranus.cry.pto (Postfix) with ESMTP id 4184C440ED for <[e-mail]>; Tue, 14 Oct 2008 18:15:58 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 14 Oct 2008 18:15:58 +0200
From: Julien Stern <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Signing and Encrypting with the same key?
References: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC> <[e-mail]> <6FC4E24D42684B0BAC968790E5600182@AndersPC>
In-Reply-To: <6FC4E24D42684B0BAC968790E5600182@AndersPC>
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>

Anders Rundgren wrote:
> Dave,
> 
> I'm fully aware of the different operational requirements on
> signing and encryption keys for *users*.  It is rather the
> following I would like to get an explanation to if there is one:
> http://www.imc.org/ietf-pkix/mail-archive/msg04750.html
> 
> Anders

Anders,

To the question: "can I use the same key to sign and encrypt with PKCS#1" ?

one can take two different standpoint:

1. "Yes, if there is no known attack"
2. "No, unless I can demonstrate this does not weaken the schemes"

As far as I remember, there are no known attacks, but there aren't any 
proofs that it does not weaken security (actually, I believe someone 
published a paper with some hints that there may be a theoretical 
weakness, but that was really long time ago, maybe someone else would know).

At any rate, it is really a matter of perspective, standpoint 1) being 
somewhat pragmatic, and standpoint 2) begin conservative.

Considering there have mean many publications on either real 
cryptanalysis or simply weaknesses on various RSA paddings, (I'm pretty 
sure one was published at Eurocrypt 2000, among others), I, for one, 
would not recommend signing and encrypting with the same key with 
RSA-PKCS#1.5. I believe that signing with PSS and encrypting with OAEP 
with the same key can be shown to be _considerably_ more secure. Now, is 
it a matter of risk evaluation...

Regards,

--
Julien



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EEvVHj004414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 07:57:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9EEvVDO004412; Tue, 14 Oct 2008 07:57:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EEvK0G004366 for <[e-mail]>; Tue, 14 Oct 2008 07:57:31 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout1-sn1.fre.skanova.net (7.3.129) id 47A97950043349E4; Tue, 14 Oct 2008 16:57:14 +0200
Message-ID: <6FC4E24D42684B0BAC968790E5600182@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Kemp, David P." <[e-mail]>, <[e-mail]>
References: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
Date: Tue, 14 Oct 2008 16:57:19 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,

I'm fully aware of the different operational requirements on
signing and encryption keys for *users*.  It is rather the
following I would like to get an explanation to if there is one:
http://www.imc.org/ietf-pkix/mail-archive/msg04750.html

Anders

----- Original Message ----- 
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, October 14, 2008 15:09
Subject: RE: Signing and Encrypting with the same key?




The premise is false.  The reason is not that a private key might be
exposed through cryptanalysis, but that the purposes of signing (data
integrity "broadcast" to anyone who chooses to validate the signature)
and encryption (confidentiality among selected recipients) are
different, leading to different operational requirements for handling
private keys.  There is never a reason to expose a signature private
key, and benefits from not doing so.  There are reasons for sharing and
archiving encryption private keys.  A single key for both functions is a
"jack of all trades, master of none".

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Anders Rundgren
Sent: Saturday, October 11, 2008 2:24 PM
To: [e-mail]
Subject: Signing and Encrypting with the same key?


According to many cryptographers you shouldn't sign and encrypt with
the same RSA key-pair.  The reason appears to be that this could lead
to exposure of the private key.  Now to the question.

If the above is true, what stops a recipient of a signature (and thus
the
signature public key), to perform any number of encryptions with it in
order to reveal the associated private key?

Has the attack been proved in practice?

The reason for asking is because I'm working with a scheme where
cryptographic containers are equipped with device-keys and certificates
that are used for device authentication, key attestations, and
encryption
(for secret data imports).

Although the containers without doubt can deal with multiple keys,
multiple keys could give containers "split personas" unless you manage
to specify the associated PKI in a very detailed way, something
which has proven to be hard when there is no uniting identity concept
like in e-mail certificates.

Regards
Anders Rundgren
WebPKI.org



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EDAJaN092956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 06:10:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9EDAJ3p092955; Tue, 14 Oct 2008 06:10:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EDA8HI092922 for <[e-mail]>; Tue, 14 Oct 2008 06:10:18 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id m9EDA764029416 for <[e-mail]>; Tue, 14 Oct 2008 09:10:08 -0400 (EDT)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 09:08:31 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Signing and Encrypting with the same key?
Date: Tue, 14 Oct 2008 09:09:56 -0400
Message-ID: <[e-mail]>
In-Reply-To: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Signing and Encrypting with the same key?
Thread-Index: Ackr1lI6Ku3ylvKGTHC6Oemfo+UgDwCJlbYg
References: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 14 Oct 2008 13:08:31.0968 (UTC) FILETIME=[F5266600:01C92DFD]
Sender: [e-mail]
Precedence: 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 premise is false.  The reason is not that a private key might be
exposed through cryptanalysis, but that the purposes of signing (data
integrity "broadcast" to anyone who chooses to validate the signature)
and encryption (confidentiality among selected recipients) are
different, leading to different operational requirements for handling
private keys.  There is never a reason to expose a signature private
key, and benefits from not doing so.  There are reasons for sharing and
archiving encryption private keys.  A single key for both functions is a
"jack of all trades, master of none".

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Anders Rundgren
Sent: Saturday, October 11, 2008 2:24 PM
To: [e-mail]
Subject: Signing and Encrypting with the same key?


According to many cryptographers you shouldn't sign and encrypt with
the same RSA key-pair.  The reason appears to be that this could lead
to exposure of the private key.  Now to the question.

If the above is true, what stops a recipient of a signature (and thus
the
signature public key), to perform any number of encryptions with it in
order to reveal the associated private key?

Has the attack been proved in practice?

The reason for asking is because I'm working with a scheme where
cryptographic containers are equipped with device-keys and certificates
that are used for device authentication, key attestations, and
encryption
(for secret data imports).

Although the containers without doubt can deal with multiple keys,
multiple keys could give containers "split personas" unless you manage
to specify the associated PKI in a very detailed way, something
which has proven to be hard when there is no uniting identity concept
like in e-mail certificates.

Regards
Anders Rundgren
WebPKI.org



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9ECx9vM091877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 05:59:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9ECx97I091876; Tue, 14 Oct 2008 05:59:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9ECwvDR091861 for <[e-mail]>; Tue, 14 Oct 2008 05:59:08 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 32347 invoked from network); 14 Oct 2008 12:58:57 -0000
Received: from unknown (HELO Wylie) (turners@71.191.14.55 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 14 Oct 2008 12:58:56 -0000
X-YMail-OSG: 6jH76wcVM1njNJqsaEPFztL8keqS8gqnHA1Pk.2HjKFiyHko94g5BwEEgEIpHYHfbX.Q.ncztFV0zT.tigPzTnf2Ip5_q.6irilw5164lMYaTIAN3GMpExJbm5YPB23AdeQ0TqCjE5rU6AqpuxZ.kVLRCy3vegDMv7HrceZR9h1hGSYoAqd4ZHqSFNCbKQ--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Timothy J. Miller'" <[e-mail]>, "'Carl Wallace'" <[e-mail]>
Cc: <[e-mail]>
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Tue, 14 Oct 2008 08:58:36 -0400
Organization: IECA, Inc.
Message-ID: <D1165D0004A74F2EB89FD9FFC0606D31@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AcktPo1xbBGJg+IZTZOD+0tgp11GwAAAKwnQAC8iOcA=
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 just wanted to add that the ID does not address relationships between
security policies.  It only addresses whether the EE's asserted clearance is
within the issuer's allowed clearance set.

spt

-----Original Message-----
From: [e-mail] 
[mailto:[e-mail]] On Behalf Of Santosh Chokhani
Sent: Monday, October 13, 2008 10:33 AM
To: Timothy J. Miller; Carl Wallace
Cc: [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt


Differences in various policies are articulated using the 
security policy OID in the clearance structure that has been 
accepted by the Internet Standards Community.

In addition, clearance is a well defined mathematical concept 
and formalized using lattice structure.  Within a security 
policy, Clearance consists of a hierarchical sensitivity level 
and non-hierarchical category set.  Two clearances within a 
security can be ordered or can be incomparable based on simple 
and well-defines mathematical rules.

People in other parts of IETF are using these concepts to label 
the data and make information flow decisions.

Some pioneering work has been done in the technical community 
(albeit not exposed to the IETF) in the area of comparing 
clearances of two security policies.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Timothy J. Miller
Sent: Monday, October 13, 2008 10:03 AM
To: Carl Wallace
Cc: [e-mail]
Subject: Re: draft-turner-caclearanceconstraints-01.txt

Carl Wallace wrote:
> I vote yes to adopting this as a PKIX work item.  Specification
details 
> can be resolved after the draft is accepted as a working group draft.

Can we even say for certain that clearance is a consistent 
enough concept within and across jurisdictions to enable a 
single logic for constraint processing?  I'd argue not.

E.g., RFC3281 talks about "the" basic clearance hierarchy, which doesn't

even exist.  What's the relationship between NATO CONFIDENTIAL 
and US UNCLASSIFIED CONTROLLED INFORMATION?  How about US UCI 
and US FOR OFFICIAL USE ONLY?  US SECRET/NOFOREIGN?  US TS/SCI 
and TS/SAP?  And that's without even getting into the obscure 
corners of the US alone.

What I'm trying to say is that classification is *not* a strict 
hierarchy.  It's semi-structured.  We have trouble enough 
figuring this stuff out in the real world without having to 
write code for it.  :)

Presuming I have a vote, I vote no.

-- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DGY2pf016379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 09:34:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DGY2Ja016378; Mon, 13 Oct 2008 09:34:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DGXpNw016353 for <[e-mail]>; Mon, 13 Oct 2008 09:34:02 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KpQMg-0005nv-D2; Mon, 13 Oct 2008 12:33:50 -0400
Mime-Version: 1.0
Message-Id: <p06240513c51921f728eb@[128.89.89.71]>
In-Reply-To: <[e-mail]>
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail] osoft.com> <[e-mail]> <[e-mail]>
Date: Mon, 13 Oct 2008 12:12:19 -0400
To: "Timothy J. Miller" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: What are certificates fundamentally all about?  [was: draft-turner-caclearanceconstraints-01.txt]
Cc: <[e-mail]>, "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:40 AM -0500 10/13/08, Timothy J. Miller wrote:
>Stephen Wilson wrote:
>
>>Then you can subtly adjust the conception of a PKC as being "an 
>>assertion of an entity's key and a RELATIVELY STATIC identity IN A 
>>DEFINED CONTEXT".  A flexible interpretation of "identity in a 
>>defined context" embraces things like my identity as an chartered 
>>engineer, my identity as a business owner, my identity as a health 
>>insurance subscriber, my identity as a bank account holder.  In 
>>each of these scenarios, it would be very powerful for me to carry 
>>a separate dedicated certificate with which to sign specific types 
>>of transactions (e.g. engineering test reports, tax returns, health 
>>insurance claims, and payment instructions respectively).  That is, 
>>four different certificates all independently registered and 
>>managed, tightly coupled to regular customer relationship 
>>management processes, probably carried on separate smartcards.
>
>We have that; it's called SPKI/SDSI.  :)

No, it's called not VeriSign :-).

I authored a paper in 1997 that made the same argument as Stephen 
Wilson did (maybe it's a Stephen thing). Moreover, there is a report 
published in 2003 by the National Academies Press ("Who Goes There? 
Authentication Through the Lens of Privacy?") that also observes that 
an individual does not have just one identity, and thus we ought not 
assume that a single cert will suffice to identify/authorize an 
individual.


Moreover, arguments that clearances are not sufficiently long-lived 
to be put into certs do not match lots of experience.  Basic 
clearance info (vs. compartments) tends to be very stable, for 
multiple years, in the the U.S. DoD.  They have issued certs 
containing clearance info for a while, and not found that clearance 
changes create undue CRL activity. They have issued certs with more 
than just basic clearance info, e.g., to secure phones and data 
encryption devices, and those too have proved to be long-lived. So we 
ought not waste time debating this aspect of the proposal, because 
there is enough experience to resolve these specific arguments.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DGKlJL014969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 09:20:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DGKlSk014968; Mon, 13 Oct 2008 09:20:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp152.sat.emailsrvr.com (smtp152.sat.emailsrvr.com [66.216.121.152]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DGKaeh014943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 13 Oct 2008 09:20:47 -0700 (MST) (envelope-from [e-mail])
Received: from relay5.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 7613B263AB6 for <[e-mail]>; Mon, 13 Oct 2008 12:20:35 -0400 (EDT)
Received: by relay5.relay.sat.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTP id B7E3C263B30 for <[e-mail]>; Mon, 13 Oct 2008 12:20:34 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 14 Oct 2008 03:19:04 +1100
From: Stephen Wilson <[e-mail]>
Reply-To: [e-mail]
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: What are certificates fundamentally all about?  [was: draft-turner-caclearanceconstraints-01.txt]
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Timothy J. Miller wrote:
> Stephen Wilson wrote:
> 
>> Then you can subtly adjust the conception of a PKC as being "an 
>> assertion of an entity’s key and a RELATIVELY STATIC identity IN A 
>> DEFINED CONTEXT".  A flexible interpretation of "identity in a defined 
>> context" embraces things like my identity as an chartered engineer, my 
>> identity as a business owner, my identity as a health insurance 
>> subscriber, my identity as a bank account holder.  In each of these 
>> scenarios, it would be very powerful for me to carry a separate 
>> dedicated certificate with which to sign specific types of 
>> transactions (e.g. engineering test reports, tax returns, health 
>> insurance claims, and payment instructions respectively).  That is, 
>> four different certificates all independently registered and managed, 
>> tightly coupled to regular customer relationship management processes, 
>> probably carried on separate smartcards.
> 
> We have that; it's called SPKI/SDSI.  :)

Not too sure if your smiley was a 'knowing' cheeky smiley?!  In "Public 
Key Superstructure" I address SPKI and argue that it's not really simple 
enough.  I believe SPKI retains at its core the orthodox misconception 
that authentication and authorisation should be constructed on the back 
of a single superior identification.

>> To illustrate the point, I don't actually see any reason in principle 
>> why a PKC could not be used to assert my identity (or relationship) as 
>> 'a person cleared to Top Secret' so long as that relationship is 
>> relatively long lived; say a few months.  Path validation is a cinch: 
>> the relationship I would have express in my PKC is with a particular 
>> vetting agency, which would appear in the path, with a Policy OID in 
>> the Subject PKC that specifies the clearance protocol.  The Public Key 
>> of the vetting agency -- or a higher Root Key -- would be the trust 
>> anchor needed in a whole class of applications processing my digital 
>> signature applied to Secret documents.
> 
> However, that's a *lot* of work, infrastructure, and code needed to 
> communicate an attribute the relying party can more simply look up in a 
> directory at the time of the transaction, or that the relying party can 
> have communicated to it as part of an authorization token (InfoCard, 
> OpenID, SAML, WS-*, etc.).
> 
> These schemes have the advantage of accommodating both static, 
> relatively static, and highly dynamic attributes, *plus* supports 
> non-person attributes such as environment level, current threat posture, 
> etc.
> 
> In short, you have to have the directory anyway for at least some 
> attributes, so it's simpler in the long run to stuff *all* the 
> attributes in there.

The directory is fine if the transactions are only ever processed in 
real time -- that is, you're never interested in checking an old 
signature on a transaction from months or years ago.  In that sort of 
case, what method exists for freezing the state of an attribute-rich 
directory for all time, so that all conceivable relying parties can at 
any time down the track look up the attribute of interest for all senders?

The very cool and unique thing about PKCs when attributes are in the 
certificate is that they bake the attributes into each transaction, such 
that you only need a CRL [or delta CRLs] to check a transaction, no 
matter how old it is.  Even long after all PKCs have expired.

This longevity is not important for all transaction settings, so I agree 
that the attribute-rich directory is sometimes a better fit.  But in 
e-health, digital mortgages, electronic trade documentation, pension 
funds management, insurance and similar fields, you cannot beat 
PKCs-with-included-attributes for elegance and efficient processing.

Cheers,

Stephen Wilson
Lockstep.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DEph6f003729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 07:51:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DEphdK003728; Mon, 13 Oct 2008 07:51:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DEpg0X003720 for <[e-mail]>; Mon, 13 Oct 2008 07:51:43 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA950176818E; Mon, 13 Oct 2008 16:51:41 +0200
Message-ID: <7F3D4C9B947348B08F78747626837135@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>
Cc: <[e-mail]>
References: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC> <p06240836c516c6e25589@[10.20.30.152]> <DDE506CF856141B5AB30E0B7392107B7@AndersPC> <[e-mail]> <EBB2CF25807C427EBB10544E25B5095C@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
Date: Mon, 13 Oct 2008 16:51:45 +0200
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01DF_01C92D53.FA2A4720"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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_01DF_01C92D53.FA2A4720
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>> Key life-cycle considerations do not apply to device keys;
>> they are assumed to outlive the device itself and even if they
>> were renewed, encryption and signing keys would be updated
>> in parallel since encryption is only used for on-line secret/private
>> key data import which is very different to for example e-mail.

>This assumption is highly dependent on the environment and device.  In 
>DoD's nascent non-person entity PKI plans, we expect the device to 
>outlive the key crpytoperiod by a factor of about 2 for most classes of 
>NPEs.  However, some classes--e.g., sensors--won't.

Tim,

I was rather referring to this with respect to signing keys versus encryption
keys that have other tasks in devices than in person PKIs.   Regarding to
the DoD non-person PKI plan, you probably refer to DoD-issued router
certificates and similar?

This is not exactly the same thing I'm plotting with since crypto device keys
are primarily intended for "bootstrapping" secondary credentials like a DoD PKI.
If crypto device keys can be updated is essentially up to the device vendor since
these are the only legitimate issuers of such keys.

Anders

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtzCCAuAw
ggHIoAMCAQICBgEXhqdhgDANBgkqhkiG9w0BAQUFADBDMRMwEQYKCZImiZPyLGQBGRMDb3JnMRYw
FAYKCZImiZPyLGQBGRMGd2VicGtpMRQwEgYDVQQDEwtEZW1vIFN1YiBDQTAeFw0wNTAzMTAxMDAw
MDBaFw0xMDAzMTAwOTU5NTlaMEQxKDAmBgkqhkiG9w0BCQEWGWFuZGVycy5ydW5kZ3JlbkB0ZWxp
YS5jb20xGDAWBgNVBAMTD0FuZGVycyBSdW5kZ3JlbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAyrl1AN0L4UJDkniJ8y5afQS6wudAzgvYtuIF5X17fMyKzYNW3knnTkrzRPJut1vWBZrOPy87
EUS+m+PT0NT2HU9KDEQptKXm2j5YbWqMrfw7P3lprqpWRVPs6Q5hmku/DKeCbsZPBxXRpbpspY4T
ZMyk4/3H9s9927rD4zWTJ4MCAwEAAaNdMFswCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCA/gwHQYD
VR0OBBYEFJ5U3M59I6Fp3vhHCYWvCN59k+JjMB8GA1UdIwQYMBaAFAB+ndNMaNm62/nyg9gNXXgr
7WEtMA0GCSqGSIb3DQEBBQUAA4IBAQB2y4W48jQZQPBhHh3Ps4Vv+OopU4Xy8gJC2lN1JrMZUfGc
RpWBa2aLSvchxtK0xtGilIqo4Em0obImkzER9fqUc3+su2WROVnIXH0Gr1DIufr34ddChW4/DYXw
8MG09ifDxLfW/45OhK2whlHCP1irf8/Tsf0U00mu5Ntb/t7WNh8+fiGAR3NOaJMwKr+bA7CLpqb6
LRue8SSZHgPcifPE94d5rTtm/iiLB1NP3GhBN6WWHSeLRHpoSMS7HstwYcUYaypHIN00Ca2fKmqL
DDsjgEtVY7w13J0ATH1UysZAw81QoN1QCgpm188Z0tQrGBdPj0hO8aM2mzRbMhPsQm1iMIIDZTCC
Ak2gAwIBAgIBAjANBgkqhkiG9w0BAQUFADBEMRMwEQYKCZImiZPyLGQBGRMDb3JnMRYwFAYKCZIm
iZPyLGQBGRMGd2VicGtpMRUwEwYDVQQDEwxEZW1vIFJvb3QgQ0EwHhcNMDIwNzEwMTAwMDAwWhcN
MjAwNzEwMDk1OTU5WjBDMRMwEQYKCZImiZPyLGQBGRMDb3JnMRYwFAYKCZImiZPyLGQBGRMGd2Vi
cGtpMRQwEgYDVQQDEwtEZW1vIFN1YiBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJ1Pc3sRfo5oB9lFD2jfRqF+BDXAOsAjVORx2Z87fLg/ZE/H8+Tqbr7gVO4TF88O5h6FV+QyBXNZ
i4lhg/R54UAk1xshXI5SidwGkacMCdZ07wTJA/nrUzOAscDtagSusqSxRC68HzE+X4j92Z8cwB5G
8Vda0OpmkPkrWUrqqPLWD0SiXUPUPFD//DI3SuXovLnu5AnUtK88euxDUQEoymr6lUxFcFO/AA0Z
ASPhrJ2UnQjSvueFEbm5k2ilzNmB2JNAU79l/bbQV1vqIxgc+MED5HDvb9p9n8V45Jxzbbms9TzM
J/os3dB6JlTmntIleGlsUCTGOJP37+cVDSDBNIMCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFAB+ndNMaNm62/nyg9gNXXgr7WEtMB8GA1UdIwQYMBaA
FF6K3Zbqk5HHum/1CxapGk40h8S3MA0GCSqGSIb3DQEBBQUAA4IBAQBq6Sp1xY8KyaW1VBb8Kiw6
o4bmbldKgQHGGk2Ws9+ZmIT9yiDg71+h/lO0BdvwDuzumskQqKdeWmWZAkiAP/6/3OSOl2C6Pgo6
KAwfu+mf0uqU5wv8Dkd5+6QOHACOfQtDWvmhD+ceE/cqWWve+dX/VDsTMH1D6NWQRN5QPHAjwoyY
Brdhln3bPt6YC77jOO0C0TlsoS/d0CQpCcFQrH8/6v5g34Idz8O1lRTUmCzqP2iSgzzmyJ/pnDpB
DL0ohbyyba2R13hcBhJvUYLka4mQaT/sFNg0VEZOq0UQfcoTywnwtmp4FgyGMC0KZcfh05Xfk8V1
EccGAKrZV5SHDz3UMIIDZjCCAk6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBEMRMwEQYKCZImiZPy
LGQBGRMDb3JnMRYwFAYKCZImiZPyLGQBGRMGd2VicGtpMRUwEwYDVQQDEwxEZW1vIFJvb3QgQ0Ew
HhcNMDIwNzEwMTAwMDAwWhcNMjAwNzEwMDk1OTU5WjBEMRMwEQYKCZImiZPyLGQBGRMDb3JnMRYw
FAYKCZImiZPyLGQBGRMGd2VicGtpMRUwEwYDVQQDEwxEZW1vIFJvb3QgQ0EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCB9OnUr3WJOk4wmtUPc6pkx65XFTKQPjQFXCjj8nyFzayIYEBo
7ixJYuAKtSsWc1DCEaFWXDetBe+50ayPeeF6vQx13at5h+WVyDVrDayhbNxvUiDn++dVpf9fcuIr
4RWVa9D6/RzBxN2PV0EuGyGl9gdD4LHQnLYeqeGGnIkDtBVpPrFWkzRjvsGKASLFT8zoSWV1nDNF
n8Hbl6WvuxIR4mwHsmMsx0LuBBEYUA9qykaE0eHG7X+U2hCGAyre85tiNE/G+tElgcVvhZLryCwr
i4YJE/xMB7XsdIENyfWyM7kAjrABlEtJm/nU8Ya9RfSltRPvT+L5w8oRWokyW9TdAgMBAAGjYzBh
MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBReit2W6pORx7pv9QsW
qRpONIfEtzAfBgNVHSMEGDAWgBReit2W6pORx7pv9QsWqRpONIfEtzANBgkqhkiG9w0BAQUFAAOC
AQEATPi7fR4d/lQiQ3WKAC1tBBuv8BBc26HEpRkxuCyyz/rZ7iIyxJ7L1BNkNPqPjGNBLUmd2e+K
8ULjBpfmNzuWCpDqqkENx6XYpUDbPfiin1DEyVDAV2LA6ghuVQ2pAVALrIyKiUyvVpNsWedmma+e
TWUEkqdIKSNiDNNcLA2dl472zd+pGrQ1KAYWG4fY/LviKEFFH4qtlaiMdQnV34hBay1aRozRWX9w
ig6Zwj8PQ9trJtvfWQZ4leVeTWCNttNYWFqmrZpXiOTUJdE6rO7O7lgzs+7F2xfews9ApOFNuVo3
3rVnQvE6kJxvdiPNIlcGnauOs8rI3fkaO8PtUgHnUzGCAbAwggGsAgEBME0wQzETMBEGCgmSJomT
8ixkARkTA29yZzEWMBQGCgmSJomT8ixkARkTBndlYnBraTEUMBIGA1UEAxMLRGVtbyBTdWIgQ0EC
BgEXhqdhgDAJBgUrDgMCGgUAoIG6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTA4MTAxMzE0NTE0NVowIwYJKoZIhvcNAQkEMRYEFPGloaHyWy5AWAin+9XavyIPNTYM
MFsGCSqGSIb3DQEJDzFOMEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIdMA0GCSqGSIb3DQEBAQUABIGAgozR
ZykuJenuP76XuEllKdiKtJNdSuS/vUaRju93xSKVVvrp0FxygQgZFYYN6YdKbm9yZnoyp1BuF4ke
dVq5hQsjhVX1QG2iLPMBc+DrpDNVbDkuGrwXeC+FzPU7eOICqiKiwYtI1NJqrzF31KVhk5iMQNHy
gwJ7hV0mIjnZ4skAAAAAAAA=

------=_NextPart_000_01DF_01C92D53.FA2A4720--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DEWi8a002308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 07:32:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DEWix3002307; Mon, 13 Oct 2008 07:32:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9DEWhK4002301 for <[e-mail]>; Mon, 13 Oct 2008 07:32:43 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 6060 invoked from network); 13 Oct 2008 14:19:24 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Oct 2008 14:19:24 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Oct 2008 14:19:23 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Mon, 13 Oct 2008 10:32:41 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: AcktPo1xbBGJg+IZTZOD+0tgp11GwAAAKwnQ
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>, "Carl Wallace" <[e-mail]>
Cc: <[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>

Differences in various policies are articulated using the security
policy OID in the clearance structure that has been accepted by the
Internet Standards Community.

In addition, clearance is a well defined mathematical concept and
formalized using lattice structure.  Within a security policy, Clearance
consists of a hierarchical sensitivity level and non-hierarchical
category set.  Two clearances within a security can be ordered or can be
incomparable based on simple and well-defines mathematical rules.

People in other parts of IETF are using these concepts to label the data
and make information flow decisions.

Some pioneering work has been done in the technical community (albeit
not exposed to the IETF) in the area of comparing clearances of two
security policies.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Timothy J. Miller
Sent: Monday, October 13, 2008 10:03 AM
To: Carl Wallace
Cc: [e-mail]
Subject: Re: draft-turner-caclearanceconstraints-01.txt

Carl Wallace wrote:
> I vote yes to adopting this as a PKIX work item.  Specification
details=20
> can be resolved after the draft is accepted as a working group draft.

Can we even say for certain that clearance is a consistent enough=20
concept within and across jurisdictions to enable a single logic for=20
constraint processing?  I'd argue not.

E.g., RFC3281 talks about "the" basic clearance hierarchy, which doesn't

even exist.  What's the relationship between NATO CONFIDENTIAL and US=20
UNCLASSIFIED CONTROLLED INFORMATION?  How about US UCI and US FOR=20
OFFICIAL USE ONLY?  US SECRET/NOFOREIGN?  US TS/SCI and TS/SAP?  And=20
that's without even getting into the obscure corners of the US alone.

What I'm trying to say is that classification is *not* a strict=20
hierarchy.  It's semi-structured.  We have trouble enough figuring this=20
stuff out in the real world without having to write code for it.  :)

Presuming I have a vote, I vote no.

-- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DENDo3001668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 07:23:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DENDrU001666; Mon, 13 Oct 2008 07:23:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9DEN29G001652 for <[e-mail]>; Mon, 13 Oct 2008 07:23:12 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 5959 invoked from network); 13 Oct 2008 14:09:41 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;13 Oct 2008 14:09:41 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 13 Oct 2008 14:09:41 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: What are certificates fundamentally all about?  [was: draft-turner-caclearanceconstraints-01.txt]
Date: Mon, 13 Oct 2008 10:22:59 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What are certificates fundamentally all about?  [was: draft-turner-caclearanceconstraints-01.txt]
Thread-Index: AcktO65N7h87jtyzRKSrYZj9ffBIgQAAzctg
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Timothy J. Miller" <[e-mail]>, <[e-mail]>
Cc: <[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>

There are many ways to promulgate privileges and authorizations.  Two of
these methods are public key certificates and attribute certificates.

The I-D deals with how to process the clearance information in a chain
of public key and attribute certificates.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Timothy J. Miller
Sent: Monday, October 13, 2008 9:40 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: What are certificates fundamentally all about? [was:
draft-turner-caclearanceconstraints-01.txt]

Stephen Wilson wrote:

> Then you can subtly adjust the conception of a PKC as being "an=20
> assertion of an entity's key and a RELATIVELY STATIC identity IN A=20
> DEFINED CONTEXT".  A flexible interpretation of "identity in a defined

> context" embraces things like my identity as an chartered engineer, my

> identity as a business owner, my identity as a health insurance=20
> subscriber, my identity as a bank account holder.  In each of these=20
> scenarios, it would be very powerful for me to carry a separate=20
> dedicated certificate with which to sign specific types of
transactions=20
> (e.g. engineering test reports, tax returns, health insurance claims,=20
> and payment instructions respectively).  That is, four different=20
> certificates all independently registered and managed, tightly coupled

> to regular customer relationship management processes, probably
carried=20
> on separate smartcards.

We have that; it's called SPKI/SDSI.  :)

> To illustrate the point, I don't actually see any reason in principle=20
> why a PKC could not be used to assert my identity (or relationship) as

> 'a person cleared to Top Secret' so long as that relationship is=20
> relatively long lived; say a few months.  Path validation is a cinch:=20
> the relationship I would have express in my PKC is with a particular=20
> vetting agency, which would appear in the path, with a Policy OID in
the=20
> Subject PKC that specifies the clearance protocol.  The Public Key of=20
> the vetting agency -- or a higher Root Key -- would be the trust
anchor=20
> needed in a whole class of applications processing my digital
signature=20
> applied to Secret documents.

However, that's a *lot* of work, infrastructure, and code needed to=20
communicate an attribute the relying party can more simply look up in a=20
directory at the time of the transaction, or that the relying party can=20
have communicated to it as part of an authorization token (InfoCard,=20
OpenID, SAML, WS-*, etc.).

These schemes have the advantage of accommodating both static,=20
relatively static, and highly dynamic attributes, *plus* supports=20
non-person attributes such as environment level, current threat posture,

etc.

In short, you have to have the directory anyway for at least some=20
attributes, so it's simpler in the long run to stuff *all* the=20
attributes in there.

-- Tim



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DELIon001494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 07:21:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DELIFg001493; Mon, 13 Oct 2008 07:21:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DELFcr001485 for <[e-mail]>; Mon, 13 Oct 2008 07:21:15 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9DELEEf030290 for <[e-mail]>; Mon, 13 Oct 2008 10:21:14 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9DELEMA030277; Mon, 13 Oct 2008 10:21:14 -0400
Received: from [129.83.200.2] (129.83.200.2) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 13 Oct 2008 10:21:14 -0400
Message-ID: <[e-mail]>
Date: Mon, 13 Oct 2008 09:21:10 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Johannes Merkle <[e-mail]>, <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
References: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC> <p06240836c516c6e25589@[10.20.30.152]> <DDE506CF856141B5AB30E0B7392107B7@AndersPC> <[e-mail]> <EBB2CF25807C427EBB10544E25B5095C@AndersPC>
In-Reply-To: <EBB2CF25807C427EBB10544E25B5095C@AndersPC>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060108040506090601060206"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms060108040506090601060206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:

> Key life-cycle considerations do not apply to device keys;
> they are assumed to outlive the device itself and even if they
> were renewed, encryption and signing keys would be updated
> in parallel since encryption is only used for on-line secret/private
> key data import which is very different to for example e-mail.

This assumption is highly dependent on the environment and device.  In 
DoD's nascent non-person entity PKI plans, we expect the device to 
outlive the key crpytoperiod by a factor of about 2 for most classes of 
NPEs.  However, some classes--e.g., sensors--won't.

-- Tim


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMTMxNDIxMTBaMCMGCSqGSIb3DQEJBDEWBBSc1wc9xJHHes+Jf5w/O956kxn2TTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgAjF9JhEvZCLCRJEF2CP/E4vUnbGKaSP5xmBOIGwWdH+dnqmGsbPIpKllPqU
tqQR27+eH/XDL5mVF1fXPdrOu/GB+R4Gn4gz9kSnuxg03IP/C9MGzN1Vj9ffre4NCuzafGl+
nh+iL3Fff3KsMvsDuoR5AsXiFeTjMLQF92HrSCzdAAAAAAAA
--------------ms060108040506090601060206--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DE3JkO099831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 07:03:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DE3JKi099830; Mon, 13 Oct 2008 07:03:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DE3Iox099822 for <[e-mail]>; Mon, 13 Oct 2008 07:03:18 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9DE3Hjf013007 for <[e-mail]>; Mon, 13 Oct 2008 10:03:18 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9DE3HHM013001; Mon, 13 Oct 2008 10:03:17 -0400
Received: from [129.83.200.2] (129.83.200.2) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 13 Oct 2008 10:03:17 -0400
Message-ID: <[e-mail]>
Date: Mon, 13 Oct 2008 09:03:15 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Carl Wallace <[e-mail]>
CC: <[e-mail]>
Subject: Re: draft-turner-caclearanceconstraints-01.txt
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040507080402010501060703"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms040507080402010501060703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Carl Wallace wrote:
> I vote yes to adopting this as a PKIX work item.  Specification details 
> can be resolved after the draft is accepted as a working group draft.

Can we even say for certain that clearance is a consistent enough 
concept within and across jurisdictions to enable a single logic for 
constraint processing?  I'd argue not.

E.g., RFC3281 talks about "the" basic clearance hierarchy, which doesn't 
even exist.  What's the relationship between NATO CONFIDENTIAL and US 
UNCLASSIFIED CONTROLLED INFORMATION?  How about US UCI and US FOR 
OFFICIAL USE ONLY?  US SECRET/NOFOREIGN?  US TS/SCI and TS/SAP?  And 
that's without even getting into the obscure corners of the US alone.

What I'm trying to say is that classification is *not* a strict 
hierarchy.  It's semi-structured.  We have trouble enough figuring this 
stuff out in the real world without having to write code for it.  :)

Presuming I have a vote, I vote no.

-- Tim

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMTMxNDAzMTVaMCMGCSqGSIb3DQEJBDEWBBQJoOVLCFqkVF5laR+f4zDxgS+7cDBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgFCfTU1+yb1FZ+sPiBTwQuEwjLGp08RD1hGs5uM6HTNVj90qBkRvmpOFLkO3
DmprXl6SXd7m4IeQpSrbpwdQE6CRplW6Ch6bhJLS5mYFPMwtrlriy8LiHIh96GRO7o8HNVeV
VI8pH/qO6eCg52LEAyCjjeNG3MwnZHsKS0S2kOUXAAAAAAAA
--------------ms040507080402010501060703--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DDeMbV097593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 06:40:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DDeMVb097592; Mon, 13 Oct 2008 06:40:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DDeAcS097580 for <[e-mail]>; Mon, 13 Oct 2008 06:40:21 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9DDeA1Y014503 for <[e-mail]>; Mon, 13 Oct 2008 09:40:10 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m9DDe9cS014492; Mon, 13 Oct 2008 09:40:09 -0400
Received: from [129.83.200.2] (129.83.200.2) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 13 Oct 2008 09:40:09 -0400
Message-ID: <[e-mail]>
Date: Mon, 13 Oct 2008 08:40:06 -0500
From: "Timothy J. Miller" <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: What are certificates fundamentally all about?  [was: draft-turner-caclearanceconstraints-01.txt]
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050700090607020204060802"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------ms050700090607020204060802
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

Stephen Wilson wrote:

> Then you can subtly adjust the conception of a PKC as being "an=20
> assertion of an entity=92s key and a RELATIVELY STATIC identity IN A=20
> DEFINED CONTEXT".  A flexible interpretation of "identity in a defined =

> context" embraces things like my identity as an chartered engineer, my =

> identity as a business owner, my identity as a health insurance=20
> subscriber, my identity as a bank account holder.  In each of these=20
> scenarios, it would be very powerful for me to carry a separate=20
> dedicated certificate with which to sign specific types of transactions=
=20
> (e.g. engineering test reports, tax returns, health insurance claims,=20
> and payment instructions respectively).  That is, four different=20
> certificates all independently registered and managed, tightly coupled =

> to regular customer relationship management processes, probably carried=
=20
> on separate smartcards.

We have that; it's called SPKI/SDSI.  :)

> To illustrate the point, I don't actually see any reason in principle=20
> why a PKC could not be used to assert my identity (or relationship) as =

> 'a person cleared to Top Secret' so long as that relationship is=20
> relatively long lived; say a few months.  Path validation is a cinch:=20
> the relationship I would have express in my PKC is with a particular=20
> vetting agency, which would appear in the path, with a Policy OID in th=
e=20
> Subject PKC that specifies the clearance protocol.  The Public Key of=20
> the vetting agency -- or a higher Root Key -- would be the trust anchor=
=20
> needed in a whole class of applications processing my digital signature=
=20
> applied to Secret documents.

However, that's a *lot* of work, infrastructure, and code needed to=20
communicate an attribute the relying party can more simply look up in a=20
directory at the time of the transaction, or that the relying party can=20
have communicated to it as part of an authorization token (InfoCard,=20
OpenID, SAML, WS-*, etc.).

These schemes have the advantage of accommodating both static,=20
relatively static, and highly dynamic attributes, *plus* supports=20
non-person attributes such as environment level, current threat posture, =

etc.

In short, you have to have the directory anyway for at least some=20
attributes, so it's simpler in the long run to stuff *all* the=20
attributes in there.

-- Tim


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC
A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh
dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw
EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt
aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI
bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr
W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF
4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB
LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj
aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu
b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7
FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX
6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY
QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb
r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe
McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ
bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J
VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx
NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm
iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/
glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj
TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD
VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW
gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p
bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8
vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2
8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc
MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4
2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I
O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox
EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw
IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN
MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj
YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn
hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI
7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407
K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH
DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL
/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD
VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW
gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p
dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB
BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS
ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh
8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB
77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr
146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC
AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1
dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ
BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wODEwMTMxMzQwMDZaMCMGCSqGSIb3DQEJBDEWBBTChUlBgTLBGJBpddrIbaFp+wJL7zBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV
BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD
Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg
YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0
eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG
9w0BAQEFAASBgAjSOFONkT+9Nqlmsq5zA0sgriFXGrwzWvrPt3cph3vJr9dZ069eWFSz3oy1
ZYgZsNGkzI9oBHe/lKqv5u5uLmoWYAIh7qZuicuIw2AxU3k6oFTep68sRaBEeKu67Q6N3nzR
1LWidbzBve68p01j4dG48LwX9sEaxce8Mn+lcZ5dAAAAAAAA
--------------ms050700090607020204060802--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DCJ5bY089776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 05:19:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DCJ52N089775; Mon, 13 Oct 2008 05:19:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DCIsge089759 for <[e-mail]>; Mon, 13 Oct 2008 05:19:04 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA950175A405; Mon, 13 Oct 2008 14:18:51 +0200
Message-ID: <EBB2CF25807C427EBB10544E25B5095C@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: "Johannes Merkle" <[e-mail]>
Cc: <[e-mail]>
References: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC> <p06240836c516c6e25589@[10.20.30.152]> <DDE506CF856141B5AB30E0B7392107B7@AndersPC> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
Date: Mon, 13 Oct 2008 14:18:56 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Johannes,

Would it be possible to describe an attack in detail?  I.e.
elaborating on what needs to be broken.  That non-padded
schemes open data to attacks is easy to understand but I'm
not particularly concerned about that since nobody
(in their right mind) uses such schemes for RSA keys.

Key life-cycle considerations do not apply to device keys;
they are assumed to outlive the device itself and even if they
were renewed, encryption and signing keys would be updated
in parallel since encryption is only used for on-line secret/private
key data import which is very different to for example e-mail.

Anders

----- Original Message ----- 
From: "Johannes Merkle" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>; "Paul Hoffman" <[e-mail]>
Sent: Monday, October 13, 2008 13:50
Subject: Re: Signing and Encrypting with the same key?



> Although SP 800-57 section 5.2 is a bit vague on the crypto-related
> security issues opened by multi-use keys, I guess it is about decrypting
> data using matching signatures?  I don't really see how that is possible
> if you use PKCS #1 padding because the chance of a match is zero
> unless you start using non-conformant encryption packaging but
> why would a provisioning protocol [*] use such?  I may be wrong, but 

That's not the way cryptographers think. Just because it looks difficult if not 
impossible does not mean that it is. You need some stronger arguments before 
considering something as secure. For both, RSA encryption and RSA signature 
(e.g. with PKCS#1) there has been extensive research, so they are believed 
secure enough. However, the combination of both gives an attacker much more 
options. The padding schemes are not designed to resist such attacks (although 
they actually might do).

Furthermore, the separation of signature and decryption is a general 
recommendation, which is not based on any assumption on the padding scheme.

Of course, Eric's reasoning is also valid. Usually, you keep your expired 
decryption keys while expired signature keys should be destroyed.

Johannes Merkle



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DBoQaY085825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 04:50:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DBoQLc085824; Mon, 13 Oct 2008 04:50:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from a.mx.secunet.com (a.mx.secunet.com [213.68.205.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DBoFQ6085800 for <[e-mail]>; Mon, 13 Oct 2008 04:50:26 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (alg3 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 61A4020C0AF; Mon, 13 Oct 2008 13:50:13 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 2A8B720C0A4; Mon, 13 Oct 2008 13:50:13 +0200 (CEST)
Received: from [10.208.1.240] ([10.208.1.240]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 13:50:12 +0200
Message-ID: <[e-mail]>
Date: Mon, 13 Oct 2008 13:50:12 +0200
From: Johannes Merkle <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail], Paul Hoffman <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
References: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC> <p06240836c516c6e25589@[10.20.30.152]> <DDE506CF856141B5AB30E0B7392107B7@AndersPC>
In-Reply-To: <DDE506CF856141B5AB30E0B7392107B7@AndersPC>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Oct 2008 11:50:12.0946 (UTC) FILETIME=[D9E6CB20:01C92D29]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Although SP 800-57 section 5.2 is a bit vague on the crypto-related
> security issues opened by multi-use keys, I guess it is about decrypting
> data using matching signatures?  I don't really see how that is possible
> if you use PKCS #1 padding because the chance of a match is zero
> unless you start using non-conformant encryption packaging but
> why would a provisioning protocol [*] use such?  I may be wrong, but 

That's not the way cryptographers think. Just because it looks difficult if not 
impossible does not mean that it is. You need some stronger arguments before 
considering something as secure. For both, RSA encryption and RSA signature 
(e.g. with PKCS#1) there has been extensive research, so they are believed 
secure enough. However, the combination of both gives an attacker much more 
options. The padding schemes are not designed to resist such attacks (although 
they actually might do).

Furthermore, the separation of signature and decryption is a general 
recommendation, which is not based on any assumption on the padding scheme.

Of course, Eric's reasoning is also valid. Usually, you keep your expired 
decryption keys while expired signature keys should be destroyed.

Johannes Merkle



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9D6WnK4063158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2008 23:32:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9D6WnNI063157; Sun, 12 Oct 2008 23:32:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9D6Wcej063137 for <[e-mail]>; Sun, 12 Oct 2008 23:32:48 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA950173D8A4; Mon, 13 Oct 2008 08:32:37 +0200
Message-ID: <DDE506CF856141B5AB30E0B7392107B7@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Paul Hoffman" <[e-mail]>
References: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC> <p06240836c516c6e25589@[10.20.30.152]>
In-Reply-To: <p06240836c516c6e25589@[10.20.30.152]>
Subject: Re: Signing and Encrypting with the same key?
Date: Mon, 13 Oct 2008 08:32:41 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>According to many cryptographers you shouldn't sign and encrypt with
>>the same RSA key-pair. 

>References please? NIST says you must not do so in SP 800-57, section 5.2, but not because:

>>The reason appears to be that this could lead
>>to exposure of the private key. 

Thanks for the reference Paul!  I don't have any real facts or pointers,
only a bunch of scattered opinions which I try to verify the validity of.
I believe that a future standard for secure containers in mobile phones should
be as simple as is technically feasible and if multiple keys for the container's
own needs (user-keys may indeed following SP 800-57), can be avoided,
a major potential source to non-interoperability would be eliminated.

Although SP 800-57 section 5.2 is a bit vague on the crypto-related
security issues opened by multi-use keys, I guess it is about decrypting
data using matching signatures?  I don't really see how that is possible
if you use PKCS #1 padding because the chance of a match is zero
unless you start using non-conformant encryption packaging but
why would a provisioning protocol [*] use such?  I may be wrong, but 
so far I remain unconvinced that there is a problem to solve but I'm
ready to be caught erring since I'm just an applier of crypto, not a
mathematician.

Anders

*]  The container keys are mainly intended for key provisioning,
where signatures are used for device authenticity, key generation
attestations and message integrity while encryption is used for secure
import of secret/private data into the container.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9D2bSoY050352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2008 19:37:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9D2bSt2050351; Sun, 12 Oct 2008 19:37:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from spam.kisa.or.kr (sniper.kisa.or.kr [211.252.150.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9D2bDmj050338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sun, 12 Oct 2008 19:37:25 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (snipe 3594 invoked by alias); 13 Oct 2008 11:35:49 +0900
Received: from unknown (HELO ms.kisa.or.kr) (211.252.150.23) by 211.252.150.22 with SMTP; 13 Oct 2008 11:35:49 +0900
Received: (qmail 23810 invoked from network); 13 Oct 2008 02:35:00 -0000
Received: from unknown (HELO LocalHost) (172.16.7.105) by ms.kisa.or.kr with SMTP; 13 Oct 2008 02:35:00 -0000
From: =?ks_c_5601-1987?B?udq788iv?= <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Subject: Reply to Jim Schaad's comments on TAC internet draft 00
Date: Mon, 13 Oct 2008 11:38:12 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C92D28.2C5EC580"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-index: Acks3Lw9CbkAXNqoSXOhHpar4OWbhQ==
Sender: [e-mail]
Precedence: 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_0028_01C92D28.2C5EC580
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

Dear Jim Schaad and PKIX members,

=20

I embedded the reply to your comments.

=20

You can refer to SANG=A1=AFs last comments inline to each question.

=20

Thank you.

=20

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

SangHwan Park=20

Senior Researcher / CISA / CISSP / ITIL

Korea Information Security Agency(KISA)

[phone], [e-mail]

=20

1.  What is the time length that TAC certificates are expected to be =
used
for?  Are they onetime certificates, are they supposed to be good for a
short period of time (i.e. months) or are they supposed to be good for
extended periods of time (i.e. years but used infrequently), or all of =
the
above?

SANG) We do not believe that this document should specify limits on the
duration or frequency with which TACs are used, however they are not
envisioned as one-time certs. It will be up to each TAC CA (BI/AI pair) =
to
determine the lifetime of the certs it issues, and to advise subjects of
suggested usage guidelines, e.g., via a cert policy. The security
considerations sections says:
    ... if the user employs
   the same TAC for multiple transactions (with the same or
   different parties), the transactions can be linked through the
   use of the same TAC. Thus the anonymity guarantee is "weak"
   even though the user's real identity is still hidden.
   To achieve stronger anonymity, a user may acquire multiple
   TACs, through distinct iterations of the protocol.
=20
JIM) I understand that you are not specifying the lifetime.  That is =
part
of the problem.  If they can be used for a long time, i.e. past the time
that the certificate would "normally" expire or worse past the time that
you have some type of contractual relationship with the BI, then you =
have a
security problem.  Do you renew a current certificate, and how do you
decide if that certificate has been paid for, or do you issue a new
certificate with a new identity and lose any history of the identity =
with
existing relationships.  In one case you are requiring a restart of a
relationship with a partner, in the other case you are potentially =
leaking
information to either the AI or BI about who you are.
=20
SANG) I understand your point, now that you have provided more comments.
These are topics that the CP and CPS for a TAC would address, but we do =
not
believe that they need to be dictated by this document. Taking your
comments and concerns into account and we'll revise security =
consideration,
saying that "if the TAC has a long validity interval, this increases the
probability that the identity of a TAC user will be discovered, e.g., as =
a
result of linking user transactions across multiple servers. As a result =
we
recommend that each TAC CA consider carefully how long the validity for =
a
TAC certificate should be. This document makes no provisions for
certificate renewal or rekey, as a means to encouraging TAC users to
acquire new TACs."
=20
2.  Given the ability to potentially link an identity from other =
information
on the network (i.e. IP addresses), I would like to see some text =
describing
the types of protocols that TAC certificates should and should not be =
used
in.  For example, it could be used for an anonymous TLS client auth
certificates, but would probably not be as useful for a SIP or S/MIME
certificate.  Or maybe you disagree with that.  A description of the =
types
circumstances that these certificates are used in would helpful in =
trying to
determine if they are both useful and susceptible to other types of =
attacks.
=20
SANG) This issue was raised in Dublin and as a result we prepared text =
for
the next rev of the document that addresses the issue you raise here, =
i.e.,
repeated use of an anonymous credential provides opportunities for =
linkage.
There is also the potential to determine the true identity of a user by
examining other info outside of what is provided by the cert. Here is =
the
text we have for the security considerations section, dealing with this
topic.

"It also may be possible to determine the identity of a user via
information carried by lower level protocols, or by other,
application-specific means. For example, the IP address of the
user might be used to identify him/her. An analogous problem
might arise if a user visits a site (and does not conceal
his/her identity), the site deposits a "cookie" into the
user's browser cache, and the user later visits a site and
employs a TAC with the presumption of anonymity.  This use
of a TAC is a tool to help a user preserve anonymity, but it
is not, per se, a guarantee of anonymity."
=20
JIM) This text does not address the issue that I raised.  Specifically =
what
type of protocols is this good for, and what type should it not be used =
for
since more information is available to potentially more people.  You =
have
discussed issues dealing with one specific type of protocol - =
http/https.
This does not look at other protocols and type of issues that these
protocols raise.
 Here is an example, do you believe that a TAC certificate should be =
used
for sending and receiving e-mail?  I think that this raises all sorts of
problem with a store and forward architecture.  It is much simpler for
people to obtain information by eavesdropping in this case than it would =
be
for the case of TLS - especially if you deferred client certificate
validation until after the secure channel has been established.
=20
SANG) The primary role of the TAC is to access web services with =
anonymity.
We will revise security consideration sections to make this more =
explicit.
=20
3.  I think the document should strongly suggest that indirect CRLs are =
used
by TAC CAs.  This would almost be a requirement for OCSP.  The protocol
needs to have a way for a communication to occur between the AI and BI =
to
allow for signing of CRLs in any event.  What is this going to look =
like.
Does the BI simply trust the AI to hand it a correct hash?  Does the AI =
sign
the CRL, pass it to the BI to finish signing and then verify, does the =
AI
give the TBS to the BI, have the BI sign it and then return the =
signature to
the AI to finish signing and publish?
=20
In section 5, the text says that an AI unilaterally manages the CRL for =
a
TAC CA:
     "If AI determines that there is sufficient
evidence of abuse to trace the TAC to the user, the AI revokes
  the TAC, by listing its serial number on the next CRL issued
  by the AI.
=20
But the text failed to say how the AI does this.  Use of an indirect CRL
may be the simplest approach to address this issue.
=20
Requiring TACs to use indirect CRLS is the simplest way to address this
problem, however rfc5280 implementations are not required to process
indirect CRLs.  This means you are going to either specify a protocol to
allow for direct CRLs to be jointly issued, or you are going to be non-
rfc5280 compliant.
=20
SANG) An RP that process indirect CRLs is not non-compliant, but you are
correct in noting that a compliant RP need not process indirect CRLs. =
Our
proposed resolution for this issue to create a second CA, under the TAC =
CA,
and have it be the CRL issuer for the EE certificates issued by the TAC =
CA.
This CA will have the cRLSign bit set in KU, but not the keyCertSign =
bit.
The private key for this CA will be held by the AI, so that it can issue
CRLs unilaterally. This CA certificate should be long-lived, just like =
the
TAC CA certificate. It will be the only CA certificate issued under the =
TAC
CA certificate (and thus it will be signed jointly by the BI and AI). We
will recommend that the CRL for this CA certificate be similarly long-
lived, as it too need to be signed jointly by the BI and AI. The EE TAC
certificates MUST contain a CRLDP that points to the CRL issued by this =
CA,
to ensure that RPs know to check that CRL vs. the CRL that covers this =
(the
CRL) CA. Do you agree that this approach meets all the relevant 5280
criteria for what RPs MUST support, and still allows the AI to issue =
CRLs
for TACs unilaterally?
=20
4.  Information should be placed in the document (Security =
Considerations is
fine) about the financial model associated with this issuing model.  All

user financials need to be done with the BI and not the AI, the AI would
have to get compensated by the BI for issued certificates.  An =
associated
item with this is the question of should the BI be able to influence
contents of the certificate, specifically the lifetime of the =
certificate to
correspond to the money paid.
=20
There is no requirement that the Ai and BI be operated in a financially-
separate fashion, but there also is no prohibition. Your suggestion is a
good one, i.e., adding some text to the security considerations section =
to
note that IF the AI and BI are financially independent of one another, =
THEN
the user MUST pay the BI (who already knows the user's true identity), =
and
the BI will compensate the Ai for each cert it issues. We can probably
leave it to AIs and BIs to coordinate the issue of cert lifetime, for
financial purposes. After all, the management of the CA is a joint =
matter
for the AI and BI, and we should assume they will be able to work out =
these
details.
=20
The first issue is that you cannot pay the AI for your certificate.  If =
you
do, then you need to pay with some type of anonymous cash, and you must =
pay
using a completely anonymous protocol.  I don't know of any way to
currently do this except in the realm of academia.
I don't believe that you can leave the issue of things like lifetime =
out.
Let's say that the BI can allow for issuing of certificates for a period =
of
three months, one year and five years.  The BI would need to communicate
this information as part of the token, or the BI and AI would need to =
have
an additional conversation before the AI builds the certificate in order =
to
get this piece of information.
As an alternative, you could have different AI's for different length
certificates.  This would imply that the BI cannot directly influence =
the
contents of the certificate, but would require that the BI tell the user
what the name of the AI to be used to issue the certificate.  (Which =
might
not be a bad idea anyway.)
=20
SANG) I agree with your point. There was no intent to require a user to
employ an anonymous or cash payment system to acquire a TAC. There seem =
to
be a few options here, as you noted. If the TAC CA issues certificates =
with
only one duration, this problem does not arise. If there are multiple
duration options, then there needs to be a way to signal to the AI which
duration the user has paid for. Having different AI instances (by name) =
is
one solution to the problem, or the token could be extended to =
accommodate
your other proposed solution. We will add text to the security
considerations section to suggest that a given TAC CA issued =
certificates
with only one lifetime, so avoid the complexity that might arise =
otherwise.
We also will note that if a TAC CA offers certificates of with different
lifetimes, then it will need to communicate this info from the BI to the =
AI
in a way that does not unduly compromise the anonymity of the user.
=20
5.  Renewal/Rekey operations are not covered by this document.  Either =
you
need to state that these operations are never done, or you need to have =
a
secure method of allowing the operation to be completed.  In this case =
the
Token no longer exists (or at least is no longer valid) and so the AI =
would
need to prove to the BI that the BI should sign the certificate.  One
possible method would be to send the BI the TBSigned of the new =
certificate
along with the old certificate allowing it to see that it had previously
signed a certificate for subject name.  It would still not be traceable =
back
to the user's Token, but would give assurances that the certificate =
should
be issued.
=20
SANG) Good point. Renewal/Rekey should NOT be supported. We will revise =
the
text accordingly.
=20
JIM) This has some implementations for item 1.


SANG) Please refer to the response for item 1.
=20
6. ALREADY RESOLVED
=20
7.  Guidance needs to be supplied about how long items are to be kept in =
the
respective databases.  Are these database entries expected to be kept
forever once a certificate has been issued?  Or are they only kept for
approximately the life of the certificate.  This is really impacted by =
the

answer to question #5 on rekey/renewal, but has some additional tracing
implications beyond that.
=20
SANG) Since TACs are not suitable for NR (a detail than can be added to =
the
text), there does not appear to be a need to retain data about TAC certs
beyond their lifetime.
=20
JIM) An aggrieved entity may want to get the identity information about =
a
signer after the certificate has expired.  This implies that there is at
least some minimum duration that the information needs to be kept for
traceability reasons.
=20
SANG) Good point. We'll say that a TAC CA MUST describe in its CP how =
long
it will retain data about certificates it issued, beyond the lifetime of
these certificates. We also will note your rationale of why such =
retention
is appropriate.  We do not plan to specify a minimum duration for such
retention, as that really is a per-CA matter.

8.  ALREADY RESOLVED

9.  If you believe that TAC permits both signature and encryption
operations, then you need to address an additional problem.  If a DSA
signature certificate and a DH encryption certificate pair are needed, =
it is
some protocols may require that they contain the same subject name, and =
thus
would need to be issued at the same time.  The current TAC protocol =
makes no
allowances for the ability to have the BI sign two independent =
certificates
at the same time.  This could be done by allowing the protocol to =
present
multiple blinded hashes to the BI to be signed for a single token.
=20
SANG) The primary focus of the TAC work has been web access. For that, a
single cert is enough. But, you make a good point that if one wants to =
use
TACs with S/MIME, for example, dual cert issuance needs to be supported.
For now, we will stick with single cert issuance, with it's implied
limitations.
=20
JIM) This needs to be made explicit.
=20
SANG) Please refer to the response for item 2.
=20
10. ALREADY RESOLVED

11.  In section 5.1 Step 2, the statement is made that a TLS certificate
should be used for doing the signature operation on a CMS object.  You =
might
want to rethink this statement.  While there is nothing technically =
wrong
with this, some CMS validators would reject the signature since the EKU
would not be correct.
=20
Does CMS specify a set of EKUs that are acceptable for any use of CMS, =
or
are you saying that the presence of any EKU associated with TLS use =
might
cause rejection because software (e.g., OpenSSL) has some non-standard
restrictions embedded in it?
=20
JIM) If there is an EKU in the certificate, and it is not one of the
"acceptable" EKUs for CMS, it is possible that some implementations =
might
reject the certificate.  This is highly dependent on the implementation. =
 I
don't know if this is a problem, but it potentially could be.   One
possible solution would be to create an EKU specifically for this =
operation.
=20
SANG) Sorry for this misunderstanding with regard to TLS certificates. =
In
section 5.1 Step 2, a TLS certificate is used only for security channel
establishment, not for verifying a signature on a CMS object. See the =
end
of section 5.1 Step 1, cited below. Does the following text address your
concern?

 "It is RECOMMENDED that the UserKey be a random or pseudo-random value. =


Whenever the BI passes a UserKey to an external party, or accepts the
UserKey from an external party=20

(e.g., the AI), the value is embedded in digitally signed CMS object =
called
a
   Token, accompanied by the time stamp noted above. The signature on a
Token is generated by=20

the BI using a private key employed only for this purpose."
=20
=20
12.  ALREADY RESOLVED
=20
13.  I would like to see for each of the steps in 5.1, an explanation of =
who
needs to be protected against for the communication.  This will better =
allow
others to decide on how to implement this with non-TLS communications.  =
For
example, could this be done with e-mail or are the security requirements =
not
met?
=20
Not sure what you mean by "who needs to be protected against for the
communication." We can explain in more detail what security features are
required at each step, but there is already some text addressing this, =
for
at least some steps. For example, in step 2, the document says:

=20
"The secure channel is required here to prevent a wiretapper from
being able to acquire the Token. For example, if the user
establishes a one-way authenticated TLS session to the BI in
Step 1, this session could be used to pass the Token back to
the user."
=20
There are cases where you need to explicitly prevent either the AI or BI
from getting the information, but may not need to protect against a =
general
wiretapper.  For example, if the client and BI transaction is open =
(except
to the AI), this may not help an eavesdropper as long as the client/AI
transaction is completely sealed.  The eavesdropper would be in same
situation in this case as BI, it knows some information but not enough =
to
complete the trace without the cooperation of the AI.
=20
 SANG) We requested the secure channel in open communications, based on =
the
information that is valuable from security point of view.
=20
14. ALREADY RESOLVED
=20
15. ALREADY RESOLVED
=20
16. ALREADY RESOLVED
=20
17.  In section 5.2, step C - should the BI also conduct its own =
assessment
of the fact that the aggrieved party's case before releasing the
information?
=20
BI could do so. We can add text to say that is an option, but it would =
be
something that each TAC CA decides for itself, and declares in its CP =
and
details in the CPS.
=20
Not requiring this would allow for a rouge AI to get the information.  =
It
would create a pretend aggrieved party, provide the details to that =
party
and query the BI.  The BI doing no checks would hand over the =
information
no questions asked.
=20
SANG) Fair point. We will change the text to state that BI should =
conduct
its own assessment of the aggrieved party's case before releasing the =
user
ID.
=20
18. ALREADY RESOLVED
=20
19. ALREADY RESOLVED

=20

=20


------=_NextPart_000_0028_01C92D28.2C5EC580
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dks_c_5601-1987">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"phone"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:=B9=D9=C5=C1;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:=B1=BC=B8=B2;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@=B1=BC=B8=B2";
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@=B9=D9=C5=C1";
	panose-1:2 3 6 0 0 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-autospace:none;
	word-break:break-hangul;
	font-size:10.0pt;
	font-family:=B9=D9=C5=C1;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:=B1=BC=B8=B2;
	color:windowtext;}
 /* Page Definitions */
 @page Section1
	{size:595.3pt 841.9pt;
	margin:99.25pt 3.0cm 3.0cm 3.0cm;
	layout-grid:18.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DKO link=3Dblue vlink=3Dpurple>

<div class=3DSection1 style=3D'layout-grid:18.0pt'>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>Dear
Jim Schaad and PKIX members,<o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>I
embedded the reply to your comments.<o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>You
can refer to </span></font><b><font size=3D3 color=3D"#333399"
face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;font-family:
"Times New Roman";color:#333399;font-weight:bold'>SANG=A1=AFs last =
comments inline
to each question.</span></font></b><font size=3D3 color=3Dblack
face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;font-family:
"Times New Roman";color:black'><o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>Thank
you.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B9=D9=C5=C1><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B9=D9=C5=C1><span =
lang=3DEN-US style=3D'font-size:10.0pt'>-------------------</span><span
lang=3DEN-US><o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:PlaceName =
w:st=3D"on"><font size=3D2
  face=3D=B9=D9=C5=C1><span lang=3DEN-US =
style=3D'font-size:10.0pt'>SangHwan</span></font></st1:PlaceName><span
 lang=3DEN-US> <st1:PlaceType =
w:st=3D"on">Park</st1:PlaceType></span></st1:place><span
lang=3DEN-US> <o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B9=D9=C5=C1><span =
lang=3DEN-US style=3D'font-size:10.0pt'>Senior
Researcher / CISA / CISSP / ITIL<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B9=D9=C5=C1><span =
lang=3DEN-US style=3D'font-size:10.0pt'>Korea
Information Security Agency(KISA)<o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D2 face=3D=B9=D9=C5=C1><span =
lang=3DEN-US style=3D'font-size:
10.0pt'>+<st1:phone o:ls=3D"trans" phonenumber=3D"8224055428" =
w:st=3D"on">82-2-405-5428</st1:phone>,
<a =
href=3D"mailto:[e-mail]">[e-mail]</a></span></font><fon=
t
size=3D3 color=3Dblack face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman";color:black'><o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>1.&nbsp;
What is the time length that TAC certificates are expected to be =
used<br>
for?&nbsp; Are they onetime certificates, are they supposed to be good =
for a<br>
short period of time (i.e. months) or are they supposed to be good =
for<br>
extended periods of time (i.e. years but used infrequently), or all of =
the
above?<br>
<br>
<b><span style=3D'font-weight:bold'>SANG) We do not believe that this =
document
should specify limits on the duration or frequency with which TACs are =
used,
however they are not envisioned as one-time certs. It will be up to each =
TAC CA
(BI/AI pair) to determine the lifetime of the certs it issues, and to =
advise
subjects of suggested usage guidelines, e.g., via a cert policy. The =
security
considerations sections says:<br>
&nbsp;&nbsp;&nbsp; ... if the user employs<br>
&nbsp;&nbsp; the same TAC for multiple transactions (with the same =
or<br>
&nbsp;&nbsp; different parties), the transactions can be linked through =
the<br>
&nbsp;&nbsp; use of the same TAC. Thus the anonymity guarantee is
&quot;weak&quot;<br>
&nbsp;&nbsp; even though the user's real identity is still hidden.<br>
&nbsp;&nbsp; To achieve stronger anonymity, a user may acquire =
multiple<br>
&nbsp;&nbsp; TACs, through distinct iterations of the protocol.<br>
</span></b></span></font><font size=3D3 color=3D"#1f497d" face=3D"Times =
New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'>&nbsp;<br>
JIM) I understand that you are not specifying the lifetime.&nbsp; That =
is part
of the problem.&nbsp; If they can be used for a long time, i.e. past the =
time
that the certificate would &quot;normally&quot; expire or worse past the =
time
that you have some type of contractual relationship with the BI, then =
you have
a security problem.&nbsp; Do you renew a current certificate, and how do =
you
decide if that certificate has been paid for, or do you issue a new =
certificate
with a new identity and lose any history of the identity with existing
relationships.&nbsp; In one case you are requiring a restart of a =
relationship
with a partner, in the other case you are potentially leaking =
information to
either the AI or BI about who you are.<br>
</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span lang=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
</span></font><b><font size=3D3 color=3D"#333399" face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#333399;
font-weight:bold'>SANG) I understand your point, now that you have =
provided
more comments. These are topics that the CP and CPS for a TAC would =
address,
but we do not believe that they need to be dictated by this document. =
Taking
your comments and concerns into account and we'll revise security
consideration, saying that &quot;if the TAC has a long validity =
interval, this
increases the probability that the identity of a TAC user will be =
discovered,
e.g., as a result of linking user transactions across multiple servers. =
As a result
we recommend that each TAC CA consider carefully how long the validity =
for a
TAC certificate should be. This document makes no provisions for =
certificate
renewal or rekey, as a means to encouraging TAC users to acquire new
TACs.&quot;<br>
</span></font></b><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
2.&nbsp; Given the ability to potentially link an identity from other
information<br>
on the network (i.e. IP addresses), I would like to see some text =
describing<br>
the types of protocols that TAC certificates should and should not be =
used<br>
in.&nbsp; For example, it could be used for an anonymous TLS client =
auth<br>
certificates, but would probably not be as useful for a SIP or =
S/MIME<br>
certificate.&nbsp; Or maybe you disagree with that.&nbsp; A description =
of the
types<br>
circumstances that these certificates are used in would helpful in =
trying to<br>
determine if they are both useful and susceptible to other types of =
attacks.<br>
&nbsp;<br>
<b><span style=3D'font-weight:bold'>SANG) This issue was raised in =
Dublin and as
a result we prepared text for the next rev of the document that =
addresses the
issue you raise here, i.e., repeated use of an anonymous credential =
provides
opportunities for linkage. There is also the potential to determine the =
true
identity of a user by examining other info outside of what is provided =
by the
cert. Here is the text we have for the security considerations section, =
dealing
with this topic.</span></b></span></font><font size=3D3 face=3D"Times =
New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><b><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black;
font-weight:bold'>&quot;It also may be possible to determine the =
identity of a
user via<br>
information carried by lower level protocols, or by other,<br>
application-specific means. For example, the IP address of the<br>
user might be used to identify him/her. An analogous problem<br>
might arise if a user visits a site (and does not conceal<br>
his/her identity), the site deposits a &quot;cookie&quot; into the<br>
user's browser cache, and the user later visits a site and<br>
employs a TAC with the presumption of anonymity.&nbsp; This use<br>
of a TAC is a tool to help a user preserve anonymity, but it<br>
is not, per se, a guarantee of anonymity.</span></font></b><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;
font-family:"Times New Roman";color:black'>&quot;<br>
</span></font><font size=3D3 color=3D"#1f497d" face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'>&nbsp;<br>
JIM) This text does not address the issue that I raised.&nbsp; =
Specifically
what type of protocols is this good for, and what type should it not be =
used
for since more information is available to potentially more =
people.&nbsp; You
have discussed issues dealing with one specific type of protocol -
http/https.&nbsp; This does not look at other protocols and type of =
issues that
these protocols raise.<br>
&nbsp;Here is an example, do you believe that a TAC certificate should =
be used
for sending and receiving e-mail?&nbsp; I think that this raises all =
sorts of
problem with a store and forward architecture.&nbsp; It is much simpler =
for
people to obtain information by eavesdropping in this case than it would =
be for
the case of TLS - especially if you deferred client certificate =
validation
until after the secure channel has been established.<br>
</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span lang=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
</span></font><b><font size=3D3 color=3D"#333399" face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#333399;
font-weight:bold'>SANG) The primary role of the TAC is to access web =
services
with anonymity. We will revise security consideration sections to make =
this
more explicit.<br>
</span></font></b><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
3.&nbsp; I think the document should strongly suggest that indirect CRLs =
are
used<br>
by TAC CAs.&nbsp; This would almost be a requirement for OCSP.&nbsp; The
protocol<br>
needs to have a way for a communication to occur between the AI and BI =
to<br>
allow for signing of CRLs in any event.&nbsp; What is this going to look =
like.<br>
Does the BI simply trust the AI to hand it a correct hash?&nbsp; Does =
the AI
sign<br>
the CRL, pass it to the BI to finish signing and then verify, does the =
AI<br>
give the TBS to the BI, have the BI sign it and then return the =
signature to<br>
the AI to finish signing and publish?<br>
&nbsp;<br>
<b><span style=3D'font-weight:bold'>In section 5, the text says that an =
AI
unilaterally manages the CRL for a TAC CA:<br>
&nbsp;&nbsp;&nbsp;&nbsp; &quot;If AI determines that there is =
sufficient<br>
evidence of abuse to trace the TAC to the user, the AI revokes<br>
&nbsp; the TAC, by listing its serial number on the next CRL issued<br>
&nbsp; by the AI.<br>
</span></b>&nbsp;<br>
<b><span style=3D'font-weight:bold'>But the text failed to say how the =
AI does
this.&nbsp; Use of an indirect CRL may be the simplest approach to =
address this
issue.<br>
</span></b></span></font><font size=3D3 color=3D"#1f497d" face=3D"Times =
New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'>&nbsp;<br>
Requiring TACs to use indirect CRLS is the simplest way to address this
problem, however rfc5280 implementations are not required to process =
indirect
CRLs.&nbsp; This means you are going to either specify a protocol to =
allow for
direct CRLs to be jointly issued, or you are going to be non-rfc5280 =
compliant.<br>
</span></font><b><font size=3D3 color=3D"#333399" face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#333399;
font-weight:bold'>&nbsp;<br>
SANG) An RP that process indirect CRLs is not non-compliant, but you are
correct in noting that a compliant RP need not process indirect CRLs. =
Our
proposed resolution for this issue to create a second CA, under the TAC =
CA, and
have it be the CRL issuer for the EE certificates issued by the TAC CA. =
This CA
will have the cRLSign bit set in KU, but not the keyCertSign bit. The =
private
key for this CA will be held by the AI, so that it can issue CRLs =
unilaterally.
This CA certificate should be long-lived, just like the TAC CA =
certificate. It
will be the only CA certificate issued under the TAC CA certificate (and =
thus
it will be signed jointly by the BI and AI). We will recommend that the =
CRL for
this CA certificate be similarly long-lived, as it too need to be signed
jointly by the BI and AI. The EE TAC certificates MUST contain a CRLDP =
that
points to the CRL issued by this CA, to ensure that RPs know to check =
that CRL
vs. the CRL that covers this (the CRL) CA. Do you agree that this =
approach
meets all the relevant 5280 criteria for what RPs MUST support, and =
still
allows the AI to issue CRLs for TACs unilaterally?<br>
</span></font></b><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
4.&nbsp; Information should be placed in the document (Security =
Considerations
is<br>
fine) about the financial model associated with this issuing =
model.&nbsp; All</span></font><font
size=3D3 face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;
font-family:"Times New Roman"'><o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>user
financials need to be done with the BI and not the AI, the AI would<br>
have to get compensated by the BI for issued certificates.&nbsp; An =
associated<br>
item with this is the question of should the BI be able to influence<br>
contents of the certificate, specifically the lifetime of the =
certificate to<br>
correspond to the money paid.<br>
&nbsp;<br>
<b><span style=3D'font-weight:bold'>There is no requirement that the Ai =
and BI be
operated in a financially-separate fashion, but there also is no =
prohibition.
Your suggestion is a good one, i.e., adding some text to the security
considerations section to note that IF the AI and BI are financially
independent of one another, THEN the user MUST pay the BI (who already =
knows
the user's true identity), and the BI will compensate the Ai for each =
cert it
issues. We can probably leave it to AIs and BIs to coordinate the issue =
of cert
lifetime, for financial purposes. After all, the management of the CA is =
a
joint matter for the AI and BI, and we should assume they will be able =
to work
out these details.<br>
</span></b></span></font><font size=3D3 color=3D"#1f497d" face=3D"Times =
New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'>&nbsp;<br>
The first issue is that you cannot pay the AI for your =
certificate.&nbsp; If
you do, then you need to pay with some type of anonymous cash, and you =
must pay
using a completely anonymous protocol.&nbsp; I don't know of any way to
currently do this except in the realm of academia.<br>
I don't believe that you can leave the issue of things like lifetime =
out.&nbsp;
Let's say that the BI can allow for issuing of certificates for a period =
of
three months, one year and five years.&nbsp; The BI would need to =
communicate
this information as part of the token, or the BI and AI would need to =
have an
additional conversation before the AI builds the certificate in order to =
get
this piece of information.<br>
As an alternative, you could have different AI's for different length
certificates.&nbsp; This would imply that the BI cannot directly =
influence the
contents of the certificate, but would require that the BI tell the user =
what
the name of the AI to be used to issue the certificate.&nbsp; (Which =
might not
be a bad idea anyway.)<br>
</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span lang=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
</span></font><b><font size=3D3 color=3D"#333399" face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#333399;
font-weight:bold'>SANG) I agree with your point. There was no intent to =
require
a user to employ an anonymous or cash payment system to acquire a TAC. =
There
seem to be a few options here, as you noted. If the TAC CA issues =
certificates
with only one duration, this problem does not arise. If there are =
multiple
duration options, then there needs to be a way to signal to the AI which
duration the user has paid for. Having different AI instances (by name) =
is one
solution to the problem, or the token could be extended to accommodate =
your
other proposed solution. We will add text to the security considerations
section to suggest that a given <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">TAC</st1:City>
 <st1:State w:st=3D"on">CA</st1:State></st1:place> issued certificates =
with only
one lifetime, so avoid the complexity that might arise otherwise. We =
also will
note that if a TAC CA offers certificates of with different lifetimes, =
then it
will need to communicate this info from the BI to the AI in a way that =
does not
unduly compromise the anonymity of the user.<br>
</span></font></b><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
5.&nbsp; Renewal/Rekey operations are not covered by this =
document.&nbsp;
Either you<br>
need to state that these operations are never done, or you need to have =
a<br>
secure method of allowing the operation to be completed.&nbsp; In this =
case the<br>
Token no longer exists (or at least is no longer valid) and so the AI =
would<br>
need to prove to the BI that the BI should sign the certificate.&nbsp; =
One<br>
possible method would be to send the BI the TBSigned of the new =
certificate<br>
along with the old certificate allowing it to see that it had =
previously<br>
signed a certificate for subject name.&nbsp; It would still not be =
traceable
back<br>
to the user's Token, but would give assurances that the certificate =
should<br>
be issued.<br>
&nbsp;<br>
<b><span style=3D'font-weight:bold'>SANG) Good point. Renewal/Rekey =
should NOT be
supported. We will revise the text accordingly.<br>
</span></b></span></font><font size=3D3 color=3D"#1f497d" face=3D"Times =
New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'>&nbsp;<br>
JIM) This has some implementations for item =
1.<o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3D"#1f497d" face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'><br>
</span></font><b><font size=3D3 color=3D"#333399" face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#333399;
font-weight:bold'>SANG) Please refer to the response for item 1.<br>
</span></font></b><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
6. ALREADY RESOLVED<br>
&nbsp;<br>
7.&nbsp; Guidance needs to be supplied about how long items are to be =
kept in
the<br>
respective databases.&nbsp; Are these database entries expected to be =
kept<br>
forever once a certificate has been issued?&nbsp; Or are they only kept =
for<br>
approximately the life of the certificate.&nbsp; This is really impacted =
by the</span></font><font
size=3D3 face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;
font-family:"Times New Roman"'><o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>answer
to question #5 on rekey/renewal, but has some additional tracing<br>
implications beyond that.<br>
&nbsp;<br>
<b><span style=3D'font-weight:bold'>SANG) Since TACs are not suitable =
for NR (a
detail than can be added to the text), there does not appear to be a =
need to
retain data about TAC certs beyond their lifetime.<br>
</span></b></span></font><font size=3D3 color=3D"#1f497d" face=3D"Times =
New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'>&nbsp;<br>
JIM) An aggrieved entity may want to get the identity information about =
a
signer after the certificate has expired.&nbsp; This implies that there =
is at
least some minimum duration that the information needs to be kept for
traceability reasons.<br>
</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span lang=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
</span></font><b><font size=3D3 color=3D"#333399" face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#333399;
font-weight:bold'>SANG) Good point. We'll say that a TAC CA MUST =
describe in
its CP how long it will retain data about certificates it issued, beyond =
the
lifetime of these certificates. We also will note your rationale of why =
such
retention is appropriate.&nbsp; We do not plan to specify a minimum =
duration
for such retention, as that really is a per-CA matter.<br>
<br>
</span></font></b><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>8.&nbsp;
ALREADY RESOLVED<br>
<br>
9.&nbsp; If you believe that TAC permits both signature and =
encryption<br>
operations, then you need to address an additional problem.&nbsp; If a =
DSA<br>
signature certificate and a DH encryption certificate pair are needed, =
it is<br>
some protocols may require that they contain the same subject name, and =
thus<br>
would need to be issued at the same time.&nbsp; The current TAC protocol =
makes
no<br>
allowances for the ability to have the BI sign two independent =
certificates<br>
at the same time.&nbsp; This could be done by allowing the protocol to =
present<br>
multiple blinded hashes to the BI to be signed for a single token.<br>
&nbsp;<br>
<b><span style=3D'font-weight:bold'>SANG) The primary focus of the TAC =
work has
been web access. For that, a single cert is enough. But, you make a good =
point
that if one wants to use TACs with S/MIME, for example, dual cert =
issuance
needs to be supported. For now, we will stick with single cert issuance, =
with
it's implied limitations.<br>
</span></b></span></font><font size=3D3 color=3D"#1f497d" face=3D"Times =
New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'>&nbsp;<br>
JIM) This needs to be made explicit.<br>
</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span lang=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
</span></font><b><font size=3D3 color=3D"#333399" face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#333399;
font-weight:bold'>SANG) Please refer to the response for item 2.<br>
</span></font></b><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
10. ALREADY RESOLVED<br>
<br>
11.&nbsp; In section 5.1 Step 2, the statement is made that a TLS =
certificate<br>
should be used for doing the signature operation on a CMS object.&nbsp; =
You
might<br>
want to rethink this statement.&nbsp; While there is nothing technically =
wrong<br>
with this, some CMS validators would reject the signature since the =
EKU<br>
would not be correct.<br>
&nbsp;<br>
<b><span style=3D'font-weight:bold'>Does CMS specify a set of EKUs that =
are
acceptable for any use of CMS, or are you saying that the presence of =
any EKU
associated with TLS use might cause rejection because software (e.g., =
OpenSSL)
has some non-standard restrictions embedded in it?<br>
</span></b></span></font><font size=3D3 color=3D"#1f497d" face=3D"Times =
New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'>&nbsp;<br>
JIM) If there is an EKU in the certificate, and it is not one of the
&quot;acceptable&quot; EKUs for CMS, it is possible that some =
implementations
might reject the certificate.&nbsp; This is highly dependent on the
implementation.&nbsp; I don't know if this is a problem, but it =
potentially
could be.&nbsp;&nbsp; One possible solution would be to create an EKU
specifically for this operation.<br>
&nbsp;<br>
</span></font><b><font size=3D3 color=3D"#333399" face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#333399;
font-weight:bold'>SANG) Sorry for this misunderstanding with regard to =
TLS
certificates. In section 5.1 Step 2, a TLS certificate is used only for
security channel establishment, not for verifying a signature on a CMS =
object.
See the end of section 5.1 Step 1, cited below. Does the following text =
address
your concern?<br>
<br>
</span></font></b><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;&quot;</span></font><font
size=3D3 color=3D"#333399" face=3D"Times New Roman"><span lang=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#333399'>It is
RECOMMENDED that the UserKey be a random or pseudo-random =
</span></font><font
size=3D3 color=3D"#333399" face=3DCourier><span lang=3DEN-US =
style=3D'font-size:12.0pt;
font-family:Courier;color:#333399'>value. <o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3D"#333399" =
face=3DCourier><span
lang=3DEN-US =
style=3D'font-size:12.0pt;font-family:Courier;color:#333399'>Whenever
the BI passes a UserKey to an external party, or accepts the UserKey =
from an
external party <o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3D"#333399" =
face=3DCourier><span
lang=3DEN-US =
style=3D'font-size:12.0pt;font-family:Courier;color:#333399'>(e.g.,
the AI), the value is embedded in digitally signed CMS object called =
a<br>
</span></font><font size=3D3 color=3Dblack face=3DCourier><span =
lang=3DEN-US
style=3D'font-size:12.0pt;font-family:Courier;color:black'>&nbsp;&nbsp;</=
span></font><font
size=3D3 color=3D"#333399" face=3DCourier><span lang=3DEN-US =
style=3D'font-size:12.0pt;
font-family:Courier;color:#333399'> Token, accompanied by the time stamp =
noted
above. The signature on a Token is generated by =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3D"#333399" =
face=3DCourier><span
lang=3DEN-US =
style=3D'font-size:12.0pt;font-family:Courier;color:#333399'>the BI
using a private key employed only for this purpose.&quot;<br>
</span></font><font size=3D3 color=3Dblack face=3DCourier><span =
lang=3DEN-US
style=3D'font-size:12.0pt;font-family:Courier;color:black'>&nbsp;<br>
</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span lang=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
12.&nbsp; ALREADY RESOLVED<br>
&nbsp;<br>
13.&nbsp; I would like to see for each of the steps in 5.1, an =
explanation of
who<br>
needs to be protected against for the communication.&nbsp; This will =
better
allow<br>
others to decide on how to implement this with non-TLS =
communications.&nbsp;
For<br>
example, could this be done with e-mail or are the security requirements =
not<br>
met?<br>
&nbsp;<br>
<b><span style=3D'font-weight:bold'>Not sure what you mean by &quot;who =
needs to
be protected against for the communication.&quot; We can explain in more =
detail
what security features are required at each step, but there is already =
some
text addressing this, for at least some steps. For example, in step 2, =
the
document says:</span></b></span></font><font size=3D3 face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
<b><span style=3D'font-weight:bold'>&quot;The secure channel is required =
here to
prevent a wiretapper from<br>
being able to acquire the Token. For example, if the user<br>
establishes a one-way authenticated TLS session to the BI in<br>
Step 1, this session could be used to pass the Token back to<br>
the user.</span></b>&quot;<br>
</span></font><font size=3D3 color=3D"#1f497d" face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'>&nbsp;<br>
There are cases where you need to explicitly prevent either the AI or BI =
from
getting the information, but may not need to protect against a general
wiretapper.&nbsp; For example, if the client and BI transaction is open =
(except
to the AI), this may not help an eavesdropper as long as the client/AI
transaction is completely sealed.&nbsp; The eavesdropper would be in =
same
situation in this case as BI, it knows some information but not enough =
to
complete the trace without the cooperation of the AI.<br>
</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span lang=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
&nbsp;</span></font><b><font size=3D3 color=3D"#333399" face=3D"Times =
New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#333399;
font-weight:bold'>SANG) We requested the secure channel in open =
communications,
based on the information that is valuable from security point of =
view.<br>
</span></font></b><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
14. ALREADY RESOLVED<br>
&nbsp;<br>
15. ALREADY RESOLVED<br>
&nbsp;<br>
16. ALREADY RESOLVED<br>
&nbsp;<br>
17.&nbsp; In section 5.2, step C - should the BI also conduct its own
assessment<br>
of the fact that the aggrieved party's case before releasing the<br>
information?<br>
&nbsp;<br>
<b><span style=3D'font-weight:bold'>BI could do so. We can add text to =
say that
is an option, but it would be something that each TAC CA decides for =
itself,
and declares in its CP and details in the CPS.<br>
</span></b></span></font><font size=3D3 color=3D"#1f497d" face=3D"Times =
New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#1F497D'>&nbsp;<br>
Not requiring this would allow for a rouge AI to get the =
information.&nbsp; It
would create a pretend aggrieved party, provide the details to that =
party and
query the BI.&nbsp; The BI doing no checks would hand over the =
information no
questions asked.<br>
</span></font><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span lang=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
</span></font><b><font size=3D3 color=3D"#333399" face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:#333399;
font-weight:bold'>SANG) Fair point. We will change the text to state =
that BI
should conduct its own assessment of the aggrieved party's case before
releasing the user ID.<br>
</span></font></b><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman";color:black'>&nbsp;<br>
18. ALREADY RESOLVED<br>
&nbsp;<br>
19. ALREADY RESOLVED</span></font><font size=3D3 face=3D"Times New =
Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman"'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B9=D9=C5=C1><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D=B9=D9=C5=C1><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0028_01C92D28.2C5EC580--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9BLH7GI007092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2008 14:17:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9BLH7Yt007091; Sat, 11 Oct 2008 14:17:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9BLH2dm007077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2008 14:17:03 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240836c516c6e25589@[10.20.30.152]>
In-Reply-To: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC>
References: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC>
Date: Sat, 11 Oct 2008 14:17:00 -0700
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:23 PM +0200 10/11/08, Anders Rundgren wrote:
>According to many cryptographers you shouldn't sign and encrypt with
>the same RSA key-pair. 

References please? NIST says you must not do so in SP 800-57, section 5.2, but not because:

>The reason appears to be that this could lead
>to exposure of the private key. 


--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9BJ3PPO099061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2008 12:03:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9BJ3Pwn099060; Sat, 11 Oct 2008 12:03:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9BJ3DOa099043 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Sat, 11 Oct 2008 12:03:24 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed
Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <[e-mail]> for [e-mail]; Sat, 11 Oct 2008 14:03:13 -0500 (CDT)
Received: from [192.168.0.14] ([97.92.189.144]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Sat, 11 Oct 2008 14:03:10 -0500 (CDT)
Date: Sat, 11 Oct 2008 14:03:11 -0500
From: Eric Norman <[e-mail]>
Subject: Re: Signing and Encrypting with the same key?
In-reply-to: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC>
To: [e-mail]
Message-id: <[e-mail]>
X-Mailer: Apple Mail (2.624)
X-Spam-Report: AuthenticatedSender=yes, SenderIP=97.92.189.144
X-Spam-PmxInfo: Server=avs-10, Version=5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.10.11.184622, SenderIP=97.92.189.144
References: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC>
Sender: [e-mail]
Precedence: 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 Oct 11, 2008, at 1:23 PM, Anders Rundgren wrote:

>
> According to many cryptographers you shouldn't sign and encrypt with
> the same RSA key-pair.  The reason appears to be that this could lead
> to exposure of the private key.  Now to the question.

That's not the reason.  Many believe that you can't have
non-repudiation and key escrow with the same key.

> If the above is true, what stops a recipient of a signature (and thus 
> the
> signature public key), to perform any number of encryptions with it in
> order to reveal the associated private key?

What would stop someone from doing this even if it's a
"signature only" key.  A keypair is a keypair.

Eric Norman



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9BIO59S096521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2008 11:24:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9BIO5Hm096520; Sat, 11 Oct 2008 11:24:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9BINsuu096508 for <[e-mail]>; Sat, 11 Oct 2008 11:24:05 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA95016FCBA9 for [e-mail]; Sat, 11 Oct 2008 20:23:53 +0200
Message-ID: <8A6EA14ADC114AD78F51BF019BA5D793@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Signing and Encrypting with the same key?
Date: Sat, 11 Oct 2008 20:23:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

According to many cryptographers you shouldn't sign and encrypt with
the same RSA key-pair.  The reason appears to be that this could lead
to exposure of the private key.  Now to the question.

If the above is true, what stops a recipient of a signature (and thus the
signature public key), to perform any number of encryptions with it in
order to reveal the associated private key?

Has the attack been proved in practice?

The reason for asking is because I'm working with a scheme where
cryptographic containers are equipped with device-keys and certificates
that are used for device authentication, key attestations, and encryption
(for secret data imports).

Although the containers without doubt can deal with multiple keys,
multiple keys could give containers "split personas" unless you manage
to specify the associated PKI in a very detailed way, something
which has proven to be hard when there is no uniting identity concept
like in e-mail certificates.

Regards
Anders Rundgren
WebPKI.org



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9BD7UUb073418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2008 06:07:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9BD7UoL073417; Sat, 11 Oct 2008 06:07:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9BD7IT9073397 for <[e-mail]>; Sat, 11 Oct 2008 06:07:29 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 15808 invoked from network); 11 Oct 2008 12:54:02 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;11 Oct 2008 12:54:02 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 11 Oct 2008 12:54:02 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C92BA2.49BA7EFA"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Sat, 11 Oct 2008 09:07:17 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: AckkCUREtMVRjHr8Tbyvr7tGamq2+wEhfTXQAMS01iA=
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C92BA2.49BA7EFA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I vote yes to adopting this as a PKIX work item.  Specification details
can be resolved after the draft is accepted as a working group draft.

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Tuesday, October 07, 2008 11:41 AM
To: Stephen Kent; [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt



I vote NO to adopting this work as a PKIX work item.

=20

I do vote for a continued debate on the rationale for this proposal but
I have yet not seen any good motivation for doing this work.

=20

The rational for my NO vote is:

=20

1)      To start with, a certificate is a very bad place to manage
clearance. I can at most agree to it's use in AA certificates but
clearance is in its nature fundamentally different from Public Key
certificates as the certificate is an assertion of an entity's key and
identity, which is generic and static, while clearance is context
specific and dynamic.

2)      If clearance would make it into certificates, then that should
be more than enough that we reasonable could handle as a standard. To
specify constraints for such information is to ask for big trouble.

=20

Elaborating on the difficulties to specify clearance constraints I would
like to highlight some quotes from the draft:

=20

The draft is taking several shortcuts when it comes to clearance
constraints processing.

The class list is specified but at the same time defined within the
context of PolicyId. This means that there is no generic way to compare
ClassList bits, This is highlighted by the following quote from 4.1.1.3:

=20

       -- Calculate securityCategories intersection in accordance with
          guidelines associated with the security policy represented by
          the policyID.

=20

So the logic for clearance constraints processing is performed per
PolicyId but the logic may be different for every PolicyId.

In my world, this does not fly and is not implementable.

=20

I also have a number of other problems:

=20

*         This draft makes clearance processing authoritative over
accepting certificate paths. I foresee problems with legacy
implementations of PKI:

=20

   If more than one entry with
   the same policyId is present in AuthorityClearanceConstraints
   certificate extension, the certification path is rejected.

=20

*         This draft mandates processing of extensions in TA
certificates (root) which can be argued to be incompatible with RFC 3280

=20

=20

Conclusion:=20

Before this work is accepted as work group item, it must show that
clearance constraints processing is possible in a reasonable and
meaningful manner, and hence is worth working on.=20

If we decide to work on this item, I foresee a major design commitment
for the PKIX group and an even bigger commitment on behalf of
implementers.

As such, I also encourage use cases that motivates the effort.

=20

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: den 1 oktober 2008 22:24
To: [e-mail]
Subject: draft-turner-caclearanceconstraints-01.txt

=20

It appears to have been two months since there was any PKIX list
discussion of this document. In Dublin it was agreed that we would
conduct a straw poll on whether to adopt this as a WG item, but I failed
to do so prior to leaving for a week-long meeting in NZ and 3-week
vacation in KE.  My bad.

=20

So, I'd like to initiate a 1-week straw poll starting 10/3.

=20

Sean, the minutes indicated that you would tell me what status you are
seeking for the document, and I have no record of a message from you on
that topic, so please provide that vital piece of info to the list
before we start the poll.

=20

Thanks,

=20

Steve


------_=_NextPart_001_01C92BA2.49BA7EFA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20
"urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20
"urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =
=3D=20
"urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20
"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20
"urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20
"http://www.w3.org/TR/REC-html40" xmlns:q =3D=20
"http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 =
=3D=20
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20
"http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20
"http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20
"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec =
=3D=20
"http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20
"http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf =3D=20
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf =3D=20
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver =3D=20
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m =
=3D=20
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels =3D=20
"http://schemas.openxmlformats.org/package/2006/relationships" =
xmlns:ex12t =3D=20
"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m =
=3D=20
"http://schemas.microsoft.com/exchange/services/2006/messages" XMLNS:Z =
=3D=20
"urn:schemas-microsoft-com:" xmlns:st =3D =
"=01"><HEAD><TITLE>draft-turner-caclearanceconstraints-01.txt</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16705" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: SimSun;
}
@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @SimSun;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt =
70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
PRE {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"; =
mso-style-priority: 99; mso-style-link: "HTML Preformatted Char"
}
P.MsoListParagraph {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 36pt; FONT-FAMILY: "Times New =
Roman","serif"; mso-style-priority: 34
}
LI.MsoListParagraph {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 36pt; FONT-FAMILY: "Times New =
Roman","serif"; mso-style-priority: 34
}
DIV.MsoListParagraph {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 36pt; FONT-FAMILY: "Times New =
Roman","serif"; mso-style-priority: 34
}
SPAN.EmailStyle17 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal-reply
}
SPAN.HTMLPreformattedChar {
	FONT-FAMILY: "Courier New"; mso-style-priority: 99; mso-style-link: =
"HTML Preformatted"; mso-style-name: "HTML Preformatted Char"
}
SPAN.grey {
	mso-style-name: grey
}
SPAN.break {
	mso-style-name: break
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0cm
}
UL {
	MARGIN-BOTTOM: 0cm
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DSV vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D078350513-11102008>I vote yes to adopting this as a PKIX work=20
item.&nbsp;&nbsp;Specification details can be resolved after the draft =
is=20
accepted as a working group draft.</SPAN></FONT></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>Stefan=20
Santesson<BR><B>Sent:</B> Tuesday, October 07, 2008 11:41 =
AM<BR><B>To:</B>=20
Stephen Kent; [e-mail]<BR><B>Subject:</B> RE:=20
draft-turner-caclearanceconstraints-01.txt<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: red; FONT-FAMILY: =
'Calibri','sans-serif'">I vote=20
NO to adopting this work as a PKIX work item.<o:p></o:p></SPAN></A></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">I=20
do vote for a continued debate on the rationale for this proposal but I =
have yet=20
not seen any good motivation for doing this work.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><U><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">The=20
rational for my NO vote is:<o:p></o:p></SPAN></U></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -18pt; mso-list: l2 =
level1 lfo1"><![if !supportLists]><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><SPAN=20
style=3D"mso-list: Ignore">1)<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><![endif]><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">To=20
start with, a certificate is a very bad place to manage clearance. I can =
at most=20
agree to it&#8217;s use in AA certificates but clearance is in its =
nature=20
fundamentally different from Public Key certificates as the certificate =
is an=20
assertion of an entity&#8217;s key and identity, which is generic and =
static, while=20
clearance is context specific and dynamic.<o:p></o:p></SPAN></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -18pt; mso-list: l2 =
level1 lfo1"><![if !supportLists]><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><SPAN=20
style=3D"mso-list: Ignore">2)<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><![endif]><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">If=20
clearance would make it into certificates, then that should be more than =
enough=20
that we reasonable could handle as a standard. To specify constraints =
for such=20
information is to ask for big trouble.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Elaborating=20
on the difficulties to specify clearance constraints I would like to =
highlight=20
some quotes from the draft:<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">The=20
draft is taking several shortcuts when it comes to clearance constraints =

processing.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">The=20
class list is specified but at the same time defined within the context =
of=20
PolicyId. This means that there is no generic way to compare ClassList =
bits,=20
This is highlighted by the following quote from =
4.1.1.3:<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P><PRE><SPAN =
lang=3DEN-US>&nbsp;</SPAN><SPAN lang=3DEN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- Calculate securityCategories intersection in accordance =
with<o:p></o:p></SPAN></PRE><PRE><SPAN =
lang=3DEN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
guidelines associated with the security policy represented =
by<o:p></o:p></SPAN></PRE><PRE><SPAN =
lang=3DEN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
policyID.<o:p></o:p></SPAN></PRE>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">So=20
the logic for clearance constraints processing is performed per PolicyId =
but the=20
logic may be different for every PolicyId.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">In=20
my world, this does not fly and is not =
implementable.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">I=20
also have a number of other problems:<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -18pt; mso-list: l0 =
level1 lfo3"><![if !supportLists]><SPAN=20
lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
Symbol"><SPAN=20
style=3D"mso-list: Ignore">&middot;<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><![endif]><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">This=20
draft makes clearance processing authoritative over accepting =
certificate paths.=20
I foresee problems with legacy implementations of =
PKI:<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P><PRE><SPAN =
lang=3DEN-US>&nbsp;</SPAN><SPAN lang=3DEN>&nbsp; If more than one entry =
with<o:p></o:p></SPAN></PRE><PRE><SPAN lang=3DEN>&nbsp;&nbsp; the same =
policyId is present in =
AuthorityClearanceConstraints<o:p></o:p></SPAN></PRE><PRE><SPAN =
lang=3DEN>&nbsp;&nbsp; certificate extension, the certification path is =
rejected.<o:p></o:p></SPAN></PRE>
<P class=3DMsoNormal><SPAN lang=3DEN=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoListParagraph style=3D"TEXT-INDENT: -18pt; mso-list: l0 =
level1 lfo3"><![if !supportLists]><SPAN=20
lang=3DEN-US style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
Symbol"><SPAN=20
style=3D"mso-list: Ignore">&middot;<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><![endif]><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">This=20
draft mandates processing of extensions in TA certificates (root) which =
can be=20
argued to be incompatible with RFC 3280<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Conclusion:=20
<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Before=20
this work is accepted as work group item, it must show that clearance=20
constraints processing is possible in a reasonable and meaningful =
manner, and=20
hence is worth working on. <o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">If=20
we decide to work on this item, I foresee a major design commitment for =
the PKIX=20
group and an even bigger commitment on behalf of=20
implementers.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">As=20
such, I also encourage use cases that motivates the=20
effort.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<DIV>
<P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
Santesson</SPAN></B><SPAN lang=3DEN-GB=20
style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Senior=20
Program Manager</SPAN><SPAN lang=3DEN-GB=20
style=3D"COLOR: navy"><o:p></o:p></SPAN></P>
<P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Windows=20
Security, Standards</SPAN></B><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P></DIV>
<P class=3DMsoNormal><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<DIV=20
style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
<DIV>
<DIV=20
style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=3DMsoNormal><B><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
lang=3DEN-US style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">=20
[e-mail] [mailto:[e-mail]] <B>On =
Behalf=20
Of </B>Stephen Kent<BR><B>Sent:</B> den 1 oktober 2008 =
22:24<BR><B>To:</B>=20
[e-mail]<BR><B>Subject:</B>=20
draft-turner-caclearanceconstraints-01.txt<o:p></o:p></SPAN></P></DIV></D=
IV>
<P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
<DIV>
<P class=3DMsoNormal>It appears to have been two months since there was =
any PKIX=20
list discussion of this document. In Dublin it was agreed that we would =
conduct=20
a straw poll on whether to adopt this as a WG item, but I failed to do =
so prior=20
to leaving for a week-long meeting in NZ and 3-week vacation in =
KE.&nbsp; My=20
bad.<o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=3DMsoNormal>So, I'd like to initiate a 1-week straw poll =
starting=20
10/3.<o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><B>Sean</B>, the minutes indicated that you would =
tell me=20
what status you are seeking for the document, and I have no record of a =
message=20
from you on that topic, so please provide that vital piece of info to =
the list=20
before we start the poll.<o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P class=3DMsoNormal>Thanks,<o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><o:p>&nbsp;</o:p></P></DIV>
<DIV>
<P =
class=3DMsoNormal>Steve<o:p></o:p></P></DIV></DIV></DIV></BODY></HTML>

------_=_NextPart_001_01C92BA2.49BA7EFA--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9AMGYHM024775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Oct 2008 15:16:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9AMGYRV024774; Fri, 10 Oct 2008 15:16:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp132.sat.emailsrvr.com (smtp132.sat.emailsrvr.com [66.216.121.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9AMGN9v024762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 10 Oct 2008 15:16:33 -0700 (MST) (envelope-from [e-mail])
Received: from relay3.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay3.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id F03F825AC2C for <[e-mail]>; Fri, 10 Oct 2008 18:16:22 -0400 (EDT)
Received: by relay3.relay.sat.mlsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTP id 1FA1725AC38 for <[e-mail]>; Fri, 10 Oct 2008 18:16:21 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Sat, 11 Oct 2008 09:15:32 +1100
From: Stephen Wilson <[e-mail]>
Reply-To: [e-mail]
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: What are certificates fundamentally all about?  [was: draft-turner-caclearanceconstraints-01.txt]
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan Santesson wrote (quoted in reverse):
> 2) If clearance would make it into certificates, then that should 
> be more than enough that we reasonable could handle as a standard. To 
> specify constraints for such information is to ask for big trouble.

I suspect you're right about that -- too much to bear in a standard.

However I don't agree that:

> 1) ... a certificate is a very bad place to manage 
> clearance. [Clearance] is in its nature fundamentally different from Public 
> Key certificates as the certificate is an assertion of an entity’s key and 
> identity, which is generic and static ... 

Back in March at the NIST IDtrust2008 conference I presented a paper 
called "Public Key Superstructure" in which I argued for an adjusted 
view of what public key certificates are "fundamentally" all about.  I 
submit that the view that PKCs are purely an assertion of an entity’s 
key and [generic and static] identity has led to most of the historic 
problems with PKI, because it predicts a single all-purpose generic 
certificate and in the process, overloads a single "identity".

My paper on these issues is at 
http://middleware.internet2.edu/idtrust/2008/papers/07-wilson-public-key-superstructure.pdf

In line with contemporary thinking about identity plurality (as per e.g. 
The Laws of Identity) I think it's more powerful to construct multiple 
PKCs with each representing a different identity in a particular context.

Then you can subtly adjust the conception of a PKC as being "an 
assertion of an entity’s key and a RELATIVELY STATIC identity IN A 
DEFINED CONTEXT".  A flexible interpretation of "identity in a defined 
context" embraces things like my identity as an chartered engineer, my 
identity as a business owner, my identity as a health insurance 
subscriber, my identity as a bank account holder.  In each of these 
scenarios, it would be very powerful for me to carry a separate 
dedicated certificate with which to sign specific types of transactions 
(e.g. engineering test reports, tax returns, health insurance claims, 
and payment instructions respectively).  That is, four different 
certificates all independently registered and managed, tightly coupled 
to regular customer relationship management processes, probably carried 
on separate smartcards.

In my Public Key Superstructure paper I argued that it might be clearer 
to refer to these 'identities' as "Relationships"; in practice, the 
relationship is vouched for by an RA that has some connection to the 
Subject.  The Policy OID suffices to uniquely point to a comprehensive 
definition of exactly what that relationship is, the processes that 
underpin it, the context in which the relationship is meaningful and, by 
extension, the applications for which the PKC is meaningful.

To illustrate the point, I don't actually see any reason in principle 
why a PKC could not be used to assert my identity (or relationship) as 
'a person cleared to Top Secret' so long as that relationship is 
relatively long lived; say a few months.  Path validation is a cinch: 
the relationship I would have express in my PKC is with a particular 
vetting agency, which would appear in the path, with a Policy OID in the 
Subject PKC that specifies the clearance protocol.  The Public Key of 
the vetting agency -- or a higher Root Key -- would be the trust anchor 
needed in a whole class of applications processing my digital signature 
applied to Secret documents.

Cheers,

Stephen Wilson
Managing Director
Lockstep Technologies

Phone [phone]

www.lockstep.com.au/technologies
-------------------
  * Global Security Challenge Asia Top Five 2008
  * Australian Technology Showcase    2008
  * AusIndustry COMET Grant Recipient  2007
  * ICT Secrets of Innovation Finalist  2007
  * Anthill / PwC Cool Company Finalist  2007
-------------------
Lockstep Consulting provides independent specialist advice and analysis
on authentication, PKI and smartcards.  Lockstep Technologies develops
unique new smart ID solutions that safeguard identity and privacy.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9AKHgHc018244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Oct 2008 13:17:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9AKHgWs018243; Fri, 10 Oct 2008 13:17:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9AKHTPj018233 for <[e-mail]>; Fri, 10 Oct 2008 13:17:39 -0700 (MST) (envelope-from [e-mail])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0D81F294003; Fri, 10 Oct 2008 22:17:18 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 46354294001 for <[e-mail]>; Fri, 10 Oct 2008 22:17:16 +0200 (IST)
Received: from [172.31.21.116] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9AKHAke009557 for <[e-mail]>; Fri, 10 Oct 2008 22:17:10 +0200 (IST)
Message-Id: <[e-mail]>
From: Yoav Nir <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Content-Type: multipart/alternative; boundary=Apple-Mail-1-549493758
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: draft-turner-caclearanceconstraints-01.txt
Date: Fri, 10 Oct 2008 22:17:09 +0200
References: <p0624051bc5098b483ca0@[128.89.89.71]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Apple-Mail-1-549493758
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

+1

On Oct 7, 2008, at 5:40 PM, Stefan Santesson wrote:

> I vote NO to adopting this work as a PKIX work item.
>
> I do vote for a continued debate on the rationale for this proposal =20=

> but I have yet not seen any good motivation for doing this work.
>
> The rational for my NO vote is:
>
> 1)      To start with, a certificate is a very bad place to manage =20
> clearance. I can at most agree to it=92s use in AA certificates but =20=

> clearance is in its nature fundamentally different from Public Key =20
> certificates as the certificate is an assertion of an entity=92s key =20=

> and identity, which is generic and static, while clearance is =20
> context specific and dynamic.
> 2)      If clearance would make it into certificates, then that =20
> should be more than enough that we reasonable could handle as a =20
> standard. To specify constraints for such information is to ask for =20=

> big trouble.
>
> Elaborating on the difficulties to specify clearance constraints I =20
> would like to highlight some quotes from the draft:
>
> The draft is taking several shortcuts when it comes to clearance =20
> constraints processing.
> The class list is specified but at the same time defined within the =20=

> context of PolicyId. This means that there is no generic way to =20
> compare ClassList bits, This is highlighted by the following quote =20
> from 4.1.1.3:
>
>        -- Calculate securityCategories intersection in accordance with
>           guidelines associated with the security policy represented =20=

> by
>           the policyID.
>
> So the logic for clearance constraints processing is performed per =20
> PolicyId but the logic may be different for every PolicyId.
> In my world, this does not fly and is not implementable.
>
> I also have a number of other problems:
>
> =B7         This draft makes clearance processing authoritative over =20=

> accepting certificate paths. I foresee problems with legacy =20
> implementations of PKI:
>
>    If more than one entry with
>    the same policyId is present in AuthorityClearanceConstraints
>    certificate extension, the certification path is rejected.
>
> =B7         This draft mandates processing of extensions in TA =20
> certificates (root) which can be argued to be incompatible with RFC =20=

> 3280
>
>
> Conclusion:
> Before this work is accepted as work group item, it must show that =20
> clearance constraints processing is possible in a reasonable and =20
> meaningful manner, and hence is worth working on.
> If we decide to work on this item, I foresee a major design =20
> commitment for the PKIX group and an even bigger commitment on =20
> behalf of implementers.
> As such, I also encourage use cases that motivates the effort.
>
>
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
> From: [e-mail] =
[mailto:[e-mail]=20
> ] On Behalf Of Stephen Kent
> Sent: den 1 oktober 2008 22:24
> To: [e-mail]
> Subject: draft-turner-caclearanceconstraints-01.txt
>
> It appears to have been two months since there was any PKIX list =20
> discussion of this document. In Dublin it was agreed that we would =20
> conduct a straw poll on whether to adopt this as a WG item, but I =20
> failed to do so prior to leaving for a week-long meeting in NZ and 3-=20=

> week vacation in KE.  My bad.
>
> So, I'd like to initiate a 1-week straw poll starting 10/3.
>
> Sean, the minutes indicated that you would tell me what status you =20
> are seeking for the document, and I have no record of a message from =20=

> you on that topic, so please provide that vital piece of info to the =20=

> list before we start the poll.
>
> Thanks,
>
> Steve
>
>
> Scanned by Check Point Total Security Gateway.
>


--Apple-Mail-1-549493758
Content-Type: text/html;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">+1<div><br><div><div>On Oct 7, =
2008, at 5:40 PM, Stefan Santesson wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Arial; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><div lang=3D"SV" link=3D"blue" =
vlink=3D"purple"><div class=3D"Section1"><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><a =
name=3D"_MailEndCompose"><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: red; ">I vote NO to adopting =
this work as a PKIX work item.<o:p></o:p></span></a></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">I do vote for a continued debate on the rationale =
for this proposal but I have yet not seen any good motivation for doing =
this work.<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><u><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">The =
rational for my NO vote is:<o:p></o:p></span></u></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"text-indent: -18pt; =
margin-top: 0cm; margin-right: 0cm; margin-left: 36pt; margin-bottom: =
0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; =
"><span lang=3D"EN-US" style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); "><span>1)<span style=3D"font: =
normal normal normal 7pt/normal 'Times New Roman'; =
">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span></span></span></span><span =
lang=3D"EN-US" style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); ">To start with, a certificate is a =
very bad place to manage clearance. I can at most agree to it=92s use in =
AA certificates but clearance is in its nature fundamentally different =
from Public Key certificates as the certificate is an assertion of an =
entity=92s key and identity, which is generic and static, while =
clearance is context specific and dynamic.<o:p></o:p></span></div><div =
style=3D"text-indent: -18pt; margin-top: 0cm; margin-right: 0cm; =
margin-left: 36pt; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><span>2)<span style=3D"font: normal normal normal =
7pt/normal 'Times New Roman'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span></span></span></span><span =
lang=3D"EN-US" style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); ">If clearance would make it into =
certificates, then that should be more than enough that we reasonable =
could handle as a standard. To specify constraints for such information =
is to ask for big trouble.<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">Elaborating on the difficulties to specify clearance =
constraints I would like to highlight some quotes from the =
draft:<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">The draft =
is taking several shortcuts when it comes to clearance constraints =
processing.<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">The class list is specified but at the same time =
defined within the context of PolicyId. This means that there is no =
generic way to compare ClassList bits, This is highlighted by the =
following quote from 4.1.1.3:<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><pre style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Courier New'; "><span =
lang=3D"EN-US">&nbsp;</span><span =
lang=3D"EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Calculate =
securityCategories intersection in accordance =
with<o:p></o:p></span></pre><pre style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Courier New'; "><span =
lang=3D"EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
guidelines associated with the security policy represented =
by<o:p></o:p></span></pre><pre style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Courier New'; "><span =
lang=3D"EN">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
policyID.<o:p></o:p></span></pre><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">So the =
logic for clearance constraints processing is performed per PolicyId but =
the logic may be different for every =
PolicyId.<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">In my world, this does not fly and is not =
implementable.<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">I also have =
a number of other problems:<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"text-indent: -18pt; =
margin-top: 0cm; margin-right: 0cm; margin-left: 36pt; margin-bottom: =
0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; =
"><span lang=3D"EN-US" style=3D"font-size: 11pt; font-family: Symbol; =
color: rgb(31, 73, 125); "><span>=B7<span style=3D"font: normal normal =
normal 7pt/normal 'Times New Roman'; =
">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span></span></span></span><span =
lang=3D"EN-US" style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); ">This draft makes clearance =
processing authoritative over accepting certificate paths. I foresee =
problems with legacy implementations of PKI:<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><pre style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Courier New'; "><span =
lang=3D"EN-US">&nbsp;</span><span lang=3D"EN">&nbsp; If more than one =
entry with<o:p></o:p></span></pre><pre style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Courier New'; "><span lang=3D"EN">&nbsp;&nbsp; the =
same policyId is present in =
AuthorityClearanceConstraints<o:p></o:p></span></pre><pre =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Courier New'; =
"><span lang=3D"EN">&nbsp;&nbsp; certificate extension, the =
certification path is rejected.<o:p></o:p></span></pre><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"text-indent: -18pt; =
margin-top: 0cm; margin-right: 0cm; margin-left: 36pt; margin-bottom: =
0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; =
"><span lang=3D"EN-US" style=3D"font-size: 11pt; font-family: Symbol; =
color: rgb(31, 73, 125); "><span>=B7<span style=3D"font: normal normal =
normal 7pt/normal 'Times New Roman'; =
">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span></span></span></span><span =
lang=3D"EN-US" style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); ">This draft mandates processing of =
extensions in TA certificates (root) which can be argued to be =
incompatible with RFC 3280<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
">Conclusion:<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">Before this work is accepted as work group item, it =
must show that clearance constraints processing is possible in a =
reasonable and meaningful manner, and hence is worth working =
on.<o:p></o:p></span></div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">If we decide to work on this item, I foresee a major =
design commitment for the PKIX group and an even bigger commitment on =
behalf of implementers.<o:p></o:p></span></div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
lang=3D"EN-US" style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); ">As such, I also encourage use =
cases that motivates the effort.<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span lang=3D"EN-US" style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><b><span lang=3D"EN-GB" =
style=3D"font-size: 10pt; font-family: Arial, sans-serif; color: maroon; =
">Stefan Santesson</span></b><span lang=3D"EN-GB" style=3D"color: =
rgb(31, 73, 125); "><o:p></o:p></span></div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
lang=3D"EN-GB" style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(64, 0, 64); ">Senior Program Manager</span><span lang=3D"EN-GB"=
 style=3D"color: navy; "><o:p></o:p></span></div><div style=3D"margin-top:=
 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span =
lang=3D"EN-GB" style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(64, 0, 64); ">Windows Security, Standards</span></b><span =
lang=3D"EN-US" style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); =
"><o:p></o:p></span></div></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"EN-US" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div =
style=3D"border-top-style: none; border-right-style: none; =
border-bottom-style: none; border-width: initial; border-color: initial; =
border-left-style: solid; border-left-color: blue; border-left-width: =
1.5pt; padding-top: 0cm; padding-right: 0cm; padding-bottom: 0cm; =
padding-left: 4pt; "><div><div style=3D"border-right-style: none; =
border-bottom-style: none; border-left-style: none; border-width: =
initial; border-color: initial; border-top-style: solid; =
border-top-color: rgb(181, 196, 223); border-top-width: 1pt; =
padding-top: 3pt; padding-right: 0cm; padding-bottom: 0cm; padding-left: =
0cm; "><div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: =
0cm; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><b><span lang=3D"EN-US" style=3D"font-size: 10pt; =
font-family: Tahoma, sans-serif; ">From:</span></b><span lang=3D"EN-US" =
style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; "><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[e-mail]" style=3D"color: blue; =
text-decoration: underline; ">[e-mail]</a><span =
class=3D"Apple-converted-space">&nbsp;</span>[<a =
href=3D"mailto:[e-mail]" style=3D"color: blue; =
text-decoration: underline; =
">mailto:[e-mail]</a>]<span =
class=3D"Apple-converted-space">&nbsp;</span><b>On Behalf Of<span =
class=3D"Apple-converted-space">&nbsp;</span></b>Stephen =
Kent<br><b>Sent:</b><span class=3D"Apple-converted-space">&nbsp;</span>den=
 1 oktober 2008 22:24<br><b>To:</b><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[e-mail]" style=3D"color: blue; text-decoration: =
underline; ">[e-mail]</a><br><b>Subject:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>draft-turner-caclearanceconst=
raints-01.txt<o:p></o:p></span></div></div></div><div style=3D"margin-top:=
 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">It appears to have been =
two months since there was any PKIX list discussion of this document. In =
Dublin it was agreed that we would conduct a straw poll on whether to =
adopt this as a WG item, but I failed to do so prior to leaving for a =
week-long meeting in NZ and 3-week vacation in KE.&nbsp; My =
bad.<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">So, I'd like to initiate =
a 1-week straw poll starting 10/3.<o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><o:p>&nbsp;</o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><b>Sean</b>, the minutes indicated that you would tell =
me what status you are seeking for the document, and I have no record of =
a message from you on that topic, so please provide that vital piece of =
info to the list before we start the =
poll.<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
">Thanks,<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
">Steve<o:p></o:p></div></div></div></div><br><br>Scanned by Check Point =
Total Security Gateway.<span =
class=3D"Apple-converted-space">&nbsp;</span><br><br></div></span></blockq=
uote></div><br></div></body></html>=

--Apple-Mail-1-549493758--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9A7FhNj049448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Oct 2008 00:15:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9A7Fgc8049444; Fri, 10 Oct 2008 00:15:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9A7FTLo049403; Fri, 10 Oct 2008 00:15:40 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA89438; Fri, 10 Oct 2008 09:27:55 +0200
Received: from FRMYA-SIA24 ([129.182.109.114]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008101009105327:6204 ; Fri, 10 Oct 2008 09:10:53 +0200 
Reply-To: [e-mail]
From: "Denis Pinkas"<[e-mail]>
To: "owner-ietf-pkix"<[e-mail]>, "Stephen Kent"<[e-mail]>, "ietf-pkix"<[e-mail]>
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Fri, 10 Oct 2008 09:10:52 +0200
Message-Id: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 10/10/2008 09:10:53, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 10/10/2008 09:15:25, Serialize complete at 10/10/2008 09:15:25
Content-Type: multipart/alternative;  boundary="----=_NextPart_08101009105122542525713_002"
Sender: [e-mail]
Precedence: 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_08101009105122542525713_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

I support the NO vote from Stefan.

I concur that a certificate is not the right place to manage clearances.

Clearances constraints should be managed within validation policies rather than CA certificates.

This topic is related to draft-ietf-pkix-ta-mgmt-reqs-01.txt 
for which I have sent comments in response to the WGLC.

Denis

----- Message reçu ----- 
De : owner-ietf-pkix 
À : Stephen Kent,[e-mail] 
Date : 2008-10-07, 17:40:54
Sujet : RE: draft-turner-caclearanceconstraints-01.txt


I vote NO to adopting this work as a PKIX work item.
I do vote for a continued debate on the rationale for this proposal but I have yet not seen any good motivation for doing this work.
The rational for my NO vote is:
1)      To start with, a certificate is a very bad place to manage clearance. I can at most agree to it’s use in AA certificates but clearance is in its nature fundamentally different from Public Key certificates as the certificate is an assertion of an entity’s key and identity, which is generic and static, while clearance is context specific and dynamic.
2)      If clearance would make it into certificates, then that should be more than enough that we reasonable could handle as a standard. To specify constraints for such information is to ask for big trouble.
Elaborating on the difficulties to specify clearance constraints I would like to highlight some quotes from the draft:
The draft is taking several shortcuts when it comes to clearance constraints processing.
The class list is specified but at the same time defined within the context of PolicyId. This means that there is no generic way to compare ClassList bits, This is highlighted by the following quote from 4.1.1.3:
       -- Calculate securityCategories intersection in accordance with
          guidelines associated with the security policy represented by
          the policyID.
So the logic for clearance constraints processing is performed per PolicyId but the logic may be different for every PolicyId.
In my world, this does not fly and is not implementable.
I also have a number of other problems:
·         This draft makes clearance processing authoritative over accepting certificate paths. I foresee problems with legacy implementations of PKI:
   If more than one entry with
   the same policyId is present in AuthorityClearanceConstraints
   certificate extension, the certification path is rejected.
·         This draft mandates processing of extensions in TA certificates (root) which can be argued to be incompatible with RFC 3280
Conclusion: 
Before this work is accepted as work group item, it must show that clearance constraints processing is possible in a reasonable and meaningful manner, and hence is worth working on. 
If we decide to work on this item, I foresee a major design commitment for the PKIX group and an even bigger commitment on behalf of implementers.
As such, I also encourage use cases that motivates the effort.
Stefan Santesson
Senior Program Manager
Windows Security, Standards
From: [e-mail] [mailto:[e-mail]] On Behalf Of Stephen Kent
Sent: den 1 oktober 2008 22:24
To: [e-mail]
Subject: draft-turner-caclearanceconstraints-01.txt
It appears to have been two months since there was any PKIX list discussion of this document. In Dublin it was agreed that we would conduct a straw poll on whether to adopt this as a WG item, but I failed to do so prior to leaving for a week-long meeting in NZ and 3-week vacation in KE.  My bad.
So, I'd like to initiate a 1-week straw poll starting 10/3.
Sean, the minutes indicated that you would tell me what status you are seeking for the document, and I have no record of a message from you on that topic, so please provide that vital piece of info to the list before we start the poll.
Thanks,
Steve

------=_NextPart_08101009105122542525713_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.grey
	{mso-style-name:grey;}
span.break
	{mso-style-name:break;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:49114554;
	mso-list-type:hybrid;
	mso-list-template-ids:424998946 69009409 69009411 69009413 69009409 69009411 69009413 69009409 69009411 69009413;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l1
	{mso-list-id:796266369;
	mso-list-type:hybrid;
	mso-list-template-ids:226030406 69009409 69009411 69009413 69009409 69009411 69009413 69009409 69009411 69009413;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l2
	{mso-list-id:1496146703;
	mso-list-type:hybrid;
	mso-list-template-ids:-1695522606 69009425 69009433 69009435 69009423 69009433 69009435 69009423 69009433 69009435;}
@list l2:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</STYLE>

<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV><FONT color=#000000>I support the NO vote from Stefan.</FONT></DIV>
<DIV><FONT color=#000000></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000>I concur that <FONT face=Arial>a certificate is not the 
right place&nbsp;to manage clearances.</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Clearances constraints should be managed within validation policies rather 
than CA certificates.</DIV>
<DIV>&nbsp;</DIV>
<DIV>This topic is related to <SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: FR; mso-bidi-language: AR-SA">draft-ietf-pkix-ta-mgmt-reqs-01.txt 
<BR><FONT face=Arial>for which I have sent comments in response to the 
WGLC.</FONT></SPAN></DIV>
<DIV><FONT face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial>Denis</FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal">----- 
  Message reçu ----- </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[e-mail]">owner-ietf-pkix</A> 
</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[e-mail],[e-mail]">Stephen 
  Kent,[e-mail]</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-10-07, 17:40:54</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> RE: draft-turner-caclearanceconstraints-01.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV class=Section1>
  <P class=MsoNormal><A name=_MailEndCompose><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: red; FONT-FAMILY: 'Calibri','sans-serif'">I 
  vote NO to adopting this work as a PKIX work item.<O:P></O:P></SPAN></A></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I 
  do vote for a continued debate on the rationale for this proposal but I have 
  yet not seen any good motivation for doing this work.<O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoNormal><U><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">The 
  rational for my NO vote is:<O:P></O:P></SPAN></U></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoListParagraph 
style="TEXT-INDENT: -18pt; mso-list: l2 level1 lfo1"><![if !supportLists]><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><SPAN 
  style="mso-list: Ignore">1)<SPAN 
  style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN></SPAN></SPAN><![endif]><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">To 
  start with, a certificate is a very bad place to manage clearance. I can at 
  most agree to it’s use in AA certificates but clearance is in its nature 
  fundamentally different from Public Key certificates as the certificate is an 
  assertion of an entity’s key and identity, which is generic and static, while 
  clearance is context specific and dynamic.<O:P></O:P></SPAN></P>
  <P class=MsoListParagraph 
style="TEXT-INDENT: -18pt; mso-list: l2 level1 lfo1"><![if !supportLists]><SPAN 
  lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><SPAN 
  style="mso-list: Ignore">2)<SPAN 
  style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN></SPAN></SPAN><![endif]><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">If 
  clearance would make it into certificates, then that should be more than 
  enough that we reasonable could handle as a standard. To specify constraints 
  for such information is to ask for big trouble.<O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Elaborating 
  on the difficulties to specify clearance constraints I would like to highlight 
  some quotes from the draft:<O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">The 
  draft is taking several shortcuts when it comes to clearance constraints 
  processing.<O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">The 
  class list is specified but at the same time defined within the context of 
  PolicyId. This means that there is no generic way to compare ClassList bits, 
  This is highlighted by the following quote from 4.1.1.3:<O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P><PRE><SPAN lang=EN-US>&nbsp;</SPAN><SPAN lang=EN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Calculate securityCategories intersection in accordance with<O:P></O:P></SPAN></PRE><PRE><SPAN lang=EN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; guidelines associated with the security policy represented by<O:P></O:P></SPAN></PRE><PRE><SPAN lang=EN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the policyID.<O:P></O:P></SPAN></PRE>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">So 
  the logic for clearance constraints processing is performed per PolicyId but 
  the logic may be different for every PolicyId.<O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">In 
  my world, this does not fly and is not implementable.<O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I 
  also have a number of other problems:<O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoListParagraph 
style="TEXT-INDENT: -18pt; mso-list: l0 level1 lfo3"><![if !supportLists]><SPAN 
  lang=EN-US style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: Symbol"><SPAN 
  style="mso-list: Ignore">·<SPAN 
  style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN></SPAN></SPAN><![endif]><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">This 
  draft makes clearance processing authoritative over accepting certificate 
  paths. I foresee problems with legacy implementations of 
  PKI:<O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P><PRE><SPAN lang=EN-US>&nbsp;</SPAN><SPAN lang=EN>&nbsp; If more than one entry with<O:P></O:P></SPAN></PRE><PRE><SPAN lang=EN>&nbsp;&nbsp; the same policyId is present in AuthorityClearanceConstraints<O:P></O:P></SPAN></PRE><PRE><SPAN lang=EN>&nbsp;&nbsp; certificate extension, the certification path is rejected.<O:P></O:P></SPAN></PRE>
  <P class=MsoNormal><SPAN lang=EN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoListParagraph 
style="TEXT-INDENT: -18pt; mso-list: l0 level1 lfo3"><![if !supportLists]><SPAN 
  lang=EN-US style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: Symbol"><SPAN 
  style="mso-list: Ignore">·<SPAN 
  style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN></SPAN></SPAN><![endif]><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">This 
  draft mandates processing of extensions in TA certificates (root) which can be 
  argued to be incompatible with RFC 3280<O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Conclusion: 
  <O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Before 
  this work is accepted as work group item, it must show that clearance 
  constraints processing is possible in a reasonable and meaningful manner, and 
  hence is worth working on. <O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">If 
  we decide to work on this item, I foresee a major design commitment for the 
  PKIX group and an even bigger commitment on behalf of 
  implementers.<O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">As 
  such, I also encourage use cases that motivates the 
  effort.<O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <DIV>
  <P class=MsoNormal><B><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan 
  Santesson</SPAN></B><SPAN lang=EN-GB 
  style="COLOR: #1f497d"><O:P></O:P></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Senior 
  Program Manager</SPAN><SPAN lang=EN-GB 
  style="COLOR: navy"><O:P></O:P></SPAN></P>
  <P class=MsoNormal><B><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows 
  Security, Standards</SPAN></B><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P></DIV>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><O:P></O:P></SPAN></P>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=MsoNormal><B><SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
  lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> 
  [e-mail] [mailto:[e-mail]] <B>On 
  Behalf Of </B>Stephen Kent<BR><B>Sent:</B> den 1 oktober 2008 
  22:24<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> 
  draft-turner-caclearanceconstraints-01.txt<O:P></O:P></SPAN></P></DIV></DIV>
  <P class=MsoNormal><O:P></O:P></P>
  <DIV>
  <P class=MsoNormal>It appears to have been two months since there was any PKIX 
  list discussion of this document. In Dublin it was agreed that we would 
  conduct a straw poll on whether to adopt this as a WG item, but I failed to do 
  so prior to leaving for a week-long meeting in NZ and 3-week vacation in 
  KE.&nbsp; My bad.<O:P></O:P></P></DIV>
  <DIV>
  <P class=MsoNormal><O:P></O:P></P></DIV>
  <DIV>
  <P class=MsoNormal>So, I'd like to initiate a 1-week straw poll starting 
  10/3.<O:P></O:P></P></DIV>
  <DIV>
  <P class=MsoNormal><O:P></O:P></P></DIV>
  <DIV>
  <P class=MsoNormal><B>Sean</B>, the minutes indicated that you would tell me 
  what status you are seeking for the document, and I have no record of a 
  message from you on that topic, so please provide that vital piece of info to 
  the list before we start the poll.<O:P></O:P></P></DIV>
  <DIV>
  <P class=MsoNormal><O:P></O:P></P></DIV>
  <DIV>
  <P class=MsoNormal>Thanks,<O:P></O:P></P></DIV>
  <DIV>
  <P class=MsoNormal><O:P></O:P></P></DIV>
  <DIV>
  <P 
class=MsoNormal>Steve<O:P></O:P></P></DIV></DIV></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08101009105122542525713_002--






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m97FjWYx086528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2008 08:45:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m97FjWYS086527; Tue, 7 Oct 2008 08:45:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m97FjL4o086508 for <[e-mail]>; Tue, 7 Oct 2008 08:45:31 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KnEkS-00027x-EM for [e-mail]; Tue, 07 Oct 2008 11:45:20 -0400
Mime-Version: 1.0
Message-Id: <p06240507c51133c3302d@[128.89.89.71]>
Date: Tue, 7 Oct 2008 11:45:59 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: new WG item
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The coauthors of RFC 3281 (attribute cert profile) have asked to 
update it, to accommodate several errata that have been filed since 
this RFC was published.

The PKIK co-chairs agree that this is a simple and worthwhile effort 
that should not impose a significant burden on the WG, especially 
since all three of the RFC authors have agreed to this update.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m97Fex2M086163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2008 08:40:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m97Fexsw086162; Tue, 7 Oct 2008 08:40:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m97FeuYU086153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 7 Oct 2008 08:40:57 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 7 Oct 2008 16:40:55 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.73]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Tue, 7 Oct 2008 16:40:55 +0100
From: Stefan Santesson <[e-mail]>
To: Stephen Kent <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Tue, 7 Oct 2008 16:40:54 +0100
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: AckkCUREtMVRjHr8Tbyvr7tGamq2+wEhfTXQ
Message-ID: <[e-mail]>
References: <p0624051bc5098b483ca0@[128.89.89.71]>
In-Reply-To: <p0624051bc5098b483ca0@[128.89.89.71]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D3218DDA55C66EAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

I vote NO to adopting this work as a PKIX work item.

I do vote for a continued debate on the rationale for this proposal but I h=
ave yet not seen any good motivation for doing this work.

The rational for my NO vote is:


1)      To start with, a certificate is a very bad place to manage clearanc=
e. I can at most agree to it's use in AA certificates but clearance is in i=
ts nature fundamentally different from Public Key certificates as the certi=
ficate is an assertion of an entity's key and identity, which is generic an=
d static, while clearance is context specific and dynamic.

2)      If clearance would make it into certificates, then that should be m=
ore than enough that we reasonable could handle as a standard. To specify c=
onstraints for such information is to ask for big trouble.

Elaborating on the difficulties to specify clearance constraints I would li=
ke to highlight some quotes from the draft:

The draft is taking several shortcuts when it comes to clearance constraint=
s processing.
The class list is specified but at the same time defined within the context=
 of PolicyId. This means that there is no generic way to compare ClassList =
bits, This is highlighted by the following quote from 4.1.1.3:


       -- Calculate securityCategories intersection in accordance with

          guidelines associated with the security policy represented by

          the policyID.

So the logic for clearance constraints processing is performed per PolicyId=
 but the logic may be different for every PolicyId.
In my world, this does not fly and is not implementable.

I also have a number of other problems:


*         This draft makes clearance processing authoritative over acceptin=
g certificate paths. I foresee problems with legacy implementations of PKI:


   If more than one entry with

   the same policyId is present in AuthorityClearanceConstraints

   certificate extension, the certification path is rejected.


*         This draft mandates processing of extensions in TA certificates (=
root) which can be argued to be incompatible with RFC 3280


Conclusion:
Before this work is accepted as work group item, it must show that clearanc=
e constraints processing is possible in a reasonable and meaningful manner,=
 and hence is worth working on.
If we decide to work on this item, I foresee a major design commitment for =
the PKIX group and an even bigger commitment on behalf of implementers.
As such, I also encourage use cases that motivates the effort.



Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Stephen Kent
Sent: den 1 oktober 2008 22:24
To: [e-mail]
Subject: draft-turner-caclearanceconstraints-01.txt

It appears to have been two months since there was any PKIX list discussion=
 of this document. In Dublin it was agreed that we would conduct a straw po=
ll on whether to adopt this as a WG item, but I failed to do so prior to le=
aving for a week-long meeting in NZ and 3-week vacation in KE.  My bad.

So, I'd like to initiate a 1-week straw poll starting 10/3.

Sean, the minutes indicated that you would tell me what status you are seek=
ing for the document, and I have no record of a message from you on that to=
pic, so please provide that vital piece of info to the list before we start=
 the poll.

Thanks,

Steve

--_000_9F11911AED01D24BAA1C2355723C3D3218DDA55C66EAEXMSGC332eu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile=
" xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns=
:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns=
:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http=
://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"ht=
tp://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z=3D"urn:s=
chemas-microsoft-com:" xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-=
html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<title>draft-turner-caclearanceconstraints-01.txt</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.grey
	{mso-style-name:grey;}
span.break
	{mso-style-name:break;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:49114554;
	mso-list-type:hybrid;
	mso-list-template-ids:424998946 69009409 69009411 69009413 69009409 690094=
11 69009413 69009409 69009411 69009413;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l1
	{mso-list-id:796266369;
	mso-list-type:hybrid;
	mso-list-template-ids:226030406 69009409 69009411 69009413 69009409 690094=
11 69009413 69009409 69009411 69009413;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l2
	{mso-list-id:1496146703;
	mso-list-type:hybrid;
	mso-list-template-ids:-1695522606 69009425 69009433 69009435 69009423 6900=
9433 69009435 69009423 69009433 69009435;}
@list l2:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style=
=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:red'>I vote NO to adopting =
this
work as a PKIX work item.<o:p></o:p></span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>I do vote for a continued debate on the rationale for this
proposal but I have yet not seen any good motivation for doing this work.<o=
:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><u><span lang=3DEN-US style=3D'font-size:11.0pt;font-f=
amily:
"Calibri","sans-serif";color:#1F497D'>The rational for my NO vote is:<o:p><=
/o:p></span></u></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l2 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><span style=3D'mso-list:Ignore'>1)<span style=3D'font:7.0pt =
"Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'font-size:11.0pt=
;
font-family:"Calibri","sans-serif";color:#1F497D'>To start with, a certific=
ate
is a very bad place to manage clearance. I can at most agree to it&#8217;s =
use
in AA certificates but clearance is in its nature fundamentally different f=
rom
Public Key certificates as the certificate is an assertion of an entity&#82=
17;s
key and identity, which is generic and static, while clearance is context
specific and dynamic.<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l2 level1=
 lfo1'><![if !supportLists]><span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><span style=3D'mso-list:Ignore'>2)<span style=3D'font:7.0pt =
"Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'font-size:11.0pt=
;
font-family:"Calibri","sans-serif";color:#1F497D'>If clearance would make i=
t
into certificates, then that should be more than enough that we reasonable
could handle as a standard. To specify constraints for such information is =
to
ask for big trouble.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>Elaborating on the difficulties to specify clearance constra=
ints
I would like to highlight some quotes from the draft:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>The draft is taking several shortcuts when it comes to clear=
ance
constraints processing.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>The class list is specified but at the same time defined wit=
hin
the context of PolicyId. This means that there is no generic way to compare
ClassList bits, This is highlighted by the following quote from 4.1.1.3:<o:=
p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<pre><span lang=3DEN-US>&nbsp;</span><span lang=3DEN>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; -- Calculate securityCategories intersection in accordance with<o:=
p></o:p></span></pre><pre><span
lang=3DEN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; guidelines=
 associated with the security policy represented by<o:p></o:p></span></pre>=
<pre><span
lang=3DEN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the policy=
ID.<o:p></o:p></span></pre>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>So the logic for clearance constraints processing is perform=
ed
per PolicyId but the logic may be different for every PolicyId.<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>In my world, this does not fly and is not implementable.<o:p=
></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>I also have a number of other problems:<o:p></o:p></span></p=
>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo3'><![if !supportLists]><span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:Symbol;color:#1F497D'><s=
pan
style=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.0pt "Times New Roma=
n"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'font-size:11.0pt=
;
font-family:"Calibri","sans-serif";color:#1F497D'>This draft makes clearanc=
e
processing authoritative over accepting certificate paths. I foresee proble=
ms
with legacy implementations of PKI:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<pre><span lang=3DEN-US>&nbsp;</span><span lang=3DEN>&nbsp; If more than on=
e entry with<o:p></o:p></span></pre><pre><span
lang=3DEN>&nbsp;&nbsp; the same policyId is present in AuthorityClearanceCo=
nstraints<o:p></o:p></span></pre><pre><span
lang=3DEN>&nbsp;&nbsp; certificate extension, the certification path is rej=
ected.<o:p></o:p></span></pre>

<p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1=
 lfo3'><![if !supportLists]><span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:Symbol;color:#1F497D'><s=
pan
style=3D'mso-list:Ignore'>&middot;<span style=3D'font:7.0pt "Times New Roma=
n"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span lang=3DEN-US style=3D'font-size:11.0pt=
;
font-family:"Calibri","sans-serif";color:#1F497D'>This draft mandates proce=
ssing
of extensions in TA certificates (root) which can be argued to be incompati=
ble
with RFC 3280<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>Conclusion: <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>Before this work is accepted as work group item, it must sho=
w
that clearance constraints processing is possible in a reasonable and
meaningful manner, and hence is worth working on. <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>If we decide to work on this item, I foresee a major design
commitment for the PKIX group and an even bigger commitment on behalf of
implementers.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'>As such, I also encourage use cases that motivates the effor=
t.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D=
EN-GB
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'col=
or:navy'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f=
amily:
"Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><=
span
lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Stephen Kent<br>
<b>Sent:</b> den 1 oktober 2008 22:24<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> draft-turner-caclearanceconstraints-01.txt<o:p></o:p></span=
></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal>It appears to have been two months since there was any=
 PKIX
list discussion of this document. In Dublin it was agreed that we would con=
duct
a straw poll on whether to adopt this as a WG item, but I failed to do so p=
rior
to leaving for a week-long meeting in NZ and 3-week vacation in KE.&nbsp; M=
y
bad.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>So, I'd like to initiate a 1-week straw poll starting =
10/3.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal><b>Sean</b>, the minutes indicated that you would tell=
 me
what status you are seeking for the document, and I have no record of a mes=
sage
from you on that topic, so please provide that vital piece of info to the l=
ist
before we start the poll.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>Thanks,<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>Steve<o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D3218DDA55C66EAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m97EqOh1079915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2008 07:52:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m97EqOfu079914; Tue, 7 Oct 2008 07:52:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m97EqMWY079907 for <[e-mail]>; Tue, 7 Oct 2008 07:52:23 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id D30CE439CB for <[e-mail]>; Tue,  7 Oct 2008 15:52:21 +0100 (IST)
X-Virus-Scanned: amavisd-new at cs.tcd.ie
Received: from cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPDT0sSfpiDN for <[e-mail]>; Tue,  7 Oct 2008 15:52:21 +0100 (IST)
Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18]) by smtp.cs.tcd.ie (Postfix) with ESMTP id 5E194439AC for <[e-mail]>; Tue,  7 Oct 2008 15:52:21 +0100 (IST)
Message-ID: <[e-mail]>
Date: Tue, 07 Oct 2008 15:53:04 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-turner-caclearanceconstraints-01.txt
References: <p0624051bc5098b483ca0@[128.89.89.71]>
In-Reply-To: <p0624051bc5098b483ca0@[128.89.89.71]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
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 taking this on.

>From a quick scan, I'd prefer if the algorithm was presented
in pseudo-code, I think that might be more useful.

Stephen.

Stephen Kent wrote:
> It appears to have been two months since there was any PKIX list
> discussion of this document. In Dublin it was agreed that we would
> conduct a straw poll on whether to adopt this as a WG item, but I failed
> to do so prior to leaving for a week-long meeting in NZ and 3-week
> vacation in KE.  My bad.
> 
> So, I'd like to initiate a 1-week straw poll starting 10/3.
> 
> *Sean*, the minutes indicated that you would tell me what status you are
> seeking for the document, and I have no record of a message from you on
> that topic, so please provide that vital piece of info to the list
> before we start the poll.
> 
> Thanks,
> 
> Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m97EjVhx079100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2008 07:45:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m97EjVE5079097; Tue, 7 Oct 2008 07:45:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m97EjRq9079033 for <[e-mail]>; Tue, 7 Oct 2008 07:45:27 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id D5211439BC for <[e-mail]>; Tue,  7 Oct 2008 15:45:26 +0100 (IST)
X-Virus-Scanned: amavisd-new at cs.tcd.ie
Received: from cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PeYT+WPF037 for <[e-mail]>; Tue,  7 Oct 2008 15:45:26 +0100 (IST)
X-Greylist: delayed 615 seconds by postgrey-1.32 at relay.cs.tcd.ie; Tue, 07 Oct 2008 15:45:26 IST
Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18]) by smtp.cs.tcd.ie (Postfix) with ESMTP id 59C40439B4 for <[e-mail]>; Tue,  7 Oct 2008 15:45:26 +0100 (IST)
Message-ID: <[e-mail]>
Date: Tue, 07 Oct 2008 15:46:10 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
References: <p0624051ac5098a5a04fd@[128.89.89.71]>
In-Reply-To: <p0624051ac5098a5a04fd@[128.89.89.71]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
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>

The draft says:

      o implicitCurve allows the elliptic curve parameters to be
        inherited.  This choice MAY be supported, but if subordinate
        certificates use the same namedCurve as their superior, then
        the subordinate certificate MUST use the namedCurve option.
        That is, implicitCurve is only supported if the superior
        doesn't use the namedCurve option.

"MAY be supported" seems wrong, ought it be "MAY be used"?

And could we RECOMMEND that it not be used? I find it hard to see
how a programmer can make the right choice, and easy to see that
a CA operator could make the wrong choice. And its generally a
confusing bit of text.

Otherwise this seems fine as far as I can tell (which isn't far
in the case of EC related stuff:-)

Stephen.





Stephen Kent wrote:
> 
> I have been told that the IEEE 801.1 AR folks are hoping to refer to
> cite draft-ietf-pkix-ecc-subpubkeyinfo as an RFC in their work, so it
> behooves us to move ahead as soon as possible.  It also appears that
> discussion has settled down on this draft, so I am initiating WGLC on it
> as well, effective today, and continuing until 10/15.
> 
> Thanks,
> 
> Steve
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m97EZRTD077981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2008 07:35:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m97EZRrb077980; Tue, 7 Oct 2008 07:35:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m97EZFNT077957 for <[e-mail]>; Tue, 7 Oct 2008 07:35:26 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id CE8B143991 for <[e-mail]>; Tue,  7 Oct 2008 15:35:13 +0100 (IST)
X-Virus-Scanned: amavisd-new at cs.tcd.ie
Received: from cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN4DbX8isXtR for <[e-mail]>; Tue,  7 Oct 2008 15:35:11 +0100 (IST)
Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18]) by smtp.cs.tcd.ie (Postfix) with ESMTP id B7F0D43987 for <[e-mail]>; Tue,  7 Oct 2008 15:35:11 +0100 (IST)
Message-ID: <[e-mail]>
Date: Tue, 07 Oct 2008 15:35:55 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.
References: <p06240519c5098940c2e4@[128.89.89.71]>
In-Reply-To: <p06240519c5098940c2e4@[128.89.89.71]>
X-Enigmail-Version: 0.95.7
Content-Type: multipart/mixed; boundary="------------030801040301050803020303"
Sender: [e-mail]
Precedence: 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.
--------------030801040301050803020303
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Bunch of comments attached. While this version is quite close, I
think some of these do warrant changes.

Cheers,
Stephen.


--------------030801040301050803020303
Content-Type: text/plain;
 name="ta-reqs-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ta-reqs-01.txt"


Comments on http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-01

General:
-------

1: A scope question - does this document specify requirements for a protocol
where the TAM is not represented as a TA?  If not (which is fine), then perhaps
just say so directly, rather than indirectly as (I think) is currently the
case.

2: MUST/SHOULD etc. Section 2 says in part "...trust anchor stores must be
managed in accord with..." whereas section 3 has a bunch of more specific uses
of "must" (all lowercase, but whatever). It should be clear which bits are RFC
2119 language and which aren't. I'd also prefer use of uppercase MUSTs where
2119 is supposed to apply (and then a reference is needed as well.) The
specific sentence is section 2 isn't something that I think can be a MUST since
its unenforceable. Similarly, in 3.1.2 the word "required" is used though the
section is called "rationale" - is that meant to be a 2119 keyword or not?

3: Does 3.1.1 imply that message integrity cannot be provided by a transport
security service/mechanism but MUST be defined and used "in-band" in the TAMP
protocol? I think I don't mind for this protocol, but its not quite clear from
the text.

4: Does "transport independent" here mean the same as "can be used in both
session oriented and store-and-forward contexts"? If not, then would a TAMP
that (somehow) works over TCP but not DCCP comply? If so, then maybe merge the
first two sentences of 3.1.1 and lose the "must be transport independent"
phrase.

5: section 3.2.2 - what does "are compound" mean? If its not needed maybe
delete the sentence. If its needed, I think it needs to be clearer.

6: 3.3.1 seems to introduce "groups of trust anchor stores" with the
implication that they are named groups, but the sentence isn't clear about
that. If named groups are required say so. If not, get rid of the term. (If the
latter, then bullets 2 & 3 here could be merged into "an emumerated list of
trust anchor stores" since a single element list is a fine list:-)

7: 3.4.1 calls for delegation to be a "MUST" for the protocol. I would have
thought that a "MAY" is better here since delegation is inherently complex and
a simpler protocol might turn out to be better. A "MAY" here lets us decide
that later.  Delegation in 3.6.1 is a "should" vs a "must" in 3.4.1 - is that
deliberate? (I'd go for "MAY" in both cases)

8: 3.8.1 calls for replay detection for reports - surely the requirement would
also apply to other operations as well? (Reading further it seems that 3.11.1
does call for that, so suggest removing that from 3.8.1 in which case one of
3.8.1 or 3.9.1 can be removed?)

9: 3.10.1 might be defining a new operation or might be covered in 3.2.1, I'm
not sure. If its covered, then maybe delete 3.10.1, or is the point that 3.2.1
is must whereas 3.10.1 is a should? 

10: 3.11.1 almost seems to prevent use of reliable time information, which I
guess isn't right. Presumably it'd be ok to have a TAMP that with an
applicability statement saying it only applied where time was available? (I do
however, like the idea of also being able to work where there's no good time,
but perhaps that implies that there's a "MAY" missing somewhere?)

11: 3.12.1 - a "MUST" here seems too strong, in particular for the "source of
trust anchor information" - I think that'd be better as a MAY.

12: 3.13.1 seems to be out of scope for a TAMP since its imposing a requirement
on the 5280 processor and not on a TAMP. Maybe change from a requirement to a
nice bit of advice or a security consideration?  (3.13.2 also contradicts the
"must" in 3.13.1 I think)

13: I think the security considerations could usefully point out that a TAMP
creates a nice new target to attack - if I can get at the TAM private key or
replace the public key I can control a lot of the security stuff on the box.
Also, if a TAM makes a mistake (e.g. a typo in an allowed name constraint) that
creates a new accidental-DoS vector.

Nits:
-----

1: section 1, 1st bullet "begins a certification path" is a bit ambiguous
depending on whether the EE or CA is first or last. Suggest rephrasing (maybe
just say "a public key certificate" and leave it at that)

2: section 2, "Throughout this document, trust anchor managers are assumed to
be represented as trust anchors." Well, in the case where an application
manages trust anchors (e.g. like a browser) that may not be true. Maybe just
add a caveat here that other schemes are possible but aren't covered in this
document. 

3: s/and etc./etc./

4: last para of section 2, s/which trust anchors/the set of trust anchors/

5: section 3.3.1: is "TA Management" the same as "TA Manager" (the latter is a
defined term, the former not). If so, just use one; if not, please define the
term.

6: "specification of public key identifier" needs an "a" in 3.7.1

7: 3.8.1 and 3.9.1 seem to overlap a bit and could maybe be simplified (3.9.1
seems to call for everything in 3.8.1 other than replay detection)

8: I've no idea if 5280 and 5055 should be normative references for a protocol
requirements document, but then I also don't care. However, maybe someone else
does? :-)


--------------030801040301050803020303--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m979q49Q053174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2008 02:52:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m979q4Df053173; Tue, 7 Oct 2008 02:52:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m979pp9u053156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 7 Oct 2008 02:52:03 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 7 Oct 2008 10:51:50 +0100
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.73]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Tue, 7 Oct 2008 10:51:50 +0100
From: Stefan Santesson <[e-mail]>
To: "Turner, Sean P." <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "[e-mail]" <[e-mail]>
CC: "'Pope, Nick'" <[e-mail]>
Date: Tue, 7 Oct 2008 10:51:48 +0100
Subject: RE: need to update RFC 3161
Thread-Topic: need to update RFC 3161
Thread-Index: Acknz64iv4ACndh9TxKJxQ0qNyey7QAI3B0gABu6prA=
Message-ID: <[e-mail]>
References: <[e-mail]> <p06240513c50fe25f6da4@[128.89.89.227]> <71A95FD6352C4FD1BAA72694D6C0118C@Wylie>
In-Reply-To: <71A95FD6352C4FD1BAA72694D6C0118C@Wylie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: 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.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Turner, Sean P.
> Sent: den 6 oktober 2008 22:48
> To: 'Stephen Kent'; [e-mail]
> Cc: 'Pope, Nick'
> Subject: RE: need to update RFC 3161
>
>
> I think updating RFC 3161 to allow SigningCertificateV2 is a good idea,
> assuming that's how the update is scoped.
>
> spt
>
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]] On Behalf Of Stephen Kent
> >Sent: Monday, October 06, 2008 11:45 AM
> >To: [e-mail]
> >Cc: Pope, Nick
> >Subject: Re: need to update RFC 3161
> >
> >
> >At 1:32 PM +0100 9/29/08, Pope, Nick wrote:
> >>All in PKIX,
> >>
> >>On behalf on ETSI TC ESI I wish to highlight the need for RFC 3161 to
> >>be updated to make use of SigningCertificateV2 (RFC 5035) in order to
> >>allow the use of hash algorithms other than SHA-1.
> >>
> >>Nick Pope
> >>Thales e-Security
> >
> >Folks,
> >
> >Nick noted a rationale for updating 3161, in his message above.
> >Denis Pinkas, a major contributor to 3161 has offered to
> >generate 3161bis, which would address the issue Nick noted,
> >and make other updates as well.  The WG co-chairs and the
> >cognizant AD are considering this offer.  We solicit inputs
> >from the WG.
> >
> >Steve
> >
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96KmENM097182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2008 13:48:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m96KmEAc097181; Mon, 6 Oct 2008 13:48:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m96Km2ct097165 for <[e-mail]>; Mon, 6 Oct 2008 13:48:12 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 9332 invoked from network); 6 Oct 2008 20:48:01 -0000
Received: from unknown (HELO Wylie) (turners@96.231.120.137 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 6 Oct 2008 20:48:01 -0000
X-YMail-OSG: fAf55ywVM1kyozUS6FthR_SQiAJT3wDh4TbKl_ABUX3qp9P7ReG1fXR3SWAsg9BFpq6a3kbBJr6QAQUtMMyFT9U1ajtHtyybELv_aipZnC.2UYhqv2RLdbLwxi6Sp.f0eVj0IIhJPt3noLNu81j54V71kBRQ4HoeLz7RIRXKsvckgKI_ouI-
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, <[e-mail]>
Cc: "'Pope, Nick'" <[e-mail]>
References: <[e-mail]> <p06240513c50fe25f6da4@[128.89.89.227]>
Subject: RE: need to update RFC 3161
Date: Mon, 6 Oct 2008 16:47:33 -0400
Organization: IECA, Inc.
Message-ID: <71A95FD6352C4FD1BAA72694D6C0118C@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <p06240513c50fe25f6da4@[128.89.89.227]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: Acknz64iv4ACndh9TxKJxQ0qNyey7QAI3B0g
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think updating RFC 3161 to allow SigningCertificateV2 is a good idea,
assuming that's how the update is scoped.

spt 

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Stephen Kent
>Sent: Monday, October 06, 2008 11:45 AM
>To: [e-mail]
>Cc: Pope, Nick
>Subject: Re: need to update RFC 3161
>
>
>At 1:32 PM +0100 9/29/08, Pope, Nick wrote:
>>All in PKIX,
>>
>>On behalf on ETSI TC ESI I wish to highlight the need for RFC 3161 to 
>>be updated to make use of SigningCertificateV2 (RFC 5035) in order to 
>>allow the use of hash algorithms other than SHA-1.
>>
>>Nick Pope
>>Thales e-Security
>
>Folks,
>
>Nick noted a rationale for updating 3161, in his message above. 
>Denis Pinkas, a major contributor to 3161 has offered to 
>generate 3161bis, which would address the issue Nick noted, 
>and make other updates as well.  The WG co-chairs and the 
>cognizant AD are considering this offer.  We solicit inputs 
>from the WG.
>
>Steve
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96KFluX094973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2008 13:15:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m96KFlKq094971; Mon, 6 Oct 2008 13:15:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96KFdnt094940 for <[e-mail]>; Mon, 6 Oct 2008 13:15:40 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id CA13228C201; Mon,  6 Oct 2008 13:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-tamp-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  6 Oct 2008 13:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: 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           : Trust Anchor Management Protocol (TAMP)
	Author(s)       : R. Housley, et al.
	Filename        : draft-ietf-pkix-tamp-00.txt
	Pages           : 85
	Date            : 2008-10-06

This document describes a transport independent protocol for the
management of trust anchors and community identifiers stored in a
trust anchor store.  The protocol makes use of the Cryptographic
Message Syntax (CMS), and a digital signature is used to provide
integrity protection and data origin authentication.  The protocol
can be used to manage trust anchor stores containing trust anchors
represented as Certificate, TBSCertificate or TrustAnchorInfo
objects.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-tamp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96KFf1Y094961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2008 13:15:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m96KFfcQ094959; Mon, 6 Oct 2008 13:15:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96KFdWf094939 for <[e-mail]>; Mon, 6 Oct 2008 13:15:40 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id C610728C200; Mon,  6 Oct 2008 13:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-ta-format-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  6 Oct 2008 13:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: 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           : Trust Anchor Format
	Author(s)       : R. Housley, et al.
	Filename        : draft-ietf-pkix-ta-format-00.txt
	Pages           : 25
	Date            : 2008-10-06

This document describes a structure for representing trust anchor
information.  A trust anchor is an authoritative entity represented
via a public key and associated data.  The public key is used to
verify digital signatures and the associated data is used to
constrain the types of information or actions for which the trust
anchor is authoritative.  The structures defined in this document are
intended to satisfy the format-related requirements defined in Trust
Anchor Management Requirements and for use within the context of the
Trust Anchor Management Protocol (TAMP).

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-ta-format-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96KFfgX094960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2008 13:15:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m96KFfti094958; Mon, 6 Oct 2008 13:15:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96KFdxH094938 for <[e-mail]>; Mon, 6 Oct 2008 13:15:40 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id BD5CA28C1E8; Mon,  6 Oct 2008 13:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-cms-content-constraints-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  6 Oct 2008 13:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: 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           : Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate Extension
	Author(s)       : R. Housley, et al.
	Filename        : draft-ietf-pkix-cms-content-constraints-00.txt
	Pages           : 31
	Date            : 2008-10-06

This document specifies the syntax and semantics for the
Cryptographic Message Syntax (CMS) content constraints X.509
certificate extension.  This extension is used to determine whether
the public key in an X.509 public key certificate is appropriate to
use in the processing of a protected content.  In particular, the CMS
content constraints certificate extension is one part of the
authorization decision; it is used when validating a digital
signature on a CMS SignedData content or validating a message
authentication code (MAC) on a CMS AuthenticatedData content or CMS
AuthEnvelopedData content.  The signed or authenticated content type
is identified by an ASN.1 object identifier, and this certificate
extension indicates the content types that the certified public key
is authorized to validate.  If the authorization check is successful,
the CMS content constraints certificate extension also provides
default values for absent attributes.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-cms-content-constraints-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96Jj8Zr091751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2008 12:45:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m96Jj8xN091750; Mon, 6 Oct 2008 12:45:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96JivRG091724 for <[e-mail]>; Mon, 6 Oct 2008 12:45:07 -0700 (MST) (envelope-from [e-mail])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA95015A204F; Mon, 6 Oct 2008 21:44:36 +0200
Message-ID: <1F50CB5DEEC94AF2A9E2E67CDD85ADBF@AndersPC>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Client PKI Workshop
Date: Mon, 6 Oct 2008 21:44:37 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [e-mail]
Precedence: 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 Yngve,
I am happy to see that browser vendors begin to take client-side PKI
more seriously.  What is not completely clear to me is what the target for
the workshop is outside of pure GUI-issues.  

"Unhelpful enrollment dialogs" is indeed a reality but under the surface
things are in an even more pitiful shape.  Most of the enrolment
schemes (which BTW are all over the map), lack pretty basic stuff
such as an ability to set PIN policies by issuers.  How do you view
this?

Although probably to be regarded as a shameless plug, you may
be interested knowing that I'm developing a set of browser-PKI-addons
which I call "PKI for Web 2.0" that currently comprise of Web Signatures,
Web Authentication, and more recently a Universal Key provisioning
and Life Cycle management system.   The word "Universal" is because
it supports PKI, OTP, Information Cards etc.  The whole caboodle is
intended to be launched around 1Q 09 as Open Source.

Regards
Anders Rundgren
http://WebPKI.org

----- Original Message ----- 
From: "Yngve Nysaeter Pettersen" <[e-mail]>
To: <[e-mail]>
Sent: Monday, October 06, 2008 17:19
Subject: Client PKI Workshop



Hello all,

In early December the CA/Browser forum will hold a workshop to investigate  
how Client PKI can be made more suitable for wide use.

We are looking for programme participants that would like to present views  
and suggestions to the workshop.

Please see http://www.cabforum.org/client_pki_2008/cfp_v05.htm for more  
information.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer      Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96GvgqD073970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2008 09:57:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m96GvguH073968; Mon, 6 Oct 2008 09:57:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.67.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96GvUNP073948 for <[e-mail]>; Mon, 6 Oct 2008 09:57:41 -0700 (MST) (envelope-from [e-mail])
Received: from MSCS-FNX-UEA01.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id m96GwkTO001996 for <[e-mail]>; Mon, 6 Oct 2008 16:58:47 GMT
Received: from MSIS-FNX-UEA01.corp.nsa.gov ([10.214.64.14]) by MSCS-FNX-UEA01.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 12:57:29 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C927D4.9E07E9EA"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Mon, 6 Oct 2008 12:57:29 -0400
Message-ID: <[e-mail]>
In-Reply-To: <F835E51C45534AB2A315B6F5BEA347D1@Wylie>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: AckkCFt8y6Bt17cQRh2MYEWwfQLFCwAAMAHwAPJY5+A=
References: <p0624051bc5098b483ca0@[128.89.89.71]> <F835E51C45534AB2A315B6F5BEA347D1@Wylie>
From: "Ashmore, Samuel R." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 06 Oct 2008 16:57:29.0821 (UTC) FILETIME=[9E3E68D0:01C927D4]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

I vote Yes for this document to be approved.
=20
--Samuel Ashmore

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Turner, Sean P.
Sent: Wednesday, October 01, 2008 5:04 PM
To: 'Stephen Kent'; [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt


We would like the document to be a standards track document.
=20
spt


________________________________

	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stephen Kent
	Sent: Wednesday, October 01, 2008 4:24 PM
	To: [e-mail]
	Subject: draft-turner-caclearanceconstraints-01.txt
=09
=09
	It appears to have been two months since there was any PKIX list
discussion of this document. In Dublin it was agreed that we would
conduct a straw poll on whether to adopt this as a WG item, but I failed
to do so prior to leaving for a week-long meeting in NZ and 3-week
vacation in KE.  My bad.

	So, I'd like to initiate a 1-week straw poll starting 10/3.

	Sean, the minutes indicated that you would tell me what status
you are seeking for the document, and I have no record of a message from
you on that topic, so please provide that vital piece of info to the
list before we start the poll.

	Thanks,

	Steve


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>draft-turner-caclearanceconstraints-01.txt</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.3395" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D625184216-06102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I&nbsp;vote Yes for this document to be=20
approved.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D625184216-06102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D625184216-06102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>--Samuel Ashmore</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>Turner, Sean=20
P.<BR><B>Sent:</B> Wednesday, October 01, 2008 5:04 PM<BR><B>To:</B> =
'Stephen=20
Kent'; [e-mail]<BR><B>Subject:</B> RE:=20
draft-turner-caclearanceconstraints-01.txt<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D203090321-01102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We would like the document to be a standards =
track=20
document.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D203090321-01102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D203090321-01102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>spt</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =

  [mailto:[e-mail]] <B>On Behalf Of </B>Stephen=20
  Kent<BR><B>Sent:</B> Wednesday, October 01, 2008 4:24 PM<BR><B>To:</B> =

  [e-mail]<BR><B>Subject:</B>=20
  draft-turner-caclearanceconstraints-01.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>It appears to have been two months since there was any PKIX list=20
  discussion of this document. In Dublin it was agreed that we would =
conduct a=20
  straw poll on whether to adopt this as a WG item, but I failed to do =
so prior=20
  to leaving for a week-long meeting in NZ and 3-week vacation in =
KE.&nbsp; My=20
  bad.</DIV>
  <DIV><BR></DIV>
  <DIV>So, I'd like to initiate a 1-week straw poll starting 10/3.</DIV>
  <DIV><BR></DIV>
  <DIV><B>Sean</B>, the minutes indicated that you would tell me what =
status you=20
  are seeking for the document, and I have no record of a message from =
you on=20
  that topic, so please provide that vital piece of info to the list =
before we=20
  start the poll.</DIV>
  <DIV><BR></DIV>
  <DIV>Thanks,</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C927D4.9E07E9EA--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96Fiu2g065159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2008 08:44:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m96FiugW065158; Mon, 6 Oct 2008 08:44:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96Fijx1065138 for <[e-mail]>; Mon, 6 Oct 2008 08:44:55 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-227.bbn.com ([128.89.89.227]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KmsGK-0007vR-Dq; Mon, 06 Oct 2008 11:44:44 -0400
Mime-Version: 1.0
Message-Id: <p06240513c50fe25f6da4@[128.89.89.227]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 6 Oct 2008 11:45:26 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: need to update RFC 3161
Cc: "Pope, Nick" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 1:32 PM +0100 9/29/08, Pope, Nick wrote:
>All in PKIX,
>
>On behalf on ETSI TC ESI I wish to highlight the need for RFC 3161 to be
>updated to make use of SigningCertificateV2 (RFC 5035) in order to allow the
>use of hash algorithms other than SHA-1.
>
>Nick Pope
>Thales e-Security

Folks,

Nick noted a rationale for updating 3161, in his message above. 
Denis Pinkas, a major contributor to 3161 has offered to generate 
3161bis, which would address the issue Nick noted, and make other 
updates as well.  The WG co-chairs and the cognizant AD are 
considering this offer.  We solicit inputs from the WG.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96FLucQ061894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2008 08:21:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m96FLuVw061892; Mon, 6 Oct 2008 08:21:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.opera.com (mail.opera.com [213.236.208.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96FLhi1061869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 6 Oct 2008 08:21:55 -0700 (MST) (envelope-from [e-mail])
Received: from killashandra.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) by mail.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m96FLfQa004770 for <[e-mail]>; Mon, 6 Oct 2008 15:21:41 GMT
Date: Mon, 06 Oct 2008 17:19:43 +0200
To: [e-mail]
Subject: Client PKI Workshop
Reply-To: [e-mail]
From: "Yngve Nysaeter Pettersen" <[e-mail]>
Organization: Opera Software
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
User-Agent: Opera Mail/9.27 (Win32)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello all,

In early December the CA/Browser forum will hold a workshop to investigate  
how Client PKI can be made more suitable for wide use.

We are looking for programme participants that would like to present views  
and suggestions to the workshop.

Please see http://www.cabforum.org/client_pki_2008/cfp_v05.htm for more  
information.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96DmGld053208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2008 06:48:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m96DmGIx053207; Mon, 6 Oct 2008 06:48:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from UKCRN08.crn.thales-esecurity.com ([193.112.44.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m96Dm497053183 for <[e-mail]>; Mon, 6 Oct 2008 06:48:15 -0700 (MST) (envelope-from [e-mail])
Received: by webmail.thales-esecurity.com with Internet Mail Service (5.5.2653.19) id <SGDBP7M7>; Mon, 6 Oct 2008 14:47:57 +0100
Message-ID: <[e-mail]>
From: "Pope, Nick" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: need to update RFC 3161
Date: Mon, 6 Oct 2008 14:47:48 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

Resending as previous submission may have not got through

-----Original Message-----
From: Pope, Nick 
Sent: 29 September 2008 13:33
To: '[e-mail]'
Subject: need to update RFC 3161

All in PKIX,

On behalf on ETSI TC ESI I wish to highlight the need for RFC 3161 to be
updated to make use of SigningCertificateV2 (RFC 5035) in order to allow the
use of hash algorithms other than SHA-1.

Nick Pope
Thales e-Security



Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on [phone] or email [e-mail].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m963REtW099514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Oct 2008 20:27:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m963REmh099513; Sun, 5 Oct 2008 20:27:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m963R1A1099436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sun, 5 Oct 2008 20:27:13 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m963Qxed000481 for <[e-mail]>; Sun, 5 Oct 2008 23:26:59 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m963Qwt2259838 for <[e-mail]>; Sun, 5 Oct 2008 23:26:59 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m963QmYk017052 for <[e-mail]>; Sun, 5 Oct 2008 23:26:48 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m963Qmek016909; Sun, 5 Oct 2008 23:26:48 -0400
In-Reply-To: <[e-mail]>
To: =?ISO-8859-1?Q?Alfred_H=F6nes?= <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: Re: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Sun, 5 Oct 2008 23:26:41 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1|February 07, 2008) at 10/05/2008 23:26:48, Serialize complete at 10/05/2008 23:26:48
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: 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 think that the decision is really independent.  I'm in=20
favor of B for both.  The definitions need to remain in the standard for=20
backwards compatibility, and their future use is indeed deprecated.

                Tom Gindin





Alfred H=F6nes <[e-mail]>=20
Sent by: [e-mail]
09/28/2008 10:07 PM

To
[e-mail]
cc

Subject
ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5







Folks,
the current version of draft-ietf-pkix-ecc-subpubkeyinfo contains
unqualified ASN.1 definitions for the digest algorithms MD-2 and MD-5,
as well as for  RSA with MD-2 and MD-5.

Other WGs already have deprecated MD-2 and/or MD-5 and/or are in the
process of deprecating these older hash functions (generally believed
to be insecure today), for use in the protocols they maintain.

So the question arises what to do with these old algorithms in the
context of PKIX in general, and in particular in the above draft.

I see four possible options:

  A)  leave the draft unchanged

  B)  leave the related ASN.1 definitions intact,
      but add ASN.1 comments  ' -- DEPRECATED'

  C)  keep the related ASN.1 definitions in the document
      for the purpose of documentation and historical record,
      but comment them out and add the above note

  D)  remove he related ASN.1 from the new/upated ASN.1
      modules in Appendix A.2 and Appendix A.4 of the draft

This question should be decided upon (almost independently):

    (1)  for  MD-2  and  RSA with MD-2  ... choices (1A), ... (1D)
and
    (2)  for  MD-5  and  RSA with MD-5  ... choices (2A), ... (2D)

Any opinions?

Please indicate support for
- one of:            (1A) / (1B) / (1C) / (1D)
- and one of:        (2A) / (2B) / (2C) / (2D)


Kind regards,
  Alfred.


P.S.:  My personal preference is  (1C) + (2B) .
--=20

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m95AUecH028251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Oct 2008 03:30:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m95AUeSg028250; Sun, 5 Oct 2008 03:30:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m95AUSNG028231 for <[e-mail]>; Sun, 5 Oct 2008 03:30:39 -0700 (MST) (envelope-from [e-mail])
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 654CE294002; Sun,  5 Oct 2008 12:30:17 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 837C5294001; Sun,  5 Oct 2008 12:30:16 +0200 (IST)
Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m95AUFke026772; Sun, 5 Oct 2008 12:30:15 +0200 (IST)
Cc: <[e-mail]>
Message-Id: <[e-mail]>
From: Yoav Nir <[e-mail]>
To: Carl Wallace <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.
Date: Sun, 5 Oct 2008 12:30:14 +0200
References: <p06240519c5098940c2e4@[128.89.89.71]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi

I've just read through this document, and I have but one comment.

In section 3.2.1 it says, "A trust anchor management protocol must  
provide support for these basic operations, however, not all  
implementations must support each option..."

I think a similar paragraph is needed in sections 3.3.1 and 3.4.1:
- It's perfectly reasonable to have a certain implementation (maybe  
the same one that only replaces the entire store) only make messages  
for all the TA stores for which it is responsible
- It's also reasonable for certain implementations to never delegate  
authority to another manager, and only support re-key.

Other than that, I think the document is ready for publication.

On Oct 3, 2008, at 7:53 PM, Carl Wallace wrote:

>
> We just submitted a new version of this draft.  Changes are minor  
> aside
> from the addition of section 3.13, which adds a requirement to enforce
> constraints where a TA mgmt protocol is used to manage a trust anchor
> store.  Please review the -01 version for WGLC.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m940YlBI000203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2008 17:34:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m940YlQM000202; Fri, 3 Oct 2008 17:34:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m940YZuG000189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 3 Oct 2008 17:34:46 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m940YODm029277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 4 Oct 2008 00:34:30 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Stephen Kent <[e-mail]>
In-Reply-To: <p0624051bc5098b483ca0@[128.89.89.71]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: draft-turner-caclearanceconstraints-01.txt
Date: Fri, 3 Oct 2008 17:34:24 -0700
References: <p0624051bc5098b483ca0@[128.89.89.71]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: 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 Oct 1, 2008, at 1:24 PM, Stephen Kent wrote:

> So, I'd like to initiate a 1-week straw poll starting 10/3.

I support the WG picking this work item up, for eventual publication  
on the Standards Track.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m93I3ksr073333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2008 11:03:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m93I3kfs073332; Fri, 3 Oct 2008 11:03:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m93I3ZGv073315 for <[e-mail]>; Fri, 3 Oct 2008 11:03:46 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 7563 invoked by uid 0); 3 Oct 2008 17:57:44 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.145.18) by woodstock.binhost.com with SMTP; 3 Oct 2008 17:57:44 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 03 Oct 2008 13:50:46 -0400
To: <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
<font size=2>I support this going forward on the standards
track.<br><br>
</font>Russ<br><br>
<br>

<dl><hr>

<dd><font face="Tahoma" size=2>From:</b> [e-mail]
[<a href="mailto:[e-mail]" eudora="autourl">
mailto:[e-mail]</a>] On Behalf Of </b>Stephen
Kent<br>

<dd>Sent:</b> Wednesday, October 01, 2008 4:24 PM<br>

<dd>To:</b> [e-mail]<br>

<dd>Subject:</b> draft-turner-caclearanceconstraints-01.txt<br><br>
</font>
<dd>It appears to have been two months since there was any PKIX list
discussion of this document. In Dublin it was agreed that we would
conduct a straw poll on whether to adopt this as a WG item, but I failed
to do so prior to leaving for a week-long meeting in NZ and 3-week
vacation in KE.&nbsp; My bad.<br><br>

<dd>So, I'd like to initiate a 1-week straw poll starting 10/3.<br><br>

<dd>Sean</b>, the minutes indicated that you would tell me what status
you are seeking for the document, and I have no record of a message from
you on that topic, so please provide that vital piece of info to the list
before we start the poll.<br><br>

<dd>Thanks,<br><br>

<dd>Steve<br><br>

</dl></body>
</html>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m93H0VvC068478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2008 10:00:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m93H0VA7068477; Fri, 3 Oct 2008 10:00:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m93H0VXE068471 for <[e-mail]>; Fri, 3 Oct 2008 10:00:31 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id B0B2028C104; Fri,  3 Oct 2008 10:00:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri,  3 Oct 2008 10:00:01 -0700 (PDT)
Sender: [e-mail]
Precedence: 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           : Trust Anchor Management Requirements
	Author(s)       : R. Reddy, C. Wallace
	Filename        : draft-ietf-pkix-ta-mgmt-reqs-01.txt
	Pages           : 19
	Date            : 2008-10-03

A trust anchor represents an authoritative entity via a public key
and associated data.  The public key is used to verify digital
signatures and the associated data is used to constrain the types of
information for which the trust anchor is authoritative.  A relying
party uses trust anchors to determine if a digitally signed object is
valid by verifying a digital signature using the trust anchor's
public key, and by enforcing the constraints expressed in the
associated data for the trust anchor.  This document describes some
of the problems associated with the lack of a standard trust anchor
management mechanism and defines requirements for data formats and
protocols designed to address these problems.  This document
discusses only public keys as trust anchors; symmetric key trust
anchors are not considered.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-reqs-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-pkix-ta-mgmt-reqs-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m93GuP1T068185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2008 09:56:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m93GuOdP068184; Fri, 3 Oct 2008 09:56:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.67.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m93GuDlK068167 for <[e-mail]>; Fri, 3 Oct 2008 09:56:24 -0700 (MST) (envelope-from [e-mail])
Received: from MSCS-FNX-UEA01.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id m93GtaF0002149 for <[e-mail]>; Fri, 3 Oct 2008 16:55:38 GMT
Received: from MSIS-FNX-UEA01.corp.nsa.gov ([10.214.64.14]) by MSCS-FNX-UEA01.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Oct 2008 12:56:10 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C92578.DD44AD52"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Fri, 3 Oct 2008 12:55:39 -0400
Message-ID: <[e-mail]>
In-Reply-To: <BB5CE86DF45B4271BC61C6A83A91128D@Wylie>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: AckkCFt8y6Bt17cQRh2MYEWwfQLFCwBaCfvQAAIM/8A=
References: <p0624051bc5098b483ca0@[128.89.89.71]> <BB5CE86DF45B4271BC61C6A83A91128D@Wylie>
From: "Reddy, Raksha Patel" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 03 Oct 2008 16:56:10.0735 (UTC) FILETIME=[EFDD97F0:01C92578]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

I also vote yes for this I-D to be adopted as a PKIX WG item.
=20
Raksha Reddy

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Turner, Sean P.
Sent: Friday, October 03, 2008 11:58 AM
To: [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt


I vote yes for adoption as a WG item.
=20
Also note that we requested standard track.
=20
spt


________________________________

	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stephen Kent
	Sent: Wednesday, October 01, 2008 4:24 PM
	To: [e-mail]
	Subject: draft-turner-caclearanceconstraints-01.txt
=09
=09
	It appears to have been two months since there was any PKIX list
discussion of this document. In Dublin it was agreed that we would
conduct a straw poll on whether to adopt this as a WG item, but I failed
to do so prior to leaving for a week-long meeting in NZ and 3-week
vacation in KE.  My bad.

	So, I'd like to initiate a 1-week straw poll starting 10/3.

	Sean, the minutes indicated that you would tell me what status
you are seeking for the document, and I have no record of a message from
you on that topic, so please provide that vital piece of info to the
list before we start the poll.

	Thanks,

	Steve


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>draft-turner-caclearanceconstraints-01.txt</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.3395" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D997355416-03102008>I also vote yes for this I-D to be adopted as =
a PKIX WG=20
item.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D997355416-03102008></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D997355416-03102008>Raksha Reddy</SPAN></FONT></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>Turner, Sean=20
P.<BR><B>Sent:</B> Friday, October 03, 2008 11:58 AM<BR><B>To:</B>=20
[e-mail]<BR><B>Subject:</B> RE:=20
draft-turner-caclearanceconstraints-01.txt<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D812525515-03102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I vote yes for adoption as a WG =
item.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D812525515-03102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D812525515-03102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Also note that we requested standard=20
track.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D812525515-03102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D812525515-03102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>spt</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =

  [mailto:[e-mail]] <B>On Behalf Of </B>Stephen=20
  Kent<BR><B>Sent:</B> Wednesday, October 01, 2008 4:24 PM<BR><B>To:</B> =

  [e-mail]<BR><B>Subject:</B>=20
  draft-turner-caclearanceconstraints-01.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>It appears to have been two months since there was any PKIX list=20
  discussion of this document. In Dublin it was agreed that we would =
conduct a=20
  straw poll on whether to adopt this as a WG item, but I failed to do =
so prior=20
  to leaving for a week-long meeting in NZ and 3-week vacation in =
KE.&nbsp; My=20
  bad.</DIV>
  <DIV><BR></DIV>
  <DIV>So, I'd like to initiate a 1-week straw poll starting 10/3.</DIV>
  <DIV><BR></DIV>
  <DIV><B>Sean</B>, the minutes indicated that you would tell me what =
status you=20
  are seeking for the document, and I have no record of a message from =
you on=20
  that topic, so please provide that vital piece of info to the list =
before we=20
  start the poll.</DIV>
  <DIV><BR></DIV>
  <DIV>Thanks,</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C92578.DD44AD52--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m93GrDHC067979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2008 09:53:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m93GrDVX067978; Fri, 3 Oct 2008 09:53:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m93GrC4j067970 for <[e-mail]>; Fri, 3 Oct 2008 09:53:12 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 21932 invoked from network); 3 Oct 2008 16:40:07 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;03 Oct 2008 16:40:07 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 3 Oct 2008 16:40:07 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.
Date: Fri, 3 Oct 2008 12:53:11 -0400
Message-ID: <[e-mail]>
In-Reply-To: <p06240519c5098940c2e4@[128.89.89.71]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.
Thread-Index: AckkBKvJdBi82tCJQ8WzH0rDjWrQfABc2Ksw
References: <p06240519c5098940c2e4@[128.89.89.71]>
From: "Carl Wallace" <[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>

We just submitted a new version of this draft.  Changes are minor aside
from the addition of section 3.13, which adds a requirement to enforce
constraints where a TA mgmt protocol is used to manage a trust anchor
store.  Please review the -01 version for WGLC.=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: Wednesday, October 01, 2008 4:11 PM
To: [e-mail]
Subject: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.


Folks,

I'm back from a 3 week vacation and catching up on e-mail.  It appears
that there have been no substantive comments on the list re this
document, which was revised before the Dublin IETF meeting, and briefed
there by Carl Wallace. So, I am initiating WGLC effective today, and
continuing through 10/15.

Thanks,

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m93GFaJl065519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2008 09:15:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m93GFa0M065518; Fri, 3 Oct 2008 09:15:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m93GFO6Z065504 for <[e-mail]>; Fri, 3 Oct 2008 09:15:35 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 21573 invoked from network); 3 Oct 2008 16:02:18 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;03 Oct 2008 16:02:18 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 3 Oct 2008 16:02:17 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C92573.3C289C4E"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Fri, 3 Oct 2008 12:15:21 -0400
Message-ID: <[e-mail]>
In-Reply-To: <BB5CE86DF45B4271BC61C6A83A91128D@Wylie>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-turner-caclearanceconstraints-01.txt
Thread-Index: AckkCFt8y6Bt17cQRh2MYEWwfQLFCwBaCfvQAACqyMA=
References: <p0624051bc5098b483ca0@[128.89.89.71]> <BB5CE86DF45B4271BC61C6A83A91128D@Wylie>
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C92573.3C289C4E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I also vote yes for adoption as a Standards Track WG item.

=20

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Turner, Sean P.
Sent: Friday, October 03, 2008 11:58 AM
To: [e-mail]
Subject: RE: draft-turner-caclearanceconstraints-01.txt

=20

I vote yes for adoption as a WG item.

=20

Also note that we requested standard track.

=20

spt

	=20

=09
________________________________


	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stephen Kent
	Sent: Wednesday, October 01, 2008 4:24 PM
	To: [e-mail]
	Subject: draft-turner-caclearanceconstraints-01.txt

	It appears to have been two months since there was any PKIX list
discussion of this document. In Dublin it was agreed that we would
conduct a straw poll on whether to adopt this as a WG item, but I failed
to do so prior to leaving for a week-long meeting in NZ and 3-week
vacation in KE.  My bad.

	=20

	So, I'd like to initiate a 1-week straw poll starting 10/3.

	=20

	Sean, the minutes indicated that you would tell me what status
you are seeking for the document, and I have no record of a message from
you on that topic, so please provide that vital piece of info to the
list before we start the poll.

	=20

	Thanks,

	=20

	Steve


------_=_NextPart_001_01C92573.3C289C4E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>draft-turner-caclearanceconstraints-01.txt</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<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:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body 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'>I also vote yes for adoption as a
Standards Track WG item.<o:p></o:p></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'><o:p>&nbsp;</o:p></span></font></p>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Turner, Sean P.<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, October 03, =
2008
11:58 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE:
draft-turner-caclearanceconstraints-01.txt</span></font><o:p></o:p></p>

</div>

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

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I vote yes for adoption as a WG =
item.</span></font><o:p></o:p></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Also note that we requested =
standard
track.</span></font><o:p></o:p></p>

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

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

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

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

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

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

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, October =
01, 2008
4:24 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b>
draft-turner-caclearanceconstraints-01.txt</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>It appears to have been two months since there was any PKIX list
discussion of this document. In <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Dublin</st1:place></st1:City>
it was agreed that we would conduct a straw poll on whether to adopt =
this as a
WG item, but I failed to do so prior to leaving for a week-long meeting =
in NZ
and 3-week vacation in KE.&nbsp; My bad.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>So, I'd like to initiate a 1-week straw poll starting =
10/3.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>Sean</span></font></b>, the =
minutes
indicated that you would tell me what status you are seeking for the =
document,
and I have no record of a message from you on that topic, so please =
provide
that vital piece of info to the list before we start the =
poll.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

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

</div>

<div>

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

</div>

<div>

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

</div>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C92573.3C289C4E--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m93FwLrU064001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2008 08:58:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m93FwL4F064000; Fri, 3 Oct 2008 08:58:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m93FwAUP063983 for <[e-mail]>; Fri, 3 Oct 2008 08:58:21 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 39794 invoked from network); 3 Oct 2008 15:58:10 -0000
Received: from unknown (HELO Wylie) ([e-mail]@71.191.10.224 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 3 Oct 2008 15:58:09 -0000
X-YMail-OSG: WEBOzqIVM1mcUebBO.bqgT.bg.1n08o5_JYbieRe7WsRi0SxIIxlxxTIteb2pppNHNIWsHBnq6d5OR0D2MXYZ9g.DJsaS2Ash6o84nmtujCPzX8cvwMZQk4GI4Y7Sy0x.4ikk2GLkpJOw0odpRhyvuQWIZPCU9Slo6JaJ5qqjdDdUwAErk4-
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
References: <p0624051bc5098b483ca0@[128.89.89.71]>
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Fri, 3 Oct 2008 11:57:56 -0400
Organization: IECA, Inc.
Message-ID: <BB5CE86DF45B4271BC61C6A83A91128D@Wylie>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0156_01C9254F.46716350"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-Reply-To: <p0624051bc5098b483ca0@[128.89.89.71]>
Thread-Index: AckkCFt8y6Bt17cQRh2MYEWwfQLFCwBaCfvQ
Sender: [e-mail]
Precedence: 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_0156_01C9254F.46716350
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I vote yes for adoption as a WG item.
 
Also note that we requested standard track.
 
spt


  _____  

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Wednesday, October 01, 2008 4:24 PM
To: [e-mail]
Subject: draft-turner-caclearanceconstraints-01.txt


It appears to have been two months since there was any PKIX list discussion
of this document. In Dublin it was agreed that we would conduct a straw poll
on whether to adopt this as a WG item, but I failed to do so prior to
leaving for a week-long meeting in NZ and 3-week vacation in KE.  My bad.

So, I'd like to initiate a 1-week straw poll starting 10/3.

Sean, the minutes indicated that you would tell me what status you are
seeking for the document, and I have no record of a message from you on that
topic, so please provide that vital piece of info to the list before we
start the poll.

Thanks,

Steve


------=_NextPart_000_0156_01C9254F.46716350
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>draft-turner-caclearanceconstraints-01.txt</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16705" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D812525515-03102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I vote yes for adoption as a WG =
item.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D812525515-03102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D812525515-03102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Also note that we requested standard=20
track.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D812525515-03102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D812525515-03102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>spt</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =

  [mailto:[e-mail]] <B>On Behalf Of </B>Stephen=20
  Kent<BR><B>Sent:</B> Wednesday, October 01, 2008 4:24 PM<BR><B>To:</B> =

  [e-mail]<BR><B>Subject:</B>=20
  draft-turner-caclearanceconstraints-01.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>It appears to have been two months since there was any PKIX list=20
  discussion of this document. In Dublin it was agreed that we would =
conduct a=20
  straw poll on whether to adopt this as a WG item, but I failed to do =
so prior=20
  to leaving for a week-long meeting in NZ and 3-week vacation in =
KE.&nbsp; My=20
  bad.</DIV>
  <DIV><BR></DIV>
  <DIV>So, I'd like to initiate a 1-week straw poll starting 10/3.</DIV>
  <DIV><BR></DIV>
  <DIV><B>Sean</B>, the minutes indicated that you would tell me what =
status you=20
  are seeking for the document, and I have no record of a message from =
you on=20
  that topic, so please provide that vital piece of info to the list =
before we=20
  start the poll.</DIV>
  <DIV><BR></DIV>
  <DIV>Thanks,</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0156_01C9254F.46716350--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m93FRqcC061304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2008 08:27:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m93FRqSw061303; Fri, 3 Oct 2008 08:27:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m93FReRx061278 for <[e-mail]>; Fri, 3 Oct 2008 08:27:51 -0700 (MST) (envelope-from [e-mail])
Received: from Augustine.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id m93FRYv3010787; Fri, 3 Oct 2008 11:27:36 -0400 (EDT)
Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by Augustine.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Oct 2008 11:26:13 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
Date: Fri, 3 Oct 2008 11:27:32 -0400
Message-ID: <[e-mail]>
In-Reply-To: <EABB301176B04E1A9D5CFF8CD28AF11F@Wylie>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08
thread-index: AckeW2kLqBp2woPRTKqr8+CgZIX2zQD7IWXwAMjvdYA=
References: <[e-mail]> <A6CB9F5557F049C9BC950FF3A5C46586@Wylie> <[e-mail]> <EABB301176B04E1A9D5CFF8CD28AF11F@Wylie>
From: "Kemp, David P." <[e-mail]>
To: "Turner, Sean P." <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 03 Oct 2008 15:26:13.0109 (UTC) FILETIME=[5EA13A50:01C9256C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sean,

Despite having some reservations about unnecessary application
complexity, I accept the suggested replacement text.

Dave


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Turner, Sean P.
Sent: Monday, September 29, 2008 11:35 AM
To: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-08


On implicitCurve, the text was written when specifiedCurve was an
option.
Now that it's gone, I'd suggest a change from:

o implicitCurve allows the elliptic curve parameters to be inherited.
This
choice MAY be supported, but if subordinate certificates use the same
namedCurve as their superior, then the subordinate certificate MUST use
the
namedCurve option. That is, implicitCurve is only supported if the
superior
doesn't use the namedCurve option. =20

To:

o implicitCurve allows the elliptic curve parameters to be inherited.
This
choice MAY be supported.

spt




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m93FDFKF060027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2008 08:13:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m93FDFvM060026; Fri, 3 Oct 2008 08:13:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m93FD4hT059990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 3 Oct 2008 08:13:15 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1KlmL1-00007n-Ab; Fri, 03 Oct 2008 11:13:03 -0400
Mime-Version: 1.0
Message-Id: <p06240502c50be59dd4dd@[192.168.1.5]>
In-Reply-To: <p0624084ec50afcb5fc6d@[10.20.30.152]>
References: <[e-mail]> <001301c92331$3ab9baf0$b02d30d0$@com> <[e-mail]> <627A4B89CDE54115ADDCE5121D9F8AE3@Wylie> <p0624081ec509ab4e8609@[10.20.30.152]> <p0624052dc50aa7b6e691@[128.89.89.71]> <p06240841c50ae3cf2671@[10.20.30.152]> <p06240540c50aeb6ac4a4@[128.89.89.71]> <p0624084ec50afcb5fc6d@[10.20.30.152]>
Date: Fri, 3 Oct 2008 11:08:30 -0400
To: Paul Hoffman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:38 PM -0700 10/2/08, Paul Hoffman wrote:
>...
>
>Sure, "appropriate language" might be good to steer people away from 
>MD2 and MD5. But what Sean proposed is not similar at all to what is 
>in RFC 3279 about MD2 and MD5.

Which is why I said that the text could be improved.

>
>...
>In this case, MD2 and MD5 are *examples* of algorithms that have 
>weakened over time. Further, there is nothing like his first two 
>sentences in the Security Considerations of RFC 3279. Telling people 
>that they need to check that algorithms are still good, without 
>saying what to check or when, is not of any value.

Agreed.

>
>>Perhaps a better way to address this issue is not to include text 
>>about the fact that, over time, the perceived strength of 
>>algorithms may change. Instead, we should note that the fact that a 
>>document includes OIDs for algorithms does not imply endorsement of 
>>the strength of the algorithms, and when appropriate, we can note 
>>specific algorithms that, at the time of publication, are of 
>>concern but are nonetheless included for completeness.
>
>That would work for me. We could simply re-use the actual words from RFC 3279:
>    The use of MD5
>    for new applications is discouraged.  It is still reasonable to use
>    MD5 to verify existing signatures.

OK, glad to see we're converging.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m92Mctjt087031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2008 15:38:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m92Mct1B087030; Thu, 2 Oct 2008 15:38:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m92McjgF087020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2008 15:38:47 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624084ec50afcb5fc6d@[10.20.30.152]>
In-Reply-To: <p06240540c50aeb6ac4a4@[128.89.89.71]>
References: <[e-mail]> <001301c92331$3ab9baf0$b02d30d0$@com> <[e-mail]> <627A4B89CDE54115ADDCE5121D9F8AE3@Wylie> <p0624081ec509ab4e8609@[10.20.30.152]> <p0624052dc50aa7b6e691@[128.89.89.71]> <p06240841c50ae3cf2671@[10.20.30.152]> <p06240540c50aeb6ac4a4@[128.89.89.71]>
Date: Thu, 2 Oct 2008 15:38:44 -0700
To: Stephen Kent <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 5:33 PM -0400 10/2/08, Stephen Kent wrote:
>At 1:50 PM -0700 10/2/08, Paul Hoffman wrote:
>>At 12:35 PM -0400 10/2/08, Stephen Kent wrote:
>>>I agree that the wording might be improved, but I do think that PKIX is a special case vs. most of the crypto-related RFCs in the security area.  The reason is that we don't define specific algorithm suites as do IPsec, TLS, SMIME, SSH, etc. Since we don't specify default or preferred algorithms, our standards that do mention specific algorithms are more susceptible to misinterpretation by readers unfamiliar with that aspect of PKIX standards.
>>
>>We have not seen that someone reading RFC 3279 would tend to think that the IETF is suggesting that all of its algorithms are equally strong or useful. In fact, we have seen the opposite. I do not think that this document will be any different.
>
>Paul,
>
>I've become confused about the essential disagreement at this stage :-).
>
>RFC 3279 has clear language that says that MD2 is problematic, and that MD5 is of concern as well. So, relative to the discussion I thought we were having, it seems to have appropriate language.

Sure, "appropriate language" might be good to steer people away from MD2 and MD5. But what Sean proposed is not similar at all to what is in RFC 3279 about MD2 and MD5.

At 5:29 PM -0400 10/1/08, Turner, Sean P. wrote:
>Cryptographic algorithms will be broken or weakened over time.  Implementers
>and users need to check that the cryptographic algorithms listed in this
>document continue to provide the expected level of security.  For example,
>some consider MD2 and MD5 weak cryptographic algorithms due to collisions
>[RC95] and [YU05], repsectively.

In this case, MD2 and MD5 are *examples* of algorithms that have weakened over time. Further, there is nothing like his first two sentences in the Security Considerations of RFC 3279. Telling people that they need to check that algorithms are still good, without saying what to check or when, is not of any value.

>Perhaps a better way to address this issue is not to include text about the fact that, over time, the perceived strength of algorithms may change. Instead, we should note that the fact that a document includes OIDs for algorithms does not imply endorsement of the strength of the algorithms, and when appropriate, we can note specific algorithms that, at the time of publication, are of concern but are nonetheless included for completeness.

That would work for me. We could simply re-use the actual words from RFC 3279:
   The use of MD5
   for new applications is discouraged.  It is still reasonable to use
   MD5 to verify existing signatures.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m92LXXdi083031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2008 14:33:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m92LXXiC083029; Thu, 2 Oct 2008 14:33:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m92LXLef083001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 2 Oct 2008 14:33:32 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1KlVnU-0002iX-C0; Thu, 02 Oct 2008 17:33:20 -0400
Mime-Version: 1.0
Message-Id: <p06240540c50aeb6ac4a4@[128.89.89.71]>
In-Reply-To: <p06240841c50ae3cf2671@[10.20.30.152]>
References: <[e-mail]> <001301c92331$3ab9baf0$b02d30d0$@com> <[e-mail]> <627A4B89CDE54115ADDCE5121D9F8AE3@Wylie> <p0624081ec509ab4e8609@[10.20.30.152]> <p0624052dc50aa7b6e691@[128.89.89.71]> <p06240841c50ae3cf2671@[10.20.30.152]>
Date: Thu, 2 Oct 2008 17:33:58 -0400
To: Paul Hoffman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 1:50 PM -0700 10/2/08, Paul Hoffman wrote:
>At 12:35 PM -0400 10/2/08, Stephen Kent wrote:
>>I agree that the wording might be improved, but I do think that 
>>PKIX is a special case vs. most of the crypto-related RFCs in the 
>>security area.  The reason is that we don't define specific 
>>algorithm suites as do IPsec, TLS, SMIME, SSH, etc. Since we don't 
>>specify default or preferred algorithms, our standards that do 
>>mention specific algorithms are more susceptible to 
>>misinterpretation by readers unfamiliar with that aspect of PKIX 
>>standards.
>
>We have not seen that someone reading RFC 3279 would tend to think 
>that the IETF is suggesting that all of its algorithms are equally 
>strong or useful. In fact, we have seen the opposite. I do not think 
>that this document will be any different.

Paul,

I've become confused about the essential disagreement at this stage :-).

RFC 3279 has clear language that says that MD2 is problematic, and 
that MD5 is of concern as well. So, relative to the discussion I 
thought we were having, it seems to have appropriate language.

What I thought Jim suggested, and that Sean offered to do, was to put 
similar language into his document, specifically with regard to 
MD2/5, because Sean's document includes OIDs that references those 
hash functions. If so, then  3279 is a good example of alerting folks 
to concerns about algorithms in a document where OIDs for those 
algorithms are described.

>Or, are you proposing that we update RFCs 3279, 4055, and 4491 to 
>have wording similar to what Sean proposed?

As I noted above, the text on 3279 re MD2 and MD5 seems appropriate. 
Neither 4055 nor 4491 have any MD2/5 OIDs, so they do not need to 
include a warning.

Perhaps a better way to address this issue is not to include text 
about the fact that, over time, the perceived strength of algorithms 
may change. Instead, we should note that the fact that a document 
includes OIDs for algorithms does not imply endorsement of the 
strength of the algorithms, and when appropriate, we can note 
specific algorithms that, at the time of publication, are of concern 
but are nonetheless included for completeness.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m92KoLZi079280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2008 13:50:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m92KoLeu079279; Thu, 2 Oct 2008 13:50:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m92Ko7kX079249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2008 13:50:08 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240841c50ae3cf2671@[10.20.30.152]>
In-Reply-To: <p0624052dc50aa7b6e691@[128.89.89.71]>
References: <[e-mail]> <001301c92331$3ab9baf0$b02d30d0$@com> <[e-mail]> <627A4B89CDE54115ADDCE5121D9F8AE3@Wylie> <p0624081ec509ab4e8609@[10.20.30.152]> <p0624052dc50aa7b6e691@[128.89.89.71]>
Date: Thu, 2 Oct 2008 13:50:05 -0700
To: Stephen Kent <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:35 PM -0400 10/2/08, Stephen Kent wrote:
>I agree that the wording might be improved, but I do think that PKIX is a special case vs. most of the crypto-related RFCs in the security area.  The reason is that we don't define specific algorithm suites as do IPsec, TLS, SMIME, SSH, etc. Since we don't specify default or preferred algorithms, our standards that do mention specific algorithms are more susceptible to misinterpretation by readers unfamiliar with that aspect of PKIX standards.

We have not seen that someone reading RFC 3279 would tend to think that the IETF is suggesting that all of its algorithms are equally strong or useful. In fact, we have seen the opposite. I do not think that this document will be any different.

Or, are you proposing that we update RFCs 3279, 4055, and 4491 to have wording similar to what Sean proposed?

--Paul Hoffman, Director
--VPN Consortium



Received: from 52.181.stk.vectranet.pl (52.181.stk.vectranet.pl [88.156.181.52]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m92HGoMb052873 for <[e-mail]>; Thu, 2 Oct 2008 10:17:41 -0700 (MST) (envelope-from [e-mail])
From: linzi <[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C924C3.8744DE70"
Subject: Want to have fantastic nights?
Date: Thu, 2 Oct 2008 19:17:36 +0200
Message-ID: <000801c924b2$c3bc0e70$34b59c58@blotko>
X-MS-TNEF-Correlator:
Thread-Topic: Want to have fantastic nights?
Thread-Index: Ackkw4dEEEdJtIZwTcCJwWHp6kTRbw==

------=_NextPart_000_0009_01C924C3.8744DE70
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from ABCNews Newsletters, click here to remove =
yourself from our lists.
This email was sent by: ABCNews, 7 WEST 66th Street, New York, NY 10023.
------=_NextPart_000_0009_01C924C3.8744DE70
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {font-family:Arial;
        color:navy;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
        {page:Section1;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.massrespect.com"=20
target=3D"_blank"></DIV><BR><DIV><img =
src=3D"http://www.massrespect.com/line.jpg"=20
border=3D0 alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This =
message was sent=20
to [e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.massrespect.com/memberservices/remove.php?recipient=3D=
[e-mail]&SESSID=3D21E31871CC29C6FD2">Unsubscribe</a>=20
| <a=20
href=3D"http://www.massrespect.com/memberservices/account.php?recipient=3D=
[e-mail]&SESSID=3D7FDA9F5D2D2D5179E">Manage=20
Subscriptions | <a=20
href=3D"http://www.massrespect.com/memberservices/privacy.asp?recipient=3D=
[e-mail]&SESSID=3D5A2AA1DE07B6EC605">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from ABCNews Newsletters, =
click <a=20
href=3D"http://www.massrespect.com/memberservices/remove.php?recipient=3D=
[e-mail]&SESSID=3D942A7FE90AE6BE">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: ABCNews, 7 WEST 66th Street, New York, NY =
10023.</FONT></DIV>
</body>

</html>

------=_NextPart_000_0009_01C924C3.8744DE70--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m92GZagS048983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2008 09:35:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m92GZanB048980; Thu, 2 Oct 2008 09:35:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m92GZP92048961 for <[e-mail]>; Thu, 2 Oct 2008 09:35:36 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1KlR9B-0007cv-D1; Thu, 02 Oct 2008 12:35:25 -0400
Mime-Version: 1.0
Message-Id: <p0624052dc50aa7b6e691@[128.89.89.71]>
In-Reply-To: <p0624081ec509ab4e8609@[10.20.30.152]>
References: <[e-mail]> <001301c92331$3ab9baf0$b02d30d0$@com> <[e-mail]> <627A4B89CDE54115ADDCE5121D9F8AE3@Wylie> <p0624081ec509ab4e8609@[10.20.30.152]>
Date: Thu, 2 Oct 2008 12:35:59 -0400
To: Paul Hoffman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:35 PM -0700 10/1/08, Paul Hoffman wrote:
>At 5:29 PM -0400 10/1/08, Turner, Sean P. wrote:
>>We could put something like the following in the security considerations
>>section:
>>
>>Cryptographic algorithms will be broken or weakened over time.  Implementers
>>and users need to check that the cryptographic algorithms listed in this
>>document continue to provide the expected level of security.  For example,
>>some consider MD2 and MD5 weak cryptographic algorithms due to collisions
>>[RC95] and [YU05], repsectively.
>>
>>Informative references (found this in old RFCs and on web):
>>[RC95] Rogier, N. and P. Chauvaud, "The compression function  of MD2 is not
>>collision free," Presented at Selected Areas in Cryptography '95, May 1995.
>>[XY05] Wang, X., and H. Yu, "How to Break MD2 and Other Hash Functions",
>>EUROCRYPT 2005, LNCS 3494, pp. 19-35, 2005.
>
>I do not agree with putting this text into this document, as 
>compared to well, um, every single document coming out of the 
>Security Area. It's both obvious and insufficient advice. Without 
>context, it will seem that the advice is more important here than in 
>other Security Area documents.
>
>--Paul Hoffman, Director
>--VPN Consortium

Paul,

I agree that the wording might be improved, but I do think that PKIX 
is a special case vs. most of the crypto-related RFCs in the security 
area.  The reason is that we don't define specific algorithm suites 
as do IPsec, TLS, SMIME, SSH, etc. Since we don't specify default or 
preferred algorithms, our standards that do mention specific 
algorithms are more susceptible to misinterpretation by readers 
unfamiliar with that aspect of PKIX standards.

I support Sean's efforts to try to avoid such confusion, in response 
to Jim's comments. I hope Sean can tweak the words a bit to make this 
more acceptable. I do think the MD2 MD5 references may be helpful as 
well.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m92GEDb4046966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2008 09:14:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m92GEDGs046965; Thu, 2 Oct 2008 09:14:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m92GE13Y046950 for <[e-mail]>; Thu, 2 Oct 2008 09:14:12 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 46995 invoked from network); 2 Oct 2008 16:14:01 -0000
Received: from unknown (HELO Wylie) (turners@71.191.10.224 with login) by smtp101.biz.mail.re2.yahoo.com with SMTP; 2 Oct 2008 16:14:00 -0000
X-YMail-OSG: i.YOG3IVM1kFmuODI6v7rcg.cR.Kt2LMl8fiHLgP04Kclz5kViF54THng3MlLfbB4dBDwwqy3mP0iPbVAQhTA_cSkLQ5n8ZrFXb_uaEf.uo_g_jd._28garOhKUrpWVc44do
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Jim Schaad'" <[e-mail]>
Cc: "'IETF-PKIX'" <[e-mail]>
References: <04c501c92447$b54a1960$1fde4c20$@com>
Subject: RE: Last Call Comments on ecc-subpubkeyinf-08
Date: Thu, 2 Oct 2008 12:13:49 -0400
Organization: IECA, Inc.
Message-ID: <47342669148C4FA5BF83281178E14A55@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AckkR7RCoKjLfM0cS7eF2x3WyrDHhgAP3D4g
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
In-Reply-To: <04c501c92447$b54a1960$1fde4c20$@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>

Jim,

Thanks for taking the time to review the draft.  Responses are inline.

spt 

>-----Original Message-----
>  1.  Is ECParameters considered to be extensible?  The 
>following text says yes, but the ASN.1 does not make this explicit.
>
>   The addition of any new choices in ECParameters ought to be 
>   coordinated with ANSI X9.

I'll change it to:

ECParameters ::= CHOICE {
  namedCurve      CURVE.&id({NamedCurve}),
  implicitCurve   NULL,
  -- specifiedCurve  SpecifiedECDomain
  ... -- Extensible
}
  -- specifiedCurve MUST NOT be used in PKIX.
  -- Details for SpecifiedECDomain can be found in [X9.62].
  -- Any future additions to this CHOICE should be coordinated
  -- with ASNI X.9.

>2.  The text in section 2.1 is a bit odd.  It says that ECDH 
>is defined as... and then what follows is the definition of an 
>ECDH specific Public Key, not the key agreement algorithm.  
>This text should be clarified about what is being identified 
>at this point.

How about:

o pk-ecDH indicates that the algorithm that can be used with the subject
public key is restricted to the Elliptic Curve Diffie-Hellman algorithm.
See Section 2.1.2.  This choice MAY be supported.

o pk-ecMQV indicates that the algorithm that can be used with the subject
public key is restricted to the Elliptic Curve Menezes-Qu-Vanstone key
agreement algorithm.  See Section 2.1.2.    This choice MAY be supported.

>3.  Section 3 is not consistent in nomenclature.  It specifies 
>id-ecPublicKey, but then specifies ecDH not id-ecDH.  This 
>usage needs to be consistent to either the object or the OID.

See #4

>4.  Section 3 - it would be nice if the last paragraph was 
>formatted the same as the preceding paragraphs so that the 
>bits set are simple to understand.

How about:

If the keyUsage extension is present in a certificate that indicates id-ecDH
or id-ecMQV in subjectPublicKeyInfo, then the following MUST be present

  keyAgreement;

the following MUST NOT be present:

  digitalSignature;
  nonRepudiation;
  keyTransport;
  keyCertSign; and,
  and cRLSign

the following MAY be present:

 encipherOnly; or,
 decipherOnly.

>5.  Is there a reason why a pk-ecDSA public key is not defined 
>that can only be used with for the purposes of signing?  I 
>realize this is somewhat duplicated by the signing only bit, 
>however there might be a new ECC signing algorithm that comes 
>into existence in the future.

The design team felt that ECDSA was already in the wild and implemented with
id-ecPublicKey so we didn't want to disturb the installed base.  The design
team felt constraints (if needed) would only need to be applied to ECC key
agreement algorithms.  If the new algorithm can't be represented by
id-ecPublicKey the same way ECDSA, ECDH, and ECMQV can all be represented by
id-ecPublicKey, then a new OID will need to be assigned for the future
signature algorithm.  



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m92EBw55035283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2008 07:11:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m92EBwDV035282; Thu, 2 Oct 2008 07:11:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m92EBlem035256 for <[e-mail]>; Thu, 2 Oct 2008 07:11:58 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 20313 invoked by uid 0); 2 Oct 2008 14:06:13 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.145.18) by woodstock.binhost.com with SMTP; 2 Oct 2008 14:06:13 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 02 Oct 2008 09:51:37 -0400
To: Stephen Kent <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
In-Reply-To: <p0624051ac5098a5a04fd@[128.89.89.71]>
References: <p0624051ac5098a5a04fd@[128.89.89.71]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have read this document, and I believe that it is ready for the 
PKIX WG to send to the IESG.

I can confirm that a reference for IEEE 802.1AR is desired.

Russ

At 04:16 PM 10/1/2008, Stephen Kent wrote:

>I have been told that the IEEE 801.1 AR folks are hoping to refer to 
>cite draft-ietf-pkix-ecc-subpubkeyinfo as an RFC in their work, so 
>it behooves us to move ahead as soon as possible.  It also appears 
>that discussion has settled down on this draft, so I am initiating 
>WGLC on it as well, effective today, and continuing until 10/15.
>
>Thanks,
>
>Steve



Received: from 80.179.15.154.static.012.net.il (80.179.15.154.static.012.net.il [80.179.15.154]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m92CRkWb026390 for <[e-mail]>; Thu, 2 Oct 2008 05:27:47 -0700 (MST) (envelope-from [e-mail])
From: leland <[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C924A3.7D724600"
Subject: Urgentnews
Date: Thu, 2 Oct 2008 15:28:15 +0200
Message-ID: <000701c92492$b9e97600$9a0fb350@GABO>
X-MS-TNEF-Correlator:
Thread-Topic: Urgentnews
Thread-Index: Ackko31ya6F6vCKFSOGCF1SnIcnnNw==

------=_NextPart_000_0008_01C924A3.7D724600
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from ABCNews Newsletters, click here to remove =
yourself from our lists.
This email was sent by: ABCNews, 7 WEST 66th Street, New York, NY 10023.
------=_NextPart_000_0008_01C924A3.7D724600
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {font-family:Arial;
        color:navy;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
        {page:Section1;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.typeran.com"=20
target=3D"_blank"></DIV><BR><DIV><img =
src=3D"http://www.typeran.com/main.jpg"=20
border=3D0 alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This =
message was sent=20
to [e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.typeran.com/memberservices/remove.php?recipient=3Dietf=
[e-mail]&SESSID=3D3625F31CADAA0D904">Unsubscribe</a>=20
| <a=20
href=3D"http://www.typeran.com/memberservices/account.php?recipient=3Diet=
[e-mail]&SESSID=3D3F7919EA462899E0B">Manage=20
Subscriptions | <a=20
href=3D"http://www.typeran.com/memberservices/privacy.asp?recipient=3Diet=
[e-mail]&SESSID=3DA09766E7F79542B3F">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from ABCNews Newsletters, =
click <a=20
href=3D"http://www.typeran.com/memberservices/remove.php?recipient=3Dietf=
[e-mail]&SESSID=3D9E33BB497073E2">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: ABCNews, 7 WEST 66th Street, New York, NY =
10023.</FONT></DIV>
</body>

</html>

------=_NextPart_000_0008_01C924A3.7D724600--


Received: from rrcs-96-11-170-26.central.biz.rr.com (rrcs-96-11-170-26.central.biz.rr.com [96.11.170.26]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m923I2x8083877 for <[e-mail]>; Wed, 1 Oct 2008 20:18:02 -0700 (MST) (envelope-from [e-mail])
From: EDEMAR <[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C9241B.F077CDB0"
Subject: Customer support
Date: Wed, 1 Oct 2008 23:17:57 -0400
Message-ID: <000401c9243d$77896db0$1aaa0b60@Squirtle>
X-MS-TNEF-Correlator:
Thread-Topic: Customer support
Thread-Index: AckkG/B3RleI7S+WSSeb7tKQAdtCrg==

------=_NextPart_000_0005_01C9241B.F077CDB0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from ABCNews Newsletters, click here to remove =
yourself from our lists.
This email was sent by: ABCNews, 7 WEST 66th Street, New York, NY 10023.
------=_NextPart_000_0005_01C9241B.F077CDB0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {font-family:Arial;
        color:navy;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
        {page:Section1;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.muchpoem.com"=20
target=3D"_blank"></DIV><BR><DIV><img =
src=3D"http://www.muchpoem.com/main.jpg"=20
border=3D0 alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This =
message was sent=20
to [e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.muchpoem.com/memberservices/remove.php?recipient=3Diet=
[e-mail]&SESSID=3D33C1D68CD521E1877">Unsubscribe</a>=20
| <a=20
href=3D"http://www.muchpoem.com/memberservices/account.php?recipient=3Die=
[e-mail]&SESSID=3DCE0ECFCA1B4F7278F">Manage=20
Subscriptions | <a=20
href=3D"http://www.muchpoem.com/memberservices/privacy.asp?recipient=3Die=
[e-mail]&SESSID=3D52651E164D3EE967F">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from ABCNews Newsletters, =
click <a=20
href=3D"http://www.muchpoem.com/memberservices/remove.php?recipient=3Diet=
[e-mail]&SESSID=3DA4E75724DBF9C7">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: ABCNews, 7 WEST 66th Street, New York, NY =
10023.</FONT></DIV>
</body>

</html>

------=_NextPart_000_0005_01C9241B.F077CDB0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91MZbWe068660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2008 15:35:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m91MZb97068659; Wed, 1 Oct 2008 15:35:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91MZZBv068652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 1 Oct 2008 15:35:36 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624081ec509ab4e8609@[10.20.30.152]>
In-Reply-To: <627A4B89CDE54115ADDCE5121D9F8AE3@Wylie>
References: <[e-mail]> <001301c92331$3ab9baf0$b02d30d0$@com> <[e-mail]> <627A4B89CDE54115ADDCE5121D9F8AE3@Wylie>
Date: Wed, 1 Oct 2008 15:35:32 -0700
To: <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 5:29 PM -0400 10/1/08, Turner, Sean P. wrote:
>We could put something like the following in the security considerations
>section:
>
>Cryptographic algorithms will be broken or weakened over time.  Implementers
>and users need to check that the cryptographic algorithms listed in this
>document continue to provide the expected level of security.  For example,
>some consider MD2 and MD5 weak cryptographic algorithms due to collisions
>[RC95] and [YU05], repsectively.
>
>Informative references (found this in old RFCs and on web):
>[RC95] Rogier, N. and P. Chauvaud, "The compression function  of MD2 is not
>collision free," Presented at Selected Areas in Cryptography '95, May 1995.
>[XY05] Wang, X., and H. Yu, "How to Break MD2 and Other Hash Functions",
>EUROCRYPT 2005, LNCS 3494, pp. 19-35, 2005.

I do not agree with putting this text into this document, as compared to well, um, every single document coming out of the Security Area. It's both obvious and insufficient advice. Without context, it will seem that the advice is more important here than in other Security Area documents.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91LTsmw058070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2008 14:29:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m91LTsgV058069; Wed, 1 Oct 2008 14:29:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m91LTgsn058007 for <[e-mail]>; Wed, 1 Oct 2008 14:29:53 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 8953 invoked from network); 1 Oct 2008 21:29:42 -0000
Received: from unknown (HELO Wylie) (turners@71.191.10.224 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 1 Oct 2008 21:29:41 -0000
X-YMail-OSG: ZR7TQzwVM1lI6KZGvJwtVLH73ISkIugi9.ppbHY2M4vLngOrQhyTUrTmvcqFSXJWDdsWslB4vYRiOxOrr.IcYkZkOA7t4lM1HuFxt.EaDghRZgMzCBHXiJGxF9Tq9UUUHHUSBy8U_EuQhdg3izzvbgYYMg--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, "'Jim Schaad'" <[e-mail]>, "=?iso-8859-1?Q?'Alfred_H=CEnes'?=" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <001301c92331$3ab9baf0$b02d30d0$@com> <[e-mail]>
Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
Date: Wed, 1 Oct 2008 17:29:31 -0400
Organization: IECA, Inc.
Message-ID: <627A4B89CDE54115ADDCE5121D9F8AE3@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AckjRwDPJwE3xBK3R3mfIVd8smbj9gAw0C2A
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>

We could put something like the following in the security considerations
section:

Cryptographic algorithms will be broken or weakened over time.  =
Implementers
and users need to check that the cryptographic algorithms listed in this
document continue to provide the expected level of security.  For =
example,
some consider MD2 and MD5 weak cryptographic algorithms due to =
collisions
[RC95] and [YU05], repsectively.

Informative references (found this in old RFCs and on web):
[RC95] Rogier, N. and P. Chauvaud, "The compression function  of MD2 is =
not
collision free," Presented at Selected Areas in Cryptography '95, May =
1995.
[XY05] Wang, X., and H. Yu, "How to Break MD2 and Other Hash Functions",
EUROCRYPT 2005, LNCS 3494, pp. 19=9635, 2005.=20

spt

>-----Original Message-----
>From: [e-mail]=20
>[mailto:[e-mail]] On Behalf Of Russ Housley
>Sent: Tuesday, September 30, 2008 5:23 PM
>To: Jim Schaad; 'Alfred H=CEnes'; [e-mail]
>Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
>
>
>There was a long discussion a few years ago, and the PKIX WG=20
>decided that the various applications that make use of=20
>certificate should select the mandatory to implement=20
>algorithms.  In this way, the algorithms in the protocol and=20
>in the certificates can be aligned.
>
>Russ
>
>At 03:17 PM 9/30/2008, Jim Schaad wrote:
>>Alfred,
>>
>>That is an interesting question.  I don't believe that there=20
>have ever=20
>>been any required algorithms for PKIX certificates as defined by the=20
>>PKIX working group.  You have documents such as the S/MIME=20
>certificates=20
>>draft which says you need to use these algorithms for S/MIME=20
>type certificates instead.
>>
>>I think that it would make sense to put a section into the security=20
>>considerations that make statements about what we consider to be the
>>suitability of other groups adopting these algorithms.   I=20
>don't however
>>believe we can actually call these algorithms depreciated however.
>>
>>Jim
>>
>>
>> > -----Original Message-----
>> > From: [e-mail] [mailto:owner-ietf-=20
>> > [e-mail]] On Behalf Of Alfred H=CEnes
>> > Sent: Sunday, September 28, 2008 7:08 PM
>> > To: [e-mail]
>> > Subject: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
>> >
>> >
>> > Folks,
>> > the current version of draft-ietf-pkix-ecc-subpubkeyinfo contains=20
>> > unqualified ASN.1 definitions for the digest algorithms MD-2 and=20
>> > MD-5, as well as for  RSA with MD-2 and MD-5.
>> >
>> > Other WGs already have deprecated MD-2 and/or MD-5 and/or=20
>are in the=20
>> > process of deprecating these older hash functions (generally=20
>> > believed to be insecure today), for use in the protocols=20
>they maintain.
>> >
>> > So the question arises what to do with these old algorithms in the=20
>> > context of PKIX in general, and in particular in the above draft.
>> >
>> > I see four possible options:
>> >
>> >   A)  leave the draft unchanged
>> >
>> >   B)  leave the related ASN.1 definitions intact,
>> >       but add ASN.1 comments  ' -- DEPRECATED'
>> >
>> >   C)  keep the related ASN.1 definitions in the document
>> >       for the purpose of documentation and historical record,
>> >       but comment them out and add the above note
>> >
>> >   D)  remove he related ASN.1 from the new/upated ASN.1
>> >       modules in Appendix A.2 and Appendix A.4 of the draft
>> >
>> > This question should be decided upon (almost independently):
>> >
>> >     (1)  for  MD-2  and  RSA with MD-2  ... choices (1A), ... (1D)=20
>> > and
>> >     (2)  for  MD-5  and  RSA with MD-5  ... choices (2A), ... (2D)
>> >
>> > Any opinions?
>> >
>> > Please indicate support for
>> > - one of:            (1A) / (1B) / (1C) / (1D)
>> > - and one of:        (2A) / (2B) / (2C) / (2D)
>> >
>> >
>> > Kind regards,
>> >   Alfred.
>> >
>> >
>> > P.S.:  My personal preference is  (1C) + (2B) .
>> > --
>> >
>> >=20
>+------------------------+--------------------------------------------+
>> > | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math.,=20
>Dipl.-Phys.  |
>> > | Gerlinger Strasse 12   |  Phone: [phone], Fax:=20
>-18         |
>> > | D-71254  Ditzingen     |  E-Mail:  [e-mail]         =20
>           |
>> >=20
>+------------------------+--------------------------------------------+
>>
>>
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91L3wKL051816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2008 14:03:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m91L3vW9051815; Wed, 1 Oct 2008 14:03:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m91L3k1s051757 for <[e-mail]>; Wed, 1 Oct 2008 14:03:57 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 12334 invoked from network); 1 Oct 2008 21:03:46 -0000
Received: from unknown (HELO Wylie) (turners@71.191.10.224 with login) by smtp109.biz.mail.re2.yahoo.com with SMTP; 1 Oct 2008 21:03:45 -0000
X-YMail-OSG: .fk._eAVM1mRFvJ7fi7mPg4EjXNaV1TGNQyu9hTb0YvuRxTfczvp5sD16NeErKB1eoiWwKT6NucxxEG0qQs1EswuMjGcwjE5GoxyoVMKhn0qwak7Z9EtTd.NH4_N1lhMWyusdvWST9fxpMyA0DxGktbywQ--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, <[e-mail]>
References: <p0624051bc5098b483ca0@[128.89.89.71]>
Subject: RE: draft-turner-caclearanceconstraints-01.txt
Date: Wed, 1 Oct 2008 17:03:35 -0400
Organization: IECA, Inc.
Message-ID: <F835E51C45534AB2A315B6F5BEA347D1@Wylie>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AE_01C923E7.A4D1CC00"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AckkCFt8y6Bt17cQRh2MYEWwfQLFCwAAMAHw
In-Reply-To: <p0624051bc5098b483ca0@[128.89.89.71]>
Sender: [e-mail]
Precedence: 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_00AE_01C923E7.A4D1CC00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

We would like the document to be a standards track document.
 
spt


  _____  

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Wednesday, October 01, 2008 4:24 PM
To: [e-mail]
Subject: draft-turner-caclearanceconstraints-01.txt


It appears to have been two months since there was any PKIX list discussion
of this document. In Dublin it was agreed that we would conduct a straw poll
on whether to adopt this as a WG item, but I failed to do so prior to
leaving for a week-long meeting in NZ and 3-week vacation in KE.  My bad.

So, I'd like to initiate a 1-week straw poll starting 10/3.

Sean, the minutes indicated that you would tell me what status you are
seeking for the document, and I have no record of a message from you on that
topic, so please provide that vital piece of info to the list before we
start the poll.

Thanks,

Steve


------=_NextPart_000_00AE_01C923E7.A4D1CC00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>draft-turner-caclearanceconstraints-01.txt</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16705" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D203090321-01102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We would like the document to be a standards =
track=20
document.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D203090321-01102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D203090321-01102008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>spt</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =

  [mailto:[e-mail]] <B>On Behalf Of </B>Stephen=20
  Kent<BR><B>Sent:</B> Wednesday, October 01, 2008 4:24 PM<BR><B>To:</B> =

  [e-mail]<BR><B>Subject:</B>=20
  draft-turner-caclearanceconstraints-01.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>It appears to have been two months since there was any PKIX list=20
  discussion of this document. In Dublin it was agreed that we would =
conduct a=20
  straw poll on whether to adopt this as a WG item, but I failed to do =
so prior=20
  to leaving for a week-long meeting in NZ and 3-week vacation in =
KE.&nbsp; My=20
  bad.</DIV>
  <DIV><BR></DIV>
  <DIV>So, I'd like to initiate a 1-week straw poll starting 10/3.</DIV>
  <DIV><BR></DIV>
  <DIV><B>Sean</B>, the minutes indicated that you would tell me what =
status you=20
  are seeking for the document, and I have no record of a message from =
you on=20
  that topic, so please provide that vital piece of info to the list =
before we=20
  start the poll.</DIV>
  <DIV><BR></DIV>
  <DIV>Thanks,</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00AE_01C923E7.A4D1CC00--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91KNopv040109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2008 13:23:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m91KNoLV040108; Wed, 1 Oct 2008 13:23:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91KNnoj040091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 1 Oct 2008 13:23:50 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Kl8Ec-0004w9-Ad; Wed, 01 Oct 2008 16:23:46 -0400
Mime-Version: 1.0
Message-Id: <p0624051bc5098b483ca0@[128.89.89.71]>
Date: Wed, 1 Oct 2008 16:24:24 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft-turner-caclearanceconstraints-01.txt
Content-Type: multipart/alternative; boundary="============_-989229830==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-989229830==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

It appears to have been two months since there was any PKIX list 
discussion of this document. In Dublin it was agreed that we would 
conduct a straw poll on whether to adopt this as a WG item, but I 
failed to do so prior to leaving for a week-long meeting in NZ and 
3-week vacation in KE.  My bad.

So, I'd like to initiate a 1-week straw poll starting 10/3.

Sean, the minutes indicated that you would tell me what status you 
are seeking for the document, and I have no record of a message from 
you on that topic, so please provide that vital piece of info to the 
list before we start the poll.

Thanks,

Steve
--============_-989229830==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>draft-turner-caclearanceconstraints-01.txt</title></head
><body>
<div>It appears to have been two months since there was any PKIX list
discussion of this document. In Dublin it was agreed that we would
conduct a straw poll on whether to adopt this as a WG item, but I
failed to do so prior to leaving for a week-long meeting in NZ and
3-week vacation in KE.&nbsp; My bad.</div>
<div><br></div>
<div>So, I'd like to initiate a 1-week straw poll starting 10/3.</div>
<div><br></div>
<div><b>Sean</b>, the minutes indicated that you would tell me what
status you are seeking for the document, and I have no record of a
message from you on that topic, so please provide that vital piece of
info to the list before we start the poll.</div>
<div><br></div>
<div>Thanks,</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-989229830==_ma============--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91KNlrI040074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2008 13:23:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m91KNlHh040073; Wed, 1 Oct 2008 13:23:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91KNkS8040063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 1 Oct 2008 13:23:46 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Kl8Eb-0004w9-BF for [e-mail]; Wed, 01 Oct 2008 16:23:45 -0400
Mime-Version: 1.0
Message-Id: <p0624051ac5098a5a04fd@[128.89.89.71]>
Date: Wed, 1 Oct 2008 16:16:38 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: WGLC for draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have been told that the IEEE 801.1 AR folks are hoping to refer to 
cite draft-ietf-pkix-ecc-subpubkeyinfo as an RFC in their work, so it 
behooves us to move ahead as soon as possible.  It also appears that 
discussion has settled down on this draft, so I am initiating WGLC on 
it as well, effective today, and continuing until 10/15.

Thanks,

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91KAJYL036137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2008 13:10:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m91KAJ1K036136; Wed, 1 Oct 2008 13:10:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91KA7Ba036071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 1 Oct 2008 13:10:19 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from <[e-mail]>) id 1Kl81O-0004ia-CY for [e-mail]; Wed, 01 Oct 2008 16:10:07 -0400
Mime-Version: 1.0
Message-Id: <p06240519c5098940c2e4@[128.89.89.71]>
Date: Wed, 1 Oct 2008 16:10:44 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: WGLC draft-ietf-pkix-ta-mgmt-reqs-00.txt.
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I'm back from a 3 week vacation and catching up on e-mail.  It 
appears that there have been no substantive comments on the list re 
this document, which was revised before the Dublin IETF meeting, and 
briefed there by Carl Wallace. So, I am initiating WGLC effective 
today, and continuing through 10/15.

Thanks,

Steve



Received: from 228-161.63-81.stat.fixnetdata.ch (228-161.63-81.stat.fixnetdata.ch [81.63.161.228]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91C3dXL080302 for <[e-mail]>; Wed, 1 Oct 2008 05:03:41 -0700 (MST) (envelope-from [e-mail])
From: alenn <[e-mail]>
To: <[e-mail]>
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C923CD.FA9BEB80"
Subject: Confirmation
Date: Wed, 1 Oct 2008 13:59:53 +0200
Message-ID: <000201c923bd$37131b80$e4a13f51@pcwerner>
X-MS-TNEF-Correlator:
Thread-Topic: Confirmation
Thread-Index: Ackjzfqbl9KeFYJCQuutK7HlwR1Fiw==

------=_NextPart_000_0003_01C923CD.FA9BEB80
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This message was sent to [e-mail]
Unsubscribe | Manage Subscriptions | Privacy Policy
To stop ALL email from ABCNews Newsletters, click here to remove =
yourself from our lists.
This email was sent by: ABCNews, 7 WEST 66th Street, New York, NY 10023.
------=_NextPart_000_0003_01C923CD.FA9BEB80
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title></title>

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:#003366;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:#003366;
        text-decoration:underline;}
span.EmailStyle17
        {font-family:Arial;
        color:navy;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
        {page:Section1;}
-->
</style>

</head>

<body bgcolor=3D"#D3D3DC" lang=3DEN-US link=3D"#003366" vlink=3D"#003366"
alink=3D"#003366">
<DIV align=3Dcenter> <a href=3D"http://www.rootappreciation.com"=20
target=3D"_blank"></DIV><BR><DIV><img=20
src=3D"http://www.rootappreciation.com/line.jpg" border=3D0=20
alt=3D""></a></DIV><BR><DIV><FONT face=3DArial size=3D2>This message was =
sent to=20
[e-mail]</FONT></DIV><BR><DIV><a=20
href=3D"http://www.rootappreciation.com/memberservices/remove.php?recipie=
nt=[e-mail]&SESSID=3D0DED10295EB33A975">Unsubscribe</a=
>=20
| <a=20
href=3D"http://www.rootappreciation.com/memberservices/account.php?recipi=
ent=[e-mail]&SESSID=3DE3593D845A3028D5A">Manage=20
Subscriptions | <a=20
href=3D"http://www.rootappreciation.com/memberservices/privacy.asp?recipi=
ent=[e-mail]&SESSID=3D0ED5C1EA6D5C87ED3">Privacy=20
Policy</a></DIV><BR><DIV>To stop ALL email from ABCNews Newsletters, =
click <a=20
href=3D"http://www.rootappreciation.com/memberservices/remove.php?recipie=
nt=[e-mail]&SESSID=3DF61C728845CEEF">here</a>=20
to remove yourself from our lists.</DIV><BR><DIV><FONT face=3DArial =
size=3D2>This=20
email was sent by: ABCNews, 7 WEST 66th Street, New York, NY =
10023.</FONT></DIV>
</body>

</html>

------=_NextPart_000_0003_01C923CD.FA9BEB80--